Chứng thực khoá và mã nhận dạng

Kho khoá mang đến một nơi an toàn hơn để tạo, lưu trữ và sử dụng công nghệ mã hoá các khoá một cách có kiểm soát. Khi có bộ nhớ khoá dựa trên phần cứng và được sử dụng, vật liệu khoá an toàn hơn trước việc trích xuất từ thiết bị và Keymaster thực thi các hạn chế khó phá vỡ.

Tuy nhiên, điều này chỉ đúng nếu các khoá kho khoá được xác định nằm trong bộ nhớ dựa trên phần cứng. Trong Keymaster 1, không có cách nào để các ứng dụng hoặc máy chủ từ xa để xác minh một cách đáng tin cậy xem đây có phải là trường hợp đó hay không. Trình nền kho khoá đã tải HAL keymaster có sẵn và tin vào bất cứ điều gì mà HAL đã nói đối với việc sao lưu khoá bằng phần cứng.

Để khắc phục vấn đề này, Keymaster đã ra mắt tính năng chứng thực khoá trong Android 7.0 (Keymaster 2) và mã nhận dạng trong Android 8.0 (Keymaster 3).

Chứng thực khoá nhằm cung cấp cách thức xác định xem một cặp khoá bất đối xứng có được dựa trên phần cứng hay không, các thuộc tính của khoá là gì và những điều kiện ràng buộc được áp dụng cho việc sử dụng mã đó.

Chứng thực mã nhận dạng cho phép thiết bị cung cấp bằng chứng về mã nhận dạng phần cứng, chẳng hạn như số sê-ri hoặc IMEI.

Chứng thực khoá

Để hỗ trợ quy trình chứng thực khoá, Android 7.0 đã ra mắt một tập hợp các thẻ, kiểu và cho HAL.

Thẻ từ khóa

• Tag::ATTESTATION_CHALLENGE
• Tag::INCLUDE_UNIQUE_ID
• Tag::RESET_SINCE_ID_ROTATION

Loại

Keymaster 2 trở xuống

typedef struct {
    keymaster_blob_t* entries;
    size_t entry_count;
} keymaster_cert_chain_t;

Phương thức AttestKey

Keymaster 3

    attestKey(vec<uint8_t> keyToAttest, vec<KeyParameter> attestParams)
        generates(ErrorCode error, vec<vec<uint8_t>> certChain);

Keymaster 2 trở xuống

keymaster_error_t (*attest_key)(const struct keymaster2_device* dev,
        const keymaster_key_blob_t* key_to_attest,
        const keymaster_key_param_set_t* attest_params,
        keymaster_cert_chain_t* cert_chain);

• dev là cấu trúc thiết bị keymaster.
• keyToAttest là blob khoá được trả về từ generateKey để tạo chứng thực.
• attestParams là danh sách mọi tham số cần thiết cho chứng thực. bao gồm Tag::ATTESTATION_CHALLENGE và có thể là Tag::RESET_SINCE_ID_ROTATION, cũng như Tag::APPLICATION_ID và Tag::APPLICATION_DATA. Chiến lược phát hành đĩa đơn hai cái sau là cần thiết để giải mã blob khóa nếu chúng đã được chỉ định trong quá trình tạo khoá.
• certChain là tham số đầu ra, trả về một mảng chứng chỉ. Mục nhập 0 là chứng chỉ chứng thực, có nghĩa là chứng thực khoá của keyToAttest và chứa tiện ích chứng thực.

Phương thức attestKey được coi là một thao tác khoá công khai trên vì mã này có thể được gọi bất cứ lúc nào mà không cần đáp ứng ràng buộc uỷ quyền. Ví dụ: nếu khoá đã chứng thực cần người dùng để sử dụng, có thể tạo chứng thực mà không cần người dùng xác thực.

Chứng chỉ chứng thực

Chứng chỉ chứng thực là chứng chỉ X.509 tiêu chuẩn, trong đó có một chứng chỉ không bắt buộc tiện ích chứng thực có chứa nội dung mô tả về khoá đã được chứng thực. Chiến lược phát hành đĩa đơn chứng chỉ được ký bằng một khoá chứng thực được chứng nhận. Khoá chứng thực có thể sử dụng một thuật toán khác với khoá đang được chứng thực.

Chứng chỉ chứng thực chứa các trường trong bảng bên dưới và không thể chứa bất kỳ trường bổ sung nào. Một số trường chỉ định một giá trị trường cố định. CTS (Bộ kiểm tra tính tương thích) các bài kiểm thử xác thực rằng nội dung chứng chỉ chính xác như đã xác định.

Chứng chỉ SEQUENCE

TRÌNH TỰ Chứng chỉ TBS

Tiện ích chứng thực

Tiện ích attestation chứa thông tin mô tả đầy đủ về keymaster hoạt động uỷ quyền được liên kết với khoá theo một cấu trúc tương ứng trực tiếp vào danh sách uỷ quyền như được sử dụng trong Android và lớp trừu tượng phần cứng (HAL) cho keymaster. Mỗi thẻ trong danh sách uỷ quyền được biểu thị bằng ASN.1 SEQUENCE mục nhập, một cách rõ ràng được gắn thẻ bằng số thẻ keymaster nhưng có mã mô tả loại (số 4 bit đơn đặt hàng) được che đi.

Ví dụ: trong Keymaster 3, Tag::PURPOSE được xác định trong type.hal dưới dạng ENUM_REP | 1. Đối với tiện ích chứng thực, giá trị ENUM_REP bị xoá, để lại thẻ 1. (Đối với Keymaster 2 trở xuống, KM_TAG_PURPOSE được định nghĩa trong keymaster_defs.h.)

Các giá trị được dịch theo cách đơn giản sang loại ASN.1, theo bảng sau:

Lược đồ

Nội dung của tiện ích chứng thực được mô tả theo giản đồ ASN.1 sau đây.

KeyDescription ::= SEQUENCE {
  attestationVersion         INTEGER, # KM2 value is 1. KM3 value is 2. KM4 value is 3.
  attestationSecurityLevel   SecurityLevel,
  keymasterVersion           INTEGER,
  keymasterSecurityLevel     SecurityLevel,
  attestationChallenge       OCTET_STRING,
  uniqueId                   OCTET_STRING,
  softwareEnforced           AuthorizationList,
  teeEnforced                AuthorizationList,
}

SecurityLevel ::= ENUMERATED {
  Software                   (0),
  TrustedEnvironment         (1),
  StrongBox                  (2),
}

AuthorizationList ::= SEQUENCE {
  purpose                     [1] EXPLICIT SET OF INTEGER OPTIONAL,
  algorithm                   [2] EXPLICIT INTEGER OPTIONAL,
  keySize                     [3] EXPLICIT INTEGER OPTIONAL.
  digest                      [5] EXPLICIT SET OF INTEGER OPTIONAL,
  padding                     [6] EXPLICIT SET OF INTEGER OPTIONAL,
  ecCurve                     [10] EXPLICIT INTEGER OPTIONAL,
  rsaPublicExponent           [200] EXPLICIT INTEGER OPTIONAL,
  rollbackResistance          [303] EXPLICIT NULL OPTIONAL, # KM4
  activeDateTime              [400] EXPLICIT INTEGER OPTIONAL
  originationExpireDateTime   [401] EXPLICIT INTEGER OPTIONAL
  usageExpireDateTime         [402] EXPLICIT INTEGER OPTIONAL
  noAuthRequired              [503] EXPLICIT NULL OPTIONAL,
  userAuthType                [504] EXPLICIT INTEGER OPTIONAL,
  authTimeout                 [505] EXPLICIT INTEGER OPTIONAL,
  allowWhileOnBody            [506] EXPLICIT NULL OPTIONAL,
  trustedUserPresenceRequired [507] EXPLICIT NULL OPTIONAL, # KM4
  trustedConfirmationRequired [508] EXPLICIT NULL OPTIONAL, # KM4
  unlockedDeviceRequired      [509] EXPLICIT NULL OPTIONAL, # KM4
  allApplications             [600] EXPLICIT NULL OPTIONAL,
  creationDateTime            [701] EXPLICIT INTEGER OPTIONAL,
  origin                      [702] EXPLICIT INTEGER OPTIONAL,
  rollbackResistant           [703] EXPLICIT NULL OPTIONAL, # KM2 and KM3 only.
  rootOfTrust                 [704] EXPLICIT RootOfTrust OPTIONAL,
  osVersion                   [705] EXPLICIT INTEGER OPTIONAL,
  osPatchLevel                [706] EXPLICIT INTEGER OPTIONAL,
  attestationApplicationId    [709] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdBrand          [710] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdDevice         [711] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdProduct        [712] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdSerial         [713] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdImei           [714] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdMeid           [715] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdManufacturer   [716] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdModel          [717] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  vendorPatchLevel            [718] EXPLICIT INTEGER OPTIONAL, # KM4
  bootPatchLevel              [719] EXPLICIT INTEGER OPTIONAL, # KM4
}

RootOfTrust ::= SEQUENCE {
  verifiedBootKey            OCTET_STRING,
  deviceLocked               BOOLEAN,
  verifiedBootState          VerifiedBootState,
  verifiedBootHash           OCTET_STRING, # KM4
}

VerifiedBootState ::= ENUMERATED {
  Verified                   (0),
  SelfSigned                 (1),
  Unverified                 (2),
  Failed                     (3),
}

Trường KeyDescription

keymasterVersion và attestationChallenge đã xác định các trường thay vì theo thẻ, do đó, các thẻ trong dạng được mã hoá chỉ xác định loại trường. Các trường còn lại được ngầm gắn thẻ như được chỉ định trong giản đồ.

Trường Uỷ quyền

Các trường AuthorizationList là không bắt buộc và được xác định theo giá trị thẻ keymaster, với các bit loại bị che khuất. Gắn thẻ rõ ràng nên các trường này cũng chứa thẻ cho biết loại ASN.1 của chúng để phân tích cú pháp dễ dàng hơn.

Để biết thông tin chi tiết về các giá trị của từng trường, hãy xem types.hal cho Keymaster 3 và keymaster_defs.h dành cho Keymaster 2 trở xuống. Tên thẻ Keymaster đã được chuyển đổi thành tên trường bằng cách bỏ qua KM_TAG và thay đổi phần dư của kiểu viết lạc đà, vì vậy, Tag::KEY_SIZE đã trở thành keySize.

Trường RootOfTrust

Các trường RootOfTrust được xác định theo vị trí.

Giá trị VerifyBootState

Các giá trị của verifiedBootState có những ý nghĩa sau:

Giá trị Mức độ bảo mật

Các giá trị của securityLevel có những ý nghĩa sau:

Mã nhận dạng duy nhất

Mã nhận dạng duy nhất là giá trị 128 bit xác định thiết bị, nhưng chỉ dành cho trong khoảng thời gian có hạn. Giá trị này được tính bằng:

HMAC_SHA256(T || C || R, HBK)

Trong trường hợp:

• T là "giá trị bộ đếm tạm thời", được tính bằng cách chia giá trị của Tag::CREATION_DATETIME bằng 2592000000, giảm bất kỳ giá trị nào phần còn lại. T thay đổi mỗi 30 ngày (2592000000 = 30 * 24 * 60 * 60 * 1000).
• C là giá trị của Tag::APPLICATION_ID
• R là 1 nếu Tag::RESET_SINCE_ID_ROTATION là hiện diện trong tham số attest_params đến lệnh gọi attest_key hoặc bằng 0 nếu không có thẻ.
• HBK là một khoá bí mật ràng buộc phần cứng duy nhất mà Trusted biết Môi trường thực thi mà không bao giờ được tiết lộ. Mã bí mật chứa ít nhất 128 bit entropy và là duy nhất cho từng thiết bị (xác suất duy nhất có thể chấp nhận được với 128 bit entropy). HBK phải là bắt nguồn từ tài liệu khoá hợp nhất thông qua HMAC hoặc AES_CMAC.

Cắt bớt đầu ra HMAC_SHA256 còn 128 bit.

Khoá chứng thực và chứng chỉ

Hai khoá, một RSA và một ECDSA cùng với chuỗi chứng chỉ tương ứng là được cấp phép an toàn vào thiết bị.

Android 12 ra mắt tính năng Cấp phép khoá từ xa, còn Android 13 đòi hỏi phải có thiết bị hãy triển khai nó. Cấp phép khoá từ xa cung cấp cho các thiết bị hiện trường có chứng chỉ chứng thực ECDSA P256 cho từng ứng dụng. Những chứng chỉ này ngắn hơn so với chứng chỉ do nhà máy cấp.

Nhiều số IMEI

Android 14 hỗ trợ nhiều IMEI trong Bản ghi chứng thực khoá Android. Nhà sản xuất thiết bị gốc có thể triển khai tính năng này bằng cách thêm thẻ KeyMint cho số IMEI thứ hai. Việc các thiết bị có nhiều trạm phát sóng di động ngày càng trở nên phổ biến và OEM hiện có thể hỗ trợ các thiết bị có 2 IMEI.

Nhà sản xuất thiết bị gốc bắt buộc phải có một số IMEI phụ (nếu có trên thiết bị của họ) để được cấp phép cho(các) quá trình triển khai KeyMint để những hoạt động triển khai đó có thể chứng thực số IMEI này giống như cách họ chứng thực số IMEI đầu tiên

Chứng thực giấy tờ tuỳ thân

Android 8.0 có hỗ trợ tuỳ chọn cho việc chứng thực giấy tờ tuỳ thân đối với các thiết bị có Keymaster 3. Chứng thực giấy tờ tuỳ thân cho phép thiết bị cung cấp bằng chứng về phần cứng thông tin nhận dạng, chẳng hạn như số sê-ri hoặc IMEI. Mặc dù đây là tính năng không bắt buộc, tất cả các hoạt động triển khai Keymaster 3 đều phải hỗ trợ vì có thể chứng minh danh tính của thiết bị cho phép các trường hợp sử dụng như true cấu hình điều khiển từ xa tự động để tăng cường bảo mật (vì phía từ xa có thể hãy chắc chắn rằng mã đó đang giao tiếp với đúng thiết bị chứ không phải là thiết bị giả mạo nhận dạng).

Chứng thực giấy tờ tuỳ thân hoạt động bằng cách tạo ra các bản sao mã nhận dạng phần cứng của thiết bị mà chỉ Môi trường thực thi đáng tin cậy (TEE) mới có thể truy cập trước thiết bị rời khỏi nhà máy. Người dùng có thể mở khoá trình tải khởi động của thiết bị và thay đổi phần mềm hệ thống và giá trị nhận dạng do khung Android báo cáo. Chiến lược phát hành đĩa đơn Không thể sửa đổi các bản sao của các giá trị nhận dạng do TEE nắm giữ theo cách này, đảm bảo rằng chứng thực mã thiết bị sẽ chỉ chứng thực giá trị nhận dạng phần cứng ban đầu do đó ngăn chặn nỗ lực giả mạo.

Nền tảng API chính để chứng thực giá trị nhận dạng được xây dựng dựa trên khoá hiện có cơ chế chứng thực được giới thiệu trong Keymaster 2. Khi yêu cầu một chứng chỉ chứng thực cho một khoá do quản trị viên khoá nắm giữ, thì phương thức gọi có thể yêu cầu có đưa giá trị nhận dạng phần cứng của thiết bị vào quy trình chứng thực siêu dữ liệu của chứng chỉ. Nếu khoá được lưu giữ trong TEE, thì chứng chỉ sẽ liên kết lại với nguồn gốc tin cậy đã biết. Người nhận chứng chỉ đó có thể xác minh chứng chỉ và nội dung của chứng chỉ, bao gồm cả phần cứng giá trị nhận dạng do TEE viết. Khi được yêu cầu cung cấp phần cứng giá trị nhận dạng trong chứng chỉ chứng thực, TEE chỉ chứng thực mã nhận dạng được lưu trữ trong bộ nhớ, được điền sẵn tại nhà máy.

Thuộc tính lưu trữ

Bộ nhớ lưu trữ các giá trị nhận dạng của thiết bị cần có các thuộc tính sau:

• Các giá trị thu được từ giá trị nhận dạng ban đầu của thiết bị sẽ được sao chép vào dung lượng lưu trữ trước khi thiết bị xuất xưởng.
• Phương thức destroyAttestationIds() có thể huỷ vĩnh viễn bản sao dữ liệu có nguồn gốc từ mã nhận dạng. Phá huỷ vĩnh viễn có nghĩa là dữ liệu sẽ bị xoá hoàn toàn, do đó, không có thao tác đặt lại về trạng thái ban đầu hay bất kỳ được thực hiện trên thiết bị có thể khôi phục dữ liệu đó. Điều này đặc biệt đối với các thiết bị mà người dùng đã mở khoá trình tải khởi động và thay đổi phần mềm hệ thống và sửa đổi giá trị nhận dạng do Android trả về khung.
• Các cơ sở RMA phải có khả năng tạo bản sao mới của dữ liệu lấy từ giá trị nhận dạng phần cứng. Bằng cách này, một thiết bị vượt qua RMA có thể thực hiện lại quy trình chứng thực mã nhận dạng. Chiến lược phát hành đĩa đơn cơ chế do các cơ sở RMA sử dụng phải được bảo vệ để người dùng không thể tự gọi nó ra, vì việc đó sẽ cho phép họ có được các chứng thực về ID giả mạo.
• Không có mã nào khác ngoài ứng dụng đáng tin cậy của Keymaster trong TEE có thể đọc được giữ lại trong bộ nhớ.
• Bộ nhớ rõ ràng là có sự can thiệp: Nếu nội dung của bộ nhớ đã bị được sửa đổi, TEE sẽ xử lý hàm này giống như thể các bản sao của nội dung đã đã bị huỷ và từ chối tất cả các nỗ lực chứng thực giấy tờ tuỳ thân. Cách này được triển khai bằng cách ký hoặc MAC vào bộ nhớ như được mô tả bên dưới.
• Bộ nhớ này không chứa các giá trị nhận dạng ban đầu. Bởi vì chứng thực giấy tờ tuỳ thân liên quan đến một thử thách, phương thức gọi luôn cung cấp các giá trị nhận dạng chứng thực. TEE chỉ cần xác minh rằng các giá trị này khớp với các giá trị mà chúng ban đầu. Lưu trữ các hàm băm bảo mật của các giá trị ban đầu thay vì các giá trị cho phép xác minh này.

Xây dựng

Để tạo một phương thức triển khai có các thuộc tính nêu trên, hãy lưu trữ Giá trị bắt nguồn từ mã nhận dạng trong cấu trúc S sau đây. Không lưu trữ bản sao khác của các giá trị mã nhận dạng, ngoại trừ các vị trí thông thường trong hệ thống mà chủ sở hữu thiết bị có thể sửa đổi bằng cách can thiệp vào hệ thống:

S = D || HMAC(HBK, D)

trong đó:

• D = HMAC(HBK, ID1) || HMAC(HBK, ID2) || ... || HMAC(HBK, IDn)
• HMAC là cấu trúc HMAC có hàm băm bảo mật thích hợp (nên dùng SHA-256)
• HBK là khoá ràng buộc phần cứng không dùng cho bất kỳ mục đích nào khác
• ID1...IDn là giá trị mã nhận dạng ban đầu; mối liên kết của một giá trị cụ thể đối với một chỉ mục cụ thể phụ thuộc vào việc triển khai, vì các thiết bị khác nhau sẽ có số nhận dạng khác nhau
• || biểu thị phép nối

Vì đầu ra HMAC có kích thước cố định, nên không có tiêu đề hay cấu trúc nào khác phải có để có thể tìm thấy giá trị băm mã nhận dạng cá nhân hoặc HMAC của D. Ngoài ra để kiểm tra các giá trị được cung cấp nhằm thực hiện quy trình chứng thực, các hoạt động triển khai cần xác thực S bằng cách trích xuất D từ S, tính toán HMAC(HBK, D) và so sánh nó với giá trị trong S để xác minh rằng không có mã nhận dạng cá nhân nào bị sửa đổi/bị hỏng. Ngoài ra, Việc triển khai phải sử dụng phép so sánh theo thời gian không đổi cho tất cả các mã nhận dạng riêng lẻ và xác thực S. Thời gian so sánh phải là không đổi bất kể số lượng mã nhận dạng được cung cấp và kết quả trùng khớp chính xác của bất kỳ phần nào trong quá trình kiểm thử.

Mã nhận dạng phần cứng

Chứng thực mã nhận dạng hỗ trợ các giá trị nhận dạng phần cứng sau đây:

1. Tên thương hiệu, do Build.BRAND trả về trong Android
2. Tên thiết bị, do Build.DEVICE trả về trong Android
3. Tên sản phẩm, do Build.PRODUCT trả về trong Android
4. Tên nhà sản xuất, do Build.MANUFACTURER trả về trong Android
5. Tên kiểu máy do Build.MODEL trả về trong Android
6. Số sê-ri
7. Số IMEI của tất cả các đài phát thanh
8. MEID của tất cả các đài

Để hỗ trợ quy trình chứng thực mã nhận dạng thiết bị, một thiết bị sẽ phải chứng thực các giá trị nhận dạng này. Tất cả các thiết bị chạy Android có 6 URL đầu tiên và chúng là cần thiết cho việc này làm việc. Nếu thiết bị có bất kỳ sóng vô tuyến di động tích hợp nào, thiết bị cũng phải hỗ trợ chứng thực đối với IMEI và/hoặc MEID của bộ đàm.

Chứng thực mã nhận dạng được yêu cầu bằng cách tiến hành chứng thực khoá và bao gồm mã nhận dạng thiết bị để xác thực trong yêu cầu. Các giá trị nhận dạng được gắn thẻ là:

• ATTESTATION_ID_BRAND
• ATTESTATION_ID_DEVICE
• ATTESTATION_ID_PRODUCT
• ATTESTATION_ID_MANUFACTURER
• ATTESTATION_ID_MODEL
• ATTESTATION_ID_SERIAL
• ATTESTATION_ID_IMEI
• ATTESTATION_ID_MEID

Giá trị nhận dạng để chứng thực là một chuỗi byte được mã hoá UTF-8. Định dạng này áp dụng cho giá trị nhận dạng bằng số. Mỗi giá trị nhận dạng để chứng thực được biểu thị dưới dạng Chuỗi mã hóa UTF-8.

Nếu thiết bị không hỗ trợ quy trình chứng thực giấy tờ tuỳ thân (hoặc destroyAttestationIds() đã từng được gọi và thiết bị không thể chứng thực mã nhận dạng của khoá đó), mọi yêu cầu chứng thực khoá có chứa một hoặc nhiều các thẻ này không thành công với ErrorCode::CANNOT_ATTEST_IDS.

Nếu thiết bị hỗ trợ chứng thực giấy tờ tuỳ thân và một hoặc nhiều thẻ nêu trên có đã được đưa vào yêu cầu chứng thực khoá, TEE sẽ xác minh giá trị nhận dạng được cung cấp cùng với mỗi thẻ khớp với bản sao của giá trị nhận dạng phần cứng. Nếu một hoặc nhiều giá trị nhận dạng không khớp, thì toàn bộ quá trình chứng thực không thành công ErrorCode::CANNOT_ATTEST_IDS. Cùng một thẻ hợp lệ là được cung cấp nhiều lần. Cách này có thể hữu ích, chẳng hạn như khi chứng thực số IMEI: Một thiết bị có thể có nhiều đài phát với nhiều mã số IMEI. Yêu cầu chứng thực hợp lệ nếu giá trị được cung cấp cùng với mỗi ATTESTATION_ID_IMEI khớp với một trong các đài của thiết bị. Quy tắc tương tự cũng áp dụng cho tất cả các thẻ khác.

Nếu chứng thực thành công, hệ thống sẽ thêm những mã nhận dạng đã được chứng thực vào tiện ích chứng thực (OID 1.3.6.1.4.1.11129.2.1.17) của chứng chỉ chứng thực được cấp, bằng giản đồ ở trên. Các thay đổi từ Keymaster 2 giản đồ chứng thực được in đậm, kèm theo phần nhận xét.

API Java

Phần này chỉ nhằm cung cấp thông tin. Trình triển khai Keymaster cũng không triển khai và sử dụng API Java. Thông tin này được cung cấp để giúp những người triển khai nắm được cách các ứng dụng sử dụng tính năng này. Các thành phần hệ thống có thể sử dụng dữ liệu này khác nhau, đó là lý do tại sao phần này lại quan trọng không được coi là quy tắc.

// Create KeyPairGenerator and set generation parameters for an ECDSA key pair
// using the NIST P-256 curve.  "Key1" is the key alias.
KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore");
keyPairGenerator.initialize(
    new KeyGenParameterSpec.Builder("Key1", KeyProperties.PURPOSE_SIGN)
         .setAlgorithmParameterSpec(new ECGenParameterSpec("secp256r1"))
         .setDigests(KeyProperties.DIGEST_SHA256,
                     KeyProperties.DIGEST_SHA384,
                     KeyProperties.DIGEST_SHA512)
         // Only permit the private key to be used if the user
         // authenticated within the last five minutes.
         .setUserAuthenticationRequired(true)
         .setUserAuthenticationValidityDurationSeconds(5 * 60)
         // Request an attestation with challenge "hello world".
         .setAttestationChallenge("hello world".getBytes("UTF-8"))
         .build());
// Generate the key pair. This will result in calls to both generate_key() and
// attest_key() at the keymaster2 HAL.
KeyPair keyPair = keyPairGenerator.generateKeyPair();
// Get the certificate chain
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
Certificate[] certs = keyStore.getCertificateChain("Key1");
// certs[0] is the attestation certificate. certs[1] signs certs[0], etc.,
// up to certs[certs.length - 1].