Using Digital Signatures to Secure E-Commerce

Digital signatures are emerging as a key enabler not only of e-commerce, but also of electronic contracting and legal activity. This how-to guide will start you rolling them out in your own company.

Digital signatures—which have been de rigueur for years among both professional and amateur security advocates—have emerged from those relatively small populations to become an important part of mainstream security discussions.

The driving force was the Electronic Signatures in Global and National Commerce Act (the so-called "E-Sign" bill) that, beginning in October of 2000, allowed an electronic signature to be accepted as binding in a commercial transaction.

E-Sign allows the parties in an agreement to accept an E-Signature; but, contrary to popular belief, it does not require that digital signatures be accepted.

Well defer a real discussion of this legislation; but check out this GigaLaw article for a legally focused explanation of the bills provisions.

Well also defer a spelunk into the nitty-gritty math of encryption and decryption, largely because RSA has a series of papers (PCKS 1-10) at its Web site that covers the math involved quite adequately. PCKS Nos. 1, 5, and 7 are a great a place to start.

Here well talk about the concepts delineated in those papers, as well as how to apply them in the non-mathematical world.


One simple word definition: a "digital signature" is extra data appended to a message which identifies and authenticates the identity of the sender and the message data using public-key encryption.

The sender uses a one-way hash function to generate a hash-code from the message data.

He/she then encrypts the hash-code with his/her private key. The receiver recomputes the hash-code from the data and decrypts the received hash with the senders public key.

If the two hash-codes are equal, the receiver is given an indication that the data has not been corrupted while in transit from one machine to another, and that it appears on first glance to have come from the given sender.

Now for Some Detail

Now, lets look at this definition with some intermediate steps left in, instead of glossing them over:

A message is a collection of some data into a unit. This "message" has a finite, but variable, length. What is called a message hash results from the reduction (by a mathematical operation) of this variable length message into a fixed length result. This result is called, understandably, the hash.

For most routine computational situations, the fixed length used for a hash is 128 bits; though some transaction systems will cut this down to 32 bits for speed. One property of a hash function is that it gives differing results for each different input. This means that hashes produce a unique resultant value given a unique message input.

The Secure Hash Algorithm (SHA-1, described in FIPS 181-1) is one commonly used algorithm for a one-way hash. In general, commercial products (like MD2 or MD5 from RSA Data Security Inc.) are used by most programmers to compute the hash on the fly (stream processing) inside a program.

MD5 is designed specifically to be fast when used in real-time operations, and has been widely accepted. Not having to reinvent the wheel and then optimize it as well is a strong attraction when a project needs to be finished on time.

Now, (and here comes the payoff) if one then encrypts the resulting hash of a message with ones private key , you get the digital signature of a message. This signature is usually appended to the message itself.

The digital signature is the result of binding someones private key via encryption to a specific message digest hash, thereby binding the person (by extension) to that messages specific content.

In the RSA-style method, to verify that a person has signed message with their private key; one decrypts the encoded message digest (which has been bound to the message) using the public key of the assumed sender to get the message hash.

If that hash is the same as the one that the receiver then performs on the message that accompanied the encrypted digest, the receiver then makes the assumption that (1) the sender (or someone who has the senders private key) encrypted the digest with their private key and (2) the message did not change in transmission.

Next page: Some Caveats