I would like to thank Vicky & Stathis for all the kind help they gave me for this thesis, Geralt, and also my academic friends who helped me through the semesters. Last but not least, I would like to thank the fellow students who not only did not help my team through the projects, but "just took care of them". This thesis is prepared in such a way that anyone – with basic Android and security knowledge – can understand the issues surrounding the key storage module in Android OS called Android Keystore.
Most use cases are investigated – regarding the application of Android Keystore – on AVDs (Android Virtual Devices), but a physical machine (Nexus 5) is also included, with or without TEE (Trusted Execution Environment), for Android versions 5 , 6 and 7. The reader becomes familiar with the topics that this thesis explores, mainly the security of Android Apps. In the second chapter, the security background is analyzed so that the reader can understand this thesis.
Introduction
Foreword
- What is Android (1)?
- What is computer security and how important is it in the 21th century?
- Mobile Platform Security
Looking at the numbers, we realize how important security can be for smartphones and device owners. Due to the dual purpose use of USB charging ports, many devices have been susceptible to data extortion or the installation of malware on a mobile device using malicious charging kiosks placed in public places or hidden in common charging adapters (5). SMS and MMS attacks were unleashed, in December 2012 the Eurograbber SMS Trojan intercepted SMS messages on Android phones containing Transaction Authentication Numbers (TANs), including Stagefright5, a group of software bugs affecting versions 2.2 ("Froyo") and newer than the Android operating system.
3 while plugged into the audio output jacks of the vulnerable smartphones and effectively spoofed audio input to inject commands via the audio interface6. For example, each mobile device can transmit information related to the owner of the mobile phone contract and an attacker may want to steal the identity of the owner of a smartphone in order to commit other crimes. This has also led companies to create awareness among their employers, but also among the users of the smartphones and mobile applications.
Subject of Thesis
4 There are two main subjects of this thesis, secure computing and secure key storage (SKS). In contrast to the term Key Management, a KMS is tailored for specific use cases such as secure software updates or machine-to-machine communication. In a holistic approach, it covers all aspects of security - from secure key generation to secure key exchange to secure handling and storage of keys at the client.
SKS, the functionalities provided by CKMS and other aspects of a secure execution environment provided within a device make "Secure Computing". A commonly used solution for secure computing and secure key storage is Secure Element. As ARM states on their website7, Arm TrustZone technology is a system-on-chip (SoC) and CPU approach to system-wide security.
Chapter Reference
Background
Cryptography
- Symmetric Cryptography
- Asymmetric Cryptography
If you use a private key for encryption, you must use the public key from the pair for decryption. The only way for someone to read the message is to use Alice's private key, which was created together with the public key as a key pair that only Alice must have (otherwise anyone can read the message). The CA holds the public key of both, and when Bob and Alice need to communicate, they exchange their certificates, which are essentially their public keys and IDs encrypted with the CA's private key.
By knowing CA's public key, Bob can decrypt the certificate and verify whether the key belongs to Alice or not. He then sends the signature along with the message and the recipient, Alice, then decrypts the encrypted hash (signature) with Bob's public key and compares it with the hash of the message. We use the private key for signature generation and the public key for signature verification.
Trusted Execution Environment
- ARM TrustZone®
Some of the interfaces to communicate with the user can be used from both the secure and non-secure worlds. This means that the normal world cannot access the memory used by the safe world. This is indicated by the NS -bit (Non-Secure-bit) in the processor's Secure Configuration Register (SCR).
System software running in the secure world can access devices hidden from the normal world. A secure world OS should handle both context switches (between trusted worlds and between secure and normal worlds). In principle, there are no restrictions on the complexity and functionality of a safe world operating system operating in a safe world.
Android
Android Keystore
APIs for Key storage
The best known are the Bouncy Castle keystore, which is a cryptographic library for Java and C#, and the official Android Keystore. Manufacturers can develop drivers for their hardware that communicate with the KeyStore service, providing hardware-based secure key storage. For this reason, Android developers have created a software-based KeyMaster trustlet that runs in TEE.
Hardware-based: Qualcomm has built a closed-source key manager into TEE and the Android driver. Note that while AndroidKeyStore versions are called software and hardware, all solutions are of course software and hardware based. By software-based and hardware-based, we mean that hardware-based or software-only security features are used to protect the keystore.
The Spongy Castle library uses this to interact with Bouncy Castle's key store type. When you create an instance of the Bouncy Castle keystore, the Spongy Castle type is defined as the provider. Note that not all combinations of providers and key store types are supported, some key store types do not support providers at all.
This may be the case for key store types that only provide an interface to manage the keys but do not provide the actual key material. An example of this is the AndroidKeyStore keystore type which can perform its cryptographic operations outside of application process on other hardware. In contrast to the KeyStore class, the KeyChain class interacts with the user using a graphical interface.
IsKeyAlgorithmSupported (string algorithm) can be used to test if the device supports a particular algorithm.
Methodology
- Criteria
- Evaluation
Experiment
Android KeyStore test using TEE on Qualcomm devices
- Evaluation in Android 5.0
- Evaluation in Android 6.0.1
- Evaluation in Android 7.1.2
For example, the following image shows how we copy the key files of the legitimate keystore_app to the rogue_app. Encrypted Private Exponent: Stores the private exponent of the RSA key pair in encrypted form using AES-CBC-128 encryption. Encrypted private exponent size: stores the actual private exponent size in unencrypted form.
The key used to encrypt the private exponent and to calculate the HMAC cannot be found on the device. After that, all we have to do is copy the files of the legitimate app with the UID of the rogue app (10089) as we can see in the figure below. After this step we run the rogue patch and we can see that the key entry of the legitimate app is read (algorithm used, subject, validity period) but also a signature validation.
As we can see in Figure 16, the entire module of the RSA key can be exported on the display. After that, all we have to do is copy the files of the legitimate app with the UID of the rogue app (10085) as we can see in the figure below. We can again see the algorithm, subject and validity period of the key pair and also the module of RSA, but not all.
After that, we need to copy the files of the legitimate application with the UID of the rogue application (10085), as we can see in the figure below. If we run the rogue application, we can again see the algorithm, the subject and the validity period of the key pair and also the modulus of RSA, but not completely. The system again does not allow the full extraction of the modulus in the screen.
Also when we try to export the private exponent of the key pair, we get the same Android 6 exception.
Android KeyStore using software-based Keymaster
- Evaluation in Android 5.0
- Evaluation in Android 6.0
- Evaluation in Android 7.0
Future Work & Conclusions
8 For this reason, the private key is tied to the owner's identity by a trusted third party, a Certificate Authority (CA). One of the most important hardware features of the TrustZone technology is the security bit on the communication bus (18). Another aspect of the TrustZone hardware is the separation of the two worlds in the processor itself.
Access to those virtual resources may be restricted depending on the security status of the processor. The normal world is active (not secure bit is set), the OS running on the platform can access only a subset of the physical resources. When such a switch occurs due to SMC instructions or exceptions, the safe world monitoring mode is activated.
Monitor mode ensures that the state of the world it leaves is saved and. However, hardware features such as the inability of the normal world to access the secure world's memory allow this functionality to be implemented. However, all contents of the (emulated) SD card can be read and modified via USB.
This alias is defined inside the application and creates the key with what is used to identify the key pair. Also for Android version 5 we will try to parse the private key of the keyblob exported from the device. Now we run the rogue patch and we can see that the key entry of the legitimate app is being read (algorithm used, subject, validity period) but also a signature validation.
The next step is to try exporting the private key outside the device again. Then we need to copy the files of the legitimate app with the UID of the rogue app (10064), as we can see in the image below, and also change the ownership. Then we run the rogue app and we can see that it reads the key input from the legitimate app (algorithm used, subject, validity period), but also a validation of the signature.
45 Then we need to copy the files of the legitimate app with the UID of the rogue app (10081), as we can see in the image above, and also change the ownership. We use the rogue app and we can see that the key input from the legitimate app is read (algorithm used, subject, validity period), but also a validation of the signature.