Converged security -- Do we need a new model?

We're running a couple of "think pieces" about the role of telcos in assuring user security and privacy in the converged world of communications and IT. For our appetiser post we noted how telcos are getting into the security business, and IT companies are struggling to keep their products secure. Then for the second course we served up some thoughts on how security was just one means of changing the basis of competition.

Now we're onto the main course. This is going to be a high cholesterol intellectual diet full of unrefined ideas and potentially hazardous raw ingredients. Follow this recipe at your peril. The same caveats as the first article apply: we might be really, deeply mistaken and these are just provisional thoughts.

Computer science, meet social science

Today's networked applications -- email, browsers, file sharing, and so on -- are based around attaching a network interface to a 1940s computer architecture. It just happens that the computers got a trillion times faster or so over the past six decades.

There are three underlying causes of difficulty in making these safe and convenient-to-use in a hostile online environment:

  • Firstly, computers have only a very primitive classification of data internally, if any. They keep the data from different concurrent programs safe from each other, but within the memory allocated to any one program all bits are equal. At best they understand the difference between "instructions (code)" and "data". Computers of the future need to model the real complexity of the different natures of the data stored within in ways they don't today. As a business person reading this blog, it's always uncomfortable to hear that there's some nasty problem lurking down inside the basement of the data centre. We hire CIOs and CTOs to help us pretend that technology can be cordoned off as a business concern.
  • Secondly, it matters where the bits came from and go to outside the CPU -- and this needs to be tracked in meta-data about machines, people and institutions which is currently discarded too readily. Today's security model is from a pre-networked era. A document I created isn't the same security risk as one emailed to me. But my computer can't tell them apart, not in the processor, storage, OS or applications.
  • Finally, these two issues need to be bridged, so the different types of data can be passed around and preserve their metadata properties: not everything is a "bag of bits". But the "human factors" side of integrating permissions, auditing and communication need addressing.

In other words, just as enterprises grew accounting, reporting and auditing functions that became integral, similar systems of control need to be incorporated into future connected devices.

It's the humans, stupid

A little diversionary side story on this last point. At the open day for applicants to the university I ended up going to, the tutor had a recommended reading list. So I picked the textbook for the first term -- "Introduction to Functional Programming" by Bird & Wadler (there's no chance of ever forgetting that mental image of sparrows and ducks) -- and read it on the school bus. All kinds of strange mathematical ways of describing computer programs that were provably derived for their specification, as expressed in predicate calculus.

All seemed like rather a lot of work to put together a ten-line sorting algorithm, given I was used to churning out a hundred lines of working machine code an hour. (At 36, I've already been playing with computers for a quarter of a century.) So on the way into the interview, a bag of nerves, I said that I'd read the book, but had a question: how exactly do you go about writing the specification for a word processor in formal, mathematical predicate logic -- and ensure your specification is correct?

I never got a satisfactory answer during the whole of the three years there. Still waiting.

It's those damned humans in the process. That's where all the interesting problems lie. So our real objective is to alleviate humans from responsibility for security, be they programmers or users. Where they are given choices, they are given meaningful ones. That means something better than "do you want to install this application and have it trash your data or capture your keystrokes?", which is where we de facto are today.

So a confident communications system is going to pay as much attention to the user experience as to cryptography.

Bits are just bits (except when you act on them)

So, let's tackle our three problems. Firstly, let's get a better classification of the bits, which we can then use to create richer security policies and tracking of bits sourced from elsewhere:

  • Instructions that act as instructions ("executable data"). These are the instructions that your CPU runs through, executing code.
  • Instructions that act as data ("compiled data"). When your compiler turns program text into machine code, it produces this output as data.
  • Data that acts as data ("payload data"). The purpose of such data is solely to be stored, re-transmitted, or rendered for human consumption on some external device. The content of an MP3 music file might be a good example.
  • Data that acts as instructions ("flow control data"). This is user data that is used to drive decisions within the CPU -- which branch of instructions to follow -- the flow of the code.

The difference between "flow" and "payload" data isn't in the data itself, but whether it is transferred into memory and then loaded into the CPU and then used by an instruction that affects the flow control of the CPU. That's because data that just "passes through" isn't a security risk -- a security problem has to do something different that deviates from the intended flow. No change, no risk.

(If you're already feeling queasy, this is a good time to skip a course and wait for dessert. Normal flavour of business commentary will resume shortly.)

As you can guess, we're going to build a new and different security policy scheme based on this classification.

Fundamental problems already exist

Some important points about these categories:

  • Today, we've got the wrong granularity of permissions on "executable data". When I install an extension into my Firefox browser, it forms part of the same executable and inherits all of Firefox's permissions and capabilities; yet I have far less confidence in the trustworthiness of such extensions than I do in the browser itself.
  • Compiled data needs to "jump the fence" and be treated as executable code. In today's operating systems, this might just be a permissions or extension change to a file. As you can imagine, I'm less than impressed by the ease with which such a thing can occur! All these buffer overflow problems have been given extensive prophylactic treatment in new operating systems like Vista, but I'm not convinced the OS is the place to enforce this.

Where did you get that bit, where did you get that bit?

So we're going to assume that any data passes through the processor is classified according to the above scheme. Later will look at how we attach permissions based on the real class of the data.

The second part of the puzzle is assembling some kind of social history of the data we're dealing with. It's time for computers to stop having unsafe sex with strange data just because the data looks pretty and innocent. At the very least we need to track whether the data has been sourced locally (typed in, captured on a webcam, etc. into some local editing tool), or imported from afar. Users tend not to be saboteurs of their own computers in the same way as the controller of a zombied PC half a world away.

Ideally, we'd like a longer and more detailed audit trail of where the data has come from. Which website did I download this file from? Who typed this data in? Which email did I paste this text from?

Putting it all together

Now for the hard bit -- putting together the metadata and the "Confident computing" environment where we've separated out our different security concerns.

Firstly, we're going to take a somewhat looser view of what an "application" might be. It's not one-to-one with an icon down on your taskbar, but a lump of executable code from a discrete source. So using the Firefox browser example, the extensions come from a different source, and should be tagged as such and subject to different security rules. We're provisioning applications onto devices -- and even pushing the granularity down to below the application. Individual bits of script in a web page, sourced from different places, are then subject to different rules. Your banking application may request to access the smartcard reader attached. If you visited this blog and it made the same request, you'd be suspicious.

At the moment we have a reactive approach to dealing with security permissions. When the application tries to do something that requires a greater security level, it trips the switch and the OS or browser pops up a request window. If the application requires a whole bunch of permissions, you get a whole bunch of requests in succession. People don't like to be nagged, so they turn off such warnings. As soon as Vista launched, the first sets of hints and tips were on how to turn off the nagging nannying security dialogue boxes.

(Before Linux and Mac users start to gloat, really it's no better there either. Creating faux users for different applications, and adding in granular user-based permissions to the filesystem -- HP-UX, RIP -- just doesn't cut it. Either you're designing in security and modelling it properly, or you're not.)

Ask for permission, not forgiveness

Instead we need to move to a proactive approach. When we install an application, or first visit a website requiring above-normal system access, it should make all the security requests necessary. A website for editing pictures might request access to the My Pictures folder. A conference calling application can ask to view your webcam. Today, I download an application and install it, and it gets access to anything and everything on my PC.

This means applications need to come with a "manifest" of what they are and intend to do.

The choice would also be presented to the user in a simple and palatable manner. Rather than cryptically listing the permitted OS system calls and resources, there might be standard bundles of permissions (e.g. "File editor", "System diagnostics"), and it might list the overall high-level permissions, any existing applications with that set of permissions, and any deviance from the standard set of permissions. It's easy to tell if my music player should be given the same permissions as my banking application or not.

Because we're tracking the nature of the data in memory and being stored, as well as its origin, we can do some interesting things. Any unit of code that doesn't need to access a system resource (e.g. network, file system, devices) isn't a security risk per se. For example, an extension module to rotate videos in a web-based editing
suite can be installed and the user might not even be troubled with a request for any security permissions. Its function is purely transformative. I don't have to believe anything about what it says on the tin -- I know it can't access any parts of my personal data or modify any system files. It has no "flow control" impact outside its container.

Likewise, data captured from my webcam and passed through to the video system and the screen, without being used to influence a branch inside any CPU code, isn't a security risk. No need to ask for permission to do anything.

Make it quick, make it easy

So far we've managed to simplify the user's experience by:

  • Not nagging about "transformative" actions that have no security implications. Do I want to install this extension or piece of code? Sure, if it doesn't have any chance of side-effects.
  • Asking for permission once and only once in a meaningful manner when new code is installed or downloaded that wants to access secure resources.
  • Allowing policies that make more sense to the user in a networked world.

The next trick is to make it all happen fast. In principle all conventional digital computers can emulate each other (the Church-Turing thesis -- I knew that final year computability course would come in useful some day). The only difference important to us here is in the physical security of the packaging (which is what trusted computing technology achieves) and the speed at which they execute. So my suspicion is that most of the confident communications capabilities will require support from the silicon layer. Indeed, there may come a point in the near future where most of the transistors in a processor are given over to auditing, policy and cryptographic functions. Eliminating the evil bits becomes more of an imperative than processing the good ones faster.

Practical lessons? We're going to make you wait...

We'll look at some consequences of these ideas and practical baby steps operators and others can take towards a more secure communications and computing environment in our next post. But as a parting thought this time, consider how difficult it remains to install, update and manage client software -- be it Java, Windows Mobile or Symbian -- on mobile handsets. Plenty of people want to be the "container" in which all software must run, and become an essential facility. Adobe's Flash clients are there already, Google's latest technology is trying to bridge the Web and PC models. But given their heterogeneous nature, can any one of these software solutions ever be the answer? Or is the passing of secure, identified, audited data and code between computers inevitably a job for some other part of the device and software stack?

In the meantime we're sure there's a ton of research out there on building secure networked devices that we're not aware of. If you think there are some gems that might point the way to the future, why not share them using the comment feedback below?