বেশিরভাগ ডিস্ক এবং ফাইল এনক্রিপশন সফ্টওয়্যারের মতো, অ্যান্ড্রয়েডের স্টোরেজ এনক্রিপশন ঐতিহ্যগতভাবে সিস্টেম মেমরিতে থাকা কাঁচা এনক্রিপশন কীগুলির উপর নির্ভর করে যাতে এনক্রিপশনটি সম্পাদন করা যায়। এমনকি যখন এনক্রিপশন সফ্টওয়্যারের পরিবর্তে ডেডিকেটেড হার্ডওয়্যার দ্বারা সঞ্চালিত হয়, তখনও সাধারণত সফ্টওয়্যারকে কাঁচা এনক্রিপশন কীগুলি পরিচালনা করতে হয়।
এটি ঐতিহ্যগতভাবে একটি সমস্যা হিসাবে দেখা হয় না কারণ একটি অফলাইন আক্রমণের সময় কীগুলি উপস্থিত থাকবে না, এটি হল প্রধান ধরনের আক্রমণ যা থেকে রক্ষা করার জন্য স্টোরেজ এনক্রিপশনের উদ্দেশ্য। যাইহোক, অন্যান্য ধরণের আক্রমণের বিরুদ্ধে বর্ধিত সুরক্ষা প্রদান করার ইচ্ছা রয়েছে, যেমন কোল্ড বুট আক্রমণ এবং অনলাইন আক্রমণ যেখানে একজন আক্রমণকারী ডিভাইসের সাথে সম্পূর্ণ আপস না করে সিস্টেম মেমরি লিক করতে সক্ষম হতে পারে।
এই সমস্যা সমাধানের জন্য, 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 বাস্তবায়ন পরিবর্তন করতে হবে৷
কীমাস্টারে, convertStorageKeyToEphemeral
এর পরিবর্তে exportKey
ব্যবহার করা হয়েছিল।
লিনাক্স কার্নেল পরিবর্তন
ডিভাইসের ইনলাইন ক্রিপ্টো ইঞ্জিনের জন্য লিনাক্স কার্নেল ড্রাইভারকে হার্ডওয়্যার-র্যাপড কী সমর্থন করতে পরিবর্তন করতে হবে।
android14
এবং উচ্চতর কার্নেলের জন্য, 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
-programming এবং 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
ব্যবহার করুন। আরো বিস্তারিত জানার জন্য, মেটাডেটা এনক্রিপশন ডকুমেন্টেশন দেখুন।
বেশিরভাগ ডিস্ক এবং ফাইল এনক্রিপশন সফ্টওয়্যারের মতো, অ্যান্ড্রয়েডের স্টোরেজ এনক্রিপশন ঐতিহ্যগতভাবে সিস্টেম মেমরিতে থাকা কাঁচা এনক্রিপশন কীগুলির উপর নির্ভর করে যাতে এনক্রিপশনটি সম্পাদন করা যায়। এমনকি যখন এনক্রিপশন সফ্টওয়্যারের পরিবর্তে ডেডিকেটেড হার্ডওয়্যার দ্বারা সঞ্চালিত হয়, তখনও সাধারণত সফ্টওয়্যারকে কাঁচা এনক্রিপশন কীগুলি পরিচালনা করতে হয়।
এটি ঐতিহ্যগতভাবে একটি সমস্যা হিসাবে দেখা হয় না কারণ একটি অফলাইন আক্রমণের সময় কীগুলি উপস্থিত থাকবে না, এটি হল প্রধান ধরনের আক্রমণ যা থেকে রক্ষা করার জন্য স্টোরেজ এনক্রিপশনের উদ্দেশ্য। যাইহোক, অন্যান্য ধরণের আক্রমণের বিরুদ্ধে বর্ধিত সুরক্ষা প্রদান করার ইচ্ছা রয়েছে, যেমন কোল্ড বুট আক্রমণ এবং অনলাইন আক্রমণ যেখানে একজন আক্রমণকারী ডিভাইসের সাথে সম্পূর্ণ আপস না করে সিস্টেম মেমরি লিক করতে সক্ষম হতে পারে।
এই সমস্যা সমাধানের জন্য, 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 বাস্তবায়ন পরিবর্তন করতে হবে৷
কীমাস্টারে, convertStorageKeyToEphemeral
এর পরিবর্তে exportKey
ব্যবহার করা হয়েছিল।
লিনাক্স কার্নেল পরিবর্তন
ডিভাইসের ইনলাইন ক্রিপ্টো ইঞ্জিনের জন্য লিনাক্স কার্নেল ড্রাইভারকে হার্ডওয়্যার-র্যাপড কী সমর্থন করতে পরিবর্তন করতে হবে।
android14
এবং উচ্চতর কার্নেলের জন্য, 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
-programming এবং 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
ব্যবহার করুন। আরো বিস্তারিত জানার জন্য, মেটাডেটা এনক্রিপশন ডকুমেন্টেশন দেখুন।
বেশিরভাগ ডিস্ক এবং ফাইল এনক্রিপশন সফ্টওয়্যারের মতো, অ্যান্ড্রয়েডের স্টোরেজ এনক্রিপশন ঐতিহ্যগতভাবে সিস্টেম মেমরিতে থাকা কাঁচা এনক্রিপশন কীগুলির উপর নির্ভর করে যাতে এনক্রিপশনটি সম্পাদন করা যায়। এমনকি যখন এনক্রিপশন সফ্টওয়্যারের পরিবর্তে ডেডিকেটেড হার্ডওয়্যার দ্বারা সঞ্চালিত হয়, তখনও সাধারণত সফ্টওয়্যারকে কাঁচা এনক্রিপশন কীগুলি পরিচালনা করতে হয়।
এটি ঐতিহ্যগতভাবে একটি সমস্যা হিসাবে দেখা হয় না কারণ একটি অফলাইন আক্রমণের সময় কীগুলি উপস্থিত থাকবে না, এটি হল প্রধান ধরনের আক্রমণ যা থেকে রক্ষা করার জন্য স্টোরেজ এনক্রিপশনের উদ্দেশ্য। যাইহোক, অন্যান্য ধরণের আক্রমণের বিরুদ্ধে বর্ধিত সুরক্ষা প্রদান করার ইচ্ছা রয়েছে, যেমন কোল্ড বুট আক্রমণ এবং অনলাইন আক্রমণ যেখানে একজন আক্রমণকারী ডিভাইসের সাথে সম্পূর্ণ আপস না করে সিস্টেম মেমরি লিক করতে সক্ষম হতে পারে।
এই সমস্যা সমাধানের জন্য, 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
অর্জন করতে, হার্ডওয়্যারটি অবশ্যই একটি ক্রিপ্টোগ্রাফিকভাবে শক্তিশালী কেডিএফ ব্যবহার করতে হবে। এই কেডিএফকে অবশ্যই ক্রিপ্টোগ্রাফি সেরা অনুশীলনগুলি অনুসরণ করতে হবে; এটির কমপক্ষে 256 বিটের সুরক্ষা শক্তি থাকতে হবে, এটি পরে ব্যবহৃত কোনও অ্যালগরিদমের পক্ষে যথেষ্ট। ফলস্বরূপ সাবকিগুলি ক্রিপ্টোগ্রাফিকভাবে বিচ্ছিন্ন, অর্থাৎ, এর মধ্যে একটির জ্ঞান অন্য কোনও প্রকাশ করে না এমন গ্যারান্টি দেওয়ার জন্য প্রতিটি ধরণের সাবকি অর্জন করার সময় এটি অবশ্যই একটি স্বতন্ত্র লেবেল, প্রসঙ্গ এবং অ্যাপ্লিকেশন-নির্দিষ্ট তথ্য স্ট্রিং ব্যবহার করতে হবে। কী স্ট্রেচিংয়ের প্রয়োজন হয় না, কারণ কাঁচা স্টোরেজ কীটি ইতিমধ্যে অভিন্ন এলোমেলো কী।
প্রযুক্তিগতভাবে, সুরক্ষা প্রয়োজনীয়তা পূরণ করে এমন কোনও কেডিএফ ব্যবহার করা যেতে পারে। তবে পরীক্ষার উদ্দেশ্যে, পরীক্ষার কোডে একই কেডিএফ পুনরায় প্রয়োগ করা প্রয়োজন। বর্তমানে, একটি কেডিএফ পর্যালোচনা এবং প্রয়োগ করা হয়েছে; এটি vts_kernel_encryption_test
এর উত্স কোডে পাওয়া যাবে। এটি সুপারিশ করা হয় যে হার্ডওয়্যার এই কেডিএফ ব্যবহার করুন, যা এনআইএসটি এসপি 800-108 "কেডিএফ ইন কাউন্টার মোডে" ব্যবহার করে PRF হিসাবে AES-256-CMAC সহ। নোট করুন যে সামঞ্জস্যপূর্ণ হওয়ার জন্য, প্রতিটি সাবকিটির জন্য কেডিএফ প্রসঙ্গ এবং লেবেলগুলির পছন্দ সহ অ্যালগরিদমের সমস্ত অংশ অবশ্যই অভিন্ন হতে হবে।
কী মোড়ানো
হার্ডওয়্যার-মোড়ানো কীগুলির সুরক্ষা লক্ষ্যগুলি পূরণ করতে, দুটি ধরণের কী মোড়ক সংজ্ঞায়িত করা হয়:
- ইফেমেরাল মোড়ক : হার্ডওয়্যারটি একটি কী ব্যবহার করে কাঁচা কীটি এনক্রিপ্ট করে যা এলোমেলোভাবে প্রতিটি বুটে উত্পন্ন হয় এবং হার্ডওয়্যারের বাইরে সরাসরি প্রকাশিত হয় না।
- দীর্ঘমেয়াদী মোড়ক : হার্ডওয়্যারটি হার্ডওয়্যারটিতে নির্মিত একটি অনন্য, অবিরাম কী ব্যবহার করে কাঁচা কীটি এনক্রিপ্ট করে যা হার্ডওয়্যারের বাইরে সরাসরি প্রকাশিত হয় না।
স্টোরেজটি আনলক করতে লিনাক্স কার্নেলে সমস্ত কীগুলি পাস করা হয়েছে তা হ'ল মোড়কযুক্ত। এটি নিশ্চিত করে যে কোনও আক্রমণকারী যদি সিস্টেম মেমরি থেকে কোনও ইন-ব্যবহার কী বের করতে সক্ষম হয় তবে সেই কীটি কেবল ডিভাইসই নয়, পুনরায় বুট করার পরে ডিভাইসেও ব্যবহারযোগ্য নয়।
একই সময়ে, অ্যান্ড্রয়েডের এখনও কীগুলি অন-ডিস্কের একটি এনক্রিপ্ট করা সংস্করণ সংরক্ষণ করতে সক্ষম হওয়া দরকার যাতে তারা প্রথম স্থানে আনলক করা যায়। কাঁচা কীগুলি এই উদ্দেশ্যে কাজ করবে। তবে, কাঁচা কীগুলি সিস্টেমের মেমরিতে কখনও উপস্থিত না থাকাই এটি বাঞ্ছনীয় যাতে বুটের সময় বের করা হলেও এগুলি ডিভাইস বন্ধ ব্যবহার করার জন্য কখনই বের করা যায় না। এই কারণে, দীর্ঘমেয়াদী মোড়কের ধারণাটি সংজ্ঞায়িত করা হয়।
এই দুটি ভিন্ন উপায়ে মোড়ানো কীগুলি পরিচালনা করতে সমর্থন করতে, হার্ডওয়্যারটি অবশ্যই নিম্নলিখিত ইন্টারফেসগুলি প্রয়োগ করতে হবে:
- স্টোরেজ কীগুলি তৈরি এবং আমদানি করার জন্য ইন্টারফেসগুলি, দীর্ঘমেয়াদী মোড়ানো আকারে এগুলিকে ফিরিয়ে দেয়। এই ইন্টারফেসগুলি কিমিন্টের মাধ্যমে অপ্রত্যক্ষভাবে অ্যাক্সেস করা হয় এবং এগুলি
TAG_STORAGE_KEY
কিমিন্ট ট্যাগের সাথে মিলে যায়। "জেনারেট" ক্ষমতাটি অ্যান্ড্রয়েড দ্বারা ব্যবহারের জন্য নতুন স্টোরেজ কীগুলি উত্পন্ন করতেvold
ব্যবহার করে, যখন "আমদানি" ক্ষমতাটিvts_kernel_encryption_test
টেস্ট কীগুলি আমদানি করতে ব্যবহৃত হয়। - দীর্ঘমেয়াদী মোড়ানো স্টোরেজ কীটিকে একটি ইফেমেরালি-মোড়ানো স্টোরেজ কীতে রূপান্তর করার জন্য একটি ইন্টারফেস। এটি
convertStorageKeyToEphemeral
কিমিন্ট পদ্ধতির সাথে মিলে যায়। এই পদ্ধতিটি স্টোরেজটি আনলক করার জন্যvold
এবংvts_kernel_encryption_test
উভয়ই ব্যবহার করে।
মূল মোড়ক অ্যালগরিদম একটি বাস্তবায়নের বিশদ, তবে এটি এলোমেলো আইভি সহ AES-256-GCM এর মতো শক্তিশালী এইড ব্যবহার করা উচিত।
সফ্টওয়্যার পরিবর্তন প্রয়োজন
এওএসপি ইতিমধ্যে হার্ডওয়্যার-মোড়ানো কীগুলি সমর্থন করার জন্য একটি প্রাথমিক কাঠামো রয়েছে। এর মধ্যে vold
মতো ব্যবহারকারী স্পেস উপাদানগুলিতে সমর্থন, পাশাপাশি বিএলকে-ক্রাইপ্টো , এফএসসিআরআইপিটি এবং ডিএম-ডিফল্ট-কীতে লিনাক্স কার্নেল সমর্থন অন্তর্ভুক্ত রয়েছে।
তবে কিছু বাস্তবায়ন-নির্দিষ্ট পরিবর্তন প্রয়োজন।
কিমিন্ট পরিবর্তন
TAG_STORAGE_KEY
সমর্থন করতে এবং convertStorageKeyToEphemeral
পদ্ধতিটি প্রয়োগ করতে ডিভাইসের কীমিন্ট বাস্তবায়ন অবশ্যই সংশোধন করতে হবে।
কিমাস্টারে, convertStorageKeyToEphemeral
পরিবর্তে exportKey
ব্যবহার করা হত।
লিনাক্স কার্নেল পরিবর্তন হয়
ডিভাইসের ইনলাইন ক্রিপ্টো ইঞ্জিনের জন্য লিনাক্স কার্নেল ড্রাইভারটি হার্ডওয়্যার-মোড়ানো কীগুলি সমর্থন করার জন্য অবশ্যই পরিবর্তন করতে হবে।
android14
এবং উচ্চতর কার্নেলগুলির জন্য, BLK_CRYPTO_KEY_TYPE_HW_WRAPPED
blk_crypto_profile::key_types_supported
, 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
কার্নেলগুলির জন্য, BLK_CRYPTO_FEATURE_WRAPPED_KEYS
keyslot_manager::features
keyslot_mgmt_ll_ops::keyslot_program
এবং keyslot_mgmt_ll_ops::keyslot_evict
-এ/এভিক্টলিং/এভিক্টিং/এভিক্টিং keyslot_mgmt_ll_ops::derive_raw_secret
।
টেস্টিং
যদিও হার্ডওয়্যার-মোড়ানো কীগুলির সাথে এনক্রিপশন স্ট্যান্ডার্ড কীগুলির সাথে এনক্রিপশনের চেয়ে পরীক্ষা করা আরও শক্ত, তবুও একটি পরীক্ষার কী আমদানি করে এবং হার্ডওয়্যারটি কী কী ডেরাইভেশনটি করে তা পুনরায় বাস্তবায়ন করে পরীক্ষা করা সম্ভব। এটি vts_kernel_encryption_test
এ প্রয়োগ করা হয়েছে। এই পরীক্ষা চালাতে, চালান:
atest -v vts_kernel_encryption_test
পরীক্ষার লগটি পড়ুন এবং যাচাই করুন যে হার্ডওয়্যার-মোড়ানো কী পরীক্ষার কেসগুলি (উদাহরণস্বরূপ, FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy
এবং DmDefaultKeyTest.TestHwWrappedKey
) এখনও হার্ডওয়্যার-মোড়ানো কীগুলি সনাক্ত করা হচ্ছে না বলে "পরীক্ষার ফলাফলগুলি" পাসের ফলাফল হিসাবে "পাসের ফলাফলগুলি" পাসের ফলাফল হিসাবে "এড়ানো হয়নি" যে ক্ষেত্রে
কীগুলি সক্ষম করুন
একবার ডিভাইসের হার্ডওয়্যার-মোড়ানো কী সমর্থনটি সঠিকভাবে কাজ করার পরে, অ্যান্ড্রয়েডকে এফবিই এবং মেটাডেটা এনক্রিপশনের জন্য এটি ব্যবহার করতে আপনি ডিভাইসের fstab
ফাইলে নিম্নলিখিত পরিবর্তনগুলি করতে পারেন:
- এফবিই:
fileencryption
প্যারামিটারেwrappedkey_v0
পতাকা যুক্ত করুন। উদাহরণস্বরূপ,fileencryption=::inlinecrypt_optimized+wrappedkey_v0
ব্যবহার করুন। আরও তথ্যের জন্য, এফবিই ডকুমেন্টেশন দেখুন। - মেটাডেটা এনক্রিপশন:
wrappedkey_v0
পতাকাmetadata_encryption
প্যারামিটারে যুক্ত করুন। উদাহরণস্বরূপ,metadata_encryption=:wrappedkey_v0
ব্যবহার করুন। আরও তথ্যের জন্য, মেটাডেটা এনক্রিপশন ডকুমেন্টেশন দেখুন।
বেশিরভাগ ডিস্ক এবং ফাইল এনক্রিপশন সফ্টওয়্যারগুলির মতো, অ্যান্ড্রয়েডের স্টোরেজ এনক্রিপশন tradition তিহ্যগতভাবে কাঁচা এনক্রিপশন কীগুলির উপর নির্ভর করে সিস্টেমের মেমরিতে উপস্থিত থাকার জন্য যাতে এনক্রিপশনটি সম্পাদন করা যায়। এমনকি যখন এনক্রিপশনটি সফ্টওয়্যার দ্বারা ডেডিকেটেড হার্ডওয়্যার দ্বারা সঞ্চালিত হয়, তখনও সফ্টওয়্যারটি সাধারণত কাঁচা এনক্রিপশন কীগুলি পরিচালনা করতে হয়।
এই tradition তিহ্যগতভাবে কোনও সমস্যা হিসাবে দেখা যায় না কারণ অফলাইন আক্রমণ চলাকালীন কীগুলি উপস্থিত থাকবে না, যা মূল ধরণের আক্রমণ যা স্টোরেজ এনক্রিপশন থেকে রক্ষা করার উদ্দেশ্যে। তবে, অন্যান্য ধরণের আক্রমণগুলির বিরুদ্ধে যেমন শীতল বুট আক্রমণ এবং অনলাইন আক্রমণগুলির বিরুদ্ধে বর্ধিত সুরক্ষা সরবরাহ করার ইচ্ছা রয়েছে যেখানে কোনও আক্রমণকারী ডিভাইসটিতে পুরোপুরি আপস না করে সিস্টেম মেমরি ফাঁস করতে সক্ষম হতে পারে।
এই সমস্যাটি সমাধান করার জন্য, অ্যান্ড্রয়েড 11 হার্ডওয়্যার-মোড়ানো কীগুলির জন্য সমর্থন প্রবর্তন করেছে, যেখানে হার্ডওয়্যার সমর্থন উপস্থিত রয়েছে। হার্ডওয়্যার-মোড়ানো কীগুলি স্টোরেজ কীগুলি যা কেবল কাঁচা আকারে ডেডিকেটেড হার্ডওয়্যারগুলিতে পরিচিত; সফ্টওয়্যার কেবল এই কীগুলি মোড়ানো (এনক্রিপ্ট করা) ফর্মের সাথে দেখে এবং কাজ করে। এই হার্ডওয়্যারটি অবশ্যই স্টোরেজ কীগুলি উত্পন্ন এবং আমদানি করতে, সাময়িক এবং দীর্ঘমেয়াদী ফর্মগুলিতে স্টোরেজ কীগুলি মোড়ানো, সাবকিগুলি গ্রহণ করতে, সরাসরি একটি সাবকে একটি ইনলাইন ক্রিপ্টো ইঞ্জিনে প্রোগ্রামিং করতে এবং সফ্টওয়্যারটিতে একটি পৃথক সাবকি ফিরিয়ে দিতে সক্ষম হতে হবে।
দ্রষ্টব্য: একটি ইনলাইন ক্রিপ্টো ইঞ্জিন (বা ইনলাইন এনক্রিপশন হার্ডওয়্যার ) হার্ডওয়্যারকে বোঝায় যা স্টোরেজ ডিভাইসে/যাওয়ার সময় ডেটা এনক্রিপ্ট করে/ডিক্রিপ্ট করে। সাধারণত এটি একটি ইউএফএস বা ইএমএমসি হোস্ট কন্ট্রোলার যা সংশ্লিষ্ট জেডইসিইসি স্পেসিফিকেশন দ্বারা সংজ্ঞায়িত ক্রিপ্টো এক্সটেনশনগুলি প্রয়োগ করে।
ডিজাইন
এই বিভাগটি হার্ডওয়্যার-মোড়ানো কী বৈশিষ্ট্যের নকশা উপস্থাপন করে, এর জন্য কী হার্ডওয়্যার সমর্থন প্রয়োজন। এই আলোচনাটি ফাইল-ভিত্তিক এনক্রিপশন (এফবিই) এর উপর দৃষ্টি নিবদ্ধ করে তবে সমাধানটি মেটাডেটা এনক্রিপশনেও প্রযোজ্য।
সিস্টেম মেমরিতে কাঁচা এনক্রিপশন কীগুলির প্রয়োজন এড়ানোর একটি উপায় হ'ল এগুলি কেবল একটি ইনলাইন ক্রিপ্টো ইঞ্জিনের কীস্লটে রাখা। যাইহোক, এই পদ্ধতির কিছু সমস্যার মধ্যে চলে:
- এনক্রিপশন কীগুলির সংখ্যা কীলটগুলির সংখ্যা ছাড়িয়ে যেতে পারে।
- ইনলাইন ক্রিপ্টো ইঞ্জিনগুলি কেবল ডিস্কে ডেটাগুলির সম্পূর্ণ ব্লকগুলি এনক্রিপ্ট/ডিক্রিপ্ট করতে ব্যবহার করা যেতে পারে। তবে, এফবিইর ক্ষেত্রে, সফ্টওয়্যারটি এখনও অন্যান্য ক্রিপ্টোগ্রাফিক কাজ যেমন ফাইলের নাম এনক্রিপশন এবং প্রাপ্ত কী সনাক্তকারীগুলি করতে সক্ষম হতে হবে। এই অন্যান্য কাজটি করার জন্য সফ্টওয়্যারটির এখনও কাঁচা এফবিই কীগুলিতে অ্যাক্সেসের প্রয়োজন হবে।
এই সমস্যাগুলি এড়াতে, স্টোরেজ কীগুলি পরিবর্তে হার্ডওয়্যার-মোড়ানো কীগুলিতে তৈরি করা হয়, যা কেবল উত্সর্গীকৃত এবং ডেডিকেটেড হার্ডওয়্যার দ্বারা ব্যবহার করা যেতে পারে। এটি সীমাহীন সংখ্যক কীগুলি সমর্থন করার অনুমতি দেয়। তদতিরিক্ত, মূল শ্রেণিবিন্যাসটি সংশোধন করা হয়েছে এবং আংশিকভাবে এই হার্ডওয়্যারটিতে সরানো হয়েছে, যা একটি সাবকে এমন কাজের জন্য সফ্টওয়্যারটিতে ফিরে আসতে দেয় যা ইনলাইন ক্রিপ্টো ইঞ্জিন ব্যবহার করতে পারে না।
মূল অনুক্রম
কীগুলি কেডিএফ (কী ডেরাইভেশন ফাংশন) যেমন এইচকেডিএফ ব্যবহার করে অন্যান্য কীগুলি থেকে প্রাপ্ত করা যেতে পারে, যার ফলে একটি মূল শ্রেণিবিন্যাস হয়।
নিম্নলিখিত চিত্রটি যখন হার্ডওয়্যার-মোড়ানো কীগুলি ব্যবহার করা হয় না তখন এফবিইর জন্য একটি সাধারণ কী শ্রেণিবিন্যাস চিত্রিত করে:
এফবিই ক্লাস কী হ'ল কাঁচা এনক্রিপশন কী যা অ্যান্ড্রয়েড লিনাক্স কার্নেলের কাছে এনক্রিপ্ট করা ডিরেক্টরিগুলির একটি নির্দিষ্ট সেট যেমন কোনও নির্দিষ্ট অ্যান্ড্রয়েড ব্যবহারকারীর জন্য শংসাপত্র-এনক্রিপ্টড স্টোরেজ আনলক করতে দেয়। (কার্নেলে, এই কীটিকে একটি এফস্ক্রিপ্ট মাস্টার কী বলা হয়।) এই কী থেকে কার্নেলটি নিম্নলিখিত সাবকিগুলি অর্জন করে:
- কী শনাক্তকারী। এটি এনক্রিপশনের জন্য ব্যবহৃত হয় না, বরং একটি নির্দিষ্ট ফাইল বা ডিরেক্টরি সুরক্ষিত কী দিয়ে কীটি সনাক্ত করতে ব্যবহৃত একটি মান।
- ফাইল বিষয়বস্তু এনক্রিপশন কী
- ফাইলের নামগুলি এনক্রিপশন কী
বিপরীতে, নিম্নলিখিত চিত্রটি যখন হার্ডওয়্যার-মোড়ানো কীগুলি ব্যবহার করা হয় তখন এফবিইর জন্য মূল শ্রেণিবিন্যাস চিত্রিত করে:
পূর্ববর্তী ক্ষেত্রে তুলনা করে, মূল শ্রেণিবিন্যাসে একটি অতিরিক্ত স্তর যুক্ত করা হয়েছে এবং ফাইলের বিষয়বস্তু এনক্রিপশন কীটি স্থানান্তরিত করা হয়েছে। রুট নোডটি এখনও এনক্রিপ্ট করা ডিরেক্টরিগুলির একটি সেট আনলক করতে অ্যান্ড্রয়েড লিনাক্সে পাস করে এমন কীটি উপস্থাপন করে। যাইহোক, এখন সেই কীটি সংক্ষিপ্তভাবে মোড়ানো আকারে রয়েছে এবং ব্যবহারের জন্য এটি অবশ্যই ডেডিকেটেড হার্ডওয়্যারের কাছে যেতে হবে। এই হার্ডওয়্যারটি অবশ্যই দুটি ইন্টারফেস প্রয়োগ করতে হবে যা একটি ক্ষণস্থায়ীভাবে মোড়ানো কী গ্রহণ করে:
-
inline_encryption_key
অর্জনের জন্য একটি ইন্টারফেস এবং সরাসরি এটি ইনলাইন ক্রিপ্টো ইঞ্জিনের একটি কীলটে প্রোগ্রাম করুন। এটি ফাইলের বিষয়বস্তুগুলিকে কাঁচা কী অ্যাক্সেস না করে সফ্টওয়্যার ছাড়াই এনক্রিপ্ট/ডিক্রিপ্ট করার অনুমতি দেয়। অ্যান্ড্রয়েড কমন কার্নেলগুলিতে, এই ইন্টারফেসটিblk_crypto_ll_ops::keyslot_program
অপারেশনের সাথে সম্পর্কিত, যা অবশ্যই স্টোরেজ ড্রাইভার দ্বারা প্রয়োগ করা উচিত। -
sw_secret
("সফ্টওয়্যার সিক্রেট" - এটি কিছু জায়গায় "কাঁচা গোপন" নামে পরিচিত) প্রাপ্ত করার জন্য একটি ইন্টারফেস, যা লিনাক্স ফাইলের সামগ্রী এনক্রিপশন ব্যতীত অন্য সমস্ত কিছুর জন্য সাবকিগুলি অর্জন করতে ব্যবহার করে। অ্যান্ড্রয়েড কমন কার্নেলগুলিতে, এই ইন্টারফেসটিblk_crypto_ll_ops::derive_sw_secret
অপারেশনের সাথে সম্পর্কিত, যা অবশ্যই স্টোরেজ ড্রাইভার দ্বারা প্রয়োগ করা উচিত।
কাঁচা স্টোরেজ কী থেকে inline_encryption_key
এবং sw_secret
অর্জন করতে, হার্ডওয়্যারটি অবশ্যই একটি ক্রিপ্টোগ্রাফিকভাবে শক্তিশালী কেডিএফ ব্যবহার করতে হবে। এই কেডিএফকে অবশ্যই ক্রিপ্টোগ্রাফি সেরা অনুশীলনগুলি অনুসরণ করতে হবে; এটির কমপক্ষে 256 বিটের সুরক্ষা শক্তি থাকতে হবে, এটি পরে ব্যবহৃত কোনও অ্যালগরিদমের পক্ষে যথেষ্ট। ফলস্বরূপ সাবকিগুলি ক্রিপ্টোগ্রাফিকভাবে বিচ্ছিন্ন, অর্থাৎ, এর মধ্যে একটির জ্ঞান অন্য কোনও প্রকাশ করে না এমন গ্যারান্টি দেওয়ার জন্য প্রতিটি ধরণের সাবকি অর্জন করার সময় এটি অবশ্যই একটি স্বতন্ত্র লেবেল, প্রসঙ্গ এবং অ্যাপ্লিকেশন-নির্দিষ্ট তথ্য স্ট্রিং ব্যবহার করতে হবে। কী স্ট্রেচিংয়ের প্রয়োজন হয় না, কারণ কাঁচা স্টোরেজ কীটি ইতিমধ্যে অভিন্ন এলোমেলো কী।
প্রযুক্তিগতভাবে, সুরক্ষা প্রয়োজনীয়তা পূরণ করে এমন কোনও কেডিএফ ব্যবহার করা যেতে পারে। তবে পরীক্ষার উদ্দেশ্যে, পরীক্ষার কোডে একই কেডিএফ পুনরায় প্রয়োগ করা প্রয়োজন। বর্তমানে, একটি কেডিএফ পর্যালোচনা এবং প্রয়োগ করা হয়েছে; এটি vts_kernel_encryption_test
এর উত্স কোডে পাওয়া যাবে। এটি সুপারিশ করা হয় যে হার্ডওয়্যার এই কেডিএফ ব্যবহার করুন, যা এনআইএসটি এসপি 800-108 "কেডিএফ ইন কাউন্টার মোডে" ব্যবহার করে PRF হিসাবে AES-256-CMAC সহ। নোট করুন যে সামঞ্জস্যপূর্ণ হওয়ার জন্য, প্রতিটি সাবকিটির জন্য কেডিএফ প্রসঙ্গ এবং লেবেলগুলির পছন্দ সহ অ্যালগরিদমের সমস্ত অংশ অবশ্যই অভিন্ন হতে হবে।
কী মোড়ানো
হার্ডওয়্যার-মোড়ানো কীগুলির সুরক্ষা লক্ষ্যগুলি পূরণ করতে, দুটি ধরণের কী মোড়ক সংজ্ঞায়িত করা হয়:
- ইফেমেরাল মোড়ক : হার্ডওয়্যারটি একটি কী ব্যবহার করে কাঁচা কীটি এনক্রিপ্ট করে যা এলোমেলোভাবে প্রতিটি বুটে উত্পন্ন হয় এবং হার্ডওয়্যারের বাইরে সরাসরি প্রকাশিত হয় না।
- দীর্ঘমেয়াদী মোড়ক : হার্ডওয়্যারটি হার্ডওয়্যারটিতে নির্মিত একটি অনন্য, অবিরাম কী ব্যবহার করে কাঁচা কীটি এনক্রিপ্ট করে যা হার্ডওয়্যারের বাইরে সরাসরি প্রকাশিত হয় না।
স্টোরেজটি আনলক করতে লিনাক্স কার্নেলে সমস্ত কীগুলি পাস করা হয়েছে তা হ'ল মোড়কযুক্ত। এটি নিশ্চিত করে যে কোনও আক্রমণকারী যদি সিস্টেম মেমরি থেকে কোনও ইন-ব্যবহার কী বের করতে সক্ষম হয় তবে সেই কীটি কেবল ডিভাইসই নয়, পুনরায় বুট করার পরে ডিভাইসেও ব্যবহারযোগ্য নয়।
একই সময়ে, অ্যান্ড্রয়েডের এখনও কীগুলি অন-ডিস্কের একটি এনক্রিপ্ট করা সংস্করণ সংরক্ষণ করতে সক্ষম হওয়া দরকার যাতে তারা প্রথম স্থানে আনলক করা যায়। কাঁচা কীগুলি এই উদ্দেশ্যে কাজ করবে। তবে, কাঁচা কীগুলি সিস্টেমের মেমরিতে কখনও উপস্থিত না থাকাই এটি বাঞ্ছনীয় যাতে বুটের সময় বের করা হলেও এগুলি ডিভাইস বন্ধ ব্যবহার করার জন্য কখনই বের করা যায় না। এই কারণে, দীর্ঘমেয়াদী মোড়কের ধারণাটি সংজ্ঞায়িত করা হয়।
এই দুটি ভিন্ন উপায়ে মোড়ানো কীগুলি পরিচালনা করতে সমর্থন করতে, হার্ডওয়্যারটি অবশ্যই নিম্নলিখিত ইন্টারফেসগুলি প্রয়োগ করতে হবে:
- স্টোরেজ কীগুলি তৈরি এবং আমদানি করার জন্য ইন্টারফেসগুলি, দীর্ঘমেয়াদী মোড়ানো আকারে এগুলিকে ফিরিয়ে দেয়। এই ইন্টারফেসগুলি কিমিন্টের মাধ্যমে অপ্রত্যক্ষভাবে অ্যাক্সেস করা হয় এবং এগুলি
TAG_STORAGE_KEY
কিমিন্ট ট্যাগের সাথে মিলে যায়। "জেনারেট" ক্ষমতাটি অ্যান্ড্রয়েড দ্বারা ব্যবহারের জন্য নতুন স্টোরেজ কীগুলি উত্পন্ন করতেvold
ব্যবহার করে, যখন "আমদানি" ক্ষমতাটিvts_kernel_encryption_test
টেস্ট কীগুলি আমদানি করতে ব্যবহৃত হয়। - দীর্ঘমেয়াদী মোড়ানো স্টোরেজ কীটিকে একটি ইফেমেরালি-মোড়ানো স্টোরেজ কীতে রূপান্তর করার জন্য একটি ইন্টারফেস। এটি
convertStorageKeyToEphemeral
কিমিন্ট পদ্ধতির সাথে মিলে যায়। এই পদ্ধতিটি স্টোরেজটি আনলক করার জন্যvold
এবংvts_kernel_encryption_test
উভয়ই ব্যবহার করে।
মূল মোড়ক অ্যালগরিদম একটি বাস্তবায়নের বিশদ, তবে এটি এলোমেলো আইভি সহ AES-256-GCM এর মতো শক্তিশালী এইড ব্যবহার করা উচিত।
সফ্টওয়্যার পরিবর্তন প্রয়োজন
এওএসপি ইতিমধ্যে হার্ডওয়্যার-মোড়ানো কীগুলি সমর্থন করার জন্য একটি প্রাথমিক কাঠামো রয়েছে। এর মধ্যে vold
মতো ব্যবহারকারী স্পেস উপাদানগুলিতে সমর্থন, পাশাপাশি বিএলকে-ক্রাইপ্টো , এফএসসিআরআইপিটি এবং ডিএম-ডিফল্ট-কীতে লিনাক্স কার্নেল সমর্থন অন্তর্ভুক্ত রয়েছে।
তবে কিছু বাস্তবায়ন-নির্দিষ্ট পরিবর্তন প্রয়োজন।
কিমিন্ট পরিবর্তন
TAG_STORAGE_KEY
সমর্থন করতে এবং convertStorageKeyToEphemeral
পদ্ধতিটি প্রয়োগ করতে ডিভাইসের কীমিন্ট বাস্তবায়ন অবশ্যই সংশোধন করতে হবে।
কিমাস্টারে, convertStorageKeyToEphemeral
পরিবর্তে exportKey
ব্যবহার করা হত।
লিনাক্স কার্নেল পরিবর্তন হয়
ডিভাইসের ইনলাইন ক্রিপ্টো ইঞ্জিনের জন্য লিনাক্স কার্নেল ড্রাইভারটি হার্ডওয়্যার-মোড়ানো কীগুলি সমর্থন করার জন্য অবশ্যই পরিবর্তন করতে হবে।
android14
এবং উচ্চতর কার্নেলগুলির জন্য, BLK_CRYPTO_KEY_TYPE_HW_WRAPPED
blk_crypto_profile::key_types_supported
, 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
কার্নেলগুলির জন্য, BLK_CRYPTO_FEATURE_WRAPPED_KEYS
keyslot_manager::features
keyslot_mgmt_ll_ops::keyslot_program
এবং keyslot_mgmt_ll_ops::keyslot_evict
-এ/এভিক্টলিং/এভিক্টিং/এভিক্টিং keyslot_mgmt_ll_ops::derive_raw_secret
।
টেস্টিং
যদিও হার্ডওয়্যার-মোড়ানো কীগুলির সাথে এনক্রিপশন স্ট্যান্ডার্ড কীগুলির সাথে এনক্রিপশনের চেয়ে পরীক্ষা করা আরও শক্ত, তবুও একটি পরীক্ষার কী আমদানি করে এবং হার্ডওয়্যারটি কী কী ডেরাইভেশনটি করে তা পুনরায় বাস্তবায়ন করে পরীক্ষা করা সম্ভব। এটি vts_kernel_encryption_test
এ প্রয়োগ করা হয়েছে। এই পরীক্ষা চালাতে, চালান:
atest -v vts_kernel_encryption_test
পরীক্ষার লগটি পড়ুন এবং যাচাই করুন যে হার্ডওয়্যার-মোড়ানো কী পরীক্ষার কেসগুলি (উদাহরণস্বরূপ, FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy
এবং DmDefaultKeyTest.TestHwWrappedKey
) এখনও হার্ডওয়্যার-মোড়ানো কীগুলি সনাক্ত করা হচ্ছে না বলে "পরীক্ষার ফলাফলগুলি" পাসের ফলাফল হিসাবে "পাসের ফলাফলগুলি" পাসের ফলাফল হিসাবে "এড়ানো হয়নি" যে ক্ষেত্রে
কীগুলি সক্ষম করুন
একবার ডিভাইসের হার্ডওয়্যার-মোড়ানো কী সমর্থনটি সঠিকভাবে কাজ করার পরে, অ্যান্ড্রয়েডকে এফবিই এবং মেটাডেটা এনক্রিপশনের জন্য এটি ব্যবহার করতে আপনি ডিভাইসের fstab
ফাইলে নিম্নলিখিত পরিবর্তনগুলি করতে পারেন:
- এফবিই:
fileencryption
প্যারামিটারেwrappedkey_v0
পতাকা যুক্ত করুন। উদাহরণস্বরূপ,fileencryption=::inlinecrypt_optimized+wrappedkey_v0
ব্যবহার করুন। আরও তথ্যের জন্য, এফবিই ডকুমেন্টেশন দেখুন। - মেটাডেটা এনক্রিপশন:
wrappedkey_v0
পতাকাmetadata_encryption
প্যারামিটারে যুক্ত করুন। উদাহরণস্বরূপ,metadata_encryption=:wrappedkey_v0
ব্যবহার করুন। আরও তথ্যের জন্য, মেটাডেটা এনক্রিপশন ডকুমেন্টেশন দেখুন।