Repository navigation
Conversation
…SILIENCE Pure move with no content changes so the rewrite in the next commit shows as a real diff. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Split out of OWASP#3756. Covers hardware-backed Key Attestation and Play Integrity: server-side verification guidance (MASTG-BEST-0x01), the reworked Key Attestation knowledge with device and app attestation pages filled in, app and device attestation tests (MASTG-TEST-0x01, MASTG-TEST-0x05) and three semgrep-backed demos. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Diolor
commented
Sep 17, 2026
| - **`signatureDigests` do not match**: The SHA-256 digests of the app's signing certificates differ from the legitimate app's known digests at the time of release. This is the primary indicator that the APK has been repackaged or signed with a different key (e.g., a malicious clone or a patched version of the app). | ||
| - **`version` is below the minimum acceptable version**: The app version recorded at key generation time is too old, indicating a version with known vulnerabilities or one that predates a security-relevant update. | ||
|
|
||
| ## Enforce Key Properties |
Collaborator
Author
There was a problem hiding this comment.
so that I don't forget: add a session to align app risk with device security and patch level
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR closes #3505
Description
Split out of #3756, which mixed attestation and hardcoded secrets across both platforms. This is the Android attestation part and stands on its own.
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. MASTG had the pieces but not the guidance: Key Attestation was a single storage-oriented knowledge page, the device and app attestation pages were placeholders, and nothing said what a server should actually verify.
MASTG-BEST-0x01: server-side verification of hardware-backed Key Attestation (challenge freshness, chain and revocation checks,rootOfTrustandattestationApplicationIdevaluation, key properties, failure handling). Play Integrity is presented as the default starting point.MASTG-KNOW-0044(Key Attestation) reworked and moved to MASVS-RESILIENCE. The move is its own commit so the rewrite shows as a real diff.MASTG-KNOW-0119/0120placeholders filled in;MASTG-KNOW-0035(Play Integrity) andMASTG-KNOW-0118(RASP) cleaned up and cross-linked.MASTG-TEST-0x01(app attestation, MASWE-0056) andMASTG-TEST-0x05(device attestation, MASWE-0054, first coverage).MASTG-DEMO-0x01/0x03(key attestation without and with a server-issued challenge) and0x07(retrieving device integrity signals), each with a semgrep rule and generated output. Run on an emulator; the decompiled Java matches a real build.Fake IDs are kept as they were in #3756 so the three split PRs stay collision-free when stacked and earlier review comments still map.
Siblings: #3954 (iOS attestation, independent of this one) and #3955 (hardcoded secrets, stacked on both). The cross-link from
MASTG-KNOW-0035to Firebase App Check lives in the stacked PR because that knowledge page is introduced in the iOS one.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
Check exactly one option.
If AI tools were used to generate or substantially modify code or text, complete the following.
TEST-0x05and the device-attestation demo, to build and verify the demos against a local emulator, and finally to split Attestation & Hardcoded Secrets (Android+ iOS): Best Practises, Know, Tests, Demos #3756 into three PRs and run a content quality pass over the result.Undisclosed use of AI tools will result in the PR being closed. Large rewrites or bulk changes generated by AI require explicit prior approval from the maintainers. Learn more in "Use of AI tools in contributions".
Contributor Checklist
Relevant documentation.
Contributors are expected to understand basic git and GitHub workflows, including forks, branches, commits, and pull requests. The project does not provide training. Pull requests that do not meet these minimum requirements may be closed without review.
🤖 Generated with Claude Code