Kho khoá dựa trên phần cứng

Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

Việc có môi trường thực thi đáng tin cậy trong một hệ thống trên một khối xếp (SoC) mang đến cơ hội để các thiết bị Android cung cấp các dịch vụ bảo mật mạnh mẽ, dựa trên 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í là cho các ứng dụng của bên thứ ba. Nhà phát triển tìm kiếm các tiện ích dành riêng cho Android nên chuyển đến android.security.keystore.

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

Trong Android 6.0, Kho khoá đã thêm các thuật toán mã hoá đối xứng nguyên gốc, AES và HMAC, cũng như hệ thống kiểm soát quyền truy cập cho các khoá dựa trên phần cứng. Các chế độ kiểm soát truy cập được chỉ định trong quá trình tạo khoá và được thực thi trong suốt vòng đời của khoá. Bạn có thể hạn chế việc chỉ sử dụng được khoá 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ụ thể. Để biết thêm thông tin, hãy xem trang Thẻ uỷ quyền.

Ngoài việc mở rộng phạm vi các thuật toán gốc mã hoá, Kho khoá trong Android 6.0 còn bổ sung những tính năng sau:

• Một lược đồ kiểm soát mức sử dụng để cho phép giới hạn mức sử dụng khoá, nhằm giảm thiểu rủi ro về bảo mật do sử dụng sai khoá
• Một lược đồ kiểm soát quyền truy cập để cho phép hạn chế các khoá cho người dùng, máy khách và phạm vi thời gian đã chỉ định

Trong Android 7.0, Keymaster 2 đã thêm tính năng hỗ trợ chứng thực khoá và liên kết phiên bản. Tính năng chứng thực khoá cung cấp chứng chỉ khoá công khai chứa nội dung mô tả chi tiết về khoá và các chế độ kiểm soát quyền truy cập của khoá, để xác minh từ xa sự tồn tại của khoá trong phần cứng bảo mật và cấu hình của khoá.

Liên kết phiên bản liên kết các khoá 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 nếu 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, thì kẻ tấn công 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 khoá được tạo bằng phiên bản mới hơn. Ngoài ra, khi một khoá có phiên bản và cấp bản vá nhất định được sử dụng trên một 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, khoá đó sẽ được nâng cấp trước khi có thể sử dụng và phiên bản khoá trước đó sẽ không hợp lệ. Khi thiết bị được nâng cấp, các khoá sẽ "chuyển tiếp" cùng với thiết bị, nhưng mọi thao tác quay lại bản phát hành trước của thiết bị sẽ khiến các khoá không sử dụng được.

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

Ngoài bản sửa đổi giao diện này, Android 8.0 còn mở rộng tính năng chứng thực của Keymaster 2 để hỗ trợ chứng thực giấy tờ tuỳ thân. Chứng thực danh tính cung cấp một cơ chế hạn chế và không bắt buộc để chứng thực mạnh mẽ các giá trị 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à mã điện thoại (IMEI / MEID). Để triển khai phần bổ sung này, Android 8.0 đã thay đổi giản đồ chứng thực ASN.1 để thêm chứng thực giấy tờ tuỳ thân. Các hoạt động 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 một cơ chế để vô hiệu hoá tính năng 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 khoá an toàn
• Hỗ trợ mã hoá 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 biệt cho phép cập nhật độc lập

Bảng chú giải thuật ngữ

Dưới đây là thông tin tổng quan nhanh về các thành phần của Kho khoá và mối quan hệ giữa các thành phần đó.

AndroidKeystore là API Khung Android và thành phần mà các ứng dụng sử dụng để truy cập vào chức năng Kho khoá. API này được triển khai dưới dạng một tiện ích mở rộng cho các API Kiến trúc mã hoá Java chuẩn và bao gồm mã Java chạy trong không gian quy trình của chính ứng dụng. AndroidKeystore thực hiện các yêu cầu của ứng dụng đối với hành vi của Kho khoá bằng cách chuyển tiếp các yêu cầu đó đến trình nền kho khoá.

Trình nền kho khoá 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 khoá bằng Binder API. Thư viện này chịu trách nhiệm lưu trữ "key blob" (tệp khoá) chứa tài liệu khoá bí mật thực tế, được mã hoá để Kho khoá có thể lưu trữ nhưng không sử dụng hoặc tiết lộ các tệp này.

keymasterd là một máy chủ HIDL cung cấp quyền truy cập vào TA Keymaster. (Tên này chưa được chuẩn hoá và chỉ dùng 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 ngữ cảnh bảo mật, thường là trong TrustZone trên một SoC ARM, cung cấp tất cả các thao tác bảo mật của Kho khoá, có quyền truy cập vào tài liệu khoá thô, xác thực tất cả các điều kiện kiểm soát quyền truy cập trên khoá, v.v.

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à vân tay. Đây không phải là một phần của Kho khoá, nhưng có liên quan vì nhiều thao tác khoá Kho khoá yêu cầu xác thực người dùng. LockSettingsService tương tác với TA Gatekeeper và TA vân tay để lấy mã thông báo xác thực. Mã thông báo này được cung cấp cho trình nền kho khoá và cuối cùng được ứng dụng TA Keymaster sử dụng.

Gatekeeper TA (ứng dụng đáng tin cậy) là một thành phần khác chạy trong ngữ cảnh bảo mật, chịu trách nhiệm xác thực mật khẩu của người dùng và tạo mã thông báo xác thực dùng để chứng minh cho Keymaster TA rằng đã xác thực 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 ngữ cảnh bảo mật, chịu trách nhiệm xác thực vân tay người dùng và tạo mã thông báo xác thực dùng để chứng minh cho Keymaster TA rằng đã xác thực cho một người dùng cụ thể tại một thời điểm cụ thể.

Kiến trúc

API Kho khoá Android và HAL Keymaster cơ bản cung cấp một tập hợp các nguyên hàm mã hoá 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 khoá được kiểm soát quyền truy cập và dựa trên phần cứng.

Keymaster HAL là một thư viện có thể tải động do OEM cung cấp, được dịch vụ Kho khoá sử dụng để cung cấp các dịch vụ mã hoá dựa trên phần cứng. Để đảm bảo tính bảo mật, các hoạt động 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 hạt nhân. Các thao tác nhạy cảm được uỷ quyền cho một trình xử lý bảo mật được truy cập thông qua một số giao diện nhân. Cấu trúc kết quả sẽ có dạng như sau:

Hình 1. Quyền truy cập vào Keymaster

Trong một thiết bị Android, "ứng dụng" của HAL Keymaster bao gồm nhiều lớp (ví dụ: ứng dụng, khung, trình nền Kho khoá), nhưng bạn có thể bỏ qua lớp đó cho 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 các thành phần nội bộ của nền tảng sử dụ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 dành cho nhà phát triển Android.

Mục đích của HAL Keymaster 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ỉ để điều phối và huỷ điều phối các yêu cầu đến thế giới bảo mật. Định dạng dây được xác định bằng cách triển khai.

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

HAL Keymaster 1 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. Để hỗ trợ khả năng tương tác trên các thiết bị chạy Android 5.0 trở xuống được khởi chạy bằng các HAL Keymaster cũ, Kho khoá cung cấp một bộ chuyển đổi triển khai HAL Keymaster 1 bằng các lệnh gọi đến 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 HAL Keymaster 1. Cụ thể, lớp này chỉ hỗ trợ các thuật toán RSA và ECDSA, đồng thời tất cả các hoạt động thực thi uỷ quyền khoá đều do bộ chuyển đổi thực hiện trong môi trường không an toàn.

Keymaster 2 đã đơn giản hoá giao diện HAL hơn nữa bằng cách xoá các phương thức get_supported_* và cho phép phương thức finish() chấp nhận dữ liệu đầu vào. Điều này giúp giảm số lượt đi và về đến TEE trong trường hợp dữ liệu đầu vào có sẵn cùng một lúc và đơn giản hoá 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 HAL C++ đượ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. Bạn có thể tạo một phương thức triển khai HAL kiểu mới bằng cách tạo lớp con cho lớp IKeymasterDevice đã tạo và triển khai các phương thức ảo thuần tuý. Trong quá trình thay đổi, nhiều loại đối số đã thay đổi, mặc dù các loại và phương thức có mối tương ứng một với một với các loại 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ế triển khai độc lập với ngôn ngữ để chỉ định giao diện phần cứng. Bộ công cụ HIDL hiện hỗ trợ việc tạo giao diện C++ và Java. Chúng tôi dự kiến rằng hầu hết các nhà triển khai Môi trường thực thi đáng tin cậy (TEE) sẽ thấy công cụ C++ thuận tiện hơn, vì vậy, trang này chỉ thảo luận về cách thể hiệ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ị dưới dạng:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

Có nhiều loại được xác định trước 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 thông tin chi tiết về HIDL, hãy xem Mục tham khảo.

Một phương thức mẫu từ IKeymasterDevice.hal Keymaster 3 là:

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

Mã này tương đương với mã sau đây trong HAL keymaster2:

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ị xoá vì đối số này là ngầm ẩn. Đối số params không còn là một cấu trúc chứa con trỏ tham chiếu đến một mảng đối tượng key_parameter_t, 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ơ các giá trị uint8_t cho blob khoá.

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

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

Trong đó, generateKey_cb là con trỏ hàm được xác định 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 lấy 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 phương thức gọi. Lưu ý rằng lệnh gọi con trỏ hàm là đồng bộ. Phương thức gọi gọi generateKey và generateKey gọi con trỏ hàm được cung cấp, thực thi cho đến khi hoàn tất, trả lại quyền kiểm soát cho quá trình triển khai generateKey, sau đó trả về phương thức 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. Phương thứ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ó HAL keymaster0, keymaster1 hoặc keymaster2 kiểu cũ.

Kiểm soát quyền truy cập

Quy tắc cơ bản nhất của tính năng kiểm soát quyền truy cập vào Kho khoá là mỗi ứng dụng có một không gian tên riêng. Tuy nhiên, mọi quy tắc đều có ngoại lệ. Kho khoá có một số bản đồ được mã hoá cứng cho phép một số thành phần hệ thống truy cập vào một số không gian tên nhất định khác. Đây là một công cụ rất thô sơ vì nó cấp cho một thành phần toàn quyền kiểm soát một không gian tên khác. Ngoài ra, còn có vấn đề về các thành phần của nhà cung cấp đóng vai trò là ứng dụng cho Kho khoá. 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ụ: ứng dụng yêu cầu WPA.

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

Miền kho khoá

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

Chúng tôi giới thiệu 5 tham số miền quản lý cách truy cập khoá. Các thuộc tính này kiểm soát ngữ nghĩa của tham số không gian tên của chỉ số mô tả khoá và cách thực hiện kiểm soát quyền truy cập.

• DOMAIN_APP: Miền ứng dụng bao gồm hành vi cũ. Theo mặc định, SPI Kho khoá Java sử dụng miền này. Khi sử dụng miền này, đối số không gian tên sẽ bị bỏ qua và UID của phương thức gọi sẽ được sử dụng. Quyền truy cập vào miền này được kiểm soát bằng nhãn Kho khoá cho lớp keystore_key trong chính sách SELinux.
• DOMAIN_SELINUX: Miền này cho biết rằng không gian tên có nhãn trong chính sách SELinux. Tham số không gian tên được tìm và dịch thành ngữ cảnh mục tiêu, đồng thời kiểm tra quyền được thực hiện cho ngữ cảnh SELinux 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 dùng để tra cứu khoá.
• DOMAIN_GRANT: Miền cấp phép cho biết rằng tham số không gian tên là giá trị nhận dạng cấp phép. Tham số bí danh sẽ bị bỏ qua. Hoạt động kiểm tra SELinux được thực hiện khi bạn tạo quyền cấp. Cơ chế kiểm soát quyền truy cập bổ sung chỉ kiểm tra xem UID của phương thức gọi có khớp với UID của bên được cấp quyền của quyền cấp được yêu cầu hay không.
• DOMAIN_KEY_ID: Miền này cho biết rằng tham số không gian tên là một mã khoá duy nhất. Chính khoá này 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 khoá theo cách tương tự như khi blob được tải bằng miền, không gian tên và bộ dữ liệu đại diện. Lý do cho miền mã khoá là tính liên tục. Khi truy cập khoá theo bí danh, các lệnh gọi tiếp theo có thể hoạt động trên nhiều khoá, vì khoá 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, mã khoá không bao giờ thay đổi. Vì vậy, khi sử dụng khoá theo mã khoá sau khi khoá đã được tải từ cơ sở dữ liệu Kho khoá bằng bí danh một lần, bạn có thể chắc chắn rằng đó là cùng một khoá miễn là mã khoá vẫn tồn tại. Các nhà phát triển ứng dụng sẽ không thấy được chức năng này. Thay vào đó, API này đượ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 phương thức gọi tự quản lý blob. Phương thức này được dùng cho các ứng dụng cần truy cập vào Kho khoá trước khi phân vùng dữ liệu được gắn. Blob khoá được đưa vào trường blob của chỉ số mô tả khoá.

Khi sử dụng miền SELinux, chúng ta 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 Kho khoá 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 liên kết một mã nhận dạng không gian tên dạng số với 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 không gian tên khoá mới theo cách này, chúng ta có thể cấp quyền truy cập vào không gian tê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 khoá trong không gian tên mới, chúng ta 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, bạn có thể sử dụng AndroidKeyStore gần như bình thường. Sự khác biệt duy nhất là bạn phải chỉ định mã không gian tên. Để tải và nhập khoá từ và vào Kho khoá, mã nhận dạng không gian tên được chỉ định bằ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 khoá trong một không gian tên nhất định, bạn phải cung cấp mã nhận dạng không gian tên bằng cách sử dụng KeyGenParameterSpec.Builder#setNamespace():

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

Bạn có thể dùng các tệp ngữ cảnh sau để định cấu hình không gian tên SELinux của Kho khoá 2.0. Mỗi phân vùng có một dải 10.000 mã nhận dạng không gian tên được dành riêng để 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

Ứng dụng yêu cầu khoá 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", theo mã nhận dạng dạng số.

Ngoài ra, các không gian tên sau đây đã được xác định. Nếu các quy tắc này thay thế các quy tắc đặc biệt, bảng sau đây sẽ cho biết UID mà các quy tắc này từng tương ứng.

Truy cập vào vectơ

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

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