>
    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 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 have 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:
    RFC 8784 Best Practices:
    • Don't use IKEv1. IKEv1 is considered to be a weak protocol and does not 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 (NetworkNetwork ProfilesIKE GatewaysGeneral).
    • 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 mode.
    • Manually specify or automatically generate a PPK Secret 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's 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 exactly the 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.
    RFC 9242 and RFC 9370 Best Practices:
    • Don't use IKEv1. IKEv1 is considered to be a weak protocol and does not 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 (NetworkNetwork ProfilesIKE GatewaysGeneral).
    • Create the hybrid key using a strong classic KEM, such as Diffie-Hellman Group 20 and above, and at least one PQC in the additional KEM rounds, such as Kyber-768 (ML-KEM), when you configure the IKE crypto profiles (NetworkNetwork ProfilesIKE CryptoGeneral and Advanced Options).
    • Use only PQCs that are rated at a security strength level of L3 or higher for sensitive information. Each additional PQC added to the key creation process increases the key’s ability to resist a quantum attack, but it also adds latency and overhead to the IKEv2 peering process. In general, adding a security level L3 PQC adds approximately 20 to 30 ms to the IKEv2 key exchange, and adding a security level L5 PQC adds 40 to 60 ms. Stronger PQCs that use larger keys, such as Classic McEliese, can potentially add more than 800 ms to the key exchange and introduce high levels of fragmentation. Familiarize yourself with the PQC key sizes and security strengths to select the best PQC for your VPN communications.
    • Coordinate the PQCs used in each key negotiation round with the administrator who manages the peer VPN device. When both VPN devices on each side of the tunnel are configured with the same PQCs in each optional key negotiation round, interoperability issues are minimized. Try to agree on the PQC and its security strength to ensure both sides are configured with the same parameters. For firewalls managed under the same organization, central management tools can be used to ensure consistent configuration and PQC selection in each key negotiation round.
    • Enable cryptographic agility to safeguard your data during the transition to a pure PQC environment. The transition can take as much as 5 to 10 years before the industry fully trusts the new PQCs.
      • For organizations that must use PQCs standardized by NIST and approved by FIPS, cryptographic agility can be achieved by enabling RFC 8784 with RFC 9242 and RFC 9370. If the PQC used in the hybrid key falls to a vulnerability, the PPK string used in RFC 8784 can still provide quantum resistance to prevent a successful harvesting attack.
      • For organizations that are allowed to use both NIST standardized and non-standardized PQCs, cryptographic agility can be achieved by using at least two PQCs with a strong classic KEM, such as Diffie-Hellman Group 21. Ideally, the PQC KEMs should be using different mathematical technologies where one KEM is based on lattice and the other based on code-based or other non-lattice technologies. Optionally, RFC 8784 can also be enabled with the hybrid key to add an extra layer of security and extend cryptographic agility.
    • Reduce the key lifetime value from its default value to a lower value to facilitate faster rekeying.
    • Enable IPSec to use hybrid keys when you configure the IPSec crypto profiles (NetworkNetwork ProfilesIPSec CryptoGeneral and Advanced Options). Both sides of the IPSec tunnel must be configured to use the same PQC and security strength in each additional key exchange round.

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