Know and understand encryption including its purpose for the protection of data on hard discs, email, cloud, HTTPS websites

Safety and Security – Encryption (ICT 0417)

1. What is Encryption?

  • Plaintext – data in its original, readable form.
  • Ciphertext – data that has been transformed into an unreadable form by an encryption algorithm using a key.
  • Decryption – the reverse process that restores the original plaintext when the correct key is supplied.

2. Why Do We Encrypt?

Encryption helps achieve the four core security objectives required by the Cambridge IGCSE ICT syllabus (8.3):

  • Confidentiality – only authorised users can read the data.
  • Integrity – when combined with hash functions, it proves that data has not been altered.
  • Authentication – verifies the identity of the sender or receiver (e.g., digital signatures).
  • Compliance – satisfies legal and organisational data‑protection requirements.

3. Encryption & Data‑Protection Legislation

In many jurisdictions (e.g., UK Data Protection Act 2018, GDPR, similar laws worldwide) organisations must protect personal and sensitive data.

Encryption is a recognised method for complying with these legal obligations because it reduces the risk of unauthorised disclosure if data is lost, stolen, or intercepted.

4. Types of Cryptographic Techniques (and Their Uses)

CategoryTypical Key Length / OutputPrimary Uses
Symmetric (e.g., AES)128, 192, 256 bitsFile & full‑disk encryption, cloud‑storage encryption, VPN tunnels
Asymmetric (e.g., RSA, ECC)RSA 2048–4096 bits; ECC 256–521 bitsEmail encryption/signing, TLS/HTTPS handshake, digital certificates
Hash functions (e.g., SHA‑256)256‑bit output (fixed)Password storage, integrity checks, digital signatures (note: hashing is NOT encryption)

Key point for students: Hashes provide integrity verification; they cannot be reversed to recover the original data, whereas encryption is reversible with the correct key.

5. Threats ↔ Encryption / Related Controls (Syllabus 8.3)

ThreatEncryption / Related Control that Mitigates It
Data interception / eavesdroppingTLS/HTTPS (in‑transit encryption) or VPN tunnels (symmetric encryption)
Man‑in‑the‑middle (MITM) attacksCertificate validation by trusted Certificate Authorities (CAs) and asymmetric key exchange (RSA/ECDHE)
Loss or theft of a deviceFull‑disk encryption (AES) with TPM or Secure Enclave key storage
Malware / ransomwareEncrypted, offline backups (client‑side encryption) plus regular key rotation
Phishing, smishing, vishingDigitally signed email (PGP/S‑MIME) and HTTPS padlock verification

6. Encryption in Everyday ICT Contexts

6.1 Hard‑Disk (Full‑Disk) Encryption

  1. Data is encrypted automatically as it is written to the drive (AES‑XTS or similar).
  2. At boot‑up the user (or TPM) supplies the decryption key; without it the OS cannot read the disk.
  3. Protects information if the device is lost, stolen, or accessed without permission.

Hardware‑based key storage: Trusted Platform Module (TPM), Secure Enclave or dedicated HSM keeps the key inside the device, making offline brute‑force attacks far harder.

6.2 Email Encryption

Two widely used standards:

  • PGP / OpenPGP – combines a random symmetric session key (for the message) with the recipient’s public key (to protect the session key).
  • S/MIME – uses X.509 certificates for both encryption and digital signing.

Typical workflow:

  1. Sender generates a random symmetric session key.
  2. Message body is encrypted with the session key (symmetric encryption).
  3. Session key is encrypted with the recipient’s public key (asymmetric encryption).
  4. Sender optionally adds a digital signature using their private key.
  5. Recipient uses their private key to recover the session key, then decrypts the message.

Anti‑phishing benefit: A valid digital signature shows the message really comes from the claimed sender; missing or invalid signatures trigger a warning.

6.3 Cloud‑Storage Encryption

  • At‑rest encryption – data stored on the provider’s servers is encrypted with a symmetric key. The key may be managed by the provider (server‑side) or supplied by the user (client‑side or “end‑to‑end” encryption).
  • In‑transit encryption – TLS/HTTPS protects data while it travels between the client device and the cloud service.

Best practice: Use client‑side encryption so that only you hold the decryption key; the provider cannot read the stored files.

6.4 HTTPS Websites (TLS/SSL)

Although the term “SSL” is still used colloquially, TLS (Transport Layer Security) is the current standard. The handshake creates a secure channel as follows:

  1. ClientHello – browser lists supported TLS versions and cipher suites.
  2. ServerHello – server selects a cipher suite and sends its digital certificate.
  3. Certificate validation – browser checks that the certificate is issued by a trusted Certificate Authority (CA), has not expired, and matches the website’s domain.
  4. Key exchange – using RSA, Diffie‑Hellman, or (preferred) ECDHE, both sides derive a shared symmetric session key.
  5. Secure communication – all subsequent HTTP data is encrypted with the session key (commonly AES‑GCM).

Students should always look for the padlock icon, click it to view certificate details, and never ignore warnings about expired, self‑signed, or untrusted certificates.

7. Supporting Security Measures (Syllabus 8.3)

  • Firewalls – restrict which network traffic can reach encrypted services, reducing exposure to attacks.
  • Two‑Factor Authentication (2‑FA) – adds a second verification step (OTP, hardware token, biometric) before a user can access encrypted resources.
  • Biometric encryption – fingerprints, facial data or iris scans can unlock encryption keys stored in secure hardware (e.g., smartphones’ Secure Enclave).
  • Hardware Security Modules (HSM), smart cards, TPM – store private keys and perform cryptographic operations without exposing the key to the operating system.

8. Key Management Essentials

  • Never store encryption keys in the same location as the encrypted data.
  • Generate keys with a cryptographically secure random number generator; never reuse passwords as keys.
  • Rotate keys regularly (e.g., annually) and securely destroy old keys.
  • Back up keys in an offline, tamper‑proof medium (hardware token, encrypted USB, or paper‑based key escrow).
  • Document who has access to each key and under what circumstances.

9. Safe‑Use Tips for Students (eSafety 8.2)

  • Check the padlock icon before entering personal data on a website; click it to verify the certificate is valid and issued by a trusted CA.
  • Do not ignore browser warnings about expired, self‑signed, or untrusted certificates.
  • When using encrypted email, always verify the digital signature of the sender – an unsigned or mismatched signature may indicate phishing.
  • Keep devices updated and enable full‑disk encryption on laptops, tablets and smartphones.
  • Prefer client‑side (end‑to‑end) encryption for sensitive cloud files so that only you hold the decryption key.

10. Summary Checklist – What You Must Know

  1. Define encryption, plaintext, ciphertext and key.
  2. Explain the four reasons for encrypting data: confidentiality, integrity, authentication, compliance.
  3. Identify the three main cryptographic categories – symmetric, asymmetric, hashing – and give one example of each.
  4. Describe how encryption protects:

    • Hard‑disk data (full‑disk encryption, TPM)
    • Email (PGP/S‑MIME, digital signatures against phishing)
    • Cloud storage (at‑rest & in‑transit encryption, client‑side option)
    • Web traffic (HTTPS/TLS handshake, certificate validation, padlock verification)

  5. List at least three best practices for key management.
  6. State how encryption works together with firewalls, 2‑FA and biometric protection.
  7. Give one safe‑use tip for checking website security.

Suggested diagram: Flow of PGP email encryption – session key generation, symmetric encryption of the message, asymmetric encryption of the session key, optional digital signature, and decryption steps.

Suggested diagram: TLS/HTTPS handshake – ClientHello, ServerHello, certificate exchange, key exchange, and encrypted application data.