Removing Secrets from Android's TLS

Abstract

Abstract-Cryptographic libraries that implement Transport Layer Security (TLS) have a responsibility to delete cryptographic keys once they're no longer in use. Any key that's left in memory can potentially be recovered through the actions of an attacker, up to and including the physical capture and forensic analysis of a device's memory. This paper describes an analysis of the TLS library stack used in recent Android distributions, combining a C language core (BoringSSL) with multiple layers of Java code (Conscrypt, OkHttp, and Java Secure Sockets). We first conducted a black-box analysis of virtual machine images, allowing us to discover keys that might remain recoverable. After identifying several such keys, we subsequently pinpointed undesirable interactions across these layers, where the higherlevel use of BoringSSL's reference counting features, from Java code, prevented BoringSSL from cleaning up its keys. This interaction poses a threat to all Android applications built on standard HTTPS libraries, exposing master secrets to memory disclosure attacks. We found all versions we investigated from Android 4 to the latest Android 8 are vulnerable, showing that this problem has been long overlooked. The Android Chrome application is proven to be particularly problematic. We suggest modest changes to the Android codebase to mitigate these issues, and have reported these to Google to help them patch the vulnerability in future Android systems.

Total Recall: Persistence of Passwords in Android

“…Obviously, these credentials and keys must also be deleted in a timely manner. We previously looked at SSL/TLS session key retention [34], discovering a number of issues similar to what we have found with password retention in this study.…”

“…Although Android apps are commonly written in Java, they may make native calls to underlying C libraries included by the app or installed natively on the system. For example, the Android TLS implementation wraps a Java layer (Conscrypt) atop the BoringSSL cryptographic library written in C. If passwords are copied from the Java layer to the C layer, there is also a possibility for the data to be retained in the C layer [34].…”

“…We installed and launched each app, and manually entered passwords for authentication. After this, we performed a full physical memory dump [56] as well as a per-process dump [34]. Our simple "black-box" approach does not make any assumption about the apps.…”

“…Researchers have developed many solutions to address this. Chow et al handle this by secure deallocation [14], Pridgen et al aim at reducing encryption keys retained in the Java heap for desktops and servers [49], Dunn et al use ephemeral channels where data will be securely erased after a session finishes [18], and Lee and Wallach study the retention of TLS secrets in Android memory [34]. Different from existing work, our paper focuses on the study of password retention, and proposes effective fixes to address this problem.…”

“…Each of the steps in this chain may inadvertently retain passwords for longer than necessary. Last but not least, previous studies have found that Android apps fall short in performing secure deallocation [57], and that they may retain TLS key materials in memory [34].…”