Dan Griffin's Blog
Comments on security, PKI, smart cards, cryptography, and entrepreneurship.
SSL, TLS 1.0, and TLS 1.1
April 22, 2006
An article entitled Transit Safety in the April 2006 Information Security magazine made me realize that I didn’t really know the difference between SSL and TLS (note these are widely-used internet security protocols; see the little lock icon on your browser when you buy something on Amazon.com). Unfortunately, it appears that free online access to that article is not readily available. But, my comments are based on other available references.
The primary difference between SSL and TLS is that the SSL protocol, originally defined in 1994, is the intellectual property of Netscape. TLS, which is based on SSL 3.0, is a much newer open standard defined by the IETF. So much for the original question …
One interesting crypto-related tidbit came out of my research, though.
The TLS 1.1 proposal is currently in draft phase. Interestingly, a primary reason for its existence is to replace the use of PKCS #1 v1.5, used by TLS 1.0, with PKCS #1 v2.1 (PKCS #1 is a data-padding standard for the RSA cryptosystem). This is due to a cryptographic threat known as the Bleichenbacher attack. Suppose an eavesdropper has captured the encrypted session key which the client (e.g. a web browser) sends to the server (e.g. a web server) during the TLS protocol setup phase. The goal of the attack is to compromise that session key, at which point the data exchanged during the session (e.g. your credit card number) can be recovered by the attacker. Note that the session key is encrypted such that, in theory, only the server’s RSA private key can decrypt it.
To accomplish the attack, a series of carefully chosen permutations of the RSA-encrypted session key are transmitted to the server. The server’s response to each transmitted permutation is a single bit of information: Valid or Invalid. The Valid response indicates something remarkable – that the permuted, encrypted key, when decrypted via the server’s private key, resulted in a valid, correctly-padded message.
Observe that in the client’s original plaintext/padded message, some byte values are fixed (e.g. the session key bytes, as well as a few of the padding bytes) and some byte values can vary (i.e. the remainder of the padding bytes). Refer to PKCS #1 v1.5 for more info.
Consider the behavior of the padding in another way. Suppose that by changing a specific bit in the ciphertext, I can affect a specific byte in the plaintext (I don’t claim that to be possible, at least not exactly). There are three cases:
- Variance in the session key bytes will still result in a valid padded message, but the server would end up with the wrong session key
- Variance in the fixed padding bytes would result in a message that fails to decrypt (more accurately, fails the padding check immediately after decryption).
- Variance in the variable padding bytes would result in successful decryption and the correct session key.
So, based on that, we can say that that PKCS#1 v1.5 is insufficiently plaintext aware. In other words, it’s possible for the attacker, via trial and error, to discover a number of valid ciphertexts that correlate with a desired plaintext (that is, specifically the session key bytes of the plaintext). In summary, Bleichenbacher is an adaptive-chosen-ciphertext attack. Bottom line: if the server is using a 1024-bit RSA key, an estimated one million chosen ciphertexts can compromise a session. Such an attack is well within the grasp of even a poorly funded hacker. The PKCS #1 v2.1 RSA padding standard (see the PSS scheme, currently section 9.1), and hence TLS v1.1 which will adopt it, addresses this problem by being much more plaintext aware. Per the v2.1 standard, a PSS padded message has only nine fixed bits. Based on my analysis, all remaining bits of the padded message are in various ways derived from the base message (e.g. a session key). In other words, and in contrast to v1.5, there are no variable padding bytes. So case (1) above doesn’t apply and case (3) is exceedingly unlikely. Hence, no Bleichenbacher!
No Comments »
No comments yet.
RSS feed for comments on this post. TrackBack URL
