After two programs have interchanged the keys, they can encrypt data sent to each other. However, a violator can substitute the real server with a false one and send its own key while interchanging keys. To make sure that the application sends data to the correct recipient only, digital signatures are used.
Digital signatures are used to verify the identity of the sender. As you already know, the recipient's public key is required to encrypt a message so that only the recipient can read it. Such messages can only be decrypted with a recipient's secret key. However, what if you encrypt a message with your secret key? Such messages can be read by people who have your public key and thus the message it not secure. Nobody but you (the owner of a secret key) can encrypt data so that other people can decrypt it with your public key. Thus, when you create/encrypt a message with your secret key, you verify your identity, so anyone who decrypts the message with your public key can be sure that you are the author of the message. Since asymmetric algorithms are
rather slow, there is no sense in encrypting the whole message; only the message size is encrypted. This procedure consists of two stages: first you calculate the message size and then encrypt it with your secret key. When the message is sent, the encrypted size is included. The recipient calculates the message size, decrypts the attached size using the same algorithm and
compares the results. If the sizes are equal, this means that this is the original message and it has not been modified during transfer.
Sounds good, but how can we be sure that a public key received actually does belong to a specified person? After all, someone could have substituted a false key for the original key.
To verify that a public key belongs to an individual, digital certificates are used. A certificate contains identity information (the name of a person, its personal ID data, and so forth) and cryptographic info (a public key and a Certificate Authority's (CA) digital signature). A Certificate Authority's (CA) digital signature verifies that a certificate belongs to the individual specified in it.
Thus, though the scheme has become more complicated, it has also become more secure. For example, if you'd like to obtain a digital certificate, depending on the certificate's security level, you will need to send a request to a Certificate Authority or go there in person, so that the CA could make sure that you are the one who has applied for the certificate. Thus, a CA binds together your identity info and your public key in a certificate and signs it using its secret key.
To make sure that a message was sent by you, a recipient does the following:
1. Obtain a CA's public key
2. Verify a certificate's signature using this key
If the signature does belong to a CA, then the certificate information is authentic. In case of problems, this CA is responsible for information specified in the certificate.
To prove that a signature does belong to a CA, the CA should have its own certificate that would verify its public key. In this case, a self-signed certificate is used. A self-signed certificate is an identity certificate signed by its own creator. That is, a CA that created the certificate also signed off on its legitimacy. You can create a self-signed certificate yourself too, but this does not mean that people will trust your certificate. For security reasons, it is not recommended that you trust self-signed certificates unless they belong to a root certification authority.
If you create a self-signed certificate for your company, you can use it to sign all your company employees' certificates (but only for your company employees). This allows you to not only create as many certificates as needed, thus, saving time and money, but also to increase your company security level. Certificates can also be used by applications. This can be extremely useful in cases where applications exchange data over open (insecure) channels.