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

Android 7.0 এবং তার পরবর্তী যেকোনও ভার্সনে ফাইল-ভিত্তিক এনক্রিপশন (FBE) কাজ করে। ফাইল-ভিত্তিক এনক্রিপশন বিভিন্ন কী ব্যবহার করে বিভিন্ন ফাইল এনক্রিপ্ট করার অনুমতি দেয় যা স্বাধীনভাবে আনলক করা যেতে পারে।

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

Android 10 ও তার পরবর্তী যেকোনও ভার্সন সহ লঞ্চ করা সব ডিভাইসে ফাইল-ভিত্তিক এনক্রিপশন ব্যবহার করতে হবে।

ডাইরেক্ট বুট

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

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

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

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

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

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

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

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

  • টেলিফোনি পরিষেবা ও ডায়ালার
  • লক স্ক্রিনে পাসওয়ার্ড লেখার ইনপুট পদ্ধতি

উদাহরণ ও সোর্স

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

  • AOSP Dialer (packages/apps/Dialer)
  • ডেস্ক ক্লক (packages/apps/DeskClock)
  • LatinIME (packages/inputmethods/LatinIME)*
  • Settings অ্যাপ (packages/apps/Settings)*
  • SystemUI (frameworks/base/packages/SystemUI)*

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

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

ডিপেন্ডেন্সি

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

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

প্রয়োগ

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

কার্নেল সংক্রান্ত সহায়তা

Ext4 এবং F2FS এনক্রিপশনের জন্য কার্নেল সহায়তা Android সাধারণ কার্নেল, ভার্সন ৩.১৮ এবং তার পরবর্তী ভার্সনে উপলভ্য। 5.1 বা তার পরবর্তী ভার্সনের কোনও কার্নেলে এটি চালু করতে, এগুলি ব্যবহার করুন: 

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

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

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 হতে পারে। Android 11 থেকে ডিফল্ট অ্যালগরিদম নির্দিষ্ট করার জন্য এটি ফাঁকাও রাখা যেতে পারে, যা হল 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 হবে, অথবা contents_encryption_mode যদি adiantum হয়, তাহলে ডিফল্ট হিসেবে adiantum হবে।
  • Android 11-এ নতুন flags প্যারামিটার হল + ক্যারেক্টার দিয়ে আলাদা করা ফ্ল্যাগের একটি তালিকা। নিম্নলিখিত ফ্ল্যাগ কাজ করে:
    • v1 ফ্ল্যাগটি এনক্রিপশন নীতি ভার্সন ১ বেছে নেয়; v2 ফ্ল্যাগটি এনক্রিপশন নীতি ভার্সন ২ বেছে নেয়। ভার্সন ২ এনক্রিপশন নীতি আরও সুরক্ষিত ও নমনীয় কী ডেরিভেশন ফাংশন ব্যবহার করে। ডিভাইসটি Android 11 বা তার পরবর্তী কোনও ভার্সনে লঞ্চ হলে ডিফল্ট হল v2 (ro.product.first_api_level দ্বারা নির্ধারিত), অথবা ডিভাইসটি Android 10 বা তার আগের কোনও ভার্সনে লঞ্চ হলে ডিফল্ট হল v1।
    • inlinecrypt_optimized ফ্ল্যাগ এমন একটি এনক্রিপশন ফর্ম্যাট বেছে নেয় যা ইনলাইন এনক্রিপশন হার্ডওয়্যারের জন্য অপ্টিমাইজ করা হয়েছে এবং এটি অনেক সংখ্যক কী দক্ষতার সাথে ম্যানেজ করে না। এটি CE বা DE কী প্রতি শুধুমাত্র একটি ফাইল কন্টেন্ট এনক্রিপশন কী তৈরি করে এটি করে, প্রতিটি ফাইলের জন্য একটি করে নয়। IV (ইনিশিয়ালাইজেশন ভেক্টর) জেনারেশন সেই অনুযায়ী অ্যাডজাস্ট করা হয়।
    • emmc_optimized ফ্ল্যাগটি inlinecrypt_optimized-এর মতো, তবে এটি একটি IV জেনারেশন পদ্ধতিও বেছে নেয় যা IV-কে ৩২ বিটে সীমাবদ্ধ করে। এই ফ্ল্যাগ শুধুমাত্র ইনলাইন এনক্রিপশন হার্ডওয়্যারে ব্যবহার করা উচিত যা JEDEC eMMC v5.2 স্পেসিফিকেশন মেনে চলে এবং তাই শুধুমাত্র ৩২-বিট IV-কে সাপোর্ট করে। অন্য ইনলাইন এনক্রিপশন হার্ডওয়্যারে, এর পরিবর্তে inlinecrypt_optimized ব্যবহার করুন। এই ফ্ল্যাগ UFS-ভিত্তিক স্টোরেজে কখনই ব্যবহার করা উচিত নয়; UFS স্পেসিফিকেশন ৬৪-বিট IV-এর ব্যবহারের অনুমতি দেয়।
    • হার্ডওয়্যার-র‌্যাপড ইনলাইন এনক্রিপশন কী কাজ করে এমন ডিভাইসে, wrappedkey বা wrappedkey_v0 ফ্ল্যাগ যোগ করে FBE কী হার্ডওয়্যার-র‌্যাপড করা যেতে পারে। wrappedkey হল আধুনিক ভার্সন; wrappedkey_v0 শুধুমাত্র সেইসব ডিভাইসে ব্যবহার করা উচিত যেগুলিতে wrappedkey কাজ করে না অথবা আগে থেকেই wrappedkey_v0 লঞ্চ করা আছে। আরও তথ্যের জন্য, র‌্যাপ করা কী চালু করুন দেখুন।
    • dusize_4k ফ্ল্যাগ এনক্রিপশন ডেটা ইউনিট সাইজকে ৪০৯৬ বাইট হতে বাধ্য করে, এমনকি ফাইলসিস্টেম ব্লক সাইজ ৪০৯৬ বাইট না হলেও। এনক্রিপশন ডেটা ইউনিটের সাইজ হল ফাইল কন্টেন্ট এনক্রিপশনের গ্র্যানুলারিটি। এই ফ্ল্যাগ Android 15 থেকে উপলভ্য। এই ফ্ল্যাগটি শুধুমাত্র ইনলাইন এনক্রিপশন হার্ডওয়্যারের ব্যবহার চালু করতে ব্যবহার করা উচিত যা ৪০৯৬ বাইটের চেয়ে বড় ডেটা ইউনিট সমর্থন করে না, এমন একটি ডিভাইসে যা ৪০৯৬ বাইটের চেয়ে বড় পৃষ্ঠার আকার ব্যবহার করে এবং যা f2fs ফাইলসিস্টেম ব্যবহার করে।

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

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

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

ডিফল্ট হিসেবে, Linux কার্নেলের ক্রিপ্টোগ্রাফি API ব্যবহার করে ফাইলের কন্টেন্ট এনক্রিপ্ট করা হয়। আপনি যদি এর পরিবর্তে ইনলাইন এনক্রিপশন হার্ডওয়্যার ব্যবহার করতে চান, তাহলে 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

অ্যাডপ্টেবেল স্টোরেজ

Android 9 থেকে, FBE এবং অ্যাডপ্টেবেল স্টোরেজ একসাথে ব্যবহার করা যেতে পারে।

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

Android 11 বা তার পরবর্তী ভার্সন সহ লঞ্চ হওয়া ডিভাইসে, নিম্নলিখিত প্রপার্টি ব্যবহার করুন:

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

Android 10 ও তার আগের যেকোনও ভার্সন দিয়ে লঞ্চ করা ডিভাইসে, নিম্নলিখিত প্রপার্টি ব্যবহার করুন:

  • 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-এর প্রয়োজন যে KeyMint যেন post-fs-data বুট ফেজেইvold অনুরোধ হ্যান্ডেল করার জন্য প্রস্তুত থাকে, এই সময় প্রাথমিক কী সেট-আপ করা হয়।

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

init /data-এর সব টপ-লেভেল ডিরেক্টরির উপর সিস্টেম DE কী প্রয়োগ করে, তবে যেসব ডিরেক্টরি এনক্রিপ্ট করা যাবে না, যেমন, যে ডিরেক্টরি সিস্টেম DE কী ধারণ করে এবং যে ডিরেক্টরি ব্যবহারকারীর CE বা DE ডিরেক্টরি ধারণ করে, সেগুলির উপর এটি প্রয়োগ করা হয় না। এনক্রিপশন কী রিকার্সিভভাবে প্রয়োগ করা হয় এবং সাবডিরেক্টরি দ্বারা ওভাররাইড করা যায় না।

Android 11 ও তার পরবর্তী যেকোনও ভার্সনে, ডিরেক্টরির ক্ষেত্রে প্রযোজ্য init কী, init স্ক্রিপ্টে mkdir কমান্ডের encryption=<action> আর্গুমেন্ট দ্বারা নিয়ন্ত্রণ করা যেতে পারে। <action>-এর সম্ভাব্য ভ্যালু Android init language-এর README ডকুমেন্টে উল্লেখ করা আছে।

Android 10-এ, init এনক্রিপশন অ্যাকশন নিম্নলিখিত লোকেশনে হার্ডকোড করা ছিল: 

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Android 9 এবং তার আগের ভার্সনে, লোকেশন ছিল: 

/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 স্টোরেজ ব্যবহার করতে হবে। এই বিকল্প ব্যবহারকারী ডিভাইস প্রস্তুতকারকদের উচিত, তারা যে ডেটা স্টোর করছে তা ভালোভাবে পরীক্ষা করে দেখা, যাতে নিশ্চিত করা যায় যে এতে কোনও ব্যক্তিগত তথ্য নেই।

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

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

একাধিক ব্যবহারকারীর জন্য কাজ করে

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

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

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

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

আপডেট ম্যানেজ করা

রিকভারি পার্টিশন, userdata পার্টিশনে DE-সুরক্ষিত স্টোরেজ অ্যাক্সেস করতে পারছে না। FBE প্রয়োগ করা ডিভাইসগুলিকে A/B সিস্টেম আপডেট ব্যবহার করে OTA-কে সাপোর্ট করার জন্য জোরালোভাবে সাজেস্ট করা হয়। যেহেতু সাধারণ অপারেশন চলাকালীন OTA প্রয়োগ করা যেতে পারে, তাই এনক্রিপ্ট করা ড্রাইভে ডেটা অ্যাক্সেস করার জন্য রিকভারির প্রয়োজন নেই।

পুরনো OTA সমাধান ব্যবহার করার সময়, userdata পার্টিশনে OTA ফাইল অ্যাক্সেস করার জন্য রিকভারি প্রয়োজন:

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

যাচাইকরণ

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

ডিভাইসে Android 11 বা তার পরবর্তী যেকোনও ভার্সন থাকলে, 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 স্টোরেজ চেক করতে নিম্নলিখিত কমান্ড রান করুন। ডিভাইসটি হেডলেস সিস্টেম ইউজার মোড (বেশিরভাগ অটোমোটিভ ডিভাইস) ব্যবহার করলে, প্রধান ব্যবহারকারী হলেন ব্যবহারকারী ১০, তাই রান করুন: 

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

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

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

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

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

AOSP প্রয়োগ করা সংক্রান্ত বিবরণ

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

fscrypt এনক্রিপশন

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

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

এছাড়াও, Adiantum এনক্রিপশন কাজ করে। Adiantum এনক্রিপশন চালু করা থাকলে, ফাইলের কন্টেন্ট ও ফাইলের নাম, দুটিই Adiantum-এর মাধ্যমে এনক্রিপ্ট করা হয়।

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 নিজে কোনও 'কী' ব্যবহার করে না।
সিস্টেম DE ডিভাইস-এনক্রিপ্ট করা ডেটা কোনও নির্দিষ্ট ব্যবহারকারীর সাথে যুক্ত নয়
  • /data/apex/decompressed
  • /data/apex/ota_reserved
  • /data/app
  • /data/misc
  • /data/system
  • /data/vendor
  • /data-এর অন্যান্য সব সাবডিরেক্টরি যেগুলি এই সারণী আলাদা ক্লাস হিসেবে উল্লেখ করেনি
প্রতি-বুট ক্ষণস্থায়ী সিস্টেম ফাইল যা রিবুট করার পরে আর প্রয়োজন হয় না /data/per_boot
ব্যবহারকারী CE (ইন্টার্নাল) অভ্যন্তরীণ স্টোরেজে প্রতি ব্যবহারকারীর জন্য ক্রেডেনশিয়াল-এনক্রিপ্টেড ডেটা
  • /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}
ব্যবহারকারী DE (ইন্টার্নাল) ইন্টার্নাল স্টোরেজে প্রতি ব্যবহারকারীর ডিভাইস-এনক্রিপটেড ডেটা
  • /data/misc_de/${user_id}
  • /data/system_de/${user_id}
  • /data/user_de/${user_id}
  • /data/vendor_de/${user_id}
ব্যবহারকারী CE (গ্রহণযোগ্য) অ্যাডপ্টেবেল স্টোরেজে প্রতি ব্যবহারকারীর জন্য ক্রেডেনশিয়াল-এনক্রিপ্টেড ডেটা
  • /mnt/expand/${volume_uuid}/media/${user_id}
  • /mnt/expand/${volume_uuid}/misc_ce/${user_id}
  • /mnt/expand/${volume_uuid}/user/${user_id}
ব্যবহারকারী DE (অ্যাডপ্টেবল) অ্যাডপ্টেবেল স্টোরেজে ব্যবহারকারী প্রতি ডিভাইস-এনক্রিপটেড ডেটা
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

কী স্টোরেজ ও সুরক্ষা

প্রতি-বুট কী ছাড়া, সব FBE কী vold-এর মাধ্যমে ম্যানেজ করা হয় এবং ডিস্কে এনক্রিপ্ট করে স্টোর করা হয়, প্রতি-বুট কী স্টোর করা হয় না। নিচের সারণীতে বিভিন্ন FBE কী স্টোর করার লোকেশন তালিকাভুক্ত করা হয়েছে:

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

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

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

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

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

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

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

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

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