JDK 24 安全增強
1. 引言
JDK 24 帶來了關鍵的安全升級，強化了加密、PKI 和 TLS。本文將深入探討 Java JDK 24 版本所帶來的安全性改進。
2. 後量子密碼學
隨著量子電腦的普及，密碼學面臨迫在眉睫的威脅。量子電腦最終將強大到足以破解現有的加密標準。為了保持領先地位，我們正在整合一些即使是量子處理器也無法破解的演算法。 Shor 演算法能夠以指數級的速度分解大素數，從而徹底破解 TLS 握手和簽章中使用的 RSA、ECC 和 Diffie-Hellman 公鑰系統。
JDK 24 帶來了大量的後量子加密安全改進，包括JEP 496 、 JEP 497和JEP 478 。
2.1. JEP 496：ML-KEM 金鑰封裝機制
Java 透過 JEP 496 將抗量子金鑰封裝機制 (ML-KEM) 加入 JDK 24 中。這是一種lattice-based金鑰封裝機制，允許我們在不安全的頻道上安全地建立共用金鑰。透過現在就實現它，我們可以確保即使在後量子時代，我們的通訊仍然保持私密性。
它帶來了新的KeyPairGenerator 、 KEM和KeyFactory APIs以及多個參數集（ ML-KEM-512/-768/-1024 ），旨在抵禦未來可能破壞 RSA/DH 式金鑰交換的量子攻擊。
2.2. JEP 497：ML-DSA 數位簽章演算法
讓我們來談談 JEP 497，它專注於數位簽章。 Java 24新增了ML-DSA ，這是用於驗證資料真實性和完整性的標準。當我們使用 ML-DSA 對程式碼或文件進行簽署時，我們可以確信它們沒有被未來的量子攻擊者篡改。
為了使用它，我們將使用名為“ML-DSA”新演算法，並配合KeyPairGenerator和Signature API。我們也可以選擇特定的安全強度。
2.3. JEP 478：金鑰派生函數 (KDF) API
Java透過JEP 478引進了新的KDF API 。它提供了一種統一的方式，讓我們能夠從秘密材料中派生加密金鑰。它支援HKDF等現代演算法，並且設計為可擴展的。現在，我們可以跨不同的協定更靈活、更安全地管理金鑰。以前，我們必須將KDFs強制整合到現有的類別中，例如SecretKeyFactory 。現在，我們有了一個簡潔的、一流的javax.crypto.KDF類別。
3. 核心密碼學改進
本節將探討 JDK 24 如何改善核心加密引擎。這些更新不僅涉及新的演算法，還旨在提升現有演算法的速度、標準化程度，並使其與高階硬體相容。
3.1. 標準化的RSASSA-PSS雜湊和MGF名稱
透過此次更新，我們現在有了一套清晰、有據可查的雜湊函數和遮罩生成函數 (MGF) 標準名稱。
我們可以使用PSSParameterSpec和MGF1ParameterSpec類別來定義這些參數。例如，現在我們可以使用標準化的字串常數在MGF1ParameterSpec中更明確地指向SHA3-256 。
這樣可以確保不同 Java 提供者之間的安全性配置保持一致。
3.2. SHA-3 訊息摘要效能改進
JDK 24 優化了MessageDigest類別中的SHA-3實作。透過利用現代 CPU 指令，此次更新顯著降低了計算哈希值的開銷。
無論我們是在驗證檔案完整性還是建立數位簽名， MessageDigest.getInstance(“SHA3-256”)呼叫現在在支援的硬體上執行速度都會快得多。
3.3. PKCS#11 AES 密文竊取 (CTS) 模式支持
AES-CTS （具有密文竊取功能的高級加密標準）是一種對稱加密模式，允許在不需要填充的情況下加密數據，使密文大小與明文大小相同。
這在智慧卡上相當常見。
隨著 Java 24 的更新，硬體安全模組 (HSM) 或智慧卡現在透過SunPKCS11提供者更好地支援 AES-CTS。
對於像 Kerberos 這樣的協定來說，這一點至關重要，因為 Kerberos 需要「密文竊取」來處理無法完美適應區塊大小而不添加額外填充的資料。
我們可以使用新的cipherTextStealingVariant屬性（從 CS1、CS2 或 CS3 中選擇）在PKCS#11設定檔中進行設定。這使得 Java 能夠與期望使用這些特定 AES 變體的本地硬體完美通訊。
4. PKI 和信任庫更新
JDK 24 對預設信任庫以及我們管理憑證的方式來保持其基礎穩固性帶來了重要的更新。
4.1. 精選信任庫更新
JDK 24**引進了更新的****cacerts** 信任庫**，**即預先設定的來自受信任憑證授權單位 (CA) 的根憑證集合。此版本新增了多個根證書。
同時，隨著 Java 24 的更新，過期或不受信任的憑證已被移除。這種自動化維護機制可確保我們不會意外地信任過時或已被竄改的憑證錨點。
4.2. 增強對弱演算法的停用
JDK 24 透過模式比對提供了更精細的憑證信任控制。新增的機制讓我們可以使用通配符語法在jdk.tls.disabledAlgorithms安全屬性中停用TLS cipher suites或憑證類型。
例如，我們現在可以使用TLS_RSA_*來廣泛限制缺乏前向保密性的舊式加密套件。
隨著安全標準的不斷發展，這使得我們的設定檔更加簡潔，也更容易管理。
5. 安全模型演進
安全模型中最顯著的變化是永久禁用了安全管理器（ JEP 486 ）。隨著 Java 24 的更新，我們無法再在啟動時啟用它，也無法在執行時間安裝自訂的安全管理器。這標誌著本地執行程式碼「沙箱」時代的終結。透過移除這一複雜的遺留層，JDK 24 簡化了內部安全架構，降低了維護開銷，並提升了依賴容器級或作業系統級安全性的現代應用程式的效能。
此外，JDK 24 對原生程式碼採取了更嚴格的要求。透過JEP 472 ，平台準備限制 JNI（Java 本地介面）的使用。這將促使我們轉向更安全的外部函數與記憶體 (FFM) API，確保我們的原生整合更加透明，並更好地符合平台的長期完整性目標。
6. 結論
本文探討了 Java 24 如何透過其 JEP 整合後量子密碼技術，使我們的系統能夠應對未來的威脅。現在，我們可以自信地部署 ML-KEM 和 ML-DSA，因為我們的加密和簽章機制能夠經得起量子運算的考驗。同時，此次 Java 24 更新也克服了傳統技術的許多障礙。移除安全管理器並轉向受限的本地訪問，體現了 Java 致力於建立更精簡、更有效率、更透明的安全模型。最終，這些增強功能確保 Java 生態系統持續維持企業安全領域的黃金標準。