Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

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

Tính khả dụng 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ởi phần cứng cho hệ điều hành 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 tìm kiếm các phần mở rộng Android cụ thể nên đến android.security.keystore .

Trước Android 6.0, Android đã có một API dịch vụ tiền điện tử đơn giản, được hỗ trợ bởi 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 ký và xác minh kỹ thuật số, cùng với việc tạo và nhập các cặp khóa ký bất đố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ý. Kho khóa trong Android 6.0 đã mở rộng API Kho khóa để cung cấp nhiều khả năng hơn.

Trong Android 6.0, Keystore thêm nguyên thủy đối xứng mật mã , AES và HMAC, và một hệ thống kiểm soát truy cập cho các phím phần cứng hỗ trợ. 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 thời gian tồn tại của khóa. Các khóa có thể bị hạn chế chỉ sử dụng được sau khi người dùng đã được xác thực và chỉ cho các mục đích cụ thể hoặc với các tham số mật mã được chỉ định. Để biết thêm thông tin, vui lòng xem Authorization Thẻchức năng trang.

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

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

Trong Android 7.0, Keymaster 2 đã thêm hỗ trợ chứng thực khóa và ràng buộc phiên bản. Xác nhận chính cung cấp chứng thực khóa công khai có chứa một mô tả chi tiết của khóa và kiểm soát truy cập của nó, để làm cho sự tồn tại của chủ chốt trong phần cứng bảo mật và cấu hình của nó từ xa có thể kiểm chứng.

Phiên bản ràng buộc khóa liên kết với các hệ điều hành và phiên bản vá cấp. Đ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ể đưa thiết bị trở lại 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 khóa có phiên bản và cấp bản vá nhất định được sử dụng 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, khóa sẽ được nâng cấp trước khi có thể được sử dụng và phiên bản trước của khóa sẽ bị vô hiệu. Khi thiết bị được nâng cấp, các phím "bánh cóc" chuyển tiếp cùng với thiết bị, nhưng bất kỳ sự đảo ngược nào của thiết bị về bản phát hành trước đó đều khiến các phím không thể sử dụng được.

Trong Android 8.0, Keymaster 3 đã chuyển đổi từ Lớp trừu tượng phần cứng cấu trúc C (HAL) 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 kiểu đối số đã thay đổi, mặc dù các kiểu và phương thức có sự tương ứng 1-1 với các kiểu cũ và phương thức cấu trúc HAL. Xem Chức năng trang để biết thêm chi tiết.

Ngoài phiên bản giao diện này, Android 8.0 mở rộng tính năng xác nhận Keymaster 2 để hỗ trợ ID xác nhận . Chứng thực ID cung cấp một cơ chế giới hạn và tùy chọn để chứng thực mạnh mẽ các số 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 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 phải tìm một số cách an toàn để truy xuất các mục dữ liệu 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:

  • Update để 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
  • Các thay đổi đối với ràng buộc phiên bản để boot.img và system.img có các phiên bản đặt riêng biệt để 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à API Android Framework và thành phần được sử dụng bởi các ứng dụng để truy cập chức năng Keystore. Nó được triển khai như một phần mở rộng cho các 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 quy trình riêng của ứng dụng. AndroidKeystore đáp ứng các yêu cầu ứng dụng cho hành vi Keystore bằng cách chuyển tiếp chúng đến daemon keystore.

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

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

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

LockSettingsService là thành phần hệ thống Android chịu trách nhiệm về 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 hoạt động chính của Keystore yêu cầu xác thực người dùng. LockSettingsService tương tác với các Gatekeeper TA và vân tay TA để lấy thẻ xác thực, mà nó cung cấp cho các daemon keystore, và mà cuối cùng được tiêu thụ bởi các ứng dụng Keymaster TA.

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

Vân tay TA (ứng dụng đáng tin cậy) là một thành phần chạy trong bối cảnh an toàn có trách nhiệm để xác thực dấu vân tay người dùng và tạo ra xác thực mã thông báo sử dụng để chứng minh cho Keymaster TA rằng một chứng thực được thực hiện cho một người dùng cụ thể tại một điểm cụ thể trong thời gian.

Ngành kiến ​​trúc

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

Keymaster HAL là một thư viện có thể tải động, do OEM cung cấp được sử dụng bởi dịch vụ Keystore để cung cấp các dịch vụ mật mã được hỗ trợ bởi phần cứng. Để giữ mọi thứ an toàn, các triển khai HAL không thực hiện bất kỳ hoạt động nhạy cảm nào trong không gian người dùng hoặc thậm chí trong không gian hạt nhân. Các hoạt động nhạy cảm được giao cho một bộ xử lý an toàn đạt được 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 vào Keymaster

Trong thiết bị Android, "client" của Keymaster HAL bao gồm nhiều lớp (ví dụ: ứng dụng, khuôn khổ, daemon Keystore), nhưng điều đó có thể bị bỏ qua 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ả là 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 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 của 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ỉ để thực hiện các yêu cầu thống nhất và không quản lý đối với thế giới an toàn. Định dạng dây được xác định bởi việc triển khai.

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ụ như Keymaster 0.2 và 0.3. Để hỗ trợ khả năng tương tác trên các thiết bị chạy Android 5.0 trở về trước được khởi chạy với Keymaster HALs cũ hơn, Keystore cung cấp bộ điều hợp triển khai Keymaster 1 HAL với các lệnh gọi đến thư viện phần cứng hiện có. Kết quả là không thể cung cấp đầy đủ các 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 được thực hiện bởi bộ điều hợp, trong thế giới không an toàn.

Keymaster 2 tiếp tục đơn giản hóa giao diện HAL bằng cách loại bỏ các get_supported_* phương pháp và cho phép finish() phương pháp để nhận tín hiệu vào. Điều này làm giảm số lượng các chuyến đi khứ hồi đến TEE trong trường hợp đầu vào 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ừ cấu trúc C kiểu cũ HAL sang giao diện C ++ HAL được tạo ra từ một định nghĩa trong Ngôn ngữ định nghĩa giao diện phần cứng (HIDL) mới. Một thực hiện HAL kiểu mới được tạo ra bởi subclassing tạo IKeymasterDevice lớp và thực hiện các phương pháp ảo tinh khiết. Là một phần của sự thay đổi, nhiều kiểu đối số đã thay đổi, mặc dù các kiểu và phương thức có sự tương ứng 1-1 với các kiểu cũ và 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 một cơ chế độc lập với ngôn ngữ triển khai để chỉ định các 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ề biểu diễn C ++.

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

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

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

Một phương pháp 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 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, các dev luận được lấy ra, bởi vì nó tiềm ẩn. Các params tranh luận không còn là một struct chứa một con trỏ tham khảo một loạt các key_parameter_t đối tượng, nhưng một vec (vector) có chứa KeyParameter đối tượng. Các giá trị trả về được liệt kê trong " generates " điều khoản, trong đó có một vector của uint8_t giá trị cho các blob then chốt.

Phương thức ảo C ++ được tạo bởi trình biên dịch HIDL là:

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

Nơi generate_cb được một con trỏ hàm định nghĩa là:

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

Đó là, generate_cb là một chức năng mà sẽ đưa các giá trị trở lại được liệt kê trong mệnh đề tạo. Lớp thực hiện HAL đè này generateKey phương pháp và gọi generate_cb con trỏ hàm để trả về kết quả của các hoạt động để người gọi. Lưu ý gọi con trỏ hàm là đồng bộ. Người gọi gọi generateKeygenerateKey gọi là con trỏ hàm cung cấp, mà thực hiện để hoàn thành, trở về điều khiển đến đoạn generateKey thực hiện, sau đó trở về người gọi.

Đối với một ví dụ chi tiết, xem việc thực hiện 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 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ệ. Kho khóa có một số bản đồ được mã hóa cứng cho phép các 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 cùn ở chỗ nó cung cấp cho một thành phần toàn quyền kiểm soát đối với mộ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. Chúng tôi hiện không có cách nào để thiết lập không gian tên cho các thành phần của nhà cung cấp, chẳng hạn như chất hỗ trợ WPA.

Để phù hợp với các thành phần của nhà cung cấp và kiểm soát truy cập tổng quát 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 các miền Kho khóa, chúng tôi có thể tách không gian tên khỏi UID. Khách hàng truy cập một 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 tuple 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 mà người gọi muốn truy cập và khóa đó 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 các khóa có thể được truy cập. 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 kiểm soát truy cập được thực hiện.

  • DOMAIN_APP : Miền ứng dụng bao gồm các hành vi di sản. Java Keystore SPI 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. Truy cập đến tên miền này được điều khiển bởi các nhãn Keystore đến lớp keystore_key trong chính sách SELinux.
  • DOMAIN_SELINUX : Tên miền này chỉ ra rằng không gian tên có nhãn trong chính sách SELinux. Tham số namespace được nhìn lên và dịch sang một bối cảnh mục tiêu, và một tấm séc cho phép được thực hiện cho gọi SELinux bối cảnh cho keystore_key lớp. Khi quyền đã được thiết lập cho hoạt động nhất định, bộ giá trị đầy đủ được sử dụng để tra cứu khóa.
  • DOMAIN_GRANT : Tên miền cấp cho thấy rằng các tham số namespace là một định danh cấp. Tham số bí danh bị bỏ qua. Kiểm tra SELinux được thực hiện khi khoản cấp được tạo. Kiểm soát truy cập hơn nữa 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 khoản tài trợ được yêu cầu hay không.
  • DOMAIN_KEY_ID : Tên miền này chỉ ra rằng các tham số không gian tên là chìa khóa id duy nhất. Chìa khóa chính nó có thể đã được tạo ra với DOMAIN_APP hoặc DOMAIN_SELINUX . Vui lòng cung phép được thực hiện sau khi domain và các namespace đã được nạp từ cơ sở dữ liệu quan trọng trong cùng một cách như thể blob đã được nạp bởi các tên miền, tên miền không gian, và tuple bí danh. Cơ sở lý luận cho miền id khóa là tính liên tục. Khi truy cập một khóa bằng bí danh, các cuộc 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. Mã khóa, tuy nhiên, 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 Kho khóa 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 để cung cấp 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 : Tên miền blob chỉ ra rằng người gọi quản lý blob của chính nó. Điều này được sử dụng cho các máy khách cần truy cập Kho khóa trước khi phân vùng dữ liệu được gắn kết. Blob chủ chốt được bao gồm trong blob lĩnh vực của bộ mô tả chính.

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ẻ như hộp thoại cài đặt.

Chính sách SELinux cho keystore_key

Nhãn namespace được cấu hình bằng cách sử dụng keystore2_key_context tập tin.
Mỗi dòng trong các tệp này ánh xạ một id không gian tên số đến một 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 tôi 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 để có được và sử dụng các phím 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. Đối với tải và nhập khẩu chìa khóa từ và thành Keystore, id namespace được quy đị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 ra một chìa khóa trong một không gian tên nào đó, id namespace phải được sử dụ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 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ó một phạm vi dự phò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 Định cấu hình tệp
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

Các khách hàng yêu cầu chìa khóa bằng cách yêu cầu các miền SELinux và không gian tên ảo mong muốn, trong trường hợp này "wifi_key" , bởi id số của nó.

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

ID không gian tên Nhãn SEPolicy UID Sự miêu tả
0 su_key N / A Phím siêu người dùng. Chỉ được sử dụng để thử nghiệm trên bản dựng userdebug và eng. Không liên quan đến các bản dựng của người dùng.
1 shell_key N / A Không gian tên có sẵn cho trình bao. Chủ yếu được sử dụng để thử nghiệm, nhưng có thể được sử dụng trên các bản dựng của người dùng cũng như từ dòng lệnh.
100 vold_key N / A Dự định để sử dụng bởi vold.
101 odsing_key N / A Đượ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 hệ thống Wi-Fi của Android bao gồm wpa_supplicant.
120 Resume_on_reboot_key AID_SYSTEM (1000) Được sử dụng bởi máy chủ hệ thống của Android để hỗ trợ tiếp tục khi khởi động lại.

Truy cập Vectơ

Lớp SELinux keystore_key đã già đi một chút và một số quyền, chẳng hạn như verify hoặc sign đã mất đi ý nghĩa của chúng. Dưới đây là tập hợp mới các điều khoản, keystore2_key , mà Keystore 2.0 sẽ thực thi.

Sự cho phép Nghĩa
delete Được 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 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 namespace SELinux nhất định, do đó việc quản lý các đốm màu của chính nó. Điều này đặc biệt hữu ích cho vold.
rebind Quyền này kiểm soát nếu một bí danh có thể được khôi phục lại thành một khóa mới. Điều này là bắt buộc để chèn và ngụ ý rằng khóa được ràng buộc 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 Ứng dụng khách có quyền này có thể tạo các hoạt động không thể duyệt được 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 được thực hiện bởi các hoạt động không thể truy cập.
update Bắt buộc phải cập nhật thành phần con của một khóa.
use Được kiểm tra khi tạo thao tác Keymint sử dụng tài liệu chính, ví dụ: để ký, vi / 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ị.

Thêm vào đó, chúng tôi chia ra một tập các điều khoản cụ thể keystore chính phi trong SELinux lớp an ninh keystore2 :

Sự cho phép Nghĩa
add_auth Được yêu cầu bởi nhà cung cấp xác thực như Gatekeeper hoặc BiometricsManager để 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 xóa tất cả các khóa trong vùng tên đó.
list Hệ thống yêu cầu để liệt kê các khóa theo các 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. Quyền này không được yêu cầu bởi những người gọi liệt kê không gian tên riêng của họ. Này được bao phủ bởi các get_info phép.
lock Quyền này cho phép khóa Keystore, tức là loại bỏ khóa chính, sao cho các khóa giới hạn xác thực trở nên không sử dụng được và không thể xử lý đượ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 Quyền này là cần thiết để cố gắng mở khóa chính cho các khóa giới hạn xác thực.