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 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.