Devoxx France 2026

Slides for Devoxx France 2026

Transcript

1. Theory to Practice: Real-World Lessons in Post-Quantum Cryptography Migration NISHIKAWA, Akihiro (Aki) Cloud Solution Architect, Microsoft @logico_jp @logico-jp.dev linkedin.com/in/anishi1222/
2. Bonjour! こんにちは! Hello! { "name": "NISHIKAWA, Akihiro", "nationality": "Japan", "work": "Microsoft", "favourites": [ "JVM", "GraalVM", "Azure" ], "expertise": [ "Application integration", "Container", "Serverless" ] }
3. Agenda ž Why this matters now? ž What can Java already do? What will Java support? ž How to migrate without breaking production ž What to do next
4. TL;DR ž Hidden crypto is the first migration problem. ž Even one small Spring Boot service hides more crypto than you would expect. ž Java already gives you a path: Bouncy Castle now, hybrid TLS in JDK 27. ž Inventory first. Hybrid key exchange first. Signatures next.
5. Why this matters now?
6. No cryptography stays safe forever. ž Even once-trusted algorithms like DES and SHA-1 were eventually broken. ž RSA and ECDSA have served us well, but they are not immune to the same fate — especially in the face of quantum computing.
7. 10-year retention period 2036 End of retention period 2026 Data protected with RSA/ECC
8. “Harvest Now, Decrypt Later” (HNDL) Attackers can capture encrypted data today and keep it for later decryption.
9. If “Q-Day” happened in the retention period... End of retention period Data protected with RSA/ECC HNDL attack 2026 Q-day 2036 Q-Day.org - Q-Day, Y2Q, PQC, Quantum Readiness, Quantum Security
10. Post-Quantum Cryptography (PQC) PQC algorithms fall into three main families: ž lattice-based (ML-KEM / ML-DSA; historically Kyber / Dilithium) ž hash-based (SLH-DSA / SPHINCS+) ž code-based (for example HQC) ž Each relies on mathematical problems that quantum computers are not known to solve efficiently.
11. Current NIST PQC Standards — and What Is Next Source: Post-Quantum Cryptography | CSRC Approved and in effect ž FIPS 203 (ML-KEM): key establishment ž FIPS 204 (ML-DSA): digital signatures ž FIPS 205 (SLH-DSA): digital signatures Selected / ongoing standardisation ž FN-DSA (FIPS 206 Initial Public Draft, Sep 2025; final expected late 2026 or early 2027) ž HQC: additional KEM, draft standard under way
12. Why act now?
13. Research Estimates for Breaking RSA-2048 Are Falling These are research estimates under specific hardware and error-correction assumptions, not deployed systems. How to factor 2048-bit RSA integers in 8 hours using 20 million noisy qubits – Quantum [2505.15917] How to factor 2048-bit RSA integers with less than a million noisy qubits Quantum computers need just 10,000 qubits to break the most secure encryption, scientists warn | Live Science 2025 2019 Mar 2026 20M noisy qubits, about 8 hours ~1M noisy qubits, under a week ~10k-100k physical qubits Architecture-specific estimate (preprint)
14. Awareness is high, but deployment is lagging 65% 69% are concerned about HNDL. expect current encryption to break within five years. 5% have fully deployed quantum-safe encryption. DigiCert, 2025, Survey of 1,042 senior cybersecurity managers (US, UK, AU) Capgemini 2025, Survey of 1,000 orgs (≥$1B revenue) in 13 countries
15. Global Government Timelines for PQC Migration Region Full PQC Transition United States ~2035 (NSA CNSA 2.0) European Union ~2035 (EC Recommendation 2024/1101) United Kingdom ~2035 (NCSC Guidance) Japan ~2035 (Cabinet Secretariat PQC Council) Australia ~2030 (ASD/ACSC Roadmap)
16. “It took many organizations over five years to migrate from the vulnerable primitive SHA-1 to its secure successor SHA-256, even after the necessary specifications and implementations were available.” – The PQC Migration Handbook Cryptographic migration takes time (SHA-1 deprecated 2017; many systems still used it in 2020+)
17. Industry Movement – Recent updates PQC is now an engineering roadmap, not only a research topic. 2026 JAN NIST highlighted migration and crypto agility work CSRC Presentations | CSRC Frequently Asked Questions about Post-Quantum Cryptography 2026 FEB JEP 527 completed and shipping in JDK 27 EA JEP 527 / Inside.java blog / JDK 27 Early-Access Release Notes 2026 MAR Google linked its 2029 PQC timeline to hardware and QEC progress Google’s timeline for PQC migration
18. Why Are Java Applications at Risk? ž They live for a long time. ž They use crypto everywhere. ž Infrastructure changes alone are not enough. ž Application integration still matters.
19. What can Java already do? What will Java support?
20. JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 JEP 510: Key Derivation Function (KDF) API JEP 496: ML-KEM JEP 497: ML-DSA JEP 452: KEM API (Key Encapsulation Mechanism) Evolution of PQC support in Java 2023 Sep 2025 Mar 2025 Sep 2026 Sep Java 21 Java 24 Java 25 Java 27
21. Java PQC Support What You Can Use Today, and What You Will Be Able To Use Tomorrow Introduced functionalities Practical path Java 21 KEM API Use Bouncy Castle where needed Java 24 ML-KEM, ML-DSA Java 25 KDF API Java 27 Hybrid TLS 1.3 (JEP 527) Prefer hybrid TLS through standard JSSE APIs Migration lesson ž Start with platform capability ž Do not start with hand-written crypto code
22. JEP 527 Post-quantum Hybrid Key Exchange for TLS 1.3 If you use the standard javax.net.ssl APIs, JDK 27 offers hybrid named groups first in ClientHello. ž The handshake goes hybrid when the peer also supports it. ž No need to change app code unless you override named groups. ž Override with -Djdk.tls.namedGroups=..."" Supported Named Groups ž X25519MLKEM768 ž SecP256r1MLKEM768 ž SecP384r1MLKEM1024
23. Hybrid TLS 1.3 X25519MLKEM768 – only what you need to know 3. Both sides derive two shared secrets: X25519 + ML-KEM 🖥 Client 🌐 Server 2. ServerHello selects the group and returns a hybrid key share 4. HKDF combines them into one handshake secret 1. ClientHello offers a hybrid group (e.g., X25519MLKEM768) NOTE: Certificates can stay RSA or ECDSA for now. JEP 527 changes key exchange first.
24. How to migrate without breaking production This is not only a standards problem. It is an estate-discovery problem. First find the hidden crypto. Then decide what moves first.
25. 1. Inventory Identify TLS endpoints, cipher suites, mTLS, cert stores. Catalogue code/JAR signing, JWT/OIDC/SAML algorithms. Locate custom cipher usages and data-at-rest encryption. Use static analysis/scanners for API/algorithm detection. ž Dependency libraries ž Configuration ž Certificate OIDs (Object Identifiers) Map sensitive data and required secrecy lifetime.
26. A Practical Four-Layer Crypto Inventory for Java Each layer covers a blind spot from the others. One grep is never enough. 1. Dependencies What crypto comes in through libraries or drivers? 2. Source & frameworks 3. Config & KeyStore 4. Runtime capability & Evidence Where does the application ask for crypto? What enables crypto with almost no Java code? What the JVM could use, and what it actually used under real traffic?
27. Layer 4 Needs Two Views Capability ž JCE providers ž supported cipher suites ž supported named groups Evidence ž JFR TLS handshakes ž X.509 validation ž security events Outside the JVM Edge TLS / Managed crypto / External identity For TLS 1.3: cipher suite != key exchange group Check named groups as well
28. Where Does Crypto Hide? A typical Spring Boot microservice — how many crypto usage points can you spot? src/main ├── java/com/example/pqcdemo │ ├── config │ │ └── SecurityConfig.java │ ├── controller │ │ └── ApiController.java │ ├── PqcDemoApplication.java │ └── service │ ├── EncryptionService.java │ ├── HmacService.java │ ├── JwtService.java │ └── LicenseService.java └── resources ├── application.properties └── keystore.p12 DEMO Code: https://github.com/anishi1222 /find-crypto-usages
29. What The Audit Finds - Dependencies Review first ž JWT signing libraries ž database drivers using TLS ž general-purpose crypto providers ▪ Quantum-vulnerable ▪ Needs review ▪ Low-risk ▪Nimbus JOSE+JWT JWS — RSA signing inside framework ▪Bouncy Castle General-purpose crypto provider ▪Google Tink Algorithm hidden in key template ▪Spring Security BCrypt, crypto utilities ▪PostgreSQL JDBC TLS via driver configuration - easy to miss in code review ▪Commons Codec Hashing/encoding utilities ▪JDK built-in JCA/JCE Always available
30. What The Audit Finds - Source and Configuration JCE / JCA API Calls ▪ KeyStore.getInstance (2 files) Configuration ▪ server.ssl.enabled=true ▪ datasource sslmode=verify-full Framework / Library Patterns ▪ NimbusJwtEncoder (RS256 signing) ▪ NimbusJwtDecoder (RS256 verification) ▪ JcaContentSignerBuilder (SHA256withRSA) ▪ Tink AEAD (AES-256-GCM) ▪ Tink KeysetHandle ▪ BC CMS / SignerInfoGenerator ▪ BC HMac + SHA256Digest
31. What The Audit Finds – KeyStore Indeed quantum-vulnerable, but... ▪RSA-2048 server key ▪RSA-signed certificate chain ž Used for HTTPS authentication in this service ž Same keystore is also referenced by JWT and licence flows in this demo ž Needs review for certificate and signature migration ž Does not prove the negotiated TLS named group
32. What The Audit Finds – JFR Runtime Audit Static analysis might miss runtime-only crypto behaviour ž TLS handshakes ž X.509 validation ž security-property changes ž deserialization-related security events Enable events below and capture with jcmd or a custom .jfc file ž jdk.TLSHandshake ž jdk.X509Validation ž jdk.X509Certificate ž jdk.SecurityPropertyModification ž jdk.Deserialization
33. How to Prove Hybrid TLS in Practice Built-in runtime evidence ž JFR / JDK Mission Control ž protocol version ž cipher suite ž certificate-validation events Exact named-group proof ž JSSE handshake debug ž packet capture ž custom audit event Practical rule ž JFR shows what happened ž one extra source proves the exact named group
34. Crypto is everywhere, and much of it is invisible. Quantum vulnerable Need review Low risk Total 5 14 3 22
35. 2. Prioritisation ❶ data in transit ❷ long-lived encrypted data ❸ code signing
36. Why HNDL Targets Key Exchange, Not Authentication ClientHello key_share: X25519 / X25519MLKEM768 🔑 Shared Secret derived here 🖥 Client 🌐 Server Application Data Application Data ServerHello key_share: X25519 / X25519MLKEM768 Certificate + CertificateVerify RSA / ECDSA signature 🔑 Server identity verified here This is what HNDL targets: Break the key exchange = decrypt ALL past sessions HNDL does NOT apply. Break the signature = forge future sessions only ▪ Key Exchange ▪ Authentication HNDL risk Past sessions decryptable No retroactive impact Time pressure Now (data already captured) Later (future threat only)
37. HNDL threatens the exchange, not authentication. KEM protects past confidentiality. Signatures protect future impersonation risk.
38. 3. Hybrid Use hybrid mode to reduce transition risk while the ecosystem is mixed. ž Hybrid = classical + PQC during transition ž Pure PQ = likely future end state in controlled ecosystems ž Use hybrid when interoperability is uncertain ž Use pure PQ only when you control and can test both ends
39. PKI Certificate Migration Private PKI pilot only — not a near-term public-web recommendation Today ž Move hybrid key exchange first for HNDL protection ž Pilot certificate changes only where you control both ends ž Test trust stores, chain validation, and certificate-size impact ž Keep RSA/ECDSA on the public web until browser, CA, and standards support is ready Decision rule ž Controlled ecosystem: experiment ž Open ecosystem: wait
40. key_share size is much bigger, but... Item Classical (X25519) Hybrid (X25519MLKEM768) ClientHello key_share 32 bytes 1,216 bytes (32 + 1,184) ServerHello key_share 32 bytes 1,120 bytes (32 + 1,088) Shared-Secret Input (HKDF) 32 bytes 64 bytes (32 + 32) (concatenated, fed into HKDF) Classical: X25519 (RFC 7748) Hybrid: X25519MLKEM768 (draft-ietf-tls-ecdhe-mlkem)
41. Why Is Hybrid Hard on TLS 1.2? Not impossible, but significantly harder than TLS 1.3. Three practical blockers ž Cipher-suite rigidity ž Message size and middleboxes ž IETF feature freeze Practical advice ž Upgrade to TLS 1.3 first, then add hybrid TLS.
42. 4. Crypto-Agility ž Change crypto policy and algorithms with minimal code change. ž Use inventory, configuration, and rollback to make migration repeatable.
43. Why? Resilience ž If one approved option changes, you can move to another with less disruption. Testing ž Roll out gradually, measure behaviour, and revert quickly if needed. Engineering effort ž Refactor hard-coded crypto before migration pressure arrives.
44. Bad code... //" hardcoded! Signature sig = Signature.getInstance("SHA256withRSA"); //" hardcoded! KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA", "SunRsaSign");
45. Design Principles ž No hard-code algorithm names or parameters ž Externalise choices in configuration ž Abstract crypto behind interfaces (strategy pattern) ž Leverage JCA provider abstraction ž Keep provider choice out of business code ž Prepare fallback toggles and feature flags Config file SignatureService RSASigner Specify algorithm (ML-DSA, RSA, etc.) sign() verify() MlDsaSigner Interface
46. Configuration e.g., application.yml Keep three things in configuration: 1. Separate modes by track 2. Use JCA Standard Names / complete transformations 3. TLS named-group order tls: key-exchange-mode: hybrid named-groups: - X25519MLKEM768 - x25519 certificates: mode: classical application-signatures: mode: classical legacy-verify-allowed: true
47. TLS configuration JDK 27 default ž X25519MLKEM768 is enabled by default. ž Override when needed ž JVM-wide: jdk.tls.namedGroups ž Per-connection: SSLParameters::"setNamedGroups(..."") Earlier JDKs ž Use provider-specific paths only if you need hybrid TLS.
48. 5. Phased Approach — Two Dimensions at the edge, or at the trust core? key exchange, or authentication? Where to start What to move first
49. Topology Comparison Outside-in (edge-first) ž First step: upgrade the edge TLS path ž Best for public web and mobile systems ž Faster change, narrower blast radius Inside-out (trust-core-first) ž First step: map internal trust dependencies and controlled service- to-service domains ž Best for tightly controlled internal ecosystems ž Slower change, broader coordination Note: topology order and primitive order are separate axes
50. Hybrid TLS Hybrid TLS Hybrid TLS Outside-in 3 Phases ž Roll out hybrid TLS in phases. ž Keep backward compatibility. ž Introduce hybrid certificates only where the client ecosystem is controlled. Backends Java app CDN/Proxy Client Classic TLS Classic TLS Classic TLS
51. Primitive Axis KEM First, Authentication Later. Ready today • Hybrid key exchange in TLS • Java 27 / JEP 527 • Browser and CDN deployment paths Later • PQC certificates for TLS authentication • RFC maturity • JSSE integration • Browser and CA ecosystem readiness ž Keep RSA/ECDSA certificates until the ecosystem is ready.
52. 6. Performance & Operational Impact on TLS Bulk cipher unchanged — AES/HKDF run at the same speed. Still measure: ž CPU / memory per handshake ž p50 / p95 handshake latency under real traffic ž connection-reuse rate (handshake cost amortises here) Handshake size and middlebox risk are on the earlier "key_share" slide.
53. 7. Testing Strategy 1. Interoperability - Cross-implementation (Java ↔ OpenSSL-based PQC TLS stack) - Hybrid TLS handshakes 2. Performance - Handshake latency - CPU/memory - Throughput 3. Fallback and rollback - Classical fallback paths - Legacy clients - Graceful failure modes 4. Policy enforcement - Allowed / denied algorithms - Visible constraint failure
54. 2025 2026 2027 2028 2029 2030 Discover Protect Expand trust Retire legacy 8. Migration Timeline — Anonymized Customer Case JDK 27 released in September 2026 Why it took longer than expected - 200+ services / 3,000+ touchpoints, mostly on Java 17 - 60%+ of crypto sat outside the security module - Same 4-layer model as the demo — just at estate scale
55. Top Migration Blockers — and the Practical Response Network - test larger handshakes on the real path - use canary rollout and fallback Certificates and keys - start with private PKI - plan for larger keys, signatures, and chain size Libraries and vendors - pin versions - test upgrades separately - ask vendors for PQC timelines early Operations - capture runtime evidence - monitor fallback to classical-only paths - prepare rollback before rollout
56. What to do next
57. Key Takeaways: Three things to remember Inventory ž You cannot migrate what you cannot find. Hybrid key exchange ž The practical bridge during transition. ž Not the permanent end state. Start now ž Migration spans years, not months.
58. Call to Action … and ask key vendors for their PQC roadmap. Developers Architects Security leads Managers ž Check runtime providers / TLS evidence ž Externalise algorithm and provider choice ž Build a Java 27 hybrid-TLS PoC now ž Plan production adoption on the first suitable LTS carrying JEP 527 ž Brief leadership on HNDL risk ž Fund the roadmap and ask key vendors for their PQC timelines
59. Start this week! ž Run keytool -list -v on one service keystore ž Do one 4-layer crypto inventory on that same service ž Test one hybrid TLS path with JDK 27 EA or a provider-specific hybrid-TLS stack That is how PQC migration starts in the real world.
60. Merci beaucoup! ありがとう! Thank you!