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

Khả năng sử dụng môi trường thực thi đáng tin cậy trong hệ thống trên chip (SoC) mang lại cơ hội cho các thiết bị Android cung cấp dựa trên phần cứng, các dịch vụ bảo mật mạnh mẽ cho hệ điều hành Android, cho đến các dịch vụ nền tảng và thậm chí là ứng dụng bên thứ ba. Nhà phát triển đang tìm kiếm các tiện ích dành riêng cho Android nên truy cập vào android.security.keystore.

Trước Android 6.0, Android đã có một loại tiền mã hoá đơn giản, dựa trên phần cứng Services API, được cung cấp bởi các phiên bản 0.2 và 0.3 của Keymaster Hardware Lớp trừu tượng (HAL). Tính năng ký số và xác minh do kho khoá cung cấp cộng với việc tạo và nhập cặp khoá ký bất đối xứng. Đây là đã đượ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 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, chúng tôi đã thêm Kho khoá dữ liệu mật mã đối xứng, AES và HMAC và hệ thống kiểm soát truy cập dành cho các khoá dựa trên phần cứng. Quyền truy cập được chỉ định trong quá trình tạo khoá và được thực thi trong suốt thời gian hoạt động của khoá. Bạn có thể hạn chế khoá để chỉ sử dụng được sau khi người dùng đã được xác thực và chỉ dành cho những mục đích nhất định hoặc bằng mật mã học được chỉ định tham số. Để biết thêm thông tin, hãy xem Thẻ uỷ quyền và Trang Hàm.

Ngoài việc mở rộng phạm vi của dữ liệu mã hoá nguyên gốc, Kho khoá Android 6.0 bổ sung thêm 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 nguy cơ bị xâm phạm tính bảo mật do dùng khoá sai mục đích
• Sơ đồ kiểm soát quyền truy cập cho phép hạn chế khoá đối với những người dùng cụ thể, khách hàng và phạm vi thời gian xác định

Trong Android 7.0, Keymaster 2 đã thêm tính năng hỗ trợ chứng thực khoá và phiên bản ràng buộc. Chứng thực khoá cung cấp các chứng chỉ khoá công khai có 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á, để khoá vẫn tồn tại trong phần cứng bảo mật và cấu hình có thể xác minh từ xa.

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 bản vá. Điều này giúp đả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 khoá được tạo bằng phiên bản mới hơn. Ngoài ra, khi một khoá có một phiên bản cụ thể và cấp bản vá được sử dụng trên một thiết bị đã được nâng cấp lên một phiên bản mới hơn hoặc cấp bản vá, khoá sẽ được nâng cấp trước khi có thể sử dụng và phiên bản của khoá bị mất hiệu lực. Khi thiết bị được nâng cấp, các khoá ở trạng thái "chuột" tiến cùng với thiết bị, nhưng mọi phiên đảo ngược thiết bị về phiên bản trước đó khiến cho các phím không sử dụng được.

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

Ngoài việc sửa đổi giao diện này, Android 8.0 mở rộng Keymaster 2 chứng thực để hỗ trợ Chứng thực giá trị nhận dạng. Chứng thực mã nhận dạng cung cấp một cơ chế không bắt buộc và có giới hạn để chứng thực một cách hiệu quả đến mã nhận dạng phần cứng, chẳng hạn như số sê-ri của thiết bị, tên sản phẩm và số điện thoại Mã nhận dạng (IMEI / MEID). Để triển khai việc bổ sung này, Android 8.0 đã thay đổi ASN.1 giản đồ chứng thực để thêm chứng thực mã nhận dạng. 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 một cơ chế tắt tính năng một cách an toàn và vĩnh viễn.

Trên 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ợ tính năng nhập khoá bảo mật
• Hỗ trợ mã hoá 3DES
• Thay đổi đối vớ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 thuật ngữ

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

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

keystore daemon (trình nền kho khoá) là một trình nền hệ thống của Android cung cấp quyền truy cập vào tất cả chức năng của Kho khoá thông qua Binder API. Nó chịu trách nhiệm lưu trữ "key blobs", chứa tài liệu về khoá bí mật thực tế, đã mã hoá để Kho khoá 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ột máy chủ HIDL cung cấp quyền truy cập vào Keymaster TA. (Tên này không được chuẩn hoá 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 ngữ cảnh bảo mật, thường là trong TrustZone trên ARM SoC, cung cấp tất cả hoạt động trong Kho khoá an toàn, có quyền truy cập vào tài liệu khoá thô, xác thực tất cả điều kiện kiểm soát truy cập vào 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. Không thuộc Kho khoá, nhưng có liên quan vì nhiều thao tác khoá Kho khoá yêu cầu người dùng xác thực. LockSettingsService tương tác với Người trực điện thoại TA và Vân tay số để lấy mã thông báo xác thực mà mã này cung cấp cho trình nền kho khoá và cuối cùng được sử dụng bởi Keymaster TA .

TA của người trực điện thoại (ứ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, có nhiệm vụ xác thực người dùng mật khẩu và tạo mã xác thực dùng để chứng minh cho Keymaster TA rằng quá trình 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ể trong bất cứ lúc nào.

Vân tay 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 có nhiệm vụ xác thực người dùng lấy vân tay số và tạo mã xác thực dùng để chứng minh cho Keymaster TA cho biết quá trình xác thực đã được thực hiện cho một người dùng cụ thể tại một điểm cụ thể kịp thời.

Kiến trúc

API Kho khoá Android và HAL Keymaster cơ bản cung cấp một tập hợp mật mã gốc cơ bản nhưng đầy đủ để cho phép việc triển khai các giao thức bằng khoá kiểm soát truy cập, dựa trên phần cứng.

Keymaster HAL là một thư viện do OEM cung cấp, có thể tải linh động, được sử dụng trong dịch vụ Kho khoá để cung cấp các dịch vụ mật mã dựa trên phần cứng. Để giữ lại bảo mật, việc triển khai HAL (Lớp trừu tượng phần cứng) sẽ 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 nhân. Các hoạt động nhạy cảm được ủy quyền cho bộ xử lý bảo mật nào đó đạt được qua giao diện nhân hệ điều hành nào đó. Kiến trúc thu được sẽ có dạng như sau:

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

Trong thiết bị Android, "ứng dụng" của Keymaster HAL bao gồm nhiều lớp (ví dụ: ứng dụng, khung, trình nền Kho khoá), nhưng có thể bỏ qua cho mục đích của tài liệu này. Điều này có nghĩa là HAL Keymaster được mô tả API là cấp thấp, được các thành phần nội bộ trong nền tảng sử dụng và không tiếp xúc với ứng dụng nhà phát triển. 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 tính năng bảo mật nhạy cảm mà chỉ áp dụng cho các yêu cầu kiểm soát và yêu cầu không kiểm soát đối với thế giới bảo mật. Chiến lược phát hành đĩa đơn định dạng dây được xác định triển khai.

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

Keymaster 1 HAL hoàn toàn không tương thích với HAL được 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ở về trước được phát hành với HAL Keymaster cũ, Kho khoá cung cấp một bộ chuyển đổi giú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ả không thể cung cấp đầy đủ các chức năng trong Keymaster 1 HAL. Cụ thể, nó chỉ hỗ trợ thuật toán RSA và ECDSA cũng như tất cả bộ chuyển đổi thực hiện việc thực thi trong một thế giới không an toàn.

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

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

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

Đây là đoạn mã sau của 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 sẽ bị xoá vì đó 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 gồm các đối tượng key_parameter_t, nhưng một vec (vectơ) chứa các đối tượng KeyParameter. Chiến lược phát hành đĩa đơn giá trị trả về được liệt kê trong "generates" bao gồm một mệnh đề vectơ của 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 đị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 triển khai HAL sẽ ghi đè lớp này Phương thức generateKey và gọi hàm generateKey_cb con trỏ để trả về kết quả của thao tác cho phương thức gọi. Ghi chú hàm lệnh gọi con trỏ có tính đồng bộ. Người gọi generateKey và generateKey gọi phương thức đã cung cấp con trỏ hàm thực thi cho đến khi hoàn thành, trả về quyền điều khiển cho Triển khai generateKey, sau đó sẽ quay lại 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ó keymaster0, keymaster1 hoặc keymaster2 HALS 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 đều có không gian tên riêng. Nhưng mỗi quy tắc lại có một ngoại lệ. Kho khoá có một số các bản đồ được cố định giá trị trong mã 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. Đây là một công cụ rất cùn, trong đó nó đưa ra 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. Sau đó là vấn đề nhà cung cấp làm ứng dụng khách cho Kho khoá. Hiện tại, chúng tôi không có cách thiết lập không gian tên cho các thành phần của nhà cung cấp, ví dụ: nhà cung cấp WPA.

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

Miền kho khoá

Với miền Kho khoá, chúng ta có thể tách không gian tên khỏi UID. Khách hàng truy cập một khoá trong Kho khoá 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 phương thức gọi, chúng ta có thể xác định khoá mà người gọi muốn truy cập và liệu khoá đó có phù hợp hay không quyền truy cập.

Chúng tôi giới thiệu 5 tham số miền chi phối cách truy cập vào khoá. Chúng kiểm soát ngữ nghĩa của tham số không gian tên của mã 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 việc này được sử dụng, đối số không gian tên bị bỏ qua và UID của phương thức gọi được sử dụng thay thế. Quyền truy cập vào miền này được kiểm soát bởi nhãn Kho khoá vào phần tử 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 theo chính sách SELinux. Tham số không gian tên được nhìn và được dịch sang 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 cho lớp keystore_key. Khi quyền đã được thiết lập cho thao tác đã cho, thì bộ dữ liệu đầy đủ sẽ được sử dụng để tra cứu khoá.
• DOMAIN_GRANT: Miền cấp cho biết rằng tham số không gian tên là giá trị nhận dạng cấp quyền. Tham số bí danh bị bỏ qua. Quá trình kiểm tra SELinux sẽ được thực hiện khi tạo trạng thái cấp quyền. 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 người nhận tài trợ của khoản tiền tài trợ đượ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 id khoá duy nhất. Khoá có thể đã được tạo thông qua DOMAIN_APP hoặc DOMAIN_SELINUX. Quyền bước kiểm tra sẽ được thực hiện sau 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 theo miền, không gian tên và bộ bí danh. Lý do cho miền mã khoá chính là tính liên tục. Khi truy cập vào một khoá bằng bí danh, các cuộc gọi tiếp theo có thể hoạt động trên các khoá khác nhau vì một 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ã nhận dạng phím sau khi đã tải từ cơ sở dữ liệu Kho khoá bằng bí danh một lần, một 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. Chiến dịch này nhà phát triển ứng dụng sẽ không thấy chức năng này. Thay vào đó, ngôn ngữ này được dùng trong SPI Kho khoá Android 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. Trường này được sử dụng cho những khách hàng cần truy cập vào Kho khoá trước khi phân vùng dữ liệu được gắn kết. Blob chính là có trong trường blob của phần mô tả khoá.

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 không gian tên cụ thể trong Kho khoá có thể được các thành phần hệ thống chia sẻ như hộp thoại cài đặt.

Chính sách SELinux cho kho khoá_khoá

Nhãn không gian tên được định cấu hình bằng cách sử dụng keystore2_key_context .
Mỗi dòng trong các tệp này ánh xạ một mã không gian tên dạng số vớ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 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 bằng cách thêm 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 mà 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, AndroidKeyStore có thể được sử dụng gần như thông thường. Điểm khác biệt duy nhất là bạn phải chỉ định mã không gian tên. Cho tải và nhập các khoá từ và vào Kho khoá, mã không gian tên sẽ đượ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 khoá trong một không gian tên nhất định, bạn phải cung cấp mã không gian tên đang 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 dùng để định cấu hình Kho khoá 2.0 SELinux không gian tên. Mỗi phân vùng có một phạm vi không gian tên dành riêng là 10.000 để 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 khoá bằng cách yêu cầu miền SELinux và miền không gian tên ảo, trong trường hợp này là "wifi_key", theo mã nhận dạng dạng số.

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 đây cho biết UID mà chúng được sử dụng để tương ứng sang.

Truy cập vectơ

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

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