This article is about secure cryptographic signatures. For simple signatures in digital form, see Electronic signature.

A digital signature or digital signature scheme is a mathematical scheme for demonstrating the authenticity of a digital message or document. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, and that it was not altered in transit. Digital signatures are commonly used for software distribution, financial transactions, and in other cases where it is important to detect forgery or tampering.

Contents
[hide]

1 Explanation 2 Definition 3 History 4 Notions of security 5 Uses of digital signatures o 5.1 Authentication o 5.2 Integrity o 5.3 Non-repudiation 6 Additional security precautions o 6.1 Putting the private key on a smart card o 6.2 Using smart card readers with a separate keyboard o 6.3 Other smart card designs o 6.4 Using digital signatures only with trusted applications o 6.5 WYSIWYS o 6.6 Digital signatures vs. ink on paper signatures 7 Some digital signature algorithms 8 The current state of use legal and practical 9 Industry standards o 9.1 Using separate key pairs for signing and encryption 10 See also 11 Notes 12 Further reading

[edit] Explanation
Digital signatures are often used to implement electronic signatures, a broader term that refers to any electronic data that carries the intent of a signature,[1] but not all electronic signatures use digital signatures.[2][3][4] In some countries, including the United States, India,[5] and members of the European Union, electronic signatures have legal significance. However, laws concerning electronic signatures do not always make clear

whether they are digital cryptographic signatures in the sense used here, leaving the legal definition, and so their importance, somewhat confused. Digital signatures employ a type of asymmetric cryptography. For messages sent through a nonsecure channel, a properly implemented digital signature gives the receiver reason to believe the message was sent by the claimed sender. Digital signatures are equivalent to traditional handwritten signatures in many respects; properly implemented digital signatures are more difficult to forge than the handwritten type. Digital signature schemes in the sense used here are cryptographically based, and must be implemented properly to be effective. Digital signatures can also provide non-repudiation, meaning that the signer cannot successfully claim they did not sign a message, while also claiming their private key remains secret; further, some non-repudiation schemes offer a time stamp for the digital signature, so that even if the private key is exposed, the signature is valid nonetheless. Digitally signed messages may be anything representable as a bitstring: examples include electronic mail, contracts, or a message sent via some other cryptographic protocol.

[edit] Definition

Diagram showing how a simple digital signature is applied and then verified Main article: Public-key cryptography A digital signature scheme typically consists of three algorithms: A key generation algorithm that selects a private key uniformly at random from a set of possible private keys. The algorithm outputs the private key and a corresponding public key. A signing algorithm that, given a message and a private key, produces a signature. A signature verifying algorithm that, given a message, public key and a signature, either accepts or rejects the message's claim to authenticity.

Two main properties are required. First, a signature generated from a fixed message and fixed private key should verify the authenticity of that message by using the corresponding public key. Secondly, it should be computationally infeasible to generate a valid signature for a party who does not possess the private key.

Uses of digital signatures

As organizations move away from paper documents with ink signatures or authenticity stamps, digital signatures can provide added assurances of the evidence to provenance, identity, and status of an electronic document as well as acknowledging informed consent and approval by a signatory. The United States Government Printing Office (GPO) publishes electronic versions of the budget, public and private laws, and congressional bills with digital signatures. Universities including Penn State, University of Chicago, and Stanford are publishing electronic student transcripts with digital signatures. Below are some common reasons for applying a digital signature to communications:

[edit] Authentication
Although messages may often include information about the entity sending a message, that information may not be accurate. Digital signatures can be used to authenticate the source of messages. When ownership of a digital signature secret key is bound to a specific user, a valid signature shows that the message was sent by that user. The importance of high confidence in sender authenticity is especially obvious in a financial context. For example, suppose a bank's branch office sends instructions to the central office requesting a change in the balance of an account. If the central office is not convinced that such a message is truly sent from an authorized source, acting on such a request could be a grave mistake.

[edit] Integrity
In many scenarios, the sender and receiver of a message may have a need for confidence that the message has not been altered during transmission. Although encryption hides the contents of a message, it may be possible to change an encrypted message without understanding it. (Some encryption algorithms, known as nonmalleable ones, prevent this, but others do not.) However, if a message is digitally signed, any change in the message after signature will invalidate the signature. Furthermore, there is no efficient way to modify a message and its signature to produce a new message with a valid signature, because this is still considered to be computationally infeasible by most cryptographic hash functions (see collision resistance).

[edit] Non-repudiation
Non-repudiation, or more specifically non-repudiation of origin, is an important aspect of digital signatures. By this property an entity that has signed some information cannot at a

later time deny having signed it. Similarly, access to the public key only does not enable a fraudulent party to fake a valid signature

Some digital signature algorithms

RSA-based signature schemes, such as RSA-PSS DSA and its elliptic curve variant ECDSA ElGamal signature scheme as the predecessor to DSA, and variants Schnorr signature and PointchevalStern signature algorithm Rabin signature algorithm Pairing-based schemes such as BLS Undeniable signatures Aggregate signature - a signature scheme that supports aggregation: Given n signatures on n messages from n users, it is possible to aggregate all these signatures into a single signature whose size is constant in the number of users. This single signature will convince the verifier that the n users did indeed sign the n original messages.

Message confidentiality, if it is negotiated, also implies message integrity. If message confidentiality is negotiated, a sealed (and implicitly signed) message is sent instead of a signed or unsigned message. The function that seals a message using the signing key, sealing key, and message sequence number is as follows:

-- Input: -SigningKey - The key used to sign the message. -Message - The message to be sealed, as provided to the application. -NegFlg, SeqNum - Defined in section 3.1.1. -Handle - The handle to a key state structure corresponding to the -current state of the SealingKey --- Output: -Sealed message The encrypted message -Signature The checksum of the Sealed message --Functions used: --RC4() - Defined in Section 6 and 3.1. MAC() - Defined in Section 3.4.4.1 and 3.4.4.2.

Define SEAL(Handle, SigningKey, SeqNum, Message) as Set Sealed message to RC4(Handle, Message) Set Signature to MAC(Handle, SigningKey, SeqNum, Message) EndDefine

Message confidentiality is available in connectionless mode only if the client configures extended session security.

The function to sign a message MUST be calculated as follows:

-- Input: -SigningKey - The key used to sign the message. -Message - The message being sent between the client and server. -SeqNum - Defined in section 3.1.1. -Handle - The handle to a key state structure corresponding to -the current state of the SealingKey --- Output: Signed message -Functions used: -ConcatenationOf() - Defined in Section 6. -MAC() - Defined in section 3.4.3. Define SIGN(Handle, SigningKey, SeqNum, Message) as ConcatenationOf(Message, MAC(Handle, SigningKey, SeqNum, Message)) EndDefine
The format of the message integrity data that is appended to each message for signing and sealing purposes is defined by the NTLMSSP_MESSAGE_SIGNATURE structure (section 2.2.2.9). Note If the client is sending the message, the signing key is the one that the client calculated. If the server is sending the message, the signing key is the one that the server calculated. The same is true for the sealing key. The sequence number can be explicitly provided by the application protocol or by the NTLM security service provider. If the latter is chosen, the sequence number is initialized to zero and then incremented by one for each message sent. On receipt, the message authentication code (MAC) value is computed and compared with the received value. If they differ, the message MUST be discarded (section 3.4.4).

Configuring encryption to protect message confidentiality at the application level

You can configure the encryption information for the request consumer (server side) and response consumer (client side) bindings at the application level.

Before you begin

Configure the key information that is referenced in the encryption information panel. For more information, see Configuring the key information for the consumer binding on the application level.

About this task

This task provides the steps that are needed for configuring the encryption information for the request consumer (server side) and response consumer (client side) bindings at the application level. The encryption information on the consumer side is used for decrypting the encrypted message parts in the incoming SOAP message. Complete the following steps to configure the encryption information for the request consumer or response consumer section of the bindings file on the application level:

Procedure
1. Locate the Encryption information configuration panel in the administrative console.

a. b.
c.

Click Applications > Enterprise applications > application_name. Under Manage modules, click URI_name. Under Web Services Security Properties you can access the encryption information for the request consumer and response consumer bindings.

For the request consumer (receiver) binding, click Web services: Server security bindings. Under Request consumer (receiver) binding, click Edit custom. For the response consumer (receiver) binding, click Web services: Client security bindings. Under Response consumer (receiver) binding, click Edit custom.

d. e.

Under Required properties, click Encryption information. Click New to create an encryption information configuration, click Delete to delete an existing configuration, or click the name of an existing encryption information configuration to edit its settings. If you are creating a new configuration, enter a name in the Encryption information name field. For example, you might specify cons_encinfo.

2.

Select a data encryption algorithm from the Data encryption algorithm field. The data encryption algorithm is used for encrypting or decrypting parts of a SOAP message such as the SOAP body or the username token. WebSphere Application Server supports the following pre-configured algorithms: o o o http://www.w3.org/2001/04/xmlenc#tripledes-cbc http://www.w3.org/2001/04/xmlenc#aes128-cbc http://www.w3.org/2001/04/xmlenc#aes256-cbc To use this algorithm, you must download the unrestricted Java Cryptography Extension (JCE) policy file from the following Web site: http://www.ibm.com/developerworks/java/jdk/security/index.html. o http://www.w3.org/2001/04/xmlenc#aes192-cbc

To use this algorithm, you must download the unrestricted Java Cryptography Extension (JCE) policy file from the following Web site: http://www.ibm.com/developerworks/java/jdk/security/index.html. Do not use the 192-bit key encryption algorithm if you want your configured application to be in compliance with the Basic Security Profile (BSP). Important: Your country of origin might have restrictions on the import, possession, use, or re-export to another country, of encryption software. Before downloading or using the unrestricted policy files, you must check the laws of your country, its regulations, and its policies concerning the import, possession, use, and re-export of encryption software, to determine if it is permitted. 3. The data encryption algorithm that you select for the consumer side must match the data encryption method that you select for the generator side.

2. Select a key encryption algorithm from the Key encryption algorithm field. The key
encryption algorithm is used for encrypting the key that is used for encrypting the message parts within the SOAP message. Select (none) if the data encryption key, which is the key that is used for encrypting the message parts, is not encrypted. WebSphere Application Server supports the following pre-configured algorithms:

o o o o

http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p. When running with Software Development Kit (SDK) Version 1.4, the list of supported key transport algorithms does not include this one. This algorithm appears in the list of supported key transport algorithms when running with SDK Version 1.5. Restriction: This algorithm is not supported when the WebSphere Application Server is running in Federal Information Processing Standard (FIPS) mode. http://www.w3.org/2001/04/xmlenc#rsa-1_5 http://www.w3.org/2001/04/xmlenc#kw-tripledes http://www.w3.org/2001/04/xmlenc#kw-aes128 http://www.w3.org/2001/04/xmlenc#kw-aes256 To use the http://www.w3.org/2001/04/xmlenc#aes256-cbc algorithm, you must download the unrestricted Java Cryptography Extension (JCE) policy file from the following Web site: http://www.ibm.com/developerworks/java/jdk/security/index.html.

http://www.w3.org/2001/04/xmlenc#kw-aes192 To use the http://www.w3.org/2001/04/xmlenc#kw-aes192 algorithm, you must download the unrestricted Java Cryptography Extension (JCE) policy file from the following Web site: http://www.ibm.com/developerworks/java/jdk/security/index.html. Do not use the 192-bit key encryption algorithm if you want your configured application to be in compliance with the Basic Security Profile (BSP).

3. The key encryption algorithm that you select for the consumer side must match the key
encryption method that you select for the generator side.

4. Optional: Select a part reference in the Part reference field. The part reference specifies the
name of the message part that is encrypted and is defined in the deployment descriptor. For example, you can encrypt the bodycontent message part in the deployment descriptor. The name of this Required Confidentiality part is conf_con. This message part is shown as an option in the Part reference field.

5. Under Additional properties, click Key information references. 6. Click New to create a key information configuration, click Delete to delete an existing
configuration, or click the name of an existing key information configuration to edit its settings. If you are creating a new configuration, enter a name in the Name field. For example, you might specify con_ekeyinfo. This entry is the name of the <encryptionKeyInfo> element in the binding file.

7. Select a key information reference from the Key information reference field. This reference
is the value of the keyinfoRef attribute of the <encryptionKeyInfo> element and it is the name of the <keyInfo> element that is referenced by this key information reference. Each key information reference entry generates an <encryptionKeyInfo> element under the <encryptionInfo> element in the binding configuration file. For example, if you enter con_ekeyinfo in the Name field and dec_keyinfo in the Key information reference field, the following <encryptionKeyInfo> element is generated in the binding file

Definition of: message integrity The validity of a transmitted message. It deals with methods that ensure that the contents of a message have not been tampered with and altered. The most common approach is to use a one-way hash function that combines all the bytes in the message with a secret key and produces a message digest that is impossible to reverse. Integrity checking is one component of an information security program. See one-way hash function, security protocol, Parkerian Hexad and data integrity.

When the message transferred from sender to receiver in not added, deleted or modifies by an external third parties, then that message represents the message integrity. Message confidentiality will be added when the message is not been viewed or noted by the unauthorized user. Message integrity and message confidentiality are related to each other. Without message confidentiality you cannot achieve message integrity and vice versa.

message integrity The validity of a transmitted message. It deals with methods that ensure that the contents of a message have not been tampered with and altered. The most common approach is to use a one-way hash function that combines all the bytes in the message with a secret key and produces a message digest that is impossible to reverse. Integrity checking is one component of an information security program.