Security (A Level)

Chapter 6 introduced encryption as a way of protecting data. At A Level you need to explain how it works, why two different kinds are used, and how a user can be sure that a website or a message is genuine.

17.1 Encryption, encryption protocols and digital certificates

How encryption works

Encryption converts data (plaintext) into an unreadable form (ciphertext) using an algorithm and a key. Without the right key the ciphertext is meaningless. Decryption turns it back into plaintext. The purpose is confidentiality: even if the data is intercepted while it travels, or if a device storing it is stolen, it cannot be read.

A very simple example is a Caesar cipher, which shifts every letter along by a fixed number of places (the key): with a shift of 3, CAT becomes FDW. This is easy to break by trying all 25 shifts. Real algorithms use long keys and complex mathematics, so that trying every key (a brute-force attack) would take an impractical length of time. A longer key gives many more possible keys (a 128-bit key has $2^{128}$), so it is harder to break, but encrypting takes a little longer.

Symmetric encryption

In symmetric key encryption the same secret key is used to encrypt and decrypt the data.

• Advantage: fast, so it is suited to encrypting large amounts of data (files, disks, a whole web session).
• Problem: the key must be shared securely between sender and receiver before they can communicate. If the key is intercepted when it is sent, the encryption is useless, and with many users the number of keys becomes large.

Asymmetric encryption

Asymmetric key encryption uses a pair of mathematically linked keys:

• a public key, which anyone can have (it is published), and
• a private key, which only the owner keeps secret.

Data encrypted with the public key can only be decrypted with the matching private key. To send a secret message to Anna, you encrypt it with Anna's public key; only Anna's private key can open it. The private key never has to be sent, so there is no key-sharing problem.

• Advantage: securely sends data (and keys) to someone you have never met.
• Drawback: it is much slower than symmetric encryption, and needs longer keys, so it is not used for large amounts of data.

Tap to enlarge

Asymmetric encryption: the sender encrypts the plaintext Hello with the receiver's public key into ciphertext and the receiver decrypts it with their private key; and a digital signature, where the message is hashed to a digest, encrypted with the sender's private key, and the receiver decrypts it with the public key and compares it with a hash of the message

Close

Quantum cryptography

Quantum cryptography uses the properties of quantum particles (such as photons) to share an encryption key. Measuring a quantum state changes it, so if someone intercepts the key, the sender and receiver can detect it and throw the key away. Its purpose is to exchange keys with a security that is based on physics and not on the difficulty of a mathematical problem. Benefits: interception can be detected, and it should stay secure even against future quantum computers, which could break some current asymmetric methods. Drawbacks: it needs special and expensive equipment, works only over limited distances (so far) through fibre-optic cable, and is not yet widely available.

Secure Socket Layer (SSL) and Transport Layer Security (TLS)

SSL and its replacement TLS are protocols that provide a secure, encrypted connection between a client (a web browser) and a server, so that data cannot be read or altered on its way. HTTPS is HTTP running over SSL/TLS (shown by the padlock and https://). They are used for online banking and shopping, email and logins.

How a secure session is set up (the handshake), in outline:

1. The browser requests a secure connection and sends the encryption methods it supports.
2. The server sends its digital certificate, which contains the server's public key.
3. The browser checks the certificate is genuine (that it was issued by a trusted certificate authority, is in date and matches the website).
4. The browser creates a session key (a symmetric key), encrypts it with the server's public key, and sends it. Only the server can decrypt it with its private key.
5. Both sides now use the session key to encrypt all of the data sent during the session (symmetric encryption), and the session key is discarded at the end.

Tap to enlarge

The steps of an SSL/TLS handshake between a browser and a web server: the browser requests a secure connection, the server sends its digital certificate with its public key, the browser checks the certificate, sends a session key encrypted with the server's public key, the server decrypts it with its private key, and then all data is encrypted with the session key

Close

TLS also makes sure the data has not been changed during transmission, and that you are communicating with the genuine server.

When SSL/TLS is appropriate: whenever private data travels between a client and a server, for example online banking and shopping (card details), logging in with a password, sending personal information in a form, email between a mail client and server, and any site that shows the padlock and https://. It is not needed for a public page that carries no private data, though it is still good practice.

Digital signatures

A digital signature shows that a message really came from a particular sender and was not altered.

1. The sender runs the message through a hashing algorithm to produce a short fixed-length digest (hash) of it. Any change to the message gives a totally different digest.
2. The sender encrypts the digest with their private key. This is the digital signature, which is sent with the message.
3. The receiver decrypts the signature with the sender's public key to get the digest, and independently hashes the message received.
4. If the two digests are the same, the message is authentic (it came from the owner of that key) and has not been changed.

Digital certificates

How do you know a public key really belongs to the website or person it claims to? A digital certificate is an electronic document that links a public key to its owner's identity. It contains:

• the owner's name (the organisation or website domain),
• the owner's public key,
• the serial number and the dates between which it is valid,
• the name of the certificate authority (CA) that issued it, and
• the CA's digital signature, which proves the certificate has not been forged.

A certificate authority is a trusted organisation that checks the identity of a person or company before issuing a certificate, and signs it with its own private key. Web browsers come with the public keys of the main CAs built in, so they can check the signature on a certificate.

How a digital certificate is acquired. The organisation generates a pair of keys and sends a request to a certificate authority with its public key and proof of its identity. The authority checks that the organisation really is who it says, then signs the certificate with its own private key and issues it. The organisation installs it on its web server, which sends it to browsers during the handshake. A digital signature on a message is made with the owner's private key and checked with the public key in the certificate.