Schneier on Security

Clive Robinson • July 18, 2015 7:02 AM

@ name.witheld…,

My advice is for your friend to “carry on as normal” and let people know he’s going fishing or hiking or some such holiday activity, where not having a phone let alone a computer would not raise suspicions. Prior to you doing any active investigation of the devices. Thus if anything does go wrong then someone can chuck a brick through his back door window etc for him to find he’s been burgled and the laptop etc stolen whilst he was away… That provides him with cover to go get a new laptop if the old one can not be properly fixed. Something that I suspect is very likely to be the case.

In the unlikely event there is stuff on it your friend needs to keep I would pull it off file by file and do statistical checking for “embeded code” and format violations. If possible convert file content to “ASCII plain text” to strip off all formating, then copy onto a new platform and manually rebuild the formating if required [1].

Another way if the stuff is archival is “print off and scan as an image on a new machine”, yes it makes very large image files and uses up half a forest, but unless there are barcode / QR code or similar in them then malware is not likely to get transmitted that way [2]

As I’ve indicated in the past “I lead a terminal life” and whilst old fashioned kit and the command line is not quite the “Moscow State typewriter revival” that’s been in the security news, it does give a very small and easier to audit compiler independent code base. Importantly it makes the use of “air gapping” much easier and (outside of TEMPEST considerations) more reliable.

Using two machines seperated by a decent “guard” is the way to go, with the “off line” machine being an old PC with DVD drives and no hard drives or other mutable storage. ASCII plaintext File transfer across serial lines via Xmodem or similar is simple to do. Further making a “Serial line Guard” is something that can be done using low cost SoC development kits. The cheapest way to do this used to be the Microchip Pickit16 development board, which allowed the high end SoC to be easily removed and “locked in a safe” and importantly had a “board extender bus” and peripherals you could buy to do all sorts of stuff. You also had the choice of doing assembler or C code development quite easily with plenty of code libraries you could download and use. I developed a number of “Serial Guards” etc on it.

As a general note, there are also several other things people should consider doing as standard –irrespective of what they do or have done for a living or hobby– that will in the long term make their lives easier,

Much though I hate it the original FAT12&16 disk formating are unencumbered by patents etc, are widely recognised and consequently turn up in all sorts of places as standard. Especialy in places where SD memory cards are found like embedded systems for camera’s, smart phones, your car satnav, digital instruments such as test kit, musical instruments, medical and industrial systems. Many of these systems have the ability to use a “command line” or atleast display ASCII plain text files. Thus using such a file system format especialy for archiving, backups etc is applying a sensible level of future proofing, that other file systems just don’t have.

[1] Storing all user created files in an “ASCII plain text” format such as RTF, CSV, HTML, etc, is likewsis a good working habit to develop. Not just because the files are a lot smaller, have less oportunities for nasties to hide and are consequently easier to check and transfer from one system to another. But because it acts as future proofing alowing easy migration to other apps and platforms in the future, and should files get corupted it’s usually easier to recover / rebuild them in part if not whole.

[2] As I frequently tell people that get hit with certain problems “Paper Paper, Never Data”, you see exactly what you are giving to people, and there are no nasty meta-data suprises waiting to be discovered. As well as sanitizing meta-data it should also sanitize most malware etc that might be hidden in a file in various ways like MS’s ill thought out “Object Linking and Embedding”, macros and other “productivity” nasties. Further a little adept use of a scalpel / craft knife makes redacting a “whole” lot more reliable. You can then put the pages in a file cabinate for long term archiving or scan them back in as bitmap image files that you can then later OCR if you require.

Also much as many people hate it, writing “plain text” programs for interpreters like early BASIC’s are another way to future proof code. Compilers come and go and each one has “productivity features” that stop code migration deader than a “dodo kebab”. Even javascript if “written to be readable” in a subset of it’s common features is more future proof than most production C or other code. Likewise if you want to future proof code, don’t use assembler or non published (as international standards in paper form) code libraries etc. And remember just as with surgery “a quick hack, usually gives longterm pain or loss of function and frequently both”.

For my sins I still have amongst many others an Xmodem program I wrote in AppleBasic for the Apple ][ and it’s serial card. I later rewrote it in BBC “B” BASIC and several othe 8 and 16 bit computers that ran BASIC natively. The only real changes were “fluff code” for fancy screen handeling and the low and dirty code for the serial hardware. And like a dog with a favourite bone I still use it some thirty five years later (even rewriting a BASIC interpreter I have in K&R C in ANSI for a SoC microcontroller, to use it on that a couple of years ago…). The nice thing about having a BASIC or similar interpreter in C or other compiled language, is that making specialised additions to an interpreter are much much easier than to a compiler. The Tool Control Language (TCL) is a “higher level” idea in the same vein and can easily be added to other compiled programs.

Clive Robinson • July 18, 2015 8:24 AM

@ ALL

Although the hacking of “The hacking Team” has caused much amusment it has also caused harm to others as well.

Though most computer security personnel quite rightly say that Adobe Flash should have been put out of everybodies missery some years ago, it is still in major use by very many people. Thus the release of atleast three “zero-days” from the hack, which have now been quickly added to several other RATs and attack tools is activly hurting people today.

But it gets worse, as some know the US is activly trying to get new export rules under the Wassenaar Agrement where amongst other technology cyber defense tools will get classified like nuclear technology and thus require licences to even talk about them in companies to other “foreign born” staff, students and even expert researchers…

Basicaly as always with such lawmaking, the basic premise is wrong, thd scope overly broad, and wording and meaning ill defined so that just about anything could be argued by a smart mouthed prosecutor as being covered. And thus will bring considerable harm not benift, and in the process weaken everybodies computer security.

The big problem is that the rules as written take no account that technology is agnostic to use and in the case of safety/security often urgently. Thus in trying to prevent “bad use” they “ban the technology” and thus “all use” outside what they consider “trusted people” and thus stop the rather more important “good use” by far the majority of people that need to use it often quite urgently. Because to become a “trusted person” takes considerable time and has to be done anew each time a slight variation or improvment is required.

The new rules are not yet cast in stone, but the recent hack makes a much stronger political case for them, or making them even more draconian. Thus people need to not just give voice but actually do so in the correct method to cause these rules to be changed.

You can read more about this at,

http://www.wired.com/2015/07/moussouris-wassenaar-open-comment-period/

Clive Robinson • July 19, 2015 4:40 PM

@ Comment,

Password Safe, might not have the features of other password managers, but it works more than adequately at the User Interface for it’s intended purpose.

Now I have no reason currently to think “Two Fish” is broken, it might be it might not, however it is getting to the point where there are more uptodate and even standard algorithms available.

So adding new algorithms might be sensible from one view point but not from some others. The reason for this is whilst algorithms may be considered secure their practical implementations often are not (the classic case being the AES winner). Thus time based side channels amongst many other things now need to be considered in the design of any practical password manager.

Personaly I would prefer to see several algorithms included such as all the AES competition finalists and a configuration method included that allowed a user to select their choice of one or more algorithms in a chain (think about how 3DES improved DES).

It would also be nice to do one or two other things from the command line, to take further advantage of the work involved in providing updated algorithms. However care would have to be taken to prevent any increase in functionality making information leakage more likely.

Clive Robinson • July 20, 2015 5:14 AM

@ Is Small Better,

In general, is a small mobile device with an 4″ LCD screen more secure from TEMPEST type attacks than a desktop system with a 21″ LCD monitor?

Firstlty TEMPEST is to do with generalised “Emission Security” not a whole bunch of other things you also have to worry about as well.

There are several things required for a “useful” signal to be emmitted. Firstly, the signal must have sufficient bandwidth for the information and the carrier it is impressed upon. Secondly their must be a physical medium by which the carrier can leave the device. Thirdly the carrier must have sufficient energy to be detectable above the natural and other noise floor at the distance the receiver is from the emitting device.

If you look at Nyquist and the later Hartly-Shannon theorms you will get the base physics on this.

At a more fundemental level we have matter and energy being equivalent (E=MC^2) and subject to forces by which they interact with each other. However they are both “conserved” and due to the various mechanisms such as “radiation transport” the energy becomes disapated and drops to a background level which is why we can detect microwave energy from the time of the big bang some 14 billion years ago. Such cosmic signals cover the entire electromagnetic spectrum and give the ultimate noise floor.

However even when a carrier of information has sufficient energy it needs to be coupled into and back from the channel medium. You can look the physics up but the lower the frequency of a carrier the larger the matter of the coupling mechanism needs to be. The basic idea is an “isotropic radiator” pushes signals out in all directions equally and thus it can be seen that the signal energy drops by the square of the distance when considered as a wavefront and by the cube of the distance when considered against the volume of space it occupies, which thus effects the shape of the coupling device . However as we know from optics when considered as a wave energy can be focused, but the amount of focusing is dependent on the “effective area” of the coupling mechanism divided by the wavelength of the frequency involved.

Thus the higher the frequency the easier it is for any given effective area to radiate in a given direction.

So the smaller any device the smaller any “effective area” can be, but the higher the frequency the more effective a given area will be.

Oh and the greater the frequency of any given carrier the wider the bandwidth of information that can realisticaly be impressed upon it.

So the bigger the device, the more energy it uses and the higher it’s operational frequency, the more likely it is to emitt “compromising eminations”.

Unless of course you take precautions during the design to reduce the bandwidth, energy, frequency and area, then of course keep the energy “bottled up” by sheilding, which has it’s own problems unless you take care to manage it with absorbers that convert it to heat and transport it away by a very low bandwidth channel…

Clive Robinson • July 20, 2015 6:15 AM

@ Anura,

Even the best attack against DES requires 2^43 known plaintexts – although the key itself is weak enough to be brute forcible (56-bits), even then your weak point is much more likely to be the passphrase.

True but those are not the attack vectors I want the crypto to deal with. Algorithmic / certification and brut force attacks whilst possible are low on my list. What I’m concerned about are algorithm implementation attacks, such as time based side channels which are relativly trivial to use in comparison.

There are ways you can split algorithms up and randomize their execution order to make power signiture attacks as dificult as certification or brut force attacks. The more crypto algorithms you chain the harder an attackers problem becomes, and within reason the easier the randomization. That is it in effect exhibits similar properties to a one way function.

Clive Robinson • July 22, 2015 9:35 AM

@ MarkH and others,

The point I was making was the “trade off” between the complexity of the backdoor and the complexity of the attackers receiver.

Whilst not a zero sum game, simplisticaly there is a level of complexity that needs to be achieved to “passively” get meaningful data from a CPU. Interestingly is that the more complexity you put in the CPU the tighter it’s scope or focus and the less use it is to wn attacker.

For instance assume a new CPU in the upper end of an existing CPU family gets the addition of a fast hardware multiplier and other DSP related stuff. You might decide instead of backdooring the ALU, you would get better results if you backdoor the multiplier (in a similar way). On the theory that all “real world” analog signals and PubKey crypto will get “off loaded” onto the fast multiplier. However the code writer might not be that interested in cutting new code for the fast multiplier when they already have adequate PubKey code they know works in a library from an earlier CPU, and use that rather than going through the grief of trying to get it working in an interleaved way with DSP functions processing audio.

Likewise backdooring an AES functional block is not going to help if some other crypto algorithm is used as well or instead of AES (just another reason I like cipher chaining).

Thus the more complex a processor chip, the more difficult it is to make passive backdoors. That is you can not backdoor all parts because the process by which you get the signal out would end up interfering with each other.

Further shielding alone is insufficient to stop backdoors being effective. You could for instance “phase modulate” the edges of data signals, to superimpose a Spread Spectrum like signal either as a “watermark” or lower bandwidth communications channel. As long as the data sent was relativly short and did not change it could be sent over and over again such that even the slowest changes of edges on a data output signal would eventually get the data out. This is one of the important reasons why you must always “re-clock” data outputs with a known to be good clock signal and fail hard and long on any error.

However the backdoors that worry the military are not those that emit signals but those susceptable to external signals aimed at the CPU.

Again a simple example would be a digital matched filter of two hundred or more bits. When the correct digital sequence is received the matched filter outputs a pulse, that could be used to do all manner of things, one of which could be to invert the meaning of the carry, zero or sign flags for the next operation. Or more subtly change a shift from logical to arithmetic, or add with carry to one without.

If the matched filter accidently got triggered it would be put down to meta-stability, gama radiation, or other very infrequent soft fault, or even a software bug, not a backdoor.

Thus it would only be under times of attack that such a backdoor would become visable, but with care by the attacker not obvious.

The thing about matched filters, is you can invert them and turn them into matchea correlators fairly easily, thus all inputs to the chip can be used for such an attack. The enemy simply broadcasts the corelation code repeatedly untill a match happens. Certain linear codes work if if they are subsampled etc.

Clive Robinson • July 31, 2015 5:22 AM

@ Figureitout,

Contrary to what a lot of people say who probably haven’t tried attacking much stuff, I’m a believer in obscurity (when it really matters for the worst attackers)…

Obscurity only works when the attacker is working in a vacuum and the possible options are practicaly –not mathmatically– infinite.

Have a look at the history of breaking the Enigma, how each step forward was based on known information on the system. Starting from nothing would never have worked but each only just climbable mountain you conquer makes that next impossible mountain just climbable, so on and so on till Everest becomes peoples two week holiday or boy scout trip.

The thing is that knowledge of what a target has done before, tells you what they have invested in and that makes the moutain climbable.

Have a look at the history of satellite TV and stopping “free loaders” obscurity failed. One example was Sky, the made a new box, not only did they have unidetifiable info printed on the chip they also got the chip manufacturer to change the pins around and swap chip level functionality around by changing the metal layers. A lot of obscurity… It failed miserably one cracker took three weeks to break it. Because he knew they could not have re-designed the actuall system due to legacy boxes, he knew they would not write the code from scratch, therefore the internal CPU would be the same, getting at the code was a game of probing the pins for electrical differences (program line having a higher voltage than Vcc did not have substrate diode so could be found with a multimeter). Likewise other lines had give away charecteristics, each pin solved reduced the problem greatly to the point a little experimentation gave forth the internal code, it was simply a case of match sections of code and find the differences, once found then disassemble and reverse engineer, and make a work around then sell it… Three weeks work of “no pay” to be the kid on the block that everybody wants to give money to.

Also study how the Xbox got broken despite Micro$haft obsfication and cryptography.

If there is money behind striping the obsfication it will be done in less time than it took for you to do it in the first place.

The lesson is you have to develop in a vacuum, everything has to be new, no history and the bar has to be so high that no existing technology can get people up close let alone over it.

The problem is there is never going to be a sufficient technology gap, the market does not alow it as all the profit is in that gap.

Thus obscurity only works for one off or very limited effectivly obscure products with only tiny markets with little profit in them.

I know the serial guards I use to reduce the chances of malware attacks on “air gap crossing” work by what is effectivly obscurity, but then all guards do, and I also know they have software or design bugs that could be exploited, but again they all do.

The advantage I have over the $10,000 and up comercial models is mine are obscure very obscure, they are not available to others except by a black bag job. This makes the job of a potential attacker much much harder as they don’t have one on their test bench. Thus they have to probe, and they don’t know what I’m scanning for and how, thus I have a reasonable chance of seeing them coming and change things to protect the node systems.

I’m not overly worried about a black bag job, if they mount one it probably won’t be against the guards but the node information stores, and they will leave traces which ever they go for any way, which is why black bag jobs are hardly used these days, when supply chain poisoning or insider attacks are so much easier.

And before you mention the $5 wrench, nobody knows what the crypto keys are and no one person knows what the other shares are. It’s not compleatly invulnerable but sufficient for the value of the information / task that any attacks will be made at a different point in the overal system not this node of it. The information is short lived and does not stay in the node stores very long, once it’s moved on it’s not the node’s or my problem any more. However even if they did get into the node stores the information is always at rest in an encrypted form any way, it comes in that way and goes out that way it’s not decrypted by this node in the system. the only direct information the would get is when it came in and it’s size and a service identifier by which it gets pulled out by other nodes. All of which an attacker would have got by watching the wire into the node any way. By infrence of it not being in store they could see it had moved on but not by who or when it was pulled out.

When the number of users is limited pull systems are easier to secure than push systems, a nugget of information you might find usefull one day.