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

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

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

मॉड्यूल को डिप्लॉय करने का तरीका

इस मॉड्यूल को Android बिल्ड में शामिल करने के लिए, यहां दिया गया तरीका अपनाएं:

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

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

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

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

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

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

खुद की जांच में होने वाली गड़बड़ियां

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

  1. ऐसा माना जाता है कि मॉड्यूल का AES-GCM इस्तेमाल "एल्गोरिदम" हो सकता है स्वीकृत" मॉड्यूल को अनुमति मिली है, लेकिन "मॉड्यूल को मंज़ूरी नहीं मिली" है. इनकी पुष्टि की जा सकती है, लेकिन एफ़आईपीएस मॉड्यूल के हिसाब से, AES-GCM को मंज़ूरी पा चुके एल्गोरिदम नहीं माना जा सकता. ऐसा इसलिए है, क्योंकि GCM के लिए एफ़आईपीएस मॉड्यूल की ज़रूरी शर्तें इसके साथ काम नहीं करती हैं GCM को ऐसे लागू करना जो खुद के IVs जनरेट नहीं करते.↩