( ESNUG 327 Item 8 ) ----------------------------------------------- [9/2/99]
Subject: Four Users Explain Technically How Secure PGP IP Encryption Works
> "It doesn't matter what encryption algorithm is chosen, it doesn't solve
> the problem," wrote Steven Sharp of Cadence. "The problem is, who gets
> 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?"
> continues Steven. "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?"
>
> "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."
>
> - Steven Sharp of Cadence (from "Why PGP IP Doesn't Work")
From: "David G. Koontz" <koontz@ariolimax.com>
Hi, John,
How about throwing the key down a well so no one can unlock it. If
you can't protect your IP by contractual obligation, and you are
so afraid of someone stealing it, don't distribute it. The half life
of IP is probably less than 3 years. Its a self correcting problem.
It is possible to steal tools today, yet companies are not going out
of business because of forged licenses. The amount of work is roughly
on par with recovering a key from a tool for encrypted IP. The good
news is that there are probably around 250 people world wide with the
skill and knowledge base to steal licenses or encrypted IP. Amazing
that you don't hear any hints of success stories other than from
the former Soviet Union. You can always limit theft by attacking
re-distribution channels. I remember one Moscovite telling me you
could buy all of MicroSoft's SW on a CDROM for a few dollars. Yesterday
in the newspaper there was an item describing a mountain of CDROMs
containing stolen intellectual property having been destroyed in the
former Soviet Union.
Heck, a network in a simulator is essentially a database. Someone
could write a tool to traverse IP loaded in a simulator. You ever
notice how many vendors limit the distribution of encrypted Software,
IP and intellectual property? Locks keep honest people honest.
Access denial keeps others from stealing.
- David G. Koontz
ArioliMax
---- ---- ---- ---- ---- ---- ----
From: "Dan Oelke" <Dan@oelke.com>
Dear John,
After reading your recent column on Why PGP IP doesn't work, I felt I had to
reply to correct some incorrect statements.
Towards the end, a quote from Steven Sharp states that if the encryption is
built into tools, then people will reverse-engineer it and be able to break
the encryption. This is simply false. The beauty of really good encryption
schemes is that people can know decryption scheme, but if they don't have
the key they can't decrypt the data. The more that is known about the
algorithms, the more trust you can put in them.
Now, even with correcting Steven's one misperception, I must concede that at
some point somebody must be able to decrypt the IP to use it, and that person
might not be trustworthy, resulting in a possible loss of IP.
Then again, since Steven doesn't have a basic understanding of what you need
to trust your encryption, I would like to see details of Dave Brier's scheme,
because it might address this problem as well.
- Dan Oelke
---- ---- ---- ---- ---- ---- ----
From: Howard Landman <HowardL@SiTera.com>
Hi, John,
There's a reasonable solution to this using separate keys for the customer
and IP vendor. Tool vendors get treated like customers in this model.
The IP vendor has an encryption key (call it IPEK) and a decryption key
(IPDK); each customer creates their own encryption key (CuEK) and decryption
key (CuDK).
The IP vendor gives the IPDK to the tool vendors, who incorporate it into
their products. Each tool vendor also makes their own set of "customer"
keys so they can pretend to be a customer. Each customer (and tool vendor)
gives the IP vendor their CuEK.
NOW: The IP Vendor has to encrypt their IP differently for each customer.
They do this in the order IP -> CuEK -> IPEK -> file. Then they give the
encrypted file to the customer.
The customer feeds their CuDK into the tool, which already contains the
IPDK. The tool then decrypts in the order file -> IPDK -> CuDK -> IP.
The IP vendor can use IP test cases with tool vendors which are not the real
IP that they sell. This is adequate to test the encryption/decryption. So,
the tool vendors never have to see any "real" IP unless the IP vendor wants
them to. Because the tool vendor's CuDK is different from any other CuDK,
even if they get ahold of some other customer's encrypted IP file, they'll
only be able to decrypt it halfway, because they don't have that customer's
CuDK.
In order to break this, a tool vendor needs to get both a customer's
encrypted file and also the matching CuDK. Similarly, one customer would
not be able to use another customer's file. Of course, this is still
subject to "social engineering" attacks (e.g. mercenary customer employee
sells key to unethical tool vendor), but what isn't?
- Howard A. Landman
SiTera, Inc. Longmont, CO
---- ---- ---- ---- ---- ---- ----
From: David C Black <dcblack@qualis.com>
Hi, John,
Boy did Steve Sharp from Cadence put his foot in your mouth. Please take
the time to carefully read and understand the following. There are
three sections:
1. PGP EXPLANATION
2. WHERE IT FAILS
3. ADDITIONAL SAFETY MEASURES
4. ABOUT ENCRYPTION SAFETY
5. CONCLUSION.
PGP EXPLANATION
~~~~~~~~~~~~~~~~
PGP uses something called "Public Key Encryption" rather than the traditional
"Private Key" mechanism. Rather than having a single key for the document,
the PGP uses two keys: 1 public and 1 secret. Data may be encrypted with
either key, and decryption requires the opposite key.
Each party in a typical transaction owns a key pair. Thus there are four
(4) keys involved.
Allow me to give a clear example of how this works:
1. EDA customer requests a license from an IP vendor and supplies
his (customer's) public key to the vendor.
2. Vendor processes request (license agreement and money), and
then send's the customer a copy of the IP encrypted with with
the CUSTOMER's own public key and SIGNED with the vendor's secret key.
3. EDA customer verifies the signature using the vendor's public key
and proceeds to use the IP using the customer's secret key.
Thus, nobody except those with access to the customer's secret key can
access the IP (not even the vendor unless they added their own public key
during encryption!). If multiple customer's are involved, the vendor would
have to encrypt multiple times. If the customer gave out their secret key
and the IP, it would be fairly easy to prove who did it.
WHERE IT FAILS
~~~~~~~~~~~~~~~
Now some notes on where this falls down:
A. If customer decides to copy or illegally use the IP (e.g. sell the
decrypted copy to somebody else), the only recourse of the vendor is
legal. If the vendor can establish that it has taken appropriate
measures to secure its IP, they will hopefully win in a court of law.
B. If the customer doesn't take measures to protect the vendor's IP,
it could be stolen from the customer.
Neither of the above is particularly different from traditional issues. The
only thing new is that the IP was transmitted electronically.
ADDITIONAL SAFETY MEASURES
~~~~~~~~~~~~~~~~~~~~~~~~~~~
A sly vendor would take one additional step (which does entail some
additional cost and effort). Prior to encryption, they would perform a
simple transformation on some of the IP that would preserve the function,
but change the order or naming of some components of the IP for a particular
customer such that the IP would be very likely to be identifiable even in
the event of modifications. For example, consider the simple register
implementation:
always @(posedge clock) begin :X_REG
if (reset) begin :RESET_X_REG
x_ff <= 0;
end
else begin :CAPTURE_X_REG
x_ff <= data_in;
end
end
By changing the block labels (not really needed), adding or removing the
begin/end's, grouping some registers in common blocks and rearranging the
ordering of parallel blocks (always & initial), renaming sub-blocks, etc.
one can obtain many "signatures" in the IP itself. This can be automated
relatively easily. Think of this as similar to watermarks on digital art.
Mind you, this last step is only necessary to establish where the code came
from. It doesn't prevent fraud.
ABOUT ENCRYPTION SAFETY
~~~~~~~~~~~~~~~~~~~~~~~~
Your article also complained about the safety of encryption itself. It is
true that over time, various algorithms are subject to breakage. The safety
of a technique comes from a variety of factors including: the algorithm, key
selection, key security (how you protect the keys themselves), and key
validation/exchange (how do you know who's key you have). There are many
good books on this subject. An advantage of PGP is that it's algorthms are
exposed for public inspection and many people are looking for holes. It's
weaknesses are known, but manageable (see the books for this).
Suffice it to say that every technique has a projected "safety". PGP using
keys of 2048 bits has a projected safety of at least five (5) years I
believe. Given the pace of technology, I suggest this is not too bad. As
computer processing power improves, you can always increase the length of
the keys or move to newer algorithms for newer IP. The idea is not to
prevent fraud, but rather to make it improbable and difficult. Criminals
are eventually caught.
- David Black
Qualis Design Austin, TX
|
|
