Tính năng

Trang này chứa thông tin về các tính năng mật mã của Kho khoá Android, do việc triển khai KeyMint (hoặc Keymaster) cơ bản cung cấp.

Nguyên hàm mật mã

Keystore cung cấp các danh mục thao tác sau:

  • Tạo khoá, dẫn đến việc chỉ môi trường bảo mật mới có thể truy cập vào nội dung khoá riêng tư hoặc khoá bí mật. Ứng dụng có thể tạo khoá theo những cách sau:
    • Tạo khoá mới
    • Nhập tài liệu khoá chưa mã hoá
    • Nhập tài liệu khoá đã mã hoá
  • Chứng thực khoá: Việc tạo khoá bất đối xứng sẽ tạo ra một chứng chỉ chứa phần khoá công khai của cặp khoá. Giấy chứng nhận này cũng có thể chứa thông tin về siêu dữ liệu cho khoá và trạng thái của thiết bị (tất cả đều được ký bằng một khoá liên kết trở lại một gốc đáng tin cậy).
  • Các thao tác mã hoá:
    • Mã hoá và giải mã đối xứng (AES, 3DES)
    • Giải mã bất đối xứng (RSA)
    • Ký bất đối xứng (ECDSA, RSA)
    • Ký và xác minh đối xứng (HMAC)
    • Thoả thuận về khoá bất đối xứng (ECDH)

Xin lưu ý rằng Keystore và KeyMint không xử lý các thao tác khoá công khai cho khoá bất đối xứng.

Các phần tử giao thức, chẳng hạn như mục đích, chế độ và khoảng đệm, cũng như các ràng buộc về kiểm soát truy cập, được chỉ định khi khoá được tạo hoặc nhập và được liên kết vĩnh viễn với khoá, đảm bảo khoá không thể được sử dụng theo bất kỳ cách nào khác.

Ngoài danh sách trên, còn có một dịch vụ khác mà các hoạt động triển khai KeyMint (trước đây là Keymaster) cung cấp, nhưng không được hiển thị dưới dạng API: Tạo số ngẫu nhiên. Đây là phương thức được dùng nội bộ để tạo khoá, vectơ khởi tạo (IV), khoảng đệm ngẫu nhiên và các phần tử khác của giao thức bảo mật yêu cầu tính ngẫu nhiên.

Các thành phần cơ bản cần thiết

Tất cả các cách triển khai KeyMint đều cung cấp:

  • RSA
    • Hỗ trợ khoá 2048, 3072 và 4096 bit
    • Hỗ trợ số mũ công khai F4 (2^16+1)
    • Chế độ đệm để ký RSA:
      • RSASSA-PSS (PaddingMode::RSA_PSS)
      • RSASSA-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_SIGN)
    • Các chế độ tóm tắt để ký RSA:
      • SHA-256
    • Các chế độ đệm để mã hoá/giải mã RSA:
      • Không có lớp đệm
      • RSAES-OAEP (PaddingMode::RSA_OAEP)
      • RSAES-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_ENCRYPT)
  • ECDSA
    • Hỗ trợ khoá 224, 256, 384 và 521 bit, sử dụng các đường cong NIST P-224, P-256, P-384 và P-521 tương ứng
    • Chế độ tóm tắt cho ECDSA:
      • Không có thông báo tóm tắt (không dùng nữa, sẽ bị xoá trong tương lai)
      • SHA-256
  • AES
    • Hỗ trợ khoá 128 và 256 bit
    • CBC, CTR, ECB và GCM. Việc triển khai GCM không cho phép sử dụng các thẻ nhỏ hơn 96 bit hoặc độ dài số chỉ dùng một lần khác với 96 bit.
    • Các chế độ đệm PaddingMode::NONE và PaddingMode::PKCS7 được hỗ trợ cho các chế độ CBC và ECB. Nếu không có khoảng đệm, quá trình mã hoá ở chế độ CBC hoặc ECB sẽ không thành công nếu đầu vào không phải là bội số của kích thước khối.
  • HMAC SHA-256, với mọi kích thước khoá lên đến ít nhất 32 byte.

Bạn nên sử dụng SHA1 và các thành viên khác của họ SHA2 (SHA-224, SHA384 và SHA512) cho các hoạt động triển khai KeyMint. Kho khoá cung cấp các khoá này trong phần mềm nếu quá trình triển khai KeyMint trên phần cứng không cung cấp.

Một số nguyên tắc cơ bản cũng được đề xuất để tương tác với các hệ thống khác:

  • Kích thước khoá nhỏ hơn cho RSA
  • Số mũ công khai tuỳ ý cho RSA

Kiểm soát quyền truy cập vào khoá

Các khoá dựa trên phần cứng không bao giờ có thể trích xuất từ thiết bị sẽ không mang lại nhiều tính bảo mật nếu kẻ tấn công có thể sử dụng chúng tuỳ ý (mặc dù chúng an toàn hơn các khoá có thể bị xâm nhập). Do đó, điều quan trọng là Keystore phải thực thi các chế độ kiểm soát quyền truy cập.

Quyền kiểm soát truy cập được xác định là "danh sách uỷ quyền" gồm các cặp thẻ/giá trị. Thẻ uỷ quyền là số nguyên 32 bit và các giá trị thuộc nhiều loại. Bạn có thể lặp lại một số thẻ để chỉ định nhiều giá trị. Việc một thẻ có thể được lặp lại hay không được chỉ định trong giao diện HAL KeyMint. Khi tạo khoá, phương thức gọi sẽ chỉ định một danh sách uỷ quyền. Việc triển khai KeyMint cơ bản của Keystore sẽ sửa đổi danh sách để chỉ định một số thông tin bổ sung, chẳng hạn như liệu khoá có biện pháp bảo vệ chống quay lui hay không, đồng thời trả về danh sách uỷ quyền "cuối cùng", được mã hoá thành blob khoá đã trả về. Mọi nỗ lực sử dụng khoá cho bất kỳ hoạt động mã hoá nào đều không thành công nếu danh sách uỷ quyền cuối cùng bị sửa đổi.

Đối với Keymaster 2 trở xuống, tập hợp các thẻ có thể có được xác định trong quá trình liệt kê keymaster_authorization_tag_t và được cố định vĩnh viễn (mặc dù có thể mở rộng). Tên có tiền tố là KM_TAG. 4 bit trên cùng của mã nhận dạng thẻ được dùng để cho biết loại.

Keymaster 3 đã thay đổi tiền tố KM_TAG thành Tag::.

Các loại có thể có là:

ENUM: Nhiều giá trị của thẻ được xác định trong các phép liệt kê. Ví dụ: các giá trị có thể có của TAG::PURPOSE được xác định trong enum keymaster_purpose_t.

ENUM_REP: Tương tự như ENUM, ngoại trừ việc thẻ có thể được lặp lại trong danh sách uỷ quyền. Việc lặp lại cho biết có nhiều giá trị được cho phép. Ví dụ: khoá mã hoá có thể có KeyPurpose::ENCRYPT và KeyPurpose::DECRYPT.

Khi KeyMint tạo một khoá, phương thức gọi sẽ chỉ định một danh sách uỷ quyền cho khoá. Danh sách này được Keystore và KeyMint sửa đổi để thêm các ràng buộc bổ sung, đồng thời quá trình triển khai KeyMint cơ bản sẽ mã hoá danh sách uỷ quyền cuối cùng vào keyblob được trả về. Danh sách uỷ quyền được mã hoá sẽ được liên kết bằng mật mã vào keyblob, để mọi nỗ lực sửa đổi danh sách uỷ quyền (bao gồm cả việc sắp xếp) đều dẫn đến một keyblob không hợp lệ và không thể dùng cho các hoạt động mật mã.

Thực thi bằng phần cứng so với phần mềm

Không phải mọi chế độ triển khai phần cứng bảo mật đều có các tính năng giống nhau. Để hỗ trợ nhiều phương pháp, Keymaster phân biệt giữa việc thực thi kiểm soát quyền truy cập bảo mật và không bảo mật, hoặc việc thực thi phần cứng và phần mềm.

Khoá này được hiển thị trong API KeyMint bằng trường securityLevel của loại KeyCharacteristics. Phần cứng bảo mật chịu trách nhiệm đặt các hoạt động uỷ quyền trong KeyCharacteristics với mức độ bảo mật thích hợp, dựa trên những gì phần cứng này có thể thực thi. Thông tin này cũng được hiển thị trong các bản ghi chứng thực cho khoá không đối xứng: đặc điểm khoá cho SecurityLevel::TRUSTED_ENVIRONMENT hoặc SecurityLevel::STRONGBOX xuất hiện trong danh sách hardwareEnforced và đặc điểm cho SecurityLevel::SOFTWARE hoặc SecurityLevel::KEYSTORE xuất hiện trong danh sách softwareEnforced.

Ví dụ: các ràng buộc về khoảng thời gian có thể sử dụng khoá thường không được môi trường bảo mật thực thi, vì môi trường này không có quyền truy cập đáng tin cậy vào thông tin ngày và giờ. Do đó, các hoạt động uỷ quyền như Tag::ORIGINATION_EXPIRE_DATETIME sẽ được Kho khoá thực thi trong Android và sẽ có SecurityLevel::KEYSTORE.

Để biết thêm thông tin về cách xác định xem các khoá và uỷ quyền của khoá có được phần cứng hỗ trợ hay không, hãy xem phần Chứng thực khoá.

Uỷ quyền xây dựng thông báo mật mã

Các thẻ sau đây được dùng để xác định đặc điểm mã hoá của các thao tác bằng khoá được liên kết:

  • Tag::ALGORITHM
  • Tag::KEY_SIZE
  • Tag::BLOCK_MODE
  • Tag::PADDING
  • Tag::CALLER_NONCE
  • Tag::DIGEST
  • Tag::MGF_DIGEST

Các thẻ sau đây có thể lặp lại, tức là bạn có thể liên kết nhiều giá trị với một khoá duy nhất:

  • Tag::BLOCK_MODE
  • Tag::PADDING
  • Tag::DIGEST
  • Tag::MGF_DIGEST

Giá trị cần sử dụng được chỉ định tại thời điểm hoạt động.

Mục đích

Khoá có một tập hợp các mục đích liên quan, được thể hiện dưới dạng một hoặc nhiều mục uỷ quyền bằng thẻ Tag::PURPOSE, xác định cách có thể sử dụng khoá. Các mục đích được xác định trong KeyPurpose.aidl.

Xin lưu ý rằng một số tổ hợp giá trị mục đích có thể gây ra các vấn đề về bảo mật. Ví dụ: khoá RSA có thể dùng để mã hoá và ký cho phép kẻ tấn công có thể thuyết phục hệ thống giải mã dữ liệu bất kỳ để tạo chữ ký.

Nhập khoá

Keymaster chỉ hỗ trợ xuất khoá công khai ở định dạng X.509 và nhập:

  • Các cặp khoá bất đối xứng ở định dạng PKCS#8 được mã hoá theo DER (không có phương thức mã hoá dựa trên mật khẩu)
  • Khoá đối xứng dưới dạng byte thô

Để đảm bảo rằng các khoá đã nhập có thể phân biệt với các khoá được tạo một cách an toàn, Tag::ORIGIN sẽ được đưa vào danh sách uỷ quyền khoá thích hợp. Ví dụ: nếu một khoá được tạo trong phần cứng bảo mật, thì Tag::ORIGIN có giá trị KeyOrigin::GENERATED sẽ xuất hiện trong danh sách hw_enforced gồm các đặc điểm của khoá, trong khi một khoá được nhập vào phần cứng bảo mật sẽ có giá trị KeyOrigin::IMPORTED.

Xác thực người dùng

Các hoạt động triển khai KeyMint an toàn không triển khai quy trình xác thực người dùng, mà phụ thuộc vào các ứng dụng đáng tin cậy khác có triển khai quy trình này. Để biết giao diện mà các ứng dụng này triển khai, hãy xem trang Gatekeeper.

Các yêu cầu xác thực người dùng được chỉ định thông qua 2 nhóm thẻ. Nhóm đầu tiên cho biết những phương thức xác thực nào cho phép sử dụng khoá:

  • Tag::USER_SECURE_ID có giá trị số 64 bit chỉ định mã nhận dạng người dùng bảo mật được cung cấp trong mã thông báo xác thực bảo mật để mở khoá việc sử dụng khoá. Nếu được lặp lại, khoá có thể được dùng nếu có bất kỳ giá trị nào được cung cấp trong mã thông báo xác thực bảo mật.

Nhóm thứ hai cho biết người dùng có cần xác thực hay không và thời điểm cần xác thực. Nếu không có thẻ nào trong số này, nhưng có Tag::USER_SECURE_ID, thì bạn phải xác thực mỗi khi sử dụng khoá.

  • Tag::NO_AUTHENTICATION_REQUIRED cho biết không cần xác thực người dùng, mặc dù quyền truy cập vào khoá vẫn bị hạn chế đối với ứng dụng sở hữu (và mọi ứng dụng mà ứng dụng đó cấp quyền truy cập).
  • Tag::AUTH_TIMEOUT là một giá trị bằng số, cho biết (tính bằng giây) mức độ mới nhất mà quá trình xác thực người dùng cần có để cho phép sử dụng khoá. Thời gian chờ không vượt quá thời gian khởi động lại; sau khi khởi động lại, tất cả các hoạt động xác thực đều không hợp lệ. Bạn có thể đặt thời gian chờ thành một giá trị lớn để cho biết rằng cần xác thực một lần cho mỗi lần khởi động (2^32 giây là khoảng 136 năm; có lẽ các thiết bị Android sẽ khởi động lại thường xuyên hơn).

Yêu cầu thiết bị đã mở khoá

Bạn chỉ có thể sử dụng các khoá có biểu tượng Tag::UNLOCKED_DEVICE_REQUIRED khi thiết bị đã mở khoá. Để biết ngữ nghĩa chi tiết, hãy xem KeyProtection.Builder#setUnlockedDeviceRequired(boolean).

UNLOCKED_DEVICE_REQUIRED được Keystore thực thi chứ không phải KeyMint. Tuy nhiên, trong Android 12 trở lên, Keystore sẽ bảo vệ khoá UNLOCKED_DEVICE_REQUIRED bằng mật mã khi thiết bị bị khoá để đảm bảo rằng trong hầu hết các trường hợp, khoá không thể được sử dụng ngay cả khi Keystore bị xâm phạm trong khi thiết bị bị khoá.

Để đạt được điều này, Keystore sẽ "siêu mã hoá" tất cả các khoá UNLOCKED_DEVICE_REQUIRED trước khi lưu trữ chúng trong cơ sở dữ liệu của mình, đồng thời bảo vệ các khoá siêu mã hoá (khoá siêu cấp) khi có thể trong khi thiết bị bị khoá theo cách mà chỉ có thể khôi phục chúng bằng cách mở khoá thiết bị thành công. (Thuật ngữ "siêu mã hoá" được dùng vì lớp mã hoá này được áp dụng ngoài lớp mã hoá mà KeyMint đã áp dụng cho tất cả các khoá.)

Mỗi người dùng (bao gồm cả hồ sơ) có 2 khoá chính liên kết với UNLOCKED_DEVICE_REQUIRED:

  • Khoá đối xứng siêu cấp UnlockedDeviceRequired. Đây là khoá AES‑256‑GCM. Thư viện này mã hoá các khoá UNLOCKED_DEVICE_REQUIRED được nhập hoặc tạo trong khi thiết bị đang ở trạng thái mở khoá cho người dùng.
  • Khoá siêu khoá bất đối xứng UnlockedDeviceRequired. Đây là một cặp khoá ECDH P-521. Thư viện này mã hoá các khoá UNLOCKED_DEVICE_REQUIRED được nhập hoặc tạo trong khi thiết bị bị khoá đối với người dùng. Các khoá được mã hoá bằng khoá bất đối xứng này sẽ được mã hoá lại bằng khoá đối xứng vào lần sử dụng đầu tiên (chỉ có thể xảy ra khi thiết bị được mở khoá).

Keystore tạo các khoá siêu dữ liệu này tại thời điểm tạo người dùng và lưu trữ chúng trong cơ sở dữ liệu của mình, được mã hoá bằng mật khẩu tổng hợp của người dùng. Điều này cho phép khôi phục các khoá này bằng mã PIN, hình mở khoá hoặc mật khẩu tương đương.

Keystore cũng lưu các khoá chính này vào bộ nhớ đệm, cho phép hoạt động trên các khoá UNLOCKED_DEVICE_REQUIRED. Tuy nhiên, nó chỉ cố gắng lưu vào bộ nhớ đệm các phần bí mật của những khoá này khi người dùng mở khoá thiết bị. Khi thiết bị bị khoá đối với người dùng, Kho khoá sẽ xoá bản sao được lưu vào bộ nhớ đệm của các phần bí mật của những khoá siêu dữ liệu này (nếu có thể). Cụ thể, khi thiết bị bị khoá đối với người dùng, Kho khoá sẽ chọn và áp dụng một trong 3 cấp độ bảo vệ cho các khoá chính UnlockedDeviceRequired của người dùng:

  • Nếu người dùng chỉ bật mã PIN, hình mở khoá hoặc mật khẩu, thì Keystore sẽ đặt lại các phần bí mật của khoá chính được lưu vào bộ nhớ đệm. Điều này khiến các siêu khoá chỉ có thể khôi phục thông qua bản sao đã mã hoá trong cơ sở dữ liệu. Chỉ có thể giải mã bản sao này bằng mã PIN, hình mở khoá hoặc mật khẩu tương đương.
  • Nếu người dùng chỉ có dữ liệu sinh trắc học loại 3 ("mạnh") và đã bật mã PIN, hình mở khoá hoặc mật khẩu, thì Keystore sẽ sắp xếp để mọi dữ liệu sinh trắc học loại 3 mà người dùng đã đăng ký (thường là vân tay) đều có thể khôi phục các khoá chính, thay cho mã PIN, hình mở khoá hoặc mật khẩu tương đương. Để làm việc này, nó sẽ tạo một khoá AES‑256‑GCM mới, mã hoá các phần bí mật của khoá chính bằng khoá này, nhập khoá AES‑256‑GCM vào KeyMint dưới dạng một khoá liên kết bằng sinh trắc học, yêu cầu xác thực bằng sinh trắc học thành công trong vòng 15 giây qua và xoá các bản sao văn bản thuần tuý của tất cả các khoá này.
  • Nếu người dùng có dữ liệu sinh trắc học loại 1 ("tiện lợi"), dữ liệu sinh trắc học loại 2 ("yếu") hoặc đã bật tác nhân tin cậy mở khoá đang hoạt động, thì Keystore sẽ lưu trữ các khoá chính ở dạng văn bản thuần tuý. Trong trường hợp này, không có biện pháp bảo mật mã hoá cho các khoá UNLOCKED_DEVICE_REQUIRED. Người dùng có thể tránh phương thức dự phòng kém an toàn này bằng cách không bật các phương thức mở khoá này. Các phương thức mở khoá phổ biến nhất thuộc các danh mục này là mở khoá bằng khuôn mặt trên nhiều thiết bị và mở khoá bằng đồng hồ thông minh được ghép nối.

Khi người dùng mở khoá thiết bị, Keystore sẽ khôi phục các khoá chính UnlockedDeviceRequired của người dùng nếu có thể. Đối với phương thức mở khoá tương đương bằng mã PIN, hình mở khoá hoặc mật khẩu, phương thức này sẽ giải mã bản sao của các khoá được lưu trữ trong cơ sở dữ liệu. Nếu không, ứng dụng sẽ kiểm tra xem có lưu bản sao của các khoá này được mã hoá bằng khoá liên kết sinh trắc học hay không. Nếu có, ứng dụng sẽ tìm cách giải mã bản sao đó. Thao tác này chỉ thành công nếu người dùng đã xác thực thành công bằng một hệ thống nhận dạng sinh trắc học cấp 3 trong vòng 15 giây gần nhất, do KeyMint thực thi (không phải Keystore).

Liên kết ứng dụng

Việc liên kết ứng dụng khách (sự liên kết của một khoá với một ứng dụng khách cụ thể) được thực hiện thông qua mã ứng dụng khách không bắt buộc và một số dữ liệu ứng dụng khách không bắt buộc (tương ứng là Tag::APPLICATION_ID và Tag::APPLICATION_DATA). Keystore coi những giá trị này là các blob mờ, chỉ đảm bảo rằng các blob giống nhau được trình bày trong quá trình tạo/nhập khoá sẽ được trình bày cho mọi lần sử dụng và hoàn toàn giống nhau từng byte. KeyMint không trả về dữ liệu liên kết của ứng dụng. Người gọi phải biết mã này để sử dụng khoá.

Tính năng này không được cung cấp cho các ứng dụng.

Hết hạn

Kho khoá hỗ trợ hạn chế việc sử dụng khoá theo ngày. Bạn có thể liên kết thời điểm bắt đầu có hiệu lực của khoá và thời điểm hết hạn của khoá với một khoá, đồng thời Keymaster sẽ từ chối thực hiện các thao tác khoá nếu ngày/giờ hiện tại nằm ngoài phạm vi hợp lệ. Phạm vi hiệu lực của khoá được chỉ định bằng các thẻ Tag::ACTIVE_DATETIME, Tag::ORIGINATION_EXPIRE_DATETIME và Tag::USAGE_EXPIRE_DATETIME. Sự khác biệt giữa "nguồn gốc" và "cách sử dụng" dựa trên việc khoá có đang được dùng để "tạo" một văn bản mã hoá/chữ ký/v.v. mới hay để "sử dụng" một văn bản mã hoá/chữ ký/v.v. hiện có. Xin lưu ý rằng sự khác biệt này không được hiển thị cho các ứng dụng.

Các thẻ Tag::ACTIVE_DATETIME, Tag::ORIGINATION_EXPIRE_DATETIME và Tag::USAGE_EXPIRE_DATETIME là không bắt buộc. Nếu không có thẻ này, hệ thống sẽ giả định rằng khoá được đề cập luôn có thể dùng để giải mã/xác minh thư.

Vì thời gian theo đồng hồ thực được cung cấp bởi thế giới không bảo mật, nên các thẻ liên quan đến thời gian hết hạn nằm trong danh sách do phần mềm thực thi.

Liên kết gốc tin cậy

Kho khoá yêu cầu các khoá phải được liên kết với một gốc tin cậy, đó là một chuỗi bit được cung cấp cho phần cứng bảo mật KeyMint trong quá trình khởi động, tốt nhất là do trình tải khởi động cung cấp. Chuỗi bit này được liên kết bằng mật mã với mọi khoá do KeyMint quản lý.

Nguồn gốc của niềm tin bao gồm khoá công khai dùng để xác minh chữ ký trên hình ảnh khởi động và trạng thái khoá của thiết bị. Nếu khoá công khai được thay đổi để cho phép sử dụng một hình ảnh hệ thống khác hoặc nếu trạng thái khoá bị thay đổi, thì không có khoá nào được KeyMint bảo vệ do hệ thống trước đó tạo ra có thể sử dụng được, trừ phi gốc tin cậy trước đó được khôi phục và một hệ thống được khoá bằng khoá đó sẽ khởi động. Mục tiêu là tăng giá trị của các chế độ kiểm soát quyền truy cập vào khoá do phần mềm thực thi bằng cách ngăn hệ điều hành do kẻ tấn công cài đặt sử dụng các khoá KeyMint.

Khoá độc lập

Một số phần cứng bảo mật KeyMint có thể chọn lưu trữ nội dung khoá nội bộ và trả về các mã nhận dạng thay vì nội dung khoá được mã hoá. Hoặc có thể có những trường hợp khác mà khoá không thể dùng được cho đến khi có một thành phần hệ thống khác không bảo mật hoặc bảo mật. HAL KeyMint cho phép người gọi yêu cầu một khoá "độc lập" thông qua thẻ TAG::STANDALONE, nghĩa là không cần tài nguyên nào khác ngoài blob và hệ thống KeyMint đang chạy. Bạn có thể kiểm tra các thẻ được liên kết với một khoá để xem khoá đó có độc lập hay không. Hiện tại, chỉ có hai giá trị được xác định:

  • KeyBlobUsageRequirements::STANDALONE
  • KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

Tính năng này không được cung cấp cho các ứng dụng.

Vận tốc

Khi được tạo, bạn có thể chỉ định tốc độ sử dụng tối đa bằng TAG::MIN_SECONDS_BETWEEN_OPS. Các phương thức triển khai TrustZone từ chối thực hiện các thao tác mã hoá bằng khoá đó nếu một thao tác được thực hiện ít hơn TAG::MIN_SECONDS_BETWEEN_OPS giây trước đó.

Cách đơn giản để triển khai giới hạn tốc độ là sử dụng bảng gồm các mã nhận dạng khoá và dấu thời gian sử dụng gần đây nhất. Bảng này có kích thước giới hạn, nhưng chứa ít nhất 16 mục. Trong trường hợp bảng đầy và không có mục nào có thể được cập nhật hoặc loại bỏ, các hoạt động triển khai phần cứng bảo mật sẽ "thất bại an toàn", ưu tiên từ chối tất cả các thao tác khoá bị giới hạn tốc độ cho đến khi một trong các mục hết hạn. Tất cả các mục đều có thể hết hạn khi khởi động lại.

Bạn cũng có thể giới hạn số lần sử dụng khoá là n lần cho mỗi lần khởi động bằng TAG::MAX_USES_PER_BOOT. Điều này cũng yêu cầu một bảng theo dõi, có ít nhất 4 khoá và cũng có cơ chế dự phòng. Xin lưu ý rằng các ứng dụng không thể tạo khoá bị hạn chế cho mỗi lần khởi động. Tính năng này không được hiển thị thông qua Kho khoá và dành riêng cho các hoạt động của hệ thống.

Tính năng này không được cung cấp cho các ứng dụng.

Tạo lại số ngẫu nhiên cho trình tạo số ngẫu nhiên

Vì phần cứng bảo mật tạo ra các số ngẫu nhiên cho nội dung khoá và vectơ khởi tạo (IV) và vì trình tạo số ngẫu nhiên phần cứng không phải lúc nào cũng hoàn toàn đáng tin cậy, nên KeyMint HAL cung cấp một giao diện để cho phép ứng dụng cung cấp thêm entropy, được trộn lẫn vào các số ngẫu nhiên đã tạo.

Sử dụng trình tạo số ngẫu nhiên phần cứng làm nguồn gieo hạt chính. Dữ liệu gốc được cung cấp thông qua API bên ngoài không thể là nguồn duy nhất của tính ngẫu nhiên được dùng để tạo số. Ngoài ra, thao tác kết hợp được dùng cần đảm bảo rằng đầu ra ngẫu nhiên là không thể dự đoán nếu bất kỳ nguồn nào trong số các nguồn ban đầu là không thể dự đoán.