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.

Trang này được dịch bởi Cloud Translation API.

Xác thực

Android sử dụng khái niệm khóa mật mã xác thực người dùng yêu cầu các thành phần sau:

Nhà cung cấp dịch vụ và lưu trữ khóa mật mã. Lưu trữ các khóa mật mã và cung cấp các quy trình mã hóa tiêu chuẩn dựa trên các khóa đó. Android hỗ trợ Keystore và Keymaster được hỗ trợ bằng phần cứng cho các dịch vụ mật mã, bao gồm cả mật mã được hỗ trợ bằng phần cứng để lưu trữ khóa có thể bao gồm Môi trường thực thi đáng tin cậy (TEE) hoặc Phần tử bảo mật (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 của người dùng và/hoặc xác thực thành công. Android hỗ trợ Gatekeeper để xác thực mã PIN/mẫu/mật khẩu và Dấu vân tay để xác thực dấu vân tay. Các thiết bị chạy Android 9 trở lên có thể sử dụng BiometricPrompt làm điểm tích hợp duy nhất cho dấu vân tay và sinh trắc học bổ sung. Các thành phần này truyền đạt trạng thái xác thực của chúng với dịch vụ kho khóa thông qua kênh được xác thực. ( Hệ thống kho khóa Android ở cấp khung cũng được hỗ trợ bởi dịch vụ kho khóa.)

Các thành phần Gatekeeper, Vân tay và Sinh trắc học hoạt động với Keystore và các thành phần khác để hỗ trợ việc sử dụng mã thông báo xác thực được hỗ trợ bằng phần cứng (AuthTokens).

Ghi danh

Trong lần khởi động thiết bị đầu tiên sau khi khôi phục cài đặt gốc, tất cả các trình xác thực đều sẵn sàng nhận đăng ký thông tin xác thực từ người dùng. Ban đầu người dùng phải đăng ký mã PIN/mẫu/mật khẩu với Gatekeeper. Việc đăng ký ban đầu này tạo ra một mã định danh an toàn cho người dùng (SID) 64-bit được tạo ngẫu nhiên, đóng vai trò là mã định danh cho người dùng và là mã thông báo ràng buộc cho tài liệu mật mã của người dùng. SID người dùng này được liên kết bằng mật mã với mật khẩu của người dùng; xác thực thành công với Gatekeeper dẫn đến AuthTokens chứa SID người dùng cho mật khẩu đó.

Người dùng muốn thay đổi thông tin xác thực phải xuất trình thông tin xác thực hiện có. Nếu thông tin xác thực hiện có được xác minh thành công, SID người dùng được liên kết với thông tin xác thực hiện có sẽ được chuyển sang thông tin xác thực mới, cho phép người dùng tiếp tục truy cập các khóa sau khi thay đổi thông tin xác thực. Nếu người dùng không xuất trình thông tin xác thực hiện có thì thông tin xác thực mới sẽ được đăng ký với SID người dùng hoàn toàn ngẫu nhiên. Người dùng có thể truy cập thiết bị nhưng các khóa được tạo theo SID người dùng cũ sẽ bị mất vĩnh viễn. Điều này được gọi là đăng ký không đáng tin cậy .

Trong các trường hợp thông thường, khung Android không cho phép đăng ký không đáng tin cậy, vì vậy hầu hết người dùng sẽ không bao giờ thấy chức năng này. Tuy nhiên, việc buộc phải đặt lại mật khẩu bởi quản trị viên thiết bị hoặc kẻ tấn công có thể khiến điều này xảy ra.

Xác thực

Sau khi người dùng thiết lập thông tin xác thực và nhận 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ở khóa, mật khẩu hoặc dấu vân tay. Tất cả các thành phần TEE đều chia sẻ một khóa bí mật mà chúng sử dụng để xác thực tin nhắn của nhau.

Hình 1. Luồng 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 sẽ đưa ra yêu cầu tới daemon được liên kết.
- Đối với mã PIN, mẫu hoặc mật khẩu, LockSettingsService sẽ gửi yêu cầu tới gatekeeperd .
- Luồng xác thực dựa trên 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, FingerprintService đưa ra yêu cầu lấy fingerprintd ). Trên các thiết bị chạy Android 9 trở lên, BiometricPrompt đưa ra yêu cầu tới daemon sinh trắc học thích hợp (ví dụ: lấy fingerprintd để lấy dấu vân tay hoặc faced cho khuôn mặt) bằng cách sử dụng lớp Biometric Manager thích hợp, chẳng hạn như FingerprintManager hoặc FaceManager . Bất kể phiên bản nào, xác thực sinh trắc học đều diễn ra không đồng bộ sau khi yêu cầu được gửi.
Trình nền sẽ gửi dữ liệu đến đối tác của nó để tạo ra AuthToken:
- Để xác thực mã PIN/mẫu/mật khẩu, gatekeeperd sẽ gửi mã PIN, mẫu hoặc hàm băm mật khẩu đến Người gác cổng trong TEE. Nếu xác thực trong TEE thành công, Gatekeeper trong TEE sẽ gửi AuthToken chứa SID người dùng tương ứng (được ký bằng khóa AuthToken HMAC) tới đối tác của nó trong Hệ điều hành Android.
- Để xác thực dấu vân tay, fingerprintd sẽ lắng nghe các sự kiện dấu vân tay và gửi dữ liệu đến Dấu vân tay trong TEE. Nếu xác thực trong TEE thành công, Dấu vân tay trong TEE sẽ gửi AuthToken (được ký bằng khóa AuthToken HMAC) tới đối tác của nó trong Hệ điều hành Android.
- Đối với xác thực sinh trắc học khác, daemon sinh trắc học thích hợp sẽ lắng nghe sự kiện sinh trắc học và gửi nó đến thành phần TEE sinh trắc học thích hợp.
Trình nền nhận được AuthToken đã ký và chuyển nó đến dịch vụ kho khóa thông qua tiện ích mở rộng cho giao diện Binder của dịch vụ kho khóa. ( gatekeeperd cũng thông báo cho dịch vụ kho khóa khi thiết bị bị khóa lại và khi mật khẩu thiết bị thay đổi.)
Dịch vụ kho khóa chuyển AuthTokens đến Keymaster và xác minh chúng bằng khóa được chia sẻ với Gatekeeper và thành phần TEE sinh trắc học được hỗ trợ. Keymaster tin tưởng dấu thời gian trong mã thông báo là thời gian xác thực cuối cùng và đưa ra quyết định phát hành khóa (để cho phép ứng dụng sử dụng khóa) dựa trên dấu thời gian.

Định dạng mã thông báo xác thực

Để đảm bảo chia sẻ mã thông báo và khả năng tương thích giữa các ngôn ngữ và thành phần, định dạng AuthToken được mô tả trong hw_auth_token.h . Định dạng này là một giao thức tuần tự hóa đơn giản với các trường có kích thước cố định.

Cánh đồng	Kiểu	Yêu cầu	Sự miêu tả
Phiên bản AuthToken	1 byte	Đúng	Thẻ nhóm cho tất cả các trường bên dưới.
Thử thách	Số nguyên không dấu 64-bit	KHÔNG	Một số nguyên ngẫu nhiên để ngăn chặn các cuộc tấn công lặp lại. Thông thường ID của hoạt động mật mã được yêu cầu. Hiện đang được sử dụng bởi ủy quyền dấu vân tay giao dịch. Nếu có, AuthToken chỉ hợp lệ cho các hoạt động tiền điện tử có cùng thử thách.
SID người dùng	Số nguyên không dấu 64-bit	Đúng	Giá trị nhận dạng người dùng không lặp lại được gắn bằng mật mã với tất cả các khóa liên quan đến xác thực thiết bị. Để biết chi tiết, xem Người gác cổng .
ID xác thực (ASID)	Số nguyên không dấu 64 bit theo thứ tự mạng	KHÔNG	Mã định danh được sử dụng để liên kết với chính sách xác thực cụ thể. Tất cả các trình xác thực đều có giá trị ASID riêng mà chúng có thể thay đổi theo yêu cầu của riêng mình.
Loại xác thực	Số nguyên không dấu 32 bit theo thứ tự mạng	Đúng	0x00 là Người gác cổng. 0x01 là Dấu vân tay.
Dấu thời gian	Số nguyên không dấu 64 bit theo thứ tự mạng	Đúng	Thời gian (tính bằng mili giây) kể từ lần khởi động hệ thống gần đây nhất.
AuthToken HMAC (SHA-256)	đốm màu 256-bit	Đúng	Đã khóa MAC SHA-256 của tất cả các trường ngoại trừ trường HMAC.

Luồng khởi động thiết bị

Trong mỗi lần khởi động thiết bị, khóa AuthToken HMAC phải được tạo và chia sẻ với tất cả các thành phần TEE (Gatekeeper, Keymaster và các ủy thác 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 lặp lại, khóa HMAC phải được tạo ngẫu nhiên mỗi khi thiết bị khởi động lại.

Giao thức chia sẻ khóa HMAC này với tất cả các thành phần là một tính năng triển khai phụ thuộc vào nền tảng. Chìa khóa không bao giờ được cung cấp bên ngoài TEE. Nếu HĐH TEE thiếu cơ chế giao tiếp liên tiến trình nội bộ (IPC) và cần truyền dữ liệu qua HĐH không đáng tin cậy thì việc truyền dữ liệu phải được thực hiện thông qua giao thức trao đổi khóa an toàn.

Hệ điều hành Trusty chạy bên cạnh Android là một ví dụ về TEE, nhưng có thể sử dụng các TEE khác để thay thế. Trusty sử dụng hệ thống IPC nội bộ để liên lạc trực tiếp giữa Keymaster và Gatekeeper hoặc ủy thác sinh trắc học thích hợp. Khóa HMAC chỉ được giữ trong Keymaster; Dấu vân tay và Người gác cổng yêu cầu khóa từ Keymaster cho mỗi lần sử dụng và không lưu giữ hoặc lưu giá trị vào bộ nhớ đệm.

Vì một số TEE thiếu cơ sở hạ tầng IPC nên không có giao tiếp nào xảy ra giữa các applet trong TEE. Điều này cũng cho phép dịch vụ kho khóa nhanh chóng từ chối các yêu cầu có khả năng thất bại vì nó biết về bảng xác thực trong hệ thống, tiết kiệm IPC có thể tốn kém vào TEE.