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.

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.

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.

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

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:

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.

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
        mau1qupdate_failure          0
        mau1submit                              18780
        mau2qfull                               0
        mau2qupdate_failure          0
        mau2submit                              19832
        mau3qfull                               0
        mau3qupdate_failure                     0 
        mau3submit                              21442
        mau4qfull                               0
        mau4qupdate_failure          0
        mau4submit                              23154
        mau5qfull                               0
        mau5qupdate_failure          0
        mau5submit                              24614
        mau6qfull                               0
        mau6qupdate_failure          0
        mau6submit                              25630
        mau7qfull                               0
        mau7qupdate_failure          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
• The Solaris Cryptographic Framework (pdf), by Paul Sangster, Valerie Bubb, and Kais Belgaied
• Applied Cryptography, by Bruce Schneier
• Canonical XML Version 1.0 (W3C)
• Exclusive XML Canonicalization Version 1.0 (W3C)

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.