Re: Question on encryption

From: John Shields <John_Shields_at_.....>
Date: Mon Apr 24 2006 - 15:18:36 PDT

Dr. Rolland,

First of all, you should be aware of the rules for advertising products here.  You participated in the recent discussion with Amr Turk in which this issue was explained.  Since it is not new to you, I am concerned that you are not taking it seriously.  It would not be hard to talk about the problem without mentioning your product.  You made no attempt to do so. You do realize the consequences are being removed from the privilege of posting to this group?

Regarding your opinion about encryption, I think you should look at the solution that is being standardized.  Those problems you mention have been considered and well addressed. Every single one you mentioned.  I might cast some doubt on your solution as truly having the attributes you claim, but there is no reason to discuss it in the context of this standards group.  Please, refrain from this kind of email.

Regards, John Shields


olivier.rolland@systemsvip.com wrote:

Hi everybody,

Thank you for your question, the topic you open is really important for IP protection purpose and an answer is required to guarantee a successfull spread of the VHDL-AMS.
1) It is not , in our view, something which is relevant to the language itself, since the source code protection has nothing to do with the semantic or grammatical rules.
2) Encryption tool which depends to an EDA vendor is useless because of its proprietary nature which is in contradiction to the IEEE open standard natureof the language itself.
3) Using a common encryption scheme to protect the source code presents several issues:
- the first one is  related to different national laws dealing with encryption tools and encryption keys management, which might drive to major security holes or impossibility to implement a suitable common set of tools and keys
- the second one is related to the logistic nightmare users might face when dealing with keys management coming for complex design using encrypted models from different providers (see the today Digital Right Management issue we do have with the music industry)
- the third one is related to the limited value of a secret (encryption scheme) shared by an open community to be able to implement it. Knowing the encryption algorithm used is of great help for a hacker to find out the encryption key and implement the appropriate reverse engineering.
- the fourth one is related to the EDA vendors who have a strong interest to limit, for obvious reasons, simulation and development platforms interroperability.

We have developped, for all this reasons an obfuscation tool which is available in form of an ASP through an encrypted internet web site.
What does it mean?
An VHDL-AMS obfuscator convert a source code model into an other formally equivalent source model unreadable by a human beeing but treated like a standard source code model by a vhdl-AMS compilers and simulators.
This shows many advantages:
- No encryption tools and keys (no legal limitation and no encryption key management nightmare)
- No reverse engineering possible since the generated model is a new one formaly equivalent to the original one (only the necessary  information for the compiler and related simulator and generated, all other informations like comments ore meaningfull sgnal names are thrown away in to preserve the Intellectual property).
Note that developping such a sophisticated obfuscator  is as complex as developping a compiler.
- Watermarking included into the generated code in order to guaranted the traceability of the delivered models and the enforcement of contrated NDA and contracts between companies.
- EDA independant generated scrambled code (as long as the original source works on all target platforms), there  is no  compilers and simulators  platform changes  required at all.
- EDA software platform version independant scrambled model since it can be compiled when required.
- Since the scrambler deals with the VHDL-AMS language, the pure digital world (namely VHDL) is covered as well by the solution.

In order to give you a first taste of this software capabilities which is the result of more than two years of intensive research and development work,  you can have a look on our web site: www.systemvip.com
and register yourself on following link: http://www.systemsvip.com/request_access.html to get within 48 hours your personal login and password to have access on our limited demo version of the software.

I apologize in advance for this partially advert oriented email, but we think that providing such breakthrough capabilities in term of IP protection to the VHDL-AMS community is crucial for its long term success and therefore all community members should have a chance to get this information. Whith such tools the era of intensive information sharing among companies can start putting the VHDL-AMS as the natural choice for moving from physical prototypes based R&D to a more virtual prototypes de-materialized based R&D.

Your feedback will be appreciated

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



Muranyi, Arpad wrote:

Hello everyone,

Sorry for bringing up such off topic questions all the time,
but I would like to find out whether encryption has been
considered by the workgroup for VHDL-AMS models.

The reason I am asking is because this has been brought up
in the recent IBIS Open Forum discussions in connection
with modeling bleeding edge high speed buffers behaviorally.
Semiconductor vendors feel increasingly uneasy about
releasing even behavioral models for such buffers without
encryption.  In addition we do not like the idea of using
the individual and proprietary encryption schemes of EDA
vendors, because that would require the model makers to
encrypt the same model multiple times for each tool.  It
seems that there is a strong need for some sort of a tool
independent encryption scheme.

We thought we should look around what has been done, if
anything, before we reinventing the wheel.

Thanks,

Arpad
=============================================================

 

Received on Mon Apr 24 15:18:42 2006