এপিকে স্বাক্ষর স্কিম v3.2

অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭)-এর মাধ্যমে এপিকে সিগনেচার স্কিম ভি৩.২ চালু করা হয়েছে, যা অ্যান্ড্রয়েড ইকোসিস্টেমের পোস্ট-কোয়ান্টাম ক্রিপ্টোগ্রাফি (পিকিউসি)-তে রূপান্তরকে সমর্থন করার জন্য ডিজাইন করা একটি হাইব্রিড সিগনেচার স্কিম।

যেহেতু ইন্ডাস্ট্রি ব্যাপকভাবে PQC অ্যালগরিদম ব্যবহার করছে, তাই v3.2 স্কিমটি একটি গভীর সুরক্ষা প্রদান করে। এর জন্য আপনাকে RSA বা ECDSA-এর মতো একটি ক্লাসিক্যাল অ্যালগরিদম এবং একটি PQC অ্যালগরিদম উভয় দিয়েই APK সাইন করতে হবে। এই হাইব্রিড পদ্ধতিটি আপনার APK-কে সুরক্ষিত রাখতে ক্লাসিক্যাল ক্রিপ্টোগ্রাফি ব্যবহার করে এবং একই সাথে কোয়ান্টাম কম্পিউটারের হুমকি থেকেও রক্ষা করে।

উদ্দেশ্য এবং বিবরণ

v3.2 স্কিমটি একটি স্ট্যান্ডার্ড, ইন্ডাস্ট্রি-সম্মত রূপান্তরকালীন ব্যবস্থা হিসেবে কাজ করে। এই হাইব্রিড পদ্ধতির মাধ্যমে, আপনি PQC-এর কোয়ান্টাম-প্রতিরোধী সুবিধাগুলো লাভ করেন এবং একই সাথে ক্লাসিক্যাল সিগনেচার অ্যালগরিদমগুলোর প্রমাণিত নিরাপত্তার উপরও নির্ভর করতে পারেন। যখন নতুন স্ট্যান্ডার্ডাইজড PQC অ্যালগরিদমগুলো বৃহৎ পরিসরে কার্যক্ষম পরিপক্কতা অর্জন করবে, তখন আপনি এই হাইব্রিড কনফিগারেশন থেকে একটি একক PQC সাইনিং কী-তে স্থানান্তরিত হতে পারবেন। v3.2 সিগনেচার স্কিমের জন্য প্ল্যাটফর্ম সাপোর্ট Android 17 থেকে শুরু হয়। এর চেয়ে নিম্ন স্তরের Android সংস্করণগুলো v3.2 ব্লকটি এড়িয়ে যায় এবং সিগনেচার যাচাইয়ের জন্য পূর্ববর্তী স্কিমগুলো ব্যবহার করে।

এই রূপান্তরকালে নিরাপত্তা বজায় রাখতে এবং ডাউনগ্রেড আক্রমণ প্রতিরোধ করতে, v3.2 স্কিমটি নিম্নলিখিত আচরণবিধি প্রয়োগ করে:

• নতুন কী উপাদান: হাইব্রিড ব্লকে স্থানান্তরের জন্য নতুন ক্লাসিক্যাল এবং PQC কী তৈরি করতে হবে। হাইব্রিড এবং নন-হাইব্রিড কনফিগারেশনের মধ্যে কী উপাদান পুনরায় ব্যবহার করবেন না।
• অন্তর্নিহিত রোটেশন: প্ল্যাটফর্মটি হাইব্রিড ব্লকটিকে একটি অন্তর্নিহিত কী রোটেশন হিসেবে বিবেচনা করে। প্ল্যাটফর্মটি নতুন ক্লাসিক্যাল কী-টিকে অ্যাপের বিদ্যমান সাইনিং লিনিয়েজে শেষের আগের কী হিসেবে যুক্ত করে এবং নতুন PQC কী-টিকে অ্যাপের বর্তমান সাইনিং আইডেন্টিটি হিসেবে গণ্য করে।
• একই উৎস: অন্তর্নিহিত রোটেশন সফলভাবে কার্যকর করার জন্য, হাইব্রিড ব্লকের মধ্যে থাকা নতুন ক্লাসিক্যাল কী এবং নতুন PQC কী উভয়েরই সাইনিং উৎস একই হতে হবে। উভয় নতুন হাইব্রিড সাইনারের জন্য আপনাকে অ্যাপটির বিদ্যমান সাইনিং হিস্ট্রি—সেটি একটি একক মূল কী হোক বা পূর্বে রোটেশন করা কী-গুলোর একটি উৎস হোক—নকল করতে হবে। প্ল্যাটফর্মটি এই একই উৎস ব্যবহার করে যাচাই করে যে, অ্যাপটিকে হাইব্রিড স্কিমে রূপান্তরকারী সত্তাটিই অ্যাপটির বর্তমান সাইনিং আইডেন্টিটির বৈধ মালিক।
• PQC একক-স্বাক্ষরকারীর সীমাবদ্ধতা: PQC-এর প্রাথমিক প্রচলনের সময়, অ্যান্ড্রয়েড স্পষ্টভাবে PQC অ্যালগরিদমের ব্যবহারকে v3.2 হাইব্রিড ব্লকে সীমাবদ্ধ করে। প্ল্যাটফর্মটি v2, v3.0, বা v3.1-এর মতো পূর্ববর্তী স্বাক্ষর স্কিম ব্যবহার করে কোনো একক-স্বাক্ষরকারী PQC কনফিগারেশন যাচাই করে না।
• প্রত্যাবর্তন: যখন একটি v3.2 হাইব্রিড ব্লক থেকে একটি সিঙ্গেল-সাইনার ব্লকে—ভবিষ্যৎ রিলিজে সমর্থিত হলে ক্লাসিক্যাল সাইনার বা PQC সাইনার—পুনরায় রূপান্তর করা হয়, তখন প্ল্যাটফর্মটি যাচাই করে যে হাইব্রিড ব্লকের ক্লাসিক্যাল এবং PQC উভয় কী-ই নতুন সাইনিং লিনিয়েজে উপস্থিত আছে এবং নতুন সিঙ্গেল সাইনারকে সত্যায়ন করছে।

রূপান্তরের জন্য সর্বোত্তম অনুশীলন

অ্যান্ড্রয়েডের নিম্নতর সংস্করণগুলির সাথে সামঞ্জস্য বজায় রাখতে এবং PQC সাইনিং-এ রূপান্তরের সময় একটি নিরাপদ আপগ্রেড পথ প্রদান করতে, APK-গুলিতে অবশ্যই একটি একক ক্লাসিক্যাল কী দ্বারা স্বাক্ষরিত একটি স্ট্যান্ডার্ড v3.0 বা v3.1 সিগনেচার ব্লক অন্তর্ভুক্ত থাকতে হবে। যেহেতু শুধুমাত্র অ্যান্ড্রয়েড ১৭ (API লেভেল ৩৭) এবং তার উপরের সংস্করণগুলি v3.2 হাইব্রিড স্কিম সমর্থন করে, তাই এই শর্তটি নিম্নতর সংস্করণ চালিত ডিভাইসগুলিকে অ্যাপটি যাচাই এবং ইনস্টল করার সুযোগ দেয়।

ক্লাসিক্যাল ফলব্যাক কনফিগারেশন

PQC রূপান্তরের সময় একটি কার্যক্ষম সুরক্ষা ব্যবস্থা প্রদানের জন্য, একটি ক্লাসিক্যাল ফলব্যাক কনফিগারেশন প্রয়োগ করুন।

• বিদ্যমান অ্যাপসমূহ: অ্যাপটির বর্তমানে প্রতিষ্ঠিত সাইনিং কী, K0, এই ফলব্যাকের স্বাভাবিক ভিত্তি হিসেবে কাজ করে।
• নতুন অ্যাপ: প্রাথমিক পরিচয় স্থাপনের জন্য নতুন হাইব্রিড কী, C_K1 এবং PQC_K1-এর পাশাপাশি একটি বেসলাইন ক্লাসিক্যাল সাইনিং কী, K0, তৈরি করুন।

উভয় ক্ষেত্রেই, APK-টিতে অবশ্যই ক্লাসিক্যাল কী, K0 দ্বারা স্বাক্ষরিত একটি স্ট্যান্ডার্ড v3.0 বা v3.1 সিগনেচার ব্লকের পাশাপাশি নতুন হাইব্রিড কী, C_K1 এবং PQC_K1 দ্বারা স্বাক্ষরিত v3.2 হাইব্রিড ব্লক অন্তর্ভুক্ত থাকতে হবে।

v3.2 স্কিমের প্রাথমিক ডেপ্লয়মেন্টের সময়, হাইব্রিড ব্লকের সাইনিং লিনিয়েজকে K0-কে ROLLBACK ক্যাপাবিলিটি প্রদান করতে হবে। ডেপ্লয়মেন্টে কোনো সমস্যা দেখা দিলে, এই ক্যাপাবিলিটি ব্যবহারকারীর আপডেটে কোনো ব্যাঘাত না ঘটিয়ে অ্যাপটিকে একটি ক্লাসিক্যাল সিগনেচারে ফিরে যেতে দেয়। পর্যাপ্ত রানটাইম ডেটা দ্বারা হাইব্রিড ডেপ্লয়মেন্টটি স্থিতিশীল বলে নিশ্চিত হওয়ার পর, আপনার নতুন কী-গুলোকে সম্পূর্ণরূপে সুরক্ষিত করার জন্য আমরা পরবর্তী আপডেটগুলোতে ROLLBACK ক্যাপাবিলিটিটি সরিয়ে ফেলার পরামর্শ দিই।

দীর্ঘমেয়াদী কনফিগারেশন প্রয়োজনীয়তা

যতক্ষণ আপনার অ্যাপটি এমন কোনো প্ল্যাটফর্ম রিলিজকে টার্গেট করবে যা শুধুমাত্র হাইব্রিড স্কিম সমর্থন করে, ততক্ষণ আপনাকে এই হাইব্রিড সাইনিং কনফিগারেশনটি বজায় রাখতে হবে। এমনকি যদি কোনো প্ল্যাটফর্ম সংস্করণ সিঙ্গেল-সাইনার PQC কী সমর্থন করে, তবুও v3.2 হাইব্রিড ব্লক প্রয়োজন এমন কোনো রিলিজকে টার্গেট করা যেকোনো APK-তে আপনাকে উভয় কী দিয়েই সাইন করতে হবে।

এপিকে স্বাক্ষর স্কিম v3.2 ব্লক

এপিকে সাইনিং ব্লকটি v3.2 সিগনেচার ব্লকটিকে যেকোনো v2, v3.0, এবং v3.1 সিগনেচার ব্লকের পাশাপাশি সংরক্ষণ করে।

v3.2-এর ব্লক কাঠামো v3.0-এর অনুরূপ, তবে এটি একটি হাইব্রিড ব্লক বোঝাতে 0x70e1c89f নামক একটি নতুন ব্লক আইডি ব্যবহার করে। একটি বৈধ v3.2 ব্লকে অবশ্যই ঠিক দুইজন স্বাক্ষরকারী থাকতে হবে।

সমর্থিত অ্যালগরিদম

v3.2 স্কিমটি প্রাথমিকভাবে নিম্নলিখিত PQC সিগনেচার অ্যালগরিদমগুলিকে সমর্থন করে:

• এমএল-ডিএসএ-৬৫
• এমএল-ডিএসএ-৮৭

এগুলোকে v3.0 এবং v3.1-এ সমর্থিত স্ট্যান্ডার্ড ক্লাসিক্যাল সিগনেচার অ্যালগরিদমগুলোর সাথে যুক্ত করে হাইব্রিড ব্লকটি গঠন করা হয়।

ফর্ম্যাট

এপিকে সাইনিং ব্লকটি এপিকে সিগনেচার স্কিম v3.2 ব্লকটিকে 0x70e1c89f আইডি-র অধীনে সংরক্ষণ করে।

v3.2 ব্লকের ফরম্যাটটি v3.0-এর অনুরূপ, কিন্তু সাইনার এলিমেন্টগুলোর শীর্ষ-স্তরের অনুক্রমে অবশ্যই একই SDK সংস্করণকে লক্ষ্য করে ঠিক দুটি এন্ট্রি থাকতে হবে:

• দৈর্ঘ্য-পূর্বনির্ধারিত স্বাক্ষরকারীর দৈর্ঘ্য-পূর্বনির্ধারিত অনুক্রম:
  
  • দৈর্ঘ্য-উপসর্গযুক্ত স্বাক্ষরকারী (শাস্ত্রীয়)
  • দৈর্ঘ্য-উপসর্গযুক্ত স্বাক্ষরকারী (PQC)

প্রত্যেক স্বাক্ষরকারী স্ট্যান্ডার্ড v3 ফরম্যাট ব্যবহার করেন:

• দৈর্ঘ্য-উপসর্গযুক্ত স্বাক্ষরিত ডেটা:
  
  • দৈর্ঘ্য-পূর্বনির্ধারিত ডাইজেস্টের দৈর্ঘ্য-পূর্বনির্ধারিত অনুক্রম:
  • স্বাক্ষর অ্যালগরিদম আইডি (৪ বাইট)
  • ডাইজেস্ট (দৈর্ঘ্য-পূর্বসূচনা)
  • দৈর্ঘ্য-পূর্বসূচিত সনদপত্রের ক্রম:
  • দৈর্ঘ্য-উপসর্গযুক্ত X.509 সার্টিফিকেট (ASN.1 DER ফর্ম)
  • minSDK (uint32)
  • সর্বোচ্চ এসডিকে (uint32)
  • দৈর্ঘ্য-পূর্বনির্ধারিত অতিরিক্ত অ্যাট্রিবিউটের দৈর্ঘ্য-পূর্বনির্ধারিত অনুক্রম:
  • আইডি (uint32)
  • মান (পরিবর্তনশীল দৈর্ঘ্য: অতিরিক্ত অ্যাট্রিবিউটের দৈর্ঘ্য - ৪ বাইট)
• minSDK (uint32)
• সর্বোচ্চ এসডিকে (uint32)
• দৈর্ঘ্য-পূর্বনির্ধারিত স্বাক্ষরসমূহের দৈর্ঘ্য-পূর্বনির্ধারিত অনুক্রম:
  
  • স্বাক্ষর অ্যালগরিদম আইডি (৪ বাইট)
  • স্বাক্ষরিত ডেটার উপর দৈর্ঘ্য-পূর্বনির্ধারিত স্বাক্ষর
• দৈর্ঘ্য-উপসর্গযুক্ত পাবলিক কী ( SubjectPublicKeyInfo , ASN.1 DER ফর্ম)

যাচাইকরণ

অ্যান্ড্রয়েড ১৭ (এপিআই লেভেল ৩৭) এবং এর পরবর্তী সংস্করণগুলোতে, v3.2 সিগনেচার যাচাই করার জন্য প্ল্যাটফর্মটি ক্লাসিক্যাল এবং PQC উভয় সাইনারকেই যাচাই করে, তাদের সামঞ্জস্যতা নিশ্চিত করে এবং অন্তর্নিহিত রোটেশন লিনিয়েজ পরীক্ষা করে। অ্যান্ড্রয়েড ১৬ (এপিআই লেভেল ৩৬) এবং এর পূর্ববর্তী প্ল্যাটফর্ম রিলিজগুলোতে, প্ল্যাটফর্মটি এই হাইব্রিড সিগনেচার ব্লকটি প্রসেস করে না এবং এর পরিবর্তে পূর্ববর্তী স্কিমগুলো ব্যবহার করে।

সামগ্রিক প্রক্রিয়াটি নিম্নরূপ:

1. APK সিগনেচার স্কিম v3.2 ব্লক (ID 0x70e1c89f) খুঁজুন।
2. যাচাই করুন যে ব্লকটিতে ঠিক দুইজন স্বাক্ষরকারী আছেন। দুইজনের কম বা বেশি থাকলে, যাচাইকরণ ব্যর্থ হবে।
3. যাচাই করুন যে একজন স্বাক্ষরকারী ক্লাসিক্যাল সিগনেচার অ্যালগরিদম এবং অন্যজন PQC সিগনেচার অ্যালগরিদম ব্যবহার করছেন। যদি উভয়ই ক্লাসিক্যাল অথবা উভয়ই PQC হয়, তাহলে যাচাইকরণ ব্যর্থ হবে।
4. যাচাই করুন যে উভয় স্বাক্ষরকারী হুবহু একই SDK পরিসর ( minSdkVersion এবং maxSdkVersion ) লক্ষ্য করছে।
5. দুইজন স্বাক্ষরকারীর প্রত্যেকের জন্য, স্ট্যান্ডার্ড v3 যাচাইকরণ সম্পাদন করুন:
   
   1. স্বাক্ষরগুলো থেকে সবচেয়ে শক্তিশালী সমর্থিত স্বাক্ষর অ্যালগরিদম আইডিটি বেছে নিন।
   2. পাবলিক কী ব্যবহার করে স্বাক্ষরিত ডেটার সাথে স্বাক্ষরগুলো থেকে সংশ্লিষ্ট স্বাক্ষরটি যাচাই করুন।
   3. যাচাই করুন যে স্বাক্ষরিত ডেটার minSdkVersion এবং maxSdkVersion , অ-স্বাক্ষরিত minSdkVersion এবং maxSdkVersion সাথে মেলে।
   4. সার্টিফিকেটগুলো পার্স করুন এবং যাচাই করুন যে প্রথম সার্টিফিকেটটি পাবলিক কী-এর সাথে মেলে।
   5. ঘূর্ণন-প্রমাণ কাঠামো বের করার জন্য অতিরিক্ত বৈশিষ্ট্যগুলো পার্স করুন।
6. স্বাক্ষরের ইতিহাস যাচাই করুন (ঘূর্ণনের প্রমাণ):
   
   1. যাচাই করুন যে উভয় স্বাক্ষরকারীর পূর্ববর্তী স্বাক্ষরের ইতিহাস অভিন্ন।
   2. বংশধারার দৈর্ঘ্য অবশ্যই মিলতে হবে এবং বর্তমান স্বাক্ষরকারী পর্যন্ত সমস্ত সার্টিফিকেট ও সক্ষমতা ফ্ল্যাগ অভিন্ন হতে হবে।
   3. যদি ইতিহাসগুলো মিলে যায়, তাহলে বংশধারাগুলো একীভূত করুন: ক্লাসিক্যাল স্বাক্ষরকারীর সার্টিফিকেটকে PQC স্বাক্ষরকারীর সার্টিফিকেটের পূর্বসূরি হিসেবে গণ্য করুন এবং PQC স্বাক্ষরকারীকে বর্তমান টার্মিনাল নোড হিসেবে নির্ধারণ করুন।
7. বিষয়বস্তু সারসংক্ষেপ যাচাই করুন:
   
   1. উভয় স্বাক্ষরকারীর জন্য ডাইজেস্ট ম্যাপটি পুনরাবৃত্তি করুন।
   2. যাচাই করুন যে, যেকোনো মিলে যাওয়া ডাইজেস্ট অ্যালগরিদমের ক্ষেত্রে, ক্লাসিক্যাল এবং PQC স্বাক্ষরকারীদের মধ্যে গণনা করা ডাইজেস্ট মানগুলো অভিন্ন হয়।
8. APK-এর বিষয়বস্তুর অখণ্ডতা যাচাই করার জন্য যাচাইকৃত স্বাক্ষরকারীদের থেকে মিলে যাওয়া ডাইজেস্টগুলো ব্যবহার করুন (v2 এবং v3-এর অনুরূপ)।
1. অ্যাপটি যদি আগে থেকেই ইনস্টল করা থাকে, তাহলে প্যাকেজ আপডেটের উৎস যাচাই করুন:
2. একক স্বাক্ষরকারী থেকে হালনাগাদ করা: যদি ইনস্টল করা অ্যাপটি একটি একক ক্লাসিক্যাল কী দিয়ে স্বাক্ষরিত হয়ে থাকে, তবে সেই কী-টি অবশ্যই নতুন হাইব্রিড ব্লকের স্বাক্ষর বংশধারায় হাইব্রিড স্বাক্ষরকারীদের পূর্বসূরি হিসেবে উপস্থিত থাকতে হবে।
3. হাইব্রিড সাইনার থেকে আপডেট করে হাইব্রিড পদ্ধতি চালু রাখা: যদি ইনস্টল করা অ্যাপটি একটি v3.2 হাইব্রিড ব্লক দিয়ে সাইন করা হয়ে থাকে, তাহলে পূর্ববর্তী ক্লাসিক্যাল এবং PQC উভয় কী-কেই হয় আপডেট করা APK-এর v3.2 ব্লকে বর্তমান সক্রিয় সাইনার হিসেবে থাকতে হবে, অথবা নতুনভাবে রোটেট করা হাইব্রিড কী-গুলোর সত্যতা প্রমাণকারী নতুন সাইনিং লিনিয়েজে উভয়কেই উপস্থিত থাকতে হবে।
4. হাইব্রিড সাইনার থেকে সরে আসা: যদি ইনস্টল করা অ্যাপটি একটি v3.2 হাইব্রিড ব্লক দিয়ে স্বাক্ষরিত হয়ে থাকে এবং আপডেট APK-টি আবার কোনো একক সাইনারে (হয় PQC অথবা ক্লাসিক্যাল) ফিরে যায়, তাহলে পূর্ববর্তী উভয় হাইব্রিড সাইনারকেই আপডেট APK-টির সাইনিং লিনিয়েজে উপস্থিত থাকতে হবে এবং নতুন একক সাইনিং কী-টিকে সত্যায়ন করতে হবে।
5. অবৈধ আপডেট পাথ: যদি কোনো ডেভেলপার যথাযথ রোটেশন ছাড়া শুধুমাত্র একটি হাইব্রিড কী-কে একক সাইনার হিসেবে ব্যবহার করে একটি হাইব্রিড-সাইনড অ্যাপ আপডেট করার চেষ্টা করেন, তাহলে আপডেটটি ব্যর্থ হয়। ডাউনগ্রেড অ্যাটাক প্রতিরোধ করার জন্য যেকোনো ট্রানজিশনে উভয় কী-কেই স্পষ্টভাবে অন্তর্ভুক্ত করতে হবে।
9. যেকোনো একটি ধাপ ব্যর্থ হলে, যাচাইকরণ ব্যর্থ হয়।

স্ট্রিপিং সুরক্ষা

নিম্নতর সিগনেচার স্কিমে ডাউনগ্রেড আক্রমণ প্রতিরোধ করার জন্য, v3.2 স্কিমটিতে পূর্ববর্তী স্কিম সংস্করণগুলির অনুরূপ স্ট্রিপিং সুরক্ষা অ্যাট্রিবিউট অন্তর্ভুক্ত রয়েছে।

সাইনিং টুলটি v3.0 এবং v3.1 সিগনেচার ব্লকের অতিরিক্ত অ্যাট্রিবিউটগুলোর মধ্যে দুটি নির্দিষ্ট হাইব্রিড স্ট্রিপিং প্রোটেকশন অ্যাট্রিবিউট লিখে দেয়। এই অ্যাট্রিবিউটগুলো SDK ভার্সনের সুনির্দিষ্ট সীমানা নির্ধারণ করে, যার মধ্যে v3.2 হাইব্রিড ব্লকটি অবশ্যই উপস্থিত এবং ভেরিফাই করা থাকতে হবে:

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

যদি ব্লকটি অনুপস্থিত থাকার কারণে বা এর SDK রেঞ্জ ডিভাইসটির জন্য প্রযোজ্য না হওয়ায় প্ল্যাটফর্মটি v3.2 ভেরিফিকেশন এড়িয়ে যায়, তবে প্ল্যাটফর্মটি পরবর্তী উপস্থিত ব্লকের সাথে APK-টি যাচাই করে। যদি সেই পূর্ববর্তী ব্লকটিতে এই স্ট্রিপিং প্রোটেকশন অ্যাট্রিবিউটগুলো থাকে, তবে প্ল্যাটফর্মটি নিম্নলিখিত চেকগুলো প্রয়োগ করে:

• উপস্থিতি এবং পরিসীমা যাচাইকরণ: যদি কোনো v3.0 বা v3.1 সিগনেচার ব্লকে সর্বনিম্ন SDK অ্যাট্রিবিউট (ID 0xbf940529 , মান X ) অথবা সর্বোচ্চ SDK অ্যাট্রিবিউট (ID 0x9f06b79c , মান Y ) থাকে, তাহলে প্ল্যাটফর্মের জন্য APK-এর মধ্যে v3.2 হাইব্রিড ব্লকটির উপস্থিতি আবশ্যক। প্ল্যাটফর্মটি হাইব্রিড ব্লকটি পড়ে যাচাই করে যে এর টার্গেট করা SDK পরিসীমা এই অ্যাট্রিবিউটগুলো দ্বারা নির্দিষ্ট সীমার সাথে মেলে কিনা। যদি v3.2 ব্লকটি অনুপস্থিত থাকে, অথবা যদি এর অভ্যন্তরীণ সর্বনিম্ন এবং সর্বোচ্চ SDK টার্গেট মান X এবং Y-এর সমান না হয়, তাহলে প্ল্যাটফর্মটি ইনস্টলেশনটি প্রত্যাখ্যান করে।
• নির্দিষ্ট সীমার মধ্যে প্রয়োগ: যদি ডিভাইসটির SDK ভার্সন এই অ্যাট্রিবিউটগুলো দ্বারা নির্দিষ্ট বৈধ সীমার মধ্যে পড়ে—যা X- এর সমান বা তার বেশি, এবং সর্বোচ্চ অ্যাট্রিবিউটটি প্রদান করলে Y- এর সমান বা তার কম—তাহলে প্ল্যাটফর্মটি সিগনেচার ভেরিফিকেশনের জন্য v3.2 হাইব্রিড ব্লকটি কঠোরভাবে আবশ্যক করে। যদি প্ল্যাটফর্মটি এই নির্দিষ্ট SDK সীমার মধ্যে থাকা কোনো ডিভাইসে v3.0 বা v3.1 ব্লক ভেরিফাই করে, তবে প্ল্যাটফর্মটি ইনস্টলেশনটি প্রত্যাখ্যান করে, কারণ v3.2 ব্লকটি বিদ্বেষপূর্ণভাবে বাইপাস বা স্ট্রিপ করা হয়েছিল।

এই সীমাগুলো প্রয়োগ করার মাধ্যমে প্ল্যাটফর্মটি নির্ধারণ করে যে কখন একটি APK-তে অবশ্যই v3.2 ব্লক থাকতে হবে। যদি ব্লকটি সরিয়ে ফেলা হয়, তাহলে ডাউনগ্রেড আক্রমণ প্রতিরোধ করার জন্য প্ল্যাটফর্মটি ইনস্টলেশনটি প্রত্যাখ্যান করে।

আপনার বাস্তবায়ন যাচাই করুন

আপনার v3.2 সিগনেচার স্কিমের বাস্তবায়ন পরীক্ষা করতে, cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ -এ অবস্থিত HybridSignatureVerificationTest.java CTS টেস্টগুলো চালান।

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