الميزات

تحتوي هذه الصفحة على معلومات حول ميزات التشفير الخاصة بـ Keystore في Android 6.0 والإصدارات الأحدث.

بدايات التشفير

يوفر Keystore الفئات التالية من العمليات:

• توليد المفتاح
• استيراد وتصدير المفاتيح غير المتماثلة (بدون تغليف المفاتيح)
• استيراد المفاتيح المتماثلة الخام (بدون تغليف المفاتيح)
• التشفير وفك التشفير غير المتماثلين باستخدام أوضاع الحشو المناسبة
• التوقيع والتحقق غير المتماثلين مع أوضاع الاستيعاب والحشو المناسبة
• التشفير وفك التشفير المتماثل في الأوضاع المناسبة، بما في ذلك وضع AEAD
• إنشاء والتحقق من رموز مصادقة الرسائل المتماثلة

يتم تحديد عناصر البروتوكول، مثل الغرض والوضع والحشوة، بالإضافة إلى قيود التحكم في الوصول ، عند إنشاء المفاتيح أو استيرادها وتكون مرتبطة بشكل دائم بالمفتاح، مما يضمن عدم إمكانية استخدام المفتاح بأي طريقة أخرى.

بالإضافة إلى القائمة أعلاه، هناك خدمة أخرى توفرها تطبيقات Keymaster، ولكن لا يتم عرضها كواجهة برمجة تطبيقات: إنشاء الأرقام العشوائية. يُستخدم هذا داخليًا لإنشاء المفاتيح ومتجهات التهيئة (IVs) والحشو العشوائي والعناصر الأخرى للبروتوكولات الآمنة التي تتطلب العشوائية.

البدائيات اللازمة

توفر جميع تطبيقات Keymaster:

• آر إس إيه
  • دعم مفاتيح 2048 و3072 و4096 بت
  • دعم الأس العام F4 (2^16+1)
  • أوضاع الحشو لتوقيع RSA:
    • RSASSA-PSS ( PaddingMode::RSA_PSS )
    • RSASSA-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_SIGN )
  • أوضاع الملخص لتوقيع RSA:
    • شا-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:
    • لا يوجد ملخص (متوقف، ستتم إزالته في المستقبل)
    • شا-256
• الخدمات المعمارية والهندسية
  • يتم دعم مفاتيح 128 و256 بت
  • CBC ، ونسبة النقر إلى الظهور، والبنك المركزي الأوروبي، وGCM. لا يسمح تطبيق GCM باستخدام علامات أصغر من 96 بت أو أطوال غير 96 بت.
  • أوضاع الحشو PaddingMode::NONE و PaddingMode::PKCS7 مدعومة لوضعي CBC وECB. مع عدم وجود حشوة، يفشل تشفير وضع CBC أو ECB إذا لم يكن الإدخال مضاعفًا لحجم الكتلة.
• HMAC SHA-256 ، مع أي حجم مفتاح يصل إلى 32 بايت على الأقل.

يوصى بشدة باستخدام SHA1 والأعضاء الآخرين في عائلة SHA2 (SHA-224 وSHA384 وSHA512) لتطبيقات Keymaster. يوفرها Keystore في البرنامج إذا لم يوفرها تطبيق Keymaster للأجهزة.

يوصى أيضًا ببعض البدائيات لقابلية التشغيل البيني مع الأنظمة الأخرى:

• أحجام مفاتيح أصغر لـ RSA
• الأسس العامة التعسفية لـ RSA

التحكم في الوصول إلى المفتاح

المفاتيح المستندة إلى الأجهزة والتي لا يمكن استخراجها من الجهاز أبدًا لا توفر قدرًا كبيرًا من الأمان إذا كان بإمكان المهاجم استخدامها حسب الرغبة (على الرغم من أنها أكثر أمانًا من المفاتيح التي يمكن سحبها). وبالتالي، من المهم أن يقوم Keystore بفرض ضوابط الوصول.

يتم تعريف عناصر التحكم في الوصول على أنها "قائمة تفويض" لأزواج العلامات/القيمة. علامات التفويض هي أعداد صحيحة 32 بت والقيم هي مجموعة متنوعة من الأنواع. قد يتم تكرار بعض العلامات لتحديد قيم متعددة. يتم تحديد إمكانية تكرار العلامة في وثائق العلامة . عند إنشاء مفتاح، يحدد المتصل قائمة التفويضات. يقوم تطبيق Keymaster الأساسي لـ Keystore بتعديل القائمة لتحديد بعض المعلومات الإضافية، مثل ما إذا كان المفتاح يتمتع بحماية التراجع، وإرجاع قائمة التفويض "النهائية"، المشفرة في blob للمفتاح الذي تم إرجاعه. أي محاولة لاستخدام المفتاح لأي عملية تشفير تفشل إذا تم تعديل قائمة التفويض النهائية.

بالنسبة إلى Keymaster 2 والإصدارات الأقدم، يتم تعريف مجموعة العلامات المحتملة في التعداد keymaster_authorization_tag_t ويتم إصلاحها بشكل دائم (على الرغم من إمكانية توسيعها). كانت الأسماء مسبوقة بـ KM_TAG . يتم استخدام البتات الأربعة العليا لمعرفات العلامات للإشارة إلى النوع.

قام 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 : أعداد صحيحة ذات طول تعسفي، يتم التعبير عنها كمصفوفة بايت بترتيب النهاية الكبيرة. مثال: TAG::RSA_PUBLIC_EXPONENT

BYTES : سلسلة من البايتات. مثال: TAG::ROOT_OF_TRUST

إنفاذ الأجهزة مقابل البرمجيات

لا تحتوي جميع تطبيقات الأجهزة الآمنة على نفس الميزات. لدعم مجموعة متنوعة من الأساليب، يميز Keymaster بين إنفاذ التحكم في الوصول العالمي الآمن وغير الآمن، أو إنفاذ الأجهزة والبرامج، على التوالي.

جميع التنفيذات:

• فرض المطابقة الدقيقة (وليس التنفيذ) لجميع التفويضات. تتطابق قوائم التفويض في النقاط الرئيسية تمامًا مع التفويضات التي يتم إرجاعها أثناء إنشاء المفتاح، بما في ذلك الطلب. يؤدي أي عدم تطابق إلى تشخيص الخطأ.
• أعلن عن التفويضات التي يتم فرض قيمها الدلالية.

توجد آلية واجهة برمجة التطبيقات (API) للإعلان عن التفويضات المفروضة على الأجهزة في بنية keymaster_key_characteristics_t . يقوم بتقسيم قائمة التفويض إلى قائمتين فرعيتين، hw_enforced و sw_enforced . الأجهزة الآمنة مسؤولة عن وضع القيم المناسبة في كل منها، بناءً على ما يمكنها فرضه.

بالإضافة إلى ذلك، يقوم Keystore بتنفيذ جميع التفويضات بناءً على البرامج، سواء تم فرضها بواسطة الأجهزة الآمنة أم لا.

على سبيل المثال، ضع في اعتبارك تطبيقًا يستند إلى TrustZone ولا يدعم انتهاء صلاحية المفتاح. لا يزال من الممكن إنشاء مفتاح له تاريخ انتهاء الصلاحية. ستتضمن قائمة ترخيص هذا المفتاح العلامة TAG::ORIGINATION_EXPIRE_DATETIME مع تاريخ انتهاء الصلاحية. سيؤدي طلب Keystore للحصول على خصائص المفاتيح إلى العثور على هذه العلامة في قائمة 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 قابلة للتكرار، مما يعني أنه قد ترتبط قيم متعددة بمفتاح واحد، ويتم تحديد القيمة التي سيتم استخدامها في وقت التشغيل.

غاية

تحتوي المفاتيح على مجموعة من الأغراض المرتبطة بها، والتي يتم التعبير عنها كإدخال ترخيص واحد أو أكثر باستخدام العلامة 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 .

مصادقة المستخدم

لا تنفذ تطبيقات Keymaster الآمنة مصادقة المستخدم، ولكنها تعتمد على التطبيقات الموثوقة الأخرى التي تقوم بذلك. للتعرف على الواجهة التي تنفذها هذه التطبيقات، راجع صفحة Gatekeeper .

يتم تحديد متطلبات مصادقة المستخدم عبر مجموعتين من العلامات. تشير المجموعة الأولى إلى المستخدم الذي يمكنه استخدام المفتاح:

• يشير TAG::ALL_USERS إلى أن المفتاح قابل للاستخدام من قبل جميع المستخدمين. إذا كان موجودًا، فإن TAG::USER_ID و TAG::USER_SECURE_ID غير موجودين.
• TAG::USER_ID له قيمة رقمية تحدد معرف المستخدم المعتمد. لاحظ أن هذا هو معرف مستخدم Android (للمستخدمين المتعددين)، وليس UID للتطبيق، ويتم فرضه بواسطة برامج غير آمنة فقط. إذا كان موجودًا، فإن TAG::ALL_USERS غير موجود.
• TAG::USER_SECURE_ID له قيمة رقمية 64 بت تحدد معرف المستخدم الآمن الذي يتم توفيره في رمز المصادقة الآمن لإلغاء قفل استخدام المفتاح. في حالة التكرار، يمكن استخدام المفتاح إذا تم توفير أي من القيم في رمز مصادقة آمن.

تشير المجموعة الثانية إلى ما إذا كان المستخدم يحتاج إلى المصادقة ومتى. في حالة عدم وجود أي من هذه العلامات، ولكن TAG::USER_SECURE_ID موجود، تكون المصادقة مطلوبة لكل استخدام للمفتاح.

• يشير NO_AUTHENTICATION_REQUIRED إلى عدم الحاجة إلى مصادقة المستخدم، على الرغم من أنه لا يزال من الممكن استخدام المفتاح فقط من خلال التطبيقات التي تعمل كمستخدم (مستخدمين) محدد بواسطة TAG::USER_ID .
• TAG::AUTH_TIMEOUT هي قيمة رقمية تحدد، بالثواني، مدى تحديث مصادقة المستخدم للسماح باستخدام المفتاح. ينطبق هذا فقط على عمليات المفاتيح الخاصة/السرية. لا تتطلب عمليات المفتاح العام المصادقة. لا تتعارض المهلات مع عمليات إعادة التشغيل؛ بعد إعادة التشغيل، يتم "عدم المصادقة على" كافة المفاتيح. قد يتم تعيين المهلة على قيمة كبيرة للإشارة إلى أن المصادقة مطلوبة مرة واحدة لكل تمهيد (2 ^ 32 ثانية هي ~ 136 عامًا؛ ومن المفترض أن يتم إعادة تشغيل أجهزة Android أكثر من ذلك).

ملزمة العميل

يتم ربط العميل، وهو ربط مفتاح بتطبيق عميل معين، عبر معرف عميل اختياري وبعض بيانات العميل الاختيارية ( TAG::APPLICATION_ID و TAG::APPLICATION_DATA ، على التوالي). يتعامل Keystore مع هذه القيم على أنها نقاط غير شفافة، ويضمن فقط أن نفس النقط التي تم تقديمها أثناء إنشاء/استيراد المفتاح يتم تقديمها لكل استخدام وتكون متطابقة لكل بايت. لا يتم إرجاع بيانات ربط العميل بواسطة Keymaster. يجب أن يعرف المتصل ذلك حتى يتمكن من استخدام المفتاح.

لا يتم عرض هذه الميزة للتطبيقات.

انتهاء الصلاحية

يدعم 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 ربط المفاتيح بجذر الثقة، وهو عبارة عن سلسلة بت يتم توفيرها لجهاز Keymaster الآمن أثناء بدء التشغيل، ويفضل أن يكون ذلك بواسطة أداة تحميل التشغيل. ترتبط سلسلة البت هذه بشكل مشفر بكل مفتاح يديره Keymaster.

يتكون جذر الثقة من المفتاح العام المستخدم للتحقق من التوقيع على صورة التمهيد وحالة قفل الجهاز. إذا تم تغيير المفتاح العام للسماح باستخدام صورة نظام مختلفة أو إذا تم تغيير حالة القفل، فلن يكون أي من المفاتيح المحمية بواسطة Keymaster التي أنشأها النظام السابق قابلاً للاستخدام، ما لم تتم استعادة جذر الثقة السابق ونظام تم التوقيع عليه بواسطة هذا المفتاح. الهدف هو زيادة قيمة عناصر التحكم في الوصول إلى المفاتيح التي يفرضها البرنامج من خلال جعل من المستحيل على نظام التشغيل المثبت من قبل المهاجم استخدام مفاتيح Keymaster.

مفاتيح مستقلة

قد تختار بعض أجهزة Keymaster الآمنة تخزين المواد الرئيسية داخليًا وإرجاع المقابض بدلاً من المواد الرئيسية المشفرة. أو قد تكون هناك حالات أخرى لا يمكن فيها استخدام المفاتيح حتى يتوفر بعض مكونات النظام العالمي الأخرى غير الآمنة أو الآمنة. يسمح Keymaster HAL للمتصل بطلب أن يكون المفتاح "مستقلًا"، عبر علامة TAG::STANDALONE ، مما يعني أنه لا توجد حاجة إلى موارد أخرى غير blob ونظام Keymaster قيد التشغيل. قد يتم فحص العلامات المرتبطة بالمفتاح لمعرفة ما إذا كان المفتاح مستقلاً أم لا. في الوقت الحاضر، تم تحديد قيمتين فقط:

• KeyBlobUsageRequirements::STANDALONE
• KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

لا يتم عرض هذه الميزة للتطبيقات.

سرعة

عند إنشائه، يمكن تحديد الحد الأقصى لسرعة الاستخدام باستخدام TAG::MIN_SECONDS_BETWEEN_OPS . ترفض تطبيقات TrustZone تنفيذ عمليات التشفير باستخدام هذا المفتاح إذا تم تنفيذ العملية قبل أقل من TAG::MIN_SECONDS_BETWEEN_OPS ثانية.

إن النهج البسيط لتطبيق حدود السرعة هو جدول للمعرفات الرئيسية والطوابع الزمنية للاستخدام الأخير. من المحتمل أن يكون هذا الجدول محدود الحجم، ولكنه يتسع لـ 16 مدخلاً على الأقل. في حالة امتلاء الجدول وعدم إمكانية تحديث أي إدخالات أو تجاهلها، فإن تطبيقات الأجهزة الآمنة "تفشل بشكل آمن"، مفضلاً رفض جميع العمليات الرئيسية ذات السرعة المحدودة حتى تنتهي صلاحية أحد الإدخالات. من المقبول أن تنتهي صلاحية جميع الإدخالات عند إعادة التشغيل.

يمكن أيضًا أن تقتصر المفاتيح على عدد n من الاستخدامات لكل تمهيد باستخدام TAG::MAX_USES_PER_BOOT . يتطلب هذا أيضًا جدول تتبع يتسع لأربعة مفاتيح على الأقل ويكون آمنًا أيضًا. لاحظ أن التطبيقات لن تكون قادرة على إنشاء مفاتيح محدودة لكل تمهيد. لا يتم عرض هذه الميزة من خلال Keystore وهي محجوزة لعمليات النظام.

لا يتم عرض هذه الميزة للتطبيقات.

إعادة زرع مولد الأرقام العشوائية

نظرًا لأن الأجهزة الآمنة تولد أرقامًا عشوائية للمواد الأساسية ومتجهات التهيئة (IVs)، ولأن مولدات الأرقام العشوائية للأجهزة قد لا تكون دائمًا جديرة بالثقة تمامًا، فإن Keymaster HAL يوفر واجهة للسماح للعميل بتوفير إنتروبيا إضافية سيتم مزجها في العشوائية الأرقام التي تم إنشاؤها.

استخدم منشئ الأرقام العشوائية للأجهزة كمصدر أولي أساسي. لا يمكن أن تكون البيانات الأولية المقدمة من خلال واجهة برمجة التطبيقات الخارجية هي المصدر الوحيد للعشوائية المستخدمة لتوليد الأرقام. علاوة على ذلك، تحتاج عملية الخلط المستخدمة إلى التأكد من عدم إمكانية التنبؤ بالمخرجات العشوائية إذا كان أي من مصادر البذور غير قابل للتنبؤ به.

لا يتم عرض هذه الميزة للتطبيقات ولكن يتم استخدامها بواسطة إطار العمل، الذي يوفر بانتظام إنتروبيا إضافية، يتم استردادها من مثيل Java SecureRandom، إلى الأجهزة الآمنة.