EMZETT.Authenticity
In short: The property that data or a connection demonstrably comes from the stated source — a protection goal alongside integrity and confidentiality.
In more detail: Authenticity is usually established technically via digital signatures or certificates: a signed document can only come from someone who has the matching private key. In TLS connections, the server certificate ensures that the client can be sure it’s really talking to the genuine server and isn’t falling victim to spoofing.
In Depth
The three classic protection goals
Authenticity, integrity and confidentiality are the three classic protection goals of information security (often called the “CIA triad”, with “A” for availability adding a fourth goal) — they’re often confused, but mean different things:
Confidentiality: only authorised recipients can read the data (encryption)
Integrity: the data wasn't changed unnoticed in transit (hashing/MAC)
Authenticity: the data really comes from the stated source (signature/certificate)
These three goals can be violated independently of each other: a message can be intact (unchanged) but still not authentic — if it was written exactly like that by an attacker posing as someone else. Conversely, a message can certainly come from the right sender (authentic) but have been manipulated in transit (not intact) if there’s no additional integrity check. Digital signatures typically provide BOTH at the same time: if a signature is valid, this proves both that the data hasn’t been changed since it was signed (integrity) and that it was signed by the holder of the private key (authenticity).
Non-repudiation
A closely related fourth concept is non-repudiation: the sender can’t later deny having sent a message, because only they have the private key with which it was signed. This distinguishes digital signatures from a simple MAC (message authentication code, which only uses a shared symmetric key): with a MAC, both sender and recipient can “sign” the message, because both know the same key — so a recipient could theoretically create a forged message that seems to come from the sender themselves. With asymmetric digital signatures, nobody except the owner of the private key can do that, which makes real non-repudiation possible.
Authenticity in TLS connections
In TLS connections, authenticity is established via the certificate chain: the server certificate is signed by a trusted certificate authority, whose own certificate in turn is stored as trusted in the browser/operating system. Without this chain, an attacker on the network (e.g. on public Wi-Fi) could pose as the genuine server and intercept credentials or other sensitive data — a so-called man-in-the-middle attack.
A real-world incident
How serious the risk of missing authenticity checks is was shown by the DigiNotar incident in 2011: attackers compromised a Dutch certificate authority and used it to issue themselves valid, browser-accepted certificates for domains such as *.google.com — even though they didn’t own these domains. This allowed them to pose as Google to unsuspecting users and read their encrypted traffic without the browser showing any warning (the certificate chain was formally “valid”, after all). As a direct consequence, DigiNotar had to shut down its business, and browsers removed trust in the certificate authority completely — the incident showed how strongly the entire web security model depends on trust in a relatively small number of certificate authorities.
Authenticity of software and files
Authenticity is relevant outside network connections too: software updates are typically signed so that an operating system or package manager can check that an update really comes from the stated vendor and wasn’t slipped in by an attacker (supply chain attack). GPG-signed Git commits and software packages work on the same principle.
See also: Integrity, Signature, Certificate