ভেরিফাইড বুটের জন্য ক্রিপ্টোগ্রাফিকভাবে সমস্ত এক্সিকিউটেবল কোড এবং ডেটা যাচাই করা প্রয়োজন যা ব্যবহার করার আগে বুট করা Android সংস্করণের অংশ। এর মধ্যে রয়েছে কার্নেল ( boot
পার্টিশন থেকে লোড করা), ডিভাইস ট্রি ( dtbo
পার্টিশন থেকে লোড করা), system
পার্টিশন, vendor
পার্টিশন ইত্যাদি।
ছোট পার্টিশন, যেমন boot
এবং dtbo
, যা শুধুমাত্র একবার পঠিত হয়, সাধারণত মেমরিতে সম্পূর্ণ বিষয়বস্তু লোড করে এবং তারপর তার হ্যাশ গণনা করে যাচাই করা হয়। এই গণনা করা হ্যাশ মান তারপর প্রত্যাশিত হ্যাশ মানের সাথে তুলনা করা হয়। মান না মিললে, Android লোড হবে না। আরো বিস্তারিত জানার জন্য, বুট ফ্লো দেখুন।
বৃহত্তর পার্টিশন যা মেমরিতে ফিট হবে না (যেমন, ফাইল সিস্টেম) একটি হ্যাশ ট্রি ব্যবহার করতে পারে যেখানে মেমরিতে ডেটা লোড হওয়ার সাথে সাথে যাচাইকরণ একটি ক্রমাগত প্রক্রিয়া। এই ক্ষেত্রে, হ্যাশ গাছের রুট হ্যাশ রান টাইমের সময় গণনা করা হয় এবং প্রত্যাশিত রুট হ্যাশ মানের বিপরীতে চেক করা হয়। বৃহত্তর পার্টিশন যাচাই করতে Android-এ dm-verity ড্রাইভার অন্তর্ভুক্ত রয়েছে। যদি কোনো সময়ে গণনা করা রুট হ্যাশ প্রত্যাশিত রুট হ্যাশ মানের সাথে মেলে না, ডেটা ব্যবহার করা হয় না এবং Android একটি ত্রুটির অবস্থায় প্রবেশ করে। আরো বিস্তারিত জানার জন্য, dm-verity দুর্নীতি দেখুন।
প্রত্যাশিত হ্যাশগুলি সাধারণত প্রতিটি যাচাইকৃত পার্টিশনের শেষ বা শুরুতে, একটি ডেডিকেটেড পার্টিশনে বা উভয়েই সংরক্ষণ করা হয়। গুরুত্বপূর্ণভাবে, এই হ্যাশগুলি বিশ্বাসের মূল দ্বারা স্বাক্ষরিত (প্রত্যক্ষ বা পরোক্ষভাবে)। উদাহরণ হিসেবে, AVB বাস্তবায়ন উভয় পদ্ধতিকে সমর্থন করে, বিস্তারিত জানার জন্য Android Verified Boot দেখুন।
রোলব্যাক সুরক্ষা
এমনকি একটি সম্পূর্ণ সুরক্ষিত আপডেট প্রক্রিয়ার সাথেও, একটি অবিরাম অ্যান্ড্রয়েড কার্নেল শোষণের পক্ষে অ্যান্ড্রয়েডের একটি পুরানো, আরও দুর্বল সংস্করণ ম্যানুয়ালি ইনস্টল করা, দুর্বল সংস্করণে রিবুট করা এবং তারপরে একটি ক্রমাগত শোষণ ইনস্টল করতে সেই অ্যান্ড্রয়েড সংস্করণটি ব্যবহার করা সম্ভব। সেখান থেকে আক্রমণকারী স্থায়ীভাবে ডিভাইসটির মালিক এবং আপডেট অক্ষম করা সহ যেকোন কিছু করতে পারে।
এই শ্রেণীর আক্রমণের বিরুদ্ধে সুরক্ষাকে বলা হয় রোলব্যাক সুরক্ষা । রোলব্যাক সুরক্ষা সাধারণত অ্যান্ড্রয়েডের সাম্প্রতিকতম সংস্করণ রেকর্ড করার জন্য ট্যাম্পার-এভিডেন্ট স্টোরেজ ব্যবহার করে প্রয়োগ করা হয় এবং যদি এটি রেকর্ড করা সংস্করণের চেয়ে কম হয় তবে Android বুট করতে অস্বীকার করে। সংস্করণগুলি সাধারণত প্রতি-পার্টিশন ভিত্তিতে ট্র্যাক করা হয়।
AVB কীভাবে রোলব্যাক সুরক্ষাগুলি পরিচালনা করে সে সম্পর্কে আরও বিশদ বিবরণের জন্য, AVB README দেখুন৷
যাচাইকরণ ত্রুটিগুলি পরিচালনা করা
যাচাইকরণ হয় বুট করার সময় ব্যর্থ হতে পারে (যেমন, যদি boot
পার্টিশনে গণনা করা হ্যাশ প্রত্যাশিত হ্যাশের সাথে মেলে না) অথবা রান টাইমে (যেমন, যদি dm-verity system
পার্টিশনে একটি যাচাইকরণ ত্রুটির সম্মুখীন হয়)। বুট করার সময় যাচাইকরণ ব্যর্থ হলে, ডিভাইসটি বুট করতে পারে না এবং শেষ ব্যবহারকারীকে ডিভাইসটি পুনরুদ্ধার করার জন্য ধাপগুলি অতিক্রম করতে হবে।
রান-টাইমে যাচাইকরণ ব্যর্থ হলে প্রবাহটি একটু বেশি জটিল। যদি ডিভাইসটি dm-verity ব্যবহার করে, তাহলে এটিকে restart
মোডে কনফিগার করা উচিত। restart
মোডে, যদি একটি যাচাইকরণ ত্রুটির সম্মুখীন হয়, ডিভাইসটি অবিলম্বে কারণ নির্দেশ করার জন্য একটি নির্দিষ্ট পতাকা সেট দিয়ে পুনরায় চালু করা হয়। বুট লোডারের এই পতাকাটি লক্ষ্য করা উচিত এবং I/O ত্রুটি ( eio
) মোড ব্যবহার করতে dm-verity পরিবর্তন করা উচিত এবং একটি নতুন আপডেট ইনস্টল না হওয়া পর্যন্ত এই মোডে থাকা উচিত।
eio
মোডে বুট করার সময়, ডিভাইসটি একটি ত্রুটি স্ক্রীন দেখায় যা ব্যবহারকারীকে জানায় যে দুর্নীতি সনাক্ত করা হয়েছে এবং ডিভাইসটি সঠিকভাবে কাজ করতে পারে না। ব্যবহারকারী এটি খারিজ না করা পর্যন্ত স্ক্রীন দেখায়। eio
মোডে dm-verity ড্রাইভার ডিভাইসটি পুনরায় চালু করবে না যদি একটি যাচাইকরণ ত্রুটির সম্মুখীন হয়, পরিবর্তে একটি EIO ত্রুটি ফেরত দেওয়া হয় এবং অ্যাপ্লিকেশনটিকে ত্রুটিটি মোকাবেলা করতে হবে।
উদ্দেশ্য হল সিস্টেম আপডেটারটি চলবে (তাই দুর্নীতির ত্রুটি ছাড়াই একটি নতুন OS ইনস্টল করা যেতে পারে) অথবা ব্যবহারকারী যতটা সম্ভব ডিভাইস থেকে তাদের ডেটা পেতে পারেন। নতুন ওএস ইনস্টল হয়ে গেলে, বুট লোডার নতুন ইনস্টল করা ওএসকে লক্ষ্য করে এবং restart
মোডে ফিরে যায়।