This post follows on from the previous one describing the range of RSA mechanisms supported in PKCS#11, and their security properties (or lack of). One big change to the standard in the upcoming version 2.40 is a separation of the mechanisms in to “Historic” and “Current” mechanisms.
The standard doesn’t say anything specific about the security of the mechanisms in each, but one might conclude that the Historic category will include all the broken mechanisms and the Current list those still believed to be secure.
This is not the case.
Looking at the RSA mechanisms, the Current list still includes PKCS#1v1.5 encryption as well as the raw mechanisms and ISO 9796, which as we discussed last time are not suitable for use in new applications.
There are also some newcomers in v2.40.
The first are mechanisms for use with the TPM. These consist of RSA PKCS#1v1.5 and OAEP with the addition of the padding as described in the TPM TCPA_BOUND_DATA structure, specifically the version number of the TPM across two bytes followed by two bytes of zeros. As specified in the standard, these are added on encryption, but only the first two bytes are checked on decryption.
The security of OAEP should not be affected by the extra padding on the interior plaintext. For PKCS#1v1.5, the extra formatting might offer a degree of protection against the best publicly-known chosen ciphertext algorithm since it reduces the probability that an arbitrary ciphertext decrypts to give a valid padding. However, this depends on the error messages being identical and there being no other way to distinguish the error types (e.g. by timing). Essentially, PKCS#1v1.5 is still a minefield and should not be used.
RSA AES Keywrap
Finally we come to the most intriguing new mechanism in the standard, a hybrid keywrap scheme combining RSA OAEP with AES keywrap. While OAEP has well-studied security results, AES Keywrap is less obviously sound as we discussed in our review of the W3C Crypto mechanisms. But, there is one very interesting feature in this mechanism which is that for the first time, it allows a standardized mechanism for key wrap to carry information about the attributes that the unwrapped key should be given. These attribute values are given via the PKCS#8 private key structure. The problem of managing attributes under wrap and unwrap gives rise to a whole host of attacks (get our whitepaper via the form on the right for a host of examples), and often leads to vendor lock-in as proprietary mechanisms have to be used. Interestingly, this new mechanism was proposed by a vendor.
The changes to RSA support in PKCS#11 v2.40 are a mixed bag: the “Current Mechanisms” list includes known-to-be-dangerous padding methods, new mechanisms include new ways to go wrong with PKCS#1v1.5, but there’s also the introduction of a credible-looking keywrap method. It’s only specified for managing private keys unfortunately – banking users will also often have long-term symmetric keys they’d like to be able to share between HSMs and backup securely and in a vendor-independent way. The mapping between private key objects and PKCS#11 attributes isn’t made precise. But it’s a step in the right direction and a sign that the need to address this problem has been recognized.