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

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

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

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

Direct Boot

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

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

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

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

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

Direct Boot 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 কী-এর জন্য কী ম্যানেজমেন্ট করা যায়। কার্নেলে ফাইল-ভিত্তিক এনক্রিপশন ক্ষমতা ব্যবহার করার জন্য মূল পরিবর্তনগুলি ছাড়াও, লকস্ক্রিন এবং SystemUI সহ অনেক সিস্টেম প্যাকেজ FBE এবং ডাইরেক্ট বুট ফিচারকে সাপোর্ট করার জন্য পরিবর্তন করা হয়েছে। এগুলির মধ্যে রয়েছে:

  • AOSP Dialer (packages/apps/Dialer)
  • Desk Clock (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 কী-এর জন্য অনুরোধ করতে না পারে।
  • অননুমোদিত অপারেটিং সিস্টেম যাতে DE কী অ্যাক্সেস করতে না পারে তা নিশ্চিত করতে, KeyMint ইনিশিয়ালাইজেশনের সাথে বাউন্ড করা হার্ডওয়্যার রুট অফ ট্রাস্ট এবং যাচাই করা বুট প্রয়োজন।

প্রয়োগ

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

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

Ext4 এবং F2FS এনক্রিপশনের জন্য কার্নেল সহায়তা Android সাধারণ কার্নেল, ভার্সন 3.18 এবং তার পরবর্তী ভার্সনে উপলভ্য। ভার্সন 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 হবে।
  • flags প্যারামিটার, Android 11-এ নতুন, এটি হল + অক্ষর দ্বারা আলাদা করা ফ্ল্যাগের তালিকা। নিম্নলিখিত ফ্ল্যাগ কাজ করে:
    • v1 ফ্ল্যাগ ভার্সন ১ এনক্রিপশন নীতি বেছে নেয়; v2 ফ্ল্যাগ ভার্সন ২ এনক্রিপশন নীতি বেছে নেয়। ভার্সন ২ এনক্রিপশন নীতি আরও সুরক্ষিত ও নমনীয় কী ডেরিভেশন ফাংশন ব্যবহার করে। ডিভাইসটি Android 11 বা তার পরবর্তী কোনও ভার্সনে লঞ্চ হলে (ro.product.first_api_level দ্বারা নির্ধারিত) ডিফল্ট হল v2, অথবা ডিভাইসটি 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 বা তার আগের যেকোনও ভার্সন সহ লঞ্চ হওয়া ডিভাইসে, FSCRYPT_MODE_PRIVATE ফাইল কন্টেন্ট এনক্রিপশন মোডের ব্যবহার নির্দিষ্ট করতে fileencryption=ice-ও গ্রহণ করা হয়। এই মোডটি 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 এবং অ্যাডপ্টেবেল স্টোরেজ একসাথে ব্যবহার করা যেতে পারে।

userdata-এর জন্য fileencryption fstab বিকল্প নির্দিষ্ট করলে, তা অ্যাডপ্টেবেল স্টোরেজে 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 ভাষার জন্য 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

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

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}
User DE (adoptable) অ্যাডপ্টেবেল স্টোরেজে ব্যবহারকারী প্রতি ডিভাইস-এনক্রিপটেড ডেটা
  • /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 কী ব্যবহার করে। সিন্থেটিক পাসওয়ার্ড হল একটি অপরিবর্তনীয় হাই-এনট্রপি ক্রিপ্টোগ্রাফিক সিক্রেট যা প্রতিটি ব্যবহারকারীর জন্য র‍্যান্ডমভাবে তৈরি করা হয়। system_server-এ LockSettingsService সিন্থেটিক পাসওয়ার্ড এবং এটি সুরক্ষিত রাখার উপায় ম্যানেজ করে।

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 কী দিয়ে যা Gatekeeper এনরোলমেন্টের সাথে অথ-বাউন্ড। এটি LSKF অনুমানের TEE-এনফোর্সড রেট-লিমিটিং প্রদান করে।

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