PKI & certificates

Asymmetric cryptography and PKI (Public Key Infrastructure) underpin TLS, code signing, encrypted email, and certificate authentication. This card covers how the chain of trust works and the attacks that appear when validation is done wrong.

Asymmetric: encryption and signing

KEY PAIR: public (shared) + private (kept secret)
Encryption:  encrypt with the target's PUBLIC key -> only their PRIVATE key decrypts (confidentiality)
Signature:   sign with your own PRIVATE key -> anyone verifies with the PUBLIC key (authenticity)
RSA   based on factoring; use RSA-OAEP (encryption) and RSA-PSS (signing), never raw PKCS#1v1.5
ECC   elliptic curves; short keys, same security; Ed25519 (signing), X25519 (exchange)

The chain of trust (PKI)

Root CA (in the OS/browser truststore)
  └─ signs -> intermediate CA
        └─ signs -> server certificate (CN/SAN = domain, public key, validity)
Validating a cert = verify each link's signature up to a trusted CA
+ check: validity period, that the name (SAN) matches the host, and revocation (CRL/OCSP)

Attacks and flaws (what’s exploitable)

Broken certificate validation (clients/apps)

# the most common flaw in mobile/IoT/custom clients:
- not validating the chain        -> accepts self-signed cert -> MITM
- not checking the hostname (SAN)  -> a valid cert for ANOTHER domain works -> MITM
- accepting expired/revoked certs
# test: intercept with Burp/mitmproxy and see if the client accepts your cert

Signature algorithm confusion (JWT)

# JWT alg=none    -> some verifiers accept a token with NO signature
# JWT RS256->HS256 -> sign with the (known) PUBLIC key as the HMAC secret
#   if the verifier doesn't pin the algorithm. (see web-session / web-api)

Key weaknesses

- RSA with a small key (<2048) or badly generated primes (twin keys from weak RNG, see crypto-rng)
- private key exposed in repos/binaries/firmware -> total impersonation
- PKCS#1 v1.5 padding -> Bleichenbacher/ROBOT (padding oracle over RSA)

Tools

openssl (inspect/forge certs, CSRs, verify chains), mitmproxy/Burp (test client TLS validation).
jwt_tool (JWT attacks), testssl.sh (see TLS), crt.sh (certificate transparency for recon).

Defense

Always validate chain + hostname + validity + revocation; don’t disable verification “to make it work”.
Certificate pinning in high-value mobile apps; use RSA ≥ 2048 / ECC and OAEP/PSS.
Protect the private key (HSM/KMS, permissions); Certificate Transparency and issuance monitoring.
JWT: pin the expected algorithm server-side; reject none and the RS→HS switch.

CVEs and real-world cases

Bleichenbacher / ROBOT (2017): RSA PKCS#1v1.5 padding oracle at major sites.
goto fail (CVE-2014-1266, Apple): a goto skipped TLS signature verification.
DigiNotar (2011): compromised CA issued fake Google certificates → MITM against users in Iran.
Numerous JWT alg=none and RS256/HS256 confusion CVEs in popular libraries.

Testing checklist

Client/app: does it validate chain and hostname? (MITM with Burp/mitmproxy)
Does it accept self-signed/expired/revoked certs?
JWT: try alg=none and RS256→HS256 confusion
RSA key size/quality? Repeated keys (RNG)?
Hunt for leaked private keys (repos/firmware/binaries)
RSA: PKCS#1v1.5 padding vulnerable to an oracle?
Recon: enumerate subdomains via crt.sh (Certificate Transparency)