On the subject of encryption that’s getting so much press, one of my friends asked me what the PM was thinking. While we don’t actually call each other up and thus I have no idea what’s she’s thinking at any given moment, I may have an idea of how she’s thinking:

Simply put I suspect it’s a call for options. When you come up against an intractable problem you begin with an impossible answer. It’s an old methodology.  One that most of us were taught in school because we grew up before we could Google for everything. To get people out of their comfort zone you have to push them in unreasonable directions. I expected various technology groups to come up with options but so far all we have is people screaming and making a lot of noise.

One of the best ways to stop insurgents operating in this or any country is to disrupt communications – that’s hard to do because of encryption.

Encryption is the mainstay of much of geopolitics, commerce and humanity from the dawn of the common era. It’s is a boon and a curse. Over the last fifty years we have become extremely dependent on it and its usefulness. However, all these technologies of today were invented in isolation from reality in a past sure of the goodness of all men.

The problem is that those charged with developing these protocols have become used to the constraints of the technology and we need to think beyond them. At one time these technologies were the privilege of the developed world. However as ubiquitous technology opens the doors to more and more people our enemies use these techniques against us. The answer so far from the technology community is “it can’t be done”, where “it” refers to back doors in encryption. That’s not an acceptable answer because it’s not addressing the question.

When the government drafts an outrageous bills it’s looking for constructive responses. It’s asking for more effort from the subject matter experts to evaluate the real objectives.

The very idea of encryption is because we don’t trust anyone. Thus it’s impossible to accept that we should allow those who work against us to use our own technology against us.

While the ultimate decryption key is a sharp knife to a nerve cluster, that kind of behavior applied wholesale leads to a dark and dismal future and isn’t always a viable option. We’re still waiting for our technology experts to come up with an answer but many seem so enamored with their toys they can’t see past them.

Encryption is a tool.

A tool is used to execute an answer to a question.

The question is Security.

Isn’t it?

There’s an interesting blog post by Mythic Beasts on why encryption is vital. They seem to be missing the point. Everyone knows encryption is vital to the continued economic deliverable of the Internet as well as basic technology security.  While this blog post is an obvious political statement, we were rather hoping for options. Turning around and telling the wider society that the cat is out of the bag and that’s just tough is a stupid and arrogant thing to do. We’ve unleashed this double edged sword and we can’t put it back in the sheath but we must have more of an answer if we’re not to look like complete idiots to the rest of society. Like a child that spills their milk but just pouts and won’t clean it up.

When we look for an unreasonable answer this kind of response isn’t wan’t we’re expecting from people who should know better how to handle intractable problems.

So far there’s been little option provided which seems to suggest everyone is happy with the knife and nerves option.

Which is dumb.

So here, in clear and plain terms, is the question:

Given that encryption is easy to acquire and utilize, given our enemies have the access to same technologies as us, what are the options available to our society to ensure we are able to disrupt encrypted command and communication channels our enemies use whilst maintaining our freedoms to use it?

We all know we can’t put the cat back in the bag. I refuse to believe that a trillion dollar discipline such as ours can’t come up with some feasible answers that don’t involve the road to perdition.

If this is too tough a question for us, perhaps we’re not really worth the fuss.

WIRED reports this morning that

ALL UNITED AIRLINES flights in the US were grounded this morning for nearly an hour, over “dispatching information.”

There’s much speculation around the possibility of erroneous flight plans being generated by the flight planning system and even a tweet about a possible hack of the system.

Tweet of message from Ted Benson

Whatever the cause, there exists today a silent but growing problem upon which little thought is being spent. Ours is a world of increasing reliance on electronic systems that orchestrate more and more of our lives. These electronic systems govern many safety critical functions and are driven to automatic and autonomic operation by data. While there is much made of Data Science and it’s disciplined application to drive greater revenue and safer interactions between man and machine, we are forgetting the much bigger and deeper field of Information Science.

The thing is that data is only part of the picture and in our ever increasing dependance on automatic and autonomic systems we’re going to have to make sure we take a holistic look at how we and our machines compose the ever growing amount of data into usable and trustable  information. Data Science is the discipline of extracting knowledge from data. But, there is a difference between having knowledge and knowing it. Knowledge is the accepted inferences made from data. Knowing is the ability to understand the full context and veracity of the knowledge in relation to the wider system within which the knowledge is embedded. It’s the ability to trust the knowledge that you or your machines have inferred.

This knowing begins with being able to trust your data. To be able to unequivocally assure all components of the system that the data it is being provided is what it say’s it is and is from where it says it’s from – at least. Each use-case will have more to add to the definition of trusted data but all use-cases need to be able to verify these two basic facts. Note I said verify. I didn’t say trust. Trust is almost always assumed.

It comes from within it’s own system so surely it can be trusted – right?

There’s firewalls, ACLs, tripwires, log parsing, alerting and a plethora of other defences – right?

Those defences are all well managed, well understood and well maintained – right?

You understand the provenance of your information – right?




the place of origin or earliest known history of something.

a record of ownership of a work of art or an antique, used as a guide to authenticity or quality.

A much abused term in the modern parlance of Engineering. Often used by companies and individuals who wish to bolster the credibility of their ‘inventions’ which are often no more than the regurgitation of broken technology patterns and modes of man-machine behaviours.

The truth of knowing is the purity found in the absence of assumption.

Within our discipline of Engineering it’s a tough order to fill. Engineers are so used to patterns of assumed trust and behaviour.

We trust out key stores.

We trust our CAs.

We trust those that we are unable to validate the veracity of us because it makes our lives easier. Then we are surprised when that trust is proven false. We are surprised when our implied modes of trust is circumvented from within and without, with ease.

The problem is the knowing the provenance of your information. We as a discipline have to become more aware of the challenges of understanding the knowing of our information. It is not enough to be able to trust our data any longer.

I work for a company called Guardtime. We believe we have a robust and provable solution to this challenge of information provenance. We believe we can provide your data and information handling with a leading edge technology which will allow you to know your information; allow your machines to know your information. It’s called KSI. There’s a great paper on what this technology is – go read it.

Over the coming weeks I’ll be expanding on some use-cases within my own disciplines of cloud solutions and devops – so, stay tuned but in the meantime try some light reading:

Can’t Touch This

Stopping The Next Snowden