1 <html devsite> 2 <head> 3 <title>Implementer's Reference</title> 4 <meta name="project_path" value="/_project.yaml" /> 5 <meta name="book_path" value="/_book.yaml" /> 6 </head> 7 <body> 8 <!-- 9 Copyright 2017 The Android Open Source Project 10 11 Licensed under the Apache License, Version 2.0 (the "License"); 12 you may not use this file except in compliance with the License. 13 You may obtain a copy of the License at 14 15 http://www.apache.org/licenses/LICENSE-2.0 16 17 Unless required by applicable law or agreed to in writing, software 18 distributed under the License is distributed on an "AS IS" BASIS, 19 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 20 See the License for the specific language governing permissions and 21 limitations under the License. 22 --> 23 24 25 26 <p>This page provides details to assist implementers of <a href="index.html">Keymaster</a> HALs. It 27 covers each tag and each function in the HAL.</p> 28 29 <h2 id=authorization_tags>Authorization tags</h2> 30 31 <p>Except as noted in the tag descriptions, all of the tags below are used during 32 key generation to specify key characteristics.</p> 33 34 <h3 id=km_tag_purpose>KM_TAG_PURPOSE</h3> 35 36 <p>Specifies the set of purposes for which the key may be used.</p> 37 38 <p>Possible values are defined by the following enumeration:</p> 39 40 <pre class="devsite-click-to-copy"> 41 typedef enum { 42 KM_PURPOSE_ENCRYPT = 0, 43 KM_PURPOSE_DECRYPT = 1, 44 KM_PURPOSE_SIGN = 2, 45 KM_PURPOSE_VERIFY = 3, 46 } keymaster_purpose_t; 47 </pre> 48 49 <p>This tag is repeatable; keys may be generated with multiple values, although an 50 operation has a single purpose. When the <a href="#begin">begin</a> function is called to 51 start an operation, the purpose of the operation is 52 specified. If the purpose specified to the operation is not authorized by the 53 key, the operation must fail with <code>KM_ERROR_INCOMPATIBLE_PURPOSE</code>.</p> 54 55 <h3 id=km_tag_algorithm>KM_TAG_ALGORITHM</h3> 56 57 <p>Specifies the cryptographic algorithm with which the key is used.</p> 58 59 <p>Possible values are defined by the following enumeration:</p> 60 61 <pre class="devsite-click-to-copy"> 62 typedef enum { 63 KM_ALGORITHM_RSA = 1, 64 KM_ALGORITHM_EC = 3, 65 KM_ALGORITHM_AES = 32, 66 KM_ALGORITHM_HMAC = 128, 67 } keymaster_algorithm_t; 68 </pre> 69 70 <p>This tag is not repeatable.</p> 71 72 <h3 id=km_tag_key_size>KM_TAG_KEY_SIZE</h3> 73 74 <p>Specifies the size, in bits, of the key, measuring in the normal way for the 75 key's algorithm. For example, for RSA keys, <code>KM_TAG_KEY_SIZE</code> specifies 76 the size of the public modulus. For AES keys it specifies the length 77 of the secret key material.</p> 78 79 <p>This tag is not repeatable.</p> 80 81 <h3 id=km_tag_block_mode>KM_TAG_BLOCK_MODE</h3> 82 83 <p>Specifies the block cipher mode(s) with which the key may be used. This tag is 84 only relevant to AES keys.</p> 85 86 <p>Possible values are defined by the following enumeration:</p> 87 88 <pre class="devsite-click-to-copy"> 89 typedef enum { 90 KM_MODE_ECB = 1, 91 KM_MODE_CBC = 2, 92 KM_MODE_CTR = 3, 93 KM_MODE_GCM = 32, 94 } keymaster_block_mode_t; 95 </pre> 96 97 <p>This tag is repeatable, and for AES key operations a mode must be specified in 98 the <code>additional_params</code> argument of <a href="#begin">begin</a>. If the specified 99 mode is not in the modes associated with the key, the 100 operation must fail with <code>KM_ERROR_INCOMPATIBLE_BLOCK_MODE</code>.</p> 101 102 <h3 id=km_tag_digest>KM_TAG_DIGEST</h3> 103 104 <p>Specifies the digest algorithms which may be used with the key to perform 105 signing and verification operations. This tag is relevant to RSA, ECDSA and 106 HMAC keys.</p> 107 108 <p>Possible values are defined by the following enumeration:</p> 109 110 <pre class="devsite-click-to-copy"> 111 typedef enum { 112 KM_DIGEST_NONE = 0, 113 KM_DIGEST_MD5 = 1, 114 KM_DIGEST_SHA1 = 2, 115 KM_DIGEST_SHA_2_224 = 3, 116 KM_DIGEST_SHA_2_256 = 4, 117 KM_DIGEST_SHA_2_384 = 5, 118 KM_DIGEST_SHA_2_512 = 6, 119 } 120 keymaster_digest_t; 121 </pre> 122 123 <p>This tag is repeatable. For signing and verification operations a digest must 124 be specified in the <code>additional_params</code> argument of <a href="#begin">begin</a>. 125 If the specified digest is not in the digests associated with the key, the 126 operation must fail with <code>KM_ERROR_INCOMPATIBLE_DIGEST</code>.</p> 127 128 <h3 id=km_tag_padding>KM_TAG_PADDING</h3> 129 130 <p>Specifies the padding modes which may be used with the key. This tag is 131 relevant to RSA and AES keys.</p> 132 133 <p>Possible values are defined by the following enumeration:</p> 134 135 <pre class="devsite-click-to-copy"> 136 typedef enum { 137 KM_PAD_NONE = 1, 138 KM_PAD_RSA_OAEP = 2, 139 KM_PAD_RSA_PSS = 3, 140 KM_PAD_RSA_PKCS1_1_5_ENCRYPT = 4, 141 KM_PAD_RSA_PKCS1_1_5_SIGN = 5, 142 KM_PAD_PKCS7 = 64, 143 } keymaster_padding_t; 144 </pre> 145 146 <p><code>KM_PAD_RSA_OAEP</code> and <code>KM_PAD_RSA_PKCS1_1_5_ENCRYPT</code> are used 147 only for RSA encryption/decryption keys and specify RSA PKCS#1v2 OAEP 148 padding and RSA PKCS#1 v1.5 randomized padding, respectively. <code>KM_PAD_RSA_PSS</code> and 149 <code>KM_PAD_RSA_PKCS1_1_5_SIGN</code> are used only for RSA signing/verification keys and 150 specify RSA PKCS#1v2 PSS 151 padding and RSA PKCS#1 v1.5 deterministic padding, respectively. Note also that 152 the RSA PSS padding mode is incompatible with <a href="#km_tag_digest">KM_DIGEST_NONE</a>.</p> 153 154 <p><code>KM_PAD_NONE</code> may be used with either RSA or AES keys. For AES keys, 155 if <code>KM_PAD_NONE</code> is used with block mode ECB or CBC and the data to be encrypted 156 or decrypted 157 is not a multiple of the AES block size in length, the call to finish must fail 158 with <code>KM_ERROR_INVALID_INPUT_LENGTH</code>.</p> 159 160 <p><code>KM_PAD_PKCS7</code> may only be used with AES keys, and only with ECB and CBC modes.</p> 161 162 <p>This tag is repeatable. A padding mode must be specified in the call to 163 <a href="#begin">begin</a>. If the specified mode is not authorized for the key, 164 the operation must fail 165 with <code>KM_ERROR_INCOMPATIBLE_BLOCK_MODE</code>.</p> 166 167 <h3 id=km_tag_caller_nonce>KM_TAG_CALLER_NONCE</h3> 168 169 <p>Specifies that the caller is allowed to provide a nonce for nonce-requiring 170 operations.</p> 171 172 <p>This tag is boolean, so the possible values are true (if the tag is present) 173 and false (if the tag is not present).</p> 174 175 <p>This tag is used only for AES keys, and is only relevant for CBC, CTR and GCM 176 block modes. If the tag is not present, implementations should reject any 177 operation which provides <a href="#km_tag_nonce">KM_TAG_NONCE</a> to <a href="#begin">begin</a> 178 with <code>KM_ERROR_CALLER_NONCE_PROHIBITED</code>.</p> 179 180 <p>This tag is not repeatable.</p> 181 182 <h3 id=km_tag_min_mac_length>KM_TAG_MIN_MAC_LENGTH</h3> 183 184 <p>Required for HMAC keys and AES keys that support GCM mode, this tag specifies 185 the minimum length of MAC that can be requested or verified with this key.</p> 186 187 <p>This value is the minimum MAC length, in bits. It must be a multiple of 8. For 188 HMAC keys, the value must be at least 64. For GCM keys it must be at least 96 189 and must not exceed 128.</p> 190 191 <h3 id=km_tag_rsa_public_exponent>KM_TAG_RSA_PUBLIC_EXPONENT</h3> 192 193 <p>Specifies the value of the public exponent for an RSA key pair. This tag is 194 relevant only to RSA keys, and required for all RSA keys.</p> 195 196 <p>The value is a 64-bit unsigned integer that must satisfy the requirements of an 197 RSA public exponent. Because it is specified by the caller and therefore cannot 198 be chosen by the implementation, it must be a prime number. Trustlets are 199 required to support the value 2^16+1. It is recommended that other reasonable 200 values be supported, in particular the value 3. If no exponent is specified or 201 if the specified exponent is not supported, key generation must fail 202 with <code>KM_ERROR_INVALID_ARGUMENT</code>.</p> 203 204 <p>This tag is not repeatable.</p> 205 206 <h3 id=km_tag_blob_usage_requirements>KM_TAG_BLOB_USAGE_REQUIREMENTS</h3> 207 208 <p>Specifies the system environment conditions which must hold for the generated 209 key to be used.</p> 210 211 <p>Possible values are defined by the following enumeration:</p> 212 213 <pre class="devsite-click-to-copy"> 214 typedef enum { 215 KM_BLOB_STANDALONE = 0, 216 KM_BLOB_REQUIRES_FILE_SYSTEM = 1, 217 } keymaster_key_blob_usage_requirements_t; 218 </pre> 219 220 <p>This tag may be specified during key generation to require that the key be 221 usable in the specified condition, and must be returned with the key 222 characteristics (from <a href="#generate_key">generate_key</a> and 223 <a href="#get_key_characteristics">get_key_characteristics</a>). If 224 the caller specifies <code>KM_TAG_BLOB_USAGE_REQUIREMENTS</code> with 225 value <code>KM_BLOB_STANDALONE</code> the trustlet must return a key blob 226 which can be used without file system 227 support. This is critical for devices with encrypted disks, where the file 228 system may not be available until after a Keymaster key is used to decrypt the 229 disk.</p> 230 231 <p>This tag is not repeatable.</p> 232 233 <h3 id=km_tag_bootloader_only>KM_TAG_BOOTLOADER_ONLY</h3> 234 235 <p>Specifies that the key may only be used by the bootloader.</p> 236 237 <p>This tag is boolean, so the possible values are true (if the tag is present) 238 and false (if the tag is not present).</p> 239 240 <p>Any attempt to use a key with <code>KM_TAG_BOOTLOADER_ONLY</code> from the 241 Android system must fail with <code>KM_ERROR_INVALID_KEY_BLOB</code>.</p> 242 243 <p>This tag is not repeatable.</p> 244 245 <h3 id=km_tag_active_datetime>KM_TAG_ACTIVE_DATETIME</h3> 246 247 <p>Specifies the date and time at which the key becomes active. Prior to this 248 time, any attempt to use the key must fail with <code>KM_ERROR_KEY_NOT_YET_VALID</code>.</p> 249 250 <p>The value is a 64-bit integer representing milliseconds since January 1, 1970.</p> 251 252 <p>This tag is not repeatable.</p> 253 254 <h3 id=km_tag_origination_expire_datetime>KM_TAG_ORIGINATION_EXPIRE_DATETIME</h3> 255 256 <p>Specifies the date and time at which the key expires for signing and encryption 257 purposes. After this time, any attempt to use a key 258 with <a href="#km_tag_purpose">KM_PURPOSE_SIGN</a> or 259 <a href="#km_tag_purpose">KM_PURPOSE_ENCRYPT</a> provided 260 to <a href="#begin">begin</a> must fail with <code>KM_ERROR_KEY_EXPIRED</code>.</p> 261 262 <p>The value is a 64-bit integer representing milliseconds since January 1, 1970.</p> 263 264 <p>This tag is not repeatable.</p> 265 266 <h3 id=km_tag_usage_expire_datetime>KM_TAG_USAGE_EXPIRE_DATETIME</h3> 267 268 <p>Specifies the date and time at which the key expires for verification and 269 decryption purposes. After this time, any attempt to use a key with 270 <a href="#km_tag_purpose">KM_PURPOSE_VERIFY</a> or <a href="#km_tag_purpose">KM_PURPOSE DECRYPT</a> 271 provided to <a href="#begin">begin</a> must fail with <code>KM_ERROR_KEY_EXPIRED</code>.</p> 272 273 <p>The value is a 64-bit integer representing milliseconds since January 1, 1970.</p> 274 275 <p>This tag is not repeatable.</p> 276 277 <h3 id=km_tag_min_seconds_between_ops>KM_TAG_MIN_SECONDS_BETWEEN_OPS</h3> 278 279 <p>Specifies the minimum amount of time that must elapse between allowed 280 operations using a key. This can be used to rate-limit uses of keys in contexts 281 where unlimited use may enable brute force attacks.</p> 282 283 <p>The value is a 32-bit integer representing seconds between allowed operations.</p> 284 285 <p>When a key with this tag is used in an operation, a timer should be started 286 during the <a href="#finish">finish</a> or <a href="#abort">abort</a> call. Any 287 call to <a href="#begin">begin</a> that is received before the timer indicates 288 that the interval specified by <code>KM_TAG_MIN_SECONDS_BETWEEN_OPS</code> has 289 elapsed must fail with <code>KM_ERROR_KEY_RATE_LIMIT_EXCEEDED</code>. This 290 requirement implies that a trustlet must keep a table of timers for keys 291 with this tag. Because Keymaster memory is often limited, it is acceptable for 292 this table to have a fixed maximum size and for Keymaster to fail operations 293 which attempt to use keys with this tag when the table is full. At least 32 294 in-use keys must be accommodated, and table slots must be aggressively reused 295 when key minimum-usage intervals expire. If an operation fails because the 296 table is full, Keymaster should return <code>KM_ERROR_TOO_MANY_OPERATIONS</code>.</p> 297 298 <p>This tag is not repeatable.</p> 299 300 <h3 id=km_tag_max_uses_per_boot>KM_TAG_MAX_USES_PER_BOOT</h3> 301 302 <p>Specifies the maximum number of times that a key may be used between system 303 reboots. This is another mechanism to rate-limit key use.</p> 304 305 <p>The value is a 32-bit integer representing uses per boot.</p> 306 307 <p>When a key with this tag is used in an operation, a key-associated counter 308 should be incremented during the <a href="#begin">begin</a> call. After the key counter 309 has exceeded this value, all subsequent attempts 310 to use the key must fail with <code>KM_ERROR_MAX_OPS_EXCEEDED</code>, until the device is 311 restarted. This requirement implies that a trustlet must 312 keep a table of use counters for keys with this tag. Because Keymaster memory 313 is often limited, it is acceptable for this table to have a fixed maximum size 314 and for Keymaster to fail operations that attempt to use keys with this tag 315 when the table is full. At least 16 keys must be accommodated. If an operation 316 fails because the table is full, Keymaster should return <code>KM_ERROR_TOO_MANY_OPERATIONS</code>.</p> 317 318 <p>This tag is not repeatable.</p> 319 320 <h3 id=km_tag_user_secure_id>KM_TAG_USER_SECURE_ID</h3> 321 322 <p>Specifies that a key may only be used under a particular secure user 323 authentication state. This tag is mutually exclusive 324 with <a href="#km_tag_no_auth_required">KM_TAG_NO_AUTH_REQUIRED</a>.</p> 325 326 <p>The value is a 64-bit integer specifying the authentication policy state value 327 which must be present in an authentication token (provided to <a href="#begin">begin</a> with 328 the <a href="#km_tag_auth_token">KM_TAG_AUTH_TOKEN</a>) to authorize use of the key. Any 329 call to <a href="#begin">begin</a> with a key with this tag that does not provide an 330 authentication token, or provides an 331 authentication token without a matching policy state value, must fail.</p> 332 333 <p>This tag is repeatable. If any of the provided values matches any policy state 334 value in the authentication token, the key is authorized for use. Otherwise the operation 335 must fail with <code>KM_ERROR_KEY_USER_NOT_AUTHENTICATED</code>.</p> 336 337 <h3 id=km_tag_no_auth_required>KM_TAG_NO_AUTH_REQUIRED</h3> 338 339 <p>Specifies that no authentication is required to use this key. This tag is 340 mutually exclusive with <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a>.</p> 341 342 <p>This tag is boolean, so the possible values are true (if the tag is present) 343 and false (if the tag is not present).</p> 344 345 <p>This tag is not repeatable.</p> 346 347 <h3 id=km_tag_user_auth_type>KM_TAG_USER_AUTH_TYPE</h3> 348 349 <p>Specifies the types of user authenticators that may be used to authorize this 350 key. When Keymaster is requested to perform an operation with a key with this 351 tag, it must receive an authentication token, and the token's 352 <code>authenticator_type</code> field must match the value in the tag. To be 353 precise, it must be true that <code>(ntoh(token.authenticator_type) & 354 auth_type_tag_value) != 0</code>, where <code>ntoh</code> is a function that converts 355 network-ordered integers to host-ordered integers and 356 <code>auth_type_tag_value</code> is the value of this tag.</p> 357 358 <p>The value is a 32-bit integer bitmask of values from the enumeration:</p> 359 360 <pre class="devsite-click-to-copy"> 361 typedef enum { 362 HW_AUTH_NONE = 0, 363 HW_AUTH_PASSWORD = 1 << 0, 364 HW_AUTH_FINGERPRINT = 1 << 1, 365 // Additional entries should be powers of 2. 366 HW_AUTH_ANY = UINT32_MAX, 367 } hw_authenticator_type_t; 368 </pre> 369 370 <p>This tag is not repeatable.</p> 371 372 <h3 id=km_tag_auth_timeout>KM_TAG_AUTH_TIMEOUT</h3> 373 374 <p>Specifies the time in seconds for which the key is authorized for use, after 375 authentication. If <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a> is present and this tag 376 is not, then the key requires authentication for every 377 usage (see <a href="#begin">begin</a> for the details of the authentication-per-operation flow).</p> 378 379 <p>The value is a 32-bit integer specifying the time in seconds after a successful 380 authentication of the user specified by <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a> with 381 the authentication method specified 382 by <a href="#km_tag_mac_length">KM_TAG_USER_AUTH_TYPE</a> that the key can be used.</p> 383 384 <p>This tag is not repeatable.</p> 385 386 <h3 id=km_tag_all_applications>KM_TAG_ALL_APPLICATIONS</h3> 387 388 <p>Reserved for future use.</p> 389 390 <p>This tag is not repeatable.</p> 391 392 <h3 id=km_tag_application_id>KM_TAG_APPLICATION_ID</h3> 393 394 <p>When provided to <a href="#generate_key">generate_key</a> or <a href="#import_key">import_key</a>, 395 this tag specifies data that must be provided during all uses of the key. In 396 particular, calls to <a href="#export_key">export_key</a> and 397 <a href="#get_key_characteristics">get_key_characteristics</a> must 398 provide the same value in the <code>client_id</code> parameter, and 399 calls to <a href="#begin">begin</a> must provide this tag and the 400 same associated data as part of the <code>in_params</code> set. If the correct 401 data is not provided the function must return <code>KM_ERROR_INVALID_KEY_BLOB</code>.</p> 402 403 <p>The content of this tag must be bound to the key <i>cryptographically</i>, 404 meaning it must not be possible for an adversary who has access to all of the 405 secure world secrets but does not have access to the tag content to decrypt the 406 key (without brute-forcing the tag content).</p> 407 408 <p>The value is a blob, an arbitrary-length array of bytes.</p> 409 410 <p>This tag is not repeatable.</p> 411 412 <h3 id=km_tag_application_data>KM_TAG_APPLICATION_DATA</h3> 413 414 <p>When provided to <a href="#generate_key">generate_key</a> or <a href="#import_key">import_key</a>, 415 this tag specifies data that must be provided during all uses of the key. In 416 particular, calls to <a href="#export_key">export_key</a> and 417 <a href="#get_key_characteristics">get_key_characteristics</a> must 418 provide the same value to the <code>client_id</code> parameter, and calls 419 to <a href="#begin">begin</a> must provide this tag and the same associated 420 data as part of the <code>in_params</code> set. If the correct data is not 421 provided, the function must return <code>KM_ERROR_INVALID_KEY_BLOB</code>.</p> 422 423 <p>The content of this tag must be bound to the key <i>cryptographically</i>, 424 meaning it must not be possible for an adversary who has access to all of the 425 secure world secrets but does not have access to the tag content to decrypt the 426 key (without brute-forcing the tag content, which applications can prevent by 427 specifying sufficiently high-entropy content).</p> 428 429 <p>The value is a blob, an arbitrary-length array of bytes.</p> 430 431 <p>This tag is not repeatable.</p> 432 433 <h3 id=km_tag_creation_datetime>KM_TAG_CREATION_DATETIME</h3> 434 435 <p>Specifies the date and time the key was created, in milliseconds since January 436 1, 1970. This tag is optional and informational only.</p> 437 438 <p>This tag is not repeatable.</p> 439 440 <h3 id=km_tag_origin>KM_TAG_ORIGIN</h3> 441 442 <p>Specifies where the key was created, if known. This tag may not be specified 443 during key generation or import, and must be added to the key characteristics 444 by the trustlet.</p> 445 446 <p>The possible values are defined in <code>keymaster_origin_t</code>:</p> 447 448 <pre class="devsite-click-to-copy"> 449 typedef enum { 450 KM_ORIGIN_GENERATED = 0, 451 KM_ORIGIN_IMPORTED = 2, 452 KM_ORIGIN_UNKNOWN = 3, 453 } keymaster_key_origin_t 454 </pre> 455 456 <p>The full meaning of the value depends not only on the value but on whether it's 457 found in the hardware-enforced or software-enforced characteristics list.</p> 458 459 <p><code>KM_ORIGIN_GENERATED</code> indicates that Keymaster generated the key. 460 If in the hardware-enforced list, 461 the key was generated in secure hardware and is permanently hardware-bound. If 462 in the software-enforced list, the key was generated in SoftKeymaster and is 463 not hardware-bound.</p> 464 465 <p><code>KM_ORIGIN_IMPORTED</code> indicates that the key was generated outside 466 of Keymaster and imported into 467 Keymaster. If in the hardware-enforced list, it is permanently hardware-bound, 468 although copies outside of secure hardware may exist. If in the 469 software-enforces list, the key was imported into SoftKeymaster and is not 470 hardware-bound.</p> 471 472 <p><code>KM_ORIGIN_UNKNOWN</code> should only appear in the hardware-enforced list. 473 It indicates that the key is 474 hardware-bound, but it is not known whether the key was originally generated in 475 secure hardware or was imported. This only occurs when keymaster0 hardware is 476 being used to emulate keymaster1 services.</p> 477 478 <p>This tag is not repeatable.</p> 479 480 <h3 id=km_tag_rollback_resistant>KM_TAG_ROLLBACK_RESISTANT</h3> 481 482 <p>Indicates that the key is rollback-resistant, meaning that when deleted 483 by <a href="#delete_key">delete_key</a> or <a href="#delete_all_keys">delete_all_keys</a>, 484 the key is guaranteed to be permanently deleted and unusable. It's possible 485 that keys without this tag could be deleted and then restored from backup.</p> 486 487 <p>This tag is boolean, so the possible values are true (if the tag is present) 488 and false (if the tag is not present).</p> 489 490 <p>This tag is not repeatable.</p> 491 492 <h3 id=km_tag_root_of_trust>KM_TAG_ROOT_OF_TRUST</h3> 493 494 <p>Specifies the "root of trust," the key used by verified boot to validate the 495 operating system booted (if any). This tag is never provided to or returned 496 from Keymaster in the key characteristics.</p> 497 498 <h3 id=km_tag_associated_data>KM_TAG_ASSOCIATED_DATA</h3> 499 500 <p>Provides "associated data" for AES-GCM encryption or decryption. This tag is 501 provided to <a href="#update">update</a> and specifies data that is not 502 encrypted/decrypted but is used in computing 503 the GCM tag.</p> 504 505 <p>The value is a blob, an arbitrary-length array of bytes.</p> 506 507 <p>This tag is not repeatable.</p> 508 509 <h3 id=km_tag_nonce>KM_TAG_NONCE</h3> 510 511 <p>Provides or returns a nonce or Initialization Vector (IV) for AES GCM, CBC or 512 CTR encryption or decryption. This tag is provided to <a href="#begin">begin</a> 513 during encryption and decryption operations. It may only be provided to <a href="#begin">begin</a> 514 if the key has <a href="#km_tag_caller_nonce">KM_TAG_CALLER_NONCE</a>. If not provided, 515 an appropriate nonce or IV will be randomly generated by 516 Keymaster and returned from begin.</p> 517 518 <p>The value is a blob, an arbitrary-length array of bytes. Allowed lengths depend 519 on the mode: GCM nonces are 12 bytes in length; CBC and CTR IVs are 16 bytes in 520 length.</p> 521 522 <p>This tag is not repeatable.</p> 523 524 <h3 id=km_tag_auth_token>KM_TAG_AUTH_TOKEN</h3> 525 526 <p>Provides an authentication token (see the Authentication page) to 527 <a href="#begin">begin</a>, <a href="#update">update</a> or <a href="#finish">finish</a>, 528 to prove user authentication for a key operation that requires 529 it (key has <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a>).</p> 530 531 <p>The value is a blob which contains a <code>hw_auth_token_t</code> structure.</p> 532 533 <p>This tag is not repeatable.</p> 534 535 <h3 id=km_tag_mac_length>KM_TAG_MAC_LENGTH</h3> 536 537 <p>Provides the requested length of a MAC or GCM authentication tag, in bits.</p> 538 539 <p>The value is the MAC length in bits. It must be a multiple of 8 and must be at 540 least as large as the value of <a href="#km_tag_min_mac_length">KM_TAG_MIN_MAC_LENGTH</a> 541 associated with the key.</p> 542 543 <h2 id=functions>Functions</h2> 544 545 <h3 id=deprecated_functions>Deprecated functions</h3> 546 547 <p>The following functions are in the <code>keymaster1_device_t</code> definition but 548 should not be implemented. The function pointers should be set 549 to <code>NULL</code>:</p> 550 551 <ul> 552 <li><code>generate_keypair</code> 553 <li><code>import_keypair</code> 554 <li><code>get_keypair_public</code> 555 <li><code>delete_keypair</code> 556 <li><code>delete_all</code> 557 <li><code>sign_data</code> 558 <li><code>verify_data</code> 559 </ul> 560 561 <h3 id=general_implementation_guidelines>General implementation guidelines</h3> 562 563 <p>The following guidelines apply to all functions in the API.</p> 564 565 <h4 id=input_pointer_parameters>Input pointer parameters</h4> 566 567 <p>Input pointer parameters that are not used for a given call may be <code>NULL</code>. 568 The caller is not required to provide placeholders. For example, some key 569 types and modes may not use any values from the <code>in_params</code> argument 570 to <a href="#begin">begin</a>, so the caller may set <code>in_params</code> 571 to <code>NULL</code> or provide an empty parameter set. It is also acceptable for the caller to 572 provide unused parameters, and Keymaster methods should not issue errors.</p> 573 574 <p>If a required input parameter is NULL, Keymaster methods should return 575 <code>KM_ERROR_UNEXPECTED_NULL_POINTER</code>.</p> 576 577 <h4 id=output_pointer_parameters>Output pointer parameters</h4> 578 579 <p>Similar to input pointer parameters, unused output pointer parameters 580 may be <code>NULL</code>. If a method needs to return data in an output 581 parameter found to be <code>NULL</code>, it should return <code>KM_ERROR_OUTPUT_PARAMETER_NULL</code>.</p> 582 583 <h4 id=api_misuse>API misuse</h4> 584 585 <p>There are many ways that callers can make requests that don't make sense or are 586 foolish but not technically wrong. Keymaster1 implementations are not required 587 to fail in such cases or issue a diagnostic. Use of too-small keys, 588 specification of irrelevant input parameters, reuse of IVs or nonces, 589 generation of keys with no purposes (hence useless) and the like should not be 590 diagnosed by implementations. Omission of required parameters, specification of 591 invalid required parameters, and similar errors must be diagnosed.</p> 592 593 <p>It is the responsibility of apps, the framework, and Android keystore to ensure 594 that the calls to Keymaster modules are sensible and useful.</p> 595 596 <h3 id=get_supported_algorithms>get_supported_algorithms</h3> 597 598 <p>Returns the list of algorithms supported by the Keymaster hardware 599 implementation. A software implementation must return an empty list; a hybrid 600 implementation must return a list containing only the algorithms that are 601 supported by hardware.</p> 602 603 <p>Keymaster1 implementations must support RSA, EC, AES and HMAC.</p> 604 605 <h3 id=get_supported_block_modes>get_supported_block_modes</h3> 606 607 <p>Returns the list of AES block modes supported by the Keymaster hardware 608 implementation for a specified algorithm and purpose.</p> 609 610 <p>For RSA, EC and HMAC, which are not block ciphers, the method must return an 611 empty list for all valid purposes. Invalid purposes should cause the method to 612 return <code>KM_ERROR_INVALID_PURPOSE</code>.</p> 613 614 <p>Keymaster1 implementations must support ECB, CBC, CTR and GCM for AES 615 encryption and decryption.</p> 616 617 <h3 id=get_supported_padding_modes>get_supported_padding_modes</h3> 618 619 <p>Returns the list of padding modes supported by the Keymaster hardware 620 implementation for a specified algorithm and purpose.</p> 621 622 <p>HMAC and EC have no notion of padding so the method must return an empty list 623 for all valid purposes. Invalid purposes should cause the method to return <code>KM_ERROR_INVALID_PURPOSE</code>.</p> 624 625 <p>For RSA, keymaster1 implementations must support:</p> 626 627 <ul> 628 <li>Unpadded encryption, decryption, signing and verification. For unpadded 629 encryption and signing, if the message is shorter than the public modulus, 630 implementations must left-pad it with zeros. For unpadded decryption and 631 verification, the input length must match the public modulus size. 632 <li>PKCS#1 v1.5 encryption and signing padding modes 633 <li>PSS with a minimum salt length of 20 634 <li>OAEP 635 </ul> 636 637 <p>For AES in ECB and CBC modes, keymaster1 implementations must support no 638 padding and PKCS#7-padding. CTR and GCM modes must support only no padding.</p> 639 640 <h3 id=get_supported_digests>get_supported_digests</h3> 641 642 <p>Returns the list of digest modes supported by the Keymaster hardware 643 implementation for a specified algorithm and purpose.</p> 644 645 <p>No AES modes support or require digesting, so the method must return an empty 646 list for valid purposes.</p> 647 648 <p>Keymaster1 implementations are allowed to implement a subset of the defined 649 digests, but must provide SHA-256. It is strongly recommended that keymaster1 650 implementations provide MD5, SHA1, SHA-224, SHA-256, SHA384 and SHA512 (the 651 full set of defined digests).</p> 652 653 <h3 id=get_supported_import_formats>get_supported_import_formats</h3> 654 655 <p>Returns the list of import formats supported by the Keymaster hardware 656 implementation of a specified algorithm.</p> 657 658 <p>Keymaster1 implementations must support the PKCS#8 format (without password 659 protection) for importing RSA and EC key pairs, and must support RAW import of 660 AES and HMAC key material.</p> 661 662 <h3 id=get_supported_export_formats>get_supported_export_formats</h3> 663 664 <p>Returns the list of export formats supported by the Keymaster hardware 665 implementation of a specified algorithm.</p> 666 667 <p>Keymaster1 implementations must support the X.509 format for exporting RSA and 668 EC public keys. Export of private keys or asymmetric keys must not be 669 supported.</p> 670 671 <h3 id=add_rng_entropy>add_rng_entropy</h3> 672 673 <p>Adds caller-provided entropy to the pool used by the Keymaster1 implementation 674 for generating random numbers, for keys, IVs, etc.</p> 675 676 <p>Keymaster1 implementations must <strong>securely</strong> mix the provided 677 entropy into their pool, which must also contain 678 internally-generated entropy from a hardware random number generator. Mixing 679 must have the property that an attacker with complete control of either 680 the <code>add_rng_entropy</code>-provided bits or the hardware-generated bits, but not both, cannot predict 681 bits generated from the entropy pool with probability greater than .</p> 682 683 <p>Keymaster1 implementations that attempt to estimate the entropy in their 684 internal pool must assume that data provided by <code>add_rng_entropy</code> contains no entropy.</p> 685 686 <h3 id=generate_key>generate_key</h3> 687 688 <p>Generates a new cryptographic key, specifying associated authorizations, which 689 will be permanently bound to the key. Keymaster1 implementations must make it 690 impossible to use a key in any way inconsistent with the authorizations 691 specified at generation time. With respect to authorizations that the secure 692 hardware cannot enforce, the secure hardware's obligation is limited to 693 ensuring that the unenforceable authorizations associated with the key cannot 694 be modified, so that every call to <a href="#get_key_characteristics">get_key_characteristics</a> 695 will return the original value. In addition, the characteristics returned by <code>generate_key</code> 696 must allocate authorizations correctly between the hardware-enforced and 697 software-enforced lists. See <a href="#get_key_characteristics">get_key_characteristics</a> 698 for more details.</p> 699 700 <p>The parameters that must be provided to <code>generate_key</code> depend on the type of key 701 being generated. This section will summarize the 702 required and allowed tags for each type of key. <a href="#km_tag_algorithm">KM_TAG_ALGORITHM</a> 703 is always required, to specify the type.</p> 704 705 <h4 id=rsa_keys>RSA keys</h4> 706 707 <p>The following parameters are required when generating an RSA key.</p> 708 709 <ul> 710 <li><a href="#km_tag_key_size">KM_TAG_KEY_SIZE</a> specifies the size of the public 711 modulus, in bits. If omitted, the method must 712 return <code>KM_ERROR_UNSUPPORTED_KEY_SIZE</code>. Values that must be supported are 713 1024, 2048, 3072 and 4096. It is 714 recommended to support all key sizes that are a multiple of 8. 715 <li><a href="#km_tag_rsa_public_exponent">KM_TAG_RSA_PUBLIC_EXPONENT</a> specifies 716 the RSA public exponent value. If omitted, the method must 717 return <code>KM_ERROR_INVALID_ARGUMENT</code>. 718 Implementations must support the values 3 and 65537. It is recommended to 719 support all prime values up to 2^64. 720 </ul> 721 722 <p>The following parameters are not required to generate an RSA key, but creating 723 an RSA key without them will produce a key that is unusable. 724 The <code>generate_key</code> function should not return an error if these parameters are omitted.</p> 725 726 <ul> 727 <li><a href="#km_tag_purpose">KM_TAG_PURPOSE</a> specifies allowed purposes. 728 All purposes must be supported for RSA keys, in 729 any combination. 730 <li><a href="#km_tag_digest">KM_TAG_DIGEST</a> specifies digest algorithms that 731 may be used with the new key. Implementations 732 that do not support all digest algorithms must accept key generation requests 733 that include unsupported digests. The unsupported digests should be placed in 734 the "software-enforced" list in the returned key characteristics. This is 735 because the key will be usable with those other digests, but digesting will be 736 performed in software. Then hardware will be called to perform the operation 737 with <code>KM_DIGEST_NONE</code>. 738 <li><a href="#km_tag_padding">KM_TAG_PADDING</a> specifies the padding modes 739 that may be used with the new key. Implementations 740 that do not support all digest algorithms must place <code>KM_PAD_RSA_PSS</code> 741 and <code>KM_PAD_RSA_OAEP</code> in the software-enforced list of the key 742 characteristics if any unsupported 743 digest algorithms are specified. 744 </ul> 745 746 <h4 id=ecdsa_keys>ECDSA keys</h4> 747 748 <p>Only <a href="#km_tag_key_size">KM_TAG_KEY_SIZE</a> is required to generate an 749 ECDSA key. It is used to select the EC group. 750 Implementations must support values 224, 256, 384 and 521, which indicate the 751 NIST p-224, p-256, p-384 and p521 curves, respectively.</p> 752 753 <p><a href="#km_tag_digest">KM_TAG_DIGEST</a> is also needed for a useful ECDSA key, 754 but is not required for generation.</p> 755 756 <h4 id=aes_keys>AES keys</h4> 757 758 <p>Only <a href="#km_tag_key_size">KM_TAG_KEY_SIZE</a> is required when 759 generating an AES key. If omitted, the method must return <code>KM_ERROR_UNSUPPORTED_KEY_SIZE</code>. 760 Values that must be supported are 128 and 256. It is recommended to support 761 192-bit AES keys.</p> 762 763 <p>The following parameters are particularly relevant for AES keys, but not 764 required to generate one:</p> 765 766 <ul> 767 <li><code>KM_TAG_BLOCK_MODE</code> specifies the block modes with which the new key may be used. 768 <li><code>KM_TAG_PADDING</code> specifies the padding modes that may be used. This is only relevant for ECB 769 and CBC modes. 770 </ul> 771 772 <p>If the GCM block mode is specified, then <a href="#km_tag_min_mac_length">KM_TAG_MIN_MAC_LENGTH</a> 773 must be provided. If omitted, the method must return 774 <code>KM_ERROR_MISSING_MIN_MAC_LENGTH</code>. The value of the tag must be a multiple of 8 and must 775 be at least 96 and no more than 128.</p> 776 777 <h4 id=hmac_keys>HMAC keys</h4> 778 779 <p>The following parameters are required for HMAC key generation:</p> 780 781 <ul> 782 <li><a href="#km_tag_key_size">KM_TAG_KEY_SIZE</a> specifies the key size in bits. Values 783 smaller than 64 and values that are not 784 multiples of 8 must not be supported. All multiples of 8, from 64 to 512, must 785 be supported. Larger values may be supported. 786 <li><a href="#km_tag_min_mac_length">KM_TAG_MIN_MAC_LENGTH</a> specifies the minimum length of 787 MACs that can be generated or verified with 788 this key. The value must be a multiple of 8 and must be at least 64. 789 <li><a href="#km_tag_digest">KM_TAG_DIGEST</a> specifies the digest algorithm for the key. Exactly 790 one digest must be 791 specified, otherwise return <code>KM_ERROR_UNSUPPORTED_DIGEST</code>. If the digest is not supported 792 by the trustlet, return <code>KM_ERROR_UNSUPPORTED_DIGEST</code>. 793 </ul> 794 795 <h4 id=key_characteristics>Key characteristics</h4> 796 797 <p>If the characteristics argument is non-NULL, <code>generate_key</code> must return the newly-generated 798 key's characteristics divided appropriately 799 into hardware-enforced and software-enforced lists. See <a href="#get_key_characteristics">get_key_characteristics</a> 800 for a description of which characteristics go in which list. The returned 801 characteristics must include all of the parameters specified to key generation, 802 except <a href="#km_tag_application_id">KM_TAG_APPLICATION_ID</a> and 803 <a href="#km_tag_application_data">KM_TAG_APPLICATION_DATA</a>. 804 If these tags were included in the key parameters, they must be removed from 805 the returned characteristics; it must not be possible to find their values by 806 examining the returned key blob. However, they must be cryptographically bound 807 to the key blob, so that if the correct values are not provided when the key is 808 used, usage will fail. Similarly, <a href="#km_tag_root_of_trust">KM_TAG_ROOT_OF_TRUST</a> must 809 be cryptographically bound to the key, but it may not be specified during 810 key creation or import and must never be returned.</p> 811 812 <p>In addition to the provided tags, the trustlet must also 813 add <a href="#km_tag_origin">KM_TAG_ORIGIN</a>, with the value <code>KM_ORIGIN_GENERATED</code>, 814 and if the key is rollback resistant, <a href="#km_tag_rollback_resistant">KM_TAG_ROLLBACK_RESISTANT</a>.</p> 815 816 <h4 id=rollback_resistance>Rollback resistance </h4> 817 818 <p>Rollback resistance means that once a key is deleted with 819 <a href="#delete_key">delete_key</a> or <a href="#delete_all_keys">delete_all_keys</a>, 820 it is guaranteed by secure hardware never to be usable again. Implementations 821 without rollback resistance will typically return generated or imported key 822 material to the caller as a key blob, an encrypted and authenticated form. When 823 keystore deletes the key blob, the key is gone, but an attacker who has 824 previously managed to retrieve the key material can potentially restore it to 825 the device.</p> 826 827 <p>A key is rollback resistant if the secure hardware guarantees that deleted keys 828 cannot be restored later. This is generally done by storing additional key 829 metadata in a trusted location that cannot be manipulated by an attacker. On 830 mobile devices, the mechanism used for this is usually Replay Protected Memory 831 Blocks (RPMB). Because the number of keys that may be created is essentially 832 unbounded and the trusted storage used for rollback resistance may be limited 833 in size, it is required that this method succeed even if rollback resistance 834 cannot be provided for the new key. In that case, 835 <a href="#km_tag_rollback_resistant">KM_TAG_ROLLBACK_RESISTANT</a> should not be 836 added to the key characteristics.</p> 837 838 <h3 id=get_key_characteristics>get_key_characteristics</h3> 839 840 <p>Returns parameters and authorizations associated with the provided key, divided 841 into two sets: hardware-enforced and software-enforced. The description here 842 applies equally to the key characteristics lists returned 843 by <a href="#generate_key">generate_key</a> and <a href="#import_key">import_key</a>.</p> 844 845 <p>If <code>KM_TAG_APPLICATION_ID</code> was provided during key generation 846 or import, the same value must provided to 847 this method in the <code>client_id</code> argument. Otherwise, the 848 method must return <code>KM_ERROR_INVALID_KEY_BLOB</code>. Similarly, 849 if <code>KM_TAG_APPLICATION_DATA </code>was provided during generation 850 or import, the same value must be provided to 851 this method in the <code>app_data</code> argument.</p> 852 853 <p>The characteristics returned by this method completely describe the type and 854 usage of the specified key.</p> 855 856 <p>The general rule for deciding whether a given tag belongs in the 857 hardware-enforced or software-enforced list is that if the meaning of the tag 858 is fully assured by secure hardware, it is hardware-enforced. Otherwise, it's 859 software enforced. Below is a list of specific tags whose correct allocation 860 may be unclear:</p> 861 862 <ul> 863 <li><a href="#km_tag_algorithm">KM_TAG_ALGORITHM</a>, <a href="#km_tag_key_size">KM_TAG_KEY_SIZE</a>, 864 and <a href="#km_tag_rsa_public_exponent">KM_TAG_RSA_PUBLIC_EXPONENT</a> are 865 intrinsic properties of the key. For any key that is secured by hardware, 866 these will be in the hardware-enforced list, because the statement that, for 867 example, "This RSA key material is only used as an RSA key" is enforced by 868 hardware because the hardware will use it in no other way and software has no 869 access to the key material and cannot use it at all. 870 <li><a href="#km_tag_digest">KM_TAG_DIGEST</a> values that are supported by the 871 secure hardware are to be placed in the 872 hardware-supported list. Unsupported digests go in the software-supported list. 873 <li><a href="#km_tag_padding">KM_TAG_PADDING</a> values generally go in the 874 hardware-supported list, but if there is a 875 possibility that a specific padding mode may have to be performed by software, 876 they go in the software-enforced list. Such a possibility arises for RSA keys 877 that permit PSS or OAEP padding with digest algorithms that are not supported 878 by the secure hardware. 879 <li><a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a> and 880 <a href="#km_tag_mac_length">KM_TAG_USER_AUTH_TYPE</a> are hardware-enforced 881 only if user authentication is hardware enforced. For 882 that to be true, the Keymaster trustlet and the relevant authentication 883 trustlet must both be secure and must share a secret HMAC key used to sign and 884 validate authentication tokens. See the Authentication page for details. 885 <li><a href="#km_tag_active_datetime">KM_TAG_ACTIVE_DATETIME</a>, 886 <a href="#km_tag_origination_expire_datetime">KM_TAG_ORIGINATION_EXPIRE_DATETIME</a>, 887 and <a href="#km_tag_usage_expire_datetime">KM_TAG_USAGE_EXPIRE_DATETIME</a> tags 888 require access to a verifiably correct wall clock. Most secure hardware 889 will only have access to time information provided by the non-secure OS, which 890 means the tags are software-enforced. 891 <li><a href="#km_tag_origin">KM_TAG_ORIGIN</a> is always in the hardware list for 892 hardware-bound keys. Its presence in that 893 list is the way higher layers determine that a key is hardware-backed. 894 </ul> 895 896 <h3 id=import_key>import_key</h3> 897 898 <p>Imports key material into Keymaster hardware. Key definition parameters and 899 output characteristics are handled the same as for <code>generate_key</code>, 900 with the following exceptions:</p> 901 902 <ul> 903 <li><a href="#km_tag_key_size">KM_TAG_KEY_SIZE</a> and 904 <a href="#km_tag_rsa_public_exponent">KM_TAG_RSA_PUBLIC_EXPONENT</a> (for RSA keys only) 905 are not required in the input parameters. If not provided, 906 the trustlet must deduce the values from the provided key material and add 907 appropriate tags and values to the key characteristics. If the parameters are 908 provided, the trustlet must validate them against the key material. In the 909 event of a mismatch, the method must return <code>KM_ERROR_IMPORT_PARAMETER_MISMATCH</code>. 910 <li>The returned <a href="#km_tag_origin">KM_TAG_ORIGIN</a> must have the 911 value <code>KM_ORIGIN_IMPORTED</code>. 912 </ul> 913 914 <h3 id=export_key>export_key</h3> 915 916 <p>Exports a public key from a Keymaster RSA or EC key pair.</p> 917 918 <p>If <code>KM_TAG_APPLICATION_ID</code> was provided during key generation or import, 919 the same value must provided to 920 this method in the <code>client_id</code> argument. Otherwise, the method must return 921 <code>KM_ERROR_INVALID_KEY_BLOB</code>. Similarly, if <code>KM_TAG_APPLICATION_DATA</code> 922 was provided during generation or import, the same value must be provided to 923 this method in the <code>app_data</code> argument.</p> 924 925 <h3 id=delete_key>delete_key</h3> 926 927 <p>Deletes the provided key. This method is optional, and will likely be 928 implemented only by Keymaster modules that provide rollback resistance.</p> 929 930 <h3 id=delete_all_keys>delete_all_keys</h3> 931 932 <p>Deletes all keys. This method is optional, and will likely be implemented only 933 by Keymaster modules that provide rollback resistance.</p> 934 935 <h3 id=begin>begin</h3> 936 937 <p>Begins a cryptographic operation, using the specified key, for the specified 938 purpose, with the specified parameters (as appropriate), and returns an 939 operation handle which is used with <a href="#update">update</a> and <a 940 href="#finish">finish</a> to complete the operation. The operation handle is 941 also used as the "challenge" token in authenticated operations, and for such 942 operations must be included in the <code>challenge</code> field of the 943 authentication token.</p> 944 945 <p>A Keymaster implementation must support at least 16 concurrent 946 operations. Keystore will use up to 15, leaving one for vold to use for password 947 encryption. When Keystore has 15 operations in progress (<code>begin</code> has 948 been called, but <code>finish</code> or <code>abort</code> have not yet been 949 called) and it receives a request to begin a 16th, it will call 950 <code>abort</code> on the least-recently used operation to reduce the number of 951 active operations to 14 before calling <code>begin</code> to start the 952 newly-requested operation. 953 954 <p>If <a href="#km_tag_application_id">KM_TAG_APPLICATION_ID</a> or <a 955 href="#km_tag_application_data">KM_TAG_APPLICATION_DATA</a> were specified 956 during key generation or import, calls to <code>begin</code> must include those 957 tags with the originally-specified values in the <code>in_params</code> argument 958 to this method.</p> 959 960 <h4 id=authorization_enforcement>Authorization enforcement</h4> 961 962 <p>During this method, the following key authorizations must be enforced by the 963 trustlet if the implementation placed them in the "hardware-enforced" 964 characteristics and if the operation is not a public key operation. Public key 965 operations, meaning <code>KM_PURPOSE_ENCRYPT</code> and <code>KM_PURPOSE_VERIFY</code>, 966 with RSA or EC keys, must be allowed to succeed even if authorization 967 requirements are not met.</p> 968 969 <ul> 970 <li><a href="#km_tag_purpose">KM_TAG_PURPOSE</a> requires that the purpose specified 971 for this method match one of the purposes 972 in the key authorizations, unless the requested operation is a public key 973 operation, meaning that the key is RSA or EC and the purpose is <code>KM_PURPOSE_ENCRYPT</code> 974 or <code>KM_PURPOSE_VERIFY</code>. Note that <code>KM_PURPOSE_ENCRYPT</code> is not valid for EC keys. 975 Begin should return <code>KM_ERROR_UNSUPPORTED_PURPOSE</code> in that case. 976 <li><a href="#km_tag_active_datetime">KM_TAG_ACTIVE_DATETIME</a> requires comparison with a trusted 977 UTC time source. If the current date and 978 time is prior to the tag value, the method must return <code>KM_ERROR_KEY_NOT_YET_VALID</code>. 979 <li><a href="#km_tag_origination_expire_datetime">KM_TAG_ORIGINATION_EXPIRE_DATETIME</a> requires 980 comparison with a trusted UTC time source. If the current date and 981 time is later than the tag value and the purpose is <code>KM_PURPOSE_ENCRYPT</code> or <code>KM_PURPOSE_SIGN</code>, 982 the method must return <code>KM_ERROR_KEY_EXPIRED</code>. 983 <li><a href="#km_tag_usage_expire_datetime">KM_TAG_USAGE_EXPIRE_DATETIME</a> requires comparison with a 984 trusted UTC time source. If the current date and 985 time is later than the tag value and the purpose is <code>KM_PURPOSE_DECRYPT</code> or <code>KM_PURPOSE_VERIFY</code>, 986 the method must return <code>KM_ERROR_KEY_EXPIRED</code>. 987 <li><a href="#km_tag_min_seconds_between_ops">KM_TAG_MIN_SECONDS_BETWEEN_OPS</a> requires comparison with a 988 trusted relative timer indicating the last use of 989 the key. If the last use time plus the tag value is less than the current time, 990 the method must return <code>KM_ERROR_KEY_RATE_LIMIT_EXCEEDED</code>. See the tag description for 991 important implementation requirements. 992 <li><a href="#km_tag_max_uses_per_boot">KM_TAG_MAX_USES_PER_BOOT</a> requires comparison against a 993 secure counter that tracks the uses of the key 994 since boot time. If the count of previous uses exceeds the tag value, the 995 method must return <code>KM_ERROR_KEY_MAX_OPS_EXCEEDED</code>. 996 <li><a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a> is enforced by this method only 997 if the key also has <a href="#km_tag_auth_timeout">KM_TAG_AUTH_TIMEOUT</a>. If the key has both, 998 then this method must have received a <a href="#km_tag_auth_token">KM_TAG_AUTH_TOKEN</a> in 999 <code>in_params</code> and that token must be valid, meaning that the HMAC field validates correctly. 1000 In addition, at least one of the <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a> 1001 values from the key must match at least one of the secure ID values in the 1002 token. Finally, the key must also have a <a href="#km_tag_mac_length">KM_TAG_USER_AUTH_TYPE</a> and 1003 it must match the auth type in the token. If any of these requirements is 1004 not met, the method must return <code>KM_ERROR_KEY_USER_NOT_AUTHENTICATED</code>. 1005 <li><a href="#km_tag_caller_nonce">KM_TAG_CALLER_NONCE</a> allows the caller to specify a nonce 1006 or initialization vector (IV). If the key 1007 does not have this tag but the caller provided <a href="#km_tag_nonce">KM_TAG_NONCE</a> to this method, 1008 <code>KM_ERROR_CALLER_NONCE_PROHIBITED</code> must be returned. 1009 <li><a href="#km_tag_bootloader_only">KM_TAG_BOOTLOADER_ONLY</a> specifies that the key may only be 1010 used by the bootloader. If this method is 1011 called with a bootloader-only key after the bootloader has finished executing, 1012 it must return <code>KM_ERROR_INVALID_KEY_BLOB</code>. 1013 </ul> 1014 1015 <h4 id=rsa_keys>RSA keys</h4> 1016 1017 <p>All RSA key operations must specify exactly one padding mode in <code>in_params</code>. If 1018 unspecified or specified more than once, the method must return <code>KM_ERROR_UNSUPPORTED_PADDING_MODE</code>.</p> 1019 1020 <p>RSA signing and verification operations require a digest, as do RSA encryption 1021 and decryption operations with OAEP padding mode. For those cases, the caller 1022 must specify exactly one digest in <code>in_params</code>. If unspecified or specified more than once, 1023 the method must return <code>KM_ERROR_UNSUPPORTED_DIGEST</code>.</p> 1024 1025 <p>Private key operations (<code>KM_PURPOSE_DECYPT</code> and <code>KM_PURPOSE_SIGN</code>) require 1026 authorization of digest and padding, which means that the specified 1027 values must be in the key authorizations. If not, the method must return <code>KM_ERROR_INCOMPATIBLE_DIGEST</code> 1028 or <code>KM_ERROR_INCOMPATIBLE_PADDING</code>, as appropriate. Public key operations 1029 (<code>KM_PURPOSE_ENCRYPT</code> and <code>KM_PURPOSE_VERIFY</code>) are permitted with 1030 unauthorized digest or padding.</p> 1031 1032 <p>With the exception of <code>KM_PAD_NONE</code>, all RSA padding modes are applicable only to 1033 certain purposes. Specifically, <code>KM_PAD_RSA_PKCS1_1_5_SIGN</code> and <code>KM_PAD_RSA_PSS</code> 1034 only support signing and verification, while <code>KM_PAD_RSA_PKCS1_1_1_5_ENCRYPT</code> and 1035 <code>KM_PAD_RSA_OAEP</code> only support encryption and decryption. The method must return 1036 <code>KM_ERROR_UNSUPPORTED_PADDING_MODE</code> if the specified mode does not support the specified purpose.</p> 1037 1038 <p>There are some important interactions between padding modes and digests:</p> 1039 1040 <ul> 1041 1042 <li><code>KM_PAD_NONE</code> indicates that a "raw" RSA operation will be 1043 performed. If signing or verifying, <code>KM_DIGEST_NONE</code> must be 1044 specified for the digest. No digest is required for unpadded encryption or 1045 decryption. 1046 1047 <li><code>KM_PAD_RSA_PKCS1_1_5_SIGN</code> padding requires a digest. The 1048 digest may be <code>KM_DIGEST_NONE</code>, in which case the Keymaster 1049 implementation cannot build a proper PKCS#1 v1.5 signature structure, because 1050 it cannot add the DigestInfo structure. Instead, the implementation must 1051 construct <code>0x00 || 0x01 || PS || 0x00 || M</code>, where M is the 1052 provided message and PS is the padding string. The size of the RSA key must be 1053 at least 11 bytes larger than the message, otherwise the method must return 1054 <code>KM_ERROR_INVALID_INPUT_LENGTH</code>. 1055 1056 <li><code>KM_PAD_RSA_PKCS1_1_1_5_ENCRYPT</code> padding does not require a digest. 1057 1058 <li><code>KM_PAD_RSA_PSS</code> padding requires a digest, which may not be 1059 <code>KM_DIGEST_NONE</code>. If <code>KM_DIGEST_NONE</code> is specified, the 1060 method must return <code>KM_ERROR_INCOMPATIBLE_DIGEST</code>. In addition, the 1061 size of the RSA key must be at least 22 bytes larger than the output size of 1062 the digest. Otherwise, the method must return 1063 <code>KM_ERROR_INCOMPATIBLE_DIGEST</code>. 1064 1065 <li><code>KM_PAD_RSA_OAEP</code> padding requires a digest, which may not be 1066 <code>KM_DIGEST_NONE</code>. If <code>KM_DIGEST_NONE</code> is specified, the 1067 method must return <code>KM_ERROR_INCOMPATIBLE_DIGEST</code>. 1068 1069 </ul> 1070 1071 <h4 id=ec_keys>EC keys</h4> 1072 1073 <p>EC key operations must specify exactly one padding mode in <code>in_params</code>. 1074 If unspecified or specified more than once, 1075 return <code>KM_ERROR_UNSUPPORTED_PADDING_MODE</code>.</p> 1076 1077 <p>Private key operations (<code>KM_PURPOSE_SIGN</code>) require authorization of the 1078 digest, which means that the specified value must be in the key authorizations. 1079 If not, return <code>KM_ERROR_INCOMPATIBLE_DIGEST</code>. 1080 Public key operations (<code>KM_PURPOSE_VERIFY</code>) are permitted with unauthorized digest or padding.</p> 1081 1082 <h4 id=aes_keys>AES keys</h4> 1083 1084 <p>AES key operations must specify exactly one block mode and one padding mode in <code>in_params</code>. 1085 If either value is unspecified or specified more than once, return <code>KM_ERROR_UNSUPPORTED_BLOCK_MODE</code> or 1086 <code>KM_ERROR_UNSUPPORTED_PADDING_MODE</code>. The specified modes must be authorized by the key. 1087 Otherwise, the method must 1088 return <code>KM_ERROR_INCOMPATIBLE_BLOCK_MODE</code> or <code>KM_ERROR_INCOMPATIBLE_PADDING_MODE</code>.</p> 1089 1090 <p>If the block mode is <code>KM_MODE_GCM</code>, <code>in_params</code> must specify <code>KM_TAG_MAC_LENGTH</code>, and the 1091 specified value must be a multiple of 8 and must not be greater than 1092 128, or less than the value of <code>KM_TAG_MIN_MAC_LENGTH</code> in the key authorizations. For MAC lengths greater than 128 or non-multiples of 1093 8, return <code>KM_ERROR_UNSUPPORTED_MAC_LENGTH</code>. For values less than the key's minimum length, return <code>KM_ERROR_INVALID_MAC_LENGTH</code>.</p> 1094 1095 <p>If the block mode is <code>KM_MODE_GCM</code> or <code>KM_MODE_CTR</code>, the specified padding mode must 1096 be <code>KM_PAD_NONE</code>. For <code>KM_MODE_ECB</code> or <code>KM_MODE_CBC</code>, the mode may 1097 be <code>KM_PAD_NONE</code> or <code>KM_PAD_PKCS7</code>. If the padding mode doesn't meet these 1098 requirements, return <code>KM_ERROR_INCOMPATIBLE_PADDING_MODE</code>.</p> 1099 1100 <p>If the block mode is <code>KM_MODE_CBC</code>, <code>KM_MODE_CTR</code>, or <code>KM_MODE_GCM</code>, an initialization vector or nonce is needed. 1101 In most cases, callers should not 1102 provide an IV or nonce and the Keymaster implementation must generate a random 1103 IV or nonce and return it via <a href="#km_tag_nonce">KM_TAG_NONCE</a> in <code>out_params</code>. CBC 1104 and CTR IVs are 16 bytes. GCM nonces are 12 bytes. If the key 1105 authorizations contain <a href="#km_tag_caller_nonce">KM_TAG_CALLER_NONCE</a>, then the caller may 1106 provide an IV/nonce with <a href="#km_tag_nonce">KM_TAG_NONCE</a> in <code>in_params</code>. If a 1107 nonce is provided when <a href="#km_tag_caller_nonce">KM_TAG_CALLER_NONCE</a> is not authorized, 1108 return <code>KM_ERROR_CALLER_NONCE_PROHIBITED</code>. If a nonce is not provided when 1109 <a href="#km_tag_caller_nonce">KM_TAG_CALLER_NONCE</a> is authorized, generate a random IV/nonce.</p> 1110 1111 <h4 id=hmac_keys>HMAC keys</h4> 1112 1113 <p>HMAC key operations must specify <code>KM_TAG_MAC_LENGTH</code> in <code>in_params</code>. 1114 The specified value must be a multiple of 8 and must not be greater than the 1115 digest length, or less than the value of <code>KM_TAG_MIN_MAC_LENGTH</code> in the key authorizations. 1116 For MAC lengths greater than the digest length or 1117 non-multiples of 8, return <code>KM_ERROR_UNSUPPORTED_MAC_LENGTH</code>. For values less than 1118 the key's minimum length, return <code>KM_ERROR_INVALID_MAC_LENGTH</code>.</p> 1119 1120 <h3 id=update>update</h3> 1121 1122 <p>Provides data to process in an ongoing operation started with <a href="#begin">begin</a>. 1123 The operation is specified by the <code>operation_handle</code> parameter.</p> 1124 1125 <p>To provide more flexibility for buffer handling, implementations of this method 1126 have the option of consuming less data than was provided. The caller is 1127 responsible for looping to feed the rest of the data in subsequent calls. The 1128 amount of input consumed must be returned in the <code>input_consumed</code> parameter. 1129 Implementations must always consume at least one byte, unless the 1130 operation cannot accept any more; if more than zero bytes are provided and zero 1131 bytes are consumed, callers will consider this an error and abort the 1132 operation.</p> 1133 1134 <p>Implementations may also choose how much data to return, as a result of the 1135 update. This is only relevant for encryption and decryption operations, since 1136 signing and verification return no data until <a href="#finish">finish</a>. It is recommended 1137 to return data as early as possible, rather than buffer it.</p> 1138 1139 <h4 id=error_handling>Error handling</h4> 1140 1141 <p>If this method returns an error code other than <code>KM_ERROR_OK</code>, the operation is 1142 aborted and the operation handle must be invalidated. Any 1143 future use of the handle, with this method or <a href="#finish">finish</a> or <a href="#abort">abort</a>, 1144 must return <code>KM_ERROR_INVALID_OPERATION_HANDLE</code>.</p> 1145 1146 <h4 id=authorization_enforcement>Authorization enforcement</h4> 1147 1148 <p>Key authorization enforcement is performed primarily in <a href="#begin">begin</a>. The one exception 1149 is the case where the key has:</p> 1150 1151 <ul> 1152 <li>One or more <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_IDs</a>, and 1153 <li>Does not have a <a href="#km_tag_auth_timeout">KM_TAG_AUTH_TIMEOUT</a> 1154 </ul> 1155 1156 <p>In this case, the key requires an authorization per operation, and the update 1157 method must receive a <a href="#km_tag_auth_token">KM_TAG_AUTH_TOKEN</a> in the <code>in_params</code> argument. 1158 The token must be valid (HMAC must verify) and it must contain a 1159 matching secure user ID, must match the key's <a href="#km_tag_mac_length">KM_TAG_USER_AUTH_TYPE</a>, and must 1160 contain the operation handle of the current operation in the 1161 challenge field. If these requirements aren't met, return <code>KM_ERROR_KEY_USER_NOT_AUTHENTICATED</code>.</p> 1162 1163 <p>The caller must provide the authentication token to every call to <a href="#update">update</a> and 1164 <a href="#finish">finish</a>. The implementation need only validate the token once if it prefers.</p> 1165 1166 <h4 id=rsa_keys>RSA keys</h4> 1167 1168 <p>For signing and verification operations with <code>KM_DIGEST_NONE</code>, this method must accept 1169 the entire block to be signed or verified in a single 1170 update. It may not consume only a portion of the block. It still must accept 1171 the data in multiple updates if the caller chooses to provide it that way, 1172 however. If the caller provides more data to sign than can be used (length of 1173 data exceeds RSA key size), return <code>KM_ERROR_INVALID_INPUT_LENGTH</code>.</p> 1174 1175 <h4 id=ecdsa_keys>ECDSA keys</h4> 1176 1177 <p>For signing and verification operations with <code>KM_DIGEST_NONE</code>, this method must accept the 1178 entire block to be signed or verified in a single 1179 update. This method may not consume only a portion of the block.</p> 1180 1181 <p>However, this method still must accept the data in multiple updates if the 1182 caller chooses to provide it that way. If the caller provides more data to sign 1183 than can be used, the data should be silently truncated. (This differs from the 1184 handling of excess data provided in similar RSA operations. The reason for this 1185 is compatibility with legacy clients.)</p> 1186 1187 <h4 id=aes_keys>AES keys</h4> 1188 1189 <p>AES GCM mode supports "associated authentication data," provided via the 1190 <a href="#km_tag_associated_data">KM_TAG_ASSOCIATED_DATA</a> tag in the <code>in_params</code> argument. 1191 The associated data may be provided in repeated calls (important if 1192 the data is too large to send in a single block) but must always precede data 1193 to be encrypted or decrypted. An update call may receive both associated data 1194 and data to encrypt/decrypt, but subsequent updates may not include associated 1195 data. If the caller provides associated data to an update call after a call 1196 that includes data to encrypt/decrypt, return <code>KM_ERROR_INVALID_TAG</code>.</p> 1197 1198 <p>For GCM encryption, the tag is appended to the ciphertext by <a href="#finish">finish</a>. 1199 During decryption, the last <code>KM_TAG_MAC_LENGTH</code> bytes of the data provided to the last 1200 update call is the tag. Since a given 1201 invocation of <a href="#update">update</a> cannot know if it's the last invocation, it must process all but the tag 1202 length and buffer the possible tag data for processing during <a href="#finish">finish</a>.</p> 1203 1204 <h3 id=finish>finish</h3> 1205 1206 <p>Finished an ongoing operation started with <a href="#begin">begin</a>, processing all of the 1207 as-yet-unprocessed data provided by <a href="#update">update</a>(s).</p> 1208 1209 <p>This method is the last one called in an operation, so all processed data must 1210 be returned.</p> 1211 1212 <p>Whether it completes successfully or returns an error, this method finalizes 1213 the operation and therefore invalidates the provided operation handle. Any 1214 future use of the handle, with this method or <a href="#update">update</a> or 1215 <a href="#abort">abort</a>, must return <code>KM_ERROR_INVALID_OPERATION_HANDLE</code>.</p> 1216 1217 <p>Signing operations return the signature as the output. Verification operations 1218 accept the signature in the <code>signature</code> parameter, and return no output.</p> 1219 1220 <h4 id=authorization_enforcement>Authorization enforcement</h4> 1221 1222 <p>Key authorization enforcement is performed primarily in <a href="#begin">begin</a>. The one exception is the case where the key has:</p> 1223 1224 <ul> 1225 <li>One or more <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_IDs</a>, and 1226 <li>Does not have a <a href="#km_tag_auth_timeout">KM_TAG_AUTH_TIMEOUT</a> 1227 </ul> 1228 1229 <p>In this case, the key requires an authorization per operation, and the update 1230 method must receive a <a href="#km_tag_auth_token">KM_TAG_AUTH_TOKEN</a> in the <code>in_params</code> argument. 1231 The token must be valid (HMAC must verify) and it must contain a 1232 matching secure user ID, must match the key's <a href="#km_tag_mac_length">KM_TAG_USER_AUTH_TYPE</a>, and must 1233 contain the operation handle of the current operation in the 1234 challenge field. If these requirements aren't met, return <code>KM_ERROR_KEY_USER_NOT_AUTHENTICATED</code>.</p> 1235 1236 <p>The caller must provide the authentication token to every call to <a href="#update">update</a> and <a href="#finish">finish</a>. 1237 The implementation need only validate the token once if it prefers.</p> 1238 1239 <h4 id=rsa_keys>RSA keys</h4> 1240 1241 <p>Some additional requirements, depending on the padding mode:</p> 1242 1243 <ul> 1244 <li><strong>KM_PAD_NONE</strong>. For unpadded signing and encryption operations, if the provided data is 1245 shorter than the key, the data must be zero-padded on the left before 1246 signing/encryption. If the data is the same length as the key but numerically 1247 larger, return <code>KM_ERROR_INVALID_ARGUMENT</code>. For verification and decryption operations, the data must be exactly as long 1248 as the key. Otherwise, return <code>KM_ERROR_INVALID_INPUT_LENGTH.</code> 1249 <li><strong>KM_PAD_RSA_PSS</strong>. For PSS-padded signature operations, the PSS salt must be at least 20 bytes 1250 in length and randomly-generated. The salt may be longer; the reference 1251 implementation uses maximally-sized salt. The digest specified with <a href="#km_tag_digest">KM_TAG_DIGEST</a> in 1252 <code>input_params</code> on <a href="#begin">begin</a> is used as the PSS digest algorithm, and SHA1 is used as the MGF1 digest 1253 algorithm. 1254 <li><strong>KM_PAD_RSA_OAEP</strong>. The digest specified with <a href="#km_tag_digest">KM_TAG_DIGEST</a> in 1255 <code>input_params</code> on <a href="#begin">begin</a> is used as the OAEP digest algorithm, and SHA1 is used as the MGF1 digest 1256 algorithm. 1257 </ul> 1258 1259 <h4 id=ecdsa_keys>ECDSA keys</h4> 1260 1261 <p>If the data provided for unpadded signing or verification is too long, truncate 1262 it.</p> 1263 1264 <h4 id=aes_keys>AES keys</h4> 1265 1266 <p>Some additional requirements, depending on block mode:</p> 1267 1268 <ul> 1269 <li><strong>KM_MODE_ECB</strong> or <strong>KM_MODE_CBC</strong>. If padding is <code>KM_PAD_NONE</code> and the 1270 data length is not a multiple of the AES block size, return <code>KM_ERROR_INVALID_INPUT_LENGTH</code>. If 1271 padding is <code>KM_PAD_PKCS7</code>, pad the data per the PKCS#7 specification. Note that PKCS#7 requires that if 1272 the data is a multiple of the block length, an additional padding block must be 1273 added. 1274 <li><strong>KM_MODE_GCM</strong>. During encryption, after processing all plaintext, compute the 1275 tag (<a href="#km_tag_mac_length">KM_TAG_MAC_LENGTH</a> bytes) and append it to the returned ciphertext. 1276 During decryption, process 1277 the last <a href="#km_tag_mac_length">KM_TAG_MAC_LENGTH</a> bytes as the tag. If tag verification fails, 1278 return <code>KM_ERROR_VERIFICATION_FAILED</code>. 1279 </ul> 1280 1281 <h3 id=abort>abort</h3> 1282 1283 <p>Aborts the in-progress operation. After the call to abort, return <code>KM_ERROR_INVALID_OPERATION_HANDLE</code> for 1284 any subsequent use of the provided operation handle with <a href="#update">update</a>, 1285 <a href="#finish">finish</a>, or <a href="#abort">abort</a>.</p> 1286 1287 </body> 1288 </html> 1289