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.

Authentication

Android sử dụng khái niệm khoá mã hoá có cổng 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à bộ nhớ khoá mã hoá. 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á dựa trên phần cứng và Keymaster cho các dịch vụ mã hoá, bao gồm cả mã hoá dựa trên phần cứng để lưu trữ 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 của người dùng và/hoặc xác thực thành công. Android hỗ trợ Cổng kiểm soát để xác thực mã PIN/hình mở khoá/mật khẩu và Vân tay để xác thực vân tay. Các thiết bị chạy Android 9 trở lên có thể sử dụng BiometricPrompt làm một điểm tích hợp duy nhất cho vân tay và các thông tin sinh trắc học bổ sung. Các thành phần này thông báo 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 dịch vụ kho khoá hỗ trợ.)

Các thành phần Cổng bảo vệ, Vân tay và Sinh trắc học hoạt động với Kho khoá 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 (AuthTokens) được hỗ trợ phần cứng.

Đăng ký

Trong lần khởi động đầu tiên của thiết bị 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 xác thực của người dùng. Ban đầu, người dùng phải đăng ký mã PIN/hình mở khoá/mật khẩu với Gatekeeper. Lần đăng ký ban đầu này sẽ tạo một giá trị nhận dạng bảo mật (SID) 64 bit cho người dùng được tạo ngẫu nhiên, đóng vai trò là giá trị nhận dạng cho người dùng và là mã thông báo liên kết cho tài liệu mã hoá của người dùng. SID người dùng này được liên kết bằng phương thức mã hoá với mật khẩu của người dùng; các lượt xác thực thành công với Gatekeeper sẽ dẫn đến AuthToken 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 cung cấp thông tin xác thực hiện có. Nếu xác minh thành công thông tin xác thực hiện có, SID người dùng 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 vào các khoá sau khi thay đổi thông tin xác thực. Nếu người dùng không cung cấp thông tin xác thực hiện có, thì thông tin xác thực mới sẽ được đăng ký bằng một SID người dùng hoàn toàn ngẫu nhiên. Người dùng có thể truy cập vào thiết bị, nhưng các khoá được tạo theo SID người dùng cũ sẽ bị mất vĩnh viễn. Đây được gọi là lượt đăng ký không đáng tin cậy.

Trong trường hợp bình 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 đặt lại mật khẩu do quản trị viên thiết bị hoặc kẻ tấn công thực hiện một cách cưỡng bức có thể khiến điều này xảy ra.

Xác thực

Sau khi thiết lập thông tin xác thực và nhận được SID người dùng, người dùng 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 hoặc vân tay. Tất cả thành phần TEE đều dùng chung một khoá bí mật để xác thực tin nhắn của nhau.

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ụ liên kết sẽ đưa ra yêu cầu cho trình nền liên kết.
- Đối với mã PIN, hình mở khoá hoặc mật khẩu, LockSettingsService sẽ gửi yêu cầu đến gatekeeperd.
- Quy trình 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 sẽ gửi yêu cầu đến fingerprintd. Trên các thiết bị chạy Android 9 trở lên, BiometricPrompt sẽ gửi yêu cầu đến trình nền nhận dạng sinh trắc học thích hợp (ví dụ: fingerprintd đối với vân tay hoặc faced đối với khuôn mặt) bằng cách sử dụng lớp BiometricManager thích hợp, chẳng hạn như FingerprintManager hoặc FaceManager. Bất kể phiên bản nào, quá trình xác thực bằng sinh trắc học cũng 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 AuthToken:
- Để xác thực bằng mã PIN/hình mở khoá/mật khẩu, gatekeeperd sẽ gửi hàm băm mã PIN, hình mở khoá hoặc mật khẩu đến Gatekeeper trong TEE. Nếu xác thực trong TEE thành công, thì Trình kiểm soát truy cập trong TEE sẽ gửi một AuthToken chứa SID người dùng tương ứng (được ký bằng khoá HMAC AuthToken) đến đối tác trong Android OS.
- Đối với tính năng xác thực vân tay, fingerprintd sẽ theo dõi các sự kiện vân tay và gửi dữ liệu đến Vân tay trong TEE. Nếu xác thực trong TEE thành công, thì Fingerprint trong TEE sẽ gửi AuthToken (được ký bằng khoá HMAC AuthToken) đến đối tác trong Android OS.
- Đối với các phương thức xác thực 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 thành phần TEE sinh trắc học thích hợp.
Trình nền nhận AuthToken đã ký và chuyển AuthToken đó đế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á. (gatekeeperd cũ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á sẽ chuyển AuthTokens đến Keymaster và xác minh các mã thông báo đó bằng cách sử dụng khoá đượ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 gần đây nhất và dựa vào dấu thời gian đó để đưa ra quyết định phát hành khoá (cho phép ứng dụng sử dụng khoá).

Định dạng AuthToken

Để đảm bảo khả năng chia sẻ và tương thích của mã thông báo trên 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 chuyển đổi tuần tự đơn giản với các trường có kích thước cố định.

Trường	Loại	Bắt buộc	Mô tả
Phiên bản AuthToken	1 byte	Có	Thẻ nhóm cho tất cả các trường bên dưới.
Thách thức	Số nguyên 64 bit chưa ký	Không	Một số nguyên ngẫu nhiên để ngăn chặn các cuộc tấn công phát lại. Thường là mã nhận dạng của một thao tác mã hoá được yêu cầu. Hiện được các hoạt động uỷ quyền vân tay giao dịch sử dụng. Nếu có, AuthToken chỉ hợp lệ cho các thao tác mã hoá chứa cùng một thử thách.
SID người dùng	Số nguyên 64 bit chưa ký	Có	Giá trị nhận dạng người dùng không lặp lại được liên kết bằng phương thức mã hoá với tất cả các khoá liên kết với quá trình xác thực thiết bị. Để biết thông tin chi tiết, hãy xem phần Trình kiểm soát.
Mã xác thực (ASID)	Số nguyên 64 bit chưa ký theo thứ tự mạng	Không	Giá trị nhận dạng dùng để liên kết với một chính sách trình xác thực cụ thể. Tất 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 trình xác thực	Số nguyên 32 bit không dấu theo thứ tự mạng	Có	0x00 là Gatekeeper. 0x01 là Vân tay.
Dấu thời gian	Số nguyên 64 bit chưa ký theo thứ tự mạng	Có	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)	Blob 256 bit	Có	MAC SHA-256 được khoá của tất cả các trường ngoại trừ trường HMAC.

Quy trình khởi động thiết bị

Mỗi khi khởi động thiết bị, bạn phải tạo và chia sẻ khoá HMAC AuthToken với tất cả thành phần TEE (Gatekeeper, Keymaster và các trustlet sinh trắc học được hỗ trợ). Do đó, để tăng cườ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.

Giao thức chia sẻ khoá 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. Khoá không bao giờ được cung cấp bên ngoài TEE. Nếu một hệ điều hành TEE thiếu cơ chế giao tiếp liên quy trình (IPC) nội bộ và cần chuyển dữ liệu thông qua hệ điều hành không đáng tin cậy, thì quá trình chuyển phải được thực hiện thông qua giao thức trao đổi khoá 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 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 Keymaster và Gatekeeper hoặc trustlet sinh trắc học thích hợp. Khoá HMAC chỉ được lưu trữ trong Keymaster; Fingerprint và Gatekeeper yêu cầu khoá từ Keymaster cho mỗi lần sử dụng và không lưu trữ 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 xảy ra giữa các ứng dụng 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 có thông tin về bảng xác thực trong hệ thống, giúp tiết kiệm một IPC có thể tốn kém vào TEE.