( ESNUG 328 Item 10 ) ---------------------------------------------- [9/9/99]
Subject: ( ESNUG 327 #8 ) How Secure PGP IP Encryption Technically 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: Matt Christiano <matt@globes.com>
John,
What Steven says is correct.
If the IP is only usable by the (vendor-specific) tool, then they could
license it's use with a FLEXlm feature, just as they license the use of the
tool generically.
On the other hand, if the IP is in some industry-standard format, such that
it's usable by tools from a number of vendors, then a standard encryption
package isn't of much use. Once you give someone the key, they can either
give the key to everyone, or they can give the non-encrypted version of the
IP to everyone.
Encryption packages operate on the priciple that *both* the sender and the
receiver of the encrypted data actually want to keep it secret. Otherwise,
you don't need the encryption in the first place.
We developed our FLEXcrypt product to solve a part of this problem, you can
give a different key to every customer, or even a machine-specific decryption
key. But even so, it doesn't solve the problem that any legitimate person
who has a decryption key could then redistribute the decrypted IP. To solve
that problem, you need some kind of watermarking technology. Of course,
watermarking only solves the "audit-trail" part of the problem, it doesn't
prevent others from gaining access to the IP. With watermarking, you are
depending on the fact that the legitimate user will not want an unlicensed
user to end up with a copy of the IP that is tracable back to them.
- Matt Christiano, CEO
GLOBEtrotter Software San Jose, CA
---- ---- ---- ---- ---- ---- ----
> 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.
>
> - David Black
> Qualis Design Austin, TX
From: Lee Bradshaw <lee@sectionIV.com>
Hi John,
Actually there is also a session key. The message is actually encrypted
with this session key using a fast private key algorithm. The slow
public key algorithm is only used to encrypt the session key. If
you're sending a message to several users, the session key will be
encrypted with each of their public keys. The recipeints use their
private key to decrypt the session key and then use that (and the much
faster algorithm) to decrypt the message. So the message size only
grows slightly with multiple recipients and the message itself is only
encrypted once.
For handing out IP, you would probably want to use different session
keys and encrypt the message once per customer as mentioned below. I'm
not convinced that any kind of encryption is reliable when you're using
networked computers. The algorithm may be fine, but there are many ways
to observe the password/passphrase used to unlock the secret key. (Do
your users control access to the display with xhost, MIT magic cookies,
xdm authorization, or kerberos? Are the more secure implementations bug
free?) Companies may want to make a reasonable effort and then admit
that they probably can't stop a determined thief (especially one with
physical access to a customer site.) I'm not saying the the encryption
algorithms have to be broken, but that giving an entire design team the
ability to use an encrypted file opens lots of holes for carelessness,
deception,...
- Lee Bradshaw
Alantro Communications
|
|
