Security goals

Intuition

“Secure” is not one property. A password manager that never leaks a password but silently corrupts one entry is not secure just because it kept the secret. A system is judged against a specific list of properties, and a policy is really a statement about which of these properties must hold and to what degree. Some overlap — they are not a clean partition — but each one fails in a different way and gets tested separately.

Mechanism

Week 1 names nine goals: confidentiality, integrity, authenticity, authorisation, accountability, non-repudiation, deniability, availability, and privacy. Several build directly on the one before it.

Confidentiality

Confidentiality is the effect of mechanisms that limit who can access data in plaintext form — access control is therefore a form of confidentiality. It also covers protecting the secret content of a message or data, commonly by encryption. A loss of confidentiality is the unauthorised disclosure of information. Confidentiality carries an obligation too: if you hold someone else’s secret, protecting it is part of confidentiality, not a separate goal.

Integrity

Integrity lets a verifier check whether a message was modified in transit, or data altered since the last legitimate update. A loss of integrity is unauthorised modification or destruction of information. Defending against modification in transit is hard in general — an attacker positioned in the network can flip bits — so the useful property integrity gives you is detection, not prevention. It is close in meaning to tamper-evident.

Pitfall

Tamper-evident is not the same as tamper-resistant. Evident means you can tell it happened; resistant means it is hard to do in the first place. Resistance is the term used for hardware; integrity mechanisms in software are usually evidence, not resistance.

Authenticity

Authenticity lets a verifier determine the true originator of a message or data item. It is not the same as authentication, which is the process of identifying a party you are communicating with — authenticity is the property; authentication is one way to check for it. Effectively implementing authenticity typically requires two things underneath it:

Exam detail

Integrity is part of authenticity: without it, the message’s content cannot be trusted even if its origin can. Freshness is the other part: without it, an attacker can replay an old, genuinely authentic and unaltered message and have it accepted as new. Authenticity needs both, not either alone.

Authorisation

Authorisation lets a verifier determine whether an entity is allowed to execute an action or access data. It often makes use of authentication but does not require it — entering a cinema requires showing a ticket (authorisation), not proving identity (authentication). Authorisation is closely linked to access control and to accountability.

Worked example

AnswerAuthorisation, access control, and accountability are three separate steps, in that order.

1. Alice, a Finance Manager, tries to access the financial reporting system.
2. Authorisation: the system checks her role and determines she is authorised to access financial reports.
3. Access control: based on that authorisation, the access control mechanism lets Alice into the application to view or edit financial data.
4. Accountability: every action Alice takes inside the system is logged with her user ID and a timestamp, so an audit can trace what she did later.

Aside

Access control is not treated as a security goal in this unit, even though some material elsewhere does. Here it is a mechanism — the thing that enforces authorisation — not a goal in its own right.

Accountability

Accountability lets a verifier determine which entity, or category of authorised entities, is responsible for an action, so that action can be traced through the system. It implies authorisation and access control, and may imply authentication. It is closely related to non-repudiation. Since no system is perfectly secure, tracing a breach back to a responsible party matters, and that requires logging: records that are auditable (a verifier can access and trust them) and themselves protected from tampering.

Non-repudiation and deniability

Compare

The entity that caused an action cannot successfully deny responsibility for it. A legal concept at its core: it guarantees you cannot deny sending or receiving a transaction. Courts only need plausible evidence, not cryptographic proof. Supported by accountability; in cryptographic terms it needs authenticity, integrity, and secure timestamping of the action — timestamping being genuinely hard to achieve.

The capability to successfully reject the notion of being responsible for an action — close to the opposite of non-repudiation, and often more useful, particularly for highly confidential communication. Achievable to a degree by cryptographic means. What counts as deniable in a security sense may not match how a court interprets it.

Availability

Availability is a system’s capability to provide its services when needed, even during an attack, error or mishap — service is not denied to authorised users. A loss of availability is disruption of access to information or a system. DDoS attacks are the standard example of attacks against availability.

Availability sometimes trades off against confidentiality. In warfare, keeping communication channels available can matter more than keeping them confidential — a commander able to communicate in the clear beats one who cannot communicate at all — so encryption may be switched off deliberately. Availability is hard to achieve in general: many systems are asymmetric by design, which is itself exploitable, and attackers usually have a large attack surface to pick from.

Threat

An attacker who floods a service with requests denies it to legitimate users without needing to break any cryptography or bypass any access control — availability can fail even when every other goal holds.

Control

Week 1 does not give a specific technical countermeasure for denial of service; the general principle it does give is that shrinking the attack surface — fewer exposed interfaces for an attacker to flood — makes the attack harder to mount, even if it cannot remove the exposure entirely.

Privacy and anonymity

Compare

An entity’s ability to control what information relating to themselves is released or hidden. No single definition, because the term spans society, law and technology at once. Covers privacy of static data (released datasets), of dynamic data (database queries), and of data in transit through a network.

Example: Alice joins a health forum under her real name and address, but controls who else can see that information — the forum protects her data and restricts it to authorised staff. She is identifiable, but she governs disclosure.

The state of being unidentified or unidentifiable in a given context — an individual’s identity is unknown and cannot be traced back to them. Privacy may imply secrecy or confidentiality; anonymity is a different property from both.

Example: Bob joins the same forum as “HealthSeeker123”, gives no real personal information, and the forum keeps no IP log. His identity cannot be recovered at all.

Recall

A ride-sharing app logs your trips under your real account, but only shows other passengers a randomly generated nickname. Is this privacy, anonymity, or both?

Privacy. The app itself can identify you and knows exactly who took the trip — nothing about your identity is unrecoverable from the system’s point of view. What has been controlled is disclosure to other passengers, not the existence of an identifiable record. True anonymity would require the app itself to be unable to trace the trip back to you.