Lecture-4 Cybersecurity: PKI, Certificates, and Public Key Infrastructure (PKI) Notes

Public Key Cryptography Foundations

• Public Key Cryptography (PKC) enables secure communication over insecure channels, authentication, and data integrity via asymmetric keys.
• Real-world motivation: digital trust from key signers, verifiable issuance, and transparent logging (Certificate Transparency).
• Core concepts include:
  • Symmetric vs Asymmetric encryption and hashing
  • Secure key exchange, digital signatures
  • Digital certificates, Certificate Authorities (CAs), and PKI
  • X.509 certificates, ACME, and short-lived certificates
• Examples of cryptographic usage in daily tech:
  • Email security and secure messaging (TLS 1.3 with RSA/ECDHE and PFS)
  • Banking authentication with MFA and salted hashing (PBKDF2, Argon2)
  • Software provenance via Digital Signatures (Ed25519, ECDSA)
  • Cloud data protection with client-side encryption (AES-256, GCM)
  • E-commerce security with TLS and tokenization
• High-level objective: understand cryptographic functions, PKI, X.509, CAs, and their role in internet trust.

Symmetric vs Asymmetric encryption and hashing

• Symmetric encryption (Secret Key Cryptography)
  • One key for both encryption and decryption.
  • Key must be shared securely beforehand.
  • Fast for large data; examples: AES, ChaCha20, 3DES (legacy).
  • Use cases: VPN traffic, database encryption, full-disk encryption.
  • Key points: requires secure key exchange.
• Asymmetric encryption (Public Key Cryptography)
  • Two keys: Public key (encrypt) and Private key (decrypt).
  • Easy public-key distribution; public key can be shared openly.
  • Slower for large data; used for SSL/TLS certificates, secure email (PGP), digital signatures.
  • Examples: RSA, ECC, Diffie–Hellman (key exchange).
• Hashing
  • One-way function to verify data integrity.
  • Used in digital signatures and message authentication.
• Hybrid approach (common in practice): combine asymmetric for key exchange with symmetric for data encryption to balance security and performance.

RSA: Fundamentals and Worked Example

• RSA overview
  • Based on the difficulty of prime factorization of a large composite number n = pq.
  • Security strength hinges on factoring difficulty; RSA-2048+ bits is commonly recommended today.
  • RSA supports both encryption and digital signatures; used in SSL/TLS and email encryption.
• Key generation (illustrative steps from the transcript):
  • Step 1: Choose primes p and q.
  • Step 2: Compute n = p × q.
  • Step 3: Compute φ(n) (or z as used in the slides):
    
    \varphi(n) = (p-1)(q-1)
    
  • Step 4: Choose public exponent k such that gcd(k, φ(n)) = 1.
  • Step 5: Compute the private exponent j, the modular inverse of k modulo φ(n):
    $k \cdot j \equiv 1 \pmod{\varphi(n)}$
  • Public key: (n, k); Private key: j.
• Worked numerical example from slides:
  • p = 5, q = 13 → n = pq = 65
  • φ(n) = (p-1)(q-1) = 4 × 12 = 48
  • Choose k = 11 (public exponent); ensure gcd(11, 48) = 1
  • Compute j as the modular inverse of 11 mod 48: j = 35 because
    $11 \cdot 35 = 385 \equiv 1 \pmod{48}$
  • Public key: (n, k) = (65, 11); Private key: j = 35
• RSA encryption and decryption demonstrated:
  • Encryption: ciphertext C ≡ m^k (mod n)
  • Decryption: plaintext P ≡ C^j (mod n)
  • Example from slides: with m = 14, n = 65, k = 11, j = 35
    $C ≡ 14^{11} \bmod 65 = 14$
  • Decryption yields P ≡ 14^{35} \bmod 65 = 14
  • Conclusion: decryption recovers the original message when using the correct private key.
• RSA notes
  • Security: resistant to classical computing attacks; future quantum risk if large-scale quantum computers exist.
  • Practical guidance: 2048-bit keys are the minimum for robust security today; 3072-bit+ for long-term protection.
• RSA key generation steps recap (summary formula):
  $n = p q, \quad \varphi(n) = (p-1)(q-1), \quad k \cdot j \equiv 1 \pmod{\varphi(n)}, \quad \text{Public key} = (n, k), \quad \text{Private key} = j$

Elliptic Curve Cryptography (ECC)

• ECC overview
  • Public-key cryptography based on elliptic curves over finite fields.
  • Smaller key sizes can achieve equivalent security to RSA with shorter keys.
  • Benefits: faster computations (good for mobile/IoT), lower bandwidth.
  • Security basis: Elliptic Curve Discrete Logarithm Problem (ECDLP) is hard to solve.
• Simplified ECC key exchange example (conceptual):
  • Alice picks private key a and computes public key A = aG.
  • Bob picks private key b and computes public key B = bG.
  • They exchange A and B; Alice computes SA = aB; Bob computes SB = bA.
  • Both derive the same shared secret S = abG, which can be used for symmetric encryption.
  • Public curve and base point: agreed-upon curve and generator point G.
• ECC advantages: smaller keys, speed, efficiency, and strong security with shorter key lengths.

Hybrid Encryption (RSA + AES) and TLS-style Security

• Rationale
  • RSA secures the exchange of an ephemeral AES session key; AES protects the payload data.
  • Hybrid approach combines the best of both: RSA for key exchange and AES for data encryption.
• TLS/HTTPS flow (high-level)
  • Sender generates a random AES session key.
  • AES key is encrypted with recipient's RSA public key and sent.
  • Recipient decrypts AES key with private key and uses it for subsequent data encryption.
  • All following data is encrypted with AES (fast) and authenticated (e.g., AES-GCM).
• Benefits
  • Speed of AES for bulk data.
  • Forward secrecy if ephemeral keys are used.
  • Security of RSA for key exchange.

Public Key Infrastructure (PKI) and Certificate Authorities (CAs)

• PKI purpose
  • Framework to manage public key encryption, including software, hardware, policies, and processes for creating, distributing, storing, and revoking digital certificates.
  • Provides secure communications, authentication, and data integrity.
• Core PKI components
  • Certificate Authority (CA): trusted third party that verifies identity, binds identity to a public key, issues digitally signed certificates, and maintains a Certificate Revocation List (CRL).
  • Digital certificates: bind a public key to an entity’s identity; include owner, organization, public key, serial number, issuing CA; enable authentication, encryption, and signatures; follow X.509.
  • X.509 standard: defines certificate format, fields, and validation rules; enables cross-platform compatibility; supports certificate chaining and key usage policies.
  • ACME (Automatic Certificate Management Environment): automation protocol for obtaining and renewing certificates (e.g., Let’s Encrypt).
  • Certificate Transparency: public logging of certificate issuance to detect mis-issuance.
• Why trust matters
  • Trust depends on who signs your key, whether issuance is transparent and verifiable.
• PKI architecture goals
  • Global trust, automation (ACME), short-lived certificates, revocation mechanisms, and transparent logging.

X.509 Certificates: Structure and Lifecycle

• What a certificate does
  • Verifies identity and binds it to a public key; enables secure TLS and digital signatures.
• Certificate types (DV, OV, EV)
  • DV (Domain Validation): domain ownership validated; quick; no organization identity check; best for blog sites.
  • OV (Organization Validation): domain ownership plus organization identity checks; better for business sites.
  • EV (Extended Validation): strongest assurance; extensive identity verification; displays organization name in the browser; highest trust but longer issuance and higher cost.
• Validation workflows (DCV, etc.)
  • Domain Control Validation (DCV): via email, file, or DNS token.
  • Organization verification for OV/EV includes entity existence and contact details.
• Certificate types and use cases
  • EV: banks, large e-commerce, government portals; high assurance.
  • OV: medium-sized businesses, NGOs; extra credibility.
  • DV: blogs, personal sites, development/test servers; quick and cheap.
• Digital certificate lifecycle
  • Creation and signing by CA using CA’s private key.
  • Verification by relying parties using CA’s public key.
  • Validity period; certificates expire and must be renewed.
  • Revocation if private key compromised, identity changes, policy non-compliance, or CA compromise.
• X.509 certificate fields (highlights)
  • Mandatory: version, serial number, signature algorithm, issuer, validity, subject, subject public key info, and signature.
  • Optional: extensions (key usage, extended key usage, CRL distribution points, authority information access, etc.).
• Verification steps (summary)
  • Check issuer against trusted root CAs.
  • Check that the certificate is valid (not expired).
  • Check that the certificate’s subject matches the domain (CN and SAN).
  • Verify the CA’s digital signature with the CA’s public key.
  • Check for certificate revocation (CRL/OCSP).

Certificate Authorities (CAs), Root and Intermediate CAs, and the Chain of Trust

• Root CA
  • Top-level authority; self-signed certificate; root private key kept offline for security.
  • Root public keys are pre-installed in operating systems and browsers to establish trust anchors.
  • Without root trust, the entire chain fails.
• Intermediate CAs
  • Delegated by Root CA to issue certificates; a layer between root and end-entities to limit risk.
  • If an intermediate CA is compromised, the root CA can revoke or reissue trust without affecting the entire chain.
• Certificate chain example (conceptual)
  • Root CA → Intermediate CA(s) → End-entity certificate (domain owner).
• Practical chain verification
  • Example: verifying a PayPal certificate requires the intermediate to bridge to the root; the chain is validated against the root in the trust store.
• Self-signed certificates
  • Not inherently trusted; trust depends on distribution path (OS/software pre-vetted stores or manual trust decisions).
  • Risks: external, unsolicited self-signed certs pose high security risks; verify distribution method.

Managing PKI Trust and Certificate Validation in Browsers

• Trust stores
  • Browsers and OSes pre-install trusted root CAs; verify end-entity certs against these roots.
• Manual verification and trust decisions
  • Self-signed certs require trusted distribution; otherwise should be avoided.
• Real-world browser trust landscapes
  • Different CAs are trusted by different platforms; Let’s Encrypt dominates >60% of market; others include Sectigo/Comodo, GoDaddy, GlobalSign, IdenTrust, etc.
• How to inspect trusted CAs
  • Chrome: Settings → Security → Manage Certificates
  • Firefox: Settings → Privacy & Security → Certificates → View Certificates

Man-in-the-Middle Attacks (MITM) and PKI Defenses

• MITM concept
  • An attacker intercepts TLS handshakes by presenting a forged or stolen certificate; the goal is to decrypt or alter communications.
• PKI defense strategy
  • The browser validates the server certificate against trusted CAs; if not signed by a trusted CA, a warning is shown.
  • The certificate must match the domain (CN/SAN) to prevent hostname spoofing.
  • Certificate binding of identity to public keys and certificate transparency help detect mis-issuance.
• MITM defense scenarios
  • If the attacker forwards a real certificate, the private key remains unknown to the attacker, so decryption cannot be performed; the channel remains secure unless there is a different vulnerability.
  • If the attacker creates a fake certificate, trusted CAs should not sign it; if the browser cannot validate, it warns or blocks the connection.
  • If the attacker uses a self-signed cert trusted by the user’s device (via a malicious proxy), the MITM succeeds unless additional checks (domain binding, CT) fail or user distrust prompts action.

MITM Mitigation via Digital Signatures and CA-based Certification

• Certificate binding of identity to public key by a trusted CA ensures trust in the public key only if the CA is trusted.
• Steps in a certificate-based handshake (high level)
  1. Client requests a secure connection to a domain.
  2. Server presents its certificate chain; the client validates it against root CAs.
  3. If validation passes, the client uses the server’s public key to establish a secure channel (e.g., via TLS with ephemeral keys).
• Role of CA signatures
  • CA signs the certificate with its private key; verification uses CA’s public key.

MITM Attack Scenarios and Defenses: Practical Illustrations

• Attacker forwards the authentic certificate
  • The attacker cannot decrypt traffic without the server’s private key.
  • Only disruption possible is a DoS if the attacker blocks the legitimate handshake.
• Attacker creates a fake certificate
  • If the attacker cannot get CA signature for the domain, the browser flags a warning.
  • Self-signed certs lead to user warnings/errors unless the self-signed cert is somehow trusted by the user’s environment.
• Attacker presents a certificate for a different domain
  • The browser checks the hostname against the certificate's subject; a mismatch terminates the handshake.
• Critical validation: Common Name (CN) and Subject Alternative Name (SAN)
  • TLS handshakes validate CN and/or SAN against the target hostname; failing to verify CN/SAN exposes MITM risk.

Side-Channel Attacks and Defenses

• Side-channel attack overview
  • Exploit physical leakage (power, EM, timing) to extract secrets like keys.
• Common mitigations
  • Constant-time implementations: avoid data-dependent branches and table lookups.
  • Blinding/masking: randomize intermediate values in crypto ops (e.g., RSA/ECDSA nonce randomness).
  • Shielding hardware and adding noise in power/EM, fixed-rate sampling.
  • Use constant-time cryptographic libraries and routines (AES, RSA/ECC).
• Defensive steps
  • Replace vulnerable code with constant-time implementations.
  • Apply RSA blinding and ECC nonce randomization.
  • Test with side-channel tools and monitor for anomalies (power/EM patterns).

Chosen-Ciphertext Attacks (CCA) and AEAD/OAEP Solutions

• Problem
  • An attacker can submit a ciphertext to a decryption oracle and obtain plaintexts, gradually leaking information.
• Solution: Use CCA-secure schemes and hide decryption errors
  • Prefer AEAD (AES-GCM or ChaCha20-Poly1305) which provides encryption and authentication.
  • If RSA is needed, use RSA-OAEP (not PKCS#1 v1.5) to avoid padding-oracle weaknesses.
  • Decrypt only after authentication passes (verify-then-decrypt).
  • Make failure paths indistinguishable in time and content; apply rate limits and logging on decryption endpoints.
• Result
  • Crafted ciphertexts reveal nothing; decryption vulnerabilities are mitigated.

Key Management and Lifecycle Security

• Key management attacks and mitigations
  • Poor key storage and handling increase risk; protect private keys with hardware devices.
• Solutions using HSMs/TPMs/secure enclaves
  • Store private keys in hardware security modules; separate duties and limit access (RBAC, MFA).
  • Key rotation and revocation on schedule or event-driven.
• Practical steps for key lifecycle management
  • Encrypt keys at rest and in transit; split knowledge (M-of-N).
  • Maintain an inventory: owner, purpose, algorithm, key length, expiry.
  • Continuous backups and recovery testing; monitor for key misuse.
• Result
  • Even if servers are compromised, keys remain protected or quickly unusable.

Brute-Force Attacks and Password-Dolicy Hardening

• Attack model
  • Automated guessing of passwords/derived keys with high-powered hardware.
• Defensive measures
  • Use large, modern key sizes: RSA ≥ 2048-bit, ECC ≥ 256-bit, AES-256.
  • For passwords/derived keys: employ high-cost KDFs (PBKDF2, bcrypt, scrypt, Argon2).
  • Throttle attempts: rate limits, exponential back-off, account lockouts, CAPTCHA, MFA.
  • Enforce strong randomness (CSPRNG) for keys and nonces.
  • Add two-factor or multi-factor authentication for logins and key usage.
• Outcome
  • Larger search space makes online guessing impractical and reduces risk.

Key Management Tools and Practical Ecosystem

• Common PKI tools and utilities for certificate management include:
  • Kleopatra (OpenPGP/X.509 management) – Windows/Linux
  • GnuPG (GPG) – cross-platform CLI/OpenPGP
  • Mailvelope – browser-based OpenPGP for email
  • AES Crypt, AxCrypt, Encrypto – file encryption tools
  • GPG Suite (macOS) – OpenPGP integration for Apple Mail
  • WinGPG – Windows OpenPGP management
• Purpose of tools
  • Manage keys and certificates, encrypt/sign data, and facilitate secure communications across platforms.

How PKI Works in Practice (Papers, Resources, and Real-World Usage)

• PKI in practice: PKI provides the framework to create, distribute, manage, store, and revoke certificates to enable secure communications and authentication.
• Real-world references and tutorials include cloud-provider guides, vendor docs, and standards RFCs. Use these to understand certificate chaining, revocation, and cross-platform trust.
• Important concepts to remember:
  • Trust anchors (root CAs) are pre-installed in browsers/OS; chain must lead to a trusted root.
  • End-entity certificates bind public keys to domain identities and/or organizations.
  • Revocation mechanisms (CRL, OCSP) ensure compromised certificates are not trusted.
  • Certificate transparency logs help detect mis-issuance and malicious CA behavior.

X.509 Certificates: Standard and Validation Details

• Mandatory vs optional fields (highlights)
  • Version, serial number, signature algorithm, issuer, validity, subject, subjectPublicKeyInfo, and signature.
  • Extensions provide additional attributes and constraints (e.g., key usage, extended key usage).
• Verification workflow (high level)
  • Validate certificate chain up to a trusted root.
  • Check signature using CA’s public key.
  • Check validity period and revocation status.
  • Verify that the domain (CN/SAN) matches the intended host.
• Certificate Extension examples
  • KeyUsage: digitalSignature, keyEncipherment, etc.
  • ExtendedKeyUsage: serverAuth, clientAuth, codeSigning, etc.

Real-World Case Studies and Threat Landscape

• Case study: DigiCert DCV Failure (July 2024)
  • Validation fault allowed issuance of 83,000+ invalid certificates; revocations caused outages.
• Case study: Entrust distrust (November 2024)
  • Browsers blocked new certs from Entrust roots due to repeated compliance issues.
• Case study: Let’s Encrypt renewal failure (April 2024)
  • Geoblocked domains renewal failure due to CT perspective changes.
• Case study: GoDaddy SCT Logging incident (May–June 2025)
  • Thousands of Safari-failing certs due to CT log misconfig.
• Collective impact
  • Service outages, loss of trust, and emergency browser/CRL/OCSP responses to maintain ecosystem integrity.

Case Studies: Trust and Certification Distrust Scenarios

• DigiCert/DV/CT narrative: Validation faults can undermine a CA’s trust and issuance confidence.
• Chunghwa Telecom & Netlock (Google Chrome distrust): Trust decisions can be based on behavior patterns; legacy certs may remain valid for a grace period but new ones will be distrusted.
• Takeaway: Non-technical trust failures (policy, compliance, governance) can undermine PKI even when cryptographic primitives remain strong.

Attacks on Cryptographic Algorithms and Hash Functions

• Background context
  • Certificates rely on hash functions (e.g., SHA) and digital signatures (e.g., RSA, ECDSA).
• Notable vulnerabilities and trends
  • SHA-1 collision (2020): identical hashes across different files; undermined collision resistance.
  • HashDiff (2023): weaknesses in Merkle trees affecting SHA-256 preimage/partial collision properties.
  • Quantum era (2024–2025): experiments suggesting potential quantum-era risks to SHA-256; drives move towards post-quantum-safe schemes and hybrid cryptography.
• Countermeasures
  • Deprecate SHA-1 and move toward stronger hash functions; migrate to post-quantum safe hash functions.
  • Use hybrid cryptography combining classical and quantum-safe approaches for future resilience.
  • Encourage routine certificate rotation and timely revocation of weak algorithms.

Attacks on User Confirmation and Phishing Awareness

• Attack vectors in practice
  • Phishing sites using valid but misissued certificates.
  • Wildcard certificates misused for subdomain impersonation.
  • Homograph attacks using mixed scripts (punycode) to mimic legitimate domains.
• Security flaws and improvements
  • Inadequate CN/SAN verification by clients can enable MITM/impersonation.
  • Stronger domain validation, SAN checks, and robust UI warnings help mitigate risks.
• Notable incidents and mitigations
  • 2022 Let’s Encrypt cert misuse for phishing; 2023 EV punycode mismatch bug; emphasis on strict validation and user warnings.
• Countermeasures
  • Strict domain & SAN validation in client software.
  • Enhanced UI warnings for suspicious domains.
  • Regular certificate transparency monitoring.

Diffie–Hellman (DH) Key Agreement and Man-in-the-Middle Wrestles

• DH overview
  • Allows two parties to establish a shared secret over an insecure channel without encrypting the initial values.
  • Based on the difficulty of computing discrete logarithms.
• DH operational sketch
  • Parameters: public prime q and generator α; private keys XA and XB; public values YA = α^{XA} mod q and YB = α^{XB} mod q.
  • Shared secret: K = α^{XA XB} mod q = YB^{XA} = YA^{XB} mod q.
• MITM scenario in DH
  • An attacker (Darth) can intercept and substitute public values, deriving different shared keys with each party, thus compromising confidentiality.
• Defenses against DH MITM
  • Use signatures on DH parameters (e.g., RSA/ECDSA-based digital signatures) and leverage PKI to bind identities to keys.
  • Certificate-based authentication ensures the public keys are tied to real entities.

Identity-Based Encryption (IBE) and Secure Email (brief)

• IBE concept
  • A cryptographic primitive where a user’s identity (e.g., email) can act as a public key, with a private key generated by a trusted authority.
  • Enables secure email and messaging without traditional public-key distribution.
• References and resources
  • Various security wikis and standards discuss IBE and related identity-based cryptography approaches.

User Authentication and Credential Security

• Password authentication maturity ladder (highlights from the slides)
  • Level 1: Password-only (weak).
  • Level 2: Password + second factor (e.g., authenticator app).
  • Level 3: Passwordless approaches (e.g., FIDO2 security keys, Windows Hello).
  • Level 4+: Hardware-backed or biometric-based, continuous authentication.
• Stronger authentication modalities
  • SMS-based one-time codes (less secure) vs authenticator apps and hardware security keys.
  • Passwordless and hardware-based MFA (FIDO2) offer stronger security against credential theft.

Summary: Takeaways for Exam Preparation

• Public Key Cryptography underpins secure communication, authentication, and integrity of data.
• PKI provides a framework to manage keys and certificates, with CAs and chains of trust.
• Digital signatures ensure integrity and origin authentication; X.509 certificates define how identities and keys are bound.
• Browsers verify certificates against trusted CAs, ensuring domain identity via CN/SAN and cross-checking with CT logs and revocation mechanisms.
• Common attacks include MITM, side-channel, chosen-ciphertext, and DH-based MITM; mitigations include CA-based trust, AEAD schemes, RSA-OAEP, constant-time implementations, and robust key management.
• Real-world incidents highlight the importance of certificate validation, revocation, and governance in PKI ecosystems.
• Understanding key sizes, hash function evolution (SHA-1 to SHA-2/3 and post-quantum options), and hybrid cryptography is essential for future security planning.