A-Level Computer Science: Security, Data and Consequences

Security is the topic where a student can write the right word and still not have the idea, so every question here asks what a protection actually does and, in several cases, what it does not.

It opens with the problem that makes public key cryptography necessary at all: two parties who have never met and cannot share a secret in advance. A key exchange is possible because the key that locks and the key that unlocks are different — not because one kind of encryption is a stronger version of the other, which is the wrong answer offered beside it.

Then passwords. A well-built system stores the result of a one-way function, and the property that matters is the direction: easy forwards, infeasible backwards, so a login can be checked and a copy of the table gives nobody the passwords. Two users choose the same password and the stored values differ, which is the salt doing its one job. A certificate is next, and the question is as much about what it does not establish — it binds a key to a name, and it says nothing whatever about whether the organisation behind the name is honest.

Parameterised queries are put as the principle rather than the syntax: the structure of the query is fixed before the input arrives, so what the user typed can only ever be data and never part of the instruction. And three checks that students routinely merge — is this a real date, is this who they say they are, are they allowed to do this — are separated into validation, authentication and authorisation.

The last four are about consequences. An organisation finds its backups cannot be restored, and the answer is not that it should have backed up more often: an untested backup is an assumption, and the policy has to include the test. A retailer that collects shoe sizes it never uses and keeps records for twenty years has broken two named principles, minimisation and storage limitation. A hiring system trained on a decade of past decisions repeats their pattern, which is a fact about the data rather than a malfunction, and "software cannot be biased because it is only arithmetic" is available as an answer. And a service described as environmentally neutral is weighed against the electricity behind it and the hardware it runs on, with neither "technology is inherently green" nor "nothing can be done" accepted.

Everything here is defensive. No attack technique or procedure is described anywhere; attacks are named only next to the defence against them. Every organisation and system described is invented, no real company or product is named, and no legislation is cited by section. Nothing is reproduced from any exam board specification, past paper or mark scheme.

Zestly is an independent study tool. It is not affiliated with any exam board and it is not an exam centre.

• Say why an asymmetric scheme solves a key exchange that a symmetric one cannot
• Explain what makes a one-way function the right place to keep a password, and what a salt adds
• State what a digital certificate establishes and what it does not
• Explain a parameterised query as input that can never be read as instruction
• Separate validation, authentication and authorisation in a described system
• Say why an untested backup is an assumption rather than a protection
• Name the data protection principles a described practice breaks
• Locate the source of a biased automated decision, and weigh an environmental claim honestly

Ten invented systems and situations: a client and server that have never met, a login module storing one-way values, two users who chose the same password, a browser shown a certificate, a form whose input reaches a query, three checks that are not the same check, a backup nobody tried to restore, a retailer holding shoe sizes for twenty years, a hiring system trained on a decade of decisions, and a service called environmentally neutral. Twelve flashcards carry the vocabulary — symmetric and asymmetric encryption, public and private key, hash function, salt, digital certificate, parameterised query, validation, authentication, authorisation, data minimisation.