ফাইল-ভিত্তিক এনক্রিপশন

অ্যান্ড্রয়েড ৭.০ এবং এর পরবর্তী সংস্করণ ফাইল-ভিত্তিক এনক্রিপশন (FBE) সমর্থন করে। ফাইল-ভিত্তিক এনক্রিপশনের মাধ্যমে বিভিন্ন ফাইলকে ভিন্ন ভিন্ন কী ব্যবহার করে এনক্রিপ্ট করা যায়, যেগুলো স্বাধীনভাবে আনলক করা সম্ভব।

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

অ্যান্ড্রয়েড ১০ এবং এর পরবর্তী সংস্করণসহ চালু হওয়া সকল ডিভাইসে ফাইল-ভিত্তিক এনক্রিপশন ব্যবহার করা বাধ্যতামূলক।

সরাসরি বুট

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

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

FBE-সক্ষম ডিভাইসে, প্রতিটি ব্যবহারকারীর জন্য অ্যাপের ব্যবহারের জন্য দুটি স্টোরেজ লোকেশন উপলব্ধ থাকে:

  • ক্রেডেনশিয়াল এনক্রিপ্টেড (সিই) স্টোরেজ হলো ডিফল্ট স্টোরেজ লোকেশন এবং এটি শুধুমাত্র ব্যবহারকারী ডিভাইসটি আনলক করার পরেই উপলব্ধ হয়।
  • ডিভাইস এনক্রিপ্টেড (DE) স্টোরেজ হলো এমন একটি স্টোরেজ লোকেশন যা ডাইরেক্ট বুট মোডে এবং ব্যবহারকারী ডিভাইসটি আনলক করার পরেও উপলব্ধ থাকে।

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

ডিরেক্ট বুট এপিআই এনক্রিপশন-সচেতন অ্যাপগুলোকে এই প্রতিটি এলাকা অ্যাক্সেস করার সুযোগ দেয়। লক স্ক্রিনে প্রথমবার ক্রেডেনশিয়াল প্রবেশ করানোর ফলে, অথবা ওয়ার্ক প্রোফাইল থেকে কোনো ওয়ার্ক চ্যালেঞ্জ পাওয়ার ক্ষেত্রে, যখন ব্যবহারকারীর সিই (CE) স্টোরেজ আনলক হয়, তখন অ্যাপগুলোকে অবহিত করার প্রয়োজন মেটাতে অ্যাপ লাইফসাইকেলে পরিবর্তন আনা হয়েছে। অ্যান্ড্রয়েড ৭.০ চালিত ডিভাইসগুলোকে অবশ্যই এই নতুন এপিআই এবং লাইফসাইকেলগুলো সমর্থন করতে হবে, তারা এফবিই (FBE) প্রয়োগ করুক বা না করুক। যদিও, এফবিই ছাড়া ডিই (DE) এবং সিই (CE) স্টোরেজ সর্বদা আনলকড অবস্থায় থাকে।

Ext4 এবং F2FS ফাইল সিস্টেমে ফাইল-ভিত্তিক এনক্রিপশনের একটি সম্পূর্ণ বাস্তবায়ন অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্ট (AOSP)-এ প্রদান করা হয়েছে এবং এটি শুধুমাত্র প্রয়োজনীয়তা পূরণকারী ডিভাইসগুলিতে সক্রিয় করা প্রয়োজন। FBE ব্যবহার করতে ইচ্ছুক নির্মাতারা ব্যবহৃত সিস্টেম অন চিপ (SoC)-এর উপর ভিত্তি করে এই ফিচারটিকে অপ্টিমাইজ করার উপায়গুলি অন্বেষণ করতে পারেন।

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

  • টেলিফোনি পরিষেবা এবং ডায়ালার
  • লক স্ক্রিনে পাসওয়ার্ড প্রবেশ করানোর পদ্ধতি

উদাহরণ এবং উৎস

অ্যান্ড্রয়েড ফাইল-ভিত্তিক এনক্রিপশনের একটি রেফারেন্স ইমপ্লিমেন্টেশন প্রদান করে, যেখানে vold ( system/vold ) অ্যান্ড্রয়েডে স্টোরেজ ডিভাইস এবং ভলিউম পরিচালনার কার্যকারিতা সরবরাহ করে। FBE যুক্ত হওয়ার ফলে vold-এ একাধিক ব্যবহারকারীর CE এবং DE কী-এর ব্যবস্থাপনাকে সমর্থন করার জন্য বেশ কিছু নতুন কমান্ড যুক্ত হয়েছে। কার্নেলে ফাইল-ভিত্তিক এনক্রিপশন ক্ষমতা ব্যবহারের জন্য মূল পরিবর্তনগুলো ছাড়াও, লকস্ক্রিন এবং SystemUI সহ অনেক সিস্টেম প্যাকেজ FBE এবং ডিরেক্ট বুট বৈশিষ্ট্যগুলোকে সমর্থন করার জন্য পরিবর্তন করা হয়েছে। এগুলোর মধ্যে রয়েছে:

  • AOSP ডায়ালার (প্যাকেজ/অ্যাপ/ডায়ালার)
  • ডেস্ক ক্লক (প্যাকেজ/অ্যাপস/ডেস্কক্লক)
  • ল্যাটিনআইএমই (প্যাকেজ/ইনপুটমেথড/ল্যাটিনআইএমই)*
  • সেটিংস অ্যাপ (প্যাকেজ/অ্যাপ/সেটিংস)*
  • সিস্টেমইউআই (ফ্রেমওয়ার্ক/বেস/প্যাকেজ/সিস্টেমইউআই)*

সিস্টেম অ্যাপ যা defaultToDeviceProtectedStorage ম্যানিফেস্ট অ্যাট্রিবিউট ব্যবহার করে

AOSP সোর্স ট্রির ফ্রেমওয়ার্কস বা প্যাকেজেস ডিরেক্টরিতে mangrep directBootAware কমান্ডটি চালিয়ে এনক্রিপশন-সচেতন অ্যাপ ও সার্ভিসের আরও উদাহরণ খুঁজে পাওয়া যাবে।

নির্ভরশীলতা

AOSP-এর FBE বাস্তবায়ন নিরাপদে ব্যবহার করার জন্য, একটি ডিভাইসকে নিম্নলিখিত শর্তগুলো পূরণ করতে হবে:

  • Ext4 এনক্রিপশন অথবা F2FS এনক্রিপশনের জন্য কার্নেল সাপোর্ট ।
  • KeyMint (বা Keymaster 1.0 বা উচ্চতর সংস্করণ) সমর্থিত । Keymaster 0.3 সমর্থিত নয়, কারণ এটি এনক্রিপশন কী-গুলির জন্য প্রয়োজনীয় সক্ষমতা বা পর্যাপ্ত সুরক্ষা নিশ্চিত করে না।
  • ডিই কী-গুলোর সুরক্ষা নিশ্চিত করার জন্য KeyMint/Keymaster এবং Gatekeeper অবশ্যই একটি ট্রাস্টেড এক্সিকিউশন এনভায়রনমেন্ট (TEE)-এ প্রয়োগ করতে হবে, যাতে কোনো অননুমোদিত ওএস (ডিভাইসে ফ্ল্যাশ করা কাস্টম ওএস) সহজে ডিই কী-গুলোর জন্য অনুরোধ করতে না পারে।
  • কোনো অননুমোদিত অপারেটিং সিস্টেম যাতে ডিই (DE) কী-গুলো অ্যাক্সেস করতে না পারে, তা নিশ্চিত করার জন্য কীমিন্ট (KeyMint) ইনিশিয়ালাইজেশনের সাথে হার্ডওয়্যার রুট অফ ট্রাস্ট (Hardware Root of Trust) এবং ভেরিফাইড বুট (Verified Boot) সংযুক্ত থাকা আবশ্যক।

বাস্তবায়ন

সর্বাগ্রে, ডিরেক্ট বুট ডেভেলপার ডকুমেন্টেশন অনুযায়ী অ্যালার্ম ক্লক, ফোন এবং অ্যাক্সেসিবিলিটি ফিচারের মতো অ্যাপগুলোকে android:directBootAware করতে হবে।

কার্নেল সমর্থন

অ্যান্ড্রয়েড কমন কার্নেলের ৩.১৮ এবং তার পরবর্তী সংস্করণগুলোতে Ext4 এবং F2FS এনক্রিপশনের জন্য সমর্থন পাওয়া যায়। ৫.১ বা তার পরবর্তী সংস্করণের কোনো কার্নেলে এটি সক্রিয় করতে, ব্যবহার করুন:

CONFIG_FS_ENCRYPTION=y

পুরোনো কার্নেলগুলোর জন্য, আপনার ডিভাইসের userdata ফাইলসিস্টেম Ext4 হলে CONFIG_EXT4_ENCRYPTION=y ব্যবহার করুন, অথবা আপনার ডিভাইসের userdata ফাইলসিস্টেম F2FS হলে CONFIG_F2FS_FS_ENCRYPTION=y ব্যবহার করুন।

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

Ext4 বা F2FS এনক্রিপশনের জন্য কার্যকরী সমর্থনের পাশাপাশি, ডিভাইস নির্মাতাদের ফাইল-ভিত্তিক এনক্রিপশনের গতি বাড়াতে এবং ব্যবহারকারীর অভিজ্ঞতা উন্নত করতে ক্রিপ্টোগ্রাফিক অ্যাক্সিলারেশনও সক্ষম করা উচিত। উদাহরণস্বরূপ, ARM64-ভিত্তিক ডিভাইসগুলিতে, নিম্নলিখিত কার্নেল কনফিগারেশন বিকল্পগুলি সেট করার মাধ্যমে ARMv8 CE (ক্রিপ্টোগ্রাফি এক্সটেনশন) অ্যাক্সিলারেশন সক্ষম করা যেতে পারে:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

পারফরম্যান্স আরও উন্নত করতে এবং বিদ্যুৎ খরচ কমাতে, ডিভাইস নির্মাতারা ইনলাইন এনক্রিপশন হার্ডওয়্যার প্রয়োগ করার কথাও বিবেচনা করতে পারেন, যা স্টোরেজ ডিভাইসে ডেটা আসা-যাওয়ার পথেই সেটিকে এনক্রিপ্ট/ডিক্রিপ্ট করে। অ্যান্ড্রয়েডের সাধারণ কার্নেলগুলোতে (সংস্করণ ৪.১৪ এবং তার উচ্চতর) এমন একটি ফ্রেমওয়ার্ক রয়েছে যা হার্ডওয়্যার এবং ভেন্ডর ড্রাইভারের সমর্থন থাকলে ইনলাইন এনক্রিপশন ব্যবহারের সুযোগ দেয়। নিম্নলিখিত কার্নেল কনফিগারেশন অপশনগুলো সেট করার মাধ্যমে ইনলাইন এনক্রিপশন ফ্রেমওয়ার্কটি সক্রিয় করা যায়:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

আপনার ডিভাইস যদি UFS-ভিত্তিক স্টোরেজ ব্যবহার করে, তাহলে এটিও সক্রিয় করুন:

CONFIG_SCSI_UFS_CRYPTO=y

আপনার ডিভাইস যদি eMMC-ভিত্তিক স্টোরেজ ব্যবহার করে, তাহলে এটিও সক্রিয় করুন:

CONFIG_MMC_CRYPTO=y

ফাইল-ভিত্তিক এনক্রিপশন সক্রিয় করুন

কোনো ডিভাইসে FBE সক্রিয় করতে হলে, অভ্যন্তরীণ স্টোরেজে ( userdata ) এটি সক্রিয় করতে হয়। এর ফলে অ্যাডপ্টেবল স্টোরেজেও স্বয়ংক্রিয়ভাবে FBE সক্রিয় হয়ে যায়; তবে, প্রয়োজনে অ্যাডপ্টেবল স্টোরেজের এনক্রিপশন ফরম্যাটটি ওভাররাইড করা যেতে পারে।

অভ্যন্তরীণ স্টোরেজ

userdata এর জন্য fstab লাইনের fs_mgr_flags কলামে fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] অপশনটি যোগ করে FBE সক্রিয় করা হয়। এই অপশনটি অভ্যন্তরীণ স্টোরেজের এনক্রিপশন ফরম্যাট নির্ধারণ করে। এতে কোলন দ্বারা পৃথক করা সর্বোচ্চ তিনটি প্যারামিটার থাকতে পারে:

  • contents_encryption_mode প্যারামিটারটি নির্ধারণ করে যে ফাইলের বিষয়বস্তু এনক্রিপ্ট করার জন্য কোন ক্রিপ্টোগ্রাফিক অ্যালগরিদম ব্যবহার করা হবে। এটি aes-256-xts অথবা adiantum হতে পারে। অ্যান্ড্রয়েড ১১ থেকে, ডিফল্ট অ্যালগরিদম ` aes-256-xts নির্দিষ্ট করার জন্য এটি খালিও রাখা যায়।
  • filenames_encryption_mode প্যারামিটারটি নির্ধারণ করে যে ফাইলের নাম এনক্রিপ্ট করার জন্য কোন ক্রিপ্টোগ্রাফিক অ্যালগরিদম ব্যবহার করা হবে। এটি aes-256-cts , aes-256-heh , adiantum , অথবা aes-256-hctr2 এর যেকোনো একটি হতে পারে। যদি এটি নির্দিষ্ট করা না থাকে, তাহলে contents_encryption_mode যদি `aes-256-xts` হয়, তবে এটি ডিফল্টভাবে aes-256-cts aes-256-xts হয়; অথবা contents_encryption_mode যদি ` adiantum হয়, তবে এটি ডিফল্টভাবে ` adiantum ব্যবহৃত হয়।
  • অ্যান্ড্রয়েড ১১-এ নতুন সংযোজিত flags প্যারামিটারটি হলো ‘ + চিহ্ন দ্বারা পৃথক করা ফ্ল্যাগগুলোর একটি তালিকা। নিম্নলিখিত ফ্ল্যাগগুলো সমর্থিত:
    • v1 ফ্ল্যাগটি ভার্সন ১ এনক্রিপশন পলিসি নির্বাচন করে; v2 ফ্ল্যাগটি ভার্সন ২ এনক্রিপশন পলিসি নির্বাচন করে। ভার্সন ২ এনক্রিপশন পলিসিগুলো একটি অধিক সুরক্ষিত এবং নমনীয় কী ডিরাইভেশন ফাংশন ব্যবহার করে। যদি ডিভাইসটি অ্যান্ড্রয়েড ১১ বা তার উচ্চতর সংস্করণে ( ro.product.first_api_level দ্বারা নির্ধারিত) চালু হয়ে থাকে, তবে ডিফল্ট হলো v2, অথবা যদি ডিভাইসটি অ্যান্ড্রয়েড ১০ বা তার নিম্নতর সংস্করণে চালু হয়ে থাকে, তবে ডিফল্ট হলো v1।
    • inlinecrypt_optimized ফ্ল্যাগটি এমন একটি এনক্রিপশন ফরম্যাট নির্বাচন করে যা সেইসব ইনলাইন এনক্রিপশন হার্ডওয়্যারের জন্য অপ্টিমাইজ করা হয়েছে, যেগুলো বিপুল সংখ্যক কী দক্ষতার সাথে পরিচালনা করতে পারে না। এটি প্রতি ফাইলের জন্য একটি করে কী-এর পরিবর্তে, প্রতিটি CE বা DE কী থেকে কেবল একটি ফাইল কন্টেন্টস এনক্রিপশন কী তৈরি করার মাধ্যমে এই কাজটি করে থাকে। সেই অনুযায়ী IV (ইনিশিয়ালাইজেশন ভেক্টর)-এর জেনারেশনও সামঞ্জস্য করা হয়।
    • emmc_optimized ফ্ল্যাগটি inlinecrypt_optimized এর অনুরূপ, তবে এটি এমন একটি IV তৈরির পদ্ধতিও নির্বাচন করে যা IV-কে ৩২ বিটে সীমাবদ্ধ রাখে। এই ফ্ল্যাগটি শুধুমাত্র সেইসব ইনলাইন এনক্রিপশন হার্ডওয়্যারে ব্যবহার করা উচিত যা JEDEC eMMC v5.2 স্পেসিফিকেশনের সাথে সঙ্গতিপূর্ণ এবং সেই কারণে কেবল ৩২-বিট IV সমর্থন করে। অন্যান্য ইনলাইন এনক্রিপশন হার্ডওয়্যারে এর পরিবর্তে inlinecrypt_optimized ব্যবহার করুন। এই ফ্ল্যাগটি UFS-ভিত্তিক স্টোরেজে কখনোই ব্যবহার করা উচিত নয়; UFS স্পেসিফিকেশন ৬৪-বিট IV ব্যবহারের অনুমতি দেয়।
    • যেসব ডিভাইস হার্ডওয়্যার-র‍্যাপড কী সমর্থন করে, সেগুলোতে wrappedkey_v0 ফ্ল্যাগটি FBE-এর জন্য হার্ডওয়্যার-র‍্যাপড কী ব্যবহার সক্ষম করে। এটি শুধুমাত্র inlinecrypt মাউন্ট অপশন এবং inlinecrypt_optimized বা emmc_optimized ফ্ল্যাগের সাথে একত্রে ব্যবহার করা যায়।
    • dusize_4k ফ্ল্যাগটি এনক্রিপশন ডেটা ইউনিট সাইজকে ৪০৯৬ বাইট হতে বাধ্য করে, এমনকি যখন ফাইলসিস্টেম ব্লক সাইজ ৪০৯৬ বাইট না-ও হয়। এনক্রিপশন ডেটা ইউনিট সাইজ হলো ফাইলের বিষয়বস্তু এনক্রিপশনের সূক্ষ্মতা। এই ফ্ল্যাগটি অ্যান্ড্রয়েড ১৫ থেকে উপলব্ধ। এই ফ্ল্যাগটি শুধুমাত্র এমন ডিভাইসে ব্যবহার করা উচিত যা ৪০৯৬ বাইটের চেয়ে বড় পেজ সাইজ এবং f2fs ফাইলসিস্টেম ব্যবহার করে, এবং যেখানে এমন ইনলাইন এনক্রিপশন হার্ডওয়্যার ব্যবহার করা যায় যা ৪০৯৬ বাইটের চেয়ে বড় ডেটা ইউনিট সমর্থন করে না।

আপনি যদি ইনলাইন এনক্রিপশন হার্ডওয়্যার ব্যবহার না করেন, তবে বেশিরভাগ ডিভাইসের জন্য প্রস্তাবিত সেটিং হলো fileencryption=aes-256-xts । আপনি যদি ইনলাইন এনক্রিপশন হার্ডওয়্যার ব্যবহার করেন, তবে বেশিরভাগ ডিভাইসের জন্য প্রস্তাবিত সেটিং হলো fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (অথবা সমতুল্যভাবে fileencryption=::inlinecrypt_optimized )। যেসব ডিভাইসে কোনো ধরনের AES অ্যাক্সিলারেশন নেই, সেখানে fileencryption=adiantum সেট করে AES-এর পরিবর্তে Adiantum ব্যবহার করা যেতে পারে।

অ্যান্ড্রয়েড ১৪ থেকে, অ্যাক্সিলারেটেড ক্রিপ্টোগ্রাফি নির্দেশাবলীযুক্ত ডিভাইসগুলির জন্য ফাইলের নাম এনক্রিপশনের পছন্দের মোড হলো AES-HCTR2। তবে, শুধুমাত্র নতুন অ্যান্ড্রয়েড কার্নেলগুলিই AES-HCTR2 সমর্থন করে। ভবিষ্যতের কোনো অ্যান্ড্রয়েড রিলিজে, এটিকে ফাইলের নাম এনক্রিপশনের জন্য ডিফল্ট মোড করার পরিকল্পনা রয়েছে। যদি আপনার কার্নেলে AES-HCTR2 সমর্থন থাকে, তবে filenames_encryption_mode aes-256-hctr2 তে সেট করে ফাইলের নাম এনক্রিপশনের জন্য এটি সক্রিয় করা যেতে পারে। সবচেয়ে সহজ ক্ষেত্রে, এটি fileencryption=aes-256-xts:aes-256-hctr2 দিয়ে করা হয়।

অ্যান্ড্রয়েড ১০ বা তার নিচের সংস্করণ দিয়ে চালু হওয়া ডিভাইসগুলিতে, FSCRYPT_MODE_PRIVATE ফাইল কন্টেন্ট এনক্রিপশন মোড ব্যবহারের জন্য fileencryption=ice বিকল্পটিও গৃহীত হতো। এই মোডটি অ্যান্ড্রয়েডের সাধারণ কার্নেলগুলিতে বাস্তবায়িত নয়, তবে বিক্রেতারা কাস্টম কার্নেল প্যাচ ব্যবহার করে এটি বাস্তবায়ন করতে পারত। এই মোডের মাধ্যমে ডিস্কে যে ফরম্যাট তৈরি হতো, তা বিক্রেতা-নির্দিষ্ট ছিল। অ্যান্ড্রয়েড ১১ বা তার উচ্চতর সংস্করণ দিয়ে চালু হওয়া ডিভাইসগুলিতে এই মোডটি আর অনুমোদিত নয় এবং এর পরিবর্তে একটি স্ট্যান্ডার্ড এনক্রিপশন ফরম্যাট ব্যবহার করতে হবে।

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

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

গ্রহণযোগ্য স্টোরেজ

অ্যান্ড্রয়েড ৯ থেকে এফবিই এবং অ্যাডপ্টেবল স্টোরেজ একসাথে ব্যবহার করা যায়।

userdata জন্য fileencryption fstab অপশনটি নির্দিষ্ট করলে অ্যাডপ্টেবল স্টোরেজে FBE এবং মেটাডেটা এনক্রিপশন উভয়ই স্বয়ংক্রিয়ভাবে সক্রিয় হয়ে যায়। তবে, আপনি PRODUCT_PROPERTY_OVERRIDES এ প্রোপার্টি সেট করার মাধ্যমে অ্যাডপ্টেবল স্টোরেজে FBE বা মেটাডেটা এনক্রিপশন ফরম্যাটগুলো ওভাররাইড করতে পারেন।

যেসব ডিভাইস অ্যান্ড্রয়েড ১১ বা তার উচ্চতর সংস্করণ দিয়ে বাজারে এসেছে, সেগুলোতে নিম্নলিখিত প্রোপার্টিগুলো ব্যবহার করুন:

  • ro.crypto.volume.options (অ্যান্ড্রয়েড ১১-এ নতুন) অ্যাডপ্টেবল স্টোরেজে FBE এনক্রিপশন ফরম্যাট নির্বাচন করে। এর সিনট্যাক্সটি fileencryption fstab অপশনের আর্গুমেন্টের মতোই এবং এটি একই ডিফল্ট ব্যবহার করে। এখানে কী ব্যবহার করতে হবে, তা জানতে উপরে fileencryption জন্য দেওয়া সুপারিশগুলো দেখুন।
  • ro.crypto.volume.metadata.encryption অ্যাডপ্টেবল স্টোরেজে মেটাডেটা এনক্রিপশন ফরম্যাট নির্বাচন করে। মেটাডেটা এনক্রিপশন ডকুমেন্টেশন দেখুন।

যেসব ডিভাইস অ্যান্ড্রয়েড ১০ বা তার পূর্ববর্তী সংস্করণ দিয়ে বাজারে এসেছে, সেগুলোতে নিম্নলিখিত প্রোপার্টিগুলো ব্যবহার করুন:

  • ro.crypto.volume.contents_mode কন্টেন্ট এনক্রিপশন মোড নির্বাচন করে। এটি ro.crypto.volume.options এর প্রথম কোলন-বিভক্ত ফিল্ডের সমতুল্য।
  • ro.crypto.volume.filenames_mode ফাইলনেম এনক্রিপশন মোড নির্বাচন করে। এটি ro.crypto.volume.options এর দ্বিতীয় কোলন-বিভক্ত ফিল্ডের সমতুল্য, তবে পার্থক্য হলো, Android 10 এবং তার নিচের সংস্করণ দিয়ে চালু হওয়া ডিভাইসগুলিতে ডিফল্ট হলো aes-256-heh । বেশিরভাগ ডিভাইসে, এটিকে স্পষ্টভাবে aes-256-cts এ ওভাররাইড করতে হয়।
  • ro.crypto.fde_algorithm এবং ro.crypto.fde_sector_size অ্যাডপ্টেবল স্টোরেজে মেটাডেটা এনক্রিপশন ফরম্যাট নির্বাচন করে। মেটাডেটা এনক্রিপশন ডকুমেন্টেশন দেখুন।

KeyMint-এর সাথে একীভূত করুন

KeyMint HAL-কে early_hal ক্লাসের অংশ হিসেবে চালু করা উচিত। এর কারণ হলো, FBE-এর প্রয়োজন অনুযায়ী post-fs-data বুট পর্যায়ের মধ্যেই KeyMint-কে অনুরোধগুলি পরিচালনা করার জন্য প্রস্তুত থাকতে হয়, যে পর্যায়ে vold প্রাথমিক কীগুলি সেট আপ করে।

ডিরেক্টরি বাদ দিন

init কমান্ডটি /data এর সমস্ত শীর্ষ-স্তরের ডিরেক্টরিতে সিস্টেম ডিই কী প্রয়োগ করে, তবে সেইসব ডিরেক্টরি এর ব্যতিক্রম যেগুলো অবশ্যই এনক্রিপ্ট করা যাবে না; যেমন—যে ডিরেক্টরিতে স্বয়ং সিস্টেম ডিই কী থাকে এবং যে ডিরেক্টরিগুলোতে ব্যবহারকারীর সিই বা ডিই ডিরেক্টরি থাকে। এনক্রিপশন কীগুলো রিকার্সিভলি প্রয়োগ হয় এবং সাবডিরেক্টরি দ্বারা এগুলোকে ওভাররাইড করা যায় না।

অ্যান্ড্রয়েড ১১ এবং এর পরবর্তী সংস্করণগুলিতে, init স্ক্রিপ্টে mkdir কমান্ডের encryption=<action> আর্গুমেন্টের মাধ্যমে ডিরেক্টরিগুলিতে init যে কী প্রয়োগ করে তা নিয়ন্ত্রণ করা যায়। <action> এর সম্ভাব্য মানগুলি অ্যান্ড্রয়েড init ল্যাঙ্গুয়েজের README- তে নথিভুক্ত করা আছে।

অ্যান্ড্রয়েড ১০-এ, init এনক্রিপশন অ্যাকশনগুলো নিম্নলিখিত স্থানে হার্ডকোড করা ছিল:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

অ্যান্ড্রয়েড ৯ এবং এর আগের সংস্করণগুলোতে অবস্থানটি ছিল:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

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

এর একমাত্র জ্ঞাত গ্রহণযোগ্য ব্যবহার হলো পুরোনো OTA সক্ষমতা সমর্থন করা।

সিস্টেম অ্যাপে ডাইরেক্ট বুট সমর্থন করে

অ্যাপগুলিকে ডিরেক্ট বুট সম্পর্কে সচেতন করুন

সিস্টেম অ্যাপগুলির দ্রুত স্থানান্তর সহজ করার জন্য, অ্যাপ লেভেলে দুটি নতুন অ্যাট্রিবিউট সেট করা যায়। defaultToDeviceProtectedStorage অ্যাট্রিবিউটটি শুধুমাত্র সিস্টেম অ্যাপের জন্য উপলব্ধ। directBootAware অ্যাট্রিবিউটটি সকলের জন্য উপলব্ধ।

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

অ্যাপ লেভেলের directBootAware অ্যাট্রিবিউটটি অ্যাপের সমস্ত কম্পোনেন্টকে এনক্রিপশন-সচেতন হিসেবে চিহ্নিত করার একটি সংক্ষিপ্ত উপায়।

` defaultToDeviceProtectedStorage অ্যাট্রিবিউটটি অ্যাপের ডিফল্ট স্টোরেজ লোকেশনকে CE স্টোরেজের পরিবর্তে DE স্টোরেজের দিকে নির্দেশ করে। যে সিস্টেম অ্যাপগুলো এই ফ্ল্যাগটি ব্যবহার করে, তাদের অবশ্যই ডিফল্ট লোকেশনে সংরক্ষিত সমস্ত ডেটা সতর্কতার সাথে নিরীক্ষা করতে হবে এবং সংবেদনশীল ডেটার পাথ পরিবর্তন করে CE স্টোরেজ ব্যবহার করতে হবে। যে ডিভাইস নির্মাতারা এই অপশনটি ব্যবহার করেন, তাদেরও উচিত নিজেদের সংরক্ষিত ডেটা সতর্কতার সাথে পরীক্ষা করে নিশ্চিত করা যে তাতে কোনো ব্যক্তিগত তথ্য নেই।

এই মোডে চলার সময়, প্রয়োজনে CE স্টোরেজ দ্বারা সমর্থিত একটি Context-কে সুস্পষ্টভাবে পরিচালনা করার জন্য নিম্নলিখিত সিস্টেম API-গুলি উপলব্ধ থাকে, যেগুলি তাদের ডিভাইস প্রোটেক্টেড প্রতিরূপগুলির সমতুল্য।

  • Context.createCredentialProtectedStorageContext()
  • Context.isCredentialProtectedStorage()

একাধিক ব্যবহারকারীকে সমর্থন করুন

একাধিক ব্যবহারকারীর পরিবেশে প্রত্যেক ব্যবহারকারী একটি পৃথক এনক্রিপশন কী পান। প্রত্যেক ব্যবহারকারী দুটি কী পান: একটি ডিই (DE) এবং একটি সিই (CE) কী। ব্যবহারকারী ০-কে অবশ্যই প্রথমে ডিভাইসে লগ ইন করতে হবে, কারণ তিনি একজন বিশেষ ব্যবহারকারী। ডিভাইস অ্যাডমিনিস্ট্রেশন ব্যবহারের জন্য এটি প্রাসঙ্গিক।

ক্রিপ্টো-সচেতন অ্যাপগুলো বিভিন্ন ব্যবহারকারীর সাথে এইভাবে যোগাযোগ করে: INTERACT_ACROSS_USERS এবং INTERACT_ACROSS_USERS_FULL একটি অ্যাপকে ডিভাইসের সমস্ত ব্যবহারকারীর উপর কাজ করার অনুমতি দেয়। তবে, এই অ্যাপগুলো শুধুমাত্র সেইসব ব্যবহারকারীর CE-এনক্রিপ্টেড ডিরেক্টরি অ্যাক্সেস করতে পারে, যাদের ডিভাইসগুলো ইতিমধ্যেই আনলক করা আছে।

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

প্রতিটি ওয়ার্ক প্রোফাইল ইউজার আইডির জন্যও দুটি কী থাকে: DE এবং CE। যখন ওয়ার্ক চ্যালেঞ্জটি পূরণ করা হয়, তখন প্রোফাইল ইউজারটি আনলক হয়ে যায় এবং KeyMint (TEE-তে থাকা) প্রোফাইলটির TEE কী প্রদান করতে পারে।

আপডেটগুলি পরিচালনা করুন

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

যখন কোনো লিগ্যাসি OTA সলিউশন ব্যবহার করা হয়, যেটির userdata পার্টিশনে থাকা OTA ফাইলটি অ্যাক্সেস করার জন্য রিকভারি প্রয়োজন হয়:

  1. userdata পার্টিশনে একটি শীর্ষ-স্তরের ডিরেক্টরি (যেমন misc_ne ) তৈরি করুন।
  2. এই শীর্ষ-স্তরের ডিরেক্টরিটি এনক্রিপ্টবিহীন রাখতে কনফিগার করুন (দেখুন ডিরেক্টরি বাদ দেওয়া )।
  3. OTA প্যাকেজগুলো রাখার জন্য শীর্ষ-স্তরের ডিরেক্টরির মধ্যে একটি ডিরেক্টরি তৈরি করুন।
  4. এই ডিরেক্টরি এবং এর বিষয়বস্তুতে প্রবেশাধিকার নিয়ন্ত্রণ করতে একটি SELinux রুল এবং ফাইল কনটেক্সট যোগ করুন। শুধুমাত্র যে প্রসেস বা অ্যাপগুলো OTA আপডেট গ্রহণ করে, তারাই এই ডিরেক্টরিতে পড়তে ও লিখতে পারবে। অন্য কোনো অ্যাপ বা প্রসেসের এই ডিরেক্টরিতে প্রবেশাধিকার থাকা উচিত নয়।

বৈধতা

ফিচারটির বাস্তবায়িত সংস্করণটি উদ্দেশ্য অনুযায়ী কাজ করছে কিনা তা নিশ্চিত করতে, প্রথমে DirectBootHostTest এবং EncryptionTest-এর মতো বিভিন্ন CTS এনক্রিপশন টেস্টগুলো চালান।

ডিভাইসটিতে অ্যান্ড্রয়েড ১১ বা তার উচ্চতর সংস্করণ চালিত হলে, vts_kernel_encryption_test- ও চালান: 

atest vts_kernel_encryption_test

অথবা: 

vts-tradefed run vts -m vts_kernel_encryption_test

এছাড়াও, ডিভাইস নির্মাতারা FBE সক্রিয় থাকা একটি ডিভাইসে নিম্নলিখিত ম্যানুয়াল পরীক্ষাগুলো করতে পারেন:

  • ro.crypto.state এর অস্তিত্ব আছে কিনা তা যাচাই করুন।
    • ro.crypto.state এনক্রিপ্ট করা আছে কিনা তা নিশ্চিত করুন।
  • ro.crypto.type এর অস্তিত্ব আছে কিনা তা যাচাই করুন।
    • নিশ্চিত করুন ro.crypto.type file এ সেট করা আছে।

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

adb root; adb shell ls /data/user/10

অন্যান্য ডিভাইসে (বেশিরভাগ নন-অটোমোটিভ ডিভাইস), প্রধান ব্যবহারকারী হলো ইউজার 0, তাই চালান: 

adb root; adb shell ls /data/user/0

যাচাই করুন যে তালিকাভুক্ত ফাইলের নামগুলো Base64-এনকোডেড কিনা, যা নির্দেশ করে যে ফাইলের নামগুলো এনক্রিপ্ট করা আছে এবং সেগুলো ডিক্রিপ্ট করার চাবি এখনও পাওয়া যায়নি। যদি ফাইলের নামগুলো প্লেইনটেক্সটে তালিকাভুক্ত থাকে, তাহলে কিছু একটা ভুল আছে।

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

AOSP বাস্তবায়নের বিবরণ

এই বিভাগে AOSP বাস্তবায়নের বিশদ বিবরণ দেওয়া হয়েছে এবং ফাইল-ভিত্তিক এনক্রিপশন কীভাবে কাজ করে তা বর্ণনা করা হয়েছে। ডিভাইস নির্মাতাদের তাদের ডিভাইসে FBE এবং ডিরেক্ট বুট ব্যবহার করার জন্য এখানে কোনো পরিবর্তন করার প্রয়োজন হবে না।

fscrypt এনক্রিপশন

AOSP বাস্তবায়নে কার্নেলে 'fscrypt' এনক্রিপশন (যা ext4 এবং f2fs দ্বারা সমর্থিত) ব্যবহৃত হয় এবং এটি সাধারণত নিম্নরূপে কনফিগার করা থাকে:

  • XTS মোডে AES-256 দিয়ে ফাইলের বিষয়বস্তু এনক্রিপ্ট করুন
  • CBC-CTS মোডে AES-256 ব্যবহার করে ফাইলের নাম এনক্রিপ্ট করুন

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

fscrypt এনক্রিপশন পলিসির দুটি সংস্করণ সমর্থন করে: সংস্করণ ১ এবং সংস্করণ ২। সংস্করণ ১ এখন আর ব্যবহৃত হয় না, এবং Android 11 ও তার পরবর্তী সংস্করণসহ চালু হওয়া ডিভাইসগুলোর জন্য CDD-এর প্রয়োজনীয়তাগুলো শুধুমাত্র সংস্করণ ২-এর সাথেই সামঞ্জস্যপূর্ণ। সংস্করণ ২ এনক্রিপশন পলিসিগুলো ইউজারস্পেস থেকে সরবরাহ করা কীগুলো থেকে প্রকৃত এনক্রিপশন কী তৈরি করতে HKDF-SHA512 ব্যবহার করে।

fscrypt সম্পর্কে আরও তথ্যের জন্য, আপস্ট্রিম কার্নেল ডকুমেন্টেশন দেখুন।

স্টোরেজ ক্লাস

নিম্নলিখিত সারণিতে FBE কী-গুলো এবং সেগুলোর দ্বারা সুরক্ষিত ডিরেক্টরিগুলো আরও বিস্তারিতভাবে তালিকাভুক্ত করা হয়েছে:

স্টোরেজ ক্লাস বর্ণনা ডিরেক্টরি
এনক্রিপ্ট করা হয়নি /data এর মধ্যে থাকা ডিরেক্টরিগুলো, যেগুলোকে FBE দ্বারা সুরক্ষিত করা যায় না বা করার প্রয়োজন নেই। যেসব ডিভাইস মেটাডেটা এনক্রিপশন ব্যবহার করে, সেগুলোতে এই ডিরেক্টরিগুলো পুরোপুরি এনক্রিপ্টবিহীন থাকে না, বরং মেটাডেটা এনক্রিপশন কী দ্বারা সুরক্ষিত থাকে, যা সিস্টেম ডিই (System DE)-এর সমতুল্য।
  • /data/apex , /data/apex/decompressed এবং /data/apex/ota_reserved ব্যতীত, যেগুলো সিস্টেম ডিই (DE)।
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • সেই সমস্ত ডিরেক্টরি যাদের সাবডিরেক্টরিগুলো ভিন্ন ভিন্ন FBE কী ব্যবহার করে। উদাহরণস্বরূপ, যেহেতু প্রতিটি /data/user/${user_id} ডিরেক্টরি ব্যবহারকারী-ভিত্তিক একটি কী ব্যবহার করে, /data/user নিজে কোনো কী ব্যবহার করে না।
সিস্টেম ডিই ডিভাইস-এনক্রিপ্টেড ডেটা যা কোনো নির্দিষ্ট ব্যবহারকারীর সাথে সংযুক্ত নয়
  • /data/apex/decompressed
  • /data/apex/ota_reserved
  • /data/app
  • /data/misc
  • /data/system
  • /data/vendor
  • /data এর অন্য সমস্ত সাবডিরেক্টরি, যেগুলোকে এই সারণিতে ভিন্ন শ্রেণীভুক্ত হিসেবে উল্লেখ করা হয়নি।
প্রতি-বুট ক্ষণস্থায়ী সিস্টেম ফাইল, যেগুলো রিবুটের পর টিকে থাকার প্রয়োজন নেই। /data/per_boot
ব্যবহারকারী সিই (অভ্যন্তরীণ) অভ্যন্তরীণ স্টোরেজে প্রতি-ব্যবহারকারীর পরিচয়পত্র-এনক্রিপ্ট করা ডেটা
  • /data/data (যা /data/user/0 এর একটি বিকল্প নাম)
  • /data/media/${user_id}
  • /data/misc_ce/${user_id}
  • /data/system_ce/${user_id}
  • /data/user/${user_id}
  • /data/vendor_ce/${user_id}
ব্যবহারকারী ডিই (অভ্যন্তরীণ) অভ্যন্তরীণ স্টোরেজে প্রতি-ব্যবহারকারী ডিভাইস-এনক্রিপ্টেড ডেটা
  • /data/misc_de/${user_id}
  • /data/system_de/${user_id}
  • /data/user_de/${user_id}
  • /data/vendor_de/${user_id}
ব্যবহারকারী সিই (গ্রহণযোগ্য) গ্রহণযোগ্য স্টোরেজে প্রতি-ব্যবহারকারীর পরিচয়পত্র-এনক্রিপ্ট করা ডেটা
  • /mnt/expand/${volume_uuid}/media/${user_id}
  • /mnt/expand/${volume_uuid}/misc_ce/${user_id}
  • /mnt/expand/${volume_uuid}/user/${user_id}
ব্যবহারকারী ডিই (গ্রহণযোগ্য) অ্যাডপ্টেবল স্টোরেজে প্রতি-ব্যবহারকারী ডিভাইস-এনক্রিপ্টেড ডেটা
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

চাবি সংরক্ষণ এবং সুরক্ষা

প্রতি-বুট কী (per-boot key) ছাড়া, সমস্ত FBE কী vold দ্বারা পরিচালিত হয় এবং ডিস্কে এনক্রিপ্ট করা অবস্থায় সংরক্ষিত থাকে; প্রতি-বুট কী একেবারেই সংরক্ষিত হয় না। নিম্নলিখিত সারণিতে বিভিন্ন FBE কী-গুলির সংরক্ষিত স্থানগুলির তালিকা দেওয়া হলো:

চাবির ধরন গুরুত্বপূর্ণ অবস্থান কী অবস্থানের স্টোরেজ ক্লাস
সিস্টেম ডিই কী /data/unencrypted এনক্রিপ্ট করা হয়নি
ব্যবহারকারীর CE (অভ্যন্তরীণ) কী /data/misc/vold/user_keys/ce/${user_id} সিস্টেম ডিই
ব্যবহারকারীর ডিই (অভ্যন্তরীণ) কী /data/misc/vold/user_keys/de/${user_id} সিস্টেম ডিই
ব্যবহারকারী CE (গ্রহণযোগ্য) কী /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} ব্যবহারকারী সিই (অভ্যন্তরীণ)
ব্যবহারকারী ডিই (গ্রহণযোগ্য) কী /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} ব্যবহারকারী ডিই (অভ্যন্তরীণ)

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

vold সমস্ত FBE কী-এর উপর একটি এনক্রিপশন স্তরও প্রয়োগ করে। অভ্যন্তরীণ স্টোরেজের জন্য CE কী ব্যতীত প্রতিটি কী তার নিজস্ব কীস্টোর কী ব্যবহার করে AES-256-GCM দ্বারা এনক্রিপ্ট করা হয়, যা TEE-এর বাইরে প্রকাশ করা হয় না। এটি নিশ্চিত করে যে, ভেরিফাইড বুট দ্বারা বলবৎকৃত একটি বিশ্বস্ত অপারেটিং সিস্টেম বুট না হওয়া পর্যন্ত FBE কী আনলক করা যাবে না। কীস্টোর কী-এর উপর রোলব্যাক রেজিস্ট্যান্সের জন্যও অনুরোধ করা হয়, যা KeyMint দ্বারা সমর্থিত ডিভাইসগুলিতে FBE কী নিরাপদে মুছে ফেলার সুযোগ দেয়। যখন রোলব্যাক রেজিস্ট্যান্স উপলব্ধ থাকে না, তখন একটি সর্বোত্তম বিকল্প ব্যবস্থা হিসাবে, কী-এর সাথে সংরক্ষিত secdiscardable ফাইলে থাকা ১৬৩৮৪টি র‍্যান্ডম বাইটের SHA-512 হ্যাশটি কীস্টোর কী-এর Tag::APPLICATION_ID হিসাবে ব্যবহৃত হয়। একটি FBE কী পুনরুদ্ধার করার জন্য এই সমস্ত বাইট পুনরুদ্ধার করা প্রয়োজন।

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

এটি অর্জন করার জন্য, vold ব্যবহারকারীর সিন্থেটিক পাসওয়ার্ড থেকে প্রাপ্ত একটি AES-256-GCM কী ব্যবহার করে অভ্যন্তরীণ স্টোরেজের জন্য প্রতিটি CE কী এনক্রিপ্ট করে। সিন্থেটিক পাসওয়ার্ড হলো একটি অপরিবর্তনীয় উচ্চ-এনট্রপি ক্রিপ্টোগ্রাফিক গোপনীয়তা যা প্রতিটি ব্যবহারকারীর জন্য এলোমেলোভাবে তৈরি করা হয়। system_server এর LockSettingsService সিন্থেটিক পাসওয়ার্ড এবং এটি সুরক্ষিত রাখার পদ্ধতিগুলো পরিচালনা করে।

LSKF দিয়ে সিন্থেটিক পাসওয়ার্ড সুরক্ষিত করতে, LockSettingsService প্রথমে LSKF-টিকে scrypt মধ্য দিয়ে পাঠিয়ে প্রসারিত করে, যার লক্ষ্য থাকে প্রায় ২৫ মিলিসেকেন্ড সময় এবং প্রায় ২ মেগাবাইট মেমরি ব্যবহার। যেহেতু LSKF সাধারণত ছোট হয়, তাই এই ধাপটি সাধারণত খুব বেশি নিরাপত্তা প্রদান করে না। নিরাপত্তার প্রধান স্তরটি হলো নিচে বর্ণিত Secure Element (SE) বা TEE-দ্বারা বলবৎকৃত রেট-লিমিটিং।

যদি ডিভাইসটি উইভার এইচএএল (Weaver HAL) প্রয়োগ করে, তাহলে LockSettingsService উইভার ব্যবহার করে স্ট্রেচড এলএসকেএফ (stretched LSKF)-কে এসই (SE) বা টিইই (TEE)-তে সংরক্ষিত একটি হাই-এন্ট্রপি র‍্যান্ডম সিক্রেটের সাথে ম্যাপ করে। এরপর LockSettingsService সিন্থেটিক পাসওয়ার্ডটিকে দুইবার এনক্রিপ্ট করে: প্রথমবার স্ট্রেচড এলএসকেএফ এবং উইভার সিক্রেট থেকে প্রাপ্ত একটি সফটওয়্যার কী দিয়ে, এবং দ্বিতীয়বার একটি নন-অথ-বাউন্ড কীস্টোর কী দিয়ে। এটি এলএসকেএফ অনুমানের উপর এসই বা টিইই দ্বারা প্রয়োগকৃত রেট-লিমিটিং প্রদান করে।

যদি ডিভাইসটি উইভার (Weaver) প্রয়োগ না করে, তাহলে LockSettingsService পরিবর্তে স্ট্রেচড এলএসকেএফ (stretched LSKF)-কে গেটকিপার পাসওয়ার্ড (Gatekeeper password) হিসেবে ব্যবহার করে। এরপর LockSettingsService সিন্থেটিক পাসওয়ার্ডটিকে দুইবার এনক্রিপ্ট করে: প্রথমবার স্ট্রেচড এলএসকেএফ এবং একটি সেকডিসকার্ডেবল (secdiscardable) ফাইলের হ্যাশ থেকে প্রাপ্ত একটি সফটওয়্যার কী দিয়ে, এবং দ্বিতীয়বার গেটকিপার এনরোলমেন্টের সাথে অথ-বাউন্ড (auth-bound) একটি কীস্টোর কী (Keystore key) দিয়ে। এটি এলএসকেএফ অনুমানের ক্ষেত্রে টিইই (TEE) দ্বারা বলবৎকৃত রেট-লিমিটিং (rate-limiting) প্রদান করে।

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