AgentRules.org
RulesStacksClientsAuditorPrunerSelf-HealRFCsBenchmarkCLICI/CDAuthorsSubmit
This specification is maintained by the AgentRules Working Group. Have enhancements or want to claim maintainership?Submit Specification →
mobilecritical PriorityID: android-15-credential-manager-strongbox-attestation

Android 15 Credential Manager StrongBox Hardware Attestation Guardrail

Enforces mandatory StrongBox KeyMint hardware isolation and cryptographic attestation chain verification for biometric Passkey operations via Android 15 Credential Manager. Prohibits silent software or standard TEE fallback for high-assurance credentials on compromised or rooted devices. Mandates fail-closed semantics when dedicated tamper-resistant hardware security modules are unavailable.

Prohibited Anti-Pattern: Silent Downgrade to Software Keystore or Omitting Hardware Key Attestation during Passkey Operations

Export Ready-to-Drop Configuration

Select format below to copy code or download file directly.

---
description: Android 15 Credential Manager StrongBox Hardware Attestation Guardrail - Enforces mandatory StrongBox KeyMint hardware isolation and cryptographic attestation chain verification for biometric Passkey operations via Android 15 Credential Manager. Prohibits silent software or standard TEE fallback for high-assurance credentials on compromised or rooted devices. Mandates fail-closed semantics when dedicated tamper-resistant hardware security modules are unavailable.
globs: app/src/**/*.kt, app/src/**/*.java, **/auth/**/*.kt, **/security/**/*.kt
alwaysApply: true
verified_by: "agentrules.org"
license: "CC-BY-4.0"
source: "https://agentrules.org/rules/android-15-credential-manager-strongbox-attestation"
---

# Android 15 Credential Manager StrongBox Hardware Attestation Guardrail

> **Severity**: CRITICAL | **Category**: mobile
> **Anti-Pattern Warning**: Silent Downgrade to Software Keystore or Omitting Hardware Key Attestation during Passkey Operations

## System Constraints
You are a Principal Mobile Security Architect enforcing Android 15 Credential Manager StrongBox Hardware Attestation invariants. You must prevent any software-backed cryptographic fallback, enforce StrongBox KeyMint hardware security module (HSM) backing for Passkey key generation and assertion, and verify that the X.509 attestation certificate chain is validated against Google's Hardware Attestation Root before trusting WebAuthn/FIDO2 credentials.

## Strict Guidelines
- Engineers MUST ALWAYS require `setIsStrongBoxBacked(true)` when generating client-side authentication key pairs for high-assurance Passkeys via Android Keystore / KeyMint.
- Engineers MUST NOT catch `StrongBoxUnavailableException` to silently fall back to software-backed or unverified TEE keystore implementations for zero-trust or critical financial transactions.
- Clients MUST pass a cryptographically random, server-originated challenge into `setAttestationChallenge(...)` to thwart replay attacks during Passkey registration.
- Backend verification services MUST strictly validate the attestation certificate chain up to Google's Attestation Root CA and inspect the ASN.1 KeyDescription extension to ensure `SecurityLevel` is explicitly `StrongBox`.
- Credential Manager requests via `CreatePublicKeyCredentialRequest` MUST explicitly configure authenticator selection with `authenticatorAttachment = AuthenticatorAttachment.PLATFORM` and `requireResidentKey = true` without allowing unauthenticated non-hardware fallback.
- Applications MUST treat any hardware attestation failure or missing StrongBox support as an explicit authentication denial (Fail-Closed Architecture).

## Bad vs Good Implementations
### Android 15 StrongBox Passkey Registration & Attestation Challenge

#### Bad Antipattern (AI Common Hallucination)
> **Why it fails**: The bad example omits `setIsStrongBoxBacked(true)` and fails to provide a server-originated attestation challenge via `setAttestationChallenge()`. This permits execution inside software-backed keystores on rooted or emulated devices, leaving private keys vulnerable to extraction via memory inspection or compromised Android frameworks.
```kotlin
// INSECURE: Relies on generic KeyPairGenerator with software fallback
// and ignores StrongBox KeyMint hardware isolation.
import android.security.keystore.KeyGenParameterSpec
import android.security.keystore.KeyProperties
import java.security.KeyPairGenerator

fun generatePasskeyPair(alias: String) {
    val keyPairGenerator = KeyPairGenerator.getInstance(
        KeyProperties.KEY_ALGORITHM_EC,
        "AndroidKeyStore"
    )
    val spec = KeyGenParameterSpec.Builder(
        alias,
        KeyProperties.PURPOSE_SIGN or KeyProperties.PURPOSE_VERIFY
    )
        .setDigests(KeyProperties.DIGEST_SHA256)
        .setUserAuthenticationRequired(true)
        // Flaw: Silent fallback to standard TEE or Software keystore;
        // Flaw: Missing attestation challenge allowing compromised OS replay.
        .build()
    
    try {
        keyPairGenerator.initialize(spec)
        keyPairGenerator.generateKeyPair()
    } catch (e: Exception) {
        // Unsafe downgrade
        println("Keystore failed, using software fallback: ${e.message}")
    }
}
```

#### Production Standard (Correct)
> **Standard**: The good implementation verifies `FEATURE_STRONGBOX_KEYSTORE`, explicitly mandates `.setIsStrongBoxBacked(true)`, binds a server-side cryptographic challenge using `.setAttestationChallenge(...)`, and fails closed if `StrongBoxUnavailableException` is raised, guaranteeing hardware-enforced protection against extraction on Android 15.
```kotlin
// SECURE: Enforces Android 15 StrongBox KeyMint isolation with explicit attestation
import android.content.Context
import android.content.pm.PackageManager
import android.security.keystore.KeyGenParameterSpec
import android.security.keystore.KeyProperties
import android.security.keystore.StrongBoxUnavailableException
import java.security.KeyPair
import java.security.KeyPairGenerator
import java.security.KeyStore

class StrongBoxPasskeyManager(private val context: Context) {
    fun generateHardwareAttestedPasskey(
        alias: String,
        serverAttestationChallenge: ByteArray
    ): KeyPair {
        val hasStrongBox = context.packageManager.hasSystemFeature(PackageManager.FEATURE_STRONGBOX_KEYSTORE)
        if (!hasStrongBox) {
            throw SecurityException("Hardware isolation failed: StrongBox is not available on this device.")
        }

        val keyPairGenerator = KeyPairGenerator.getInstance(
            KeyProperties.KEY_ALGORITHM_EC,
            "AndroidKeyStore"
        )

        val spec = KeyGenParameterSpec.Builder(
            alias,
            KeyProperties.PURPOSE_SIGN or KeyProperties.PURPOSE_VERIFY
        )
            .setDigests(KeyProperties.DIGEST_SHA256)
            .setAlgorithmParameterSpec(java.security.spec.ECGenParameterSpec("secp256r1"))
            .setUserAuthenticationRequired(true)
            .setIsStrongBoxBacked(true) // Enforce dedicated tamper-resistant hardware (KeyMint)
            .setAttestationChallenge(serverAttestationChallenge) // Guard against replay attacks
            .build()

        return try {
            keyPairGenerator.initialize(spec)
            keyPairGenerator.generateKeyPair()
        } catch (e: StrongBoxUnavailableException) {
            // Fail closed: reject silent fallback to standard TEE or software keystore
            throw SecurityException("StrongBox isolation required but rejected by KeyMint hardware", e)
        }
    }
}
```
Recommended MCP Servers (mcp-serverlist.com)

Equip agent with system tools to verify code for this stack.

Android Manifest & Security MCP
Analyzes Android application configurations and security permissions for hardware-level attestation compliance.
Recommended Agent Skills (askills.dev)

Ready-to-use executable skill functions tailored to this stack.

Semgrep Android Mobile Hardening
Static analysis checks detecting insecure KeyGenParameterSpec definitions and silent keystore fallback patterns.
Architectural Specification & Invariant Rationale

Architectural Invariant Design: Android 15 Credential Manager StrongBox Hardware Attestation Guardrail

Android 15 Credential Manager StrongBox Hardware Attestation Guardrail defines an industrial-grade behavioral standard for mobile engineering. Enforces mandatory StrongBox KeyMint hardware isolation and cryptographic attestation chain verification for biometric Passkey operations via Android 15 Credential Manager. Prohibits silent software or standard TEE fallback for high-assurance credentials on compromised or rooted devices. Mandates fail-closed semantics when dedicated tamper-resistant hardware security modules are unavailable. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Silent Downgrade to Software Keystore or Omitting Hardware Key Attestation during Passkey Operations Without an explicit system instruction file, developers spend hours debugging silent failures.
Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure ModeAI Symptom (The Anti-Pattern)SeverityProduction Impact & Remedy
AI Hallucination & Deprecation DriftSilent Downgrade to Software Keystore or Omitting Hardware Key Attestation during Passkey OperationsCritical
Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production.
Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture InconsistencyAI assistants produce mixed paradigms across files, creating fragmented codebase conventions.Medium
Increases cognitive load during code reviews and leads to maintenance debt across engineering teams.
Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.
Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

1

Engineers MUST ALWAYS require `setIsStrongBoxBacked(true)` when generating client-side authentication key pairs for high-assurance Passkeys via Android Keystore / KeyMint.

Engineers MUST ALWAYS require `setIsStrongBoxBacked(true)` when generating client-side authentication key pairs for high-assurance Passkeys via Android Keystore / KeyMint.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
2

Engineers MUST NOT catch `StrongBoxUnavailableException` to silently fall back to software-backed or unverified TEE keystore implementations for zero-trust or critical financial transactions.

Engineers MUST NOT catch `StrongBoxUnavailableException` to silently fall back to software-backed or unverified TEE keystore implementations for zero-trust or critical financial transactions.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
3

Clients MUST pass a cryptographically random, server-originated challenge into `setAttestationChallenge(...)` to thwart replay attacks during Passkey registration.

Clients MUST pass a cryptographically random, server-originated challenge into `setAttestationChallenge(...)` to thwart replay attacks during Passkey registration.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
4

Backend verification services MUST strictly validate the attestation certificate chain up to Google's Attestation Root CA and inspect the ASN.1 KeyDescription extension to ensure `SecurityLevel` is explicitly `StrongBox`.

Backend verification services MUST strictly validate the attestation certificate chain up to Google's Attestation Root CA and inspect the ASN.1 KeyDescription extension to ensure `SecurityLevel` is explicitly `StrongBox`.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
5

Credential Manager requests via `CreatePublicKeyCredentialRequest` MUST explicitly configure authenticator selection with `authenticatorAttachment = AuthenticatorAttachment.PLATFORM` and `requireResidentKey = true` without allowing unauthenticated non-hardware fallback.

Credential Manager requests via `CreatePublicKeyCredentialRequest` MUST explicitly configure authenticator selection with `authenticatorAttachment = AuthenticatorAttachment.PLATFORM` and `requireResidentKey = true` without allowing unauthenticated non-hardware fallback.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
6

Applications MUST treat any hardware attestation failure or missing StrongBox support as an explicit authentication denial (Fail-Closed Architecture).

Applications MUST treat any hardware attestation failure or missing StrongBox support as an explicit authentication denial (Fail-Closed Architecture).

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
Technical Questions & Answers

Frequently Asked Technical Questions

Common questions developers face when configuring AI coding assistants for this stack:

Q:Why is Android 15 Credential Manager StrongBox Hardware Attestation Guardrail critical for AI coding assistants?

Enforces mandatory StrongBox KeyMint hardware isolation and cryptographic attestation chain verification for biometric Passkey operations via Android 15 Credential Manager. Prohibits silent software or standard TEE fallback for high-assurance credentials on compromised or rooted devices. Mandates fail-closed semantics when dedicated tamper-resistant hardware security modules are unavailable. Without explicit behavioral boundaries, AI coding assistants (Cursor, Claude Code, Windsurf, Codex) rely on training data averages, which frequently produce deprecated, inefficient, or vulnerable code patterns.

Q:How does adopting this rule prevent AI hallucinations?

This rule explicitly declares what the AI must avoid (Silent Downgrade to Software Keystore or Omitting Hardware Key Attestation during Passkey Operations) and prescribes verified positive examples. Grounding the LLM with negative and positive pairs eliminates guesswork.

Q:Which AI coding environments are supported?

This specification is multi-platform compatible: Cursor (.cursor/rules/*.mdc & .cursorrules), Anthropic Claude Code (CLAUDE.md), Windsurf (.windsurfrules), Codex / Cline (AGENTS.md), and GitHub Copilot (.github/copilot-instructions.md).

Q:Can I combine this rule with other technology stacks?

Yes. Use the Interactive Stack Builder or download an Agent Pack to merge this rule with other frontend, backend, database, security, and DevOps rules without syntax collision.

Open Specification · CC BY 4.0·Free for Personal, Team & Commercial In-Repo Use

Citation & Open Source Attribution Guidelines

This specification is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). You are completely free to adapt and share this rule in your workspace. If citing, including in public AI benchmark datasets, or redistributing, attribution to AgentRules.org is required.

Related MOBILE Rules

View all rules →
mobile
106

Tauri 2.0 Mobile IPC & Capabilities Permissions Matrix Standard

Tauri v2 introduces a capability-driven permissions system replacing legacy v1 allowlists across iOS and Android runtimes. Failure to constrain IPC command handlers with typed schemas and explicit mobile capability definitions exposes native mobile OS surfaces to arbitrary code execution, permission leakage, and silent serialization failures. Production mobile deployments require strictly typed IPC boundary validation, granular capability scopes, and graceful permission degradation.

mobile
70

Capacitor 7 Native Bridge, Biometric Auth & Android 15 Lifecycle Production Standard

Capacitor 7 enforces strict bridge lifecycle contracts, asynchronous native plugin interop, and mandatory Android 15 edge-to-edge window inset handling. Storing sensitive authentication tokens in unencrypted web storage or failing to bind biometric authentication directly to hardware-backed Keystore or Secure Enclave mechanisms compromises app integrity and causes fatal crash or viewport occlusion issues on modern mobile operating systems.

mobile
58

Tauri 2.0 Mobile IPC Isolation and Capabilities Permission Scoping

Enforces strict capability permission boundaries, payload validation, and secure IPC invoke scoping for Tauri v2 Android and iOS environments. Prevents arbitrary IPC command execution, excessive native privilege granting, and deserialization vulnerabilities across the mobile webview-native boundary.

1 Rule in Stack

Android