Re: [1076.1] Information on proposed IP support in VHDL-200X

Olivier,

See my replies below.

> The context is to define a standard based on well-defined, well 
> characterized and open methods and algorithms. The IP protection 
> mechanism currently in development for VHDL, Verilog and their AMS 
> extensions (and probably also for other design languages or formats) is 
> proposing a standard way to use existing encryption/decryption methods 
> that have been extensively studied and published. As John said, the 
> secret here is in the keys. The obfuscation method you are advocating is 
> based on a private algorithm you are obviously not going to publish and 
> share since it is the key (and the secret) of a commercial tool. I can 
> hardly see a way to make a standard out of that.
> 
> /Answer:
> 1) See my last answer to John where well the secret is in the key, but 
> the secret is shared by more people/agencies that everybody wants to get 
> shared. It just doesn't work on a worldwide basis.
> 2) As long as you deal with obfuscated models, there is no need anymore 
> to think about setting a encryption standard since obfuscated models are 
> treated like source code models by simulators. You then save a lot of 
> time and effort in the standard commitee./

We are discussing at different, but complementary, levels. You are 
questioning the use and the performances of encryption-based methods, 
while I'm considering what could make a standard. A standard may exist 
when there is a large consensus on a way of doing something and when the 
related methods are known and openly established. How does this apply to 
the obfuscation method you are advocating?

> Now the objective. What do you want to show with the challenge? Assuming 
> nobody will be able or have the time or resources (or even care) to win 
> your challenge, what would then be the conclusion? To me, as far as I 
> can say, there would not be any evidence that the obfuscation approach 
> is secure in all cases. Again, the result of the exercise would not 
> bring more light for developing a standard.
> 
> /Answer:
> 1) What I want to show with this challenge is that if nobody can crack 
> the obfuscated model, there is a serious opportunity for the community 
> to get a excellent solution to protect its IP.

If so, how to go further? Are you going to publish your obfuscating 
method to make it a standard or just say the the standard should only 
say something like "The standard way to protect a VHDL-AMS model is to 
obfuscate the source code. How to do it is left to implementors"?

> 2) Getting something secure in all cases will never be guaranted 
> whatever the protection scheme used. Anyway, in most of the cases, the 
> security issue comes from the company employees themselves.
> 3) Have a look on my last answer to John where an well known encryption 
> method has been crack down by chinese mathematician 
> (http://www.infosecurity-magazine.com/news/050331_crypto.htm) and the 
> low security level of some encryption algorithm 
> (http://www.cnn.com/TECH/computing/9901/21/descrack.idg/). Whats about 
> encryption and  VHDL models where security should last at least until 
> patent expiration (10 or 20 years ?)

Each encryption algorithm has its strengths and weaknesses. Selecting 
the right one to use depends on many factors such as, among others, what 
the protected item is, its required level of confidentiality, who is 
assumed to manipulate it, and who should be prevented to access the 
source code. The proposed IP protection scheme supports this kind of 
selection for existing and upcoming encryption methods.

> 4) On top of  it, if you back go to the roots, an encryption scheme is 
> build two way (so its a question of time, effort ,IQ to get the original 
> source code back) where an obfuscation method is one way (so there is 
> formally no way to recover the original source code). It means that 
> legally you will always been able, via obfuscated code exchange, to 
> desmonstrate who is the real code owner vs. who has counterfait it.
> 5) If nobody care about such issues in the community then there is no 
> need to spend even a minute over potential encryption standards.

These are clearly two different, and maybe complementary, as John Willis 
suggested, use models. The people who developed the proposed IP 
protection selected the encryption as the base. The question is to 
figure out if there is a large consensus to revise the initial 
requirements to address the issues you are raising.

Best regards,
Alain Vachoux