Skip to content

Private Key Protection

TL;DR: Private keys are the foundation of PKI security—their compromise allows impersonation, decryption of traffic, and complete trust breakdown. Protection requires defense in depth: HSMs or secure key storage, encryption at rest, strict access controls, comprehensive auditing, and key rotation policies.

Overview

In asymmetric cryptography, the private key is the secret that must never be exposed. While certificates and public keys are distributed freely, the private key must be protected with extreme rigor. A compromised private key means an attacker can impersonate the legitimate key owner, decrypt previously encrypted traffic (without forward secrecy), and sign malicious content as if it came from a trusted source.

Private key protection is not a one-time implementation but an ongoing operational discipline. Keys must be protected during generation, storage, usage, backup, and destruction. The protection level must match the key's criticality: a CA root key requires maximum protection (offline HSM, multi-person access), while a short-lived service key may use cloud KMS with automated rotation.

Every major PKI breach—from DigiNotar to CodeSigning certificate compromises—ultimately traces to inadequate private key protection. Understanding the threat model, implementing appropriate controls, and maintaining operational discipline are non-negotiable for PKI security.

Related Pages: Ca Architecture, Hsm Integration, Certificate Lifecycle Management, Ca Compromise Scenarios

Key Concepts

The Private Key Threat Model

What Attackers Can Do With Private Keys

Server/Device Certificate Private Key:

  • Impersonate the server or device
  • Perform man-in-the-middle attacks
  • Decrypt past TLS traffic (if no forward secrecy)
  • Sign malicious content appearing to come from legitimate source

Code Signing Private Key:

  • Sign malware appearing to come from legitimate software vendor
  • Bypass application whitelisting controls
  • Compromise software supply chain
  • Damage reputation of legitimate vendor

CA Private Key (catastrophic):

  • Issue trusted certificates for any identity
  • Create rogue intermediate CAs
  • Complete breakdown of trust hierarchy
  • Potential for national-scale attacks (see DigiNotar case)

User Certificate Private Key:

  • Impersonate user in authentication systems
  • Access user's encrypted data
  • Sign documents as the user
  • Access corporate resources

Attack Vectors

Network-Based Exfiltration:

  • Compromised server with remote access
  • Malware with data exfiltration capability
  • Network sniffing (if key transmitted unencrypted)
  • API exploitation exposing key material

Physical Access:

  • Stolen backup tapes or disks
  • Decommissioned hardware not properly sanitized
  • Insider threat with physical access
  • Forensic recovery from disposed equipment

Software Vulnerabilities:

  • Memory dumps exposing keys in RAM
  • Log files containing key material
  • Debug output exposing keys
  • Heartbleed-style vulnerabilities leaking memory

Supply Chain:

  • Compromised key generation libraries
  • Backdoored random number generators
  • Tampered HSMs or hardware
  • Malicious certificate management software

Operational Failures:

  • Keys stored in version control (GitHub, GitLab)
  • Keys in configuration files or scripts
  • Keys in email or chat systems
  • Unencrypted backups
  • Keys on shared file systems

Key Storage Security Levels

Different security requirements demand different protection levels:

Level 1: File System Storage (Lowest Security)

Characteristics:

  • Private key stored as file on disk
  • May or may not be encrypted
  • Accessible to OS and running processes
  • Protected by file system permissions

Appropriate Use Cases:

  • Development and testing environments
  • Non-critical internal services
  • Short-lived certificates with frequent rotation
  • Situations where business risk is minimal

Protection Measures:

  • Encrypt private keys with strong passphrase (PKCS#8)
  • Restrict file permissions (chmod 600)
  • Store on encrypted volumes
  • Keep keys separate from certificates
  • Never commit to version control

Limitations:

  • Key accessible to anyone with root/admin access
  • Vulnerable to memory dumps and process inspection
  • Vulnerable to backup theft if encryption key is weak
  • No tamper resistance

Example: 

# Generate encrypted private key
openssl genpkey -algorithm RSA -out private.key -aes256 -pass pass:SecurePassword

# Set restrictive permissions
chmod 600 private.key
chown app-user:app-group private.key

# Verify no world-readable permissions
ls -la private.key
# Should show: -rw------- 1 app-user app-group

Level 2: Operating System Keystores (Medium Security)

Characteristics:

  • Keys stored in OS-managed secure storage
  • Hardware-backed encryption (TPM, Secure Enclave)
  • Access control integrated with OS authentication
  • Better protection against file system access

Technologies:

  • Windows: Certificate Store with CNG/CryptoAPI
  • macOS: Keychain with Secure Enclave
  • Linux: Kernel keyring, TPM integration

Appropriate Use Cases:

  • Enterprise workstations
  • Mobile devices
  • Servers with TPM support
  • Applications needing OS integration

Protection Measures:

  • Require user or system authentication for key access
  • Enable TPM/Secure Enclave backing where available
  • Configure minimum access privileges
  • Enable audit logging for key operations

Limitations:

  • Still vulnerable to OS-level compromise
  • Limited tamper resistance
  • Key extractability varies by implementation
  • Performance may be limited for high-volume operations

Level 3: Cloud KMS (Medium-High Security)

Characteristics:

  • Keys managed by cloud provider
  • Hardware-backed security (cloud HSMs)
  • API-driven access with IAM controls
  • Automatic key rotation capabilities
  • Audit logging included

Providers:

  • AWS: KMS, CloudHSM
  • Azure: Key Vault, Managed HSM
  • GCP: Cloud KMS, Cloud HSM
  • HashiCorp: Vault Transit

Appropriate Use Cases:

  • Cloud-native applications
  • Kubernetes workloads
  • High-scale certificate operations
  • Organizations without HSM expertise
  • Automated certificate rotation

Protection Measures:

  • Use IAM policies to restrict key access
  • Enable key usage logging and monitoring
  • Implement key rotation policies
  • Use separate keys for different environments
  • Leverage automatic key versioning

Limitations:

  • Dependency on cloud provider
  • Potential regulatory concerns (data sovereignty)
  • Network latency for key operations
  • Cost can be significant at scale
  • Key material typically exportable (varies by service)

Example (AWS KMS): 

# Create KMS key
aws kms create-key --description "Application signing key"

# Encrypt data with KMS key
aws kms encrypt --key-id $KEY_ID --plaintext "sensitive data" --output text

# Decrypt data
aws kms decrypt --ciphertext-blob fileb://encrypted-data --output text

Level 4: Hardware Security Modules (Highest Security)

Characteristics:

  • Dedicated cryptographic hardware
  • FIPS 140-2 Level 3+ certification
  • Tamper-resistant and tamper-evident
  • Keys never extractable in plaintext
  • Multi-person access controls

Use Cases:

  • Certificate Authority operations
  • Root and intermediate CA keys
  • Code signing for critical software
  • High-value transaction signing
  • Regulated industries (finance, government)
  • High-assurance PKI

Protection Measures:

  • Physical security controls for HSM
  • M-of-N key access (require multiple key holders)
  • Comprehensive audit logging
  • Secure backup with split knowledge
  • Regular security audits

Limitations:

  • High cost (hardware and operational)
  • Complexity in setup and operation
  • Requires specialized expertise
  • Performance may limit throughput
  • Vendor lock-in considerations

Key Advantages:

  • Keys generated and used entirely within HSM
  • Physical tamper detection
  • FIPS validated security
  • Regulatory compliance
  • High assurance for critical operations

Example HSM Vendors:

  • Thales (formerly Gemalto) Luna
  • Entrust nShield
  • Utimaco SecurityServer
  • AWS CloudHSM (managed service)
  • Azure Managed HSM

Practical Guidance

Key Generation Best Practices

On-Device Generation

Generate keys where they'll be used whenever possible:

Server Certificate: 

# Generate key on server (never transmitted)
openssl genpkey -algorithm RSA -out private.key -pkeyopt rsa_keygen_bits:2048

# Generate CSR for CA signing
openssl req -new -key private.key -out certificate.csr

# CA signs CSR and returns certificate
# Private key never leaves server

Advantages:

  • Key never transmitted over network
  • No exposure during generation/transmission
  • Complies with security best practices

HSM Generation: 

# Generate key in HSM (never exported)
pkcs11-tool --module /usr/lib/libCryptoki2.so --login --keypairgen --key-type RSA:2048 --label "CA-Key"

# Key stored in HSM, only public key exported

Entropy and Randomness

Private keys must be generated with cryptographically secure random number generators (CSRNG).

Good Entropy Sources:

  • /dev/urandom (Linux)
  • CryptGenRandom (Windows)
  • Hardware RNG (RDRAND, TPM)
  • HSM internal RNG

Poor Entropy Sources (Never Use):

  • rand() function
  • Current timestamp
  • Process ID
  • Predictable seeds

Verify Entropy: 

# Check available entropy (Linux)
cat /proc/sys/kernel/random/entropy_avail
# Should be >1000 for key generation

# Install haveged if entropy is low
apt-get install haveged

Encryption at Rest

PKCS#8 Encrypted Private Keys

# Generate unencrypted key
openssl genpkey -algorithm RSA -out private-unencrypted.key

# Convert to encrypted PKCS#8 format
openssl pkcs8 -topk8 -in private-unencrypted.key -out private-encrypted.key -v2 aes256

# Or generate directly as encrypted
openssl genpkey -algorithm RSA -out private.key -aes256

# Verify encryption
openssl pkey -in private-encrypted.key -text -noout
# Will prompt for password

Password Selection:

  • Minimum 20 characters
  • Mix of character types
  • Use password manager or generated passwords
  • Consider using key derivation function (KDF)

Key Encryption Key (KEK) Architecture

For automated systems requiring unattended key access:

Master Key (KEK) → Stored in HSM/KMS
    ↓ Encrypts
Data Encryption Keys → Stored on disk (encrypted)
    ↓ Encrypt
Private Keys → Stored on disk (double encrypted)

Implementation Pattern: 1. Generate master KEK in HSM/KMS 2. Generate data encryption keys (DEK) for each service 3. Encrypt DEKs with KEK, store encrypted DEKs 4. Encrypt private keys with DEKs 5. For key use: Decrypt DEK with KEK, decrypt private key with DEK, use key, clear from memory

Benefits:

  • Private keys never unencrypted on disk
  • KEK rotation doesn't require re-encrypting all keys
  • Access control at KEK level
  • Audit trail at KEK access points

Access Control

Principle of Least Privilege

Who Needs Access:

  • CA Operations: Only authorized CA administrators
  • Server Keys: Only the application process running the service
  • Code Signing: Only authorized build systems/developers
  • User Keys: Only the individual user

Access Control Matrix Example:

Key Type Generate Use View Cert Backup Revoke Destroy
Root CA Security Team Security Team All Security Team Security Team Security Team
Intermediate CA Security + PKI PKI Team All Security Team Security + PKI Security Team
Server App Team Application All App + Security App Team App Team
Code Sign Dev Lead Build System All Security Team Dev Lead Dev Lead
User User User User Backup System User/Admin User/Admin

Operating System Controls

Linux: 

# Create dedicated key user
useradd -r -s /bin/false keyuser

# Set ownership and permissions
chown keyuser:keyuser /path/to/private.key
chmod 400 /path/to/private.key  # Read-only for owner

# Configure service to run as keyuser
systemctl edit myservice.service
# Add: User=keyuser

# Use SELinux for additional isolation
chcon -t httpd_cert_t /path/to/private.key

Windows: 

# Set ACL for private key
$acl = Get-Acl "C:\Keys\private.key"
$acl.SetAccessRuleProtection($true, $false)  # Remove inheritance
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("SYSTEM","FullControl","Allow")
$acl.SetAccessRule($rule)
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("Administrators","FullControl","Allow")
$acl.SetAccessRule($rule)
Set-Acl "C:\Keys\private.key" $acl

API Access Control (Cloud KMS)

# AWS KMS Policy Example
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow application use",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789:role/ApplicationRole"
      },
      "Action": [
        "kms:Decrypt",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow admin management",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789:role/SecurityAdmin"
      },
      "Action": [
        "kms:*"
      ],
      "Resource": "*"
    }
  ]
}

Monitoring and Auditing

What to Log

Key Operations:

  • Key generation events
  • Key usage (signing, decryption operations)
  • Key access attempts (successful and failed)
  • Key export or backup operations
  • Key deletion or destruction
  • Permission changes

Context Information:

  • User/service identity
  • Source IP address
  • Timestamp
  • Operation type
  • Key identifier
  • Success/failure status
  • Request parameters

Detection Scenarios

Anomaly Detection:

  • Unusual number of key operations
  • Key access from unexpected IP addresses
  • Key operations outside business hours
  • Failed authentication attempts spike
  • Key access by terminated users

Example Alert Rules: 

ALERT: PrivateKeyAccessFromNewIP
  IF key_access_event.ip NOT IN historical_ips
  AND key_type = "ca" OR key_type = "code_signing"
  THEN notify security_team

ALERT: ExcessiveKeyUsage
  IF count(key_operations) > threshold_per_hour
  AND operation_type = "decrypt"
  THEN investigate_potential_compromise

ALERT: OffHoursCAKeyAccess
  IF key_type = "root_ca" OR key_type = "intermediate_ca"
  AND time NOT BETWEEN 09:00 AND 17:00 local_time
  AND day NOT IN scheduled_maintenance
  THEN notify security_team URGENT

Key Rotation

Rotation Strategies

Proactive Rotation (Preventive):

  • Scheduled key replacement
  • Reduces exposure window
  • Limits damage if past compromise undiscovered

Reactive Rotation (Incident Response):

  • Immediate replacement after compromise
  • Emergency procedures required
  • Requires certificate revocation

Rotation Frequency Guidelines:

Key Type Recommended Frequency Rationale
Root CA Never (20+ year lifetime) Rotation requires trust redistribution
Intermediate CA Annually Limits compromise exposure
TLS Server (automated) 30-90 days Enables automation testing
TLS Server (manual) Annually minimum Balance security and operations
Code Signing 1-2 years Requires reissuing signed artifacts
User Authentication 1-2 years Balance security and user friction

Rotation Implementation

Step-by-Step Process:

  1. Generate New Key Pair 

    openssl genpkey -algorithm RSA -out new-private.key -aes256

  2. Obtain New Certificate 

    openssl req -new -key new-private.key -out new-certificate.csr
# Submit CSR to CA

  3. Deploy New Certificate (Parallel Run)

  4. Configure service to accept both old and new certificates
  5. Test new certificate in non-production

  6. Monitor for issues

  7. Cutover

  8. Make new certificate primary
  9. Keep old certificate active for grace period

  10. Monitor client compatibility

  11. Revoke Old Certificate 

    # After grace period (e.g., 7 days)
openssl ca -revoke old-certificate.pem

  12. Destroy Old Key 

    # Securely wipe old private key
shred -vfz -n 10 old-private.key
# Or for HSM: HSM vendor-specific deletion command

Secure Key Destruction

When keys are no longer needed, they must be securely destroyed:

File System Keys

Linux: 

# Multiple overwrite passes
shred -vfz -n 35 private.key

# Or use secure-delete package
srm -v private.key

# For SSDs (wear leveling makes overwrite unreliable)
# Use whole-disk encryption and securely erase encryption keys

Windows: 

# Use sdelete (Sysinternals)
sdelete -p 7 C:\Keys\private.key

# Or cipher command
cipher /w:C:\Keys\

HSM Keys

# HSM-specific destruction (example with PKCS#11)
pkcs11-tool --module libCryptoki2.so --login --delete-object --type privkey --label "OldKey"

# Verify deletion
pkcs11-tool --module libCryptoki2.so --login --list-objects

Backup Media

  • Physical destruction: Shredding, incineration, degaussing
  • Cryptographic erasure: If backup encrypted, destroy encryption key
  • Verification: Document destruction, obtain certificate of destruction
  • Chain of custody: Track media from removal to destruction

Common Pitfalls

  • Storing keys in version control: Committing private keys to Git, SVN, or other VCS
  • Why it happens: Keys in config files; developers not understanding risk; convenience over security
  • How to avoid: Use .gitignore for key patterns; pre-commit hooks to detect keys; education

  • How to fix: Rotate compromised keys immediately; revoke certificates; scan entire repository history; consider repository private

  • Unencrypted backups: Backing up private keys without encryption

  • Why it happens: Backup tools default to unencrypted; lack of backup encryption strategy
  • How to avoid: Encrypted backup volumes; separate key encryption; test backup restoration

  • How to fix: Re-encrypt existing backups; rotate keys if backup security unknown; implement encrypted backup process

  • Keys in configuration management: Private keys in Ansible, Puppet, Chef, Terraform state

  • Why it happens: Convenience of centralized configuration; misunderstanding of CM security model
  • How to avoid: Use secrets management (Vault, AWS Secrets Manager); separate key distribution mechanism

  • How to fix: Rotate exposed keys; implement proper secrets management; audit CM repositories

  • Inadequate key access controls: World-readable key files, shared admin accounts

  • Why it happens: Misconfiguration; lack of understanding; troubleshooting shortcuts becoming permanent
  • How to avoid: Automated permission checks; infrastructure as code with correct permissions; regular audits

  • How to fix: Immediately fix permissions; rotate keys if unauthorized access possible; review audit logs

  • Key material in logs or error messages: Debug output or stack traces containing key data

  • Why it happens: Verbose logging during development; insufficient sanitization; error handling exposing sensitive data
  • How to avoid: Sanitize all output; review logging configuration; test error conditions
  • How to fix: Rotate exposed keys; scrub logs; fix logging code; alert on similar patterns

Security Considerations

Forward Secrecy

TLS connections using Diffie-Hellman key exchange provide forward secrecy—compromise of server private key doesn't allow decryption of past captured traffic.

Without Forward Secrecy (RSA key exchange):

  • Attacker captures encrypted traffic
  • Later compromises server private key
  • Can decrypt all captured traffic

With Forward Secrecy (DHE/ECDHE):

  • Ephemeral keys used for each session
  • Session keys not derivable from server private key
  • Past traffic remains secure even if private key compromised

Implementation: 

# Prefer ECDHE cipher suites (nginx)
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;

Memory Protection

Private keys in application memory are vulnerable to:

  • Memory dumps
  • Debugger attachment
  • Process memory reading
  • Swap/hibernation file exposure

Mitigations:

  • Clear sensitive data from memory after use (memset to zero)
  • Use secure memory allocation (mlock to prevent swapping)
  • Disable core dumps for sensitive processes
  • Enable address space layout randomization (ASLR)
  • Use memory-hard functions for key derivation

Example (C): 

#include <sys/mman.h>
#include <string.h>

// Allocate locked memory for private key
unsigned char *key = mmap(NULL, key_size, PROT_READ | PROT_WRITE,
                          MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, -1, 0);

// Use key...

// Securely clear before freeing
memset(key, 0, key_size);
munmap(key, key_size);

Side-Channel Attacks

Private key operations may leak information through:

  • Timing attacks: Key operations taking different time based on key bits
  • Power analysis: Power consumption revealing key material
  • EM radiation: Electromagnetic emissions during crypto operations
  • Cache timing: CPU cache behavior leaking key information

Mitigations:

  • Use constant-time cryptographic implementations
  • Hardware with side-channel countermeasures (HSMs)
  • Blinding techniques for RSA operations
  • Regular security assessments

Real-World Examples

Case Study: GitHub RSA Key Exposure (2023)

GitHub accidentally exposed RSA SSH private host key in public repository. While not a certificate private key, this demonstrates how easily keys can be exposed.

Impact: Anyone could impersonate GitHub's servers in man-in-the-middle attacks.

Response: GitHub immediately rotated the host key, notified users, and improved secret scanning.

Key Takeaway: Even sophisticated organizations make mistakes. Automated detection and rapid rotation capabilities are essential.

Case Study: Code Signing Certificate Theft

Multiple incidents where developers' code signing certificates were stolen through malware and used to sign malicious software (Stuxnet, Flame malware).

Attack Vector: Compromised developer workstations with code signing keys stored in Windows Certificate Store.

Impact: Malware signed with legitimate certificates bypassed security controls and damaged vendor reputation.

Key Takeaway: High-value keys (especially code signing) require hardware protection. Developer workstations are high-risk environments for critical keys.

Case Study: DigiNotar CA Compromise (2011)

DigiNotar's CA private keys were compromised, allowing attackers to issue rogue certificates for Google, Mozilla, CIA, and others.

Root Cause: Inadequate key protection—CA keys not in HSM, weak access controls, compromised servers with key access.

Impact: Complete loss of trust, DigiNotar bankruptcy, browsers removed all DigiNotar certificates.

Key Takeaway: CA keys demand maximum protection. HSMs, offline operations, and multi-person controls are non-negotiable for CA operations.

Further Reading

Essential Resources

Advanced Topics

References

Standards and Guidelines

Cryptographic Specifications

HSM and Hardware Security

Password-Based Key Derivation

Secret Sharing and Key Backup

Secure Deletion

Attack Research

Industry Standards

Academic Research

Historical Incidents

Books and Comprehensive Guides

Change History

Date Version Changes Reason
2025-11-09 1.0 Initial creation Critical security topic documentation

Quality Checks:

  • [x] All claims cited from authoritative sources
  • [x] Cross-references validated
  • [x] Practical guidance included
  • [x] Examples are current and relevant
  • [x] Security considerations addressed

  1. NIST. "Recommendation for Key Management." NIST SP 800-57 Part 1 Rev. 5, May 2020. Nist - Detail ↩

  2. NIST. "Security Requirements for Cryptographic Modules." FIPS 140-2, May 2001. Nist - Detail ↩

  3. NIST. "Security Requirements for Cryptographic Modules." FIPS 140-3, March 2019. Nist - Detail ↩

  4. NIST. "A Framework for Designing Cryptographic Key Management Systems." NIST SP 800-130, August 2013. Nist - Detail ↩

  5. NIST. "Recommendation for the Entropy Sources Used for Random Bit Generation." NIST SP 800-90B, January 2018. Nist - Detail ↩

  6. Moriarty, K., et al. "PKCS #1: RSA Cryptography Specifications Version 2.2." RFC 8017, November 2016. Ietf - Rfc8017 ↩

  7. NIST. "Digital Signature Standard (DSS)." FIPS 186-4, July 2013. Nist - Detail ↩

  8. NIST. "Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters." NIST SP 800-186, February 2023. Nist - Detail ↩

  9. Trusted Computing Group. "TPM 2.0 Library Specification." 2019. Trustedcomputinggroup - Tpm Library Specification ↩

  10. OASIS. "PKCS #11 Cryptographic Token Interface Base Specification Version 2.40." 2015. Oasis-open - Pkcs11 Base ↩

  11. OASIS. "Key Management Interoperability Protocol Specification Version 2.1." January 2020. Oasis-open - Kmip Spec ↩

  12. Percival, C., Josefsson, S. "The scrypt Password-Based Key Derivation Function." RFC 7914, August 2016. Ietf - Rfc7914 ↩

  13. Biryukov, A., Dinu, D., Khovratovich, D. "Argon2 Memory-Hard Function for Password Hashing." RFC 9106, September 2021. Ietf - Rfc9106 ↩

  14. Kaliski, B. "PKCS #5: Password-Based Cryptography Specification Version 2.1." RFC 8018, January 2017. Ietf - Rfc8018 ↩

  15. Shamir, A. "How to Share a Secret." Communications of the ACM, Vol. 22, No. 11, pp. 612-613, November 1979. Acm - 10.1145 ↩

  16. Feldman, P. "A Practical Scheme for Non-interactive Verifiable Secret Sharing." FOCS 1987. ↩

  17. Pedersen, T.P. "Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing." CRYPTO 1991. ↩

  18. NIST. "Guidelines for Media Sanitization." NIST SP 800-88 Revision 1, December 2014. Nist - Detail ↩

  19. Gutmann, P. "Secure Deletion of Data from Magnetic and Solid-State Memory." USENIX Security Symposium, July 1996. ↩

  20. Kocher, P., Jaffe, J., Jun, B. "Differential Power Analysis." CRYPTO 1999. ↩

  21. Genkin, D., et al. "Get Your Hands Off My Laptop: Physical Side-Channel Key-Extraction Attacks on PCs." CHES 2014. ↩

  22. Kocher, P., et al. "Spectre Attacks: Exploiting Speculative Execution." IEEE S&P 2019. ↩

  23. Boneh, D., DeMillo, R.A., Lipton, R.J. "On the Importance of Checking Cryptographic Protocols for Faults." EUROCRYPT 1997. ↩

  24. CA/Browser Forum. "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates." Current version. Cabforum - Baseline Requirements Documents ↩

  25. CPA Canada/AICPA. "WebTrust Principles and Criteria for Certification Authorities." Current version. Cpacanada ↩

  26. ETSI. "General Policy Requirements for Trust Service Providers." ETSI EN 319 401, V2.3.1, 2021. Etsi - Etsi En ↩

  27. European Parliament. "Regulation (EU) No 910/2014 on electronic identification and trust services (eIDAS)." July 2014. Europa - Txt ↩

  28. PCI Security Standards Council. "Payment Card Industry (PCI) Data Security Standard." Version 4.0, March 2022. Pcisecuritystandards ↩

  29. Heninger, N., et al. "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices." USENIX Security 2012. ↩

  30. Lenstra, A.K., Verheul, E.R. "Selecting Cryptographic Key Sizes." Journal of Cryptology, Vol. 14, pp. 255-293, 2001. ↩

  31. Chen, L., et al. "Report on Post-Quantum Cryptography." NIST Internal Report 8105, April 2016. Nist - Detail ↩

  32. Fox-IT. "DigiNotar Certificate Authority breach - Operation Black Tulip." September 2011. Fox-IT DigiNotar Report ↩

  33. Comodo. "Comodo Fraud Incident Report." March 2011. ↩

  34. Durumeric, Z., et al. "The Matter of Heartbleed." ACM IMC 2014. Acm - 10.1145 ↩

  35. Schneier, B. "Applied Cryptography: Protocols, Algorithms, and Source Code in C." 2nd Edition, Wiley, 1996. ↩

  36. Anderson, R. "Security Engineering: A Guide to Building Dependable Distributed Systems." 3rd Edition, Wiley, 2020. ↩

  37. Ferguson, N., Schneier, B., Kohno, T. "Cryptography Engineering: Design Principles and Practical Applications." Wiley, 2010. ↩