وحدة تشفير GKI المعتمدة على معيار FIPS 140-3

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

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

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

لماذا يتم استخدام وحدة نواة منفصلة

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

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

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

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

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

يحمل نواة GKI بحد ذاته رمزًا يعتمد على سلاسل العملات المشفَّرة المضمَّنة أيضًا في وحدة النواة 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" عند تشغيل الجهاز.

التحقّق الذاتي من السلامة

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

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

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

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

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

الخوارزميات المضمّنة في الوحدة

يتم سرد جميع الخوارزميات المضمّنة في وحدة FIPS 140-3 على النحو التالي. وينطبق ذلك على فروع النواة android12-5.10 وandroid13-5.10 وandroid13-5.15 وandroid14-5.15 وandroid14-6.1 وandroid15-6.6، مع أنّ الاختلافات بين إصدارات النواة تُلاحظ عند اللزوم.

خوارزمية عمليات التنفيذ مقبولة التعريف
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: في الإصدار 6.1 من kernel والإصدارات الأقدم، يتم دعم جميع أحجام مفاتيح AES، أما في الإصدار 6.6 والأحدث من النواة، فلا يتم دعم سوى AES-128 وAES-256. يمكن إنشاء نموذج xts مع أي تنفيذ لـ ecb(aes) باستخدام xts(<ecb(aes)-impl>). وهناك عمليات تنفيذ أخرى مستقلة. تنفِّذ جميع عمليات التنفيذ فحص المفتاح الضعيف المطلوبة بواسطة بروتوكول FIPS، أي مفاتيح XTS التي يتساوى نصفها الأول والثاني.
gcm(aes) gcm (نموذج)، gcm-aes-ce رقم1 AES-GCM: تتوفّر جميع أحجام مفاتيح AES. يتوافق هذا التنسيق مع ملفات IV ذات الإصدار 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
sha3-224 sha3-224-generic نعم دالة التجزئة المشفرة SHA3-224. لا تتوفّر هذه الميزة إلا في الإصدار 6.6 من النواة والإصدارات الأعلى.
sha3-256 sha3-256-generic نعم مثل ما سبق، ولكن مع طول ملخص 256 بت (SHA3-256). تستخدم جميع أطوال الملخصات طريقة Keccak نفسها.
sha3-384 sha3-384-generic نعم مثل ما سبق، ولكن مع طول ملخص 384 بت (SHA3-384). تستخدم جميع أطوال الملخصات طريقة Keccak نفسها.
sha3-512 sha3-512-generic نعم مثل ما سبق، ولكن مع طول ملخص 512 بت (SHA3-512). تستخدم جميع أطوال الملخصات طريقة Keccak نفسها.
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_*، ولكن مع إيقاف مقاومة التوقّع. تتم مشاركة الرمز مع الصيغة المقاومة للتوقّع. في الإصدار 5.10 من النواة، تكون قيمة DRBG ذات الأولوية القصوى هي drbg_nopr_hmac_sha256. في الإصدار 5.15 من النواة والإصدارات الأحدث، هذه القيمة هي drbg_pr_hmac_sha512.
jitterentropy_rng jitterentropy_rng لا Jitter RNG، إمّا الإصدار 2.2.0 (النواة 6.1 والإصدارات الأقدم) أو الإصدار 3.4.0 (النواة الإصدار 6.6 والإصدارات الأحدث). يحصل مستخدمو هذه الواجهة على مثيلات Jitter RNG الخاصة بهم. ولا تعيد استخدام المثيلات التي تستخدمها ألعاب DRBG.
xcbc(aes) xcbc-aes-neon، xcbc-aes-ce لا
xctr(aes) xctr-aes-neon، xctr-aes-ce لا لا تتوفّر هذه الميزة إلا في الإصدار 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 من المصدر باستخدام الأوامر التالية.

  • الإنشاء باستخدام Bazel:

    tools/bazel run //common:fips140_dist

  • الإصدار باستخدام "build.sh" (الإصدار القديم):

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

تنفِّذ هذه الأوامر عملية إنشاء كاملة، بما في ذلك النواة kernel ووحدة fips140.ko التي تتضمّن محتوى ملخّص HMAC-SHA256.

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

إرشادات مسؤولي التشفير

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

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

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

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

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

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

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

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

  1. من المتوقّع أن تكون عمليات تنفيذ AES-GCM للوحدة "مقبولة باستخدام الخوارزمية" ولكن ليس "معتمدة على الوحدة". يمكن التحقق من صحتها، ولكن لا يمكن اعتبار AES-GCM خوارزمية معتمدة من وجهة نظر وحدة FIPS. ويرجع ذلك إلى أن متطلبات وحدة بروتوكول معالجة المعلومات (FIPS) في GCM غير متوافقة مع عمليات تنفيذ GCM التي لا تنشئ عناصر IV الخاصة بها.↩