thesinoda@xxxxxxxxxxx wrote: > This to answer Mr Jon Callas (PGP CTO) and to show him the last > proof-of-concept. If he did not get it we consider we have done our > part to report a BIG problem in PGP unless this is some kinda of > HIDDEN features. > > We do not know why they just see one side of the coin. I don't quite see the other side. They, and several others here have explained what is happening. At most I can see a user interface issue here, as I will detail below: > What if you had created a virtual disk and give that to someone. > That someone use it as his/her own disk This is unsafe, unless the disk is reencrypted. > and decided to change the password because they own the disk now The assumption that changing the password will disallow access from a former owner of _that_ very same disk is wrong. You have to reencrypt the disk, if you want to take full "ownership" of the data. > So they did change the passowrd, but the originator can still access > that disk if he/she replace the passphrase bytes in the binary file. That is not even necessary. You can just save the actual encryption key and decrypt the disk with a modified software. > So I consider this an attack on data INTEGRITY and data AVAILABILITY Containers of this kind cannot assure this anyway. Integrity of the file might be checkable, but what is the point in checking the integrity of data you want to protect from an adversary that can decrypt the data anyway? Are you suggesting that the software should check for a modified header? How should the software do that? Said header is perfectly valid. It is just for another time in the disks lifecycle. So you could only check it together with the whole disk. That would mean hashing a few GB of data ... everytime you unmount the disk. Or at least everytime you want to check integrity - so at least at mount time ... And: What would that give? An attacker can easily disable such checks. Regarding availability: > since the legitimate user will be denied access to the disk after > replacing the passphrase bytes. How do you want to avoid that? If an attacker has write access to a container file, he can just as well overwrite it with gibberish, thus really denying access. A cryptocontainer is designed to thwart illegitimate access to data. It is not designed to protect its content against manipulation. > "why you do not want to see that your password verification can be > simply bypassed, It cannot. You can only restore a previous version of the disk key, which was encrypted by a known password. You could just as well simply store the disk key. > besides a reputable co. like PGP should at least put anti-debugging > tweaks, What for? Security by obscurity? If you use it properly, it is absolutely irrelevant, if the encryption software is being traced. If you cannot recover the disk key, you can't read a single thing making sense. You are _not_ bypassing any "authentication" with your trick. You are only using you previous knowledge about the disk key in an obscure way. You can just as well jump ahead in the code to the point where the disk key is there in decrypted form, replace it by the known value and run on. No need to even enter a password actually. > or even encrypt/hide the passphrase location" It is encrypted. Let's sketch the way such programs work again: When a container is created, a random "disk key" (DK) is generated. This is what is used to actually encrypt the sectors on the disk. When reading/writing, something along the lines of D_S(DK,[sector ciphertext]) or E_S(DK,[sector plaintext] is used to en/decrypt the sector, where D_S and E_S are the sector de-/encryption functions, which often take additional state parameters (like the sector number) to avoid some watermarking attacks etc. As humans are very bad at remembering 256 Bit binary (or hex or base64 or ...) values, this key needs to be stored somewhere. Unless hardware crypto tokens are in use, where can you store it? First idea: On disk. But: This would be ridiculously insecure. The solution is, to store it, but encrypted. So what disk encryption programs usually do, is to store the actual disk key somewhere in the volume header of the container - encrypted with the passphrase the user has to give when mounting. Of course one could as well derive the "disk key" directly from the passphrase. However that has the disadvantage of not being able to change the passphrase easily. Let's reiterate the workings once more: When doing operations on the disk like reading/writing sectors, the Disk Key DK is used like this: D/E_S(DK,[sector cipher/plaintext]). The key DK has been randomly generated at volume creation time. When a user mounts a crypto volume, the Disk Key needs to be determined. This is done by entering a password/phrase. This passphrase is then used to decrypt an encrypted version of DK. So what is in the volume header is E_DK(K_DK(passphrase),DK) where E_DK is an encryption function used to encrypt the disk key, K_KD is some kind of key material derivation function that transforms a passphrase into a key suitable for E_DK. When changing passphrase, only this stored value E_DK(K_DK(passphrase),DK) gets overwritten with E_DK(K_DK(new_passphrase),DK). Take back that change and the old password will work again. Corollary: Anyone who knows a working pair of passphrase and E_DK(K_DK(passphrase),DK) will be able to derive DK. And if you have DK, you can do any operation on the disk. The passphrase is absolutely irrelevant for accessing the disk contents. The passphrase is there to protect DK. If DK is known by an adversory, you need to change DK. If you suspect a password for a crypto volume to be compromised, you have to change _DK_ unless you are absolutely sure, that the possible attacker cannot get at a version of the container which worked with that password. This is, because an attacker that has both the passphrase and E_DK(K_DK(passphrase),DK), he can derive DK and thus do all disk operations as if he knew the new passphrase and E_DK(K_DK(new_passphrase),DK). Both pairs of information allow to determine DK. So in most cases, where password changes are executed due to a suspected compromise, you should also reencrypt the volume. Just changing passwords is ok, if you just do that to e.g. sync the password up to the new password scheme you started using to avoid having to remember any old scheme you used for other systems that demand password changes. It is not sufficient, if you suspect someone might have gotten the password and a container version for which it works. > To pgp, your authentication can be bypassed, There is no authentication. You are just recovering the known DK, as the new owner didn't bother to change it. > even if you have created two different .sda file with two different > content. the authentication can be overwritten and the file can be > extracted if you use a debugger No need to use a debugger. Try your method with a file that was reencrypted. Try it with a file that was created independently. You can't. > if you do not use a debugger you will be able to just bypass the > authentication but without extraction. why don't you see that mr. jon? I hope my comments clarify the inner workings of disk encryption programs and what password changes can and can't do. The reason why you don't just always reencrypt is, that this takes a very very long time. Changing the password with the above scheme only needs to calculate E_DK(K_DK(new_passphrase),DK) and write that to disk. No big deal, done in seconds. Changing the DK will require reencrypting all sectors of the virtual disk. And - often worse - you need to read and rewrite all those sectors. > instead of bitching and stuff? Because he's right? He knows the inner workings and stated quite plainly what is happening. There might be an UI issue that users should be warned more about only changing passwords, but there isn't more to it, as far as I can see now. > why cannot you be professional and just explain fact after you do > your home work with a nice debugger.? I don't quite see a fact not yet explained. > http://www.safehack.com/Advisory/pgp/answerjon.html Yeah - you do what I sketched above. I don't see any authentication bypass. > Quote from Mr Jon comments: "For completeness, I'll note that we are > discussing whether we should add in a warning dialog to the passphrase > change on a PGP Disk, to tell the user that an attacker who has > learned an old passphrase, has an old disk and a hex editor can patch > the disk so that it can be opened. On the one hand, this might be a > good thing to do". > So if Mr Jon does not see the problem why they are talking about > adding a message box? Because a user might be expecting the behaviour you sketch: That changing the passphrase will render knowledge of old password and disk state useless. Obviously, at least you fell for that belief, which is wrong. So it might be a good idea to clarify that to Joe Average. > Why the passphrase location is not hidden? etc. There is no need to hide it. Hiding something is the _wrong_ thing to do. Security should rest on the secret used to protect it alone. This secret is the DK. By having another person know the DK (because he knows an old passphrase and has a copy of the DK encrypted with it), you share the secret that protects the data. That is, what needs to be avoided. You can of course make the above process a bit more painful by adding some voodoo to the process of determining the DK, but unless the DK is changed, all that effort is in vain. And voodoo is something a security software should _not_ employ. It will obscure real problems from reviewers. > I still see this as INTEGRITY and AVAILABILITY attacks on PGP. They are not. Moreover: If you want to talk about INTEGRITY at all, you should never ever use SFX-Style .EXE files that might have been tampered with, as I explained in http://seclists.org/lists/bugtraq/2006/Apr/0519.html#start > I do not think it is normal behavior of an encryption application to > reveal it is passphrase location There is no way to hide it. If you change a password on a container, the password will change, so a diff will show where it is stored. > and I do not see bypassing the passphrase dialog-box as Feature either. Try your "attack" on a volume that is not cloned from another volume, or on a volume that has been reencrypted. See it fail. I will skip commenting on the rest of the mail for obvious reasons. Regards, Andreas Beck -- Andreas Beck http://www.bedatec.de/