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

and a server called S
negotiate a secure communications link. The following table shows the messages that pass between C
and S
. S
has to prove that its certificate is valid by showing that it has the private key to encrypt a message digest:

`C` ------------------------------->`S` Hello, I am `C` S
<--------------------------------- Hello, I am `S` , and here is my certificate	C can now verify the certificate using the CA's public key and extract the public key of S
-------------------------------> Prove it
<--------------------------------- Here is a random bit of data plus a message digest of this data encrypted with `S` 's private key (digital signature)	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

, who was trying to impersonate S
?

`C` -------------------------------> I
Hello, I am `C`
`C` <-------------------------------- I Hello, I am `S` , and here is my certificateI	`S` 's certificate is freely available and so `I` can quite easily send a copy of it
`C` -------------------------------> I Prove it	`I` does not have a copy of `S` 's private key and so cannot construct a message that `C` will believe
`C` <-------------------------------- I ?

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

Now that

has 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 C
and S
knowing the secret key.

`C` ---------------------------------> S Here is the secret key	Secret key is encrypted with `S` 's public key. Only `S` can decode it, because this requires `S` 's private key.
`C` <--------------------------------- S Message A	Message A is encrypted with secret key, so `C` can decipher it.
`C` ---------------------------------> S Message B etc.	Message B is encrypted with secret key, so `S` can decipher it.

Authenticating Messages against Tampering

Now let us consider another bad guy called

who eavesdrops on the network, and could intercept and tamper with a messages en route to their destinations.

`C` -------------->E--------------S Message A	Message is encrypted with secret key, and intercepted by `E` .
`C` --------------E-------------->S Tampered A	`E` tampers with the message and sends it on to `S` .

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

does not know the secret key, it is unlikely that they could evaluate the correct MAC for his new tampered message.