Making the JDK More Secure

Sean Mullan Oracle September 19, 2016 @seanjmullan

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

1 Java Security Overview

2 Making the JDK More Secure

3 Cryptography

4 Public Key Infrastructure

5 Transport Layer Security

6 Other Areas

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 4 Java Security Overview • Java Security technology can generally be divided into three areas • Language and Runtime security controls • APIs and Libraries for integrating security into applications • Tools for managing security

Java Language and Runtime Security

JAAS GSSAPI/Kerberos XML Signature

APIs and Libraries JSSE (SSL/TLS) SASL

JCE (crypto) PKI

Java Language and Runtime Security

Tools keytool jarsigner policytool kinit, klist, ktab

JAAS GSSAPI/Kerberos XML Signature

APIs and Libraries JSSE (SSL/TLS) SASL

JCE (crypto) PKI

Java Language and Runtime Security

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 9 Overall Goals • Provide out-of-the box secure defaults • Restrict broken or weak cryptographic algorithms and protocols • Ensure API and tool defaults are safe to use • Provide sufficiently strong algorithms for every security function • Incorporate new security standards • Adhere to industry best practices

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 10 What does “Secure by Default” actually mean? • “Security by default, in software, means that the default configuration settings are the most secure settings possible, which are not necessarily the most user friendly settings.

In many cases, security and user friendliness are evaluated based on both risk analysis and usability tests. This leads to the discussion of what the most secure settings actually are. As a result, the precise meaning of ‘secure by default’ remains undefined.”

https://en.wikipedia.org/wiki/Secure_by_default

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 12 Crypto Roadmap http://java.com/cryptoroadmap • Publicly available roadmap of upcoming restrictions and changes to security defaults • Provides advance notice of the changes and guidance for determining if you may be affected • Also shows all changes that have been released in the past year • Does not apply to third party security providers • Initially published on August 18, 2016

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 16 Evolution of Java and Secure by Default • Initial focus: provide protection against untrusted code • Default sandbox policy • Enforced by a SecurityManager • As scope of security APIs expanded, new defaults became necessary • Cryptographic algorithms were weakening or being broken • TLS was increasingly under attack • Going forward, module system will introduce additional safeguards • Not just for code running with a Security Manager

Tools keytool jarsigner policytool kinit, klist, ktab

JAAS GSSAPI/Kerberos XML Signature

APIs and Libraries JSSE (SSL/TLS) SASL

JCE (crypto) PKI

Java Language and Runtime Security

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 19 Cryptography (JCE) Secure by Default Guidelines • Direct access to crypto algorithms (via JCE) is not restricted • Ensures long-term compatibility • Applications can still use MD2, but they do so at their own risk • Required algorithms are evaluated at each major release • Ensures every SE implementation supports industry-recommended algorithms • API and Provider defaults are changed if necessary • Stronger or new algorithms are added over time • Ideally, there should be at least one secure algorithm for each cryptographic primitive (MessageDigest, Signature, Cipher, etc)

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 20 Algorithm Requirements • Every implementation of Java SE MUST support a minimum set of security algorithms • These required algorithms improve compatibility, interoperability and security • The list is evaluated at each release. New requirements as of JDK 9: • Signature: SHA256withDSA • KeyPairGenerator (implementations must support the key size in parens): DSA (2048), DiffieHellman (2048, 4096), RSA (4096) • AlgorithmParameterGenerator: DSA (2048), DiffieHellman (2048, 4096) • Cipher: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128) • SSLContext: TLSv1.1, TLSv1.2 • TrustManagerFactory: PKIX • Full list is at http://download.java.net/java/jdk9/docs/technotes/guides/security/ StandardNames.html#impl

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 21 Cryptographic API and Provider Defaults • Several JCE APIs include optional parameters that default to API or implementation specific values if not specified • We periodically review these to ensure the defaults are secure. In JDK 9, we have changed the following defaults: • The default key size for the RSA and DiffieHellman KeyPairGenerator and the DiffieHellman AlgorithmParameterGenerator implementations increased from 1024 bits to 2048 bits • The default KeyStore type changed from JKS to PKCS12 • KeyStore.getDefaultType() now returns “PKCS12” • See JEP 229 for more information: http://openjdk.java.net/jeps/229

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 22 New JDK 9 Cryptographic Algorithms • SHA-3 • FIPS PUB 202 • Support for 4 variants: SHA3-224, SHA3-256, SHA3-384, SHA3-512 • Usage is exactly the same as other MessageDigest algorithms:

MessageDigest md = MessageDigest.getInstance(“SHA3-256”); md.update(buffer); byte[] digest = md.digest();

• See JEP 287 for more information: http://openjdk.java.net/jeps/287

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 23 New JDK 9 Cryptographic Algorithms (continued) • DRBG SecureRandom Algorithms • DRBG = Deterministic Random Bit Generator • NIST Special Publication 800-90Ar1 • Uses modern algorithms as strong as SHA-512 and AES-256 • API can be configured with different security strengths and features to match user requirements • Implementation of all 3 mechanisms: Hash_DRBG, HMAC_DRBG, CTR_DRBG • default mechanism is Hash_DRBG, but can be changed using the securerandom.drbg.config security property • See JEP 273 for more information: http://openjdk.java.net/jeps/273

// Requests a strong DRBG instance with a personalization string. The // returned instance is guaranteed to support 256 bits of security // strength with prediction resistance and reseeding capability. SecureRandom drbg = SecureRandom.getInstance(“DRBG", DrbgParameters.instantiation( 256, DrbgParameters.Capability.PR_AND_RESEED, "hello".getBytes()));

// Generates random bytes. Prediction resistance is not requested, but // an additional input is specified. byte[] buffer = new byte[32]; drbg.nextBytes(buffer, DrbgParameters.nextBytes(-1, false, "more".getBytes()));

// Reseeds this instance. Prediction resistance is not requested, but // an additional input is specified. drbg.reseed(DrbgParameters.reseed(false, "extra".getBytes()));

Tools keytool jarsigner policytool kinit, klist, ktab

JAAS GSSAPI/Kerberos XML Signature

APIs and Libraries JSSE (SSL/TLS) SASL

JCE (crypto) PKI

Java Language and Runtime Security

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 27 Public Key Infrastructure Secure by Default Guidelines • Restrict certificates that are signed with weak or broken algorithms or key sizes by default • Certificates are commonly used to authenticate entities over a network • Restrictions are enforced in the PKIX implementation of the CertPathValidator and CertPathBuilder APIs • Certificates signed with restricted algorithms will be rejected • Restricted algorithms are controlled by the jdk.certpath.disabledAlgorithms Security Property • Restrictions also apply to revocation information (CRLs and OCSP responses)

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 28 The jdk.certpath.disabledAlgorithms Security Property • Contains a list of algorithms and key sizes that are disabled by default • The current value (as of JDK 9) is set to: jdk.certpath.disabledAlgorithms=MD2, MD5, \ SHA1 jdkCA & denyAfter 2017-01-01, \ RSA keySize < 1024, DSA keySize < 1024, \ EC keySize < 224 • Which means the following certificates will be blocked by default: • Those signed with MD2 or MD5 based algorithms (ex: MD5withRSA) • (SHA1 discussed later) • Those containing RSA or DSA public keys less than 1024 bits • Those containing EC keys less than 224 bits

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 29 Impact of Restrictions • What type of Exception is thrown? • CertPathValidator will throw a CertPathValidatorException with a message like one of the following: • “Algorithm constraints check failed on signature algorithm: MD5withRSA” • “Algorithm constraints check failed on keysize: 512” • How do I know if my certificates may be affected? • Use keytool -printcert to see what algorithms are used in your certificates • Reverting the change (Not Recommended) • Remove the algorithm or key size restriction from the jdk.certpath.disabledAlgorithms property

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 30 Upcoming PKI Restrictions • Disable SHA-1 in certificates • Phase 1 • JDK 9 only • Disable certificate chains that are anchored by roots in the cacerts file • Local/enterprise Certificate Authorities not affected • Signed code that is timestamped before end-of-year is ok • Phase 2 • Backports to earlier releases. See crypto roadmap for targeted dates and releases. • Later phases • Stricter restrictions (ex: all SHA-1 certificates restricted) • See JEP 288 for more information: http://openjdk.java.net/jeps/288

Tools keytool jarsigner policytool kinit, klist, ktab

JAAS GSSAPI/Kerberos XML Signature

APIs and Libraries JSSE (SSL/TLS) SASL

JCE (crypto) PKI

Java Language and Runtime Security

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 33 TLS/SSL (JSSE) Secure by Default Guidelines • Restrict weak or broken algorithms and protocols by default • Applies to algorithms used in protocol version negotiation, cipher suite selection, and peer authentication and key exchange mechanisms • Also applies to DTLS • Restrictions are enforced in the SunJSSE provider implementation of the JSSE API • Strive to adhere to best practices such as RFC 7525 • Integrate new protocols and features that improve security

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 34 The jdk.tls.disabledAlgorithms Security Property • Contains a list of protocols, algorithms, and key sizes that are disabled by default • Disabled algorithms will not be negotiated when establishing a TLS connection even if they are explicitly enabled by an application • The current value (as of JDK 9) is set to: jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, \ DH keySize < 1024, EC keySize < 224

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 35 The jdk.tls.legacyAlgorithms Security Property • Contains a list of cipher suites and algorithms that are negotiated only if nothing stronger is enabled • Allows weak algorithms to be phased out • The current value (as of JDK 9) is set to: jdk.tls.legacyAlgorithms=K_NULL, C_NULL, M_NULL, \ DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_anon_EXPORT, \ DH_DSS_EXPORT, DH_RSA_EXPORT, RSA_EXPORT, \ DH_anon, ECDH_anon, RC4_128, RC4_40, DES_CBC, DES40_CBC

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 36 RFC 7525 Recommendations for Secure Use of TLS and DTLS • Provides guidance on how TLS can be used securely • Contains 51 recommendations in the form of requirements (MUST, SHOULD, RECOMMENDED, etc) • Bernd Eckenfels created a RFC 7525 scorecard for the JDK TLS implementation (SunJSSE) • JDK 8: 39 compliant, 8 not-applicable, 4 not-compliant • JDK 9: 43 compliant, 6 not-applicable, 2 not-compliant • https://docs.google.com/spreadsheets/d/ 135Eqf3RCpYLcmVHOIPb_Q7pzFde9yqJI_oD2jvpnKPE/edit#gid=0

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 37 RFC 7525 (Continued) A look at some of the requirements • MUST not negotiate SSLv3 • SSLv3 is disabled by default • MUST support TLS 1.2 • TLS 1.2 is enabled by default • MUST not negotiate RC4 ciphers • RC4 is disabled by default • SHOULD support OCSP status request extensions • OCSP Stapling support added in JDK 9

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 38 New JDK 9 TLS Features • Datagram Transport Layer Security (DTLS) • OCSP Stapling • Application-Layer Protocol Negotiation (ALPN) Extension

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 39 Datagram Transport Layer Security (DTLS) • Extends the JSSE API and implementation to support DTLS (RFCs 4347 and 6347) • DTLS allows applications to use TLS over an unreliable transport channel such as UDP • An increasing number of application protocols use UDP, e.g.: SIP, CoAP, SRTP • Applications use the SSLEngine programming model to use DTLS • Disabled/restricted algorithms are enforced • See JEP 219 for more information: http://openjdk.java.net/jeps/219

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 40 OCSP Stapling for TLS • Implement the TLS Certificate Status Request Extensions (RFCs 6066 and 6961) • Client-side OCSP checking incurs significant performance overhead • With OCSP Stapling, the server is responsible for obtaining and sending the OCSPResponse to the client. This has several benefits: • Performance: responses can be cached and sent to all clients • Security • Allows captive portals to check revocation status • Avoids client-side privacy leaks • See JEP 249 for more information: http://openjdk.java.net/jeps/249

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 41 Application-Layer Protocol Negotiation Extension • The ALPN extension allows a client to provide a list of the application-layer protocols it supports, in order of preference. • A server can then select one of the advertised client protocols and tell the client which protocol will be used in the TLS connection. • One important consumer of this TLS extension will be the HTTP/2 client (JEP 110). • See JEP 244 for more information: http://openjdk.java.net/jeps/ 244

Tools keytool jarsigner policytool kinit, klist, ktab

JAAS GSSAPI/Kerberos XML Signature

APIs and Libraries JSSE (SSL/TLS) SASL

JCE (crypto) PKI

Java Language and Runtime Security

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 44 Module System Security Features • Strong encapsulation • A module’s packages must be exported for its public types to be accessible to other modules, e.g.: module java.security.sasl { requires java.logging; exports javax.security.sasl; } • Qualified exports allow you to export public types to one or more modules, e.g.: module java.security.sasl { requires java.logging; exports javax.security.sasl; exports com.sun.security.sasl.util to jdk.security.jgss; }

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 45 Module System Security Features (continued) • Encapsulate most internal APIs (JEP 260) • With a few exceptions, all internal JDK APIs will be inaccessible by default • Even if a Security Manager is not enabled • IllegalAccessError will be thrown if a SecurityManager is disabled • AccessControlException will be thrown if a SecurityManager is enabled and package is listed in the package.access security property

• New Platform Class Loader • Modules loaded by the Platform Class Loader can be de-privileged • Apply principle of least privilege, and only grant required permissions, e.g.: grant codeBase “jrt:/jdk.crypto.ec” { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.*"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.util.PropertyPermission "*", "read"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; permission java.security.SecurityPermission "clearProviderProperties.SunEC"; permission java.security.SecurityPermission "removeProviderProperty.SunEC"; }; • Modules loaded by Platform Class Loader: java.activation, java.compiler, java.corba, java.scripting, java.security.jgss, java.smartcardio, java.sql, java.sql.rowset, java.xml.bind, java.xml.crypto, java.xml.ws, jdk.charsets, jdk.crypto.ec, jdk.crypto.pkcs11, jdk.dynalink, jdk.internal.le, jdk.jsobject, jdk.localedata, jdk.naming.dns, jdk.scripting.nashorn, jdk.scripting.nashorn.shell, jdk.security.auth, jdk.security.jgss, jdk.zipfs

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 47 Kerberos/XML Signature • Kerberos • DES disabled by default • Can be reenabled by setting allow_weak_crypto=true in krb5.conf • XML Signature • Secure Mode blocks potentially hostile signatures • Forbids XSLT, MD5, limits number of References/Transforms, helps prevent wrapping attacks, and more • Enabled by setting the property org.jcp.xml.dsig.secureValidation to true or running with a SecurityManager • See https://blogs.oracle.com/mullan/entry/how_to_use_the_xml for more info

Key Size Key Type (in bits) DSA 2048

RSA 2048

EC 256

• keytool default signature algorithm (-gencert, -genkeypair, -certreq options) • Follows recommendations in NIST SP 800-57 Part 1-Rev 3.

Key Size Key Type Signature Algorithm (in bits) DSA >7680 SHA512withDSA RSA >7680 SHA512withRSA EC >512 SHA512withECDSA DSA >3072 SHA384withDSA RSA >3071 SHA384withRSA EC >384 SHA384withECDSA DSA <=3072 SHA256withDSA RSA <=3072 SHA256withRSA ECDSA <=384 SHA256withECDSA

• jarsigner • Digest Algorithm (if -digestalg option not specified): SHA-256 • Timestamp Token Algorithm (if -tsadigestalg option not specified): SHA-256 • Signature Algorithm (if -sigalg option not specified): same as keytool

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 51 Conclusion • Security is important • We continue to make Java more secure and incorporate new security features • You can help us • Let us know what you think is important • Participate: http://openjdk.java.net/groups/security/ • Discuss: [email protected] • Contribute: http://openjdk.java.net/contribute • Come to our BOF tomorrow • OpenJDK Security Group: Discussion and Q&A [BOF2637] • Tuesday, Sep 20, 7:00 p.m. - 7:45 p.m., Hilton - Continental Ballroom 4