PKI Infrastructure: পাবলিক কি ইনফ্রাস্ট্রাকচার এবং ডিজিটাল সার্টিফিকেটের নিরাপত্তা!

Public Key Infrastructure হলো এমন একটি ব্যবস্থা যা পাবলিক কি ক্রিপ্টোগ্রাফি ব্যবহার করে ডিজিটাল পরিচয় তৈরি, বিতরণ, যাচাই এবং প্রত্যাহার করার কাঠামো প্রদান করে। এর কেন্দ্রবিন্দুতে রয়েছে অসমমিত (Asymmetric) ক্রিপ্টোগ্রাফি—যেখানে প্রতিটি সত্তার একটি Public Key এবং একটি গণিতগতভাবে সম্পর্কিত Private Key থাকে। Public Key দিয়ে এনক্রিপ্ট করা ডেটা শুধুমাত্র সংশ্লিষ্ট Private Key দিয়ে ডিক্রিপ্ট করা যায়, এবং Private Key দিয়ে স্বাক্ষরিত ডেটার সত্যতা Public Key দিয়ে যাচাই করা যায়।

PKI-এর প্রধান উপাদানগুলো হলো Certificate Authority (CA), Registration Authority (RA), Certificate Repository, Certificate Revocation List (CRL) বা OCSP Responder, এবং End Entity। CA হলো বিশ্বস্ত তৃতীয় পক্ষ যা ডিজিটাল সার্টিফিকেট ইস্যু এবং স্বাক্ষর করে। RA সার্টিফিকেটের জন্য আবেদনকারীর পরিচয় যাচাই করে। Repository ইস্যুকৃত সার্টিফিকেট সংরক্ষণ করে। CRL/OCSP প্রত্যাহৃত সার্টিফিকেটের তথ্য প্রদান করে। End Entity হলো সার্টিফিকেটধারী—ব্যবহারকারী, ডিভাইস, সার্ভার বা অ্যাপ্লিকেশন।

ডিজিটাল সার্টিফিকেট X.509 v3 মান অনুযায়ী গঠিত হয়। প্রতিটি সার্টিফিকেটে থাকে Subject (যার পরিচয়), Issuer (কে ইস্যু করেছে), Public Key, Serial Number, Validity Period, Signature Algorithm, এবং বিভিন্ন Extension—Key Usage, Extended Key Usage, Subject Alternative Names (SAN), Authority Information Access (AIA), CRL Distribution Points (CDP), এবং Basic Constraints। প্রতিটি Extension-এর সঠিক কনফিগারেশন নিরাপত্তার জন্য অত্যন্ত গুরুত্বপূর্ণ।

এন্টারপ্রাইজ PKI সাধারণত একটি Hierarchical Trust Model-এ গঠিত হয়। শীর্ষে থাকে Root CA—সর্বোচ্চ বিশ্বাসযোগ্য সত্তা যা স্ব-স্বাক্ষরিত (Self-signed)। Root CA-এর নিচে থাকে এক বা একাধিক Subordinate CA বা Intermediate CA। Subordinate CA-গুলোই সাধারণত End-entity সার্টিফিকেট ইস্যু করে। এই দ্বি-স্তর বা ত্রি-স্তর কাঠামো নিরাপত্তা এবং পরিচালনাগত নমনীয়তা উভয়ই প্রদান করে।

আদর্শ অনুশীলন হলো Root CA-কে Offline রাখা—এটি শুধুমাত্র Subordinate CA-এর সার্টিফিকেট ইস্যু বা পুনর্নবীকরণের সময় চালু করা হয়। Root CA-এর Private Key একটি Hardware Security Module (HSM)-এ সংরক্ষিত এবং কঠোর ভৌত নিরাপত্তায় রাখা হয়। Root CA Compromise হলে পুরো PKI Infrastructure পুনঃনির্মাণ করতে হয়—যা একটি বিপর্যয়কর পরিস্থিতি। Microsoft Active Directory Certificate Services (AD CS)-এ Two-tier (Root + Issuing CA) বা Three-tier (Root + Policy CA + Issuing CA) কাঠামো প্রচলিত।

Cross-certification এবং Bridge CA মডেল বহু সংস্থার মধ্যে আন্তঃ-পরিচালন সক্ষম করে। US Federal PKI Bridge এর একটি বিখ্যাত উদাহরণ। Path Validation অ্যালগরিদম (RFC 5280) Trust Chain যাচাই করে—End-entity সার্টিফিকেট থেকে শুরু করে কোনো বিশ্বস্ত Root পর্যন্ত প্রতিটি স্বাক্ষর, Validity Period এবং Extension পরীক্ষা করে।

সার্টিফিকেট জীবনচক্রের প্রথম ধাপ Enrollment বা Issuance। আবেদনকারী একটি Key Pair তৈরি করে এবং Certificate Signing Request (CSR) তৈরি করে—যা PKCS#10 ফরম্যাটে পাবলিক কি এবং Subject তথ্য বহন করে। RA এই অনুরোধ যাচাই করে এবং অনুমোদনের পর CA সার্টিফিকেট স্বাক্ষর করে ইস্যু করে। আধুনিক পরিবেশে এই প্রক্রিয়া Automated Certificate Management Environment (ACME) প্রোটোকল, SCEP, EST বা CMP-এর মাধ্যমে স্বয়ংক্রিয় হয়।

Let's Encrypt ACME প্রোটোকল ব্যবহার করে ইন্টারনেটের TLS সার্টিফিকেট ব্যবস্থাপনাকে আমূল পরিবর্তন করেছে। ৯০ দিনের সংক্ষিপ্ত Validity Period এবং স্বয়ংক্রিয় পুনর্নবীকরণ আদর্শ হয়ে উঠেছে। এন্টারপ্রাইজ পরিবেশে cert-manager (Kubernetes), HashiCorp Vault PKI, এবং Smallstep CA জনপ্রিয় সমাধান।

সার্টিফিকেট পুনর্নবীকরণ একটি গুরুত্বপূর্ণ ধাপ। মেয়াদ শেষ হওয়ার আগেই নতুন সার্টিফিকেট ইস্যু এবং স্থাপন করতে হবে। মনোযোগের অভাবে মেয়াদোত্তীর্ণ সার্টিফিকেট বিশাল সেবা বিভ্রাট ঘটায়—২০২০ সালে Microsoft Teams, ২০২১ সালে Spotify, এবং ২০২২ সালে Slack সবাই Expired Certificate-এর কারণে সেবা বিভ্রাট ভোগ করেছে। Certificate Inventory এবং Expiration Monitoring তাই অত্যন্ত গুরুত্বপূর্ণ।

সবচেয়ে চ্যালেঞ্জিং ধাপ Revocation বা প্রত্যাহার। যদি Private Key Compromise হয়, কর্মচারী চলে যায়, বা সার্টিফিকেট তথ্য পরিবর্তিত হয়—তাহলে সার্টিফিকেট প্রত্যাহার করতে হবে। Revocation দুটি প্রধান পদ্ধতিতে প্রকাশিত হয়—Certificate Revocation List (CRL) এবং Online Certificate Status Protocol (OCSP)। CRL একটি স্বাক্ষরিত তালিকা যা পর্যায়ক্রমে প্রকাশিত হয়—এটি বড় এবং পুরনো হতে পারে। OCSP প্রতিটি সার্টিফিকেটের জন্য তাৎক্ষণিক জিজ্ঞাসা সমর্থন করে কিন্তু গোপনীয়তা এবং প্রাপ্যতার সমস্যা রয়েছে।

OCSP Stapling এই সমস্যার সমাধানে সাহায্য করে—সার্ভার নিজেই OCSP প্রতিক্রিয়া সংগ্রহ করে এবং TLS Handshake-এ সংযুক্ত করে। CRLite হলো আধুনিক একটি কৌশল যা সমস্ত পরিচিত প্রত্যাহার তথ্য একটি কম্প্যাক্ট Bloom Filter-এ সংরক্ষণ করে।

CA Compromise হলো সবচেয়ে ভয়াবহ আক্রমণ। ২০১১ সালে DigiNotar CA Compromise হয়েছিল—আক্রমণকারীরা google.com সহ ৫০০-এর বেশি জাল সার্টিফিকেট ইস্যু করেছিল যা ইরানি সরকার নাগরিকদের গুপ্তচরবৃত্তিতে ব্যবহার করেছিল। DigiNotar পরে দেউলিয়া হয়ে যায়। একই বছর Comodo-এর একটি Reseller Compromise-এ অনুরূপ ঘটনা ঘটে।

Wildcard Certificate-এর অপব্যবহার আরেকটি ঝুঁকি। *.example.com-এর জন্য একটি Wildcard সার্টিফিকেট চুরি হলে আক্রমণকারী যেকোনো সাবডোমেইনের জন্য নিজেকে বৈধ হিসেবে উপস্থাপন করতে পারে। এই কারণে আধুনিক অনুশীলন Wildcard-এর পরিবর্তে SAN ভিত্তিক স্বতন্ত্র সার্টিফিকেট ব্যবহারের পক্ষে।

Active Directory Certificate Services (AD CS)-এর বিরুদ্ধে SpecterOps-এর Will Schroeder এবং Lee Christensen "Certified Pre-Owned" শ্বেতপত্রে ESC1 থেকে ESC8 পর্যন্ত আটটি প্রধান আক্রমণ পদ্ধতি বর্ণনা করেছেন। ESC1-এ একজন নিম্ন-অধিকার ব্যবহারকারী Subject Alternative Name নিয়ন্ত্রণ করে Domain Administrator-এর নামে সার্টিফিকেট অনুরোধ করতে পারে যদি Template-এ "Supply in request" অনুমোদিত থাকে। ESC8-এ NTLM Relay আক্রমণের মাধ্যমে Domain Controller-এর সার্টিফিকেট অর্জন করা যায়। Certipy এবং Certify-এর মতো টুলস এই দুর্বলতাগুলো শোষণ করতে ব্যবহৃত হয়।

Private Key Compromise অসংখ্য উপায়ে ঘটতে পারে—অনিরাপদ ফাইল সংরক্ষণ, Git Repository-তে দুর্ঘটনাবশত কমিট, Memory Dump থেকে নিষ্কাশন, বা Side-channel আক্রমণ। ২০১৪ সালের Heartbleed bug OpenSSL-এ একটি Memory Disclosure দুর্বলতা যা Private Key পর্যন্ত নিষ্কাশনের সুযোগ দিয়েছিল। প্রতিটি Heartbleed-প্রভাবিত সার্ভারের সার্টিফিকেট পুনরায় ইস্যু করতে হয়েছিল।

Rogue CA Installation একটি স্থানীয় আক্রমণ যেখানে আক্রমণকারী ভুক্তভোগীর সিস্টেমে নিজের CA-কে Trusted Root হিসেবে স্থাপন করে। এর পরে আক্রমণকারী যেকোনো ডোমেইনের জন্য বৈধ-দেখানো সার্টিফিকেট ইস্যু করতে পারে যা ব্রাউজার গ্রহণ করে। Lenovo Superfish (২০১৫) ছিল এর একটি বিখ্যাত উদাহরণ যেখানে একটি প্রি-ইনস্টলড Adware সমস্ত HTTPS ট্রাফিক ইন্টারসেপ্ট করছিল।

আধুনিক PKI-তে অ্যালগরিদম পছন্দ অত্যন্ত গুরুত্বপূর্ণ। RSA-2048 দীর্ঘদিন ধরে আদর্শ ছিল, কিন্তু এখন RSA-3072 বা RSA-4096 বেশি সুপারিশকৃত। Elliptic Curve Cryptography (ECC)—P-256 বা P-384—সমতুল্য নিরাপত্তায় কম কম্পিউটেশনাল ব্যয় প্রদান করে এবং মোবাইল ও IoT ডিভাইসের জন্য আদর্শ। Ed25519 আধুনিক উচ্চ-পারফরম্যান্স পরিবেশে ক্রমশ গ্রহণযোগ্যতা পাচ্ছে।

হ্যাশ অ্যালগরিদমে MD5 এবং SHA-1 দীর্ঘকাল ধরে অপ্রচলিত—এদের Collision Attack প্রমাণিত। SHA-256 বর্তমান মান, এবং SHA-384, SHA-512 উচ্চতর নিরাপত্তার জন্য। CA/Browser Forum এবং প্রধান ব্রাউজার কোম্পানি SHA-1 ভিত্তিক সার্টিফিকেট সম্পূর্ণরূপে অপ্রচলিত করেছে।

Post-Quantum Cryptography-এর প্রস্তুতি এখন সক্রিয়ভাবে শুরু হচ্ছে। NIST ২০২৪ সালে CRYSTALS-Kyber (এনক্রিপশন) এবং CRYSTALS-Dilithium, FALCON, SPHINCS+ (স্বাক্ষর) অনুমোদন করেছে। Hybrid Certificate—যা প্রচলিত এবং Post-Quantum উভয় অ্যালগরিদম সমর্থন করে—একটি ক্রান্তিকালীন সমাধান হিসেবে বিকশিত হচ্ছে। দীর্ঘমেয়াদী সংবেদনশীল ডেটার জন্য Harvest-now-decrypt-later হুমকি বিবেচনায় এখনই Post-Quantum স্থানান্তরের পরিকল্পনা শুরু করা প্রয়োজন।

Certificate Transparency (CT) ২০১৩ সালে Google চালু করেছে DigiNotar-এর মতো ঘটনার পুনরাবৃত্তি রোধে। প্রতিটি Public Trusted সার্টিফিকেট অন্তত দুটি স্বাধীন CT Log-এ প্রকাশিত হতে হবে। Browser-গুলো Signed Certificate Timestamp (SCT) যাচাই করে নিশ্চিত হয় যে সার্টিফিকেট পাবলিকলি দৃশ্যমান। যেকেউ crt.sh বা Censys-এ অনুসন্ধান করে নিজের ডোমেইনের জন্য ইস্যুকৃত সমস্ত সার্টিফিকেট দেখতে পারে—এটি Rogue Issuance তাৎক্ষণিকভাবে সনাক্ত করতে সাহায্য করে।

CAA (Certification Authority Authorization) DNS রেকর্ড নির্ধারণ করে কোন CA আপনার ডোমেইনের জন্য সার্টিফিকেট ইস্যু করতে পারবে। ২০১৭ সাল থেকে CA-গুলোর জন্য CAA চেক বাধ্যতামূলক। DNS CAA রেকর্ডে "issue" বা "issuewild" Directive দিয়ে অনুমোদিত CA নির্দিষ্ট করুন। উদাহরণ: example.com. IN CAA 0 issue "letsencrypt.org"—এটি শুধুমাত্র Let's Encrypt-কে অনুমতি দেয়।

HSTS (HTTP Strict Transport Security) এবং HPKP (HTTP Public Key Pinning)—যদিও HPKP এখন অপ্রচলিত—Trust জোরদার করে। আধুনিক পরিবেশে Expect-CT এবং Encrypted Client Hello (ECH) ব্যবহৃত হয়।

এন্টারপ্রাইজ PKI পরিচালনায় Root CA Air-gapped রাখুন এবং HSM-এ Private Key সংরক্ষণ করুন—FIPS 140-2 Level 3 বা তদূর্ধ্ব। Subordinate CA-গুলোও HSM-এ Key সংরক্ষণ করবে। CA পরিচালনায় Multi-person Control (Quorum)—সংবেদনশীল কাজে একাধিক প্রশাসকের অনুমোদন বাধ্যতামূলক। প্রতিটি CA অপারেশন বিস্তারিতভাবে Audit Log-এ রেকর্ড করুন।

Certificate Template Hardening অপরিহার্য। AD CS-এ "Supply in request" এড়ান, EDITF_ATTRIBUTESUBJECTALTNAME2 ফ্ল্যাগ নিষ্ক্রিয় রাখুন, Manager Approval বাধ্যতামূলক করুন সংবেদনশীল Template-এ, এবং নিয়মিত Locksmith বা PSPKIAudit-এর মতো টুল দিয়ে অডিট চালান। অপ্রয়োজনীয় Template নিষ্ক্রিয় করুন।

Certificate Lifecycle Management (CLM) সমাধান স্থাপন করুন—Venafi, Keyfactor, AppViewX, বা Open Source DogTag PKI। স্বয়ংক্রিয় Discovery, Renewal এবং Revocation প্রক্রিয়া স্থাপন করুন। Certificate Inventory নিয়মিত আপডেট করুন। সংক্ষিপ্ত Validity Period (৯০ দিন বা কম)-এর দিকে অগ্রসর হোন—সমস্যা দ্রুত সংশোধন হয় এবং Compromise-এর প্রভাব সীমিত থাকে।

Private Key সুরক্ষায় কঠোর হোন। Source Code Repository-তে Key কমিট রোধে Pre-commit Hook এবং Git Secret Scanner (TruffleHog, GitLeaks) ব্যবহার করুন। Cloud পরিবেশে AWS KMS, Azure Key Vault, GCP KMS ব্যবহার করুন—Key কখনো Plain Text-এ রপ্তানি হবে না। Application স্তরে Key Pinning বা Mutual TLS (mTLS) ব্যবহার করে অতিরিক্ত নিরাপত্তা স্তর যোগ করুন।

Monitoring এবং Detection-এ CT Log Monitoring স্থাপন করুন—আপনার ডোমেইনের জন্য কোনো অপ্রত্যাশিত সার্টিফিকেট ইস্যু হলে অবিলম্বে Alert পান। SSL Labs বা testssl.sh-এর মাধ্যমে নিয়মিত স্ক্যান করুন। SIEM-এ CA Event Log অন্তর্ভুক্ত করুন এবং অস্বাভাবিক Issuance প্যাটার্নের জন্য নিয়ম তৈরি করুন।

Incident Response Plan তৈরি রাখুন। CA Compromise বা Mass Revocation পরিস্থিতিতে স্পষ্ট কর্মপন্থা থাকতে হবে। প্রতি বছর অন্তত একবার Disaster Recovery Drill চালান যেন Root CA পুনরুদ্ধারের প্রক্রিয়া পরীক্ষিত থাকে। Cryptographic Agility—দ্রুত নতুন অ্যালগরিদমে স্থানান্তরের ক্ষমতা—এখন একটি কৌশলগত অগ্রাধিকার।