FIPS 140-3 সার্টিফায়েবল GKI ক্রিপ্টো মডিউল

GKI কার্নেলে fips140.ko নামের একটি Linux কার্নেল মডিউল থাকে যা ক্রিপ্টোগ্রাফিক সফ্টওয়্যার মডিউলের জন্য FIPS 140-3 সংক্রান্ত প্রয়োজনীয়তা মেনে চলে। যে প্রোডাক্টে GKI কার্নেল চলে সেটির প্রয়োজন হলে, এই মডিউলটি FIPS সার্টিফিকেশনের জন্য জমা দেওয়া যেতে পারে।

ক্রিপ্টো রুটিন ব্যবহার করার আগে নিম্নলিখিত FIPS 140-3 সংক্রান্ত প্রয়োজনীয়তা অবশ্যই পূরণ করতে হবে:

  • ক্রিপ্টোগ্রাফিক অ্যালগরিদম উপলভ্য করার আগে মডিউলটিকে অবশ্যই তার নিজস্ব ইন্টিগ্রিটি চেক করতে হবে।
  • মডিউলকে অবশ্যই তার অনুমোদিত ক্রিপ্টোগ্রাফিক অ্যালগরিদম ব্যবহার করতে হবে এবং সেগুলি উপলভ্য করার আগে ক্রিপ্টোগ্রাফিক অ্যালগরিদম সেল্ফ-টেস্টের মাধ্যমে যাচাই করতে হবে।

আলাদা কার্নেল মডিউল কেন

FIPS 140-3 যাচাইকরণ এই ধারণার উপর ভিত্তি করে করা হয় যে, একবার কোনও সফ্টওয়্যার বা হার্ডওয়্যার ভিত্তিক মডিউল সার্টিফায়েড হয়ে গেলে, সেটি আর কখনও পরিবর্তন করা হয় না। পরিবর্তন করা হলে, এটি আবার সার্টিফাই করতে হবে। এটি বর্তমানে ব্যবহৃত সফ্টওয়্যার ডেভেলপমেন্ট প্রসেসের সাথে সরাসরি মেলে না এবং এই প্রয়োজনীয়তার ফলস্বরূপ, FIPS সফ্টওয়্যার মডিউলগুলি সাধারণত ক্রিপ্টোগ্রাফিক কম্পোনেন্টগুলির উপর যতটা সম্ভব নিবিড়ভাবে ফোকাস করার জন্য ডিজাইন করা হয়, যাতে ক্রিপ্টোগ্রাফির সাথে সম্পর্কিত নয় এমন পরিবর্তনগুলির জন্য ক্রিপ্টোগ্রাফির পুনর্মূল্যায়নের প্রয়োজন না হয়।

GKI কার্নেলকে তার সম্পূর্ণ সমর্থিত লাইফস্প্যান চলাকালীন নিয়মিত আপডেট করার জন্য তৈরি করা হয়েছে। এর ফলে, সম্পূর্ণ কার্নেলকে FIPS মডিউলের মধ্যে রাখা সম্ভব হয় না, কারণ প্রতিটি কার্নেল আপডেটের পরে এই ধরনের মডিউলকে আবার সার্টিফাই করতে হয়। "FIPS মডিউল"-কে কার্নেল ইমেজের একটি সাবসেট হিসেবে সংজ্ঞায়িত করলে এই সমস্যার প্রভাব কমবে, তবে এর সমাধান হবে না, কারণ "FIPS মডিউলের<0x0A>" বাইনারি কন্টেন্ট এখনও প্রয়োজনের তুলনায় অনেক বেশি ঘন ঘন পরিবর্তিত হবে।

কার্নেল ভার্সন ৬.১-এর আগে, আরেকটি বিষয় বিবেচনা করা হত যে 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-এ যোগ করা হয়। ডিভাইস বুট করার সময় init-এর লোড করা মডিউলের তালিকা modules.load-এ থাকে।

ইন্টিগ্রিটি সেল্ফ চেক

মডিউল লোড করার সময় FIPS 140-3 কার্নেল মডিউল নিজের .code এবং .rodata বিভাগের HMAC-SHA256 ডাইজেস্ট নেয় এবং মডিউলে রেকর্ড করা ডাইজেস্টের সাথে তুলনা করে। Linux মডিউল লোডার ELF রিলোকেশন প্রসেসিং এবং CPU ত্রুটির জন্য বিকল্প প্যাচিংয়ের মতো সাধারণ পরিবর্তনগুলি করার পরে এটি ঘটে। ডাইজেস্ট যাতে সঠিকভাবে পুনরুৎপাদন করা যায় তা নিশ্চিত করতে নিম্নলিখিত অতিরিক্ত ধাপ নেওয়া হয়:

  • মডিউলের মধ্যে ELF রিলোকেশন সংরক্ষিত থাকে যাতে HMAC-এর ইনপুটে রিভার্স প্রসেস প্রয়োগ করা যায়।
  • Dynamic Shadow কল স্ট্যাকের জন্য কার্নেল দ্বারা তৈরি করা যেকোনও কোড প্যাচ মডিউলটি রিভার্স করে। নির্দিষ্টভাবে, এই মডিউল এমন যেকোনও নির্দেশকে প্রতিস্থাপন করে যা শ্যাডো কল স্ট্যাক থেকে পুশ বা পপ করে এবং এর সাথে পয়েন্টার যাচাইকরণ কোড (PAC) নির্দেশ থাকে যা আগে থেকেই উপস্থিত ছিল।
  • মডিউলের জন্য অন্য সব কোড প্যাচিং বন্ধ করা আছে, এর মধ্যে স্ট্যাটিক কী এবং সেই জন্য ট্রেসপয়েন্ট ও ভেন্ডর হুকও অন্তর্ভুক্ত।

ক্রিপ্টোগ্রাফিক অ্যালগরিদম সেল্ফ-টেস্ট করে

FIPS 140-3 কার্নেল মডিউল, পরিচিত উত্তর পরীক্ষা প্রয়োগ করার মাধ্যমে FIPS 140-3-এর ক্রিপ্টোগ্রাফিক অ্যালগরিদম সেল্ফ-টেস্ট সংক্রান্ত প্রয়োজনীয়তা পূরণ করে। প্রয়োগ করা পরীক্ষাগুলি অ্যালগরিদম অনুযায়ী আলাদা হয় এবং FIPS 140-3 প্রয়োগ সংক্রান্ত নির্দেশিকা 10.3.A মেনে চলে।

সাধারণত, প্রতিটি অ্যালগরিদমের জন্য একটি করে টেস্ট ভেক্টর প্রয়োজন। FIPS ক্রিপ্টোগ্রাফিক অ্যালগরিদম সেল্ফ-টেস্ট শুধুমাত্র প্রাথমিক কার্যকারিতা যাচাই করার জন্য ডিজাইন করা হয়েছে। ক্রিপ্টোগ্রাফিক অ্যালগরিদম ভ্যালিডেশন প্রোগ্রাম (CAVP) এবং আপস্ট্রিম কার্নেলের ক্রিপ্টোগ্রাফিক টেস্ট স্যুট ব্যবহার করে আলাদাভাবে বিস্তারিত পরীক্ষা করা হয়।

কোনও অ্যালগরিদমে একাধিক ইমপ্লিমেন্টেশন থাকলে যা ব্যবহারকারী অ্যাক্সেস করতে পারেন বা মডিউলের পরিষেবা ব্যবহার করে, FIPS 140-3-এর জন্য সেইসব ইমপ্লিমেন্টেশন সেল্ফ-টেস্ট করতে হয়। এটি Linux CryptoAPI-এর সাথে ইন্টিগ্রেশন স্ট্র্যাটেজির সাথে প্রাসঙ্গিক যা ঐতিহ্যগতভাবে ব্যবহার করা হয়, যেখানে প্রতিটি অ্যালগরিদমের একাধিক ব্যবহারকারী-অ্যাক্সেসযোগ্য ইমপ্লিমেন্টেশন থাকতে পারে। যেমন, android16-6.12 কার্নেলে, SHA-256-এর তিনটি ইমপ্লিমেন্টেশন আছে: sha256-generic, sha256-arm64 এবং sha256-ce। ARMv8 ক্রিপ্টো এক্সটেনশন সহ CPU-তে, ডিফল্ট হিসেবে sha256-ce ব্যবহার করা হয়, তবে ব্যবহারকারীরা এখনও অন্যগুলি স্পষ্টভাবে অ্যাক্সেস করতে পারবেন। তাই, মডিউলটি তিনটি ইমপ্লিমেন্টেশনই সেল্ফ-টেস্ট করে।

android17-6.18 ও এর পরের ভার্সনের কার্নেলে, কিছু অ্যালগরিদম আরও সহজ ইন্টিগ্রেশন স্ট্র্যাটেজি ব্যবহার করে। যেমন, android17-6.18 কার্নেলে, SHA-256-এর একটি সিঙ্গেল ইমপ্লিমেন্টেশন sha256-lib আছে যা মডিউল লোড করার সময় CPU-এর জন্য উপযুক্ত কোড অটোমেটিক বেছে নেয়। তাই, মডিউলটি শুধু সেল্ফ-টেস্ট করে 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 লাইব্রেরি হ্যাঁ কোনও মোড অফ অপারেশন ছাড়াই সাধারণ AES ব্লক সাইফার: সব কী সাইজ (১২৮ বিট, ১৯২ বিট ও ২৫৬ বিট) কাজ করে। লাইব্রেরি প্রয়োগ করা ছাড়া অন্য সব প্রয়োগ একটি টেমপ্লেটের মাধ্যমে অপারেশন মোড দিয়ে কম্পোজ করা যেতে পারে।
cmac(aes) cmac (টেমপ্লেট), cmac-aes-neon, cmac-aes-ce হ্যাঁ AES-CMAC: সব AES কী-এর সাইজ কাজ করে। cmac টেমপ্লেটটি cmac() ব্যবহার করে aes-এর যেকোনও ইমপ্লিমেন্টেশনের সাথে কম্পোজ করা যেতে পারে। অন্যান্য প্রয়োগগুলি স্বতন্ত্র।
ecb(aes) ecb (টেমপ্লেট), ecb-aes-neon, ecb-aes-neonbs, ecb-aes-ce হ্যাঁ AES-ECB: সব AES কী-এর সাইজ কাজ করে। 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: ব্যবহৃত কনভেনশন হল CS3; শেষ দুটি সাইফারটেক্সট ব্লক শর্তহীনভাবে সোয়্যাপ করা হয়। AES কী সাইজের সবকটিই কাজ করে। cts টেমপ্লেটটি cts() ব্যবহার করে cbc-এর যেকোনও ইমপ্লিমেন্টেশনের সাথে কম্পোজ করা যেতে পারে। অন্যান্য প্রয়োগগুলি স্বতন্ত্র।
ctr(aes) ctr (টেমপ্লেট), ctr-aes-neon, ctr-aes-neonbs, ctr-aes-ce হ্যাঁ AES-CTR: সব AES কী-এর সাইজ কাজ করে। 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 না ১ AES-GCM: সব AES কী-এর সাইজ কাজ করে। শুধুমাত্র ৯৬-বিট IV কাজ করে। এই মডিউলের অন্যান্য সব AES মোডের মতো, IV প্রদান করার দায়িত্ব কলারের। gcm টেমপ্লেটটি gcm_base(,) ব্যবহার করে ctr(aes) ও ghash-এর যেকোনও প্রয়োগের মাধ্যমে কম্পোজ করা যেতে পারে। অন্যান্য প্রয়োগগুলি স্বতন্ত্র।
sha1 Kernel 6.12 ও তার আগের যেকোনও ভার্সন: sha1-generic, sha1-ce হ্যাঁ SHA-1 ক্রিপ্টোগ্রাফিক হ্যাশ ফাংশন। 6.18 ও তার পরের যেকোনও ভার্সনে সরিয়ে দেওয়া হয়েছে।
sha224 Kernel 6.18 ও তার পরের যেকোনও ভার্সন: sha224-lib. Kernel 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 হ্যাঁ আগেরটির মতোই, তবে ২৫৬-বিট ডাইজেস্ট দৈর্ঘ্য (SHA3-256) সহ। সব ডাইজেস্টের দৈর্ঘ্য একই Keccak ইমপ্লিমেন্টেশন ব্যবহার করে।
sha3-384 Kernel 6.6 ও তার পরের যেকোনও ভার্সন: sha3-384-generic হ্যাঁ আগেরটির মতোই, তবে ৩৮৪-বিট ডাইজেস্ট দৈর্ঘ্য (SHA3-৩৮৪) সহ। সব ডাইজেস্ট দৈর্ঘ্যে একই Keccak প্রয়োগ করা হয়।
sha3-512 Kernel 6.6 ও তার পরের যেকোনও ভার্সন: sha3-512-generic হ্যাঁ আগেরটির মতোই, তবে ৫১২-বিট ডাইজেস্ট দৈর্ঘ্য (SHA3-512) সহ। সব ডাইজেস্ট দৈর্ঘ্যে একই Keccak প্রয়োগ করা হয়।
hmac 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_* অ্যালগরিদমের মতোই, তবে পূর্বাভাষ প্রতিরোধ করার সুবিধা বন্ধ করা আছে। কোডটি প্রেডিকশন-রেজিস্ট্যান্ট ভেরিয়েন্টের সাথে শেয়ার করা হয়। কার্নেল ৫.১০-এ, সর্বোচ্চ-অগ্রাধিকার 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 এবং তার পরের)। এই ইন্টারফেসের ব্যবহারকারীরা তাদের নিজস্ব জিটার 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 না

১. মডিউলের AES-GCM ইমপ্লিমেন্টেশন অ্যালগরিদম অনুমোদিত হতে পারে, কিন্তু মডিউল অনুমোদিত নাও হতে পারে। এগুলি যাচাই করা যেতে পারে, তবে AES-GCM-কে FIPS মডিউলের দৃষ্টিকোণ থেকে অনুমোদিত অ্যালগরিদম হিসেবে বিবেচনা করা যাবে না। এর কারণ হল, GCM-এর জন্য FIPS মডিউল সংক্রান্ত প্রয়োজনীয়তা, GCM ইমপ্লিমেন্টেশনের সাথে সামঞ্জস্যপূর্ণ নয়, যা নিজস্ব IV তৈরি করে না।

সোর্স থেকে মডিউল তৈরি করা

Android 14 ও তার পরের যেকোনও ভার্সনের (এর মধ্যে android-mainline) জন্য, সোর্স থেকে fips140.ko মডিউল তৈরি করতে নিচের কমান্ডগুলি ব্যবহার করুন।

  • Bazel-এর সাহায্যে তৈরি করুন:

    tools/bazel run //common:fips140_dist
  • build.sh (পুরনো) দিয়ে তৈরি করুন:

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

এইসব কমান্ড, কার্নেল ও fips140.ko মডিউল সহ সম্পূর্ণ বিল্ড পারফর্ম করে, যার মধ্যে HMAC-SHA256 ডাইজেস্ট কন্টেন্ট এম্বেড করা থাকে।

ব্যবহারকারীর জন্য নির্দেশিকা

ক্রিপ্টো অফিসার সংক্রান্ত নির্দেশিকা

কার্নেল মডিউল অপারেট করতে, অপারেটিং সিস্টেমকে অবশ্যই একটি একক অপারেটর মোডে সীমাবদ্ধ থাকতে হবে। প্রসেসরের মেমরি ম্যানেজমেন্ট হার্ডওয়্যার ব্যবহার করে Android এটি অটোমেটিক ম্যানেজ করে।

কার্নেল মডিউল আলাদাভাবে ইনস্টল করা যায় না; এটি ডিভাইস ফার্মওয়্যারের অংশ হিসেবে অন্তর্ভুক্ত থাকে এবং বুট করার সময় অটোমেটিক লোড হয়। এটি শুধুমাত্র অনুমোদিত মোডে কাজ করে।

ক্রিপ্টো অফিসার যেকোনও সময় ডিভাইস রিস্টার্ট করে সেল্ফ-টেস্ট রান করতে পারেন।

ব্যবহারকারীর নির্দেশিকা

কার্নেল মডিউলের ব্যবহারকারী হল অন্যান্য কার্নেল কম্পোনেন্ট যেগুলিকে ক্রিপ্টোগ্রাফিক অ্যালগরিদম ব্যবহার করতে হয়। কার্নেল মডিউল অ্যালগরিদম ব্যবহারের ক্ষেত্রে অতিরিক্ত যুক্তি প্রদান করে না এবং ক্রিপ্টোগ্রাফিক অপারেশন পারফর্ম করার জন্য প্রয়োজনীয় সময় ব্যতীত কোনও প্যারামিটার স্টোর করে না।

FIPS মেনে চলার উদ্দেশ্যে অ্যালগরিদম ব্যবহার অনুমোদিত অ্যালগরিদমের মধ্যে সীমাবদ্ধ। FIPS 140-3 "পরিষেবা সূচক" সংক্রান্ত প্রয়োজনীয়তা পূরণ করতে, মডিউল fips140_is_approved_service এমন একটি ফাংশন প্রদান করে যা কোনও অ্যালগরিদম অনুমোদিত কিনা তা নির্দেশ করে।

সেল্ফ-টেস্ট সংক্রান্ত সমস্যা

সেল্ফ টেস্টে সমস্যা হলে, কার্নেল মডিউল কার্নেলকে প্যানিক করে তোলে এবং ডিভাইস বুট করা চালিয়ে যায় না। ডিভাইস রিবুট করার পরেও সমস্যার সমাধান না হলে, ডিভাইসটি রি-ফ্ল্যাশ করে সমস্যাটি সমাধান করার জন্য ডিভাইসটিকে অবশ্যই রিকভারি মোডে বুট করতে হবে।