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

لذلك، يتم تجميع كل الرموز التي تغطيها متطلبات 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. يؤدي ذلك إلى نسخ الوحدة إلى ramdisk المورِّد.
• أضِف اسم الوحدة إلى 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 اختبارًا ذاتيًا للإجابات المعروفة قبل استخدامها. وفقًا لإرشادات التنفيذ 10.3.A لمعيار FIPS 140-3، يكفي استخدام متجه اختبار واحد لكل خوارزمية باستخدام أي من أطوال المفاتيح المتوافقة معها، ما دام قد تم اختبار كل من التشفير وفك التشفير.

تتضمّن واجهة برمجة التطبيقات CryptoAPI في Linux مفهوم أولويات الخوارزميات، حيث يمكن أن تتوفّر عدة عمليات تنفيذ (مثل عملية تستخدم تعليمات تشفير خاصة، وعملية احتياطية لوحدات المعالجة المركزية التي لا تنفّذ هذه التعليمات) للخوارزمية نفسها. لذلك، يجب اختبار جميع عمليات تنفيذ الخوارزمية نفسها. وهذا ضروري لأنّ واجهة برمجة التطبيقات 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 والإصدارات الأقدم من النواة، تتوافق جميع أحجام مفاتيح 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. يُسمح فقط باستخدام متجهات تهيئة بحجم 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	لا	مولّد الأرقام العشوائية المستند إلى التشويش، إما الإصدار 2.2.0 (إصدار النواة 6.1 والإصدارات الأقدم) أو الإصدار 3.4.0 (إصدار النواة 6.6 والإصدارات الأحدث) يحصل مستخدمو هذه الواجهة على مثيلات Jitter RNG الخاصة بهم. ولا يعيدون استخدام الحالات التي تستخدمها مولّدات الأرقام العشوائية المحدّدة.
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

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

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

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

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

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

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

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

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

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

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

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