Attestation & Hardcoded Secrets (Android+ iOS): Best Practises, Know, Tests, Demos - #3756
Attestation & Hardcoded Secrets (Android+ iOS): Best Practises, Know, Tests, Demos#3756Diolor wants to merge 59 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds Android-focused guidance around Key Attestation by introducing new Knowledge pages (generic Key Attestation plus device/app-attestation-focused pages) and a new Best Practice that recommends using server-verified, hardware-backed attestation for integrity decisions.
Changes:
- Moves/reworks the existing Key Attestation Knowledge content into
MASVS-RESILIENCEand expands it with certificate-chain and field interpretation details. - Adds two new Knowledge pages for device attestation (
rootOfTrust) and application attestation (attestationApplicationId). - Adds a new Android Best Practice describing a server-driven attestation flow and verification checks; updates related Storage Knowledge pages to reference the new Key Attestation KNOW.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 9 comments.
Show a summary per file
| File | Description |
|---|---|
| knowledge/android/MASVS-STORAGE/MASTG-KNOW-0047.md | Updates wording around using Key Attestation to verify keys are hardware-backed. |
| knowledge/android/MASVS-STORAGE/MASTG-KNOW-0045.md | Adds an explicit cross-reference to the Key Attestation Knowledge page. |
| knowledge/android/MASVS-STORAGE/MASTG-KNOW-0044.md | Removes the old Storage-category Key Attestation Knowledge page content (relocated). |
| knowledge/android/MASVS-RESILIENCE/MASTG-KNOW-0044.md | Adds the new Resilience-category Key Attestation Knowledge page with updated structure and references. |
| knowledge/android/MASVS-RESILIENCE/MASTG-KNOW-01kw.md | Adds a new Knowledge page focused on device attestation fields (root of trust). |
| knowledge/android/MASVS-RESILIENCE/MASTG-KNOW-02kw.md | Adds a new Knowledge page focused on application attestation fields (application ID). |
| best-practices/MASTG-BEST-00be.md | Adds a new Best Practice recommending hardware-backed key attestation for device/app integrity. |
| For a reference implementation, see [Dionysis Lorentzos' Android-Security sample](https://github.com/Diolor/Android-Security/blob/main/app/src/main/java/dio/security/crypto/KeyManager.kt#L45-L70). | ||
|
|
||
| ## Reading the X.509 Certificate | ||
|
|
||
| The returned [X509Certificate](https://developer.android.com/reference/kotlin/java/security/cert/X509Certificate) chain from [`KeyStore.getCertificateChain(alias)`](https://developer.android.com/reference/kotlin/java/security/KeyStore#getcertificatechain) can be inspected to determine the key properties. X.509 certificates are described by [ASN.1 format](https://source.android.com/docs/security/features/keystore/attestation#tbscertificate-sequence) and the Android-specific extensions (certificate's payload) can be requested with OID `1.3.6.1.4.1.11129.2.1.17`. This attestation extension content is described by the [ASN.1 schema KeyDescription](https://source.android.com/docs/security/features/keystore/attestation#schema). | ||
|
|
||
| For a sample decoding functionality of X.509 certificate's payload, you may consult [Dionysis Lorentzos' - Simple attestation converter](https://github.com/Diolor/Android-Security/blob/main/app/src/main/java/dio/security/crypto/attestation/Attestation.kt#L34-L64). |
There was a problem hiding this comment.
This Knowledge page links to non-official, personal GitHub repositories as “reference implementations”. Knowledge pages are expected to rely on official documentation/standards; consider replacing these with official sources (Android docs, AOSP, or Google-maintained samples) or move third-party samples to DEMO/tooling content.
There was a problem hiding this comment.
I could copy the sample code here however the reader might lose context
39b2e27 to
7d8ccdb
Compare
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
7d8ccdb to
aed967d
Compare
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Move attestation-focused TEST-0x01 here from the file-integrity branch. Pairs with existing MASTG-KNOW-0x02 (DeviceCheck) and MASTG-KNOW-0x03 (App Attest). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Rename Android key-attestation test MASTG-TEST-0342 -> MASTG-TEST-0x01 (resolves duplicate ID with iOS NETWORK MASTG-TEST-0342) and update MASTG-DEMO-0x01 to reference it. - Rename iOS App Attest test MASTG-TEST-0x01 -> MASTG-TEST-0x02. Android (original) attestation under 0x01, iOS (new) under 0x02. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Placeholder demo md only (no r2 or sample files), paired with MASTG-TEST-0x02. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
| @@ -0,0 +1,74 @@ | |||
| --- | |||
| title: Use Hardware-Backed Key Attestation for Device and App Integrity | |||
There was a problem hiding this comment.
After merge MASWE-0006 should reference this
| @@ -0,0 +1,73 @@ | |||
| --- | |||
| title: Mitigate the Risk of API Keys Hardcoded in the App Package | |||
There was a problem hiding this comment.
After merge MASWE-0006 should reference this
…device attestation in MASTG-BEST-0x02 and MASTG-KNOW-0044, and clarify DeviceCheck and App Attest functionalities in related documents.
…n MASTG-BEST-0x01 and mark MASTG-DEMO-0x01 as a failing test case
…ficate verification, including updates on root certificate management, revocation checks, and validity period enforcement. Add new section on attestation key provisioning methods and their implications.
… detection rules and test case
…pp attestation APIs and their integrity verification processes
…raction steps and evaluation criteria
…Challenge, emphasizing the importance of certificate chain retrieval for attestation. Update documentation to reflect manual correlation of key generation and certificate chain retrieval.
… for readability.
This PR closes #3505 and #3767
Description
A backend cannot trust anything a mobile client claims about itself. Attestation is how it gets cryptographic evidence instead, and it is the precondition for every other client-side control: certificate pinning and RASP only mean something once the app binary and the device are known to be genuine.
MASTG had the pieces but not the guidance. Key attestation was a single storage-oriented KNOW, device and app attestation were placeholders, App Attest and DeviceCheck were conflated in a platform overview, and nothing said what a server should actually verify. Hardcoded API keys — the most common reason a client holds a secret it cannot protect — had no test at all, and the honest mitigation for them is attestation, so the two belong in one PR.
What
BEST-0x01) and iOS App Attest (BEST-0x03), plus mitigations for keys that must ship in the package (BEST-0x02).TEST-0x01/0x02), device attestation (TEST-0x05, first coverage of MASWE-0054), hardcoded secrets (TEST-0x03/0x04).KNOW-0135, now pointing at the new knowledge entries.Known gap
No best practice covers the Play Integrity API itself.
BEST-0x01recommends it as the starting point but only documents the manual Key Attestation path, and the nonce guidance that used to live inKNOW-0035was removed with the rewrite. Worth a follow-up.TODO:
AI Tool Disclosure
This contribution includes AI-generated content.
AI tools used: Claude Code
Models and versions: Claude Opus 5
Prompt summary: Grammar, feedback and reading cohesion throughout. Later used to review the branch for gaps and broken cross-references, to draft
TEST-0x05and the device-attestation demo, and to build and verify the demos against a local emulator and simulator.