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

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

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

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

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

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

من المفترض أن يتم تحديث نواة GKI بانتظام خلال فترة الحياة المدعومة بالكامل. هذا يجعل من غير المجدي أن تكون النواة بأكملها ضمن حدود وحدة FIPS ، حيث تحتاج هذه الوحدة إلى إعادة اعتمادها عند كل تحديث لـ kernel. أيضًا ، يتم تجميع GKI مع تمكين LTO (تحسين وقت الارتباط) ، نظرًا لأن LTO شرط أساسي لـ CFI وهي ميزة أمان مهمة. هذا يجعل من غير المجدي رسم حدود وحدة FIPS حول رمز تشفير kernel فقط ، لأن هذا الرمز ليس في موقع محدد بوضوح في الملف الثنائي الناتج. قد تغير تحديثات Kernel أيضًا كود التشفير.

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

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

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

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

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

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

يتم سرد جميع الخوارزميات المضمنة في الوحدة النمطية FIPS 140-3 عند إنشائها من مصادر android13-5.10 على النحو التالي.

الخوارزمية	تطبيقات	مقبول	تعريف
aes	aes-generic ، aes-arm64 ، aes 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 مدعومة. يتم دعم 96 بت IVs فقط. كما هو الحال مع جميع أوضاع AES الأخرى في هذه الوحدة ، يكون المتصل مسؤولاً عن توفير IVs. يمكن تكوين قالب 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 -Hash): يمكن تكوين قالب 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_* ، ​​ولكن مع تعطيل مقاومة التنبؤ. تتم مشاركة الكود مع المتغير المقاوم للتنبؤ. أعلى أولوية DRBG هي drbg_nopr_hmac_sha256 .
jitterentropy_rng	jitterentropy_rng	رقم	الإصدار 2.2.0 من Jitter RNG : يحصل مستخدمو هذه الواجهة على مثيلات Jitter RNG الخاصة بهم. لا يعيدون استخدام الحالات التي تستخدمها DRBG.
xcbc(aes)	xcbc-aes-neon ، xcbc-aes-ce	رقم
cbcmac(aes)	cbcmac-aes-neon ، cbcmac-aes-ce	رقم
essiv(cbc(aes),sha256)	essiv-cbc-aes-sha256-neon ، essiv-cbc-aes-sha256-ce	رقم

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

يمكن إنشاء الوحدة النمطية fips140.ko من مصادر نواة GKI باستخدام الأمر التالي:

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

يؤدي هذا إلى الإنشاء الكامل مع kernel والوحدة النمطية fips140.ko ، مع ملخص HMAC-SHA256 الصحيح لمحتوياته المضمنة.

في Android 14 (AOSP تجريبي) والإصدارات الأحدث ، قم بالبناء باستخدام Bazel بدلاً من build/build.sh باستخدام الأمر التالي:

tools/bazel run //common:fips140_dist

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

توجيه موظف التشفير

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

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

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

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

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

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

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

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