java xml digital signatures

Article

Java XML Digital Signatures

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

Contents

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.

By the Java Web Services Team, July 2006

- 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

of 16Java XML Digital Signatures

3/13/2009http://java.sun.com/jsp_utils/PrintPage.jsp?url=http%3A%2F%2Fjava.sun.com%2Fdeveloper%2Ftechnic...

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 1: Public Key Cryptography



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.

The digital signature protocol helps to ensures the following:

Figure 2: Digital Signature Creation

Figure 3: Digital Signature Verification



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.

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.

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 4: Enveloped Signatures

Figure 5: Enveloping 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.

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.

Figure 6: Detached Signatures

Figure 7: XML Signature Generation



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.

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 8: XML Signature Validation



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,

Figure 9: Java XML Digital Signature Reference Implementation Architecture



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

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 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);



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.

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);

Click here for a larger sample.



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 10: Java Technology Applications and the Sun PKCS#11 Provider

Click here for a larger sample.



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.

Figure 11: Solaris OS Cryptographic Architecture



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.

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.

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 algorithm

See W3C site

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



Figure 13 shows the Sun Fire T2000 server with the UltraSPARC T1 Cryptographic provider and Xeon with the Solaris Cryptographic Framework.

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

Figure 12: JSR105 Sign Operation Performance: Sun Fire T2000 Server Versus

Intel Xeon

Figure 13: JSR 105 Sign Operation Performance NCP Versus SunRSASign

Provider on Sun Fire T2000 Server



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.

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:

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

name = Solaris

description = SunPKCS11 accessing Solaris Cryptographic Framework

library = /usr/lib/$ISA/libpkcs11.so

handleStartupErrors = ignoreAll



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.

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

}

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 »



java xml digital signatures

Documents