Thanks John for your quick answer. It seems that you have only scratch the surface with your thought. Let me give some additional comments (see below in the core text). Dr. Olivier Rolland Systems'ViP c/o SEMIA 4, rue Boussingault F-67000 Strasbourg Tel: +33 671 128 130 Email: olivier.rolland@systemsvip.com Web: http://www.systemsvip.com Systems'ViP: Your innovation capitalization partner This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient,please delete this message and notify the sender John Shields wrote: > /Dr. Rolland, > > Thanks for the feedback and the thought exercise here. I made some > comments below and I apologize for repeating myself in places. I can't > spend much more time on this in the immediate future, but the thought > experiment has been interesting. I am clearer on the strengths and > weakness of the obsfucation approach. I wish you the best of luck with > this going forward. > / > / > Regards, John/ Answer: Thank you john for your good luck wishes. I notice that you have decided to give up on this intellectual fight, because of timing issue, where on the other hand you give so much time on conferences to promote an encryption based solution for the vhdl-ams community. Is that not strange? > > olivier.rolland@systemsvip.com wrote: >> John, >> >> Thank you for your answer. Let me provide some comments. >> >> 1) The foundation for the standard is open and published >> cryptographic algorithms and the flexibility of the pragmas should >> make it possible to build tools that afford legal compliance across >> countries. As always, the quality of tool implementations matters >> even when standards apply. You make some good points and the legal >> context is certainly one of them. As best I understand it, it was >> well considered when crafting the standard and it remains the domain >> of the tool developers and IP providers to assure they are compliant >> with any rules. >> >> Answer: >> In order to be compliant between all providers tools, you need first >> to share some keys between simulators softwares providers and >> guarantee that everybody uses exactly the same encryption/decryption >> algorithms with all variants implemented for different key lenght. In >> addition you have to guarante that users will stick to the US legal >> constraints (NSA or other agency key code registration) + Key lenght >> limitations depending on location where the software and encrypted >> VHDL, VHDL-AMS model is used. What is your proposal to help the >> end-user to cope with this complexity. On top of it, the encrypted >> source code is decrypted by the simulator before the code analysis >> and compilation because of the parser, compilers requirements. It >> means that a malicious organisation might be able to try to read the >> computer memory and get theVHDL, VHDL-AMS source code without >> tremendous efforts. Is there an answer in the standard proposal to >> prevent this type of issue? > /The algorithms are not an issue. They are themselves standard. It is > tool developer's job to build a correct implementation. A tool that > is not correct produces encrypted results that no one can read or is > incapable of decrypting anything legitimate. Such tools are easily > weeded out. Having to qualify new tool releases before committing > them to your production tool flow is nothing new for users, be they > providers or consumers of IP. > The key mgmt problem is not a short discussion, but it will not be the > burden you think. The key exchange is between the tool provider and > the IP owner, not between tool providers. No one has to guarantee > that users do the right thing, but the IP providers and tool providers > have to do the right thing. If a tool provider delivers a tool that > is capable of doing something that violates export laws, that is a > problem for them. If an IP provider delivers IP protected in a manner > such that no legal tool can decrypt it, that might be bad for > business. Of course I can't say what every tool might do, but your > concept of how a compiler or load-n-go simulator would handle the > decryption task is not what any tools that I know of would do. I do > not believe the malicious scenario you describe is realistic. > However, the IP provider has to trust the tools that you authorize to > handle your IP by providing them keys have a reasonable approach./ ANSWER: Algorithm is definitly an issue: First crypto guys will tell that they never trust an algoritm not implemented at home and second look at the reaction in this area with the encryption keys broken by chinese mathematicien a few month ago. The telecommunication industry has to rethink its cryptography implementation to prevent individual or government based hacking. Third, if you want to make your solution avalaible on a worldwide basis, you will end up with a really low crypto security level because of key deposit you have to make at each security government agency, because of local key lenght limitations and because of algorithm export limitation which prevent you from using really rugged crypto algorithm. All of that is basic stuff in the crypto world. The today proposed cryptographic implementation is a joke for a government agency and will protect the customers IP only in apparence. The malicious way I've described comes from existing implementations used in the past in other area. Concerning the key management, this might be a nightmare for the end user. Think about a company dealing with ten different Soft IP providers for a complex design. This company will have to manage all this keys (Think about the potential complexity of serious PKI (public Key Infrastructure)worldwide based) in a really clean manner, assuming that his underlying software will be able to cope with it. You just need to have a look on the music or video industry and the Digital Right Management issue ending up into several standards and end user community splitted by type of music players (ipod vs. Sony vs......). This is not a viable way for the VHD and VHDL-AMS industry and I hope that this is the goal of simlators providers. Do not forget that we deal with IEEE standards where, per definition, we want a really open world with low cost in term of data exchange. By the way, IF you want all simulators vendors to implement a complex key management system and the related encryption algoritms, there will be a lot of good job opportunities for crypto guys in the future. It will as well significantly increase the development cost of the software. The end-users will show their licence fees jumping up and that is absolutly not good news for the community. >> >> 2) If I may, you have made a case for source code obfuscation and it >> may prove to be effective protection for many applications. I do not >> understand enough of the approach you have advocated. Without the >> details and looking at a high level, I have some concerns. Perhaps >> you can shed some light? >> >> Answer: The difference between encryption and obfuscation lies in the >> fact that with the encryption, you make your source code unreadable >> by applying an encryption algorithm othe it. As long as you have the >> encryption key(s) and you know the algorithm used, you can reverse >> the process and you get the original code back. >> Using the obfuscation mechanism, you rewritte your source code in a >> new human unreadable source code while keeping it strictly identical >> at a simulator level after compilation.The consequence is that there >> is no need for key sharing and the process can't be applied >> backwards. It is stricly impossible to make a reverse engineering and >> therefore you get through this obfuscation mechanism a rugged, >> legally independant IP protection mechanism. The issue with it, is >> that developing such an obfuscator is a non trivial task. This is why >> encryption is usually the poor man implementation for IP protection. >> > /Of course a key is the secret. Without it, the encryption cannot be > broken. The algorithm is sufficiently strong that is not a problem > for it to be known. That is the nature of encryption and its inherent > strength. > So you are saying the algorithm for the obsfucator is the key to doing > this right. It itself is the secret. A poor algorithm would be > possibly be reversible, yes? Why would I want to trust a single > vendor? I think reverse engr does not need to come up with the same > names for objects, etc. to understand the original implementation. > The HDL has a set of keywords that must be preserved which itself > offers a lot of insight. > / Answer: Concerning the key and the secrecy have a look at my answer before. Concerning the obfuscation there is, per definition, no way to go backwards. For you there is no need to trust a single vendor since all of us can develop our own obfuscators. The issue, please remember, is that the task to develop such a tool is absolutely not trivial. The obfuscated code is treated like the source code by the simulator, so you don't have to bother with compatibility issue, there is no issue in this case. Yes, you can partially reverse engineer the obfuscated code with pretty printers tools (good point) and because you keep the HDL keywords. The problem is that it works quite well for a resistor definition, even if you never get the original comments and original signal names....But if you have to deal with industrial gradedesign with thousands of line codes, seeing the HDL keywords doesn't help you at all and that makes the difference. > // >> 3) First is that tools will not understand the intent to protect >> information because it is not conveyed with source code obfuscation. >> If there is information to be mined from obfuscated source, the tools >> will allow it in an oblivious manner, correct? Looking at the >> opposite problem, if there is information that the tool should convey >> because the intent of the IP provider is to open aspects (what is >> addressed by the viewport pragma in the VHDL IP protection spec) to >> the user, would the obfuscated source get in the way? Finally, I >> have no knowledge of your specific algorithms for obsfucation and >> what a determined hacker with a sufficient spec for what the IP is >> (in order to use it) might be able to do to reverse engineer it. I >> presume you would assert that it is next to impossible. I wonder >> whether that depends on the algorithms you use remaining trade >> secret. If you had the algorithm would it help unobsfucate the >> source? If not, would the availability of one proprietrary tool >> using these algorithms be of concern? Would other tools attempt >> obsfucation and inferior implementations lead to compromise? >> >> Answer: There is no need to convey obfuscation intent information, >> since original source code or obfuscated code is transparent on the >> compiler simulator level.E.g. If a variable is called >> "temperature_input" or "10001111001100100101" it has a lot of meaning >> for a human being but make no difference for a simulator. This >> approach is valid as well constant values, code suite, not speaking >> about comments which are useless for a simulator. >> Concerning the obfuscation algorithm, this algorithm is useless to >> un-obfuscate the source, this is why I told you that this solution >> really rugged (no need to mention the application potential). >> Bottom line, an obfuscated code is treated the same a a source by a >> compiler. This then no tool dependency as long as the source has been >> written in a way where the original code is understood by all simlators. >> > /I disagree with the first part of your answer. If tool must report > information which is meaningful only if the original declarations are > used, there is a problem. The interface declaration has to be > readable enough to use, so if you can't change it, you can see how it > is referenced in the obsfucated source. If a tool can support code > understanding and causality tracing, it will show hierarchical > structure and loads and drivers. You can write an obsfuscator that > uses long, unintelligable names and hides meaningful white space. I > can write a tool that collects and substitutes better, cleaner names > and pretty prints the source, correct? I might even have an > interactive tool in which I review and cleanup names on the fly as my > understanding grows./ Answer: You can design an obfuscator where the top level interface is readable. As said befor a pretty printer will help you to see the structure but you have no chance concerning the meaning of it. It is like having a pretty printer to decipher the structure of a chinese book (for the one not understanding the mandarin language) and a grammatic analysis tool. As long as you do not understand the meaning of the words all this tools are meaningless. This is the key lesson concerning the obfuscators and this one of the reason why it is so succesfull in the java community where I wissh that one day the VHDL VHDL-AMS community will see its language be spread as far as it is the case for the java language. >> My point is really to say that I do not understand enough of the >> technical approach you have advocated and I am, of course, an >> advocate for the current standard approach. Of course, it will have >> to prove itself in the marketplace like anything else. >> >> In order to make the point clear to everybody, my proposal is to >> provide, to all of you ,an obfuscated VHDL-AMS model (with its spec >> documents and testbench and simulation results) running on the three >> VHDL-AMS platforms avalaible (Ansoft, Mentor Graphic and Dolphin), >> and to give you 15 days to re-engineer this model back (having all >> initial value, variables names and comments provided back). > /I grant you your point. I don't want to invest energy trying to > "crack" any approach to convince myself of its strength. It would be > horrible if the EDA community had to analyze the theoretical strength > of various encryption algorithms. There is an accepted body of such > expertise in cryptography that has done that and we trust this is > effective. How would I reach such trust with your idea? > / Answer: It wouldn't be horrible at all if the EDA community had to analyze the strebngh or weakness of various IP protection scheme. The community should have enough smart guys which are ble to deal with such topics (I hope so). Else there is no reason to deal with that and use better a PGP (Pretty Good Privacy based tools) implementation to protect your Intellectual Property. Could you give me more information about an accepted body concerning cryptography on a worldwide basis. On top of it, having a good encryption algorithm doesn't prevent you from having backdoors in its implemntation. I think about a well known groupware software having encryption capabilities but we all know that the key root has been (for legal compliance issues) deposit to the relevant federal agency. It means that such encrypted databases can be decrypted by the appropriate body within minutes.There is no trust in this case. Looking on a worldwide basis this is just not acceptable, because a growing market like China or India will never agree. So we have to find a way which is acceptable by all countries. This is why an obfuscator is so powerfull, there is no way back, even if you have the obfuscation algorithm in you hand and it force everybody to treat the IP on the same level and to respect its counterpart. This is why I think that the community will show a strong interrest in such a way. > / > A few thoughts on that. First no one can get back information that is > truly missing, such as elided comments. It is trivial to strip > comments before encryption too (but arguably unnecessary). Regarding > names, it would not matter that I have the names correct, only > meaningful. I would not waste my time doing this task manually, but if > I was determined, I would build a tool to support me. You cannot hide > keywords, so alot of integrity of the HDL decl and statement structure > must remain, only obscured. I think the important theoretical point is > supported by examing what the obsfucating mechanism does and whether a > determined effort can mitigate what information was merely hidden. > But if the obsfucation algorithm is itself the only secret and since > only you know it, it seems pretty unverifiable whether it is strong > enough to resist code understanding tools. It therefore remains a > worthy task for you to obtain such trust from your potential > customers. There is nothing other vendors can do to build tools that > do the same thing without also being a proprietary and unique > solution and also facing the same task as you have with your tool. I > don't see something to standardize for all tool vendors to use here./ >> I do not want to go against the mailing list policy, this is why I >> aske here the moderator authorization to share an obfuscated model >> with everybody. >> >> Regards. >> >> Olivier Rolland >> >> Dr. Olivier Rolland >> Systems'ViP >> c/o SEMIA >> 4, rue Boussingault >> F-67000 Strasbourg >> >> Tel: +33 671 128 130 >> Email: olivier.rolland@systemsvip.com >> Web: http://www.systemsvip.com >> >> Systems'ViP: Your innovation capitalization partner >> >> This e-mail, including attachments, is intended for the person(s) or >> company named and may contain confidential and/or legally privileged >> information. Unauthorized disclosure, copying or use of this >> information may be unlawful and is prohibited. If you are not the >> intended recipient,please delete this message and notify the sender >> >> >> >> John Shields wrote: >>> Dr. Rolland, >>> >>> Thanks for your comments. The foundation for the standard is open >>> and published cryptographic algorithms and the flexibility of the >>> pragmas should make it possible to build tools that afford legal >>> compliance across countries. As always, the quality of tool >>> implementations matters even when standards apply. You make some >>> good points and the legal context is certainly one of them. As best >>> I understand it, it was well considered when crafting the standard >>> and it remains the domain of the tool developers and IP providers to >>> assure they are compliant with any rules. >>> >>> If I may, you have made a case for source code obfuscation and it >>> may prove to be effective protection for many applications. I do >>> not understand enough of the approach you have advocated. Without >>> the details and looking at a high level, I have some concerns. >>> Perhaps you can shed some light? >>> >>> First is that tools will not understand the intent to protect >>> information because it is not conveyed with source code >>> obfuscation. If there is information to be mined from obfuscated >>> source, the tools will allow it in an oblivious manner, correct? >>> Looking at the opposite problem, if there is information that the >>> tool should convey because the intent of the IP provider is to open >>> aspects (what is addressed by the viewport pragma in the VHDL IP >>> protection spec) to the user, would the obfuscated source get in the >>> way? Finally, I have no knowledge of your specific algorithms for >>> obsfucation and what a determined hacker with a sufficient spec for >>> what the IP is (in order to use it) might be able to do to reverse >>> engineer it. I presume you would assert that it is next to >>> impossible. I wonder whether that depends on the algorithms you use >>> remaining trade secret. If you had the algorithm would it help >>> unobsfucate the source? If not, would the availability of one >>> proprietrary tool using these algorithms be of concern? Would other >>> tools attempt obsfucation and inferior implementations lead to >>> compromise? >>> >>> My point is really to say that I do not understand enough of the >>> technical approach you have advocated and I am, of course, an >>> advocate for the current standard approach. Of course, it will have >>> to prove itself in the marketplace like anything else. >>> >>> Regards, John >>> >>> olivier.rolland@systemsvip.com wrote: >>>> John, >>>> >>>> I do now understand your somehow aggressive reaction, in march >>>> 2006, when I do have send some information to the working group >>>> over the fact that an obfuscation based solution exists vor the >>>> VHDL and VHDL-AMS languages and that it might be better than all >>>> other solutions. >>>> After reading the accelera information, it turns out, asd Arpad >>>> said, that we will have maybe a common mechanism for IP protection >>>> but based over propietary keys and proprietary implementation of >>>> the general mechanism. I hope that the community members will pay >>>> attention to the theoretical and practical consequences of going >>>> into potentially vendor dependant implementation of an IP >>>> protection mechanism and its inherent, country dependant, legal >>>> limitation related to the use of an encryption key based mechanism. >>>> Remember that the java language is so successfull because of its >>>> portability over many platforms and the IP protection solution used >>>> in this case is based over source code obfuscation tools. I do hope >>>> that theVHDL and VHDL-AMS community has got enough smart guys to be >>>> able to understand and treat the IP protection issue in a truly >>>> open, vendor independant and legally smart way. >>>> >>>> Regards. >>>> >>>> Olivier Rolland >>>> >>>> >>>> >>>> Dr. Olivier Rolland >>>> Systems'ViP >>>> c/o SEMIA >>>> 4, rue Boussingault >>>> F-67000 Strasbourg >>>> >>>> Tel: +33 671 128 130 >>>> Email: olivier.rolland@systemsvip.com >>>> Web: http://www.systemsvip.com >>>> >>>> Systems'ViP: Your innovation capitalization partner >>>> >>>> This e-mail, including attachments, is intended for the person(s) >>>> or company named and may contain confidential and/or legally >>>> privileged information. Unauthorized disclosure, copying or use of >>>> this information may be unlawful and is prohibited. If you are not >>>> the intended recipient,please delete this message and notify the >>>> sender >>>> >>>> >>>> >>>> John Shields wrote: >>>>> Alain, >>>>> >>>>> A bit of a clarification. IMHO, the more appropriate group to >>>>> engage in discussion is the Accellera VHDL TC. Visit >>>>> www.accellera.org to add yourself if your company is a member. >>>>> Lance Thompson, the chair, may know to what extent you might >>>>> participate even if you are not a member. The vhdl-200x group is >>>>> not active as their work has transitioned and broadened at the >>>>> Accellera VHDL TC. He is cc'ed on this email. It is true that >>>>> many of the same people are on both email reflectors and within >>>>> the boundaries of the IEEE, it is easy to subscribe/engage working >>>>> groups. Nevertheless, the work is taking place in Accellera. >>>>> Their results will move back systematically to the IEEE for review >>>>> and ballot preparation. >>>>> >>>>> A second item that may be of interest if you are attending DAC is >>>>> that I will be making a presentation on IP encryption at the IBIS >>>>> Summit meeting sometime on Tuesday morning. They are interested >>>>> specifically in VHDL-AMS IP, though the focus of the talk will be >>>>> to provide a general understanding of the mechanism and how it >>>>> works for any Verilog or VHDL-based HDL. I will at least motivate >>>>> where issues specific to a particular HDL would lie. >>>>> >>>>> Regards, >>>>> John Shields >>>>> >>>>> Alain Vachoux wrote: >>>>>> Dear 1076.1 Working Group member, >>>>>> >>>>>> A couple of months ago, there was some discussion about the >>>>>> support of encryption/decryption for VHDL-AMS models. Ernst >>>>>> Christen mentioned the ongoing effort in the VHDL-200X working >>>>>> group (http://www.eda-stds.org/vhdl-200x/). Since then, I >>>>>> discussed with Lance Thomson, Chair of the Accellera Technical >>>>>> Committee in charge of developing the new VHDL LRM to be >>>>>> submitted to IEEE for revision. We agreed to provide the 1076.1 >>>>>> WG members with documents for information and review. Three >>>>>> documents on IP protection may be then downloaded at the >>>>>> following URLs: >>>>>> >>>>>> http://www.accellera.org/apps/group_public/download.php/532/VHDL_IP_Proposal_V9.doc >>>>>> >>>>>> The original proposal put forward by the VHDL TC extensions >>>>>> committee. It is derived from a donation from Cadence which was >>>>>> derived from their donation to Verilog. >>>>>> >>>>>> http://www.accellera.org/apps/group_public/download.php/634/IP-requirements.pdf >>>>>> >>>>>> A reworked document fixing the low security level provided by >>>>>> some of the use models. This is the base for the new 1076-2006 LRM. >>>>>> >>>>>> http://www.accellera.org/apps/group_public/download.php/682/LCS-2006-140.pdf >>>>>> >>>>>> Actual LRM text that has been added to VHDL (P1076-2006-D2.11) >>>>>> which is currently under review. >>>>>> >>>>>> If you have questions or comments about the proposed IP support, >>>>>> I would suggest to carry the discussion to *both* the 1076.1 and >>>>>> the VHDL-200X mailing list (go to the VHDL-200X web site to >>>>>> subscribe). >>>>>> The IP protection proposal that is being developed is pretty >>>>>> general and should be applicable to 1076.1 models as well. A more >>>>>> detailed review might however reveal some issues specifically >>>>>> related to AMS models. But so far the ownership of the proposal >>>>>> belongs to the VHDL-200X Working Group. >>>>>> >>>>>> Best regards, >>>>>> Alain Vachoux >>>>>> >>>>>> >>>>> >>> >
This archive was generated by hypermail 2.1.8 : Fri Jun 23 2006 - 00:35:37 PDT