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

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

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

ডাইরেক্ট বুট

ফাইল-ভিত্তিক এনক্রিপশন অ্যান্ড্রয়েড 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 বা 2.0 সহ কীমাস্টার সমর্থন । Keymaster 0.3 এর জন্য কোন সমর্থন নেই কারণ এটি প্রয়োজনীয় ক্ষমতা প্রদান করে না বা এনক্রিপশন কীগুলির জন্য পর্যাপ্ত সুরক্ষা নিশ্চিত করে না।
  • কীমাস্টার/ কীস্টোর এবং গেটকিপারকে অবশ্যই একটি বিশ্বস্ত এক্সিকিউশন এনভায়রনমেন্টে (TEE) প্রয়োগ করতে হবে যাতে DE কীগুলির সুরক্ষা প্রদান করা যায় যাতে একটি অননুমোদিত OS (ডিভাইসে ফ্ল্যাশ করা কাস্টম OS) কেবল 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 হয়।

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

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 সক্ষম করে; যাইহোক, প্রয়োজনে গ্রহণযোগ্য স্টোরেজের এনক্রিপশন বিন্যাস ওভাররাইড করা হতে পারে।

অভ্যন্তরীণ সংরক্ষণ ব্যবস্থা

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

  • contents_encryption_mode প্যারামিটার ফাইলের বিষয়বস্তু এনক্রিপ্ট করতে কোন ক্রিপ্টোগ্রাফিক অ্যালগরিদম ব্যবহার করা হয় তা নির্ধারণ করে। এটি হয় aes-256-xts xts বা adiantum হতে পারে। অ্যান্ড্রয়েড 11 থেকে এটি ডিফল্ট অ্যালগরিদম নির্দিষ্ট করতেও খালি রাখা যেতে পারে, যা aes-256-xts ।
  • filenames_encryption_mode প্যারামিটার সংজ্ঞায়িত করে কোন ক্রিপ্টোগ্রাফিক অ্যালগরিদম ফাইলের নাম এনক্রিপ্ট করতে ব্যবহৃত হয়। এটি হয় aes-256-cts cts, aes-256-heh -256-heh, adiantum , অথবা aes-256-hctr2 । নির্দিষ্ট করা না থাকলে, contents_encryption_mode aes-256-xts xts হলে এটি ডিফল্ট হয় aes-256-cts - adiantum , অথবা যদি contents_encryption_mode 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 এনক্রিপশন fstab বিকল্পটি নির্দিষ্ট করা স্বয়ংক্রিয়ভাবে fileencryption এবং মেটাডেটা এনক্রিপশন উভয়ই গ্রহণযোগ্য সঞ্চয়স্থানে সক্ষম করে। যাইহোক, আপনি 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 গ্রহণযোগ্য সঞ্চয়স্থানে মেটাডেটা এনক্রিপশন বিন্যাস নির্বাচন করুন। মেটাডেটা এনক্রিপশন ডকুমেন্টেশন দেখুন।

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

কার্নেল কীরিং-এর কী প্রজন্ম এবং ব্যবস্থাপনা vold দ্বারা পরিচালিত হয়। FBE-এর AOSP বাস্তবায়নের জন্য ডিভাইসটি Keymaster HAL সংস্করণ 1.0 বা তার পরে সমর্থন করতে হবে। Keymaster HAL-এর পূর্ববর্তী সংস্করণগুলির জন্য কোন সমর্থন নেই।

প্রথম বুটে, ব্যবহারকারী 0-এর কীগুলি বুট প্রক্রিয়ার প্রথম দিকে তৈরি এবং ইনস্টল করা হয়। init এর on-post-fs পর্যায় সম্পূর্ণ হওয়ার সময়, কী-মাস্টারকে অনুরোধগুলি পরিচালনা করার জন্য প্রস্তুত থাকতে হবে। পিক্সেল ডিভাইসে, এটি একটি স্ক্রিপ্ট ব্লকের মাধ্যমে পরিচালনা করা হয় যাতে /data মাউন্ট করার আগে কীমাস্টার শুরু হয়।

এনক্রিপশন নীতি

ফাইল-ভিত্তিক এনক্রিপশন ডিরেক্টরি স্তরে এনক্রিপশন নীতি প্রয়োগ করে। যখন একটি ডিভাইসের userdata পার্টিশন প্রথম তৈরি করা হয়, তখন প্রাথমিক কাঠামো এবং নীতিগুলি init স্ক্রিপ্ট দ্বারা প্রয়োগ করা হয়। এই স্ক্রিপ্টগুলি প্রথম ব্যবহারকারীর (ব্যবহারকারী 0 এর) CE এবং DE কীগুলি তৈরি করতে ট্রিগার করবে এবং সেই সাথে এই কীগুলির সাথে কোন ডিরেক্টরিগুলিকে এনক্রিপ্ট করা হবে তা নির্ধারণ করবে৷ যখন অতিরিক্ত ব্যবহারকারী এবং প্রোফাইল তৈরি করা হয়, প্রয়োজনীয় অতিরিক্ত কী তৈরি করা হয় এবং কীস্টোরে সংরক্ষণ করা হয়; তাদের শংসাপত্র এবং ডিভাইসের স্টোরেজ অবস্থান তৈরি করা হয় এবং এনক্রিপশন নীতি এই কীগুলিকে সেই ডিরেক্টরিগুলির সাথে লিঙ্ক করে।

অ্যান্ড্রয়েড 11 এবং উচ্চতর ক্ষেত্রে, এনক্রিপশন নীতিটি আর একটি কেন্দ্রীভূত অবস্থানে হার্ডকোড করা হয় না, বরং init স্ক্রিপ্টে mkdir কমান্ডের আর্গুমেন্ট দ্বারা সংজ্ঞায়িত করা হয়। সিস্টেম DE কী দিয়ে এনক্রিপ্ট করা ডিরেক্টরিগুলি encryption=Require প্রয়োজনীয়, যখন এনক্রিপ্ট না করা ডিরেক্টরিগুলি (অথবা যেগুলির সাব-ডিরেক্টরিগুলি প্রতি-ব্যবহারকারী কীগুলির সাথে এনক্রিপ্ট করা হয়) ব্যবহার করে encryption=None ।

Android 10-এ, এনক্রিপশন নীতিটি এই অবস্থানে হার্ডকোড করা হয়েছিল:

/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 সম্পর্কে আরও তথ্যের জন্য, আপস্ট্রিম কার্নেল ডকুমেন্টেশন দেখুন।

কী ডেরিভেশন

ফাইল-ভিত্তিক এনক্রিপশন কী, যা 512-বিট কী, টিইই-তে রাখা অন্য কী (একটি 256-বিট AES-GCM কী) দ্বারা এনক্রিপ্ট করা হয়। এই TEE কী ব্যবহার করতে, তিনটি প্রয়োজনীয়তা অবশ্যই পূরণ করতে হবে:

  • প্রমাণীকরণ টোকেন
  • প্রসারিত শংসাপত্র
  • "সেকডিসকার্ডেবল হ্যাশ"

প্রমাণীকরণ টোকেন হল একটি ক্রিপ্টোগ্রাফিকভাবে প্রমাণীকৃত টোকেন যা গেটকিপার দ্বারা উত্পন্ন হয় যখন একজন ব্যবহারকারী সফলভাবে লগ ইন করে। সঠিক প্রমাণীকরণ টোকেন সরবরাহ না করা পর্যন্ত TEE কী ব্যবহার করতে অস্বীকার করবে। ব্যবহারকারীর যদি কোনো শংসাপত্র না থাকে, তাহলে কোনো প্রমাণীকরণ টোকেন ব্যবহার করা হয় না বা প্রয়োজন হয় না।

scrypt অ্যালগরিদম দিয়ে সল্টিং এবং স্ট্রেচ করার পরে প্রসারিত শংসাপত্র হল ব্যবহারকারীর শংসাপত্র। scrypt পাস করার জন্য vold পাস করার আগে লক সেটিংস পরিষেবাতে শংসাপত্রটি আসলে একবার হ্যাশ করা হয়। KM_TAG_APPLICATION_ID এ প্রযোজ্য সমস্ত গ্যারান্টি সহ এটি ক্রিপ্টোগ্রাফিকভাবে KM_TAG_APPLICATION_ID এর কী-এর সাথে আবদ্ধ। ব্যবহারকারীর যদি কোনো শংসাপত্র না থাকে, তাহলে কোনো প্রসারিত শংসাপত্র ব্যবহার করা হয় না বা প্রয়োজন হয় না।

secdiscardable hash হল একটি এলোমেলো 16 KB ফাইলের একটি 512-বিট হ্যাশ যা কী পুনর্গঠনের জন্য ব্যবহৃত অন্যান্য তথ্যের সাথে সংরক্ষিত থাকে, যেমন বীজ। এই ফাইলটি সুরক্ষিতভাবে মুছে ফেলা হয় যখন কী মুছে ফেলা হয়, বা এটি একটি নতুন উপায়ে এনক্রিপ্ট করা হয়; এই অতিরিক্ত সুরক্ষা নিশ্চিত করে যে একজন আক্রমণকারীকে এই সুরক্ষিতভাবে মুছে ফেলা ফাইলটির প্রতিটি বিট পুনরুদ্ধার করতে হবে চাবিটি পুনরুদ্ধার করতে। KM_TAG_APPLICATION_ID এ প্রযোজ্য সমস্ত গ্যারান্টি সহ এটি ক্রিপ্টোগ্রাফিকভাবে KM_TAG_APPLICATION_ID এর কী-এর সাথে আবদ্ধ।

বেশিরভাগ ক্ষেত্রে, FBE কীগুলি কার্নেলে একটি অতিরিক্ত কী ডেরিভেশন ধাপের মধ্য দিয়ে যায় যাতে এনক্রিপশনের জন্য প্রকৃতপক্ষে ব্যবহৃত সাবকিগুলি তৈরি করা হয়, উদাহরণস্বরূপ প্রতি-ফাইল বা প্রতি-মোড কী। সংস্করণ 2 এনক্রিপশন নীতির জন্য, এর জন্য HKDF-SHA512 ব্যবহার করা হয়।