listen to this article:
Last week, I had the pleasure of attending the Real-World Cryptography conference (RWC 2020) in New York. There was a large attendance with over 600 people (yes, this is a large number for an academic cryptography conference), who came to hear about academic work that has impact on practice. I found many of the talks very interesting, and I will describe some of them here.
Tetsu Iwata presented a talk on attacks on the authenticated-encryption scheme OCB2. This is a standardized scheme that has a proof of security, and was assumed to be secure for 15 years. On September 6 2018, Inoue and Minematsu [IM] found a potential gap in the proof of security, and a month later converted this into a quite theoretical forgery attack. Yet another month later, they further strengthened the attack. At this point, things went haywire – Poettering found a distinguishing attack and published it two weeks later, Iwata saw this and extended it to a full plaintext recovery attack in just two days, and the forgery was even further improved. This is an amazing example of the saying “attacks only get better”, which is used by cryptographers to argue that as soon as a crack is found in a scheme, it needs to be replaced. Another interesting lesson is that all of this happened even though there was a proof of security of the scheme. This is a good reminder that proofs can sometimes be wrong, and scrutiny and review of proofs is crucial. It is really important for me to stress that this does not undermine the importance of proofs at all. Proofs are written by humans, and humans make mistakes. This is understandable and only those “who do” can make mistakes. However, as a community, we need to examine and re-examine and re-examine proofs to be absolutely sure of the security of the schemes that we use.
Another talk that I enjoyed was by Jean-Baptiste Bédrune from Ledger on breaking HSMs. The talk was extremely surprising in the number of bugs and flaws that they found. There were multiple bugs that could have been utilized, but they were looking for the ultimate – the ability to upload malicious firmware remotely and completely own the HSM (including extracting all keys). The HSM developers appeared to have worked under the assumption that an HSM is secure, and attacks won’t ever be possible. As such, they did not use a defense-in-depth design. For example, everything runs as root, all of the keys in the HSM are protected by one key (with no actual separation between slots/partitions), and more. The vendor relied on security by obscurity, and this is just not acceptable in 2020. It is not possible for us to know if these attacks were utilized by attackers in the past. I stress that the attacks are all software attacks, and do not require any physical access. An HSM is actually no more protected against software attacks than any other machine.
The next talk after attacks on HSMs was an analysis of TPMs. These are also woefully vulnerable to side-channel attacks. TPMs are actually in the hands of the attacker (according to their security model) and so security against side channel attacks should be a given. However, the TPMs they analyzed even had timing attacks against them. This is insane! Prevention against timing attacks is well understood, and there is really no excuse for this (in contrast to other much more subtle attacks that are harder to protect against). The researchers managed to extract ECDSA and RSA keys in 3-4 minutes only.
The final talk that I want to highlight was by Chandler Carruth from Google about the ramification of speculative execution attacks on cryptographic code. It was very enlightening, and one really important thing for me to understand was that according to him, these attacks are specifically disturbing since forensics are not able to help us understand what happened after the fact. The example of the difficulty of dealing with these attacks that was most scary for me was that if we have code that accepts a key and then checks if the key is an ECDSA or RSA key, and then computes ECDSA or RSA based on the check, then this could be a real problem. In particular, the speculative execution of the machine could compute RSA on an ECDSA key, and no one has any idea what the ramification of that would be. Of course, that computation would be “erased” after the branch was checked, but as with speculative execution attacks, it could be too late by that point (with a cache side-channel attack being possible). This highlights the fact that it’s extremely hard, if not impossible, to prevent such attacks.
There were many other good talks, but these were my favorite four. See you next year at RWC 2021 in Amsterdam!