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

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

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

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

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

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

تتضمن واجهة برمجة التطبيقات 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. تتم ملاحظة الاختلافات بين إصدارات النواة (kernel) متى كان ذلك مناسبًا.

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

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

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

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

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

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

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

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