This is the latest in our series analysing the state of the art cryptanalysis results on the RSAmechanisms, hash functions and block ciphers available in PKCS#11.
We've seen that PKCS#11 makes available a range of block ciphers ranging from dubious to recommended options. Additionally, for most block ciphers, several modes are available. What are the security consequences of the mode choice?Here we survey the block cipher modes available, giving a brief summary of their security. If you really want to understand block cipher modes, you could do a lot worse than read Phil Rogaway's block cipher mode survey written in 2011. We draw heavily on that for this article. Note that in PKCS#11 some of these modes are only available for AES at the moment.
ECB
This is almost certainly not the encryption mode you are looking for. Even calling Electronic Code Book a mode is enough to make some cryptographers scream. The easiest way to see why is to observe following two pictures sourced from the wikipedia page on block cipher modes. On the left we have the plaintext. On the right, the ciphertext as obtained under ECB mode. Is that what you wanted? No, thought not.
CBC
To talk CBC, we need a brief detour into security notions. There are two security notions commonly used to discuss the security of encryption modes (well, actually there are several but let's not go in to that right now). One is the security against chosen plaintext attacks (CPA-secure) and the other security against chosen ciphertext attacks (CCA-secure). Very roughly speaking CPA-secure means secure against a guy who can observe a bunch of encryptions on the wire, including those that correspond to a plaintext he already knows, but he can't, for example, send you a carefully manipulated ciphertext and observe your behaviour. The CCA attacker can do this. In reality, it turns out that you need CCA security for almost every practical application of cryptography. CPA-security is interesting as a building block, if you're going to add something later (like a MAC or keyed hash) to prevent ciphertexts being manipulated. But on its own it's not much use.So, in that context, we observe that CBC mode is not CCA secure. It is secure against chosen plaintext attacks (CPA-secure) if the IV is random, but not if the IV is a nonce. In particular, CBC mode does not tolerate a padding oracle. The padding mode used in PKCS#11 by the CBC_PAD mechanisms is exactly that which gives rise to most of these attacks. Many real implementations have been shown to be vulnerable.
CTR
New in PKCS#11 v2.40, CTR is CPA-secure, but not CCA secure.
CFB
CFB is not CCA secure. It is CPA-secure if the IV is random, but not if the IV is a nonceFor a summary of the properties of these modes and the dangers of using ciphers with only CPA-security,the following excerpt from Rogaway’s review is apposite:
I am unable to think of any cryptographic design problem where, absent major legacy considerations, any of CBC, CFB, or OFB would represent the mode of choice.I regard CTR as easily the “best” choice among the set of the confidentiality modes (meaning the set of schemes aiming only for message privacy, as classically understood). It has unsurpassed performance characteristics and provable-security guarantees that are at least as good as any of the “basic four” modes with respect to classical notions of privacy. The simplicity, efficiency, and obvious correctness of CTR make it a mandatory member in any modern portfolio of SemCPA-secure schemes.The only substantial criticisms of CTR center on its ease of misuse. First, it is imperative that the counter-values that are enciphered are never reused. What is more, these values are “exposed” to the user of CTR, offering ample opportunity to disregard the instructions. Second, the mode offers absolutely no authenticity, nonmalleability, or chosen-ciphertext-attack (CCA) security. Users of a symmetric scheme who implicitly assume such properties of their confidentiality-providing mode are, with CTR, almost certain to get caught in their error
To turn a CPA-secure mode into a CCA-secure mode, you need to compose it with a MAC. We'll cover that in a future post dealing with the MAC modes available in PKCS#11. Suffice to say that, like all crypto, it's surprisingly easy to get it wrong, so once v2.40 is available, you'd be wise to consider using one of the two modes below instead.
GCM
New in PKCS#11 v2.40, GCM mode has a security proof – the security notion is AEAD (Authenticated Encryption with Associated Data), which (loosely speaking) means that the encryption part is CCA-secure and the message and associated data are unforgeable. There are some cryptanalytic results on certain instantiations of the scheme, those these are not currently thought to pose a practical threat.
CCM
New in PKCS#11 v2.40, CCM also has a security proof for AEAD. It is simpler to implement than GCM, there are some efficiency concerns but currently no real security concerns.
XTS
XTS mode was pulled at the last minute from PKCS#11 v2.40, but may still make it in to version 2.41 or 2.40a. It's designed to be used in mass storage applications. We saw above in the tux penguin pictures that ECB leaks the equality of blocks across time and in any position. XTS leaks the equality of blocks across time, but not position. So the security notion aimed for is weaker than CPA. To understand exactly what the security notion is, you'll have to read section 1.9.2 of Rogaway's survey.
Conclusion
PKCS#11 provides a whole suite of modes from the dangerously insecure to the "provably secure with well examined proofs". As always, choose carefully. If you'd like to know more about secure use of PKCS#11, download our PKCS#11 security whitepaper.