Proving you are who you say

To check that nothing was altered, you could compare the whole message. But doing that with a long document is heavy going.

So we use a message digest: the short value that comes out of putting the message through a hash function, rather like a fingerprint for it. It is also called a hash value.

Two properties. Change one character of the message and the value comes out completely different. And the length is always the same. So whether the original document is ten characters or a hundred thousand, the fingerprint is the same size.

Compare fingerprints and you can tell whether anything was rewritten without comparing the whole message.

Sending only the fingerprint is no use if the fingerprint can be swapped out with everything else. You have to stamp the fingerprint with your own seal. That is a digital signature.

The sending side goes like this.

• Make a message digest from the message
• Transform that digest with your own private key
• What comes out is the signature. Attach it to the message and send

Only the owner holds the private key. So only that person can produce this signature, which is why it works as a seal.

Note too that what gets signed is the digest, not the whole message. Processing only a short value is what keeps it light.

The receiving side turns the signature back using the sender public key. What comes out is a digest.

Then you compare that against the digest you calculate yourself from the message in front of you. Match, and it passes.

A match tells you two things: the message was not rewritten (the fingerprints agree) and the sender themselves signed it (it opened with that public key, so the holder of the matching private key made it).

Watch the direction the keys run here. It is the reverse of hiding contents. Laying it out as a table stops the confusion.

This is the most heavily targeted point in the exam. A signature does not hide the contents. The message travels attached in the clear, so anybody looking can read it.

A signature says only these three things.

• The message was not tampered with
• Who produced it
• That the person cannot later claim they never wrote it (non-repudiation)

What it cannot say: that the contents will not leak to a third party, that it will certainly arrive, that the person holds some qualification or permission, or that the same thing was not sent again.

These line up plausibly in the choices, so remember: hiding, delivering and permitting are not the work of a signature.

Verifying a signature needs the sender public key. But how can you say the public key you received is really theirs? If an impostor hands out their own public key saying "this is me", both the signature and the verification go through.

What closes that hole is a public key certificate (a digital certificate). It is an ID card saying "this public key belongs to this person", carrying the owner name, the owner public key and an expiry date, plus the digital signature of the issuer. That last one is the crux: if the certificate is a fake, verification fails.

Who issues it is a certificate authority (CA). It vouches from the position of a trusted third party, neither of the two parties involved. The whole arrangement of certificates and authorities together is called PKI (public key infrastructure).

The job of a CA is issuing certificates, and that is all. Similar but distinct jobs line up in the choices, so keep them apart.

• Handing out accurate time … the job of a time-stamping authority
• Signing a user email on their behalf … a CA does not do this
• Looking after private keys or passwords … a CA does not do this

Here is the certificate you meet every day: the padlock in your browser address bar.

Connect with https:// and the server shows the browser its server certificate. The browser verifies the signature inside it with the CA public key to check whether the thing it reached is the server it claims to be. That is the part http:// does not have.

The other job of HTTPS is encrypting the traffic between server and browser. Those two together are what https:// amounts to.

Be equally clear about what HTTPS does not do. It does not stop malicious input being fed to the server, and it does not sort out which traffic should be let through. It is an arrangement for guarding the journey, not for guarding the door at the far end.

Servers are not the only things that hold certificates. You can put one on the device doing the connecting, and that is called a client certificate.

Put a certificate on a company phone and the internal system can verify the certificate of whatever connects, checking whether this is a machine that was approved in advance. Somebody personal device brought from home gets turned away.

Worth being careful about: that one point is all you learn. Installing a certificate tells you nothing whatsoever about whether the device has a virus, whether the OS is up to date, or whether the apps are current.

Think of a certificate as an ID card and not a medical certificate, and the two will not blur.

So far this has been about machines and data. From here it is user authentication, checking a person.

The methods sort into three factors.

• Knowledge (something only they know) … a password, a PIN, a secret question
• Possession (something only they hold) … an IC card, a hardware token, a phone
• Inherence (their own body) … a fingerprint, an iris, a vein pattern, a face

Every one has a weakness. Knowledge gets forgotten and guessed. Possession gets dropped. Inherence cannot be replaced. So combining several is the basic move.

Combining two or more is multi-factor authentication. Two of them is two-factor authentication.

What matters is that it only counts if the factors are of different kinds. A password and a secret question are both knowledge, so putting them together is still one factor. A fingerprint and a vein pattern are both inherence, so likewise. Password (knowledge) plus vein (inherence) — now that is two factors.

Another favourite is the one-time password: a throwaway value good for a single use, so seeing it stolen does not help anyone next time. Some are generated from the clock, and some answer a value sent by the server, which is the challenge-response approach.

An IC card with a PIN is possession plus knowledge, so two factors. In practice the basics are: do not put the PIN in the same envelope as the card (tell them by a separate route), on a loss, revoke first and reissue after, and do not give everybody the same PIN.

Biometrics cannot decide "matches / does not match" outright. A fingerprint reads slightly differently every time, so a line has to be drawn: how alike is alike enough to count as this person?

Which brings in two rates.

• False rejection rate … the proportion of times the genuine person is wrongly turned away
• False acceptance rate … the proportion of times somebody else is wrongly let through

The two cannot both be lowered at once. Loosen the judgement and the genuine person gets through more easily, but so does everybody else. Tighten it and others are stopped, but so is the genuine person.

So installing such a device means weighing the two against each other and deciding where the line goes. Any choice saying "lower one of them" is wrong.

Authentication finishing is not the end of it. All you know is who somebody is; what they may do has to be decided separately. That is access control.

• Authentication … checking who they are
• Authorisation … deciding what they may do

The list of what they may do is their access rights. In a database there are levels: read only, able to insert and change, able to remake the tables themselves.

The principle for handing them out is least privilege: give only the minimum the job needs. An application that searches and displays needs read rights only, and gets no update or administrator rights. Handing out extra looks easier, but it makes the damage that much wider if the thing is hijacked.

Grouping rights by role rather than by person is also standard. When somebody changes jobs, the reassignment is one operation.