27 মার্চ, 2025 থেকে, আমরা AOSP তৈরি করতে এবং অবদান রাখতে aosp-main এর পরিবর্তে android-latest-release ব্যবহার করার পরামর্শ দিচ্ছি। আরও তথ্যের জন্য, AOSP-তে পরিবর্তনগুলি দেখুন।

এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

মেটাডেটা এনক্রিপশন

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

অ্যান্ড্রয়েড 9 মেটাডেটা এনক্রিপশনের জন্য সমর্থন চালু করেছে। মেটাডেটা এনক্রিপশনের সাহায্যে, বুট করার সময় উপস্থিত একটি একক কী FBE দ্বারা এনক্রিপ্ট করা নয় এমন বিষয়বস্তু এনক্রিপ্ট করে। এই কীটি KeyMint (পূর্বে Keymaster) দ্বারা সুরক্ষিত, যা ঘুরেফিরে যাচাইকৃত বুট দ্বারা সুরক্ষিত।

যখনই FBE সক্ষম করা হয় তখনই গ্রহণযোগ্য সঞ্চয়স্থানে মেটাডেটা এনক্রিপশন সক্রিয় থাকে। অভ্যন্তরীণ সঞ্চয়স্থানে মেটাডেটা এনক্রিপশনও সক্ষম করা যেতে পারে। Android 11 বা উচ্চতর সংস্করণের সাথে লঞ্চ করা ডিভাইসগুলিতে অভ্যন্তরীণ সঞ্চয়স্থানে মেটাডেটা এনক্রিপশন সক্রিয় থাকতে হবে।

অভ্যন্তরীণ স্টোরেজ বাস্তবায়ন

আপনি metadata ফাইল সিস্টেম সেট আপ করে, init ক্রম পরিবর্তন করে এবং ডিভাইসের fstab ফাইলে মেটাডেটা এনক্রিপশন সক্ষম করে নতুন ডিভাইসের অভ্যন্তরীণ সঞ্চয়স্থানে মেটাডেটা এনক্রিপশন সেট আপ করতে পারেন।

পূর্বশর্ত

মেটাডেটা এনক্রিপশন তখনই সেট আপ করা যেতে পারে যখন ডেটা পার্টিশনটি প্রথম ফরম্যাট করা হয়। ফলস্বরূপ, এই বৈশিষ্ট্য শুধুমাত্র নতুন ডিভাইসের জন্য; এটি এমন কিছু নয় যা একটি OTA পরিবর্তন করা উচিত।

মেটাডেটা এনক্রিপশনের জন্য আপনার কার্নেলে dm-default-key মডিউল সক্রিয় করা প্রয়োজন। Android 11 এবং উচ্চতর সংস্করণে, dm-default-key Android সাধারণ কার্নেল, সংস্করণ 4.14 এবং উচ্চতর দ্বারা সমর্থিত। dm-default-key এর এই সংস্করণটি blk-crypto নামে একটি হার্ডওয়্যার এবং বিক্রেতা-স্বাধীন এনক্রিপশন ফ্রেমওয়ার্ক ব্যবহার করে।

dm-default-key সক্ষম করতে, ব্যবহার করুন:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
CONFIG_DM_DEFAULT_KEY=y

dm-default-key ইনলাইন এনক্রিপশন হার্ডওয়্যার ব্যবহার করে (হার্ডওয়্যার যা ডেটা এনক্রিপ্ট/ডিক্রিপ্ট করে যখন এটি স্টোরেজ ডিভাইসে/থেকে যাওয়ার পথে থাকে) উপলব্ধ। আপনি যদি ইনলাইন এনক্রিপশন হার্ডওয়্যার ব্যবহার না করেন, তাহলে কার্নেলের ক্রিপ্টোগ্রাফি API-এ একটি ফলব্যাক সক্ষম করার জন্যও এটি প্রয়োজনীয়:

CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y

ইনলাইন এনক্রিপশন হার্ডওয়্যার ব্যবহার না করার সময় আপনাকে FBE ডকুমেন্টেশনে প্রস্তাবিত যেকোনো উপলব্ধ CPU-ভিত্তিক ত্বরণ সক্ষম করতে হবে।

অ্যান্ড্রয়েড 10 এবং তার চেয়ে কম সময়ে, dm-default-key Android সাধারণ কার্নেল দ্বারা সমর্থিত ছিল না। তাই dm-default-key প্রয়োগ করা বিক্রেতাদের উপর নির্ভর করে।

মেটাডেটা ফাইল সিস্টেম সেট আপ করুন

যেহেতু মেটাডেটা এনক্রিপশন কী উপস্থিত না হওয়া পর্যন্ত userdata পার্টিশনের কিছুই পড়া যায় না, পার্টিশন টেবিলটিকে মেটাডেটা পার্টিশন নামে একটি পৃথক পার্টিশন আলাদা করে রাখতে হবে যা এই কীকে সুরক্ষিত রাখে সেই KeyMint ব্লবগুলি সংরক্ষণ করার জন্য। মেটাডেটা পার্টিশন 16MB হওয়া উচিত।

fstab.hardware মেটাডেটা ফাইলসিস্টেমের জন্য একটি এন্ট্রি অন্তর্ভুক্ত করা আবশ্যক যেটি /metadata এ মাউন্ট করা পার্টিশনে থাকে, যাতে বুট করার সময় ফর্ম্যাট করা হয়েছে তা নিশ্চিত করার জন্য formattable ফ্ল্যাগ সহ। f2fs ফাইল সিস্টেম ছোট পার্টিশনে কাজ করে না; আমরা পরিবর্তে ext4 ব্যবহার করার পরামর্শ দিই। যেমন:

/dev/block/bootdevice/by-name/metadata              /metadata          ext4        noatime,nosuid,nodev,discard                          wait,check,formattable

/metadata মাউন্ট পয়েন্ট বিদ্যমান আছে তা নিশ্চিত করতে, BoardConfig-common.mk এ নিম্নলিখিত লাইন যোগ করুন:

BOARD_USES_METADATA_PARTITION := true

init ক্রম পরিবর্তন

যখন মেটাডেটা এনক্রিপশন ব্যবহার করা হয়, তখন /data মাউন্ট করার আগে vold অবশ্যই চলতে হবে। এটি যথেষ্ট তাড়াতাড়ি শুরু হয়েছে তা নিশ্চিত করতে, init.hardware.rc এ নিম্নলিখিত স্তবকটি যোগ করুন:

# We need vold early for metadata encryption
on early-fs
    start vold

init /data মাউন্ট করার চেষ্টা করার আগে KeyMint অবশ্যই চলমান এবং প্রস্তুত থাকতে হবে।

init.hardware.rc ইতিমধ্যেই একটি mount_all নির্দেশ থাকা উচিত যা /data নিজেই on late-fs স্তবকে মাউন্ট করে। এই লাইনের আগে, wait_for_keymaster পরিষেবাটি চালানোর নির্দেশনা যোগ করুন:

on late-fs
   … 
    # Wait for Keymaster
    exec_start wait_for_keymaster

    # Mount RW partitions which need run fsck
    mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late

মেটাডেটা এনক্রিপশন চালু করুন

অবশেষে userdata জন্য fstab এন্ট্রির fs_mgr_flags কলামে keydirectory=/metadata/vold/metadata_encryption যোগ করুন। উদাহরণস্বরূপ, একটি সম্পূর্ণ fstab লাইন এর মতো দেখতে পারে:

/dev/block/bootdevice/by-name/userdata              /data              f2fs        noatime,nosuid,nodev,discard,inlinecrypt latemount,wait,check,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized,keydirectory=/metadata/vold/metadata_encryption,quota,formattable

ডিফল্টরূপে, অভ্যন্তরীণ সঞ্চয়স্থানে মেটাডেটা এনক্রিপশন অ্যালগরিদম হল AES-256-XTS। fs_mgr_flags কলামে, metadata_encryption বিকল্প সেট করে এটি ওভাররাইড করা যেতে পারে:

যে ডিভাইসগুলিতে AES ত্বরণের অভাব রয়েছে, সেখানে metadata_encryption=adiantum সেট করে Adiantum এনক্রিপশন সক্ষম করা যেতে পারে।
যে ডিভাইসগুলিতে হার্ডওয়্যার-র্যাপড কী সমর্থন করে, মেটাডেটা এনক্রিপশন কীটিকে metadata_encryption=aes-256-xts:wrappedkey_v0 (অথবা সমতুল্যভাবে metadata_encryption=:wrappedkey_v0 , aes-256-xts এর মতো) সেট করে হার্ডওয়্যার-র্যাপ করা যেতে পারে।

কারণ Android 11-এ dm-default-key তে কার্নেল ইন্টারফেস পরিবর্তিত হয়েছে, আপনাকে নিশ্চিত করতে হবে যে আপনি device.mk এ PRODUCT_SHIPPING_API_LEVEL জন্য সঠিক মান সেট করেছেন। উদাহরণস্বরূপ, যদি আপনার ডিভাইস Android 11 (API লেভেল 30) দিয়ে লঞ্চ হয়, তাহলে device.mk মধ্যে থাকবে:

PRODUCT_SHIPPING_API_LEVEL := 30

শিপিং API স্তর নির্বিশেষে আপনি নতুন dm-default-key API ব্যবহার করতে বাধ্য করতে নিম্নলিখিত সিস্টেম সম্পত্তি সেট করতে পারেন:

PRODUCT_PROPERTY_OVERRIDES += \
    ro.crypto.dm_default_key.options_format.version=2

বৈধতা

মেটাডেটা এনক্রিপশন সক্ষম হয়েছে এবং সঠিকভাবে কাজ করছে তা যাচাই করতে, নীচে বর্ণিত পরীক্ষাগুলি চালান৷ নীচে বর্ণিত সাধারণ সমস্যাগুলিও মনে রাখবেন।

টেস্ট

অভ্যন্তরীণ সঞ্চয়স্থানে মেটাডেটা এনক্রিপশন সক্ষম হয়েছে তা যাচাই করতে নিম্নলিখিত কমান্ডটি চালানোর মাধ্যমে শুরু করুন:

adb root
adb shell dmctl table userdata

আউটপুট অনুরূপ হওয়া উচিত:

Targets in the device-mapper table for userdata:
0-4194304: default-key, aes-xts-plain64 - 0 252:2 0 3 allow_discards sector_size:4096 iv_large_sectors

আপনি যদি ডিভাইসের fstab এ metadata_encryption বিকল্পটি সেট করে ডিফল্ট এনক্রিপশন সেটিংস ওভাররড করেন, তাহলে আউটপুট উপরের থেকে কিছুটা আলাদা হয়। উদাহরণস্বরূপ, যদি আপনি Adiantum এনক্রিপশন সক্ষম করেন, তাহলে তৃতীয় ক্ষেত্রটি aes-xts-plain64 এর পরিবর্তে xchacha12,aes-adiantum-plain64 ।

পরবর্তী, মেটাডেটা এনক্রিপশন এবং FBE এর সঠিকতা যাচাই করতে vts_kernel_encryption_test চালান:

atest vts_kernel_encryption_test

বা:

vts-tradefed run vts -m vts_kernel_encryption_test

সাধারণ সমস্যা

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

mount_all চালানোর সময় KeyMint সম্পূর্ণরূপে চালু না হলে, init থেকে নির্দিষ্ট বৈশিষ্ট্যগুলি না পড়া পর্যন্ত এটি vold এ সাড়া দেয় না, যার ফলে বর্ণনা করা অচলাবস্থা দেখা দেয়। নির্ধারিত হিসাবে প্রাসঙ্গিক mount_all আহ্বানের উপরে exec_start wait_for_keymaster স্থাপন করা নিশ্চিত করে যে KeyMint সম্পূর্ণরূপে আগে থেকে চলছে এবং তাই এই অচলাবস্থা এড়ায়।

গ্রহণযোগ্য স্টোরেজ কনফিগারেশন

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

AOSP-এ, গ্রহণযোগ্য সঞ্চয়স্থানে মেটাডেটা এনক্রিপশনের দুটি প্রয়োগ রয়েছে: একটি dm-crypt এর উপর ভিত্তি করে অবচয়িত, এবং dm-default-key উপর ভিত্তি করে একটি নতুন। আপনার ডিভাইসের জন্য সঠিক বাস্তবায়ন নির্বাচন করা হয়েছে তা নিশ্চিত করতে, আপনি device.mk এ PRODUCT_SHIPPING_API_LEVEL এর জন্য সঠিক মান সেট করেছেন তা নিশ্চিত করুন। উদাহরণস্বরূপ, যদি আপনার ডিভাইস Android 11 (API লেভেল 30) দিয়ে লঞ্চ হয়, তাহলে device.mk মধ্যে থাকবে:

PRODUCT_SHIPPING_API_LEVEL := 30

শিপিং API স্তর নির্বিশেষে আপনি নতুন ভলিউম মেটাডেটা এনক্রিপশন পদ্ধতি (এবং নতুন ডিফল্ট FBE নীতি সংস্করণ) ব্যবহার করতে বাধ্য করতে নিম্নলিখিত সিস্টেম বৈশিষ্ট্যগুলিও সেট করতে পারেন:

PRODUCT_PROPERTY_OVERRIDES += \
    ro.crypto.volume.metadata.method=dm-default-key \
    ro.crypto.dm_default_key.options_format.version=2 \
    ro.crypto.volume.options=::v2

বর্তমান পদ্ধতি

অ্যান্ড্রয়েড 11 বা উচ্চতর সংস্করণের সাথে চালু হওয়া ডিভাইসগুলিতে, গ্রহণযোগ্য স্টোরেজের মেটাডেটা এনক্রিপশন অভ্যন্তরীণ স্টোরেজের মতোই dm-default-key কার্নেল মডিউল ব্যবহার করে। কার্নেল কনফিগারেশন বিকল্পগুলি সক্রিয় করার জন্য উপরের পূর্বশর্তগুলি দেখুন। মনে রাখবেন যে ডিভাইসের অভ্যন্তরীণ সঞ্চয়স্থানে কাজ করে এমন ইনলাইন এনক্রিপশন হার্ডওয়্যার গ্রহণযোগ্য সঞ্চয়স্থানে অনুপলব্ধ হতে পারে, এবং এইভাবে CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y প্রয়োজন হতে পারে৷

ডিফল্টরূপে, dm-default-key ভলিউম মেটাডেটা এনক্রিপশন পদ্ধতি 4096-বাইট ক্রিপ্টো সেক্টরের সাথে AES-256-XTS এনক্রিপশন অ্যালগরিদম ব্যবহার করে। ro.crypto.volume.metadata.encryption সিস্টেম বৈশিষ্ট্য সেট করে অ্যালগরিদম ওভাররাইড করা যেতে পারে। এই সম্পত্তির মান উপরে বর্ণিত metadata_encryption fstab বিকল্পের মত একই সিনট্যাক্স আছে। উদাহরণস্বরূপ, যে ডিভাইসগুলিতে AES ত্বরণের অভাব রয়েছে, সেখানে ro.crypto.volume.metadata.encryption=adiantum সেট করে Adiantum এনক্রিপশন সক্ষম করা যেতে পারে।

উত্তরাধিকার পদ্ধতি

অ্যান্ড্রয়েড 10 এবং তার নিচের ডিভাইসে লঞ্চ করা ডিভাইসগুলিতে, গ্রহণযোগ্য স্টোরেজের মেটাডেটা এনক্রিপশন dm-default-key পরিবর্তে dm-crypt কার্নেল মডিউল ব্যবহার করে:

CONFIG_DM_CRYPT=y

dm-default-key পদ্ধতির বিপরীতে, dm-crypt পদ্ধতিতে ফাইলের বিষয়বস্তু দুবার এনক্রিপ্ট করা হয়: একবার FBE কী দিয়ে এবং একবার মেটাডেটা এনক্রিপশন কী দিয়ে। এই ডাবল এনক্রিপশন কর্মক্ষমতা হ্রাস করে এবং মেটাডেটা এনক্রিপশনের নিরাপত্তা লক্ষ্য অর্জনের জন্য প্রয়োজন হয় না, যেহেতু অ্যান্ড্রয়েড নিশ্চিত করে যে FBE কীগুলি অন্তত মেটাডেটা এনক্রিপশন কীগুলির মতো আপস করা কঠিন। বিক্রেতারা ডবল এনক্রিপশন এড়াতে কার্নেল কাস্টমাইজেশন করতে পারে, বিশেষ করে allow_encrypt_override বিকল্পটি প্রয়োগ করে যা অ্যান্ড্রয়েড dm-crypt এ পাস করে যখন সিস্টেম প্রপার্টি ro.crypto.allow_encrypt_override true সেট করা থাকে। এই কাস্টমাইজেশনগুলি Android সাধারণ কার্নেল দ্বারা সমর্থিত নয়৷

ডিফল্টরূপে, dm-crypt ভলিউম মেটাডেটা এনক্রিপশন পদ্ধতি ESSIV এবং 512-বাইট ক্রিপ্টো সেক্টরের সাথে AES-128-CBC এনক্রিপশন অ্যালগরিদম ব্যবহার করে। নিম্নলিখিত সিস্টেম বৈশিষ্ট্যগুলি (যা FDE এর জন্যও ব্যবহৃত হয়) সেট করে এটি ওভাররাইড করা যেতে পারে:

ro.crypto.fde_algorithm মেটাডেটা এনক্রিপশন অ্যালগরিদম নির্বাচন করে। পছন্দ হল aes-128-cbc এবং adiantum . ডিভাইসটিতে AES ত্বরণের অভাব থাকলেই Adiantum ব্যবহার করা যেতে পারে।
ro.crypto.fde_sector_size ক্রিপ্টো সেক্টরের আকার নির্বাচন করে। পছন্দগুলি হল 512, 1024, 2048 এবং 4096৷ Adiantum এনক্রিপশনের জন্য, 4096 ব্যবহার করুন৷