Kho khóa được hỗ trợ bằng phần cứng

Sự sẵn có của môi trường thực thi đáng tin cậy trong hệ thống trên chip (SoC) mang đến cơ hội cho các thiết bị Android cung cấp các dịch vụ bảo mật mạnh mẽ, được hỗ trợ bằng phần cứng cho HĐH Android, cho các dịch vụ nền tảng và thậm chí cho các ứng dụng của bên thứ ba. Các nhà phát triển đang tìm kiếm tiện ích mở rộng dành riêng cho Android nên truy cập android.security.keystore .

Trước Android 6.0, Android đã có API dịch vụ mã hóa đơn giản, được hỗ trợ bằng phần cứng, được cung cấp bởi các phiên bản 0.2 và 0.3 của Lớp trừu tượng phần cứng Keymaster (HAL). Kho khóa cung cấp các hoạt động xác minh và ký kỹ thuật số, cùng với việc tạo và nhập các cặp khóa ký không đối xứng. Điều này đã được triển khai trên nhiều thiết bị, nhưng có nhiều mục tiêu bảo mật không thể dễ dàng đạt được chỉ với một API chữ ký. Keystore trong Android 6.0 đã mở rộng API Keystore để cung cấp phạm vi khả năng rộng hơn.

Trong Android 6.0, Keystore đã thêm các nguyên tắc mã hóa đối xứng , AES và HMAC, cũng như hệ thống kiểm soát truy cập cho các khóa được hỗ trợ bằng phần cứng. Kiểm soát truy cập được chỉ định trong quá trình tạo khóa và được thực thi trong suốt vòng đời của khóa. Khóa có thể bị hạn chế chỉ có thể sử dụng được sau khi người dùng đã được xác thực và chỉ cho các mục đích được chỉ định hoặc với các tham số mật mã được chỉ định. Để biết thêm thông tin, hãy xem trang Thẻ ủy quyềnChức năng .

Ngoài việc mở rộng phạm vi mã hóa nguyên thủy, Keystore trong Android 6.0 đã bổ sung thêm các tính năng sau:

  • Sơ đồ kiểm soát việc sử dụng cho phép hạn chế việc sử dụng khóa, nhằm giảm thiểu rủi ro xâm phạm bảo mật do sử dụng sai khóa
  • Sơ đồ kiểm soát truy cập để cho phép hạn chế khóa đối với người dùng, khách hàng được chỉ định và phạm vi thời gian xác định

Trong Android 7.0, Keymaster 2 đã thêm hỗ trợ cho chứng thực khóa và liên kết phiên bản. Chứng thực khóa cung cấp chứng chỉ khóa công khai chứa mô tả chi tiết về khóa và các biện pháp kiểm soát truy cập của khóa, giúp cho sự tồn tại của khóa trong phần cứng bảo mật và cấu hình của khóa có thể được xác minh từ xa.

Liên kết phiên bản liên kết các khóa với hệ điều hành và phiên bản cấp bản vá. Điều này đảm bảo rằng kẻ tấn công phát hiện ra điểm yếu trong phiên bản cũ của hệ thống hoặc phần mềm TEE không thể khôi phục thiết bị về phiên bản dễ bị tấn công và sử dụng các khóa được tạo bằng phiên bản mới hơn. Ngoài ra, khi sử dụng một khóa có phiên bản và cấp bản vá nhất định trên thiết bị đã được nâng cấp lên phiên bản hoặc cấp bản vá mới hơn, thì khóa đó sẽ được nâng cấp trước khi có thể sử dụng và phiên bản trước đó của khóa sẽ không còn hiệu lực. Khi thiết bị được nâng cấp, các phím sẽ "bánh cóc" về phía trước cùng với thiết bị, nhưng bất kỳ sự đảo ngược nào của thiết bị về phiên bản trước sẽ khiến các phím không thể sử dụng được.

Trong Android 8.0, Keymaster 3 đã chuyển từ Lớp trừu tượng phần cứng (HAL) cấu trúc C kiểu cũ sang giao diện C++ HAL được tạo từ một định nghĩa trong Ngôn ngữ định nghĩa giao diện phần cứng (HIDL) mới. Là một phần của sự thay đổi, nhiều loại đối số đã thay đổi, mặc dù các loại và phương thức có sự tương ứng một-một với các loại cũ và các phương thức cấu trúc HAL. Xem trang Chức năng để biết thêm chi tiết.

Ngoài bản sửa đổi giao diện này, Android 8.0 đã mở rộng tính năng chứng thực của Keymaster 2 để hỗ trợ chứng thực ID . Chứng thực ID cung cấp một cơ chế có giới hạn và tùy chọn để chứng thực mạnh mẽ các mã nhận dạng phần cứng, chẳng hạn như số sê-ri thiết bị, tên sản phẩm và ID điện thoại (IMEI / MEID). Để triển khai tính năng bổ sung này, Android 8.0 đã thay đổi lược đồ chứng thực ASN.1 để thêm chứng thực ID. Việc triển khai Keymaster cần tìm một số cách an toàn để truy xuất các mục dữ liệu có liên quan, cũng như xác định cơ chế vô hiệu hóa tính năng này một cách an toàn và vĩnh viễn.

Trong Android 9, các bản cập nhật bao gồm:

  • Cập nhật lên Keymaster 4
  • Hỗ trợ các phần tử bảo mật được nhúng
  • Hỗ trợ nhập khóa an toàn
  • Hỗ trợ mã hóa 3DES
  • Thay đổi liên kết phiên bản để boot.img và system.img có các phiên bản được đặt riêng để cho phép cập nhật độc lập

Bảng chú giải

Dưới đây là tổng quan nhanh về các thành phần Keystore và mối quan hệ của chúng.

AndroidKeystore là thành phần và API Android Framework được các ứng dụng sử dụng để truy cập chức năng Keystore. Nó được triển khai như một phần mở rộng cho API Kiến trúc mật mã Java tiêu chuẩn và bao gồm mã Java chạy trong không gian xử lý riêng của ứng dụng. AndroidKeystore đáp ứng các yêu cầu ứng dụng về hoạt động của Keystore bằng cách chuyển tiếp chúng tới daemon kho khóa.

Trình nền kho khóa là một trình nền hệ thống Android cung cấp quyền truy cập vào tất cả chức năng của Kho khóa thông qua API Binder . Nó chịu trách nhiệm lưu trữ "các đốm màu", chứa tài liệu khóa bí mật thực sự, được mã hóa để Keystore có thể lưu trữ chúng nhưng không được sử dụng hoặc tiết lộ chúng.

keymasterd là máy chủ HIDL cung cấp quyền truy cập vào Keymaster TA. (Tên này không được tiêu chuẩn hóa và chỉ nhằm mục đích mang tính khái niệm.)

Keymaster TA (ứng dụng đáng tin cậy) là phần mềm chạy trong bối cảnh bảo mật, thường xuyên nhất là trong TrustZone trên ARM SoC, cung cấp tất cả các hoạt động Kho khóa an toàn, có quyền truy cập vào tài liệu khóa thô, xác thực tất cả các điều kiện kiểm soát truy cập trên khóa , vân vân.

LockSettingsService là thành phần hệ thống Android chịu trách nhiệm xác thực người dùng, cả mật khẩu và dấu vân tay. Nó không phải là một phần của Keystore nhưng có liên quan vì nhiều thao tác khóa Keystore yêu cầu xác thực người dùng. LockSettingsService tương tác với Gatekeeper TA và Vân tay TA để lấy mã thông báo xác thực mà nó cung cấp cho daemon kho khóa và cuối cùng được ứng dụng Keymaster TA sử dụng.

Gatekeeper TA (ứng dụng đáng tin cậy) là một thành phần khác chạy trong bối cảnh bảo mật, chịu trách nhiệm xác thực mật khẩu người dùng và tạo mã thông báo xác thực dùng để chứng minh với Keymaster TA rằng xác thực đã được thực hiện cho một người dùng cụ thể tại một thời điểm cụ thể.

Dấu vân tay TA (ứng dụng đáng tin cậy) là một thành phần khác chạy trong bối cảnh bảo mật, chịu trách nhiệm xác thực dấu vân tay của người dùng và tạo mã thông báo xác thực dùng để chứng minh với Keymaster TA rằng xác thực đã được thực hiện cho một người dùng cụ thể tại một thời điểm cụ thể.

Ngành kiến ​​​​trúc

API kho khóa Android và Keymaster HAL cơ bản cung cấp một bộ mã hóa cơ bản nhưng đầy đủ để cho phép triển khai các giao thức bằng cách sử dụng các khóa được hỗ trợ bằng phần cứng, được kiểm soát quyền truy cập.

Keymaster HAL là thư viện có thể tải động, do OEM cung cấp, được dịch vụ Keystore sử dụng để cung cấp các dịch vụ mã hóa được hỗ trợ bằng phần cứng. Để giữ mọi thứ an toàn, việc triển khai HAL không thực hiện bất kỳ thao tác nhạy cảm nào trong không gian người dùng hoặc thậm chí trong không gian kernel. Các hoạt động nhạy cảm được ủy quyền cho bộ xử lý an toàn được tiếp cận thông qua một số giao diện hạt nhân. Kiến trúc kết quả trông như thế này:

Truy cập vào Keymaster

Hình 1. Truy cập Keymaster

Trong thiết bị Android, "máy khách" của Keymaster HAL bao gồm nhiều lớp (ví dụ: ứng dụng, khung, trình nền Keystore), nhưng có thể bỏ qua lớp đó vì mục đích của tài liệu này. Điều này có nghĩa là API Keymaster HAL được mô tả ở cấp độ thấp, được sử dụng bởi các thành phần bên trong nền tảng và không được hiển thị cho các nhà phát triển ứng dụng. API cấp cao hơn được mô tả trên trang web dành cho Nhà phát triển Android .

Mục đích của Keymaster HAL không phải là triển khai các thuật toán nhạy cảm về bảo mật mà chỉ để sắp xếp các yêu cầu sắp xếp và không sắp xếp đối với thế giới bảo mật. Định dạng dây được xác định theo cách thực hiện.

Khả năng tương thích với các phiên bản trước

Keymaster 1 HAL hoàn toàn không tương thích với các HAL đã phát hành trước đó, ví dụ Keymaster 0.2 và 0.3. Để tạo điều kiện thuận lợi cho khả năng tương tác trên các thiết bị chạy Android 5.0 trở về trước đã ra mắt cùng với Keymaster HAL cũ hơn, Keystore cung cấp một bộ điều hợp triển khai Keymaster 1 HAL với các lệnh gọi tới thư viện phần cứng hiện có. Kết quả không thể cung cấp đầy đủ chức năng trong Keymaster 1 HAL. Đặc biệt, nó chỉ hỗ trợ các thuật toán RSA và ECDSA và tất cả việc thực thi ủy quyền khóa đều được bộ điều hợp thực hiện trong thế giới không bảo mật.

Keymaster 2 đã đơn giản hóa hơn nữa giao diện HAL bằng cách loại bỏ các phương thức get_supported_* và cho phép phương thức finish() chấp nhận đầu vào. Điều này làm giảm số lượng chuyến đi khứ hồi tới TEE trong trường hợp tất cả đầu vào đều có sẵn cùng một lúc và đơn giản hóa việc triển khai giải mã AEAD.

Trong Android 8.0, Keymaster 3 đã chuyển đổi từ HAL cấu trúc C kiểu cũ sang giao diện C++ HAL được tạo từ một định nghĩa trong Ngôn ngữ định nghĩa giao diện phần cứng (HIDL) mới. Việc triển khai HAL kiểu mới được tạo bằng cách phân lớp lớp IKeymasterDevice được tạo và triển khai các phương thức ảo thuần túy. Là một phần của sự thay đổi, nhiều loại đối số đã thay đổi, mặc dù các loại và phương thức có sự tương ứng một-một với các loại cũ và các phương thức cấu trúc HAL.

Tổng quan về HIDL

Ngôn ngữ định nghĩa giao diện phần cứng (HIDL) cung cấp cơ chế độc lập với ngôn ngữ triển khai để chỉ định giao diện phần cứng. Công cụ HIDL hiện hỗ trợ tạo giao diện C++ và Java. Dự kiến ​​rằng hầu hết những người triển khai Môi trường thực thi tin cậy (TEE) sẽ thấy công cụ C++ thuận tiện hơn, vì vậy tài liệu này chỉ thảo luận về cách trình bày C++.

Giao diện HIDL bao gồm một tập hợp các phương thức, được biểu thị dưới dạng:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

Có nhiều loại được xác định trước khác nhau và HAL có thể xác định các loại cấu trúc và liệt kê mới. Để biết thêm chi tiết về HIDL, xem phần Tham khảo .

Một phương thức ví dụ từ Keymaster 3 IKeymasterDevice.hal là:

generateKey(vec<KeyParameter> keyParams)
        generates(ErrorCode error, vec<uint8_t> keyBlob,
                  KeyCharacteristics keyCharacteristics);

Điều này tương đương với điều sau đây từ keymaster2 HAL:

keymaster_error_t (*generate_key)(
        const struct keymaster2_device* dev,
        const keymaster_key_param_set_t* params,
        keymaster_key_blob_t* key_blob,
        keymaster_key_characteristics_t* characteristics);

Trong phiên bản HIDL, đối số dev bị loại bỏ vì nó ẩn. Đối số params không còn là một cấu trúc chứa con trỏ tham chiếu một mảng các đối tượng key_parameter_t nữa mà là một vec (vectơ) chứa các đối tượng KeyParameter . Các giá trị trả về được liệt kê trong mệnh đề " generates ", bao gồm một vectơ giá trị uint8_t cho blob khóa.

Phương thức ảo C++ do trình biên dịch HIDL tạo ra là:

Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams,
                         generateKey_cb _hidl_cb) override;

Trong đó generateKey_cb là một con trỏ hàm được định nghĩa là:

std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob,
                   const KeyCharacteristics& keyCharacteristics)>

Nghĩa là, generateKey_cb là hàm nhận các giá trị trả về được liệt kê trong mệnh đề tạo. Lớp triển khai HAL ghi đè phương thức generateKey này và gọi con trỏ hàm generateKey_cb để trả về kết quả của thao tác cho người gọi. Lưu ý cuộc gọi con trỏ hàm là đồng bộ . Người gọi gọi generateKeygenerateKey gọi con trỏ hàm được cung cấp, con trỏ này thực thi đến khi hoàn thành, trả lại quyền điều khiển cho việc triển khai generateKey , sau đó trả về cho người gọi.

Để biết ví dụ chi tiết, hãy xem cách triển khai mặc định trong hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp . Việc triển khai mặc định cung cấp khả năng tương thích ngược cho các thiết bị có keymaster0, keymaster1 hoặc keymaster2 HALS kiểu cũ.

Kiểm soát truy cập

Quy tắc cơ bản nhất của kiểm soát quyền truy cập Keystore là mỗi ứng dụng có không gian tên riêng. Nhưng đối với mọi quy tắc đều có một ngoại lệ. Keystore có một số bản đồ được mã hóa cứng cho phép một số thành phần hệ thống nhất định truy cập vào một số không gian tên khác. Đây là một công cụ rất đơn giản ở chỗ nó cung cấp cho một thành phần toàn quyền kiểm soát không gian tên khác. Và sau đó là vấn đề về các thành phần của nhà cung cấp với tư cách là khách hàng của Keystore. Hiện tại chúng tôi không có cách nào để thiết lập một không gian tên cho các thành phần của nhà cung cấp, ví dụ như chất thay thế WPA.

Để phù hợp với các thành phần của nhà cung cấp và tổng quát hóa việc kiểm soát truy cập mà không có ngoại lệ được mã hóa cứng, Keystore 2.0 giới thiệu các miền và không gian tên SELinux.

Tên miền kho khóa

Với miền Keystore, chúng tôi có thể tách các vùng tên khỏi UID. Khách hàng truy cập khóa trong Keystore phải chỉ định miền, không gian tên và bí danh mà họ muốn truy cập. Dựa trên bộ dữ liệu này và danh tính của người gọi, chúng tôi có thể xác định khóa nào người gọi muốn truy cập và liệu nó có quyền thích hợp hay không.

Chúng tôi giới thiệu năm tham số miền chi phối cách truy cập khóa. Chúng kiểm soát ngữ nghĩa của tham số không gian tên của bộ mô tả khóa và cách thực hiện kiểm soát truy cập.

  • DOMAIN_APP : Miền ứng dụng bao gồm hành vi cũ. SPI kho khóa Java sử dụng miền này theo mặc định. Khi miền này được sử dụng, đối số không gian tên sẽ bị bỏ qua và thay vào đó, UID của người gọi sẽ được sử dụng. Quyền truy cập vào miền này được kiểm soát bởi nhãn Keystore đối với lớp keystore_key trong chính sách SELinux.
  • DOMAIN_SELINUX : Miền này cho biết không gian tên có nhãn trong chính sách SELinux. Tham số không gian tên được tra cứu và dịch sang ngữ cảnh đích, đồng thời thực hiện kiểm tra quyền đối với ngữ cảnh SELinux đang gọi cho lớp keystore_key . Khi quyền đã được thiết lập cho thao tác nhất định, toàn bộ bộ dữ liệu sẽ được sử dụng để tra cứu khóa.
  • DOMAIN_GRANT : Miền cấp cho biết rằng tham số không gian tên là mã định danh cấp. Tham số bí danh bị bỏ qua. Kiểm tra SELinux được thực hiện khi cấp phép được tạo. Kiểm soát truy cập sâu hơn chỉ kiểm tra xem UID của người gọi có khớp với UID của người được cấp của quyền được yêu cầu hay không.
  • DOMAIN_KEY_ID : Miền này cho biết tham số không gian tên là id khóa duy nhất. Bản thân khóa có thể đã được tạo bằng DOMAIN_APP hoặc DOMAIN_SELINUX . Việc kiểm tra quyền được thực hiện sau khi domainnamespace đã được tải từ cơ sở dữ liệu khóa theo cách tương tự như khi blob được tải bởi miền, không gian tên và bộ bí danh. Cơ sở lý luận cho miền id chính là tính liên tục. Khi truy cập khóa bằng bí danh, các lệnh gọi tiếp theo có thể hoạt động trên các khóa khác nhau vì khóa mới có thể đã được tạo hoặc nhập và liên kết với bí danh này. Tuy nhiên, id chính không bao giờ thay đổi. Vì vậy, khi sử dụng khóa theo id khóa sau khi nó được tải từ cơ sở dữ liệu Keystore bằng bí danh một lần, người ta có thể chắc chắn rằng đó là cùng một khóa miễn là id khóa vẫn tồn tại. Chức năng này không được hiển thị cho các nhà phát triển ứng dụng. Thay vào đó, nó được sử dụng trong Android Keystore SPI để mang lại trải nghiệm nhất quán hơn ngay cả khi được sử dụng đồng thời theo cách không an toàn.
  • DOMAIN_BLOB : Miền blob cho biết rằng người gọi tự quản lý blob. Điều này được sử dụng cho các máy khách cần truy cập Keystore trước khi gắn kết phân vùng dữ liệu. Blob khóa được bao gồm trong trường blob của bộ mô tả khóa.

Bằng cách sử dụng miền SELinux, chúng tôi có thể cấp cho các thành phần của nhà cung cấp quyền truy cập vào các không gian tên Keystore rất cụ thể mà các thành phần hệ thống có thể chia sẻ, chẳng hạn như hộp thoại cài đặt.

Chính sách SELinux cho keystore_key

Nhãn không gian tên được định cấu hình bằng tệp keystore2_key_context .
Mỗi dòng trong các tệp này ánh xạ id không gian tên số tới nhãn SELinux. Ví dụ,

# wifi_key is a keystore2_key namespace intended to be used by wpa supplicant and
# Settings to share keystore keys.
102            u:object_r:wifi_key:s0

Sau khi thiết lập một không gian tên khóa mới theo cách này, chúng ta có thể cấp quyền truy cập vào nó bằng cách thêm một chính sách thích hợp. Ví dụ: để cho phép wpa_supplicant lấy và sử dụng các khóa trong không gian tên mới, chúng tôi sẽ thêm dòng sau vào hal_wifi_supplicant.te :

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Sau khi thiết lập không gian tên mới, AndroidKeyStore có thể được sử dụng gần như bình thường. Sự khác biệt duy nhất là ID không gian tên phải được chỉ định. Để tải và nhập khóa từ và vào Keystore, id vùng tên được chỉ định bằng cách sử dụng AndroidKeyStoreLoadStoreParameter . Ví dụ,

import android.security.keystore2.AndroidKeyStoreLoadStoreParameter;
import java.security.KeyStore;

KeyStore keystore = KeyStore.getInstance("AndroidKeyStore");
keystore.load(new AndroidKeyStoreLoadStoreParameter(102));

Để tạo khóa trong một không gian tên nhất định, id vùng tên phải được cung cấp bằng KeyGenParameterSpec.Builder#setNamespace():

import android.security.keystore.KeyGenParameterSpec;
KeyGenParameterSpec.Builder specBuilder = new KeyGenParameterSpec.Builder();
specBuilder.setNamespace(102);

Các tệp ngữ cảnh sau đây có thể được sử dụng để định cấu hình không gian tên Keystore 2.0 SELinux. Mỗi phân vùng có phạm vi dành riêng khác nhau gồm 10.000 id không gian tên để tránh xung đột.

Vách ngăn Phạm vi Tập tin cấu hình
Hệ thống 0 ... 9,999
/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts
Hệ thống mở rộng 10.000... 19.999
/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts
Sản phẩm 20.000... 29.999
/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts
Người bán 30.000... 39.999
/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

Máy khách yêu cầu khóa bằng cách yêu cầu miền SELinux và vùng tên ảo mong muốn, trong trường hợp này là "wifi_key" , theo id số của nó.

Trên đó, các không gian tên sau đã được xác định. Nếu chúng thay thế các quy tắc đặc biệt, bảng sau sẽ cho biết UID mà chúng sử dụng tương ứng.

ID không gian tên Nhãn chính sách SE UID Sự miêu tả
0 su_key không áp dụng Khóa siêu người dùng. Chỉ được sử dụng để thử nghiệm trên các bản dựng userdebug và eng. Không liên quan đến bản dựng của người dùng.
1 shell_key không áp dụng Không gian tên có sẵn cho shell. Chủ yếu được sử dụng để thử nghiệm, nhưng cũng có thể được sử dụng trên các bản dựng của người dùng từ dòng lệnh.
100 vold_key không áp dụng Dự định sử dụng bởi vold.
101 odsing_key không áp dụng Được sử dụng bởi daemon ký trên thiết bị.
102 wifi_key AID_WIFI(1010) Được sử dụng bởi hệ thống Wifi của Android bao gồm wpa_supplicant.
120 sơ yếu lý lịch_on_reboot_key AID_HỆ THỐNG(1000) Được sử dụng bởi máy chủ hệ thống của Android để hỗ trợ tiếp tục khởi động lại.

Truy cập vectơ

Lớp SELinux keystore_key đã cũ đi khá nhiều và một số quyền, chẳng hạn như verify hoặc sign đã mất đi ý nghĩa. Đây là bộ quyền mới, keystore2_key , mà Keystore 2.0 sẽ thực thi.

Sự cho phép Nghĩa
delete Đã kiểm tra khi xóa khóa khỏi Keystore.
get_info Được kiểm tra khi siêu dữ liệu của khóa được yêu cầu.
grant Người gọi cần có quyền này để tạo quyền cấp cho khóa trong ngữ cảnh đích.
manage_blob Người gọi có thể sử dụng DOMAIN_BLOB trên vùng tên SELinux đã cho, do đó tự quản lý các đốm màu. Điều này đặc biệt hữu ích cho vold.
rebind Quyền này kiểm soát xem bí danh có thể được chuyển sang khóa mới hay không. Điều này là cần thiết để chèn và ngụ ý rằng khóa được liên kết trước đó sẽ bị xóa. Về cơ bản, nó là một quyền chèn, nhưng nó nắm bắt ngữ nghĩa của kho khóa tốt hơn.
req_forced_op Khách hàng có quyền này có thể tạo các hoạt động không thể chỉnh sửa và việc tạo hoạt động không bao giờ thất bại trừ khi tất cả các vị trí hoạt động đều được thực hiện bởi các hoạt động không thể chỉnh sửa.
update Cần thiết để cập nhật thành phần phụ của khóa.
use Đã được kiểm tra khi tạo thao tác Keymint sử dụng tài liệu khóa, ví dụ: để ký, en/giải mã.
use_dev_id Bắt buộc khi tạo thông tin nhận dạng thiết bị, chẳng hạn như chứng thực id thiết bị.

Ngoài ra, chúng tôi tách ra một tập hợp các quyền kho khóa cụ thể không có khóa trong lớp bảo mật SELinux keystore2 :

Sự cho phép Nghĩa
add_auth Được nhà cung cấp dịch vụ xác thực như Gatekeeper hoặc BiometricsManager yêu cầu để thêm mã thông báo xác thực.
clear_ns Trước đây là clear_uid, quyền này cho phép người không phải là chủ sở hữu của một vùng tên có thể xóa tất cả các khóa trong vùng tên đó.
list Được hệ thống yêu cầu để liệt kê các khóa theo nhiều thuộc tính khác nhau, chẳng hạn như quyền sở hữu hoặc giới hạn xác thực. Người gọi liệt kê không gian tên của riêng họ không cần có quyền này. Điều này được bao phủ bởi quyền get_info .
lock Quyền này cho phép khóa Keystore, tức là loại bỏ khóa chính, khiến các khóa liên kết xác thực trở nên không sử dụng được và không thể tạo được.
reset Quyền này cho phép đặt lại Keystore về mặc định ban đầu, xóa tất cả các khóa không quan trọng đối với hoạt động của hệ điều hành Android.
unlock Cần có quyền này để cố gắng mở khóa chính cho các khóa được xác thực.