The structure of the PKCS#1 key block used to encrypt a content-encryption
key in a recipient public key offers some integrity protection. Other
techniques have been defined that offer even more integrity.
The recipient of such a block has some assurance that the unwrapped key is
the one used by the originator. Thus, it is unlikely that the recipient
will spend time decrypting the message content if an attacker altered the
wrapped content-encryption key.
I am trying to specify a mechanism that offers similar capailities with
Diffie-Hellman key management.
There are many, many denial of service attacks possible. This mechanis is
not intended to address all of them.
At 12:31 PM 6/19/98 +0100, Dr Stephen Henson wrote:
Russ Housley wrote:
This technique does not offer any integrity. I have a strong desire for a
mechnaism that allows a message recipient to detect problems with the key
before processing the entire message content is possibel.
Indeed it does not provide any integrity but then again even a
sophisticated scheme is not resistant to even simple attacks. The
anonymous nature of most of the enveloped data forms (barring non anon
DH which has a signing element anyway). I'll describe a few possible
attacks with each mode to illustrate the point.
Some of these could also occur due to message corruption.
These first few work in all modes and attack all recipients at once.
1. The simplest attack is just to substitute bogus content. This is
possible because RecipientInfo structures can be built using just public
information (public keys of recipients or a random anon-DH keypair).
Since this is a perfectly valid message it decrypts fine.
2. Just scramble the encrypted content. Since only the last block has
any kind of integrity check if you leave it and the previous one alone
(due to CBC mode) you can kill the whole content and it will still
decrypt fine. This works in static DH modes.
The next few can be aimed at several recipients or just one. In the case
of single recipient attacks the other recipient can read the message
3. Delete the RecipientInfo structure(s). A bit primitive and easily
4. Substitute the RecipientInfo structure or part of it from another
message. This shouldn't be detected until the whole message is read.
Even then it may not be detected. Again this can hit static DH.
The next few rely on finding a specific "content decryption key". Since
only the last couple of blocks of a message have any kind of integrity
check it is possible to find a bogus content encryption key which will
decrypt the message just fine but yield only garbage. This can be done
by just trying random keys. On average this will work after around 128
5. Substitute the RecipientInfo structure(s) with one for the bogus key.
Key transport makes this very easy. Key agreement is similar, except you
have to follow the integrity check rules (if any).
6. In key agreement swap the first two blocks of the EncryptedKey. This
I believe is the attack that an integrity check will prevent. You can't
touch the last two blocks because that could break the padding: since in
3DES this padding will be 8 8s this makes it unlikely that touching the
last two blocks will work.
7. (May not be possible: depends on final structure) fiddle with the IV
for the EncryptedKey.
... Lots more I can't think of at present.
Given that only one of these is stopped by an integrity check and
several of the others are undetectable (and number 4 is particularly
easy and nasty) IMHO an integrity check does not offer much if any
useful protection. What do other people think?
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
PGP key: via homepage.