Reference.getDigestInputStream
This method returns the Reference's pre-digested input stream. Because this data can be potentially large and expensive to keep in memory, you must first enable reference caching. The data returned is the input to the digest operation during a validation or signing operation. This method is very useful for debugging reference validation failures as well as showing the user exactly what was signed, which is very important. The usage of this API is similar to SignedInfo.getCanonicalizedData:
// enable reference caching in your validation context
valContext.setProperty
("javax.xml.crypto.dsig.cacheReference", Boolean.TRUE);
System.out.println("Pre-digested Input:");
InputStreamReader isr =
new InputStreamReader(ref.getDigestInputStream());
char[] cbuf = new char[1024];
while (isr.read(cbuf, 0, 1024) != -1) {
System.out.print(cbuf);
}
System.out.println();
Java Security at JavaOne 2007
Posted by mullan on May 04, 2007 at 01:15 PM | Permalink
| Comments (0)
Wow, JavaOne is here again, next week to be exact! I hope you are
going. We have a bunch of new security features in the JDK and
a number of things we are thinking about for the future.
Come to one of our sessions to learn or discuss more about Java
Security:
1. Ask the Experts about Java Security in the Java Pavilion (booth #1538)
Time: Tuesday, 12:30 - 1:30 PM
2. Session ID: TS-2594
Session Title: Secure Coding Guidelines, Continued: Preventing Attacks and Avoiding Antipatterns
Time: Wednesday, 9:35 AM - 10:35 AM
3. Session ID: BOF-2516
Session Title: Stump the (Security) Band
Time: Thursday, 8:55 PM - 9:45 PM
Apache Java XML Security 1.4 released!
Posted by mullan on January 29, 2007 at 12:24 PM | Permalink
| Comments (2)
Apache Java XML Security 1.4 has just been released. This is the first release that contains an implementation of JSR 105, the standard Java XML Digital Signature API. It also contains several performance and memory reduction improvements. See the website for more details and a download link.
Security Feature Planning for JDK 7
Posted by mullan on August 25, 2006 at 09:41 AM | Permalink
| Comments (0)
In a recent blog of my colleague Andreas Sterbenz, he asks the Java community for input on the security features for JDK 7. Specifically, he writes:
Let us know your suggestions for features in the security area including topics such as crypto, PKI, SSL, Kerberos, security manager + policy, authorization + JAAS, SASL, XML security, secure coding, performance, ease of use and administration, and everything else related to security. Or if you don't have a specific suggestion but find that there are some things that really annoy you or that you cannot do, we want to hear about that us well.
So I am posing the same question on my blog. Feel free to send your suggestions as comments on my or Andreas blog or directly to me at sean.mullan@sun.com, and together we'll collect all the feedback. As Andreas mentions, due to our limited resources, we will not be able to accomodate all requests. And of course, all Java SE platform features are subject to JCP approval.
Thanks for your feedback!
New java.sun.com article on XML Digital Signatures
Posted by mullan on July 14, 2006 at 12:02 PM | Permalink
| Comments (0)
There's a new java.sun.com article titled Java XML Digital Signatures. It includes an introduction to XML digital signatures and to the new Java XML Digital Signatures APIs (JSR 105). It also discusses how to accelerate Java XML digital signature performance using cryptographic hardware accelerators such as Sun's UltraSPARC T1 processor with cryptographic acceleration support. The article was written by Sun's Java Web Services Security and Performance Team.
Extending JSR 105 to support more URI reference types
Posted by mullan on June 28, 2006 at 10:24 AM | Permalink
| Comments (4)
In XML Signatures, Reference elements use URIs to describe the data that is to be digested and signed. Adding support for your own URI dereferencing implementation is pretty straightforward in JSR 105. First you need to create a concrete implementation of the javax.xml.crypto.URIDereferencer interface, ex:
public class MyURIDereferencer implements URIDereferencer {
...
There is only one method in URIDereferencer that you need to provide an implementation for: the dereference method:
Data dereference(URIReference uriReference,
XMLCryptoContext context)
throws URIReferenceException
This method takes a URIReference object describing the URI to be dereferenced and an XMLCryptoContext object that may contain additional information (such as the base URI) that is helpful in dereferencing the URI. The method returns a Data object containing the dereferenced data. The API defines two subclasses of Data: OctetStreamData for holding byte streams, and NodeSetData for holding node-sets.
Once you have implemented your URIDereferencer, it can be set as the default URIDereferencer by invoking the XMLCryptoContext.setURIDereferencer method (which takes a URIDereferencer argument), ex:
context.setURIDereferencer(new MyURIDereferencer());
Does this mean MyURIDereferencer is responsible for dereferencing all URI types? Yes. But what if I want to continue to use the built-in support and only add support for new types? Well you can do that too. In your URIDereferencer implementation, you should add some code to fallback to the built-in URIDereferencer for URI types that you do not support. You can do this by calling the XMLSignatureFactory.getURIDereferencer method which returns a reference to the XMLSignatureFactory's built-in implementation of URIDereferencer.
You can get the reference implementation of JSR 105 from the Java Web Service Developer's Pack v2.0, the beta 2 release or latest snapshot of JDK 6 (Mustang), or GlassFish.
More XML Signature debugging tips
Posted by mullan on February 14, 2006 at 08:24 AM | Permalink
| Comments (0)
In a previous blog entry, I discussed how to determine what caused an invalid XML Signature and provided some code snippets. But for some programmers, this information may not be enough, and you may want to know more details.
Well then, good news. The reference implementation of XML DSig has extensive logging support, that when enabled, will provide you with lots of additional information. The log messages use the JDK logging facility (java.util.logging) so if you are familiar with how to format and configure that, you should breeze through the rest of my blog.
I'll show you two different ways to enable this logging, first if you are running your application from the command-line, and second if you are running it inside a J2EE container, in this case - Sun's Java System Application Server.
If you are running your application from the java command line, you need to configure the logging facility so that the XML DSig logging messages are emitted. You can do this by editing the JRE's default logging.properties file directly, or by creating your own file and set it with the java.util.logging.config.file property, ex:
java -Djava.util.logging.config.file=logging.properties ...
where logging.properties contains:
handlers= java.util.logging.ConsoleHandler
.level= INFO
java.util.logging.ConsoleHandler.level = FINER
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
org.jcp.xml.dsig.internal.level = FINER
com.sun.org.apache.xml.internal.security.level = FINER
This will emit XML DSig log messages of level FINER and higher to the console. All other components will emit log messages of level INFO and higher.
With Sun's Application Server, enable logging using the Application Server admin console:
- In the tree component, select the Application Server node.
- Click the Logging tab.
- On the Logging Settings page, click the Log Levels tab.
- Add a new property named "org.jcp.xml.dsig.internal" with value "FINER"
- Add a new property named "com.sun.org.apache.xml.internal.security" with value "FINER"
- Click Save to save the changes
The log messages will be written to the application server log file.
I won't describe each and every log message in detail, but some of the most helpful are the following:
[java] FINER: Pre-digested input: ...
This message displays the content of the referenced data just before it was digested.
[java] FINE: Expected digest: ...
[java] FINE: Actual digest: ...
This message displays the expected and actual base64 encoded digest values of a Reference.
[java] FINE: Canonicalized SignedInfo: ...
This message displays the canonicalized SignedInfo element before it is signed.
You can get the reference implementation of JSR 105 from the Java Web Service Developer's Pack v2.0, an early access snapshot of JDK 6 (Mustang), or GlassFish.
My XML Signature is invalid, now what do I do?
Posted by mullan on January 27, 2006 at 11:33 AM | Permalink
| Comments (1)
When validating an XML Signature using the Java XML DSig API, it returns a simple boolean indicating if the signature is valid or not:
// Validate the XMLSignature
boolean coreValidity = xmlSignature.validate(valContext);
If it is valid, then great ... no worries. But what if it is invalid? How can you determine exactly what caused the failure? Perhaps you used the wrong key to validate the signature or perhaps the signed contents were modified. But maybe it is a much more subtle problem involving transformations or canonicalization of the data that is digested and signed.
The first thing you should do is determine if the validation failure was caused by an invalid reference or an invalid signature (or both). XML Signature core validation consists of 2 phases: reference validation and signature validation. Both phases must pass for the XML signature to be valid.
Reference validation is the verification of the message digest of each of the references in the XML Signature. Signature validation is the verification of the signature over the signed contents, or the SignedInfo element.
To check if it is a signature validation failure, call the validate method of the SignatureValue object:
if (coreValidity == false) {
System.err.println("Signature failed core validation");
boolean sv = xmlSignature.getSignatureValue().validate(valContext);
System.out.println("signature validation status: " + sv);
This returns a boolean indicating if the signature validation phase was valid or not.
To check if one or more of the references failed to validate, iterate over the Reference objects and call the validate method on each:
Iterator i = xmlSignature.getSignedInfo().getReferences().iterator();
for (int j=0; i.hasNext(); j++) {
boolean refValid = ((Reference) i.next()).validate(valContext);
System.out.println("ref["+j+"] validity status: " + refValid);
}
}
This code allows you to zero in on what part of the core validation caused the XML Signature to be invalid. But it still may not give you enough information. In subsequent blogs, I'll show you more debugging tips.
You can get the reference implementation of JSR 105 from the Java Web Service Developer's Pack v2.0, an early access snapshot of JDK 6 (Mustang), or GlassFish.
Apache Java XML-Security 1.3 released, what's next?
Posted by mullan on November 29, 2005 at 07:50 AM | Permalink
| Comments (0)
The Apache XML Security Team has announced the 1.3 release of the Java XML-Security library.
The main changes in this release are:
* Better performance & memory utilization.
* Bug fixes.
The detailed changelog can be found here: http://xml.apache.org/security/changes.html
So what's next? Well, plans are already underway to integrate JSR 105 with the next release. But we are also looking for your suggestions such as additional performance improvements, new transform/c14n algorithms, support for XKMS, etc.
Let me know what you think or subscribe to the Apache xml security alias and send in your input.
JSR 105 (XML Digital Signature API) Final Release
Posted by mullan on June 26, 2005 at 07:06 AM | Permalink
| Comments (0)
In case you missed it, the final release of JSR 105 (Java XML Digital Signature API) is now available! :
http://jcp.org/aboutJava/communityprocess/final/jsr105/index.html
Security sessions at JavaOne
Posted by mullan on June 24, 2005 at 06:05 AM | Permalink
| Comments (0)
This being my first blog entry, I'll quickly introduce myself. I'm an
engineer at Sun Microsystems working on Java (SE) Security, primarily
in the areas of XML Security, PKI and access control.
At next week's JavaOne, our team are presenting a talk and a BOF. Here
are the details:
TS-7247 New Security and Networking Features for Web Services, Smart Cards, and More
Security and networking technology has never been more important and continues to evolve at a rapid pace to make it faster, more scalable, and more secure. This talk provides an overview and code examples of the new security and networking features currently under development for the upcoming 6 release (code-named Mustang) of Java™ Platform, Standard Edition. A test drive demonstrates some of the new capabilities.
Tuesday, June 28
2:45 pm - 3:45 pm @ Moscone Center, Gateway 102/103
BOF-9966 J2SE™ Security: Features, Examples, and Q&A
Come meet the Java™ 2 Platform, Standard Edition (J2SE™ platform) security team, and learn about the security features in the latest release of the Java platform, code-named Mustang. Topics include performing authentication, access control, secure communication, and cryptography in Java technology. We discuss the security architecture, APIs, and supported standards (SSL/TLS, Kerberos, PKCS, and more). Time will be allotted for an informal Q&A.
Wednesday, June 29
8:30 pm - 9:20 pm @ Moscone Center, Gateway 102/103
Also, there is a Meet the Experts session on Monday night from
6:30 to 8PM at the JavaOne Pavilion Reception in Moscone Hall B/C
where you will be able to personally ask the security developers
those burning questions.
Hope to see you there!
java.net RSS Feeds
