Digital signature আর PKI — certificate, CA আর বিশ্বাসের শিকল

১ · সইয়ের সমস্যা — কাগজের সই থেকে গণিতের সই

পর্ব ১০-এ দেখেছেন, public key cryptography-তে দুটি চাবি থাকে: একটি সবার জন্য খোলা (public key), অন্যটি শুধু মালিকের (private key). এই পর্বে সেই জুটিকে আমরা একটি নতুন কাজে লাগাব: প্রমাণ করা যে একটি বার্তা সত্যিই নির্দিষ্ট কারও কাছ থেকে এসেছে, আর পথে বদলায়নি।

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

কিন্তু এখানেই একটি নতুন প্রশ্ন জন্ম নেয়, যা এই পর্বের দ্বিতীয় অর্ধেক। আপনি public key দিয়ে স্বাক্ষর যাচাই করলেন। কিন্তু সেই public key যে সত্যিই “আপনার ব্যাংকের”, তা জানলেন কীভাবে? মাঝখানে কেউ নিজের public key “ব্যাংকের” বলে ধরিয়ে দিলে সব গণিত ঠিক থাকবে, আর আপনি ঠকবেন। Key আর নামের এই জোড়া প্রমাণ করার পুরো ব্যবস্থার নাম PKI (Public Key Infrastructure).

২ · আগে hash, তারপর স্বাক্ষর — আর MAC-এর সাথে পার্থক্য

Public key-এর গণিত ধীর, আর একটি নির্দিষ্ট আকারের সংখ্যার ওপরই কাজ করে। তাই ১০ GB-এর ফাইলে সরাসরি স্বাক্ষর হয় না। আগে পুরো ফাইলের hash বের করা হয় (পর্ব ০৯), তারপর সেই ছোট, নির্দিষ্ট আকারের hash-এর ওপর স্বাক্ষর। এই রীতির নাম hash-then-sign. এর একটি গুরুত্বপূর্ণ ফল আছে: স্বাক্ষর ততটাই শক্ত, যতটা শক্ত hash-টি। Hash-এ collision বানানো গেলে একটি স্বাক্ষর দুটি আলাদা বার্তায় বসে যায়।

নিচের ধাপগুলোতে ছোট সংখ্যার একটি খেলনা উদাহরণ চলছে। সংখ্যাগুলো পরের কোড ব্লকের আসল আউটপুট থেকে নেওয়া।

এবার নিজে চালিয়ে দেখুন। এটি খেলনা RSA: মাত্র ৩২৩৩ আকারের modulus আর একটি খেলনা hash. শুধু ধারণার জন্য; সত্যিকারের RSA-তে key হাজার হাজার বিটের, আর padding ছাড়া এভাবে স্বাক্ষর করা নিরাপদ নয়।

// Toy RSA (p=61, q=53). Real নয়, শুধু ধারণার জন্য।
const pub = { n: 3233n, e: 17n }, priv = { n: 3233n, d: 2753n };
function modpow(b, x, m) {
  let r = 1n; b %= m;
  for (; x > 0n; x >>= 1n) { if (x & 1n) r = r * b % m; b = b * b % m; }
  return r;
}
// Toy hash: any length in, a small number out. Never use for real.
function toyHash(text, n) {
  let h = 7n;
  for (const ch of text) h = (h * 131n + BigInt(ch.charCodeAt(0))) % n;
  return h;
}
const sign = (msg) => modpow(toyHash(msg, priv.n), priv.d, priv.n);
function verify(msg, sig) {
  const want = toyHash(msg, pub.n), got = modpow(sig, pub.e, pub.n);
  return { want, got, ok: want === got };
}
const msg = 'pay 500 to shop-17';
const sig = sign(msg);
console.log('message  :', msg);
console.log('hash     :', String(toyHash(msg, pub.n)));
console.log('signature:', String(sig), '(made with private d)');
const show = (label, v) =>
  console.log(label.padEnd(20), 'want', String(v.want).padStart(4),
              'got', String(v.got).padStart(4), v.ok ? 'VALID' : 'INVALID');
show('original', verify(msg, sig));
show('amount changed', verify('pay 900 to shop-17', sig));
show('signature changed', verify(msg, sig + 1n));

স্বাক্ষর কী প্রমাণ করে, আর কী করে না

একটি বৈধ স্বাক্ষর ঠিক তিনটি জিনিস বলে: বার্তা স্বাক্ষরের পর বদলায়নি (integrity), স্বাক্ষরটি ওই private key দিয়ে বানানো (authenticity), আর তৃতীয় কোনো পক্ষের কাছেও তা দেখানো যায় (non-repudiation-এর ভিত্তি)। কিন্তু স্বাক্ষর বলে না যে বার্তাটি সত্যি, স্বাক্ষরকারী সৎ, বা ভেতরের কোড নিরাপদ। সবচেয়ে বড় কথা, এটি প্রমাণ করে key ব্যবহার হয়েছে, মানুষটি নিজে করেছেন তা নয়। Key চুরি হলে চোরের স্বাক্ষরও গণিতের চোখে নিখুঁত। আর বার্তা গোপনও থাকে না; গোপনতার জন্য আলাদা encryption লাগে।

MAC আর signature — একই কাজ?

পর্ব ০৯-এ MAC দেখেছেন, যেমন HMAC. দুটোই বদল ধরে। পার্থক্য হলো কে বানাতে পারে।

৩ · RSA-PSS, ECDSA আর Ed25519 — তিন পরিচিত স্বাক্ষর

গণিতের বিস্তার পর্ব ১০-এর বিষয়। এখানে একজন প্রকৌশলীর যা জানা দরকার, শুধু সেটুকু।

NIST-এর FIPS 186-5 (২০২৩) RSA, ECDSA আর EdDSA-কে স্বাক্ষরের মান হিসেবে রেখেছে। নতুন নকশায় কোনটি নেবেন, সেটি নির্ভর করে কে যাচাই করবে তার ওপর। Public web-এ RSA আর ECDSA সবচেয়ে সর্বজনীন; SSH key, software signing আর নিজের নিয়ন্ত্রিত ব্যবস্থায় Ed25519 জনপ্রিয়। কোয়ান্টাম-যুগের নতুন স্বাক্ষর (FIPS 204, FIPS 205; ২০২৪) নিয়ে আলোচনা হবে পর্ব ১৪-এ।

ECDSA-তে nonce-এর ইতিহাস — একটি সংখ্যার দাম

ECDSA-তে প্রতিটি স্বাক্ষরের জন্য একটি নতুন, গোপন, অননুমেয় সংখ্যা লাগে। এই একটি সংখ্যার নিয়ম ভাঙলে গণিত নিজেই গোপন তথ্য ফাঁস করে। দুটি ভিন্ন বার্তায় একই nonce পড়লে, বা nonce অনুমানযোগ্য হলে, প্রকাশ্য স্বাক্ষর থেকেই private key বেরিয়ে আসা সম্ভব। অর্থাৎ অ্যালগরিদম ঠিক, key-ও লম্বা, তবু দুর্বল random-এ সব শেষ।

৪ · X.509 certificate — ডিজিটাল পরিচয়পত্র পড়া

শুরুর প্রশ্নটি এবার ফিরে আসে: public key-টি কার? উত্তর হলো certificate. জাতীয় পরিচয়পত্রের মতোই এতে নাম আছে, দাতার পরিচয় আছে, মেয়াদ আছে, আর একটি জিনিস আছে যা কার্ডে নেই: মালিকের public key. পুরোটার ওপর দাতার স্বাক্ষর। মানটির নাম X.509.

নিচের আউটপুট বানানো গল্প নয়। আমরা একটি আলাদা ল্যাব-ফোল্ডারে OpenSSL 3.5.5 দিয়ে lab.example.com নামে একটি self-signed certificate বানিয়ে পড়েছি। এই বানানো certificate-এ কোনো আসল সাইট জড়িত নয়। আউটপুট ছোট করা হয়েছে, আর private key-র কিছুই এতে নেই।

উদাহরণ — আসল রান, ছাঁটা (version-ভেদে বিন্যাস আলাদা হতে পারে): openssl x509 -in test.crt -noout -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            29:0c:63:7b:f4:a8:ff:22:52:9a:d7:48:3c:c9:c8:41:f4:eb:6f:a7
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: O=ABCL Lab Example, CN=lab.example.com
        Validity
            Not Before: Oct 31 13:23:10 2026 GMT
            Not After : Nov 30 13:23:10 2026 GMT
        Subject: O=ABCL Lab Example, CN=lab.example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                ASN1 OID: prime256v1
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:lab.example.com, DNS:www.lab.example.com
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:46:02:21:00:b6:ae:99:87:... (ছাঁটা)

নিজের যন্ত্রে হাতে-কলমে দেখতে ব্রাউজারের তালা-চিহ্ন থেকে certificate দেখে নিতে পারেন, অথবা নিচের কমান্ডগুলো চালাতে পারেন। এগুলো শুধু আপনার নিজের ফোল্ডারের ফাইল পড়ে; কোনো সার্ভারে যোগাযোগ করে না।

# উদাহরণ: নিজের ফোল্ডারে test certificate বানানো আর পড়া
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
  -nodes -keyout test.key -out test.crt -days 30 \
  -subj "/O=ABCL Lab Example/CN=lab.example.com" \
  -addext "subjectAltName=DNS:lab.example.com,DNS:www.lab.example.com"

openssl x509 -in test.crt -noout -subject -issuer -dates
openssl x509 -in test.crt -noout -ext subjectAltName
openssl x509 -in test.crt -noout -fingerprint -sha256
openssl x509 -in test.crt -noout -checkend 0
openssl x509 -in test.crt -noout -checkhost lab.example.com

শেষ দুটি কমান্ড আমাদের ল্যাবে দিয়েছে Certificate will not expire আর Hostname lab.example.com does match certificate. -checkend 0 মানে “এই মুহূর্তে মেয়াদ আছে কি”; সংখ্যাটি সেকেন্ডে, তাই ৩০ দিন আগে সতর্ক হতে 2592000 দিতে পারেন। test.key ফাইলটি এই পরীক্ষার পর মুছে ফেলুন, আর কোনো অবস্থায় কারও সাথে ভাগ করবেন না। -nodes মানে key-তে কোনো passphrase নেই, যা শুধু এমন ল্যাবের জন্য চলে।

Certificate-এর “fingerprint” বা আঙুলের ছাপ আসলে কী? এটি certificate-এর গায়ে লেখা কোনো ঘর নয়। এটি পুরো ফাইলের (DER আকার) hash, যা আপনি নিজেই বের করতে পারেন। নিচের Python কোড আসল hashlib দিয়ে তা করে, আর উপরের সেই test certificate-ই ব্যবহার করে। PEM ফাইলটি শুধু DER বাইটের Base64 রূপ।

# A public test certificate from our lab folder. It holds no private key.
import base64, hashlib

PEM = """-----BEGIN CERTIFICATE-----
MIICFTCCAbqgAwIBAgIUKQxje/So/yJSmtdIPMnIQfTrb6cwCgYIKoZIzj0EAwIw
NTEZMBcGA1UECgwQQUJDTCBMYWIgRXhhbXBsZTEYMBYGA1UEAwwPbGFiLmV4YW1w
bGUuY29tMB4XDTI2MTAzMTEzMjMxMFoXDTI2MTEzMDEzMjMxMFowNTEZMBcGA1UE
CgwQQUJDTCBMYWIgRXhhbXBsZTEYMBYGA1UEAwwPbGFiLmV4YW1wbGUuY29tMFkw
EwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEvBcJrUiqX5xuV8iUmfhveAFJqPXkIRJU
riTrUrIW2agLKit0bHC9qGtp7akM8QKW0SoYylMvgjIjscz/chqxqqOBpzCBpDAd
BgNVHQ4EFgQUYjRAIQ88WjayLysyJsz37e+XX44wHwYDVR0jBBgwFoAUYjRAIQ88
WjayLysyJsz37e+XX44wLwYDVR0RBCgwJoIPbGFiLmV4YW1wbGUuY29tghN3d3cu
bGFiLmV4YW1wbGUuY29tMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMG
A1UdJQQMMAoGCCsGAQUFBwMBMAoGCCqGSM49BAMCA0kAMEYCIQC2rpmHT8O9OHiI
dRCTiUeJ4QiIITYVtOlVPO84Uj/MMwIhAIOPVMgiRR7I3n6xgnGH85DbcUX3IXHO
KC3jwLEQvRG+
-----END CERTIFICATE-----"""
der = base64.b64decode("".join(
    line for line in PEM.splitlines() if "CERTIFICATE" not in line))

def fingerprint(data):
    h = hashlib.sha256(data).hexdigest().upper()
    return ":".join(h[i:i + 2] for i in range(0, len(h), 2))

print("DER bytes    :", len(der))
print("SHA-256      :", fingerprint(der)[:47], "...")
changed = bytearray(der)
changed[100] ^= 1                    # flip one bit
print("after 1 bit  :", fingerprint(changed)[:47], "...")
a = hashlib.sha256(der).digest()
b = hashlib.sha256(changed).digest()
print("same bytes   :", sum(x == y for x, y in zip(a, b)), "of", len(a))

৫ · CA, intermediate, root আর trust store — বিশ্বাস আসে কোথা থেকে

আপনার সার্ভারের certificate-কে বলে leaf. এতে যে CA স্বাক্ষর করে, সে সাধারণত intermediate CA. তার certificate-এ স্বাক্ষর করে root CA. Root নিজের স্বাক্ষর নিজেই করে, তাই গণিত দিয়ে তাকে প্রমাণ করা যায় না। তাকে বিশ্বাস করতে হয় আগে থেকে, আর সেই তালিকাটিই trust store: OS বা ব্রাউজারের সাথে আসা বিশ্বস্ত root-এর তালিকা। Certificate থেকে root পর্যন্ত এই সংযোগই chain of trust.

Root key-কে সরাসরি কাজে লাগানো হয় না কেন? কারণ root key ফাঁস হলে তার ওপর দাঁড়ানো সব certificate অকেজো, আর সব যন্ত্র থেকে root সরাতে বছর লেগে যেতে পারে। তাই root key-কে সাধারণত offline HSM-এ রাখা হয়, মাঝেমধ্যে শুধু intermediate সই করতে বের করা হয়। Intermediate ফাঁস হলে তাকে বাতিল করে নতুন একটি নিলেই হয়। এটি পর্ব ০৩-এর blast radius ছোট রাখার নীতিরই বাস্তব রূপ।

Trust store-এ কারা ঢুকবে, সেটি ঠিক করে root program: Microsoft, Apple, Mozilla, Google আর Linux distribution-গুলোর তালিকা। CA-দের নিয়মিত audit দিতে হয় আর CA/Browser Forum-এর Baseline Requirements মানতে হয়। এই ব্যবস্থার গঠনগত দুর্বলতা হলো, সাধারণভাবে trust store-এর যেকোনো CA যেকোনো domain-এর certificate দিতে পারে। সেজন্য একটি CA ভুল করলে পুরো ওয়েবের ঝুঁকি। এই কথায় আমরা ৮ নম্বর অংশে ফিরব।

৬ · Chain validation — ধাপে ধাপে যাচাই

সার্ভার certificate দিলে আপনার ব্রাউজার কী করে? এই পদ্ধতির নাম path validation, যার আনুষ্ঠানিক নিয়ম RFC 5280-এর ৬ নম্বর অংশে। প্রতিটি library-র ক্রম আলাদা হতে পারে, RFC-র বর্ণনাও root থেকে নিচের দিকে চলে; কিন্তু শর্তগুলো একই, আর একটি ব্যর্থ হলেই পুরো শিকল ব্যর্থ। কল্পিত দিন ১৫০-এ, shop.example.com-এর শিকল ধরে দেখুন।

এবার একই ধারণা কোডে। ছয়টি কল্পিত শিকল, প্রতিটি certificate-এ সত্যিকারের ধাঁচে (খেলনা RSA দিয়ে) স্বাক্ষর আছে। ব্যর্থ হলে কারণও ছাপা হয়। তারিখ কল্পিত, ক্রম leaf থেকে ওপরে।

// Toy chain validator on made-up certificates. Real নয়, শুধু ধারণার জন্য।
const pow = (b, x, m) => { let r = 1n; b %= m;
  for (; x > 0n; x >>= 1n) { if (x & 1n) r = r * b % m; b = b * b % m; } return r; };
const hash = (s, n) => { let h = 7n;
  for (const c of s) h = (h * 131n + BigInt(c.charCodeAt(0))) % n; return h; };
const H = 'shop.example.com', NOW = 150, STORE = ['Toy Root'];  // simulated day 150
const KEYS = { 'Toy Root': [3233n, 17n, 2753n], 'Toy CA': [2773n, 17n, 157n],
               'Rogue CA': [3127n, 3n, 2011n], [H]: [2537n, 5n, 1949n] };  // n, e, d
const tbs = c => [c.sub, c.iss, c.from, c.to, c.ca, c.san].join('/');
function mk(sub, iss, ca, san = '', from = 100, to = 200) {
  const c = { sub, iss, ca, san, from, to }, [n, , d] = KEYS[iss];
  c.sig = pow(hash(tbs(c), n), d, n);
  return c;
}
function validate(chain, host) {          // chain[0] = leaf, last = root
  if (!chain[0].san.split(',').includes(host)) return 'FAIL name not in SAN';
  for (const [i, c] of chain.entries()) {
    const [n, e] = KEYS[c.iss], next = chain[i + 1];
    if (next ? next.sub !== c.iss : c.iss !== c.sub) return `FAIL ${c.sub}: issuer link`;
    if (pow(c.sig, e, n) !== hash(tbs(c), n)) return `FAIL ${c.sub}: bad signature`;
    if (NOW < c.from || NOW > c.to) return `FAIL ${c.sub}: outside validity`;
    if (i > 0 && !c.ca) return `FAIL ${c.sub}: not a CA`;
  }
  return STORE.includes(chain.at(-1).sub) ? 'OK' : 'FAIL root not in trust store';
}
const root = mk('Toy Root', 'Toy Root', true, '', 0, 900);
const ca = mk('Toy CA', 'Toy Root', true, '', 50, 500), leaf = mk(H, 'Toy CA', false, H);
const P = 'pay.example.com', X = 'x.example.com';
for (const [name, chain, host] of [['good chain', [leaf, ca, root], H],
  ['wrong host', [leaf, ca, root], P],
  ['expired leaf', [mk(H, 'Toy CA', false, H, 100, 140), ca, root], H],
  ['edited SAN', [{ ...leaf, san: H + ',' + P }, ca, root], P],
  ['leaf acts as CA', [mk(X, H, false, X), leaf, ca, root], X],
  ['rogue root', [mk(H, 'Rogue CA', false, H), mk('Rogue CA', 'Rogue CA', true, '', 0, 900)], H],
]) console.log(name.padEnd(16), validate(chain, host));

৭ · Revocation আর মেয়াদ — বাতিল করা এত কঠিন কেন

Private key ফাঁস হলে মেয়াদের আগেই certificate বাতিল (revocation) করতে হয়। সমস্যা হলো, certificate ইতিমধ্যে সবার হাতে হাতে ঘুরছে। হারানো পরিচয়পত্রের মতো: কার্ডটি তো আর ফেরত আনা যায় না, তাই একটি তালিকা রাখতে হয়, আর দারোয়ানকে সেই তালিকা দেখতে হয়।

OCSP-র বড় দুর্বলতা হলো soft-fail: উত্তর না পেলে ক্লায়েন্ট সংযোগ চালিয়ে যায়, কারণ responder-এর একটি বিভ্রাটে অর্ধেক ওয়েব বন্ধ হওয়া কেউ চায় না। কিন্তু যে আক্রমণকারী আপনার পথে বসে আছে, সে উত্তরটিই আটকে দিতে পারে। তাই সুরক্ষাটি ঠিক তখনই কাজ করে না, যখন দরকার। পর্ব ০৩-এর fail open আর fail secure-এর দ্বন্দ্ব এখানে সরাসরি দেখা যায়।

গতিপথ এখন স্পষ্ট। Let's Encrypt গোপনতার কারণ দেখিয়ে ২০২৫ সালের ৬ আগস্ট তাদের OCSP responder বন্ধ করেছে, আর CRL-এ চলে গেছে। ব্রাউজারগুলোও নিজেদের সংকুচিত তালিকা বানায় (Chrome-এর CRLSets, Firefox-এর CRLite). আর CA/Browser Forum-এর SC-081v3 ব্যালট (এপ্রিল ২০২৫) সর্বোচ্চ মেয়াদ ধাপে ধাপে কমাচ্ছে: ৩৯৮ দিন থেকে ২০০ দিন (১৫ মার্চ ২০২৬), ১০০ দিন (১৫ মার্চ ২০২৭) আর ৪৭ দিন (১৫ মার্চ ২০২৯)। এই নিয়ম public TLS certificate-এর জন্য; private PKI-তে নিজের নীতি চলে।

মেয়াদ ছোট হলে ঝুঁকির জানালা ছোট, কিন্তু কাজ বেশি। হিসাবটি নিজে দেখুন। একটি কল্পিত তারিখে (১৫ নভেম্বর ২০২৬) চারটি certificate পরীক্ষা করা হলো, আর ২০০টি certificate-এর একটি কল্পিত প্রতিষ্ঠানের বছরের কাজ গোনা হলো।

// Validity window on a fixed simulated date (no real clock).
const DAY = 86400000;
const d = s => Date.UTC(+s.slice(0, 4), +s.slice(5, 7) - 1, +s.slice(8, 10));
const TODAY = d('2026-11-15');
const certs = [
  ['shop.example.com', '2026-09-01', '2026-11-30'],
  ['api.example.com',  '2026-10-20', '2027-01-18'],
  ['old.example.com',  '2026-05-01', '2026-11-10'],
  ['new.example.com',  '2026-11-20', '2027-02-18'],
];
function status(from, to) {
  const f = d(from), t = d(to), life = (t - f) / DAY, left = (t - TODAY) / DAY;
  if (TODAY < f) return `NOT YET VALID (starts in ${(f - TODAY) / DAY} days)`;
  if (TODAY > t) return `EXPIRED ${-left} days ago`;
  // Common habit: renew when one third of the lifetime remains.
  return left <= life / 3 ? `RENEW NOW (${left} of ${life} days left)`
                          : `OK (${left} of ${life} days left)`;
}
for (const [name, from, to] of certs)
  console.log(name.padEnd(17), status(from, to));
console.log('--- renewals per year if renewed at 2/3 of life ---');
for (const days of [398, 200, 100, 47]) {
  const every = Math.floor(days * 2 / 3), n = Math.ceil(365 / every);
  console.log(String(days).padStart(3), 'day cert: renew every', every, 'days =', n,
              'renewals/yr; 200 certs =', n * 200, 'jobs/yr');
}

৮ · CA ভুল করলে কী হয় — DigiNotar আর Certificate Transparency

শিকল যত শক্তই হোক, প্রতিটি CA-ই একটি একক ব্যর্থতার বিন্দু। ২০১১ সালের ঘটনাটি এই সত্যকে সবার সামনে আনে।

রক্ষকের চোখে শিক্ষাটি পরিষ্কার। প্রতিষ্ঠানটি জানত না ঠিক কী কী তৈরি হয়েছে, আর domain-এর মালিকেরও জানার কোনো উপায় ছিল না। জাল certificate আসল certificate-এর মতোই বৈধ দেখায়, তাই সমস্যার মূল ছিল দৃশ্যমানতার অভাব।

Certificate Transparency — প্রকাশ্য রেজিস্টার খাতা

CT জাল certificate তৈরি আটকায় না; সেটি লুকিয়ে রাখা কঠিন করে। কর্মপদ্ধতি তিন ভাগে। CA প্রকাশের আগে certificate-টি কয়েকটি স্বাধীন, শুধু-যোগ-করা (append-only) log-এ জমা দেয়। Log তার রসিদ হিসেবে দেয় SCT (Signed Certificate Timestamp), যা certificate-এর ভেতরে থাকে। ব্রাউজার SCT ছাড়া public certificate গ্রহণ করে না (Chrome ২০১৮ সাল থেকে নতুন certificate-এর জন্য এই শর্ত চালু করেছে; Apple-এরও নিজস্ব নীতি আছে)। আর log-গুলো Merkle tree-র গঠনে থাকে, যাতে পরে গোপনে কিছু মুছলে গণিতে ধরা পড়ে।

আসল কাজটি আপনার: নিজের domain-এর জন্য CT নজরদারি (CT monitoring) চালু রাখা। অচেনা CA বা অচেনা নামে certificate দেখলেই তদন্ত করতে হয়। পাশাপাশি CAA record দিয়ে DNS-এ জানিয়ে দেওয়া যায় কোন CA আপনার domain-এর জন্য certificate দিতে পারবে; CA-দের issuance-এর আগে এটি দেখা বাধ্যতামূলক। CT log-এ নাম প্রকাশ্য হয়, তাই ভেতরের গোপন hostname public certificate-এ রাখা ঠিক নয়।

৯ · Certificate-এর জীবন — ACME, private PKI, code signing আর বাংলাদেশ

CA কী যাচাই করে: DV, OV, EV

ACME আর Let's Encrypt

ACME (RFC 8555, ২০১৯) হলো certificate নেওয়া আর নবায়নের একটি স্বয়ংক্রিয় protocol. উদাহরণ হিসেবে অলাভজনক CA Let's Encrypt এটি ব্যবহার করে; অন্য CA-ও করে। Client প্রমাণ করে যে domain তার নিয়ন্ত্রণে: HTTP-01-এ নির্দিষ্ট URL-এ একটি token রেখে, DNS-01-এ DNS-এ একটি TXT record রেখে। তারপর কাগজে হাত না দিয়েই certificate মেলে। Let's Encrypt-এর সাধারণ মেয়াদ দীর্ঘদিন ধরে ৯০ দিন; তাদের প্রকাশিত পরিকল্পনায় ২০২৮-এর মধ্যে ৪৫ দিনে নামার কথা আছে, আর ঐচ্ছিক ৬ দিনের profile-ও আছে। নিচের ধাপগুলো ৯০ দিনের একটি certificate-এর গল্প।

Private PKI — প্রতিষ্ঠানের নিজস্ব CA

অভ্যন্তরীণ সার্ভিস, VPN, Wi-Fi আর যন্ত্রের পরিচয়ে অনেক প্রতিষ্ঠান নিজস্ব CA চালায়, যাকে বলে private PKI. এতে mTLS দিয়ে সার্ভিসগুলো একে অপরকে চিনতে পারে, আর ভেতরের নাম CT log-এ যায় না। কিন্তু public CA-র যে পাহারা (audit, CT, ব্রাউজারের নজর) ছিল, এখানে তার সবই আপনার দায়িত্ব। Root offline রাখা, আলাদা intermediate, ছোট মেয়াদ, স্বয়ংক্রিয় নবায়ন, issuance-এর log (পর্ব ৫৫), আর revocation-এর পরিকল্পনা লাগবে। আর একটি সতর্কতা: কোনো যন্ত্রের trust store-এ আপনার root বসানো মানে সেই root সেই যন্ত্রে যেকোনো নামের বিশ্বাস পায়। তাই name constraints বিবেচনা করুন, আর শুধু প্রতিষ্ঠানের নিজের যন্ত্রেই বসান। Key রাখার দিকটি দেখতে পারেন Cloud & DevOps-এর secrets আর KMS পর্বে।

Code signing — একটি নোট

Code signing-এ একই ধারণা software-এর ওপর: প্রকাশক স্বাক্ষর করেন, OS বা package manager যাচাই করে। এখানে timestamp গুরুত্বপূর্ণ: certificate মেয়াদোত্তীর্ণ হলেও স্বাক্ষরের সময়ের প্রমাণ থাকলে পুরোনো software বৈধ থাকতে পারে। স্বাক্ষর মানে কিন্তু “কে প্রকাশ করেছে”, “নিরাপদ কোড” নয়। চুরি হওয়া key দিয়ে malware স্বাক্ষরের ঘটনা প্রকাশিত হয়েছে, যেমন ২০১০ সালের Stuxnet-এ। তাই signing key HSM-এ রাখা, আর build pipeline সুরক্ষিত রাখাই আসল কাজ (পর্ব ৪৮)।

বাংলাদেশের প্রেক্ষাপট

বাংলাদেশে ডিজিটাল স্বাক্ষরের লাইসেন্সপ্রাপ্ত CA-দের তত্ত্বাবধান করে Controller of Certifying Authorities (CCA), সরকারি সাইট cca.gov.bd. সাইটটিতে নিজস্ব root CA certificate, লাইসেন্সপ্রাপ্ত CA-র তালিকা আর audit নির্দেশিকা পাওয়া যায়, আর আইনি ভিত্তি হিসেবে তথ্য ও যোগাযোগ প্রযুক্তি আইন, ২০০৬ (২০০৯ ও ২০১৩-এর সংশোধনীসহ) এবং Information Technology (Certifying Authority) Rules, ২০১০-এর উল্লেখ আছে। এই পর্ব লেখার সময় (অক্টোবর ২০২৬) আমরা আইনের নির্দিষ্ট ধারাগুলো সরকারি উৎস থেকে মিলিয়ে নিতে পারিনি, তাই এখানে কোনো ধারা উদ্ধৃত করছি না। কোন দলিলে কোন স্বাক্ষর গ্রহণযোগ্য, সে বিষয়ে bdlaws.minlaw.gov.bd আর CCA-র সর্বশেষ দলিল দেখুন, আর আইনজীবীর পরামর্শ নিন। এটি আইনি পরামর্শ নয়। সাইবার আইনের সাধারণ চিত্রের জন্য দেখুন পর্ব ০৬. খেয়াল রাখবেন, আইনি স্বাক্ষরের CA আর ব্রাউজারের ওয়েব trust store দুটি আলাদা ব্যবস্থা; একটিতে থাকলে অন্যটিতে থাকা নিশ্চিত হয় না।

১০ · AI-এর যুগে certificate সামলানো

Certificate-এর ত্রুটি হাতে নিয়ে AI-কে জিজ্ঞেস করা এখন স্বাভাবিক। উত্তর দ্রুত আসে, কিন্তু প্রায়ই সবচেয়ে সহজ পথটি হয় যাচাই বন্ধ করা। সেটি ত্রুটি সারায় না, নিরাপত্তা সরিয়ে ফেলে।

AI-এর সাহায্য নেওয়ার পরে — চেকলিস্ট

• কোনো private key, token বা গ্রাহকের তথ্য prompt-এ যায়নি
• যাচাই বন্ধ করে নয়, কারণ ধরে সমস্যা সেরেছি
• প্রস্তাবিত অ্যালগরিদম আর আকার বর্তমান মানের সাথে মিলিয়েছি
• উল্লেখ করা RFC আর নিয়ম মূল উৎসে খুলে দেখেছি
• পরিবর্তনটি আগে ল্যাবে চালিয়েছি, আর diff নিজে পড়েছি
• Production-এ বদলানোর সিদ্ধান্ত একজন মানুষ নিয়েছেন, আর ফেরার পথ ঠিক আছে