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

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

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

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

ডাইরেক্ট বুট

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

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

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

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

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

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

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

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

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

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

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

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

* সিস্টেম অ্যাপ্লিকেশন যা defaultToDeviceProtectedStorage ম্যানিফেস্ট বৈশিষ্ট্য ব্যবহার করে

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

নির্ভরতা

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

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

বাস্তবায়ন

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

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

Ext4 এবং F2FS এনক্রিপশনের জন্য কার্নেল সমর্থন অ্যান্ড্রয়েড সাধারণ কার্নেল, 3.18 এবং উচ্চতর সংস্করণে উপলব্ধ। এটি একটি কার্নেলে সক্ষম করতে যা সংস্করণ 5.1 বা উচ্চতর, ব্যবহার করুন:

CONFIG_FS_ENCRYPTION=y

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

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

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

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

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

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 হতে পারে। অ্যান্ড্রয়েড 11 থেকে এটি ডিফল্ট অ্যালগরিদম নির্দিষ্ট করতেও খালি রাখা যেতে পারে, যা aes-256-xts ।
  • filenames_encryption_mode প্যারামিটার সংজ্ঞায়িত করে কোন ক্রিপ্টোগ্রাফিক অ্যালগরিদম ফাইলের নাম এনক্রিপ্ট করতে ব্যবহৃত হয়। এটি হয় aes-256-cts , aes-256-heh , adiantum , অথবা aes-256-hctr2 হতে পারে। নির্দিষ্ট করা না থাকলে, contents_encryption_mode aes-256-cts হলে এটি ডিফল্ট হয় aes-256-xts , অথবা যদি contents_encryption_mode adiantum adiantum ।
  • flags প্যারামিটার, Android 11-এ নতুন, + অক্ষর দ্বারা পৃথক করা পতাকার একটি তালিকা। নিম্নলিখিত পতাকা সমর্থিত:
    • v1 পতাকা সংস্করণ 1 এনক্রিপশন নীতি নির্বাচন করে; v2 পতাকা সংস্করণ 2 এনক্রিপশন নীতি নির্বাচন করে। সংস্করণ 2 এনক্রিপশন নীতিগুলি আরও নিরাপদ এবং নমনীয় কী ডেরিভেশন ফাংশন ব্যবহার করে। ডিভাইসটি Android 11 বা উচ্চতর সংস্করণে চালু হলে ডিফল্ট v2 ( ro.product.first_api_level এর দ্বারা নির্ধারিত), অথবা ডিভাইসটি Android 10 বা তার নিম্ন সংস্করণে চালু হলে v1।
    • inlinecrypt_optimized পতাকা একটি এনক্রিপশন বিন্যাস নির্বাচন করে যা ইনলাইন এনক্রিপশন হার্ডওয়্যারের জন্য অপ্টিমাইজ করা হয় যা দক্ষতার সাথে বড় সংখ্যক কী পরিচালনা করে না। এটি প্রতি ফাইলে একটির পরিবর্তে শুধুমাত্র একটি ফাইলের বিষয়বস্তু এনক্রিপশন কী প্রতি CE বা DE কী প্রাপ্ত করে এটি করে। IV-এর প্রজন্ম (ইনিশিয়ালাইজেশন ভেক্টর) সেই অনুযায়ী সামঞ্জস্য করা হয়।
    • emmc_optimized পতাকা inlinecrypt_optimized এর অনুরূপ, তবে এটি একটি IV প্রজন্মের পদ্ধতিও নির্বাচন করে যা IV-কে 32 বিটের মধ্যে সীমাবদ্ধ করে। এই পতাকাটি শুধুমাত্র ইনলাইন এনক্রিপশন হার্ডওয়্যারে ব্যবহার করা উচিত যা JEDEC eMMC v5.2 স্পেসিফিকেশনের সাথে সঙ্গতিপূর্ণ এবং তাই শুধুমাত্র 32-বিট IV সমর্থন করে। অন্যান্য ইনলাইন এনক্রিপশন হার্ডওয়্যারে, পরিবর্তে inlinecrypt_optimized ব্যবহার করুন। এই পতাকা UFS-ভিত্তিক স্টোরেজে ব্যবহার করা উচিত নয়; UFS স্পেসিফিকেশন 64-বিট IV ব্যবহার করার অনুমতি দেয়।
    • যে ডিভাইসগুলিতে হার্ডওয়্যার-র্যাপড কী সমর্থন করে, wrappedkey_v0 পতাকা FBE-এর জন্য হার্ডওয়্যার-র্যাপড কী ব্যবহার করতে সক্ষম করে। এটি শুধুমাত্র inlinecrypt মাউন্ট বিকল্পের সাথে এবং হয় inlinecrypt_optimized বা emmc_optimized পতাকার সাথে ব্যবহার করা যেতে পারে।

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

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

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

ডিফল্টরূপে, লিনাক্স কার্নেলের ক্রিপ্টোগ্রাফি 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 এবং/অথবা মেটাডেটা এনক্রিপশন ফর্ম্যাটগুলিকে ওভাররাইড করতে পারেন।

অ্যান্ড্রয়েড 11 বা উচ্চতর সংস্করণের সাথে চালু হওয়া ডিভাইসগুলিতে নিম্নলিখিত বৈশিষ্ট্যগুলি ব্যবহার করুন:

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

অ্যান্ড্রয়েড 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 গ্রহণযোগ্য সঞ্চয়স্থানে মেটাডেটা এনক্রিপশন বিন্যাস নির্বাচন করুন। মেটাডেটা এনক্রিপশন ডকুমেন্টেশন দেখুন।

কীমাস্টারের সাথে একীভূত হচ্ছে

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

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

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

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

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

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

অ্যান্ড্রয়েড 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৷ কাজের চ্যালেঞ্জ পূরণ হলে, প্রোফাইল ব্যবহারকারীকে আনলক করা হয় এবং কীমাস্টার (টিইই-তে) প্রোফাইলের টিইই কী প্রদান করতে পারেন।

আপডেট হ্যান্ডলিং

রিকভারি পার্টিশন ইউজারডেটা পার্টিশনে ডি-সুরক্ষিত স্টোরেজ অ্যাক্সেস করতে অক্ষম। FBE বাস্তবায়নকারী ডিভাইসগুলিকে A/B সিস্টেম আপডেট ব্যবহার করে OTA সমর্থন করার জন্য দৃঢ়ভাবে সুপারিশ করা হয়। যেহেতু OTA স্বাভাবিক অপারেশনের সময় প্রয়োগ করা যেতে পারে এনক্রিপ্ট করা ড্রাইভে ডেটা অ্যাক্সেস করার জন্য পুনরুদ্ধারের প্রয়োজন নেই।

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

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

বৈধতা

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

ডিভাইসটি যদি 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 সেট করা আছে

উপরন্তু, পরীক্ষকরা প্রাথমিক ব্যবহারকারীর উপর একটি লকস্ক্রিন সেট সহ একটি userdebug উদাহরণ বুট করতে পারে। তারপর ডিভাইসে adb শেল এবং রুট হতে su ব্যবহার করুন। নিশ্চিত করুন যে /data/data এনক্রিপ্ট করা ফাইলের নাম রয়েছে; যদি তা না হয়, কিছু ভুল।

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

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

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

fscrypt এনক্রিপশন

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

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

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

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

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

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

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

স্টোরেজ ক্লাস বর্ণনা ডিরেক্টরি
সিস্টেম DE ডিভাইস-এনক্রিপ্ট করা ডেটা একটি নির্দিষ্ট ব্যবহারকারীর সাথে আবদ্ধ নয় /data/system , /data/app , এবং /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}
ব্যবহারকারী DE (অভ্যন্তরীণ) অভ্যন্তরীণ সঞ্চয়স্থানে প্রতি ব্যবহারকারী ডিভাইস-এনক্রিপ্ট করা ডেটা
  • /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}
ব্যবহারকারী DE (গ্রহণযোগ্য) গ্রহণযোগ্য সঞ্চয়স্থানে প্রতি-ব্যবহারকারী ডিভাইস-এনক্রিপ্ট করা ডেটা
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

কী স্টোরেজ এবং সুরক্ষা

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

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

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

vold সমস্ত FBE কীগুলিতে এনক্রিপশনের একটি স্তর প্রয়োগ করে। অভ্যন্তরীণ স্টোরেজের জন্য CE কীগুলি ছাড়াও প্রতিটি কী AES-256-GCM এর সাথে এনক্রিপ্ট করা হয়েছে নিজস্ব কীস্টোর কী ব্যবহার করে যা TEE এর বাইরে প্রকাশ করা হয় না। এটি নিশ্চিত করে যে FBE কীগুলিকে আনলক করা যাবে না যদি না একটি বিশ্বস্ত অপারেটিং সিস্টেম বুট না হয়, যেমনটি Verified Boot দ্বারা প্রয়োগ করা হয়েছে। কীস্টোর কী-তেও রোলব্যাক প্রতিরোধের অনুরোধ করা হয়েছে, যা FBE কীগুলিকে নিরাপদে মুছে ফেলার অনুমতি দেয় ডিভাইসগুলিতে যেখানে কীমাস্টার রোলব্যাক প্রতিরোধকে সমর্থন করে। রোলব্যাক রেজিস্ট্যান্স অনুপলব্ধ হলে সর্বোত্তম প্রচেষ্টার ফলব্যাক হিসাবে, কী-এর পাশে সংরক্ষিত secdiscardable ফাইলে সংরক্ষিত 16384 র্যান্ডম বাইটের SHA-512 হ্যাশ কীস্টোর কী-এর অ্যাপ্লিকেশন আইডি ট্যাগ হিসাবে ব্যবহৃত হয়। একটি FBE কী পুনরুদ্ধার করতে এই সমস্ত বাইটগুলি পুনরুদ্ধার করতে হবে।

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

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

LSKF দিয়ে সিন্থেটিক পাসওয়ার্ড সুরক্ষিত করার জন্য, LockSettingsService প্রথমে LSKF কে scrypt মাধ্যমে প্রসারিত করে, প্রায় 25 ms সময় এবং প্রায় 2 MiB মেমরি ব্যবহার লক্ষ্য করে। যেহেতু LSKFগুলি সাধারণত সংক্ষিপ্ত হয়, এই পদক্ষেপটি সাধারণত খুব বেশি নিরাপত্তা প্রদান করে না। নিরাপত্তার প্রধান স্তর হল সিকিউর এলিমেন্ট (SE) বা TEE- প্রয়োগকৃত রেট লিমিটিং নীচে বর্ণিত।

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

যদি ডিভাইসে SE না থাকে, তাহলে LockSettingsService পরিবর্তে প্রসারিত LSKF কে গেটকিপার পাসওয়ার্ড হিসেবে ব্যবহার করে। LockSettingsService তারপর সিন্থেটিক পাসওয়ার্ডটি দুবার এনক্রিপ্ট করে: প্রথমটি প্রসারিত LSKF থেকে প্রাপ্ত একটি সফ্টওয়্যার কী এবং একটি সেকডিসকার্ডেবল ফাইলের হ্যাশ দিয়ে, এবং দ্বিতীয়টি একটি কীস্টোর কী দিয়ে যা গেটকিপার তালিকাভুক্তির জন্য প্রমাণীকৃত। এটি LSKF অনুমানের TEE-প্রয়োগকৃত রেট লিমিটিং প্রদান করে।

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