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.

Tính năng

Trang này chứa thông tin về các tính năng mật mã của Keystore trong Android 6.0 trở lên.

Cơ bản về mật mã

Kho khóa cung cấp các loại hoạt động sau:

  • Tạo khóa
  • Nhập và xuất các khóa không đối xứng (không có khóa)
  • Nhập khóa đối xứng thô (không có khóa)
  • Mã hóa và giải mã bất đối xứng với các chế độ đệm thích hợp
  • Ký kết và xác minh không đối xứng với chế độ tiêu hóa và đệm thích hợp
  • Mã hóa đối xứng và giải mã ở các chế độ thích hợp, bao gồm cả chế độ AEAD
  • Tạo và xác minh mã xác thực tin nhắn đối xứng

Các phần tử giao thức, chẳng hạn như mục đích, chế độ và phần đệm, cũng như các ràng buộc kiểm soát truy cập , được chỉ định khi khóa được tạo hoặc nhập và được liên kết vĩnh viễn với khóa, đảm bảo khóa không thể được sử dụng theo bất kỳ cách nào khác.

Ngoài danh sách trên, còn có một dịch vụ nữa mà các triển khai Keymaster cung cấp, nhưng không được tiết lộ dưới dạng API: Tạo số ngẫu nhiên. Điều này được sử dụng nội bộ để tạo khóa, Vectơ khởi tạo (IV), đệm ngẫu nhiên và các yếu tố khác của giao thức an toàn yêu cầu tính ngẫu nhiên.

Nguyên thủy cần thiết

Tất cả các triển khai Keymaster cung cấp:

  • RSA
    • Hỗ trợ phím 2048, 3072 và 4096-bit
    • Hỗ trợ cho số mũ công khai F4 (2 ^ 16 + 1)
    • Các chế độ đệm để ký RSA:
      • RSASSA-PSS ( PaddingMode::RSA_PSS )
      • RSASSA-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_SIGN )
    • Chế độ thông báo để ký RSA:
      • SHA-256
    • Các chế độ đệm cho mã hóa / giải mã RSA:
      • Không được đánh dấu
      • RSAES-OAEP ( PaddingMode::RSA_OAEP )
      • RSAES-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_ENCRYPT )
  • ECDSA
    • Hỗ trợ phím 224, 256, 384 và 521-bit được hỗ trợ, sử dụng các đường cong NIST P-224, P-256, P-384 và P-521 tương ứng
    • Chế độ thông báo cho ECDSA:
      • Không có thông báo nào (không dùng nữa, sẽ bị xóa trong tương lai)
      • SHA-256
  • AES
    • Các khóa 128 và 256 bit được hỗ trợ
    • CBC , CTR, ECB và GCM. Việc triển khai GCM không cho phép sử dụng các thẻ nhỏ hơn 96 bit hoặc có độ dài không quá 96 bit.
    • Chế độ đệm PaddingMode::NONE và PaddingMode::PKCS7 được hỗ trợ cho các chế độ CBC và ECB. Không có phần đệm, mã hóa chế độ CBC hoặc ECB không thành công nếu đầu vào không phải là bội số của kích thước khối.
  • HMAC SHA-256 , với bất kỳ kích thước khóa nào lên đến ít nhất 32 byte.

SHA1 và các thành viên khác của gia đình SHA2 (SHA-224, SHA384 và SHA512) được khuyến khích triển khai Keymaster. Keystore cung cấp chúng trong phần mềm nếu việc triển khai Keymaster phần cứng không cung cấp chúng.

Một số nguyên thủy cũng được khuyến nghị để có khả năng tương tác với các hệ thống khác:

  • Kích thước khóa nhỏ hơn cho RSA
  • Số mũ công khai tùy tiện cho RSA

Kiểm soát truy cập chính

Các khóa dựa trên phần cứng không bao giờ có thể được trích xuất từ ​​thiết bị sẽ không cung cấp nhiều bảo mật nếu kẻ tấn công có thể sử dụng chúng theo ý muốn (mặc dù chúng an toàn hơn các khóa có thể được lấy ra). Do đó, điều quan trọng là Keystore phải thực thi các kiểm soát truy cập.

Kiểm soát quyền truy cập được định nghĩa là "danh sách ủy quyền" của các cặp thẻ / giá trị. Thẻ ủy quyền là các số nguyên 32 bit và các giá trị có nhiều loại. Một số thẻ có thể được lặp lại để chỉ định nhiều giá trị. Việc một thẻ có thể được lặp lại hay không được chỉ định trong tài liệu cho thẻ . Khi một khóa được tạo, người gọi chỉ định một danh sách ủy quyền. Việc triển khai Keymaster bên dưới Kho khóa sửa đổi danh sách để chỉ định một số thông tin bổ sung, chẳng hạn như khóa có bảo vệ khôi phục hay không và trả về danh sách ủy quyền "cuối cùng", được mã hóa thành khối khóa được trả lại. Mọi nỗ lực sử dụng khóa cho bất kỳ hoạt động mật mã nào đều không thành công nếu danh sách ủy quyền cuối cùng bị sửa đổi.

Đối với Keymaster 2 trở về trước, tập hợp các thẻ có thể có được xác định trong liệt kê keymaster_authorization_tag_t và được cố định vĩnh viễn (mặc dù nó có thể được mở rộng). Các tên có tiền tố là KM_TAG . Bốn bit trên cùng của ID thẻ được sử dụng để chỉ ra loại.

Keymaster 3 đã thay đổi tiền tố KM_TAG thành Tag:: .

Các loại có thể bao gồm:

ENUM : Nhiều giá trị của thẻ được xác định trong kiểu liệt kê. Ví dụ: các giá trị có thể có của TAG::PURPOSE được xác định trong enum keymaster_purpose_t .

ENUM_REP : Giống như ENUM , ngoại trừ thẻ có thể được lặp lại trong danh sách ủy quyền. Sự lặp lại chỉ ra nhiều giá trị được cho phép. Ví dụ: một khóa mã hóa có thể có KeyPurpose::ENCRYPT và KeyPurpose::DECRYPT .

UINT : Số nguyên không dấu 32 bit. Ví dụ: TAG::KEY_SIZE

UINT_REP : Giống với UINT , ngoại trừ thẻ có thể được lặp lại trong danh sách ủy quyền. Sự lặp lại chỉ ra nhiều giá trị được cho phép.

ULONG : Số nguyên không dấu 64-bit. Ví dụ: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP : Giống như ULONG , ngoại trừ thẻ có thể được lặp lại trong danh sách ủy quyền. Sự lặp lại chỉ ra nhiều giá trị được cho phép.

DATE : Giá trị ngày / giờ, được biểu thị bằng mili giây kể từ ngày 1 tháng 1 năm 1970. Ví dụ: TAG::PRIVKEY_EXPIRE_DATETIME

BOOL : Đúng hay sai. Thẻ loại BOOL được giả định là "sai" nếu thẻ không có và "đúng" nếu có. Ví dụ: TAG::ROLLBACK_RESISTANT

BIGNUM : Các số nguyên có độ dài tùy ý, được biểu thị dưới dạng một mảng byte theo thứ tự big-endian. Ví dụ: TAG::RSA_PUBLIC_EXPONENT

BYTES : Một chuỗi các byte. Ví dụ: TAG::ROOT_OF_TRUST

Thực thi phần cứng so với phần mềm

Không phải tất cả các triển khai phần cứng an toàn đều chứa các tính năng giống nhau. Để hỗ trợ nhiều cách tiếp cận, Keymaster phân biệt giữa thực thi kiểm soát truy cập thế giới an toàn và không an toàn, hoặc thực thi phần cứng và phần mềm tương ứng.

Tất cả các triển khai:

  • Thực thi đối sánh chính xác (không phải thực thi) tất cả các ủy quyền. Danh sách ủy quyền trong các đốm màu chính khớp chính xác với các ủy quyền được trả lại trong quá trình tạo khóa, bao gồm cả việc đặt hàng. Bất kỳ sự không phù hợp nào cũng gây ra lỗi chẩn đoán.
  • Khai báo các ủy quyền có giá trị ngữ nghĩa được thực thi.

Cơ chế API để khai báo các ủy quyền do phần cứng thực thi nằm trong cấu trúc keymaster_key_characteristics_t . Nó chia danh sách ủy quyền thành hai danh sách con, hw_enforced và sw_enforced . Phần cứng an toàn chịu trách nhiệm đặt các giá trị thích hợp trong mỗi giá trị, dựa trên những gì nó có thể thực thi.

Ngoài ra, Keystore triển khai thực thi dựa trên phần mềm đối với tất cả các ủy quyền, cho dù chúng được thực thi bởi phần cứng an toàn hay không.

Ví dụ: hãy xem xét triển khai dựa trên TrustZone không hỗ trợ khóa hết hạn. Khóa có ngày hết hạn vẫn có thể được tạo. Danh sách ủy quyền của khóa đó sẽ bao gồm thẻ TAG::ORIGINATION_EXPIRE_DATETIME với ngày hết hạn. Yêu cầu tới Keystore đối với các đặc điểm chính sẽ tìm thấy thẻ này trong danh sách sw_enforced và phần cứng an toàn sẽ không thực thi yêu cầu hết hạn. Tuy nhiên, những nỗ lực sử dụng khóa sau khi hết hạn sẽ bị Keystore từ chối.

Nếu thiết bị sau đó được nâng cấp bằng phần cứng an toàn hỗ trợ hết hạn thì yêu cầu về các đặc điểm chính sẽ tìm thấy TAG::ORIGINATION_EXPIRE_DATETIME trong danh sách hw_enforced và việc cố gắng sử dụng khóa sau khi hết hạn sẽ không thành công ngay cả khi kho khóa bị lật đổ hoặc bỏ qua bằng cách nào đó .

Để biết thêm thông tin về việc xác định xem các khóa có được hỗ trợ bằng phần cứng hay không, hãy xem Chứng thực khóa .

Giấy phép xây dựng thông điệp mật mã

Các thẻ sau được sử dụng để xác định các đặc điểm mật mã của các hoạt động sử dụng khóa được liên kết: TAG::ALGORITHM , TAG::KEY_SIZE , TAG::BLOCK_MODE , TAG::PADDING :: PADDING, TAG::CALLER_NONCE và TAG::DIGEST

TAG::PADDING , TAG::DIGEST và PaddingMode::BLOCK_MODE có thể lặp lại, có nghĩa là nhiều giá trị có thể được liên kết với một khóa duy nhất và giá trị được sử dụng được chỉ định tại thời điểm hoạt động.

Mục đích

Các khóa có một tập hợp các mục đích được liên kết, được biểu thị dưới dạng một hoặc nhiều mục nhập ủy quyền với thẻ TAG::PURPOSE , xác định cách chúng có thể được sử dụng. Mục đích là:

  • KeyPurpose::ENCRYPT
  • KeyPurpose::DECRYPT
  • KeyPurpose::SIGN
  • KeyPurpose::VERIFY

Bất kỳ khóa nào cũng có thể có bất kỳ tập hợp con nào cho các mục đích này. Lưu ý rằng một số kết hợp tạo ra các vấn đề bảo mật. Ví dụ, một khóa RSA có thể được sử dụng để vừa mã hóa vừa để ký cho phép kẻ tấn công có thể thuyết phục hệ thống giải mã dữ liệu tùy ý để tạo ra chữ ký.

Nhập khẩu và xuất khẩu

Keymaster chỉ hỗ trợ xuất khóa công khai, ở định dạng X.509 và nhập:

  • Các cặp khóa công khai và riêng tư ở định dạng PKCS # 8 được mã hóa DER, không có mã hóa dựa trên mật khẩu
  • Các khóa đối xứng dưới dạng các byte thô

Để đảm bảo rằng các khóa đã nhập có thể được phân biệt với các khóa được tạo an toàn, TAG::ORIGIN được đưa vào danh sách ủy quyền khóa thích hợp. Ví dụ: nếu một khóa được tạo trong phần cứng bảo mật, TAG::ORIGIN với giá trị KeyOrigin::GENERATED sẽ được tìm thấy trong danh sách hw_enforced của các đặc điểm chính, trong khi khóa được nhập vào phần cứng an toàn sẽ có giá trị KeyOrigin::IMPORTED .

Xác thực người dùng

Triển khai Secure Keymaster không triển khai xác thực người dùng mà phụ thuộc vào các ứng dụng đáng tin cậy khác. Để biết giao diện mà các ứng dụng này triển khai, hãy xem trang Gatekeeper .

Yêu cầu xác thực người dùng được chỉ định thông qua hai bộ thẻ. Tập hợp đầu tiên cho biết người dùng nào có thể sử dụng khóa:

  • TAG::ALL_USERS cho biết tất cả người dùng đều có thể sử dụng khóa. Nếu có, TAG::USER_ID và TAG::USER_SECURE_ID không có.
  • TAG::USER_ID có một giá trị số chỉ định ID của người dùng được ủy quyền. Lưu ý rằng đây là ID người dùng Android (dành cho nhiều người dùng), không phải UID ứng dụng và nó chỉ được thực thi bởi phần mềm không an toàn. Nếu có, TAG::ALL_USERS không có.
  • TAG::USER_SECURE_ID có giá trị số 64 bit chỉ định ID người dùng an toàn được cung cấp trong mã thông báo xác thực an toàn để mở khóa sử dụng khóa. Nếu được lặp lại, khóa có thể được sử dụng nếu bất kỳ giá trị nào được cung cấp trong mã thông báo xác thực an toàn.

Bộ thứ hai cho biết liệu người dùng có cần được xác thực hay không. Nếu không có thẻ nào trong số các thẻ này, nhưng có TAG::USER_SECURE_ID , thì xác thực là bắt buộc đối với mỗi lần sử dụng khóa.

  • NO_AUTHENTICATION_REQUIRED cho biết không cần xác thực người dùng, mặc dù khóa vẫn chỉ có thể được sử dụng bởi các ứng dụng đang chạy với tư cách là (các) người dùng được chỉ định bởi TAG::USER_ID .
  • TAG::AUTH_TIMEOUT là một giá trị số chỉ định, tính bằng giây, xác thực người dùng cần phải mới như thế nào để cho phép sử dụng khóa. Điều này chỉ áp dụng cho các hoạt động khóa bí mật / riêng tư. Các hoạt động khóa công khai không yêu cầu xác thực. Hết thời gian chờ không vượt qua các lần khởi động lại; sau khi khởi động lại, tất cả các khóa "không bao giờ được xác thực". Thời gian chờ có thể được đặt thành một giá trị lớn để cho biết rằng yêu cầu xác thực một lần cho mỗi lần khởi động (2 ^ 32 giây là ~ 136 năm; có lẽ các thiết bị Android được khởi động lại thường xuyên hơn thế).

Khách hàng ràng buộc

Liên kết ứng dụng khách, liên kết khóa với một ứng dụng khách cụ thể, được thực hiện thông qua ID ứng dụng khách tùy chọn và một số dữ liệu ứng dụng khách tùy chọn ( TAG::APPLICATION_ID và TAG::APPLICATION_DATA , tương ứng). Kho khóa coi các giá trị này như các đốm màu không trong suốt, chỉ đảm bảo rằng các đốm màu giống nhau được trình bày trong quá trình tạo / nhập khóa được hiển thị cho mọi mục đích sử dụng và giống nhau từng byte. Keymaster không trả về dữ liệu ràng buộc máy khách. Người gọi phải biết điều đó để sử dụng chìa khóa.

Tính năng này không được hiển thị với các ứng dụng.

Hết hạn

Kho khóa hỗ trợ hạn chế sử dụng khóa theo ngày. Khóa bắt đầu hiệu lực và hết hạn khóa có thể được liên kết với một khóa và Keymaster từ chối thực hiện các thao tác khóa nếu ngày / giờ hiện tại nằm ngoài phạm vi hợp lệ. Phạm vi hiệu lực của khóa được chỉ định bằng các thẻ TAG::ACTIVE_DATETIME , TAG::ORIGINATION_EXPIRE_DATETIME và TAG::USAGE_EXPIRE_DATETIME . Sự phân biệt giữa "nguồn gốc" và "cách sử dụng" dựa trên việc liệu khóa đang được sử dụng để "tạo ra" một bản mã mới / chữ ký / v.v., hay để "sử dụng" một bản mã / chữ ký / v.v. hiện có. Lưu ý rằng sự khác biệt này không được tiếp xúc với các ứng dụng.

Các thẻ TAG::ACTIVE_DATETIME , TAG::ORIGINATION_EXPIRE_DATETIME và TAG::USAGE_EXPIRE_DATETIME là tùy chọn. Nếu không có các thẻ, có thể giả định rằng khóa được đề cập luôn có thể được sử dụng để giải mã / xác minh thông báo.

Vì thời gian trên đồng hồ treo tường được cung cấp bởi thế giới không an toàn, nên không có khả năng các thẻ liên quan đến ngày hết hạn sẽ nằm trong danh sách được thực thi bởi phần cứng. Việc thực thi phần cứng hết hạn sẽ yêu cầu thế giới an toàn bằng cách nào đó có được thời gian và dữ liệu đáng tin cậy, ví dụ như thông qua giao thức phản hồi thử thách với bộ hẹn giờ từ xa đáng tin cậy.

Gốc của ràng buộc tin cậy

Keystore yêu cầu các khóa phải được liên kết với gốc tin cậy, là một chuỗi bit được cung cấp cho phần cứng bảo mật Keymaster trong quá trình khởi động, tốt nhất là bởi bộ nạp khởi động. Chuỗi bit này được liên kết mật mã với mọi khóa do Keymaster quản lý.

Gốc tin cậy bao gồm khóa công khai được sử dụng để xác minh chữ ký trên hình ảnh khởi động và trạng thái khóa của thiết bị. Nếu khóa công khai được thay đổi để cho phép sử dụng hình ảnh hệ thống khác hoặc nếu trạng thái khóa bị thay đổi, thì không có khóa nào được bảo vệ bởi Keymaster được tạo bởi hệ thống trước đó có thể sử dụng được, trừ khi gốc tin cậy trước đó được khôi phục và hệ thống được ký bởi khóa đó được khởi động. Mục đích là để tăng giá trị của các kiểm soát truy cập khóa do phần mềm thực thi bằng cách làm cho hệ điều hành do kẻ tấn công cài đặt không thể sử dụng khóa Keymaster.

Các phím độc lập

Một số phần cứng bảo mật của Keymaster có thể chọn lưu trữ tài liệu khóa bên trong và trả về tay cầm thay vì tài liệu khóa được mã hóa. Hoặc có thể có những trường hợp khác mà khóa không thể được sử dụng cho đến khi có một số thành phần hệ thống thế giới không an toàn hoặc bảo mật khác. Keymaster HAL cho phép người gọi yêu cầu khóa là "độc lập", thông qua thẻ TAG::STANDALONE , nghĩa là không cần tài nguyên nào khác ngoài blob và hệ thống Keymaster đang chạy. Các thẻ được liên kết với một khóa có thể được kiểm tra để xem liệu một khóa có phải là khóa độc lập hay không. Hiện tại, chỉ có hai giá trị được xác định:

  • KeyBlobUsageRequirements::STANDALONE
  • KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

Tính năng này không được hiển thị với các ứng dụng.

Vận tốc

Khi nó được tạo, tốc độ sử dụng tối đa có thể được chỉ định bằng TAG::MIN_SECONDS_BETWEEN_OPS . Việc triển khai TrustZone từ chối thực hiện các hoạt động mật mã với khóa đó nếu một hoạt động được thực hiện ít hơn TAG::MIN_SECONDS_BETWEEN_OPS giây trước đó.

Cách tiếp cận đơn giản để thực hiện giới hạn vận tốc là một bảng gồm các ID chính và dấu thời gian sử dụng lần cuối. Bảng này có thể sẽ có kích thước hạn chế, nhưng chứa ít nhất 16 mục nhập. Trong trường hợp bảng đã đầy và không có mục nhập nào có thể được cập nhật hoặc hủy bỏ, việc triển khai phần cứng an toàn "không an toàn", ưu tiên từ chối tất cả các thao tác phím giới hạn tốc độ cho đến khi một trong các mục nhập hết hạn. Có thể chấp nhận tất cả các mục nhập hết hạn khi khởi động lại.

Các phím cũng có thể được giới hạn ở n lần sử dụng mỗi lần khởi động với TAG::MAX_USES_PER_BOOT . Điều này cũng yêu cầu một bảng theo dõi, chứa ít nhất bốn chìa khóa và cũng không an toàn. Lưu ý rằng các ứng dụng sẽ không thể tạo khóa giới hạn mỗi lần khởi động. Tính năng này không được hiển thị thông qua Keystore và được dành riêng cho các hoạt động của hệ thống.

Tính năng này không được hiển thị với các ứng dụng.

Hạt giống lại trình tạo số ngẫu nhiên

Bởi vì phần cứng an toàn tạo ra các số ngẫu nhiên cho vật liệu chính và Vectơ khởi tạo (IV), và vì trình tạo số ngẫu nhiên phần cứng có thể không phải lúc nào cũng đáng tin cậy hoàn toàn, Keymaster HAL cung cấp một giao diện cho phép khách hàng cung cấp thêm entropy sẽ được trộn vào ngẫu nhiên số được tạo.

Sử dụng trình tạo số ngẫu nhiên phần cứng làm nguồn gốc chính. Dữ liệu gốc được cung cấp thông qua API bên ngoài không thể là nguồn ngẫu nhiên duy nhất được sử dụng để tạo số. Hơn nữa, hoạt động trộn được sử dụng cần đảm bảo rằng đầu ra ngẫu nhiên là không thể đoán trước được nếu bất kỳ nguồn giống nào là không thể đoán trước.

Tính năng này không hiển thị với các ứng dụng nhưng được sử dụng bởi khuôn khổ, thường xuyên cung cấp entropy bổ sung, được truy xuất từ ​​phiên bản Java SecureRandom, đến phần cứng an toàn.