FOSDEM'10: Maemo 6 platform security

One of the keynote speakers at FOSDEM 2010 in Brussels was Elena Reshetova, a senior security engineer at the Nokia Maemo Security team. Last October at the Maemo Summit 2009, she gave a short introduction to Maemo 6 Platform Security, a set of mechanisms and techniques to protect the Maemo 6 platform; at FOSDEM she gave a more technical overview.

Security of a platform depends on a whole "stack" of solutions: at the bottom there are hardware enablers, such as a TPM (Trusted Platform Module) chip in PCs. On top of that, software implements integrity protection, layered above that is access control, and then privacy protection. On each of these levels, the platform needs key management for encryption and signing keys, and all this is coordinated by a particular security policy. For Maemo 6, Nokia is working on this whole security stack.

DRM

It's no secret that Nokia wants to attract a larger commercial offering to its application store for Maemo. Therefore, the security framework of Maemo 6 will enforce DRM (digital rights management or digital restrictions management, depending on the viewpoint) policies. According to Elena, this is needed to be able to attract a larger developer offering: "DRM will enable a lot more use cases for Maemo devices, such as games and commercial applications."

When talking about DRM, most of the time that means locking down the platform. Elena assured the assembled open source audience that Maemo remains an open source platform, even when DRM comes into play. Maemo 6 will have two device modes: one mode has DRM protection, which means that users can't tinker with their platform. But there will also be an open source mode, which will have the same functionality as Maemo 5 on the N900. In this mode, users are free to hack their device, compile and flash their own kernel, define their own security policy, and do low-level platform development. However, they won't be able to run protected software or play protected media files.

The Maemo 6 device's boot process is assisted by a hardware enabler: the ARM TrustZone security extension to the ARM Cortex-A8 processor creates a trusted execution environment (TrEE) with two main keys: a root public key and a root device specific key. The boot ROM of the device checks the integrity of the boot loader and refuses to load it if it has been tampered with. Incidentally, this means that users cannot swap out Nokia's boot loader for another one. However, if Nokia's loader passes the integrity check, then it checks the integrity of the software (including Nokia's kernel). If that doesn't pass (e.g. the user compiled a custom kernel that isn't signed by Nokia) and the device is SIM locked by the carrier, the device refuses to boot. If the integrity check fails and the device is not SIM locked, then it boots an unsigned software image with restricted security functionality: DRM keys are disabled so that content from the closed mode can't be decrypted.

So, in open mode, the user cannot run DRM-protected software purchased from the Ovi Store or play music bought from the Nokia Comes With Music store. It is only if the software verifies as that shipped by Nokia that the boot loader starts the Nokia signed software image (including the kernel root file system and important system components like drivers and Application Manager), which has the DRM keys enabled and thus can decrypt DRM-protected content.

This system gives users a choice. If they want to have full access to their devices, they will continue to be able to do so in Maemo 6 just like now, but without access to DRM-protected services. Users can also switch between the open and closed modes (e.g. between a 'community' kernel and Nokia's kernel), so that after working in the open mode, users can return to the DRM-protected mode to play some music. If the application doesn't use the protected storage but just stores its data as plain files in the file system, like most non-commercial applications will do, those files are accessible in both modes. Switching modes requires rebooting the device, though, because the checks for the integrity of the software are done by the boot loader.

A new kind of access control

Because Maemo is close to a standard Linux distribution, it won't surprise that Nokia has taken a close look at the classical Linux and UNIX access control mechanisms and their extensions. The classical UNIX access control mechanisms are discretionary access controls (DAC) and were created primarily for servers and desktops with multiple users. Nokia's criteria for their Maemo platform, which is essentially a single-user system, are completely different. For starters, Elena mentioned that the platform needs mandatory access control on the process level: processes should be protected from other processes. Moreover, it needs a good level of flexibility and granularity, and all of that should require only minimal changes to the current Linux DAC model Maemo uses.

Nokia's engineers looked at existing security extensions, such as FreeBSD access controls, MLS, Biba, SELinux, RBAC, AppArmor and TOMOYO Linux, but none of them were a good match to Nokia's requirements. For example, SELinux has fine-grained access control, but needs large, complex policies that require filesystem extended attributes to store the metadata. Moreover, most of these mechanisms don't provide protection from off-line attacks, which is crucial for a mobile device.

So the main goal of Nokia's engineers was to create a lightweight system on top of existing Linux security mechanisms, while having to make the smallest possible change to existing applications. The Maemo 6 security system starts from the principle of least privilege: every application should be able to access only a limited set of needed resources. Therefore, there will be a list of protected resources, and any application that wants to use them will have to declare that in an "Aegis Manifest" file. This is an optional XML file (new as part of the Maemo 6 security model) inside a Debian package, generated automatically by the Maemo SDK (Software Development Kit) based on the source code. That means that developers don't have to worry about it and don't have to change their code. According to Elena, the full list of protected resources is not yet finalized, but components like cellular functionality or location information will be on that list. The former should be protected because misuse could harm the device, while the latter should be protected because misuse could cause harm to the user.

Secure software distribution

The Maemo 6 security framework also has a solution for secure software distribution. Each package has a "software source", which can be a software repository or a home page of the software author. Each known software source has an asymmetric key pair: the private key that has been used to sign the package, and the public key used to verify this package. On top of that, each software source is assigned a trust level. Updating a specific package is only possible from the same software source or from a software source with a higher trust level.

All of this is configured in the Aegis security policy, which contains the mapping between software sources and what the software is allowed to do. So while each application can declare the access control rights it needs in its Aegis Manifest file, ultimately the Aegis security policy decides if these access control rights are granted, based on the risk level associated to the software source.

For example, software from the Ovi Store is assigned a different trust level than software from maemo.org or the home page of an arbitrary software package. The Aegis security policy is accessible only to the application installer and can only be changed by an authorized update, meaning that the trust levels cannot be changed by the user but only by Nokia. Users always have the option to run the device in the open mode, which gives them the capability to define their own security policy.

Integrity and privacy protection

Integrity protection is handled by the Aegis Validator. This component ensures the integrity of all executable components, such as binaries and libraries. It not only protects against runtime manipulations, but also against off-line attacks. A kernel module calculates a cryptographic hash, currently SHA-1, of each file. The reference hashes, which come inside the package or can be computed during installation time, are then stored in the Aegis Protected Storage

The Aegis Protected Storage ensures the integrity of data and configuration files after installation. It can not only be used to sign and verify data, but also to protect the user's privacy by encrypting their data with an encryption key that is stored in hardware. However, applications have to explicitly use the Aegis Protected Storage APIs to place files in the protected storage. The Protected Storage APIs can be used in both of the device's modes, but with an obvious caveat: if an application uses the API to encrypt data in the closed mode, it won't be able to decrypt it in the open mode, and vice versa.

Open source

Nokia is doing its best to behave like a good citizen in the open source world. Elena said they are offering their security additions to the upstream D-Bus project. In addition, recently Nokia created a Maemo 6 Platform Security project at gitorious.org, and the first available code is from the libcreds library, which allows getting and setting the credentials of another process in a secure way. The credentials that libcreds can handle include the user id, group id, supplementary groups, and capabilities defined by the kernel. At the end of her talk, Elena said that, over time, it is Nokia's goal to open source most of the Maemo 6 security framework.

However, DRM threatens the open nature of the Maemo 6 platform. In her talk, Elena stressed how simple it is to use Platform Security because the user doesn't have to worry about key management. All encryption and signing keys of the platform are ultimately based on hardware keys of the ARM TrustZone. So if users backup their data by a simple one-to-one copy and lose their Maemo 6 device, they can't read their backup anymore. Moreover, given that the device's private key is carved in hardware in the chip factory, users can't be sure that they are the only one with access to the private key. Users don't have any control over the key, but Nokia is promoting its Maemo platform as an open platform without restrictions.

Those conflicting signals generated a lot of questions from the audience, many of whom had bad memories of the Trusted Platform Module and "Trusted Computing". So all in all, it looks like the Maemo 6 Platform Security will become a challenge for Nokia's relationship with the Maemo community. Luckily, Nokia is clearly listening to these concerns: the Finnish company has opened a wiki page with questions and official answers about the topic, and it welcomes users to add their questions to the discussion page.