TPM—Fail TPM meets Timing and Lattice Attacks
> We discovered timing leakage on Intel firmware-based TPM (fTPM) as well as in STMicroelectronics’ TPM chip. Both exhibit secret-dependent execution times during cryptographic signature generation. While the key should remain safely inside the TPM hardware, we show how this information allows an attacker to recover 256-bit private keys from digital signature schemes based on elliptic curves.
> This research shows that even rigorous testing as required by Common Criteria certification is not flawless and may miss attacks that have explicitly been checked for. The STMicroelectronics TPM chip is Common Criteria certified at EAL4+ for the TPM protection profiles and FIPS 140-2 certified at level 2, while the Intel TPM is certified according to FIPS 140-2. However, the certification has failed to protect the product against an attack that is considered by the protection profile.
> Rolling forward 15 years, isogeny-based cryptography is another area with many technical subtleties, but is moving into the mainstream of cryptography. Once again, not everything that can be done with discrete logarithms can necessarily be done with isogenies. It is therefore not surprising to find papers that have issues with their security.
> It is probably time for an Isogenies for Cryptographers paper, but I don’t have time to write it. Instead, in this blog post I will mention several recent examples of incorrect papers. My hope is that these examples are instructional and will help prevent future mistakes. My intention is not to bring shame upon the authors.
'Mario Maker 2' Creators Are Using Cryptography to Make Impossible Levels
> A strange competition has popped up to create levels with audacious passcodes that you could spend a lifetime trying to guess.
Real-world measurements of structured-lattices and supersingular isogenies in TLS
> This is the third in a series of posts about running experiments on post-quantum confidentiality in TLS. The first detailed experiments that measured the estimated network overhead of three families of post-quantum key exchanges. The second detailed the choices behind a specific structured-lattice scheme. This one gives details of a full, end-to-end measurement of that scheme and a supersingular isogeny scheme, SIKE/p434. This was done in collaboration with Cloudflare, who integrated Microsoft’s SIKE code into BoringSSL for the tests, and ran the server-side of the experiment.
> Because optimised assembly implementations are labour-intensive to write, they were only available/written for AArch64 and x86-64. Because SIKE is computationally expensive, it wasn’t feasible to enable it without an assembly implementation, thus only AArch64 and x86-64 clients were included in the experiment and ARMv7 and x86 clients did not contribute to the results even if they were assigned to one of the experiment groups.
Minerva: Lattice attacks strike again
> This page describes our discovery of a group of side-channel vulnerabilities in implementations of ECDSA/EdDSA in programmable smart cards and cryptographic software libraries. Our attack allows for practical recovery of the long-term private key. We have found implementations which leak the bit-length of the scalar during scalar multiplication on an elliptic curve. This leakage might seem minuscule as the bit-length presents a very small amount of information present in the scalar. However, in the case of ECDSA/EdDSA signature generation, the leaked bit-length of the random nonce is enough for full recovery of the private key used after observing a few hundreds to a few thousands of signatures on known messages, due to the application of lattice techniques.
Looking back at the Snowden revelations
> It’s no coincidence that this is a cryptography blog, which means that I’m not concerned with the same things as the general public. That is, I’m not terribly interested in debating the value of whistleblower laws (for some of that, see this excellent Twitter thread by Jake Williams). Instead, when it comes to Snowden’s leaks, I think the question we should be asking ourselves is very different. Namely:
> What did the Snowden leaks tell us about modern surveillance capabilities? And what did we learn about our ability to defend against them?
Chromebook U2F ECDSA vulnerability
> We discovered a vulnerability in the H1 security chip firmware concerning ECDSA signature generation. The firmware code used incompatible transfer instructions when passing a critical secret value to the cryptographic hardware block, resulting in generating secret values of a specific structure and having a significant loss of entropy in the secret value (64 bits instead of 256 bits). We confirmed that the incorrect generation of the secret value allows it to be recovered, which in turn allows the the underlying ECC private key to be obtained. Thus, attackers that have a single pair of signature and signed data can effectively compute the private key, breaking any functionality or protocols that use the key pair in question.
Experimental feature, with an annoying fix. If it had been for real, quite messy.
The Enigma Machine
> The Enigma Machine was one of the centerpoints of World War II, and its cryptanalysis was one of the stepping stones from breaking codes as an art to cryptography as a science. The machine encrypted messages sent between parts of the German army – operators would type a key on its keyboard, the machine would scramble that, and a letter would light up on the top.
> This notebook simulates an Enigma Machine and visualizes how it works. The Enigma Machine is an especially neat thing to visualize because it was electromechanical. As you used it, it moved. Instead of circuit traces, it had beautiful real wires connecting its pieces.
Cache Attacks on CTR_DRBG
> This post presents results from our paper “Pseudorandom Black Swans: Cache Attacks on CTR_DRBG”. We illustrate how omissions in the threat model of a U.S government’s standard lead to a practical, end-to-end attack on the most popular generator contained within.
The Matasano Crypto Challenges (review)
If you don’t have time for the challenges themselves, reading this review a few times until the lessons are internalized may be a good substitute.
> How practical these attacks were. A lot of stuff that I knew was weak in principle (like re-using a nonce or using a timestamp as a ‘random’ seed) turns out to be crackable within seconds by an art major writing crappy Python.
> We present an attack on the encryption key negotiation protocol of Bluetooth BR/EDR. The attack allows a third party, without knowledge of any secret material (such as link and encryption keys), to make two (or more) victims agree on an encryption key with only 1 byte (8 bits) of entropy. Such low entropy enables the attacker to easily brute force the negotiated encryption keys, decrypt the eavesdropped ciphertext, and inject valid encrypted messages (in real-time). The attack is stealthy because the encryption key negotiation is transparent to the Bluetooth users. The attack is standard-compliant because all Bluetooth BR/EDR versions require to support encryption keys with entropy between 1 and 16 bytes and do not secure the key negotiation protocol. As a result, the attacker completely breaks Bluetooth BR/EDR security without being detected. We call our attack Key Negotiation Of Bluetooth (KNOB) attack.
Better Encrypted Group Chat
> End-to-end encrypted group messaging is also a hard problem to solve. Existing solutions such as Signal, WhatsApp, and iMessage have inherent problems with scaling, which I’ll discuss in detail, that make it infeasible to conduct group chats of more than a few hundred people. The Message Layer Security (MLS) protocol aims to make end-to-end encrypted group chat more efficient while still providing security guarantees like forward secrecy and post-compromise security.
> The primary contribution of molasses has been in detecting errors in the specification and other implementations through unit and interoperability testing. Molasses implements most of MLS draft 6. Why not all of draft 6? There was an error in the spec that made it impossible for members to be added to any group. This broke all the unit tests that create non-trivial groups. Errors like this are hard to catch just by reading the spec; they require some amount of automated digging. Once they are found, the necessary revisions tend to be pretty obvious, and they are swiftly incorporated into the subsequent draft.
Nice work and a very nice explanation of the protocol.
Dragonblood new results
> August 2019 — During our initial disclosure, the Wi-Fi Alliance privately created security recommendations to mitigate our attacks. In these recommendations, they claim that Brainpool curves are safe to use, at least if products securely implement Dragonfly’s quadratic residue test (i.e. it must be implemented without side-channel leaks). However, we found that using Brainpool curves introduces a second class of side-channel leaks in the Dragonfly handshake of WPA3. In other words, even if the advice of the Wi-Fi Alliance is followed, implementations remain at risk of attacks. This demonstrates that implementing Dragonfly and WPA3 without side-channel leaks is surprisingly hard. It also, once again, shows that privately creating security recommendations and standards is at best irresponsible and at worst inept.
That last line.
Four reasons why cryptography is so hard to get right and four solutions
> Before proceeding, I want to stress that everything I refer to here relates to mistakes made when using (good) cryptographic libraries. The challenge of implementing the low-level cryptographic primitives themselves (like AES, RSA, ECC and so on) is a very different one, requiring high cryptographic engineering experience and knowledge. As such, this should be avoided whenever possible. In contrast, many software engineers need to just use cryptography in their work, and this cannot be avoided. Unfortunately, even this turns out to be far more problematic than expected.
This rings very true. The recommended solution, use a better library instead of lower level pieces, is also good, but should probably give some names. libsodium for example.
> RSA is an intrinsically fragile cryptosystem containing countless foot-guns which the average software engineer cannot be expected to avoid. Weak parameters can be difficult, if not impossible, to check, and its poor performance compels developers to take risky shortcuts. Even worse, padding oracle attacks remain rampant 20 years after they were discovered. While it may be theoretically possible to implement RSA correctly, decades of devastating attacks have proven that such a feat may be unachievable in practice.
Hello World, and OpenPGP Is Broken
> This is the inaugural issue of Cryptography Dispatches, meant to be quick, frequent and lightly edited discussions of cryptographic topics. Longer form can be found at blog.filippo.io.
> For my first round, I am writing about the recent attack on the PGP keyservers. The overall goal of the newsletter is to explain cryptography rather than to comment on the news, so we will cover context and mechanics, not the last minute updates. Issues about Ristretto, Ed25519 in Go, AES-GCM-SIV, and OPRF based contact discovery are still coming as promised!
How does Apple (privately) find your offline devices?
> A big caveat: much of this could be totally wrong. I’ll update it relentlessly when Apple tells us more.
> Since this is a security system, the first question you should ask is: who’s the bad guy? The answer in this setting is unfortunate: everyone is potentially a bad guy. That’s what makes this problem so exciting.
Using Ed25519 Signing Keys For Encryption
> First, we need to understand the difference between Ed25519 and X25519. For that I recommend Montgomery curves and their arithmetic by Craig Costello and Benjamin Smith, which is where I learned most of the underlying mechanics of Montgomery curves. The high level summary is that the twisted Edwards curve used by Ed25519 and the Montgomery curve used by X25519 are birationally equivalent: you can convert points from one to the other, and they behave the same way.
age - A simple file encryption tool & format
> This is a design for a simple file encryption CLI tool, Go library, and format. It’s meant to replace the use of gpg for encrypting files, backups, streams, etc. It’s going to be called “age”, which might be an acronym for Actually Good Encryption.