FIPS 140-3 وحدة تشفير GKI قابلة للتصديق

تتضمن نواة GKI وحدة نواة Linux تسمى fips140.ko والتي تتوافق مع متطلبات FIPS 140-3 لوحدات برامج التشفير. يمكن تقديم هذه الوحدة للحصول على شهادة FIPS إذا كان المنتج الذي يستخدم نواة GKI يتطلب ذلك.

يجب استيفاء متطلبات FIPS 140-3 التالية على وجه الخصوص قبل استخدام إجراءات التشفير:

  • يجب أن تتحقق الوحدة من سلامتها قبل إتاحة خوارزميات التشفير.
  • يجب أن تقوم الوحدة بممارسة خوارزميات التشفير المعتمدة والتحقق منها باستخدام الاختبارات الذاتية ذات الإجابة المعروفة قبل إتاحتها.

لماذا وحدة نواة منفصلة

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

تم تصميم نواة GKI ليتم تحديثها بانتظام خلال كامل عمرها المدعوم. وهذا يجعل من غير الممكن للنواة بأكملها أن تكون ضمن حدود وحدة FIPS، حيث أن مثل هذه الوحدة ستحتاج إلى إعادة اعتمادها عند كل تحديث للنواة. إن تحديد "وحدة FIPS" لتكون مجموعة فرعية من صورة kernel من شأنه أن يخفف من هذه المشكلة ولكنه لن يحلها، حيث أن المحتويات الثنائية لـ "وحدة FIPS" ستظل تتغير بشكل متكرر أكثر من اللازم.

قبل إصدار kernel 6.1، كان هناك اعتبار آخر وهو أنه تم تجميع GKI مع تمكين LTO (تحسين وقت الارتباط)، نظرًا لأن LTO كان شرطًا أساسيًا للتحكم في تكامل التدفق وهو ميزة أمنية مهمة.

لذلك، يتم تجميع جميع التعليمات البرمجية التي تغطيها متطلبات FIPS 140-3 في وحدة kernel منفصلة fips140.ko والتي تعتمد فقط على الواجهات المستقرة التي يكشفها مصدر kernel GKI الذي تم بناؤه منه. يضمن هذا إمكانية استخدام الوحدة مع إصدارات GKI مختلفة من نفس الجيل، وأنه يجب تحديثها وإعادة تقديمها للحصول على الشهادة فقط إذا تم إصلاح أي مشكلات في الكود الذي تحمله الوحدة نفسها.

متى تستخدم الوحدة

تحمل نواة GKI نفسها تعليمات برمجية تعتمد على إجراءات التشفير التي يتم حزمها أيضًا في وحدة kernel FIPS 140-3. لذلك، لا يتم نقل إجراءات التشفير المضمنة فعليًا من نواة GKI، بل يتم نسخها إلى الوحدة النمطية. عند تحميل الوحدة، يتم إلغاء تسجيل إجراءات التشفير المضمنة من Linux CryptoAPI وتحل محلها تلك التي تحملها الوحدة.

وهذا يعني أن وحدة fips140.ko اختيارية تمامًا، ومن المنطقي نشرها فقط إذا كانت شهادة FIPS 140-3 مطلوبة. علاوة على ذلك، لا توفر الوحدة أي وظائف إضافية، ومن المرجح أن يؤثر تحميلها دون داع على وقت التمهيد، دون تقديم أي فائدة.

كيفية نشر الوحدة

يمكن دمج الوحدة في إصدار Android باستخدام الخطوات التالية:

  • أضف اسم الوحدة إلى BOARD_VENDOR_RAMDISK_KERNEL_MODULES . يؤدي هذا إلى نسخ الوحدة النمطية إلى قرص الذاكرة الخاص بالمورد.
  • أضف اسم الوحدة إلى BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD . يؤدي هذا إلى إضافة اسم الوحدة إلى modules.load على الهدف. يحتوي modules.load على قائمة الوحدات التي تم تحميلها بواسطة init عند تشغيل الجهاز.

التحقق الذاتي من النزاهة

تأخذ وحدة kernel FIPS 140-3 ملخص HMAC-SHA256 لأقسام .code و .rodata الخاصة بها في وقت تحميل الوحدة، وتقارنه بالملخص المسجل في الوحدة. يحدث هذا بعد أن يقوم مُحمل وحدة Linux بالفعل بإجراء التعديلات المعتادة مثل معالجة نقل ELF وتصحيح البدائل لأخطاء وحدة المعالجة المركزية في تلك الأقسام. يتم اتخاذ الخطوات الإضافية التالية لضمان إمكانية إعادة إنتاج الملخص بشكل صحيح:

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

الاختبارات الذاتية ذات الإجابة المعروفة

يجب أن تقوم أي خوارزميات تم تنفيذها والتي تغطيها متطلبات FIPS 140-3 بإجراء اختبار ذاتي للإجابة المعروفة قبل استخدامها. وفقًا لإرشادات تنفيذ FIPS 140-3 10.3.A ، يعد ناقل اختبار واحد لكل خوارزمية باستخدام أي من أطوال المفاتيح المدعومة كافيًا للشفرات، طالما تم اختبار كل من التشفير وفك التشفير.

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

الخوارزميات المدرجة في الوحدة

يتم سرد كافة الخوارزميات المضمنة في الوحدة النمطية FIPS 140-3 كما يلي. ينطبق هذا على فروع kernel android12-5.10 و android13-5.10 و android13-5.15 و android14-5.15 و android14-6.1 ، على الرغم من ملاحظة الاختلافات بين إصدارات kernel حيثما كان ذلك مناسبًا.

خوارزمية التنفيذ مقبول تعريف
aes aes-generic ، aes-arm64 ، aes-ce ، مكتبة AES نعم تشفير كتلة AES عادي، بدون وضع تشغيل: يتم دعم جميع أحجام المفاتيح (128 بت، و192 بت، و256 بت). يمكن أن تتكون جميع التطبيقات بخلاف تطبيق المكتبة من طريقة تشغيل من خلال قالب.
cmac(aes) cmac (قالب)، cmac-aes-neon ، cmac-aes-ce نعم AES-CMAC: جميع أحجام مفاتيح AES مدعومة. يمكن إنشاء قالب cmac باستخدام أي تطبيق لـ aes باستخدام cmac(<aes-impl>) . التطبيقات الأخرى مستقلة.
ecb(aes) ecb (قالب)، ecb-aes-neon ، ecb-aes-neonbs ، ecb-aes-ce نعم AES-ECB: جميع أحجام مفاتيح AES مدعومة. يمكن إنشاء قالب ecb باستخدام أي تطبيق لـ aes باستخدام ecb(<aes-impl>) . التطبيقات الأخرى مستقلة.
cbc(aes) cbc (قالب)، cbc-aes-neon ، cbc-aes-neonbs ، cbc-aes-ce نعم AES-CBC: جميع أحجام مفاتيح AES مدعومة. يمكن إنشاء قالب cbc باستخدام أي تطبيق لـ aes باستخدام ctr(<aes-impl>) . التطبيقات الأخرى مستقلة.
cts(cbc(aes)) cts (قالب)، cts-cbc-aes-neon ، cts-cbc-aes-ce نعم AES-CBC-CTS أو AES-CBC مع سرقة النص المشفر: الاتفاقية المستخدمة هي CS3 ؛ يتم تبديل كتلتي النص المشفر الأخيرتين دون قيد أو شرط. يتم دعم جميع أحجام مفاتيح AES. يمكن إنشاء قالب cts بأي تطبيق لـ cbc باستخدام cts(<cbc(aes)-impl>) . التطبيقات الأخرى مستقلة.
ctr(aes) ctr (قالب)، ctr-aes-neon ، ctr-aes-neonbs ، ctr-aes-ce نعم AES-CTR: جميع أحجام مفاتيح AES مدعومة. يمكن إنشاء قالب ctr باستخدام أي تطبيق لـ aes باستخدام ctr(<aes-impl>) . التطبيقات الأخرى مستقلة.
xts(aes) xts (قالب)، xts-aes-neon ، xts-aes-neonbs ، xts-aes-ce نعم AES-XTS: جميع أحجام مفاتيح AES مدعومة. يمكن إنشاء قالب xts بأي تطبيق لـ ecb(aes) باستخدام xts(<ecb(aes)-impl>) . التطبيقات الأخرى مستقلة. تقوم كافة التطبيقات بتنفيذ فحص المفتاح الضعيف الذي يتطلبه FIPS؛ أي أنه يتم رفض مفاتيح XTS التي يتساوى نصفيها الأول والثاني.
gcm(aes) gcm (قالب)، gcm-aes-ce رقم 1 AES-GCM: جميع أحجام مفاتيح AES مدعومة. يتم دعم IVs 96 بت فقط. كما هو الحال مع جميع أوضاع AES الأخرى في هذه الوحدة، يكون المتصل مسؤولاً عن توفير أجهزة IV. يمكن إنشاء قالب gcm باستخدام أي تطبيقات لـ ctr(aes) و ghash باستخدام gcm_base(<ctr(aes)-impl>,<ghash-impl>) . التطبيقات الأخرى مستقلة.
sha1 sha1-generic ، sha1-ce نعم وظيفة تجزئة التشفير SHA-1
sha224 sha224-generic ، sha224-arm64 ، sha224-ce نعم وظيفة تجزئة التشفير SHA-224: تتم مشاركة الرمز مع SHA-256.
sha256 مكتبة sha256-generic ، sha256-arm64 ، sha256-ce ، SHA-256 نعم وظيفة تجزئة التشفير SHA-256: يتم توفير واجهة مكتبة لـ SHA-256 بالإضافة إلى واجهة CryptoAPI التقليدية. تستخدم واجهة المكتبة هذه تطبيقًا مختلفًا.
sha384 sha384-generic ، sha384-arm64 ، sha384-ce نعم وظيفة تجزئة التشفير SHA-384: تتم مشاركة الرمز مع SHA-512.
sha512 sha512-generic ، sha512-arm64 ، sha512-ce نعم وظيفة تجزئة التشفير SHA-512
hmac hmac (قالب) نعم HMAC (رمز مصادقة رسالة التجزئة المفتاحية): يمكن إنشاء قالب hmac باستخدام أي خوارزمية SHA أو تطبيق باستخدام hmac(<sha-alg>) أو hmac(<sha-impl>) .
stdrng drbg_pr_hmac_sha1 ، drbg_pr_hmac_sha256 ، drbg_pr_hmac_sha384 ، drbg_pr_hmac_sha512 نعم تم إنشاء مثيل HMAC_DRBG باستخدام وظيفة التجزئة المسماة وتمكين مقاومة التنبؤ: تم تضمين عمليات التحقق من الصحة. يحصل مستخدمو هذه الواجهة على مثيلات DRBG الخاصة بهم.
stdrng drbg_nopr_hmac_sha1 ، drbg_nopr_hmac_sha256 ، drbg_nopr_hmac_sha384 ، drbg_nopr_hmac_sha512 نعم مثل خوارزميات drbg_pr_* ، ولكن مع تعطيل مقاومة التنبؤ. تتم مشاركة الكود مع المتغير المقاوم للتنبؤ. في إصدار kernel 5.10، يكون DRBG ذو الأولوية الأعلى هو drbg_nopr_hmac_sha256 . في إصدار kernel 5.15 والإصدارات الأحدث، يكون drbg_pr_hmac_sha512 .
jitterentropy_rng jitterentropy_rng لا الإصدار 2.2.0 من Jitter RNG : يحصل مستخدمو هذه الواجهة على مثيلات Jitter RNG الخاصة بهم. إنهم لا يعيدون استخدام المثيلات التي تستخدمها DRBGs.
xcbc(aes) xcbc-aes-neon ، xcbc-aes-ce لا
xctr(aes) xctr-aes-neon ، xctr-aes-ce لا موجود فقط في إصدار kernel 5.15 والإصدارات الأحدث.
cbcmac(aes) cbcmac-aes-neon ، cbcmac-aes-ce لا
essiv(cbc(aes),sha256) essiv-cbc-aes-sha256-neon ، essiv-cbc-aes-sha256-ce لا

بناء الوحدة من المصدر

بالنسبة لنظام التشغيل Android 14 أو الإصدارات الأحدث (بما في ذلك android-mainline )، أنشئ وحدة fips140.ko من المصدر باستخدام الأوامر التالية.

  • البناء مع بازل:

    tools/bazel run //common:fips140_dist
    
  • البناء باستخدام build.sh (القديم):

    BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh
    

تؤدي هذه الأوامر إنشاءًا كاملاً يتضمن النواة ووحدة fips140.ko مع محتويات خلاصة HMAC-SHA256 المضمنة فيها.

إرشادات المستخدم النهائي

توجيهات مسؤول التشفير

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

لا يمكن تثبيت وحدة kernel بشكل منفصل؛ يتم تضمينه كجزء من البرنامج الثابت للجهاز ويتم تحميله تلقائيًا عند التمهيد. إنه يعمل فقط في وضع التشغيل المعتمد.

يمكن لضابط التشفير أن يتسبب في تشغيل الاختبارات الذاتية في أي وقت عن طريق إعادة تشغيل الجهاز.

توجيه المستخدم

مستخدم وحدة kernel هو مكونات kernel الأخرى التي تحتاج إلى استخدام خوارزميات التشفير. لا توفر وحدة kernel منطقًا إضافيًا في استخدام الخوارزميات، ولا تخزن أي معلمات تتجاوز الوقت اللازم لإجراء عملية تشفير.

يقتصر استخدام الخوارزميات لأغراض التوافق مع FIPS على الخوارزميات المعتمدة. لتلبية متطلبات "مؤشر الخدمة" FIPS 140-3، توفر الوحدة وظيفة fips140_is_approved_service التي تشير إلى ما إذا كانت الخوارزمية قد تمت الموافقة عليها أم لا.

أخطاء الاختبار الذاتي

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


  1. من المتوقع أن تكون تطبيقات AES-GCM الخاصة بالوحدة "معتمدة من الخوارزمية" ولكن ليس "معتمدة من الوحدة". يمكن التحقق من صحتها، ولكن لا يمكن اعتبار AES-GCM خوارزمية معتمدة من وجهة نظر وحدة FIPS. وذلك لأن متطلبات الوحدة النمطية FIPS لـ GCM غير متوافقة مع تطبيقات GCM التي لا تقوم بإنشاء IVs الخاصة بها.