Security and Going Open Source

Over on the main Symbian Foundation blog, Tyson Key asks:

Out of interest, how would you deal with releasing the source code to “sensitive” parts of the combined Symbian OS/S60/UIQ/MOAP(S) codebase? Components involved with handling storing keys for DRM, certain hardware drivers, baseband/physical layer access code, and GSM, GPRS and UMTS radio stacks come to mind.

This is a very good question!  We’re clear on our goal, which is that devices using the Symbian Foundation platform won’t rely on any “security by obscurity”.  Although that can work (for a while) and can be a rational business decision in some circumstances, it’s not a long-term foundation for a good security architecture (especially not for one that’s going open source!).  We’ve been clear on this from the outset in designing the Symbian OS Platform Security architecture, and security is not going to be an acceptable reason for blocking the publication of any of the source code.

That said, of course real life isn’t that clear cut!  Many of the things you mention (DRM key storage, radio stack, etc.) need to work with the particular hardware platform in the device, and they aren’t (yet) standardised parts of the Symbian Foundation platform.  There are some things that need to be protected more strongly than you can do in software alone (the IMEI for example) and today phone manufacturers typically write custom code to talk to their hardware when is then embedded in the boot code, radio stack, DRM agent and so on.

The architecturally pure way to fix that is to define hardware adaptation interfaces (HAIs) which abstract the common features of these hardware security services (but at the lowest possible level of abstraction) and then generic platform components can be provided which call those HAIs, and device integrators can provide simple adaptations for the hardware platform they choose.

Today we are probably missing some of those necessary HAIs, but we hope that we will, step by step, identify which are missing, agree the definition of the HAI, and thus be able to provide a functionally complete set of generic open source components which anyone can take and build a working, secure device with a minimal amount of hardware adaptation.

That’s a quick run through of some of the issues I’ve been thinking about recently, but what do you think?


3 Responses to “Security and Going Open Source”

  1. Tyson Key Says:

    Wow, thanks for taking the time to pick out my comment to use for the foundation of this post.

    I’ve been interested in the internals of the Symbian OS platform for a while, and whilst I recognise that security is of utmost importance, is there any chance that we’ll see an interface that allows developers/curious users read-only packet-level access to the Bluetooth, IrDA, UMTS, TCP/IP and SMS stacks and similar, for building TCPdump-style tools?

  2. Craig H Says:

    @Tyson – my pleasure, thanks for providing a perfect opportunity to introduce myself 🙂

    You raise another interesting question, regarding a read-only packet-level “sniffing” interface. I can see that would be very useful for developers in debugging network protocols and so on, and it’s not immediately obvious why there should be any security issues with it.

    I think it’s probably worth investigating possible security issues of that in more depth though. It occurs to me that applications may be making some assumptions about the implicit security of connections based on the transport. For example, no sensible application developer would assume that unencrypted TCP/IP traffic is secure – it could be routed anywhere and it could be read or modified at any intermediate node, so there would be no security implications to allowing sniffing at the socket interface. However, an application developer might well assume that IrDA or Bluetooth traffic is secure from sniffing (as Bluetooth pairing provides security at the link layer, and IrDA is line-of-sight) and thus a socket-level sniffing interface might allow private data to be compromised.

  3. Tyson Key Says:

    Hmm, I was tempted to suggest that they expose the option in the UI, and let the user decide if they want to enable it, although of course, that means that it won’t be ubiquitous/accessible to anyone who wants it, unless they’re willing to play a game of chance, and see whether or not Phone Y by Vendor X supports it… (Which kind of moots things).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: