Getting Rid of TLS 1.2: The Weaknesses of PKCS#v1.5 and The Fault Attack
Getting Rid of TLS 1.2: The Weaknesses of PKCS#v1.5 and The Fault Attack
TLS is truly one of the worst and the best protocols. When it works well, it protects data like no other method, but its implementation has often been buggy, and it copes with so many options. One of its greatest weaknesses is that Eve can select the weakest cipher suite that is possible from the server, and then possibly compromise it. But, there are many other problems, especially for PCKSv1#1.5 padding, and where Eve can probe the server, and eventually crack the cipher. For this, TLS 1.3 has dumped PCKSv1#1.5 padding, but the industry is taking time to adapt.
A new paper [1] now shines a light on the current state of the usage of TLS, and where the research team analysed 5.8 billion TLS handshakes from two different university networks:
In their analysis, they found that ECDHE (Elliptic Curve Diffie Hellman with Public Key Authentication) with RSA was the most popular key exchange methods, and with 128-bit AES GCM with a 256-bit hash (SHA-256) being used for the tunnel:
AES GCM was by far the most popular symmetric key method, with the only other mode being CBC (Cipher Block Chaining). In terms of signature methods, both RSA and ECDSA can be open to attack. With RSA, the most common attack is against the usage of PKCS#1v1.5 padding, and which has been dropped in TLS 1.3. The industry, though, is now moving towards TLS 1.3, but its adoption has been relatively slow. For ECDSA, the main problems relates to a non-random nonce value and nonce reuse. Along with the RSA and ECDSA can suffer from a fault attack and where two signatures are produced with the same nonce value: one which is correct and the other has a fault.
PKCS#1v1.5
There have been many attacks on the usage of PKCS#1v5:
In the analysis, RSA PKCS#1v1.5 was by far the most popular signature method (followed by RSA OEAP and ECDSA):
The research team were able to take 200 signatures that used RSA PKCS#1v1.5, and from these 11 RSA private keys where discovered from the signatures.
Fault attack
If ECDSA, we generate a signature with:
and where k is a random nonce value, h is the hash of the message, and d is the private key. Now, let’s say we have two signatures. One has a fault and the other one is valid [2]. We then have (r,s) for the valid one, and (r_f,s_f) for the fault. These will be:
and where h is the hash of the message. Now if we subtract the two s values we get:
Then:
We can then discover the k and then solve for d for a valid signature:
and then discover the private key with:
I have coded this up here:
https://asecuritysite.com/ecdsa/ecd7
Conclusions
I love working in cybersecurity. Why? Because virtually every week a new research paper arrives that changes the way I think about things. If you have time, please read the paper by Sullivan et al, as it has so many great experiments and highly real-life threats. In conclusion, they are critical of the usage of PKCS#1v1.5, and the need to move to TLS 1.3:
The research team also found that faults and errors in TLS signatures can cause private keys to be breached, so please handle RSA and ECDSA with care.
Here is my overview of TLS 1.3:
References
[1] Sullivan, G. A., Sippe, J., Heninger, N., & Wustrow, E. (2022). Open to a fault: On the passive compromise of {TLS} keys via transient errors. In 31st USENIX Security Symposium (USENIX Security 22) (pp. 233–250).
[2] Poddebniak, D., Somorovsky, J., Schinzel, S., Lochter, M., & Rösler, P. (2018, April). Attacking deterministic signature schemes using fault attacks. In 2018 IEEE European Symposium on Security and Privacy (EuroS&P) (pp. 338–352). IEEE.