Schneier on Security

Clive Robinson • February 13, 2013 6:55 AM

@ Nick P,

Why don’t they encrypt and then MAC?

The short answer is two words “History & Perspective”, the long answer is explaining why…

Depending on how you look at it the history of “cryptograhy” is very old more simply people have “been keeping secrets since befor they could communicate”. It goes back even prior to “Hunter Gatherer” tribal society and can be seen in the behaviour of animals. In essence it’s a survival trait to not communicate to competitors sources of food etc.

This continued through tribal life and promoted the ability to “cheat” or “lie” to protect “you and yours”. And it’s still going strong today, we all likes society for what it brings us but when push comes to shove and things come down to basic survival and a choice between “you and yours and society” you know the preference order.

Whilst the basic rules of the game have not changed technology has repeatedly moved the goal posts and thus the perspective.

Prior to writing to communicate a secret required a person to go to the person they were going to share the secret with and tell them in person or… involve a third party as a go between who would also become privy to the secret for as long as they lived. Which brought up various issues of “trust”…

These trust issues were partialy solved with writing and the invention of tamper evident ways of hiding them from the go between (baked clay tablets that were then put in clay enevelops that had seals impressed and then baked again).

However there were still trust issues in that the messenger was party to the fact of communication and thus could reveal that a problem we would now call “traffic analysis”.

The idea of courier services and multiple envelops partialy resolved this in a way we would now associate with Onion Routing. However it introduced other problems such as “nodes” where all communications went through and thus were vulnerable so we got the various “Black Chambers” where envelops could be opened and resealed without being (easily) detected.

And as we know the ciphers were not upto hiding the information except in isolated cases as Mary Queen of Scots exemplified resulting in her losing her head. Even code books were fairly easily broken if sufficient traffic was available for examination, and rather less if the communications context was known.

So the idea of “Super Encryption” came about where the message was first coded via a code book that only rarely changed, and this was then encrypted via a cipher system. But all the while the special papers and envelopes with seals etc were retained which still gave the impression of authenticating the communication.

Thus the idea of what we now refer to as the CIA triade was inplace several hundred years ago with Confidentiality provided by codes and ciphers, Authentication provided by special papers and seals, with Integraty given by the design and use of the envelopes and seals.

Then we had the application of electricity to communications giving rise to firstly the telegraph, which had the side effect of destroying the existing Authentication and Integrity methods and also made the passing of traffic obvious. Then the telephone which did atleast alow some (all be it faux) authentication to return. But as WWI showed the use of the telephone alowed the start of what was later to be called TEMPEST attacks. But there was also the new fangled Radio Telegraphy using “spark gap transmitters” where authentication and any kind of integrity were just not possible in anything aproaching a reliable way.

But worse it was also painfully obvious that the existing codes and ciphers were just not upto the job and this was made quite public in the writings of Winston Churchill after the war who put a lot of the UK Navies successes to code breaking in the English Admiralty Office.

Thus it was clear to all major Governments that the whole security of millitary communications rested on these inadiquate, difficult and thus untimely codes and ciphers.

It however had come to the notice of one or two people that whilst the various military organisations had basicaly stayed in the past commercial organisations had been much more forward thinking and in a limiited way had embraced machine cryptography and thus in some cases had more security than the equivalent military communications. And it would appear had also solved the authentication issue with such machines.

The result as we know was the German Enigma the British Typex and the later US and Nato SIGBA systems. But as we now know all the pre-war mechanical systems could be easily replaced with paper analogs and worse the use of mechanics for ciphering had been taken a step further with automated attacks by motorised machines and early electronic devices that were the forrunners of computers.

However what it did put in way to many minds was the belief that basic crypto alone could give you the CIA triad. And thus emphasis was given to Basic Crypto as being the magical solution even where various people knew very much otherwise (GCHQ,NSA etc) but for operational reasons wanted to keep it very very hush hush.

But due to government policy and a whole load of other issues prior to the DES competition civilian/comercial crypto was to be blunt a joke.

DES in effect kick started civilian and academic interest in Crypto again and arguably it has now in some areas beaten the governmant agencies at their own game and is in other areas progressing more rapidly than such agencies worst nightmares.

Back in the 1980’s I and a very few others were banging on about how to attack systems via what you might call “Reverse TEMPEST” and slowely but surely the academic world is catching up.

The academic world has likewise realised that there is one heck of a lot more to do with security than just algorithms. Part of this can be seen with the HASH competition, where the “so what” attitude has hit home because the game has moved on significantly in other areas. The pigeons are coming home to roost on protocols and the resulting chinks in the armour which we call side channels, that like tiny holes in the bucket drain secrecy away not instantly but still very very effectivly.

We are finding out that contrary to theoretical ideas in the practical world it realy does matter in what order you do things and how.

But importantly we are finaly waking upto the fact that our preconceptions and assumptions inherited from a previous age are wrong.

Thus the long held assumption by many that the final Crypto Envelope gives the CIA triad is wrong it’s not “magical pixie dust” you sprinkle on and all is right with the world. Other considerations apply. Just as with real world envelops you can feel through them and under certain conditions even see through them to get a good idea of what’s inside, all you need are the right tools.

We currently talk glibly of “time based” side channels but forget there are many others that the likes of electronic engineers are only too aware of.

As I’ve indicated in the past “Efficiency -v- Security” is a very real issue. If you do things the right way you can make all theoreticaly secure algorithms used to construct crypto enevelopes transparent…

Matt Blaze and some of his students ably demonstrated this several years ago by implementing a bug device in a keyboard that simply by delaying key stroke information in a predictable way made the entire computer and it’s OS and applications transparent and thus leaked information directly onto the network.

If the hardware designers or even the OS or App software writers had thought about it it would not have been that easily possible because they would have “clocked the input” in the right way.

Even now many theoretical frameworks and the resulting design verification systems don’t take clocking of the inputs and clocking of the outputs into consideration.

Those doing TEMPEST / EmSec design at indepth levels are only too well aware of this requirment but many are not.

Back in the 1980’s I was demonstrating “active fault injection” and how it could be synchronised to the operation of a CPU outside of the case with no direct electrical connection. The result was I could make a “pocket gambling device” pay out way way more than it should. Others have used the same ideas to (supposadly) “defraud” the likes of Casinos in Nevada etc in much more recent times.

As far as I’m aware the only academic paper on RF fault injection is by a couple of people at the UK Cambridge labs who pointed an unmodulated carrier at a supposedly secure TRNG and reduced its entropy from 32bits to less than 8bits. They however did not put envelope or phase modulation on the carrrier or make any attempt to synchronize it to the devices operation. The chances are if they did they may well reduce the entropy to zero and actually force the TRNG to output what ever thirty two bit number they desired, thus being able to defeat any defenders statistical analysis of the output…

Then what about Quantum Key Distrubution, the designers of many of the practical devices appear too be compleatly unaware that the order you put certain components in was important to stop active fault injection. If you can some how read Alices polariser (or it’s random generator) then it’s game over for the security. Some designers failed to realise that you could couple out of band energy back into Alice’s transmitter and read the state of the very broad band polariser simply due to what it reflected or did not reflect of the out of band signal…

There are a whole load more interesting fault injection attacks you can make on QKD equipment some of which have been published none of which so far are (as far as I’m aware) what I would call synchronised fault injection attacks.

Every time you can trace the root of these failings back to assumptions that often are actually sufficiently well known to be false but like our DNA appear hard coded into us by our forebears..

I’m reminded of the mem of a once frequent poster (RSH) here 😉