Update : 3rd message dated Mon, 28 Aug 2000 18:15:51 +0200 (see at the end) From: "Michel Bouissou" Newsgroups: alt.security.pgp,comp.security.pgp.discuss,sci.crypt Subject: PGP 6.5.8 test: That's NOT enough !!! Date: Sat, 26 Aug 2000 12:49:17 +0200 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've just tested the "ADK-bug-fixed" PGP 6.5.8 against Ralf's B1 forged key that holds a faked ADK. Where previous versions would show this key as having an ADK, and use the forged ADK, the "fixed" PGP 6.5.8 shows the forged key as being a normal, valid key, without any ADK. PGP 6.5.8 will not use the forged ADK for encryption, and will just behave as for a normal key. Well, okay, it "fixes" the bug. BUT IT DOESN'T WARN YOU IN ANY WAY THAT THE KEY YOU'RE USING HAS BEEN FORGED. You just see a valid key and the forged ADK is ignored. So: - - You don't know the recipient's key has been victim of an attack; - - You don't know that this key remains a potential danger for users that still have previous versions of PGP. Actually with PGP 6.5.8, you have LESS CHANCES to ever detect that a key was forged, than you had with previous vulnerable versions. That's no good folks. Waiting for 6.5.9 that will display a BIG WARNING that an ADK sits where it shouldn't on a given key. - -- michel@bouissou.net -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use Comment: Corrigez le bug PG ADK. Installez PGP 6.5.8 ou plus recent. iQA/AwUBOaeSnY7YarFcK+6PEQJUCACdFPt9KmCr+ImmCdpYt8i6XUlcmYUAnRRj +OXfvsBkFugPmzNIlCaVO2N5 =iGL6 -----END PGP SIGNATURE----- ******************* From: "Michel Bouissou" Newsgroups: alt.security.pgp,comp.security.pgp.discuss,sci.crypt Subject: PGP Bug: IMPORTANT Personal test report Date: Fri, 25 Aug 2000 13:20:49 +0200 Well folks, To be able to diagnose the EXACT behaviour of my PGP 6.5.2 Freeware / Windows, I made some tests myself which will help understanding how PGP behaves when encrypting to keys with a forged ADK. My PGP has the following settings: - Warning when encrypting to key with an ADK set to ON; - Display of the ADK column in PGPkeys set to ON. For this, I imported forged test keys gotten from Ralf's website in the following way: 1) I imported Key-B1, which is "Billy Clean's" key to which a forged ADK was added - This key shows up in PGPKeys with the ADK circle being RED, which immediately identifies this key as containing a forged ADK. - The properties of the key shows an ADK tab, in which I see the unknown key (keyID) being an enforced ADK. ==> FIRST CONCLUSION: It is immediately visible in PGPkeys that the key contains an ADK, although PGP doesn't detect that this ADK is a forged one. 2) From the explorer, I encrypted a text file to "Billy Clean's" key and mine as well. - As soon as I select "Billy Clean's" key in the recipient key selection box, I get a dialog box that states: "The user Billy Clean has a missing Additional Decryption Key". Contact the owner of the key to obtain the additional decryption key" - I click on OK then see only my own key and Billy's one in the selected recipients field. - I encrypt and all goes well. - Now I try to decrypt the file. The dialog box shows the file was encrypted to BILLY and MYSELF, no visible trace of another decryption key. - I can decrypt the file. 3) Now I import Key-C into my keyring, which is the public key of the "forger" of Billy's key -- The ADK's public key. - The "ADK" tab in Billy's public key properties box now shows that his ADK is "control" (the newly imported key). 4) From the explorer, I encrypt again a text file to "Billy's" key and mine as well. - As soon as I select "Billy's" key in the recipient selection box, BOTH BILLY'S KEY *AND* CONTROL'S one drop into the selected recipients field. - IT IS THUS VISIBLE THAT "CONTROL" WILL BE ABLE TO DECRYPT THE MESSAGE - NO SPECIFIC WARNING DIALOG BOX HAS BEEN ISSUED BY PGP although the "Warn when encrypting to key with an ADK" option was selected. ==> SECOND CONCLUSION: The warning option doesn't seem to work at all in this situation, but it is visible that there will be a supplementary recipient that was not selected by the sender. - Now I encrypt the file 5) I try to decrypt the file - The decryption passphrase box shows me that the file is encrypted for ME, BILLY and CONTROL. It is thus visible to me that CONTROL is able to decrypt the file. - The file decrypts OK ==> IMPORTANT NOTE: - In the first place, me not having the ADK public key, it seems that the file was NOT encrypted to the ADK - In the 2nd place, me HAVING the ADK public key, the file was visibly encrypted to the ADK as well THIS IS MOST IMPORTANT. Reading carefully Ralf's paper, the ADK public key seems NOT to be actually included in public keys that mention mandatory use of this ADK. YOU MUST HAVE THE ADK public key as well. Only the ADK's key ID is included in the key that holds and ADK, which is not enough to allow encryption to the ADK by itself. ==> IF YOU ENCRYPT A MESSAGE TO A KEY WITH AN ADK, but DO NOT have the ADK public key in your own keyring, PGP warns that the ADK key is missing, then apparently DROPS it and accepts to encrypt to the intended recipient ONLY, and NOT to the ADK !!!!! THIS DRAMATICALLY LOWERS THE RISK OF EXPLOITATION OF THIS BUG, because if you receive a key with a forged ADK for one of your correspondants, you would ALSO NEED to have the forged ADK's public key in YOUR own keyring to make PGP able to encrypt for this key. Without this ADK public key, PGP will warn you that it is missing, and will just drop it and encrypt for the recipient only ! - And there is a low probability that you have this attacker's key in your ring... If yes, you might be able to easily identify the attacker. SUMMARY OF RESULTS: ===================== According to the tests I made: 1) Keys with an ADK (forged or not) can be clearly visible in PGPkeys 2) The "warn to encrypt to key with an ADK" feature does NOT seem to work 3) The ADK's recipient key gets clearly visible in the "recipient selection box" as soon as you select a recipient key that holds an ADK and you have the ADK's public key in your keyring as well. 4) Due to the faulty (2), the existence of the ADK COULD BE INVISIBLE when the selection of recipient keys is automatic (and thus the selection box is bypassed), i.e. when using an e-mail software plugin. But I had no occasion to test this yet. 3) You MUST have the ADK's public key in your ring for PGP to encrypt a message to this ADK 4) If you don't, PGP issues a warning and bypasses the ADK. ENFORCEMENT OF ADK IN PGP is NOT STRICT, you can bypass it as soon as you don't have the ADK's public key in your ring ! FINAL CONCLUSIONS: =================== In light of this, it appears to me that the COMPLETE IMPLEMENTATION OF THE ADK SYSTEM IN PGP IS SERIOUSLY FLAWED and doesn't meet the security and quality standards expected for such critical software. - ADKs can be forged onto public keys in an unacceptable manner; - Wanted (option selected) warning messages are not displayed; - Enforcement of the ADK policy is not strict and can be bypassed, which doesn't suit the needs of organizations that want to make sure that the ADK policy HAS TO BE APPLIED in all cases. And all this is very disappointing to me. -- Michel Bouissou PGP DH/DSS ID 0x5C2BEE8F Network Administrator - Internet Quake - http://www.i-quake.com ********** From: "Michel Bouissou" To: , , , , , , Cc: "Ralf Senderek" Subject: Tr: Your update to CERT Date: Mon, 28 Aug 2000 18:15:51 +0200 Following the "update to CERT" written yesterday by Ralf Senderek, I sent him back some further comments. Ralf answered to me, suggesting that I should forward my comments to you "the way they were", which I am pleased to do. Best regards. Michel Bouissou PGP DH/DSS ID 0x5C2BEE8F Following the "update to CERT" written yesterday by Ralf Senderek, I sent him back some further comments. Ralf answered to me, suggesting that I should forward my comments to you "the way they were", which I am pleased to do. Best regards. Michel Bouissou PGP DH/DSS ID 0x5C2BEE8F -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ralf, I saw your update to CERTand have complementary notes. Please see my comments below. > But let me come to your conditions which will be globally cited and > will be important for users to recognize their risks. > > * the sender must be using a vulnerable version of PGP Yes. > * the send must be encrypting data with a certificate modified > by > the attacker Yes. Which necessitates that the recipient's public key was a vulnerable one: a key with a v4 self-signature. > * the sender must acknowledge a warning dialog that an ADK is > associated with the certificate NO !!! There is no such warning dialog, at least in the G.U.I. versions of PGP for Windows that I have tested. Even with the "Warn when encrypting to keys with an ADK" option set, you don't get the kind of warning dialog or box you could expect. According to Will Price, director of PGP development at N.A.I.: (Quotes from Will Price are lines preceded with *> ) <<<<< *>"Warn when encrypting to keys with an ADK" does in fact mean "warn me if I *>encrypt to any key which has an ADK on it." However, it does NOT mean *>"blow sirens and put up special dialog boxes if I encrypt to a key with an *>ADK on it." *> *>Basically, the option is only meaningful in the context of mail plugins *>where the recipient dialog may not even appear. In the case where you *>encrypt to Joe and you have Joe's valid key in your keyring with an ADK, *>the mail plugins will bypass the recipient dialog unless you have the *>option above checked (as it is by default). *> *>In other words, the option means "make sure I see the recipient dialog if *>there is an ADK being used." >>>>> So, if you encrypt to a key with an ADK, you will not see anything more than the usual recipient key selection box, in which you may -- or may not -- notice the presence of the ADK recipient key. You will get a true warning message ONLY IF you don't have the ADK key in your public ring: Then you get a message asking you to get the ADK key from its owner. See details in the posts I wrote when first testing keys with bogus ADKs. In this respect it looks like error and warning messages were not designed to prevent you from encrypting to an unwanted ADK, but rather to help enforcing ADK policies, which is not exactly the same thing... > * the sender have the key for the bogus ADK already on their > local > keyring Yes. > * the bogus ADK must be signed certificate by a CA that the > sender > trusts No !!! Even if Will Price writes: <<<<< *>One other simple reminder I'd like to make is that aside from needing to *>have the ADK key on your keyring, the ADK key on your keyring must also be *>*valid*. If it is not valid, you will see the recipient dialog telling you *>that you are trying to encrypt to an invalid key. >>>>> My own experiments show, with recent Windows versions 6.5.x of PGP, that you actually get the ADK key shown as invalid in the recipient selection box, but clicking on the usual [OK] button is enough to perform the encryption. PGP v. 5.x and 6.x (G.U.I.) are very friendly with encrypting to "invalid" keys. Much more than the previous text mode versions were, where you really needed to confirm with a YES to a warning message... This is regrettable, because making the encryption to "invalid" keys so easy and common doesn't incitate people to perform key authenticity checking and sign keys by themselves or get them signed by a trusted introducer. It's kind of frequent that you daily encrypt messages (which are not of very high importance) to people for which you haven't verified the validity of their key. Maybe just because you're just answering (and encrypting) to a message they sent you along with their public key, so you reply encrypted without checking the key validity, because you would have felt comfortable to answer without encryption anyway, the contents of the message being of little importance or confidentiality. So you get used to encrypt to "invalid" keys without thinking that much, and you may miss the fact that you're (again) using an "invalid" key the day when you shouldn't have missed that. The current PGP versions are IMHO MUCH TOO friendly with doing this kind of things, and should at least ask for individual confirmation before encrypting to any invalid key. This would incitate users to validate their keys, maybe just to get rid of the annoying confirmation messages, but this would be done. Making encryption to invalid keys so easy may be a good idea from a marketing standpoint. It is surely not from a security standpoint. > * the attacker be able to obtain the ciphertext sent from the > sender > to the victim Yes. > Back in the old times before those clickable damage traps came up > trust had something to do with using your secret key. When getting > a new key the user had to do something which was not done in half a > second. Adding a key without using your secret key would bring the > key into the keyring but it would still be handled as untrusted. > Accepting it as a trusted key would have required > self-certification or having authorized another key as an > introducer which would require using > your secret key as well. True. > Today exposing yourself to the risk I had described would require > only getting the manipulated key, and pressing the OK-button and > because no secret key is used one should not call this trust. > That is why no trust is neccessary to make the manipulation work. > The bogous ADK just has to be present in the key ring, that's all. Exactly. [...] > Another point which you do not emphasize enough ist the > vulnerabilty of RSA key. Or may I say the lack of it. > > Your statement was : > > "The recipient may use any type of PGP key, including RSA and > Diffie-Hellman. The version of PGP used by the recipient has no > impact on the attack." > > You failed to tell the people that neither RSA nor Diffie-Hellman > is the problem but Version-4-self-signatures, as I had discovered. > To produce a Version-4-RSA-key from a Version-3-RSA-key is possible > but it had to be done with a key-editor I never saw the > transformation happen automatically as I documented in my paper. > So the difference between RSA and Diffie-Hellman is important, > because all DH-keys are Version-4 and vulnerable and only those > RSA-keys which have been tampered with and whose key-ID had changed > in the manipulation can be contaminated. The vast majority of > RSA-key users who know their key-ID well can be sure that their > key is not affected after having checked that it has an old-style > self-signature. I must admit that I had quite missed the point myself until you corrected my first posts. It indeed IS in your report, But IMHO you should have stressed the point much more. At first, I had uncorrectly understood that PGP5 or 6 could change the v3 sig of RSA keys into v4, or create RSA keys with v4 sigs. It's only when I got your comments and double-checked with your report that I understood that only GnuPG could create RSA keys with v4 sigs on them. Maybe your call for using only 2.6.x versions of PGP could have been moderated with the clear statement that using RSA keys that had been generated and signed only with PGP, no matter the version, was riskless. > Please do not add to the denigration of RSA-keys, they are > different in respect to the ADK-problem. Yes, but this becomes clear only when the above has been correctly understood ;-) Best regards. Michel. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use Comment: Corrigez le bug PGP ADK. Installez PGP 6.5.8 ou superieur. iQA/AwUBOapozY7YarFcK+6PEQIsJQCg4adUGr4EEyBSEPVnt7Z2AtkDpwkAoNQB CQkGveoK064tE/uOKao+/ZTS =bLXj -----END PGP SIGNATURE-----