Asymmetric Cryptography and Public Key Infrastructure (PKI) Questions

Solid grasp of public-key algorithms including RSA, elliptic curve cryptography (ECC), and Diffie-Hellman key exchange. Understand key generation processes, mathematical principles underlying their security, and why larger keys are needed compared to symmetric cryptography. Know digital signatures, signature verification, and their role in authentication. Understand PKI architecture including certificate authorities (CAs), trust models, certificate chains, revocation mechanisms, and certificate validation. Be able to discuss modern PKI standards and practices.

MediumTechnical

47 practiced

For a high-scale web service handling millions of TLS connections per day, evaluate revocation strategies including CRLs, OCSP, OCSP stapling, short-lived certificates, and certificate pinning. Recommend a practical combination to balance latency, privacy, scalability, and timely revocation and explain operational considerations for implementation and monitoring.

Sample Answer

**Situation & goal**

For a high-scale service (millions TLS connections/day) we need timely revocation, low latency, user privacy, and scalable backend load. I recommend a hybrid approach that prioritizes availability and operational simplicity while preserving strong revocation semantics.

**Recommended combination**

- OCSP stapling (server-side) as primary: reduces client latency and preserves most privacy; servers staple a current OCSP response per TLS handshake.- Short-lived leaf certificates (1–7 days) to minimize window of compromise and reduce reliance on revocation for routine key rotation.- OCSP must-staple for clients that support it (enforce policy) so clients reject missing stapled responses when required.- Fallback: allow client OCSP only for emergency revocations; avoid CRL for scale reasons.- Pinning only for high-value internal APIs (HPKP avoided publicly); use pinning via trusted pin-management (Pin-Sharing via MDM for enterprise).

**Why this balances constraints**

- Latency: stapling eliminates extra client RTT to CA.- Privacy: stapling avoids client contacting CA; short-lived certs limit exposure.- Scalability: CA issues short certs and produces OCSP responses; use CDN/edge caching of OCSP responses.- Timeliness: revocation via OCSP ("revoked" status) plus short cert lifetime constrains exposure.

**Operational considerations**

- Automate issuance/renewal (ACME or internal CA) with safe private-key handling and hardware security modules.- Ensure OCSP responder HA: behind load balancers, horizontally scaled, with aggressive caching TTLs and push-update on revocation.- Monitor metrics: stapled-response age, OCSP responder latency/error rates, certificate expiry timeline, issuance failure rates, and client rejection rates.- Test failure modes: responder outage (serve last good response until expiry), key compromise drills, and rollback.- Logging & alerting: anomalous revocation spikes, sudden increases in stapling misses, and CA account usage.- Compliance: specify policy in certificate profiles and in client behavior (must-staple enforcement).

This combination gives low-latency, privacy-aware validation with operationally tractable revocation windows suitable for high-scale TLS deployments.

HardSystem Design

47 practiced

Design a scalable PKI to provision and manage identities for tens of millions of IoT devices. Devices are low-resource, may be manufactured offline, and require secure boot, OTA updates, and robust revocation. Cover provisioning models (per-device credentials, group credentials, hardware-rooted identities), CA hierarchy, HSM placement, certificate lifetimes, offline revocation handling, privacy, and cost-effective operational concerns.

Sample Answer

**Clarify requirements & constraints**- Tens of millions devices, constrained CPU/flash, some manufactured offline, must support secure boot, OTA, robust revocation, low cost, privacy-preserving.

**High-level approach**- Hybrid PKI: per-device hardware-rooted identity where possible; group credentials fall back when no secure element. Root CA offline; issuing CAs (intermediate) online and scoped by region/product.

**Provisioning models**- Hardware-rooted: TPM/SE/MCU-unique secret (e.g., ECC keypair + device ID) injected at manufacturing — best for secure boot + non-exportable keys.- Per-device credentials: X.509 v3 with device serial + EK attestation extension; short-lived device certs (ECDSA P-256/ED25519).- Group credentials: for ultra-low-cost devices, use manufacturer-signed group key rotated frequently and constrained to limited trust scope; pair with device-unique symmetric key for authentication when possible.- Offline manufacturing: batch enroll using CSR signed by factory HSM; devices store factory-signed bootstrap token then request per-device cert on first network contact (just‑in‑time enrollment).

**CA hierarchy & HSM placement**- Root CA: air-gapped, offline, long lifetime (10–20y), signs offline intermediates.- Intermediate CAs: scoped (region/product/firmware domain), hosted in HSMs in cloud HSM clusters (FIPS 140-2/3) with multi-AZ redundancy and strict KM policies.- Issuing servers: stateless microservices signing via HSM-clients with short session keys; hardware-backed key wrappers for OTA signing keys in separate HSMs.

**Certificate lifetimes & algorithms**- Device identity certs: short-lived (30–90 days) with automated renewal to limit revocation window. Use ECDSA P-256 or Ed25519 for compactness and performance.- Firmware signing certs: mid-length (1–3 years) rotated and pinned by devices via live root store updates.- Root CA: long (10–20 years) offline.

**Revocation & offline handling**- Use combination of OCSP stapling, delta-CRLs, and short cert lifetimes to reduce reliance on revocation lists.- For offline devices or intermittent connectivity: include revocation epoch and signed revocation tokens in update metadata; devices check update metadata signature and local revocation epoch before applying.- Use verifiable revocation logs (Merkle tree) published periodically; devices can verify proofs of non-revocation compactly.- For emergency revocation: publish short delta to CDN; devices accept signed revocation epochs and refuse certs issued before invalidation time.

**Secure boot & OTA**- Secure boot checks device identity cert against CA chain and verifies firmware signature (detached signature with cert chain). Enforce rollback protection via monotonic counters or signed version counters anchored in device SE.- OTA updates signed by firmware signing key in HSM; devices verify signature and revocation epoch before install.

**Privacy**- Avoid embedding global serials in network-visible certificates; use ephemeral pseudonyms (short certs with randomized subjectAltName) and anonymous attestation where feasible. Use minimal telemetry.

**Operational & cost considerations**- Automate enrollment/rotation with ACME-like protocol adapted for constrained devices (lightweight DTLS/EST). Scale issuing with regional HSM pools and caching of signed certs for mass operations.- Use standardized curves for hardware acceleration, and batching of CRL/epoch pushes over CDNs to reduce bandwidth.- Logging & audits: sign all issuance/revocation events, store in append-only ledger for forensics.

**Trade-offs**- Per-device hardware root gives best security but higher BOM; group keys lower cost but larger blast radius. Short cert lifetimes reduce revocation need but increase enrollment load—mitigated by automated renewal and efficient HSM usage.

MediumTechnical

50 practiced

Given a TLS 1.2 handshake where the client receives a server certificate, enumerate the precise steps the client must perform to validate that certificate. Include chain building with intermediates, signature verification on each certificate, extension checks (basicConstraints, keyUsage, EKU), hostname verification, revocation checks, and treatment of missing or expired intermediates.

Sample Answer

**Overview — goal:** verify authenticity, integrity, and suitability of the server certificate chain presented during TLS 1.2 before using the key.

1. Chain building- Collect leaf and any provided intermediates from ServerHello/certificate. - Attempt to build a chain from leaf → intermediates → trust anchor (local root store). - If a needed intermediate is missing, attempt to fetch via AIA/OCSP/locally cached intermediates; failing that, chain build fails (unless local policy allows fetching).

2. Signature verification (for each cert in chain, bottom→top)- For each cert C_i (leaf up to but not including root): - Check C_i.signature verifies with issuer’s public key from issuer cert C_{i+1}, using the signature algorithm and proper hashing (respect algorithm constraints, e.g., reject MD5). - Ensure issuer name in C_i matches subject in C_{i+1}.

3. Time / validity checks- Verify current time ∈ [notBefore, notAfter] for each cert. Expired/malformed intermediates cause chain invalidation unless policy permits stapling/OCSP-signed exceptions.

4. Extension & constraints checks- basicConstraints: for each non-leaf cert used as an issuer, basicConstraints.cA must be TRUE and pathLen respected. Reject if absent when required. - keyUsage: ensure issuer cert permits signing (keyCertSign, cRLSign) for CAs; ensure leaf cert’s keyUsage permits its intended TLS role (digitalSignature, keyEncipherment) per key types. - extendedKeyUsage (EKU): check leaf contains serverAuth (1.3.6.1.5.5.7.3.1) if present; if EKU present and lacks serverAuth, reject. For intermediates, EKU constraints must be obeyed if marked critical.

5. Hostname verification- Match server identity against leaf cert: prefer subjectAltName DNS names (wildcards per RFC 6125); fallback to CommonName only if SAN absent. Implement wildcard rules carefully (do not match multiple labels unless allowed).

6. Revocation checks- Perform CRL and/or OCSP checks according to policy: - Prefer OCSP (and OCSP stapling from server if present). - If OCSP responds GOOD, proceed; if REVOKED, fail immediately. Unknown/malformed responses may trigger CRL check or policy-dependent soft-fail vs hard-fail. - For CRLs, ensure freshestNextUpdate and validate CRL signature chain.

7. Treatment of missing/expired intermediates- If an intermediate in the chain is expired: reject chain unless alternative valid path exists. - If intermediate missing: attempt AIA fetch; if fetch returns a valid intermediate, re-run chain build and validations. Cached/stapled intermediates may be acceptable per policy.

8. Final policy checks and decision- Ensure final chain anchors to a trusted root. Enforce algorithm constraints (minimum hash/key sizes), reject deprecated algorithms. Apply organizational policy (e.g., OCSP must succeed). Return success only if all checks pass.

Notes: log failures with specific reason (signature, expiry, revocation, EKU, hostname) for forensics and debugging.

HardTechnical

42 practiced

A major intermediate CA in your corporate PKI was compromised and used to issue fraudulent certificates. As the lead cryptographer, outline a comprehensive incident response plan covering detection, containment, revocation and blacklisting strategy, re-issuing keys and certificates, root or intermediate replacement, coordinating with browser/OS vendors, using CT/OCSP to propagate revocation, and legal/audit actions.

Sample Answer

**Situation & objectives** I would lead a rapid, measurable response to stop abuse, restore trust, and prove root-cause — preserving forensic evidence and minimizing impact to customers.

**Detection & Triage**- Immediately validate compromise indicators (suspicious certs in CT logs, unexpected issuance patterns, anomalous signing key use).- Snapshot and preserve CA HSM logs, audit trails, OCSP/CRL servers, and CT records; isolate systems for forensic imaging.- Raise severity to incident response (IR) and legal teams; brief execs with impact assessment.

**Containment**- Take compromised intermediate offline and revoke its signing capabilities at the CA orchestration layer.- Quarantine affected CA servers/HSMs; rotate admin credentials and revoke API keys.- Implement short-term mitigations: block issuance endpoints, enforce strict issuance approvals.

**Revocation & Blacklisting**- Immediately issue CRLs and OCSP responses marking the intermediate revoked with high priority.- Publish revocation in CT-equivalent feeds and coordinate with major browsers/OS vendors to push short-lived blacklist entries (safari/chrome/moz/Windows).- Use Certificate Authority Authorization (CAA) and DNS records to prevent new issuance from other CAs unless authorized.

**Re-issuing Keys & Certificates**- Generate new intermediate on hardened HSM with fresh key material, using multi‑party authorization (MPC or quorum HSM policies).- Re-issue end-entity certs only when necessary (high-value / actively used). Prefer short-lived certs and automated re-issuance pipelines (ACME-like) to reduce manual workload.- Communicate clear revocation/reissue lists and provide tooling/scripts for customers to validate and replace.

**Root/Intermediate Replacement**- If root is unaffected: create a new intermediate with strong assurance and revoke compromised intermediate.- If root is suspected: schedule coordinated root rollover with cross-signed transition intermediates, publish timelines, and provide compatibility guidance.- Ensure new keys use current best-practice algorithms/curves and HSM FIPS/CC compliance.

**Coordination with Browser/OS Vendors**- Engage immediately through security channels (bug trackers, security@, vendor PSIRT). Provide evidence, timelines, and CT entries.- Request expedited distrust/blacklist where necessary and provide wording for security advisories.- Publish transparent timelines and progress updates for vendors to synchronize trust store changes.

**Using CT/OCSP to Propagate Revocation**- Log all revoked certs to CT with explicit revocation markers to aid detection.- Set OCSP responses to “revoked” and use short OCSP TTLs; publish CRLs and Delta-CRLs aggressively.- Encourage clients to use OCSP stapling and short-lived certs; monitor CT logs for remaining fraudulent certs and request CT operators to block submissions if applicable.

**Legal, Audit & Postmortem**- Preserve chain-of-custody; work with forensics and legal to document evidence for prosecution/regulatory reporting.- Trigger mandatory breach notifications per law and industry regulations; offer affected customers remediation support.- Conduct a root-cause analysis, produce an internal/external report, update CA policies (e.g., multi-signer, offline signing, improved monitoring), and run tabletop exercises to validate improvements.

**Key principles**- Rapid containment + transparency, cryptographic best practices (HSM + MPC), coordinated vendor engagement, and durable audit evidence to restore trust.

MediumTechnical

47 practiced

Write pseudocode for a constant-time modular exponentiation routine suitable for RSA exponentiation that reduces timing leakage. Explain how your method ensures a constant control flow and avoids branching on secret exponent bits, and discuss the performance trade-offs compared to a naive square-and-multiply implementation.

Sample Answer

**Approach (brief)**

Use a fixed-sequence Montgomery ladder (or fixed-window with dummy operations) that performs the same operations regardless of secret exponent bits. Ladder keeps control flow identical per bit, using conditional moves (CMOV) or arithmetic masks instead of branches.

**Pseudocode**

pseudo

# inputs: base x, exponent e (n-bit), modulus m
# output: x^e mod m
R0 = 1            # accumulator for result
R1 = x mod m      # accumulator for "running" base

for i from n-1 downto 0:
    bit = (e >> i) & 1
    # compute without branching: use mask to select
    # t0 = R0 * R1, t1 = R1 * R1
    t0 = montmul(R0, R1, m)
    t1 = montmul(R1, R1, m)
    # Constant-time selection via mask (no branch)
    R0 = ct_select(bit, t0, R0)   # if bit==1 then t0 else R0
    R1 = ct_select(bit, t1, t0)   # choose next R1 deterministically
# ct_select implemented using bitmask and arithmetic: (mask & a) | (~mask & b)
return R0

**How it prevents timing leakage**- Control flow identical each iteration: same number and type of multiplications and assignments.- No data-dependent branches or early exits; secret bits only affect values via constant-time masked selects (bitwise ops and arithmetic).- Use constant-time Montgomery multiplication and avoid memory access patterns that depend on secrets.

**Trade-offs vs naive square-and-multiply**- Security: Much stronger against timing/branch-based side channels.- Performance: ~2x more multiplications than square-and-multiply on average (ladder does two muls per bit); masked selects add cheap bitwise ops.- Implementation complexity: Slightly higher—requires careful constant-time primitives (CMOV/masks, montgomery) and attention to constant-time memory access.

Use fixed-window with dummy multiplies if performance demands a middle ground; it reduces multiplications but requires more dummy work and careful precomputation to keep control flow constant.

Unlock Full Question Bank

Get access to hundreds of Asymmetric Cryptography and Public Key Infrastructure (PKI) interview questions and detailed answers.

Join thousands of developers preparing for their dream job.