FIPS 140-3 प्रमाणित GKI क्रिप्टो मॉड्यूल

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

क्रिप्टो रूटीन का उपयोग करने से पहले निम्नलिखित FIPS 140-3 आवश्यकताओं को विशेष रूप से पूरा किया जाना चाहिए:

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

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

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

GKI कर्नेल को उसके संपूर्ण समर्थित जीवनकाल के दौरान नियमित रूप से अद्यतन करने का इरादा है। इससे पूरे कर्नेल का FIPS मॉड्यूल सीमा के भीतर होना असंभव हो जाता है, क्योंकि ऐसे मॉड्यूल को प्रत्येक कर्नेल अपडेट पर पुन: प्रमाणित करने की आवश्यकता होगी। "FIPS मॉड्यूल" को कर्नेल छवि के सबसेट के रूप में परिभाषित करने से यह समस्या कम हो जाएगी, लेकिन इसका समाधान नहीं होगा, क्योंकि "FIPS मॉड्यूल" की बाइनरी सामग्री अभी भी आवश्यकता से अधिक बार बदलेगी।

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

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

मॉड्यूल का उपयोग कब करें

GKI कर्नेल स्वयं वह कोड रखता है जो क्रिप्टो रूटीन पर निर्भर करता है जिसे FIPS 140-3 कर्नेल मॉड्यूल में भी पैक किया जाता है। इसलिए, अंतर्निहित क्रिप्टो रूटीन वास्तव में जीकेआई कर्नेल से बाहर नहीं जाते हैं बल्कि मॉड्यूल में कॉपी किए जाते हैं। जब मॉड्यूल लोड किया जाता है, तो अंतर्निहित क्रिप्टो रूटीन को लिनक्स क्रिप्टोएपीआई से अपंजीकृत कर दिया जाता है और मॉड्यूल द्वारा किए गए रूटीन द्वारा प्रतिस्थापित कर दिया जाता है।

इसका मतलब यह है कि fips140.ko मॉड्यूल पूरी तरह से वैकल्पिक है, और इसे तैनात करना केवल तभी समझ में आता है जब FIPS 140-3 प्रमाणीकरण एक आवश्यकता है। इसके अलावा, मॉड्यूल कोई अतिरिक्त कार्यक्षमता प्रदान नहीं करता है, और इसे अनावश्यक रूप से लोड करने से केवल बूट समय प्रभावित होने की संभावना है, बिना कोई लाभ प्रदान किए।

मॉड्यूल को कैसे तैनात करें

मॉड्यूल को निम्नलिखित चरणों का उपयोग करके एंड्रॉइड बिल्ड में शामिल किया जा सकता है:

  • मॉड्यूल का नाम BOARD_VENDOR_RAMDISK_KERNEL_MODULES में जोड़ें। इसके कारण मॉड्यूल को विक्रेता रैमडिस्क पर कॉपी किया जा सकता है।
  • मॉड्यूल का नाम BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD में जोड़ें। इसके कारण लक्ष्य पर मॉड्यूल का नाम modules.load में जोड़ा जाता है। modules.load उन मॉड्यूल की सूची रखता है जो डिवाइस बूट होने पर init द्वारा लोड किए जाते हैं।

अखंडता स्व-जांच

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

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

ज्ञात-उत्तर स्वयं परीक्षण

FIPS 140-3 आवश्यकताओं के अंतर्गत आने वाले किसी भी कार्यान्वित एल्गोरिदम को उपयोग किए जाने से पहले एक ज्ञात-उत्तर स्व-परीक्षण करना होगा। FIPS 140-3 कार्यान्वयन मार्गदर्शन 10.3.ए के अनुसार, किसी भी समर्थित कुंजी लंबाई का उपयोग करके प्रति एल्गोरिदम एक एकल परीक्षण वेक्टर सिफर के लिए पर्याप्त है, जब तक कि एन्क्रिप्शन और डिक्रिप्शन दोनों का परीक्षण किया जाता है।

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

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

FIPS 140-3 मॉड्यूल में शामिल सभी एल्गोरिदम निम्नानुसार सूचीबद्ध हैं। यह android12-5.10 , android13-5.10 , android13-5.15 , android14-5.15 , और android14-6.1 कर्नेल शाखाओं पर लागू होता है, हालांकि जहां उपयुक्त हो वहां कर्नेल संस्करणों के बीच अंतर नोट किया जाता है।

कलन विधि कार्यान्वयन स्वीकार्य परिभाषा
aes aes-generic , aes-arm64 , aes-ce , एईएस लाइब्रेरी हाँ सादा एईएस ब्लॉक सिफर, ऑपरेशन के किसी भी तरीके के साथ: सभी कुंजी आकार (128 बिट्स, 192 बिट्स और 256 बिट्स) समर्थित हैं। लाइब्रेरी कार्यान्वयन के अलावा अन्य सभी कार्यान्वयनों को एक टेम्पलेट के माध्यम से संचालन के तरीके के साथ तैयार किया जा सकता है।
cmac(aes) cmac (टेम्पलेट), cmac-aes-neon , cmac-aes-ce हाँ एईएस-सीएमएसी: सभी एईएस कुंजी आकार समर्थित हैं। cmac टेम्पलेट को cmac(<aes-impl>) उपयोग करके aes के किसी भी कार्यान्वयन के साथ बनाया जा सकता है। अन्य कार्यान्वयन स्टैंडअलोन हैं।
ecb(aes) ecb (टेम्पलेट), ecb-aes-neon , ecb-aes-neonbs , ecb-aes-ce हाँ एईएस-ईसीबी: सभी एईएस कुंजी आकार समर्थित हैं। ecb टेम्पलेट को ecb(<aes-impl>) उपयोग करके aes के किसी भी कार्यान्वयन के साथ बनाया जा सकता है। अन्य कार्यान्वयन स्टैंडअलोन हैं।
cbc(aes) cbc (टेम्पलेट), cbc-aes-neon , cbc-aes-neonbs , cbc-aes-ce हाँ एईएस-सीबीसी: सभी एईएस कुंजी आकार समर्थित हैं। cbc टेम्पलेट को ctr(<aes-impl>) उपयोग करके aes के किसी भी कार्यान्वयन के साथ बनाया जा सकता है। अन्य कार्यान्वयन स्टैंडअलोन हैं।
cts(cbc(aes)) cts (टेम्पलेट), cts-cbc-aes-neon , cts-cbc-aes-ce हाँ सिफरटेक्स्ट चोरी के साथ एईएस-सीबीसी-सीटीएस या एईएस-सीबीसी: प्रयुक्त कन्वेंशन CS3 है; अंतिम दो सिफरटेक्स्ट ब्लॉक बिना शर्त स्वैप किए जाते हैं। सभी एईएस कुंजी आकार समर्थित हैं। cts टेम्पलेट cts(<cbc(aes)-impl>) उपयोग करके cbc के किसी भी कार्यान्वयन के साथ बनाया जा सकता है। अन्य कार्यान्वयन स्टैंडअलोन हैं।
ctr(aes) ctr (टेम्पलेट), ctr-aes-neon , ctr-aes-neonbs , ctr-aes-ce हाँ एईएस-सीटीआर: सभी एईएस कुंजी आकार समर्थित हैं। ctr टेम्पलेट को ctr(<aes-impl>) उपयोग करके aes के किसी भी कार्यान्वयन के साथ बनाया जा सकता है। अन्य कार्यान्वयन स्टैंडअलोन हैं।
xts(aes) xts (टेम्पलेट), xts-aes-neon , xts-aes-neonbs , xts-aes-ce हाँ एईएस-एक्सटीएस: सभी एईएस कुंजी आकार समर्थित हैं। xts टेम्पलेट को xts(<ecb(aes)-impl>) उपयोग करके ecb(aes) के किसी भी कार्यान्वयन के साथ बनाया जा सकता है। अन्य कार्यान्वयन स्टैंडअलोन हैं। सभी कार्यान्वयन FIPS द्वारा आवश्यक कमजोर कुंजी जांच को लागू करते हैं; अर्थात्, XTS कुंजियाँ जिनके पहले और दूसरे भाग बराबर हैं, अस्वीकार कर दी जाती हैं।
gcm(aes) gcm (टेम्पलेट), gcm-aes-ce नहीं 1 एईएस-जीसीएम: सभी एईएस कुंजी आकार समर्थित हैं। केवल 96-बिट IVs समर्थित हैं। इस मॉड्यूल में अन्य सभी एईएस मोड की तरह, कॉलर आईवी प्रदान करने के लिए जिम्मेदार है। 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 क्रिप्टोग्राफ़िक हैश फ़ंक्शन
hmac hmac (टेम्पलेट) हाँ HMAC (कीड-हैश मैसेज ऑथेंटिकेशन कोड): hmac टेम्पलेट को hmac(<sha-alg>) या hmac(<sha-impl>) का उपयोग करके किसी भी SHA एल्गोरिदम या कार्यान्वयन के साथ बनाया जा सकता है।
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 नहीं जिटर आरएनजी का संस्करण 2.2.0: इस इंटरफ़ेस के उपयोगकर्ताओं को अपने स्वयं के जिटर आरएनजी इंस्टेंस मिलते हैं। वे डीआरबीजी द्वारा उपयोग किए गए उदाहरणों का पुन: उपयोग नहीं करते हैं।
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 नहीं

स्रोत से मॉड्यूल बनाएँ

एंड्रॉइड 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 डाइजेस्ट सामग्री के साथ एक पूर्ण निर्माण करते हैं।

अंतिम उपयोगकर्ता मार्गदर्शन

क्रिप्टो अधिकारी मार्गदर्शन

कर्नेल मॉड्यूल को संचालित करने के लिए, ऑपरेटिंग सिस्टम को ऑपरेशन के एकल ऑपरेटर मोड तक सीमित होना चाहिए। इसे प्रोसेसर में मेमोरी प्रबंधन हार्डवेयर का उपयोग करके एंड्रॉइड द्वारा स्वचालित रूप से नियंत्रित किया जाता है।

कर्नेल मॉड्यूल अलग से स्थापित नहीं किया जा सकता; इसे डिवाइस फ़र्मवेयर के भाग के रूप में शामिल किया गया है और बूट पर स्वचालित रूप से लोड किया गया है। यह केवल संचालन के अनुमोदित मोड में ही काम करता है।

क्रिप्टो अधिकारी डिवाइस को पुनरारंभ करके किसी भी समय स्व-परीक्षण चला सकता है।

उपयोगकर्ता मार्गदर्शन

कर्नेल मॉड्यूल के उपयोगकर्ता अन्य कर्नेल घटक हैं जिन्हें क्रिप्टोग्राफ़िक एल्गोरिदम का उपयोग करने की आवश्यकता होती है। कर्नेल मॉड्यूल एल्गोरिदम के उपयोग में अतिरिक्त तर्क प्रदान नहीं करता है, और क्रिप्टोग्राफ़िक ऑपरेशन करने के लिए आवश्यक समय से परे किसी भी पैरामीटर को संग्रहीत नहीं करता है।

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

स्व-परीक्षण त्रुटियाँ

स्व-परीक्षण विफलता की स्थिति में, कर्नेल मॉड्यूल कर्नेल को घबरा देता है और डिवाइस बूटिंग जारी नहीं रखता है। यदि डिवाइस को रीबूट करने से समस्या का समाधान नहीं होता है, तो डिवाइस को फिर से फ्लैश करके समस्या को ठीक करने के लिए डिवाइस को रिकवरी मोड में बूट करना होगा।


  1. यह उम्मीद की जाती है कि मॉड्यूल के एईएस-जीसीएम कार्यान्वयन को "एल्गोरिदम अनुमोदित" किया जा सकता है लेकिन "मॉड्यूल अनुमोदित" नहीं। उन्हें मान्य किया जा सकता है, लेकिन एईएस-जीसीएम को FIPS मॉड्यूल के दृष्टिकोण से अनुमोदित एल्गोरिदम नहीं माना जा सकता है। ऐसा इसलिए है क्योंकि GCM के लिए FIPS मॉड्यूल आवश्यकताएँ GCM कार्यान्वयन के साथ असंगत हैं जो अपने स्वयं के IVs उत्पन्न नहीं करते हैं।