Authentication

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ật mã. Việc này liên quan đến các thành phần sau:

  • Nhà cung cấp dịch vụ và bộ nhớ khoá mã hoá. Lưu trữ khoá mã hoá và cung cấp các quy trình mã hoá tiêu chuẩn dựa trên các khoá đó. Android hỗ trợ Kho khoá dựa trên phần cứng và KeyMint (trước đây là Keymaster) cho các dịch vụ mã hoá, bao gồm cả hoạt động 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ợ 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ị đi kèm với Android 9 trở lên có thể sử dụng BiometricPrompt là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 truyền đạt 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ợ.)

Mỗi thành phần trong số 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 quy cách giao diện Lớp trừu tượng phần cứng (HAL) và vượt qua các kiểm thử tương ứng của bộ kiểm thử dành riêng cho nhà cung cấp (VTS).

Quá trình triển khai của nhà cung cấp thường cũng được chia thành hai 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.
  • Một ứ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ý

Vào 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ả các trình xác thực đều được chuẩn bị để nhận thông tin đăng nhập của 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 giá trị nhận dạng bảo mật (SID) gồm 64 bit được tạo ngẫu nhiên cho người dùng. Giá trị này đó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ậ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; các hoạt động xác thực thành công đối 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 xuất trình thông tin đăng nhập đó. Nếu một 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 thao tác đăng ký không đáng tin cậy để đăng ký thông tin đăng nhập mới mà không cần xuất trình thông tin đăng nhập hiện có. Thao tác 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 theo SID người dùng cũ sẽ bị mất vĩnh viễn.

Xác thực

Phần này mô tả một quy trình xác thực điển hình, bao gồm các hoạt động 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) mà chúng dùng để xác thực thông báo của nhau.

Sau khi thiết lập thông tin đăng nhập và được chỉ định một 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, vân tay hoặc dữ liệu sinh trắc học mạnh khác. Quy trình xác thực

Hình 1. Quy trình xác thực

  1. 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 đối với dịch vụ HAL.
    • Đố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 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, 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 sinh trắc học thích hợp (ví dụ: fingerprintd cho vân tay hoặc faced cho 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 sẽ diễn ra không đồng bộ sau khi yêu cầu được gửi.
  2. Dịch vụ HAL gửi dữ liệu đến TA tương ứng. TA này sẽ tạo AuthToken:
    • Đối với phương thức xác thực bằng mã PIN/hình mở khoá/mật khẩu, gatekeeperd sẽ gửi mã PIN, hình mở khoá hoặc hàm băm mật khẩu đến TA Gatekeeper trong TEE thông qua dịch vụ HAL Gatekeeper. Nếu 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 quy trình 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 TA vân tay trong TEE thông qua HAL vân tay. Nếu quá trình xác thực trong TEE thành công, TA Vân tay sẽ phát AuthToken (được ký bằng khoá AuthToken HMAC).
    • Đối với các phương thức xác thực bằng sinh trắc học khác, danh sách 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ụ HAL sinh trắc học và TA thích hợp.
  3. Trình nền nhận AuthToken đã ký và truyền mã này đế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.)
  4. Dịch vụ Kho khoá sẽ truyền AuthToken đến KeyMint và xác minh các AuthToken đó 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 truyền từ TA trình xác thực đến dịch vụ keystore2 trong Android, sau đó dịch vụ này sẽ chuyển AuthToken đến TA KeyMint. Đ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ẽ thất bại, vì dịch vụ này biết về 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 đưa ra theo quy cách 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 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 để TA có được quyền truy cập vào khoá HMAC dùng chung này:

  • Thoả thuận về bí mật dùng chung: Dịch vụ keystore2 thực hiện giao thức thoả thuận khoá nhiều chiều khi khởi động thiết bị, cho phép phái sinh an toàn khoá HMAC giữa những TA tham gia. Tuy nhiên, các TA tham gia phải có quyền truy cập vào một khoá 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 nội bộ giữa các quy trình (tuỳ 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 thay thế. Trusty sử dụng một 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; Fingerprint và Gatekeeper yêu cầu khoá từ KeyMint cho mỗi lần sử dụng và không duy 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 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ẽ thất bại vì dịch vụ này có kiến thức về 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.