This article explains how to get started with digital signatures, using X509 certificates in .NET.
The purpose of digital signatures is to identify data in a way that cannot easily be faked. Phishing, infected software and illegal contents published by unknown subjects can be prevented with digital signatures. Digital signatures will allow data and digital documents to be used as if they were signed paper. Browsers are now able to recognize X.509 certificates and know which Certificate Authorities are trusted. The X.509 system has grown to be the standard format for public key certificates, and is therefore the best way of proving that a document comes from the source it claims to come from.
This article will introduce X509 certificates, explain a little about the asymmetric cryptography that is at their heart, and end by describing how to use and manage these certificates within the .NET Framework classes.
Asymmetric Cryptography and Digital Signatures
Digital signatures are created using asymmetric cryptography, the approach on which digital signatures are based. Asymmetric Cryptography is distinguished by having two different keys, a private key to encrypt messages and a public key to decrypt them. The cryptographic private key K0 (a suitable array of bytes) is used with an appropriate algorithm to transform the initial human-readable message into a different message that is encrypted.
A second public cryptographic key K1, which is related to the private one, is used to change the encrypted message back to its original decrypted form via a second related algorithm.
With this mechanism, your recipient is sure that the message that she/he received is your message, because only you hold the private key that is related to the public, shared, key. You digitally ‘sign’ your message.
In practice, you will hash the message beforehand (with hash algorithm such as MD5 or SHA1), obtaining the hashed message M1. Then you will encrypt M1 with your private key K0, digitally signing your message, and, finally, you will send your message M, the encrypted hash M1 (the signature) and the public key K1 to your recipient. Your recipient will compute the hash of your message M and will compare it with the decrypted value of M1. If the two hashes matches, the signature is valid.
You will notice that the signature is obtained by encrypting the hash of a message, rather than the message itself. This is done for performance reasons. Asymmetric cryptography is a slow process and the time required to encrypt, or decrypt, a message is directly related to the message length. You can make better use of the processor by reducing the amount of data to be processed. Sometimes, a very large (in bytes) message, can be reduced, by hashing it, to a much smaller hashed message. It is more convenient to transmit a the bulk of the data as clear text and just attach less than a hundred encrypted bytes attached to it than to encrypt the entire message and send it in the encrypted form.
Asymmetric key encryption by itself is not enough because it is necessary to trust the public key received. An attacker can deceive you by signing a message with his private key and send you a digitally confirmed message with its (related) public key, whilst pretending he is someone else.
The public-key infrastructure (PKI) avoids this by utilizing a third-party entity, called Certification Authority that, under its responsibility, binds a public key to its owner. The binding occurs when the Certification Authority digitally sign a message that contains the public key and the identity of its owner. A digital certificate is obtained.
Read more
