সংস্করণ বাঁধাই

কীমাস্টার 1-এ, সমস্ত কীমাস্টার কী ক্রিপ্টোগ্রাফিকভাবে ডিভাইস রুট অফ ট্রাস্ট বা যাচাইকৃত বুট কী-এর সাথে আবদ্ধ ছিল। কীমাস্টার 2 এবং 3-এ, সমস্ত কীগুলি অপারেটিং সিস্টেম এবং সিস্টেম চিত্রের প্যাচ স্তরের সাথে আবদ্ধ। এটি নিশ্চিত করে যে একজন আক্রমণকারী যে সিস্টেম বা TEE সফ্টওয়্যারের একটি পুরানো সংস্করণে দুর্বলতা আবিষ্কার করে সে একটি ডিভাইসকে দুর্বল সংস্করণে ফিরিয়ে আনতে পারে না এবং নতুন সংস্করণের সাথে তৈরি করা কীগুলি ব্যবহার করতে পারে না। উপরন্তু, যখন একটি নতুন সংস্করণ বা প্যাচ স্তরে আপগ্রেড করা হয়েছে এমন একটি ডিভাইসে একটি প্রদত্ত সংস্করণ এবং প্যাচ স্তর সহ একটি কী ব্যবহার করা হয়, তখন কীটি ব্যবহার করার আগে আপগ্রেড করা হয় এবং কীটির পূর্ববর্তী সংস্করণটি অবৈধ হয়ে যায়। এইভাবে, ডিভাইসটি আপগ্রেড হওয়ার সাথে সাথে, কীগুলি *র্যাচেট* ডিভাইসের সাথে এগিয়ে যায়, কিন্তু ডিভাইসটিকে পূর্ববর্তী রিলিজে ফিরিয়ে আনার কারণে কীগুলি অকেজো হয়ে যায়।

Treble-এর মডুলার কাঠামোকে সমর্থন করতে এবং boot.img-এ system.img-এর বাইন্ডিং ভাঙতে, Keymaster 4 প্রতিটি পার্টিশনের জন্য আলাদা প্যাচ লেভেলের জন্য কী সংস্করণ বাইন্ডিং মডেল পরিবর্তন করেছে। এটি প্রতিটি পার্টিশনকে স্বাধীনভাবে আপডেট করার অনুমতি দেয়, এখনও রোলব্যাক সুরক্ষা প্রদান করে।

অ্যান্ড্রয়েড 9-এ boot , system এবং vendor পার্টিশনের প্রত্যেকটির নিজস্ব প্যাচ লেভেল রয়েছে।

• অ্যান্ড্রয়েড ভেরিফাইড বুট (AVB) সহ ডিভাইসগুলি সমস্ত প্যাচ স্তর এবং সিস্টেম সংস্করণকে vbmeta-তে রাখতে পারে, যাতে বুটলোডার সেগুলি কীমাস্টারকে সরবরাহ করতে পারে। চেইনড পার্টিশনের জন্য, পার্টিশনের সংস্করণের তথ্য চেইনড vbmeta-তে রয়েছে। সাধারণভাবে, সংস্করণ তথ্য vbmeta struct থাকা উচিত যাতে একটি প্রদত্ত পার্টিশনের জন্য যাচাইকরণ ডেটা (হ্যাশ বা হ্যাশট্রি) থাকে।
• AVB ছাড়া ডিভাইসে:
  • যাচাইকৃত বুট বাস্তবায়নের জন্য বুটলোডারে সংস্করণ মেটাডেটার একটি হ্যাশ প্রদান করতে হবে, যাতে বুটলোডার কীমাস্টারকে হ্যাশ প্রদান করতে পারে।
  • boot.img হেডারে প্যাচ স্তর সংরক্ষণ করা চালিয়ে যেতে পারে
  • system.img শুধুমাত্র-পঠন বৈশিষ্ট্যগুলিতে প্যাচ স্তর এবং OS সংস্করণ সংরক্ষণ করা চালিয়ে যেতে পারে
  • vendor.img প্যাচ স্তরটিকে শুধুমাত্র-পঠনযোগ্য বৈশিষ্ট্যে সংরক্ষণ করে ro.vendor.build.version.security_patch .
  • বুটলোডার কীমাস্টারকে যাচাইকৃত বুট দ্বারা যাচাইকৃত সমস্ত ডেটার একটি হ্যাশ প্রদান করতে পারে।
• অ্যান্ড্রয়েড 9-এ, নিম্নলিখিত পার্টিশনগুলির সংস্করণ তথ্য সরবরাহ করতে নিম্নলিখিত ট্যাগগুলি ব্যবহার করুন:
  • VENDOR_PATCH_LEVEL : vendor পার্টিশন
  • BOOT_PATCH_LEVEL : boot পার্টিশন
  • OS_PATCH_LEVEL এবং OS_VERSION : system পার্টিশন। ( OS_VERSION boot.img হেডার থেকে সরানো হয়েছে৷
• কীমাস্টার বাস্তবায়নের সমস্ত প্যাচ স্তর স্বাধীনভাবে আচরণ করা উচিত। কী ব্যবহারযোগ্য যদি সমস্ত সংস্করণের তথ্য একটি কী-এর সাথে সম্পর্কিত মানগুলির সাথে মেলে এবং প্রয়োজনে IKeymaster::upgradeDevice() একটি উচ্চতর প্যাচ স্তরে চলে যায়।

HAL পরিবর্তন

সংস্করণ বাইন্ডিং এবং সংস্করণ সত্যায়ন সমর্থন করার জন্য, Android 7.1 ট্যাগ যোগ করেছে Tag::OS_VERSION এবং Tag::OS_PATCHLEVEL এবং পদ্ধতিগুলি configure এবং upgradeKey । সংস্করণ ট্যাগগুলি স্বয়ংক্রিয়ভাবে কীমাস্টার 2+ বাস্তবায়ন দ্বারা সমস্ত নতুন তৈরি (বা আপডেট হওয়া) কীগুলিতে যুক্ত হয়। উপরন্তু, বর্তমান সিস্টেমের OS সংস্করণ বা প্যাচ স্তরের সাথে মেলে না এমন একটি কী ব্যবহার করার যেকোন প্রচেষ্টা যথাক্রমে, ErrorCode::KEY_REQUIRES_UPGRADE দিয়ে প্রত্যাখ্যান করা হয়।

Tag::OS_VERSION হল একটি UINT মান যা একটি Android সিস্টেম সংস্করণের প্রধান, গৌণ এবং উপ-অপ্রধান অংশগুলিকে MMmmss হিসাবে উপস্থাপন করে, যেখানে MM প্রধান সংস্করণ, mm হল ক্ষুদ্র সংস্করণ এবং ss হল উপ-অপ্রধান সংস্করণ৷ উদাহরণস্বরূপ 6.1.2 060102 হিসাবে উপস্থাপন করা হবে।

Tag::OS_PATCHLEVEL হল একটি UINT মান যা YYYYMM হিসাবে সিস্টেমে শেষ আপডেটের বছর এবং মাসকে উপস্থাপন করে, যেখানে YYYY হল চার-সংখ্যার বছর এবং MM হল দুই-অঙ্কের মাস৷ উদাহরণস্বরূপ, মার্চ 2016 201603 হিসাবে উপস্থাপন করা হবে।

আপগ্রেড কী

সিস্টেম ইমেজের নতুন OS সংস্করণ এবং প্যাচ স্তরে কীগুলি আপগ্রেড করার অনুমতি দেওয়ার জন্য, Android 7.1 HAL-তে upgradeKey পদ্ধতি যুক্ত করেছে:

কীমাস্টার 3

    upgradeKey(vec keyBlobToUpgrade, vec upgradeParams)
        generates(ErrorCode error, vec upgradedKeyBlob);

কীমাস্টার 2

keymaster_error_t (*upgrade_key)(const struct keymaster2_device* dev,
    const keymaster_key_blob_t* key_to_upgrade,
    const keymaster_key_param_set_t* upgrade_params,
    keymaster_key_blob_t* upgraded_key);

• dev হল ডিভাইসের গঠন
• keyBlobToUpgrade হল কী যা আপগ্রেড করা দরকার
• upgradeParams হল কী আপগ্রেড করার জন্য প্রয়োজনীয় পরামিতি। এর মধ্যে রয়েছে Tag::APPLICATION_ID এবং Tag::APPLICATION_DATA , যেগুলো কী ব্লব ডিক্রিপ্ট করার জন্য প্রয়োজনীয়, যদি সেগুলি প্রজন্মের সময় প্রদান করা হয়।
• upgradedKeyBlob হল আউটপুট প্যারামিটার, নতুন কী ব্লব ফেরত দিতে ব্যবহৃত হয়।

যদি upgradeKey কে একটি কী ব্লব দিয়ে কল করা হয় যা পার্স করা যায় না বা অন্যথায় অবৈধ হয়, তাহলে এটি ErrorCode::INVALID_KEY_BLOB প্রদান করে। যদি এটিকে এমন একটি কী দিয়ে ডাকা হয় যার প্যাচ স্তর বর্তমান সিস্টেমের মানের থেকে বেশি, এটি ErrorCode::INVALID_ARGUMENT প্রদান করে। যদি এটিকে একটি কী দিয়ে কল করা হয় যার OS সংস্করণ বর্তমান সিস্টেম মানের থেকে বেশি, এবং সিস্টেমের মানটি শূন্য নয়, এটি ErrorCode::INVALID_ARGUMENT প্রদান করে। অ-শূন্য থেকে শূন্য পর্যন্ত OS সংস্করণ আপগ্রেড অনুমোদিত। নিরাপদ বিশ্বের সাথে যোগাযোগের ত্রুটির ক্ষেত্রে, এটি একটি উপযুক্ত ত্রুটি মান প্রদান করে (উদাহরণস্বরূপ, ErrorCode::SECURE_HW_ACCESS_DENIED , ErrorCode::SECURE_HW_BUSY )। অন্যথায়, এটি ErrorCode::OK প্রদান করে এবং upgradedKeyBlob এ একটি নতুন কী ব্লব প্রদান করে।

keyBlobToUpgrade upgradeKey কলের পরে বৈধ থাকে, এবং তাত্ত্বিকভাবে আবার ব্যবহার করা যেতে পারে যদি ডিভাইসটি ডাউনগ্রেড করা হয়। অনুশীলনে, কীস্টোর সাধারনত upgradeKey কল করার পরপরই keyBlobToUpgrade ব্লব-এ deleteKey কল করে। যদি keyBlobToUpgrade Tag Tag::ROLLBACK_RESISTANT থাকে, তাহলে upgradedKeyBlob এটি থাকা উচিত (এবং রোলব্যাক প্রতিরোধী হওয়া উচিত)।

সুরক্ষিত কনফিগারেশন

সংস্করণ বাইন্ডিং কার্যকর করার জন্য, কীমাস্টার TA-এর বর্তমান OS সংস্করণ এবং প্যাচ স্তর (সংস্করণ তথ্য) নিরাপদে গ্রহণ করার জন্য একটি উপায় প্রয়োজন, এবং এটি যে তথ্য প্রাপ্ত তথ্যটি চলমান সিস্টেম সম্পর্কিত তথ্যের সাথে দৃঢ়ভাবে মেলে তা নিশ্চিত করার জন্য।

TA-তে সংস্করণ তথ্যের নিরাপদ বিতরণ সমর্থন করার জন্য, বুট ইমেজ হেডারে একটি OS_VERSION ক্ষেত্র যোগ করা হয়েছে। বুট ইমেজ বিল্ড স্ক্রিপ্ট স্বয়ংক্রিয়ভাবে এই ক্ষেত্রটি পূরণ করে। বুট ইমেজ থেকে সংস্করণের তথ্য বের করতে এবং অ-সুরক্ষিত সিস্টেম বুট হওয়ার আগে এটি TA-তে পাস করার জন্য OEM এবং কীমাস্টার TA বাস্তবায়নকারীদের একসাথে কাজ করতে হবে ডিভাইস বুটলোডার সংশোধন করতে। এটি নিশ্চিত করে যে আক্রমণকারীরা TA-তে সংস্করণ তথ্যের বিধানে হস্তক্ষেপ করতে পারবে না।

সিস্টেম ইমেজ বুট ইমেজ হিসাবে একই সংস্করণ তথ্য আছে তা নিশ্চিত করা প্রয়োজন. সেই লক্ষ্যে, কীমাস্টার HAL-এ কনফিগার পদ্ধতি যোগ করা হয়েছে:

keymaster_error_t (*configure)(const struct keymaster2_device* dev,
  const keymaster_key_param_set_t* params);

params আর্গুমেন্টে Tag::OS_VERSION এবং Tag::OS_PATCHLEVEL রয়েছে। এই পদ্ধতিটি HAL খোলার পরে keymaster2 ক্লায়েন্টদের দ্বারা বলা হয়, কিন্তু অন্য কোনো পদ্ধতিতে কল করার আগে। কনফিগার করার আগে অন্য কোনো পদ্ধতিতে কল করা হলে, TA ErrorCode::KEYMASTER_NOT_CONFIGURED প্রদান করে।

ডিভাইস বুট হওয়ার পরে প্রথমবার configure কল করা হলে, এটি যাচাই করা উচিত যে প্রদত্ত সংস্করণ তথ্য বুটলোডার দ্বারা সরবরাহ করা হয়েছে তার সাথে মেলে। যদি সংস্করণের তথ্য মেলে না, ErrorCode::INVALID_ARGUMENT ফেরত configure এবং অন্যান্য সমস্ত কীমাস্টার পদ্ধতি ErrorCode::KEYMASTER_NOT_CONFIGURED ফেরত দেওয়া চালিয়ে যান। যদি তথ্য মিলে যায়, configure ErrorCode::OK , এবং অন্যান্য কীমাস্টার পদ্ধতি স্বাভাবিকভাবে কাজ করা শুরু করে।

configure জন্য পরবর্তী কলগুলি প্রথম কল দ্বারা প্রত্যাবর্তিত একই মান ফিরিয়ে দেয় এবং কীমাস্টারের অবস্থা পরিবর্তন করে না।

যেহেতু configure সেই সিস্টেম দ্বারা কল করা হয় যার বিষয়বস্তু এটি যাচাই করার উদ্দেশ্যে, একটি আক্রমণকারীর জন্য সিস্টেমের চিত্রের সাথে আপস করার এবং বুট চিত্রের সাথে মেলে এমন সংস্করণ তথ্য সরবরাহ করতে বাধ্য করার সুযোগের একটি সংকীর্ণ উইন্ডো রয়েছে, কিন্তু যা প্রকৃত নয় সিস্টেমের সংস্করণ। বুট ইমেজ যাচাইকরণের সংমিশ্রণ, সিস্টেম ইমেজ বিষয়বস্তুর dm-ভেরিটি যাচাইকরণ এবং সিস্টেম বুটের প্রথম দিকে configure বিষয়টি এই সুযোগের উইন্ডোটিকে কাজে লাগাতে কঠিন করে তুলবে।