CFP Hardwear.io

Posted on by
Reply

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.io USA 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.

CFP is open: 15 March – 15 May 2021

Notification of acceptance: 25 May 2021

Conference: July 9-10, 2021

✅  SUBMIT your research: https://bit.ly/3eEC9UE

The fall of Titans?

Posted on by
Reply

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).

Use 2FA tokens as much as possible.

Reference

Lomne, Victor, and Thomas Roche. “A Side Journey to Titan.” NinjaLab, January 7, 2021. https://ninjalab.io/wp-content/uploads/2021/01/a_side_journey_to_titan.pdf.

VoltPillager: a new attack on SGX

Posted on by
Reply

In the past, several voltage-based fault injection attacks on Intel SGX were successful.  The attacks used software commands to control the voltage of the CPU.  Intel’s mitigation was to disable the access to these commands at the BIOS level.

A team of researchers from the University of Birmingham succeeded in performing the same type of attacks but via external hardware, therefore bypassing the mitigation.  They coined the attack: VoltPillager [1].

On the motherboard, the CPU controls its voltage by sending commands to a programmable Voltage Controller using an undocumented three-wire serial bus: Software Voltage Identification (SVID).  The bus is somewhat similar to I2C.  The researchers reverse-engineered its protocol.  SVID has no protection.  Furthermore, the bus uses open-drain outputs; thus, it is “easy” to piggy-back on SVID.  Open-drain outputs require resistors to pull the signal to `1’; therefore, the connection is accessible easily and can use jumpers or soldering. 

They used a $20 Teensy 4.0 microcontroller [2].  To synchronize the Teensy microcontroller’s commands with the target’s CPU activity, the team used an RS232 UART rather than the USB port.  RS232 has minimal jitter compared to USB enabling a more accurate synchronization.  Time accuracy is critical in fault injection attacks.  The VoltPillager hardware allows issuing commands that program the shape of the undervolting waveform accurately.  Hardware-driven undervolting is more precise and accurate than equivalent software-driven fault-injection attacks.

They succeeded in reproducing the exploits disclosed by the Plundervolt attack [3]. Due to its increased accuracy, VoltPillager requested 50 times fewer iterations than Plundervolt.  Furthermore, the team discovered a new class of attacks.  It seems that undervolting briefly delays memory writes to the cache.  This potential delay opens many opportunities for cache attacks.

The bad news is that VoltPillager bypasses the mitigation introduced by Intel against the Plundervolt-like attacks.  VoltPillager attacks the Voltage Controller directly.  As explained in the paper, protecting the bus would not solve the issue because a determined attacker could directly drive the Pulse Wave Modulation that manages the actual voltage.  The most efficient mitigation would use techniques inspired by the smart card world, such as the hardware detector of voltage glitches or redundant critical code.

Of course, VoltPillager requests physical access to the CPU.  Intel’s answer to VoltPillager is

“… opening the case and tampering of internal hardware to compromise SGX is out of scope for SGX threat model.” 

This assumption of the threat model may be valid in many scenarios.  Unfortunately, tampering with hardware is in the scope of the content protection threat model.

A thrilling paper that reminds us that software runs on hardware and hardware is difficult to secure.

[1]          Z. Chen, G. Vasilakis, K. Murdock, E. Dean, D. Oswald, and F. Garcia, “VoltPillager: Hardware-based fault injection attacks against Intel SGX Enclaves using the SVID voltage scaling interface.” Nov. 2020, [Online]. Available: https://www.usenix.org/system/files/sec21summer_chen-zitai.pdf.

[2]          “Teensy USB Development Board.” https://www.pjrc.com/teensy/.

[3]          “Plundervolt.” https://plundervolt.com/.

NIST reduced the number of candidates for post-quantum cryptography

Posted on by
2

Post-quantum cryptography encompasses the algorithms that are allegedly immune against quantum computing. There are five categories that seem suitable for post-quantum cryptography. See previous post.
In 2017, NIST initiated the process to select and standardize a set of post-quantum cryptosystems. In 2019, the second round selected 26 candidates. The third round started in 2020. Last month, NIST published an intermediary analysis of these candidates. As a result, NIST selected seven serious candidates and eight potential but unlikely contenders. The draft standards should be available by 2024. Table 1 lists the nine candidates for encryption. The predominance of lattice-based and code-based solutions is visible. Table 2 lists the six selected candidates for digital signatures. The more likely candidates are highlighted.

Code-basedLatticeIsogeny
BIKEX
Classic McElieceX
CRYSTALS-KYBERX
FrodoKEMX
HQCX
NTRUX
NTRU primeX
SABERX
SIKEX
Table 1: NIST candidates for encryption
Hash-basedLatticeMQE
CRYSTALS-DILITHIUMX
FALCONX
GeMSSX
Picnic
Rainbow
SPHINCS+X
Table 2: NIST candidates for digital signature

Lattice seems to be the big runner for post-quantum. A future post will attempt to give a hint on lattice-based cryptography.

The report is available at https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8309.pdf

Quantum what?

Posted on by
2

Quantum what?

Quantum computing, quantum cryptography, and post-quantum cryptography: these terms are confusing.  This post attempts to clarify them and draws the relationship between them.

Quantum computing is the set of technologies that use quantum-mechanical phenomena to perform computing.  Quantum computing uses qubits rather than bits.  Where one bit of conventional computing has one of the two possible states “0” or “1”, a qubit has a set of independent states simultaneously via superposition.  Furthermore, entangled qubits behave together in non-conventional ways (for instance, immediate synchronization independent from the distance separating the two qubits).

These properties allow solving some classes of problems, many orders faster than conventional computing.  In 1994, Peter Shor published “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer” [1].  His algorithm solves the prime factorization and discrete logarithm hard problems.  Prime factorization is the foundation of cryptosystems such as Diffie Hellman (DH) and RSA.  Discrete logarithms are the foundation of elliptic curve cryptosystems (ECC). In 1996, Lov Grover published “A fast quantum mechanical algorithm for database search” [2].  His algorithm inverts one-way functions in  time.  It applies to symmetric ciphers and cryptographic hashes.

Whenever quantum computing is operational, accurate, and with enough qubits, these algorithms and their enhancements will impact traditional cryptography.  To mitigate Grover’s algorithm, the size of symmetric keys and hashes has to increase.  For instance, AES will need at least 256-bit keys. Shor’s algorithm annihilates the security of prime factorization or discrete logarithm-based cryptosystems.  In other words, DH, RSA, and ECC will not be secure anymore.

Post-quantum cryptography encompasses the algorithms that are allegedly immune against quantum computing.   There are mainly four categories of algorithms.

  • Hash-based signatures; It uses the current hash algorithms, and its security is well understood. The size of the public key is far larger and usable only once. 
  • Code-based encryption;  It uses sophisticated error-correcting codes.  The McEliece’s scheme was first proposed in 1978 [3] and has not been broken since. 
  • Lattice-based encryption is the most efficient and promising solution.  It allows encryption, digital signatures, and fully homomorphic encryption.
  • Multi-variate Quadratic Equations seem the less promising path.  All proposed schemes are currently broken. 

It is wise to strengthen post-quantum cryptography to be ready whenever this threat is active.  NIST estimates that a 1 billion $ quantum computer may break RSA 2048 keys in a matter of hours.   A future post will explore more in detail post-quantum cryptography.

Quantum cryptography or Quantum Key Distribution (QKD) sends over information, including a secret key, using photons over a line between Alice and Bob.  Once Bob received the secret key, Alice and Bob use it to encrypt and decrypt via traditional symmetric cryptosystems their messages.  This key distribution is very similar to many current systems.  Nevertheless, due to the Heisenberg’s principle, if Eve eavesdrops the QKD, she alters the secret key.  Thus, Alice and Bob know they are eavesdropped, offering higher security.  The obvious limitation is that it can only be used in point to point communications.  The first QKDs were designed in the 80s.

Hoping that this post shed some light, I wish you a happy new year.

References

[1]          P. W. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Comput., vol. 26, no. 5, pp. 1484–1509, Oct. 1997, doi: 10.1137/S0097539795293172.

[2]          L. K. Grover, “A fast quantum mechanical algorithm for database search,” ArXivquant-Ph9605043, Nov. 1996.

[3]          R. McEliece, “A public-key cryptosystem based on algebraic coding theory,” NASA, DSN 42-44, 1978.

My preferred papers at Black Hat 2019

Posted on by
Reply

I attended the briefings at Black Hat 2019.  All the presentations I attended were engaging.  Nevertheless, here is the feedback on my preferred ones.  The link gives access to the corresponding slid decks.

A Decade After Bleichenbacher ’06, RSA Signature Forgery Still Works (Sze Yiu Chau)

One of the mitigations to Bleichenbacher’s attack is that the exponent d should be large. Unfortunately, in some standards d is still small, typically 3.  But even with larger exponents, forgery is possible due to vulnerable software.

Forgery uses the fact that many verifiers do not check garbage, parameter lengths, and padding.

He provides a list of vulnerable libraries (that are now fixed).

Lessons:

  • Check everything. No corner cutting.
  • Parsing in security should be bulletproof.  The complexity of the structures and syntax may become an issue.  Complexity is the enemy of security.

Lessons from 3 years of crypto and blockchain audit (Jean-Philippe Aumasson)

Jean Philippe is a Kudelski Security expert. 

He provides a view of most deployed mistakes.  Most are well known.  A few ones that I liked:

  • Weak key derivation from a password. Use a real derivation function.
  • Avoid using panic if the error is not unrecoverable, else it may become a potential DoS.
  • No way to erase securely sensitive memory with garbage collection (for Instance, go)

His preferred language for crypto is Rust.

The slide deck is an excellent refresher of what not to do.  Practitioners should have a look.

Breaking Encrypted Databases: Generic Attacks on Range Queries (Marie-Sarah Lacharite)

She presented how to use access pattern leakage and volume attack leakage to guess the content of the database even if encrypted.

Independently of the provided attacks, the researcher reminded that if using a common encryption key (and same IV) with server-side encryption, it is still possible to perform a range query because the same cleartext generates the same ciphertext.  This may be a PII issue. 

There are some partial solutions to this problem:

  • Order preserving encryption solves the issue
  • Order revealing encryption is even better

Pattern leakages measure the number of returned records per request. She used PQ trees to rebuild the order of the observed answer of access pattern. For N values in the database, N log N queries were needed.

Volume leakage is easier because the attacker may just monitor the communication. For N values in the database, N2 log N of observed queries are needed.

Some possible mitigations:

  • Restricting query types
  • Dummy records
  • Dummy values

The two last solutions may introduce some accuracy issues if not filtered out.

Everybody be Cool, This is a Robbery! (Gabriel Campana, Jean-Baptiste Bédrune)

The studied the actual security of Hardware Security Modules (HSM).  HSMs are rarely studied because they are expensive and if attacked they will erase secret.

They used the PKCS11 API.

The targeted HSM used an old version of LINUX (10-year-old). Furthermore, every process runs as root, and there was NO secure boot.  Attackers used fuzzing to find 14 vulnerabilities.  Exploiting a few of them, they could get access to the private root key!

Lesson:

Hardware Tamper Resistance and controlled API are not enough.  The software should assume that the enclave has been breached and be protected correspondingly. 

Breaking Samsung’s ARM TrustZone (Maxime Peterlin, Alexandre Adamski, Joffrey Guilbon)

Samsung’s Trustzone works only on Samsung chip Exonis and not Qualcomm’s Snapdragon

The secure OS is Kinibi by Trustonics.

Once more, adversaries used a fuzzier (AFL-based)

Currently, the trustlet has no ASLR and PIE (Position Independent Executable). They used buffer overflow on the trustlet and a trusted vulnerable driver to go inside the Trustzone. From there,  they attacked mmap for accessing Kinibi.

They were able to read and write memory arbitrarily. For instance, they accessed the master key both from EL3 and from EL1.  With the master key, the attacker has access to all the secrets in the Trustzone.

Lesson:

Once more, protect code within the secure enclave.  Defense in depth is critical.

Apple’s Find My

Posted on by
Reply

Apple disclosed at the WWDC an interesting feature: “Find My.”   It will be possible to track the GPS location of your device if it is stolen or lost.  And Apple will not know this location.  Here is how it works. 

The prerequisite is that you have at least two Apple devices.   All your devices share a private key.  The trick is that instead of having one unique public key, the devices have a multitude of public keys linked to this private key.  This is possible, and there are numerous known cryptographic solutions that may fulfill this part.

The device broadcasts via Bluetooth its current public key.   The device broadcasts this beacon even while turned out.  Any Apple device nearby may catch the beacon.  Then the receiving device encrypts its current GPS location with the broadcast public key.  It sends the encrypted location as well as the cryptographic hash of the public key to Apple’s server.  Of course, the public key changes periodically.  The rotating period has not been disclosed.

If you want to locate one of your devices, you trigger the request on one of your devices.  It sends the hash of the public key to the Apple server, which returns the encrypted location.  The device has the private key and thus can decrypt the location. Et voila.

Of course, under the assumption that Apple does not have the private key, only your devices can decrypt the location.  Normally, Apple can neither get the location nor link different related public keys together.

Many questions that were not answered in the presentation.  The frequency of key rotation, is there a limited number of public keys, how to know which hash to send?  Waiting for some publications to deep dive.

The idea is interesting.  It is complex, thus subject to failures and vulnerabilities.   What would the system do if, from many locations, there is a beacon broadcasting the same public key?  Will the collection of multiple related public keys not reveal some partial information, for instance one of the exponents?