تحتوي هذه الصفحة على معلومات حول ميزات التشفير الخاصة بـ Keystore في Android 6.0 والإصدارات الأحدث.
أساسيات التشفير
يوفر Keystore فئات العمليات التالية:
- توليد المفتاح
- استيراد وتصدير المفاتيح غير المتماثلة (بدون تغليف المفاتيح)
- استيراد مفاتيح متماثلة خام (بدون تغليف للمفاتيح)
- التشفير غير المتماثل وفك التشفير مع أوضاع الحشو المناسبة
- التوقيع والتحقق غير المتماثل مع أوضاع الهضم والحشو المناسب
- التشفير المتماثل وفك التشفير في الأوضاع المناسبة ، بما في ذلك وضع AEAD
- إنشاء رموز مصادقة الرسائل المتماثلة والتحقق منها
يتم تحديد عناصر البروتوكول ، مثل الغرض والوضع والحشو ، فضلاً عن قيود التحكم في الوصول ، عند إنشاء المفاتيح أو استيرادها وربطها بشكل دائم بالمفتاح ، مما يضمن عدم إمكانية استخدام المفتاح بأي طريقة أخرى.
بالإضافة إلى القائمة أعلاه ، هناك خدمة أخرى توفرها تطبيقات Keymaster ، ولكن لا يتم عرضها كواجهة برمجة تطبيقات: إنشاء رقم عشوائي. يستخدم هذا داخليًا لإنشاء المفاتيح ونواقل التهيئة (IVs) والحشو العشوائي وعناصر أخرى من البروتوكولات الآمنة التي تتطلب العشوائية.
الأساسيات الضرورية
توفر جميع تطبيقات 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
)
- RSASSA-PSS (
- أوضاع الملخص لتوقيع 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. يوفرها Keystore في البرنامج إذا لم يوفرها تطبيق Keymaster للأجهزة.
يوصى أيضًا ببعض العناصر الأولية للتشغيل البيني مع الأنظمة الأخرى:
- أحجام مفاتيح أصغر لـ RSA
- الدعاة التعسفيون العامون لـ RSA
مفتاح التحكم في الوصول
لا توفر المفاتيح المستندة إلى الأجهزة التي لا يمكن استخراجها من الجهاز أبدًا قدرًا كبيرًا من الأمان إذا كان بإمكان المهاجم استخدامها كما يشاء (على الرغم من أنها أكثر أمانًا من المفاتيح التي يمكن اختراقها). وبالتالي ، من الأهمية بمكان أن يقوم Keystore بفرض ضوابط الوصول.
يتم تعريف ضوابط الوصول على أنها "قائمة تفويض" لأزواج العلامة / القيمة. علامات التفويض هي أعداد صحيحة 32 بت والقيم متنوعة الأنواع. قد يتم تكرار بعض العلامات لتحديد قيم متعددة. يتم تحديد إمكانية تكرار العلامة في وثائق العلامة . عند إنشاء مفتاح ، يحدد المتصل قائمة التخويل. يعدل Keystore الأساسي لتطبيق Keymaster القائمة لتحديد بعض المعلومات الإضافية ، مثل ما إذا كان المفتاح يحتوي على حماية من التراجع ، وإرجاع قائمة التخويل "النهائية" ، المشفرة في 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 بين فرض التحكم في الوصول العالمي الآمن وغير الآمن ، أو فرض الأجهزة والبرامج ، على التوالي.
كل التطبيقات:
- فرض المطابقة التامة (وليس الإنفاذ) لجميع التراخيص. تتطابق قوائم التفويض في الكتل الرئيسية تمامًا مع الأذونات التي تم إرجاعها أثناء إنشاء المفتاح ، بما في ذلك الطلب. أي عدم تطابق يسبب خطأ في التشخيص.
- التصريح عن التراخيص التي يتم فرض قيمها الدلالية.
توجد آلية واجهة برمجة التطبيقات لإعلان التراخيص التي يتم فرضها عن طريق الأجهزة في بنية 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 :: BLOCK_MODE و TAG 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
.
مصادقة المستخدم
لا تنفذ تطبيقات Secure Keymaster مصادقة المستخدم ، ولكنها تعتمد على التطبيقات الموثوقة الأخرى التي تقوم بذلك. للواجهة التي تنفذها هذه التطبيقات ، راجع صفحة Gatekeeper .
يتم تحديد متطلبات مصادقة المستخدم من خلال مجموعتين من العلامات. تشير المجموعة الأولى إلى أي مستخدم يمكنه استخدام المفتاح:
- يشير
TAG::ALL_USERS
إلى أن المفتاح قابل للاستخدام من قبل جميع المستخدمين. في حالة وجودها ،TAG::USER_ID
وTAG::USER_SECURE_ID
غير موجودة. -
TAG::USER_ID
لها قيمة رقمية تحدد معرّف المستخدم المرخص. لاحظ أن هذا هو معرف مستخدم Android (لعدة مستخدمين) ، وليس معرف المستخدم الخاص بالتطبيق ، ويتم فرضه بواسطة برنامج غير آمن فقط. إذا كان موجودًا ، فإن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 ، إلى الأجهزة الآمنة.