Java XML Digital Signatures

Java XML Digital Signatures Page 1 of 16
http://java.sun.com/developer/technicalArticles/xml/dig_signatures/ Mar 13, 2009
Article
Java XML Digital Signatures
By the Java Web Services Team, July 2006
Contents
- Overview
- Introduction to the Java XML Digital Signature APIs
- Accelerating Java XML Digital Signature Performance
- Conclusion
- Appendix A: Commands
- Appendix B: Configuration
- Acknowledgments
- For More Information
Extensible Markup Language (XML) technology is now an integral part of web-based business applications. These applications require a
fundamentally sound and secure infrastructure to meet the security requirements of confidentiality, endpoint authentication, message
integrity, and nonrepudiation. XML signature, XML encryption, XML Key Management Specification (XKMS), Security Assertion Markup
Language (SAML), and XML Access Control Markup Language (XACML) are the XML security standards that define XML vocabularies and
processing rules to meet these security requirements.
Overview
This article will provide the following:
An introduction to XML digital signatures and to the Java XML Digital Signatures APIs (JSR 105)
Information on how to accelerate Java XML digital signature performance using cryptographic hardware accelerators (pdf) with focus on
the UltraSPARC T1 processor cryptographic acceleration support
This section will provide a brief introduction to public key cryptography (PKC) and digital signatures.
Public Key Cryptography (PKC)
The purpose of a digital signature is to provide a means for an entity to bind its identity to a piece of information. Digital signatures use PKC,
which employs an algorithm using two different but mathematically related keys: one to create a digital signature and another to verify a
digital signature.
Unlike conventional symmetric-key cryptography, which uses the same secret key for encryption and decryption, PKC uses a key pair, a
private and a public key, for encryption and decryption operations (see Figure 1). The public key is freely available to anyone, but the private
key is protected and never shared. Each key pair shares a mathematical relationship that ties the two keys exclusively to one another, and
they are related to no other keys.
http://java.sun.com/jsp_utils/PrintPage.jsp?url=http%3A%2F%2Fjava.sun.com%2Fdeveloper%2Ftechnic... 3/13/2009
Figure 1: Public Key Cryptography
A cryptographic transformation encoded with one key can be reversed only with the other key. It is computationally not feasible to deduce the
private key from the public key nor to deduce the public key from the private key. This defining nature of PKC enables the following:
Confidentiality. A message encrypted with a public key can only be decrypted with the corresponding private key.
Endpoint authentication. The recipient can determine the sender's identity.
Message integrity. The recipient can easily identify whether anything has tampered with the message content during transit.
Nonrepudiation. The sender cannot deny sending the message or committed actions.
Digital Signature Protocol
PKC enables electronic messages with a mechanism analogous to signatures in the paper world, known as a digital signature. However, a
digital signature verifies the authenticity of electronic documents and provides stronger security than do signatures on paper documents.
As Figure 2 shows, in order to create a digital signature, the sender first generates a small unique thumbprint of the document, called a hash
or digest. Even a very minor change to the original document will cause the hash value to change. By comparing the hash that was received
with the hash calculated from the received document, the recipient can verify whether the document was altered.
Figure 2: Digital Signature Creation
The hash of the document signed or encrypted with the sender's private key acts as a digital signature for that document and can be
transmitted openly along with the document to the recipient. The recipient will be able to verify or decrypt the signature (see Figure 3) by
taking a hash of the message and verifying it with the signature that accompanied the message and the sender's public key.
Figure 3: Digital Signature Verification
The digital signature protocol helps to ensures the following:
The signature is authentic. When the receiver verifies the message with the sender's public key, the receiver knows that the sender
signed it.
The signature cannot be forged. Only the sender knows his or her private key.
The signature is not reusable. The signature is a function of the document and cannot be transferred to any other document.
The signed document is unalterable. If there is any alteration to the document, the signature verification will fail at the receiver's end
because the hash value will be recomputed and will differ from the original hash value.
The signature cannot be repudiated. The sender cannot deny previous committed actions, and the receiver does not need the
sender's help to verify the sender's signature.
XML Digital Signatures
XML digital signatures will enable a sender to cryptographically sign data, and the signatures can then be used as authentication credentials
or a way to check data integrity.
XML signatures can be applied to any XML resource, such as XML, an HTML page, binary-encoded data such as a gif file, and XML-
encoded data. The standout feature of the XML digital signature is its ability to sign only specific portions of the XML document.
This article will now discuss the three types of XML signatures:
Enveloped
Enveloping
Detached
Enveloped Signature
An enveloped signature is the signature applied over the XML content that contains the signature as an element. The Signature element is
excluded from the calculation of the signature value. The signed XML element in Figure 4 represents the signed XML resource fragment.
Click here to look at a sample SOAP message with an enveloped signature.
Figure 4: Enveloped Signatures
Enveloping Signature
An enveloping signature is the signature applied over the content found within an Object element of the signature itself. The object or its
content is identified through a Reference element by way of a Uniform Resource Identifier (URI) fragment identifier or transform. The
signed XML element in Figure 5 represents the signed XML resource fragment.
Figure 5: Enveloping Signatures
Detached Signature
A detached signature (see Figure 6) is the signature applied over the content external to the Signature element, and it can be identified by
way of a URI or a transform. The signed XML resource can be present within the same document as the Signature element, or it can be
external to the XML document. Click here to look at a sample SOAP message with a detached signature.
Figure 6: Detached Signatures
XML Signature Generation
In order to generate an XML signature, the digest of the canonicalized target elements identified by references is computed as shown in
Figure 7, Step 1.
Figure 7: XML Signature Generation
In simple terms, canonicalization is the generating of a physical representation of an XML document after performing a series of steps that
the W3C specifications "Canonical XML" and "Exclusive XML Canonicalization" recommend. This physical representation of the XML data is
used to determine whether two XML documents are identical. Even a slight variation in white spaces will result in a different hash for an XML
document.
The type of canonicalization performed on the target element or fragment is based on the transform algorithm defined under the respective
Reference elements. The target elements identified by references are converted to a node set, and this node set is given as input to the
canonicalizer.
The SignedInfo block in Figure 7 has the computed DigestValue from Step 1 of the same figure inserted under the respective
Reference elements. The canonicalized data of the SignedInfo element is digested, and the digest value is encrypted using the sender's
private key, as shown in Steps 2 and 3.
XML Signature Validation
The XML signature validation takes place in two steps. The first step is to verify the digest of each of the references. The second is to verify
the cryptographic signature over the SignedInfo element.
In Figure 8, Step 1, the data identified by the Reference elements is canonicalized and then digested. In Step 2, the digest value is
compared against the digest value present under the Reference element. This helps to ensure that the target elements were not tampered
with.
Figure 8: XML Signature Validation
In Steps 3 and 4, the digest value of the canonicalized SignedInfo is calculated. The resulting bytes are verified against the signature over
the SignedInfo element in Step 5, using the sender's public key. If both the signature over the SignedInfo element and each of the
Reference digest values verify correctly, then the XML signature is valid.
Introduction to the Java Digital XML Signature APIs
Sun Microsystems provides a standard set of Java technology APIs to sign and verify XML and binary documents. The Java Community
Process (JCP) program defined these APIs as JSR 105. Sun ships these APIs with the Java Web Services Developer Pack (JWSDP),
Project GlassFish, and the Java Platform, Standard Edition (Java SE), version 6.
The Java XML Digital Signature Reference Implementation from Sun is a pluggable framework built on the Java Cryptographic Architecture
(JCA), as Figure 9 shows. It provides support for various implementations of digital signature algorithms and transforms as specified by
W3C's XML-signature syntax and processing specification.
Figure 9: Java XML Digital Signature Reference Implementation

Architecture
The Java XML Digital Signature APIs define the following packages:
javax.xml.crypto
javax.xml.crypto.dsig
javax.xml.crypto.dsig.keyinfo
javax.xml.crypto.dsig.spec
javax.xml.crypto.dom
javax.xml.crypto.dsig.dom
The javax.xml.crypto package contains common classes that are used to perform XML cryptographic operations such as generating
and verifying XML signatures. Some of the important interfaces in this package are KeySelector, URIDereferencer, and Data.
The KeySelector interface allows users to locate and optionally validate keys using the information contained in a KeyInfo object. The
URIDereferencer interface allows you to create and specify your own URI-dereferencing implementations. You have the option of
providing your own implementation of KeySelector and URIDereferencer.
The Data interface represents various forms of data targeted for signing and is classified as NodeSetData and OctetStreamData.
NodeSetData is an abstract representation of DataType, representing the node set, and OctetStreamData represents binary data
targeted for signing.
The javax.xml.crypto.dsig package includes interfaces that represent the core elements defined in the W3C XML digital signature
specification. Some of the important interfaces in this package are XMLSignature, SignedInfo, CanonicalizationMethod,
SignatureMethod, Reference, and DigestMethod. The XMLSignatureFactory class provided under the
javax.xml.crypto.dsig package can be used for creating and unmarshaling signature objects.
The XMLSignature class represents the Signature element defined by the W3C standard. The sign and validate methods on this
class can be used to protect and validate data, respectively.
The SignedInfo class represents the SignedInfo element defined by the W3C standard. SignedInfo holds the
CanonicalizationMethod, SignatureMethod, and reference. CanonicalizationMethod is the canonicalization algorithm applied
on SignedInfo, and SignatureMethod represents the signature algorithm used to perform the sign and validate operations. The
SignedInfo class may have one or more references. Each reference identifies the target that is to be protected and also provides a list of
transform algorithms applied on the target before calculating the digest.
The javax.xml.crypto.dsig.keyinfo package contains interfaces that represent most of the KeyInfo structures defined in the W3C
XML digital signature. Users can use the KeyInfoFactory class provided under javax.xml.crypto.dsig.keyinfo to create objects
of the KeyInfo class.
The javax.xml.crypto.dsig.spec package contains interfaces and classes representing input parameters for the digest, signature,
transform, or canonicalization algorithms used in the processing of XML signatures.
The packages javax.xml.crypto.dom and javax.xml.crypto.dsig.dom contain classes specific to the Document Object Model
(DOM) for the javax.xml.crypto and javax.xml.crypto.dsig packages, respectively. Only developers and users who are creating
or using a DOM-based XMLSignatureFactory or KeyInfoFactory implementation should need to make direct use of these packages.
The following section describes how to use these APIs to sign and verify XML documents.
Creation of a Detached Signature
Code Fragment 1 demonstrates how to created a detached signature.
Code Fragment 1
1 XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM");

2 DigestMethod digestMethod = fac.newDigestMethod
("http://www.w3.org/2000/09/xmldsig#sha1", null);
3 Reference ref = fac.newReference("#10",digestMethod);
4 ArrayList refList = new ArrayList();
5 refList.add(ref);
6 CanonicalizationMethod cm = fac.newCanonicalizationMethod(
"http://www.w3.org/2001/10/xml-exc-c14n#",null);
7 SignatureMethod sm = fac.newSignatureMethod(
"http://www.w3.org/2000/09/xmldsig#rsa-sha1",null);
8 SignedInfo signedInfo =fac.newSignedInfo(cm,sm,refList);
9 DOMSignContext signContext = null;
10 signContext = new DOMSignContext(privKey,securityHeader);
11 signContext.setURIDereferencer(new URIResolverImpl());
12 KeyInfoFactory keyFactory = KeyInfoFactory.getInstance();
13 DOMStructure domKeyInfo = new DOMStructure(tokenReference);
14 KeyInfo keyInfo =
keyFactory.newKeyInfo(Collections.singletonList(domKeyInfo));
15 XMLSignature signature = fac.newXMLSignature(signedInfo,keyInfo)
16 signature.sign(signContext);
Line 1 shows how to create an instance of XMLSignatureFactory. Once an XMLSignatureFactory is created, you must create a
Reference object that defines the targets to be signed. To create a Reference object, as in Line 3, you must pass the URI and the digest
algorithm as the parameters. URI #10 in Code Fragment 1 represents an xpointer reference to an element in the same document
because the signature and digest algorithm supplied will be used to create the hash value from the data to be signed.
You can create the CanonicalizationMethod and SignatureMethod parameters by using the appropriate methods provided by the
XMLSignatureFactory, as in Lines 6 and 7.
The next step is to create a SignedInfo object as in Line 8. To do this, you must pass the canonicalization algorithm, signature algorithm,
and a list of references as the parameters. The canonicalization algorithm is used for canonicalizing the SignedInfo element. If you need
to canonicalize the XML data that is to be signed, then the canonicalization algorithm should be passed as a transform to the reference while
creating the transform. If you do not specify a canonicalization algorithm in the Reference object, then Inclusive C14n is used.
The next step is to create a DOMSignContext, as in Line 10. DOMSignContext accepts a private key and parent node where the signature
object should be inserted. The private key is used to perform the sign operation, and the securityHeader parameter in Line 10 is the
DOM representation of the security header element, as shown in Line 9. A KeySelector can also be supplied instead of a private key. The
application can also set its own implementation of URIDereferencer to enable the resolution of URI references, but a default
implementation of URIDereferencer will be used if you do not provide one.
The Signature elements that W3C has combined contain an optional KeyInfo element that, if present, will be used to obtain the key to
validate the signature. The domKeyInfo in Line 14 represents a DOM representation of the SecurityTokenReference element as
shown in the example. The SignedInfo and KeyInfo objects are used to create the XMLSignature object in Line 15. Line 16 shows the
sign operation being performed using the DOMSignContext object.
Creating the Enveloped Signature
Creating the enveloped signature is similar to creating the detached signature, with the additional step of specifying the transform algorithm
in Line 8. This is required to exclude the Signature element from the signature value calculation.
Code Fragment 2 shows how to create the enveloped signature.
Code Fragment 2
1 XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM");
2 DigestMethod digestMethod =
fac.newDigestMethod("http://www.w3.org/2000/09/xmldsig#sha1", null);
3 C14NMethodParameterSpec spec = null;
4 CanonicalizationMethod cm = fac.newCanonicalizationMethod(
"http://www.w3.org/2001/10/xml-exc-c14n#",spec);
5 SignatureMethod sm = fac.newSignatureMethod(
"http://www.w3.org/2000/09/xmldsig#rsa-sha1",null);
6 ArrayList transformList = new ArrayList();
7 TransformParameterSpec transformSpec = null;
8 Transform envTransform = fac.newTransform("http://www.w3.org/2001/10/xml-exc-
c14n#",transformSpec);
9 Transform exc14nTransform = fac.newTransform(
"http://www.w3.org/2000/09/xmldsig#enveloped-signature",transformSpec);
10 transformList.add(envTransform);
11 transformList.add(exc14nTransform);
12 Reference ref = fac.newReference("",digestMethod,transformList,null,null);
13 ArrayList refList = new ArrayList();
14 refList.add(ref);
15 SignedInfo signedInfo =fac.newSignedInfo(cm,sm,refList);
Validating an XML Signature
Code Fragment 3 demonstrates the XML signature validation.
Code Fragment 3
Click here for a larger sample.
To validate a signature element, you can start by creating a DOMValidateContext, as in Line 1. DOMValidateContext takes the DOM
representation of the signature and an implementation of KeySelector as the parameters. The KeySelector implementation is used to
retrieve the Key to use for validating the signature. In order to validate the signature, you must recreate the XMLSignature by unmarshaling
the DOMValidateContext, as in Line 3. The URIDereferencer attribute of the DOMValidateContext object in Line 4 will be used to
retrieve the targets that were signed by the signature. You can validate the signature by invoking the validate method on the
XMLSignature object.
Accelerating Java XML Digital Signature Performance
The Java XML Digital Signature API's sign and validate operations are computationally expensive: They can take up more than 30
percent of CPU time. PKCS#11, the Cryptographic Token Interface Standard, defines the native programming interfaces to the cryptographic
tokens such as hardware cryptographic accelerators and smart cards. PKCS#11 provides increased performance and scaling through
transparent access to hardware cryptographic acceleration without requiring modification of existing application code.
The Sun PKCS#11 Provider
Starting with the JDK for the Java 2 Platform, Standard Editon (J2SE) 5.0, Java technology applications can access the cryptographic tokens
using the Sun PKCS#11 cryptographic provider shipped with the JDK. The Sun PKCS#11 provider in Figure 10 is a generic provider that can
use any PKCS#11 token.
Figure 10: Java Technology Applications and the Sun PKCS#11 Provider
The Sun PKCS#11 provider does not implement cryptographic algorithms by itself. It is simply a bridge between the Java Cryptography
Architecture (JCA), Java Cryptography Extension (JCE) APIs, and the underlying PKCS#11 implementations. See the JCA API Specification
and Reference document for more information. The Sun PKCS#11 provider supports the following algorithms, among others: RSA, DSA,
Diffie-Hellman, AES, DES, 3DES, ARCFOUR, Blowfish, Keystore, MessageDigest, SecureRandom.
As Figure 10 indicates, the Java technology security framework helps to ensure that there is a transparent failover between the underlying
hardware and software cryptographic service providers.
The Sun PKCS#11 provider is configured by way of the sunpkcs11 configuration file. The following entry in the
<javahome>/jre/lib/security/java.security file contains the static provider installation information for the Sun PKCS#11
provider:
Click here for a larger sample.
The sunpkcs11 configuration file contains the property attributes for the Sun PKCS#11 provider to access the underlying PKCS#11
implementation.
The library property defines the pathname of the PKCS#11 implementation. For the Solaris Cryptographic Framework (SCF) library, it is
configured as library=/usr/lib/$ISA/libpkcs11.so. In order to use other hardware accelerator cards such as Chrysalis-IT, nCipher,
Rainbow, and so on, you must configure this property to point to the respective vendor's PKCS#11 implementation. By using the Sun
PKCS#11 configuration file, you can have the Sun PKCS#11 provider enable or disable mechanisms and attributes that the underlying
PKCS#11 implementation supports.
Cryptographic Acceleration on the UltraSPARC T1 Processor
The UltraSPARC T1 processor comes with eight on-chip modular arithmetic units (MAUs), one per core, which extend the processor's
capabilities to act as cryptographic accelerators. MAUs must go through the UltraSPARC T1 processor Niagara Cryptographic Provider
(NCP) within the Solaris Cryptographic Framework library. Chapter 8 and Chapter 13 of the Solaris Security for Developers Guide, as well as
the white paper "The Solaris Cryptographic Framework" (pdf), provide more information.
The Solaris Cryptographic Framework Library
As Figure 11 indicates, the Solaris Cryptographic Framework library is a PKCS#11-based architecture that enables applications or kernel
modules to use or provide cryptographic services. This library provides cryptographic services to users and applications through commands,
a user-level programming interface, a kernel- programming interface, and a user-level and kernel-level framework.
Figure 11: Solaris OS Cryptographic Architecture
The user-level framework is responsible for providing cryptographic services to consumer applications and the end-user commands. The
kernel-level framework provides cryptographic services to kernel modules and device drivers.
The programming interfaces are a front end to each of the frameworks. The system administrator can plug a library or kernel module that
provides cryptographic services into one of the frameworks, making the plug-in's cryptographic services available to applications or kernel
modules.
An application, library, or kernel module that obtains cryptographic services is called a consumer. An application that provides cryptographic
services to consumers through the framework is referred to as a provider and also as a plug-in. The software that implements a
cryptographic operation is called a mechanism.
A token is a collection of mechanisms that represents the device in abstract form. Tokens can represent hardware, as in an accelerator
board. Tokens that represent pure software are referred to as soft tokens. A token can be plugged into a slot, which is the connecting point
for applications that use cryptographic services.
In addition to specific slots for providers, the Solaris 10 Operating System implementation provides a special slot called the metaslot. The
metaslot serves as a single virtual slot with the combined capabilities of all the tokens and slots that have been installed in the framework.
The metaslot enables an application to connect transparently with any available cryptographic service through a single slot.
UltraSPARC T1 Processor Cryptographic Provider
The UltraSPARC T1 processor accelerates computationally expensive modular arithmetic operations found in PKC algorithms such as RSA
and DSA. In the context of the Solaris Cryptographic Framework library, the MAU is implemented as a service provider, and all eight MAU
units are made visible to the consumers as a single device, /dev/ncp0. This device implementation is highly available, and it continues to
process requests as long as at least one MAU is functional.
On an UltraSPARC T1 processor-based system, the shipping JVM,* J2SE 5.0, has been preconfigured to use the Sun PKCS#11 provider.
The Sun PKCS#11 provider configuration file at <java-home>/jre/lib/security/sunpkcs11-solaris.cfg contains the required
information for the provider to access the Solaris Cryptographic Framework library.
In order to enable the Java technology applications to benefit from the cryptographic acceleration hardware, the sunpkcs11-solaris.cfg
file disables the soft-token mechanisms CKM_MD5_RSA_PKCS and CKM_SHA1_RSA_PKCS by default.
When a Java technology application creates an XML signature with SHA1withRSA, it will use the soft-token mechanism
CKM_SHA1_RSA_PKCS, as advertised by the metaslot. Under normal circumstances, the metaslot will route CKM_SHA1_RSA_PKCS to the
Softtoken because NCP does not implement it. But because sunpkcs11-solaris.cfg file has disabled the CKM_SHA1_RSA_PKCS
mechanism in the Softtoken, the Java technology security framework will fall back to using the NCP mechanism CKM_RSA_PKCS, and the
SHA1 hashing will be done separately.
NCP supports the following mechanisms: CKM_DSA, CKM_RSA_X_509, and CKM_RSA_PKCS.
You can verify that the Java technology application is indeed accessing the UltraSPARC T1 processor cryptographic accelerator by using the
kstat command. Appendix A discusses this further. The kstat output will update the rsapublic and rsaprivate counters for every
RSA sign and RSA verify operation, respectively. Every such operation will be reflected with an increase in the kstat MAU counters.
Note: RSA sign uses two modular operations, and RSA verify uses only one.
Java XML Signature Performance on UltraSPARC T1 Processor Systems
Table 1 lists the detailed hardware and software configuration.
Table 1: Hardware and Software Configurations
Hardware Software Configuration

Sun Fire T2000 server UltraSPARC T1 processor 1200 Mhz, Solaris 10 OS 3/05 HW2 s10s_hw2wos_05 SPARC
Intel Xeon Two-way Intel Xeon 3591 Mhz, Solaris 10 OS 3/05 s10_74L2a X86
Web services software JWSDP 2.0, JDK 6-ea-b58
JVM tuning -server -Xms 3G -Xmx 3G
JSR 105 security provider org.jcp.xml.dsig.internal.dom.XMLDSigRI
Cryptographic provider(s) 1. SCF/NCP (NCP is applicable only for the SunFire T2000 server.)
2. SunRSASign Provider ( SUN's software provider for RSA signatures shipped with the JVM by default)
XML signature See W3C site
Signature algorithm See W3C site
JSR 105 canonicalization See W3C site
algorithm
JSR 105 digest algorithm See W3C site
Benchmark XMLTest is a micro benchmark designed to mimic the processing that takes place in an XML document's life
cycle. XMLTest simulates a multithreaded server program that processes multiple XML documents in parallel.
Document size 5.5K
Version 2.0 of the XMLTest micro benchmark has support for benchmarking the performance of Java XML digital signatures.
The benchmark simulates a multithreaded server program that signs and validates an XML document in parallel for the benchmark's defined
runtime. For every XML Sign and Validate operation, depending on whether the signature type is enveloped or detached, the relevant
Reference objects are created with the configured transforms, and the required SignedInfo, KeyInfo, and Context objects are
created. In this benchmark, the public and private key pairs are dynamically generated -- one per thread -- as part of the benchmark
initialization, and the pregenerated key store is not used.
The benchmark reports the throughput as XML sign operations per second / XML verify operations per second.
Figure 12: JSR105 Sign Operation Performance: Sun Fire T2000 Server Versus
Intel Xeon
Figure 13 shows the Sun Fire T2000 server with the UltraSPARC T1 Cryptographic provider and Xeon with the Solaris Cryptographic
Framework.
Figure 13: JSR 105 Sign Operation Performance NCP Versus SunRSASign
Provider on Sun Fire T2000 Server
The results in Figures 12 and 13 show the superior performance of the Sun Fire T2000 server system. The performance of XML signature
generation using the RSA algorithm on the Sun Fire T2000 server is four to five times that of Xeon. As the cryptographic key size increases,
you can see a leap in the difference in performance.
Conclusion
Because XML technology has become an integral part of web-based business applications, it is critical that applications meet the security
requirements of data integrity, nonrepudiation, and endpoint authentication. The Java XML digital signature implementation provides the
infrastructure to meet these security requirements.
The Java XML digital signature operations of Sign and Validate are computationally expensive, and more than 30 percent of the CPU
time can be spent in doing the actual cryptographic operations. You can use hardware cryptographic accelerators to meet the demanding
performance requirements of cryptographic operations.
The UltraSPARC T1 processor has a built-in cryptographic accelerator to accelerate the computationally expensive modular arithmetic
operations found in PKC algorithms such as RSA and DSA. With its per-core MAU and unique eight-core Chip Multithreading (CMT)
architecture, the UltraSPARC T1 processor will offer you the biggest bang for the buck.
Appendix A: Commands
1. The Cryptoadm Tool
You can use the Cryptoadm administration tool to list all providers, install or uninstall software providers, and enable or disable hardware
providers.
cryptoadm list -p
Displays the list of providers installed
cryptoadm list -m
Displays the mechanisms supported by the installed providers
cryptoadm uninstall provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
Uninstalls the soft-token implementation
cryptoadm install provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
Installs the soft-token implementation
cryptoadm disable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
mechanism=CKM_MD5_RSA_PKCS,CKM_SHA1_RSA_PKCS
Disables the CKM_MD5_RSA_PKCS and CKM_SHA1_RSA_PKCS mechanisms from the soft-token implementation
cryptoadm enable provider=/usr/lib/security/\$ISA/pkcs11_softtoken.so
mechanism=CKM_MD5_RSA_PKCS,CKM_SHA1_RSA_PKCS
Enables the CKM_MD5_RSA_PKCS and CKM_SHA1_RSA_PKCS mechanisms for the soft-token implementation
2. The Kstat Tool
The Kstat tool reports the kernel statistics on the system.
For example, kstat -n ncp0 will report the kernel statistics for the ncp module.
module: ncp instance: 0

name: ncp0 class: misc
crtime 148.210428677
dsasign 0
dsaverify 0
mau0qfull 0
mau0qupdate_failure 0
mau0submit 17517
mau1qfull 0
mau1submit 18780
mau2qfull 0
mau2submit 19832
mau3qfull 0
mau3submit 21442
mau4qfull 0
mau4submit 23154
mau5qfull 0
mau5submit 24614
mau6qfull 0
mau6submit 25630
mau7qfull 0
mau7submit 24309
rsaprivate 87542
rsapublic 158
snaptime 15875.703178835
status online
The bold sections indicate that the UltraSPARC T1 processor cryptographic accelerator is being used to accelerate the RSA Sign and
Verify operations.
Appendix B: Configuration of the sunpkcs11-solaris.cfg File
This is how to configure the sunpkcs11-solaris.cfg file:
name = Solaris
description = SunPKCS11 accessing Solaris Cryptographic Framework
library = /usr/lib/$ISA/libpkcs11.so
handleStartupErrors = ignoreAll
attributes = compatibility
disabledMechanisms = {
CKM_MD2
CKM_MD5
CKM_SHA_1
CKM_SHA256
CKM_SHA384
CKM_SHA512
CKM_DSA_KEY_PAIR_GEN
# KEY_AND_MAC_DERIVE disabled due to Solaris bug 6306708
CKM_SSL3_KEY_AND_MAC_DERIVE
CKM_TLS_KEY_AND_MAC_DERIVE
CKM_SHA1_RSA_PKCS
CKM_MD5_RSA_PKCS
CKM_DSA_SHA1
CKM_RSA_PKCS_KEY_PAIR_GEN
}
The bold section shows that the mechanisms CKM_SHA1_RSA_PKCS and CKM_MD5_RSA_PKCS have been disabled to enable the Java
technology applications to benefit from the UltraSPARC T1 processor's cryptographic hardware acceleration.
Acknowledgments
We would like to thank Pallab Bhattacharya, Chichang Lin, Sean Mullan, Debabrata Sarkar, Denis Sheahan, Andreas Sterbenz, Ning Sun,
Qiyan Sun, and Ravindra Talashikar for their technical feedback and overall support in the development of this article.
For More Information
JSR 105: Java XML Digital Signature APIs

Java Technology and Web Services home page
Java Cryptography Architecture API Specification and Reference
XML-Signature Syntax and Processing (W3C)
Java PKCS#11 Reference Guide
High-PerformanceCryptography (pdf)
Introduction to the Solaris Cryptographic Framework
Solaris Cryptographic Framework (Overview)
The Solaris Cryptographic Framework (pdf), by Paul Sangster, Valerie Bubb, and Kais Belgaied
Applied Cryptography, by Bruce Schneier
PKCS#11: Cryptographic Token Interface Standard
Canonical XML Version 1.0 (W3C)
Exclusive XML Canonicalization Version 1.0 (W3C)
XMLTest Project
About the Authors
Swaminathan Seetharaman, formerly a member of the Java Web Services team, is an engineering manager with Juniper Networks in India.
Venugopal Rao K is a senior staff member in the Java Web Services team at Sun Microsystems.
Sameer Tyagi is a senior staff engineer with the Java Web Services team at Sun Microsystems.
* The terms "Java Virtual Machine" and "JVM" mean a Virtual Machine for the Java platform.
Rate and Review

Tell us what you think of the content of this page.
Excellent Good Fair Poor

Comments:
If you would like a reply to your comment, please submit your email address:
Note: We may not respond to all submitted comments.
Submit »
copyright © Sun Microsystems, Inc

Java XML Digital Signatures

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Java XML Digital Signatures

Uploaded by

Copyright:

Available Formats

Java XML Digital Signatures Page 1 of 16

http://java.sun.com/developer/technicalArticles/xml/dig_signatures/ Mar 13, 2009

This article will provide the following:

Public Key Cryptography (PKC)

Figure 1: Public Key Cryptography

Digital Signature Protocol

Figure 2: Digital Signature Creation

Figure 3: Digital Signature Verification

The digital signature protocol helps to ensures the following:

XML Digital Signatures

Figure 4: Enveloped Signatures

Figure 5: Enveloping Signatures

Figure 6: Detached Signatures

XML Signature Generation

Figure 7: XML Signature Generation

Figure 8: XML Signature Validation

Introduction to the Java Digital XML Signature APIs

Figure 9: Java XML Digital Signature Reference Implementation

Creation of a Detached Signature

Code Fragment 1 demonstrates how to created a detached signature.

1 XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM");

Creating the Enveloped Signature

Code Fragment 2 shows how to create the enveloped signature.

Validating an XML Signature

Code Fragment 3 demonstrates the XML signature validation.

Click here for a larger sample.

Accelerating Java XML Digital Signature Performance

The Sun PKCS#11 Provider

Click here for a larger sample.

Cryptographic Acceleration on the UltraSPARC T1 Processor

The Solaris Cryptographic Framework Library

Figure 11: Solaris OS Cryptographic Architecture

NCP supports the following mechanisms: CKM_DSA, CKM_RSA_X_509, and CKM_RSA_PKCS.

Java XML Signature Performance on UltraSPARC T1 Processor Systems

Table 1 lists the detailed hardware and software configuration.

Table 1: Hardware and Software Configurations

Hardware Software Configuration

1. The Cryptoadm Tool

2. The Kstat Tool

The Kstat tool reports the kernel statistics on the system.

module: ncp instance: 0

Appendix B: Configuration of the sunpkcs11-solaris.cfg File

This is how to configure the sunpkcs11-solaris.cfg file:

For More Information

JSR 105: Java XML Digital Signature APIs

About the Authors

Rate and Review

Excellent Good Fair Poor

You might also like