Slashdot Mirror
PGP Vulnerability Discovered
From Bruce:
PGP Vulnerability
A very serious PGP vulnerability was just discovered. Using this vulnerability, an attacker can create a modified version of someone's public key that will force a sender to encrypt messages to that person AND to the attacker.
Let me explain.
When Network Associates joined the Key Recovery Alliance, they modified PGP to allow for third-party key recovery. They did this by supporting something called an Additional Decryption Key (ADK). Normally, when a PGP user creates a PGP certificate, it contains a single public key (as well as identifying information as to who the key belongs to). PGP version 5 and 6 allow the user to add additional ADKs to the certificate. When a sender encrypts a message to that user, PGP will automatically encrypt the message in both the user's public key and the ADK. The idea is that the ADK belongs to the secret police, or the user's employer, or some organization, and that organization can intercept the encrypted message and read it.
A stupid idea, but that's the sort of thing that Key Escrow demands.
The flaw is that some version of PGP don't require the ADKs to be in the signed portion of the PGP certificate. What this means is that an organization can take a PGP certificate, append his ADK, and spread it out to the world. This tampered version of the certificate will remain unnoticed by anyone who doesn't manually examine the bytes, and anyone using that tampered version will automatically and invisibly encrypt all messages to the organization as well as the certificate owner.
Unfortunately, the problem won't go away until all vulnerable versions of PGP are eradicated: the sender who is responsible for encrypting to the ADKs, not the recipient.
Way back in 1998 a bunch of us cryptographers predicted that adding Key Escrow would make system design harder, and would result in even more security problems. This is an example of that prediction coming true.
Only if somebody gets ahold of your public key while you're not looking and modifies it to include the additional decryption key.
Extending the situation, does this problem have any effect if keys are exchanged via some secure channel, where no potentially untrusted third party has access to the keys (and the chance to add an ADK to them)? So, don't trust the keyservers (which I never use) and you'll pretty much be OK as long as you get the public key directly from the person it belongs to?
Sure, so long as that person keeps perfect control of the key. However, if he goes away for the weekend and a spook enters his house and modifies your public key on his machine, you're hosed.
...phil
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
This is an awful bug, to be sure, but it's not invisible to the recipient. This is not a full fledged kleptographic attack, i.e. one where the added key material is invisible to anyone but the attacker.
ADKs *have* to leave additional encrypted content within the final package--somewhere, they've got to leave the decryption key in a detectable form for an attacker to come in and use to decrypt the one-time 3DES/Twofish/Other Symmetric Cipher Key. Now, it's possible that this internal key material could be stripped from the entire message and a valid hash reconstructed, much as the ADK can be added to a key without changing the overall key hash. But this would surprise and disappoint me--at that point, intent becomes a real question.
I have not intensively analyzed the PGP block format--I've been too busy working on SSH as of late--but it's necessary that *something* new is going to be added to the overall package, and that it's is going to be detectable, possibly without decryption, possibly without even the original public key. Whether it's strippable or not is a question mark, but people shouldn't be saying this is an invisible attack. It can't be.
Brutal, yes. Invisible, no.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
From what I can make of the section regarding GnuPG, it doesn't warn about the presence of the ADK. However, it places but one session key in the cryptogram, a key only recoverable using the user's private key.
But if you get a contaminated version-4 public key, GnuPG will not warn you about it. You should check any and all public keys that you use as decribed in the article. I'm sure the GnuPG team will not be long in adding functionality to do this automatically.
--
"Where, where is the town? Now, it's nothing but flowers!"
If you're referring to the fact that the vulnerable versions of PGP were tested running on Windows, you're not seeing a pattern. PGP-5.5.3i and PGP-6.5.1i running on Unix are just as vulnerable.
"the sender who is responsible for encrypting to the ADKs, not the recipient."
Thus, if someone with a broken version of PGP sends me encrypted email, they might also encrypt to an adversary. Am I missing something?
Never meant half of the things I said to you. So you know, there's a half that might be true - G. Phillips
I am an employee of Network Associates and a programmer working on PGP.
We're looking into it. I can't say much more than that at this point. As soon as more information is known, I will post it as a reply to this thread. Hopefully, you'll see some official word on it here soon.
-- Rob
PGP is not open source.
GPG, the GNU equivalent of PGP _is_ open source, and does not have this vunerability.
As for the police here in the UK, thats a whole other story, and if you ask me Mr Straw has no idea what problems he is creating for the police in the long term with his RIP bill either... but that's another story for another day.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
In your opinion what is a good possible solution for this? Is NAI likely to release a patch? What about a new version which does not include the ADK feature? I can also see how this might be a desired feature for corporations who want to use the ADK's for thier intended use. Is it likely NAI would release a kludge in a vain attempt to keep this feature in the code? What is your opinion of NAI and do you think they'll do the "right" thing?
Obviously with the growing popularity or PKI this can be seen as a good thing or a bad thing. Good in the fact that it exposes an inherent flaw in public key cryptography and might make some people seriously think about the implications of a public key infrastructure. Bad in the fact that a widely used version of PGP has a potentialy serious hole in it. I wonder how long the NSA has known about this one.
How appropriate this quote of yours seems.
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."
-- Sam Simpson, July 9, 1998
LiNT
The problem extends to GPG, which also uses DH keys. It doesn't automatically generate them, but like the newer versions of PGP, it fails to detect when ADKs have been appended. So in this case, the newest Free OSS is also vulnerable.
I just looked in PGP Help. Here's what the item on 'additional decryption keys' says:
Music washes away from the soul the dust of everyday life. -- Berthold Auerbach
ARRGH! Wrong!
This is a hole, a bug, a failiure. It's easily countered by including ADK information in the hashed/signed portion of the key.
This discovery means that EVERY key on public key servers is potentially broken. Hell, any naive users key could have this ADK packet and not even be aware! Using "authorised" keys, whatever that means, isn't a solution.
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."
Scan for unsigned ADKs and report them back to the (supposed-to-be) owner, as well as the current holder. For that matter, scan for signed ADKs, as well, and report them, too.
It can't really be a virus or IRC bot, but why not a snipped of open source code. Get it out, and everyone scan every key they hold. Scan every key that you know you've put somewhere. Scan every key you use to send. Scan every key you touch.
For that matter, wrap it in with GPG.
While we're at it, send upgrade notices back to anyone who uses the wrong version of PGP to send us mail. Stomp it from the face of the Earth.
The living have better things to do than to continue hating the dead.
I agree this is a problem, but it doesn't render PGP useless.
Just make sure, when you get someone's public key, that it comes from an "authentic" source.
He has illegally circumvented a carefully designed protection mechanism ! His discovery will cause bazillions of dollars to be lost to crime and piracy.
Worse even, sites such as Slashdot freely link to this information, destroying a successful business model (namely e-commerce) !
Don't let him get away with it, protect our right to profit !
And while you are at it, imprison all mathematicians who might find ways to break our precious cipher systems by finding a way to factor large numbers
(Sounds stupid, but wouldn't there be legal action in such a case ?
There's probably more truth to that than you might suspect. Encryption using PGP is inherently more complex. Since it requires two keys, as opposed to one key in traditional crypto, the math gets a lot more complicated. You can't just use a reversible function.
While there haven't been any real structural attacks to PGP, up until this, it is theoretically more likely that structural attacks will work against PGP than standard crypto. Perhaps the NSA has already found a way? Also, traditional PGP uses the RSA encryption algorithm, which, if you follow Distributed.net, gets brute-forced regularly. If you really are scared of the government reading your email, then I doubt PGP will put your fears to rest.
The problem is that anyone can add an ADK to a public key without affecting the key's fingerprint. In other words, it is perfectly possible for someone to set up a keyserver that adds an ADK for themselves to each key uploaded, and no-one will by any the wiser, unless they examine the key closely.
How they get their hands on the mail encrypted using those keys is of course outside the scope of this post.
Idea: A company could set up an internal auto-ADK-adding keyserver for its employees to use, and of course they have access to the outgoing mail spool.
--
"Where, where is the town? Now, it's nothing but flowers!"
It shouldn't, at all.
:)
GPG is based on the OpenPGP standard ( RFC 2440 ) which doesn't, AFAIK, include "Key Escrow" or "ADK". PGP seemes to have "added" this feature, perhaps this is what the mean by "multiple recipents" in the E-business product.
Of course I could be wrong, but that's the way it looks to me
there are lot's of fraudulent and dead keys in there and they are signed by someone who was trusted enough to sign the kernel key
This sentence is meaningless. Trust goes only one way. It doesn't mean anything if someone you don't know has signed a key.
I only added signers of keys to until the database was 4000 keys or so.
You're going the wrong way. You should trace the web of trust by looking for keys that are SIGNED BY that key, not keys that SIGN IT. Yes, I know, it's a little more difficult to find all the keys signed by a particular key. You need to download the entire database for that.
The only solution to this is a certified key authority.
According to your logic I could discredit the certificate authority by creating a bogus key and signing the CA's key with it...
----
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
There was a great deal of arguing and discussion in cryptographic circles when this came out. The gist of it is that when you email something from work, you're employer can get sued for it, so employers want the capability to read that email, they are legally entitled to in the US. So they added "enterprise" or "corporate" support to PGP. In the business world it makes more sense then you think, they can also recover messages if you're harddrive crashes and takes your secret key away. If PGP is to ever take hold in that market, and PGP is about making money anymore, then it needs this so called ADK feature.
DO NOT FEAR. KEEP USING PGP and GPG if you're one of the 2% who do! If they include the ADK within the key signature then the problem goes away and it works as designed. ADK is a good thing because it makes the product usable in markets it would otherwise never make it. My fear is that this will be treated like Clipper was, and for some reason people get paranoid about having encryption where an authoirzed third party can decrypt your transimition so the proper thing to do is keep using no encryption because that is some how better.
As a former one of the original cipherpunks and a crypto freak I'm also beginning to come around on escrow and key certifcation services. I've built a key database starting with my keys and the linux kernel key. I only added signers of keys to until the database was 4000 keys or so. "The web of trust" doesn't work, there are lot's of fraudulent and dead keys in there and they are signed by someone who was trusted enough to sign the kernel key, or someone who was trusted enough to sign the key of one of the signers of the kernel key. I only went out 3 hops from the kernel key when I was making the database. If you play 6 degrees of Kevin Bacon with PGP keys and start with Linus and the kernel key you get to a bunch of trash really quickly. (this was all done with keyserver.net) Example: Gandhi (yes, at nonviolent.org) has signed Dave Del Torto's key who has signed Theo Ts'o's key who is a kernel hacker and has signed the Kernel key. There is nothing that prohibits anyone from signing another key, so essentially you can't trust a key simply because it was signed by somebody. The web is a direct graph and the arrows point the wrong way, you can only trust keys you trust enough to sign and you can't draw any conclusion from someone else's signature being on a key. There is also a tremendous amount of garbage in the web of trust.
The only solution to this is a certified key authority. The problem with that is they are a business (better than a governement agency) and they will want to use ADK to cover their ass. I think the risk can be managed to a reasonable point by having multiple companies with checks and balances. I would use a key authority if, a) it was seemless and all my email was encrypted with said key and b) key authority couldn't decrypt my key but a 3 party might be able to with a court order. I still wouldn't use it for encrypting my confessions of sexual peccadillos or my plans to over throw the government but it would be more than acceptable for email which is largely unencrypted now. (So not just can the govenrnment read it but your neighbors, your employer and foreign governments can all read it too.) As it stands, if I was told by a court to decrypt my email and there wasn't an ADK capability, I would go to jail for contempt until I did, so when it comes down to it, if some one wants to forcably read your email and a court agrees you're going to lose that battle either by decrypting it or by going to jail and testing your will.
This is my signature. There are many signatures like it but this one is mine..
It's only keyservers that this could occur on. Personally I keep mine on my web pages, anyone who wants to mail me securely uses that, or the one I mail them...
Rule: Only use keyserver keys for verification of an unknown source, and even then, if it's important don't trust it...
EG I get the CERT key from their web site
It's your security people, don't give it to someone else...
Gav
"There's no such thing as data that can't be manipulated"
It looks like GPG can also be used to check a message to see if it's been encrypted to additional keys, although the method to do so is fairly complex. Perhaps the GPG guys should move this functionality up a bit and print a warning if you're decrypting a message that was encrypted to additional keys.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Does anybody have a good contact within PGP (pref. close to Phil Zimmerman) and get them to comment on this? (Like how can this be detected, other ways to safe guard against this.... etc.).
Hans Voss
---
Hans Voss
---
"I have no special talents, I am just passionately curious" -- Albert Einstein
The answer seems to be this: If you use GPG for *encryption*, then it's not vulnerable. But if you use if for *decryption*, then it is, since the person who encrypted the mail could have used normal PGP with the vulnerability.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
Maybe I completely missed the blaring announcements, but why is it that this is the first time that I'm hearing about this ADK 'feature?' If my version of PGP is automatically including an extra key along with my own, so that the government can snoop on my encrypted mail, it should be made blatantly clear, every time I generate a key. Or maybe I'm missing something obvious?
--- Remove all references to mud-dwelling quadrupeds to email me.
PGP 5.x was, is, and will continue to be a screwup.
They deliberately changed the command line interface to break every PGP-interoperable tool out there.
They released the Windows version months before the UNIX version.
When they finally were releasing the UNIX versions, they were binary-only.
Eventually, they got around to releasing the source code to the world. This was supposedly because of legal concerns, but that explanation doesn't really hold water. The binaries were released and restricted to the U.S. The source code was written in book form and exported, then to be scanned in, which was legal. Of course, the binaries made it out of the U.S. in about 45 minutes. The source code could have easily been released and restricted to the U.S., but wasn't. This didn't sound right at the time either.
They deliberately broke interoperability with older versions of PGP, which in effect forced people to upgrade. Because they didn't release source code, people were upgrading with binary-only versions.
Anybody searching the Cypherpunks archives from around the time PGP 5.0 was released can find several large threads on these topics.
So, again, it doesn't come as a surprise that PGP Incorporated is a government shill organization, particularly after they joined the KRAp.
Screw them. They and the government can go fuck themselves.
This doesn't apply at all to GnuPG - it doesn't recognise the ADK packet (and it shouldn't - RFC2440 specifies that this packet is simply "placeholder for backward compatibility".
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."
GNUPG isn't affected - so those of us who like a software free-as-in-speech don't have an problem.
It can only affect you if you get a key from an untrusted source. For most /.ers this won't be an issue.
So basically, don't panic just yet. Of course, this will no doubt start a number of 'many eyes of open-source' arguments.
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
Wouldn't the impact of this vunerability be reduced significantly if the various public keyservers were reconfigured to reject keys uploaded with unsigned ADK's?
The reason that this vulnerability in PGP is serious is that you can't fix it by updating your copy: you have to ensure that everybody who might send you encrypted messages has a copy of PGP without the ADK bug. This is difficult, especially when you don't know who your correspondants are going to be ahead of time.
Here is a summary of Ralf's paper that I wrote while reading it yesterday:
More followup: I've found the bug in the PGP-6.5.1i-beta2 source code. I'm fairly sure it will be identical in all the other vulnerable versions.
In file libs/pgpcdk/priv/keys/keys/pgpRngPub.c, I see two functions: one called ringKeyFindSubpacket(), which finds a subpacket from a self-signature packet, and ringKeyAdditionalRecipientRequestKey(), which uses ringKeyFindSubpacket() to search for ADK subpackets.
ringKeyFindSubpacket() is declared as follows:
PGPByte const * ringKeyFindSubpacket (RingObject *obj, RingSet const *set, int subpacktype, unsigned nth, PGPSize *plen, int *pcritical, int *phashed, PGPUInt32 *pcreation, unsigned *pmatches, PGPError *error);
In particular, the "phashed" parameter is used to return whether the subpacket was in the hashed region. Now, looking at the call in ringKeyAdditionalRecipientRequestKey() I see this:
krpdata = ringKeyFindSubpacket (obj, set, SIGSUB_KEY_ADDITIONAL_RECIPIENT_REQUEST, nth, &krdatalen, &critical, NULL, NULL, &matches, error);
...the "phashed" value isn't checked (or even asked for)!
Ok - it's an obvious implementation bug, and the bug itself should be easy to fix. I won't comment on the wisdom of designing in ADKs in the first place; the problem now is, how do we get everyone to replace their vulnerable copies of PGP? And, since that won't ever happen completely, how do we minimise the remaining problem?
It should be easy to spot keys that have been tampered with: use gpg --list-packets and look for ADKs in the unhashed section of the self-signature. You can also check to see whether you are receiving messages that have been encrypted to more than one recipient: look for multiple session key packets.
Finally, I recommend that regular sweeps are made of the public key servers for keys that have been tampered with.
Read the #98 post a little farther down for a better (read: more detailed) summary. It DOES matter what version of PGP you create the key with, and thus your details of the exploit are a little off...
In short, the exploit sequence is as follows:
Alice creates a PGP certificate. This is composed of her public key plus a bunch of other "packets" containing info like UserID, etc. One of these packets is essentially a checksum, containing a signature of the previous packets. In NAI PGP version 5, the ADK packet is included OUTSIDE of the checksum (so you can attach an ADK packet without affecting the checksum (and thus without generating an error message that the key has been tampered with). Alice then uploads her PGP public certificate to the pgp root server.
Carol wants to read any messages to Alice, so she goes out, pulls down Alice's certificate, and adds an ADK packet featuring her own public key. Then Carol uploads the new copy of Alice's key. Because the ADK packet is not included in (not checked by) the signed hash packet, this addition is not noticed as making the certificate invalid.
Now Bob decides he wants to send an encrypted message to Alice, so he pulls her public key from the pgp root server. He gets the latest copy, which is the version with Carol's ADK packet. So when Bob encrypts a message to Alice, it's just like he selected to encrypt the message to Alice and to Carol. So Carol can then intercept the email and decrypt it using her own private key.
---------
---------
There is no try at jedinite.com
I have copyrighted works under protected with PGP. I did not concent to the TPM I use being circumvented. Bruce's description of this vulnerability is clearly a circumvention technology that will be used to pirate my work and is thereby illegal under the DMCA.
I'm going to file a lawsuit against Bruce and Slashdot and anyone who links to Slashdot and anyone who reads the article and anyone who points at or otherwise refers to a person who reads the article. In fact, Bruce himself is circumvention technology, so I'm suing his parents, too, along with the major airlines, both of which have distributed Bruce.
We have already read all of your Emails. Thank you for your cooperation. Please stay in your seat, someone will soon arrive to collect you for processing. Yours,
MIB
Syllable : It's an Operating System
If I read this correctly, only some versions of PGP have this problem with the ADKs. So does anyone know which ones have this problem? Or (better) which ones don't have this problem.
From the authors original message:
PGP-2.6.3ia UNIX (not vulnerable - doesn't support V4 signatures)
PGP-5.0i UNIX (not vulnerable)
PGP-5.5.3i WINDOWS (VULNERABLE)
PGP-6.5.1i WINDOWS (VULNERABLE)
GnuPG-1.0.1 UNIX (not vulnerable)
And am I correct in my assumption that PGP remains OK as long as you don't create an ADK? Or am I misreading the message?
NO! The problem is that ANYONE can create an ADK on the end of your existing PGP public key!
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."
See below a message from A.Back. Basically GnuPG is NOT a victim of this "attack".
... "see PGP did it,
> -----Original Message-----
> From: Adam Back [mailto:adam@cypherspace.org]
> Sent: 24 August 2000 15:12
> To: Ross.Anderson@cl.cam.ac.uk
> Cc: ukcrypto@maillist.ox.ac.uk; ietf-openpgp@imc.org
> Subject: Re: Serious bug in PGP - versions 5 and 6
>
>
>
> Ross Anderson writes on uk-crypto:
> > Ralf Senderek has found a horrendous bug in PGP versions 5 and 6.
> >
> > [...]
> >
> > He's written a paper on his work and it's at
> >
> > http://senderek.de/security/key-experiments.html
> >
> > Since NAI joined the Key Recovery Alliance, PGP has supported
> > "Additional Decryption Keys" which can be added to a public key.
> >
> > The sender will then encrypt the session key to these as well as to
> > your main public key. The bug is that some versions of PGP respond
> > to ADK subpackets in the non-signed part of the public key data
> > structure. The effect is that GCHQ can create a tampered version of
> > your PGP public key containing a public key whose corresponding
> > private key is also known to themselves, and circulate it. People
> > who encrypt traffic to you will encrypt it to them too.
>
> Amazing, and really unfortunate. Those of us who invested large
> amounts of effort in ensuring the ADK subpackets were not included in
> the ietf openPGP standard can be pleased we succeeded -- otherwise
> gnuPG and other implementations may now also have contributed to this
> risk. As it is gnuPG doesn't honor ADK requests, and all the rfc2440
> says about them is:
>
> 10 = placeholder for backward compatibility
>
> At the time I was suggesting that if PGP really must insist on
> creating software to escrow communications (the primary argument being
> that people didn't want to lose access to the stored mail as opposed
> to being able to have designated third parties snooping mail in
> transit) they should use storage key escrow.
>
> My main premise was that communication key escrow is too risky because
> an outside attacker gets the plaintext:
>
http://www.cypherspace.org/~adam/cdr/
"Keys used to encrypt email which is transmitted over the Internet are
more valuable to an attacker than keys used to encrypt stored files
because of the relative ease with which an attacker can obtain copies
of emailed ciphertext. Stored encrypted files in contrast are
protected by all the physical security systems the company is relying
on to protect it's paper files, plaintext data stored on disks, and
backup tapes. [...]"
There was also lots of political discussion of how unwise it was for
PGP to create a escrow infrastructure which could as easily be used by
governments as by SEC companies to archive their employees
communications.
And people quoting Phil Zimmermann a few years earlier complaining
about ViaCrypt's PGP4 for business variant which had "escrow" in the
form of a third party "encrypt-to-self" config file setting.
And I believe I recall the NSA or some other US government body
picking up on the CMR / ADK mechanism and holding it up as evidence
against the claim that key recover was complex
this works".
> It's of scientific interest because it spectacularly confirms a
> prediction made by a number of us in the paper on `The Risks of Key
> Recovery, Key Escrow, and Trusted Third-Party Encryption'
> that key escrow would make it
> much more difficult than people thought to build secure systems.
Yes. It really highlights the truth in the statement about the
new risks introduced by adding key escrow.
Adam
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."