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

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

অ্যান্ড্রয়েড ৯ মেটাডেটা এনক্রিপশনের জন্য সমর্থন চালু করেছে। মেটাডেটা এনক্রিপশনের মাধ্যমে, বুট করার সময় উপস্থিত একটি একক কী FBE দ্বারা এনক্রিপ্ট করা নয় এমন যেকোনো সামগ্রী এনক্রিপ্ট করে। এই কীটি KeyMint (পূর্বে Keymaster) দ্বারা সুরক্ষিত, যা পরবর্তীতে Verified Boot দ্বারা সুরক্ষিত।

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

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

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

পূর্বশর্ত

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

মেটাডেটা এনক্রিপশনের জন্য আপনার কার্নেলে dm-default-key মডিউল সক্রিয় থাকা প্রয়োজন। অ্যান্ড্রয়েড ১১ এবং উচ্চতর সংস্করণে, dm-default-key অ্যান্ড্রয়েড সাধারণ কার্নেল, সংস্করণ ৪.১৪ এবং উচ্চতর সংস্করণ দ্বারা সমর্থিত। 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-ভিত্তিক ত্বরণ সক্ষম করা উচিত।

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

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

যেহেতু মেটাডেটা এনক্রিপশন কী উপস্থিত না থাকা পর্যন্ত ইউজারডেটা পার্টিশনের কিছুই পড়া যাবে না, তাই পার্টিশন টেবিলে এই কীটি সুরক্ষিত করে এমন 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 নির্দেশ থাকা উচিত যা on late-fs স্তবকে /data নিজেই মাউন্ট করে। এই লাইনের আগে, 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 হল ডিফল্ট অ্যালগরিদম) সেট করে হার্ডওয়্যার-র‍্যাপড করা যেতে পারে।

যেহেতু অ্যান্ড্রয়েড ১১-এ কার্নেল ইন্টারফেসটি dm-default-key তে পরিবর্তিত হয়েছে, তাই আপনাকে নিশ্চিত করতে হবে যে আপনি device.mk এ PRODUCT_SHIPPING_API_LEVEL এর জন্য সঠিক মান সেট করেছেন। উদাহরণস্বরূপ, যদি আপনার ডিভাইসটি অ্যান্ড্রয়েড ১১ (API লেভেল ৩০) দিয়ে চালু হয়, তাহলে 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 সম্পূর্ণরূপে আগে থেকে চলছে এবং তাই এই অচলাবস্থা এড়ানো যায়।

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

অ্যান্ড্রয়েড ৯ থেকে, 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

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

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

লিগ্যাসি পদ্ধতি

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

ডিফল্টরূপে, 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। অ্যাডিয়্যান্টাম এনক্রিপশনের জন্য, 4096 ব্যবহার করুন।