原文はこちら。
The original article was written by Sean Mullan (Java Security Tech Lead, Oracle).
https://seanjmullan.org/blog/2021/03/18/jdk16
2021年3月16日にJDK16がリリースされました これまでのブログと同様に、今回のリリースで最も興味深く有用と思われるセキュリティ機能の強化点をまとめました。また、それらを適切なカテゴリー(暗号、TLSなど)に分類したので、それぞれの分野で何が変わったのかを簡単に見つけることができるはずです。JDK 16のリリースノートには、これらの強化点やその他の強化点についての詳細が記載されています。
JDK 16
https://jdk.java.net/16
Sean Mullan’s Blog
https://seanjmullan.org/blog/
JDK 16 Release Notes
https://jdk.java.net/16/release-notes
また、JDK 16の他の機能として、特にセキュリティライブラリの分野ではありませんが、JEP 396(Strongly Encapsulate JDK Internals by Default)は特筆すべきものです。この変更により、「JDK 8に存在し、重要な内部APIを含まないパッケージは、デフォルトではオープンでなくなる」、つまり、JDK外のコードからはアクセスできなくなっています。これにより、標準状態におけるセキュリティが大きく向上しています。
JEP 396: Strongly Encapsulate JDK Internals by Default
https://openjdk.java.net/jeps/396
Table of Contents
Crypto
SHA-3 signature algorithm support
署名アルゴリズムのSHA-3ファミリーが、RSA、EC、DSAキーに対応しました。各鍵タイプのアルゴリズムは以下の通りです。
- RSA:
SHA3-224withRSA,SHA3-256withRSA,SHA3-384withRSA,SHA3-512withRSA - EC:
SHA3-224withECDSA,SHA3-256withECDSA,SHA3-384withECDSA,SHA3-512withECDSA - DSA:
SHA3-224withDSA,SHA3-256withDSA,SHA3-384withDSA,SHA3-512withDSA,SHA384withDSA,SHA512withDSA
ECとDSAのアルゴリズムには、P1363形式を使用したアルゴリズムも含まれます。名前にinP1363Formatがついています。SHA-3は、SHA-2と同等の強度を持つとされるダイジェストアルゴリズムです。これらのアルゴリズムにアクセスするには、java.security.Signature APIを使用します。
Class Signature
https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/security/Signature.html
Signature sig = Signature.getInstance("SHA3-256withRSA");
今回は、JDKにおけるSHA-3のサポートを拡張します。JDK 9では、SHA-3ハッシュアルゴリズムのサポートが追加され、JDK 15 では、SHA-3 hmac アルゴリズムのサポートが追加されました。
JEP 287: SHA-3 Hash Algorithms
https://openjdk.java.net/jeps/287
Support SHA-3 based Hmac algorithms
https://bugs.openjdk.java.net/browse/JDK-8172680
The SunPKCS11 provider now supports SHA-3 algorithms
SunPKCS11プロバイダーもアップデートによりSHA-3アルゴリズムをサポートします。PKCS11実装を使っている場合は、Javaアプリケーションからこれらのアルゴリズムにアクセスできます。利用可能なアルゴリズムは以下の通りです。
MessageDigest: SHA3-224, SHA3-256, SHA3-384, SHA3-512Mac: HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512Signature: SHA3-224withDSA, SHA3-256withDSA, SHA3-384withDSA, SHA3-512withDSA, SHA3-224withDSAinP1363Format, SHA3-256withDSAinP1363Format, SHA3-384withDSAinP1363Format, SHA3-512withDSAinP1363Format, SHA3-224withECDSA, SHA3-256withECDSA, SHA3-384withECDSA, SHA3-512withECDSA, SHA3-224withECDSAinP1363Format, SHA3-256withECDSAinP1363Format, SHA3-384withECDSAinP1363Format, SHA3-512withECDSAinP1363Format, SHA3-224withRSA, SHA3-256withRSA, SHA3-384withRSA, SHA3-512withRSA, SHA3-224withRSASSA-PSS, SHA3-256withRSASSA-PSS, SHA3-384withRSASSA-PSS, SHA3-512withRSASSA-PSS.KeyGenerator: HmacMD5, HmacSHA1, HmacSHA224, HmacSHA256, HmacSHA384, HmacSHA512, HmacSHA512/224, HmacSHA512/256, HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, HmacSHA3-512.
The default PKCS12 algorithms have been strengthened
証明書と鍵の暗号化、および PKCS12 キーストアの整合性の保護に使用されるデフォルトのアルゴリズムが、より強力なアルゴリズムにアップグレードされました。java.security 設定ファイル内の以下のセキュリティプロパティは、SHA256 および AES-256 を使用する PBES2 に基づくより強力なアルゴリズムに設定されます。
keystore.pkcs12.certProtectionAlgorithm = PBEWithHmacSHA256AndAES_256
keystore.pkcs12.keyProtectionAlgorithm = PBEWithHmacSHA256AndAES_256
keystore.pkcs12.macAlgorithm = HmacPBESHA256
以前のアルゴリズムのデフォルトで保護されている既存の PKCS12 キーストアとの間で相互運用性の問題が発生した場合は、システムプロパティ keystore.pkcs12.legacy を設定することで、このキーストアをロードし、古いアルゴリズムを使用してその内容を読み取ることができます。この変更は、2021年7月リリース予定のOracle JDK 11、8、7の各リリースへのバックポートを目指しており、Oracle JRE and JDK Cryptographic Roadmapに記載されています(”Upgrade the default PKCS12 encryption/MAC algorithms” というActionがある行を参照)。
Oracle JRE and JDK Cryptographic Roadmap
https://java.com/en/jre-jdk-cryptoroadmap.html
The native elliptic curve implementations have been removed
SunECプロバイダのネイティブCコードで実装されていた楕円曲線が削除されました。これらの曲線は、もはや推奨されておらず、最新の公式や技術を用いて実装されていません。今回の変更で削除された楕円曲線は以下のとおりです。
secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1
以下の楕円曲線はJavaで実装されており、最新の技術を使い、今回の変更の影響はありません。
secp256r1, secp384r1, secp521r1, x25519, x448, ed25519, ed448
PKI
Several java.security.cert APIs that represent X.500 distinguished names as String or Principal objects have been deprecated
識別名(distinguished names、DN)をStringやPrincipalオブジェクトで表現すると、エンコーディングの違いや情報の消失などの問題が発生します。これらのAPIには、識別名をX500Principalやbyte[]で表現する代替方法があります。非推奨のAPIは以下の通りです。
- X509Certificate.getIssuerDN()
- X509Certificate.getSubjectDN()
- X509CRL.getIssuerDN()
- X509CertSelector.setIssuer(String)
- X509CertSelector.setSubject(String)
- X509CertSelector.getIssuerAsString()
- X509CertSelector.getSubjectAsString()
- X509CRLSelector.addIssuerName(String)
Root CA certificates with 1024-bit keys have been removed
1024ビットのRSA公開鍵を持つ5個のルート証明書が、cacertsキーストアから削除されました。このサイズの鍵は弱く、もはや推奨されません。削除された5個のルート証明書は以下の通りです。
Thawte Premium Server CA
このルート証明書はDigiCertが有しており、以下の識別名を持ちます。
EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
VeriSign Class 2 Public Primary Certification Authority – G2
このルート証明書はDigiCertが有しており、以下の識別名を持ちます。
OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
VeriSign Class 3 Public Primary Certification Authority
このルート証明書はDigiCertが有しており、以下の識別名を持ちます。
OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
VeriSign Class 3 Public Primary Certification Authority – G2
このルート証明書はDigiCertが有しており、以下の識別名を持ちます。
OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
Thawte Timestamping CA
このルート証明書はDigiCertが有しており、以下の識別名を持ちます。
CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA
この変更も、2021年7月リリース予定のOracle JDK 11、8、7の各リリースへのバックポートを目指しており、Oracle JRE and JDK Cryptographic Roadmapに記載されています(”Remove root certificates with 1024-bit keys”というActionがある行を参照)。
Oracle JRE and JDK Cryptographic Roadmap
https://java.com/en/jre-jdk-cryptoroadmap.html
この変更に伴う互換性のリスクは低いと考えられますが、問題が発生した場合は、上記のリンクから証明書をダウンロードして、自己責任でcacertsキーストアにインポートできます。
New Entrust Root CA certificate added
“Entrust Root Certification Authority – G4” 証明書がcacertsキーストアに追加されました。このルート証明書はEntrustが有しており、以下の識別名を持ちます。
CN=Entrust Root Certification Authority - G4, OU="(c) 2015 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
このルート証明書もまたOracle JDK 11.0.9、8u271、7u281リリースのcacertsキーストアに追加されています。
New SSL Root CA certificates added
SSL.comから3個の新たなルートCA証明書がcacertsキーストアに追加されました。
SSL.com Root Certification Authority RSA
このルート証明書は以下の識別名を持ちます。
CN=SSL.com Root Certification Authority RSA, O=SSL Corporation, L=Houston, ST=Texas, C=US
SSL.com EV Root Certification Authority RSA R2
このルート証明書は以下の識別名を持ちます。
CN=SSL.com EV Root Certification Authority RSA R2, O=SSL Corporation, L=Houston, ST=Texas, C=US
SSL.com Root Certification Authority ECC
このルート証明書は以下の識別名を持ちます。
CN=SSL.com Root Certification Authority ECC, O=SSL Corporation, L=Houston, ST=Texas, C=US
これらのルート証明書もまたOracle JDK 11.0.9、8u271、7u281リリースのcacertsキーストアに追加されています。
TLS
TLS support for the EdDSA signature algorithm
JDKのTLS実装に、EdDSA署名アルゴリズムのサポートが追加されました。EdDSAはサイドチャネル攻撃に耐性があるように設計されています。プラットフォーム非依存のJavaの実装では、シークレットで分岐せず、タイミングもシークレットに依存しません。JCEによるEdDSAのサポートはJDK 15で追加され、JEP 339で規定されています。
JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
https://openjdk.java.net/jeps/339
このサポートはTLSバージョン1.0~1.3に適用され、TLS 1.0~1.2についてはRFC 8422、TLS 1.3についてはRFC 8446で規定されています。
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
https://tools.ietf.org/html/rfc8422
The Transport Layer Security (TLS) Protocol Version 1.3
https://tools.ietf.org/html/rfc8446
特に、EdDSA鍵を持つ証明書、またはEdDSA署名アルゴリズムで署名された証明書がサポートされ、クライアントやサーバーの認証に使用できるようになりました。また、以下の署名方式にも対応しました。
ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512
TLS 1.0 and 1.1 are now disabled by default
TLS 1.0および1.1プロトコルがデフォルトで無効化されました。そのため標準状態でのセキュリティが向上しています。これらのプロトコルにはさまざまな弱点があり、もはや推奨できません。詳細はRFC 8996を参照してください。
Deprecating TLS 1.0 and TLS 1.1
https://datatracker.ietf.org/doc/rfc8996/
アプリケーションでは、JDKがサポートしているより安全なTLS 1.2または1.3プロトコルを使用する必要があります。ただし、問題が発生してアプリケーションを機能させる必要がある場合は、(自己責任ではありますが)java.security設定ファイルのjdk.tls.disabledAlgorithmsセキュリティ・プロパティから「TLSv1」または「TLSv1.1」を削除することで、TLS 1.0または1.1を再び有効にできます。
この変更は、2021年4月リリース予定のOracle JDK 11、8、7にもバックポートされる予定で、Oracle JRE and JDK Cryptographic Roadmapに記載されています(“Disable TLS 1.0 and TLS 1.1”というActionがある行を参照してください)。
Oracle JRE and JDK Cryptographic Roadmap
https://java.com/en/jre-jdk-cryptoroadmap.html
Signed JARs
Signed JAR support for RSASSA-PSS and EdDSA
RSASSA-PSSとEdDSAの署名アルゴリズムでJARを署名できるようになりました。これらのアルゴリズムのサポートが、jarsignerツールとJarSigner APIに追加されました。
Package jdk.security.jarsigner
https://docs.oracle.com/en/java/javase/16/docs/api/jdk.jartool/jdk/security/jarsigner/package-summary.html
jarsignerの-sigalgオプションは、署名アルゴリズムの値として、"RSASSA-PSS"、"EdDSA"、"Ed25519"、"Ed448"を受け付けるようになりました。
以下は、Ed25519アルゴリズムでJARを署名する例です。
jarsigner -keystore keystore -sigalg Ed25519 -verbose App.jar edkey
Enter Passphrase for keystore:
adding: META-INF/MANIFEST.MF
adding: META-INF/EDKEY.SF
adding: META-INF/EDKEY.EC
signing: App.class
>>> Signer
X.509, CN=edkey
Signature algorithm: Ed25519, 255-bit key
[trusted certificate]
jar signed.
Warning:
The signer's certificate is self-signed.