Gânduri Eclectice – Eclectic Thoughts

I’ve run a few training courses with novel techniques for getting memorable lessons across. Here’s another.

Knowing whom to trust is difficult. If it wasn’t, life (and cyber security) would be simple. Some people trust others too easily, some are better than others at spotting the Bad Actor. But even someone who is excellent at correctly identifying Bad Actors cannot be present all the time.

When we design systems – and I include elements of governance, processes, technical controls, logging/auditing/alerting (“Protective Monitoring”), and personnel controls as important (and indeed integral) parts of such systems – we are designing something which has to be capable of defending itself against Bad Actors, including insiders.

Cyber security specialists need to have a well-developed scepticism in their dealings with others. Some have it naturally, some do not – but can learn to at least question everyone relevant and everything relevant. For appropriate values of “relevant”, of course.

Training in Encryption Theory And Practice

A training course I once ran was to introduce a group of six new Security Consultants to the theory and practice of encryption, covering the basics of symmetric and asymmetric encryption. To demonstrate and to get them used to the practicalities of using asymmetric encryption I conducted a lab session in a training room using PGP^[1]. The room had desks against the walls all around, and each student had their own standalone PC.

The excecise is fairly simple; each user generates a key pair, using their email address as the Identity. The objective is for the users to securely exchange messages without anyone else being able to read them. Simple.

So for our users being trained, they need each others’ public keys. Now each user goes at their own speed, as with any training course, so they don’t all have their public keys created and ready at the same time. It’s good to let the users help each other work out their problems, and have the quicker ones help the slower ones work through the process. So I have nothing much to do until they’ve all created their keypairs.

Once I have all 6 public keys on the floppy, the users take turns to copy all five additional public keys to their keyrings on their individual PCs.

Now the fun starts.

The users begin encrypting messages to each other, passing the encrypted files around on the floppy disk. It does not matter that they can see encrypted files not intended for them – that’s the whole point of the encryption; each message is encrypted such that only the owner of the private key corresponding to the public key used in the encryption process can decrypt and read the message.

But there is some consternation amongst the ranks. I leave them to see if they can resolve the confusion themselves.

Soon the room is in chaos. No one can read any of the messages. I tell them to work it out; they are all intelligent technical people. It’s fascinating watching them work together on the problem.

And this is where the real learning happens. The rest they could get from a book, but this really has to be experienced for it to stick meaningfully.

Finally, the group reach some conclusions even as they struggle to believe them. But the evidence is there. Someone has subverted the set of public keys that they have for each other! They prove it by re-exchanging their public keys, and it all works. The group turn and stare at me. They can’t really believe it, but the culprit is….. ME!

Before the lab, I generated 6 keypairs, and put each user’s identity (email address) against one of the keys. The 6 public keys went on a floppy disk in my back pocket. A separate floppy disk was used to collect up the real public keys. And then, of course, I swapped the disks and subverted the entire process.

This is a classic Man-In-The-Middle (MITM) attack, outlined in basic form below. If I had also been able to intercept the encrypted messages between them, then I could have completed the attack undetected (additional steps 6+7) – but the whole point of this excercise was to let them discover the attack to demonstrate why it is so important that you have the correct public key(s) in the first place.

Man-In-The-Middle Attack Against Asymmetric Encryption

1. Alice sends a message to Bob, which is intercepted by Mallory:
   • Alice “Hi Bob, it’s Alice. Give me your key.” →  Mallory
2. Mallory relays this message to Bob; Bob cannot tell it is not really from Alice:
   • Mallory “Hi Bob, it’s Alice. Give me your public key.” →  Bob
3. Bob responds with his public key:
   • Mallory ← [Bob’s public key] Bob
4. Mallory replaces Bob’s key with their own, and relays this to Alice, claiming that it is Bob’s key:
   • Alice  ← [Mallory’s public key] Mallory
5. Alice encrypts a message with what she believes to be Bob’s key, thinking that only Bob can read it:
   • Alice “Meet me at 6pm!” [encrypted with Mallory’s public key] → Mallory
6. However, because it was actually encrypted with Mallory’s public key, Mallory can decrypt it, read it, modify it (if desired), re-encrypt with Bob’s key, and forward it to Bob:
   • Mallory “Meet me at 7pm!” [encrypted with Bob’s public key] → Bob
7. Bob thinks that this message is a secure communication from Alice.

I like to think that these users will not have forgotten this experience, and have learned and retained a healthy scepticism regarding whom to trust and when. And that is the type of lesson you cannot easily acquire from just a book.

So when someone asks for a public key (be it PGP, or an ssh host key, or whatever), and then actually bothers to contact you via another channel (phone, in person, whatever) and verify the fingerprint of the key, that should be regarded as a Good Thing™️. And, just maybe, they want assurance that Baskerville (or even worse someone else) isn’t playing silly buggers!

Footnotes

[1] This was around 1999. No fancy GUI PGP here, this was the 2.6.2 DOS version.

[2] For a fuller account of Alice & Bob, written much better and more amusingly than I ever could, see The Alice & Bob After Dinner Speech. Recommended reading. A taster:

“Now most people in Alice’s position would give up. Not Alice. She has courage which can only be described as awesome. Against all odds, over a noisy telephone line, tapped by the tax authorities and the secret police, Alice will happily attempt, with someone she doesn’t trust, whom she cannot hear clearly, and who is probably someone else, to fiddle her tax returns and to organize a coup d’état, while at the same time minimizing the cost of the phone call. A coding theorist is someone who doesn’t think Alice is crazy.”

[3] It was 1999 or thereabouts. Don’t judge!

AI Transparency Statement