Re: Proof of concept that PGP AUTHENTICATION CAN BE BYPASSED WITHOUT PATCHING
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/