Android có khái niệm về trình xác thực người dùng được dùng để mở khoá thiết bị và kiểm soát quyền truy cập vào các khoá mã hoá. Điều này liên quan đến các thành phần sau:
- Bộ nhớ khoá mã hoá và nhà cung cấp dịch vụ. Lưu trữ các khoá mã hoá và cung cấp các quy trình mã hoá tiêu chuẩn trên các khoá đó. Android hỗ trợ Kho khoá và KeyMint (trước đây là Keymaster) được hỗ trợ bằng phần cứng cho các dịch vụ mã hoá, bao gồm cả mã hoá được hỗ trợ bằng phần cứng cho bộ nhớ khoá có thể bao gồm Môi trường thực thi đáng tin cậy (TEE) hoặc Secure Element (SE), chẳng hạn như StrongBox.
- Trình xác thực người dùng. Chứng thực sự hiện diện và/hoặc quá trình xác thực thành công của người dùng. Android hỗ trợ
Gatekeeper để xác thực bằng mã PIN/hình mở khoá/mật khẩu
và Vân tay để xác thực bằng vân tay. Các thiết bị xuất xưởng chạy Android 9 trở lên có thể sử dụng
BiometricPromptlàm điểm tích hợp duy nhất cho vân tay và các dữ liệu sinh trắc học khác. Các thành phần này giao tiếp trạng thái xác thực của chúng với dịch vụ kho khoá thông qua một kênh đã xác thực. Hệ thống Kho khoá Android ở cấp khung cũng được hỗ trợ bởi dịch vụ kho khoá.
Mỗi thành phần này đều dành riêng cho nhà cung cấp, nhưng việc triển khai của nhà cung cấp phải đáp ứng thông số kỹ thuật của giao diện Lớp trừu tượng phần cứng (HAL) và vượt qua các bài kiểm tra tương ứng trong bộ kiểm thử của nhà cung cấp (VTS).
Việc triển khai của nhà cung cấp thường cũng được chia thành 2 phần, được kết nối bằng một cơ chế giao tiếp dành riêng cho nhà cung cấp :
- Dịch vụ HAL chạy dưới dạng một quy trình hệ thống Android, nhận các yêu cầu Binder từ hệ thống Android.
- Ứng dụng đáng tin cậy (TA) chạy trong môi trường bảo mật, thực hiện các thao tác bảo mật thực tế.
Đăng ký
Khi khởi động thiết bị lần đầu tiên sau khi đặt lại về trạng thái ban đầu, tất cả trình xác thực đều được chuẩn bị để nhận thông tin đăng ký thông tin đăng nhập từ người dùng. Ban đầu, người dùng phải đăng ký mã PIN, hình mở khoá hoặc mật khẩu bằng Gatekeeper (hoặc Weaver, nếu có). Quá trình đăng ký ban đầu này sẽ tạo một mã nhận dạng bảo mật người dùng (SID) 64 bit được tạo ngẫu nhiên, đóng vai trò là mã nhận dạng cho người dùng và mã thông báo ràng buộc cho tài liệu mã hoá của người dùng. SID người dùng này được ràng buộc bằng mật khẩu của người dùng theo cách mã hoá; quá trình xác thực thành công với Gatekeeper sẽ tạo ra AuthToken chứa SID người dùng cho mật khẩu đó.
Người dùng muốn thay đổi thông tin đăng nhập hiện có phải cung cấp thông tin đăng nhập đó. Nếu thông tin đăng nhập hiện có được xác minh thành công, thì SID người dùng được liên kết với thông tin đăng nhập hiện có sẽ được chuyển sang thông tin đăng nhập mới, cho phép người dùng tiếp tục truy cập vào các khoá sau khi thay đổi thông tin đăng nhập.
Trong một số trường hợp, quản trị viên thiết bị có thể thực hiện đăng ký không đáng tin cậy để đăng ký thông tin đăng nhập mới mà không cần cung cấp thông tin đăng nhập hiện có. Điều này cho phép người dùng truy cập vào thiết bị, nhưng các khoá được tạo trong SID người dùng cũ sẽ bị mất vĩnh viễn.
Xác thực
Phần này mô tả quy trình xác thực thông thường, bao gồm các tương tác giữa nhiều thành phần trong cả Android và môi trường bảo mật. Xin lưu ý rằng tất cả các thành phần bảo mật đều dùng chung một khoá HMAC bí mật (cho mỗi lần khởi động) để xác thực thông báo của nhau.
Sau khi người dùng thiết lập thông tin đăng nhập và được chỉ định SID người dùng, họ có thể bắt đầu xác thực. Quá trình này bắt đầu khi người dùng cung cấp mã PIN, hình mở khoá, mật khẩu, vân tay hoặc dữ liệu sinh trắc học mạnh khác.
Hình 1. Quy trình xác thực
- Người dùng cung cấp một phương thức xác thực và dịch vụ được liên kết
gửi yêu cầu đến dịch vụ HAL.
- Đối với mã PIN, hình mở khoá hoặc mật khẩu,
LockSettingsServicesẽ gửi yêu cầu đếngatekeeperd. - Quy trình xác thực dựa trên dữ liệu sinh trắc học phụ thuộc vào phiên bản Android.
Trên các thiết bị chạy Android 8.x trở xuống,
FingerprintServicesẽ gửi yêu cầu đếnfingerprintd). Trên các thiết bị chạy Android 9 trở lên,BiometricPromptsẽ gửi yêu cầu đến trình nền sinh trắc học thích hợp (ví dụ:fingerprintdcho vân tay hoặcfacedcho khuôn mặt) bằng cách sử dụng lớpBiometricManagerthích hợp, chẳng hạn nhưFingerprintManagerhoặcFaceManager. Bất kể phiên bản nào, quá trình xác thực bằng sinh trắc học sẽ diễn ra không đồng bộ sau khi yêu cầu được gửi.
- Đối với mã PIN, hình mở khoá hoặc mật khẩu,
- Dịch vụ HAL gửi dữ liệu đến TA đối tác, tạo AuthToken:
AuthToken:
- Đối với quá trình xác thực bằng mã PIN/hình mở khoá/mật khẩu,
gatekeeperdgửi mã PIN, hình mở khoá hoặc hàm băm mật khẩu đến Gatekeeper TA trong TEE, thông qua dịch vụ Gatekeeper HAL. Nếu quá trình xác thực trong TEE thành công, Gatekeeper TA sẽ phát ra một AuthToken chứa SID người dùng tương ứng (được ký bằng khoá HMAC dùng chung). - Đối với quá trình xác thực bằng vân tay,
fingerprintdsẽ theo dõi các sự kiện vân tay và gửi dữ liệu đến Fingerprint TA trong TEE, thông qua Fingerprint HAL. Nếu quá trình xác thực trong TEE thành công, Fingerprint TA sẽ phát ra một AuthToken (được ký bằng khoá HMAC AuthToken). - Đối với quá trình xác thực bằng dữ liệu sinh trắc học khác, trình nền sinh trắc học thích hợp sẽ theo dõi sự kiện sinh trắc học và gửi sự kiện đó đến dịch vụ và TA HAL sinh trắc học thích hợp.
- Đối với quá trình xác thực bằng mã PIN/hình mở khoá/mật khẩu,
- Trình nền nhận một AuthToken đã ký và chuyển mã thông báo đó đến dịch vụ kho khoá
thông qua một tiện ích cho giao diện Binder của dịch vụ kho khoá.
(
gatekeeperdcũng thông báo cho dịch vụ kho khoá khi thiết bị được khoá lại và khi mật khẩu thiết bị thay đổi.) - Dịch vụ Kho khoá chuyển AuthToken đến KeyMint và xác minh các mã thông báo đó bằng khoá được chia sẻ với Gatekeeper và thành phần TEE sinh trắc học được hỗ trợ. KeyMint tin tưởng dấu thời gian trong mã thông báo là thời gian xác thực gần đây nhất và đưa ra quyết định phát hành khoá (cho phép ứng dụng sử dụng khoá) dựa trên dấu thời gian.
Quy trình xác thực không yêu cầu giao tiếp trực tiếp giữa các TA trong môi trường bảo mật: AuthToken chuyển từ TA trình xác thực đến dịch vụ keystore2 trong Android, sau đó chuyển đến KeyMint TA.
Điều này cũng cho phép dịch vụ keystore2 nhanh chóng từ chối các yêu cầu chắc chắn sẽ không thành công, vì dịch vụ này biết các AuthToken có sẵn trong hệ thống, giúp tiết kiệm một IPC có khả năng tốn kém vào TEE.
Định dạng AuthToken
Định dạng của AuthToken được cung cấp theo thông số kỹ thuật AIDL trong
HardwareAuthToken.aidl.
Quy trình khởi động thiết bị
Trong mỗi lần khởi động thiết bị, khoá HMAC AuthToken phải được tạo và chia sẻ với tất cả các thành phần TEE (Gatekeeper, KeyMint và các trustlet sinh trắc học được hỗ trợ). Do đó, để tăng cường khả năng bảo vệ chống lại các cuộc tấn công phát lại, khoá HMAC phải được tạo ngẫu nhiên mỗi khi thiết bị khởi động lại.
Có 2 cách phổ biến để các TA có quyền truy cập vào khoá HMAC dùng chung này:
- Thoả thuận khoá bí mật dùng chung: Dịch vụ
keystore2thực hiện giao thức thoả thuận khoá nhiều chiều khi khởi động thiết bị, cho phép tạo khoá HMAC một cách an toàn giữa các TA tham gia. Tuy nhiên, các TA tham gia phải có quyền truy cập vào một bí mật dùng chung được chia sẻ trước - Truy cập trực tiếp: Các TA nằm trong cùng một môi trường bảo mật có thể sử dụng cơ chế giao tiếp liên quy trình nội bộ (phụ thuộc vào nền tảng) để chia sẻ khoá HMAC.
Trong cả hai trường hợp, khoá HMAC không bao giờ được cung cấp bên ngoài TEE.
Hệ điều hành Trusty ( chạy bên cạnh Android) là một ví dụ về TEE, nhưng bạn có thể sử dụng các TEE khác. Trusty sử dụng hệ thống IPC nội bộ để giao tiếp trực tiếp giữa KeyMint và Gatekeeper hoặc trustlet sinh trắc học thích hợp. Khoá HMAC chỉ được lưu giữ trong KeyMint; Vân tay và Gatekeeper yêu cầu khoá từ KeyMint cho mỗi lần sử dụng và không lưu giữ hoặc lưu vào bộ nhớ đệm giá trị.
Vì một số TEE thiếu cơ sở hạ tầng IPC, nên không có hoạt động giao tiếp nào giữa các applet trong TEE. Điều này cũng cho phép dịch vụ kho khoá nhanh chóng từ chối các yêu cầu chắc chắn sẽ không thành công vì dịch vụ này biết bảng xác thực trong hệ thống, giúp tiết kiệm một IPC có khả năng tốn kém vào TEE.