ফিচার

এই পৃষ্ঠায় অ্যান্ড্রয়েড কীস্টোরের ক্রিপ্টোগ্রাফিক বৈশিষ্ট্য সম্পর্কে তথ্য রয়েছে, যা এর অন্তর্নিহিত কীমিন্ট (বা কীমাস্টার) ইমপ্লিমেন্টেশন দ্বারা সরবরাহ করা হয়।

ক্রিপ্টোগ্রাফিক আদিম

কীস্টোর নিম্নলিখিত শ্রেণীর অপারেশন প্রদান করে:

• কী তৈরি করা, যার ফলে এমন ব্যক্তিগত বা গোপন কী উপাদান তৈরি হয় যা শুধুমাত্র সুরক্ষিত পরিবেশে প্রবেশযোগ্য। ক্লায়েন্টরা নিম্নলিখিত উপায়ে কী তৈরি করতে পারে:
  • নতুন চাবি তৈরি
  • এনক্রিপ্ট না করা কী উপাদানের আমদানি
  • এনক্রিপ্টেড কী উপাদানের আমদানি
• কী অ্যাটেস্টেশন: অ্যাসিমেট্রিক কী তৈরির মাধ্যমে একটি সার্টিফিকেট তৈরি হয়, যা কীপেয়ারের পাবলিক কী অংশটি ধারণ করে। এই সার্টিফিকেটে ঐচ্ছিকভাবে কী-এর মেটাডেটা এবং ডিভাইসের অবস্থা সম্পর্কিত তথ্যও থাকে, যা একটি বিশ্বস্ত রুটের সাথে সংযুক্ত কী চেইন দ্বারা স্বাক্ষরিত হয়।
• ক্রিপ্টোগ্রাফিক অপারেশন:
  • প্রতিসম এনক্রিপশন এবং ডিক্রিপশন (AES, 3DES)
  • অপ্রতিসম ডিক্রিপশন (RSA)
  • অসমমিত স্বাক্ষর (ECDSA, RSA)
  • প্রতিসম স্বাক্ষর এবং যাচাইকরণ (HMAC)
  • অপ্রতিসম কী চুক্তি (ECDH)

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

উপরের তালিকা ছাড়াও, KeyMint (পূর্বে Keymaster) ইমপ্লিমেন্টেশনগুলো আরও একটি পরিষেবা প্রদান করে, যা API হিসেবে উন্মুক্ত নয়: র‍্যান্ডম সংখ্যা তৈরি। এটি অভ্যন্তরীণভাবে কী (key), ইনিশিয়ালাইজেশন ভেক্টর (IV), র‍্যান্ডম প্যাডিং এবং সুরক্ষিত প্রোটোকলের অন্যান্য উপাদান, যেগুলোর জন্য র‍্যান্ডমনেস প্রয়োজন, সেগুলো তৈরি করতে ব্যবহৃত হয়।

প্রয়োজনীয় আদিম

KeyMint-এর সকল বাস্তবায়ন নিম্নলিখিত সুবিধা প্রদান করে:

• আরএসএ
  • ২০৪৮, ৩০৭২ এবং ৪০৯৬-বিট কী সাপোর্ট
  • পাবলিক এক্সপোনেন্ট F4 (2^16+1) এর জন্য সমর্থন
  • আরএসএ স্বাক্ষরের জন্য প্যাডিং মোড:
    • RSASSA-PSS ( PaddingMode::RSA_PSS )
    • RSASSA-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_SIGN )
  • আরএসএ স্বাক্ষরের জন্য ডাইজেস্ট মোড:
    • SHA-256
  • RSA এনক্রিপশন/ডিক্রিপশনের জন্য প্যাডিং মোড:
    • প্যাডবিহীন
    • RSAES-OAEP ( PaddingMode::RSA_OAEP )
    • RSAES-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_ENCRYPT )
• ইসিডিএসএ
  • যথাক্রমে NIST P-224, P-256, P-384, এবং P-521 কার্ভ ব্যবহার করে 224, 256, 384, এবং 521-বিট কী সাপোর্ট করা হয়।
  • ECDSA-এর জন্য ডাইজেস্ট মোড:
    • কোন ডাইজেস্ট নেই (অপ্রচলিত, ভবিষ্যতে সরিয়ে ফেলা হবে)
    • SHA-256
• AES
  • ১২৮ এবং ২৫৬-বিট কী সমর্থিত।
  • CBC , CTR, ECB, এবং GCM। GCM বাস্তবায়নে ৯৬ বিটের চেয়ে ছোট ট্যাগ অথবা ৯৬ বিট ব্যতীত অন্য কোনো ননস লেংথ ব্যবহারের অনুমতি নেই।
  • CBC এবং ECB মোডের জন্য PaddingMode::NONE এবং PaddingMode::PKCS7 প্যাডিং মোড সমর্থিত। কোনো প্যাডিং না থাকলে, ইনপুটটি ব্লক সাইজের গুণিতক না হলে CBC বা ECB মোড এনক্রিপশন ব্যর্থ হয়।
• HMAC SHA-256 , যার কী-সাইজ কমপক্ষে ৩২ বাইট পর্যন্ত হতে পারে।

KeyMint ইমপ্লিমেন্টেশনের জন্য SHA1 এবং SHA2 পরিবারের অন্যান্য সদস্য (SHA-224, SHA384 এবং SHA512) ব্যবহারের জন্য জোরালোভাবে সুপারিশ করা হয়। হার্ডওয়্যার KeyMint ইমপ্লিমেন্টেশনে এগুলি না থাকলে, Keystore সফটওয়্যারের মাধ্যমে তা সরবরাহ করে।

অন্যান্য সিস্টেমের সাথে আন্তঃকার্যক্ষমতার জন্য কিছু আদিম উপাদানও সুপারিশ করা হয়:

• RSA-এর জন্য ছোট আকারের কী
• আরএসএ-এর জন্য স্বেচ্ছাচারী জনপ্রতিনিধি

চাবি দিয়ে প্রবেশ নিয়ন্ত্রণ

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

অ্যাক্সেস কন্ট্রোলকে ট্যাগ/ভ্যালু জোড়ের একটি "অথরাইজেশন লিস্ট" হিসেবে সংজ্ঞায়িত করা হয়। অথরাইজেশন ট্যাগগুলো হলো ৩২-বিটের পূর্ণসংখ্যা এবং ভ্যালুগুলো বিভিন্ন ধরনের হয়ে থাকে। একাধিক ভ্যালু নির্দিষ্ট করার জন্য কিছু ট্যাগের পুনরাবৃত্তি করা যেতে পারে। কোনো ট্যাগের পুনরাবৃত্তি করা যাবে কিনা, তা KeyMint HAL ইন্টারফেসে নির্দিষ্ট করা থাকে। যখন একটি কী তৈরি করা হয়, তখন কলার একটি অথরাইজেশন লিস্ট নির্দিষ্ট করে। Keystore-এর অন্তর্নিহিত KeyMint ইমপ্লিমেন্টেশনটি কিছু অতিরিক্ত তথ্য, যেমন কী-টির রোলব্যাক প্রোটেকশন আছে কিনা, তা নির্দিষ্ট করার জন্য লিস্টটি পরিবর্তন করে এবং ফেরত আসা কী ব্লবের মধ্যে এনকোড করা একটি "চূড়ান্ত" অথরাইজেশন লিস্ট ফেরত দেয়। যদি চূড়ান্ত অথরাইজেশন লিস্টটি পরিবর্তিত হয়, তবে যেকোনো ক্রিপ্টোগ্রাফিক অপারেশনের জন্য কী-টি ব্যবহার করার যেকোনো প্রচেষ্টা ব্যর্থ হয়।

Keymaster 2 এবং এর পূর্ববর্তী সংস্করণগুলির জন্য, সম্ভাব্য ট্যাগগুলির সেট keymaster_authorization_tag_t এনুমারেশনে সংজ্ঞায়িত করা আছে এবং এটি স্থায়ীভাবে স্থির (যদিও এটি সম্প্রসারিত করা যেতে পারে)। নামগুলির আগে KM_TAG উপসর্গটি যুক্ত করা হতো। ট্যাগ আইডিগুলির উপরের চারটি বিট এর ধরণ নির্দেশ করতে ব্যবহৃত হয়।

Keymaster 3, KM_TAG প্রিফিক্সটিকে Tag:: তে পরিবর্তন করেছে।

সম্ভাব্য প্রকারগুলোর মধ্যে রয়েছে:

ENUM : অনেক ট্যাগের মান এনুমারেশনের মাধ্যমে সংজ্ঞায়িত করা হয়। উদাহরণস্বরূপ, TAG::PURPOSE এর সম্ভাব্য মানগুলো keymaster_purpose_t নামক enum-এ সংজ্ঞায়িত করা হয়েছে।

ENUM_REP : ENUM মতোই, তবে এক্ষেত্রে ট্যাগটি একটি অনুমোদন তালিকায় পুনরাবৃত্তি করা যেতে পারে। পুনরাবৃত্তি একাধিক অনুমোদিত মান নির্দেশ করে। উদাহরণস্বরূপ, একটি এনক্রিপশন কী-তে সম্ভবত KeyPurpose::ENCRYPT এবং KeyPurpose::DECRYPT থাকে।

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

হার্ডওয়্যার বনাম সফটওয়্যার প্রয়োগ

সব সুরক্ষিত হার্ডওয়্যার বাস্তবায়নে একই বৈশিষ্ট্য থাকে না। বিভিন্ন ধরনের পদ্ধতিকে সমর্থন করার জন্য, কীমাস্টার সুরক্ষিত ও অসুরক্ষিত বিশ্ব অ্যাক্সেস নিয়ন্ত্রণ প্রয়োগ, অথবা যথাক্রমে হার্ডওয়্যার ও সফটওয়্যার প্রয়োগের মধ্যে পার্থক্য করে।

KeyMint API-তে KeyCharacteristics টাইপের securityLevel ফিল্ডের মাধ্যমে এটি প্রকাশ করা হয়। সুরক্ষিত হার্ডওয়্যারটি তার প্রয়োগ ক্ষমতার উপর ভিত্তি করে, KeyCharacteristics এ উপযুক্ত নিরাপত্তা স্তরসহ অনুমোদনগুলো স্থাপন করার জন্য দায়ী। এই তথ্যটি অ্যাসিমেট্রিক কী-এর অ্যাটেস্টেশন রেকর্ডেও প্রকাশ করা হয়: SecurityLevel::TRUSTED_ENVIRONMENT বা SecurityLevel::STRONGBOX জন্য কী ক্যারেক্টারিস্টিকস hardwareEnforced তালিকায় প্রদর্শিত হয়, এবং SecurityLevel::SOFTWARE বা SecurityLevel::KEYSTORE জন্য ক্যারেক্টারিস্টিকস softwareEnforced তালিকায় প্রদর্শিত হয়।

উদাহরণস্বরূপ, কোনো কী ব্যবহারের তারিখ ও সময়ের ব্যবধানের উপর আরোপিত সীমাবদ্ধতাগুলো সাধারণত সুরক্ষিত পরিবেশে প্রয়োগ করা হয় না, কারণ তারিখ ও সময়ের তথ্যে এর নির্ভরযোগ্য অ্যাক্সেস থাকে না। ফলস্বরূপ, Tag::ORIGINATION_EXPIRE_DATETIME এর মতো অনুমোদনগুলো অ্যান্ড্রয়েডে Keystore দ্বারা প্রয়োগ করা হয় এবং এগুলোর SecurityLevel::KEYSTORE থাকে।

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

ক্রিপ্টোগ্রাফিক বার্তা নির্মাণের অনুমোদন

সংশ্লিষ্ট কী ব্যবহার করে অপারেশনগুলোর ক্রিপ্টোগ্রাফিক বৈশিষ্ট্য নির্ধারণ করতে নিম্নলিখিত ট্যাগগুলো ব্যবহৃত হয়:

• Tag::ALGORITHM
• Tag::KEY_SIZE
• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::CALLER_NONCE
• Tag::DIGEST
• Tag::MGF_DIGEST

নিম্নলিখিত ট্যাগগুলি পুনরাবৃত্তিযোগ্য, যার অর্থ হলো একটিমাত্র কী-এর সাথে একাধিক মান যুক্ত করা যেতে পারে:

• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::DIGEST
• Tag::MGF_DIGEST

ব্যবহৃতব্য মানটি অপারেশনের সময় নির্দিষ্ট করা হয়।

উদ্দেশ্য

কী-গুলোর সাথে একগুচ্ছ উদ্দেশ্য যুক্ত থাকে, যা Tag::PURPOSE ট্যাগসহ এক বা একাধিক অথরাইজেশন এন্ট্রি হিসেবে প্রকাশ করা হয় এবং যা নির্ধারণ করে দেয় যে সেগুলো কীভাবে ব্যবহার করা যাবে। এই উদ্দেশ্যগুলো KeyPurpose.aidl ফাইলে সংজ্ঞায়িত করা থাকে।

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

মূল আমদানি

Keymaster শুধুমাত্র X.509 ফরম্যাটে পাবলিক কী রপ্তানি এবং নিম্নলিখিতগুলো আমদানি সমর্থন করে:

• DER-এনকোডেড PKCS#8 ফরম্যাটে অপ্রতিসম কী জোড়া (পাসওয়ার্ড-ভিত্তিক এনক্রিপশন ছাড়া)
• কাঁচা বাইট হিসাবে প্রতিসম কী

আমদানি করা কী-গুলোকে সুরক্ষিতভাবে তৈরি করা কী-গুলো থেকে আলাদা করা যায় তা নিশ্চিত করার জন্য, উপযুক্ত কী অনুমোদন তালিকায় Tag::ORIGIN অন্তর্ভুক্ত করা হয়। উদাহরণস্বরূপ, যদি কোনো কী সুরক্ষিত হার্ডওয়্যারে তৈরি করা হয়ে থাকে, তাহলে কী-এর বৈশিষ্ট্যগুলোর hw_enforced তালিকায় KeyOrigin::GENERATED মানসহ Tag::ORIGIN পাওয়া যায়, অপরদিকে সুরক্ষিত হার্ডওয়্যারে আমদানি করা একটি কী-এর মান হয় KeyOrigin::IMPORTED ।

ব্যবহারকারী প্রমাণীকরণ

সুরক্ষিত KeyMint ইমপ্লিমেন্টেশনগুলো ব্যবহারকারী প্রমাণীকরণ বাস্তবায়ন করে না, বরং তা করার জন্য অন্যান্য বিশ্বস্ত অ্যাপের উপর নির্ভর করে। এই অ্যাপগুলো যে ইন্টারফেসটি বাস্তবায়ন করে, তার জন্য Gatekeeper পৃষ্ঠাটি দেখুন।

ব্যবহারকারীর প্রমাণীকরণের প্রয়োজনীয়তা দুটি ট্যাগ সেটের মাধ্যমে নির্দিষ্ট করা হয়। প্রথম সেটটি নির্দেশ করে কোন প্রমাণীকরণ পদ্ধতিগুলো কী-টির ব্যবহার অনুমোদন করে:

• Tag::USER_SECURE_ID একটি ৬৪-বিটের সাংখ্যিক মান থাকে, যা সেই সুরক্ষিত ব্যবহারকারী আইডিকে নির্দিষ্ট করে। এই আইডিটি একটি সুরক্ষিত প্রমাণীকরণ টোকেনে প্রদান করা হয় কী-টির ব্যবহার আনলক করার জন্য। যদি এটির পুনরাবৃত্তি ঘটে, তবে সুরক্ষিত প্রমাণীকরণ টোকেনে উল্লিখিত মানগুলোর যেকোনো একটি প্রদান করা হলে কী-টি ব্যবহার করা যাবে।

দ্বিতীয় সেটটি নির্দেশ করে যে ব্যবহারকারীকে কখন এবং কীভাবে প্রমাণীকরণ করতে হবে। যদি এই ট্যাগগুলোর কোনোটিই উপস্থিত না থাকে, কিন্তু Tag::USER_SECURE_ID থাকে, তাহলে কী-টির প্রতিটি ব্যবহারের জন্য প্রমাণীকরণ আবশ্যক।

• Tag::NO_AUTHENTICATION_REQUIRED নির্দেশ করে যে ব্যবহারকারীর প্রমাণীকরণের প্রয়োজন নেই, যদিও কী-টির অ্যাক্সেস শুধুমাত্র এর মালিক অ্যাপ (এবং এটি যে অ্যাপগুলোকে অ্যাক্সেস দেয়) এর মধ্যেই সীমাবদ্ধ থাকে।
• Tag::AUTH_TIMEOUT হলো একটি সাংখ্যিক মান, যা সেকেন্ডে নির্দিষ্ট করে যে কী ব্যবহারের অনুমোদন দেওয়ার জন্য ব্যবহারকারীর প্রমাণীকরণ কতটা নতুন হতে হবে। রিবুটের পরেও টাইমআউটের মেয়াদ থাকে না; রিবুটের পর সমস্ত প্রমাণীকরণ বাতিল হয়ে যায়। টাইমআউটের মান বড় করে সেট করা যেতে পারে, যা নির্দেশ করে যে প্রতি বুটে একবার প্রমাণীকরণের প্রয়োজন হবে (২^৩২ সেকেন্ড হলো প্রায় ১৩৬ বছর; ধারণা করা হয় যে অ্যান্ড্রয়েড ডিভাইসগুলো এর চেয়ে বেশিবার রিবুট করা হয়)।

আনলক করা ডিভাইস প্রয়োজন

Tag::UNLOCKED_DEVICE_REQUIRED যুক্ত কী-গুলো শুধুমাত্র ডিভাইসটি আনলক করা থাকলেই ব্যবহারযোগ্য। এর বিস্তারিত ব্যাখ্যার জন্য KeyProtection.Builder#setUnlockedDeviceRequired(boolean) দেখুন।

UNLOCKED_DEVICE_REQUIRED KeyMint দ্বারা নয়, বরং Keystore দ্বারা বলবৎ করা হয়। তবে, Android 12 এবং এর পরবর্তী সংস্করণগুলিতে, ডিভাইস লক থাকা অবস্থায় Keystore ক্রিপ্টোগ্রাফিকভাবে UNLOCKED_DEVICE_REQUIRED কী-গুলিকে সুরক্ষিত রাখে। এর ফলে, বেশিরভাগ ক্ষেত্রে, ডিভাইস লক থাকা অবস্থায় Keystore-এর নিরাপত্তা বিঘ্নিত হলেও এই কী-গুলি ব্যবহার করা যায় না।

এই বিভাগে বর্ণিত সমস্ত ক্রিপ্টোগ্রাফি এবং র‍্যান্ডম নম্বর জেনারেশনে BoringSSL ব্যবহৃত হয়, তবে যেখানে KeyMint ব্যবহারের কথা স্পষ্টভাবে উল্লেখ করা হয়েছে, সেই স্থানগুলো এর ব্যতিক্রম। সমস্ত সিক্রেট অপ্রয়োজনীয় হয়ে যাওয়ার সাথে সাথেই জিরো করে দেওয়া হয়।

আনলক করা ডিভাইসের জন্য সুপার কী প্রয়োজন

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

প্রতিটি ব্যবহারকারীর (প্রোফাইল সহ) UNLOCKED_DEVICE_REQUIRED সাথে যুক্ত দুটি সুপার কী রয়েছে:

• আনলকডডিভাইসরিকোয়ার্ড সিমেট্রিক সুপার কী। এটি একটি AES‑256‑GCM কী। এটি সেইসব UNLOCKED_DEVICE_REQUIRED কী-গুলোকে এনক্রিপ্ট করে, যেগুলো ব্যবহারকারীর জন্য ডিভাইসটি আনলক করার সময় ইম্পোর্ট, জেনারেট বা ব্যবহার করা হয়।
• UnlockedDeviceRequired অ্যাসিমেট্রিক সুপার কী। এটি একটি ECDH P-521 কী পেয়ার। এটি UNLOCKED_DEVICE_REQUIRED কী-গুলোকে এনক্রিপ্ট করে, যেগুলো ব্যবহারকারীর জন্য ডিভাইসটি লক থাকা অবস্থায় ইম্পোর্ট বা জেনারেট করা হয়। আরও বিস্তারিত জানতে, “ডিভাইস লক থাকা অবস্থায় কী সংরক্ষণ” দেখুন।

সুপার কী তৈরি এবং সুরক্ষিত করা

যখন কোনো ব্যবহারকারী তৈরি করা হয়, তখন কীস্টোর ব্যবহারকারীর UnlockedDeviceRequired সুপার কীগুলো তৈরি করে এবং সেগুলোকে ব্যবহারকারীর সিন্থেটিক পাসওয়ার্ড দ্বারা (পরোক্ষভাবে) এনক্রিপ্ট করে তার ডেটাবেসে সংরক্ষণ করে:

1. সিস্টেম সার্ভারটি একটি SP800‑108 KDF ব্যবহার করে ব্যবহারকারীর সিন্থেটিক পাসওয়ার্ড থেকে তার কীস্টোর পাসওয়ার্ডটি নির্ধারণ করে।
2. সিস্টেম সার্ভার ব্যবহারকারীর কীস্টোর পাসওয়ার্ডটি কীস্টোরে প্রেরণ করে।
3. কীস্টোর ব্যবহারকারীর সুপার কী তৈরি করে।
4. ব্যবহারকারীর প্রতিটি সুপার কী-এর জন্য:
   1. কীস্টোর একটি র‍্যান্ডম সল্ট তৈরি করে।
   2. কীস্টোর ব্যবহারকারীর কীস্টোর পাসওয়ার্ড এবং সল্ট থেকে HKDF‑SHA256 ব্যবহার করে একটি AES‑256‑GCM কী তৈরি করে।
   3. কীস্টোর এই AES‑256‑GCM কী ব্যবহার করে সুপার কী-এর গোপন অংশটি এনক্রিপ্ট করে।
   4. কীস্টোর তার ডেটাবেসে এনক্রিপ্টেড সুপার কী এবং এর সল্ট সংরক্ষণ করে। যদি এটি একটি অ্যাসিমেট্রিক কী হয়, তবে কী-টির পাবলিক অংশটিও এনক্রিপ্ট না করে সংরক্ষণ করা হয়।

এই পদ্ধতিটি ব্যবহারকারীর সিন্থেটিক পাসওয়ার্ড জানা থাকলে, যেমন তার সঠিক পিন, প্যাটার্ন বা পাসওয়ার্ড প্রবেশ করালে, এই সুপার কীগুলি ডিক্রিপ্ট করার সুযোগ দেয়।

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

• যদি ব্যবহারকারী শুধুমাত্র পিন, প্যাটার্ন বা পাসওয়ার্ড সক্রিয় করে রাখেন, তাহলে কীস্টোর তার ক্যাশ করা সুপার কী-গুলির গোপন অংশগুলিকে শূন্য করে দেয়। এর ফলে সুপার কী-গুলি শুধুমাত্র ডাটাবেসে থাকা এনক্রিপ্টেড কপির মাধ্যমে পুনরুদ্ধারযোগ্য হয়, যা কেবল পিন, প্যাটার্ন বা পাসওয়ার্ডের সমতুল্য কোনো কিছুর মাধ্যমেই ডিক্রিপ্ট করা যায়।
• যদি ব্যবহারকারীর শুধুমাত্র ক্লাস ৩ ("শক্তিশালী") বায়োমেট্রিক্স থাকে এবং পিন, প্যাটার্ন বা পাসওয়ার্ড সক্রিয় করা থাকে, তাহলে কীস্টোর ব্যবহারকারীর নথিভুক্ত যেকোনো ক্লাস ৩ বায়োমেট্রিক্স (সাধারণত আঙুলের ছাপ) দ্বারা সুপার কী-গুলোকে পুনরুদ্ধারযোগ্য করার ব্যবস্থা করে, যা পিন, প্যাটার্ন বা পাসওয়ার্ডের সমতুল্য একটি বিকল্প হিসেবে কাজ করে। এটি করার জন্য, এটি একটি নতুন AES-256-GCM কী তৈরি করে, সেটি দিয়ে সুপার কী-গুলোর গোপন অংশ এনক্রিপ্ট করে, AES-256-GCM কী-টিকে KeyMint-এ একটি বায়োমেট্রিক-বাউন্ড কী হিসেবে ইম্পোর্ট করে যার জন্য গত ১৫ সেকেন্ডের মধ্যে বায়োমেট্রিক প্রমাণীকরণ সফল হওয়া প্রয়োজন, এবং এই সমস্ত কী-গুলোর প্লেইনটেক্সট কপিগুলোকে জিরো করে দেয়।
• যদি ব্যবহারকারীর ক্লাস ১ ("সুবিধাজনক") বায়োমেট্রিক, ক্লাস ২ ("দুর্বল") বায়োমেট্রিক, বা সক্রিয় আনলক ট্রাস্ট এজেন্ট চালু থাকে, তাহলে কীস্টোর সুপার কীগুলোকে প্লেইনটেক্সটে ক্যাশ করে রাখে। এই ক্ষেত্রে, UNLOCKED_DEVICE_REQUIRED কীগুলোর জন্য ক্রিপ্টোগ্রাফিক নিরাপত্তা প্রদান করা হয় না। ব্যবহারকারীরা এই আনলক পদ্ধতিগুলো চালু না করে এই কম সুরক্ষিত বিকল্প ব্যবস্থাটি এড়াতে পারেন। এই বিভাগগুলোর মধ্যে সবচেয়ে সাধারণ আনলক পদ্ধতিগুলো হলো অনেক ডিভাইসে ফেস আনলক এবং পেয়ার করা স্মার্টওয়াচ দিয়ে আনলক করা।

যখন ব্যবহারকারীর জন্য ডিভাইসটি আনলক করা হয়, তখন Keystore সম্ভব হলে ব্যবহারকারীর UnlockedDeviceRequired সুপার কীগুলো পুনরুদ্ধার করে। পিন, প্যাটার্ন বা পাসওয়ার্ডের সমতুল্য আনলকের ক্ষেত্রে, এটি ডেটাবেসে সংরক্ষিত এই কীগুলোর কপি ডিক্রিপ্ট করে। অন্যথায়, এটি পরীক্ষা করে দেখে যে বায়োমেট্রিক-বাউন্ড কী দিয়ে এনক্রিপ্ট করা এই কীগুলোর কোনো কপি সংরক্ষিত আছে কিনা, এবং যদি থাকে তবে সেটি ডিক্রিপ্ট করার চেষ্টা করে। এটি কেবল তখনই সফল হয়, যদি ব্যবহারকারী গত ১৫ সেকেন্ডের মধ্যে KeyMint (Keystore নয়) দ্বারা বলবৎকৃত ক্লাস ৩ বায়োমেট্রিকের মাধ্যমে সফলভাবে প্রমাণীকরণ করে থাকেন।

ডিভাইস লক থাকা অবস্থায় চাবি সংরক্ষণ করা

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

• এনক্রিপশন (ডিভাইসটি লক থাকা অবস্থায় একটি UNLOCKED_DEVICE_REQUIRED কী ইম্পোর্ট বা জেনারেট করা):
  1. কীস্টোর একটি নতুন ক্ষণস্থায়ী ECDH P-521 কী পেয়ার তৈরি করে।
  2. কীস্টোর এই ক্ষণস্থায়ী কী জোড়ার ব্যক্তিগত কী এবং UnlockedDeviceRequired অপ্রতিসম সুপার কী-এর সর্বজনীন অংশের মধ্যে ECDH কী চুক্তি সম্পাদনের মাধ্যমে একটি শেয়ার্ড সিক্রেট তৈরি করে।
  3. কীস্টোর একটি র‍্যান্ডম সল্ট তৈরি করে।
  4. কীস্টোরটি HKDF‑SHA256 ব্যবহার করে শেয়ার্ড সিক্রেট এবং সল্ট থেকে একটি AES‑256‑GCM কী তৈরি করে।
  5. কীস্টোর এই AES‑256‑GCM কী ব্যবহার করে UNLOCKED_DEVICE_REQUIRED কী-টিকে এনক্রিপ্ট করে।
  6. কীস্টোর তার ডেটাবেসে এনক্রিপ্টেড UNLOCKED_DEVICE_REQUIRED কী, সল্ট এবং ক্ষণস্থায়ী কী জোড়ার পাবলিক অংশটি সংরক্ষণ করে।
• ডিক্রিপশন (ডিভাইসটি আনলক থাকা অবস্থায় তৈরি করা UNLOCKED_DEVICE_REQUIRED কী ব্যবহার করে):
  1. কীস্টোর তার ডেটাবেস থেকে এনক্রিপ্টেড UNLOCKED_DEVICE_REQUIRED কী, সল্ট এবং এফিমিরাল কী পেয়ারের পাবলিক অংশটি লোড করে।
  2. কীস্টোর, এফিমিরাল কী পেয়ারের পাবলিক অংশ এবং আনলকডডিভাইসরিকোয়ার্ড অ্যাসিমেট্রিক সুপার কী-এর প্রাইভেট অংশের মধ্যে ECDH কী অ্যাগ্রিমেন্ট সম্পাদনের মাধ্যমে একটি শেয়ার্ড সিক্রেট তৈরি করে। যেহেতু ডিভাইসটি আনলক করা আছে, তাই প্রাইভেট কী-টি উপলব্ধ থাকে।
  3. কীস্টোর, HKDF-SHA256 ব্যবহার করে শেয়ার্ড সিক্রেট এবং সল্ট থেকে একটি AES-256-GCM কী তৈরি করে। এই AES-256-GCM কী-টি এনক্রিপশনের সময় তৈরি হওয়া কী-টির মতোই।
  4. কীস্টোর AES‑256‑GCM কী ব্যবহার করে UNLOCKED_DEVICE_REQUIRED কী-টি ডিক্রিপ্ট করে।
  5. কীস্টোর UnlockedDeviceRequired সিমেট্রিক সুপার কী ব্যবহার করে UNLOCKED_DEVICE_REQUIRED কী-টিকে পুনরায় এনক্রিপ্ট করে। এটি কী-টির নিরাপত্তা বৈশিষ্ট্যকে প্রভাবিত করে না, তবে এর ফলে পরবর্তীতে এটি আরও দ্রুত অ্যাক্সেস করা যায়।

এই ফিচারটির মাধ্যমে ডিভাইস লক থাকা অবস্থায় অ্যাপগুলো ডেটা সংরক্ষণ করতে পারে, যা শুধুমাত্র ডিভাইসটি আনলক করা হলেই ডিক্রিপ্ট করা যাবে। এটি করার জন্য, অ্যাপগুলোকে নিম্নলিখিত ধাপগুলো অনুসরণ করতে হবে:

1. কীস্টোরের বাইরে একটি AES‑256‑GCM কী তৈরি করুন।
2. AES‑256‑GCM কী ব্যবহার করে ডেটা এনক্রিপ্ট করুন।
3. setUnlockedDeviceRequired(true) কী প্রোটেকশন সেট করে AES‑256‑GCM কী-টি কীস্টোরে ইম্পোর্ট করুন।
4. চাবিটির মূল কপিটি শূন্য করে দিন।

ডিভাইসটি আনলক থাকা অবস্থায় ডেটা ডিক্রিপ্ট করতে, কীস্টোরে ইম্পোর্ট করা কী-টি ব্যবহার করুন।

ক্লায়েন্ট বাইন্ডিং

ক্লায়েন্ট বাইন্ডিং, অর্থাৎ একটি নির্দিষ্ট ক্লায়েন্ট অ্যাপের সাথে একটি কী-এর সংযোগ স্থাপন, একটি ঐচ্ছিক ক্লায়েন্ট আইডি এবং কিছু ঐচ্ছিক ক্লায়েন্ট ডেটার (যথাক্রমে Tag::APPLICATION_ID এবং Tag::APPLICATION_DATA ) মাধ্যমে করা হয়। কীস্টোর এই মানগুলিকে অস্বচ্ছ ব্লব হিসাবে বিবেচনা করে, এবং শুধুমাত্র এটি নিশ্চিত করে যে কী তৈরি/আমদানি করার সময় উপস্থাপিত একই ব্লবগুলি প্রতিটি ব্যবহারের জন্য উপস্থাপিত হয় এবং বাইট-বাই-বাইট অভিন্ন থাকে। ক্লায়েন্ট বাইন্ডিং ডেটা KeyMint দ্বারা ফেরত দেওয়া হয় না। কী ব্যবহার করার জন্য কলারকে অবশ্যই এটি জানতে হবে।

এই ফিচারটি অ্যাপের জন্য উন্মুক্ত নয়।

মেয়াদ শেষ

কীস্টোর তারিখ অনুযায়ী কী-এর ব্যবহার সীমাবদ্ধ করা সমর্থন করে। একটি কী-এর সাথে এর বৈধতার শুরু এবং মেয়াদ শেষ হওয়ার তারিখ যুক্ত করা যেতে পারে এবং বর্তমান তারিখ/সময় বৈধ সীমার বাইরে থাকলে কীমাস্টার কী অপারেশন সম্পাদন করতে অস্বীকার করে। কী-এর বৈধতার সীমা Tag::ACTIVE_DATETIME , Tag::ORIGINATION_EXPIRE_DATETIME , এবং Tag::USAGE_EXPIRE_DATETIME ট্যাগগুলির মাধ্যমে নির্দিষ্ট করা হয়। "অরিজিনেশন" এবং "ইউসেজ"-এর মধ্যে পার্থক্যটি নির্ভর করে কী-টি একটি নতুন সাইফারটেক্সট/সিগনেচার/ইত্যাদি "অরিজিনেট" করতে, নাকি একটি বিদ্যমান সাইফারটেক্সট/সিগনেচার/ইত্যাদি "ব্যবহার" করতে ব্যবহৃত হচ্ছে তার উপর। উল্লেখ্য যে, এই পার্থক্যটি অ্যাপগুলির কাছে প্রকাশ করা হয় না।

Tag::ACTIVE_DATETIME , Tag::ORIGINATION_EXPIRE_DATETIME , এবং Tag::USAGE_EXPIRE_DATETIME ট্যাগগুলো ঐচ্ছিক। যদি ট্যাগগুলো অনুপস্থিত থাকে, তবে ধরে নেওয়া হয় যে প্রশ্নোক্ত কী-টি বার্তা ডিক্রিপ্ট/যাচাই করার জন্য সর্বদা ব্যবহার করা যাবে।

যেহেতু ওয়াল-ক্লক টাইম অসুরক্ষিত জগৎ থেকে সরবরাহ করা হয়, তাই মেয়াদোত্তীর্ণ-সংক্রান্ত ট্যাগগুলো সফটওয়্যার-প্রবর্তিত তালিকায় থাকে।

বিশ্বাসের বন্ধনের মূল

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

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

স্বতন্ত্র চাবি

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

• KeyBlobUsageRequirements::STANDALONE
• KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

এই ফিচারটি অ্যাপের জন্য উন্মুক্ত নয়।

বেগ

এটি তৈরি করার সময়, TAG::MIN_SECONDS_BETWEEN_OPS ব্যবহার করে সর্বোচ্চ ব্যবহারের গতি নির্দিষ্ট করা যেতে পারে। যদি TAG::MIN_SECONDS_BETWEEN_OPS সেকেন্ডেরও কম সময় আগে কোনো অপারেশন করা হয়ে থাকে, তাহলে TrustZone ইমপ্লিমেন্টেশনগুলো সেই কী ব্যবহার করে ক্রিপ্টোগ্রাফিক অপারেশন সম্পাদন করতে অস্বীকার করে।

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

TAG::MAX_USES_PER_BOOT ব্যবহার করে প্রতি বুটে কী-এর ব্যবহার সংখ্যা পর্যন্ত সীমিত করা যায়। এর জন্য একটি ট্র্যাকিং টেবিলেরও প্রয়োজন হয়, যা কমপক্ষে চারটি কী ধারণ করতে পারে এবং ফেইল সেফও বটে। উল্লেখ্য যে, অ্যাপগুলো প্রতি-বুট সীমিত কী তৈরি করতে পারে না। এই ফিচারটি কীস্টোরের মাধ্যমে উপলব্ধ নয় এবং এটি সিস্টেম অপারেশনের জন্য সংরক্ষিত।

এই ফিচারটি অ্যাপের জন্য উন্মুক্ত নয়।

র‍্যান্ডম নম্বর জেনারেটর পুনরায় বীজ বপন

যেহেতু সুরক্ষিত হার্ডওয়্যার কী মেটেরিয়াল এবং ইনিশিয়ালাইজেশন ভেক্টর (IVs)-এর জন্য র‍্যান্ডম সংখ্যা তৈরি করে, এবং হার্ডওয়্যার র‍্যান্ডম সংখ্যা জেনারেটরগুলো সবসময় সম্পূর্ণ নির্ভরযোগ্য নাও হতে পারে, তাই KeyMint HAL একটি ইন্টারফেস প্রদান করে যা ক্লায়েন্টকে অতিরিক্ত এনট্রপি যোগ করার সুযোগ দেয়, এবং এই এনট্রপি উৎপাদিত র‍্যান্ডম সংখ্যাগুলোর সাথে মিশ্রিত করা হয়।

প্রাথমিক সীড উৎস হিসেবে একটি হার্ডওয়্যার র‍্যান্ডম-নম্বর জেনারেটর ব্যবহার করুন। এক্সটার্নাল এপিআই (API)-এর মাধ্যমে সরবরাহ করা সীড ডেটা সংখ্যা তৈরির জন্য ব্যবহৃত র‍্যান্ডমনেসের একমাত্র উৎস হতে পারবে না। অধিকন্তু, ব্যবহৃত মিক্সিং অপারেশনটিকে অবশ্যই নিশ্চিত করতে হবে যে, যদি সীড উৎসগুলোর মধ্যে কোনো একটি অপ্রত্যাশিত হয়, তবে র‍্যান্ডম আউটপুটও যেন অপ্রত্যাশিত হয়।