Minerva Attack and Humble Beginnings
Do you remember ROCA attack - the most devastating attack in 2017 that extracted secret keys from 25% of TPM module? It has a kind of a sibling - Minerva. While ROCA was about the RSA encryption, MINERVA is about Elliptic Curve (ECC) signing.
TLDR: a bunch of open source encryption libraries leak Elliptic Curve signing key. Quite a few widely used libraries were bitten (libgcrypt, wolfSSL, MatrixSSL, SunEC/OpenJDK, Crypto++). Check your projects and upgrade if at all possible.
First Signs of Problem
It seems that the Minerva attack came to light when the research team in Brno were playing with old IDProtect Athena cards. They discovered a correlation between key lengths and timing. This allowed them to eventually recover the whole private key with relatively small number of signatures.
The details of the attack are available from https://minerva.crocs.fi.muni.cz/
This first version of the attack was against specialist security chips. It took around 30 minutes due to slow communication speeds of the chips that would not allow more than 10 signatures per second. Indeed, the number of operations required was only 11,000.
Athena SCS IDProtect that was successfully attacked was approved for use in the US government as PIV cards in 2008. However, these chips are not really being sold any more and I would also expect only a low number to be still in use.
The core problem exploited by the attack is a leakage of the length of numbers used in multiplications of ECDSA/EdDSA. When the multiplication is optimized, it will cause different timings and this can be measured from outside - it's easiest on the same processor but successful attacks were demonstrated when using network loopback or even across local networks. Each such measurement leeks information about the key and the Minerva attack requires between just hundreds of measurements, in some cases, to over hundred thousands.
So - is the attack just an academic issue or is it a sign of a wider problem? After all, some developers like to optimize their code ...
Expanding The Impact
While the impact of the original attack was small, the team had a brilliant idea – what about testing the attack against software libraries. I would expect they were taken aback when they found quite a few popular libraries to be vulnerable.
- CVE-2019-13627: Vulnerability in libgcrypt.
- CVE-2019-13628: Vulnerability in wolfSSL/wolfCrypt.
- CVE-2019-13629: Vulnerability in MatrixSSL.
- CVE-2019-2894: Vulnerability in SunEC/OpenJDK/Oracle JDK.
- CVE-2019-14318: Vulnerability in Crypto++.
Most of them have been fixed in upgrades over the summer, but I’m pretty sure that there will be zillions of projects that will rarely upgrade versions of cryptographic libraries. So the impact may be long-term with smaller attacks to keep coming over many coming years. The list of libraries tested and found safe includes:
- OpenSSL 1.1.1d
- BouncyCastle 1.58
- BoringSSL 974f4dddf
- libtomcrypt 1.18.2
- Botan 2.11.0
- Microsoft CNG
- mbedTLS 2.16.0
While I was in no way connected to this attack, I like to think it all started in 2002.
Humble Beginnings
Back in 2002/3, mesmerised by successful side-channel attacks on internet encryption protocols, I decided to build a tool for systematic research and validation of some of these attacks. The result was an analytic toolkit for timing and power analysis of security chips.
I remember sleepless nights trying to get the tool measure, instead of burning the chips, desperation, and an eventual success.
SCSAT04 - a 2nd generation of the side-channel analysis tool
At the time I thought that just the timing attack has been a bit low-level, easy to defend against, and we really needed to combine it with other types of attacks power / glitch attacks. The SCSAT tools were designed to generate microsecond, high voltage peaks on power, clock, and data pins of chips. This was coupled with up to 200Mps, 12bit samples with microsecond trigger. The goal was to induce computational errors without triggering protection mechanisms of the high-security chips we were looking at.
The 1st generation of the tool in use
The main memory of mine is of long hours of relentless work and it’s absolutely amazing that what we have started many years ago has been turned into absolutely fascinating results by Petr Svenda and his team.
By: Dan Cvrcek, founder of KeyChest.