وحدة تشفير 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 كانت شرطًا أساسيًا لاستخدام ميزة سلامة تدفق التحكّم التي تشكّل ميزة أمان مهمة.

لذلك، يتم تجميع كل التعليمات البرمجية التي تخضع لمتطلبات 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. يؤدي ذلك إلى نسخ الوحدة إلى ذاكرة الوصول العشوائي (RAM) الخاصة بالمورِّد.
• أضِف اسم الوحدة إلى BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD. يؤدي ذلك إلى إضافة اسم الوحدة إلى modules.load في الهدف. يحتوي modules.load على قائمة بالوحدات التي يحمّلها init عند التمهيد للجهاز.

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

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

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

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

يجب أن تُجري أي خوارزميات مُطبَّقة تخضع لمتطلبات FIPS 140-3 اختبارًا ذاتيًا للإجابة المعروفة قبل استخدامها. وفقًا لـ FIPS 140-3 إرشادات التنفيذ 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 من kernel والإصدارات الأحدث، تكون فقط 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 من kernel والإصدارات الأحدث.
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_*، ولكن مع إيقاف ميزة "مقاومة التوقّعات". تتم مشاركة الرمز مع السعر المتغير المقاوم للتوقّعات. في إصدار kernel 5.10، يكون معرّف DRBG drbg_nopr_hmac_sha256 هو الأعلى أولوية. في الإصدار 5.15 من kernel والإصدارات الأحدث، يكون drbg_pr_hmac_sha512.
jitterentropy_rng	jitterentropy_rng	لا	Jitter RNG، إما الإصدار 2.2.0 (الإصدار 6.1 من kernel والإصدارات الأقدم) أو الإصدار 3.4.0 (الإصدار 6.6 من kernel والإصدارات الأحدث) يحصل مستخدمو هذه الواجهة على نُسخ 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	لا

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

بالنسبة إلى الإصدار 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 تلقائيًا مع ذلك باستخدام أجهزة إدارة الذاكرة في المعالج.

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

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

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

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

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

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

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