Cybersecurity News & Commentary - March 2019

The Source Port is Georgia Tech's monthly cybersecurity newsletter, featuring commentary from its researchers about topics in the news over the past month, what wasn't written between the lines, the big (and sometimes nagging) questions driving our research, and new projects underway.

March, 2019


Google Researchers Release Cryptography Scheme for Resource-Constrained Devices​

Researchers from Google have released a new cryptographic construct called Adiantum.  Specifically designed for inexpensive, resource-constrained devices such as entry-level phones and IoT devices, Adiantum allows an entire device to be encrypted with a five-fold performance boost over comparable constructs.  With a reference implementation released under a permissive license and a proof of security based on reasonable assumptions, Adiantum promises to be a technology that enables more widespread security in an increasingly computerized world of small things.

IISP Analyst Joel OdomI like this story not only because of the practical aspect of introducing readers to a new technology with great promise for the growing number of small devices on the global market, but also because it gives us a good chance to consider how cryptography works in the real world.

In cybersecurity courses that I've taught in the past, I've often explained that saying that encryption is secure because it uses the popular AES block cipher is like saying that a deck is well-built because it uses the highest quality ring shank nails available on the market.  While high-quality parts may be a requirement for a high-quality end product, they alone do not guarantee that your deck will withstand a strong gust of wind.  The design and implementation of your deck (or your crypto scheme) matter equally as much as the parts themselves.

Cryptographers use building blocks called cryptographic primitives to build cryptographic schemes.  The cryptographic primitives used in Adiantum include AES, ChaCha (a stream cipher), and a keyed hash based on other hash functions.  The diagram on the page that I've linked to shows how Adiantum combines these primitives to encrypt a 4,096-byte sector of persistent storage.  Because the scheme is specifically designed to be easy to implement in software, devices don't need specialized hardware to encrypt and decrypt, saving CPU cycles, battery power, and cost.

Modern cryptography relies on proofs of security to show that, if certain reasonable (and hopefully minimal) assumptions for a scheme hold true, then the expected difficulty to break the scheme (for some formal definition of break) can be proven to meet some threshold.  Adiantum has proofs of security based on the security of the underlying AES block cipher and the ChaCha stream cipher.

It is not clear to me whether or not Adiantum itself provides strong integrity protection, or if this has to be an added feature of the way the scheme is used.  Typically, integrity protection requires a way for the receiver of a message to know for sure whether or not the message is genuine by examining some small piece of metadata known as a tag.  Some ciphers have this type of integrity protection built in, but I don't see this for Adiantum.  I'd like any reader to correct me or help me to understand how the Adiantum implementation provides this important feature!  Perhaps it's simply not part of the security model for the way that Adiantum is intended to be used.




SGX Malware

Researchers at the Graz University of Technology have demonstrated the ability to load robust malware into the secure enclaves of Intel’s Software Guard Extensions (SGX) [1]. SGX enclaves are intended to protect software and data from a malicious host platform or operating system by making the data unreachable from the outside. Since its announcement, researchers have speculated about the impact of malware residing in an SGX enclave because the operating system or anti-virus software would not be able to detect or stop the malware. Before this work, it was mostly thought that malware would not use SGX enclaves because the ability of enclave code to affect the rest of the system would be limited. Now researchers have bypassed these limitations. Malware loaded onto an SGX enclave has been able to perform the same tasks as a normal malicious application. 

IISP Analyst Kennon BittickSince SGX was first announced, researchers have been concerned about the potential impact of malware in SGX enclaves. Because the host, including anti-virus software and the operating system, cannot access or tamper with enclave memory, any malware in the enclave could run without oversight or remediation. However, it was originally thought that this potential was mitigated by the fact that code running in the enclave must exit the enclave to execute system calls. Although it is unlikely that this was intended as a security feature, it was a nice side effect that may have prevented malware authors from targeting SGX.

The researchers demonstrated the ability to use an unrelated feature of modern Intel processors (transactional memory support) to scan memory outside of the software and execute arbitrary code, including system calls, using a variant of Return Oriented Programming (ROP) that the authors call SGX-ROP [2]. This allowed malware to execute any functions that normal malware could execute, all without the malware code leaving the enclave.

This research shows a great example of how even a well-implemented, good idea can have unintended consequences in a complicated system. The SGX technology is intended to for use in a “high-assurance security use case that needs to safely store secrets or protect data” [3]. Intel suggests use cases for SGX like managing private information and protecting endpoint security systems. These goals are certainly worth pursuing and can add security and protection in a variety of applications, but because SGX can combine in an unexpected way with transactional memory, a security concern is created.

The attack also brings to mind the Spectre attacks on processors, which similarly rely on unrelated inference and timing attacks to leak information from the processor. The core novel element of this research is using transactional memory extensions to leak metadata about the address space. These attacks demonstrate that it can be difficult to predict how components of a complex system will interact, especially given the presence of indirect inference attacks.