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

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

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

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

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

ডিজাইন

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

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

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

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

মূল অনুক্রম

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

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

FBE কী অনুক্রম (মান)
চিত্র 1. FBE কী অনুক্রম (মান)

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

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

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

FBE কী অনুক্রম (হার্ডওয়্যার-র্যাপড কী সহ)
চিত্র 2. 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 হার্ডওয়্যার-প্রোগ্রামিং/এভিক্ট করা সাপোর্টিং এবং ইমপ্লিমেন্ট কী 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 ব্যবহার করুন। আরো বিস্তারিত জানার জন্য, মেটাডেটা এনক্রিপশন ডকুমেন্টেশন দেখুন।