एफ़आईपीएस 140-3 सर्टिफ़ाइड जीकेआई क्रिप्टो मॉड्यूल

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 के कर्नेल में भी कोड होता है, जो क्रिप्टो रूटीन पर निर्भर करता है. ये रूटीन, FIPS 140-3 कर्नेल मॉड्यूल में भी पैकेज किए जाते हैं. इसलिए, पहले से मौजूद क्रिप्टो रूटीन को GKI कर्नेल से बाहर नहीं भेजा जाता, बल्कि उन्हें मॉड्यूल में कॉपी किया जाता है. मॉड्यूल लोड होने के बाद, बिल्ट-इन क्रिप्टो रूटीन को Linux क्रिप्टोएपीआई से डी-रजिस्टर किया जाता है और मॉड्यूल में ले जाने वाले इनकी जगह ले ली जाती है.

इसका मतलब है कि 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 को दूसरी जगह ले जाना और उन सेक्शन में सीपीयू की गड़बड़ियों को ठीक करने के लिए, वैकल्पिक पैच करना. डाइजेस्ट को सही तरीके से फिर से बनाया जा सके, यह पक्का करने के लिए ये अतिरिक्त चरण अपनाए जाते हैं:

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

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

लागू किए गए ऐसे सभी एल्गोरिदम जिन्हें एफ़आईपीएस 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(<aes-impl>) का इस्तेमाल करके, cmac टेंप्लेट को aes को लागू करके बनाया जा सकता है. अन्य तरीके, स्टैंडअलोन होते हैं.
ecb(aes)	ecb (टेंप्लेट), ecb-aes-neon, ecb-aes-neonbs, ecb-aes-ce	हां	AES-ECB: एईएस की सभी कुंजियों के साइज़ काम करते हैं. ecb(<aes-impl>) का इस्तेमाल करके, ecb टेंप्लेट को aes को लागू करके बनाया जा सकता है. अन्य लागू करने के तरीके अलग-अलग होते हैं.
cbc(aes)	cbc (टेंप्लेट), cbc-aes-neon, cbc-aes-neonbs, cbc-aes-ce	हां	AES-CBC: एईएस की सभी कुंजियों के साइज़ काम करते हैं. ctr(<aes-impl>) का इस्तेमाल करके, cbc टेंप्लेट को aes को लागू करके बनाया जा सकता है. अन्य लागू करने के तरीके अलग-अलग होते हैं.
cts(cbc(aes))	cts (टेंप्लेट), cts-cbc-aes-neon, cts-cbc-aes-ce	हां	साइफ़रटेक्स्ट चोरी के साथ AES-CBC-CTS या AES-CBC: CS3 का इस्तेमाल किया जाता है. आखिरी दो साइफ़रटेक्स्ट ब्लॉक की अदला-बदली बिना किसी शर्त के की जाती है. AES की सभी साइज़ काम करती हैं. cts टेंप्लेट को cts(<cbc(aes)-impl>) का इस्तेमाल करके, cbc के किसी भी तरीके से बनाया जा सकता है. अन्य लागू करने के तरीके, अलग-अलग होते हैं.
ctr(aes)	ctr (टेंप्लेट), ctr-aes-neon, ctr-aes-neonbs, ctr-aes-ce	हां	AES-CTR: एईएस की सभी साइज़ का इस्तेमाल किया जा सकता है. ctr(<aes-impl>) का इस्तेमाल करके, ctr टेंप्लेट को aes को लागू करके बनाया जा सकता है. अन्य लागू करने के तरीके, अलग-अलग होते हैं.
xts(aes)	xts (टेंप्लेट), xts-aes-neon, xts-aes-neonbs, xts-aes-ce	हां	AES-XTS: कर्नेल के 6.1 और इससे पहले के वर्शन में, सभी AES कुंजी साइज़ काम करते हैं. साथ ही, कर्नेल के 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 का इस्तेमाल किया जाता है: इसमें हेल्थ जांच शामिल होती है. इस इंटरफ़ेस के उपयोगकर्ताओं को अपने 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 मॉड्यूल बनाएं.

• बेज़ल के साथ बिल्ड:

  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 दिया गया है. इससे पता चलता है कि किसी एल्गोरिदम को मंज़ूरी मिली है या नहीं.

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

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