Category Archives: Reverse engineering

Breaching the Samsung S9 Keystore

Posted on by
Reply

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:

  1. Never reuse an IV with a streamcipher.  Do not trust the user to generate a new IV, do it yourself.
  2. A Trusted Execution Environment does not protect from a weak/wicked “trusted” application. 
  3. 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

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.

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.

Meltdown and Spectre

Posted on by
1

On January 2018, security researchers disclosed two attacks coined Meltdown and Spectre. These attacks bypass the memory isolation of modern CPU by exploiting side-channel attacks on hardware-based optimization features of these CPUs. Thus, Meltdown and Spectre can gain arbitrary access to confidential information in the memory of the computer.

Modern CPUs, so-called superscalar computers, do not execute anymore the instructions sequentially. They implement many hardware-based optimization techniques that modify the normal instruction flow. For instance, the CPU executes multiple instructions concurrently to keep the processor’s sub-units as busy as possible (See Eben Upton’s post). Thus, out-of-order execution speculatively executes instructions further down the instruction flow as soon as all needed resources are available. Thus, the CPU may execute an instruction before it is sure that the instruction is needed. If later the CPU determines the instruction was not needed, it discards the corresponding results from its registers. This mechanism is sound architecturally but not at the microarchitecture level. The cache memory still holds the discarded results. Unfortunately, for many years, security researchers have designed side-channel attacks that leak confidential information from the cache. Modern CPUs’ branch predictors attempt to guess the future control flow and, execute the instructions of the predicted instruction flow preemptively. If the predicted decision is wrong, the CPU discards the “results” of the speculative instructions if the prediction was incorrect. Once more, this mechanism is sound architecturally. Unfortunately, the results remain in the cache memory. Covert-side-channel cache attacks can retrieve them.

The attacks

The goal of Meltdown is to dump the kernel memory space from a user-space process. In a simplified explanation, Meltdown operates in two steps. During the first step, Meltdown entices the CPU to access the kernel space through out-of-order instructions. When the instruction flow reaches this execution point, it detects the violation and triggers an exception handling that blocks actual access to the kernel space. During the second step, Meltdown uses covert-channel cache attacks to retrieve the cached “inaccessible” data. Intel memory management maps privileged kernel memory in the user-space. Thus, kernel memory becomes accessible. The usual security assumption is that kernel memory is secure and not accessible on a computer without root access. Meltdown breaks the hardware-enforced isolation between kernel space and user-space.

Meltdown may affect any CPU using out-of-order mechanism and is OS-independent. Meltdown has been successfully tested on Intel x86, Intel XEON processors, and ARM Cortex A57. Meltdown was mounted on cloud containers, such as Docker, successfully. The software countermeasures use KAISER. KAISER is a software patch that prevents the mapping of kernel memory into the user space, thus thwarting Meltdown. The KAISER patch is available for Windows 10, Linux, MacOS and iOS.

The goal of Spectre is to reach information from another process. Spectre exploits branch prediction and speculative execution. It operates in three steps. During the first step, Spectre mistrains the branch predictor by repeatedly executing a given branching. During the second step, Spectre entices the branch predictor to mispredict the control flow. The CPU then executes the speculative code that should perform the “illegal” operations, such as reading unauthorized memory. As in Meltdown, the third step exfiltrates the cached data using a covert-channel cache attack. Spectre accesses from a given user-space the memory of another user-space. Spectre breaks the hardware-enforced isolation between processes.

Spectre has been successfully implemented on recent Intel processors, AMD Ryzen, AMD FX, and AMD PRO. Spectre was implemented on Windows and Linux-based OS. It was written in C and also in JavaScript. The countermeasure would be to halt predictive execution on sensitive execution paths. This is a difficult task as the current instruction set is not fit for that purpose. The alternative solution is to implement in the code mechanisms that reduce the impact of the leaked information (for instance, combining conditional select and conditional move. In other words, developers must be aware of the covert-channel cache attack and implement adequate countermeasures. Compilers may also implement some tricks.

As Spectre can be mounted with JavasScript, malicious adware may become the first exploits using Spectre in the field. Thus, browsers are receiving patches to mitigate the risk. The exploitability via JavaScript is worrying.

Google’s Project Zero released concurrently three vulnerabilities, coined variant 1 to 3. These three vulnerabilities are identical to Meltdown and Spectre. Variant 1 and 2 correspond to Spectre whereas variant 3 maps to Meltdown.

Conclusion

Meltdown and Spectre are not due to bugs. They are the consequences of a new breed of side-channel attacks exploiting information leaking at the microarchitectural level for speed optimization.

It is interesting to notice that Paul Kocher is one of the researchers disclosing Meltdown and Spectre. In 1996, Paul designed the first side channel attack. His attack disrupted the security of smart cards. Since 1996, side-channel attacks have been among the most prolific, complex fields of research in security.

We want/need the CPUs to be faster. Thus, silicon designer added these optimization features to go faster. Unfortunately, most trivial countermeasures would defeat the benefit. For instance, cache attacks may be defeated by randomizing or equalizing the access time, which would annihilate the purpose of the cache. New hardware architecture, as well as new instruction sets, will help to defend. Nevertheless, we have a new class of side channel attacks to take into account. No doubts that variants will soon flourish.

White box cryptography: an open challenge

Posted on by
2

The ideal implementation of a cryptographic algorithm would be such that even if the attacker would have the source code and would entirely control the platform, she would not be able to retrieve the secret key. In 2002, Stanley Chow and his colleagues proposed a new concept coined the white-box cryptography. The threat model of white-box attack assumes that the attacker has full access to the encryption software and entirely controls the execution platform. White-box cryptography attempts to protect the keys even under such a hostile threat model. The main idea is to create a functionally equivalent implementation of the encryption or decryption algorithm that uses only look-up tables. Corresponding look-up tables, with the corresponding hard-coded secret key, replace the S-boxes, Feistel boxes and XOR functions usually employed by symmetric cryptography. Then, the look-up tables are further randomized. In theory, the randomization hides the hard-coded key. White box cryptography is a difficult challenge for skilled reverse engineers.

Abundant cryptographic analysis has demonstrated that these constructions are not theoretically secure. Nevertheless, well-crafted real implementations may resist reverse engineering. Many vendors offer such white-box cryptography for AES. The issue is how do you know whether an implementation is robust. Securing white-box cryptography is a lot of black magic. Currently, the only solutions are either reverse-engineer it yourself or trust your supplier blindly.

Fortunately, the European-funded research project ECRYPT launches an exciting challenge: The WhiBox contest. It is a capture the flag challenge dedicated to white-box cryptography. Developers are encouraged to post AES-128 white-box implementation as a C source code. Attackers are invited to break the challenge, i.e., extract the encryption key.

The contest starts on May 15 and ends August 31. The winners, i.e., the implementation that resisted the longest, and the attacker who broke the “strongest” implementation, during the rump session of CHES 2017.

This initiative is interesting. It will be a benchmark of state of the art in this obscure field. Of course, it will have value only if enough skilled attackers will answer the challenge. I expect some success. It reminds the challenges to evaluate oracle attacks for digital video watermarking (BOWS and BOWS2). BOWS demonstrated the risk associated with the access to a watermark detector.

We will follow this challenge. Will commercial solutions dare to submit implementations? Winning this challenge would be a feather in their hat.

 

Reference:

    Chow, S., Eisen, P., Johnson, H., Oorschot, P.C. van: A White-Box DES Implementation for DRM Applications. In: Feigenbaum, J. (ed.) Digital Rights Management. pp. 1–15. Springer Berlin Heidelberg (2003).

An insight in Knox

Posted on by
Reply

Samsung provides for its Galaxy devices an enterprise mobile security solution Knox. Among the features, Knox offers Workspace that compartments the mobile device in two spaces: user space and Knox space. Of course, the Knox space is running in a TrustZone™ and executes only authenticated trusted applications. There is not much public information about the actual implementation of Knox.

Uri Kanonov and Avishai Wool have lifted a part of the veil by reverse engineering Knox 1.0. Their paper provides an interesting in-depth description of some secure mechanisms such a compartmentalization (based on SELinux) or encryption file system. They also disclose some vulnerabilities. The last section describes some enhancements available in Knox 2.3 as well as some remaining issues.

An interesting element of the paper is the list of lessons:

  • Component reuse is welcome, provided a proper protection for the added attack surface.
  • Protect the software code of secure components
  • Validating the application authorized to run in the Trust Zone is key for security
  • Hardware Root of Trust should be at the root of any secure container system
  • Avoid resource sharing; it increases the attack surface.
  • Check the integrity of the secure container periodically; only checking at boot time is insufficient.

If you want to learn more about Knox, this paper is a good reading.

Kanonov, Uri, and Avishai Wool. “Secure Containers in Android: The Samsung KNOX Case Study.” arXiv, May 27, 2016. http://arxiv.org/abs/1605.08567.

Attackers are smart

Posted on by
Reply

In 2010, Steven MURDOCH, Ross ANDERSON, and their team disclosed a weakness in the EMV protocol. Most Credit / Debit card equipped with a chip use the EMV (Europay, MasterCard, Visa) protocol. The vulnerability enabled to bypass the authentication phase for a given category of transactions. The card does not condition transaction authorization on successful cardholder verification. At the time of disclosure, Ross’s team created a Proof Of Concept using an FPGA. The device was bulky. Thus, some people minored the criticality.

The team of David NACCACHE recently published an interesting paper disclosing an exemplary work on a real attack exploiting this vulnerability: “when organized crime applies academic results.” The team performed a non-destructive forensic analysis of forged smart cards that exploited this weakness. The attacker combined in a plastic smart card the chip of a stolen EMV card (in green on the picture) and an other smart card chip FUN. The FUN chip acted like a man in the middle attack. It intercepted the communication between the Point of Sales (PoS) and the actual EMV chip. The FUN chip filtered out the VerifyPIN commands. The EMV card did not verify the PIN and thus was not blocked in case of the presentation of wrong PINs. On the other side, the FUN chip acknowledged the PIN for the PoS which continues the fraudulent transaction.

Meanwhile, the PoS have been updated to prevent this attack.

This paper is an excellent example of forensics analysis as well as responsible disclosure. The paper was published after the problem was solved in the field. It discloses an example of a new potential class of attacks: Chip in The Middle.

Law 1: Attackers will always find their way. Moreover, they even read academic publications and use them.