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 đang tìm kiếm các 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ó 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 các nguyên bản mật mã đối xứng , AES và HMAC, và một 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 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, hãy xem các trang Chức năng và Thẻ cấp phép .

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. Chứng thực khóa cung cấp các chứng chỉ khóa công khai chứa mô tả chi tiết về khóa và các điều khiển truy cập của khóa, để làm cho sự tồn tại của khóa trong phần cứng an toàn và cấu hình của khóa có thể 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ể đư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 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ế 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:

• 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
• 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 khung Android và thành phần được các ứng dụng sử dụng để truy cập chức năng Kho khóa. 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 đối với hành vi của Kho khóa bằng cách chuyển tiếp chúng đến daemon kho khóa.

Daemon kho khóa là một daemon 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ữ "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 quyền 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 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 Kho khóa an toàn, có quyền truy cập vào tài liệu khóa thô, xác nhận 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 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 Gatekeeper TA và Fingerprint TA để lấy mã thông báo xác thực, mã này cung cấp cho nền tảng kho khóa và cuối cùng được sử dụng bởi ứng dụng Keymaster TA.

Gatekeeper TA (ứng dụng đáng tin cậy) là một thành phần khác chạy trong ngữ cảnh an toàn, 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 được sử 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ể.

Fingerprint TA (ứng dụng đáng tin cậy) là một thành phần khác chạy trong bối cảnh an toàn, 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 được sử 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 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:

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 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 đã đơ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 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. Triển khai HAL kiểu mới được tạo ra bằng cách phân lớp lớp IKeymasterDevice 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 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, hãy 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 dev , đối số nhà phát triển bị loại bỏ vì nó ngầm. Đối số params không còn là một cấu trúc chứa một con trỏ tham chiếu đến một mảng các đối tượng key_parameter_t , mà là một vec (vector) 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ơ có giá trị uint8_t cho khối khóa.

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;

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)>

Tức là, generateKey_cb là một hàm nhận các giá trị trả về được liệt kê trong mệnh đề tạo. Lớp thực thi 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 hoạt động cho trình gọi. Lưu ý rằng lời gọi con trỏ hàm là đồng bộ . Người gọi gọi generateKey và generateKey gọi con trỏ hàm được cung cấp, con trỏ này sẽ 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 đó quay trở lại người gọi.

Để có 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 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 hành vi cũ. 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. Quyền truy cập vào miền này được kiểm soát bởi nhãn Keystore đối với keystore_key của lớp trong chính sách SELinux.
• DOMAIN_SELINUX : Miền này chỉ ra rằng 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 và kiểm tra quyền được thực hiệ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 hoạt động nhất định, bộ giá trị đầy đủ đượ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ộ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 : Miền này chỉ ra rằng tham số không gian tên là một 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 domain và namespace đã được tải từ cơ sở dữ liệu khóa theo cách giống như khi khối đượ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 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 : Miền blob chỉ ra 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 Kho khóa trước khi phân vùng dữ liệu được gắn kết. Key blob được bao gồm trong trường blob của bộ mô tả khóa.

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

Các 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ạ 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 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 không gian 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 không gian 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 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.

/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts

/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts

/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts

/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à không gian tên ảo mong muốn, trong trường hợp này là "wifi_key" , bằng 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.

Truy cập Vectơ

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

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