X
FEATURED POST

SecurityManager Survey Results

On February 5, 2018 we launched a survey to gather data on how applications and libraries use the SecurityManager. The results of the survey can now be seen...

Recent Posts

Java

Java applications that are signed and timestamped with the GeoTrust Timestamp Authority are no longer working

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...

Java

How to use the XML Signature secure validation mode

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...

Java

How to determine if a signed JAR is timestamped

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...

Java

JEP 124: Enhance the Certificate Revocation-Checking API

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...

Java

JEP 131: PKCS#11 Crypto Provider for 64-bit Windows

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...

Java

JEP 130: SHA-224 Message Digests

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...

Sun

Using stronger XML Signature Algorithms in JDK 7

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...

Sun

New API to indicate the reason a certificate chain was invalid

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....

Oracle

Integrated Cloud Applications & Platform Services