Digital Signature

Abstract

The concept of securing messages through cryptography has a long history. Throughout history, however, there has been one central problem limiting widespread use of cryptography. That problem is key management, the term key management refers to the secure administration of keys to provide them to users where and when they are required. To better understand how cryptography is used to secure electronic communications through Digital Signature.Digital signature is generally taken to be a 'subset' of electronic signatures.. A digital signature is an electronic signature that can be used to authenticate the identity of the sender of a message or the signer of a document, and possibly to ensure that the original content of the message or document that has been sent is unchanged.
In this paper digital signature is used to mean a cryptographically based signature assurance scheme. A digital signature can be used with any kind of message, whether it is encrypted or not.Digital signatures, like physical signatures, can verify that a specific user affixed their signature to a document and they can also verify that the document is the same as when the user affixed the digital signature. Digital signature systems (DSS) use public key cryptography methods to create digital signatures. The integrity of the digital signature is tied to the security of the user's private key. As long as the user's private key is secure, then only the user can affix their digital signature to a document

Contents
Key terms
Overview of
-- Public Key Cryptography (PKC)
-- Digital Signature
Digital Signature Cryptography with No Real Math
Applications
Conclusion

Key Terms:
· Keys
· Key Ring
· Finger Print
· Key Certificate
Keys:
Private key - The private key is the portion of the key we use to actually sign a document. The private key is protected by a password.
Public key - The public key is the portion of the key that is available to other people who use to check your signature. A list of other people who have signed your key is also included with your public key. You will only be able to see their identify if you already have their public keys on your key ring.
Key Ring: A key ring contains public keys. You have a key ring that contains the keys of people who have sent you their keys or whose keys you have gotten from a public key server.
Finger Print: When confirming a key, you will actually be confirming the unique series of letters and numbers that comprise the fingerprint of the key.

The fingerprint is a different series of letters and numbers.
Key Certificate :When you select a key on a key ring, you will usually see the key certificate, which contains information about the key, such as the key owner, the date the key was created, and the date the key will expire.
Overview:
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
Digital signatures are important because they provide end-to-end message integrity guarantees, and can also provide authentication information about the originator of a message. In order to be most effective, the signature must be part of the application data, so that it is generated at the time the message is created, and it can be verified at the time the message is ultimately consumed and processed.
As an analogy, consider a conventional letter. If I'm sending a check to my phone company, I sign the check—the message—and put it in an envelope to get privacy and delivery. Upon receipt of the mail, the phone company removes the envelope, throws it away, and then processes the check. I could make my message be part of the envelope, such as by gluing the payment to a postcard and mailing that, but that would be foolish.
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.

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.

Digital Signature Cryptography with No Real Math
Before we can really understand XML DSIG, we need to have an understanding of some basic cryptography.
A digital signature provides an integrity check on some content. If a single byte of the original content has been modified—an extra zero added to a price, a "2" changed to a "4", or a "No" to a "Yes"', and so on—then the signature will fail to verify. Here's how it works.
The first step is to ''hash'' the message. A cryptographic hash takes an arbitrary stream of bytes and converts it to a single fixed-size value known as a digest. A digest is a one-way process: it's ''computationally infeasible'' to recreate a message from the hash, or to find two different messages which produce the same digest value.
The most common hash mechanism is SHA1, the Secure Hash Algorithm. SHA1 takes any message up to 2**64 bytes in length and produces a 20-byte result.
So if I generate a message M, and create a digest, (written as H(M), for "the hash of M"), and you receive M and H(M), you can create your own digest H'(M), and if the two digest values match, we know that you got what I sent. To protect M against modification, I only need to protect H(M) from being modified. How do we do that? There are two common approaches. The first is to mix a shared secret into the digest. In other words, create H(S+M). When you get the message, you use your own copy of S to create H'(S+M). This new digest is called an HMAC, or Hashed Messsage Authentication Code.
When we use an HMAC, the strength of the integrity protection depends on the (in)ability of the attacker to figure out S. Therefore, S should be something not easily guessed, and something that should be changed often. One of the best ways to meet these requirements is to use Kerberos. In Kerberos, a central authority distributes "tickets" that contain a temporary session key whenever two entities want to communicate. This session key is used as the shared secret. When I want to send you a signature, I get a ticket to talk to you. I open my part of the ticket to get S, and I send you the message, its HMAC, and your part of the ticket. You open the ticket and get S and information about my identity. You can now take the message, M, generate your own H'(S+M), and see if they match. If they do match, you know that you received my message intact, and Kerberos told you who I am.
Another method to protect the digest is to use public-key cryptography, such as RSA. In public-key cryptography, there are two keys, a private key, known only to the holder, and a public key, accessible to anyone who wants to communicate with the key holder. In public-key cryptography, anything encrypted with the private key can be decrypted with the public key, and vice versa.
Let's look at a simple example that demonstrates how public-key cryptography works. In this example, we'll limit our messages to the letters a through z, and assign them the values one through 26. To encrypt, we'll add the value of the private key; in this case it's +4:Letter h e l l o
Numeric Value 8 5 12 12 15
Private Key 4 4 4 4 4
Encrypted Value 12 9 16 16 19
To decrypt, we add the public key, which will be +22; if the result is outside the number range, we add or subtract 26 until it's valid. E
Encrypted Value 12 9 16 16 19
Public Key 22 22 22 22 22
Raw decrypted value 34 31 38 38 41
Normalized value 8 5 12 12 15
Plaintext h e l l o
RSA works the same way, except that instead of addition we use exponentiation and the numbers are hundreds of digits long.
Using RSA, I generate a digest, H(M), and encrypt it with my private key, {H(M)}private-key, which is the signature. When you receive the message, M, you generate the digest, H'(M), and decrypt the signature using my public key, getting the H(M) that I generated. If H(M) and H'(M) are the same, then we know that M is the same. Further, you know that whoever has the private key—that is, me—is the sender of the message.





How It Works???
Assume you were going to send the draft of a contract to your lawyer in another town. You want to give your lawyer the assurance that it was unchanged from what you sent and that it is really from you.
1.You copy-and-paste the contract (it's a short one!) into an e-mail note.
2.Using special software, you obtain a message hash (mathematical summary) of the contract.
3.You then use a private key that you have previously obtained from a public-private key authority to encrypt the hash.
4.The encrypted hash becomes your digital signature of the message. (Note that it will be different each time you send a message.).
At the other end, your lawyer receives the message.
1.To make sure it's intact and from you, your lawyer makes a hash of the received message.
2.Your lawyer then uses your public key to decrypt the message hash or summary.
3.If the hashes match, the received message is valid

There are three common reasons for applying a digital signature to communications: -
Authentication:Public-key cryptosystems allow encryption of a message with a user's private key. The message itself need not be sent in cipher text. If a hash of the document is generated and then protected via encryption, the document cannot be altered in any way without changing the hash to match, which, if quality algorithms are properly used, will be quite difficult. By decrypting the hash using the sender's public key, and checking the result against a newly generated hash of the alleged plaintext, the recipient can confirm (with high confidence) that the encryption was done with the sender's private key (and so presumably by the user who should have been the only person able to use that key), and that the message hasn't been altered since it was signed. No recipient can ever be absolutely certain the purported sender is indeed the signer -- i.e., the person who used the private key -- since the cryptosystem might have been broken, the key copied, or the whole scheme evaded using social engineering.
The importance of high confidence in both the message integrity and sender authenticity is especially obvious in a financial context.
Integrity:Both parties will always wish to be confident that a message has not been altered during transmission. Encryption of the message makes it difficult for a third party to read it, but that third party may still be able to alter it, perhaps maliciously, without actually reading it. An example is the homomorphism attack: consider a bank which sends instructions from branch offices to the central office in the form (a, b) where a is the account number and b is the amount to be credited to the account. A devious customer may deposit £100, intercept the resulting transmission and then transmit (a, b3) to become an instant millionaire.
Non-repudiation:In a cryptographic context, the word repudiation refers to the act of disclaiming responsibility for a message (i.e., claiming it was sent by some third party, certainly not me; "I repudiate this message and its contents!"). A message's recipient may insist the sender attach a signature in order to make later repudiation more difficult, since the recipient can show the signed message to a third party (e.g., a court) to reinforce a claim as to its origin. However, loss of control over a user's private key will mean that all digital signatures using that key, and so 'from' that user, are suspect.

Digital Signature Applications for E-Government:
The increasing opportunities created by innovative systems and programming techniques have given rise to a new kind of application scenario, commonly referred to as electronic government. The digital signature is a technology that enables safe and legally binding transactions based on networked communication and the exchange of electronic documents. To explore possible application areas and the potential of this technology requires the modeling of processes, focusing, among other things, on administrative matters, their interlinking and interaction with other applications.
Application Development Trends In E-Business:
Applications of digital signature technology are on the rise because of legal and technological developments, along with strong market demand for secured transactions on the Internet. In order to predict the future demand for digital signature products and online security, it is important to understand the application development trends in digital signature technology. These developments promise to provide a robust security infrastructure for online businesses, which may promote e-business further in the future.

Conclusion:
Digital signatures are easily transportable, cannot be imitated by someone else, and can be automatically time-stamped. The ability to ensure that the original signed message arrived means that the sender cannot easily repudiate it later.

Reference:
· Digital Signature: Network Security Practices
by Kailash N. Gupta, Kamlesh N. Agarwala, Prateek A. Agarwala - 2005
· Handbook of Applied Cryptography - Page 426
by Alfred J. Menezes, Oorschot, Paul C. Van, Scott A. Vanstone - 1996
· R. Rivest, A. Shamir, L. Adleman. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM, Vol. 21 (2), pp.120–126. 1978.
· www.youdzone.com/signature.html