হার্ডওয়্যার-সমর্থিত কীস্টোর

একটি চিপে (SoC) সিস্টেমে একটি বিশ্বস্ত কার্যকরী পরিবেশের উপলব্ধতা Android ডিভাইসগুলির জন্য Android OS, প্ল্যাটফর্ম পরিষেবাগুলিতে এবং এমনকি তৃতীয় পক্ষের অ্যাপগুলিতে হার্ডওয়্যার-সমর্থিত, শক্তিশালী নিরাপত্তা পরিষেবা প্রদান করার সুযোগ দেয়৷ অ্যান্ড্রয়েড-নির্দিষ্ট এক্সটেনশন খুঁজছেন এমন ডেভেলপারদের android.security.keystore- এ যেতে হবে।

অ্যান্ড্রয়েড 6.0-এর আগে, অ্যান্ড্রয়েড ইতিমধ্যেই একটি সাধারণ, হার্ডওয়্যার-সমর্থিত ক্রিপ্টো পরিষেবা API ছিল, যা কীমাস্টার হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার (HAL)-এর 0.2 এবং 0.3 সংস্করণ দ্বারা সরবরাহ করা হয়েছিল। কীস্টোর ডিজিটাল সাইনিং এবং যাচাইকরণ কার্যক্রম, প্লাস জেনারেশন এবং অ্যাসিমেট্রিক সাইনিং কী জোড়ার আমদানি প্রদান করে। এটি ইতিমধ্যেই অনেক ডিভাইসে প্রয়োগ করা হয়েছে, কিন্তু এমন অনেক নিরাপত্তা লক্ষ্য রয়েছে যা শুধুমাত্র একটি স্বাক্ষর API দিয়ে সহজে অর্জন করা যায় না। অ্যান্ড্রয়েড 6.0-এ কীস্টোর একটি বিস্তৃত পরিসরের ক্ষমতা প্রদান করতে কীস্টোর এপিআইকে প্রসারিত করেছে।

অ্যান্ড্রয়েড 6.0-এ, কীস্টোর সিমেট্রিক ক্রিপ্টোগ্রাফিক আদিম , AES এবং HMAC, এবং হার্ডওয়্যার-ব্যাকড কীগুলির জন্য একটি অ্যাক্সেস কন্ট্রোল সিস্টেম যুক্ত করেছে। অ্যাক্সেস নিয়ন্ত্রণগুলি কী তৈরির সময় নির্দিষ্ট করা হয় এবং কীটির আজীবনের জন্য প্রয়োগ করা হয়। কীগুলি ব্যবহারকারীর প্রমাণীকরণের পরেই ব্যবহারযোগ্য হতে সীমাবদ্ধ করা যেতে পারে, এবং শুধুমাত্র নির্দিষ্ট উদ্দেশ্যে বা নির্দিষ্ট ক্রিপ্টোগ্রাফিক পরামিতিগুলির সাথে। আরও তথ্যের জন্য, অনুমোদন ট্যাগ এবং ফাংশন পৃষ্ঠাগুলি দেখুন।

ক্রিপ্টোগ্রাফিক প্রিমিটিভের পরিসর প্রসারিত করার পাশাপাশি, অ্যান্ড্রয়েড 6.0-এ কীস্টোর নিম্নলিখিতগুলি যুক্ত করেছে:

• কী ব্যবহার সীমিত করার অনুমতি দেওয়ার জন্য একটি ব্যবহার নিয়ন্ত্রণ স্কিম, কীগুলির অপব্যবহারের কারণে নিরাপত্তা আপসের ঝুঁকি কমাতে
• নির্দিষ্ট ব্যবহারকারী, ক্লায়েন্ট এবং একটি সংজ্ঞায়িত সময়সীমার জন্য কীগুলির সীমাবদ্ধতা সক্ষম করার জন্য একটি অ্যাক্সেস নিয়ন্ত্রণ স্কিম

Android 7.0-এ, Keymaster 2 কী প্রত্যয়ন এবং সংস্করণ বাইন্ডিংয়ের জন্য সমর্থন যোগ করেছে। কী প্রত্যয়ন সার্বজনীন কী শংসাপত্রগুলি সরবরাহ করে যাতে কী এবং এর অ্যাক্সেস নিয়ন্ত্রণগুলির একটি বিশদ বিবরণ থাকে, সুরক্ষিত হার্ডওয়্যারে কীটির অস্তিত্ব এবং এর কনফিগারেশন দূর থেকে যাচাইযোগ্য করে তুলতে।

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

অ্যান্ড্রয়েড 8.0-এ, কীমাস্টার 3 পুরানো-স্টাইলের সি-স্ট্রাকচার হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার (HAL) থেকে নতুন হার্ডওয়্যার ইন্টারফেস ডেফিনিশন ল্যাঙ্গুয়েজ (HIDL) এর একটি সংজ্ঞা থেকে তৈরি C++ HAL ইন্টারফেসে রূপান্তরিত হয়েছে। পরিবর্তনের অংশ হিসেবে, অনেক আর্গুমেন্টের ধরন পরিবর্তিত হয়েছে, যদিও ধরন এবং পদ্ধতির পুরানো প্রকার এবং এইচএএল স্ট্রাকট পদ্ধতির সাথে এক থেকে এক চিঠিপত্র রয়েছে। আরও বিস্তারিত জানার জন্য ফাংশন পৃষ্ঠা দেখুন।

এই ইন্টারফেস সংশোধন ছাড়াও, Android 8.0 বর্ধিত Keymaster 2-এর প্রত্যয়ন বৈশিষ্ট্য আইডি প্রত্যয়ন সমর্থন করে। আইডি প্রত্যয়ন হার্ডওয়্যার শনাক্তকারীকে দৃঢ়ভাবে প্রত্যয়িত করার জন্য একটি সীমিত এবং ঐচ্ছিক প্রক্রিয়া প্রদান করে, যেমন ডিভাইসের সিরিয়াল নম্বর, পণ্যের নাম এবং ফোন আইডি (IMEI/MEID)। এই সংযোজন বাস্তবায়নের জন্য, Android 8.0 আইডি প্রত্যয়ন যোগ করতে ASN.1 প্রত্যয়ন স্কিমা পরিবর্তন করেছে। কীমাস্টার বাস্তবায়নের জন্য প্রাসঙ্গিক ডেটা আইটেমগুলি পুনরুদ্ধার করার জন্য কিছু নিরাপদ উপায় খুঁজে বের করতে হবে, সেইসাথে বৈশিষ্ট্যটিকে নিরাপদে এবং স্থায়ীভাবে অক্ষম করার জন্য একটি প্রক্রিয়া সংজ্ঞায়িত করতে হবে।

অ্যান্ড্রয়েড 9-এ, আপডেটগুলি অন্তর্ভুক্ত:

• Keymaster 4 এ আপডেট করুন
• এমবেডেড সিকিউর এলিমেন্টের জন্য সমর্থন
• নিরাপদ কী আমদানির জন্য সমর্থন
• 3DES এনক্রিপশনের জন্য সমর্থন
• ভার্সন বাইন্ডিং-এ পরিবর্তন যাতে boot.img এবং system.img স্বাধীন আপডেটের জন্য আলাদাভাবে সংস্করণ সেট করেছে

শব্দকোষ

এখানে কীস্টোর উপাদান এবং তাদের সম্পর্কগুলির একটি দ্রুত ওভারভিউ রয়েছে৷

AndroidKeystore হল Android Framework API এবং কীস্টোর কার্যকারিতা অ্যাক্সেস করতে অ্যাপস দ্বারা ব্যবহৃত উপাদান। এটি স্ট্যান্ডার্ড জাভা ক্রিপ্টোগ্রাফি আর্কিটেকচার এপিআই-এর একটি এক্সটেনশন হিসাবে প্রয়োগ করা হয় এবং এতে জাভা কোড থাকে যা অ্যাপের নিজস্ব প্রসেস স্পেসে চলে। AndroidKeystore কীস্টোর ডেমনে ফরোয়ার্ড করে কীস্টোর আচরণের জন্য অ্যাপের অনুরোধগুলি পূরণ করে।

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

keymasterd হল একটি HIDL সার্ভার যা Keymaster TA-তে অ্যাক্সেস প্রদান করে। (এই নামটি মানসম্মত নয় এবং ধারণাগত উদ্দেশ্যে।)

Keymaster TA (বিশ্বস্ত অ্যাপ্লিকেশন) হল একটি সুরক্ষিত প্রেক্ষাপটে চলমান সফ্টওয়্যার, প্রায়শই একটি ARM SoC-তে TrustZone-এ, যা নিরাপদ কীস্টোরের সমস্ত ক্রিয়াকলাপ প্রদান করে, কাঁচা কী সামগ্রীতে অ্যাক্সেস থাকে, কীগুলিতে অ্যাক্সেস নিয়ন্ত্রণের সমস্ত শর্তকে বৈধ করে। , ইত্যাদি

LockSettingsService হল Android সিস্টেমের উপাদান যা ব্যবহারকারীর প্রমাণীকরণের জন্য দায়ী, উভয় পাসওয়ার্ড এবং আঙ্গুলের ছাপ। এটি কীস্টোরের অংশ নয়, তবে প্রাসঙ্গিক কারণ অনেক কীস্টোর কী অপারেশনের জন্য ব্যবহারকারীর প্রমাণীকরণ প্রয়োজন। LockSettingsService প্রমাণীকরণ টোকেন পেতে গেটকিপার TA এবং ফিঙ্গারপ্রিন্ট TA এর সাথে যোগাযোগ করে, যা এটি কীস্টোর ডেমনকে প্রদান করে এবং যা শেষ পর্যন্ত কীমাস্টার TA অ্যাপ্লিকেশন দ্বারা গ্রাস করা হয়।

গেটকিপার TA (বিশ্বস্ত অ্যাপ্লিকেশন) হল নিরাপদ প্রেক্ষাপটে চলমান আরেকটি উপাদান, যা ব্যবহারকারীর পাসওয়ার্ড প্রমাণীকরণ এবং প্রমাণীকরণ টোকেন তৈরি করার জন্য দায়ী যা কী-মাস্টার TA-কে প্রমাণ করতে ব্যবহৃত হয় যে নির্দিষ্ট সময়ে একটি নির্দিষ্ট ব্যবহারকারীর জন্য একটি প্রমাণীকরণ করা হয়েছিল।

ফিঙ্গারপ্রিন্ট TA (বিশ্বস্ত অ্যাপ্লিকেশন) হল নিরাপদ প্রেক্ষাপটে চলমান আরেকটি উপাদান যা ব্যবহারকারীর আঙ্গুলের ছাপ প্রমাণীকরণের জন্য দায়ী এবং প্রমাণীকরণ টোকেন তৈরি করার জন্য যা কী-মাস্টার TA-কে প্রমাণ করতে ব্যবহৃত হয় যে নির্দিষ্ট সময়ে একটি নির্দিষ্ট ব্যবহারকারীর জন্য একটি প্রমাণীকরণ করা হয়েছিল।

স্থাপত্য

অ্যান্ড্রয়েড কীস্টোর এপিআই এবং অন্তর্নিহিত কীমাস্টার এইচএএল অ্যাক্সেস-নিয়ন্ত্রিত, হার্ডওয়্যার-ব্যাকড কী ব্যবহার করে প্রোটোকল বাস্তবায়নের অনুমতি দেওয়ার জন্য ক্রিপ্টোগ্রাফিক আদিমগুলির একটি মৌলিক কিন্তু পর্যাপ্ত সেট সরবরাহ করে।

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

চিত্র 1. কীমাস্টারে অ্যাক্সেস

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

কীমাস্টার এইচএএল-এর উদ্দেশ্য নিরাপত্তা-সংবেদনশীল অ্যালগরিদমগুলি বাস্তবায়ন করা নয়, শুধুমাত্র নিরাপদ বিশ্বের কাছে মার্শাল এবং আনমার্শাল অনুরোধ করা। তারের বিন্যাস বাস্তবায়ন-সংজ্ঞায়িত।

পূর্ববর্তী সংস্করণগুলির সাথে সামঞ্জস্যপূর্ণ

Keymaster 1 HAL পূর্বে প্রকাশিত HAL-এর সাথে সম্পূর্ণ বেমানান, যেমন Keymaster 0.2 এবং 0.3. পুরানো কীমাস্টার এইচএএল-এর সাথে চালু হওয়া Android 5.0 এবং তার আগের ডিভাইসগুলিতে আন্তঃঅপারেবিলিটি সুবিধার জন্য, কীস্টোর একটি অ্যাডাপ্টার সরবরাহ করে যা বিদ্যমান হার্ডওয়্যার লাইব্রেরিতে কল সহ কীমাস্টার 1 HAL প্রয়োগ করে। ফলাফল কীমাস্টার 1 HAL-এ কার্যকারিতার সম্পূর্ণ পরিসর প্রদান করতে পারে না। বিশেষ করে, এটি শুধুমাত্র RSA এবং ECDSA অ্যালগরিদম সমর্থন করে, এবং সমস্ত মূল অনুমোদনের প্রয়োগ অ্যাডাপ্টার দ্বারা সঞ্চালিত হয়, অ-নিরাপদ বিশ্বে।

Keymaster 2 get_supported_* পদ্ধতিগুলি সরিয়ে এবং finish() পদ্ধতিকে ইনপুট গ্রহণ করার অনুমতি দিয়ে HAL ইন্টারফেসটিকে আরও সরল করেছে। এটি TEE-তে রাউন্ড ট্রিপের সংখ্যা হ্রাস করে যেখানে ইনপুট একবারে উপলব্ধ থাকে এবং AEAD ডিক্রিপশন বাস্তবায়নকে সহজ করে।

অ্যান্ড্রয়েড 8.0-এ, কীমাস্টার 3 পুরানো-স্টাইলের সি-স্ট্রাকচার HAL থেকে C++ HAL ইন্টারফেসে রূপান্তরিত হয়েছে যা নতুন হার্ডওয়্যার ইন্টারফেস ডেফিনিশন ল্যাঙ্গুয়েজ (HIDL) এর একটি সংজ্ঞা থেকে তৈরি হয়েছে। তৈরি করা IKeymasterDevice ক্লাসের সাবক্লাসিং এবং বিশুদ্ধ ভার্চুয়াল পদ্ধতি প্রয়োগ করে একটি নতুন-শৈলী HAL বাস্তবায়ন তৈরি করা হয়। পরিবর্তনের অংশ হিসেবে, অনেক আর্গুমেন্টের ধরন পরিবর্তিত হয়েছে, যদিও ধরন এবং পদ্ধতির পুরানো প্রকার এবং এইচএএল স্ট্রাকট পদ্ধতির সাথে একের সাথে একের মিল রয়েছে।

HIDL ওভারভিউ

হার্ডওয়্যার ইন্টারফেস ডেফিনিশন ল্যাঙ্গুয়েজ (HIDL) হার্ডওয়্যার ইন্টারফেস নির্দিষ্ট করার জন্য একটি বাস্তবায়ন ভাষা-স্বাধীন প্রক্রিয়া প্রদান করে। HIDL টুলিং বর্তমানে C++ এবং জাভা ইন্টারফেসের জেনারেশন সমর্থন করে। এটা প্রত্যাশিত যে বেশিরভাগ বিশ্বস্ত এক্সিকিউশন এনভায়রনমেন্ট (TEE) বাস্তবায়নকারীরা C++ টুলিংকে আরও সুবিধাজনক মনে করবে, তাই এই নথিটি শুধুমাত্র C++ উপস্থাপনা নিয়ে আলোচনা করে।

HIDL ইন্টারফেসগুলি পদ্ধতির একটি সেট নিয়ে গঠিত, যা প্রকাশ করা হয়েছে:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

বিভিন্ন পূর্ব-সংজ্ঞায়িত প্রকার রয়েছে, এবং HAL গুলি নতুন গণনা এবং কাঠামোর ধরন সংজ্ঞায়িত করতে পারে। HIDL সম্পর্কে আরও বিশদ বিবরণের জন্য, রেফারেন্স বিভাগটি দেখুন।

Keymaster 3 IKeymasterDevice.hal থেকে একটি উদাহরণ পদ্ধতি হল:

generateKey(vec<KeyParameter> keyParams)
        generates(ErrorCode error, vec<uint8_t> keyBlob,
                  KeyCharacteristics keyCharacteristics);

এটি keymaster2 HAL থেকে নিম্নলিখিতগুলির সমতুল্য:

keymaster_error_t (*generate_key)(
        const struct keymaster2_device* dev,
        const keymaster_key_param_set_t* params,
        keymaster_key_blob_t* key_blob,
        keymaster_key_characteristics_t* characteristics);

HIDL সংস্করণে, dev যুক্তিটি সরানো হয়েছে, কারণ এটি অন্তর্নিহিত। params আর্গুমেন্টটি আর একটি স্ট্রাকট নয় যেখানে একটি পয়েন্টার রয়েছে যা key_parameter_t অবজেক্টের একটি অ্যারে উল্লেখ করে, কিন্তু একটি vec (ভেক্টর) যা KeyParameter অবজেক্ট ধারণ করে। কী uint8_t জন্য uint8_t মানের একটি ভেক্টর সহ রিটার্ন মানগুলি " generates " ধারায় তালিকাভুক্ত করা হয়েছে।

HIDL কম্পাইলার দ্বারা উত্পন্ন C++ ভার্চুয়াল পদ্ধতি হল:

Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams,
                         generateKey_cb _hidl_cb) override;

যেখানে generateKey_cb একটি ফাংশন পয়েন্টার হিসাবে সংজ্ঞায়িত করা হয়:

std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob,
                   const KeyCharacteristics& keyCharacteristics)>

অর্থাৎ, generateKey_cb একটি ফাংশন যা জেনারেট ক্লজে তালিকাভুক্ত রিটার্ন মান নেয়। HAL বাস্তবায়ন ক্লাস এই generateKey পদ্ধতিকে ওভাররাইড করে এবং generateKey_cb ফাংশন পয়েন্টারকে কল করে কলারের কাছে অপারেশনের ফলাফল ফেরত দিতে। লক্ষ্য করুন ফাংশন পয়েন্টার কল সিঙ্ক্রোনাস । কলার generateKey কল করে এবং generateKey সরবরাহকৃত ফাংশন পয়েন্টারকে কল করে, যা সম্পূর্ণ করার জন্য কার্যকর করে, generateKey বাস্তবায়নে নিয়ন্ত্রণ ফিরিয়ে দেয়, যা তারপর কলারের কাছে ফিরে আসে।

বিস্তারিত উদাহরণের জন্য, hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp এ ডিফল্ট বাস্তবায়ন দেখুন। ডিফল্ট বাস্তবায়ন পুরানো-স্টাইল keymaster0, keymaster1, বা keymaster2 HALS সহ ডিভাইসগুলির জন্য পশ্চাদমুখী সামঞ্জস্য প্রদান করে।

প্রবেশাধিকার নিয়ন্ত্রণ

কীস্টোর অ্যাক্সেস নিয়ন্ত্রণের সবচেয়ে মৌলিক নিয়ম হল প্রতিটি অ্যাপের নিজস্ব নামস্থান রয়েছে। কিন্তু প্রতিটি নিয়মের জন্য একটি ব্যতিক্রম আছে। কীস্টোরে কিছু হার্ড-কোডেড মানচিত্র রয়েছে যা নির্দিষ্ট সিস্টেমের উপাদানগুলিকে নির্দিষ্ট অন্যান্য নেমস্পেস অ্যাক্সেস করতে দেয়। এটি একটি খুব ভোঁতা যন্ত্র যাতে এটি একটি উপাদানকে অন্য নামস্থানের উপর সম্পূর্ণ নিয়ন্ত্রণ দেয়। এবং তারপর কীস্টোরের ক্লায়েন্ট হিসাবে বিক্রেতার উপাদানগুলির বিষয়টি রয়েছে। আমাদের কাছে বর্তমানে বিক্রেতার উপাদানগুলির জন্য একটি নামস্থান স্থাপন করার কোন উপায় নেই, উদাহরণস্বরূপ, WPA আবেদনকারী৷

হার্ড-কোডেড ব্যতিক্রম ছাড়াই বিক্রেতার উপাদানগুলিকে মিটমাট করার জন্য এবং অ্যাক্সেস নিয়ন্ত্রণকে সাধারণীকরণ করার জন্য, Keystore 2.0 ডোমেন এবং SELinux নামস্থান প্রবর্তন করে।

কীস্টোর ডোমেন

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

আমরা পাঁচটি ডোমেন প্যারামিটার প্রবর্তন করি যা কীগুলি কীভাবে অ্যাক্সেস করা যায় তা নিয়ন্ত্রণ করে। তারা কী বর্ণনাকারীর নেমস্পেস প্যারামিটারের শব্দার্থ নিয়ন্ত্রণ করে এবং কীভাবে অ্যাক্সেস নিয়ন্ত্রণ করা হয়।

• DOMAIN_APP : অ্যাপ্লিকেশান ডোমেনটি লিগ্যাসি আচরণকে কভার করে৷ Java Keystore SPI ডিফল্টরূপে এই ডোমেনটি ব্যবহার করে। যখন এই ডোমেনটি ব্যবহার করা হয়, তখন নেমস্পেস আর্গুমেন্ট উপেক্ষা করা হয় এবং এর পরিবর্তে কলারের UID ব্যবহার করা হয়। এই ডোমেনে অ্যাক্সেস কিস্টোর লেবেল দ্বারা SELinux নীতিতে ক্লাস keystore_key এর দ্বারা নিয়ন্ত্রিত হয়।
• DOMAIN_SELINUX : এই ডোমেনটি নির্দেশ করে যে নামস্থানে SELinux নীতিতে একটি লেবেল রয়েছে৷ নেমস্পেস প্যারামিটারটি সন্ধান করা হয় এবং একটি টার্গেট প্রসঙ্গে অনুবাদ করা হয়, এবং keystore_key ক্লাসের জন্য কলিং SELinux প্রসঙ্গের জন্য একটি অনুমতি পরীক্ষা করা হয়। প্রদত্ত ক্রিয়াকলাপের জন্য অনুমতি প্রতিষ্ঠিত হলে, কী সন্ধানের জন্য সম্পূর্ণ টিপল ব্যবহার করা হয়।
• DOMAIN_GRANT : অনুদান ডোমেন নির্দেশ করে যে নেমস্পেস প্যারামিটার একটি অনুদান সনাক্তকারী। উপনাম প্যারামিটার উপেক্ষা করা হয়। অনুদান তৈরি হলে SELinux চেক করা হয়। আরও অ্যাক্সেস কন্ট্রোল শুধুমাত্র চেক করে যে কলার UID অনুরোধকৃত অনুদানের অনুদানকারী UID এর সাথে মেলে কিনা।
• DOMAIN_KEY_ID : এই ডোমেনটি নির্দেশ করে যে নেমস্পেস প্যারামিটারটি একটি অনন্য কী আইডি। কী নিজেই DOMAIN_APP বা DOMAIN_SELINUX দিয়ে তৈরি করা হতে পারে। domain এবং namespace কী ডাটাবেস থেকে লোড হওয়ার পরে অনুমতি চেক করা হয় ঠিক একইভাবে যেন ডোমেন, নেমস্পেস এবং উপনাম টিপল দ্বারা ব্লব লোড করা হয়েছিল। কী আইডি ডোমেনের যৌক্তিকতা হল ধারাবাহিকতা। উপনাম দ্বারা একটি কী অ্যাক্সেস করার সময়, পরবর্তী কলগুলি বিভিন্ন কীগুলিতে কাজ করতে পারে, কারণ একটি নতুন কী তৈরি বা আমদানি করা হয়েছে এবং এই উপনামের সাথে আবদ্ধ হতে পারে। তবে কী আইডি কখনো পরিবর্তন হয় না। তাই কীস্টোর ডাটাবেস থেকে একবার উপনাম ব্যবহার করে লোড হওয়ার পরে কী আইডি দ্বারা একটি কী ব্যবহার করার সময়, কেউ নিশ্চিত হতে পারে যে যতক্ষণ কী আইডিটি এখনও বিদ্যমান থাকবে ততক্ষণ এটি একই কী। এই কার্যকারিতা অ্যাপ ডেভেলপারদের কাছে প্রকাশ করা হয় না। পরিবর্তে, এটি একটি অনিরাপদ উপায়ে একযোগে ব্যবহার করার পরেও আরও সামঞ্জস্যপূর্ণ অভিজ্ঞতা প্রদান করতে Android Keystore SPI-এর মধ্যে ব্যবহার করা হয়।
• DOMAIN_BLOB : ব্লব ডোমেন নির্দেশ করে যে কলকারী নিজেই ব্লব পরিচালনা করে৷ এটি ক্লায়েন্টদের জন্য ব্যবহৃত হয় যাদের ডেটা পার্টিশন মাউন্ট করার আগে কীস্টোর অ্যাক্সেস করতে হবে। কী ব্লব কী বর্ণনাকারীর blob ক্ষেত্রে অন্তর্ভুক্ত।

SELinux ডোমেন ব্যবহার করে, আমরা বিক্রেতা উপাদানগুলিকে খুব নির্দিষ্ট কীস্টোর নামস্থানে অ্যাক্সেস দিতে পারি যা সেটিংস ডায়ালগের মতো সিস্টেম উপাদানগুলির দ্বারা ভাগ করা যেতে পারে।

keystore_key-এর জন্য SELinux নীতি

নেমস্পেস লেবেলগুলি keystore2_key_context ফাইল ব্যবহার করে কনফিগার করা হয়।
এই ফাইলগুলির প্রতিটি লাইন একটি SELinux লেবেলে একটি সংখ্যাসূচক নেমস্পেস আইডি ম্যাপ করে। উদাহরণ স্বরূপ,

# wifi_key is a keystore2_key namespace intended to be used by wpa supplicant and
# Settings to share keystore keys.
102            u:object_r:wifi_key:s0

এইভাবে একটি নতুন কী নামস্থান সেট আপ করার পরে, আমরা একটি উপযুক্ত নীতি যোগ করে এটিতে অ্যাক্সেস দিতে পারি। উদাহরণস্বরূপ, wpa_supplicant কে নতুন নামস্থানে কী পেতে এবং ব্যবহার করার অনুমতি দিতে আমরা hal_wifi_supplicant.te তে নিম্নলিখিত লাইনটি যুক্ত করব:

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

নতুন নামস্থান সেট আপ করার পরে, AndroidKeyStore প্রায় স্বাভাবিক হিসাবে ব্যবহার করা যেতে পারে। শুধুমাত্র পার্থক্য হল যে নামস্থান আইডি নির্দিষ্ট করা আবশ্যক। কীস্টোর থেকে এবং কী লোড করার জন্য এবং আমদানি করার জন্য, AndroidKeyStoreLoadStoreParameter ব্যবহার করে নেমস্পেস আইডি নির্দিষ্ট করা হয়। উদাহরণ স্বরূপ,

import android.security.keystore2.AndroidKeyStoreLoadStoreParameter;
import java.security.KeyStore;

KeyStore keystore = KeyStore.getInstance("AndroidKeyStore");
keystore.load(new AndroidKeyStoreLoadStoreParameter(102));

একটি প্রদত্ত নামস্থানে একটি কী তৈরি করতে, নামস্থান আইডিটি অবশ্যই KeyGenParameterSpec.Builder#setNamespace(): ব্যবহার করে দিতে হবে।

import android.security.keystore.KeyGenParameterSpec;
KeyGenParameterSpec.Builder specBuilder = new KeyGenParameterSpec.Builder();
specBuilder.setNamespace(102);

নিম্নলিখিত প্রসঙ্গ ফাইলগুলি কীস্টোর 2.0 SELinux নামস্থান কনফিগার করতে ব্যবহার করা যেতে পারে। সংঘর্ষ এড়াতে প্রতিটি পার্টিশনে 10,000 নেমস্পেস আইডির আলাদা সংরক্ষিত পরিসর রয়েছে।

/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts

/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts

/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts

/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

ক্লায়েন্ট SELinux ডোমেন এবং পছন্দসই ভার্চুয়াল নেমস্পেস অনুরোধ করে কী অনুরোধ করে, এই ক্ষেত্রে "wifi_key" এর সাংখ্যিক আইডি দ্বারা।

তার উপরে, নিম্নলিখিত নামস্থান সংজ্ঞায়িত করা হয়েছে। যদি তারা বিশেষ নিয়মগুলি প্রতিস্থাপন করে, তাহলে নিম্নলিখিত সারণীটি নির্দেশ করে যে UID তারা সঙ্গতিপূর্ণ ছিল।

অ্যাক্সেস ভেক্টর

SELinux ক্লাস keystore_key বেশ কিছুটা পুরানো হয়েছে এবং কিছু অনুমতি, যেমন verify বা sign তাদের অর্থ হারিয়েছে। এখানে অনুমতির নতুন সেট, keystore2_key , যা Keystore 2.0 প্রয়োগ করবে।

অতিরিক্তভাবে, আমরা SELinux সিকিউরিটি ক্লাস keystore2 তে নন-কি নির্দিষ্ট কী-স্টোর অনুমতিগুলির একটি সেট বিভক্ত করেছি: