Schneier on Security

Clive Robinson • December 17, 2010 11:31 AM

It could be argued that as side channel attacks where known prior to IPSEC that the whole of IPSEC is a back door...

I've said it before, the problem with a general purpose computing platform is "efficiency".

Unless great care is taken (clock the inputs clock the outputs) then any efficiency measure will almost certainly lead to information leaking via timing information.

Obviously the lower down the stack you go the more important efficiency is and the more easily visable any timing differences.

IPSEC is twords the bottom of the stack therefor any implementation is likley to be hemareging information via timing side channels unless great care is taken.

Do the Open BSD programers know how to take the right preccautions?

Well time will tell...

Clive Robinson • December 18, 2010 2:42 PM

@ anon,

"... it was only changed recently but OpenBSD is now taking special care about timing"

Thanks for hat it's been a little while since I gave OpenBSD source a look at I shall make a little time to re-aquaint myself with it.

Clive Robinson • December 18, 2010 3:26 PM

@ Geek Prophet,

"Implanting hardware flaws in equipment *used by your own side* is stupid."

Not always strange as it might sound it depends on a number of factors and what flaws you add.

"Even the NSA didn't put back doors into DES when they theoretically could have, because once the secret gets out to your enemies, you're screwed."

They may not have put it in DES but it is strongly suspected they did put deliberate flaws into mechanical cipher systems.

Although rumoured for a number of years beforehand a sales agent of Crypto AG ended up telling a tale of NSA involvment in some of Crypto AG's products (he was subsiquently charged under Swiss comercial law).

However the original rumour goes back to the C34 field cipher used extensivly by the US military. Subsiquent analysis done in the 1980's shows that part of the story has some truth to it.

To understand why it is not only possible but even plausable you first have to realise that the NSA has two functions in life. The first is to secure all US classified communications, the second is to read the secrets of foreign countries (including all it's allies without exception). And this dual role was also the case for it's predecessors, right back to before Riverbank.

The story goes something like this,

It is a well known and accepted axiom that the "enemy knows the system". However as many people realise they might know sufficient to reproduce it but do they realy have the mathmatical and logical skills to realy understand all it's strengths and weaknesses.

The reality is probably not. And this gives rise to an intresting idea to solve the problem of securing your own comms without the enemy being equally as secure using a "knocked off" copy of your system.

The problem with all mechanical ciphers and most electromechanical ciphers is once captured their basic workings become known to the enemy who can easily build their own system based on it.

This can be seen in that the German Enigma and British Typex where essentialy the same system, and the British used lightly modified Typexes to decode German Enigma traffic.

Thus if you put out a strong cipher into the field (to forfill the first requirment) it will inevitably be captured and copied and thus the enemy has the oportunity to bring their comms security up with yours (and negate the second requirment).

How do you reconcile the two requirments.

Well one way is to design a system with a large key space. But importantly some parts of the key space are strong, some of medium strength and some weak (even DES had some weak keys).

Now if you know which keys are strong you ensure that your comms only uses those keys. However if the enemy does not possess sufficient analytical skills and knowledge then they will use keys randomly from the whole key space. Thus a certain percentage of their traffic will be easily read.

What is not often appreciated is that the "technical breaking" of a cipher is not the routien activity of Government cryptoanalysts reading the traffic is. To get "daily breaks" consistantly requires a good knowledge of the traffic you are trying to read. Thus the more traffic you have read the easier it becomes to decode other traffic or associate meaning with traffic flow analysis. So not being able to read all traffic is not of necessity as bad as it might seem at first, even reading as little as 10% with time will enable the context and content of other messages to be inferred and thus "probables" be deduced that significantly short circuit the brute force cryptanalysis (it is one of the reasons this sort of directed brut force attack is known in some circles as a "British Museum" attack).

Clive Robinson • December 20, 2010 4:03 AM

@ NickP, RobertT,

It would appear Mr Perry's Email and comments are getting around they are also posted to the Financial Crypto blog,

https://financialcryptography.com/mt/archives/001301.html

One thing Mr Perry says is interesting,

"I left NETSEC in 2000 to start another venture, I had some fairly significant concerns with many aspects of these projects, and I was the lead architect for the site to-site VPN project developed for Executive Office for United States Attorneys, which was a statically keyed VPN system used at 235+ US Attorney locations and which later proved to have been backdoored by the FBI so that they could recover(potentially) grand jury information from various US Attorney sites across the United States and abroad"

If you filter the junk out you get left with,

1, I left NETSEC in 2000,
2, I was the lead architect,
3, which later proved to have been backdoored by the FBI.

Depending on how you read it he appears to be saying that he was not involved with the backdooring just that at a later point it became known to him potentialy via a third party who he used to work with.

Which potentialy means it was not actually "backdoored" but "exploited" because the third party informing him might have said "The FBI are reading the traffic by a side channel backdoor in the code". The expression "backdoor" is sufficiently ambiguous in usage to allow either meaning...

This issue is developing a strong set of legs and potentialy may get in the non technical press who will no doubt look for the lurid angle.

Clive Robinson • December 20, 2010 9:29 AM

@ Oliver Grieb,

"Do you have any pointers to some research where this has been tried - maybe even successfully to some point - for recent/ current systems?"

Yes and no.

The actual key space issue is one that has receded into the past (sort of) due to the actuall key space size in modern systems and the much more clued up open research communities.

We saw some designs that had "related key" issues but these where generaly found quite quickly.

We do know that back in 1993 NIST and the NSA designed under the "Capstone Project" the skipjack algorithm that was to only go into chips (clipper etc) and had the built in LEAF to enable US Gov key recovery.

Skipjack was supposadly secret (and it's design assumptions and background theory still are). However this caused a public backlash and a few selected academic cryptographers where invited to look at the design and they declared it to be acceptable.

Importantly their report leaked some information that the algoritm was actually designed back in 1987 and made up from primitives that had been under intense investigation for over 40years prior to this...

However the project collapsed and the Skipjack algorithm became public in 1998. Part of this was even by then it was obvious 80bits was going to be insufficient within a short period of time.

More importantly many eyes started looking at it and it is a very interesting design.

Firstly it only just meets the 80bit criteria that is there is no margin for safety under the then known publicaly attacks. Importantly new attacks developed against it come in almost bang on the 80bit spec.

Secondly the design is extreamly brittle even what appeare to be quite insignificant changes or even apparent optomisations significantly weaken it.

Now two things arise from this. Firstly SkipJack like DES before it only just meets key bit size criteria which is odd in of it's self and sugests that much more is known about cipher system evaluation than the NSA has revealed (as with DES).

Secondly and perhaps more importantly the very brittle nature of the design shows the NSA is still walking the "dual function" line quite well.

The we come onto AES, the design selected was quite odd few people would have rated it's chances even at round one of the competiton. This because at first site it's Bricklayer algorithm just looks to linear and the key scheadual algoritm likewise just does not look up to the job, thus it just feels wrong (and still does).

However for some reason neither NIST or the NSA considered or remarked on the practical demonstration implementations that have turned out to be very very weak due to side channel leaks via such things as timing issues.

Now I just do not believe that these issues where unknown to the NSA (in fact I'm sure they were not, as similar EmSec / TEMPEST attack vectors where well known back in the 1970's).

So why did the NSA keep quiet?

Well maybe even they have given up on trying to limit the "theory gap" and have started working in different areas.

As I've said before the three main attack spaces we should be considering are,

1, Protocol failures
2, Side Channels (timing etc)
3, Known Plain Text attacks.

Of the three the last is the "bread and butter" of working cryptoanalysts not your theoretical cryptoanalysts. That is other than "messages in depth" the academic community has paid little attention to the issues involved. And importantly we know that the likes of the NSA and GCHQ have been working very hard in this area since before WWII...

If I was trying to backdoor an opositions systems witha long term vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv from the outset I would go for issues in the protocol design

Clive Robinson • December 20, 2010 9:59 AM

@ Oliver,

Sorry the LG mobile smart phone I use keyboard driver took a walk in the park, and I had to hard reboot.

As I was saying if my longterm mission to backdoor everybodies sytem so I could get access to their comms then I would start with the protocol.

Putting subtal flaws in would not be difficult and importantly if you also provide the first implementation you can leverage "edge effects" by effectivly forcing everyone else to be compatable with your implementation.

The other advantage is that due to legacy systems that cannot be changed and general market malaise protocol errors will stay long long after they have been discovered.

Why?

Well because of "fallback" when two systems try to communicate the first thing they do is work their way down their respective features list untill they find a compatable mode.

Now almost without exception the fallback process is compleatly transparent to the user and they don't see (or care) what protocol they use.

Likewise for a quiet life software suppliers will include all protocols broken or not simply due to "backwards compatability" with systems that cannot be upgraded for whatever reason (poorly implemented and/or embedded).

Even if two systems have protocol 2.x they will almost certainly have the insecure 1.0 protocol. So all a Man in The Middle Attack has to do is force a fallback during the negotiation phase so the systems communicat using protocol 1.0.

If done sparingly the chances of the target noticing are about as close to zero as you can get. And might not even become suspicious when secondary effects make it obvious the oposition are party to your secrets. As with the German's in WWII you are way way more likley to look for a spy than crypto faliure.

Now that I have mentioned this potential MiTM attack vector I expect to see it in use against financial systems oh within the next year or so depending on how much the financial institutions toughen up their existing totaly inadiquate systems.

Clive Robinson • December 23, 2010 4:15 AM

@ Black Panther,

"Another question that needs answering is assuming it is true then why OpenBSD?"

It could simply be one or more of,

1, OpenBSD crypto code is unencumbered and thus gets migrated into many products sight unseen.

2, OpenBSD crypto code tends to be one of the first unencumbered implementations.

3, BSD network code is the granddady of nearly all network code in use.

For instance if you look at Microsoft Network code you will find that it was all pretty much lifted from the BSD 4 and earlier source code at some point, likewise Sun OS, most *nix and just about any OS with pretentions at being more than just an embedded gadget (and yes many of those use BSD derived code).

Look on OpenBSD crypto/network code as being "the one ring that binds them all".

If you are planning on "backdooring the world" then the place you start is with,

"Protocols"

The thing about comms protocols is they hang around your neck like a millstone once they are in use (and it is only long after that the "bugs" get noticed).

Protocol analysis hasn't had the level of academic research they should have, thus anything more serious than a simple point to point ack/nack protocol is going to have holes in it...

The next problem is even if made theoreticaly secure can practical efficient implementations be secure (side channels)?

If it is possible to make a secure practical implementation via custom hardware etc, is the same true also of software only implementations?

Especially in high "efficiency" high throughput multi tasking multi user systems?

If not then you have step one of a backdoor....

We have seen that AES has this problem. That is AES's theoretical security is a lot better than we currently need. However practical software implementations especialy on multi tasking multi user systems through timing side channels can give up the key in as little as a couple of hundred encryptions or decryptions under the same key (so one MS Word Doc for instance). This is with an unprivalaged user program running on the same box, or a few thousand encryptions or decryptions just by observing packets on the network with some software only AES implementations.

Now even if a protocol is secure in normal conditions there is the question of "interoperability" it is an accepted fact you cann't document everything in advance of practical in depth and long term testing.

So what generaly happens is somebody produces the first implementation that matches the spec "sort of". And every one else works to that implementation for "interoperability" reasons. This means the first implementation can if produced by people with the required expertise put in a load of "edge cases" where by they effectivly add a backdoor entry to the protocol "sight unseen" even though the protocol it's self may be theoreticaly secure and tested as such.

That is the implementation is secure under normal operation but give it subtal timing or other issues via a a Man in The Middle device such as a router and you open up a side channel.

The NSA for instance is happy to use AES for "data at rest" with the likes of the Inline Media Encryptor (IME). BUT apparently not for data in transit in equipment they have designed and built and remains clasified (and usually they provide the keymat for).

Now an interesting little research problem for a PhD, we know "theoreticaly" that AES keys are broadly of the same strength.... But what about in a practical implementation. That is in any given software implementation in major use are there some keys that are very weak and others that are very strong when seen from a side channel (timing or power spectrum)...

Clive Robinson • December 29, 2010 2:45 PM

@ wam,

"So we could do kernel level hardware support for crypto."

Yes but...

First we need a framework that is going to lend it's self to being both flexible but also side channel resistant (timing, power spectrum etc).

This is not easy in simple environments at the best of times (the task is of necessity multilayered and thus has some subtle issues). And I'm fairly certain Nick P and others would have advice to chip in (like "argh, don't do it way X").

The simplest way to do secure comms is with fixed rate signaling (Mil have done it this way since WWII for a reason ;) However it is not going to work well in multi-user (therefore potentialy multi-key multi-mode) systems.

As a minimum in a multi-user environment any system would have to allow for multiple hardware insatances. And the hardware would need to support multiple keys and different modes on the same hardware instance.

But... the hardware must still keep the keys, plaintext and cipher texts isolated from each other ie not reliant on kernel only security (and this is a hard problem).

Kernel to hardware communications would need to be constant to stop some side channel attacks however this causes issues with various crypto modes when not supplying constant data streams (ahh the joys of constant rate packet switching over collision detect and variable rate back off protocols such as Ethernet etc).

Usually the issue boils down to using tried and tested CommSec techniques where the design can be proved and basicaly at best these are inefficient. That is single comms channel per hardware instant, full seperation between inputs and outputs, clocking the inputs and clocking the outputs at an invariant rate and have long backoff times on error as a starting point. None of which is. realy compatible with multi-user systems...

Clive Robinson • January 4, 2011 7:32 AM

@ Paul,

"I'm not up on this side channel stuff, but the idea that you can get information out of power supply draws is pretty laughable."

They are a very real and serious threat for many reasons.

Some side channels exist because we don't use energy efficiently. The wasted energy is not destroyed, nor can it be, it can only be temporarily constrained or disipated. Either way ultimately it ends up in the environment as "heat" (which is the ultimate form of polution).

The problem is that on the way to becoming heat via it's transportation mechanism the energy communicates information via the implicit communications channel of the transportation mechanism. How much (time) now quickly (bandwidth) and how far (efficiency) depends on the properties of the transportation mechanism and the form of the energy using it.

It was known back at the time of the First World War that electromechanical and electrical communications systems leaked information via electrical energy into the environment that could be picked up by the enemy "eavesdropping" (see "phantom phone circuits" for how it was done). And in the case of acoustic energy for many centuries before that which is where the term "eavesdropping" comes from.

The likes of Westinghouse and Bell companies where well aware of "cross talk" and the problems of "close coupling" and "inductive loading" to get long distance cable communications to work back in the 1800's when the first long distance wired communications networks (telegraphs) where setup.

Thus the ideas behind Emission Security (EmSec) TEMPEST and EMC have been known practicaly for well over one hundred years.

The cause of the EmSec side channel problem is as noted above that energy does not like to be constrained, it want's to leak away in any form it can as quickly as it can (hence the term "free energy").

To do this energy needs a transportation mechanism, and some are more efficient (radiation) than others (conduction) in various environments (insulators) but not in others (conductors). Thus you have a complex task when constraining energy in that any one measure that has advantages to inhibit one transport mechanism generaly aids another form of transport mechanism.

However even transportation mechanisms tend to suffer from inefficiency...

As you will see from the manufactures specification sheets all electrical cables act not just as low pass filters but have signal antenuation or loss with distance. This loss has two primary causes, the first is the DC or IR (current, resistance) charecteristics causing "heating". The second is AC frequency (w) related where impedence is more complex (z) but involves amongst other things EM radiation.

That is due to inductance and length all wires are effectivly "antennas". To travel sizable distances EM radiation needs to be in what is called a "plane wave" where the E and H fields are orthagonal to each other this is known as the "far field". However in a wire the E and H fields are generaly not orthagonal to each other and thus you get a transition region known as the "near field".

As a rule of thumb a straight wire suspended in free space will not radiate provided the near field is undisturbed (look up "G wire transmission line"). One way of achieving this is to use another conductor close coupled to the wire to act as a constraint to the E and H fields and maintain the relationship between them (look up balanced, twisted pair and coaxial transmission lines)

As a very rough rule of thumb the near field is a region of two wavelengths from the "wire". However the properties of the near field are effected by any conductors or dielectrics that are placed in it. The usualy seen example is a Yagi TV antenna, but in the microwave regions you will see "dielectric" antennas where plastics like expanded polystyrene are used to effect the transition of the near and far field in the same way as a lens does with EM radiation in the visable spectrum we see.

Less often seen antennas are "slot radiators" where holes in a conducting sheet act as very effective transitions for EM radiation.

The simplest way to encorage a wire to radiate is to put a bend it as this increases it's inductance at that point by distorting the E and H field relationship. Thus effective changing the impeadence of the wire at that point and encoraging radiation into free space. Thus as you continue to bend the wire it will eventualy form a loop, the larger the loop area compared to the wavelength the better in general the loop will radiate. However the relationship between the bend radius and radiation efficiency is not a simple linear one.

Thus the tracks on a PCB carrying information will emit an EM field which will couple energy into any adjacent conductors or travel more freely through some dieletrics. Which in turn will reradiate the EM field at some point. Even sheet metal will carry the energy of an EM field and in the process of re-radiation effectivly cause the EM field to be reflected, or if there is a discontinuation such as a hole for ventilating heat re-radiate from any point. The only way to reduce the radiation is to ensure no discontinuation in the conductor, it's impeadence, the E and H fields around it and source and load impeadence that matches the impeadence of the line etc. Which is a difficult job especialy where the signals have fast rising edges and thus high spectral content.

Putting a capacitor on a PCB track causes most of these changes thus although it might average out the low frequency component of the transitions frequency spectrum in the part of it that is a capacitor it causes the higher frequency components to be radiated from it's leads and the circuit it's connected to...

Thus a capacitor like any other component is a bit of a "Catch 22" device in actualy use, and energy that has not been averaged out as heat in resistance will get back out by whaterver transmission mechanism is available to it.

As mentioned earlier the transmission mechanism will take information with it effectivly as modulation on the EM spectral components. The only constraints are effectivly the bandwidth of the transmission mechanism and the level to which the energy has decayed due to the spreading of the plane wavefront with distance.

You will see the expression "-174dbm in a one Hertz bandwidth" given for the "thermal noise floor" you will also see the near field freespace loss given as 17dB from these and the energy in a given circuit you can (in theory) work out the minimum safe distance at any given information bandwidth and circuit energy level.

In practice the theory is ineffective due to the calculations involved and the fact that that even the near field can be impracticaly large. So other methods are applied.

The contrling of basic radiation mechanisms can be looked up in any decent EMC refrence.

However the world is a connected one where communications is the basic facilitator of our modern society. Thus the question arises of what happens when you intentialy radiate a signal such as down a telephone or network cable?

Not only do you have to consider the possability of signals unintentionaly "piggybacking" onto the cable but also the charecteristics of the signal you are transmitting.

This gives rise to another set of side channels based on timing changes. Back when the electromechanical relay was first designed it was known that it had timing issues via the "hold and relaease" times. That is if you know the switching time you can tell the difference between the action of a "normaly open" contact pair and a "normaly closed" contact pair.

You can arange relays in a circuit configurations that will give you all the basic logic functions of NOT, OR, AND and XOR. The last of which is used as the basic logic element in the "theoreticaly secure" One Time Pad or Tape cipher system.

One such system system was developed by people working at the UK's Forign and Commenwealth Office (F&CO) for use by the Diplomatic Wirless Service (DWS) and for various reasons lost to the sands of time called the Rockex System.

It was being used towards the end of WWII to "super encrypt" traffic going out on an unsecured telex line. Sadly it was discovered by the predecsesor to the NSA that by putting an osciliscope across the telex line pair the relay time differences alowed the super encryption with the OTP to be stripped off. So although theoreticaly secure it was not so in practice...

A later development of the Rockex was found to also cross couple signals from the power supply line to the telex line and also alow the super encryption to be removed.

The Rockex was then used in "off line" mode to do super encryption thus ensuring an "air gap" between it and the telex line.

Most crypto gear leakes information via the power supply and earth return loops (those things that cause mains hum buzz in your HiFi stack). Thus the earthing of such equipment is "prescribed in ComCen use" via various secret documents that originated from the descover of such side channel issues.

As you will have noticed the only earthing instructions that come with your PC are those tucked away under "safety"...

Thus I think you can take it as read that if your PC is powered via the "mains" and you alow an earth loop to form say via the monitor power supply lead, network or modem connection then it is going to leak information...

It is one ot the reasons TEMPEST knowledge and equipment is classified in the US (but not in some other countries) and it was only interferance issues we now call EMI that EMC became a requirment.

However their are some realy glaring holes in most EMC specs that alow the old game to be continued to be played....

Which is just one of the reasons why I say "beware protocols" (which standards are) as they are a realy good way to backdoor a system for a very very long time.