দারোয়ান

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

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

স্থাপত্য

গেটকিপারে তিনটি প্রধান উপাদান রয়েছে:

• gatekeeperd (গেটকিপার ডেমন) — অ্যান্ড্রয়েডের একটি C++ বাইন্ডার সার্ভিস, যা IGateKeeperService AIDL ইন্টারফেস বাস্তবায়নকারী প্ল্যাটফর্ম-নিরপেক্ষ লজিক ধারণ করে এবং এটি IGatekeeper এর একটি অন্তর্নিহিত বিক্রেতা-নির্দিষ্ট বাস্তবায়নের উপর ভিত্তি করে তৈরি।
• গেটকিপার হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার (HAL) সার্ভিস — এটি IGatekeeper AIDL ইন্টারফেসের একটি ভেন্ডর-নির্দিষ্ট বাস্তবায়ন। এই HAL সার্ভিসটি অ্যান্ড্রয়েডে চলে, কিন্তু গেটকিপারের মূল কার্যকারিতা একটি সুরক্ষিত পরিবেশে চলার প্রয়োজন হয়, তাই এটি সাধারণত গেটকিপার TA-এর সাথে যোগাযোগ করে।
• গেটকিপার ট্রাস্টেড অ্যাপ্লিকেশন (TA) — এটি ভেন্ডর-নির্দিষ্ট একটি ইমপ্লিমেন্টেশন যা TEE-তে চলে এবং প্রকৃত পাসওয়ার্ড বা প্যাটার্ন যাচাইকরণের কাজটি সম্পাদন করে।

LockSettingsService (Binder-এর মাধ্যমে) একটি অনুরোধ পাঠায় যা Android OS-এর gatekeeperd ডেমন-এর কাছে পৌঁছায়। এরপর gatekeeperd ডেমনটি IGatekeeper HAL সার্ভিসের কাছে একটি অনুরোধ পাঠায়, এবং সেটি আবার TEE-তে থাকা এর প্রতিরূপ Gatekeeper TA-এর কাছে পৌঁছায়।

চিত্র ১. গেটকিপার কর্তৃক প্রমাণীকরণের উচ্চ-স্তরের ডেটা প্রবাহ।

gatekeeperd ডেমনটি অ্যান্ড্রয়েড ফ্রেমওয়ার্ক API-কে HAL-এ অ্যাক্সেস দেয় এবং Keystore-এ ডিভাইসের প্রমাণীকরণ রিপোর্ট করার কাজে অংশগ্রহণ করে। gatekeeperd ডেমনটি তার নিজস্ব প্রসেসে চলে এবং এটি সিস্টেম সার্ভার থেকে পৃথক।

HAL বাস্তবায়ন

gatekeeperd ডেমনটি পাসওয়ার্ড প্রমাণীকরণের জন্য অন্তর্নিহিত Gatekeeper TA-এর সাথে যোগাযোগ করতে IGatekeeper HAL ব্যবহার করে। Gatekeeper TA ইমপ্লিমেন্টেশনকে অবশ্যই ব্লব সাইন (এনরোল) এবং ভেরিফাই করতে সক্ষম হতে হবে। প্রতিটি সফল পাসওয়ার্ড যাচাইকরণের পর তৈরি হওয়া প্রমাণীকরণ টোকেনের ( HardwareAuthToken ) জন্য সমস্ত ইমপ্লিমেন্টেশনকে স্ট্যান্ডার্ড ফরম্যাট মেনে চলতে হবে বলে আশা করা হয়। HardwareAuthToken এর বিষয়বস্তু এবং অর্থ সম্পর্কে বিস্তারিত জানতে, HardwareAuthToken.aidl ডেফিনিশনটি দেখুন।

IGatekeeper HAL-এর ভেন্ডর ইমপ্লিমেন্টেশনগুলিতে অবশ্যই enroll এবং verify ফাংশনগুলি ইমপ্লিমেন্ট করতে হবে:

• enroll মেথডটি একটি পাসওয়ার্ড ব্লব গ্রহণ করে, সেটিকে স্বাক্ষর করে এবং সেই স্বাক্ষরটিকে একটি হ্যান্ডেল হিসেবে ফেরত দেয়। enroll কল থেকে ফেরত আসা ব্লবটির গঠন অবশ্যই system/gatekeeper/include/gatekeeper/password_handle.h ফাইলে দেখানো কাঠামোর মতো হতে হবে।
• verify ফাংশনটিকে অবশ্যই প্রদত্ত পাসওয়ার্ড দ্বারা উৎপাদিত স্বাক্ষরটি তুলনা করতে হবে এবং নিশ্চিত করতে হবে যে এটি নথিভুক্ত পাসওয়ার্ড হ্যান্ডেলের সাথে মেলে।

নথিভুক্তি ও যাচাই করার জন্য ব্যবহৃত কী-টি কখনোই পরিবর্তন করা যাবে না এবং প্রতিবার ডিভাইস বুট করার সময় তা পুনরায় ব্যবহারযোগ্য হতে হবে।

ট্রাস্টি এবং অন্যান্য বাস্তবায়ন

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

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

পাসওয়ার্ড নথিভুক্ত ও যাচাই করার জন্য ব্যবহৃত HMAC কী-টি শুধুমাত্র গেটকিপার-এর মধ্যেই তৈরি ও সংরক্ষণ করা হয়।

অ্যান্ড্রয়েড একটি জেনেরিক C++ গেটকিপার ইমপ্লিমেন্টেশন প্রদান করে, যা সম্পূর্ণ করার জন্য শুধুমাত্র ডিভাইস-নির্দিষ্ট রুটিন যোগ করার প্রয়োজন হয়; ট্রাস্টি ইমপ্লিমেন্টেশনটি এর উপর ভিত্তি করে তৈরি। আপনার TEE-এর জন্য ডিভাইস-নির্দিষ্ট কোড সহ একটি TEE গেটকিপার ইমপ্লিমেন্ট করতে, system/gatekeeper/include/gatekeeper/gatekeeper.h এ থাকা ফাংশন এবং কমেন্টগুলো দেখুন। একটি কমপ্লায়েন্ট ইমপ্লিমেন্টেশনের প্রধান দায়িত্বগুলোর মধ্যে রয়েছে:

• IGatekeeper HAL) মেনে চলা।
• ফেরত আসা প্রমাণীকরণ টোকেন অবশ্যই HardwareAuthToken স্পেসিফিকেশন (যা প্রমাণীকরণ অংশে বর্ণিত আছে) অনুযায়ী ফরম্যাট করা হতে হবে।
• TEE গেটকিপারকে অবশ্যই KeyMint-এর সাথে একটি HMAC কী শেয়ার করতে সক্ষম হতে হবে, হয় চাহিদা অনুযায়ী একটি TEE IPC-এর মাধ্যমে কী-টির অনুরোধ করে অথবা সব সময় ভ্যালুটির একটি বৈধ ক্যাশে বজায় রেখে।

ব্যবহারকারীর সুরক্ষিত আইডি (এসআইডি)

ব্যবহারকারীর SID হলো একজন ব্যবহারকারীর TEE উপস্থাপনা (যার সাথে অ্যান্ড্রয়েড ইউজার আইডির কোনো দৃঢ় সংযোগ নেই)। যখন কোনো ব্যবহারকারী পূর্বের পাসওয়ার্ড না দিয়ে একটি নতুন পাসওয়ার্ড নথিভুক্ত করেন, তখন একটি ক্রিপ্টোগ্রাফিক সিউডোর‍্যান্ডম নম্বর জেনারেটর (PRNG) ব্যবহার করে SID-টি তৈরি করা হয়। এটিকে একটি অবিশ্বস্ত পুনঃনথিভুক্তি (untrusted re-enroll) বলা হয় এবং এটি সাধারণত তখনই ঘটে যখন কোনো ব্যবহারকারী প্রথমবারের মতো একটি পাসওয়ার্ড বা প্যাটার্ন সেট করেন।

যখন কোনো ব্যবহারকারী একটি বৈধ, পূর্ববর্তী পাসওয়ার্ড প্রদান করেন, যেমন পাসওয়ার্ড পরিবর্তনের সময়, তখন একটি বিশ্বস্ত পুনঃ-নথিভুক্তি ঘটে। এই ক্ষেত্রে, ব্যবহারকারীর SID-টি নতুন পাসওয়ার্ড হ্যান্ডেলে স্থানান্তরিত করা হয় এবং এর সাথে সংযুক্ত কী-গুলো সংরক্ষিত থাকে।

পাসওয়ার্ড নথিভুক্ত করার সময়, পাসওয়ার্ড হ্যান্ডেলে পাসওয়ার্ডের সাথে ব্যবহারকারীর SID-টিও HMAC প্রমাণীকরণে অন্তর্ভুক্ত করা হয়।

verify() ফাংশন দ্বারা ফেরত দেওয়া HardwareAuthToken এ ব্যবহারকারীর SID-গুলি অন্তর্ভুক্ত থাকে এবং সমস্ত প্রমাণীকরণ-সংযুক্ত Keystore কী-গুলির সাথে যুক্ত থাকে ( HardwareAuthToken ফরম্যাট এবং Keystore সম্পর্কে বিস্তারিত জানতে, Authentication দেখুন)।

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

থ্রটলিং অনুরোধ

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

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

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