وحدة تشفير 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 من النواة، كان هناك اعتبار آخر وهو أنّ صورة النواة العامة (GKI) تم تجميعها مع تفعيل ميزة تحسين وقت الربط (LTO)، لأنّ ميزة تحسين وقت الربط (LTO) كانت شرطًا أساسيًا لميزة سلامة تدفق التحكّم (CFI) التي تُعد ميزة أمان مهمة.

لذلك، يتم تجميع كل الرموز البرمجية التي تغطيها متطلبات FIPS 140-3 في وحدة نمطية منفصلة للنواة fips140.ko لا تعتمد إلا على الواجهات الثابتة التي يعرضها مصدر صورة النواة العامة (GKI) الذي تم إنشاؤها منه. ويعني ذلك أنّه يمكن استخدام الوحدة النمطية مع إصدارات مختلفة من صورة النواة العامة (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 وتصحيح الأخطاء البديلة في وحدة المعالجة المركزية. يتم اتّخاذ الخطوات الإضافية التالية لضمان إمكانية إعادة إنتاج الملخّص بشكل صحيح:

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

الاختبارات الذاتية لخوارزميات التشفير

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

بشكل عام، لا يلزم سوى متّجه اختبار واحد لكل خوارزمية. تم تصميم الاختبارات الذاتية لخوارزميات التشفير في FIPS للتحقّق من الوظائف الأساسية فقط. يتم إجراء اختبار شامل بشكل منفصل باستخدام برنامج التحقّق من صحة خوارزمية التشفير (CAVP) ومجموعة اختبارات التشفير في النواة الرئيسية.

عندما يكون للخوارزمية عمليات تنفيذ متعددة يمكن للمستخدم الوصول إليها أو تستخدمها خدمات الوحدة النمطية، يتطلب FIPS 140-3 إجراء اختبار ذاتي لجميع عمليات التنفيذ هذه. وينطبق ذلك على استراتيجية التكامل التي تستخدمها عادةً واجهة Linux CryptoAPI، حيث يمكن أن يكون لكل خوارزمية عمليات تنفيذ متعددة يمكن للمستخدم الوصول إليها. على سبيل المثال، في النواة android16-6.12، تتضمّن خوارزمية SHA-256 ثلاث عمليات تنفيذ: sha256-generic وsha256-arm64 وsha256-ce. على وحدات المعالجة المركزية التي تتضمّن إضافات التشفير ARMv8، يتم استخدام sha256-ce تلقائيًا، ولكن لا يزال بإمكان المستخدمين الوصول إلى العمليات الأخرى بشكل صريح. لذلك، تجري الوحدة النمطية اختبارات ذاتية لجميع عمليات التنفيذ الثلاث.

في النواة android17-6.18 والإصدارات الأحدث، تستخدم بعض الخوارزميات استراتيجية تكامل أبسط. على سبيل المثال، في النواة android17-6.18، تتضمّن خوارزمية SHA-256 عملية تنفيذ واحدة sha256-lib تختار تلقائيًا الرمز البرمجي المناسب لوحدة المعالجة المركزية في وقت تحميل الوحدة النمطية. لذلك، تجري الوحدة النمطية اختبارًا ذاتيًا لـ sha256-lib فقط.

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

في ما يلي قائمة بجميع الخوارزميات المضمّنة في الوحدة النمطية FIPS 140-3. ينطبق ذلك على فروع النواة android12-5.10 وandroid13-5.10 وandroid13-5.15 وandroid14-5.15 وandroid14-6.1 وandroid15-6.6 وandroid16-6.12 وandroid17-6.18، على الرغم من الإشارة إلى الاختلافات بين إصدارات النواة عند الاقتضاء.

خوارزمية	عمليات التنفيذ	قابلة للموافقة	التعريف
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(). عمليات التنفيذ الأخرى مستقلة.
ecb(aes)	ecb (النموذج) وecb-aes-neon وecb-aes-neonbs وecb-aes-ce	نعم	AES-ECB: تتوافق هذه الخوارزمية مع جميع أحجام مفاتيح AES. يمكن دمج النموذج ecb مع أي عملية تنفيذ لـ aes باستخدام ecb(). عمليات التنفيذ الأخرى مستقلة.
cbc(aes)	cbc (النموذج) وcbc-aes-neon وcbc-aes-neonbs وcbc-aes-ce	نعم	AES-CBC: تتوافق هذه الخوارزمية مع جميع أحجام مفاتيح AES. يمكن دمج النموذج cbc مع أي عملية تنفيذ لـ aes باستخدام cbc(). عمليات التنفيذ الأخرى مستقلة.
cts(cbc(aes))	cts (النموذج) وcts-cbc-aes-neon وcts-cbc-aes-ce	نعم	AES-CBC-CTS أو AES-CBC مع سرقة النص المشفّر: الاتفاقية المستخدَمة هي CS3، ويتم تبديل آخر كتلتَين من النص المشفّر بدون شروط. تتوافق هذه الخوارزمية مع جميع أحجام مفاتيح AES. يمكن دمج النموذج cts مع أي عملية تنفيذ لـ cbc باستخدام cts(). عمليات التنفيذ الأخرى مستقلة.
ctr(aes)	ctr (النموذج) وctr-aes-neon وctr-aes-neonbs وctr-aes-ce	نعم	AES-CTR: تتوافق هذه الخوارزمية مع جميع أحجام مفاتيح AES. يمكن دمج النموذج ctr مع أي عملية تنفيذ لـ aes باستخدام ctr(). عمليات التنفيذ الأخرى مستقلة.
xts(aes)	xts (النموذج) وxts-aes-neon وxts-aes-neonbs وxts-aes-ce	نعم	AES-XTS: في الإصدار 6.1 من النواة والإصدارات الأقدم، تتوافق هذه الخوارزمية مع جميع أحجام مفاتيح AES، وفي الإصدار 6.6 من النواة والإصدارات الأحدث، تتوافق مع AES-128 وAES-256 فقط. يمكن دمج النموذج xts مع أي عملية تنفيذ لـ ecb(aes) باستخدام xts(). عمليات التنفيذ الأخرى مستقلة. تنفّذ جميع عمليات التنفيذ عملية فحص المفتاح الضعيف المطلوبة بموجب FIPS، أي يتم رفض مفاتيح XTS التي يكون النصفان الأول والثاني منها متساويَين.
gcm(aes)	gcm (النموذج) وgcm-aes-ce	لا 1	AES-GCM: تتوافق هذه الخوارزمية مع جميع أحجام مفاتيح AES. لا تتوافق هذه الخوارزمية إلا مع متجهات التهيئة (IV) التي تبلغ 96 بت. كما هو الحال مع جميع أوضاع AES الأخرى في هذه الوحدة النمطية، يكون المتصل مسؤولاً عن توفير متجهات التهيئة. يمكن دمج النموذج gcm مع أي عمليات تنفيذ لـ ctr(aes) وghash باستخدام gcm_base(,). عمليات التنفيذ الأخرى مستقلة.
sha1	الإصدار 6.12 من النواة والإصدارات الأقدم: sha1-generic وsha1-ce	نعم	دالة التجزئة التشفيرية SHA-1 تمت إزالة هذه الخوارزمية في الإصدار 6.18 من النواة والإصدارات الأحدث.
sha224	الإصدار 6.18 من النواة والإصدارات الأحدث: sha224-lib الإصدار 6.12 من النواة والإصدارات الأقدم: sha224-generic وsha224-arm64 وsha224-ce	نعم	دالة التجزئة التشفيرية SHA-224: تتم مشاركة الرمز البرمجي مع SHA-256.
sha256	الإصدار 6.18 من النواة والإصدارات الأحدث: sha256-lib الإصدار 6.12 من النواة والإصدارات الأقدم: sha256-generic وsha256-arm64 وsha256-ce ومكتبة SHA-256	نعم	دالة التجزئة التشفيرية SHA-256
sha384	الإصدار 6.18 من النواة والإصدارات الأحدث: sha384-lib الإصدار 6.12 من النواة والإصدارات الأقدم: sha384-generic وsha384-arm64 وsha384-ce	نعم	دالة التجزئة التشفيرية SHA-384: تتم مشاركة الرمز البرمجي مع SHA-512.
sha512	الإصدار 6.18 من النواة والإصدارات الأحدث: sha512-lib الإصدار 6.12 من النواة والإصدارات الأقدم: sha512-generic وsha512-arm64 وsha512-ce	نعم	دالة التجزئة التشفيرية SHA-512
sha3-224	الإصدار 6.6 من النواة والإصدارات الأحدث: sha3-224-generic	نعم	دالة التجزئة التشفيرية SHA3-224
sha3-256	الإصدار 6.6 من النواة والإصدارات الأحدث: sha3-256-generic	نعم	هذه الخوارزمية هي نفسها الخوارزمية السابقة، ولكن مع طول ملخّص يبلغ 256 بت (SHA3-256). تستخدم جميع أطوال الملخّص عملية تنفيذ Keccak نفسها.
sha3-384	الإصدار 6.6 من النواة والإصدارات الأحدث: sha3-384-generic	نعم	هذه الخوارزمية هي نفسها الخوارزمية السابقة، ولكن مع طول ملخّص يبلغ 384 بت (SHA3-384). تستخدم جميع أطوال الملخّص عملية تنفيذ Keccak نفسها.
sha3-512	الإصدار 6.6 من النواة والإصدارات الأحدث: sha3-512-generic	نعم	هذه الخوارزمية هي نفسها الخوارزمية السابقة، ولكن مع طول ملخّص يبلغ 512 بت (SHA3-512). تستخدم جميع أطوال الملخّص عملية تنفيذ Keccak نفسها.
hmac	hmac (النموذج)	نعم	رمز مصادقة الرسالة المستند إلى التجزئة والمشفّر بمفتاح (HMAC): يمكن دمج النموذج hmac مع أي خوارزمية SHA أو عملية تنفيذ باستخدام hmac() أو hmac().
stdrng	جميع النواة: drbg_pr_hmac_sha256 وdrbg_pr_hmac_sha384 وdrbg_pr_hmac_sha512 الإصدار 6.6 من النواة والإصدارات الأقدم: drbg_pr_hmac_sha1	نعم	HMAC_DRBG الذي تم إنشاؤه باستخدام دالة التجزئة المُسمّاة مع تفعيل ميزة مقاومة التنبؤ: يتم تضمين عمليات التحقّق من الحالة. يحصل مستخدمو هذه الواجهة على مثيلات DRBG الخاصة بهم.
stdrng	جميع النواة: drbg_nopr_hmac_sha256 وdrbg_nopr_hmac_sha384 وdrbg_nopr_hmac_sha512 الإصدار 6.6 من النواة والإصدارات الأقدم: drbg_nopr_hmac_sha1	نعم	هذه الخوارزمية هي نفسها خوارزميات drbg_pr_*، ولكن مع إيقاف ميزة مقاومة التنبؤ. تتم مشاركة الرمز البرمجي مع الإصدار المقاوم للتنبؤ. في الإصدار 5.10 من النواة، يكون DRBG ذو الأولوية القصوى هو drbg_nopr_hmac_sha256. في الإصدار 5.15 من النواة والإصدارات الأحدث، يكون drbg_pr_hmac_sha512.
jitterentropy_rng	jitterentropy_rng	لا	مولّد الأرقام العشوائية Jitter، إما الإصدار 2.2.0 (الإصدار 6.1 من النواة والإصدارات الأقدم) أو الإصدار 3.4.0 (الإصدار 6.6 من النواة والإصدارات الأحدث) يحصل مستخدمو هذه الواجهة على مثيلات مولّد الأرقام العشوائية Jitter الخاصة بهم. ولا يعيدون استخدام المثيلات التي تستخدمها DRBG.
xcbc(aes)	xcbc-aes-neon وxcbc-aes-ce	لا
xctr(aes)	الإصدار 5.15 من النواة والإصدارات الأحدث: xctr-aes-neon وxctr-aes-ce	لا
cbcmac(aes)	cbcmac-aes-neon وcbcmac-aes-ce	لا
essiv(cbc(aes),sha256)	essiv-cbc-aes-sha256-neon وessiv-cbc-aes-sha256-ce	لا

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

إنشاء الوحدة النمطية من المصدر

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

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

  tools/bazel run //common:fips140_dist

• الإنشاء باستخدام build.sh (قديم):

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

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

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

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

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

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

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

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

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

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

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

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