White box cryptography: an open challenge

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

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

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.

RowHammer: A powerful new attack

In 2014, a group of researchers from Carnegie Mellon University and Intel published a new kind of disturbance attack on DRAM: rowHammer [1]. At the difference of SRAM (static), DRAM (dynamic) need regular refreshing to keep their memory. DRAM are organized by rows. Indeed, when reading or writing to an address, the circuit access the full row rather than only one specific cell. Cells are susceptible to inter-cell crosstalk (like any electronic elements). The researchers discovered the fast, repetitive reading of two rows they could generate a high rate of disturbances that produce errors in the memory. The actual code to produce errors is simple and short. It is a simple loop that reads two addresses, flushes the registers and the instruction cache. A typical 1 million iterations takes less than one second. The code does not need to be root. They tested 129 different DDR3 DRAM commercial modules. They induced errors in 110 modules.

Thus, they demonstrate that with simple software, it was possible to wreck DRAM memory.

This month, Google researchers went one step further. They used the rowHammer technique to create actual fault injection. On a standard x86-64 bit machine, they demonstrated two exploits [2].

  • Native Client (NACl) is a sandboxing system that allows only a limited subset of instructions. They were able to have ‘blacklisted’ instructions to execute in the NACl environment.
  • They succeeded to escalate the privilege to Kernel privilege on a standard Linux.

Of course, these exploits have some limitations. The escalation was done only on a Linux machine without some sandboxing mechanisms. Nevertheless, they highlight that rowHammer may become a powerful fault injection tool. The interesting part of rowHammer is that it is purely software.

Currently, they have only experimented rowHammer on standard DRAM commercial modules. This may be an interesting way to bypass some trusted execution environment that isolate the DRAM space.

DRAM for servers should be more resistant to rowHammer as Error Correction is embedded in the chip. Nevertheless, error correction can only correct a limited amount of simultaneous errors. It may be possible perhaps to also overflow the correction. If rowHammer would be possible on DRAM for servers, then it may be a potential interesting attack vector in the public cloud. The attacker may either bypass the sandbox or impair the memory of another user of the same server.

We may see in coming months more studies and exploits around rowHammer. Will it have the same impact than side channel attacks? To be surveyed…

The two papers are worthwhile to read. Read them in the chronological order.

[1]    Y. Kim, R. Daly, J. Kim, C. Fallin, J. H. Lee, D. Lee, C. Wilkerson, K. Lai, and O. Mutlu, “Flipping bits in memory without accessing them: An experimental study of DRAM disturbance errors,” in Proceeding of the 41st annual international symposium on Computer architecture, 2014, pp. 361–372.

[2]    C. Evans, “Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges,” Project Zero, 09-Mar-2015.

 

Lenovo, Superfish, Komodia: a Man In The Middle story

Lenovo has made this week the headlines with the alleged malware: superfish.   Lenovo delivered  some PCx loaded with “bloatware” Superfish.  Superfish provides solution that performs visual search.  Seemingly, Superfish designed a software that allowed to place contextual ads on the web browsing experience.   To perform this highjacking, superfish uses a software stack from Komodia:  SSL Digestor.  According to the site of Komodia:

Our advanced SSL hijacker SDK is a brand new technology that allows you to access data that was encrypted using SSL and perform on the fly SSL decryption. The hijacker uses Komodia’s Redirector platform to allow you easy access to the data and the ability to modify, redirect, block, and record the data without triggering the target browser’s certification warning.

How does Komodia do the decryption without triggering the certificate validation of the browser?   The CERT has disclosed on Thursday the trick with its vulnerability note VU#529496.

Komodia Redirector with SSL Digestor installs non-unique root CA certificates and private keys, making systems broadly vulnerable to HTTPS spoofing

Komodia install stealthily its own root certificate within the browsers’ CA repository.   The stack holds its private key. This allows to ‘self-sign’ certificate to forge SSL connection.  The software then generates a typical Man In The Middle.   Despite the private key was encrypted, it was possible to extract some corresponding private keys (easy to guess the password; komodia).  This means that as long as the root key is not erased from browsers’ repository, an attacker may use the corresponding private key.  The attacker may sign malware that would be accepted by the machine, and generate phony certificates for phishing.   In other words, other principals than Superfish may use the hack for infecting Lenovo computers.

Lenovo provided a patch that removed the Superfish application.   Unfortunately, the patch does not erase the malicious certificate.  Microsoft provided such patch, and Mozilla should soon revoke it.

This is a perfect example of supply chain attack. The main difference is that the supplier voluntarily infected its product.    Do never forget law 4: Trust No One.

PS:  at the time of writing, the Komodia site was down, allegedly for a DOS.  It may also be because too many people try to visit the site.

Does your TV set watch you?

Benjamin Michele and Andrew Karpow presented a scary Proof of Concept  using two Samsung Smart TVs.  They used the integrated media player of these Smart TV set.  For the most recent one, they discovered that the TV set used a 2011 version of the open source FFMPEG’s libavformat library. This library identifies the type of content to be played and demux it before the content is transmitted to Samsung’s proprietary media player.  The libavformat library supports many containers.  It is a complex piece of software, and as such as many new discovered bugs. By scanning the bug-tracking database of this open source library, the researchers selected one vulnerability that was not patched in the version used by the TV set.  This vulnerability allowed them to execute arbitrary code when playing a forged content.  As the player executes in root shell, the forged payload also executes in root shell.  This means that the payload has full access to the platform.  As the Smart TV had an integrated camera and microphone, they wrote an exploit that captured the video of the camera and the sound from the microphone.  The captured information can then be sent to a remote server.  As the payload is encapsulated in a real movie, the consumer is not aware that his TV set is being infected and that he is spied.  The researchers found a way to flash the Smart TV set and thus make the infection permanent.

Of course, the payload could do other things.  The researchers could perform a thorough analysis of the TV set because they succeeded to get root access, and thus could explore the system and easily work on the exploit. The target were Samsung TV sets.  Most probably, any other smart TV of any brand could be attacked in a similar way but using another vulnerability.

This POC highlights several interesting points:

  • This exploit highlights an important issue of IoT.  Will devices in the field be upgraded and securely patched?  There are two issues that are not yet solved:
    • Will manufacturers do the security maintenance for the lifetime of the product?   Currently, the business model is to sell one device and not maintain it (unless there is a very serious bug that impact the behaviour).  How could the manufacturer finance this maintenance?  In the software world, maintenance is financed by either new version or maintenance contract for professional expensive applications.  This is not the case in the consumer domain.
    • Will consumers apply the patch?  The likelihood is low if we extrapolate from the computer world. Too many consumers’ computers are not patched.
  • The wide use of open source libraries has brought some benefits.  It is less expensive for companies and it is claimed to be more secure.  Unfortunately, it also has its downside.
    • This last claim is only true if all systems would be patched.  If it is not the case, then the use of widely deployed open source libraries may be an advantage for the attackers.  The attacker can experiment on his own system before trying on the targeted device.
    • Furthermore, the more a ‘common’ library is deployed, the more targets will be hit whenever a vulnerability is found in this library.  Heartbleed is a good illustration.
  • The more features a device has, the higher the risk to have vulnerabilities.

Reference:

Michele, Benjamin, and Andrew Karpow. “Watch and Be Watched:  Compromising All Smart TV Generations.” In Proc. of the 11th Consumer Communications and Networking Conference (CCNC). Las Vegas, NV, USA: IEEE, 2014.