এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

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

একটি চিপে (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 মানের একটি ভেক্টর সহ রিটার্ন মানগুলি " 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 নেমস্পেস আইডির আলাদা সংরক্ষিত পরিসর রয়েছে।

বিভাজন	পরিসর	কনফিগ ফাইল
পদ্ধতি	0 ... 9,999	/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts
বর্ধিত সিস্টেম	10,000 ... 19,999	/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts
পণ্য	20,000 ... 29,999	/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts
বিক্রেতা	30,000 ... 39,999	/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

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

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

নেমস্পেস আইডি	এসইপলিসি লেবেল	ইউআইডি	বর্ণনা
0	su_key	N/A	সুপার ইউজার কী। শুধুমাত্র userdebug এবং eng বিল্ডে পরীক্ষার জন্য ব্যবহার করা হয়। ব্যবহারকারী বিল্ডে প্রাসঙ্গিক নয়।
1	শেল_কী	N/A	শেলের জন্য উপলব্ধ নামস্থান। বেশিরভাগ পরীক্ষার জন্য ব্যবহৃত হয়, তবে কমান্ড লাইন থেকে ব্যবহারকারী বিল্ডে ব্যবহার করা যেতে পারে।
100	vold_key	N/A	vold দ্বারা ব্যবহারের জন্য উদ্দেশ্যে.
101	odsing_key	N/A	অন-ডিভাইস সাইনিং ডেমন দ্বারা ব্যবহৃত হয়।
102	wifi_key	AID_WIFI(1010)	wpa_supplicant সহ Android এর Wifi sybsystem দ্বারা ব্যবহৃত৷
120	resume_on_reboot_key	AID_SYSTEM(1000)	রিবুট করার সময় রিজুমে সমর্থন করার জন্য অ্যান্ড্রয়েডের সিস্টেম সার্ভার ব্যবহার করে।

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

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

অনুমতি	অর্থ
`delete`	কীস্টোর থেকে কীগুলি সরানোর সময় চেক করা হয়েছে৷
`get_info`	যখন একটি কী-এর মেটাডেটা অনুরোধ করা হয় তখন পরীক্ষা করা হয়।
`grant`	টার্গেট প্রেক্ষাপটে কীটিতে একটি অনুদান তৈরি করতে কলারের এই অনুমতির প্রয়োজন।
`manage_blob`	কলার প্রদত্ত SELinux নামস্থানে `DOMAIN_BLOB` ব্যবহার করতে পারে, যার ফলে নিজেই ব্লবগুলি পরিচালনা করতে পারে৷ এটি ভল্ডের জন্য বিশেষভাবে কার্যকর।
`rebind`	এই অনুমতি নিয়ন্ত্রণ করে যদি একটি উপনাম একটি নতুন কীতে রিবাউন্ড করা যেতে পারে। এটি সন্নিবেশের জন্য প্রয়োজন এবং বোঝায় যে পূর্বে আবদ্ধ কী মুছে ফেলা হবে। এটি মূলত একটি সন্নিবেশের অনুমতি, তবে এটি কীস্টোরের শব্দার্থকে আরও ভালভাবে ক্যাপচার করে।
`req_forced_op`	এই অনুমতি সহ ক্লায়েন্টরা অপরিশোধযোগ্য অপারেশনগুলি তৈরি করতে পারে এবং অপারেশন তৈরি করা কখনই ব্যর্থ হয় না যদি না সমস্ত অপারেশন স্লটগুলি অপরিবর্তনীয় অপারেশন দ্বারা নেওয়া হয়।
`update`	একটি কী এর সাবকম্পোনেন্ট আপডেট করার জন্য প্রয়োজন।
`use`	একটি Keymint অপারেশন তৈরি করার সময় চেক করা হয়েছে যা কী উপাদান ব্যবহার করে, যেমন, সাইনিং করার জন্য, en/decryption।
`use_dev_id`	ডিভাইস সনাক্তকরণ তথ্য যেমন ডিভাইস আইডি প্রত্যয়ন তৈরি করার সময় প্রয়োজন।

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

অনুমতি	অর্থ
`add_auth`	প্রমাণীকরণ টোকেন যোগ করার জন্য গেটকিপার বা বায়োমেট্রিক্স ম্যানেজারের মতো প্রমাণীকরণ প্রদানকারীর দ্বারা প্রয়োজনীয়৷
`clear_ns`	পূর্বে clear_uid, এই অনুমতি একটি নামস্থানের অ-মালিককে সেই নামস্থানের সমস্ত কী মুছে ফেলার অনুমতি দেয়।
`list`	বিভিন্ন বৈশিষ্ট্য, যেমন মালিকানা বা প্রমাণীকরণ সীমাবদ্ধতা দ্বারা কীগুলি গণনা করার জন্য সিস্টেমের দ্বারা প্রয়োজনীয়। কলকারীরা তাদের নিজস্ব নামস্থান গণনা করে এই অনুমতির প্রয়োজন নেই। এটি `get_info` অনুমতি দ্বারা আচ্ছাদিত।
`lock`	এই অনুমতিটি কীস্টোর লক করার অনুমতি দেয়, অর্থাৎ, মাস্টার কীটি উচ্ছেদ করে, যেমন প্রমাণীকরণ কীগুলি অব্যবহারযোগ্য এবং অপ্রয়োজনীয় হয়ে যায়।
`reset`	এই অনুমতি কীস্টোরকে ফ্যাক্টরি ডিফল্টে রিসেট করার অনুমতি দেয়, Android OS-এর কার্যকারিতার জন্য অত্যাবশ্যক নয় এমন সমস্ত কী মুছে দেয়৷
`unlock`	অথ বাউন্ড কীগুলির জন্য মাস্টার কী আনলক করার চেষ্টা করার জন্য এই অনুমতির প্রয়োজন৷

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

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

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

শব্দকোষ

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

স্থাপত্য

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

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

HIDL ওভারভিউ

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

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

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 কম্পাইলার দ্বারা উত্পন্ন 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)>

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

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

DOMAIN_APP : অ্যাপ্লিকেশান ডোমেনটি লিগ্যাসি আচরণকে কভার করে৷ Java Keystore SPI ডিফল্টরূপে এই ডোমেনটি ব্যবহার করে। যখন এই ডোমেনটি ব্যবহার করা হয়, তখন নেমস্পেস আর্গুমেন্ট উপেক্ষা করা হয় এবং এর পরিবর্তে কলারের UID ব্যবহার করা হয়। এই ডোমেনে অ্যাক্সেস কিস্টোর লেবেল দ্বারা SELinux নীতিতে ক্লাস keystore_key এর দ্বারা নিয়ন্ত্রিত হয়।
DOMAIN_SELINUX : এই ডোমেনটি নির্দেশ করে যে নামস্থানে SELinux নীতিতে একটি লেবেল রয়েছে৷ নেমস্পেস প্যারামিটারটি সন্ধান করা হয় এবং একটি টার্গেট প্রসঙ্গে অনুবাদ করা হয়, এবং keystore_key ক্লাসের জন্য কলিং SELinux প্রসঙ্গের জন্য একটি অনুমতি পরীক্ষা করা হয়। প্রদত্ত ক্রিয়াকলাপের জন্য অনুমতি প্রতিষ্ঠিত হলে, কী সন্ধানের জন্য সম্পূর্ণ টিপল ব্যবহার করা হয়।
DOMAIN_GRANT : অনুদান ডোমেন নির্দেশ করে যে নেমস্পেস প্যারামিটার একটি অনুদান সনাক্তকারী। The alias parameter is ignored. SELinux checks are performed when the grant is created. Further access control only checks if the caller UID matches the grantees UID of the requested grant.
DOMAIN_KEY_ID : This domain indicates that the namespace parameter is a unique key id. The key itself may have been created with DOMAIN_APP or DOMAIN_SELINUX . The permission check is performed after the domain and the namespace have been loaded from the key database in the same way as if the blob was loaded by the domain, namespace, and alias tuple. The rationale for the key id domain is continuity. When accessing a key by alias, subsequent calls may operate on different keys, because a new key may have been generated or imported and bound to this alias. The key id, however, never changes. So when using a key by key id after it has been loaded from the Keystore database using the alias once, one can be certain that it is the same key as long as the key id still exists. This functionality is not exposed to app developers. Instead, it is used within the Android Keystore SPI to provide a more consistent experience even when used concurrently in an unsafe way.
DOMAIN_BLOB : The blob domain indicates that the caller manages the blob by itself. This is used for clients that need to access the Keystore before the data partition is mounted. The key blob is included in the blob field of the key descriptor.

Using the SELinux domain, we can give vendor components access to very specific Keystore namespaces which can be shared by system components such as the settings dialog.

SELinux policy for keystore_key

Namespace labels are configured using the keystore2_key_context file.
Each line in these files maps a numeric namespace id to an SELinux label. For example,

# 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

After having set up a new key namespace in this way, we can give access to it by adding an appropriate policy. For example, to allow wpa_supplicant to get and use keys in the new namespace we would add the following line to hal_wifi_supplicant.te :

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

After setting up the new namespace, AndroidKeyStore can be used almost as usual. The only difference is that the namespace ID must be specified. For loading and importing keys from and into Keystore, the namespace id is specified using the AndroidKeyStoreLoadStoreParameter . For example,

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

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

To generate a key in a given namespace, the namespace id must be given using KeyGenParameterSpec.Builder#setNamespace():

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

The following context files may be used to configure Keystore 2.0 SELinux namespaces. Each partition has a different reserved range of 10,000 namespace ids to avoid collisions.

Partition	Range	Config files
System	0 ... 9,999	/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts
Extended System	10,000 ... 19,999	/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts
Product	20,000 ... 29,999	/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts
Vendor	30,000 ... 39,999	/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

The client requests the key by requesting the SELinux domain and the desired virtual namespace, in this case "wifi_key" , by its numeric id.

Above that, the following namespaces have been defined. If they replace special rules, the following table indicates the UID they used to correspond to.

Namespace ID	SEPolicy Label	UID	বর্ণনা
0	su_key	N/A	Super user key. Only used for testing on userdebug and eng builds. Not relevant on user builds.
1	shell_key	N/A	Namespace available to shell. Mostly used for testing, but can be used on user builds as well from the command line.
100	vold_key	N/A	Intended for use by vold.
101	odsing_key	N/A	Used by the on-device signing daemon.
102	wifi_key	AID_WIFI(1010)	Used by Android's Wifi sybsystem including wpa_supplicant.
120	resume_on_reboot_key	AID_SYSTEM(1000)	Used by Android's system server to support resume on reboot.

Access Vectors

The SELinux class keystore_key has aged quite a bit and some of the permissions, such as verify or sign have lost their meaning. Here is the new set of permissions, keystore2_key , that Keystore 2.0 will enforce.

Permission	Meaning
`delete`	Checked when removing keys from Keystore.
`get_info`	Checked when a key's metadata is requested.
`grant`	The caller needs this permission to create a grant to the key in the target context.
`manage_blob`	The caller may use `DOMAIN_BLOB` on the given SELinux namespace, thereby managing blobs by itself. This is specifically useful for vold.
`rebind`	This permission controls if an alias may be rebound to a new key. This is required for insertion and implies that the previously bound key will be deleted. It is basically an insert permission, but it captures the semantic of keystore better.
`req_forced_op`	Clients with this permission may create unpruneable operations, and operation creation never fails unless all operation slots are taken by unpruneable operations.
`update`	Required to update the subcomponent of a key.
`use`	Checked when creating a Keymint operation that uses the key material, eg, for signing, en/decryption.
`use_dev_id`	Required when generating device identifying information, such as device id attestation.

Additionally, we split out a set of non key specific keystore permissions in the SELinux security class keystore2 :

Permission	Meaning
`add_auth`	Required by authentication provider such as Gatekeeper or BiometricsManager for adding auth tokens.
`clear_ns`	Formerly clear_uid, this permission allows a non owner of a namespace to delete all keys in that namespace.
`list`	Required by the system for enumerating keys by various properties, such as ownership or auth boundedness. This permission is not required by callers enumerating their own namespaces. This is covered by the `get_info` permission.
`lock`	This permission allows to lock Keystore, that is, evict the master key, such that auth bound keys become unusable and uncreatable.
`reset`	This permission allows to reset Keystore to factory default, deleting all keys that are not vital to the functioning of the Android OS.
`unlock`	This permission is required to attempt to unlock the master key for auth bound keys.