Making the JDK More Secure Sean Mullan Oracle September 19, 2016 @seanjmullan Copyright © 2016, Oracle and/or its affiliates. All rights reserved. Safe Harbor Statement 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. Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 2 Agenda 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. 3 Java Security Overview 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 Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 5 Java Security Components Java Language and Runtime Security Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 6 Java Security Components 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. 7 Java Security Components 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. 8 Making the JDK More Secure 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. 11 Secure by Default Challenges • Compatibility • Interoperability • Usability • One size does not fit all • Severity of issue 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. 13 Crypto Roadmap Planned Changes Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 14 Crypto Roadmap: Example of How to Test Changes Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 15 Crypto Roadmap Released Changes 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 Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 17 MessageDigest Cryptography Data (SHA-256) Digest Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 18 Java Security Components 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 Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 24 DRBG Example // 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())); Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 25 Public Key Infrastructure Copyright © 2016, Oracle and/or its affiliates. All rights reserved. 26 Java Security Components 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