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

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

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

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

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

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

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

इसलिए, FIPS 140-3 आवश्यकताओं द्वारा कवर किए गए सभी कोड को एक अलग कर्नेल मॉड्यूल fips140.ko में पैक किया जाता है जो केवल GKI कर्नेल स्रोत द्वारा उजागर किए गए स्थिर इंटरफेस पर निर्भर करता है जिससे इसे बनाया गया था। यह गारंटी देता है कि मॉड्यूल का उपयोग एक ही पीढ़ी के विभिन्न 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 डाइजेस्ट मॉड्यूल लोड समय पर लेता है, और इसकी तुलना मॉड्यूल में रिकॉर्ड किए गए डाइजेस्ट से करता है। यह तब होता है जब Linux मॉड्यूल लोडर पहले से ही उन अनुभागों में CPU इरेटा के लिए ELF रिलोकेशन प्रोसेसिंग और वैकल्पिक पैचिंग जैसे सामान्य संशोधन कर चुका होता है। निम्नलिखित अतिरिक्त कदम यह सुनिश्चित करने के लिए उठाए गए हैं कि डाइजेस्ट को सही ढंग से पुन: उत्पन्न किया जा सके:

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

ज्ञात-उत्तर आत्म परीक्षण

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

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

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

android13-5.10 स्रोतों से निर्मित होने पर FIPS 140-3 मॉड्यूल में शामिल सभी एल्गोरिदम निम्नानुसार सूचीबद्ध हैं।

कलन विधि कार्यान्वयन स्वीकार्य परिभाषा
aes aes-generic , aes-arm64 , aes-ce , एईएस लाइब्रेरी हाँ सादा एईएस ब्लॉक सिफर, ऑपरेशन के किसी मोड के साथ: सभी प्रमुख आकार (128 बिट, 192 बिट और 256 बिट) समर्थित हैं। पुस्तकालय कार्यान्वयन के अलावा अन्य सभी कार्यान्वयन एक टेम्पलेट के माध्यम से संचालन के तरीके से बनाये जा सकते हैं।
cmac(aes) cmac (टेम्प्लेट), cmac-aes-neon , cmac-aes-ce हाँ एईएस-सीएमएसी: सभी एईएस कुंजी आकार समर्थित हैं। aes cmac(<aes-impl>) का उपयोग करके aes के किसी भी कार्यान्वयन के साथ cmac टेम्पलेट की रचना की जा सकती है। अन्य कार्यान्वयन स्टैंडअलोन हैं।
ecb(aes) ecb (टेम्पलेट), ecb-aes-neon , ecb-aes-neonbs , ecb-aes-ce हाँ एईएस-ईसीबी: सभी एईएस कुंजी आकार समर्थित हैं। aes ecb(<aes-impl>) का उपयोग करके ecb टेम्पलेट को 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(<ecb(aes)-impl>) का उपयोग करके ecb(aes ecb(aes) के किसी भी कार्यान्वयन के साथ xts टेम्पलेट बनाया जा सकता है। अन्य कार्यान्वयन स्टैंडअलोन हैं। सभी कार्यान्वयन FIPS द्वारा आवश्यक कमजोर कुंजी जाँच को लागू करते हैं; अर्थात्, XTS कुंजियाँ जिनका पहला और दूसरा भाग बराबर हैं, अस्वीकृत कर दी जाती हैं।
gcm(aes) gcm (टेम्प्लेट), gcm-aes-ce नंबर 1 एईएस-जीसीएम: सभी एईएस कुंजी आकार समर्थित हैं। केवल 96-बिट IV समर्थित हैं। इस मॉड्यूल में अन्य सभी एईएस मोड के साथ, कॉल करने वाला आईवी प्रदान करने के लिए जिम्मेदार है। gcm_base(<ctr(aes)-impl>,<ghash-impl>) का उपयोग करके gcm टेम्पलेट को ctr(aes) और ghash के किसी भी कार्यान्वयन से बनाया जा सकता है। अन्य कार्यान्वयन स्टैंडअलोन हैं।
sha1 sha1-generic , sha1-ce हाँ SHA-1 क्रिप्टोग्राफ़िक हैश फ़ंक्शन
sha224 sha224-generic , sha224-arm64 64, sha224-ce हाँ SHA-224 क्रिप्टोग्राफ़िक हैश फ़ंक्शन: कोड SHA-256 के साथ साझा किया गया है।
sha256 sha256-generic , sha256-arm64 , sha256-ce , SHA-256 पुस्तकालय हाँ SHA-256 क्रिप्टोग्राफ़िक हैश फ़ंक्शन: पारंपरिक क्रिप्टोएपीआई इंटरफ़ेस के अलावा SHA-256 को एक लाइब्रेरी इंटरफ़ेस प्रदान किया जाता है। यह लाइब्रेरी इंटरफ़ेस एक अलग कार्यान्वयन का उपयोग करता है।
sha384 sha384-generic , sha384-arm64 64, 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_* एल्गोरिदम के समान, लेकिन भविष्यवाणी प्रतिरोध अक्षम के साथ। कोड को भविष्यवाणी-प्रतिरोधी संस्करण के साथ साझा किया गया है। उच्चतम प्राथमिकता वाला DRBG है drbg_nopr_hmac_sha256 ।
jitterentropy_rng jitterentropy_rng नहीं जिटर आरएनजी का वर्जन 2.2.0 : इस इंटरफेस के यूजर्स को अपने खुद के जिटर आरएनजी इंस्टेंसेस मिलते हैं। वे डीआरबीजी द्वारा उपयोग किए जाने वाले उदाहरणों का पुन: उपयोग नहीं करते हैं।
xcbc(aes) xcbc-aes-neon , xcbc-aes-ce नहीं
cbcmac(aes) cbcmac-aes-neon , cbcmac-aes-ce नहीं
essiv(cbc(aes),sha256) essiv-cbc-aes-sha256-neon , essiv-cbc-aes-sha256-ce नहीं

स्रोत से मॉड्यूल का निर्माण

fips140.ko मॉड्यूल GKI कर्नेल स्रोतों से निम्नलिखित कमांड का उपयोग करके बनाया जा सकता है:

BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh

यह कर्नेल और fips140.ko मॉड्यूल के साथ पूर्ण निर्माण करता है, इसकी सामग्री के सही HMAC-SHA256 डाइजेस्ट के साथ।

Android 14 (AOSP प्रयोगात्मक) और इसके बाद के संस्करण में, निम्नलिखित कमांड का उपयोग करके build/build.sh के बजाय Bazel के साथ निर्माण करें:

tools/bazel run //common:fips140_dist

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

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

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

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

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

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

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

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

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

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

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