( ESNUG 319 Item 11 ) -------------------------------------------- [5/26/99]
Subject: ( ESNUG 318 #3 ) Reactions To "We Will Consider Using PGP"
> Regarding Mr. Brier's observations on encryption for IP -- his comments
> are interesting and worth investigation, but are, in fact, based on
> misinformation about our tools. To set the record straight, encryption of
> a coreKit and the files that coreConsultant produces (e.g., RTL) is
> **strictly optional**. It's done only if the **provider** of the core
> chooses this option when using coreBuilder to create the coreKit. We put
> this feature into the product based on consistent customer demand.
> Specifically, core designers want to preserve the black-box nature of the
> reusable core; hence, they want to keep core end-users from modifying the
> source. In addition, they asked for a level of *basic* (lightweight)
> protection of their RTL to "keep honest people honest," and to satisfy
> legal IP protection requirements. Synopsys core competency isn't
> encryption, so we welcome Mr. Brier's suggestions that we (and the EDA
> industry) consider PGP (or perhaps other industrial encryption like RSA).
>
> - [ John Chilton, VP/GM Design Reuse at Synopsys ]
From: "John Allen" <jallen@vhfcom.com>
John,
PGP is the most underused technology of the late 20th century. Very sad.
It deserves great success. Even Intel supports PGP, but most people are
clueless about it.
- John Allen
IronBridge Networks Lexington, MA
---- ---- ---- ---- ---- ---- ----
From: Dave Brier <dbrier@ti.com>
John:
Interesting remarks by Mr. Chilton, my impression from the original posting
was that encryption was a big part of the feature set of their coreBuilder
tool set. He also states that many of their customers have asked for some
sort of light encryption to be available to keep the honest honest. That's
nobel and I applaud their listening to their customers that way. The only
problem that I have with the way that they listen is that they (and not just
Synopsys, but the entire EDA industry) approach the problem in a self
centered manner.
The challenge as I see it is to deliver models in a uniform manner to
customers that use VSS, Modeltech, Verilog, VCS,... in one standard format.
I'm sure that Mr. Chiltons customers use other simulators and would really
appreciate some method to enable those technologies. I grow weary attempting
to remember all of the different formats, peculiarities, etc. that accompany
the various tools that are on the market at this time. We have so many
languages to know in order to get our designs done it would be nice for
once that the industry would gather in one room and cooperate on a uniform
solution to a problem. That is my dig on this situation, it's not a shot at
Synopsys per se, they are behaving in the manner that they must to survive
and grow. It would be nice if that growth could come in a manner in which
uniformity would prosper.
Once upon a time when VHDL was in it's infancy I had a conversation with a
number of companies, Synopsys, and Vantage (remember them?) were in that
crowd. My group (not at TI) stated that if VHDL were to prosper, then the
simulators would need to be more of a commodity item basically meaning that
the value added was in performance not coverage of the language or
"trueness" to the LRM. They all should produce the same simulation results
for the same input. If the EDA companies want to do something great for
the IP providers of the world, if they want to be smiled upon then they
could drive to uniformity of interface an interpretation of the commands and
languages that they use. I don't hesitate to say that many IP providers
spend a considerable amount of time and money in making their models correct
across multiple EDA platforms. It's sort of like the U.S. mixing all the
different power outlets and power formats that you find when you travel
overseas. Imagine what that would do to our economy.
- Dave Brier
Texas Instruments Dallas, TX
---- ---- ---- ---- ---- ---- ----
From: Steven Sharp <sharp@Cadence.COM>
John,
It doesn't matter what encryption algorithm is chosen, it doesn't solve
the problem. The problem is, who gets the key?
Every tool that accepts this encrypted code has to be able to decrypt it.
That requires the key. You can't put the key into some published standard,
because then anyone could decrypt and steal the code. IP vendors can't give
their key to their licensed users, because if the user could be trusted, the
encryption wouldn't have been needed. That means that the key has to be
embedded in the tools. Now the question becomes, which tool vendors do
we trust with this key? Since it is a standard, should we give it to any
vendor who wants it? What about a vendor whose product is a code decrypter
to let people steal IP, or is just a front for a company stealing IP? We
could restrict the key to some small set of "reputable" vendors. Then
any others will have to come up with their own non-standard encryption.
What we have now is just the extreme case of this where each vendor has
an encryption approach that they don't trust anyone else with. Given the
difficulty of proving who leaked a key, that is the only reasonable view
they can take.
One possible alternative would be for each IP vendor to use a different
key and provide it to those vendors they consider trustworthy. This would
complicate the entire process, and is still susceptible to leaks and the
resulting finger-pointing.
There are other weaknesses in using a standard encryption package. Since
every user has a decrypter built into their tools, they can try to reverse-
engineer it enough to extract a key or the decrypted model. The more that
is known about the algorithms and the code, the easier this is. If it is
some separate program with publically available source code, it is a trivial
matter of modifying it to print out the decrypted source that is being fed
back into the tool.
People who talk about standard code encryption don't understand the problem
that is being solved.
- Steve Sharp
Cadence
|
|
