调用方可以使用作为 API 参数有效的授权创建 KeyMint 密钥,但这会导致生成的密钥不安全或无法使用。在这种情况下,KeyMint 实现无需失败或发出诊断。实现不应诊断以下情况:使用过小的密钥、指定不相关的输入参数、重复使用 IV 或 Nonce、生成密钥时未指定目的(因此生成的密钥没有用处),以及类似情况。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-07-27。"],[],[],null,["# KeyMint functions\n\nThis page provides additional details and guidelines to assist implementers\nof the KeyMint hardware abstraction layer (HAL). The primary documentation for\nthe HAL is\nthe [AIDL\ninterface specification](https://cs.android.com/android/platform/superproject/+/android-latest-release:hardware/interfaces/security/keymint/aidl/android/hardware/security/keymint/IKeyMintDevice.aidl).\n\nAPI misuse\n----------\n\nCallers can create KeyMint keys with authorizations that are valid as API parameters, but that\nmake the resulting keys insecure or unusable. KeyMint implementations aren't\nrequired to fail in such cases or issue a diagnostic. Use of too-small keys,\nspecification of irrelevant input parameters, reuse of IVs or nonces,\ngeneration of keys with no purposes (hence useless), and the like shouldn't be\ndiagnosed by implementations.\n| **Caution:** KeyMint implementations should attempt to diagnose serious errors, such as omission of required parameters, specification of invalid required parameters, and similar errors that compromise the integrity of the KeyMint implementation.\n\nIt's the responsibility of apps, the framework, and Android Keystore to\nensure that the calls to KeyMint modules are sensible and useful.\n\naddRngEntropy entry point\n-------------------------\n\nThe `addRngEntropy` entry point adds caller-provided entropy to the\npool used by the KeyMint implementation for generating random numbers, for keys\nand IVs.\n\nKeyMint implementations need to securely mix the provided entropy into their\npool, which also must contain internally generated entropy from a hardware\nrandom number generator. Mixing should be handled so that an attacker who has\ncomplete control of either the `addRngEntropy`-provided bits or the\nhardware-generated bits (but not both) doesn't have a significant advantage in\npredicting the bits generated from the entropy pool.\n\nKey characteristics\n-------------------\n\nEach of the mechanisms (`generateKey`, `importKey`,\nand `importWrappedKey`) that create KeyMint keys returns the newly\ncreated key's characteristics, divided appropriately into the security levels\nthat enforce each characteristic. The returned characteristics include all of\nthe parameters specified for key creation,\nexcept `Tag::APPLICATION_ID` and `Tag::APPLICATION_DATA`.\nIf these tags are included in the key parameters, they're removed from the\nreturned characteristics so that it isn't possible to find their values by\nexamining the returned keyblob. However, they're cryptographically bound to\nthe keyblob, so that if the correct values aren't provided when the key is\nused, usage fails. Similarly,\n`Tag::ROOT_OF_TRUST` is\ncryptographically bound to the key, but it can't be specified during\nkey creation or import and is never returned.\n\nIn addition to the provided tags, the KeyMint implementation also\nadds `Tag::ORIGIN`, indicating the manner in which the key was\ncreated (`KeyOrigin::GENERATED`,\n`KeyOrigin::IMPORTED`, or `KeyOrigin::SECURELY_IMPORTED`).\n\nRollback resistance\n-------------------\n\nRollback resistance is indicated by `Tag::ROLLBACK_RESISTANCE`,\nand means that once a key is deleted with `deleteKey`\nor `deleteAllKeys`, the secure hardware\nensures it's never usable again.\n\nKeyMint implementations return generated or imported key material to the\ncaller as a keyblob, an encrypted and authenticated form. When Keystore deletes\nthe keyblob, the key is gone, but an attacker who has previously managed to\nretrieve the key material could potentially restore it to the device.\n\nA key is rollback resistant if the secure hardware ensures that deleted\nkeys can't be restored later. This is generally done by storing additional key\nmetadata in a trusted location that can't be manipulated by an attacker. On\nmobile devices, the mechanism used for this is usually replay protected memory\nblocks (RPMB). Because the number of keys that can be created is essentially\nunbounded and the trusted storage used for rollback resistance might be limited\nin size, the implementation can fail requests to create rollback-resistant keys\nwhen the storage is full.\n\nbegin\n-----\n\nThe `begin()` entry point begins a cryptographic operation using the\nspecified key, for the specified purpose, with the specified parameters (as\nappropriate). It returns a new `IKeyMintOperation` Binder object\nthat is used to complete the operation. In addition, a challenge value is\nreturned that is used as part of the authentication token in authenticated\noperations.\n\nA KeyMint implementation supports at least 16 concurrent\noperations. Keystore uses up to 15, leaving one for `vold` to use for password\nencryption. When Keystore has 15 operations in progress (`begin()` has\nbeen called, but `finish` or `abort` haven't been\ncalled) and it receives a request to begin a 16th, it calls\n`abort()` on the least-recently used operation to reduce the number of\nactive operations to 14 before calling `begin()` to start the\nnewly requested operation.\n\nIf `Tag::APPLICATION_ID` or `Tag::APPLICATION_DATA`\nwere specified during key generation or import, calls to `begin()` must\ninclude those tags with the originally specified values in\nthe `params` argument to this method.\n\nError handling\n--------------\n\nIf a method on a `IKeyMintOperation` returns an error code other\nthan `ErrorCode::OK`, the operation is aborted and the operation\nBinder object is invalidated. Any future use of the object\nreturns `ErrorCode::INVALID_OPERATION_HANDLE`.\n\nAuthorization enforcement\n-------------------------\n\nKey authorization enforcement is performed primarily\nin `begin()`. The one exception is the case where the key\nhas one or more `Tag::USER_SECURE_ID` values, and\ndoesn't have a `Tag::AUTH_TIMEOUT` value.\n\nIn this case, the key requires an authorization per operation, and the `update()`\nor `finish()` methods receive an auth token in the `authToken`\nargument. To ensure that the token is valid, the KeyMint implementation:\n\n- Verifies the HMAC signature on the auth token.\n- Checks that the token contains a secure user ID matching one associated with the key.\n- Checks that the token's auth type matches the key's `Tag::USER_AUTH_TYPE`.\n- Checks that the token contains the challenge value for the current operation in the challenge field.\n\nIf these conditions aren't met, KeyMint\nreturns `ErrorCode::KEY_USER_NOT_AUTHENTICATED`.\n\nThe caller provides the authentication token to every call to `update()` and\n`finish()`. The implementation can validate the token only once."]]