অন-ডিভাইস সাইনিং আর্কিটেকচার

অ্যান্ড্রয়েড 12 অনুযায়ী, অ্যান্ড্রয়েড রানটাইম (এআরটি) মডিউল একটি মেইনলাইন মডিউল। মডিউল আপডেট করার জন্য বুটক্লাসপাথ জার এবং সিস্টেম সার্ভারের আগাম-অব-টাইম (AOT) সংকলন শিল্পকর্ম পুনর্নির্মাণের প্রয়োজন হতে পারে। যেহেতু এই আর্টিফ্যাক্টগুলি নিরাপত্তা সংবেদনশীল, তাই Android 12 এই নিদর্শনগুলিকে টেম্পার করা থেকে রোধ করার জন্য অন-ডিভাইস সাইনিং নামে একটি বৈশিষ্ট্য নিয়োগ করে। এই পৃষ্ঠাটি অন-ডিভাইস সাইনিং আর্কিটেকচার এবং অন্যান্য Android নিরাপত্তা বৈশিষ্ট্যের সাথে এর মিথস্ক্রিয়া কভার করে।

উচ্চ-স্তরের নকশা

অন-ডিভাইস সাইনিংয়ের দুটি মূল উপাদান রয়েছে:

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

  • odsign হল একটি বাইনারি যা অ্যান্ড্রয়েড প্ল্যাটফর্মের অংশ। /data পার্টিশন মাউন্ট করার পরেই এটি প্রাথমিক বুটের সময় চলে। এর প্রধান দায়িত্ব হল কোনো শিল্পকর্ম তৈরি বা আপডেট করা দরকার কিনা তা পরীক্ষা করার জন্য odrefresh আহ্বান করা। odrefresh উৎপন্ন যে কোনো নতুন বা আপডেট করা শিল্পকর্মের জন্য, odsign একটি হ্যাশ ফাংশন গণনা করে। এই ধরনের হ্যাশ গণনার ফলাফলকে ফাইল ডাইজেস্ট বলা হয়। যেকোন আর্টিফ্যাক্টের জন্য যা ইতিমধ্যেই বিদ্যমান, odsign যাচাই করে যে বিদ্যমান আর্টিফ্যাক্টগুলির হজমগুলি odsign পূর্বে গণনা করা ডাইজেস্টগুলির সাথে মেলে৷ এটি নিশ্চিত করে যে নিদর্শনগুলির সাথে কোনও হেরফের করা হয়নি৷

ত্রুটির পরিস্থিতিতে, যেমন যখন একটি ফাইলের জন্য ডাইজেস্ট মেলে না, odrefresh এবং odsign /data এ বিদ্যমান সমস্ত আর্টিফ্যাক্ট ফেলে দেয় এবং সেগুলি পুনরায় তৈরি করার চেষ্টা করে। যদি এটি ব্যর্থ হয়, সিস্টেমটি JIT মোডে ফিরে আসে।

odrefresh এবং odsign dm-verity দ্বারা সুরক্ষিত এবং Android এর যাচাইকৃত বুট চেইনের একটি অংশ।

fs-verity সহ ফাইল ডাইজেস্টের গণনা

fs-verity হল Linux কার্নেলের একটি বৈশিষ্ট্য যা Merkle tree ভিত্তিক ফাইল ডেটা যাচাই করে। একটি ফাইলে fs-verity সক্ষম করার ফলে ফাইল সিস্টেম SHA-256 হ্যাশ ব্যবহার করে ফাইলের ডেটার উপর একটি Merkle ট্রি তৈরি করে, ফাইলের পাশে একটি লুকানো অবস্থানে সংরক্ষণ করে এবং ফাইলটিকে শুধুমাত্র পঠনযোগ্য হিসাবে চিহ্নিত করে। fs-verity স্বয়ংক্রিয়ভাবে মার্কেল ট্রির সাথে ফাইলের ডেটা পড়ার সাথে সাথে চাহিদা অনুযায়ী যাচাই করে। fs-verity মারকেল ট্রির রুট হ্যাশকে fs-verity ফাইল ডাইজেস্ট নামে একটি মান হিসাবে উপলব্ধ করে এবং fs-verity নিশ্চিত করে যে ফাইল থেকে পড়া যেকোনো ডেটা এই ফাইল ডাইজেস্টের সাথে সামঞ্জস্যপূর্ণ।

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

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

ফাইলের স্টোরেজ হজম হয়

odsign আর্টিফ্যাক্টের ফাইল ডাইজেস্টকে odsign.info নামে একটি পৃথক ফাইলে সংরক্ষণ করে। odsign.info সাথে টেম্পার না করা হয়েছে তা নিশ্চিত করার জন্য, odsign.info একটি সাইনিং কী দিয়ে সাইন করা হয়েছে যাতে গুরুত্বপূর্ণ নিরাপত্তা বৈশিষ্ট্য রয়েছে। বিশেষ করে, কী তৈরি করা যেতে পারে এবং শুধুমাত্র প্রাথমিক বুটের সময় ব্যবহার করা যেতে পারে, যেখানে শুধুমাত্র বিশ্বস্ত কোড চলছে; বিশদ বিবরণের জন্য বিশ্বস্ত স্বাক্ষর কীগুলি দেখুন৷

ফাইল ডাইজেস্টের যাচাইকরণ

প্রতিটি বুটে, যদি odrefresh নির্ধারণ করে যে বিদ্যমান আর্টিফ্যাক্টগুলি আপ টু ডেট, odsign নিশ্চিত করে যে ফাইলগুলি তৈরি হওয়ার পর থেকে সেগুলিকে টেম্পার করা হয়নি৷ odsign ফাইল ডাইজেস্ট যাচাই করে এটি করে। প্রথমত, এটি odsign.info এর স্বাক্ষর যাচাই করে। যদি স্বাক্ষরটি বৈধ হয়, তাহলে odsign যাচাই করে যে প্রতিটি ফাইলের ডাইজেস্ট odsign.info তে সংশ্লিষ্ট ডাইজেস্টের সাথে মেলে।

বিশ্বস্ত সাইনিং কী

অ্যান্ড্রয়েড 12 বুট স্টেজ কী নামে একটি নতুন কীস্টোর বৈশিষ্ট্য প্রবর্তন করেছে যা নিম্নলিখিত সুরক্ষা উদ্বেগের সমাধান করে:

  • কোন আক্রমণকারীকে আমাদের সাইনিং কী ব্যবহার করে odsign.info এর নিজস্ব সংস্করণে স্বাক্ষর করতে বাধা দেয়?
  • কোন আক্রমণকারীকে তাদের নিজস্ব সাইনিং কী তৈরি করতে এবং odsign.info এর নিজস্ব সংস্করণে স্বাক্ষর করতে ব্যবহার করতে বাধা দেয়?

বুট স্টেজ কীগুলি অ্যান্ড্রয়েডের বুট চক্রকে স্তরগুলিতে বিভক্ত করে এবং ক্রিপ্টোগ্রাফিকভাবে একটি কী তৈরি এবং ব্যবহারকে একটি নির্দিষ্ট স্তরে বেঁধে দেয়। odsign প্রাথমিক স্তরে তার সাইনিং কী তৈরি করে, যখন শুধুমাত্র বিশ্বস্ত কোড চলছে, dm-verity মাধ্যমে সুরক্ষিত।

বুট পর্যায়ের স্তরগুলি 0 থেকে ম্যাজিক নম্বর 1000000000 পর্যন্ত সংখ্যাযুক্ত। Android এর বুট প্রক্রিয়া চলাকালীন, আপনি init.rc থেকে একটি সিস্টেম বৈশিষ্ট্য সেট করে বুট স্তর বাড়াতে পারেন। উদাহরণস্বরূপ, নিম্নলিখিত কোডটি বুট স্তরকে 10 এ সেট করে:

setprop keystore.boot_level 10

কীস্টোরের ক্লায়েন্টরা একটি নির্দিষ্ট বুট স্তরের সাথে আবদ্ধ কীগুলি তৈরি করতে পারে। উদাহরণস্বরূপ, আপনি যদি বুট স্তর 10-এর জন্য একটি কী তৈরি করেন, তাহলে ডিভাইসটি বুট স্তর 10-এ থাকাকালীনই সেই কীটি ব্যবহার করা যেতে পারে।

odsign বুট স্তর 30 ব্যবহার করে, এবং এটি যে সাইনিং কী তৈরি করে তা সেই বুট স্তরের সাথে সংযুক্ত থাকে। আর্টিফ্যাক্ট সাইন ইন করার জন্য একটি কী ব্যবহার করার আগে, odsign যাচাই করে যে কীটি বুট লেভেল 30 এর সাথে আবদ্ধ।

এটি এই বিভাগে আগে বর্ণিত দুটি আক্রমণ প্রতিরোধ করে:

  • আক্রমণকারীরা জেনারেট করা কী ব্যবহার করতে পারে না, কারণ যখন একজন আক্রমণকারীর দূষিত কোড চালানোর সুযোগ থাকে, তখন বুট লেভেল 30-এর বেশি বেড়ে যায় এবং কীস্টোর কী ব্যবহার করে এমন ক্রিয়াকলাপ প্রত্যাখ্যান করে।
  • আক্রমণকারীরা একটি নতুন কী তৈরি করতে পারে না, কারণ যখন একজন আক্রমণকারীর দূষিত কোড চালানোর সুযোগ থাকে, তখন বুট স্তর 30-এর বেশি বেড়ে যায় এবং কীস্টোর সেই বুট স্তরের সাথে একটি নতুন কী তৈরি করতে অস্বীকার করে৷ যদি একজন আক্রমণকারী একটি নতুন কী তৈরি করে যা বুট স্তর 30 এর সাথে আবদ্ধ না থাকে, odsign এটি প্রত্যাখ্যান করে।

কীস্টোর নিশ্চিত করে যে বুট স্তরটি সঠিকভাবে প্রয়োগ করা হয়েছে। নিম্নলিখিত বিভাগগুলি বিভিন্ন কীমাস্টার সংস্করণের জন্য এটি কীভাবে করা হয় সে সম্পর্কে আরও বিশদে যায়।

কীমাস্টার 4.0 বাস্তবায়ন

Keymaster-এর বিভিন্ন সংস্করণ বুট স্টেজ কীগুলির বাস্তবায়ন ভিন্নভাবে পরিচালনা করে। একটি Keymaster 4.0 TEE/Strongbox সহ ডিভাইসগুলিতে, Keymaster নিম্নরূপ বাস্তবায়ন পরিচালনা করে:

  1. প্রথম বুট করার সময়, কীস্টোর 1 এ সেট করা MAX_USES_PER_BOOT ট্যাগ সহ একটি সিমেট্রিক কী K0 তৈরি করে। এর মানে হল প্রতি বুটে কী শুধুমাত্র একবার ব্যবহার করা যাবে।
  2. বুট চলাকালীন, বুট লেভেল বাড়ানো হলে, HKDF ফাংশন ব্যবহার করে K0 থেকে সেই বুট লেভেলের জন্য একটি নতুন কী তৈরি করা যেতে পারে: Ki+i=HKDF(Ki, "some_fixed_string") । উদাহরণস্বরূপ, আপনি যদি বুট লেভেল 0 থেকে বুট লেভেল 10 এ যান, তাহলে K0 থেকে K10 বের করার জন্য HKDF 10 বার আহ্বান করা হয়।

  3. বুট স্তর পরিবর্তন হলে, পূর্ববর্তী বুট স্তরের কী মেমরি থেকে মুছে ফেলা হয় এবং পূর্ববর্তী বুট স্তরের সাথে যুক্ত কীগুলি আর উপলব্ধ থাকে না।

    কী K0 হল একটি MAX_USES_PER_BOOT=1 কী। এর মানে হল যে বুট করার পরে সেই কীটি ব্যবহার করাও অসম্ভব, কারণ অন্তত একটি বুট স্তরের রূপান্তর (চূড়ান্ত বুট স্তরে) সর্বদা ঘটে।

যখন একটি কীস্টোর ক্লায়েন্ট যেমন odsign বুট স্তর i তে একটি কী তৈরি করার অনুরোধ করে, তখন এর ব্লব কী Ki দিয়ে এনক্রিপ্ট করা হয়। যেহেতু বুট স্তর i এর পরে Ki উপলব্ধ নেই, এই কীটি পরবর্তী বুট পর্যায়ে তৈরি বা ডিক্রিপ্ট করা যাবে না।

Keymaster 4.1 এবং KeyMint 1.0 বাস্তবায়ন

Keymaster 4.1 এবং KeyMint 1.0 বাস্তবায়ন মূলত Keymaster 4.0 বাস্তবায়নের মতই। প্রধান পার্থক্য হল K0 একটি MAX_USES_PER_BOOT কী নয়, কিন্তু একটি EARLY_BOOT_ONLY কী, যা Keymaster 4.1-এ চালু করা হয়েছিল। একটি EARLY_BOOT_ONLY কী শুধুমাত্র বুটের প্রাথমিক পর্যায়ে ব্যবহার করা যেতে পারে, যখন কোনো অবিশ্বস্ত কোড চলছে না। এটি একটি অতিরিক্ত স্তরের সুরক্ষা প্রদান করে: Keymaster 4.0 বাস্তবায়নে, একটি আক্রমণকারী যেটি ফাইল সিস্টেমের সাথে আপোস করে এবং SELinux কিস্টোর ডাটাবেস পরিবর্তন করতে পারে তার নিজস্ব MAX_USES_PER_BOOT=1 কী তৈরি করে আর্টিফ্যাক্টে স্বাক্ষর করার জন্য। Keymaster 4.1 এবং KeyMint 1.0 বাস্তবায়নের সাথে এই ধরনের আক্রমণ অসম্ভব, কারণ EARLY_BOOT_ONLY কীগুলি শুধুমাত্র প্রাথমিক বুটের সময় তৈরি করা যেতে পারে।

বিশ্বস্ত সাইনিং কীগুলির সর্বজনীন উপাদান

odsign কীস্টোর থেকে সাইনিং কী-এর সর্বজনীন কী উপাদান পুনরুদ্ধার করে। যাইহোক, কীস্টোর TEE/SE থেকে সেই পাবলিক কীটি পুনরুদ্ধার করে না যা সংশ্লিষ্ট ব্যক্তিগত কী ধারণ করে। পরিবর্তে, এটি তার নিজস্ব অন-ডিস্ক ডাটাবেস থেকে সর্বজনীন কী পুনরুদ্ধার করে। এর মানে হল যে একজন আক্রমণকারী যে ফাইল সিস্টেমের সাথে আপস করে সে কীস্টোর ডাটাবেসকে একটি পাবলিক কী ধারণ করতে পারে যা তাদের নিয়ন্ত্রণে থাকা একটি পাবলিক/প্রাইভেট কী-পেয়ারের অংশ।

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

,

অ্যান্ড্রয়েড 12 অনুযায়ী, অ্যান্ড্রয়েড রানটাইম (এআরটি) মডিউল একটি মেইনলাইন মডিউল। মডিউল আপডেট করার জন্য বুটক্লাসপাথ জার এবং সিস্টেম সার্ভারের আগাম-অব-টাইম (AOT) সংকলন শিল্পকর্ম পুনর্নির্মাণের প্রয়োজন হতে পারে। যেহেতু এই আর্টিফ্যাক্টগুলি নিরাপত্তা সংবেদনশীল, তাই Android 12 এই নিদর্শনগুলিকে টেম্পার করা থেকে রোধ করার জন্য অন-ডিভাইস সাইনিং নামে একটি বৈশিষ্ট্য নিয়োগ করে। এই পৃষ্ঠাটি অন-ডিভাইস সাইনিং আর্কিটেকচার এবং অন্যান্য Android নিরাপত্তা বৈশিষ্ট্যের সাথে এর মিথস্ক্রিয়া কভার করে।

উচ্চ-স্তরের নকশা

অন-ডিভাইস সাইনিংয়ের দুটি মূল উপাদান রয়েছে:

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

  • odsign হল একটি বাইনারি যা অ্যান্ড্রয়েড প্ল্যাটফর্মের অংশ। /data পার্টিশন মাউন্ট করার পরেই এটি প্রাথমিক বুটের সময় চলে। এর প্রধান দায়িত্ব হল কোনো শিল্পকর্ম তৈরি বা আপডেট করা দরকার কিনা তা পরীক্ষা করার জন্য odrefresh আহ্বান করা। odrefresh উৎপন্ন যে কোনো নতুন বা আপডেট করা শিল্পকর্মের জন্য, odsign একটি হ্যাশ ফাংশন গণনা করে। এই ধরনের হ্যাশ গণনার ফলাফলকে ফাইল ডাইজেস্ট বলা হয়। যেকোন আর্টিফ্যাক্টের জন্য যা ইতিমধ্যেই বিদ্যমান, odsign যাচাই করে যে বিদ্যমান আর্টিফ্যাক্টগুলির হজমগুলি odsign পূর্বে গণনা করা ডাইজেস্টগুলির সাথে মেলে৷ এটি নিশ্চিত করে যে নিদর্শনগুলির সাথে কোনও হেরফের করা হয়নি৷

ত্রুটির পরিস্থিতিতে, যেমন যখন একটি ফাইলের জন্য ডাইজেস্ট মেলে না, odrefresh এবং odsign /data এ বিদ্যমান সমস্ত আর্টিফ্যাক্ট ফেলে দেয় এবং সেগুলি পুনরায় তৈরি করার চেষ্টা করে। যদি এটি ব্যর্থ হয়, সিস্টেমটি JIT মোডে ফিরে আসে।

odrefresh এবং odsign dm-verity দ্বারা সুরক্ষিত এবং Android এর যাচাইকৃত বুট চেইনের একটি অংশ।

fs-verity সহ ফাইল ডাইজেস্টের গণনা

fs-verity হল Linux কার্নেলের একটি বৈশিষ্ট্য যা Merkle tree ভিত্তিক ফাইল ডেটা যাচাই করে। একটি ফাইলে fs-verity সক্ষম করার ফলে ফাইল সিস্টেম SHA-256 হ্যাশ ব্যবহার করে ফাইলের ডেটার উপর একটি Merkle ট্রি তৈরি করে, ফাইলের পাশে একটি লুকানো অবস্থানে সংরক্ষণ করে এবং ফাইলটিকে শুধুমাত্র পঠনযোগ্য হিসাবে চিহ্নিত করে। fs-verity স্বয়ংক্রিয়ভাবে মার্কেল ট্রির সাথে ফাইলের ডেটা পড়ার সাথে সাথে চাহিদা অনুযায়ী যাচাই করে। fs-verity মারকেল ট্রির রুট হ্যাশকে fs-verity ফাইল ডাইজেস্ট নামে একটি মান হিসাবে উপলব্ধ করে এবং fs-verity নিশ্চিত করে যে ফাইল থেকে পড়া যেকোনো ডেটা এই ফাইল ডাইজেস্টের সাথে সামঞ্জস্যপূর্ণ।

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

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

ফাইলের স্টোরেজ হজম হয়

odsign আর্টিফ্যাক্টের ফাইল ডাইজেস্টকে odsign.info নামে একটি পৃথক ফাইলে সংরক্ষণ করে। odsign.info সাথে টেম্পার না করা হয়েছে তা নিশ্চিত করার জন্য, odsign.info একটি সাইনিং কী দিয়ে সাইন করা হয়েছে যাতে গুরুত্বপূর্ণ নিরাপত্তা বৈশিষ্ট্য রয়েছে। বিশেষ করে, কী তৈরি করা যেতে পারে এবং শুধুমাত্র প্রাথমিক বুটের সময় ব্যবহার করা যেতে পারে, যেখানে শুধুমাত্র বিশ্বস্ত কোড চলছে; বিশদ বিবরণের জন্য বিশ্বস্ত স্বাক্ষর কীগুলি দেখুন৷

ফাইল ডাইজেস্টের যাচাইকরণ

প্রতিটি বুটে, যদি odrefresh নির্ধারণ করে যে বিদ্যমান আর্টিফ্যাক্টগুলি আপ টু ডেট, odsign নিশ্চিত করে যে ফাইলগুলি তৈরি হওয়ার পর থেকে সেগুলিকে টেম্পার করা হয়নি৷ odsign ফাইল ডাইজেস্ট যাচাই করে এটি করে। প্রথমত, এটি odsign.info এর স্বাক্ষর যাচাই করে। যদি স্বাক্ষরটি বৈধ হয়, তাহলে odsign যাচাই করে যে প্রতিটি ফাইলের ডাইজেস্ট odsign.info তে সংশ্লিষ্ট ডাইজেস্টের সাথে মেলে।

বিশ্বস্ত সাইনিং কী

অ্যান্ড্রয়েড 12 বুট স্টেজ কী নামে একটি নতুন কীস্টোর বৈশিষ্ট্য প্রবর্তন করেছে যা নিম্নলিখিত সুরক্ষা উদ্বেগের সমাধান করে:

  • কোন আক্রমণকারীকে আমাদের সাইনিং কী ব্যবহার করে odsign.info এর নিজস্ব সংস্করণে স্বাক্ষর করতে বাধা দেয়?
  • কোন আক্রমণকারীকে তাদের নিজস্ব সাইনিং কী তৈরি করতে এবং odsign.info এর নিজস্ব সংস্করণে স্বাক্ষর করতে ব্যবহার করতে বাধা দেয়?

বুট স্টেজ কীগুলি অ্যান্ড্রয়েডের বুট চক্রকে স্তরগুলিতে বিভক্ত করে এবং ক্রিপ্টোগ্রাফিকভাবে একটি কী তৈরি এবং ব্যবহারকে একটি নির্দিষ্ট স্তরে বেঁধে দেয়। odsign প্রাথমিক স্তরে তার সাইনিং কী তৈরি করে, যখন শুধুমাত্র বিশ্বস্ত কোড চলছে, dm-verity মাধ্যমে সুরক্ষিত।

বুট পর্যায়ের স্তরগুলি 0 থেকে ম্যাজিক নম্বর 1000000000 পর্যন্ত সংখ্যাযুক্ত। Android এর বুট প্রক্রিয়া চলাকালীন, আপনি init.rc থেকে একটি সিস্টেম বৈশিষ্ট্য সেট করে বুট স্তর বাড়াতে পারেন। উদাহরণস্বরূপ, নিম্নলিখিত কোডটি বুট স্তরকে 10 এ সেট করে:

setprop keystore.boot_level 10

কীস্টোরের ক্লায়েন্টরা একটি নির্দিষ্ট বুট স্তরের সাথে আবদ্ধ কীগুলি তৈরি করতে পারে। উদাহরণস্বরূপ, আপনি যদি বুট স্তর 10-এর জন্য একটি কী তৈরি করেন, তাহলে ডিভাইসটি বুট স্তর 10-এ থাকাকালীনই সেই কীটি ব্যবহার করা যেতে পারে।

odsign বুট স্তর 30 ব্যবহার করে, এবং এটি যে সাইনিং কী তৈরি করে তা সেই বুট স্তরের সাথে সংযুক্ত থাকে। আর্টিফ্যাক্ট সাইন ইন করার জন্য একটি কী ব্যবহার করার আগে, odsign যাচাই করে যে কীটি বুট লেভেল 30 এর সাথে আবদ্ধ।

এটি এই বিভাগে আগে বর্ণিত দুটি আক্রমণ প্রতিরোধ করে:

  • আক্রমণকারীরা জেনারেট করা কী ব্যবহার করতে পারে না, কারণ যখন একজন আক্রমণকারীর দূষিত কোড চালানোর সুযোগ থাকে, তখন বুট লেভেল 30-এর বেশি বেড়ে যায় এবং কীস্টোর কী ব্যবহার করে এমন ক্রিয়াকলাপ প্রত্যাখ্যান করে।
  • আক্রমণকারীরা একটি নতুন কী তৈরি করতে পারে না, কারণ যখন একজন আক্রমণকারীর দূষিত কোড চালানোর সুযোগ থাকে, তখন বুট স্তর 30-এর বেশি বেড়ে যায় এবং কীস্টোর সেই বুট স্তরের সাথে একটি নতুন কী তৈরি করতে অস্বীকার করে৷ যদি একজন আক্রমণকারী একটি নতুন কী তৈরি করে যা বুট স্তর 30 এর সাথে আবদ্ধ না থাকে, odsign এটি প্রত্যাখ্যান করে।

কীস্টোর নিশ্চিত করে যে বুট স্তরটি সঠিকভাবে প্রয়োগ করা হয়েছে। নিম্নলিখিত বিভাগগুলি বিভিন্ন কীমাস্টার সংস্করণের জন্য এটি কীভাবে করা হয় সে সম্পর্কে আরও বিশদে যায়।

কীমাস্টার 4.0 বাস্তবায়ন

Keymaster-এর বিভিন্ন সংস্করণ বুট স্টেজ কীগুলির বাস্তবায়ন ভিন্নভাবে পরিচালনা করে। একটি Keymaster 4.0 TEE/Strongbox সহ ডিভাইসগুলিতে, Keymaster নিম্নরূপ বাস্তবায়ন পরিচালনা করে:

  1. প্রথম বুট করার সময়, কীস্টোর 1 এ সেট করা MAX_USES_PER_BOOT ট্যাগ সহ একটি সিমেট্রিক কী K0 তৈরি করে। এর মানে হল প্রতি বুটে কী শুধুমাত্র একবার ব্যবহার করা যাবে।
  2. বুট চলাকালীন, বুট লেভেল বাড়ানো হলে, HKDF ফাংশন ব্যবহার করে K0 থেকে সেই বুট লেভেলের জন্য একটি নতুন কী তৈরি করা যেতে পারে: Ki+i=HKDF(Ki, "some_fixed_string") । উদাহরণস্বরূপ, আপনি যদি বুট লেভেল 0 থেকে বুট লেভেল 10 এ যান, তাহলে K0 থেকে K10 বের করার জন্য HKDF 10 বার আহ্বান করা হয়।

  3. বুট স্তর পরিবর্তন হলে, পূর্ববর্তী বুট স্তরের কী মেমরি থেকে মুছে ফেলা হয় এবং পূর্ববর্তী বুট স্তরের সাথে যুক্ত কীগুলি আর উপলব্ধ থাকে না।

    কী K0 হল একটি MAX_USES_PER_BOOT=1 কী। এর মানে হল যে বুট করার পরে সেই কীটি ব্যবহার করাও অসম্ভব, কারণ অন্তত একটি বুট স্তরের রূপান্তর (চূড়ান্ত বুট স্তরে) সর্বদা ঘটে।

যখন একটি কীস্টোর ক্লায়েন্ট যেমন odsign বুট স্তর i তে একটি কী তৈরি করার অনুরোধ করে, তখন এর ব্লব কী Ki দিয়ে এনক্রিপ্ট করা হয়। যেহেতু বুট স্তর i এর পরে Ki উপলব্ধ নেই, এই কীটি পরবর্তী বুট পর্যায়ে তৈরি বা ডিক্রিপ্ট করা যাবে না।

Keymaster 4.1 এবং KeyMint 1.0 বাস্তবায়ন

Keymaster 4.1 এবং KeyMint 1.0 বাস্তবায়ন মূলত Keymaster 4.0 বাস্তবায়নের মতই। প্রধান পার্থক্য হল K0 একটি MAX_USES_PER_BOOT কী নয়, কিন্তু একটি EARLY_BOOT_ONLY কী, যা Keymaster 4.1-এ চালু করা হয়েছিল। একটি EARLY_BOOT_ONLY কী শুধুমাত্র বুটের প্রাথমিক পর্যায়ে ব্যবহার করা যেতে পারে, যখন কোনো অবিশ্বস্ত কোড চলছে না। এটি একটি অতিরিক্ত স্তরের সুরক্ষা প্রদান করে: Keymaster 4.0 বাস্তবায়নে, একটি আক্রমণকারী যেটি ফাইল সিস্টেমের সাথে আপোস করে এবং SELinux কিস্টোর ডাটাবেস পরিবর্তন করতে পারে তার নিজস্ব MAX_USES_PER_BOOT=1 কী তৈরি করে আর্টিফ্যাক্টে স্বাক্ষর করার জন্য। Keymaster 4.1 এবং KeyMint 1.0 বাস্তবায়নের সাথে এই ধরনের আক্রমণ অসম্ভব, কারণ EARLY_BOOT_ONLY কীগুলি শুধুমাত্র প্রাথমিক বুটের সময় তৈরি করা যেতে পারে।

বিশ্বস্ত সাইনিং কীগুলির সর্বজনীন উপাদান

odsign কীস্টোর থেকে সাইনিং কী-এর সর্বজনীন কী উপাদান পুনরুদ্ধার করে। যাইহোক, কীস্টোর TEE/SE থেকে সেই পাবলিক কীটি পুনরুদ্ধার করে না যা সংশ্লিষ্ট ব্যক্তিগত কী ধারণ করে। পরিবর্তে, এটি তার নিজস্ব অন-ডিস্ক ডাটাবেস থেকে সর্বজনীন কী পুনরুদ্ধার করে। এর মানে হল যে একজন আক্রমণকারী যে ফাইল সিস্টেমের সাথে আপস করে সে কীস্টোর ডাটাবেসকে একটি পাবলিক কী ধারণ করতে পারে যা তাদের নিয়ন্ত্রণে থাকা একটি পাবলিক/প্রাইভেট কী-পেয়ারের অংশ।

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