FIPS 140-3 सर्टिफ़िकेट वाला GKI क्रिप्टो मॉड्यूल

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

GKI के कर्नेल में fips140.ko नाम का एक Linux कर्नेल मॉड्यूल शामिल है. यह क्रिप्टोग्राफ़िक सॉफ़्टवेयर मॉड्यूल के लिए, FIPS 140-3 की ज़रूरी शर्तों का पालन करता है. अगर GKI कर्नेल वाले प्रॉडक्ट के लिए एफ़आईपीएस सर्टिफ़िकेट की ज़रूरत है, तो इस मॉड्यूल को सबमिट किया जा सकता है.

क्रिप्टो रूटीन का इस्तेमाल करने से पहले, एफ़आईपीएस 140-3 की इन ज़रूरी शर्तों को पूरा करना ज़रूरी है:

• क्रिप्टोग्राफ़िक एल्गोरिदम उपलब्ध कराने से पहले, मॉड्यूल को अपनी पूरी सुरक्षा की जांच करनी चाहिए.
• मॉड्यूल को, मंज़ूरी पा चुके क्रिप्टोग्राफ़िक एल्गोरिदम को उपलब्ध कराने से पहले, उन्हें इस्तेमाल करना होगा और उनकी पुष्टि करनी होगी. इसके लिए, मॉड्यूल को पहले से पता होने वाले जवाबों का इस्तेमाल करके, अपने-आप होने वाली जांच करनी होगी.

अलग कर्नेल मॉड्यूल क्यों

एफ़आईपीएस 140-3 की पुष्टि इस आधार पर की जाती है कि सॉफ़्टवेयर या हार्डवेयर पर आधारित मॉड्यूल को सर्टिफ़ाइड करने के बाद, उसमें कभी बदलाव नहीं किया जाता. अगर कोई बदलाव किया जाता है, तो उसे फिर से प्रमाणित करना होगा. यह आज इस्तेमाल में आने वाली सॉफ़्टवेयर डेवलपमेंट प्रोसेस से आसानी से मेल नहीं खाता. इस ज़रूरी शर्त के तहत, एफ़आईपीएस सॉफ़्टवेयर मॉड्यूल को आम तौर पर क्रिप्टोग्राफ़िक कॉम्पोनेंट पर ज़्यादा से ज़्यादा फ़ोकस करने के लिए डिज़ाइन किया जाता है. इससे यह पक्का किया जा सकता है कि क्रिप्टोग्राफ़ी से जुड़े बदलावों के लिए, क्रिप्टोग्राफ़ी की फिर से जांच करने की ज़रूरत न पड़े.

GKI कर्नेल को, काम करने के दौरान नियमित तौर पर अपडेट किया जाता है. इस वजह से, पूरे कर्नेल को एफ़आईपीएस मॉड्यूल की सीमा के अंदर रखना मुमकिन नहीं है. ऐसा इसलिए, क्योंकि हर कर्नेल अपडेट के बाद, ऐसे मॉड्यूल को फिर से सर्टिफ़ाइड करना होगा. "FIPS मॉड्यूल" को कर्नेल इमेज के सबसेट के तौर पर तय करने से, इस समस्या को कम किया जा सकता है, लेकिन इसे ठीक नहीं किया जा सकता. ऐसा इसलिए, क्योंकि "FIPS मॉड्यूल" के बाइनरी कॉन्टेंट में अब भी ज़रूरत से ज़्यादा बार बदलाव होगा.

कर्नेल के वर्शन 6.1 से पहले, 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 में मॉड्यूल का नाम जोड़ें. इससे मॉड्यूल को वेंडर की रैमडिस्क में कॉपी किया जाता है.
• BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD में मॉड्यूल का नाम जोड़ें. इससे, टारगेट पर modules.load में मॉड्यूल का नाम जुड़ जाता है. modules.load में उन मॉड्यूल की सूची होती है जिन्हें डिवाइस के बूट होने पर, init लोड करता है.

इंटिग्रिटी की जांच

FIPS 140-3 कर्नेल मॉड्यूल, मॉड्यूल लोड होने के समय अपने .code और .rodata सेक्शन का HMAC-SHA256 डाइजेस्ट लेता है और उसकी तुलना, मॉड्यूल में रिकॉर्ड किए गए डाइजेस्ट से करता है. यह तब होता है, जब Linux मॉड्यूल लोडर ने पहले से ही सामान्य बदलाव कर लिए हों. जैसे, ELF को दूसरी जगह ले जाने की प्रोसेस और उन सेक्शन में सीपीयू की गड़बड़ियों के लिए, वैकल्पिक पैच करना. डाइजेस्ट को सही तरीके से फिर से बनाया जा सके, यह पक्का करने के लिए ये अतिरिक्त चरण अपनाए जाते हैं:

• ELF रिलोकेशन को मॉड्यूल में सेव किया जाता है, ताकि उन्हें एचएमएसी के इनपुट के उलट तरीके से लागू किया जा सके.
• यह मॉड्यूल, डाइनैमिक शैडो कॉल स्टैक के लिए, कर्नेल के बनाए गए सभी कोड पैच को हटा देता है. खास तौर पर, यह मॉड्यूल उन सभी निर्देशों को बदल देता है जो शैडो कॉल स्टैक से पुश या पॉप किए जाते हैं. साथ ही, उन्हें मूल रूप से मौजूद पॉइंटर ऑथेंटिकेशन कोड (पीएसी) निर्देशों से बदल देता है.
• मॉड्यूल के लिए, कोड की अन्य सभी पैचिंग बंद कर दी जाती है. इनमें स्टैटिक पासकोड और ट्रैसपॉइंट के साथ-साथ वेंडर हुक भी शामिल हैं.

पहले से जवाब पता होने पर, खुद से टेस्ट करना

लागू किए गए ऐसे सभी एल्गोरिदम जिन्हें एफ़आईपीएस 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: एईएस की सभी कुंजियों के साइज़ काम करते हैं. cmac टेंप्लेट को cmac(<aes-impl>) का इस्तेमाल करके, aes के किसी भी तरीके से बनाया जा सकता है. अन्य लागू करने के तरीके, अलग-अलग होते हैं.
ecb(aes)	ecb (टेंप्लेट), ecb-aes-neon, ecb-aes-neonbs, ecb-aes-ce	हां	AES-ECB: एईएस की सभी कुंजियों के साइज़ काम करते हैं. ecb टेंप्लेट को ecb(<aes-impl>) का इस्तेमाल करके, aes के किसी भी तरीके से बनाया जा सकता है. अन्य लागू करने के तरीके, अलग-अलग होते हैं.
cbc(aes)	cbc (टेंप्लेट), cbc-aes-neon, cbc-aes-neonbs, cbc-aes-ce	हां	AES-CBC: एईएस की सभी कुंजियों के साइज़ काम करते हैं. cbc टेंप्लेट को ctr(<aes-impl>) का इस्तेमाल करके, aes के किसी भी तरीके से बनाया जा सकता है. अन्य लागू करने के तरीके, अलग-अलग होते हैं.
cts(cbc(aes))	cts (टेंप्लेट), cts-cbc-aes-neon, cts-cbc-aes-ce	हां	AES-CBC-CTS या AES-CBC with ciphertext stealing: इसमें इस्तेमाल किया गया कन्वेंशन CS3 है. इसमें, आखिरी दो सिफरटेक्स्ट ब्लॉक को बिना किसी शर्त के स्वैप किया जाता है. AES की सभी साइज़ का इस्तेमाल किया जा सकता है. cts टेंप्लेट को cts(<cbc(aes)-impl>) का इस्तेमाल करके, cbc के किसी भी तरीके से बनाया जा सकता है. अन्य लागू करने के तरीके, अलग-अलग होते हैं.
ctr(aes)	ctr (टेंप्लेट), ctr-aes-neon, ctr-aes-neonbs, ctr-aes-ce	हां	AES-CTR: एईएस की सभी साइज़ की कुंजियां इस्तेमाल की जा सकती हैं. ctr टेंप्लेट को ctr(<aes-impl>) का इस्तेमाल करके, aes के किसी भी तरीके से बनाया जा सकता है. अन्य लागू करने के तरीके, अलग-अलग होते हैं.
xts(aes)	xts (टेंप्लेट), xts-aes-neon, xts-aes-neonbs, xts-aes-ce	हां	AES-XTS: कर्नेल के 6.1 और उससे पहले के वर्शन में, एईएस की सभी कुंजियों के साइज़ काम करते हैं. कर्नेल के 6.6 और उसके बाद के वर्शन में, सिर्फ़ AES-128 और AES-256 काम करते हैं. xts टेंप्लेट को xts(<ecb(aes)-impl>) का इस्तेमाल करके, ecb(aes) के किसी भी तरीके से बनाया जा सकता है. अन्य लागू करने के तरीके, अलग-अलग होते हैं. सभी लागू करने के तरीके, एफ़आईपीएस के मुताबिक कमजोर कुंजी की जांच करते हैं. इसका मतलब है कि XTS कुंजियों के पहले और दूसरे आधे हिस्से के बराबर होने पर, उन्हें अस्वीकार कर दिया जाता है.
gcm(aes)	gcm (टेंप्लेट), gcm-aes-ce	नंबर1	AES-GCM: एईएस की सभी साइज़ की कुंजियां इस्तेमाल की जा सकती हैं. सिर्फ़ 96-बिट आईवी का इस्तेमाल किया जा सकता है. इस मॉड्यूल में मौजूद अन्य सभी AES मोड की तरह ही, आईवी देने की ज़िम्मेदारी कॉलर की होती है. gcm टेंप्लेट को gcm_base(<ctr(aes)-impl>,<ghash-impl>) का इस्तेमाल करके, ctr(aes) और ghash के किसी भी तरीके से बनाया जा सकता है. अन्य लागू करने के तरीके, अलग-अलग होते हैं.
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 क्रिप्टोग्राफ़िक हैश फ़ंक्शन: स्टैंडर्ड CryptoAPI इंटरफ़ेस के अलावा, SHA-256 के लिए एक लाइब्रेरी इंटरफ़ेस भी उपलब्ध कराया जाता है. इस लाइब्रेरी इंटरफ़ेस में, अलग तरीके का इस्तेमाल किया जाता है.
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 (Keyed-Hash Message Authentication Code): 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 का इस्तेमाल किया जाता है: इसमें हेल्थ जांच शामिल होती है. इस इंटरफ़ेस के उपयोगकर्ताओं को अपने डीआरबीजी इंस्टेंस मिलते हैं.
stdrng	drbg_nopr_hmac_sha1, drbg_nopr_hmac_sha256, drbg_nopr_hmac_sha384, drbg_nopr_hmac_sha512	हां	drbg_pr_* एल्गोरिदम की तरह ही, लेकिन अनुमान लगाने की सुविधा बंद है. कोड को, अनुमान लगाने से रोकने वाले वैरिएंट के साथ शेयर किया जाता है. कर्नेल वर्शन 5.10 में, सबसे ज़्यादा प्राथमिकता वाला डीआरबीजी 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 इंस्टेंस मिलते हैं. ये उन इंस्टेंस का फिर से इस्तेमाल नहीं करते जिनका इस्तेमाल डीआरबीजी करते हैं.
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

ये निर्देश, कर्नेल और fips140.ko मॉड्यूल के साथ-साथ, उसमें एम्बेड किए गए HMAC-SHA256 डाइजेस्ट कॉन्टेंट का पूरा बिल्ड करते हैं.

असली उपयोगकर्ता के लिए दिशा-निर्देश

क्रिप्टो ऑफ़िसर के लिए दिशा-निर्देश

कर्नेल मॉड्यूल को चलाने के लिए, ऑपरेटिंग सिस्टम को ऑपरेशन के एक ऑपरेटर मोड पर सीमित रखना होगा. प्रोसेसर में मेमोरी मैनेजमेंट हार्डवेयर का इस्तेमाल करके, Android इसे अपने-आप मैनेज करता है.

कर्नेल मॉड्यूल को अलग से इंस्टॉल नहीं किया जा सकता. इसे डिवाइस के फ़र्मवेयर के हिस्से के तौर पर शामिल किया जाता है और यह बूट होने पर अपने-आप लोड होता है. यह सिर्फ़ अनुमति वाले मोड में काम करता है.

क्रिप्टो ऑफ़िसर, डिवाइस को रीस्टार्ट करके, कभी भी डिवाइस की जांच कर सकता है.

उपयोगकर्ता के लिए दिशा-निर्देश

कर्नेल मॉड्यूल के उपयोगकर्ता, कर्नेल के ऐसे अन्य कॉम्पोनेंट होते हैं जिन्हें क्रिप्टोग्राफ़िक एल्गोरिदम का इस्तेमाल करना होता है. कर्नेल मॉड्यूल, एल्गोरिदम के इस्तेमाल में कोई अतिरिक्त लॉजिक नहीं देता. साथ ही, क्रिप्टोग्राफ़िक ऑपरेशन करने के लिए ज़रूरी समय के बाद, कोई पैरामीटर सेव नहीं करता.

एल्गोरिदम का इस्तेमाल, एफ़आईपीएस के मुताबिक काम करने के लिए सिर्फ़ मंज़ूरी पा चुके एल्गोरिदम के लिए किया जा सकता है. FIPS 140-3 "सेवा सूचक" की ज़रूरी शर्त को पूरा करने के लिए, मॉड्यूल में एक फ़ंक्शन fips140_is_approved_service दिया गया है. इससे पता चलता है कि किसी एल्गोरिदम को मंज़ूरी मिली है या नहीं.

सेल्फ़ टेस्ट से जुड़ी गड़बड़ियां

अगर सेल्फ़ टेस्ट पूरा नहीं हो पाता है, तो कर्नेल मॉड्यूल की वजह से कर्नेल में पैनिक मोड चालू हो जाता है और डिवाइस बूट नहीं होता. अगर डिवाइस को रीबूट करने से समस्या हल नहीं होती है, तो डिवाइस को री-फ़्लैश करके समस्या ठीक करने के लिए, उसे रिकवरी मोड में बूट करना होगा.