Establish device trustworthiness via attestation and TPM2.0’s role

Android PlayIntergity API helps you check that service requests are coming from your genuine app binary running on a genuine Android device verified by Google Play Services.

Use case example: Android bitcoin wallet app on Google Playstore with backend
service accessing blockchain network.

Threat model:     
1. Device where wallet app is installed, might be compromised
or rooted.  Wallet transations can be tampered or replayed or forged etc.

As illustrated by following diagrams, after user app requests an integrity verdict, the Play Integrity API provides an encrypted response token, which contains Integrity Verdict, confidential and integrity protected from user app’s read and tampering. App server needs talk to Google Play server for decrypting before checking plain-text integrity verdict if satisfying provisioned security policies, then app server will decide if completes requested service and return results to the user app.

How to prevent the measurement reports(attestation token) on app binary and android device from being forged by malicious actor when user app calls Play Integrity API?

Attesting environment (RTM — root of trust for measurement) not shown in following diagram is the key entity on Android device to provide above security property, where measurement reports will be signed by attestation key endorsed cryptographically by device manufacturer within hardware backed secure enclave.

Android PlayIntegrity framework covers fundamental entities and interactions among them for typical remote attestation process and its security assurance. Among them, highlight as below before proceeding to TPM (trusted platform module) based attestation and what roles TPM can play in various security models to provide different security guarantee.

1. Attestion target (App binary and Android device's authenticity), where measurements
will be collected.
2. Attesting environment (Trusted Execution Environment), where measurement
operations will be performed and cryptographically integity protected.
1) 2) above are part of device.

3) Service provider (app server backend) providing trusted service as per app's requests.
4) Trusted authority (Google Play Server in above diagram knowing good state
   of all genuine device and sofware identities.)

Next few paragraphs will be deep diving into TPM2.0 and some of its interesting user models, assorted technical intricacies.

Overview of TPM2.0’s stack, APIs and capabilities (diagram worth thousand of words!)

Highlight of one major difference from TPM1.x (Crypto Agility and key hierarchies)

1. TPM2.0 provides crypto-agility via various Key Deriving Function(KDF) and three types of secret persistent seeds (EPS, PPS and SPS) decoupling from hardcoded cipher algorithms as in TPM1.x TCG specification. Entropy source — random seeds will be used to deterministically generate requested keys with different KDFs, which can in turn identify the TPM module.
2. TPM2.0 provides key hierarchy for different functionalities (endorsement, storage, platform). For privacy, EK is restricted not for signing operations and can only perform decrypting operations and key attestation .

As shown in following key hierarchy, from SPS seed to SRK, it’s a deterministic process via KDF (SPS seed, template with unique personalized data provided by caller.) . For other parent key to child key, various key deriving process can be requested:

• Child key = KDF( seed value in parent object’s sensitive part, template with personalization data).
• Protected object stored outside of TPM’s shielded location (eg. external storage) uses wrapping key and HMAC key to protect child key’s sensitive data’s confidentiality and integrity.

Topics to be discussed in upcoming blogs:

1. TPM2.0 Anonymous remote attestation process ( how secure connected device attests its athenticity to service provider without sharing its PII to service provider? )
2. Local attestation use cases ( verify software integrity measurement via PCR value against golden references stored on TPM shielded location before releasing secrets or performing requested security/privacy sensitive operations. )
3. TPM2.0 use as keystore and its threat model (FIPS 140–2 physical security and CC EVAL3/4+): physical attack, tamper and side channel (DPA or timing analysis) requirements.
4. TPM2.0 entropy source — TRNG and various persistent Seeds. How random or unpredictable are they (SP800–90A DRNG)? Choose between TPM generated keys or generate from external HSM then import/duplicate into TPM for cryptographical operations? Any cyber industry standard TCG TPM2 enforces or recommends?
5. TPM2’s design goal focuses on hardware physical enhanced security (tamper resistant, side-channel attack resistant, and TRNG hardware entropy, hardware enforced attestation & authorization), not acceleration and performance (secure element grade RISC MCU and not DMA capable).
6. Integrated TPM(on same silicon die as part of SoC) as part of platform level root of trust (RoT) SP800–193(platform firmware resiliency). What about non-integrated external TMP module’s relationship with platform RoT (eg. SoC boot-ROM plus on-die manufacturer provisioned FUSE parameters.)? What about physical attack on hardware board’s TPM module, physically remove and replace with compromised/malicious cloned TPM module?