Introduction to Android Keystore and Hardware Security

The Android Keystore System provides a robust mechanism for storing cryptographic keys securely. It allows applications to generate, store, and use cryptographic keys in a way that makes them difficult to extract from the device. A cornerstone of its security model is the concept of “hardware-backed” keys. When a key is hardware-backed, its operations (generation, signing, encryption/decryption) are performed within a Secure Hardware Environment (SHE), such as a Trusted Execution Environment (TEE) like ARM TrustZone, or a dedicated Secure Element (SE).

This isolation aims to protect keys even if the Android operating system itself is compromised. The OS only receives a handle to the key, never the key material itself. This makes hardware-backed keys significantly more secure against traditional software-based attacks. However, no system is impenetrable, and hardware-backed keys, while resilient, can be vulnerable to advanced physical attacks known as side-channel attacks.

The Elusive Hardware-Backed Key

The primary appeal of hardware-backed keys lies in their non-exportability. By design, these keys should never leave the secure hardware boundary. This includes protection against rooting, debugging, and memory dumps. The Keystore system enforces this by marking keys as `KEY_ALGORITHM_AES`, `KEY_ALGORITHM_RSA`, or `KEY_ALGORITHM_EC` with properties like `User authentication required` and `StrongBox` or `TEE` enforcement.

KeyPairGenerator kpg = KeyPairGenerator.getInstance(KeyProperties.KEY_ALGORITHM_RSA, "AndroidKeyStore");kpg.initialize(new KeyGenParameterSpec.Builder("my_hardware_backed_key",    KeyProperties.PURPOSE_SIGN | KeyProperties.PURPOSE_VERIFY)    .setDigests(KeyProperties.DIGEST_SHA256)    .setSignaturePaddings(KeyProperties.SIGNATURE_PADDING_RSA_PKCS1)    .setIsStrongBoxBacked(true) // Request StrongBox-backed key    .build());KeyPair kp = kpg.generateKeyPair();

This code snippet illustrates how an application might request a StrongBox-backed RSA key. StrongBox is Google’s implementation of a dedicated security chip, offering even stronger isolation than a TEE.

Understanding Side-Channel Attacks

Side-channel attacks exploit information leaked from the physical implementation of a cryptographic system rather than weaknesses in the cryptographic algorithm itself. This leaked information can come in various forms:

• Power Consumption: Different operations (e.g., bit ‘0’ vs. bit ‘1’ processing) consume slightly different amounts of power.
• Electromagnetic Radiation: Electronic components emit electromagnetic waves during operation, which can reveal internal states.
• Timing: The time taken to perform an operation can vary based on secret data.
• Acoustic: Less common for embedded systems, but sometimes operations produce audible sounds.

For hardware-backed Android Keystore keys, power analysis and electromagnetic (EM) analysis are the most promising vectors, as they directly observe the secure hardware’s physical activity during cryptographic computations.

Focusing on Power Analysis for Keystore Extraction

Our focus here will be on a conceptual power analysis attack, specifically Differential Power Analysis (DPA) or Correlation Power Analysis (CPA), which are common techniques to extract secret keys from cryptographic modules. The core idea is to measure the instantaneous power consumption of the secure hardware component while it performs cryptographic operations using the target key.

By repeatedly performing these operations and collecting thousands or millions of power traces, statistical methods can reveal correlations between power consumption and intermediate values computed during the cryptographic algorithm. If we can correctly hypothesize these intermediate values based on a guess of a key byte (or bit), we can statistically determine the correct key bytes.

The Attack Methodology: A Step-by-Step Guide

Phase 1: Target Device Preparation and Instrumentation

The first critical step involves preparing the target Android device. This often requires physical access and potentially soldering skills.

1. Physical Disassembly: Carefully open the Android device to expose the main PCB.
2. Identify Secure Hardware: Locate the Secure Element (SE) or the SoC (System on Chip) containing the TEE/StrongBox. This might require schematics or reverse engineering the PCB layout.
3. Power Measurement Point Identification: Find a suitable point to measure the power consumption of the target secure hardware. This typically involves cutting a power trace and inserting a small shunt resistor (e.g., 1-10 Ohm) in series. The voltage drop across this resistor is proportional to the current, and thus power, consumed by the component. Alternatively, specialized probes can sometimes measure EM radiation non-invasively near the chip.
4. Device Rooting/Custom Firmware: To repeatedly trigger cryptographic operations in a controlled manner, the device usually needs to be rooted, or custom firmware loaded. This allows an attacker to run applications that invoke the hardware-backed key for signing or encryption tasks, generating a consistent power profile.

# Example adb commands for device preparation (conceptual)adb rootadb remountadb shell # Navigate to device specific directories for further investigation

Phase 2: Data Acquisition – Capturing Cryptographic Traces

Once instrumented, the next step is to collect power traces. This involves triggering a cryptographic operation and simultaneously recording the power consumption using a high-speed oscilloscope or a dedicated side-channel acquisition device.

1. Setup Trigger: Configure the oscilloscope to trigger on a specific event, such as a GPIO pin toggle controlled by the Android application or the start of the cryptographic operation itself.
2. Repeated Operations: The target Android application will repeatedly sign a known plaintext (or encrypt a known block) using the hardware-backed key. Each operation should ideally be identical, except for potential noise variations.
3. Trace Collection: For each operation, the oscilloscope captures a power trace (voltage over time). Thousands to millions of these traces are collected and stored.

// Android app snippet to repeatedly use the keyfor (int i = 0; i < NUM_TRACES; i++) {    Signature s = Signature.getInstance("SHA256withRSA/PSS", "AndroidKeyStore");    s.initSign(keyPair.getPrivate());    s.update(MESSAGE_TO_SIGN.getBytes());    byte[] signature = s.sign();    // Toggle GPIO or send marker to synchronize trace acquisition    // System.out.println("Signed iteration: " + i); // Placeholder for actual sync mechanism}

Phase 3: Data Analysis – Unveiling Key Bits

With a large dataset of power traces and corresponding plaintexts/ciphertexts, the statistical analysis begins.

1. Trace Alignment and Pre-processing: Traces are aligned to a common start point and potentially filtered to reduce noise.
2. Hypothesis and Modeling: The attacker hypothesizes how power consumption correlates with specific intermediate values of the cryptographic algorithm (e.g., the output of the S-box in AES, or a partial result in RSA). This requires knowledge of the algorithm used.
3. Differential Power Analysis (DPA) / Correlation Power Analysis (CPA):
   • DPA: Divides traces into groups based on a guess for a key byte and the resulting intermediate value. If the guess is correct, the average power traces of the groups will show a significant difference (a
     
     Android Mobile Specs & Compare Directory

     Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!

     Compare Devices Specs →