গেটকিপার

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

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

স্থাপত্যশিল্প

Gatekeeper-এ তিনটি প্রধান কম্পোনেন্ট আছে:

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

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

ছবি ১. GateKeeper-এর মাধ্যমে যাচাইকরণের জন্য হাই-লেভেল ডেটা ফ্লো।

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

HAL প্রয়োগ করা

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

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

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

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

Trusty এবং অন্যান্য ইমপ্লিমেন্টেশন

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

Trusty একটি ইন্টার্নাল IPC সিস্টেম ব্যবহার করে সরাসরি KeyMint (আগে Keymaster) এবং Gatekeeper-এর Trusty ইমপ্লিমেন্টেশনের (Trusty Gatekeeper) মধ্যে শেয়ার্ড সিক্রেট কমিউনিকেট করে। পাসওয়ার্ড যাচাইকরণের অ্যাটেস্টেশন প্রদান করার জন্য Keystore-এ পাঠানো যাচাইকরণ টোকেন সাইন করার জন্য এই শেয়ার্ড সিক্রেট ব্যবহার করা হয়। Trusty Gatekeeper প্রতিবার ব্যবহারের জন্য KeyMint থেকে 'কী'র অনুরোধ করে এবং ভ্যালু সেভ বা ক্যাশে করে রাখে না। নিরাপত্তা বিঘ্নিত না করে যেকোনও উপায়ে এই গোপন কোড শেয়ার করার জন্য ইমপ্লিমেন্টেশন মুক্ত।

পাসওয়ার্ড এনরোল ও যাচাই করার জন্য ব্যবহৃত HMAC কী Gatekeeper-এ তৈরি ও সেভ করা হয়।

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

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

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

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

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

পাসওয়ার্ড এনরোল করার সময় পাসওয়ার্ড হ্যান্ডেলে পাসওয়ার্ডের সাথে HMAC যাচাইকরণে ব্যবহারকারীর SID অন্তর্ভুক্ত করা হয়।

ব্যবহারকারীর SID, verify() ফাংশনের মাধ্যমে ফেরত পাঠানো HardwareAuthToken-এ অন্তর্ভুক্ত থাকে এবং সব যাচাইকরণ-বাউন্ড Keystore কী-এর সাথে যুক্ত থাকে (HardwareAuthToken ফর্ম্যাট ও Keystore সম্পর্কে আরও জানতে, যাচাইকরণ দেখুন)।

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

থ্রটলিংয়ের অনুরোধ জানান

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

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

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