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

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

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

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

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

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

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

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

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

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

GKI कर्नेल में ऐसा कोड होता है जो क्रिप्टो रूटीन पर निर्भर करता है FIPS 140-3 कर्नेल मॉड्यूल में भी पैकेज किया जा सकता है. इसलिए, बिल्ट-इन क्रिप्टो रूटीन असल में GKI कर्नेल से बाहर नहीं ले जाए जाते, बल्कि मॉड्यूल का इस्तेमाल करना होगा. मॉड्यूल लोड होने पर, पहले से मौजूद क्रिप्टो रूटीन Linux क्रिप्टोग्राफ़ी के ज़रिए रजिस्टर किए गए एपीआई से डी-रजिस्टर किया गया और उसके बदले मॉड्यूल का इस्तेमाल नहीं किया जाएगा.

इसका मतलब है कि 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 का HMAC-SHA256 डाइजेस्ट लेता है और मॉड्यूल लोड होने में लगने वाले समय के लिए .rodata सेक्शन. साथ ही, इसकी तुलना डाइजेस्ट से करता है मॉड्यूल में रिकॉर्ड किया गया है. यह तब होता है, जब Linux मॉड्यूल लोडर पर पहले ही सामान्य बदलाव कर चुके हैं, जैसे कि ईएलएफ़ स्थानांतरण प्रोसेसिंग और उन सेक्शन में सीपीयू की गड़बड़ी के लिए पैचिंग के विकल्प भी उपलब्ध हैं. नीचे दिए गए इसके अलावा, कुछ और कदम उठाए जाते हैं, ताकि हर बार ईमेल से मिलने वाली जानकारी को आसानी से समझा जा सके सही ढंग से:

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

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

लागू किए गए ऐसे सभी एल्गोरिदम जो FIPS 140-3 की ज़रूरी शर्तों के तहत आते हैं इस्तेमाल करने से पहले, पहले से मालूम जवाब खुद की जाँच करें. एफ़आईपीएस 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 है; आखिरी दो साइफ़रटेक्स्ट ब्लॉक को बिना किसी शर्त के बदला जाता है.सभी AES कुंजी साइज़ इस्तेमाल किए जा सकते हैं.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 और इससे पहले के वर्शन में, एईएस कुंजी के सभी साइज़ काम करते हैं; कर्नेल के 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 क्रिप्टोग्राफ़िक हैश फ़ंक्शन: स्टैंडर्ड CookieAPI इंटरफ़ेस के अलावा, 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 इसे एफ़आईपीएस मॉड्यूल के हिसाब से, मंज़ूरी पा चुका एल्गोरिदम नहीं माना जा सकता. ऐसा इसलिए है, क्योंकि GCM के लिए एफ़आईपीएस मॉड्यूल की ज़रूरी शर्तें इसके साथ काम नहीं करती हैं GCM को ऐसे लागू करना जो खुद के IVs जनरेट नहीं करते.↩