Java Security Topics

Issue On October 30, 2017, the certificate for the GeoTrust TSA (Time Stamp Authority) expired. If your application is using a signed JAR that is also timestamped with the GeoTrust TSA, then you may get errors when running the applet or application with Java WebStart or Plugin. How do I know if I may be affected? To check if your JAR is timestamped with the GeoTrust TSA, you can use the jarsigner utility (although you must use JDK 9, 8u121, 7u131, 6u141 or later). Run "jarsigner -verify -verbose <jarfile>" and look for the GeoTrust TSA in the output, ex: Timestamped by "CN=GeoTrust Timestamping Signer 1, O=GeoTrust Inc, C=US" on Tue Apr 29 22:14:23 UTC 2014     Timestamp digest algorithm: SHA-1      Timestamp signature algorithm: SHA1withRSA, 1024-bit key  You can also use the keytool utility (JDK 7 and later) to see if the JAR is timestamped and get more details on the certificate chain. Run "keytool -printcert -jarfile <jarfile>" and look for the GeoTrust TSA in the output, ex: Timestamp: Owner: CN=GeoTrust Timestamping Signer 1, O=GeoTrust Inc, C=US Issuer: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA Serial number: 5e8d2daca44665546bb587978191a8bf Valid from: Tue Oct 30 20:00:00 EDT 2007 until: Mon Oct 30 19:59:59 EDT 2017 Certificate fingerprints:      SHA1: 22:3C:DA:27:07:96:73:81:6B:60:8A:1B:8C:B0:AB:02:30:10:7F:CC      SHA256: D7:B8:44:BD:39:5A:17:36:02:39:51:C6:4D:6C:81:65:45:93:AD:29:1D:DC:E4:6C:8D:79:B6:65:DF:31:0C:F6 Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: RSA (1024) Version: 3   Solution The solution is to re-sign and timestamp your JAR with a different TSA. The GeoTrust TSA uses SHA-1 and has been decommissioned by Symantec, see this article for more information and alternate TSAs which you can use: https://knowledge.symantec.com/support/partner/index?page=content&id=NEWS10071&viewlocale=en_US

Issue On October 30, 2017, the certificate for the GeoTrust TSA (Time Stamp Authority) expired. If your application is using a signed JAR that is also timestamped with the GeoTrust TSA, then you may...

My slides for my JavaOne 2016 session on "Making the JDK More Secure" are here.

My slides for my JavaOne 2016 session on "Making the JDK More Secure" are here.

My slides for my JavaOne 2015 session on "Safer and Faster: New JDK Security Features and Performance Improvements"  are available here.Thanks to all that attended my session (either in person or via the live-stream)!

My slides for my JavaOne 2015 session on "Safer and Faster: New JDK Security Features and Performance Improvements"  are available here. Thanks to all that attended my session (either in person or...

Here are the slides for my JavaOne 2014 session on Understanding the New JDK 8 Security Features. Thanks to all who attended the session. I hope it was very useful.

Here are the slides for my JavaOne 2014 session on Understanding the New JDK 8 Security Features. Thanks to all who attended the session. I hope it was very useful.

A new version of the Java Secure Coding Guidelines is now available at http://www.oracle.com/technetwork/java/seccodeguide-139067.html This version has many updates, including: Additional information for some of the new Java SE 8 features Several new guidelines and examples A new appendix covering the Java Native Interface A new symbolic naming for sections Several formatting changes These guidelines contain coding patterns and best practices that are extremely useful for building robust and secure Java applications.

A new version of the Java Secure Coding Guidelines is now available at http://www.oracle.com/technetwork/java/seccodeguide-139067.html This version has many updates, including: Additional information...

In JDK 7u25, we introduced a new secure validation mode for XML Signatures. This mode is designed to protect you from XML Signatures that contain potentially hostile constructs that could cause denial-of-service or other types of security issues.  The good news is that if you run your application with a SecurityManager, the secure validation mode is enabled by default, and there is no further action required.Otherwise, a new property with the name org.jcp.xml.dsig.secureValidation has been defined to allow applications to enable the mode. The property can be set by an application by calling the setProperty method of the javax.xml.crypto.dsig.dom.DOMValidateContext class with the name of the property above and a Boolean value. For example: DOMValidateContext context = new DOMValidateContext(key, element); context.setProperty("org.jcp.xml.dsig.secureValidation", Boolean.TRUE); The property should be set before you validate an XML Signature. When set to true, this property instructs the implementation to process XML signatures more securely. This will set limits on various XML signature constructs to avoid conditions such as denial-of-service attacks. Specifically, it enforces the following restrictions: Forbids use of the XSLT Transform  Restricts the number of SignedInfo or Manifest References to 30 or less Restricts the number of Reference Transforms to 5 or less   Forbids the use of MD5 related signature or mac algorithms Ensures that Reference Ids are unique to help prevent signature wrapping attacks Forbids Reference URIs of type http or file Does not allow a RetrievalMethod to reference another RetrievalMethod The feature is based on a similar  validation mode that was included in version 1.5.0 of  Apache Santuario XML Security. The JDK implementation is based on Apache Santuario. This mode is also in the soon to be released JDK 8.

In JDK 7u25, we introduced a new secure validation mode for XML Signatures. This mode is designed to protect you from XML Signatures that contain potentially hostile constructs that could cause...

Applying a timestamp when you sign a JAR is strongly recommended, as it allows you to prove that you signed the JAR during the time interval that your code signing certificate was still valid. This allows your JAR to be validated after the certificate expires thereby prolonging the lifetime of your application. There's really no good reason you should not apply a timestamp, and we are encouraging all developers to do that as we introduce stricter applet/RIA restrictions in JDK 7u51. To sign a JAR with a timestamp, use the -tsa option of the jarsigner utility, as follows: jarsigner -tsa http://example.tsa.url jar alias where "http://example.tsa.url"  is an example of a URL of the Time Stamp Authority (TSA). Do an internet search for "timestamp server URL" to find TSA servers that you can use. You can use the jarsigner utility to determine if a signed JAR has been timestamped as follows: jarsigner -verify -verbose -certs signed.jar where signed.jar is the name of your signed JAR. If it is timestamped, the output will include lines of the following indicating the time it was signed: [entry was signed on 8/2/13 3:48 PM] If the JAR is not timestamped, the output will not include those lines. Currently, the -certs option only prints the contents of the code signer's certificate chain, and not the Time Stamp Authority's (TSA) chain. However, there is an open RFE to add that functionality.

Applying a timestamp when you sign a JAR is strongly recommended, as it allows you to prove that you signed the JAR during the time interval that your code signing certificate was still valid. This...

Revocation checking is the mechanism to determine the revocation status of a certificate. If it is revoked, it is considered invalid and should not be used. Currently as of JDK 7, the PKIX implementation of java.security.cert.CertPathValidator  includes a revocation checking implementation that supports both OCSP and CRLs, the two main methods of checking revocation. However, there are very few options that allow you to configure the behavior. You can always implement your own revocation checker, but that's a lot of work. JEP 124 (Enhance the Certificate Revocation-Checking API) is one of the 11 new security features in JDK 8. This feature enhances the java.security.cert API to support various revocation settings such as best-effort checking, end-entity certificate checking, and mechanism-specific options and parameters. Let's describe each of these in more detail and show some examples. The features are provided through a new class named PKIXRevocationChecker. A PKIXRevocationChecker instance is returned by a PKIX CertPathValidator as follows: CertPathValidator cpv = CertPathValidator.getInstance("PKIX");PKIXRevocationChecker prc = (PKIXRevocationChecker)cpv.getRevocationChecker(); You can now set various revocation options by calling different methods of the returned PKIXRevocationChecker object. For example, the best-effort option (called soft-fail) allows the revocation check to succeed if the status cannot be obtained due to a network connection failure or an overloaded server. It is enabled as follows: prc.setOptions(Enum.setOf(Option.SOFT_FAIL)); When the SOFT_FAIL option is specified, you can still obtain any exceptions that may have been thrown due to network issues. This can be useful if you want to log this information or treat it as a warning. You can obtain these exceptions by calling the getSoftFailExceptions method: List<CertPathValidatorException> exceptions = prc.getSoftFailExceptions(); Another new option called ONLY_END_ENTITY allows you to only check the revocation status of the end-entity certificate. This can improve performance, but you should be careful using this option, as the revocation status of CA certificates will not be checked. To set more than one option, simply specify them together, for example: prc.setOptions(Enum.setOf(Option.SOFT_FAIL, Option.ONLY_END_ENTITY)); By default, PKIXRevocationChecker will try to check the revocation status of a certificate using OCSP first, and then CRLs as a fallback. However, you can switch the order using the PREFER_CRLS option, or disable the fallback altogether using the NO_FALLBACK option. For example, here is how you would only use CRLs to check the revocation status: prc.setOptions(Enum.setOf(Option.PREFER_CRLS, Option.NO_FALLBACK)); There are also a number of other useful methods which allow you to specify various options such as the OCSP responder URI, the trusted OCSP responder certificate, and OCSP request extensions. However, one of the most useful features is the ability to specify a cached OCSP response with the setOCSPResponse method. This can be quite useful if the OCSPResponse has already been obtained, for example in a protocol that uses OCSP stapling. After you have set all of your preferred options, you must add the PKIXRevocationChecker to your PKIXParameters object as one of your custom CertPathCheckers before you validate the certificate chain, as follows: PKIXParameters params = new PKIXParameters(keystore);params.addCertPathChecker(prc);CertPathValidatorResult result = cpv.validate(path, params); Early access binaries of JDK 8 can be downloaded from http://jdk8.java.net/download.html

Revocation checking is the mechanism to determine the revocation status of a certificate. If it is revoked, it is considered invalid and should not be used. Currently as of JDK 7, the...

Thanks to everyone who attended my talk yesterday on "Using the New JDK 8 Security Features". Here are the slides for my session for those that could not attend or would like a copy for further reference: CON_7932_Mullan.pdf.

Thanks to everyone who attended my talk yesterday on "Using the New JDK 8 Security Features". Here are the slides for my session for those that could not attend or would like a copy for...

JEP 131 (PKCS#11 Crypto Provider for 64-bit Windows) is another of the 11 new security features funded and targeted to JDK 8. PKCS #11 is a standard that defines a platform-independent API to cryptographic tokens like smart cards and hardware security modules. Oracle's JDK currently supports PKCS #11 on Solaris (SPARC and x86), Linux (32-bit and 64-bit), and Windows (32-bit). PKCS #11 support is provided via a JCA provider which is simply a bridge to the native PKCS #11 library. This allows developers to use the standard Java Cryptography APIs and take advantage of the PKCS #11 functionality without having to change their applications. Support for Solaris is configured out-of-the-box, but some additional configuration is required on the other platforms. JEP 131 adds PKCS #11 support for 64-bit Windows. To use the provider, additional  configuration is required that specifies the location of thenative PKCS #11 library along with additional directives as documented in the Java PKCS#11 Reference Guide. A PKCS #11 provider can be configured statically in the java.security file, ex:      security.provider.1=sun.security.pkcs11.SunPKCS11 pkcs11.cfg or dynamically in code, ex: Provider p = new sun.security.pkcs11.SunPKCS11(“pkcs11.cfg”);  Security.addProvider(p); Early access binaries of JDK 8 can be downloaded at http://jdk8.java.net/download.html

JEP 131 (PKCS#11 Crypto Provider for 64-bit Windows) is another of the 11 new security features funded and targeted to JDK 8. PKCS #11 is a standard that defines a platform-independent API...

JEP 130 (SHA-224 Message Digests) is one of the 11 new security features funded and targeted to JDK 8. The SHA-2 cryptographic hash family includes the SHA-224, SHA-256, SHA-384, and SHA-512 algorithms. The JDK already includes support for SHA-256, SHA-384, and SHA-512. JEP 130 completes the JDK support for the SHA-2 family. SHA-224 is basically a truncated version of SHA-256. The calculated hash is 224 bits (instead of 256) and is computed with a different initial value than SHA-256. It provides 112 bits of security (which is the same as two-key Triple DES). Use SHA-224 when your cryptographic application provides no more than 112 bits of security or you need the extra savings of the smaller hash size. Here are some code examples using SHA-224: // Create a SHA-224 java.security.MessageDigestMessageDigest md = MessageDigest.getInstance(“SHA-224”);// Create a SHA224withRSA java.security.SignatureSignature sig = Signature.getInstance(“SHA224withRSA”);// Create a SHA224withECDSA java.security.SignatureSignature esig = Signature.getInstance(“SHA224withECDSA”);// Create an HmacSHA224 javax.crypto.KeyGeneratorKeyGenerator kg = KeyGenerator.getInstance(“HmacSHA224”);// Create an HmacSHA224 javax.crypto.MacMac mac = Mac.getInstance(“HmacSHA224”);// Create an RSA/ECB/OAEPWithSHA-224ANDMGF1PADDING javax.crypto.CipherCipher c = Cipher.getInstance(“RSA/ECB/OAEPWithSHA-224ANDMGF1PADDING”); Early access binaries of JDK 8 can be downloaded at http://jdk8.java.net/download.html

JEP 130 (SHA-224 Message Digests) is one of the 11 new security features funded and targeted to JDK 8. The SHA-2 cryptographic hash family includes the SHA-224, SHA-256, SHA-384, and SHA-512...

Hi all, I will be presenting a session at this year's JavaOne 2013 (San Francisco) on "Using the New JDK 8 Security Features". This will be an informative session describing the 11 new security features (aka "JEPs") and will include plenty of code samples. Over the next few weeks, I will be posting new blog entries with more details of each of these features. So stay tuned for more information or attend my session if you are coming to JavaOne!

Hi all, I will be presenting a session at this year's JavaOne 2013 (San Francisco) on "Using the New JDK 8 Security Features". This will be an informative session describing the 11 new security...

The W3C XML Security Working Group has released a Last Call Working Draft for XML Signature 1.1:http://www.w3.org/TR/xmldsig-core1/An explanation of the changes against the XML Signature 1.0  specification is available:http://www.w3.org/TR/xmldsig-core1/explain.htmlChanges are focused on the set of mandatory to implement algorithms and markup for relevant key material.The Working Group has also released a Last Call Working Draft for XML Signature Properties:http://www.w3.org/TR/2010/WD-xmldsig-properties-20100204/The Last Call period lasts until 18 March 2010; comments can be sent to public-xmlsec-comments @ w3.org.  The next step in the W3C Recommendation Track process is either a Candidate Recommendation phase to collect implementation experience, or another Working Draft.The WG continues its work on XML Encryption 1.1 and is also working on a 2.0 version of Canonical XML and XML Signature.Details on all the publications of the Working Group are available on  the Working Group Publication Status page at http://www.w3.org/2008/xmlsec/wiki/PublicationStatus . 

The W3C XML Security Working Group has released a Last Call Working Draft for XML Signature 1.1:http://www.w3.org/TR/xmldsig-core1/An explanation of the changes against the XML Signature 1.0...

A new version (3.0) of the Secure Coding Guidelines for the Java Programming Language has just been published at http://java.sun.com/security/seccodeguide.html The secure coding guidelines documents best practices and patterns that you should adhere to when writing Java code in order to avoid vulnerabilities. These guidelines are important for every Java developer, whether you are writing a trusted library or an end-user application. Version 3.0 is a significant enhancement and includes a new section on fundamentals as well as many new guidelines and enhancements. Please send me any feedback you may have.

A new version (3.0) of the Secure Coding Guidelines for the Java Programming Language has just been published at http://java.sun.com/security/seccodeguide.html The secure coding guidelines documents...

This question has come up in user forums quite a bit: "how can I use a more recent Apache XML Security library with the XML Signature APIs (JSR 105) in JDK 6 and JDK 7?" Most of the time, you will not need to do this. Our JDK 6/7 XML Signature implementation is based on Apache XML Security and we try to keep up with the latest release. However, there may be a bug fix or new algorithm that you really need and are willing to depend on a more recent version of the Apache XML Security library that has that fix.  Here is what you need to do if so: Place the Apache xmlsec.jar in the endorsed standards directory.  You will also need to put the Apache commons logging jar there as well, since the Apache code uses a different logging mechanism than the JDK. And that's it. You can also use the java.endorsed.dirs  system property to point to different directory containing the jars above.

This question has come up in user forums quite a bit: "how can I use a more recent Apache XML Security library with the XML Signature APIs (JSR 105) in JDK 6 and JDK 7?" Most of the time, you will not...

One of the new features of the XML Signature 1.1 specification, which is currently in draft review, is the addition of stronger cryptographic algorithms to the REQUIRED algorithms, such as the RSAwithSHA256 SignatureMethod algorithm. Additional RECOMMENDED and OPTIONAL algorithms have also been added. See section 6.1 for a complete list of algorithm requirements. In JDK 7, you can already use many of these stronger XML Signature algorithms in your Java applications. The following algorithms are newly supported: the RSAwithSHA256, RSAwithSHA384, RSAwithSHA512 signature algorithms and the HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 mac algorithms. To take advantage of these stronger algorithms when generating XML Signatures, you may have to specify the URI of the algorithm (if there isn't a String constant already defined in the API). For example: XMLSignatureFactory factory = XMLSignatureFactory.getInstance(); SignatureMethod sm = factory.newSignatureMethod ("http://www.w3.org/2001/04/xmldsig-more#rsa-sha256", (SignatureMethodParameterSpec) null); No special code is required when validating XML Signatures with these algorithms as the implementation will automatically identify the algorithm URIs. We plan to add String constants for these URIs in a future revision of the JSR 105 API, but for now you must specify the URIs when generating signatures. Last, but not least, we are planning to backport support for these stronger signature and mac algorithms to JDK 6.

One of the new features of the XML Signature 1.1 specification, which is currently in draft review, is the addition of stronger cryptographic algorithms to the REQUIRED algorithms, such as the...

Just a reminder that we'll be holding a BOF at this year's JavaOne conference on "New Security Features in JDK™ Releases 6 and 7".  It is on Wednesday at 6:45 PM in Gateway 102/103 in the Moscone Center. We plan to have a short presentation on thelatest security features in JDK 6, JDK 7 and JavaFX. Then, we are going to show a demo of the new blacklist mechanism in the just-released JRE 6u14. The remaining time will be for Q&A so please bringyour questions on Java Security as many members of Sun's Java Security team will be on hand to help answer them. 

Just a reminder that we'll be holding a BOF at this year's JavaOne conference on "New Security Features in JDK™ Releases 6 and 7".  It is on Wednesday at 6:45 PM in Gateway 102/103 in the Moscone...

We'll be holding a BOF at this year's JavaOne conference on "New Security Features in JDK™ Releases 6 and 7". This is sure to be an interesting BOF, as we'll go over all of the latest security features that we have added to JDK 6 and new ones that are targeted for JDK 7. We also plan to show a demo of some of the features. There should be plenty of time for Q&A so please bring your questions on Java Security as many members of Sun's Java Security team will be on hand to help answer them.  I'll add more details as we get closer to JavaOne.

We'll be holding a BOF at this year's JavaOne conference on "New Security Features in JDK™ Releases 6 and 7". This is sure to be an interesting BOF, as we'll go over all of the latest security...

In JDK 7, we have added a new method (getReason) to the java.security.cert.CertPathValidatorException class which returns an object indicating the reason a certificate chain, or CertPath, is invalid. Previously, there was no standard mechanism to determine the reason of failure, and applications had to depend on the exception message or the cause which could vary based on the underlying service provider implementation. The getReason method returns an instance of CertPathValidatorException.Reason, which is an interface. There are 2 subclasses of this interface. One is BasicReason which is an enumeration of reasons which can apply to certificate chains of any type (X.509, PGP, etc). It contains reasons such as EXPIRED (certificate has expired) or INVALID_SIGNATURE. The other subclass is PKIXReason, and that enumerates the potential PKIX-specific reasons that an X.509 certification path may be invalid according to the PKIX (RFC 3280) standard, for example UNRECOGNIZED_CRIT_EXT . Here's an example of how you might use these new APIs in your application that validates certificate chains: CertPathValidator cpv = CertPathValidator.getInstance("PKIX");try {    CertPathValidatorResult cpvr = cpv.validate(path, params);} catch (CertPathValidatorException cpve) { CertPathValidator.Reason reason = cpve.getReason(); int index = cpve.getIndex(); System.err.println("Invalid certificate chain, certificate[" + index + "], reason: " + reason);⁞ }

In JDK 7, we have added a new method (getReason) to the java.security.cert.CertPathValidatorException class which returns an object indicating the reason a certificate chain, or CertPath, is invalid....

There is a new CertificateRevocationException class in JDK 7 in the java.security.cert package that indicates that an X.509 certificate is revoked and also allows you to determine additional information such as the reason the certificate has been revoked and when it was revoked.  The getRevocationReason method returns a CRLReason, which is a new enum class that enumerates the different reasons an X.509 certificate can be revoked, such as compromise of the private key. In JDK 7, The Sun PKIX CertPathValidator service provider implementation has been enhanced to throw this exception. Here's an example of how your application may use this new exception class: CertPathValidator cpv = CertPathValidator.getInstance("PKIX", "Sun");try {    CertPathValidatorResult cpvr = cpv.validate(path, params);} catch (CertPathValidatorException cpve) {    if (cpve.getCause() instanceof CertificateRevokedException) {        CertificateRevokedExcepion cre = (CertificateRevokedException) cpve.getCause(); System.err.println("Certificate  revoked on " + cre.getRevocationDate()); System.err.println("reason  for revocation: " + cre.getCRLReason()); }}

There is a new CertificateRevocationException class in JDK 7 in the java.security.cert package that indicates that an X.509 certificate is revoked and also allows you to determine additional...

Hello everyone. Although I have been with Sun for over 10 years, this is my first blog entry at blogs.sun.com. I already have a blog over at java.net (http://weblogs.java.net/blog/mullan/), but for now I will be posting new entries right here at blogs.sun.com. I may still update my blog at java.net from time to time, or figure out a way to cross-post my entries. A little about myself. I work on the Java Security Team and have spent almost 10 years working on the Java SE security technology. I was specification lead of JSR 55 and co-specification lead of JSR 105, both successful APIs that were integrated into Java SE. I'm also Sun's representative on the W3C XML Security Working Group and a committer on the Apache XML Security project. Lately, I have been investigating and working on security features related to JavaFX and web-deployed technologies.  Stay tuned for my next entry about the new CertificateRevokedException class in JDK 7.

Hello everyone. Although I have been with Sun for over 10 years, this is my first blog entry at blogs.sun.com. I already have a blog over at java.net (http://weblogs.java.net/blog/mullan/), but for...