>
    Best Practices for Resisting Post-Quantum Attacks
    Focus
    Download PDF
    Focus
    1. Home
    2. Network Security
    3. Quantum Security Concepts
    4. Best Practices for Resisting Post-Quantum Attacks
    Download PDF
    Network Security

    Best Practices for Resisting Post-Quantum Attacks

    Table of Contents

    Best Practices for Resisting Post-Quantum Attacks

    Cryptography, VPN, and transition planning best practices to resist post-quantum attacks and safeguard key exchange material.
    Where Can I Use This?
    What Do I Need?
    • PAN-OS
    • PAN-OS 11.1 or later.
    There are many best practices you can implement now to defend against post-quantum attacks carried out by quantum computers, including defending against Harvest Now, Decrypt Later attacks. Harvest Now, Decrypt Later attacks capture encrypted data and key exchange material with the intent to use cryptographically relevant quantum computers (CRQCs) to decrypt the material later by accelerating Shor's algorithm, which factors key material to find the extremely large prime numbers on which the encryption key is based.
    These best practices cover:

    Post-Quantum Transition Planning Best Practices

    The transition from classical cryptography to post-quantum cryptography can take five years or even longer. Planning alone can take several years. Give yourself the best advantage by:
    • Starting Early
      —If your company has long-lived data and is a potential target of harvesting attacks, each day you delay taking action risks allowing attackers to harvest more information to decrypt later. The earlier you take action, the sooner you stop attackers from harvesting data to decrypt in the future.
    • Leveraging Existing Resources
      —When you take your crypto inventory, leverage work you've already done for audits, Zero Trust, network enhancements, and other activities.
    • Educating Yourself
      —Learn about the quantum computing threat, post-quantum cryptography (PQC), technologies and methods to harden your network against quantum attacks, and the new and emerging PQCs that you can use to protect your network. Learn from government mandates, plans, and laws, RFCs, and other information sources.

    Cryptography Best Practices

    Increase the strength of your classical cryptographic suites to make it more difficult for an attacker to brute force decrypt keys as quantum computers become faster and faster as they evolve into CRQCs. Quantum computers that are not CRQCs might still be fast enough to break weaker encryption.
    • Follow RFC 6379 for
      Suite B Cryptographic Suites for IPsec
       to upgrade your VPN connections to tough cipher suites. Use Suite-B-GCM-256 and avoid weaker 128-bit AES algorithms, which are vulnerable to Grover's algorithm.
    • Upgrade your CA to 4K RSA key sizes to mitigate brute force attacks that can break smaller key sizes.
    • Migrate your VPN certificate authentication to new certificates with larger key sizes.
    • Upgrade to higher-bit SHA hash sizes such as SHA-384 and SHA-512. Stop using weak hashes such as MD5 and SHA-1.
    • Upgrade SSL/TLS connections to tough cipher suites; use TLSv1.3 with Perfect Forward Secrecy (PFS) ciphers.
    • Tunnel SSL/TLS sessions in hardened, client-to-server VPN sessions.
    • Configure your Vulnerability Protection profiles to block unsanctioned PQCs for traffic that you don't decrypt. For traffic that you decrypt, use a Decryption profile to block unsanctioned PQCs (the Decryption profile only allows the ciphers that you enable and the firewall blocks all other ciphers). Unsanctioned PQCs might indicate a breach or an internal bad actor attempting to use PQCs to compromise your network. Make exceptions as needed for your internal PEN testing teams.

    VPN Configuration Best Practices

    When you configure post-quantum IKEv2 VPNs, make them as resistant to quantum attacks as possible:
    • Don't use IKEv1. IKEv1 is considered to be a weak protocol and doesn't support post-quantum VPNs. If both IKE peers can support it, upgrade your VPN connections to IKEv2 and select
      IKEv2 only mode
       when you configure the IKE gateways (
      Network
      Network Profiles
      IKE Gateways
      General
      ).
    • Set the
      Negotiation Mode
       to
      Mandatory
       whenever you know both peers support RFC 8784. Using
      Mandatory
       mode ensures that the VPN resists post-quantum attacks and attackers can't harvest the data now and decrypt it later using a CRQC running Shor's algorithm.
      Shor's algorithm can crack the dynamic key exchange in the IKEv2 handshake that uses asymmetric encryption, given enough processing power. However, Shor's algorithm can't crack the IPsec tunnel symmetric encryption. To protect the symmetric IPsec encryption, use AES-256 to protect against Grover's algorithm and use the stronger hashes and key lengths recommended in the previous section on cryptography best practices.
      When peering with external devices, try to ascertain whether the peer supports RFC 8784 and work with the other administrator to use the same PQ PPKs for the connection so that you can use
      Mandatory
      .
    • Manually specify or automatically generate a that is at least 64 characters (32 bytes, or 256 bits of entropy) in length to create a strong key. You can manually specify or automatically generate a
      PPK Secret
       that is up to 128 characters (64 bytes, 512 bits of entropy) long. The longer the PPK Secret, the greater the number of entropy bits, which makes the PPK Secret harder to crack.
      The number of entropy bits provides half that number of bits of post-quantum security. For example, 256 bits of entropy provides 128 bits of post-quantum security and 512 bits of entropy provides 256 bits of post-quantum security. A minimum of 256 bits of entropy provides the security equivalent to Category 5 as defined in the NIST Post-Quantum Cryptography Call for Proposals. The Security Considerations section of RFC 8784 provides more details about entropy and what amount of entropy is sufficient.
      The PPK secret is only shown in cleartext when you configure it or generate it automatically. After you configure or generate the PPK secret and navigate away from the screen that shows the secret in cleartext, it is never shown in cleartext again to help prevent compromising the key.
      Copy the PPK secret and KeyID pair and store it securely. If you don't store the key when you configure or generate it, you can't retrieve it later. (You can delete the PQ PPK and configure another one if necessary.)
      Other best practices for handling PQ PPKs include:
      • Create multiple active PQ PPKs. Using multiple active keys, not just one, adds an element of randomness to key selection during the key exchange.
      • Ensure that each IKEv2 peer has the exact same set of activated PQ PPKs (KeyID plus PPK secret pairs) to negotiate the key exchange.
      • If Panorama manages the peers, configure the PQ PPKs and push them to managed firewalls for easier, faster, and more automatic configuration.
      • If you need to communicate the PQ PPK to another administrator, use a cryptographically secure communication method such as encrypted email.
      • Store the PPK secret string securely. Don't keep it on sticky notes or anywhere unauthorized administrators might discover it.
      The NSA publishes guidance on how to handle pre-shared keys safely, including RFC 8784 quantum pre-shared keys.

    Recommended For You

    © 2024 Palo Alto Networks, Inc. All rights reserved.