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? 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. 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. 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 evrybody, 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 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 : Thu Jun 22 2006 - 12:52:44 PDT