Dr. Rolland,
John,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.
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?
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.
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?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: 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.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?
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 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 - 16:52:52 PDT