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

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

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

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

সতর্কতা : অ্যান্ড্রয়েড ৭.০ থেকে ৮.১ পর্যন্ত, FBE গ্রহণযোগ্য স্টোরেজের সাথে সামঞ্জস্যপূর্ণ নয় এবং বহিরাগত স্টোরেজ মিডিয়া (যেমন একটি SD কার্ড) শুধুমাত্র ঐতিহ্যবাহী স্টোরেজ হিসাবে ব্যবহার করা যেতে পারে। অ্যান্ড্রয়েড ৯ এবং উচ্চতর সংস্করণগুলিতে, FBE গ্রহণযোগ্য স্টোরেজের সাথে সামঞ্জস্যপূর্ণ।

ডাইরেক্ট বুট

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

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

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

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

দ্রষ্টব্য : যখনই সম্ভব, ফাইলগুলি সিই স্টোরেজে রাখা উচিত।

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

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

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

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

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

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

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

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

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

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

নির্ভরতা

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

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

বাস্তবায়ন

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

কর্মক্ষমতা আরও উন্নত করতে এবং বিদ্যুৎ ব্যবহার কমাতে, ডিভাইস নির্মাতারা ইনলাইন এনক্রিপশন হার্ডওয়্যার বাস্তবায়নের কথাও বিবেচনা করতে পারেন, যা স্টোরেজ ডিভাইসে/থেকে আসার সময় ডেটা এনক্রিপ্ট/ডিক্রিপ্ট করে। অ্যান্ড্রয়েড সাধারণ কার্নেলগুলিতে (সংস্করণ 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 সক্ষম করে; তবে, প্রয়োজনে গ্রহণযোগ্য স্টোরেজে এনক্রিপশন ফর্ম্যাটটি ওভাররাইড করা যেতে পারে।

অভ্যন্তরীণ সঞ্চয়স্থান

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

• 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 হতে পারে। যদি নির্দিষ্ট না করা থাকে, তাহলে এটি aes-256-cts এ ডিফল্টভাবে ব্যবহৃত হয় যদি contents_encryption_mode aes-256-xts হয়, অথবা adiantum এ ব্যবহৃত হয় যদি contents_encryption_mode adiantum হয়।
• অ্যান্ড্রয়েড ১১-এ নতুন flags প্যারামিটারটি হল + অক্ষর দ্বারা পৃথক করা ফ্ল্যাগের একটি তালিকা। নিম্নলিখিত ফ্ল্যাগগুলি সমর্থিত:
  • v1 ফ্ল্যাগটি ভার্সন 1 এনক্রিপশন নীতি নির্বাচন করে; v2 ফ্ল্যাগটি ভার্সন 2 এনক্রিপশন নীতি নির্বাচন করে। ভার্সন 2 এনক্রিপশন নীতিগুলি আরও নিরাপদ এবং নমনীয় কী ডেরিভেশন ফাংশন ব্যবহার করে। ডিভাইসটি যদি Android 11 বা তার উচ্চতর সংস্করণে ( ro.product.first_api_level দ্বারা নির্ধারিত) চালু হয় তবে ডিফল্ট v2 হয়, অথবা ডিভাইসটি যদি Android 10 এবং তার নিম্নতর সংস্করণে চালু হয় তবে v1 হয়।
  • inlinecrypt_optimized ফ্ল্যাগটি এমন একটি এনক্রিপশন ফর্ম্যাট নির্বাচন করে যা ইনলাইন এনক্রিপশন হার্ডওয়্যারের জন্য অপ্টিমাইজ করা হয় যা প্রচুর সংখ্যক কী দক্ষতার সাথে পরিচালনা করে না। এটি প্রতি ফাইলের জন্য একটির পরিবর্তে, প্রতি CE বা DE কী থেকে কেবল একটি ফাইল সামগ্রী এনক্রিপশন কী বের করে এটি করে। IVs (ইনিশিয়ালাইজেশন ভেক্টর) এর জেনারেশন সেই অনুযায়ী সামঞ্জস্য করা হয়।
  • 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 ফ্ল্যাগের সাথে ব্যবহার করা যেতে পারে।
  • ফাইল সিস্টেম ব্লকের আকার ৪০৯৬ বাইট না হলেও 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 দিয়ে করা হবে।

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

সতর্কতা : যেহেতু fileencryption বিকল্পটি অন-ডিস্ক ফর্ম্যাট নির্ধারণ করে, তাই এটি কোনও OTA দ্বারা পরিবর্তন করা যাবে না।

ডিফল্টরূপে, ফাইল কন্টেন্ট এনক্রিপশন লিনাক্স কার্নেলের ক্রিপ্টোগ্রাফি 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

বিঃদ্রঃ :

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

গ্রহণযোগ্য সঞ্চয়স্থান

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

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

অ্যান্ড্রয়েড ১০ এবং তার আগের ভার্সন দিয়ে লঞ্চ হওয়া ডিভাইসগুলিতে, নিম্নলিখিত বৈশিষ্ট্যগুলি ব্যবহার করুন:

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

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

KeyMint এর সাথে ইন্টিগ্রেট করুন

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

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

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

অ্যান্ড্রয়েড ১১ এবং উচ্চতর সংস্করণে, init ডিরেক্টরিগুলিতে যে কীটি প্রয়োগ করে তা init স্ক্রিপ্টে mkdir কমান্ডের encryption=<action> আর্গুমেন্ট দ্বারা নিয়ন্ত্রণ করা যেতে পারে। <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 স্টোরেজ ব্যবহার করার জন্য সংবেদনশীল ডেটার পথ পরিবর্তন করতে হবে। এই বিকল্পটি ব্যবহার করে ডিভাইস প্রস্তুতকারকদের তাদের সংরক্ষণ করা ডেটা সাবধানে পরীক্ষা করা উচিত যাতে নিশ্চিত করা যায় যে এতে কোনও ব্যক্তিগত তথ্য নেই।

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

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

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

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

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

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

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

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

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

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

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

বৈধতা

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

যদি ডিভাইসটি অ্যান্ড্রয়েড ১১ বা তার উচ্চতর সংস্করণে চলে, তাহলে 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 বিল্ড ব্যবহার করুন, প্রধান ব্যবহারকারীর উপর একটি PIN, প্যাটার্ন বা পাসওয়ার্ড সেট করুন এবং ডিভাইসটি পুনরায় বুট করুন। ডিভাইসটি আনলক করার আগে, প্রধান ব্যবহারকারীর CE স্টোরেজ পরীক্ষা করতে নিম্নলিখিত কমান্ডটি চালান। যদি ডিভাইসটি হেডলেস সিস্টেম ইউজার মোড (বেশিরভাগ অটোমোটিভ ডিভাইস) ব্যবহার করে, তাহলে প্রধান ব্যবহারকারী হল user 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 দুটি সংস্করণের এনক্রিপশন নীতি সমর্থন করে: সংস্করণ ১ এবং সংস্করণ ২। সংস্করণ ১ অবচিত, এবং অ্যান্ড্রয়েড ১১ এবং উচ্চতর সংস্করণের সাথে লঞ্চ হওয়া ডিভাইসগুলির জন্য CDD প্রয়োজনীয়তা শুধুমাত্র সংস্করণ ২ এর সাথে সামঞ্জস্যপূর্ণ। সংস্করণ ২ এনক্রিপশন নীতিগুলি ব্যবহারকারীর স্থান-সরবরাহকৃত কীগুলি থেকে প্রকৃত এনক্রিপশন কীগুলি পেতে HKDF-SHA512 ব্যবহার করে।

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

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

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

স্টোরেজ ক্লাস	বিবরণ	ডিরেক্টরি
এনক্রিপ্ট করা নেই	/data তে থাকা ডিরেক্টরিগুলি FBE দ্বারা সুরক্ষিত হতে পারে না বা প্রয়োজন হয় না। মেটাডেটা এনক্রিপশন ব্যবহার করে এমন ডিভাইসগুলিতে, এই ডিরেক্টরিগুলি প্রকৃতপক্ষে এনক্রিপ্ট করা হয় না বরং মেটাডেটা এনক্রিপশন কী দ্বারা সুরক্ষিত থাকে যা সিস্টেম 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}
ব্যবহারকারী 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 (অভ্যন্তরীণ) কী	/data/misc/vold/user_keys/de/${user_id}	সিস্টেম ডিই
ব্যবহারকারীর সিই (গ্রহণযোগ্য) কী	/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 দিয়ে এনক্রিপ্ট করা হয় তার নিজস্ব Keystore কী ব্যবহার করে যা TEE-এর বাইরে প্রকাশিত হয় না। এটি নিশ্চিত করে যে FBE কীগুলি আনলক করা যাবে না যদি না কোনও বিশ্বস্ত অপারেটিং সিস্টেম বুট করা হয়, যেমন Verified Boot দ্বারা প্রয়োগ করা হয়েছে। Keystore কী-তে রোলব্যাক রেজিস্ট্যান্সেরও অনুরোধ করা হয়, যা FBE কীগুলিকে এমন ডিভাইসগুলিতে নিরাপদে মুছে ফেলার অনুমতি দেয় যেখানে KeyMint রোলব্যাক রেজিস্ট্যান্স সমর্থন করে। যখন রোলব্যাক রেজিস্ট্যান্স অনুপলব্ধ থাকে তখন সর্বোত্তম প্রচেষ্টার ফলব্যাক হিসাবে, কী-এর পাশে সংরক্ষিত secdiscardable ফাইলে সংরক্ষিত 16384 র্যান্ডম বাইটের SHA-512 হ্যাশ Keystore কী-এর Tag::APPLICATION_ID হিসাবে ব্যবহৃত হয়। একটি FBE কী পুনরুদ্ধার করতে এই সমস্ত বাইট পুনরুদ্ধার করতে হবে।

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

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

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

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

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

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