ฟีเจอร์

หน้านี้มีข้อมูลเกี่ยวกับฟีเจอร์การเข้ารหัสของ Android Keystore ตามที่การติดตั้งใช้งาน KeyMint (หรือ Keymaster) พื้นฐานระบุไว้

องค์ประกอบพื้นฐานของการเข้ารหัส

Keystore มีการดำเนินการในหมวดหมู่ต่อไปนี้

• การสร้างคีย์ซึ่งส่งผลให้เกิดเนื้อหาคีย์ส่วนตัวหรือคีย์ลับที่ เข้าถึงได้เฉพาะในสภาพแวดล้อมที่ปลอดภัย ไคลเอ็นต์สร้างคีย์ได้ด้วยวิธีต่อไปนี้
  • การสร้างคีย์ใหม่
  • การนำเข้าเนื้อหาคีย์ที่ไม่ได้เข้ารหัส
  • การนำเข้าเนื้อหาคีย์ที่เข้ารหัส
• การรับรองคีย์: การสร้างคีย์แบบอสมมาตรจะสร้างใบรับรองที่เก็บส่วนคีย์สาธารณะของคู่คีย์ นอกจากนี้ ใบรับรองนี้ยังอาจมีข้อมูลเกี่ยวกับข้อมูลเมตาสำหรับคีย์และสถานะของอุปกรณ์ ซึ่งทั้งหมดลงนามโดยคีย์ที่เชื่อมโยงกลับไปยังรูทที่เชื่อถือได้
• การดำเนินการเข้ารหัส
  • การเข้ารหัสและการถอดรหัสแบบสมมาตร (AES, 3DES)
  • การถอดรหัสแบบอสมมาตร (RSA)
  • การลงนามแบบอสมมาตร (ECDSA, RSA)
  • การลงนามและการยืนยันแบบสมมาตร (HMAC)
  • ข้อตกลงเกี่ยวกับคีย์แบบอสมมาตร (ECDH)

องค์ประกอบของโปรโตคอล เช่น วัตถุประสงค์ โหมด และการเพิ่มแพดดิง รวมถึงข้อจำกัดในการควบคุมการเข้าถึง จะได้รับการระบุเมื่อสร้างหรือนำเข้าคีย์ และจะเชื่อมโยงกับคีย์อย่างถาวร เพื่อให้มั่นใจว่าจะไม่สามารถใช้คีย์ในลักษณะอื่นได้

นอกเหนือจากรายการข้างต้นแล้ว การใช้งาน KeyMint (เดิมคือ Keymaster) ยังมีบริการอีกอย่างหนึ่งที่ไม่ได้แสดงเป็น API นั่นคือการสร้างตัวเลขสุ่ม ใช้ภายในเพื่อสร้างคีย์ เวกเตอร์การเริ่มต้น (IV) การเพิ่มแบบสุ่ม และองค์ประกอบอื่นๆ ของโปรโตคอลที่ปลอดภัยซึ่งต้องใช้การสุ่ม

Primitive ที่จำเป็น

การติดตั้งใช้งาน KeyMint ทั้งหมดมีฟีเจอร์ต่อไปนี้

• RSA
  • รองรับคีย์ 2048, 3072 และ 4096 บิต
  • รองรับเลขชี้กำลังสาธารณะ F4 (2^16+1)
  • โหมดการเพิ่มระยะขอบสำหรับการลงนาม RSA
    • RSASSA-PSS (PaddingMode::RSA_PSS)
    • RSASSA-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_SIGN)
  • โหมดสรุปสำหรับการลงนาม RSA
    • SHA-256
  • โหมดการเพิ่มแพดดิ้งสำหรับการเข้ารหัส/ถอดรหัส RSA
    • แบบไม่บุ
    • RSAES-OAEP (PaddingMode::RSA_OAEP)
    • RSAES-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_ENCRYPT)
• ECDSA
  • ระบบรองรับคีย์ 224, 256, 384 และ 521 บิต โดยใช้เส้นโค้ง NIST P-224, P-256, P-384 และ P-521 ตามลำดับ
  • โหมดสรุปสำหรับ ECDSA
    • ไม่มีสรุป (เลิกใช้งานแล้วและจะนำออกในอนาคต)
    • SHA-256
• AES
  • รองรับคีย์ 128 และ 256 บิต
  • CBC, CTR, ECB และ GCM การติดตั้งใช้งาน GCM ไม่อนุญาตให้ใช้แท็กที่มีขนาดเล็กกว่า 96 บิตหรือความยาวของ Nonce ที่ไม่ใช่ 96 บิต
  • รองรับโหมดการเพิ่มพื้นที่ว่าง PaddingMode::NONE และ PaddingMode::PKCS7 สำหรับโหมด CBC และ ECB หากไม่มีการเพิ่มแพดดิ้ง การเข้ารหัสโหมด CBC หรือ ECB จะล้มเหลวหากอินพุตไม่ใช่จำนวนเท่าของขนาดบล็อก
• HMAC SHA-256 ที่มีขนาดคีย์ใดก็ได้ สูงสุดอย่างน้อย 32 ไบต์

ขอแนะนำเป็นอย่างยิ่งให้ใช้ SHA1 และสมาชิกอื่นๆ ในตระกูล SHA2 (SHA-224, SHA384 และ SHA512) สำหรับการติดตั้งใช้งาน KeyMint Keystore จะให้ข้อมูลดังกล่าว ในซอฟต์แวร์หากการติดตั้งใช้งาน KeyMint ของฮาร์ดแวร์ไม่ได้ให้ข้อมูลดังกล่าว

นอกจากนี้ เรายังแนะนำให้ใช้ Primitive บางรายการเพื่อการทำงานร่วมกันกับระบบอื่นๆ ด้วย

• ขนาดคีย์ RSA ที่เล็กลง
• เลขชี้กำลังสาธารณะแบบกำหนดเองสำหรับ RSA

การควบคุมการเข้าถึงคีย์

คีย์ที่อิงตามฮาร์ดแวร์ซึ่งไม่สามารถดึงออกจากอุปกรณ์ได้จะไม่ให้ความปลอดภัยมากนักหากผู้โจมตีใช้คีย์เหล่านั้นได้ตามต้องการ (แม้ว่าจะปลอดภัยกว่าคีย์ที่ดึงข้อมูลออกได้) ดังนั้น Keystore จึงต้องบังคับใช้การควบคุมการเข้าถึง

การควบคุมการเข้าถึงจะกำหนดเป็น "รายการการให้สิทธิ์" ของคู่แท็ก/ค่า แท็กการให้สิทธิ์เป็นจำนวนเต็ม 32 บิต และค่าเป็นประเภทต่างๆ คุณสามารถใช้แท็กบางรายการซ้ำเพื่อระบุค่าหลายค่าได้ ระบุว่าแท็กทำซ้ำได้หรือไม่ในอินเทอร์เฟซ HAL ของ KeyMint เมื่อสร้างคีย์ ผู้เรียกจะระบุรายการการให้สิทธิ์ การติดตั้งใช้งาน KeyMint ที่อยู่ภายใต้ Keystore จะแก้ไขรายการเพื่อระบุข้อมูลเพิ่มเติมบางอย่าง เช่น คีย์มีการป้องกันการย้อนกลับหรือไม่ และส่งคืนรายการการให้สิทธิ์ "สุดท้าย" ที่เข้ารหัสเป็น Blob ของคีย์ที่ส่งคืน ความพยายามใดๆ ในการใช้ คีย์สำหรับการดำเนินการเข้ารหัสลับจะล้มเหลวหากมีการแก้ไขรายการการให้สิทธิ์สุดท้าย

สำหรับ Keymaster 2 และเวอร์ชันก่อนหน้า ชุดแท็กที่เป็นไปได้ จะกำหนดไว้ในการแจงนับ keymaster_authorization_tag_t และ จะได้รับการแก้ไขอย่างถาวร (แม้ว่าจะขยายได้ก็ตาม) ชื่อมีคำนำหน้าเป็น KM_TAG ระบบจะใช้ 4 บิตแรกของรหัสแท็กเพื่อระบุประเภท

Keymaster 3 เปลี่ยนคำนำหน้า KM_TAG เป็น Tag::

ประเภทที่เป็นไปได้ ได้แก่

ENUM: ค่าของแท็กจำนวนมากกำหนดไว้ใน การแจงนับ เช่น ค่าที่เป็นไปได้ของ TAG::PURPOSE จะกำหนดไว้ใน enum keymaster_purpose_t

ENUM_REP: เหมือนกับ ENUM ยกเว้นว่าแท็กสามารถทำซ้ำในรายการการให้สิทธิ์ได้ การทำซ้ำ ระบุค่าที่ได้รับอนุญาตหลายค่า ตัวอย่างเช่น คีย์การเข้ารหัส น่าจะมี KeyPurpose::ENCRYPT และ KeyPurpose::DECRYPT

เมื่อ KeyMint สร้างคีย์ ผู้เรียกจะระบุรายการการให้สิทธิ์สำหรับคีย์ Keystore และ KeyMint จะแก้ไขรายการนี้เพื่อเพิ่มข้อจำกัดเพิ่มเติม และ การติดตั้งใช้งาน KeyMint ที่อยู่เบื้องหลังจะเข้ารหัสรายการการให้สิทธิ์สุดท้าย ลงใน KeyBlob ที่ส่งคืน รายการการให้สิทธิ์ที่เข้ารหัสจะเชื่อมโยงกับคีย์บล็อบด้วยการเข้ารหัส เพื่อให้ความพยายามใดๆ ในการแก้ไขรายการการให้สิทธิ์ (รวมถึงการจัดลำดับ) ส่งผลให้คีย์บล็อบไม่ถูกต้องและใช้สำหรับ การดำเนินการเข้ารหัสไม่ได้

การบังคับใช้ด้วยฮาร์ดแวร์เทียบกับการบังคับใช้ด้วยซอฟต์แวร์

การติดตั้งใช้งานฮาร์ดแวร์ที่ปลอดภัยบางอย่างอาจมีฟีเจอร์ไม่เหมือนกัน Keymaster จะแยกความแตกต่างระหว่างการบังคับใช้การควบคุมการเข้าถึงที่ปลอดภัยและไม่ปลอดภัย หรือการบังคับใช้ฮาร์ดแวร์และซอฟต์แวร์ตามลำดับ เพื่อรองรับแนวทางที่หลากหลาย

ซึ่งจะแสดงใน KeyMint API ด้วยฟิลด์ securityLevel ของ ประเภท KeyCharacteristics ฮาร์ดแวร์ที่ปลอดภัยมีหน้าที่ในการวางการให้สิทธิ์ใน KeyCharacteristics โดยมีระดับการรักษาความปลอดภัยที่เหมาะสมตามสิ่งที่ ฮาร์ดแวร์บังคับใช้ได้ นอกจากนี้ ข้อมูลนี้ยังแสดงใน บันทึกการรับรองสำหรับคีย์แบบอสมมาตรด้วย โดยลักษณะสำคัญของคีย์ สำหรับ SecurityLevel::TRUSTED_ENVIRONMENT หรือ SecurityLevel::STRONGBOX จะปรากฏใน รายการ hardwareEnforced และลักษณะสำคัญ สำหรับ SecurityLevel::SOFTWARE หรือ SecurityLevel::KEYSTORE จะปรากฏใน รายการ softwareEnforced

ตัวอย่างเช่น โดยปกติแล้วสภาพแวดล้อมที่ปลอดภัยจะไม่บังคับใช้ข้อจํากัดเกี่ยวกับช่วงวันที่และเวลาเมื่อใช้คีย์ เนื่องจากไม่มีสิทธิ์เข้าถึงข้อมูลวันที่และเวลาที่เชื่อถือได้ ดังนั้น Keystore ใน Android จะบังคับใช้การให้สิทธิ์ เช่น Tag::ORIGINATION_EXPIRE_DATETIME และจะมี SecurityLevel::KEYSTORE

ดูข้อมูลเพิ่มเติมเกี่ยวกับการพิจารณาว่าคีย์และการให้สิทธิ์ ได้รับการสนับสนุนจากฮาร์ดแวร์หรือไม่ ได้ที่การรับรองคีย์

การให้สิทธิ์ในการสร้างข้อความที่เข้ารหัส

แท็กต่อไปนี้ใช้เพื่อกำหนดลักษณะการเข้ารหัสของ การดำเนินการโดยใช้คีย์ที่เชื่อมโยง

• Tag::ALGORITHM
• Tag::KEY_SIZE
• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::CALLER_NONCE
• Tag::DIGEST
• Tag::MGF_DIGEST

แท็กต่อไปนี้สามารถทำซ้ำได้ ซึ่งหมายความว่าค่าหลายค่าสามารถเชื่อมโยงกับคีย์เดียวได้

• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::DIGEST
• Tag::MGF_DIGEST

ระบบจะระบุค่าที่จะใช้ในเวลาที่ดำเนินการ

วัตถุประสงค์

คีย์มีชุดวัตถุประสงค์ที่เชื่อมโยงกัน ซึ่งแสดงเป็นรายการการให้สิทธิ์อย่างน้อย 1 รายการที่มีแท็ก Tag::PURPOSE ซึ่งกำหนดวิธีใช้คีย์ วัตถุประสงค์กำหนดไว้ใน KeyPurpose.aidl

โปรดทราบว่าค่าวัตถุประสงค์บางชุดอาจทำให้เกิดปัญหาด้านความปลอดภัย ตัวอย่างเช่น คีย์ RSA ที่ใช้ได้ทั้งเข้ารหัสและลงนามจะอนุญาตให้ผู้โจมตีที่สามารถโน้มน้าวให้ระบบถอดรหัสข้อมูลที่กำหนดเองสร้างลายเซ็นได้

การนำเข้าคีย์

Keymaster รองรับการส่งออกคีย์สาธารณะในรูปแบบ X.509 เท่านั้น และรองรับการนำเข้า รายการต่อไปนี้

• คู่คีย์แบบอสมมาตรในรูปแบบ PKCS#8 ที่เข้ารหัส DER (ไม่มีการเข้ารหัสตามรหัสผ่าน)
• คีย์แบบสมมาตรเป็นไบต์ดิบ

Tag::ORIGIN จะรวมอยู่ในรายการการให้สิทธิ์คีย์ที่เหมาะสม เพื่อให้มั่นใจว่าคีย์ที่นำเข้าจะแยกความแตกต่างจากคีย์ที่สร้างขึ้นอย่างปลอดภัยได้ ตัวอย่างเช่น หากสร้างคีย์ ในฮาร์ดแวร์ที่ปลอดภัย Tag::ORIGIN จะมีค่า KeyOrigin::GENERATED อยู่ใน hw_enforced รายการลักษณะของคีย์ ในขณะที่คีย์ ที่นำเข้าไปยังฮาร์ดแวร์ ที่ปลอดภัยจะมีค่า KeyOrigin::IMPORTED

การตรวจสอบสิทธิ์ของผู้ใช้

การติดตั้งใช้งาน KeyMint ที่ปลอดภัยจะไม่ติดตั้งใช้งานการตรวจสอบสิทธิ์ผู้ใช้ แต่จะ ขึ้นอยู่กับแอปอื่นๆ ที่เชื่อถือได้ซึ่งติดตั้งใช้งานการตรวจสอบสิทธิ์ผู้ใช้ สำหรับอินเทอร์เฟซที่แอปเหล่านี้ ติดตั้งใช้งาน โปรดดูหน้า Gatekeeper

ข้อกำหนดในการตรวจสอบสิทธิ์ผู้ใช้จะระบุผ่านแท็ก 2 ชุด ชุดแรกระบุวิธีการตรวจสอบสิทธิ์ที่อนุญาตให้ใช้คีย์

• Tag::USER_SECURE_ID มีค่าตัวเลข 64 บิตที่ระบุ รหัสผู้ใช้ที่ปลอดภัย ซึ่งระบุไว้ในโทเค็นการตรวจสอบสิทธิ์ที่ปลอดภัยเพื่อ ปลดล็อกการใช้คีย์ หากทำซ้ำ คุณจะใช้คีย์ได้หากมีการระบุค่าใดค่าหนึ่ง ในโทเค็นการตรวจสอบสิทธิ์ที่ปลอดภัย

ชุดที่ 2 ระบุว่าผู้ใช้ต้องได้รับการตรวจสอบสิทธิ์หรือไม่และเมื่อใด หากไม่มีแท็กทั้ง 2 รายการนี้ แต่มี Tag::USER_SECURE_ID คุณจะต้องตรวจสอบสิทธิ์ทุกครั้งที่ใช้คีย์

• Tag::NO_AUTHENTICATION_REQUIRED แสดงว่าไม่จำเป็นต้องมีการตรวจสอบสิทธิ์ผู้ใช้ แม้ว่าการเข้าถึงคีย์จะยังคงจำกัดไว้สำหรับ แอปที่เป็นเจ้าของ (และแอปใดก็ตามที่แอปดังกล่าวให้สิทธิ์เข้าถึง)
• Tag::AUTH_TIMEOUT คือค่าตัวเลขที่ระบุเป็นวินาที ว่าการตรวจสอบสิทธิ์ผู้ใช้ต้องใหม่เพียงใดจึงจะอนุญาตให้ใช้คีย์ได้ การหมดเวลาจะไม่ข้ามการรีบูต หลังจากรีบูตแล้ว การตรวจสอบสิทธิ์ทั้งหมดจะ ใช้ไม่ได้ คุณตั้งค่าการหมดเวลาเป็นค่าขนาดใหญ่เพื่อระบุว่า ต้องมีการตรวจสอบสิทธิ์ 1 ครั้งต่อการบูต (2^32 วินาทีคือประมาณ 136 ปี ซึ่งคาดว่าอุปกรณ์ Android จะรีบูตบ่อยกว่านั้น)

ต้องใช้อุปกรณ์ที่ปลดล็อกแล้ว

คีย์ที่มี Tag::UNLOCKED_DEVICE_REQUIRED จะใช้ได้เฉพาะในขณะที่ อุปกรณ์ปลดล็อกอยู่ ดูความหมายโดยละเอียดได้ที่ KeyProtection.Builder#setUnlockedDeviceRequired(boolean)

Keystore เป็นผู้บังคับใช้ UNLOCKED_DEVICE_REQUIRED ไม่ใช่ KeyMint อย่างไรก็ตาม ใน Android 12 ขึ้นไป Keystore จะเข้ารหัส UNLOCKED_DEVICE_REQUIRED เพื่อป้องกันขณะที่อุปกรณ์ล็อกอยู่ เพื่อให้มั่นใจว่าในกรณีส่วนใหญ่ จะไม่สามารถใช้คีย์ได้แม้ว่า Keystore จะถูก บุกรุกขณะที่อุปกรณ์ล็อกอยู่ก็ตาม

การเข้ารหัสและหมายเลขสุ่มทั้งหมดที่อธิบายไว้ในส่วนนี้ใช้ BoringSSL ยกเว้นในกรณีที่ระบุการใช้ KeyMint อย่างชัดเจน ระบบจะล้างข้อมูลลับทั้งหมด ทันทีที่ไม่มีความจำเป็นอีกต่อไป

คีย์ขั้นสูง UnlockedDeviceRequired

Keystore จะ "เข้ารหัสขั้นสูง" คีย์ UNLOCKED_DEVICE_REQUIRED ก่อนจัดเก็บไว้ในฐานข้อมูลเพื่อปกป้องคีย์ด้วยการเข้ารหัส เมื่อเป็นไปได้ ระบบจะปกป้องคีย์การเข้ารหัสขั้นสูง (คีย์ขั้นสูง) ขณะที่อุปกรณ์ล็อกอยู่ในลักษณะที่กู้คืนได้เฉพาะเมื่อปลดล็อกอุปกรณ์สำเร็จแล้วเท่านั้น (คำว่า "การเข้ารหัสขั้นสูง" ใช้เนื่องจากเลเยอร์การเข้ารหัสนี้จะใช้นอกเหนือจากเลเยอร์การเข้ารหัสที่ KeyMint ใช้กับคีย์ทั้งหมดอยู่แล้ว)

ผู้ใช้แต่ละราย (รวมถึงโปรไฟล์) มีคีย์ขั้นสูง 2 รายการที่เชื่อมโยงกับ UNLOCKED_DEVICE_REQUIRED ดังนี้

• คีย์ขั้นสูงแบบสมมาตร UnlockedDeviceRequired นี่คือคีย์ AES‑256‑GCM โดยจะเข้ารหัส คีย์ UNLOCKED_DEVICE_REQUIRED ที่นำเข้า สร้างขึ้น หรือใช้ขณะที่อุปกรณ์ปลดล็อกสำหรับผู้ใช้
• คีย์ขั้นสูงแบบอสมมาตรที่ต้องใช้กับอุปกรณ์ที่ปลดล็อก นี่คือคู่คีย์ ECDH P‑521 โดยจะเข้ารหัสUNLOCKED_DEVICE_REQUIRED คีย์ที่นำเข้าหรือสร้างขึ้นขณะที่อุปกรณ์ล็อกอยู่สำหรับ ผู้ใช้ ดูรายละเอียดเพิ่มเติมได้ที่การจัดเก็บ คีย์ขณะที่อุปกรณ์ล็อกอยู่

การสร้างและปกป้องคีย์หลัก

เมื่อสร้างผู้ใช้ Keystore จะสร้างคีย์ขั้นสูง UnlockedDeviceRequired ของผู้ใช้และจัดเก็บไว้ในฐานข้อมูลโดยเข้ารหัส (ทางอ้อม) ด้วยรหัสผ่าน สังเคราะห์ของผู้ใช้

1. เซิร์ฟเวอร์ของระบบจะสร้างรหัสผ่านของที่เก็บคีย์ของผู้ใช้จากรหัสผ่านสังเคราะห์ของผู้ใช้โดยใช้ KDF ของ SP800‑108
2. เซิร์ฟเวอร์ระบบจะส่งรหัสผ่านคีย์สโตร์ของผู้ใช้ไปยังคีย์สโตร์
3. Keystore จะสร้างคีย์หลักของผู้ใช้
4. สำหรับคีย์ขั้นสูงของผู้ใช้แต่ละราย ให้ทำดังนี้
   1. คีย์สโตร์จะสร้าง Salt แบบสุ่ม
   2. คีย์สโตร์จะสร้างคีย์ AES‑256‑GCM จาก รหัสผ่านคีย์สโตร์และ Salt ของผู้ใช้โดยใช้ HKDF‑SHA256
   3. Keystore จะเข้ารหัสส่วนลับของคีย์หลักโดยใช้คีย์ AES‑256‑GCM นี้
   4. Keystore จะจัดเก็บคีย์หลักที่เข้ารหัสและ Salt ของคีย์นั้นไว้ในฐานข้อมูล หากเป็นคีย์แบบอสมมาตร ระบบจะจัดเก็บคีย์ครึ่งหนึ่งที่เป็นคีย์สาธารณะโดยไม่เข้ารหัสด้วย

กระบวนการนี้ช่วยให้ถอดรหัสคีย์ขั้นสูงเหล่านี้ได้เมื่อทราบรหัสผ่านสังเคราะห์ของผู้ใช้ เช่น เมื่อผู้ใช้ป้อน PIN, รูปแบบ หรือรหัสผ่านที่ถูกต้อง

นอกจากนี้ Keystore ยังแคชคีย์หลักเหล่านี้ไว้ในหน่วยความจำด้วย ทำให้สามารถดำเนินการกับคีย์ UNLOCKED_DEVICE_REQUIRED ได้ อย่างไรก็ตาม ระบบจะพยายามแคช ส่วนที่เป็นความลับของคีย์เหล่านี้เฉพาะในขณะที่อุปกรณ์ปลดล็อกสำหรับผู้ใช้เท่านั้น เมื่อ อุปกรณ์ถูกล็อกสำหรับผู้ใช้ Keystore จะล้างข้อมูลสำเนาที่แคชไว้ของ ส่วนลับของคีย์หลักเหล่านี้ หากทำได้ กล่าวคือ เมื่ออุปกรณ์ถูกล็อกสำหรับผู้ใช้ Keystore จะเลือกและใช้ระดับการป้องกัน 1 ใน 3 ระดับ สำหรับคีย์ขั้นสูง UnlockedDeviceRequired ของผู้ใช้

• หากผู้ใช้เปิดใช้เฉพาะ PIN, รูปแบบ หรือรหัสผ่าน Keystore จะล้างส่วนที่เป็นความลับของคีย์หลักที่แคชไว้ ซึ่งจะทำให้กู้คืนคีย์หลักได้ผ่านสำเนาที่เข้ารหัสในฐานข้อมูลเท่านั้น โดยจะถอดรหัสได้ด้วย PIN, รูปแบบ หรือรหัสผ่านที่เทียบเท่าเท่านั้น
• หากผู้ใช้มีเพียงไบโอเมตริกระดับ 3 ("แข็งแกร่ง") และเปิดใช้ PIN, รูปแบบ หรือรหัสผ่าน Keystore จะจัดเตรียมให้สามารถกู้คืนคีย์หลักได้โดยใช้ไบโอเมตริกระดับ 3 ที่ผู้ใช้ลงทะเบียนไว้ (โดยทั่วไปคือลายนิ้วมือ) เพื่อเป็นทางเลือกแทน PIN, รูปแบบ หรือรหัสผ่าน โดยจะ สร้างคีย์ AES‑256‑GCM ใหม่ เข้ารหัสส่วนที่เป็นความลับของ คีย์หลักด้วยคีย์ดังกล่าว นำเข้าคีย์ AES‑256‑GCM ไปยัง KeyMint เป็นคีย์ที่เชื่อมโยงกับข้อมูลไบโอเมตริกซึ่งกำหนดให้ต้องมีการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริก ให้สำเร็จภายใน 15 วินาทีที่ผ่านมา และล้างสำเนาข้อความธรรมดา ของคีย์ทั้งหมดนี้
• หากผู้ใช้มีไบโอเมตริกคลาส 1 ("สะดวก") ไบโอเมตริกคลาส 2 ("อ่อน") หรือเปิดใช้ตัวแทนความน่าเชื่อถือในการปลดล็อกที่ใช้งานอยู่ Keystore จะเก็บคีย์หลัก ที่แคชไว้เป็นข้อความธรรมดา ในกรณีนี้ ระบบจะไม่ให้การรักษาความปลอดภัยด้วยการเข้ารหัสสำหรับ UNLOCKED_DEVICE_REQUIREDคีย์ ผู้ใช้สามารถ หลีกเลี่ยงการเปลี่ยนไปใช้การสำรองที่มีความปลอดภัยน้อยนี้ได้โดยไม่เปิดใช้การปลดล็อกด้วยวิธีเหล่านี้ วิธีการปลดล็อกที่พบบ่อยที่สุดซึ่งอยู่ในหมวดหมู่เหล่านี้คือการปลดล็อกด้วยใบหน้า ในอุปกรณ์หลายรุ่น และการปลดล็อกด้วยสมาร์ทวอทช์ที่จับคู่ไว้

เมื่อปลดล็อกอุปกรณ์ให้ผู้ใช้แล้ว Keystore จะกู้คืนคีย์หลัก UnlockedDeviceRequired ของผู้ใช้หากเป็นไปได้ สำหรับ PIN, รูปแบบ หรือรหัสผ่าน ที่เทียบเท่ากับการปลดล็อก ระบบจะถอดรหัสสำเนาของคีย์เหล่านี้ที่จัดเก็บไว้ใน ฐานข้อมูล ไม่เช่นนั้น ระบบจะตรวจสอบว่าได้บันทึกสำเนาของคีย์เหล่านี้ที่เข้ารหัสด้วย คีย์ที่เชื่อมโยงกับไบโอเมตริกไว้หรือไม่ หากบันทึกไว้ ระบบจะพยายามถอดรหัส การดำเนินการนี้จะสำเร็จก็ต่อเมื่อผู้ใช้ตรวจสอบสิทธิ์ด้วยไบโอเมตริกระดับ 3 สำเร็จภายใน 15 วินาทีที่ผ่านมา ซึ่งบังคับใช้โดย KeyMint (ไม่ใช่ Keystore)

การจัดเก็บบัตรขณะที่อุปกรณ์ล็อกอยู่

Keystore อนุญาตให้ผู้ใช้นำเข้าและสร้าง UNLOCKED_DEVICE_REQUIREDคีย์ขณะที่อุปกรณ์ล็อกอยู่ โดยใช้ รูปแบบการเข้ารหัสแบบผสมเพื่อให้มั่นใจว่าข้อมูลจะถอดรหัสได้ก็ต่อเมื่อ ปลดล็อกอุปกรณ์ในภายหลังเท่านั้น

• การเข้ารหัส (การนำเข้าหรือสร้าง UNLOCKED_DEVICE_REQUIRED คีย์ขณะที่อุปกรณ์ล็อกอยู่):
  1. Keystore จะสร้างคู่คีย์ ECDH P-521 แบบชั่วคราวใหม่
  2. Keystore จะสร้างข้อมูลลับที่ใช้ร่วมกันโดยทำข้อตกลงคีย์ ECDH ระหว่าง คีย์ส่วนตัวของคู่คีย์ชั่วคราวนี้กับครึ่งหนึ่งของคีย์สาธารณะของ คีย์หลักแบบอสมมาตรที่ต้องใช้การปลดล็อกอุปกรณ์
  3. คีย์สโตร์จะสร้าง Salt แบบสุ่ม
  4. คีย์สโตร์จะสร้างคีย์ AES‑256‑GCM จากข้อมูลลับที่ใช้ร่วมกัน และ Salt โดยใช้ HKDF‑SHA256
  5. Keystore จะเข้ารหัสUNLOCKED_DEVICE_REQUIREDโดยใช้คีย์ AES‑256‑GCM นี้
  6. Keystore จะจัดเก็บคีย์ UNLOCKED_DEVICE_REQUIRED ที่เข้ารหัส Salt และครึ่งหนึ่งที่เป็นสาธารณะของคู่คีย์ชั่วคราวไว้ในฐานข้อมูล ของตน
• การถอดรหัส (ใช้UNLOCKED_DEVICE_REQUIREDคีย์ ที่สร้างขึ้นขณะที่อุปกรณ์ปลดล็อกอยู่):
  1. Keystore จะโหลดUNLOCKED_DEVICE_REQUIRED คีย์ที่เข้ารหัส, Salt และครึ่งหนึ่งของคีย์สาธารณะของคู่คีย์ชั่วคราวจาก ฐานข้อมูลของตัวเอง
  2. Keystore จะสร้างข้อมูลลับที่ใช้ร่วมกันโดยทำข้อตกลงคีย์ ECDH ระหว่าง ครึ่งหนึ่งของคู่คีย์ชั่วคราวที่เป็นแบบสาธารณะกับครึ่งหนึ่งของ คีย์หลักแบบอสมมาตรที่ต้องปลดล็อกอุปกรณ์ที่เป็นแบบส่วนตัว คีย์ส่วนตัวพร้อมใช้งานเนื่องจากอุปกรณ์ปลดล็อกอยู่
  3. คีย์สโตร์จะสร้างคีย์ AES‑256‑GCM จากข้อมูลลับที่ใช้ร่วมกัน และ Salt โดยใช้ HKDF‑SHA256 คีย์ AES‑256‑GCM นี้ เหมือนกับคีย์ที่ได้มาในระหว่างการเข้ารหัส
  4. Keystore จะถอดรหัสUNLOCKED_DEVICE_REQUIREDโดยใช้ คีย์ AES‑256‑GCM
  5. Keystore จะเข้ารหัสUNLOCKED_DEVICE_REQUIREDคีย์อีกครั้ง โดยใช้คีย์หลักแบบสมมาตร UnlockedDeviceRequired การดำเนินการนี้ จะไม่ส่งผลต่อคุณสมบัติด้านความปลอดภัยของคีย์ แต่จะช่วยให้เข้าถึงคีย์ได้ รวดเร็วยิ่งขึ้นในภายหลัง

ฟีเจอร์นี้ช่วยให้แอปจัดเก็บข้อมูลได้ขณะที่อุปกรณ์ล็อกอยู่ เพื่อให้ถอดรหัสได้เฉพาะขณะที่อุปกรณ์ปลดล็อกอยู่เท่านั้น โดยแอปควรทำตามขั้นตอนต่อไปนี้

1. สร้างคีย์ AES‑256‑GCM นอกคีย์สโตร์
2. เข้ารหัสข้อมูลโดยใช้คีย์ AES‑256‑GCM
3. นำเข้าคีย์ AES‑256‑GCM ไปยังคีย์สโตร์ด้วยชุดการปกป้องคีย์ setUnlockedDeviceRequired(true)
4. ล้างข้อมูลสำเนาคีย์ต้นฉบับ

หากต้องการถอดรหัสข้อมูลขณะที่อุปกรณ์ปลดล็อกอยู่ ให้ใช้คีย์ที่ นำเข้าไปยังที่เก็บคีย์

การเชื่อมโยงไคลเอ็นต์

การเชื่อมโยงไคลเอ็นต์ ซึ่งเป็นการเชื่อมโยงคีย์กับแอปไคลเอ็นต์ ที่เฉพาะเจาะจง จะดำเนินการผ่านรหัสไคลเอ็นต์ที่ไม่บังคับและข้อมูลไคลเอ็นต์ที่ไม่บังคับบางอย่าง (Tag::APPLICATION_ID และ Tag::APPLICATION_DATA ตามลำดับ) Keystore จะถือว่าค่าเหล่านี้เป็น Blob ที่ทึบแสง โดยจะตรวจสอบว่า Blob เดียวกันที่แสดงในระหว่างการสร้าง/นำเข้าคีย์จะแสดงสำหรับการใช้งานทุกครั้งและเหมือนกันทุกไบต์ KeyMint จะไม่แสดงผลข้อมูลการเชื่อมโยงไคลเอ็นต์ ผู้โทรต้องทราบรหัสผ่านดังกล่าวจึงจะใช้คีย์ได้

ฟีเจอร์นี้ไม่พร้อมใช้งานในแอป

วันหมดอายุ

Keystore รองรับการจำกัดการใช้คีย์ตามวันที่ วันที่เริ่มต้นความถูกต้องของคีย์และ วันหมดอายุของคีย์จะเชื่อมโยงกับคีย์ได้ และ Keymaster จะปฏิเสธ ที่จะดำเนินการกับคีย์หากวันที่/เวลาปัจจุบันอยู่นอกช่วงที่ถูกต้อง ช่วงความถูกต้องของคีย์จะระบุด้วยแท็ก Tag::ACTIVE_DATETIME Tag::ORIGINATION_EXPIRE_DATETIME และ Tag::USAGE_EXPIRE_DATETIME ความแตกต่างระหว่าง "การสร้าง" กับ "การใช้งาน" ขึ้นอยู่กับว่ามีการใช้คีย์เพื่อ "สร้าง" ข้อความ/ลายเซ็น/ฯลฯ ที่เข้ารหัสใหม่ หรือเพื่อ "ใช้" ข้อความ/ลายเซ็น/ฯลฯ ที่เข้ารหัสที่มีอยู่ โปรดทราบว่าความแตกต่างนี้ไม่ได้แสดงต่อแอป

แท็ก Tag::ACTIVE_DATETIME Tag::ORIGINATION_EXPIRE_DATETIME และ Tag::USAGE_EXPIRE_DATETIME เป็นแท็กที่ไม่บังคับ หากไม่มีแท็ก ระบบจะถือว่าคีย์ที่เป็นปัญหา ใช้ถอดรหัส/ยืนยันข้อความได้เสมอ

เนื่องจากเวลาจริงจะมาจากโลกที่ไม่ปลอดภัย แท็กที่เกี่ยวข้องกับการหมดอายุจึงอยู่ในรายการที่บังคับใช้โดยซอฟต์แวร์

การเชื่อมโยงรูทของความน่าเชื่อถือ

Keystore กำหนดให้ต้องเชื่อมโยงคีย์กับรูทของความน่าเชื่อถือ ซึ่งเป็นบิตสตริง ที่จัดเตรียมไว้ให้ฮาร์ดแวร์ที่ปลอดภัยของ KeyMint ในระหว่างการเริ่มต้นระบบ โดย Bootloader จะเป็นผู้จัดเตรียมให้ สตริงบิตนี้เชื่อมโยงกับการเข้ารหัสกับคีย์ทุกรายการที่ KeyMint จัดการ

รูทของความน่าเชื่อถือประกอบด้วยคีย์สาธารณะที่ใช้เพื่อยืนยันลายเซ็นใน อิมเมจบูตและสถานะการล็อกของอุปกรณ์ หากมีการเปลี่ยนคีย์สาธารณะเพื่ออนุญาตให้ใช้อิมเมจระบบอื่น หรือหากมีการเปลี่ยนสถานะล็อก ระบบจะใช้คีย์ที่ KeyMint ปกป้องซึ่งสร้างโดยระบบก่อนหน้าไม่ได้ เว้นแต่จะมีการกู้คืนรูทของความน่าเชื่อถือก่อนหน้าและบูตระบบที่ลงนามด้วยคีย์นั้น เป้าหมายคือการเพิ่มมูลค่าของ การควบคุมการเข้าถึงคีย์ที่บังคับใช้ด้วยซอฟต์แวร์โดยการป้องกันไม่ให้ ระบบปฏิบัติการที่ผู้โจมตีติดตั้งใช้คีย์ KeyMint

คีย์แบบสแตนด์อโลน

ฮาร์ดแวร์ที่ปลอดภัยของ KeyMint บางรุ่นสามารถเลือกจัดเก็บเนื้อหาคีย์ภายใน และส่งคืนแฮนเดิลแทนเนื้อหาคีย์ที่เข้ารหัสได้ หรืออาจมีกรณีอื่นๆ ที่ใช้คีย์ไม่ได้จนกว่าจะมีคอมโพเนนต์ระบบที่ไม่ปลอดภัยหรือปลอดภัยอื่นๆ HAL ของ KeyMint ช่วยให้ผู้เรียกใช้สามารถ ขอให้คีย์เป็น "แบบสแตนด์อโลน" ผ่านแท็ก TAG::STANDALONE ซึ่งหมายความว่าไม่จำเป็นต้องใช้ทรัพยากรอื่นนอกเหนือจาก Blob และระบบ KeyMint ที่ทำงานอยู่ คุณตรวจสอบแท็กที่เชื่อมโยงกับคีย์เพื่อดูว่าคีย์เป็นแบบสแตนด์อโลนหรือไม่ ปัจจุบันมีการกำหนดค่าไว้ 2 ค่าเท่านั้น ได้แก่

• KeyBlobUsageRequirements::STANDALONE
• KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

ฟีเจอร์นี้ไม่พร้อมใช้งานในแอป

Velocity

เมื่อสร้างแล้ว คุณจะระบุความเร็วในการใช้งานสูงสุดได้ ด้วย TAG::MIN_SECONDS_BETWEEN_OPS การติดตั้งใช้งาน TrustZone จะปฏิเสธที่จะดำเนินการเข้ารหัสด้วยคีย์ดังกล่าว หากมีการดำเนินการน้อยกว่า TAG::MIN_SECONDS_BETWEEN_OPS วินาทีก่อนหน้านี้

แนวทางที่ง่ายในการใช้ขีดจำกัดความเร็วคือตารางรหัสคีย์และ การประทับเวลาการใช้งานล่าสุด ตารางนี้มีขนาดจำกัด แต่รองรับรายการอย่างน้อย 16 รายการ ในกรณีที่ตารางเต็มและอัปเดตหรือทิ้งรายการไม่ได้ การติดตั้งใช้งานฮาร์ดแวร์ที่ปลอดภัยจะ "ล้มเหลวอย่างปลอดภัย" โดยเลือกที่จะปฏิเสธการดำเนินการกับคีย์ทั้งหมดที่จำกัดความเร็วจนกว่ารายการใดรายการหนึ่งจะหมดอายุ รายการทั้งหมดจะหมดอายุเมื่อรีบูตได้

นอกจากนี้ คุณยังจำกัดคีย์ได้สูงสุด n ครั้งต่อการบูตด้วย TAG::MAX_USES_PER_BOOT นอกจากนี้ ยังต้องมีตารางการติดตาม ซึ่งรองรับคีย์อย่างน้อย 4 คีย์และยังทำงานได้อย่างปลอดภัย โปรดทราบว่า แอปสร้างคีย์ที่จำกัดต่อการรีบูตไม่ได้ ฟีเจอร์นี้ ไม่ได้แสดงผ่าน Keystore และสงวนไว้สำหรับการดำเนินการของระบบ

ฟีเจอร์นี้ไม่พร้อมใช้งานในแอป

การรีซีดโปรแกรมสุ่มตัวเลข

เนื่องจากฮาร์ดแวร์ที่ปลอดภัยจะสร้างตัวเลขสุ่มสำหรับเนื้อหาคีย์และเวกเตอร์การเริ่มต้น (IV) และเนื่องจากเครื่องสร้างตัวเลขสุ่มของฮาร์ดแวร์อาจไม่น่าเชื่อถือได้เสมอไป HAL ของ KeyMint จึงมีอินเทอร์เฟซเพื่อให้ไคลเอ็นต์ระบุเอนโทรปีเพิ่มเติม ซึ่งจะผสมกับตัวเลขสุ่มที่สร้างขึ้น

ใช้ตัวสร้างหมายเลขสุ่มฮาร์ดแวร์เป็นแหล่งที่มาของ Seed หลัก ข้อมูลเริ่มต้นที่ระบุผ่าน API ภายนอกไม่สามารถเป็นแหล่งที่มาเดียว ของความสุ่มที่ใช้ในการสร้างตัวเลขได้ นอกจากนี้ การดำเนินการผสมที่ใช้ต้องรับประกันว่าเอาต์พุตแบบสุ่มจะคาดเดาไม่ได้หากแหล่งที่มาของ Seed ใดแหล่งที่มาหนึ่งคาดเดาไม่ได้