[ibis-macro] Summary of email correspondence on encryption in *-AMS
- From: "Muranyi, Arpad" <arpad.muranyi@xxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 26 Apr 2006 09:36:53 -0700
Hello everyone,
This is a summary of the email correspondence I generated with
my question on encryption in the VHDL-AMS and Verilog-AMS
workgroups. I sent the same message to both workgroups
asking whether they have considered encryption for *-AMS
models. I will separate the responses in two groups, first
VHDL-AMS and second Verilog-AMS.
Enjoy reading them!
Arpad
===============================================================
VHDL-AMS:
=========
1) VHDL 1076 is being enhanced by Accellera this year. One the expected
enhancements is an encryption model for IP at the lexical level of
source code. My expectation is that this will serve this need quite
well. (There is a path to that becoming a part of IEEE 1076 and being
incorporated into products, of course.) It is architecturally quite
language neutral and serves equally well for Verilog and is part of the
latest 1364 standard already. 1076.1 should strongly consider it before
reinventing anything.
2) Encryption is a topic that comes up from time to time. The issue is not
specific to
VHDL-AMS, but affects also VHDL (IEEE Std 1076). A proposal has been submitted
to the VHDL
Analysis and Standardization Group (VASG) to support encryption in a VHDL text.
You can
find some information about the topic by following the VHDL-200x link under
P1076 at
eda.org. Go to Old VHDL-FT documents, near the bottom there are links to
relevant
documents. There is also a presentation at
http://www.accellera.org/apps/group_public/download.php/118/VHDL_IP_Encryption.ppt.
3) Thank you for your question, the topic you open is really important for
IP protection purpose and an answer is required to guarantee a
successful 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 nature of 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 interoperability.
We have developed, 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 being 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
formally equivalent to the original one (only the necessary information
for the compiler and related simulator and generated, all other
information like comments ore meaningful signal names are thrown away
in to preserve the Intellectual property).
Note that developing such a sophisticated obfuscator is as complex as
developing a compiler.
- Watermarking included into the generated code in order to guaranteed
the traceability of the delivered models and the enforcement of
contracted NDA and contracts between companies.
- EDA independent 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 independent 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. With 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
4) 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.
5) Some arguing over this point...
6) From a model delivery and IP protection standpoint, how is an encrypted
VHDL-AMS model different from (or better than) a compiled VHDL-AMS model?
Doesn't customer have to compile the encrypted model anyway?
7) Good suggestion, we have thought about this option
too. However, the binaries are not exchangeable
between tools, so they are still a tool specific
solution. The goal would be to have a tool
independent solution.
If we could have all tools use the same binary it
may be a solution, but my understanding is that
this can't be done due to compiler differences.
8) Please excuse a word of warning against encryption: According to my
experience, it serves not to protect your knowledge but your ignorance!
The limitations and shortcomings that any analogue model will always
have are thus not detected and improved by the user, but they will
continue to give inaccurate or even wrong results ...
We have already experienced that a tool vendor went out of business, and
we could not reuse the improvements to our own models ...
So when a semiconductor vendor does not want to show his models: Get a
better partner in time!
I suppose I cannot stop anybody encrypting a source file as whole. This
applies to any ASCII language. But this is not what it is about, for the
following reason: It has proven reliable and efficient to generate
documentation out of the model head itself and additional information
tagged in the code and in the comments. So the solution cannot be as
simple as encrypting files, but has to be something in line with the
Cadence slides. (Had VHDL-AMS provided a deeper hierarchy of model
inheritance than entity and architecture, it might have been possible to
let the user know the entity and the "coarse architecture" but not the
"fine architecture".)
I also fear that encryption is counter-productive for current attempts
to create a tool-independent open source "meta-language". But as long a
the models themselves are simulator-specific, why not allow individual
schemes?
9) If you believe your IP is valuable and that making it available as source
code compromises that value, you need a delivery mechanism that keeps the
source code from being inspected while allowing it to be used. A compiled
model does provide that protection or at least some of it. For every tool in a
user's production flow that has to work with that model you need to provide the
model compiled for that purpose (if that is possible). Not every tool will
have a persistent compiled representation suitable for delivery. If you do not
wish to dictate what tools a customer may use, you will have to delivery ( and
qualify/certify ) your model with all tools. That is expensive for the IP
provider; it can become a logistical nightmare, too. And, the protection may
be compromised at runtime by tool features, such as debugging and code
understanding mechanisms. After all, the tool is just working with a compiled
model; it does not know that there is any intent to protect it.
If I can speak about the IP protection model proposed for VHDL, it is applied
at the lexical level to HDL source code. The text is annotated to identify
what text is to be encrypted and what specific encryption mechanisms are chosen
to be used. An encryption tool (likely a VHDL compiler but it could be a
standalone utility) processes the text and produces a text file in which that
region of text is replaced by an encrypted, encoded block and the remainder of
the HDL is clear text. This can be delivered to any user appropriate to your
business purpose. The user may use this IP in any tools that are capable of
decrypting that IP. Without going into details about the various mechanisms of
secret or public key encryption choices available, there is a great deal of
control the IP provider has in enabling only a selected set of tools or users
to use his/her IP.
A further aspect of this mechanism is that the tool is obligated to protect the
information model of the IP and not reveal any information that could
compromise the IP while providing its intended purpose. The IP is opaque to
debuggers, browsers, etc., except as required to use the model with the tool.
There is a mechanism for the IP provider to define a viewport to makes certain
aspects of the model visible to the user. For digital VHDL models, the
semantics of what aspects of the model are protected have a foundation. For
AMS models, this would be an area for semantic definition.
The IP protection mechanism is expected to become part of the VHDL standard and
conforming tools will have a solid basis for IP providers to deliver portable
models that will be protected. It is expected to part of both Verilog and VHDL
standards and should be highly leveragable technology for tool providers. The
document that Ernst refers to is a overview PowerPoint presentation. I don't
know if the draft specs from Accellera can be made available to this group, but
I can explore it if there is interest.
It might be a bit premature until this group is ready to propose and work on
new 1076.1 features. The Verilog spec is in the latest 1364, annex H. The VHDL
specs are much more comprehensive in terms of details and use cases. You may
expect to see it in an Accellera version of 1076 later this Fall.
Verilog-AMS:
============
1) There was some work started in 1364 Verilog and/or SystemVerilog
on encryption. We have not looked into it in V-AMS.
2) would that be encryption for the transmission to the
end user, or would you require the tool to parse the
encrypted data, without giving inspection access to
the user?
and if we publish an open encryption standard. so all
tools understand the same encryption and password,
what keep the end user from writing his own tool?, and
using that to dump out the data? sure it would be a
bit of work.. but if the value of the IP was high, I
would expect the attempt to be made.
3) Encryption was added to the 1364-2005 standard so I
assume we can pick that up when Verilog-AMS syncs with
1364-2005 in LRM2.3
4) Verilog added IP protection in the latest version.
Verilog-AMS should adopt this instead of creating its own.
===============================================================
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
- » [ibis-macro] Summary of email correspondence on encryption in *-AMS
