How Secure Channel Systems Work
Now that we have a good understanding of some basic cryptographic concepts, we will move on and see how they are actually put into practice. We learned earlier that SCS provides support for a number of security protocols. Each of these has their own specific low-level operation and complexities that we do not intend to cover. Instead we will investigate how all such protocols solve the general problem of connection, negotiation, and key exchange; and how this software technology protects us against the spies, vandals and charlatans out there in the big wide world beyond our Internet connection.
Client-server Authentication with SCS
We will first look at how a client called
C and a server called
S negotiate a secure communications link. The following table shows the messages that pass between
S has to prove that its certificate is valid by showing that it has the private key to encrypt a message digest:
Hello, I am
Hello, I am
|C can now verify the certificate using the CA's public key and extract the public key of S|
Here is a random bit of data plus a message digest of this data encrypted with
|C can verify the user is S by recalculating the message digest and decrypting the digital signature, and checking for a match|
But what if there was an imposter called
I, who was trying to impersonate
|Hello, I am |
Hello, I am
From this we can see how a user can be confident that remote server is who it claims to be. It also highlights the importance of the protection of private keys.
Encrypting and Sending Messages
S's public key, it can send a message to
S that only
S can decrypt—because this task requires
S's private key. However, we learned earlier that asymmetric cryptography is much more CPU-intensive than symmetric cryptography. Thus
C generates a random secret key and informs
S of its value using asymmetric cryptography. From then onwards, encryption is done by symmetric cryptography with only
S knowing the secret key.
Here is the secret key
|Secret key is encrypted with |
|Message A is encrypted with secret key, so |
Message B etc.
|Message B is encrypted with secret key, so |
Authenticating Messages against Tampering
Now let us consider another bad guy called
E who eavesdrops on the network, and could intercept and tamper with a messages en route to their destinations.
|Message is encrypted with secret key, and intercepted by |
Because the message is encrypted, it is unlikely that tampering with it will create a valid message—but who knows, he might get lucky?
The solution is to attach a message authentication code (MAC) to each message. The MAC is a message digest value, calculated using a hash algorithm on the message contents and the secret key. The message receiver calculates the MAC value for the message and checks for a match with the attached MAC value. Since
E does not know the secret key, it is unlikely that they could evaluate the correct MAC for his new tampered message.