| Provides signature services for cryptographic messages.
Cryptographic operations are frequently required to realize
authentication, authorization, integrity, and privacy services.
These services may be provided at various layers (for example,
communication layer, application layer, and so on). These services
form critical security components of larger systems
and services such as e-commerce, e-government, or corporate
applications. The layer at which these services are used are
governed by the security requirements of the system and the policies
used to formulate those requirements.
The services of authentication and authorization are often delivered
through the use of digital signatures. For a
digital signature to be useful, it must be possible to determine
what was signed, which algorithms were used, and who generated the
signature. Additional information may be included. The combination of
this information into a single construct is referred to as a formatted
digital signature.
A formatted digital signature is well suited to deliver the services
of authentication, authorization, and integrity of information at the
application layer within numerous systems. The generation of a formatted
digital signature involves the use of multiple cryptographic
operations including random number generation, hash generation, and the
application of a suitable signature algorithm. The cryptographic
operations are often performed on a security element that is trusted for
secure storage of cryptographic keys and secure computation of cryptographic
operations. The result of these cryptographic operations is combined with
information such as the user's identity and the data on which the
cryptographic operations are performed. This is then combined and presented
in a specific format that is expressed in ASN.1 or XML. The result is
referred to as a formatted digital signature. Examples of formatted digital
signatures include PKCS#7, CMS, and XML Digital Signature. This
class supports
signature messages that conform to the Cryptographic Message Syntax
(CMS) format as specified in
RFC 2630
with enhanced security services for
RFC 2634.
The complexity of generating a formatted digital signature is reduced
through the use of a high-level interface. The implementation
is responsible for identifying and managing the appropriate security
elements, requesting the required cryptographic operations from the system
and security element, as well as performing the appropriate formatting of the
results. The advantages of this interface is twofold. First, the
complexity of
generating a formatted digital signature is removed from the application
developer. Second, the size of the implementation can be
drastically reduced, removing
the need for separate packages to access and manage security elements,
perform specific cryptographic operations, and formatting the results
appropriately.
This class provides a compact and high-level cryptographic
interface that utilizes security elements available on a J2ME device.
In this version of the interface, signature generation is defined for
authentication and authorization purposes. The sign
and authenticate methods return CMS-formatted
signatures. The signed message can be constructed with content
included (opaque signature) or without the content (detached
signature).
For the purpose of this interface, a security element is a device
or part of a
device that is trusted to provide secure storage of user credentials
and certificates as well as cryptographic keys. In addition, such a
device is trusted to perform secure computation involving
the cryptographic keys that are securely stored on the device.
If a requested security element can not be found, a
UserCredentialManagerException is thrown and
the getReason method MUST return
UserCredentialManagerException.SE_NOT_FOUND.
A device may have multiple security elements. The security elements may be
removable. Public information such as the user credential and a reference to
the corresponding security element may be cached on the J2ME device.
Authorization of the use of a key in a security element will be governed by
the policy of the security element (for example, no authorization
required, PIN
entry required, biometric required, and so on).
Cryptographic keys may be marked for different purposes, such as
non-repudiation
or authentication. The implementation will honor the key
usage defined
by a security element.
This class honors the key usage policy defined by the security
element by splitting
the generation of formatted digital signatures between two methods,
namely the
sign and authenticate methods. The sign method is
associated with keys marked for digital signature and non-repudiation. The
authenticate method is associated with keys marked for digital
signature only,
or digital signature and a key usage apart from non-repudiation (such as
authentication).
These two methods, apart from being associated with a specific key
usage, also have
distinct behavior regarding user interaction. The
sign method will always display the text that is
about to be signed. The authenticate method
is overloaded and does not display the data that is about to be
signed, if that data is passed as a byte array. If the
data that is about to be signed is passed as a String,
it is always displayed.
The sign method should be used for higher-value transactions and
authorizations while the authenticate method should be used
whenever a digital signature is required to authenticate a user.
Example Code
This is an example of how this interface may be used to generate a
formatted digital
signature used for authentication or non-repudiation purposes.
String caName = new String("cn=ca_name,ou=ou_name,o=org_name,c=ie");
String[] caNames = new String[1];
String stringToSign = new String("JSR 177 Approved");
String userPrompt = new String("Please insert the security element "
+ "issued by bank ABC"
+ "for the application XYZ.");
byte[] byteArrayToSign = new byte[8];
byte[] authSignature;
byte[] signSignature;
caNames[0] = caName;
try {
// Generate a formatted authentication signature that includes the
// content that was signed in addition to the certificate.
// Selection of the key is implicit in selection of the certificate,
// which is selected through the caNames parameter.
// If the appropriate key is not found in any of the security
// elements present in the device, the implementation may guide
// the user to insert an alternative security element using
// the securityElementPrompt parameter.
authSignature = CMSMessageSignatureService.authenticate(
byteArrayToSign,
CMSMessageSignatureService.SIG_INCLUDE_CERTIFICATE
|CMSMessageSignatureService.SIG_INCLUDE_CONTENT,
caNames, userPrompt);
// Generate a formatted signature that includes the
// content that was signed in addition to the certificate.
// Selection of the key is implicit in selection of the certificate,
// which is selected through the caNames parameter.
// If the appropriate key is not found in any of the
// security elements present in the device, the implementation
// may guide the user to insert an alternative
// security element using the securityElementPrompt parameter.
signSignature = CMSMessageSignatureService.sign(
stringToSign,
CMSMessageSignatureService.SIG_INCLUDE_CERTIFICATE
|CMSMessageSignatureService.SIG_INCLUDE_CONTENT,
caNames, userPrompt);
} catch (IllegalArgumentException iae) {
// Perform error handling
iae.printStackTrace();
} catch (CMSMessageSignatureServiceException ce) {
if (ce.getReason() == ce.CRYPTO_FORMAT_ERROR) {
System.out.println("Error formatting signature.");
} else {
System.out.println(ce.getMessage());
}
}
...
Note regarding UI implementations
The user prompts and notifications should be implemented in such a way that:
-
the UI is distinguishable from a UI generated by external sources
(for example J2ME applications)
-
external sources are not able to modify the data presented to the user.
-
external sources are not able to retrieve the PIN data.
| 