ฟีเจอร์

หน้านี้มีข้อมูลเกี่ยวกับฟีเจอร์การเข้ารหัสของคีย์สโตร์ใน Android 6.0 ขึ้นไป

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

คีออสเทอร์มีการดำเนินการต่อไปนี้

  • การสร้างคีย์
  • การนําเข้าและส่งออกคีย์แบบไม่สมมาตร (ไม่มีการรวมคีย์)
  • การนําเข้าคีย์แบบสมมาตรดิบ (ไม่มีการรวมคีย์)
  • การเข้ารหัสและการถอดรหัสแบบอสมมาตรด้วยโหมดการเติมที่เหมาะสม
  • การรับรองและการยืนยันแบบอสมมาตรด้วยโหมดการรวมข้อมูลย่อยและการเติมที่เหมาะสม
  • การเข้ารหัสและการถอดรหัสแบบสมมาตรในโหมดที่เหมาะสม รวมถึงโหมด AEAD
  • การสร้างและการยืนยันรหัสการตรวจสอบสิทธิ์ข้อความแบบสมมาตร

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

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

องค์ประกอบพื้นฐานที่จำเป็น

การติดตั้งใช้งาน Keymaster ทั้งหมดมีสิ่งต่อไปนี้

  • 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) สำหรับการติดตั้งใช้งาน Keymaster เก็บไว้ในซอฟต์แวร์หากการติดตั้งใช้งาน Keymaster ของฮาร์ดแวร์ไม่ได้จัดเตรียมไว้ให้

นอกจากนี้ เรายังแนะนําให้ใช้พรอมิเตอบางรายการเพื่อความสามารถในการทํางานร่วมกันกับระบบอื่นๆ ด้วย

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

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

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

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

สำหรับ 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

UINT: จำนวนเต็มแบบไม่ลงนาม 32 บิต ตัวอย่าง: TAG::KEY_SIZE

UINT_REP: เหมือนกับ UINT ยกเว้นว่าแท็กนี้ใช้ได้ซ้ำในรายการการให้สิทธิ์ การซ้ำบ่งบอกถึงค่าที่ได้รับอนุญาตหลายค่า

ULONG: จำนวนเต็มแบบไม่ลงนาม 64 บิต ตัวอย่าง: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP: เหมือนกับ ULONG ยกเว้นว่าแท็กนี้ใช้ได้ซ้ำในรายการการให้สิทธิ์ การซ้ำบ่งบอกถึงค่าที่ได้รับอนุญาตหลายค่า

DATE: ค่าวันที่/เวลา ซึ่งแสดงเป็นมิลลิวินาทีนับจากวันที่ 1 มกราคม 1970 ตัวอย่าง: TAG::PRIVKEY_EXPIRE_DATETIME

BOOL: จริงหรือเท็จ ระบบจะถือว่าแท็กประเภท BOOL เป็น "เท็จ" หากไม่มีแท็กนั้น และ "จริง" หากมีแท็กนั้น ตัวอย่าง: TAG::ROLLBACK_RESISTANT

BIGNUM: จำนวนเต็มที่มีความยาวตามต้องการ ซึ่งแสดงเป็นอาร์เรย์ไบต์ตามลําดับ Big-Endian ตัวอย่าง: TAG::RSA_PUBLIC_EXPONENT

BYTES: ลำดับไบต์ ตัวอย่าง: TAG::ROOT_OF_TRUST

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

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

การติดตั้งใช้งานทั้งหมด

  • บังคับใช้การจับคู่ที่ตรงกันทั้งหมด (ไม่ใช่การบังคับใช้) ของการให้สิทธิ์ทั้งหมด รายการการให้สิทธิ์ในบล็อกคีย์จะตรงกับการให้สิทธิ์ที่แสดงระหว่างการสร้างคีย์ทุกประการ รวมถึงลําดับ ความไม่ตรงกันจะทําให้เกิดการวิเคราะห์ข้อผิดพลาด
  • ประกาศการให้สิทธิ์ที่มีการใช้ค่าเชิงความหมาย

กลไก API สำหรับการประกาศการให้สิทธิ์ที่บังคับใช้ด้วยฮาร์ดแวร์อยู่ในโครงสร้าง keymaster_key_characteristics_t โดยจะแบ่งรายการการให้สิทธิ์ออกเป็น 2 รายการย่อย ได้แก่ hw_enforced และ sw_enforced ฮาร์ดแวร์ที่มีความปลอดภัยมีหน้าที่ใส่ค่าที่เหมาะสมในแต่ละรายการตามสิ่งที่บังคับใช้ได้

นอกจากนี้ Keystore ยังใช้การบังคับใช้การให้สิทธิ์ทั้งหมดโดยซอฟต์แวร์ ไม่ว่าจะมีการบังคับใช้โดยฮาร์ดแวร์ที่มีความปลอดภัยหรือไม่ก็ตาม

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

หากอัปเกรดอุปกรณ์ด้วยฮาร์ดแวร์ที่มีความปลอดภัยซึ่งรองรับการหมดอายุ คําขอลักษณะคีย์จะพบ TAG::ORIGINATION_EXPIRE_DATETIME ในรายการ hw_enforced และพยายามใช้คีย์หลังจากหมดอายุไม่สําเร็จ แม้ว่าจะมีการแทรกแซงหรือข้ามที่เก็บคีย์ก็ตาม

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

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

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

TAG::PADDING, TAG::DIGEST และ PaddingMode::BLOCK_MODE ซ้ำกันได้ ซึ่งหมายความว่าสามารถเชื่อมโยงค่าหลายค่ากับคีย์เดียวได้ และค่าที่จะใช้จะระบุไว้ในเวลาดำเนินการ

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

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

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

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

นำเข้าและส่งออก

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

  • คู่คีย์สาธารณะและคีย์ส่วนตัวในรูปแบบ PKCS#8 ที่เข้ารหัส DER โดยไม่มีการเข้ารหัสด้วยรหัสผ่าน
  • คีย์แบบสมมาตรเป็นไบต์ดิบ

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

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

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

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

  • TAG::ALL_USERS บ่งบอกว่าผู้ใช้ทุกคนสามารถใช้คีย์ได้ หากมี TAG::USER_ID และ TAG::USER_SECURE_ID จะไม่ปรากฏ
  • TAG::USER_ID มีค่าตัวเลขที่ระบุรหัสของผู้ใช้ที่ได้รับอนุญาต โปรดทราบว่านี่คือรหัสผู้ใช้ Android (สำหรับผู้ใช้หลายคน) ไม่ใช่ UID ของแอป และซอฟต์แวร์ที่ไม่ปลอดภัยเท่านั้นที่จะบังคับใช้รหัสนี้ หากมี TAG::ALL_USERS จะไม่ปรากฏ
  • TAG::USER_SECURE_ID มีค่าตัวเลข 64 บิตที่ระบุรหัสผู้ใช้ที่ปลอดภัยซึ่งระบุไว้ในโทเค็นการตรวจสอบสิทธิ์ที่ปลอดภัยเพื่อปลดล็อกการใช้คีย์ หากใช้ซ้ำ คีย์จะใช้ได้หากระบุค่าใดค่าหนึ่งในโทเค็นการตรวจสอบสิทธิ์ที่ปลอดภัย

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

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

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

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

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

ด้วยเหตุนี้ คีสต์ออฟเวอร์จึง "เข้ารหัสขั้นสูง" ให้กับคีย์ UNLOCKED_DEVICE_REQUIRED ทั้งหมดก่อนที่จะจัดเก็บไว้ในฐานข้อมูล และหากเป็นไปได้ ก็จะปกป้องคีย์การเข้ารหัสขั้นสูง (คีย์ซุปเปอร์) ขณะที่อุปกรณ์ล็อกอยู่ด้วยวิธีที่จะกู้คืนได้ก็ต่อเมื่อปลดล็อกอุปกรณ์สำเร็จเท่านั้น (คําว่า "การเข้ารหัสขั้นสูง" ใช้เนื่องจากการเข้ารหัสชั้นนี้จะใช้เพิ่มเติมจากการเข้ารหัสชั้นที่ Keymaster ใช้กับคีย์ทั้งหมดอยู่แล้ว)

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

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

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

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

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

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

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

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

ฟีเจอร์นี้จะไม่แสดงในแอป

วันหมดอายุ

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

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

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

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

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

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

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

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

  • KeyBlobUsageRequirements::STANDALONE
  • KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

ฟีเจอร์นี้จะไม่แสดงในแอป

ความเร็ว

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

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

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

ฟีเจอร์นี้จะไม่แสดงในแอป

การสร้างเมล็ดสุ่มใหม่ของโปรแกรมสุ่มตัวเลข

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

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

ฟีเจอร์นี้จะไม่แสดงต่อแอป แต่เฟรมเวิร์กจะใช้ฟีเจอร์นี้ ซึ่งจะส่งข้อมูลความผันผวนเพิ่มเติมไปยังฮาร์ดแวร์ที่มีความปลอดภัยเป็นประจำ โดยดึงมาจากอินสแตนซ์ Java SecureRandom