AuthorizationList
Intro
Authorization List ASN.1 sequence as defined by Android’s attestation schema: https://source.android.com/docs/security/features/keystore/attestation#schema
This is the meat of the AttestationKeyDescription certificate extension and is also used for secure key import.
Sources / Constants
The numeric values and semantics used here are aligned with:
KeyMint AIDL definitions (enum values, etc.): https://cs.android.com/android/platform/superproject/main/+/main:hardware/interfaces/security/keymint/aidl/android/hardware/security/keymint/
Keymaster header constants (historical reference): https://android.googlesource.com/platform/hardware/libhardware/+/refs/heads/main/include_all/hardware/keymaster_defs.h
Note: some online sources disagree with the schema for certain values (example discussion): https://android.googlesource.com/platform/frameworks/base/+blame/45ff13e/core/java/android/security/keymaster/KeymasterDefs.java
Every value is nullable because two authorization lists are present in an attestation extension: once for software-enforced values, and once for hardware-enforced value. The actual values are scattered across both instances.
On Parsing
Parsing is lenient: If a value fails to parse, it is set to null. In reality, you won't care whether a value is structurally illegal or absent:
If you want to enforce it, it must be present and structurally valid, fulfilling your constraints
If you don't care for it, you don't care whether it is present, invalid, or absent altogether In case you still want to explore the raw value, check the raw ASN.1 Sequence from the certificate extension and fetch the raw value according to the explicit tag denoting said value.
Structural Properties and Design Decisions
Structurally, this data structure follows the ASN.1 schema exactly, meaning that it is a structural 1:1 mapping if the underlying ASN.1 structure. This as both advantages and disadvantages. The main disadvantage is that it is a bit cumbersome to use. The benefits far outweigh the shortcomings of this approach, though:
Just check the schema, and you know what's what. That means that there are no booleans, but an object indicating
trueorfalseis either present or absent.Re-Encoding produces the exact same ASN.1 structure that was parsed, byte-for-byte!
Creating Attestation statements for testing, fun, profit, or malicious intentions is a peak no-brainer; just follow the schema and set values!
Encoding and Ordering
AuthorizationList preserves the original order of the ASN.1 sequence during decoding by storing all decoded entries (including unknown tags) in elements.
For ASN.1 SET fields (e.g. purpose, blockMode, digest, padding, mgfDigest, and also AttestationApplicationId.packageInfos/AttestationApplicationId.signatureDigests):
When decoding, an internal order-preserving Set implementation is used so iteration keeps the original element order from the input (even if the input violates DER sorting).
The public API still exposes these values as regular Kotlin Sets.
When encoding, if such an order-preserving set is present, the produced ASN.1 SET preserves that iteration order (which may be non-DER-compliant). Otherwise, normal SET encoding is used.
Constructors
Convenience constructor that builds an AuthorizationList from the fields defined by Android’s attestation schema.
Types
“Active date time” (notBefore) timestamp in milliseconds since epoch.
Key algorithm as defined by KeyMint.
Indicates “all applications”.
Indicates “allow while on body”.
Attestation application identifier structure.
Attestation ID value family (device identifiers).
Package info entry within AttestationApplicationId.packageInfos.
Authentication timeout.
Block modes as defined by KeyMint.
Indicates "caller nonce".
Key creation timestamp in milliseconds since epoch.
Can only ever be set by privileged system apps
Digest modes as defined by KeyMint.
Indicates “early boot only”.
Elliptic curve identifiers as defined by KeyMint.
A single entry inside the AuthorizationList ASN.1 sequence.
Helper interface for “integer-backed” authorization list values.
Key purposes as defined by KeyMint.
Key size (in bits).
MGF digest.
Minimum MAC length (in bits).
In the context of Android's Keymaster and Keystore systems, the moduleHash is a component within the attestation data structure, specifically in the KeyDescription sequence. It provides a cryptographic representation of the software environment associated with the key's creation and usage.
Indicates that no user authentication is required.
Key origin as defined by KeyMint.
“Origination expire date time” (notAfter) timestamp in milliseconds since epoch.
OS patch level as year and month, encoded as year * 100 + month as per the schema.
Padding modes as defined by KeyMint.
Patch level value family.
Indicates “rollback resistance”.
Legacy rollback-resistant indicator (older attestation versions use this tag name/spelling).
Root of trust structure.
RSA public exponent.
Base type for explicit tag constants used by the AuthorizationList schema.
Indicates “trusted confirmation required”.
Indicates “trusted user presence required”.
Indicates “unlocked device required”.
Limits the number of permitted uses of a key.
“Usage expire date time” timestamp in milliseconds since epoch.
As per the KeyMaster AIDL
Secure user ID (SID).
Properties
Key validity "not before" timestamp.
Key algorithm.
"All applications" flag (legacy / keymaster).
Allow-while-on-body flag.
Attestation application ID.
Device brand.
Device name.
IMEI (first slot).
Manufacturer name.
Device model.
Product name.
IMEI (second slot).
Device serial number.
User authentication timeout.
Block modes.
Boot patch level.
Caller-provided nonce flag.
Key creation timestamp.
Device-unique attestation flag.
Digest modes.
Early-boot-only restriction.
Elliptic curve identifier.
Key size (in bits).
RSA OAEP MGF digest.
Minimum MAC length (in bits).
Module hash.
No-authentication-required flag.
Key origin.
Key origination validity "not after" timestamp.
Operating system patch level.
YearMonth representation of AuthorizationList.osPatchLevel, but tolerating a zero-indexed month
Operating system version.
Padding modes.
Key purposes.
Rollback resistance.
Legacy rollback-resistant flag (keymaster attestation versions 1–2).
Root of trust information (verified boot state, device lock state, etc).
RSA public exponent.
Trusted confirmation required flag.
Trusted user presence required flag.
Unlocked device required flag.
Key usage count limit.
Key usage validity "not after" timestamp.
Hardware authenticator type (user authentication type).
Secure user ID (SID).
Vendor patch level.
Functions
Useful for debugging, but too strict in reality