Post-quantum cryptography encompasses the algorithms that are allegedly immune to quantum computing. In 2017, NIST initiated the process of selecting and standardizing a set of post-quantum cryptosystems. In 2020, NIST started the third round with 15 remaining candidates.
“Among its advantages are comparatively small encryption keys that two parties can exchange easily, as well as its speed of operation. ”
CRYSTALS-DILITHIUM, Falcon, and SPHINCS+ are the new digital signature systems.
“ Reviewers noted the high efficiency of the first two, and NIST recommends CRYSTALS-Dilithium as the primary algorithm, with FALCON for applications that need smaller signatures than Dilithium can provide. The third, SPHINCS+, is somewhat larger and slower than the other two, but it is valuable as a backup for one chief reason: It is based on a different math approach than all three of NIST’s other selections.”
Interestingly, version 9.0 of OpenSSH proposes a post-quantum algorithm. It is NTRU prime and not CRYSTALS-KYBER.
For several years, cryptography has studied the implication of the rise of quantum computation. Once fully operational, with enough qubits, error-free, and keeping quantum states long enough, quantum computing will break prime number factor-based cryptosystems (such as RSA) and Elliptic Curve Cryptography by quickly finding the private keys.
Thus, in 2017, NIST initiated selecting and standardizing a set of post-quantum cryptosystems.
OpenSSH just released version 9.0. And it adds the support of a post-quantum cryptosystem. To be precise:
Quoting
use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default (“sntrup761x25519-sha512@openssh.com”). The NTRU algorithm is believed to resist attacks enabled by future quantum computers and is paired with the X25519 ECDH key exchange (the previous default) as a backstop against any weaknesses in NTRU Prime that may be discovered in the future. The combination ensures that the hybrid exchange offers at least as good security as the status quo.
NTRU Prime is one of the nine remaining candidates in the NIST selection process. OpenSSH chose one without waiting for the NIST final selection.
Intel announced that the next generations of CPUs (11th and 12th) will no longer support the SGX technology (see data sheet). SGX is the secure enclave in Intel CPU. The SGX isolates the program and data in its environment from the insecure Rich Execution Environment (REE). Thus SGX-based applications could act as a Root of Trust.
At least, this was the promise. Unfortunately, starting with Spectre-like attacks, SGX was under the fire of many interesting exploits (for instance, VoltPillager). Thus, it seems that in its current form, SGX cannot be a trusted secure enclave.
For most consumers, the main consequence is that future PCs will not support any more UHD Blu-ray. Indeed, the content protection standard AACS2 mandates a Secure Execution Environment with a Hardware Root of Trust (HRoT). For Microsoft Windows, the solution was the use of SGX. Some applications were also basing their security model on SGX. They will have to find an alternative that is not necessarily available. TPM offers a valid HRoT but not a Secure Execution Environment. Current tamper-resistant software and obfuscation technologies may not be sufficient.
Most Android devices implement an Android Hardware-backed Keystore. The Rich Execution Environment (REE) applications, i.e., the unsecure ones, use a hardware root of trust and an application in the Trusted Execution Environment (TEE). Usually, as all the cryptographic operations occur only in the trusted part, these keys should be safe.
Three researchers from the Tel-Aviv university demonstrated that it is not necessarily the case. ARM’s TrustZone is one of the most used TEEs. Each vendor must write its own Trusted Application (TA) that executes in the TrustZone for its key store. The researchers reverse-engineered the Samsung implementation for S8, S9, S20, and S21. They succeeded in breaching the keys protected by the key store.
The breach is not due to a vulnerability in TrustZone. It is due to design errors in the TA.
When REE requests to generate a new key, the TA returns a wrapped key, i.e., a key encrypted with a key stored in the root of trust. In a simplified explanation, the wrapped key is the newly generated key AES-CGM-encrypted with an IV provided by the REE application and a Hardware-Derived Key (HDK) derived from some information supplied by the REE application and the hardware root of trust key.
In other words, the REE application provides the IV and some data that generate the HDK. AES-CGM is a stream cipher (uses AES CTR), and thus it is sensitive to IV reuse. With a streamcipher, you must never reuse an IV with the same key. Else, it is easy to retrieve the encrypted message with a known ciphertext. In this case, the attacker has access to the IV used to encrypt the wrapped key and can provide the same `seed` for generating the HDK. Game over!
In S20 and S21, the key derivation function adds some randomness for each new HDK. The attacker cannot anymore generate the same HDK. Unfortunately, the S20 andS21 TA contains the old derivation function. The researchers found a way to downgrade to the S9 HDK. Once more, game over!
Lessons:
Never reuse an IV with a streamcipher. Do not trust the user to generate a new IV, do it yourself.
A Trusted Execution Environment does not protect from a weak/wicked “trusted” application.
If not necessary, remove all unused software from the implementation. You reduce the attack surface.
Reference
A. Shakevsky, E. Ronen, and A. Wool, “Trust Dies in Darkness: Shedding Light on Samsung’s TrustZone Keymaster Design,” 208, 2022. Available: http://eprint.iacr.org/2022/208
Last week, I attended Black Hat 2021. It was a hybrid conference, i.e., both on-site and virtual. As a consequence, there were only four concurrent “physical’ talks at any moment. The number of attendees was far lower than in 2019. I attended the physical ones exclusively with a focus on hacking.
I enjoyed the most the two following talks
Breaking the Isolation: Cross-Account AWS Vulnerabilities by Shir Tamari and Ami Luttwak They explored the AWS cross services such as CloudTrail or the Serverless Repository. Such services allow to store some data in the same location for several services or read data from the same location for several services. They discovered that the security policy configuration did not define the referenced accounts. Thus, it was possible to use CloudTrail to store files in an S3 bucket that you did not control. AWS has fixed the issue. Unfortunately, it is up to the customer to update the policies correspondingly; else, the holes are still present. Fixing a Memory Forensics Blind Spot: Linux Kernel Tracing by Andrew Case and Golden Richard The ePBF is a programming language that makes access to the Linux kernel tracing easy. The tracing system is mighty. It allows to read registers, hook subsystem calls, etc. From the userland!! Powerful but nasty. They presented some extensions of their open-source tools to list the hooked calls and other stealthy operations. I was not aware of ePBF. It opened my eyes and scared me. An earlier talk With Friends Like eBPF, Who Needs Enemies? The authors presented a rootkit based on ePBF. Unfortunately, I did not attend this talk. Would I have known ePBF, I would have attended it. It seems that there were three other ePBF-based talks at DefCon 2021.
In the coming weeks, I will listen to some virtual talks and report the ones I enjoyed.
I must confess that I discovered this little conference only this year. It is highly specialized in hardware security. A conference truly for expert audience. Thus, I am glad to promote the conference Call For Paper for Hardwear.ioUSA 2021 is OPEN!
If you have a groundbreaking embedded research or an awesome open-source tool you’d like to showcase before the global hardware security community, this is your chance. Send in your ideas on various hardware subjects, including but not limited to Chips, Processors, ICS/SCADA, Telecom, Protocols & Cryptography.
Two French security researchers, Victor Lomne and Thomas Roche, published in January an impressive 55-page report. The report describes a successful Electro-Magnetic side-channel attack on Google’s Titan security key. They succeeded in extracting the ECDSA private key.
Titan security key is a FIDO U2F compliant key also known as Google authenticator. It is functionally similar to Yubikeys. Its purpose is to serve as a physical token for Two-Factor Authentication (2FA).
Mounting side-channel attacks on secure components like smart cards is “common.” It usually assumes the attacker has samples to analyze and that the attacker can store arbitrary known secrets in the samples. This knowledge provides some reference points during the attack. Once the attack is fine-tuned with the samples using a known secret, it is possible to extract the target’s secret. Unfortunately, this is not true in this specific use case. When registering, the token generates its ECDSA key pair. The private key never leaves the token. It is why it is not possible to back up such tokens. Thus, it is possible to purchase Titan tokens, but not to feed an arbitrary key pair. The researchers used an interesting methodology to overcome this issue.
They first identified the secure component used by Titan. They removed the plastic cover and identified NXP A7005. They found out that some JavaCards have similar characteristics to the NXP A7005. Thus, they used JavaCards using NXP P5x chips.
Using a 500µm coil with 10µm precision micromanipulators, they measured the EM signature of the ECDSA signing for both Titan and the JavaCard. The comparison of the two EM signatures confirmed that they used the same implementation. Thus, they concentrated their effort on the Javacard to design the exploit. They reverse-engineered the implementation using the EM traces to guess the calculations. They discovered a sensitive leakage and could mount a complex side-channel attack. The document details the complexity of the attack. With 4,000 sampled signatures for 2TB of data, they succeeded in extracting the key that they fed to the smart card.
Then, they implemented the same attack on the Titan chip. They increased the number of samples to 6,000 for 3TB of data. They succeeded in extracting the private key.
How devastating is this attack?
The specialized equipment is about 10K€ (about $12K). The needed skill set is high. On the Common Criteria (CC) scale, it has a rating of 27 corresponding to attackers with moderate attack potential. The corresponding chips are old and are not any more covered by CC certificates.
The attack requires the attacker to get the Titan key for several hours to collect the 6,000 samples. It is not possible to clone it.
The attack requires opening the plastic casing. The operation seems destructive. For stealthiness, the attacker must be able to repackage the chip in a legitimate case.
The attacker needs to return the “borrowed” recased key to the legitimate owner. Else this owner may detect the loss and block the access.
This attack impacts not only the Titan token but a long list of components.
Thus, we may forecast that such attack would be efficient only against very high-profile targets.
Conclusions
The attack is an impressive piece of work. Reading the document gives an overview of the issues a side-channel attack requires to solve. It is extremely interesting.
Diversity of implementation across different products is a costly but secure option.
Continue to use your 2FA tokens. It is more secure than not using them. If you lost your 2FA token, change your accounts to use a new one as soon as possible (which should be the case, independently of this attack).
