Google Pay এবং Mastercard ভারতে Consumer Device Cardholder Verification Method (CDCVM) ব্যবহার করে বায়োমেট্রিক-সক্ষম পেমেন্ট চালু করতে শুরু করেছে। ক্রেতারা ফিঙ্গারপ্রিন্ট বা ফেস স্ক্যানের মাধ্যমে কেনাকাটা নিশ্চিত করেন এবং বায়োমেট্রিক ডেটা ফোনের ভেতরেই সুরক্ষিত থাকে।
কেন এখন CDCVM গুরুত্বপূর্ণ
CDCVM "আপনি কে" যাচাইকরণ প্রক্রিয়াটিকে ডিভাইসের ওপর নিয়ে আসে। শুধুমাত্র একটি ক্রিপ্টোগ্রাফিকভাবে স্বাক্ষরিত (cryptographically signed), একবার ব্যবহারযোগ্য পেমেন্ট টোকেন ফোন থেকে বের হয়, ফলে বায়োমেট্রিক ডেটা কখনোই ইন্টারনেটের মাধ্যমে যাতায়াত করে না।
এর অভ্যন্তরীণ কার্যপ্রক্রিয়া কীভাবে কাজ করে
- Feature extraction – সেন্সর (ফিঙ্গারপ্রিন্ট রিডার বা ক্যামেরা) র (raw) ডেটাকে একটি Secure Enclave বা Trusted Execution Environment (TEE)-এ পাঠায়। এই বিচ্ছিন্ন অঞ্চলগুলো অপারেটিং সিস্টেমের কাছে ডেটা প্রকাশ না করেই ইনপুট প্রসেস করে।
- Local comparison – ডিভাইসটি ব্যবহারকারীর বায়োমেট্রিকের একটি এনক্রিপ্টেড টেমপ্লেট সংরক্ষণ করে। Secure Enclave লাইভ ক্যাপচারের সাথে এই টেমপ্লেটটি তুলনা করে, কিন্তু র (raw) ইমেজ বা ফিচার ভেক্টর অন্য কোথাও পাঠায় না।
- Hardware attestation – যখন ম্যাচ সফল হয়, তখন এনক্লেভ (enclave) একটি প্রাইভেট কি (private key) দিয়ে লেনদেনটি স্বাক্ষর করে যা কখনোই হার্ডওয়্যার থেকে বের হয় না। এই অ্যাটেস্টেশন (attestation) প্রমাণ করে যে একটি যাচাইকৃত বায়োমেট্রিক ব্যবহার করা হয়েছে, কিন্তু বায়োমেট্রিকটি প্রকাশ করে না।
- Token generation – স্বাক্ষরিত অ্যাটেস্টেশনটি একটি টোকেন-সার্ভিসের সাথে যুক্ত হয়ে একটি ওয়ান-টাইম টোকেন তৈরি করে। বায়োমেট্রিক নয়, বরং টোকেনটি মার্চেন্ট এবং তারপর সেটেলমেন্টের জন্য ইস্যুকারী ব্যাংকের কাছে যায়।
মার্চেন্ট এবং ব্যাংক শুধুমাত্র স্বাক্ষরিত টোকেনটি দেখতে পায়। সমস্ত বায়োমেট্রিক ডেটা ডিভাইসের সুরক্ষিত মেমোরিতেই থাকে।
ডেভেলপারদের যে ভুলগুলো এড়িয়ে চলা উচিত
- Sending biometric vectors – র (raw) ফিঙ্গারপ্রিন্ট বা ফেসিয়াল ডেটা পাঠানো একটি স্থায়ী ঝুঁকির সৃষ্টি করে। যদি কোনো ডেটাবেস হ্যাক হয়, তবে ফিঙ্গারপ্রিন্ট পরিবর্তন করা সম্ভব নয়।
- Replay attacks – বায়োমেট্রিকের নিউমেরিক রিপ্রেজেন্টেশন যদি নেটওয়ার্কের মাধ্যমে যাতায়াত করে, তবে সেন্সরকে স্পুফ (spoof) করার জন্য তা ক্যাপচার করে পুনরায় পাঠানো যেতে পারে।
- Regulatory headaches – অনেক বিচারব্যবস্থায় বায়োমেট্রিক ডেটাকে অত্যন্ত সংবেদনশীল ব্যক্তিগত তথ্য হিসেবে গণ্য করা হয় এবং এর স্টোরেজ, সম্মতি এবং ডেটা ব্রিচ-নোটিফিকেশন সংক্রান্ত কঠোর নিয়ম আরোপ করা হয়।
বায়োমেট্রিককে একটি লোকাল কি (local key) হিসেবে বিবেচনা করুন যা ক্রিপ্টোগ্রাফিক অপারেশনগুলো আনলক করে; এটিকে কখনোই পেলোড (payload) হিসেবে পাঠাবেন না।
একটি বাস্তবসম্মত ইমপ্লিমেন্টেশন চেকলিস্ট
- প্ল্যাটফর্ম-প্রদত্ত বায়োমেট্রিক API ব্যবহার করুন যা ক্যাপচার এবং প্রসেসিং ডিভাইসের TEE-এর ভেতরেই রাখে।
- বায়োমেট্রিক টেমপ্লেট এনক্রিপ্টেড অবস্থায় সংরক্ষণ করুন যা Secure Enclave দ্বারা পরিচালিত একটি কি (key) দিয়ে সুরক্ষিত; এটি কখনোই ফাইল সিস্টেমে লিখবেন না।
- হার্ডওয়্যার অ্যাটেস্টেশন (hardware attestation) অনুরোধ করুন সফল ম্যাচিংয়ের পর।
- একটি টোকেনাইজেশন সার্ভিসের সাথে ইন্টিগ্রেট করুন যা অ্যাটেস্টেশন গ্রহণ করে এবং একটি ওয়ান-টাইম টোকেন ইস্যু করে। টোকেন রিকোয়েস্টে স্বাক্ষরিত অ্যাটেস্টেশন অন্তর্ভুক্ত করুন কিন্তু কোনো বায়োমেট্রিক ডেটা নয়।
- সার্ভার সাইডে টোকেনটি যাচাই (validate) করুন ইস্যুকারীর পাবলিক কি (public key) ব্যবহার করে। কোনো বৈধ অ্যাটেস্টেশন সিগনেচার না থাকা টোকেন প্রত্যাখ্যান করুন।
- এজ কেসগুলো (edge cases) পরীক্ষা করুন, যেমন সেন্সর ব্যর্থতা, ফলস রিজেক্ট (false rejects) এবং ডিভাইস পরিবর্তন। বায়োমেট্রিক ডেটা প্রকাশ না করেই ফ্লো-টি যেন পিন (PIN) বা পাসওয়ার্ডে ফিরে যেতে পারে।
সারসংক্ষেপ
যখন বায়োমেট্রিক ভেরিফিকেশন ফোনের সুরক্ষিত হার্ডওয়্যারের ভেতরেই থাকে এবং শুধুমাত্র একটি ওয়ান-টাইম টোকেন স্বাক্ষর করে, তখন ব্যবহারকারীরা তাদের ফিঙ্গারপ্রিন্ট বা ফেসিয়াল ডেটা গোপন রাখতে পারেন এবং মার্চেন্টরা সংবেদনশীল ব্যক্তিগত তথ্যের ঝুঁকি কমাতে পারেন। ডেভেলপারদের জন্য নিয়মটি সহজ: বায়োমেট্রিককে ক্রিপ্টোগ্রাফিক কি (cryptographic key) আনলক করতে দিন, কিন্তু কখনোই এটিকে ডিভাইস থেকে বের হতে দেবেন না।