Schneier on Security

Clive Robinson • February 12, 2020 5:26 AM

@a,

Does anyone know how exactly they backdoored the machines?

Yes and no, what we do know is that some of the machines had to be both secure and insecure, so that they could interoperate without raising any “red flags” by not interworking with secure machines…

We know from the book “Spy Catcher” written by Peter Wright published in the early 1980’s that one method was to supply an “algorithmicaly secure machine” but with an “acoustic side channel” that leqked key information in it. Basically MI5 had gained audio access via an “infinity device” to the “Crypto Cell” at the Egyptian Embassy in London. They could thus hear the mechanical cipher machine running. Whilst it did not give the “key” what it did do was give the “wheel” starting points, turn over points, and which were rotated at any time. This reduced the “attack space” GCHQ had to deal with from “months to minutes”.

As for effecting the “key stream” back in WWII the stratigic not tactical German high level cipher machine was the Lorenz teletype cipher machine. It used 12 cipher wheels with “movable lugs” on the wheel periphery, that caused a “key stream” to be built by XORing the lug positions. The wheels sizes were essentialy “prime to each other” thus whilst they were only 30-60 steps each their combined sequence was the multiple of their step sizes which was immense. At Bletchly Park the traffic from these machines was codenamed “Fish” and the machine “Tunny”. The work of two men broke the machine sight unseen due to a mistake made by a German operator. There are various pages up on the web that will give you as little or as much information on it as you would like.

But what you need to remember is that,

1, The failings of the Lorenz machine are shared by many other machine ciphers not just mechanical ones.

2, Virtually all machine ciphers pre AES have both strong and weak keys with a range in between.

The US Field Cipher based on the Boris Haglin coin counting mechanism suffered from the second issue, in fact it had rather more weak keys than strong. This was not a problem for the US military as they “Issued key scheduals centrally” thus knowing what were strong keys and what were weak keys they only ever used the strong keys. The knowledge of weak and strong was as far as we can tell worked out by William F. Friedman, and it was deliberatly implemented as such by him. That is, the big weakness of any field cipher machine is the enemy will capture it and may well end up using it or copy it’s design to make their own machines (see the history of Enigma type “rotor” machines to see that in action).

Thus the reasoning was either the enemy is smart and will know about the strong keys and weak keys in which case nothing won or lost. However if they do not and assume all keys are the same, then your cryptanalysis team has just been given a great big bonus to make thier lifes easier. What was not known then and still not widely recognised was the British invention of Traffic Analysis in all it’s forms and the huge card file database they used with it. This enabled them to identify specific traffic circuits and individual operators without the use of cryptanalysis. Which gave not just vast amounts of “probable plaintext” but also “probable cillies” and other bad operator habits. All of which made breaking of even strong keys very very much easier. Thus traffic under weak keys becomes a leaver to put in the cracks of strong keys…

What is also known is that Crypto AG supplied customers not just with the actual crypto machines but a whole lot of key generation support… This was in the form of manuals and machines, all of which pushed Crypto AG customers into producing either “weak key scheduals” or “known key scheduals” but the actual encryption machines worked identically to those who used “secure key scheduals” thus were fully compatible, so no red flags raised.

The thing that we forget these days is that designing crypto kit is actually a hard process. Whilst it’s easy to come up with complex algorithms, they are almost impossible to implement in a mechanical system that is reliable in use. Likewise for their pencil and paper analogs. Also they are eye wateringly expensive to make. If you are ever lucky enough to get your hands on just a single Enigma rotor you will see it is superbly engineered from many many parts each one of which requires a great deal of engineering thus there are hundreds of hours of work in each Enigma machine even though the outer wooden box might look crude to modern eyes. Thus only fairly simple algorithms got implemented based on minor variations to odometer or coin counting mechanisms.

Untill DES came along nearly all “electronic” cipher machines were based on simple circuits like shift registers and SR latches. In most respects many were just simple copies of mechanical cipher algorithms. So the likes of a Lorenz wheel became a “ring counter with reset” and the lugs replaced by a “plug board” the algorithm remained the same, along with all it’s weaknesses… Even when put in software in 4 and 8 bit CPU systems or later micro controlers those old defective mechanical algorithms came along as “counters mod N” driving “lookup tables”… In part this happened due to “inventory costs” if you’ve invested a fortune in mechanical cipher systems you want your new shiny electronic systems to be compatible, likewise those that are CPU based. It’s the same old “legacy issue” that almost always works more for your enemy than it does for your security.

But acoustic side channels are known to be not the only ones. Even theoreticaly secure One Time Pad/Tape systems are practically insecure when implemented in machine form. The UK high level super encipherment machine known as Rockex used by the Diplomatic Wireless Service (DWS) and designed by Canadian engineer “Pat” Bailey suffered from this as I mentioned years ago on this blog. In essence the Pad/Tape “additive” was done in a circuit using Post Office Type 600 relays. Even though the open to close times could be adjusted there was always a slight time asymmetry that got out onto the telephone pair used to connect to the telex network. This time asymmetry could be used to determin the “addative” thus strip it off leaving the plaintext…

One solution to this is to use a “shift register” or secondary relay that “reclocked” the data signal so that the time asymmetry seen on the line was not that of the relay doing the encipherment, but the time asymmetry of the reclocking relay. In essence the contacts of the reclocking relay were “open” during the critical time period of the encipherment relay changed state.

Which in theory should have made it secure… But open relay contacts like open switch contacts can be “jumped” because in reality they are small value capacitors. This is what the “infinity device” was all about. It enabled you to put a high frequency signal on the telephone pair that would see the encryption relay change state through the open contacts of the reclocking relay… So you needed to add extra circuitry to prevent the time based side channel from the encryption relay being seen on the line. Thus leaving out that extra circuitry made a very secure system nearly totaly insecure to anyone with the appropriate device in line, yet it retained total data level compatability with it’s secure counterparts, so again no “red flag” waved.

I hope that answers some of your question.

Clive Robinson • February 13, 2020 4:43 AM

@ vas pup,

Is Proton mail (Switzerland) encrypted content is subject to direct access by ICs of US and Germany in the same way as well?

My advice applies to all applications with encryption in them irregardless of who or how they came to be.

Firstly I would assume that unless you generate and fully control the encryption keys, your encrypted content is at risk, from KeyMat loss/leak if not from National SigInt Agencies but others.

Secondly I would assume that unless you fully control the hardware and OS the application runs on your encrypted content is at risk via skiming and I/O shims, if not form National SigInt Agencirs but others.

Thirdly whilst we might be able to deal with “Known Knowns” and some “Unknown Knowns” the chances against “Unknown Unknowns” is probablistic and realy very low when you consider the number of new instancrs and classes of attack that brcome known each year.

So whatvto do?

Well as, you never realy have full control over modern hardware, or software, it’s a safe bet you don’t have control over any KeyMat. Thus you don’t have security irrespective of how trustworthy or otherwise the source of the application.

However if you have physical control and you have communications control you can potentially mitigate the loss of hardware, OS and App software.

In brief you segregate encryption from communication by encapsulating the encryption method inside a protected zone and ensure that data in and data out across the zone is only carried out over guarded channels. Also that the guarded plaintext channel(s) and the guarded ciphertext channel(s) can never crosstalk with each other at any time.

Whilst dealing with “out of band” covert channels is conceptually simple (energy gapping) The fly in the ointment is “inband covert channels” that can be added to data that goes across the guarded channels either as direct channels or as side channels.

Dealing with inband covert channels “in the data” is what the guards on the energy gapp crossing “guarded channels” are there for.

However the guards suffer from the “Unknown Knowns” and “Unknown Unknowns” issue every bit as much as the OS and App software does.

The only way to limit this is to use very simple data transmission protocols that are full understandable and controllable by an individual. Which are then sent in a time controled manner to reduce the bandwidth of any time based side channels as well as reduce trancparancy across the system from the plaintext side to the ciphertext side.

However even using plain 7bit ASCII with only three “white space” control chars alowed (CR, LF, Tab) does not stop “semantic” and similar covert side channels being introduced.

There are also other issues such as what you think of as a “oneway channel” becoming “twoway” due to “errors and omissions” that can then walk backwards through thr system such that a covert channel is formed from the ciphertext output to the plaintext input.

Just a few reasons why security is conceptually easy but practically very very hard and as history teaches us fraught with failure.

Clive Robinson • February 15, 2020 9:28 AM

@ SpaceLifeForm,

But, what happens to the Turing Tape when there is a cpu *under* the two cpus that allegedly can inspect RAM state?

Adding a third CPU, makes life more interesting. It depends on what it is doing…

Take Intel chips, the Memory Managment Unit (MMU) and surounding memory control systems are apparently “Turing complete”, thus appears,as a “ghost CPU” that many would not expect[1]. The knowledge of this compleatness has been around for about a decade now[2] and it has some real odd property’s about it which many programmers will not be able to get their head around without suitable assistence.

But programing tricks aside, that mechanism very probably has way more hardware issues tucked just out of sight of a clever mind.

But IAx86/x64 in it’s more recent forms has one or possibly two more CPU’s with what is called by some ad “Ring -3” access, one of which runs Minix[3].

In theory “Ring -3” gives you omnipotent “God status” over the CPU, which many would condider as bad as you could get… But no as I’ve mentioned before the real power depends on where you are in the computing stack… Ring -3 is actually quite high up the computing stack, and it is vulnerable, to low level omnipresent “Devil status” under all that those turing engines depend on those “tapes of instructions” we call “Memory”. If you have access at memory level or below on the computing stack, there is little you can not do –except stop attacks at lower stack levels– because like bubbles in a glass of champagne, such tiny tiny attacks “bubble up” getting bigger and more powerfull in an almost unstoppable way.

Which brings us around to the notion of “reach around/down” attacks. Most security protection in modern chips exists at the CPU or just below MMU level in the CPU stack, and both are critically dependent on the contents of memory at a lower level in the stack. What if you could find an attack that would run above the CPU ISA level stack in a compleatly unprivileged process, that could “reach around/below” the levels in the computing stack where we carry out security functions? Well RowHammer is a crude example of such an attack. It’s a fourteen pound lump hammer attack not a precision gamma knife type tool but it makes the point well enough.

When you think about it, there is no way to stop a “bubling up” attack, because there is always a lower level in the stack you have no control over, and you can not put security in at those low levels, as a security function requires a certain level of complexity that components at those low levels do not have…

Thus the only solution is by mitigation at a level that can support it (which is actually lower than a level that can support security).

To see why, take thr example of “tagging memory” with a crypto protected value. All that is required to store the crypto tag is more memory. However to generate the tag requires way more sophisticated logic that runs at a higher level. If someone uses RowHammer or similar “blut instrument” the probability they will modify the memory and it’s tag correctly is dependent on the size of the memory block and tag, but with a 128bit word and equally sized tag it’s vanishingly small.

The problem is that you will only know when an attack has been attempted when you read a memory block where the decrypted tag does not match. Compared to the memory read speed the time required to decrypt the tag and verify it would be glacial[4]. So it would be a significant bottleneck on performance.

Is there a way to keep the speed up atleast within an order of magnitude of the read speed?

Well yes there are ways, one of which is to use the advantages of parallel operating and compare results in a voting circuit. This has the advantage that it can be done at a point much further up the computing stack where memory read speed is in effect irrelevant. The trick is to know how to write code where it has larger “atomic functionality”.

I’ve discussed this in the past as @Thoth and one or two others know.

[1] I susspect the Intel IAx86 and later memory subsystems are another “gift that will keep giving”, that @Thoth will appreciate the irony of. That is it’s currently –as far as we know– an “Unknown Unknow” waiting to happen when researchers feal the need to make a name for themselves by proding a new nest of snakes in Intel chip internals. Which “my hinky sense” tells me it has the potential to make the likes of Meltdown and Spector look almost benign. So mark the date in your diary and see how long befor it becomes first one new instant in a new class of Intel CPU hardware vulnerabilities thus a single example of a “Known Known” at the start of a cascade of “Unknown Knowns” becoming “Known Knowns” as researchers churn out paper after papar with accompanying POC for the next five to eight years.

[2] Have a read of,

https://github.com/jbangert/trapcc/blob/master/README.md

Then put your mind in “thinking hinky mode”, there is an immense world of possibilities in a Turing complete engine that does not use “instructions” and won’t run in the usual “lab environment” emulators… If you have post Friday night brain fog, have a look at,

https://news.ycombinator.com/item?id=5261598

Then think again with post Saturday brain fog, heck better still think about it on the way to brain fog 😉

[3] https://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/

[4] In theory a stream cipher would only need two rows of XOR gates and a “zero detector” to grnerate an exception. The first row XORs the tag and the keystream, the second XORs the resulting plaintext and memory block and puts it into the zero detector which unfortunatly is not a “bit wide logical” but “word wide arithmetic” function which needs “carry”. But whilst that is slow compared to a memory read, there is as well the very slow issue of generating the key stream…

Clive Robinson • February 17, 2020 4:04 PM

@ vas pup,

The problem with neutrality is you have to have the power to enforce it.

If you don’t you will have to compromise, because that is the nature of “power politics” you are either “usefull” or “to be crushed under heal”.

Thus the question of “how to be usefull” to every psychopath who has desires of conquest?

Well Sweden had the same trouble and in part they sold balls for bearings to both sides whilst also spying for the side they most hoped would leave them alone.

You can go down the list.

The thing you will note is that neutral states are generaly small have a uniform population and are considered by many of their neighbours as “wealthy”.

The wealth is there because of two primary reasons,

1, They trade without discrimination.
2, They don’t waste resources on war.

The simple fact is war is realy all about “ego not profit” it’s always because some idiot “slaps it on the table” to prove they have the biggest / hardest / best / etc. Unfortunatly there is no profit in war for the combatants and any victory eventualy become pyrrhic. You might gain an Empire and it’s resources, but the cost of defending it? Or as the Spanish discovered vast amounts of gold and silver just makes prices go up, and the gold disapears faster. Worse those who have gold become lazy, their children fail to learn and when the gold runs out, they find they have nothing and know not what to do, and past glories do not put food on the table or crops in the soil.

Trading however is a useful skill it makes you usefull therefore important with those in power in other places, who have either the gold to pay you or other things you can usefully trade with others.

History teaches us that even when at war Germany and France traded iron and coal not directly but trade they did.

The secret to trading is knowledge, so much so that knowledge has become a commodity or even coin in it’s own right. The thing about knowledge as a resource is you can trade it more than once or twice, with skill you can trade it almost limitlessly…

But you can also use it in manufacturing to add value. A ton of coal limestone and ironore if used correctly will give you the much more valuable steel. Take steel add more coal for power to transform it correctly into a tool or product then it’s value is even higher. That “correctly” is the knowledge that adds the value, as long as your knowledge is better than others then you can not just profit by it but reinvest it in education to keep your knowledge ahead of others.

Thus if you want peace you have to trade and manufacture, but importantly you have to educate your population.

Some countries have realised that spending more on education than on bomb and bullets is a sensible policy. Sadly not everyone sees it that way as their egos will not let them. It’s a thought voting citizens should ponder, equitable peace and prosperity by education producing goods and trade or endless oppression by destroying others via tyrany blood shed and the breeding of illiterate cannon fodder by the masses untill all resources are gone and colapse happens?

Clive Robinson • February 17, 2020 7:14 PM

@ vas pup,

I guess the reverse is right as well…

Yes, but remember what George Orwell put in his politics “Room 101” book 1984. He had a list of criteria,

1, You should have an enemy in a far off place (he picked Asia).
2, Where the people are visably different.
3, So your civilians have someone easy to hate other than their,
4, Controling tyranical government.
5, That spies on their every moment.
6, That feeds them propaganda.
7, Via the means of television radio and all electronic communications.

For some strange reason he got the failing empire building government wrong… But hey 7/8 is way more than a good pass mark in predicting the future an average –for the time– life time away…

Clive Robinson • February 19, 2020 9:30 AM

@ ALL,

I know this is a bit late but anyone else remember,

The NSA Pown your HD

Apparently they’ve been doining it for most if not all of this century…

https://www.theregister.co.uk/2015/02/17/kaspersky_labs_equation_group/

It’s one of those things that @Nick P and myself used to warn people about fairly regularly.

It was also part of our debate over how old hardware would have to be not to have “Hidden Flash” in IO that could be exploited. @Bick P favoured “mid naughties” and I favoured “mid nineties” as the cut off points.

This issue is getting realy bad as hardware that will except any update no matter how untrust worthy and addled it might be has come up yet again this week,

https://eclypsium.com/2020/2/18/unsigned-peripheral-firmware/