وحدة تشفير 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 من نفس 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.
• تُلغي الوحدة أيّ تصحيحات رمز أجراها kernel لميزة Dynamic Shadow Call Stack. وعلى وجه التحديد، تحل الوحدة محل أي تعليمات الدفع أو الفصل من حزمة استدعاءات الظل باستخدام رمز مصادقة المؤشر (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 من 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 من النواة والإصدارات الأعلى.
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 من 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 من kernel والإصدارات الأحدث.
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 تشير إلى ما إذا تمت الموافقة على إحدى الخوارزميات.

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

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