Future-Proofing Your Network: Enabling Quantum Ciphers on F5 BIG-IP TMOS 17.5.1
The quantum computing revolution is an imminent reality that demands attention from cybersecurity experts. As quantum computers advance toward breaking traditional RSA and elliptic curve cryptography, organizations must prepare their infrastructure with quantum-resistant encryption. F5's BIG-IP TMOS 17.5.1 introduces support for post-quantum cryptographic algorithms, positioning your network security ahead of the quantum curve. Understanding the Quantum Threat Traditional cryptographic methods like RSA-2048 and ECDSA rely on mathematical problems that classical computers find computationally intractable to solve. However, quantum computers running Shor's algorithm can factor large integers exponentially faster. This renders these encryption methods vulnerable within the next decade. The National Institute of Standards and Technology (NIST) has standardized several post-quantum cryptographic algorithms. They are designed to withstand both classical and quantum attacks. TMOS 17.5.1 implements ML-KEM (FIPS 203) for key encapsulation. The standard versions are based on the original CRYSTALS-Kyber and CRYSTALS-Dilithium algorithms. They include important changes to the parameters and requirements for how they are used to make sure they work well together in the future. Prerequisites and Planning Before implementing quantum ciphers on your BIG-IP system, ensure your environment meets these requirements: Hardware Requirements: BIG-IP appliances with sufficient processing power (quantum algorithms are computationally intensive) Minimum 8GB RAM for optimal performance Hardware Security Module (HSM) support recommended for key management Hardware Security Modules are not required to support post-quantum cryptographic algorithms, but they provide a higher level of assurance for cryptographic key storage. F5 offers a range of hardware that has built in hardware security modules. Also, if virtual F5 instances are selected, they offer the ability to integrate with a network based hardware security module. Software Requirements: TMOS version 17.5.1 or later Valid SSL/TLS certificates compatible with hybrid classical-quantum cipher suites Updated client applications capable of negotiating post-quantum algorithms The current implementation is a hybrid approach where classical and post quantum algorithms run in parallel. So you would use "classical" RSA/ECDSA certificates for the server authentication, but the actual TLS handshake would use ML-KEM for establishing quantum-safe session keys. Network Considerations: Increased bandwidth requirements due to larger key sizes and signature lengths Latency impact assessment for time-sensitive applications Compatibility testing with existing security infrastructure Enabling Quantum Ciphers: Step-by-Step Configuration Step 1: Access the BIG-IP Configuration Utility Log into your BIG-IP system through the web-based Configuration utility or connect via SSH for command-line configuration. Navigate to System/Configuration/Device/General to verify you're running TMOS 17.5.1. Or in the cli type tmsh show sys version Then follow along with F5 documentation. The details are all in the article for configuration either via TMUI or TMSH. This can all be configured via APIs or could be set up using tools like Ansible or Terraform if automation is required. https://my.f5.com/manage/s/article/K000149577 Step 2: Create a Cipher Rule Step 3: Create a new Cipher Group Step 4: Create a New Client SSL profile Create a client SSL profile. Associate the ciphergroup with the new client SSL profile. Remove No TLSv1.3 from the enabled options Step 5: Create a Virtual Server Example: tmsh create /ltm virtual quantum { destination 10.0.2.113:443 ip-protocol tcp pool quantumpool profiles add { quantum { context clientside } tcp } } Test In my case, I used Chrome. I enabled the developer tools and in the privacy and developer tools, looked at what was being negotiated. Sure enough, I am getting a quantum-safe connection. Monitoring and Troubleshooting Essential Monitoring Commands Monitor quantum cipher usage and performance: # Check quantum cipher statistics tmsh show ltm profile client-ssl quantum # View quantum key exchange metrics tmsh show ltm virtual quantum Common Issues and Solutions High CPU Usage: Quantum algorithms are computationally intensive. Consider hardware acceleration or load balancing across multiple devices. Compatibility Issues: Not all clients support quantum ciphers yet. Implement graceful fallback mechanisms and maintain hybrid cipher suites during the transition period. Browser Compatibility and the Chrome ML-KEM Transition A critical consideration for BIG-IP quantum cipher deployment is the ongoing browser transition from draft Kyber implementations to standardized ML-KEM. Chrome has phased out Kybersupport in favor of ML-KEM. This shift has significant implications for your BIG-IP configuration strategy. Configuring for Browser Compatibility To ensure seamless browser compatibility during this transition, configure your BIG-IP to prioritize ML-KEM Notably, the following cipher string did not work for me in Chrome as Kyber support has been removed in the latest versions of Chrome. X25519KYBER768 As per the k Article. Note: On June 24, 2025, Google released Chrome 138.7204.49 that no longer includes Kyber support. The chrome://flags options for PQC algorithms was also removed, and MLKEM is enabled by default. My Chrome Version was Version 138.0.7204.158, so Kyber support has gone. This DH cipher string worked for me in Chrome. X25519MLKEM768 The K article recommends the following cipher string. X25519MLKEM768:X25519KYBER768:DEFAULT To reiterate. If you are using anything earlier than TMOS version 17.5.1 and you attempt a test with a new version of Chrome, it will not work with ML-KEM as the support was only introduced in 17.5.1 and Kyber has been removed from Google Chrome, so if you were to test with 17.5.0 you would find that that Chrome would not be able to negotiate a quantum-safe connection. As per the knowledge article. BIG-IP TMOS version 17.5.0 (for Kyber), 17.5.1 (for MLKEM) or later Performance Considerations Quantum cipher implementation introduces several performance implications that require careful consideration. Key exchange operations using ML-KEM-768 consume about 25% more CPU cycles than traditional ECDHE exchanges. They have slightly better performance than the original Kyber implementation due to standardization optimizations. To make your computer run faster, use hardware acceleration when possible. Use intelligent cipher selection algorithms to balance security needs with performance limits. Consider implementing session resumption mechanisms to reduce the frequency of quantum key exchanges. Compliance and Regulatory Considerations Many industries are beginning to mandate post-quantum cryptography readiness. Financial services, healthcare, and government sectors are leading the adoption of quantum-resistant security measures. TMOS 17.5.1's ML-KEM support helps organizations meet emerging compliance requirements and prepare for future regulatory mandates. It also ensures compatibility with major browsers transitioning away from draft Kyber implementations. Ensure your quantum cipher implementation aligns with relevant standards, including NIST SP 800-208, FIPS 203 (ML-KEM), and industry-specific quantum security guidelines. The transition from draft Kyber to standardized ML-KEM is critical for long-term browser compatibility and regulatory compliance. Future-Proofing Your Investment As quantum computing technology evolves, so too will post-quantum cryptographic standards. F5’s modular approach to quantum cipher implementation ensures that your BIG-IP infrastructure can adapt to future algorithm updates and security enhancements without requiring complete system replacement. Regular software updates and security patches will introduce new quantum-resistant algorithms and performance optimizations. Maintain an active support relationship with F5 to stay current with the latest quantum security developments. Conclusion Implementing quantum ciphers on F5 BIG-IP TMOS 17.5.1 represents a critical step in preparing your network infrastructure for the quantum era. While the transition requires careful planning and performance considerations, the security benefits far outweigh the implementation challenges. Start your quantum-resistant journey today by enabling hybrid cipher suites and gradually transitioning to full quantum protection. The quantum threat is real, but with proper preparation and F5's advanced security capabilities, your organization can maintain robust protection against both classical and quantum adversaries. The future of network security is quantum-resistant, and TMOS 17.5.1 provides the tools you need to secure that future today. Begin your quantum security implementation now, before the quantum advantage becomes a quantum threat.
Secp521r1 curve support in Big IP
Hi, We are running Big IP Version 12.1.5 and are interested in transitioning to secp521r1 for extra security in both ECDH and ECDSA. Are you planning on supporting this curve? if so, do you have an estimate? Thank you, John J. Lee | Senior Information Security Consultant
Crypto Client's clientssl profile config issue(External Crypto )
Hi Everyone Who has configured external crypto function ? Crypto Client's clientssl profile cert&key and Crypto Server's crypto-server-default-clientssl profile cert&key is the same? This guide “https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ssl-administration-12-0-0/18.html” is not very clear about the certificate requirements. Many thanks D.LuoSecurity Month on DevCentral: Challenge #1
As we highlight security on DevCentral this month, we wanted to pose a fun security challenge to exercise those brain cells a little bit. Today's challenge focuses on cryptography. The object of this challenge is to figure out a plaintext message given some ciphertext and clues. The plaintext message for today's challenge was encrypted using a one-time-pad encryption method to generate the ciphertext. The pad is a series of letters that are formed from a unique message based on a DES Challenge from several years ago. These DES Challenges were a series of brute force attack contests created by RSA Security to highlight the lack of security provided by the Data Encryption Standard (DES). The object of these challenges was to find the encryption key and use it to decrypt the ciphertext into a plaintext message. The first challenge began in 1997 and was solved in 96 days by the DESCHALL Project. The next challenge, "DES Challenge II-1" was solved by distributed.net in early 1998. Then, "DES Challenge II-2" was solved in July 1998. Finally, "DES Challenge III" was released and solved in January 1999. The pad for today's challenge is the plaintext message from the DES Challenge II-1. The plaintext message from the DES Challenge included a colon in the middle of the message and a period at the end, but the pad for today's challenge removes the colon and the period (i.e. removes all non-letter characters). Further, to get today's pad, you'll need to move all the letters to lowercase and also remove all spaces. For example, if the plaintext message from that challenge was, "Plaintext: Hello World." then the pad for today's challenge would be: plaintexthelloworld The ciphertext for today's challenge is: wlzuipkvtxvguky The challenge? Find the plaintext message. Get it? Got it? Go! Use the comments below to post the plaintext message, and feel free to tell us the method you used to solve the challenge!Lightboard Lessons: Crypto Offload
If you aren't encrypting all your web application traffic, then you soon will be. And, with all that encrypted traffic flowing to/from your web servers, you have the unenviable task of encrypting and decrypting it all. Well, you can overwhelm your web servers with the task of encrypting/decrypting everything, or you can let the BIG-IP do it all for you. Easy choice, right? If you're as awesome as I think you probably are, you are using BIG-IP for it's amazing SSL offload capabilities. But, did you know that you can now offload the expensive key exchange operations to an external network hardware crypto device? Imagine you have a bunch of stuff hosted in the cloud (and you love that), but you need some custom-built hardware support for all the computationally expensive crypto operations. You're gonna love crypto offload... Related Resources: The Top Ten Hardcore F5 Security Features in BIG-IP 11.6Lightboard Lessons: Elliptic Curve Cryptography
You've seen our Whiteboard Wednesday videos, but we are kicking it up a notch and introducing our new "Lightboard Lessons" video series. In this first video, John talks about the basics of Elliptic Curve Cryptography (ECC). ECC has been around for a while and it's gaining popularity as a viable alternative to RSA. But what exactly is ECC? And what are some of the key benefits it provides in protecting your web applications? Watch this video and find out! Resources BIG-IP Support for Elliptic Curve Cryptography Associating Multiple SSL Cert/Key Pair Types with an SSL Profile LogJams, DHE Parameters, and Other Obstacles to TLS Excellence Supporting Elliptic Curve Cryptography Stronger Keys and Faster Security with ECC We hope you enjoy this series of Lightboard Lessons, and stay tuned for many more exciting videos! Clarification: During my quick explanation of RSA, I said that two prime numbers are multiplied together to produce a really big prime number (at 2:20 - 2:25 in the video). As we all know, a prime number only has itself and 1 as factors. So, if you multiply two numbers together, the resultant number will at least have the two numbers you multiplied as factors…thus not making it prime. Technically speaking, the product of the two prime numbers in RSA is called a “semiprime” number because its only factors are 1, itself, and two prime numbers. Here’s a more detailed explanation of semiprimes: https://en.wikipedia.org/wiki/Semiprime For each RSA number "n", there exist prime numbers “p” and “q” such that n = p × q The problem is to find these two primes, given only n. The salient point for RSA is that “n” will always be semiprime. All that said, I should have said “a really big semiprime number” in the video, but I didn’t want to take up too much time discussing RSA since this video is targeted for ECC.
Looking for advice on CRYPTO::sign and CRYPTO::verify
Hoping someone can help... The documentation around the CRYPTO::sign and CRYPTO::verify commands is minimal and I can't find any worked examples online. Couple that with my limited knowledge of cryptography and the challenge of providing cookie integrity checking in an iRule and I'm struggling. I'm currently using the CRYPTO::encrypt and CRYPTO::decrypt commands to set and encrypted cookie in the response to a client and the decrypt it in subsequent requests and that seems to be working well. How to use the sign and verify commands around this to check that the cookie hasn't been tampered with eludes me though. Any help or advice appreciated. fergu5
