Show understanding of digital certification

17.1 Encryption, Encryption Protocols and Digital Certificates

0. Why encryption is needed

Encryption is the fundamental technique used to protect confidentiality, integrity and privacy of data. In the Cambridge Computer Science syllabus it links to the broader topic Data Security (Section 6.1). By converting readable data (plain‑text) into an unreadable form (cipher‑text) it prevents:

• Unauthorised parties from reading sensitive information (confidentiality).
• Accidental or deliberate modification of data without detection (integrity).
• Unauthorised use of data that could breach privacy or legal requirements.

1. Symmetric and Asymmetric Encryption

1.1 Symmetric (secret‑key) encryption

• Key idea: the same secret key K encrypts and decrypts the data.
• Typical algorithms (AS/A‑Level): AES, DES, 3‑DES, Blowfish.
• Process

  1. Plain‑text P → C = E_K(P) (encryption).
  2. Cipher‑text C → P = D_K(C) (decryption).

Simple numerical example – Caesar shift (key = 3)

Resulting cipher‑text: KHOOR

1.2 Asymmetric (public‑key) encryption

• Key idea: a pair of mathematically linked keys – a public key K_pub (shared) and a private key K_priv (kept secret).
• Typical algorithms (AS/A‑Level): RSA, ECC (Elliptic‑Curve Cryptography).
• Process

  1. Sender encrypts with receiver’s public key: C = E{K{pub}}(P).
  2. Receiver decrypts with matching private key: P = D{K{priv}}(C).

RSA illustration (tiny numbers – for learning only)

• Choose primes 

  p = 5

  , 

  q = 11

  . n = p·q = 55.
• Euler’s totient φ(n) = (p‑1)(q‑1) = 4·10 = 40.
• Public exponent e = 3 (coprime to 40).
• Private exponent d satisfies e·d ≡ 1 (mod φ(n)). d = 27 because 3·27 = 81 ≡ 1 (mod 40).
• Public key = (3, 55); private key = (27, 55).
• Encrypt the number 2: C = 2³ mod 55 = 8.
• Decrypt: P = 8²⁷ mod 55 = 2 (original recovered).

2. Encryption Protocols

2.1 SSL/TLS – purpose, benefits and drawbacks (AS level)

• Purpose: provide confidentiality, integrity and authentication for data exchanged over insecure networks (e.g., the Internet).
• Benefits: widely supported, negotiates strong cipher suites, protects against eavesdropping and tampering.
• Drawbacks: configuration can be complex; older versions (SSL v2/v3) are insecure; handshake adds some performance overhead.

2.2 Simplified TLS handshake (AS‑level focus)

1. ClientHello: client proposes TLS version, a random value, and a list of supported cipher suites.
2. ServerHello: server selects version, a random value, a cipher suite and sends its digital certificate.
3. Certificate verification: client checks the certificate chain (see Section 3).
4. Key‑exchange (RSA‑based example): client creates a random “pre‑master secret”, encrypts it with the server’s public key and sends it.
5. Both sides: derive the same symmetric session keys from the pre‑master secret and the two random values.
6. ChangeCipherSpec & Finished: each side signals that subsequent traffic will be encrypted with the newly derived symmetric keys and verifies the handshake integrity.

After the handshake, all application data is protected with a fast symmetric algorithm (e.g., AES‑GCM).

2.3 A‑Level extensions – additional protocols & modern TLS features

2.4 Other common encryption protocols (AS level)

3. Digital Certificates (Purpose, Structure, Lifecycle)

3.1 What is a digital certificate?

An electronic document that securely binds a public key to an entity (person, organisation or device). It is issued, signed and, when necessary, revoked by a trusted third‑party called a Certificate Authority (CA).

Certificates provide:

• Authentication – proves the holder’s identity.
• Integrity – guarantees the public key has not been altered.
• Non‑repudiation – the holder cannot deny having used the key for a signed operation.

3.2 Public Key Infrastructure (PKI) components

1. Certificate Authority (CA) – issues, signs and revokes certificates.
2. Registration Authority (RA) – verifies the applicant’s identity before the CA acts.
3. Certificate Repository – stores issued certificates and revocation data.
4. Certificate Revocation List (CRL) – periodically published list of revoked serial numbers.
5. Online Certificate Status Protocol (OCSP) – provides real‑time status for a single certificate.

3.3 Structure of an X.509 certificate (v3)

3.4 Certificate lifecycle

1. Key‑pair generation – applicant creates a public/private key pair.
2. Certificate Signing Request (CSR) – contains the public key, subject details and is signed with the applicant’s private key.
3. Verification by RA – RA checks identity documents.
4. Certificate issuance – CA signs the CSR, producing the digital certificate.
5. Distribution – certificate is installed on the server/device or sent to a client.
6. Validation (during a connection) – peer builds a certificate chain, checks signatures, dates, hostname and revocation status.
7. Renewal or revocation – before expiry the certificate may be renewed; if compromised it is revoked.

3.5 How validation works – HTTPS example (AS level)

1. Server sends its X.509 certificate to the browser.
2. Browser builds a certificate chain from the server’s certificate up to a trusted root CA stored locally.
3. For each certificate C_i in the chain, the browser verifies the signature:

   VerifySignature(Ci) = Decrypt{PublicKey(C{i+1})}(Signature(Ci))

   where C{i+1} is the issuer of Ci.

4. Checks the validity period and that the domain name matches the Subject Alternative Name field.
5. Obtains revocation status via a CRL download or an OCSP query (or via OCSP stapling – see A‑Level box).
6. If all checks succeed, the browser trusts the public key and proceeds with the TLS handshake.

3.6 Revocation mechanisms (AS level)

• CRL (Certificate Revocation List) – a periodically refreshed list of revoked serial numbers.
• OCSP (Online Certificate Status Protocol) – a real‑time request/response protocol that returns the status of a single certificate.
• OCSP stapling – server obtains a signed OCSP response and “staples” it to the TLS handshake, reducing latency and preserving client privacy. (A‑Level extension – see box in 2.3)

3.7 Additional risk‑mitigation techniques (A‑Level extensions)

4. Data Integrity & Authentication (Hash functions & MACs)

• Hash function: a one‑way algorithm that converts data of any size into a fixed‑length digest (e.g., SHA‑256). Used to verify integrity – if the digest changes, the data has been altered.
• Message Authentication Code (MAC): a hash‑based construction that also incorporates a secret key (e.g., HMAC‑SHA‑256). Provides both integrity and authentication.
• Role alongside encryption: After data is encrypted, a MAC (or an AEAD mode such as AES‑GCM) ensures that any tampering is detected.

5. Encryption of Data at Rest

While TLS protects data in transit, the syllabus also expects students to recognise encryption for data at rest:

• Full‑disk encryption (FDE) – encrypts an entire storage device (e.g., BitLocker, FileVault).
• File‑level / folder encryption – encrypts individual files or directories (e.g., VeraCrypt containers).
• Database encryption – Transparent Data Encryption (TDE) encrypts database files on disk.
• All of these rely on symmetric algorithms (AES is most common) and secure key management.

6. Ethical & Legal Considerations (Ethics and Ownership)

• Responsible use: Encryption should be used to protect personal data and intellectual property, not to hide illegal activity.
• Export controls: Many countries regulate the export of strong cryptography (e.g., US Export Administration Regulations).
• Lawful interception & government access: Some jurisdictions require backdoors or key‑escrow, raising privacy debates.
• Data protection legislation: GDPR, Data Protection Act, etc., often mandate encryption for certain categories of personal data.

7. Mapping of Syllabus Sub‑points to the Notes

8. Key Terms Summary