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

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

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

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

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

ডিজাইন

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

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

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

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

মূল অনুক্রম

কীগুলি একটি KDF (কী ডেরিভেশন ফাংশন) যেমন HKDF ব্যবহার করে অন্যান্য কী থেকে প্রাপ্ত করা যেতে পারে, যার ফলে একটি কী শ্রেণিবিন্যাস হয় ।

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

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

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

বিপরীতে, নিম্নোক্ত চিত্রটি FBE-এর জন্য কী অনুক্রমকে চিত্রিত করে যখন হার্ডওয়্যার-র্যাপড কী ব্যবহার করা হয়:

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

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

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

প্রযুক্তিগতভাবে, নিরাপত্তার প্রয়োজনীয়তা পূরণ করে এমন কোনো KDF ব্যবহার করা যেতে পারে। যাইহোক, পরীক্ষার উদ্দেশ্যে, পরীক্ষার কোডে একই KDF পুনরায় প্রয়োগ করা প্রয়োজন। বর্তমানে, একটি KDF পর্যালোচনা করা হয়েছে এবং বাস্তবায়িত হয়েছে; এটি vts_kernel_encryption_test এর সোর্স কোডে পাওয়া যাবে। এটা বাঞ্ছনীয় যে হার্ডওয়্যার এই KDF ব্যবহার করে, যেটি PRF হিসাবে AES-256- CMAC-এর সাথে NIST SP 800-108 "কাউন্টার মোডে KDF" ব্যবহার করে। মনে রাখবেন যে সামঞ্জস্যপূর্ণ হতে, অ্যালগরিদমের সমস্ত অংশ অবশ্যই অভিন্ন হতে হবে, প্রতিটি সাবকির জন্য KDF প্রসঙ্গ এবং লেবেলগুলির পছন্দ সহ।

কী মোড়ানো

হার্ডওয়্যার-র্যাপড কীগুলির নিরাপত্তা লক্ষ্য পূরণের জন্য, দুটি ধরণের কী মোড়ানো সংজ্ঞায়িত করা হয়েছে:

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

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

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

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

• স্টোরেজ কী তৈরি এবং আমদানি করতে ইন্টারফেস, দীর্ঘমেয়াদী মোড়ানো আকারে সেগুলি ফেরত দেয়। এই ইন্টারফেসগুলি কীমিন্টের মাধ্যমে পরোক্ষভাবে অ্যাক্সেস করা হয় এবং এগুলি TAG_STORAGE_KEY কীমিন্ট ট্যাগের সাথে মিলে যায়৷ "জেনারেট" ক্ষমতাটি vold দ্বারা অ্যান্ড্রয়েডের ব্যবহারের জন্য নতুন স্টোরেজ কী তৈরি করতে ব্যবহৃত হয়, যখন "আমদানি" ক্ষমতাটি পরীক্ষা কীগুলি আমদানি করতে vts_kernel_encryption_test দ্বারা ব্যবহৃত হয়।
• একটি দীর্ঘমেয়াদী মোড়ানো স্টোরেজ কীকে একটি ক্ষণস্থায়ীভাবে মোড়ানো স্টোরেজ কীতে রূপান্তর করার জন্য একটি ইন্টারফেস। এটি convertStorageKeyToEphemeral KeyMint পদ্ধতির সাথে মিলে যায়। স্টোরেজ আনলক করার জন্য এই পদ্ধতিটি vold এবং vts_kernel_encryption_test উভয়ই ব্যবহার করা হয়।

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

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

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

যাইহোক, কিছু বাস্তবায়ন-নির্দিষ্ট পরিবর্তন প্রয়োজন।

কীমিন্ট পরিবর্তন

TAG_STORAGE_KEY সমর্থন করতে এবং convertStorageKeyToEphemeral পদ্ধতি প্রয়োগ করতে ডিভাইসের KeyMint বাস্তবায়ন পরিবর্তন করতে হবে৷

কীমাস্টারে, exportKey এর পরিবর্তে convertStorageKeyToEphemeral ব্যবহার করা হয়েছিল।

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

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

android14 এবং উচ্চতর কার্নেলের জন্য, blk_crypto_profile::key_types_supported BLK_CRYPTO_KEY_TYPE_HW_WRAPPED BLK_CRYPTO_KEY_TYPE_HW_WRAPPED সেট করুন , blk_crypto_ll_ops blk_crypto_ll_ops::derive_sw_secret blk_crypto_ll_ops::keyslot_program এবং blk_crypto_ll_ops::keyslot_evict জন্য

android12 . এবং android13 কার্নেলের জন্য, blk_keyslot_manager::features এ BLK_CRYPTO_FEATURE_WRAPPED_KEYS সেট করুন, blk_ksm_ll_ops::keyslot_program এবং blk_ksm_ll_ops::keyslot_evict -keyslot_evict এবং keyslot_evict programs:keyslot_evicting/ 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_programming এবং keyslot_mgmt_evict keyslot_mgmt-এবং-প্রোগ্রামিং- keyslot_mgmt_ll_ops::derive_raw_secret

পরীক্ষামূলক

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

atest -v vts_kernel_encryption_test

পরীক্ষার লগ পড়ুন এবং যাচাই করুন যে হার্ডওয়্যার-র্যাপড কী পরীক্ষার ক্ষেত্রে (যেমন FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy এবং DmDefaultKeyTest.TestHwWrappedKey ) হার্ডওয়্যার-র্যাপড কীগুলির সমর্থনের কারণে এড়িয়ে যাওয়া হয়নি, "পরীক্ষায় এখনও ফলাফল সনাক্ত করা যাচ্ছে না" যে ক্ষেত্রে

সক্রিয় করা হচ্ছে

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

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