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

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

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

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

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

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

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

कर्नेल वर्शन 6.1 से पहले, एक और विचार यह था कि जीकेआई को एलटीओ (लिंक टाइम ऑप्टिमाइज़ेशन) के साथ कंपाइल किया गया था, क्योंकि कंट्रोल फ़्लो इंटेग्रिटी के लिए एलटीओ एक ज़रूरी सुविधा थी, जो सुरक्षा से जुड़ी एक अहम सुविधा है.

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

मॉड्यूल का इस्तेमाल कब करना चाहिए

जीकेआई कर्नेल में ऐसा कोड होता है जो एफ़आईपीएस 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 लोड करता है.

इंटिग्रिटी की अपने-आप जांच होने की सुविधा

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

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

पहले से मालूम सवालों के जवाब खुद देने की क्षमता

एफ़आईपीएस 140-3 की ज़रूरी शर्तों के तहत लागू किए गए किसी भी लागू किए गए एल्गोरिदम को, उसका इस्तेमाल किए जाने से पहले खुद की जांच के नतीजे के तौर पर करना होगा. FIPS 140-3 लागू करने से जुड़े दिशा-निर्देश 10.3.A के मुताबिक, काम करने वाली किसी भी कुंजी की लंबाई का इस्तेमाल करके, हर एल्गोरिदम के लिए एक टेस्ट वेक्टर, साइफ़र के लिए काफ़ी होता है. हालांकि, ऐसा तब ही होता है, जब एन्क्रिप्ट करने और डिक्रिप्ट करने, दोनों की जांच की जाती है.

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

मॉड्यूल में शामिल एल्गोरिदम

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