তাঁতি

অ্যান্ড্রয়েড ৮.১-এ প্রবর্তিত উইভার হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার (HAL) ( IWeaver.aidl ), পিন, প্যাটার্ন এবং পাসওয়ার্ডের মতো লক স্ক্রিন নলেজ ফ্যাক্টর (LSKF) ব্যবহার করে ব্যবহারকারী প্রমাণীকরণের জন্য একটি সুরক্ষিত ইন্টারফেস প্রদান করে।

উইভার, গেটকিপারের LSKF-যাচাইকরণ কার্যকারিতাকে প্রতিস্থাপন করে। তবে, হার্ডওয়্যার প্রমাণীকরণ টোকেন তৈরি করতে গেটকিপার এখনও ব্যবহৃত হয়।

অ্যান্ড্রয়েড ৯ এবং এর পরবর্তী সংস্করণগুলোতে, CDD 9.11.2 অনুযায়ী StrongBox সমর্থনকারী ডিভাইসগুলোকে অবশ্যই ডেডিকেটেড সুরক্ষিত হার্ডওয়্যার সরবরাহ করতে হবে যা সুরক্ষিত ব্যবহারকারী প্রমাণীকরণকে সমর্থন করে। এই সুরক্ষিত হার্ডওয়্যার ব্যবহার করে Weaver HAL বাস্তবায়ন করা হলে "সুরক্ষিত ব্যবহারকারী প্রমাণীকরণ" এর প্রয়োজনীয়তা পূরণ হয়।

যেসব ডিভাইসে ডেডিকেটেড সিকিওর এলিমেন্ট (SE) নেই, সেগুলোতেও ট্রাস্টি-র মতো একটি ট্রাস্টেড এক্সিকিউশন এনভায়রনমেন্ট (TEE)-এ উইভার ইমপ্লিমেন্ট করা যেতে পারে।

উপাদান

উইভার তিনটি উপাদান নিয়ে গঠিত:

  • উইভার এআইডিএল ইন্টারফেস ( IWeaver ) : এইচএএল-এর আনুষ্ঠানিক স্পেসিফিকেশন। অ্যান্ড্রয়েড ১৩ এবং এর পূর্ববর্তী সংস্করণগুলো এআইডিএল-এর পরিবর্তে এইচআইডিএল ব্যবহার করত।
  • উইভার হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার (HAL) সার্ভিস : একটি ভেন্ডর-নির্দিষ্ট অ্যান্ড্রয়েড প্রসেস যা IWeaver ইন্টারফেসটি ইমপ্লিমেন্ট করে।
  • উইভার ট্রাস্টেড অ্যাপ্লিকেশন (TA) : এটি একটি সুরক্ষিত পরিবেশে চলমান মূল লজিক। এটি LSKF ভেরিফিকেশন করে এবং রেট-লিমিটিং প্রয়োগ করে। HAL সার্ভিসটি একটি ইমপ্লিমেন্টেশন-নির্দিষ্ট সুরক্ষিত চ্যানেল ব্যবহার করে TA-এর সাথে যোগাযোগ করে।

ইন্টারফেস

উইভারের ইন্টারফেস স্থায়ী স্লটগুলির একটি নির্দিষ্ট আকারের অ্যারে উপস্থাপন করে, যার প্রতিটিতে একটি নির্দিষ্ট আকারের কী এবং একটি নির্দিষ্ট আকারের ভ্যালু থাকে। প্রতিটি স্লট তার আইডি দ্বারা চিহ্নিত করা হয়, [0, numSlots - 1] ব্যবধির মধ্যে একটি পূর্ণসংখ্যা। একটি স্লটের ভ্যালু কেবল তখনই অ্যাক্সেস করা যায় যখন সংরক্ষিত কী-এর সাথে মেলে এমন একটি কী প্রদান করা হয়।

উইভারের ইন্টারফেসটি নিম্নলিখিত উপাদানগুলো নিয়ে গঠিত:

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

সম্পূর্ণ ইন্টারফেস স্পেসিফিকেশনের জন্য, IWeaver.aidl দেখুন।

অ্যান্ড্রয়েড দ্বারা ব্যবহার করুন

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

  • স্লট কী ( weaverKey ): ব্যবহারকারীর LSKF-এর একটি হ্যাশ। যদি ব্যবহারকারীর স্ক্রিন লক না থাকে, তাহলে একটি ডিফল্ট স্ট্রিং ব্যবহৃত হয়।
  • স্লট মান ( weaverSecret ): একটি উচ্চ-এনট্রপি সম্পন্ন, দৈবচয়নের মাধ্যমে তৈরি ক্রিপ্টোগ্রাফিক গোপন তথ্য।

weaverSecret শুধুমাত্র নিম্নলিখিত যেকোনো একটি উপায়ে পুনরুদ্ধার করার জন্য ডিজাইন করা হয়েছে:

  • উইভার টিএ-এর রেট-লিমিটিং পলিসির আওতায় সঠিক weaverKey প্রদান করা।
  • যে সুরক্ষিত পরিবেশে উইভার টিএ চলে, তা বিঘ্নিত করা। এটি ইচ্ছাকৃতভাবেই খুব কঠিন করে তোলা হয়েছে।

LockSettingsService ব্যবহারকারীর সিন্থেটিক পাসওয়ার্ড এনক্রিপ্ট করতে weaverKey এবং weaverSecret উভয়ই ব্যবহার করে। যেহেতু সিন্থেটিক পাসওয়ার্ডটি ফাইল-ভিত্তিক এনক্রিপশন (FBE)- এর জন্য ব্যবহারকারীর ক্রেডেনশিয়াল-এনক্রিপ্টেড (CE) স্টোরেজ এবং অ্যান্ড্রয়েড কীস্টোরে থাকা ব্যবহারকারীর অথেনটিকেশন-বাউন্ড কী-গুলোকে সুরক্ষিত রাখে, তাই উইভার সিক্রেটটি রিলিজ না করা পর্যন্ত ডেটা অ্যাক্সেস করা যায় না।

তাঁতি বনাম দ্বাররক্ষক

ঐতিহাসিকভাবে, গেটকিপার HAL একটিমাত্র verify() কলে দুটি স্বতন্ত্র ভূমিকা পালন করত:

  1. যাচাইকরণ : TEE-কর্তৃক আরোপিত রেট-লিমিটিং সহ LSKF পরীক্ষা করা হচ্ছে।
  2. প্রত্যয়ন : LSKF প্রমাণীকরণ সফল হয়েছে তা KeyMint-কে (পূর্বে Keymaster) জানানোর জন্য একটি HardwareAuthToken প্রদান করা।

উইভারের দিকে এই পরিবর্তনের কারণ কী?

অ্যান্ড্রয়েড ৮.১-এ সুরক্ষিত পাসকোড রিসেট টোকেন চালু হওয়ার সাথে সাথে, 'সিন্থেটিক পাসওয়ার্ড' প্রধান ক্রিপ্টোগ্রাফিক গোপনীয় বিষয় হয়ে ওঠে। উপরে বর্ণিত দুটি ভূমিকা এখন পৃথক গেটকিপার এনরোলমেন্টের মাধ্যমে পরিচালিত হয়, একটি userId + 100000 এর অধীনে LSKF-এর জন্য এবং অন্যটি userId অধীনে সিন্থেটিক পাসওয়ার্ডের জন্য।

প্রথম ভূমিকাটি গ্রহণ করার জন্য উইভারকে চালু করা হয়েছিল, যা সিকিউর এলিমেন্ট (SE) ভিত্তিক বাস্তবায়নের সমর্থনসহ একটি সরলতর HAL ইন্টারফেস ব্যবহার করে।

বৈশিষ্ট্য তাঁতি দ্বাররক্ষক
নিরাপদ মুছে ফেলা নিরাপদভাবে মুছে ফেলার ব্যবস্থা প্রয়োজন, এবং এটি বাস্তবায়ন করা সহজ কারণ ইন্টারফেসটি নির্দিষ্ট সংখ্যক ও নির্দিষ্ট আকারের স্লট ব্যবহার করে। সুরক্ষিতভাবে মুছে ফেলার প্রয়োজন নেই এবং এটি বাস্তবায়ন করাও কঠিন, কারণ ইন্টারফেসটি অসীম সংখ্যক তালিকাভুক্তি সমর্থন করে।
হার্ডওয়্যার SE-দের জন্য অপ্টিমাইজ করা হলেও, এটি TEE-তেও কাজ করে। কার্যকরভাবে এটি শুধু TEE-এর জন্যই প্রযোজ্য। বর্তমান নকশা অনুযায়ী, একটি SE-তে এটি প্রয়োগ করলে কোনো নিরাপত্তাগত সুবিধা পাওয়া যায় না।
ত্রুটি পরিচালনা আরও স্পষ্ট ত্রুটি কোড অস্পষ্ট ত্রুটি কোড। ফলে, লক স্ক্রিন ভুল LSKF এবং সম্পর্কহীন ব্যর্থতার মধ্যে পার্থক্য করতে পারে না।
পারমাণবিকতা LockSettingsService এর মধ্যে থাকা Weaver ব্যবহারকারী কোডটি LSKF পরিবর্তনগুলো অ্যাটমিকভাবে সম্পাদন করে। নতুন ডেটা একটি নতুন Weaver স্লটে লেখা হয়, এবং পুরোনো স্লটটি কেবল তখনই মুছে ফেলা হয় যখন তা করা নিরাপদ হয়। LockSettingsService এর যে কোডটি Gatekeeper ব্যবহার করে, সেটি LSKF পরিবর্তনগুলো অ্যাটমিকভাবে সম্পাদন করে না। LSKF পরিবর্তনের সময় কোনো সমস্যা হলে ব্যবহারকারীর সমস্ত ডেটা হারিয়ে যেতে পারে।

রেফারেন্স কোড

ISO/IEC7816-4 সামঞ্জস্যপূর্ণ সুরক্ষিত উপাদানগুলিতে উইভার বাস্তবায়নের জন্য রেফারেন্স কোড AOSP: external/libese/ -এ পাওয়া যায়।

পরীক্ষা

একটি উইভার ইমপ্লিমেন্টেশন যাচাই করতে VtsHalWeaverTargetTest ব্যবহার করুন:

atest VtsHalWeaverTargetTest

অথবা:

vts-tradefed run vts -m VtsHalWeaverTargetTest