Making the JDK More Secure

Sean Mullan OpenJDK Security Group Lead Oracle October 2, 2017 @seanjmullan

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 1 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.

1 Introduction and Goals

2 Secure by Default Improvements

3 JDK 9 Security Features

4 Conclusion

1 Introduction and Goals

2 Secure by Default Improvements

3 JDK 9 Security Features

4 Conclusion

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 4 Making the JDK More Secure Two Primary Goals • Provide a secure by default environment • Deliver new features that keep pace with the rapidly evolving security landscape

Tools keytool jarsigner policytool kinit, klist, ktab

JAAS GSSAPI/Kerberos XML Signature

APIs and SASL JSSE (SSL/TLS/DTLS) JAR Verification Libraries JCE (crypto) PKI (CertPath)

Java Language and Runtime Security

1 Introduction and Goals

2 Secure by Default Improvements

3 JDK 9 Security Features

4 Conclusion

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 7 Making the JDK Secure by Default Specific Goals • Restrict weak algorithms and protocols – Ex: JAR files signed with MD5 algorithms are now treated as unsigned JARs • Ensure defaults remain strong – Ex: Default settings for keytool/jarsigner changed from SHA-1 to SHA-2 • Add support for stronger algorithms and protocols – Ex: Backported support for TLS 1.2 to JDK 6

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 8 Cryptographic Roadmap http://java.com/cryptoroadmap • Initially published on August 18, 2016 • A "heads-up" on forthcoming changes • Provides guidance for determining if change may impact your applications • Shows all changes that have been released in the past 1-2 years • Important: may not apply to third party security providers

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 9 Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 10 Disable SHA-1 Certificates • SHA-1 TLS Server certificates that chain to Public Root CAs are now restricted by default – Restriction is in JDK 9, 8u141, 7u151, 6u161 – Applies to all certificates in chain and revocation information – Public Root CAs are those that are pre-installed in the cacerts keystore • Adheres to CA/Browser Forum Baseline Requirements: – "Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm." – https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.9.pdf • See JEP 288 for more information: http://openjdk.java.net/jeps/288

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 11 Have you ever written code like this? public class AES256 { public static void main(String[] args) throws Exception { KeyGenerator kg = KeyGenerator.getInstance("AES"); kg.init(256); SecretKey key = kg.generateKey(); Cipher c = Cipher.getInstance("AES/GCM/NoPadding"); c.init(Cipher.ENCRYPT_MODE, key); byte[] bytes = c.doFinal("Hello World!".getBytes()); } } $ java AES256 Exception in thread "main" java.security.InvalidKeyException: Illegal key size or default parameters … � $ java AES256 �

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 12 Enable Unlimited Cryptographic Policy By Default • You will no longer have to download the unlimited policy bundle! • JDK 9 includes both the limited and unlimited policy files – Use crypto.policy Security Property to configure • Default value is "unlimited" • No limits on strength of cryptography – Most significantly, allows AES-192 and AES-256 to be used out-of-box • Change will be backported in two phases – 8u151, 7u161, 6u171 (10/2017): Both policy files installed, but limited is default – 8u161, 7u171, 6u181 (01/2018): default changed to unlimited • NOTE: You are advised to consult your export/import control counsel or attorney to determine the exact requirements

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 13 Configuring the Restrictions • Restrictions are configured via Security Properties in the java.security file – jdk.certpath.disabledAlgorithms • Restrictions on certificates, CRLs, and OCSP Responses – jdk.tls.disabledAlgorithms • Restrictions on algorithms used in the TLS handshake protocol – jdk.tls.legacyAlgorithms • Algorithms are negotiated in TLS handshake protocol only if no stronger candidates are available – jdk.jar.disabledAlgorithms • Signed JAR is treated as unsigned if it is digested/signed with any of the restricted algorithms – jdk.xml.dsig.secureValidationPolicy • Restrictions on XML digital signatures

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 14 Default Restrictions jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \ RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, \ EC keySize < 224 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, 3DES_EDE_CBC jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024 jdk.xml.dsig.secureValidationPolicy=\ disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5, …

Use –Djava.security.debug=certpath to debug further CertPath Issuer = CA2 Subject = Alice SigAlg = MD5withRSA validate() CertPathValidator CertPathValidatorException ("Algorithm constraints check PKIX failed on signature algorithm: Issuer = CA1 MD5withRSA") Subject = CA2 SigAlg = SHA256withRSA jdk.certpath.disabledAlgorithms="MD2, MD5, …"

java.security

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 16 Use keytool to diagnose weak certificates $ keytool -printcert -file weak.crt Owner: CN=Alice, OU=Class-1, O=Example, C=US Issuer: OU=Class-1, O=Example, C=US Serial number: 2 Valid from: Sun Jun 28 09:32:30 EDT 2009 until: Thu Mar 15 09:32:30 EDT 2029 Certificate fingerprints: SHA1: 49:0D: ... SHA256: B0:51: ... Signature algorithm name: MD5withRSA (weak) Subject Public Key Algorithm: 1024-bit RSA key Version: 3

…

Warning: The certificate uses the MD5withRSA signature algorithm which is considered a security risk.

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 17 Use jarsigner to diagnose weak JARs $ jarsigner -verify -verbose test.jar 134 Thu Dec 10 16:20:40 EST 2015 META-INF/MANIFEST.MF 245 Thu Dec 10 16:20:40 EST 2015 META-INF/MD5RSA10.SF 1005 Thu Dec 10 16:20:40 EST 2015 META-INF/MD5RSA10.RSA 0 Mon Dec 07 18:00:20 EST 2015 META-INF/ m 2137 Mon Dec 07 17:40:02 EST 2015 JarVerifyLimits.class s = signature was verified m = entry is listed in manifest k = at least one certificate was found in keystore - Signed by "CN=MD5-RSA-1024 Cert, OU=Java, O=Java, L=SCA, ST=CA, C=US" Digest algorithm: MD5 (weak) Signature algorithm: MD5withRSA (weak), 1024-bit key WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property: jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024

1 Introduction and Goals

2 Secure by Default Improvements

3 JDK 9 Security Features

4 Conclusion

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 19 JDK 9 Security Features Highlights • 9 new security JEPs • Significant cryptographic performance improvements • Support for important TLS extensions: ALPN, OCSP Stapling • Support for new crypto algorithms: SHA-3, DRBG • Support for new protocols: DTLS • New restrictions on SHA-1 certificates • More secure defaults: JKS -> PKCS12

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 20 "9 for 9": 9 New Security JEPs in JDK 9 • JCE (Crypto) • JSSE (TLS/SSL/DTLS) – 287: SHA-3 Hash Algorithms – 249: OCSP Stapling for TLS – 229: Create PKCS12 KeyStores by Default – 244: TLS Application-Layer Protocol – 246: Leverage CPU Instructions for GHASH Negotiation Extension and RSA – 219: Datagram Transport Layer Security – 273: DRBG-Based SecureRandom (DTLS) Implementations • Runtime Security • PKI (CertPath) – 232: Improve Secure Application – 288: Disable SHA-1 Certificates Performance

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 21 SHA-3 Hash Algorithms Overview and Motivation • SHA-3 is a new family of cryptographic hash functions – Based on Keccak algorithm, winner of SHA-3 Hash Competition • Standard defined in NIST FIPS 202 – Four variants: SHA3-224, SHA3-256, SHA3-384, and SHA3-512 – SHA-2 is still perfectly fine to use – Should be viewed as an insurance policy in case SHA-2 is broken • JDK 9 adds MessageDigest implementations for all four SHA-3 hash functions • More information at http://openjdk.java.net/jeps/287

• The default value of the keystore.type Security Property has changed from "JKS" to "PKCS12" • Why? PKCS12 is stronger than JKS, standards-based, and has a richer set of features • keytool now creates PKCS12 keystores by default • A JKS KeyStore can load a PKCS12 KeyStore, and vice-versa – Supported in JDK 8 and 9 – Ensures that existing code hardcoding "JKS" won’t break • More information at http://openjdk.java.net/jeps/229

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 23 Leverage CPU Instructions for GHASH and RSA Overview and Motivation • Uses HotSpot Intrinsics • GHASH is a component of the AES/GCM cipher – Improves performance of AES/GCM by 34x to 150x (depending on data size) – Supported on Intel x64 and SPARC architectures • RSA – Improves performance by 10% on Intel x64 • More information at http://openjdk.java.net/jeps/246

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 24 DRBG-Based SecureRandom Implementations Overview and Motivation • DRBG = Deterministic Random Bit Generator (also known as a PRNG) – Uses a deterministic algorithm to produce a pseudo-random sequence from a random seed • DRBG is stronger than the Java SHA1PRNG algorithm and based on a standard (NIST SP 800-90Ar1)

• A new SecureRandom algorithm named "DRBG" • Implementation of all 3 mechanisms – Hash_DRBG, HMAC_DRBG, CTR_DRBG • Several new APIs for configuring DRBG mechanisms with different security strengths and options • Use the securerandom.drbg.config Security Property to configure which mechanism you want to use (default is Hash_DRBG) • Seed source is specified by securerandom.source Security Property • More information at http://openjdk.java.net/jeps/273

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 26 OCSP Stapling for TLS Overview and Motivation • OCSP is a mechanism to check the revocation status of certificates • Client-side OCSP checking incurs significant performance overhead – Soft-fail policy is problematic • 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 – Functionality: allows captive portals to check revocation status – Privacy: avoids client-side privacy leaks

• The SunJSSE implementation supports the TLS Certificate Status Request Extensions (RFCs 6066 and 6961) • On by default in the client • Off by default in the server – May be enabled using the jdk.tls.server.enableStatusRequestExtension system property – Several other system properties provide for finer-grained configuration • More information at http://openjdk.java.net/jeps/249

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 28 TLS Application-Layer Protocol Negotiation Extension Overview and Motivation • Provides a mechanism for negotiation of the application layer protocol before TLS handshake is complete – Client offers supported values, server chooses – Avoids additional network roundtrip to negotiate protocol – Specified in RFC 7301 • Primary Use Case: HTTP/2 (RFC 7540) • Several new APIs added to support this feature • More information at http://openjdk.java.net/jeps/244

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 29 Datagram Transport Layer Security (DTLS) Overview and Motivation • Extends the JSSE API and implementation to support DTLS 1.0 (RFC 4347) and 1.2 (RFC 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.: Session Initiation Protocol (SIP), electronic gaming protocols • Applications use the SSLEngine programming model • More information at http://openjdk.java.net/jeps/219

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 31 Security Components Have Been Modularized Scope Module Exported Packages Service Provider(s) SE java.base java.security.*, javax.crypto.*, javax.net.ssl.*, SUN, SunRsaSign, SunJSSE, javax.security.auth.* SunJCE, Apple SE java.security.jgss javax.security.auth.kerberos, org.ietf.jgss SunJGSS SE java.security.sasl javax.security.sasl SunSASL SE java.xml.crypto javax.xml.crypto.* XMLDSig Other java.smartcardio javax.smartcardio SunPCSC JDK jdk.crypto.cryptoki SunPKCS11 JDK jdk.crypto.ec SunEC JDK jdk.crypto.mscapi SunMSCAPI JDK jdk.crypto.ucrypto OracleUcrypto JDK jdk.jartool com.sun.jarsigner, jdk.security.jarsigner JDK jdk.security.auth com.sun.security.auth.* Various LoginModules JDK jdk.security.jgss com.sun.security.jgss JdkSASL

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 32 Other Module System Security Features • Some modules have been deprivileged – Loaded by the Platform Class Loader – Granted only required permissions, ex:

grant codeBase "jrt:/jdk.crypto.ec" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.*"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; permission java.security.SecurityPermission "clearProviderProperties.SunEC"; permission java.security.SecurityPermission "removeProviderProperty.SunEC"; }; • Strong Encapsulation – Encapsulate most JDK-internal APIs so that they are inaccessible at compile time – Relaxed at runtime by default, but can be controlled using --illegal-access option

1 Introduction

2 Cryptographic Roadmap

3 JDK 9 Security Features

4 Conclusion

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 34 Conclusion • 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 my BOF tomorrow – BOF5944: Securing Your Java Application: Is SecurityManager the Answer? – Tuesday, Oct 3, 7:45 p.m., Moscone West – Room 2016

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. 35 More Information • Revamped JDK 9 Security Guide: https://docs.oracle.com/javase/9/security/toc.htm • Stay Connected – Join us: DevOps Corner (Developer Lounge – Moscone West) – Learn more: openjdk.java.net | wercker.com/java – Follow: @OpenJDK, @wercker #JavaOne #DevOps