जीकेआई कर्नेल में, fips140.ko नाम का एक Linux कर्नेल मॉड्यूल शामिल होता है. यह क्रिप्टोग्राफ़िक सॉफ़्टवेयर मॉड्यूल के लिए, FIPS 140-3 की ज़रूरी शर्तों का पालन करता है.
अगर GKI कर्नेल चलाने वाले प्रॉडक्ट के लिए FIPS सर्टिफ़िकेशन ज़रूरी है, तो इस मॉड्यूल को सबमिट किया जा सकता है.
क्रिप्टो रूटीन का इस्तेमाल करने से पहले, खास तौर पर FIPS 140-3 की इन शर्तों को पूरा करना ज़रूरी है:
- क्रिप्टोग्राफ़िक एल्गोरिदम उपलब्ध कराने से पहले, मॉड्यूल को अपनी इंटिग्रिटी की जांच करनी होगी.
- मॉड्यूल को, मंज़ूरी पा चुके क्रिप्टोग्राफ़िक एल्गोरिदम का इस्तेमाल करना चाहिए और उनकी पुष्टि करनी चाहिए. इसके लिए, क्रिप्टोग्राफ़िक एल्गोरिदम के सेल्फ़-टेस्ट का इस्तेमाल करना चाहिए. इसके बाद ही, उन्हें उपलब्ध कराना चाहिए.
अलग कर्नेल मॉड्यूल क्यों
FIPS 140-3 की पुष्टि इस आधार पर की जाती है कि एक बार सॉफ़्टवेयर या हार्डवेयर पर आधारित मॉड्यूल को सर्टिफ़िकेट मिल जाने के बाद, उसमें कभी बदलाव नहीं किया जाता. बदलाव होने पर, इसे फिर से सर्टिफ़ाई करना होगा. यह आज इस्तेमाल की जा रही सॉफ़्टवेयर डेवलपमेंट प्रोसेस से मेल नहीं खाता. इस ज़रूरी शर्त की वजह से, FIPS सॉफ़्टवेयर मॉड्यूल को आम तौर पर क्रिप्टोग्राफ़िक कॉम्पोनेंट पर ज़्यादा से ज़्यादा फ़ोकस करने के लिए डिज़ाइन किया जाता है. इससे यह पक्का किया जा सकता है कि क्रिप्टोग्राफ़ी से जुड़े बदलावों के लिए, क्रिप्टोग्राफ़ी का फिर से आकलन करने की ज़रूरत न पड़े.
जीकेआई कर्नेल को, इसके पूरे लाइफ़टाइम में नियमित तौर पर अपडेट किया जाता है. इस वजह से, पूरे कर्नल को FIPS मॉड्यूल की सीमा के अंदर नहीं रखा जा सकता. ऐसा इसलिए, क्योंकि हर कर्नल अपडेट के बाद, ऐसे मॉड्यूल को फिर से सर्टिफ़िकेट देना होगा. "FIPS मॉड्यूल" को कर्नल इमेज का सबसेट के तौर पर तय करने से, इस समस्या को कम किया जा सकता है. हालांकि, इससे समस्या हल नहीं होगी, क्योंकि "FIPS मॉड्यूल" के बाइनरी कॉन्टेंट में अब भी ज़रूरत से ज़्यादा बार बदलाव होगा.
कर्नल के 6.1 वर्शन से पहले, एक और बात ध्यान में रखी जाती थी. वह यह थी कि GKI को LTO (लिंक टाइम ऑप्टिमाइज़ेशन) की सुविधा के साथ कंपाइल किया गया था. ऐसा इसलिए, क्योंकि LTO, कंट्रोल फ़्लो इंटिग्रिटी के लिए ज़रूरी था. यह सुरक्षा से जुड़ी एक अहम सुविधा है.
इसलिए, FIPS 140-3 की ज़रूरी शर्तों के दायरे में आने वाले सभी कोड को एक अलग कर्नेल मॉड्यूल fips140.ko में पैकेज किया जाता है. यह सिर्फ़ GKI कर्नेल सोर्स के ज़रिए दिखाए गए स्टेबल इंटरफ़ेस पर निर्भर करता है. इसका मतलब है कि मॉड्यूल का इस्तेमाल, एक ही जनरेशन की अलग-अलग GKI रिलीज़ के साथ किया जा सकता है. साथ ही, इसे सर्टिफ़िकेशन के लिए सिर्फ़ तब अपडेट करके फिर से सबमिट करना होगा, जब मॉड्यूल में मौजूद कोड में कोई समस्या ठीक की गई हो.
इस मॉड्यूल का इस्तेमाल कब करें
GKI कर्नल में ऐसा कोड होता है जो क्रिप्टोग्राफ़िक रूटीन पर निर्भर करता है. इन रूटीन को FIPS 140-3 कर्नल मॉड्यूल में भी पैकेज किया जाता है. इसलिए, बिल्ट-इन क्रिप्टो रूटीन को GKI कर्नल से बाहर नहीं ले जाया जाता, बल्कि मॉड्यूल में कॉपी किया जाता है. मॉड्यूल लोड होने पर, बिल्ट-इन क्रिप्टो रूटीन को Linux CryptoAPI से हटा दिया जाता है. इसके बाद, मॉड्यूल में मौजूद क्रिप्टो रूटीन का इस्तेमाल किया जाता है.
इसका मतलब है कि fips140.ko मॉड्यूल पूरी तरह से वैकल्पिक है. इसे सिर्फ़ तब डिप्लॉय करना चाहिए, जब FIPS 140-3 सर्टिफ़िकेट ज़रूरी हो. इसके अलावा, यह मॉड्यूल कोई अतिरिक्त सुविधा नहीं देता है. इसे बिना किसी वजह के लोड करने से, बूट टाइम पर ही असर पड़ेगा. इससे कोई फ़ायदा नहीं होगा.
मॉड्यूल को डिप्लॉय करने का तरीका
इस मॉड्यूल को Android बिल्ड में शामिल करने के लिए, यह तरीका अपनाएं:
BOARD_VENDOR_RAMDISK_KERNEL_MODULESमें मॉड्यूल का नाम जोड़ें. इससे मॉड्यूल को वेंडर रैमडिस्क में कॉपी किया जाता है.BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOADमें मॉड्यूल का नाम जोड़ें. इससे टारगेट परmodules.loadमें मॉड्यूल का नाम जुड़ जाता है.modules.loadमें उन मॉड्यूल की सूची होती है जिन्हें डिवाइस बूट होने परinitलोड करता है.
इंटिग्रिटी की खुद से जांच करने की सुविधा
FIPS 140-3 कर्नल मॉड्यूल, मॉड्यूल लोड होने के समय अपने .code और .rodata सेक्शन का HMAC-SHA256 डाइजेस्ट लेता है. इसके बाद, इसकी तुलना मॉड्यूल में रिकॉर्ड किए गए डाइजेस्ट से करता है. यह प्रोसेस तब होती है, जब Linux मॉड्यूल लोडर पहले ही सामान्य बदलाव कर चुका होता है. जैसे, उन सेक्शन के लिए ईएलएफ़ रिलोकेशन प्रोसेसिंग और सीपीयू की गड़बड़ियों के लिए वैकल्पिक पैचिंग. डाइजेस्ट को सही तरीके से फिर से बनाया जा सके, इसके लिए ये अतिरिक्त चरण अपनाए जाते हैं:
- ईएलएफ़ रिलोकेशन को मॉड्यूल में सेव किया जाता है, ताकि उन्हें एचएमएसी के इनपुट पर उलटे क्रम में लागू किया जा सके.
- यह मॉड्यूल, कर्नल के ज़रिए Dynamic Shadow Call Stack के लिए किए गए सभी कोड पैच को पहले जैसा कर देता है. खास तौर पर, यह मॉड्यूल शैडो कॉल स्टैक से पुश या पॉप करने वाले किसी भी निर्देश को, मूल रूप से मौजूद पॉइंटर ऑथेंटिकेशन कोड (पीएसी) निर्देशों से बदल देता है.
- मॉड्यूल के लिए, कोड पैच करने की अन्य सभी सुविधाएं बंद कर दी जाती हैं. इनमें स्टैटिक कुंजियां और इसलिए ट्रेसपॉइंट के साथ-साथ वेंडर हुक भी शामिल हैं.
क्रिप्टोग्राफ़िक एल्गोरिदम, खुद ही टेस्ट करता है
FIPS 140-3 कर्नल मॉड्यूल, क्रिप्टोग्राफ़िक एल्गोरिदम के सेल्फ़-टेस्ट की ज़रूरी शर्तों को पूरा करता है. इसके लिए, यह मॉड्यूल ज्ञात जवाबों वाले टेस्ट लागू करता है. लागू किए गए टेस्ट, एल्गोरिदम के हिसाब से अलग-अलग होते हैं. साथ ही, ये FIPS 140-3 के लागू करने से जुड़े दिशा-निर्देश 10.3.A का पालन करते हैं.
आम तौर पर, हर एल्गोरिदम के लिए सिर्फ़ एक टेस्ट वेक्टर ज़रूरी होता है. FIPS के क्रिप्टोग्राफ़िक एल्गोरिदम के सेल्फ़-टेस्ट, सिर्फ़ बुनियादी फ़ंक्शन की पुष्टि करने के लिए डिज़ाइन किए गए हैं. पूरी तरह से जांच अलग से की जाती है. इसके लिए, Cryptographic Algorithm Validation Program (CAVP) और अपस्ट्रीम कर्नल के क्रिप्टोग्राफ़िक टेस्ट सुइट का इस्तेमाल किया जाता है.
जब किसी एल्गोरिदम के कई वर्शन, उपयोगकर्ता के लिए उपलब्ध होते हैं या मॉड्यूल की सेवाओं के लिए इस्तेमाल किए जाते हैं, तो FIPS 140-3 के तहत यह ज़रूरी है कि उन सभी वर्शन की जांच खुद की जाए. यह इंटिग्रेशन की उस रणनीति के लिए काम की है जिसका इस्तेमाल Linux CryptoAPI करता है. इसमें हर एल्गोरिदम के लिए, उपयोगकर्ता के हिसाब से कई लागू करने के तरीके हो सकते हैं. उदाहरण के लिए, android16-6.12 कर्नल में SHA-256 के तीन
इंपलीमेंटेशन हैं: sha256-generic, sha256-arm64, और sha256-ce. ARMv8 क्रिप्टो एक्सटेंशन वाले सीपीयू पर, sha256-ce का इस्तेमाल डिफ़ॉल्ट रूप से किया जाता है. हालांकि, उपयोगकर्ता अब भी अन्य एक्सटेंशन को साफ़ तौर पर ऐक्सेस कर सकते हैं. इसलिए, मॉड्यूल इन तीनों तरीकों की खुद ही जांच करता है.
android17-6.18 और इससे ऊपर के कर्नल में, कुछ एल्गोरिदम इंटिग्रेशन की आसान रणनीति का इस्तेमाल करते हैं. उदाहरण के लिए, android17-6.18 कर्नल में, SHA-256 का एक sha256-lib ही वर्शन होता है. यह मॉड्यूल लोड होने के समय, सीपीयू के लिए सही कोड अपने-आप चुन लेता है. इसलिए, मॉड्यूल सिर्फ़ खुद की जांच करता हैsha256-lib.
मॉड्यूल में शामिल एल्गोरिदम
FIPS 140-3 मॉड्यूल में शामिल सभी एल्गोरिदम की सूची यहां दी गई है.
यह android12-5.10, android13-5.10, android13-5.15, android14-5.15, android14-6.1, android15-6.6, android16-6.12, और android17-6.18 कर्नेल ब्रांच पर लागू होता है. हालांकि, कर्नेल वर्शन के बीच के अंतर को सही जगह पर नोट किया गया है.
| एल्गोरिदम | लागू करने के तरीके | मंज़ूरी दी जा सकती है | परिभाषा |
|---|---|---|---|
aes |
aes-generic, aes-arm64, aes-ce, एईएस लाइब्रेरी |
हां | ऑपरेशन के किसी भी मोड के बिना, सामान्य AES ब्लॉक साइफ़र: सभी कुंजी साइज़ (128 बिट, 192 बिट, और 256 बिट) काम करते हैं. लाइब्रेरी को लागू करने के अलावा, अन्य सभी तरीकों को टेम्प्लेट के ज़रिए ऑपरेशन के मोड के साथ कंपोज़ किया जा सकता है. |
cmac(aes) |
cmac (टेंप्लेट), cmac-aes-neon, cmac-aes-ce |
हां | AES-CMAC: इसमें एईएस के सभी की साइज़ काम करते हैं. cmac टेंप्लेट को cmac( का इस्तेमाल करके, aes के किसी भी वर्शन के साथ कंपोज़ किया जा सकता है. अन्य लागू करने के तरीके, स्टैंडअलोन हैं. |
ecb(aes) |
ecb (टेंप्लेट), ecb-aes-neon, ecb-aes-neonbs, ecb-aes-ce |
हां | AES-ECB: इसमें एईएस की सभी साइज़ वाली कुंजियां काम करती हैं. ecb टेंप्लेट को ecb( का इस्तेमाल करके, aes के किसी भी वर्शन के साथ कंपोज़ किया जा सकता है. अन्य लागू करने के तरीके, स्टैंडअलोन हैं. |
cbc(aes) |
cbc (टेंप्लेट), cbc-aes-neon, cbc-aes-neonbs, cbc-aes-ce |
हां | AES-CBC: इसमें AES की सभी साइज़ वाली कुंजियां इस्तेमाल की जा सकती हैं. cbc टेंप्लेट को cbc( का इस्तेमाल करके, aes के किसी भी वर्शन के साथ कंपोज़ किया जा सकता है. अन्य लागू करने के तरीके, स्टैंडअलोन हैं. |
cts(cbc(aes)) |
cts (टेंप्लेट), cts-cbc-aes-neon, cts-cbc-aes-ce |
हां | AES-CBC-CTS या AES-CBC with ciphertext stealing: इसमें CS3 का इस्तेमाल किया जाता है. साथ ही, आखिरी दो साइफ़रटेक्स्ट ब्लॉक को बिना किसी शर्त के स्वैप किया जाता है. एईएस की सभी साइज़ इस्तेमाल किए जा सकते हैं. cts टेंप्लेट को cts( का इस्तेमाल करके, cbc के किसी भी वर्शन के साथ कंपोज़ किया जा सकता है. अन्य लागू करने के तरीके, स्टैंडअलोन हैं. |
ctr(aes) |
ctr (टेंप्लेट), ctr-aes-neon, ctr-aes-neonbs, ctr-aes-ce |
हां | AES-CTR: इसमें एईएस के सभी की-साइज़ काम करते हैं. ctr टेंप्लेट को 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 टेंप्लेट को xts( का इस्तेमाल करके, ecb(aes) के किसी भी वर्शन के साथ कंपोज़ किया जा सकता है. अन्य लागू करने के तरीके, स्टैंडअलोन हैं. सभी लागू करने वाले, FIPS के लिए ज़रूरी कमज़ोर कुंजी की जांच को लागू करते हैं; यानी कि XTS कुंजियों को अस्वीकार कर दिया जाता है जिनके पहले और दूसरे हिस्से बराबर होते हैं. |
gcm(aes) |
gcm (टेंप्लेट), gcm-aes-ce |
नहीं 1 | AES-GCM: इसमें एईएस के सभी साइज़ की कुंजियां इस्तेमाल की जा सकती हैं. सिर्फ़ 96-बिट IV इस्तेमाल किए जा सकते हैं. इस मॉड्यूल में मौजूद अन्य सभी एईएस मोड की तरह, IV उपलब्ध कराने की ज़िम्मेदारी कॉलर की होती है. gcm_base( का इस्तेमाल करके, ctr(aes) और ghash के किसी भी वर्शन के साथ gcm टेंप्लेट बनाया जा सकता है. अन्य लागू करने के तरीके, स्टैंडअलोन हैं. |
sha1 |
कर्नेल 6.12 और इससे पहले के वर्शन: sha1-generic, sha1-ce |
हां | SHA-1 क्रिप्टोग्राफ़िक हैश फ़ंक्शन. इसे कर्नेल 6.18 और इसके बाद के वर्शन में हटा दिया गया है. |
sha224 |
Kernel 6.18 और इसके बाद के वर्शन: sha224-lib. कर्नेल 6.12 और इससे पहले के वर्शन: sha224-generic, sha224-arm64, sha224-ce |
हां | SHA-224 क्रिप्टोग्राफ़िक हैश फ़ंक्शन: यह कोड SHA-256 के साथ शेयर किया जाता है. |
sha256 |
Kernel 6.18 और इसके बाद के वर्शन: sha256-lib. Kernel 6.12 और इससे पहले के वर्शन: sha256-generic, sha256-arm64, sha256-ce, SHA-256 लाइब्रेरी |
हां | SHA-256 क्रिप्टोग्राफ़िक हैश फ़ंक्शन. |
sha384 |
Kernel 6.18 और इसके बाद के वर्शन: sha384-lib. कर्नेल 6.12 और इससे पहले के वर्शन: sha384-generic, sha384-arm64, sha384-ce |
हां | SHA-384 क्रिप्टोग्राफ़िक हैश फ़ंक्शन: यह कोड SHA-512 के साथ शेयर किया जाता है. |
sha512 |
Kernel 6.18 और इसके बाद के वर्शन: sha512-lib. कर्नेल 6.12 और इससे पहले के वर्शन: sha512-generic, sha512-arm64, sha512-ce |
हां | SHA-512 क्रिप्टोग्राफ़िक हैश फ़ंक्शन. |
sha3-224 |
Kernel 6.6 और इसके बाद के वर्शन: sha3-224-generic |
हां | SHA3-224 क्रिप्टोग्राफ़िक हैश फ़ंक्शन. |
sha3-256 |
Kernel 6.6 और इसके बाद के वर्शन: sha3-256-generic |
हां | यह पहले जैसा ही है, लेकिन इसमें डाइजेस्ट की लंबाई 256 बिट (SHA3-256) है. सभी डाइजेस्ट की लंबाई के लिए, Keccak के एक ही वर्शन का इस्तेमाल किया जाता है. |
sha3-384 |
Kernel 6.6 और इसके बाद के वर्शन: sha3-384-generic |
हां | यह ऊपर दिए गए उदाहरण की तरह ही है, लेकिन इसमें डाइजेस्ट की लंबाई 384 बिट (SHA3-384) है. सभी डाइजेस्ट की लंबाई के लिए, Keccak के एक ही वर्शन का इस्तेमाल किया जाता है. |
sha3-512 |
Kernel 6.6 और इसके बाद के वर्शन: sha3-512-generic |
हां | यह ऊपर दिए गए उदाहरण की तरह ही है, लेकिन इसमें डाइजेस्ट की लंबाई 512 बिट (SHA3-512) है. सभी डाइजेस्ट की लंबाई के लिए, Keccak के एक ही वर्शन का इस्तेमाल किया जाता है. |
hmac |
hmac (टेंप्लेट) |
हां | कीड-हैश मैसेज ऑथेंटिकेशन कोड (एचएमएसी): hmac टेंप्लेट को किसी भी SHA एल्गोरिदम या hmac( या hmac( का इस्तेमाल करके लागू किया जा सकता है. |
stdrng |
सभी कर्नल: drbg_pr_hmac_sha256, drbg_pr_hmac_sha384, drbg_pr_hmac_sha512. कर्नेल 6.6 और इससे पहले के वर्शन: drbg_pr_hmac_sha1 |
हां | HMAC_DRBG को नाम वाले हैश फ़ंक्शन के साथ इंस्टैंटिएट किया गया है. साथ ही, इसमें अनुमान लगाने से रोकने की सुविधा चालू है: इसमें हेल्थ चेक शामिल हैं. इस इंटरफ़ेस के उपयोगकर्ताओं को अपने DRBG इंस्टेंस मिलते हैं. |
stdrng |
सभी कर्नल: drbg_nopr_hmac_sha256, drbg_nopr_hmac_sha384, drbg_nopr_hmac_sha512. कर्नेल 6.6 और इससे पहले के वर्शन: drbg_nopr_hmac_sha1 |
हां | यह 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 और इसके बाद का वर्शन). इस इंटरफ़ेस के उपयोगकर्ताओं को, Jitter RNG के अपने इंस्टेंस मिलते हैं. ये DRBG के इस्तेमाल किए गए इंस्टेंस का फिर से इस्तेमाल नहीं करते. |
xcbc(aes) |
xcbc-aes-neon, xcbc-aes-ce |
नहीं | |
xctr(aes) |
Kernel 5.15 और इसके बाद के वर्शन: xctr-aes-neon, xctr-aes-ce |
नहीं | |
cbcmac(aes) |
cbcmac-aes-neon, cbcmac-aes-ce |
नहीं | |
essiv(cbc(aes),sha256) |
essiv-cbc-aes-sha256-neon, essiv-cbc-aes-sha256-ce |
नहीं |
1. मॉड्यूल के AES-GCM को लागू करने के तरीके को एल्गोरिदम के तौर पर मंज़ूरी मिल सकती है, लेकिन मॉड्यूल के तौर पर नहीं. इनकी पुष्टि की जा सकती है. हालांकि, FIPS मॉड्यूल के हिसाब से AES-GCM को मंज़ूरी पा चुके एल्गोरिदम के तौर पर नहीं माना जा सकता. ऐसा इसलिए है, क्योंकि GCM के लिए FIPS मॉड्यूल की ज़रूरी शर्तें, GCM के उन इंप्लीमेंटेशन के साथ काम नहीं करती हैं जो अपने IV जनरेट नहीं करते हैं.
सोर्स से मॉड्यूल बनाना
Android 14 और इसके बाद के वर्शन (android-mainline शामिल है) के लिए, fips140.ko मॉड्यूल को सोर्स से बनाने के लिए, यहां दिए गए निर्देशों का इस्तेमाल करें.
Bazel का इस्तेमाल करके बनाएं:
tools/bazel run //common:fips140_distbuild.sh(लेगसी) की मदद से बनाएँ:BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh
इन कमांड से, कर्नल और fips140.ko मॉड्यूल के साथ-साथ पूरा बिल्ड तैयार होता है. इसमें एचएमएसी-एसएचए256 डाइजेस्ट कॉन्टेंट एम्बेड किया जाता है.
असली उपयोगकर्ता के लिए दिशा-निर्देश
क्रिप्टो ऑफ़िसर के लिए दिशा-निर्देश
कर्नल मॉड्यूल को चलाने के लिए, ऑपरेटिंग सिस्टम को सिर्फ़ एक ऑपरेटर मोड में काम करना चाहिए. इसे Android अपने-आप मैनेज करता है. इसके लिए, प्रोसेसर में मेमोरी मैनेजमेंट हार्डवेयर का इस्तेमाल किया जाता है.
कर्नेल मॉड्यूल को अलग से इंस्टॉल नहीं किया जा सकता. यह डिवाइस के फ़र्मवेयर का हिस्सा होता है और बूट होने पर अपने-आप लोड हो जाता है. यह सिर्फ़ अनुमति वाले मोड में काम करता है.
क्रिप्टो ऑफ़िसर, डिवाइस को रीस्टार्ट करके किसी भी समय सेल्फ़-टेस्ट चला सकता है.
उपयोगकर्ता के लिए निर्देश
कर्नल मॉड्यूल का इस्तेमाल करने वाले उपयोगकर्ता, कर्नल के अन्य कॉम्पोनेंट होते हैं. इन्हें क्रिप्टोग्राफ़िक एल्गोरिदम का इस्तेमाल करना होता है. यह कर्नल मॉड्यूल, एल्गोरिदम के इस्तेमाल में कोई अतिरिक्त लॉजिक नहीं देता. साथ ही, क्रिप्टोग्राफ़िक ऑपरेशन करने के लिए ज़रूरी समय के बाद कोई पैरामीटर सेव नहीं करता.
FIPS के नियमों का पालन करने के लिए, एल्गोरिदम का इस्तेमाल सिर्फ़ उन एल्गोरिदम तक सीमित है जिन्हें मंज़ूरी मिली है. FIPS 140-3 "सेवा इंडिकेटर" की ज़रूरी शर्त को पूरा करने के लिए, मॉड्यूल एक फ़ंक्शन fips140_is_approved_service उपलब्ध कराता है. यह फ़ंक्शन बताता है कि किसी एल्गोरिदम को मंज़ूरी मिली है या नहीं.
अपने-आप जांच करने की सुविधा से जुड़ी गड़बड़ियां
सेल्फ़ टेस्ट फ़ेल होने पर, कर्नेल मॉड्यूल की वजह से कर्नेल पैनिक हो जाता है और डिवाइस बूट नहीं होता. अगर डिवाइस को रीबूट करने से समस्या हल नहीं होती है, तो डिवाइस को रिकवरी मोड में बूट करना होगा. इससे डिवाइस को फिर से फ़्लैश करके समस्या को ठीक किया जा सकेगा.