Symmetric and asymmetric encryption, certificates and TLS: WACE Computer Science Unit 4

• Keys: symmetric uses one shared secret key; asymmetric uses a public and private key pair.
• Speed: symmetric is much faster, suited to large amounts of data; asymmetric is slower.
• Key distribution: symmetric requires a secure way to share the key; asymmetric lets the public key be shared openly.

Marking guide: 1 mark each.

1. Alice hashes the contract and encrypts the hash with her private key, creating a digital signature.
2. Alice encrypts the contract (and signature) with Bob's public key (in practice, she encrypts a symmetric key with Bob's public key and the contract with that symmetric key).
3. Bob decrypts with his private key, so only he can read it (confidentiality).
4. Bob decrypts the signature with Alice's public key and compares it with his own hash of the contract. A match proves it came from Alice (authenticity) and was not changed (integrity).

Marking guide: 1 mark for signing with Alice's private key, 1 mark for encrypting with Bob's public key, 1 mark for Bob's decryption, 1 mark for verification.

1. Client hello: the browser proposes TLS versions and cipher suites and sends random data.
2. Server hello and certificate: the server chooses settings and sends its certificate containing its public key, signed by a certificate authority.
3. Certificate verification: the browser checks the CA's signature, the domain name and expiry. This protects against impersonation and man-in-the-middle attacks.
4. Key exchange: browser and server use asymmetric cryptography (for example ephemeral Diffie-Hellman) to agree a shared session key without sending it in the clear. This protects confidentiality of the key.
5. Finished messages: both sides confirm the handshake with values computed from the session key, detecting tampering.
6. Encrypted session: all data is encrypted with fast symmetric encryption and integrity-checked, protecting passwords and transactions from eavesdropping and modification.

Marking guide: 1 mark per correct step with what it protects (up to 6).

(a) Any two, linked to the example:

• Fixed length: SHA-256 always produces a 256-bit digest (64 hexadecimal characters) whatever the input length.
• Small change, completely different hash: changing one letter from P to p gives an entirely unrelated hash (19513fdc... versus 0b14d501...), so any change to data is detected.
• One way: there is no key or method to turn 19513fdc... back into Password1.

(b) Encryption can be reversed by anyone who obtains the key, so if the key and the password file were stolen together, every password would be exposed. A hash cannot be decrypted, so the site stores only the hash and, at login, hashes the entered password and compares the two. A salt is a random value added to each password before hashing, so two users with the same password get different stored hashes and attackers cannot use precomputed tables of common password hashes.

Marking guide: (a) 1 mark per property linked to the example (2); (b) 1 mark for encryption being reversible with the key, 1 mark for how hash comparison works at login, 1 mark for the purpose of the salt.

Contents

A digital certificate binds a public key to an identity: it contains the site's domain name and organisation details, the site's public key, an expiry date, and a digital signature from a certificate authority (CA).

Trust

The browser holds a set of trusted root CAs. It uses the CA's public key to verify the CA's signature on the certificate, then checks that the domain name matches the site visited and that the certificate has not expired. If any check fails, the browser shows a warning.

The padlock

It proves the connection is encrypted with TLS and that the browser is talking to the holder of a valid certificate for that domain, so data cannot easily be read or changed in transit. It does not prove the site is honest or safe: a scam site can obtain a valid certificate for its own domain.

Marking guide: 1 mark for public key and identity bound together; 1 mark for the CA signature; 1 mark for verification against trusted CAs with domain and expiry checks; 1 mark for what the padlock proves; 1 mark for what it does not prove.

(a) With symmetric encryption the same key encrypts and decrypts, so every patient's phone would need the secret key. The clinic would have to deliver it securely to each patient; if it were sent over the network in the clear it could be intercepted. If one shared key is used for everyone, any patient (or anyone who steals it from one phone) could decrypt every other patient's results, so confidentiality fails.

(b) Each patient's app generates a key pair. The public key is sent openly to the clinic, and the private key never leaves the phone. The clinic encrypts a result with that patient's public key; only the matching private key on the patient's phone can decrypt it. No secret ever has to be shared, so key distribution is solved.

(c) Creating: the doctor's software hashes the result (for example with SHA-256) and encrypts the hash with the doctor's private key; this is the signature, sent with the result. Verifying: the app decrypts the signature with the doctor's public key to recover the original hash, hashes the received result itself and compares the two. A match proves authenticity (only the doctor's private key could have made it) and integrity (any change to the result would change its hash).

(d) Asymmetric operations are computationally expensive and slow, especially for large data such as reports and images. Symmetric encryption such as AES is much faster. Using asymmetric cryptography only to agree a session key gives secure key exchange without sending the key in the clear, then AES protects the data efficiently. This hybrid combines the strengths of both.

(e) Without checking, the attacker could run a man-in-the-middle attack: the app would set up TLS with the attacker, who decrypts, reads or changes results, then passes them on to the real server. A self-made certificate is not signed by a trusted CA (and the attacker cannot forge the CA's signature without the CA's private key), so verification fails and the app refuses to connect, protecting patients' results.

Marking guide: (a) 1 mark for the same key being needed by every party, 1 mark for the risk of interception when sharing it, 1 mark for the consequence of a shared key; (b) 1 mark for key pairs, 1 mark for encrypting with the patient's public key, 1 mark for decrypting with the patient's private key; (c) 1 mark for hashing, 1 mark for encrypting the hash with the doctor's private key, 1 mark for verification with the public key and comparison, 1 mark for authenticity and integrity; (d) 1 mark for asymmetric being slow, 1 mark for AES being fast, 1 mark for the hybrid reasoning; (e) 1 mark for describing the man-in-the-middle, 1 mark for the missing trusted CA signature, 1 mark for the app refusing the connection. Total 16.

(a) After downloading, the customer computes the SHA-256 hash of the installer file and compares it with the published hash. If they match, the file is unchanged. Even a tiny change produces a completely different hash, as shown by changing one digit in the invoice text (b638d0e7... becomes 2f454e2d...), so a corrupted or tampered installer is detected. (For full trust the published hash should itself be obtained securely, for example over HTTPS.)

(b)

• The portal presents its certificate; the browser verifies the CA signature and domain, so staff know they are connected to the real portal, not an attacker on the café network.
• Asymmetric cryptography is used to agree a shared session key without sending it in the clear.
• All data, including usernames and passwords, is then encrypted with fast symmetric encryption, so an eavesdropper sees only ciphertext.
• Integrity checks detect any modification of data in transit, so tampering is noticed.

(c) The attacker could decrypt any data encrypted with that staff member's public key, and could forge digital signatures in the staff member's name, which others would accept as authentic. The business should stop using the compromised key pair: have the old certificate revoked, generate a new key pair, obtain a new certificate for the new public key, and tell people who rely on the old public key to stop trusting it.

(d) Symmetric encryption (for example AES). It is much faster than asymmetric encryption, which matters for 200 GB every night, and both encryption and decryption are done by the business itself, so there is no need to share a key with another party. The key must be kept secret and stored separately from the backups (not on the same drive); a good design is to protect the AES key by encrypting it with the business's public key so only its private key can recover it.

(e) A hash is a one-way function: there is no key and no way to turn the digest back into the original card number, so the business could never retrieve the number for a refund. Hashing only lets you check whether a value matches. If the data must be recovered, it should be encrypted (for example with AES), with the key carefully protected.

Marking guide: (a) 1 mark for computing and comparing the hash, 1 mark for any change giving a different hash, 1 mark for using the example; (b) 1 mark each for certificate verification, key exchange, symmetric encryption of data, integrity checks; (c) 1 mark for decrypting data, 1 mark for forging signatures, 2 marks for the response (new key pair and certificate, stop trusting the old key); (d) 1 mark for symmetric, 1 mark for speed, 1 mark for no need to share the key, 1 mark for secure key handling; (e) 1 mark for one-way, 1 mark for cannot retrieve the number, 1 mark for recommending encryption instead. Total 18.