Subject: Re: [pkcs11] Review before next meeting
|About my work item (Key Wrapping with encoded attributes)|
- I have already noted (thanks to Tim Hudson) to change the tags in section 4.1 to become standard tags in KMIP as well. Previously they were in the « vendor defined » range which will cause problems.
- However there is a more subtle crypto/security point which I’ve come across while addressing another of Tim’s points:
The idea of this wrapping method is to offer a higher level of security than existing schemes where the template for the new key is supplied on unwrapping. This means protecting against attacks where an intruder with access to the PKCS#11 interface may make a second copy of the key with some of the attributes changed - SENSITIVE turned off for example - in order to get hold of the encrypted key value.
The method relies on the new « authenticated encryption » methods added to v2.40: GCM and CCM. Both of these are counter modes, which means that they work by calculating a key stream from the IV + a counter, and then XOR this against the plaintext to obtain the ciphertext.
The problem is that if the attacker controls the IV, he can control the key stream. This means he can use the encrypt operation to decrypt, by giving the cipher text as the plaintext and reusing the same IV. In the context of PKCS11 wrap and unwrap, this mean he could decrypt a wrapped key if he can wrap a known key value. It may be possible to avoid the possibility of wrapping a known value by making heavy usage restrictions on the API, but if we introduce the new wrapping mechanism where attributes (known data for the most part) are included in the plaintext, this is no longer possible.
Options include: make the IVs for this wrap mechanism token-generated (probably a good idea anyway for NIST compliance), add a mode with automatic deterministic nonce calculation like SIV (designed for key-wrap), use an AEAD mode so that attributes are treated as public data.
Description: Message signed with OpenPGP using GPGMail