Schneier on Security

Clive Robinson • July 19, 2019 5:09 AM

@ Sancho_P,

Please don‘t blame email!

Why not?

Look at it this way, back in the early days of putting electrical wiring into property they put two or three bare metal conductors on porcelain insulators mounted on a hardwood board mounted on the wall.

Obviously this was quite effective at carrying electrical power to where it was needed, and adding new circuits was fairly easy. So it could be described as functional.

However what it did not do was protect people from harm, that required other things that in turn had their own failings which required other protection. The result is modern electricity cables that are “double insulated” in various ways including physical barriers such as steel or armoured conduits.

Email is those bare copper wires, it needs all sorts of extra protection mechanisms it currently does not have, but are essential for user safety…

So although the old power system was functional, it was very far from “fit for purpose”. Email is just like that… So do you want functional without safety or fit for purpose where people don’t get so easily hurt?

Clive Robinson • July 20, 2019 4:24 AM

@ Is there a way,

What do you do, then, to communicate at a distance?

Amongst other things I still use Snail Mail, and whilst I don’t use email when the need arises I do use other insecure digital comms as a carrier for more secure communications protocols on top. If you look back on this blog I’ve explained non technical ways people can do the same.

But your question of,

Or is the only secure protocol silence?

Is one that if thought about in the right way does give rise to interesting thoughts about how to communicate in nonstandard and to many quite suprising ways. Which takes you into the more technical way to do covert / anonymous communications.

The first thing that many have trouble getting their heads around in this respect is that “not communicating” is also “sending a message” so can be communications. That is silence at a time information is expected is communicating information, at the very least that there is some kind of problem.

But noncommunication is also expected in any “reliable” communications protocol. To see why you have to understand that at the lowest level all communications are inherently “unreliable”, so as engineers we add protocols to make them “reliable” and this adds extra normally considered ‘redundant” communications.

To see why at the base level all communications systems are “unreliable” you need to know that all electronic inputs have noise on them, and it’s dictated by the laws of physics as we currently know them. Likewise all transducers pick up what is sometimes called “random noise” at their inputs that then appears at their outputs for the same reasons. Thus you have two or more noise sources coexisting on those electronic inputs. For most purposes noise is considered “random and addative” over time (lookup AWGN “Additive white Gaussian noise”). The easy example to see this years ago was the old analog TV when not tuned into a signal giving “snow” on the screen, or older analog radios or audio amplifiers and the background hiss heard if the volume was turned up with no valid input signal.

Thus one of the major problems security wise with digital systems is the reliability protocols stop the user seeing signals other than the types they are specifically designed to work with. Which means they “blind the user” to all sorts of information with “silence”. And where a system hides other signals a lot can be communicated without people being aware of it unless they are sufficiently suspicious.

Lets say I send you valid packets at the IP level of the protocol stack, then your computer will process them to a limited extent. What happens next depends on if those valid IP packets contain a payload that has a protocol that is recognised at the next level on the protocol stack be it UDP, TCP, or something else and so on up the stack as long as it is valid at the previous layer.

But ask yourself what happens when the packet reaches some point in the stack it is not recognised or fails for some reason. Clearly communications of some form has happened, but the user does not see it as such, all they see is silence.

Thinking along these lines has given rise to all sorts of malware attacks, but there is more, because such protocols are layered. That is when a packet is “dropped” an error protocol is usually carried out such that a “technician” can diagnose and fix the fault. Thus this error handeling becomes a further continuance of the communications, that can in various ways send a message through a system in the reverse direction to the normal communications direction.

But few actually think about the fact that exception and error handeling in such protocols is usually bidirectional. That is you can as a “third party” send a communication of errors and exceptions back up what is otherwise a TX channel from the “first party” transmitter whilst also communicating errors to the “second party” receiver. Nor do most people realise just how transparent computing systems are to exceptions and errors. Knowing this you can send signals back through the likes of Data Diodes, firewalls and other security mechanisms, right back to the application layer at either end as well as leaking information to other users on those systems…

If you want an example from the earliest days of computer networking look at the original Ethernet protocols and how packet collisions were handeled. Noise on the line could be seen back at the application layer as time delays on data transmission buffering[1]. If you’ve ever read “The Cuckoo’s Egg” you will have read how Clifford Stoll used a bunch of keys to in effect send the German hacker a message of “no luck today” by making the “line noise” slow the connection down via the reliability protocols such that it was too slow to be usable.

Due to the use of more elaborate buffering we call “CPU Caching” various attacks were and still are possible this way, as the “Xmas gift that keeps giving” of Meltdown and Spector and other attacks they have spawned show.

As a simple rule anywhere you find redundancy in a communications system you find the potential for “covert communications in plain sight”. Using the protocols required to make communications reliable as the transport mechanism, makes such covert communications always possible when “reliable” or “lossless” communications are required by the system designers. Programmers almost always go for “lossless” communications because it makes their task considerably easier. Thus the odds are very high that in non broadcast[2] or point to point communications “Eve” will have a covert communications channel to play with, and that provided care is taken the users Alice and Bob will not see it.

So whilst you see silence at one level others at different levels see what appears to be “noise” but without other knowledge they treat it as silence. Yet it can quite easily be information communicated if you have the right information to decode it…

[1] What people often don’t realise is that the data buffering is also used to make multitasking operating systems “more efficient”. That is “on an I/O block” rather than spin wasted CPU cycles, the OS kernel would task switch. Such switching can be seen by all users of the system by comparing their various in U / K space timings with “wall time” of the system clock. Whilst it is a quite low “signal to noise ratio” modern techniques from amongst other places astrophysics has given us protocols that will pull signals as much as one thousand times smaller than the noise level, out from that noise.

[2] Broadcast systems generally because they are for more than one user and often thousands if not millions can not use the “reliable” communications protocols used for two party communications, because that use “feed back” mechanisms. Instead they use “feed forward” mechanisms such as checksums and duplicated data, the normal example given is Reed-Solomon coding on CDs. Whilst forward error correction (FEC) does not alow Eve to attack Alice at that level, Eve can get communications through to some or all the Bobs. Which as I’ve mentioned before on this blog can be used to provide better anonymity systems than the likes of Tor (search for “Fleet Broadcast”).

Clive Robinson • July 20, 2019 9:16 AM

@ Sancho_P,

Beauty lies in simplicity.

Whilst that is true and I’ve said both “beauty” and “simplicity” are essebtial to good design, we have to be cognizant that they are also both “relative points of view”.

The problem with Privacy, and the security required to establish it in todays world is the level of complexity required. You have literally thousands of attack vector classes to consider, with unknown numbers of instances in each. You can not treat each class or instance as seperate entities there are to many. Further as they potentially have as many commonalities as they do differences, it makes sense to analyse them in a way whereby they interlock in a way that helps improve mutual protection.

This can not help but be complex, thus the question arises can “complexity” be both “simple” and “beautiful” as well?

And the answer from nature is yes, at each level from the atomic up. But we also know that below certain levels they can not protect themselves from risk. That is molecules can be attacked by other molecules to protect the simple molecules more complex molecules are required.

It is much the same with electronics, basic components can only protect against basic risks. That is a capacitor can block a high voltage DC signal, spark gaps can when used correctly can clamp high voltages down to earth. Thus you would use a spark gap directly to ground on a long wire antenna. You would then use a band pass filter to block all but frequencies of interest at the receiver front end with series parallel diodes to make a low voltage clamp on either side. But this leaves open other high energy sources such as charge build up from wind and rain. A high value resistor across the spark gap helps prevent slow charge build up, but faster charge build up that produces low frequency AC signals can be dealt with by a fairly high value of inductance across the spark gap. It is also desirable to galvanically issolate the antenna from the feed to the radio to reduce common mode effects thus two close coupled inductors in various configurations do this. Thus what started of as a simple risk that could be dealt with by a single component, quickly became much more complex. Whilst not as simple it still possess beauty if you draw the circuit correctly, and likrwise build it correctly. As most radio engineers will tell you if it looks right it probably is and likewise if it looks wrong it probably is.

Similarly a few lines of code is most likely vulnerable, but as you build up the complexity you remove the easy vulnerabilities as risks leaving the more complex risks to be managed by more complex code. Can code be written that looks right as both a functional/flow diagram and sequential code? Yes, but like simple components to deal with more complex risks you need more complex code.

The thing about email is it is basically a series of simple protocols runing under a simple state machine. It was never designed to deal with risk above simple faliures. It can be shown that the protocols are actually incompleate and not all states can be accounted for. Thus it is not proof against sinple risks that can be used as attack vectors.

Back some years ago quite a few people thought that designing with “Abstract Syntax Notation” (ASN.1) would solve the risk problem. It was later found that ASN.1 like all logics above a certain level had significant issues. One of the largest projects to be implimented in ASN.1 which needed security was the “SET” system. At well over a thousand pages of very tightly typed ASN.1 it was discovered that the design was not fit for purpose and it effectively went nowhere.

Our knowledge of security is far from what it could be and we know that the issues range from simple to highly complex as do the risks thus attack vectors.

Email is clearly not upto much with regards security, and probably will never be so in our current methods of use. Which are to be honest a process of piling more complex risk on by the bucket load rather than fix the basic risks. On the basic principle that breaks camels backs. Email is at best a fairly primitive protocol that sits on other primitive protocols, all of which have had and are expected to have more failures to what are simple to moderate risks that were not even thought of when those protocols were developed. Thus at best it should be viewed as a fairly basic component part that needs much more extensive work and components around it.

Perhaps think of it like the old single wire “phantom circuit” telegraph systems of a century or so ago. Email does after all fail to the same basic risks as the early telegraph networks did, and for almost the same reasons we still see used as a basic design methodology in software these days, of “Get basic function up, and think about fixing it’s failing in the future maybe, but importantly don’t stop piling on the features untill you break something…”.