An android bug was observed in Google’s Android smartphones, using the Titan M chip through the Android Keystore API for AES-GCM in a specific way lead to predictable and bogus ciphertext.
Android Keystore, StrongBox and the Titan M chip are the key components that leads to this bug’s discovery. The Android Keystore is a system service that allows apps to securely generate and use cryptographic keys. While apps can use the keys they generated, they cannot extract them, as they never enter the process of the app. The idea behind this, is that even if the process of the app is compromised, the key is not.
An Android Keystore implementation that falls under the latter category is referred to as a StrongBox Keymaster, and the Titan M chip is one of them. To take advantage of it in an Android app on Pixel devices, one has to indicate a preference for StrongBox during key generation. By simply calling setIsStrongBoxBacked(true) on the KeyGenerator instance, apps that use the Android Keystore get more secure storage for their cryptographic keys, with no apparent downsides.
A 2FA app for Android, Aegis Authenticator was researched upon to disclose this bug to the globe. The app stores the OTP secrets in an encrypted file (referred to as the vault). The master key used to encrypt/decrypt the vault is managed by a key slot system that’s very similar to LUKS. Aegis has the concept of two types of key slots: for a password and for biometric authentication. The biometric key slot encrypts the master key with a key stored in the Android Keystore, so that the master key can later be decrypted after successful biometric authentication by the user.
The key generation code generates a 256-bit key, to be used with AES in GCM mode, for encryption and decryption. User authentication is required for this key, so that it can only be used after biometric authentication by the user., while switching it t strongbox the app showed an error dialog. Decryption of the key slot fails, because apparently verification of the MAC failed.
The app sits in a loop, repeatedly encrypts/decrypts some hard coded plaintext and prints the results to the log. As shown in the screenshots above, user authentication, the timeout between tries and some other things are configurable in the options dialog. While we can’t see what going on inside the HSM, this gives us a good look at the behavior we can see on the outside. Looking at the log, it turns out that this bug causes cryptographic operations to produce predictable and bogus ciphertext:
Image Source: Alexbakkr
Note the ciphertext of the second iteration: 0dd0adde0dd0adde0dd0adde0dd0adde585301005d. That doesn’t look as random as one would expect. In fact’s, there’s even a sequence that repeats: 0dd0adde.
No matter how many times this is repeated, the resulting ciphertext is always the same (while the nonce is always different, even). Now it’s obvious why decryption failed in Aegis before. Trying to decrypt bogus ciphertext like that will certainly result in a MAC verification failure and bogus plaintext. The most dangerous thing about this, is the fact that it fails so spectacularly without throwing an exception. This also completely defeats one of the most important guarantees that symmetric ciphers provide: ciphertext that is indistinguishable from random noise.
At Qualys Labs, we’ve tried to resolve the issue, reported for CVE-2019-9465.
Google’s Pixel Android smartphones that come with the Titan M security chip on board.
Qualys customers can scan their network with QID(s)# 610051 to detect vulnerable assets. Kindly continue to follow on Qualys Threat Protection for more coverage on vulnerabilities.
References & Sources: