Authentication

Android-এ ব্যবহারকারী যাচাইকারীর ধারণা আছে যা ডিভাইস আনলক করতে এবং ক্রিপ্টোগ্রাফিক কী-তে অ্যাক্সেস গেট করতে ব্যবহার করা হয়। এতে নিম্নলিখিত কম্পোনেন্ট অন্তর্ভুক্ত:

• ক্রিপটোগ্রাফিক কী স্টোরেজ ও পরিষেবা প্রদানকারী। Android Keystore অ্যাপের জন্য হার্ডওয়্যার-ব্যাকড ক্রিপ্টোগ্রাফিক পরিষেবা প্রদান করে। ফ্রেমওয়ার্ক লেভেলে Android Keystore সিস্টেম keystore2 সিস্টেম পরিষেবার মাধ্যমে ব্যাক-আপ করা হয়। এটি পরিবর্তে একটি অন্তর্নিহিত ভেন্ডর-নির্দিষ্ট KeyMint (আগে Keymaster) প্রয়োগের উপর ভিত্তি করে যা নিশ্চিত করে যে কী মেটেরিয়াল শুধুমাত্র হার্ডওয়্যার-ব্যাকড সুরক্ষিত পরিবেশে অ্যাক্সেসযোগ্য, যেমন একটি বিশ্বস্ত এক্সিকিউশন এনভায়রনমেন্ট (TEE) বা একটি নিরাপদ উপাদান (SE), যেমন StrongBox।
• ব্যবহারকারীর যাচাইকরণ। ব্যবহারকারীর সফল যাচাইকরণ অ্যাটেস্ট করুন। Android-এ নিম্নলিখিত যাচাইকরণ কম্পোনেন্ট কাজ করে:
  • TEE-তে পিন, প্যাটার্ন বা পাসওয়ার্ড যাচাইকরণের জন্য Gatekeeper।
  • (ঐচ্ছিক) নিরাপদ উপাদানে পিন, প্যাটার্ন বা পাসওয়ার্ড যাচাইকরণের জন্য Weaver।
  • ফিঙ্গারপ্রিন্ট যাচাইকরণের জন্য ফিঙ্গারপ্রিন্ট।
  • অন্যান্য বায়োমেট্রিক যাচাইকরণ পদ্ধতি। Android 9 বা তার পরবর্তী যেকোনও ভার্সন সহ শিপ করা ডিভাইস ফিঙ্গারপ্রিন্ট ও অতিরিক্ত বায়োমেট্রিক্সের জন্য একক ইন্টিগ্রেশন পয়েন্ট হিসেবে BiometricPrompt ব্যবহার করতে পারে।
  এইসব কম্পোনেন্ট হার্ডওয়্যার-ব্যাকড যাচাইকরণ টোকেন (AuthTokens) ব্যবহার করে keystore2 পরিষেবার সাথে তাদের যাচাইকরণ স্ট্যাটাস কমিউনিকেট করে।

এইসব কম্পোনেন্টের প্রতিটি ভেন্ডর-নির্দিষ্ট, তবে ভেন্ডর ইমপ্লিমেন্টেশনকে হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার (HAL) ইন্টারফেস স্পেসিফিকেশন পূরণ করতে হবে এবং সংশ্লিষ্ট ভেন্ডর টেস্ট স্যুট (VTS) টেস্টে পাস করতে হবে।

ভেন্ডর ইমপ্লিমেন্টেশন সাধারণত দুটি ভাগে বিভক্ত, যা ভেন্ডর-নির্দিষ্ট কমিউনিকেশন মেকানিজমের মাধ্যমে কানেক্ট করা থাকে :

• HAL পরিষেবা Android সিস্টেম প্রসেস হিসেবে চলে, যা Android সিস্টেম থেকে বাইন্ডার অনুরোধ গ্রহণ করে।
• একটি বিশ্বস্ত অ্যাপ্লিকেশন (TA) নিরাপদ পরিবেশে চলে, প্রকৃত নিরাপদ অপারেশন সম্পাদন করে।

এনরোল করার প্রসেস

ফ্যাক্টরি রিসেটের পরে ডিভাইস প্রথমবার বুট করার সময়, ব্যবহারকারীর থেকে ক্রেডেনশিয়াল এনরোলমেন্ট পাওয়ার জন্য সব যাচাইকারী প্রস্তুত থাকে। ব্যবহারকারীকে প্রথমে Gatekeeper (বা উপলভ্য থাকলে Weaver)-এর মাধ্যমে পিন, প্যাটার্ন বা পাসওয়ার্ড এনরোল করতে হবে। এই প্রাথমিক এনরোলমেন্ট একটি র‍্যান্ডমভাবে জেনারেট করা, ৬৪-বিট ব্যবহারকারীর সুরক্ষিত শনাক্তকারী (SID) তৈরি করে যা ব্যবহারকারীর জন্য একটি শনাক্তকারী এবং ব্যবহারকারীর ক্রিপ্টোগ্রাফিক মেটেরিয়ালের জন্য একটি বাইন্ডিং টোকেন হিসেবে কাজ করে। এই ব্যবহারকারীর SID ক্রিপ্টোগ্রাফিকভাবে ব্যবহারকারীর পাসওয়ার্ডের সাথে যুক্ত; Gatekeeper-এ সফলভাবে যাচাইকরণের ফলে AuthTokens পাওয়া যায় যার মধ্যে সেই পাসওয়ার্ডের জন্য ব্যবহারকারীর SID থাকে।

যে ব্যবহারকারী আগে থেকে থাকা ক্রেডেনশিয়াল পরিবর্তন করতে চান তাকে সেই ক্রেডেনশিয়াল উপস্থাপন করতে হবে। আগে থেকে থাকা ক্রেডেনশিয়াল সফলভাবে যাচাই করা হলে, আগে থেকে থাকা ক্রেডেনশিয়ালের সাথে সম্পর্কিত ব্যবহারকারীর SID নতুন ক্রেডেনশিয়ালে ট্রান্সফার করা হয়, যার ফলে ক্রেডেনশিয়াল পরিবর্তন করার পরেও ব্যবহারকারী অ্যাক্সেস কী ব্যবহার করা চালিয়ে যেতে পারেন।

কিছু পরিস্থিতিতে, ডিভাইস অ্যাডমিনিস্ট্রেটর আগে থেকে থাকা ক্রেডেনশিয়াল না দেখিয়েই নতুন ক্রেডেনশিয়াল এনরোল করার জন্য অবিশ্বস্ত এনরোল করতে পারেন। এটি ব্যবহারকারীকে ডিভাইস অ্যাক্সেস করার অনুমতি দেয়, তবে পুরানো ব্যবহারকারীর SID-এর অধীনে তৈরি করা কীগুলি স্থায়ীভাবে হারিয়ে যায়।

যাচাইকরণ

এই বিভাগে একটি সাধারণ যাচাইকরণ ফ্লো বর্ণনা করা হয়েছে, যার মধ্যে Android এবং সুরক্ষিত পরিবেশ, উভয় ক্ষেত্রেই একাধিক উপাদানের মধ্যে ইন্টার‍্যাকশন অন্তর্ভুক্ত। মনে রাখবেন যে সব সুরক্ষিত কম্পোনেন্ট একটি (প্রতি-বুট) গোপন HMAC কী শেয়ার করে যা তারা একে অপরের মেসেজ যাচাই করার জন্য ব্যবহার করে।

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

ছবি ১. যাচাইকরণ ফ্লো

1. ব্যবহারকারী যাচাইকরণ পদ্ধতি প্রদান করেন এবং সংশ্লিষ্ট পরিষেবা HAL পরিষেবার কাছে অনুরোধ করে।
   • পিন, প্যাটার্ন বা পাসওয়ার্ডের জন্য, LockSettingsService gatekeeperd-এর কাছে অনুরোধ করে।
   • বায়োমেট্রিক্স-ভিত্তিক যাচাইকরণ ফ্লো Android ভার্সনের উপর নির্ভর করে। Android 8.x এবং তার আগের ভার্সনে চলা ডিভাইসে, FingerprintService fingerprintd-এ অনুরোধ করে)। Android 9 এবং তার পরের ভার্সনে চলা ডিভাইসে, BiometricPrompt উপযুক্ত BiometricManager ক্লাস, যেমন FingerprintManager বা FaceManager ব্যবহার করে উপযুক্ত বায়োমেট্রিক ডেমনকে (যেমন, ফিঙ্গারপ্রিন্টের জন্য fingerprintd বা ফেসের জন্য faced) অনুরোধ করে। ভার্সন যাই হোক না কেন, অনুরোধ পাঠানোর পরে অ্যাসিঙ্ক্রোনাসভাবে বায়োমেট্রিক যাচাইকরণ করা হয়।
2. HAL পরিষেবা তার সমকক্ষ TA-তে ডেটা পাঠায়, যা একটি AuthToken তৈরি করে:
   • পিন/প্যাটার্ন/পাসওয়ার্ড যাচাইকরণের জন্য, gatekeeperd পিন, প্যাটার্ন বা পাসওয়ার্ড হ্যাশ, Gatekeeper HAL পরিষেবার মাধ্যমে, TEE-তে Gatekeeper TA-তে পাঠায়। TEE-তে যাচাইকরণ সফল হলে, Gatekeeper TA সংশ্লিষ্ট ব্যবহারকারীর SID (শেয়ার করা HMAC কী দিয়ে সাইন করা) সহ AuthToken ইস্যু করে।
   • ফিঙ্গারপ্রিন্ট যাচাইকরণের জন্য, fingerprintd ফিঙ্গারপ্রিন্ট ইভেন্ট শোনে এবং ফিঙ্গারপ্রিন্ট HAL-এর মাধ্যমে TEE-তে ফিঙ্গারপ্রিন্ট TA-তে ডেটা পাঠায়। TEE-তে যাচাইকরণ সফল হলে, ফিঙ্গারপ্রিন্ট TA একটি AuthToken (AuthToken HMAC কী দিয়ে সাইন করা) নির্গত করে।
   • অন্যান্য বায়োমেট্রিক যাচাইকরণের জন্য, উপযুক্ত বায়োমেট্রিক ডেমন বায়োমেট্রিক ইভেন্ট শোনে এবং উপযুক্ত বায়োমেট্রিক HAL পরিষেবা ও TA-তে পাঠায়।
3. ফলাফল হিসেবে পাওয়া স্বাক্ষরিত AuthToken, Binder ইন্টারফেসের মাধ্যমে keystore2 সিস্টেম সার্ভিসে পাস করা হয়।
4. keystore2 পরিষেবাটি ক্রিপ্টোগ্রাফিক অপারেশন পারফর্ম করার জন্য KeyMint (আগে Keymaster)-এর কাছে অনুরোধ করতে AuthTokens অ্যাটাচ করে। KeyMint HAL পরিষেবা সেগুলিকে KeyMint TA-তে পাস করে, যা Gatekeeper এবং কাজ করে এমন বায়োমেট্রিক TEE কম্পোনেন্টের সাথে শেয়ার করা HMAC 'কী' ব্যবহার করে সেগুলি যাচাই করে। KeyMint টোকেনে থাকা টাইমস্ট্যাম্পকে শেষ যাচাইকরণের সময় হিসেবে বিশ্বাস করে, টাইমস্ট্যাম্পের উপর ভিত্তি করে কী ব্যবহার করার অনুমতি দেওয়া হবে কিনা তা সিদ্ধান্ত নেয়।

যাচাইকরণ ফ্লোতে সুরক্ষিত পরিবেশে TA-এর মধ্যে সরাসরি যোগাযোগের প্রয়োজন হয় না: AuthTokens, যাচাইকারী TA থেকে Android-এর keystore2 পরিষেবায় যায়, যা পরে KeyMint TA-তে পাঠানো হয়। এছাড়াও, এটি keystore2 পরিষেবাকে সেইসব অনুরোধ দ্রুত বাতিল করার অনুমতি দেয় যেগুলি ব্যর্থ হতে বাধ্য, কারণ সিস্টেমে উপলভ্য AuthToken সম্পর্কে এটির কাছে তথ্য থাকে, যার ফলে TEE-তে সম্ভাব্য ব্যয়বহুল IPC-কে সেভ করে।

AuthToken ফর্ম্যাট

AuthToken-এর ফর্ম্যাট AIDL স্পেসিফিকেশন দ্বারা HardwareAuthToken.aidl-এ দেওয়া হয়।

ডিভাইস বুট ফ্লো

ডিভাইস বুট করার সময় AuthToken HMAC কী তৈরি করতে হবে এবং সব TEE কম্পোনেন্টের (Gatekeeper, KeyMint এবং কাজ করে এমন বায়োমেট্রিক্স TA) সাথে শেয়ার করতে হবে। রিপ্লে অ্যাটাক প্রতিরোধ করতে, ডিভাইস রিবুট করার সময় প্রতিবার HMAC কী র‍্যান্ডমভাবে জেনারেট করতে হবে।

TA সাধারণত দুটি উপায়ে এই শেয়ার করা HMAC কী অ্যাক্সেস করতে পারে:

• শেয়ার্ড সিক্রেট এগ্রিমেন্ট: ডিভাইস চালু হওয়ার সময় keystore2 পরিষেবা মাল্টি-ওয়ে কী এগ্রিমেন্ট প্রোটোকল পারফর্ম করে, যার ফলে অংশগ্রহণকারী TA-এর মধ্যে HMAC কী-এর সুরক্ষিত ডেরিভেশন সম্ভব হয়। তবে, অংশগ্রহণকারী TA-এর কাছে অবশ্যই একটি সাধারণ প্রি-শেয়ার্ড সিক্রেটের অ্যাক্সেস থাকতে হবে।
• সরাসরি অ্যাক্সেস: একই নিরাপদ এনভায়রনমেন্টে থাকা TA, HMAC কী শেয়ার করার জন্য ইন্টারনাল ইন্টারপ্রসেস কমিউনিকেশন মেকানিজম (যা প্ল্যাটফর্মের উপর নির্ভর করে) ব্যবহার করতে পারে।

যেকোনও ক্ষেত্রেই, HMAC কী কখনও TEE-এর বাইরে উপলভ্য করা যাবে না।

Trusty অপারেটিং সিস্টেম, যা Android-এর পাশাপাশি চলে, সেটি হল TEE-এর একটি উদাহরণ, তবে এর পরিবর্তে অন্য TEE ব্যবহার করা যেতে পারে। KeyMint এবং Gatekeeper বা উপযুক্ত বায়োমেট্রিক TA-এর মধ্যে সরাসরি যোগাযোগ করতে Trusty একটি ইন্টার্নাল IPC সিস্টেম ব্যবহার করে। HMAC কী শুধুমাত্র KeyMint-এ রাখা হয়; ফিঙ্গারপ্রিন্ট ও গেটকিপার প্রতিটি ব্যবহারের জন্য KeyMint-এর থেকে কী-এর অনুরোধ করে এবং ভ্যালু সেভ বা ক্যাশে করে রাখে না।

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