Tính năng

Trang này chứa thông tin về các tính năng mã hoá của Kho khoá trong Android 6.0 trở lên.

Lưu ý: Các thẻ và hàm được viết theo kiểu Keymaster 3. Để biết thêm thông tin, hãy xem bài viết Tổng quan về HIDL.

Nguyên hàm mật mã

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

• Tạo khoá
• Nhập và xuất khoá bất đối xứng (không gói khoá)
• Nhập khoá đối xứng thô (không gói khoá)
• Mã hoá và giải mã bất đối xứng bằng các chế độ đệm thích hợp
• Ký và xác minh bất đối xứng bằng chế độ tổng hợp và chế độ đệm thích hợp
• Mã hoá và giải mã đối xứng ở các chế độ thích hợp, bao gồm cả chế độ AEAD
• Tạo và xác minh mã xác thực thông báo đố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 quy tắc ràng buộc kiểm soát quyền 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ụ nữa mà các hoạt động triển khai Keymaster cung cấp nhưng không được hiển thị dưới dạng API: Tạo số ngẫu nhiên. Phương thức này được dùng nội bộ để tạo khoá, Vectơ khởi tạo (IV), phần đệ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 dữ liệu gốc cần thiết

Tất cả các phương thức triển khai Keymaster đều cung cấp:

• RSA
  • Hỗ trợ khoá 2048, 3072 và 4096 bit
  • Hỗ trợ hệ 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)
  • Chế độ tóm tắt để ký RSA:
    • SHA-256
  • Các chế độ đệm cho quá trình mã hoá/giải mã RSA:
    • Không có khoảng đệ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ó chuỗi đại diện (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.
  • Chế độ khoảng đệm PaddingMode::NONE và PaddingMode::PKCS7 được hỗ trợ cho chế độ CBC và ECB. Nếu không có dữ liệu đệm, quá trình mã hoá CBC hoặc ECB sẽ không thành công nếu dữ liệ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 kích thước khoá bất kỳ 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 trong gia đình SHA2 (SHA-224, SHA384 và SHA512) để triển khai Keymaster. Kho khoá cung cấp các khoá này trong phần mềm nếu việc triển khai Keymaster phần cứng không cung cấp các khoá này.

Bạn cũng nên sử dụng một số loại dữ liệu gốc để có khả năng tương tác với các hệ thống khác:

• Kích thước khoá nhỏ hơn cho RSA
• 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ể được 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 các khoá đó theo ý muốn (mặc dù các khoá này an toàn hơn so với các khoá có thể bị rò rỉ). Do đó, điều quan trọng là Kho khoá phải thực thi các biện pháp kiểm soát quyền truy cập.

Chế độ kiểm soát quyền truy cập được xác định là "danh sách uỷ quyền" của các cặp thẻ/giá trị. Thẻ uỷ quyền là số nguyên 32 bit và giá trị là nhiều loại. Một số thẻ có thể được lặp lại để chỉ định nhiều giá trị. Liệu một thẻ có thể được lặp lại hay không được chỉ định trong giao diện HAL KeyMint (trước đây là Keymaster). Khi một khoá được tạo, trình gọi sẽ chỉ định một danh sách uỷ quyền. Quá trình triển khai Keymaster cơ bản của Kho khoá 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ó tính năng bảo vệ rollback hay không và trả về danh sách uỷ quyền "cuối cùng", được mã hoá vào blob khoá được trả về. Mọi nỗ lực sử dụng khoá cho bất kỳ thao tác 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 enum keymaster_authorization_tag_t và được cố định vĩnh viễn (mặc dù có thể mở rộng). Tên được đặt 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 thẻ.

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

Có thể có các loại sau:

ENUM: Nhiều giá trị của thẻ được xác định trong các giá trị 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. Lặp lại cho biết nhiều giá trị được uỷ quyền. Ví dụ: khoá mã hoá có thể có KeyPurpose::ENCRYPT và KeyPurpose::DECRYPT.

UINT: Số nguyên 32 bit chưa ký. Ví dụ: TAG::KEY_SIZE

UINT_REP: Tương tự như UINT, ngoại trừ việc thẻ có thể được lặp lại trong danh sách uỷ quyền. Lặp lại cho biết nhiều giá trị được uỷ quyền.

ULONG: Số nguyên 64 bit chưa ký. Ví dụ: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP: Tương tự như ULONG, ngoại trừ việc thẻ có thể được lặp lại trong danh sách uỷ quyền. Lặp lại cho biết nhiều giá trị được uỷ quyền.

DATE: Giá trị ngày/giờ, được biểu thị bằng mili giây kể từ ngày 1 tháng 1 năm 1970. Ví dụ: TAG::PRIVKEY_EXPIRE_DATETIME

BOOL: Đúng hoặc sai. Thẻ thuộc loại BOOL được giả định là "false" nếu không có thẻ và "true" nếu có thẻ. Ví dụ: TAG::ROLLBACK_RESISTANT

BIGNUM: Số nguyên có độ dài tuỳ ý, được biểu thị dưới dạng mảng byte theo thứ tự big-endian. Ví dụ: TAG::RSA_PUBLIC_EXPONENT

BYTES: Một chuỗi byte. Ví dụ: TAG::ROOT_OF_TRUST

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

Không phải tất cả các phương thức triển khai phần cứng bảo mật đều có cùng các tính năng. Để 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 vào thế giới bảo mật và không bảo mật, hoặc thực thi phần cứng và phần mềm tương ứng.

Tất cả các cách triển khai:

• Thực thi việc so khớp chính xác (không phải thực thi) tất cả các quyền uỷ quyền. Danh sách uỷ quyền trong blob khoá khớp chính xác với các uỷ quyền được trả về trong quá trình tạo khoá, bao gồm cả thứ tự. Mọi trường hợp không khớp đều gây ra lỗi chẩn đoán.
• Khai báo các quyền uỷ quyền có giá trị ngữ nghĩa được thực thi.

Cơ chế API để khai báo các quyền uỷ quyền do phần cứng thực thi nằm trong cấu trúc keymaster_key_characteristics_t. Phương thức này chia danh sách uỷ quyền thành hai danh sách con, hw_enforced và sw_enforced. Phần cứng bảo mật chịu trách nhiệm đặt các giá trị thích hợp vào từng phần, dựa trên những giá trị mà phần cứng có thể thực thi.

Ngoài ra, Kho khoá triển khai việc thực thi dựa trên phần mềm đối với tất cả các hoạt động uỷ quyền, cho dù các hoạt động đó có được phần cứng bảo mật thực thi hay không.

Ví dụ: hãy xem xét phương thức triển khai dựa trên TrustZone không hỗ trợ việc hết hạn khoá. Bạn vẫn có thể tạo khoá có ngày hết hạn. Danh sách uỷ quyền của khoá đó bao gồm thẻ TAG::ORIGINATION_EXPIRE_DATETIME có ngày hết hạn. Yêu cầu đến Kho khoá cho các đặc điểm khoá sẽ tìm thấy thẻ này trong danh sách sw_enforced và phần cứng bảo mật sẽ không thực thi yêu cầu về thời gian hết hạn. Tuy nhiên, Kho khoá sẽ từ chối các nỗ lực sử dụng khoá sau khi hết hạn.

Sau đó, nếu thiết bị được nâng cấp bằng phần cứng bảo mật hỗ trợ thời gian hết hạn, thì yêu cầu về đặc điểm khoá sẽ tìm thấy TAG::ORIGINATION_EXPIRE_DATETIME trong danh sách hw_enforced và cố gắng sử dụng khoá sau khi hết hạn, ngay cả khi kho khoá bị xâm nhập hoặc bị bỏ qua.

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

Quyền tạo thông điệp mã hoá

Các thẻ sau đây được dùng để xác định các đặc điểm mật mã của các thao tác bằng cách sử dụng khoá liên kết: TAG::ALGORITHM, TAG::KEY_SIZE, TAG::BLOCK_MODE, TAG::PADDING, TAG::CALLER_NONCE và TAG::DIGEST

TAG::PADDING, TAG::DIGEST và PaddingMode::BLOCK_MODE có thể lặp lại, nghĩa là nhiều giá trị có thể được liên kết với một khoá duy nhất và giá trị sẽ được sử dụng được chỉ định tại thời điểm thao tác.

Mục đích

Khoá có một tập hợp các mục đích liên quan, được biểu thị dưới dạng một hoặc nhiều mục nhập uỷ quyền có thẻ TAG::PURPOSE, xác định cách sử dụng các mục nhập đó. Các mục đích đó là:

• KeyPurpose::ENCRYPT
• KeyPurpose::DECRYPT
• KeyPurpose::SIGN
• KeyPurpose::VERIFY

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

Nhập và xuất

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

• Các cặp khoá công khai và khoá riêng tư ở định dạng PKCS#8 được mã hoá bằng DER, không có tính năng mã hoá dựa trên mật khẩu
• Khoá đối xứng dưới dạng byte thô

Để đảm bảo có thể phân biệt các khoá đã nhập với các khoá được tạo một cách an toàn, TAG::ORIGIN đượ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ẽ được tìm thấy trong danh sách hw_enforced của các đặc điểm khoá, trong khi 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 phương thức triển khai Keymaster bảo mật 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. Đối với 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 hai nhóm thẻ. Tập hợp đầu tiên cho biết người dùng nào có thể sử dụng khoá:

• TAG::ALL_USERS cho biết khoá này có thể được tất cả người dùng sử dụng. Nếu có, TAG::USER_ID và TAG::USER_SECURE_ID sẽ không có.
• TAG::USER_ID có giá trị dạng số chỉ định mã nhận dạng của người dùng được uỷ quyền. Xin lưu ý rằng đây là mã nhận dạng người dùng Android (dành cho nhiều người dùng), chứ không phải UID ứng dụng và chỉ được phần mềm không bảo mật thực thi. Nếu có, TAG::ALL_USERS sẽ không xuất hiện.
• TAG::USER_SECURE_ID có giá trị số 64 bit chỉ định mã nhận dạng người dùng an toàn được cung cấp trong mã xác thực an toàn để mở khoá sử dụng khoá. Nếu lặp lại, bạn có thể sử dụng khoá nếu bất kỳ giá trị nào được cung cấp trong mã xác thực bảo mật.

Tập hợp thứ hai cho biết liệu người dùng có cần được 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á.

• NO_AUTHENTICATION_REQUIRED cho biết không cần xác thực người dùng, mặc dù khoá này vẫn chỉ có thể được các ứng dụng chạy dưới dạng người dùng do TAG::USER_ID chỉ định sử dụng.
• TAG::AUTH_TIMEOUT là một giá trị số chỉ định (tính bằng giây) mức độ mới của thông tin xác thực người dùng để cho phép sử dụng khoá. Điều này chỉ áp dụng cho các thao tác khoá riêng tư/khoá bí mật. Các thao tác khoá công khai không yêu cầu xác thực. Thời gian chờ không vượt quá số lần khởi động lại; sau khi khởi động lại, tất cả các khoá sẽ không bao giờ được xác thực. 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 mỗi khi khởi động (2^32 giây là khoảng 136 năm; giả sử thiết bị Android được khởi động lại thường xuyên hơn thế).

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

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

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

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

Mỗi người dùng (bao gồm cả hồ sơ) có hai khoá siêu cấp liên kết với UNLOCKED_DEVICE_REQUIRED:

• Khoá siêu đối xứng UnlockedDeviceRequired. Đây là khoá AES‑256‑GCM. Phương thức này mã hoá các khoá UNLOCKED_DEVICE_REQUIRED được nhập hoặc tạo trong khi thiết bị được mở khoá cho người dùng.
• Khoá siêu bất đối xứng UnlockedDeviceRequired. Đây là một cặp khoá ECDH P‑521. Phương thức 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 trong lần sử dụng đầu tiên (chỉ có thể xảy ra khi thiết bị đang mở khoá).

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

Kho khoá cũng lưu các khoá siêu này vào bộ nhớ đệm, cho phép hoạt động trên các khoá UNLOCKED_DEVICE_REQUIRED. Tuy nhiên, phương thức này chỉ cố gắng lưu các phần bí mật của các khoá này vào bộ nhớ đệm khi thiết bị được mở khoá cho người dùng. Khi thiết bị bị khoá cho người dùng, Kho khoá sẽ đặt giá trị rỗng cho bản sao lưu trong bộ nhớ đệm của các phần bí mật của các khoá siêu này (nếu có thể). Cụ thể, khi thiết bị được khoá cho người dùng, Kho khoá sẽ chọn và áp dụng một trong ba cấp độ bảo vệ cho khoá siêu 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ì Kho khoá sẽ đặt các phần bí mật của khoá siêu cấp được lưu vào bộ nhớ đệm về giá trị 0. Điều này khiến các khoá siêu cấp chỉ có thể khôi phục được thông qua bản sao đã mã hoá trong cơ sở dữ liệu mà chỉ có thể giải mã 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ì Kho khoá sẽ sắp xếp để khoá siêu cấp có thể khôi phục bằng bất kỳ dữ liệu sinh trắc học loại 3 nào (thường là vân tay) mà người dùng đã đăng ký, thay cho mã PIN, hình mở khoá hoặc mật khẩu tương đương. Để thực hiện việc này, ứng dụng này sẽ tạo một khoá AES‑256‑GCM mới, mã hoá các phần bí mật của khoá siêu cấp bằng khoá này, nhập khoá AES‑256‑GCM vào Keymaster dưới dạng khoá liên kết sinh trắc học yêu cầu xác thực sinh trắc học thành công trong vòng 15 giây qua và đặt các bản sao văn bản thô của tất cả các khoá này về giá trị 0.
• Nếu người dùng có thông tin sinh trắc học loại 1 ("thuận tiện"), thông tin 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ì Kho khoá sẽ lưu các khoá siêu cấp vào bộ nhớ đệm ở dạng văn bản thô. Trong trường hợp này, tính năng bảo mật mã hoá cho khoá UNLOCKED_DEVICE_REQUIRED sẽ không được cung cấp. 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 đã ghép nối.

Khi người dùng mở khoá thiết bị, Kho khoá sẽ khôi phục khoá siêu 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á này đượ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ó thì sẽ cố gắng giải mã khoá đó. Việc này chỉ thành công nếu người dùng đã xác thực thành công bằng dữ liệu sinh trắc học loại 3 trong vòng 15 giây qua, do Keymaster (không phải Kho khoá) thực thi.

Liên kết ứng dụng

Liên kết ứng dụng khách, liên kết 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). Kho khoá coi các giá trị này là các blob mờ, chỉ đảm bảo rằng cùng một blob được hiển thị trong quá trình tạo/nhập khoá được hiển thị cho mọi mục đích sử dụng và giống hệt nhau từng byte. Keymaster không trả về dữ liệu liên kết ứng dụng. Phương thức gọi phải biết giá trị này để sử dụng khoá.

Ứng dụng không thấy được tính năng này.

Hết hạn

Kho khoá hỗ trợ việc hạn chế việc sử dụng khoá theo ngày. Bạn có thể liên kết ngày bắt đầu và ngày hết hạn của khoá với một khoá và Keymaster sẽ từ chối thực hiện các thao tác với khoá nếu ngày/giờ hiện tại nằm ngoài phạm vi hợp lệ. Phạm vi hợp lệ 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à "mục đích sử dụng" dựa trên việc khoá đang được dùng để "tạo" văn bản/chữ ký/v.v. mới hay để "sử dụng" văn bản/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.

Bạn không bắt buộc phải sử dụng thẻ TAG::ACTIVE_DATETIME, TAG::ORIGINATION_EXPIRE_DATETIME và TAG::USAGE_EXPIRE_DATETIME. Nếu không có thẻ, giả định rằng khoá trong câu hỏi luôn có thể được dùng để giải mã/xác minh thư.

Vì thời gian đồng hồ thực tế do thế giới không an toàn cung cấp, nên các thẻ liên quan đến thời gian hết hạn khó có thể nằm trong danh sách do phần cứng thực thi. Việc thực thi thời gian hết hạn bằng phần cứng sẽ yêu cầu thế giới bảo mật phải lấy được thời gian và dữ liệu đáng tin cậy, chẳng hạn như thông qua giao thức phản hồi thách thức với một máy chủ thời gian từ xa đáng tin cậy.

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 Keymaster 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 phương thức mã hoá với mọi khoá do Keymaster quản lý.

Gốc tin cậy 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á được thay đổi, thì sẽ không có khoá nào do Keymaster bảo vệ mà 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à hệ thống được ký bằng khoá đó được 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á Keymaster.

Khoá độc lập

Một số phần cứng bảo mật Keymaster có thể chọn lưu trữ nội dung khoá nội bộ và trả về các tay cầm thay vì nội dung khoá đã mã hoá. Hoặc có thể có các trường hợp khác trong đó không thể sử dụng khoá cho đến khi có một số thành phần hệ thống thế giới không an toàn hoặc an toàn khác. HAL Keymaster cho phép phương thức gọi yêu cầu một khoá "độc lập" thông qua thẻ TAG::STANDALONE, nghĩa là không yêu cầu tài nguyên nào khác ngoài blob và hệ thống Keymaster đang chạy. Bạn có thể kiểm tra các thẻ 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

Ứng dụng không thấy được tính năng này.

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 hoạt động triển khai TrustZone từ chối thực hiện các hoạt động mã hoá bằng khoá đó nếu một hoạt động đã được thực hiện trước đó chưa đến TAG::MIN_SECONDS_BETWEEN_OPS giây.

Phương pháp đơn giản để triển khai giới hạn tốc độ là một bảng gồm mã 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 thể cập nhật hoặc loại bỏ mục nhập nào, các phương thức triển khai phần cứng bảo mật sẽ "an toàn khi không thành công", ư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 nhập hết hạn. Tất cả các mục nhập đề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 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, chứa ít nhất 4 khoá và cũng có khả năng chống lỗi. Xin lưu ý rằng ứng dụng không thể tạo khoá 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.

Ứng dụng không thấy được tính năng này.

Tạo lại giá trị khởi tạo cho trình tạo số ngẫu nhiên

Vì phần cứng bảo mật tạo số ngẫu nhiên cho tài liệu khoá và vectơ khởi chạy (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 đáng tin cậy, nên Keymaster HAL cung cấp một giao diện cho phép ứng dụng cung cấp thêm entropy, được trộn vào số ngẫu nhiên được tạo.

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

Tính năng này không hiển thị cho các ứng dụng nhưng được khung sử dụng, thường xuyên cung cấp thêm entropy, được truy xuất từ một thực thể Java SecureRandom, cho phần cứng bảo mật.