হার্ডওয়্যার-মোড়ানো কী

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

ঐতিহ্যগতভাবে এটিকে কোনো সমস্যা হিসেবে দেখা হয় না, কারণ অফলাইন আক্রমণের সময় কীগুলো উপস্থিত থাকে না, এবং স্টোরেজ এনক্রিপশন মূলত এই ধরনের আক্রমণ থেকেই সুরক্ষা দেওয়ার জন্য তৈরি। তবে, অন্যান্য ধরনের আক্রমণ, যেমন কোল্ড বুট অ্যাটাক এবং অনলাইন আক্রমণের বিরুদ্ধে বাড়তি সুরক্ষা দেওয়ার একটি আকাঙ্ক্ষা রয়েছে, যেখানে একজন আক্রমণকারী ডিভাইসটিকে সম্পূর্ণরূপে ক্ষতিগ্রস্ত না করেই সিস্টেম মেমরি ফাঁস করতে সক্ষম হতে পারে।

এই সমস্যা সমাধানের জন্য, অ্যান্ড্রয়েড ১১ হার্ডওয়্যার-র‍্যাপড কী- এর সাপোর্ট চালু করেছে, যেখানে হার্ডওয়্যারের সাপোর্ট বিদ্যমান। হার্ডওয়্যার-র‍্যাপড কী হলো এমন স্টোরেজ কী যা শুধুমাত্র নির্দিষ্ট হার্ডওয়্যারের কাছেই তার মূল রূপে পরিচিত থাকে; সফটওয়্যার এই কী-গুলো কেবল র‍্যাপড (এনক্রিপ্টেড) রূপে দেখতে ও ব্যবহার করতে পারে। এই হার্ডওয়্যারকে অবশ্যই স্টোরেজ কী তৈরি ও ইম্পোর্ট করতে, স্টোরেজ কী-গুলোকে ক্ষণস্থায়ী ও দীর্ঘমেয়াদী রূপে র‍্যাপ করতে, সাব-কী ডিরাইভ করতে, সরাসরি একটি সাব-কী ইনলাইন ক্রিপ্টো ইঞ্জিনে প্রোগ্রাম করতে এবং সফটওয়্যারকে একটি পৃথক সাব-কী ফেরত দিতে সক্ষম হতে হবে।

দ্রষ্টব্য: একটি ইনলাইন ক্রিপ্টো ইঞ্জিন (বা ইনলাইন এনক্রিপশন হার্ডওয়্যার ) বলতে এমন হার্ডওয়্যারকে বোঝায় যা স্টোরেজ ডিভাইসে ডেটা আসা-যাওয়ার পথে সেটিকে এনক্রিপ্ট/ডিক্রিপ্ট করে। সাধারণত এটি একটি UFS বা eMMC হোস্ট কন্ট্রোলার যা সংশ্লিষ্ট JEDEC স্পেসিফিকেশন দ্বারা সংজ্ঞায়িত ক্রিপ্টো এক্সটেনশনগুলো বাস্তবায়ন করে।

ডিজাইন

এই অংশে হার্ডওয়্যার-র‍্যাপড কী ফিচারের ডিজাইন উপস্থাপন করা হয়েছে, যার মধ্যে এর জন্য প্রয়োজনীয় হার্ডওয়্যার সাপোর্টও অন্তর্ভুক্ত রয়েছে। এই আলোচনাটি ফাইল-ভিত্তিক এনক্রিপশন (FBE)-এর উপর আলোকপাত করে, কিন্তু এই সমাধানটি মেটাডেটা এনক্রিপশনের ক্ষেত্রেও প্রযোজ্য।

সিস্টেম মেমরিতে সরাসরি এনক্রিপশন কী রাখার প্রয়োজনীয়তা এড়ানোর একটি উপায় হলো, সেগুলোকে শুধুমাত্র একটি ইনলাইন ক্রিপ্টো ইঞ্জিনের কী-স্লটগুলোতে রাখা। তবে, এই পদ্ধতিতে কিছু সমস্যা দেখা দেয়:

• এনক্রিপশন কী-এর সংখ্যা কী-স্লটের সংখ্যাকে অতিক্রম করতে পারে।
• স্টোরেজ হোস্ট কন্ট্রোলার রিসেট করা হলে ইনলাইন ক্রিপ্টো ইঞ্জিনগুলো সাধারণত তাদের কী-স্লটের ডেটা হারিয়ে ফেলে। স্টোরেজ হোস্ট কন্ট্রোলার রিসেট করা একটি সাধারণ ত্রুটি পুনরুদ্ধার প্রক্রিয়া, যা নির্দিষ্ট ধরনের স্টোরেজ ত্রুটি ঘটলে কার্যকর করা হয় এবং এই ধরনের ত্রুটি যেকোনো সময় ঘটতে পারে। তাই, ইনলাইন ক্রিপ্টো ব্যবহারের সময়, ব্যবহারকারীর হস্তক্ষেপ ছাড়াই কী-স্লটগুলো পুনরায় প্রোগ্রাম করার জন্য অপারেটিং সিস্টেমকে সর্বদা প্রস্তুত থাকতে হবে।
• ইনলাইন ক্রিপ্টো ইঞ্জিন শুধুমাত্র ডিস্কে থাকা ডেটার সম্পূর্ণ ব্লক এনক্রিপ্ট/ডিক্রিপ্ট করতে ব্যবহার করা যায়। তবে, FBE-এর ক্ষেত্রে, সফটওয়্যারকে ফাইলের নাম এনক্রিপশন এবং কী আইডেন্টিফায়ার বের করার মতো অন্যান্য ক্রিপ্টোগ্রাফিক কাজও করতে সক্ষম হতে হয়। এই অন্যান্য কাজগুলো করার জন্য সফটওয়্যারটির র FBE কী-গুলোতে অ্যাক্সেসের প্রয়োজন হবে।

এই সমস্যাগুলো এড়ানোর জন্য, স্টোরেজ কীগুলোকে হার্ডওয়্যার-র‍্যাপড কী- তে রূপান্তরিত করা হয়, যা শুধুমাত্র নির্দিষ্ট হার্ডওয়্যার দ্বারাই আনর‍্যাপ ও ব্যবহার করা যায়। এর ফলে অসীম সংখ্যক কী সমর্থন করা সম্ভব হয়। এছাড়াও, কী-এর স্তরবিন্যাস পরিবর্তন করে আংশিকভাবে এই হার্ডওয়্যারে স্থানান্তর করা হয়, যা এমন সব কাজের জন্য সফটওয়্যারে একটি সাব-কী ফেরত পাঠানোর সুযোগ করে দেয়, যেগুলো ইনলাইন ক্রিপ্টো ইঞ্জিন ব্যবহার করতে পারে না।

মূল শ্রেণিবিন্যাস

HKDF- এর মতো একটি কী ডিরাইভেশন ফাংশন (KDF) ব্যবহার করে অন্যান্য কী থেকে কী তৈরি করা যায়, যার ফলে একটি কী হায়ারার্কি তৈরি হয়।

নিম্নলিখিত ডায়াগ্রামটি FBE-এর একটি সাধারণ কী হায়ারার্কি চিত্রিত করে, যখন হার্ডওয়্যার-র‍্যাপড কী ব্যবহার করা হয় না :

FBE ক্লাস কী হলো মূল এনক্রিপশন কী, যা অ্যান্ড্রয়েড কোনো নির্দিষ্ট অ্যান্ড্রয়েড ব্যবহারকারীর ক্রেডেনশিয়াল-এনক্রিপ্টেড স্টোরেজের মতো এনক্রিপ্টেড ডিরেক্টরিগুলোর একটি নির্দিষ্ট সেট আনলক করার জন্য লিনাক্স কার্নেলের কাছে পাঠায়। (কার্নেলে, এই কী-টিকে fscrypt মাস্টার কী বলা হয়।) এই কী থেকে কার্নেল নিম্নলিখিত সাব-কীগুলো তৈরি করে:

• কী আইডেন্টিফায়ার। এটি এনক্রিপশনের জন্য ব্যবহৃত হয় না, বরং এটি এমন একটি মান যা কোনো নির্দিষ্ট ফাইল বা ডিরেক্টরি যে কী দ্বারা সুরক্ষিত, সেই কী-টিকে শনাক্ত করতে ব্যবহৃত হয়।
• ফাইলের বিষয়বস্তু এনক্রিপশন কী
• ফাইলের নাম এনক্রিপশন কী

এর বিপরীতে, হার্ডওয়্যার-র‍্যাপড কী ব্যবহার করা হলে FBE-এর জন্য কী-এর স্তরক্রম নিম্নলিখিত ডায়াগ্রামে দেখানো হয়েছে:

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

• inline_encryption_key তৈরি করতে এবং সরাসরি ইনলাইন ক্রিপ্টো ইঞ্জিনের একটি কী-স্লটে প্রোগ্রাম করার জন্য একটি ইন্টারফেস রয়েছে। এর ফলে, সফটওয়্যারের কাছে র কী (raw key)-এর অ্যাক্সেস ছাড়াই ফাইলের বিষয়বস্তু এনক্রিপ্ট/ডিক্রিপ্ট করা যায়। অ্যান্ড্রয়েড কমন কার্নেলগুলোতে, এই ইন্টারফেসটি blk_crypto_ll_ops::keyslot_program অপারেশনের সাথে সঙ্গতিপূর্ণ, যা স্টোরেজ ড্রাইভার দ্বারা অবশ্যই ইমপ্লিমেন্ট করতে হবে।
• sw_secret ("সফটওয়্যার সিক্রেট" -- যা পূর্বে "র সিক্রেট" নামে পরিচিত ছিল) ডিরাইভ ও রিটার্ন করার জন্য একটি ইন্টারফেস রয়েছে। এই sw_secret হলো সেই কী যা লিনাক্স ফাইলের বিষয়বস্তু এনক্রিপশন ছাড়া অন্য সবকিছুর জন্য সাব-কী ডিরাইভ করতে ব্যবহার করে। অ্যান্ড্রয়েড কমন কার্নেলগুলোতে, এই ইন্টারফেসটি blk_crypto_ll_ops::derive_sw_secret অপারেশনের সাথে সঙ্গতিপূর্ণ, যা স্টোরেজ ড্রাইভার দ্বারা অবশ্যই ইমপ্লিমেন্ট করতে হবে।

র স্টোরেজ কী থেকে inline_encryption_key এবং sw_secret তৈরি করার জন্য, হার্ডওয়্যারকে অবশ্যই একটি ক্রিপ্টোগ্রাফিকভাবে শক্তিশালী কেডিএফ (KDF) ব্যবহার করতে হবে। এই কেডিএফ-কে অবশ্যই ক্রিপ্টোগ্রাফির সর্বোত্তম অনুশীলন অনুসরণ করতে হবে; এর নিরাপত্তা শক্তি কমপক্ষে ২৫৬ বিট হতে হবে, অর্থাৎ, পরবর্তীতে ব্যবহৃত যেকোনো অ্যালগরিদমের জন্য যথেষ্ট। প্রতিটি ধরণের সাব-কী তৈরি করার সময় এটিকে অবশ্যই একটি স্বতন্ত্র লেবেল এবং কনটেক্সট ব্যবহার করতে হবে, যাতে নিশ্চিত করা যায় যে ফলস্বরূপ সাব-কীগুলো ক্রিপ্টোগ্রাফিকভাবে বিচ্ছিন্ন থাকে, অর্থাৎ, এদের কোনো একটির জ্ঞান অন্যটিকে প্রকাশ করে না। কী স্ট্রেচিং-এর প্রয়োজন নেই, কারণ র স্টোরেজ কী ইতিমধ্যেই একটি ইউনিফর্মলি র‍্যান্ডম কী।

প্রযুক্তিগতভাবে, নিরাপত্তা শর্ত পূরণ করে এমন যেকোনো KDF ব্যবহার করা যেতে পারে। তবে, পরীক্ষার উদ্দেশ্যে, vts_kernel_encryption_test সফটওয়্যারের মাধ্যমে একই KDF প্রয়োগ করে ডিস্কের সাইফারটেক্সট পুনরুৎপাদন করে এবং এর সঠিকতা যাচাই করে। পরীক্ষার সুবিধার জন্য এবং একটি নিরাপদ ও পূর্ব-পর্যালোচিত KDF ব্যবহৃত হচ্ছে তা নিশ্চিত করতে, আমরা সুপারিশ করি যে হার্ডওয়্যারটি সেই ডিফল্ট KDF প্রয়োগ করবে যা পরীক্ষাটি যাচাই করে। যে হার্ডওয়্যার ভিন্ন KDF ব্যবহার করে, সেটির জন্য পরীক্ষাটি কীভাবে কনফিগার করতে হবে তা জানতে "Test wrapped keys" দেখুন।

চাবি মোড়ানো

হার্ডওয়্যার-র‍্যাপড কী-এর নিরাপত্তা লক্ষ্য পূরণের জন্য দুই ধরনের কী র‍্যাপিং সংজ্ঞায়িত করা হয়েছে:

• ক্ষণস্থায়ী আবরণ : হার্ডওয়্যারটি প্রতিটি বুটের সময় দৈবচয়নের মাধ্যমে তৈরি একটি কী ব্যবহার করে মূল কী-টিকে এনক্রিপ্ট করে, যা হার্ডওয়্যারের বাইরে সরাসরি উন্মুক্ত থাকে না।
• দীর্ঘমেয়াদী র‍্যাপিং : হার্ডওয়্যারটি তার অভ্যন্তরে নির্মিত একটি অনন্য, স্থায়ী কী ব্যবহার করে মূল কী-টিকে এনক্রিপ্ট করে, যা হার্ডওয়্যারের বাইরে সরাসরি উন্মুক্ত থাকে না।

স্টোরেজ আনলক করার জন্য লিনাক্স কার্নেলে পাঠানো সমস্ত কী ক্ষণস্থায়ীভাবে মোড়ানো থাকে। এটি নিশ্চিত করে যে, যদি কোনো আক্রমণকারী সিস্টেম মেমরি থেকে একটি ব্যবহৃত কী বের করতে সক্ষমও হয়, তবে সেই কীটি কেবল ডিভাইসের বাইরেই নয়, রিবুটের পরেও ডিভাইসের ভেতরেও অব্যবহারযোগ্য থাকবে।

একই সাথে, অ্যান্ড্রয়েডের ডিস্কে কী-গুলোর একটি এনক্রিপ্টেড সংস্করণ সংরক্ষণ করার সক্ষমতা থাকা প্রয়োজন, যাতে সেগুলোকে প্রথমেই আনলক করা যায়। এই উদ্দেশ্যে র কী-গুলো কাজ করবে। তবে, এটা কাম্য যে র কী-গুলো যেন কখনোই সিস্টেম মেমরিতে উপস্থিত না থাকে, যাতে বুট করার সময় বের করা হলেও সেগুলোকে ডিভাইসের বাইরে ব্যবহারের জন্য কখনো বের করা না যায়। এই কারণেই লং-টার্ম র‍্যাপিং-এর ধারণাটি সংজ্ঞায়িত করা হয়েছে।

এই দুটি ভিন্ন উপায়ে মোড়ানো কী-গুলো পরিচালনা সমর্থন করার জন্য, হার্ডওয়্যারটিকে অবশ্যই নিম্নলিখিত ইন্টারফেসগুলো বাস্তবায়ন করতে হবে:

• স্টোরেজ কী তৈরি এবং ইম্পোর্ট করার জন্য ইন্টারফেস, যা সেগুলোকে দীর্ঘমেয়াদী র‍্যাপড ফর্মে ফেরত দেয়। generate ইন্টারফেসটি vold দ্বারা Android-এর ব্যবহারের জন্য নতুন স্টোরেজ কী তৈরি করতে ব্যবহৃত হয়। import ইন্টারফেসটি vts_kernel_encryption_test দ্বারা টেস্ট কী ইম্পোর্ট করতে ব্যবহৃত হয়।
• একটি দীর্ঘমেয়াদী র‍্যাপড স্টোরেজ কী-কে একটি ক্ষণস্থায়ী র‍্যাপড স্টোরেজ কী-তে রূপান্তর করার জন্য একটি ইন্টারফেস। এই ইন্টারফেসটি vold এবং vts_kernel_encryption_test উভয়ই স্টোরেজ আনলক করার জন্য ব্যবহার করে।

কী র‍্যাপিং অ্যালগরিদমটি একটি বাস্তবায়নগত বিষয়, কিন্তু এতে র‍্যান্ডম IVs সহ AES-256-GCM-এর মতো একটি শক্তিশালী AEAD ব্যবহার করা উচিত।

সফটওয়্যার পরিবর্তন প্রয়োজন

AOSP-তে হার্ডওয়্যার-র‍্যাপড কী সমর্থন করার জন্য ইতিমধ্যেই একটি মৌলিক কাঠামো রয়েছে। এর মধ্যে vold মতো ইউজারস্পেস কম্পোনেন্টগুলিতে সমর্থন, সেইসাথে blk-crypto , fscrypt এবং dm-default-key- তে লিনাক্স কার্নেলের সমর্থন অন্তর্ভুক্ত রয়েছে।

লিনাক্স কার্নেল পরিবর্তন

ইনলাইন এনক্রিপশন সমর্থনসহ ডিভাইসটির স্টোরেজ কন্ট্রোলারের জন্য লিনাক্স কার্নেল ড্রাইভারটিকে হার্ডওয়্যার-র‍্যাপড কী সমর্থন করার জন্য পরিবর্তন করতে হবে।

android17 এবং উচ্চতর কার্নেলের জন্য:

• blk_crypto_profile::key_types_supported এ BLK_CRYPTO_KEY_TYPE_HW_WRAPPED সেট করুন।
• blk_crypto_ll_ops::keyslot_program হার্ডওয়্যার-র‍্যাপড কী প্রোগ্রামিং সমর্থন করার জন্য তৈরি করুন।
• blk_crypto_ll_ops::keyslot_evict হার্ডওয়্যার-র‍্যাপড কী অপসারণে সক্ষম করে তুলুন।
• blk_crypto_ll_ops::derive_sw_secret , blk_crypto_ll_ops::import_key , blk_crypto_ll_ops::generate_key , এবং blk_crypto_ll_ops::prepare_key বাস্তবায়ন করুন।

android14 , android15 এবং android16 কার্নেলগুলোর জন্য:

• blk_crypto_profile::key_types_supported এ BLK_CRYPTO_KEY_TYPE_HW_WRAPPED সেট করুন।
• blk_crypto_ll_ops::keyslot_program হার্ডওয়্যার-র‍্যাপড কী প্রোগ্রামিং সমর্থন করার জন্য তৈরি করুন।
• blk_crypto_ll_ops::keyslot_evict হার্ডওয়্যার-র‍্যাপড কী অপসারণে সক্ষম করে তুলুন।
• blk_crypto_ll_ops::derive_sw_secret বাস্তবায়ন করুন।

android12 এবং android13 কার্নেলের জন্য:

• blk_keyslot_manager::features এ BLK_CRYPTO_FEATURE_WRAPPED_KEYS সেট করুন।
• blk_ksm_ll_ops::keyslot_program হার্ডওয়্যার-র‍্যাপড কী প্রোগ্রামিং সমর্থন করার উপযোগী করে তুলুন।
• blk_ksm_ll_ops::keyslot_evict হার্ডওয়্যার-র‍্যাপড কী অপসারণে সক্ষম করে তুলুন।
• blk_ksm_ll_ops::derive_raw_secret বাস্তবায়ন করুন।

android11 কার্নেলের জন্য:

• keyslot_manager::features এ BLK_CRYPTO_FEATURE_WRAPPED_KEYS সেট করুন।
• keyslot_mgmt_ll_ops::keyslot_program হার্ডওয়্যার-র‍্যাপড কী প্রোগ্রামিং সমর্থন করার জন্য তৈরি করুন।
• keyslot_mgmt_ll_ops::keyslot_evict হার্ডওয়্যার-র‍্যাপড কী অপসারণে সক্ষম করে তুলুন।
• keyslot_mgmt_ll_ops::derive_raw_secret বাস্তবায়ন করুন।

KeyMint পরিবর্তন (পুরানো)

হার্ডওয়্যার-র‍্যাপড কী-এর ( wrappedkey ) বর্তমান সংস্করণে, হার্ডওয়্যার-র‍্যাপড কী তৈরি, ইম্পোর্ট এবং প্রস্তুত করার জন্য লিনাক্স কার্নেলের ioctl-গুলো— BLKCRYPTOGENERATEKEY , BLKCRYPTOIMPORTKEY , এবং BLKCRYPTOPREPAREKEY ব্যবহৃত হয়। এই ioctl-গুলো struct blk_crypto_ll_ops এর মেথডগুলোর সাথে সঙ্গতিপূর্ণ। স্টোরেজ ড্রাইভার এই মেথডগুলো ইমপ্লিমেন্ট করে এবং অনুরোধকৃত অপারেশনটি সম্পাদন করার জন্য কী র‍্যাপিং হার্ডওয়্যারের সাথে যোগাযোগ করে। এই ioctl-গুলো সম্পর্কে আরও তথ্যের জন্য, লিনাক্স কার্নেলের ডকুমেন্টেশন দেখুন।

এই ioctl-গুলো Linux 6.16-এ যোগ করা হয়েছিল। যে ডিভাইসগুলো ioctl-ভিত্তিক সমাধান দিয়ে চালু হয়নি, সেগুলোতে Android KeyMint (বা পূর্বে KeyMaster) ব্যবহার করে একটি ভিন্ন সমাধান ব্যবহৃত হয়। লিগ্যাসি সমাধানটি ( wrappedkey_v0 ) মেইনলাইন Linux কার্নেল বা বর্তমান সমাধানের সাথে সামঞ্জস্যপূর্ণ নয়। লিগ্যাসি সমাধানটি নিম্নলিখিত KeyMint কার্যকারিতা ব্যবহার করে:

• কী তৈরি এবং ইম্পোর্ট, উভয় ক্ষেত্রেই TAG_STORAGE_KEY সমর্থিত।
• convertStorageKeyToEphemeral মেথডটির জন্য সমর্থন।

এই KeyMint কার্যকারিতাটি শুধুমাত্র সেইসব ডিভাইসে প্রয়োজন, যেগুলি লিগ্যাসি সলিউশন ব্যবহার করে এবং যা fstab ফাইলের wrappedkey_v0 সাথে সঙ্গতিপূর্ণ।

যেসব ডিভাইস fstab ফাইলের wrappedkey এর সাথে সঙ্গতিপূর্ণ বর্তমান সমাধানটি ব্যবহার করে, সেগুলোতে এই KeyMint কার্যকারিতাটি বাস্তবায়ন করার প্রয়োজন নেই।

টেস্ট র‍্যাপড কী

যদিও র কী (raw key) দিয়ে এনক্রিপশনের চেয়ে হার্ডওয়্যার-র‍্যাপড কী (hardware-wrapped key) দিয়ে এনক্রিপশন পরীক্ষা করা কঠিন, তবুও একটি টেস্ট কী (test key) ইম্পোর্ট করে এবং হার্ডওয়্যারের কী ডিরাইভেশন (key derivation) প্রক্রিয়াটি পুনরায় ইমপ্লিমেন্ট (re-implement) করে এটি পরীক্ষা করা সম্ভব। এটি vts_kernel_encryption_test এ ইমপ্লিমেন্ট করা হয়েছে। এই পরীক্ষাটি চালানোর জন্য, রান করুন:

atest -v vts_kernel_encryption_test

টেস্ট লগটি পড়ুন এবং যাচাই করুন যে হার্ডওয়্যার-র‍্যাপড কী-এর সাপোর্ট শনাক্ত না হওয়ার কারণে হার্ডওয়্যার-র‍্যাপড কী টেস্ট কেসগুলো (উদাহরণস্বরূপ, FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy এবং DmDefaultKeyTest.TestHwWrappedKey ) বাদ পড়েনি, কারণ সেক্ষেত্রেও টেস্টের ফলাফল "পাসড" দেখাচ্ছে।

ডিফল্টরূপে, vts_kernel_encryption_test ধরে নেয় যে হার্ডওয়্যারটি kdf1 নামক একটি KDF প্রয়োগ করেছে। এই KDF-টি NIST SP 800-108 -এর কাউন্টার মোড পরিবারের অন্তর্গত, এবং এটি সিউডোর‍্যান্ডম ফাংশন হিসেবে AES-256-CMAC ব্যবহার করে। CMAC সম্পর্কে আরও তথ্যের জন্য, CMAC স্পেসিফিকেশন দেখুন। প্রতিটি সাব-কি ডিরাইভ করার সময় KDF-টি নির্দিষ্ট কনটেক্সট এবং লেবেল ব্যবহার করে। হার্ডওয়্যারের এই KDF-টি প্রয়োগ করা উচিত, যার মধ্যে প্রতিটি সাব-কি ডিরাইভ করার সময় কনটেক্সট, লেবেল এবং নির্দিষ্ট ইনপুট স্ট্রিং-এর ফরম্যাটিং-এর সঠিক নির্বাচন অন্তর্ভুক্ত থাকবে।

তবে, vts_kernel_encryption_test অতিরিক্ত KDF, যেমন kdf4 kdf2 প্রয়োগ করে। এগুলো kdf1 মতোই সুরক্ষিত এবং এদের মধ্যে পার্থক্য শুধু কনটেক্সট, লেবেল এবং নির্দিষ্ট ইনপুট স্ট্রিং-এর ফরম্যাটিং-এর ক্ষেত্রে। এগুলো শুধুমাত্র বিভিন্ন হার্ডওয়্যারের সাথে সামঞ্জস্য রাখার জন্যই তৈরি করা হয়েছে।

যেসব ডিভাইস ভিন্ন KDF ব্যবহার করে, সেগুলোর ক্ষেত্রে PRODUCT_VENDOR_PROPERTIES এ থাকা ro.crypto.hw_wrapped_keys.kdf সিস্টেম প্রপার্টিটিকে টেস্ট সোর্স কোডে সংজ্ঞায়িত KDF-এর নামে সেট করুন। এর ফলে vts_kernel_encryption_test kdf1 এর পরিবর্তে সেই KDF-টি চেক করবে। উদাহরণস্বরূপ, kdf2 নির্বাচন করতে, ব্যবহার করুন:

PRODUCT_VENDOR_PROPERTIES += ro.crypto.hw_wrapped_keys.kdf=kdf2

যেসব ডিভাইস এমন KDF ব্যবহার করে যা টেস্টটি সাপোর্ট করে না, সেগুলোর ক্ষেত্রেও টেস্টটিতে সেই KDF-এর একটি ইমপ্লিমেন্টেশন যোগ করুন এবং এটিকে একটি অনন্য নাম দিন।

মোড়ানো কীগুলি সক্ষম করুন

যখন ডিভাইসটির হার্ডওয়্যার-র‍্যাপড কী সাপোর্ট সঠিকভাবে কাজ করবে, তখন অ্যান্ড্রয়েডকে FBE এবং মেটাডেটা এনক্রিপশনের জন্য এটি ব্যবহার করাতে ডিভাইসটির fstab ফাইলে নিম্নলিখিত পরিবর্তনগুলি করুন:

• FBE: fileencryption প্যারামিটারে wrappedkey (অথবা লিগ্যাসি সংস্করণের জন্য wrappedkey_v0 ) ফ্ল্যাগটি যোগ করুন। উদাহরণস্বরূপ, fileencryption=::inlinecrypt_optimized+wrappedkey ব্যবহার করুন। আরও বিস্তারিত জানতে, FBE ডকুমেন্টেশন দেখুন।
• মেটাডেটা এনক্রিপশন: metadata_encryption প্যারামিটারে wrappedkey ফ্ল্যাগটি (অথবা লিগ্যাসি সংস্করণের জন্য wrappedkey_v0 ) যোগ করুন। উদাহরণস্বরূপ, metadata_encryption=:wrappedkey ব্যবহার করুন। আরও বিস্তারিত জানতে, মেটাডেটা এনক্রিপশন ডকুমেন্টেশন দেখুন।

প্রতিটি ক্ষেত্রে, পতাকাটির দুটি সংস্করণ রয়েছে:

• wrappedkey , যা অ্যান্ড্রয়েড ১৭ এবং তার পরবর্তী সংস্করণ দ্বারা সমর্থিত, হার্ডওয়্যার-র‍্যাপড কী-এর বর্তমান সংস্করণটি সক্রিয় করে। এই সংস্করণটি মেইনলাইন লিনাক্স কার্নেলের সাথে সামঞ্জস্যপূর্ণ।
• wrappedkey_v0 , যা Android 11 এবং তার পরবর্তী সংস্করণ দ্বারা সমর্থিত, হার্ডওয়্যার-র‍্যাপড কী-এর লিগ্যাসি সংস্করণটি সক্রিয় করে। এই সংস্করণটি মেইনলাইন লিনাক্স কার্নেলের সাথে সামঞ্জস্যপূর্ণ নয়। এটি KeyMint-এর মাধ্যমে নির্দিষ্ট কিছু অপারেশন প্রক্সি করে এবং একটি নন-স্ট্যান্ডার্ড অন-ডিস্ক ফরম্যাট ব্যবহার করে। আরও তথ্যের জন্য, KeyMint changes (legacy) দেখুন।

অ্যান্ড্রয়েড ১৭ বা তার উচ্চতর সংস্করণে চালু হওয়া ডিভাইসগুলিতে wrappedkey ) ব্যবহার করা শ্রেয়।

যে ডিভাইসগুলো ইতিমধ্যেই wrappedkey_v0 সহ চালু হয়েছে, সেগুলোতে পূর্ববর্তী সংস্করণের সাথে সামঞ্জস্য (backwards compatibility) বজায় রাখতে wrappedkey_v0 ব্যবহার করা চালিয়ে যান।