Advanced System Software and Security: Question 10

Worked solution

Part (a): Why symmetric encryption for the bulk of the session

Symmetric encryption uses the same, comparatively simple key operation to encrypt and decrypt data, which makes it much faster and far less processor-intensive than asymmetric encryption for protecting the same volume of data. Since an entire browsing session can involve a large number of page requests and responses, using symmetric encryption for this bulk of the traffic keeps the connection efficient, rather than paying the much higher processing cost of asymmetric encryption for every single message. [2 marks]: [1] for stating symmetric encryption is faster/less processor-intensive, [1] for linking this to it being more efficient for the large volume of session data.

Part (b): The key exchange problem

If the browser and server want to use symmetric encryption but have never securely shared a key before, they run into the key exchange problem: the one shared key needed by both sides has to be transmitted somehow, and if it is intercepted in transit, the interceptor can then decrypt every message protected with that key for the rest of the session.

This problem does not apply to asymmetric encryption in the same way, because each party’s public key is meant to be shared openly. It can be sent over an insecure channel, or even published, without weakening security at all. This is because data encrypted with a public key can only be decrypted using the matching private key, which is never transmitted anywhere and stays solely with its owner, so intercepting a public key in transit gives an attacker no way to decrypt anything. [2 marks]: [1] for naming/describing the key exchange problem, [1] for explaining why asymmetric encryption avoids it (public keys can be shared openly; only the non-transmitted private key can decrypt).

Part (c): Combining asymmetric and symmetric encryption in SSL/TLS

SSL/TLS solves the problem in part (b) by using asymmetric encryption briefly, only to exchange a key, and then switching to fast symmetric encryption for everything else:

1. During the handshake, once the server’s digital certificate has confirmed its identity, the customer’s browser generates a random session key, intended for symmetric encryption.
2. The browser encrypts this session key using the server’s public key (asymmetric encryption) and sends it to the server.
3. Only the server, holding the matching private key, can decrypt this and recover the session key, so the session key has been exchanged securely, even though it travelled over a network that could otherwise be intercepted, solving the key exchange problem from part (b).
4. Both the browser and the server now hold an identical copy of the session key. For the rest of the session, they use this shared key with symmetric encryption to encrypt and decrypt all further data exchanged, which is much more efficient than continuing to use asymmetric encryption for every message.

[4 marks]: [1] for the browser generating a random session key, [1] for encrypting the session key with the server’s public key before sending it, [1] for only the server’s private key being able to recover it (solving the key exchange problem), [1] for both sides then using symmetric encryption with this shared session key for the rest of the session.

Final answers

• (a) Symmetric encryption is faster/less processor-intensive, so it is more efficient for the large volume of session data.
• (b) The key exchange problem: sharing a symmetric key securely is hard; asymmetric encryption avoids it because public keys can be shared openly and only the private key (never transmitted) can decrypt.
• (c) The browser generates a session key, encrypts it with the server’s public key; only the server’s private key can recover it; both sides then use symmetric encryption with this shared session key for the rest of the session.