Schneier on Security

Clive Robinson • April 5, 2016 3:56 PM

For those moaning about Wired's Ad-block nonsense, there is someyhing else you can add,

The standard of Editing is crap.

If some one as poor at the niceties of the written word as I am can not just spot it but be annoyed at it, then it must be bad for an article to have come from a traditional press background.

It maybe they have sacked the Sub's etc, in which case I would not subscribe to them. As not only are you not getting your monies-worth, the chances are they are not going to be in existance much longer. As it appears that the directors etc at the parent wield the financial axe, in the poitless pursuit of ever more profit from the printed media.

For those that do not get it the profit in the printed word is very much in the decline. New or increased profit from the printed word is only likely to happen from "captured audiences" that "are required to buy" for various reasons. General Magazines and Newspapers are waking up to this as their demographic audience heads towards retirment if not it's century and online media has hurt their business model. Similar things have happened in the general fiction etc where traditional outlets such as bookshops are getting undercut by supermarket checkout displays, not just the likes of Amazon...

Any way Wired appears to be having lot's of troubles one way or the other, so maybe their anti ad-blocking, will go the way of the dinosaur along with them fairly soon.

Clive Robinson • April 5, 2016 4:40 PM

One thing that is not quite right in the Wired story is about people using Open Source Software to develop their own authority avoiding crypto.

Whilst in theory you can develop your own code, it will only work on Open Platforms... For those to young to remember or possibly even know, the early mega expensive days of computing were all "tied systems" which we know call "walled gardens". It was the entry in the mid to late 1970's of 8bit single chip CPUs like the 6502, 6800, 8080 and Z80 that enabled "Personal Computing" to start. Apple with the Apple ][ set a trend for Open Hardware with it's I/O Peripheral Bus by publishing the specification (which got Microsft going with their Z80 CPM card).

Whilst the OS's were quite primative CP/M set a standard cross platform software interface. This ended up as an almost direct copy for 16bit Ia86 processors and formed what became MS-Dos from Microsoft. Since then little by little the commercial OS's even though looking open have been moving back towards the closed model.

This is one of the battles going on you don't tend to hear as much about when we talk of Privacy, in fact some people have tried selling "walled gardens" as a positive for privacy... Through the likes of TPM controled by not the system owner but Software companies and Digital Media companies.

I can see a time when "Open Platforms" are effectively dead for the majority of people. We can already see this with Smart Phones and Pads and quite a few named brand computers and their motherboards.

So having "walled gardens" might have be great up till now for the OS owners... As they are now finding they arein fact bad news for those who want some kind of Privacy, but also the OS owners when the FEDs and their shabby ilk come calling demanding considerably more than the law alows via their NSLs FISA court warrants etc etc.

There is a saying that "Security is hard" well trust me it's a "walk in the park" compared to where Privacy is rather rapidly heading.

It's clear from the Wired Article that even "technical journalists" working in a technology press just don't get it yet... The question is do the actual technical people designing systems "get it" well to be honest I realy don't think they do either... Which has left a large window of opportunity for the various IC and LEA organisations to put preasure onto the elected legislators and career civil servants working in the formation of legislation. Thus whilst the future is actually looking bright for the IC and LEAs the future for the rest of us is rather rapidly "going dark".

Clive Robinson • April 5, 2016 6:19 PM

There are many technical layers to Privacy in Communications.

Some are thousands of years old some from as late as the end of the twentieth century.

One that is as old as the earliest of codes and just gets harder with time is what we now call Key Managment (KeyMan) it is still an unsolved problem and may never be properly solved. Whilst much has been done as others have noted above there is the remaining issue of "First Contact" where the initial secret is exchanged. If an attacker can get in on this channel then it's effectively game over.

However a problem from more recent times that arguably is the result of the "mobile generation" is "finding end points".

Back in the days of the Plain Old Telephone System (POTS) and Radio Broadcasts, communications were either full duplex Circuit Switched through network nodes (POTS exchanges / Central Officed) or effectivly nodless with wide area half duplex broadcast to any radio that was tuned in to the transmiters frequency. Thus end point location was either fixed and known (networked) or not known and did not need to be fixed, just in range (broadcast).

The advent of the internet did not actually change the end point issue, just the way traffic was carried. That is it went from circuit switching of known fixed end points to packet switching of known fixed end points, with a fiddle in the "physical layer" to alow limited broadcasting to solve the "discovery issue", and that's pretty much the way it's stayed in the IPv4 and 6 world.

The advent of the later "Mobile Phone" networks brought with it a major change that is still being sorted out today, which is how to manage fully mobile end points that can attach to any of the fixed network leaf nodes and in fact move from leaf node to leaf node.

The world of Internet of Things (IoT) is going to make this mobile end point problem even harder, as it will not just be the end points hanging off of fixed leaf nodes, but end points hanging of mobile node points in an unfixed thus ever changing network topologies.

All mobile end point systems suffer from the various "discovery problems" from the simple issue of how the endpoints find out where they are to the complex and possibly unsolvable issue of end points discovering where other end points are reliably and sufficiently quickly.

The currently favourd way for end points to discover each other is for an end point to discover where it is and report that back to a fixed central database which can be queried by other end points. Whilst it works to a certain extent it is quite fragile and is a security nightmare even on --supposadly-- trusted networks. It also generates a huge amount of administration traffic, which can quickly grow beyond channel capacity required for data traffic.

Mobile Phone networks have a "half way house cludge" to partialy solve the problems by having regionaly distributed databases. In essence when you turn your mobile on it then "registers" with the network at that leaf node and this gets passed up from database to database up the intervening nodes to the central database. When you move however your position information is only changed in the leaf node databases not the central database, the further you move the further up the regional hierarchy your movment data is reported. Thus when another end point wishes to communicate, just like the DNS system it works it's way up the hierarchy looking for the location and if it gets to the central or root database it then works it's way down untill the location information is resolved. Unless of course the end point has moved or become out of range etc, in which case local regional tree spanning may resolve the new location. However due to traffic issues the tree spanning only happens for first class traffic (calls) and will fail if the end point has moved to far.

The admin traffic and spanning issues get worse the smaller the coverage area of any leaf node and become impractical below a certain area size and rate of node change metric. These problems become exponentialy worse as the routing nodes become mobile...

From a surveillance point of view be it for advertising revenue or bulk interception the discovery mechanism is the most vital part of obtaining meta data. Thus they do not want any end point movment or end point to end point communication to go unnoticed, which means that either the level of admin traffic to the central root database has to rise or they have to monitor at smaller regional points and carry the traffic themselves to their tracking databases. Either way "collect it all" becomes an avalanch of data descending onto their heads.

But the fundemental issue of networks becoming "discovery limited" still arises at some point even for fixed networks. How discovery will work with partialy or fully unfixed routing nodes is one of those "open questions" that wake some of those who's job it is to solve the problem in a cold sweat. And that's before you start considering the trust and resulting security issues...

The thing is that currently WhatsApp and similar services are using a fixed network central or large regional database model that will neither scale or cope with an unfixed network. They will if meta-data collection is their game, not want to change that model unless they can also change the revenue model... But whatever they do the system will still become both fragile and unwelcome to carriers that have to carry the admin traffic, and increasingly prey to attackers of various forms.

Clive Robinson • April 6, 2016 6:28 AM

@ Nick,

But if you really want to be secure, you shouldn't run your applications under any proprietary operating system

Whilst in theory your own proprietary OS is more secure because you are denying your attacker information, the chances are you can not avoid an attacker getting the code if you connect it up to an accessable network. At which point the advantage vanishes. Whilst I would agree that the latest version of Windows is malware, it probably does not have NSA backdoors, because they get the source code and will find sufficient bugs for their purpose anyway. What I would say --and have-- is that Win10 is Jim Comey's "front door" due to the way Micro$haft get it to "dial home" almost continuously and presumably store on their servers for various reasons such as selling it to the advertising business. But for many a commercial OS and Application is all they can do, which is why they need to consider how you issolate the system via the old "air gap" or more modern "energy gap".

You also shouldn't run confidential applications on any device that contains an enabled cellphone modem

There are cellphone modems and then there are embbeded cellphone modems, then there are CPU sharing cellphone modems.

Originally all celephone modems were entirely seperate and used some kind of serial communications (RS232/USB) and talked a variation of the old Hayes AT command set. These you could simply "unplug" however manufacturing price reduction put the modems first on the PCB then removed the serial interface, then shared the devices CPU to control the modem, just as it had with the old POTS modems.

At each step along that integration path the user had less and less control. However in Smart Phones the radio interface is "shared" and thus tight integration was there from day one as the phone came first and the smarts were added later. There are standards that require phones --but not modems-- to have certain "safety features-- inherited from the old POTS system which enable variois features to be remotely enabled. But in addition in a phone the SIM in the radio interface has primacy over the overall phone, thus the Over The Air update system can be missused when the CPU is shared or as is quite often the case the network provider wants in on the smart functionality for revenue protection reasons.

Thus there are no "hard and fast" rules to give, they are all conditional on the design of the device at hand and the applicable standards...

A war story :- many years ago I was involved with the design of phones for various well know companies. One of my colleagues had taken one of the latest designs I had designed parts of the hardware and all of the software off for approvals testing with the customer who was a major telco. When he came back almost the first thing he said to me was "Did you check it against the PABX standard XXX?" to which I replied "No I didn't know it had to be!!!". A conversation then followed where my colleague said it was a suprise to him as well, but he explained what the customers engineers had said why it should apply then and my colleague sensing my distress finally said "Don't worry about it, it passed anyway".... Leason learned for the next time.

Clive Robinson • April 6, 2016 7:14 AM

@ Charles, Arthur,

In my own little world, I think this is a step forward in communications, if what they claim is true.

It's the conditonal that is the sting in the tail ;-)

I tend to look at it as "They have made it easier to be off the radar", that is if they have told the truth, they have given the NSA et al a whole heap of hard work anf "forever storage" issues. If they have lied or the NSA et al or Micro$haft etc have got an end point exploit running on your device your traffic is insecure. Thus it is safer to assume the change makes no difference to your actuall comms security.

Which means take your crypto "off device" by moving it beyond any end point vulnerabilities in your device or it's software. Oh and where you can Codes which look like plaintext are preferable to ciphers that look like random noise or five letter groupings, provided of course that the Code security is sufficient.

Clive Robinson • April 6, 2016 2:52 PM

@ Jason,

The major security vulnerabilities are in the endpoints, the phones themselves.

Yes but the work factor and risk for the likes of the NSA et al goes up considerably by attacking end points.

Also those with real privacy needs should now know that the likes of electronic communications end points can not be realisticaly be made secure.

That is there are "end run" attacks whereby shims in the device I/O will get around any security an App may offer, further the walled gardens most comms devices have become stops user generated apps being installed, so apps can not be trusted either.

The solution is to extend the security beyond the comms end point to another device / system with the user being inside the security chain between the comms end point and the security end point device / system.

Which by the way I've been saying for nearly two decades with autheticating financial transactions, which most consider significantly private activities.

Clive Robinson • April 6, 2016 3:38 PM

@ Charles,

I wasn't saying they lied. It's just that they may not have disclosed all the new lawful compliance features given the ubiqiutous, convenient requirements of instant messaging.

No you didn't but it's a reasonable assumption to make along with the end run attacks, when you are assessing your own security. It's part of the "Trust nobody or no thing untill you have good reason to" OpSec mentality.

Clive Robinson • April 7, 2016 3:13 AM

@ Slime Mould...,

I learned this by reconstructing shredded documents.

That alone sounds like a story worthy of a couple of drinks if not a dinner ;-)

As for a "spelkchexer" I only treat them as malware when they get up my nose by not having the words I need in them...

I've made the mistake of updating this andoid phone, which previously had an underlining spell checker and reasonable behaviour at the start of paragraphs... Now it has turned the underlining off (although the function is still there) and added a ludicrous behaviour at the start of paragraphs unless you put in a space first... I'm sure in both cases a change to a config file will resolve the issues, but for some reason the developers have not provided a "user interface" to them. I'm guessing that having now said this somebody will hunt out the answers and post a link or whatever, to show it's me not the Android developers that are at fault ;-)

With regards to the OTP, yes you can use almanacs in that way but you have to be very careful. As it's a "known method" in this day and age it's likely to be checked automaticaly by the likes of the NSA, GCHQ et al who would have digitized any almanacs they could get there hands on.

However lets assume that AES256-CTR is crypto secure and you have a memorable pass phrase to generate the AES key, you could have a usable CS-OTP printed out at either end if you could have a way to match the IV's. Thus you could select the IV from an almanac using an appropriate indicator group within the sent crypto message.

Such things have been known to work... However if it was me I would use two compleatly diferent crypto algorithms run in CTR mode with two different IVs and combine the outputs in some way to print the pad out. Which is similar to the old argument that using four or more books to make a pad with will sufficiently flatten the statistics.

As I've indicated before, there is an argument about the onewayness of determanistic algorithms that can be used to combine determanistic streams of data to form the equivalent of a One Time Pad.

It arises from another earlier argument back in the 1990s about CS-PRNGs running at high speed getting an occasional nudge from a TRNG. That is at what point would the output be indistinguishable from a TRNG running at the same full speed? Which is a very similar argument about entropy pools and multiple low quality TRNGs.

Thus arises a philosophical question as to just how much entropy is realy needed in a "master secret"...

Clive Robinson • April 8, 2016 3:07 AM

@ Rolf Weber,

You cannot have both the security of properly implemented end-to-end encryption and the convenience of cloud-based services.

If you think that faux assumption is valid your entire argument is likewise false.

Perhaps you had better try and explain why you think it should be axiomatic when clearly many others do not.

Clive Robinson • April 8, 2016 5:46 AM

@ Rolf Webber,

Then please explain me, for example:

Those are irrelevant niceties, not insurmountable hurdles, and in absolutely no way make your faux assumption anything close to axiomatic. Thus your overall argument fails.

At best it's a sociological debating point but not a technical, legal or any other argument.

If you do not understand that then perhaps you need to join the Obama school of thought, which most hard scientists and mathmaticians know is just a delusional happy clappy view of someone who things the writ of man can bend the universe to it's logicaly inconsistant view point.

Clive Robinson • April 10, 2016 9:24 AM

@ Wael,

In other words, this means the communication channel is protected against MiTM attacks (active and passive.)

Yup that's about the short and the long of it and has been since before Claude Shannon did his "secret" take on comms channels.

With regards,

It says nothing about: Data at rest, data in use, subversion, malware, key loggers, HW weaknesses, side channel attacks, social engineering, or other 'Men in the Middle' mechanisms[1].

That's what "End Run Attacks" and "Energy / Air Gapping" deals with, and from my point of view is by far the harder task.

It's why I've suggested that the use of "paper and pencil" One Time Pads is actually something people should think seriously about.

The problems with True OTPs are KeyGen and KeyMan of the KeyMat.

Which is why CS-Pads might be an answer (ie a Crypto Secure algorithm used as the Stream Generator is printed onto paper).

The problem with CS-Pads is of course they are determanistic thus lack past and future secrecy in most cases. The question then becomes how do you get these desirable charecteristics back. One way to nearly do it is to consider something like AES-CTR which in effect has three secrets the AES Key the register seed/IV and the register update algorithm (for standard CTR this is assumed to be just a single step increment, though incrementing by a large relativly prime number works just fine).

Thus the question then moves to how to generate these three secrets and communicate them in a way which they cannot be recovered. The simplest solution is to use a True OTP and manually enter them into the KeyGen system. However the ideas behind Perfect Forward Secrecy could also be used but at what would be much higher risk (ie your points come back into play).

The ways and means of implementing such ideas securely is in effect multidisciplined, but I feel it's something that should be investigated as a way to obviate the impending legislation from Fraudstien in the US and Theresa "Noway" May in the UK.

I'm sure that @Thoth could give an indication of which Smart Cards could be used as HSMs to be used as secure KeyGen's in a dongle or some such.