Latest revision as of 21:26, 27 June 2011

This page includes all references to MeeGo Security Architecture content.

MeeGo Security Architecture

This architecture is the result of the work of many different people. Thanks go to all of the MSSF Architecture Team.

For The Reader

The following document contains the overview description of Mobile Simplified Security Framework (MSSF) for the MeeGo.com release. MSSF is the basis of the MeeGo Security Architecture and will be delivered with MeeGo starting with the 1.2 release.

Abstract

The purpose of the Mobile Simplified Security Framework (MSSF), in the MeeGo platform, is to protect the owner of a MeeGo-powered platform from getting their personal data and passwords stolen and used for malicious purposes, to prevent malware from misusing the device, to prevent the user from accidentally breaking the device software, and to make the platform meet the needs of software that requires a safe execution environment. This is accomplished by:

• A fine-grained, configurable, access control framework that can restrict the set of allowed operations according to the source and identify of an application.
• An extensive integrity checking system that ensures the authenticity of all executable files, as well as other important configuration files.
• Protection of sensitive data by means of encryption and signing, including enabling the use of a key derived from a hardware-protected, device-specific secret.

The main design goal is to accomplish all this without significant penalty in terms of performance and usability by using established open standards and having all implementation open-sourced. The other goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with MeeGo.

Security Goals

The main security goals are:

• Protect the user - Malicious applications may try to compromise users’ privacy by publishing the content of their phonebook or private messages to the Internet. They may also try to incur costs to users by calling expensive, premium numbers or using the GPRS data connection extensively while roaming.
• Protect the device - Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, even lead to the device becoming completely unusable. For example, changing the battery charging levels may lead to malfunction. Also, malicious applications should not be able to change the device parameters in a way that would violate regulations or the setup of the mobile operator.
• Protect the business - Some MeeGo devices are sold through the operator channels, which may require support for SIM lock functionality. A malicious user or application should not be able to disable such a lock. Also, MeeGo device distribution channels may require installation or blocking of certain applications or services without the possibility of users or applications changing these settings.
• Enable new services - Services like mobile payments and copyright protection require strong security support from the operating system. The security of these services is essential for their use, so MeeGo provides such enablers.

MSSF Evolution

Currently, there are two major versions of MSSF: version 1 and version 2. MSSF version 1 is the security framework that Nokia delivered as a part of earlier products. MSSF version 2 is an evolution of that framework which is included in MeeGo 1.2. The source code for MSSFv2 is found here. The differences between version 1 and version 2 are the main focus of this document and they are primarily in the areas of: access control, integrity protection, and secure software distribution.

There are several reasons for updating MSSF to version 2, which can be shortly described as:

• New Features – Version 1 lacked a number of important features in the area of access control, such as mandatory run-time filesystem access controls and socket access control.
• Upstream Sources – There is a requirement that all MeeGo components must be upstream and therefore all version 1 kernel modules and patches would need to be accepted by the upstream Linux kernel. However, upstreaming to the Linux kernel of these components was identified as being extremely difficult as it already included stable components that had comparable functionality. Unfortunately, the upstream modules (specifically SMACK* and IMA/EVM) do not provide all the functionality needed by MeeGo. So, the decision was made to contribute to these open-source projects to get the required enablers into the Linux kernel.

Security Framework Components

The MSSF has these components, which are implemented by various platform subsystems.

• Trusted Execution Environment (TEE) Services – Provides secure cryptographic services and key management for other MSSF subsystems.
• Integrity Protection – Ensures protection of the filesystem.
• Access Control – Limits application access to protected resources.
• Cryptographic Services – Provides data integrity and confidentially protection for applications.
• Secure Software Distribution – MeeGo relies on the secure software distribution model, which ensures the authentication of software packages and allows the remote management of security policies.
• Certificate Manager – Provides interfaces to store and manage the platform’s X.509 signing certificates, the user’s own certificates, and any related private keys.

All of these portions of the software stack are influenced by the Device Security Policy, which allows the OEM or operator to configure the security policies for the device.

Trusted Execution Environment

The MSSF framework enables hardware security components, if they are available. These components are then abstracted by the Trusted Execution Environment (TEE) Services subsystem of MSSF. The expectations from hardware security components are similar to those of a Trusted Platform Module (TPM) or Mobile Trusted module (MTM) specifications.

The TEE Services subsystem provides interfaces to tamper resistant services implemented inside security hardware. The actual implementation of these services depends on the security hardware itself and may vary considerably. However, MSSF poses minimal requirements towards the security hardware, which are described below:

• Securely Provisioned Root Public Key (RPK) - The root public key is a one-time programmable (OTP) key, which can be used as a root key for identifying the SW stack of the device.
• Securely Provisioned Root Device Specific Key (RDSK) - The root device specific key is a symmetric OTP key, which can be used as a root key for local cryptographic operations to guarantee data integrity and confidentiality. It can also be used to derive a unique identifier for the device, if needed.
• Trusted Execution Environment - The hardware must provide an environment where cryptographic operations and key management take place in an isolated environment.

These requirements provide a basis for building MSSF services on top of security hardware. If these requirements cannot be satisfied or the target platform does not have a security hardware subsystem, the level of security provided by MSSF decreases significantly. Operations that would take place within hardware instead take place in software, which results in a reduced bar of protection. While not optimal, this reduced bar still provides better protection than generic Linux protections.

Boot Process

This document does not go into specific secure boot implementations. MeeGo is expected to work with various hardware solutions and implementations and there are a wide variety of ways to perform a secure, measured platform boot. The MeeGo Security Framework assumes that a secure boot solution enables a secure boot to the MeeGo kernel. This ties the platform root-of-trust to the kernel. From here, the kernel can then extend the root-of-trust to other portions of the software stack. If a secure boot solution is not provided for the platform, the level of security provided to the platform decreases significantly.

Access Control

The purpose of the MeeGo Access Control subsystem is to limit the access to the operating system resources by enforcing the “principle of least privilege”. To be able to explain this principle and its applicability to MSSF ACS, let’s introduce a number of classic concepts.

Classic Access Control Concepts

The most common abstraction for representing a computer system is dividing it into subjects and objects.

A Subject is an active entity, which represents a system’s user or process in the computer system. The MeeGo access control subsystem uses processes as the granularity of control, meaning that the access control in MeeGo is process based.

An Object, also known as a resource, is a passive entity, which represents a file, system resource, or even potentially a subject. The last means that an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system.

The third commonly use abstraction is an Access Type. It is an operation which a subject can perform on an object. The concrete meaning of access type depends on the commuter system. For the file server, it can be an ability to read an object, to write to it, or to execute it. For database systems, access types can be an ability to insert a new record in a table, to search for data in database, and so on.

UNIX Access Control

After defining the goal of our access control model, let’s discuss the reasons why the current classic UNIX access control isn’t enough to achieve this goal. UNIX access controls were originally developed as “user-centric” access controls. The goal of such ACs is to separate the users and their access to each other’s data. The model of adversary for the classic UNIX model is a malicious user that tries to obtain another user’s data. However, currently most MeeGo devices are considered to be single-user devices. The model of an adversary is mainly malicious software that can be installed by a user and may cause undesirable consequences.

The changed environment and the new adversary model require a change to the access control model. However, it is important to mention that there were a number of attempts to extend the classical UNIX AC model. These include projects such as POSIX* capabilities. Unfortunately, current Linux distributions all support the use of a ‘root’ user. Moreover, the limited amount of defined POSIX capabilities led to the fact that some of them began to be used to protect quite different functionality than intended. For example, the CAP_SYS_ADMIN capability protects a wide range of system objects. This reduces the effect of capabilities separation and leads to diminishing the principle of least privilege. Additionally, POSIX capabilities were introduced to protect specific Linux interfaces and functionality. It remains difficult to use these capabilities to map to items that concern ordinary users.

MeeGo Access Control Concepts

As was explained in the previous section, the standard Linux ACs can’t be used to fulfill the main goals of MeeGo access control. To resolve this, the following AC concepts were introduced.

A resource is a virtual object, which represents some functionality. It can be a file on the filesystem, a D-Bus service, and so on. Some systems’ resources are considered sensitive because they provide access to some critical functionality or data. To access sensitive resources, an application may be required to possess a specific credential. The standard Linux access control has the following credentials, which can be associated with the process: user identifier (UID), group identifier (GID), POSIX capabilities, and supplementary groups. The MeeGo AC framework introduces two new types of credentials: Resource Token and Application Identifier.

A resource token is a string that is understandable for both users and developers. Examples of resource tokens are “Location” and “Cellular”. As an example, let’s consider the “Cellular” resource token. It represents access to cellular functionality on a device (GSM* call, SMS and GPRS data). The real system objects that will be protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, and higher-level D-Bus interfaces. The initial set of protected resources will be defined based on the risk analysis for a MeeGo platform. Each application has a possibility to define new resource tokens, which the application itself provides and may want to use to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have a manifest file inside of the package. In this file, an application declares the credentials, which it needs to work properly, and the credentials that are provided by the application.

The second type of credential is the application identifier, which should fulfill the following requirements:

• It should be impossible to forge.
• It should uniquely identify an application through its entire life cycle.
• It should remain the same for the application, regardless of application restart, application updates, multiple application instances, or platform reboots.

Such an identifier in our system, allowing reliable identification of an application through its entire life cycle, is generated by the package manager and represented by a triplet:

AppID = {SourceID, PackageName, ApplicationSpecificName}

The SourceID is a unique identifier of a software source. It should be tied with a key that is used by this software source, but it should not directly depend on the key since the key may be updated over time. The PackageName is a package name without a version number. ApplicationSpecificName is defined by a developer and is provided for the case where a developer has a number of different binaries within their package that require different access rights. It is defined inside the Manifest File. In the case where no such definition exists within the manifest, the ApplicationSpecificName shall be assumed to be ‘None’.

As an example, let’s use AppID = “com.meego.cool-tools.addressbookplugin”. In this case, “com.meego” is the SourceID, “cool-tools” is the PackageName, and “addressbookplugin” is the ApplicationSpecificName.

In version 1 of MSSF, resource tokens and application identifiers were implemented by a number of specialized kernel modules. However, because of reasons previously mentioned, the decision was made to change the access control subsystem implementation to use one of the mainline Linux Security Modules, Simple Mandatory Access Control Kernel (SMACK)*.

SMACK AC Module Overview

SMACK is a mainline Linux Security Module (LSM) which provides a complete mandatory access control model. SMACK has a notion of label which identifies a security characteristic of subject or object. The default rule is that a subject can only access an object if their labels match. SMACK access rules are defined by triplets:

{Subject, Object, Access}

Here, Access refers to the access type term, defined in Classical Access Control concepts. SMACK also has a number of default system labels that follow a set of default rules.

A detailed description of SMACK can be found in the SMACK White Paper. However, a brief overview is given here to introduce relevant concepts. While we have previously discussed the ideas of subject, object and access, we have not previously discussed the term label. In terms of SMACK, a label is data that identifies the Mandatory Access Control (MAC) characteristics of a subject or object. SMACK labels are between 1 and 23 ASCII characters in length. All single character labels using special characters are reserved by SMACK. Of these, there are four default labels currently defined:

• ‘_’ – Defined as the “floor” tag.
• ‘^’ – Defined as the “hat” tag.
• ‘*’ – Defined as the “star” tag.
• ‘?’ – Defined as the “huh” tag.

These and other system-defined labels are attached to subjects and objects within the system in various ways. For example, a file (object) has a SMACK label attached to it as part of a filesystem extended attribute. A process (subject) has a SMACK label as part of the process structure.

The SMACK LSM will then use the default set of rules (interpreted in order) to process access controls, given the labels that have been applied to the system. The default rules are:

1. Any access requested by a subject labeled ‘*’ is denied.
2. A read or execute access request by a subject labeled ‘^’ is permitted.
3. A read or execute access request on an object labeled ‘_’ is permitted.
4. Any access requested on an object labeled ‘*’ is permitted.
5. Any access requested by a subject on an object with the same label is permitted.
6. Any access requested that is explicitly defined in the loaded rule set is permitted.
7. Any other access is denied.

In the above list, rule 6 allows the SMACK access control list to be expanded and modified to fit the security goals and requirements for a particular platform. Below is a contrived example of user-defined SMACK rules that implement an information hierarchy for Unclassified, Classified, Secret, and Top Secret information.

This allows a pseudo-hierarchy of access, such as defined by this diagram:

SMACK Usage in MSSF

The SMACK LSM implements MSSF AC concepts this way:

• Application Identifier - An application identifier for an application is stored using the SMACK subject label.
• Resource Token - Resource tokens are represented as SMACK object labels.

A possession of resource tokens for applications is expressed through SMACK rules this way. Suppose we have an application that wants to obtain the location information and make GSM calls. It requests this functionality through the following manifest:

<mssf>
	<request>
		<credential name=”Location”/>
		<credential name=”Cellular”/>
			<for path=”/usr/bin/myapp” id=”myapp”/>
	</request>
</mssf>

Assume the application comes from the MeeGo.com software repository and its package name is “my-app-pkg”. The generated application identifier would be “com.meego.my-app-pkg.myapp”. The possession of the requested resource tokens is recorded in the SMACK rule set by:

One note here: Although for clarity sake the SMACK subject labels above have been presented in such a way that the application ID itself is used for the subject label, in practice it will not be used this way. Because SMACK imposes a 24-byte length limitation on labels and application IDs can be arbitrarily long, a 32-bit unique identifier is generated from the application ID and stored as the subject label.

Figure 3 shows the basic components of MSSF AC and their interaction during application installation.

1. An application package, together with a manifest file, comes to the Package Manager.
2. The Package Manager checks the Device Security Policy to determine the maximum set of credentials which can be granted for this application.
3. The Package Manager generates the application identifier for the new application and sets the corresponding SMACK subject label in the security.SMACK64EXEC extended attribute.
4. The Package Manager makes additions to the SMACK rules to mark the possession of certain resource tokens and their access type.
5. If the package provides a D-Bus service that the application would like to protect using manifest rules, then the D-Bus configuration policy is also updated.
6. The Package Manager sends the additions to the SMACK rule set stored in the kernel.

The enforcement of access controls during runtime happens in one of these ways:

• Kernel Enforcement - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels.
• D-Bus Daemon - The D-Bus daemon is modified to perform the credentials checking based on the modified D-Bus configuration policy.
• Application Enforcement - If necessary, each application can use the libcreds library to check the credentials (standard Linux and MSSF specific) of the client connected to it over D-Bus or local socket interfaces. This is needed if an application needs to enforce more fine-grained access control than per socket or D-Bus interfaces can manage.

Loading Shared Libraries

MSSF access control is done on the process level. However, it is quite typical for a process to load a shared library during its execution, to use some functionality it provides. This creates a possibility for a malicious library to get loaded to a process with a set of sensitive credentials and misuse these credentials. Moreover, the case of plug-in based architectures is very common on the MeeGo platform. These issues dictate the need to provide secure loading of shared libraries.

The rule chosen for MeeGo to enforce secure loading of libraries is that at the moment a shared library is loaded into a process, the process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, and resource tokens) than the software source of the library is allowed to grant. In MSSF version 1, the Validator LSM module enforced this rule. For MSSF version 2, the long-term goal is to use an LSM composer. An LSM composer would allow combining the abilities from multiple LSMs into a single, cohesive entity. Unfortunately, a LSM composer will not be available in time for the MeeGo 1.2 release. The short-term solution for this is to add the additional functionality directly into the SMACK LSM using the mmap LSM hook to enforce the rule. Using this hook ensures that when an application tries to load a shared library, the kernel calls into the SMACK LSM, which can then determine the maximum credentials the process is allowed, given the library it is loading.

Integrity Protection

It is the responsibility of the MSSF Integrity Protection subsystem to verify the integrity of all user space components, data files, and anything else that resides in the filesystem.

The MSSF version 1 integrity protection subsystem was implemented with the help of the Validator kernel module and a number of user space components. However, the implementation of this subsystem changed significantly due to the mainline kernel already having its own integrity protection subsystem: Integrity Measurement Architecture (IMA). One of the main benefits of the move to IMA is usage of extended attributes to store reference hashes of files, which allows removal of the need to keep reference hashes in kernel memory during system run-time. The reference cryptographic hash (currently SHA-1) for each file is stored in the security.ima extended attribute and the integrity of the file is verified every time the IMA kernel module accesses it. There is also a caching mechanism available to improve the performance by removing the need to verify the files that were not changed in run-time since the last IMA measurement. An additional difference between IMA and Validator is that IMA heavily relies on ACs for integrity protection during system run-time. In practice, this means that the security.ima extended attribute is recalculated every time the file is changed during system run-time and all levels of access control protection allowed the change.

The downside of using the security.ima extended attribute is that it contains a non-keyed hash resulting in a protection mechanism that gives no protection against offline modifications. Depending on the device, it could be very easy and straightforward for an attacker to remove the storage device and modify it in another system. To address this, IMA has an extension called the Extended Verification Module (EVM). The latest available white paper describing IMA and EVM is located here. EVM provides offline protection for filesystem metadata, including the extended attributes by calculating a keyed cryptographic hash (currently HMAC-SHA1) over them and storing this hash in the security.evm extended attribute. This HMAC calculation must be done by a trusted execution environment on the platform with a hardware protected key. Without this, the key used for the HMAC calculation must be stored somewhere in the filesystem and offers no additional protections over IMA alone. The protection of the key can be done by:

• Direct usage of TEE services and keys - In this case, EVM would use the interfaces provided by the TEE services subsystem to compute and verify the keyed cryptographic hash. The key for these operations would never be exposed outside of TEE and would provide the best level of protection. However, this alternative could present a large performance impact on the system, depending on the number of operations needed by the application and the underlying security hardware implementation.
• Key export from TEE upon kernel validation - This method is proposed by IMA/EVM authors. After successful kernel integrity verification during the boot sequence, the kernel is given a key that can be used by the EVM module to compute and verify the keyed cryptographic hashes. In this case, the performance impact could be relatively smaller because a HW security subsystem will not be invoked for each verification operation. However, the risk of key compromise is higher, since even a verified kernel will have a security defect that will be later discovered and made exploitable.

The choice between the above two approaches should be based on performance measurements for the specific platform security goals and requirements.

A simplified picture of the MSSF integrity protection subsystem and its component interactions can be viewed in Figure 4.

0. The software package comes to the package manager.

1. The security.ima and security.evm (if applicable) extended attributes for all files provided by the package are set up.
2. When a file is accessed…
3. …the IMA module intercepts the system call and calculates the cryptographic hash over the contents…
4. …and accesses the security.ima extended attribute to compare the calculated hash with the reference hash.
5. This triggers the EVM module…
6. …which performs verification of the security.ima extended attribute (among others) by using the value stored in the security.evm extended attribute.
7. If verification succeeds, then IMA is given the security.ima attribute value. Otherwise, the IMA module receives an error.

Cryptographic Services

The MSSF Cryptographic Services subsystem provides an additional way to ensure the integrity and confidentiality of application data during run-time and between platform restarts. Cryptographic Services utilities are provided for the following TEE Services subsystem interfaces:

• Local cryptographic services
• Key management

The access to protected data can be accomplished:

• By the application specific key derived from the application identifier (AppID) and RDSK key
• Or by the shared key derived from the resource token name and RDSK key.

Figure 5 provides a high-level view of the typical interaction scenario when an application wants to protect the integrity of its data.

1. Application calls the libmssf-crypto library API to compute a local message authentication code (MAC) over the data.
2. The libmssf-crypto library transfers this request to the security driver through a libtee provided interface.
3. The security driver verifies if the application possesses the necessary credential.
4. If so, the MAC is computed…
5. …and returned to the application by passing through the security driver, libtee, and finally libmssf-crypto.

Once this is in place, the application can verify its own data at any time and can determine its own security policy if the integrity checks fail.

Secure Software Distribution

The process of software distribution is directly linked to the security architecture. It creates a trusted link between developers and end user devices by ensuring that software originated from any of a number of authenticated SW sources. This section provides a brief introduction to the main software distribution concepts.

MeeGo applications may come to the Package Manager from different software sources that can be either known or unknown. The notion of a “software source” is abstract and can represent a different range of entities starting from software repositories and ending with a single developer who can publish signed software packages on his web page. The Package Manager has access to a list of known software sources and their public keys. Each software source has a trust level associated with it. The trust level defines the software update rules for any package in the platform. Installed packages can be updated only from the same source they originally came from, or from a software source with a higher trust level. This rule ensures that trusted software couldn’t be updated with software from a less trusted repository. This applies even if the less trusted repository contains newer versions of software. In addition to this list of software repositories, the Package Manager maintains an additional software source called “Unknown”. All applications that can’t be considered to come from any of the known software sources would be considered to come from “Unknown”. The information about a software source is preserved through the application lifetime.

Each MeeGo software source is supposed to check its applications for robustness and security compliance against their own security policies. There are many different ways a software vendor can accomplish this, and that effort specifically falls outside the scope of this document.

Device Security Policy

The Device Security Policy defines the mapping between the software sources and the list of credentials that each software source can grant. A manufacturer, operator or even a device user can either define the device security policy when a platform is in “Developer Mode”. The software source is assumed to have some level of quality assurance and that the repository owner follows that process or ensures the process is followed by external, 3rd parties creating software for the repository.

MSSF can enforce different policies, starting from the strictest ones and ending all the way with a completely open developer platform. The owner of a device defines a device policy based on his needs and goals. Such flexibility allows a range of mobile devices targeted for different purposes and environments to use the same security framework. For example, an operator may want a device to give access to telephony functionality only to applications that originate from their own software repository. However, the user of a device in developer mode may want their own applications to have access to telephony. The flexibility of the device security policy allows different access to the same application in devices with different security goals without additional changes to the application itself. Additionally, updates to the device security policy allow fast reaction as the threat landscape for MeeGo platforms change over time. For example, while the risk of malware for MeeGo is currently relatively small, the security policy can be tightened down if in the future this circumstance changes.

Each software source can be represented by a single entry in a device policy file: software source name, trust level, key, and list of allowed credentials. For example, Table 2 shows a simple Device Security Policy which has two software sources defined: MeeGo.com and Developer.org. Both the “Cellular” and “UserData” credentials can be assigned to software, requesting them from MeeGo.com. However, only “UserData” can be accessed by software from Developer.org. Additionally, this generous device policy allows unknown software to access user data.

Certificate Manager

The MSSF Certificate Manager subsystem provides means of managing and securely storing the system’s X.509 signing certificates, user’s own certificates and the related private keys. These certificates can be used by various applications in MeeGo (like browser, e-mail and other applications) in order to perform authentication of the remote party or, in case of user’s certificates and related private keys, authenticate a user towards some remote service. The main component of the Certificate Manager subsystem is a libmssf-certman library, which provides a user space interface for MeeGo applications in order to perform actions described above.

When authenticating a remote service (for example, web site or mail server), an application usually needs to be able to verify an X.509 signing certificate, presented by this service. In order to do it, it needs to verify an authority, which signed this certificate. This, in turn, can be done by verifying the certificate signature against some known public key, which is stored inside another X.509 certificate. However, such a chain of certificates can’t be endless and therefore some certificates in this chain are usually self-signed certificates (also called root certificates), which are initially imported to the system and trusted by it. So, in order to verify a remote service’s certificate, an application needs to retrieve a set of system’s self-signed root X.509 certificates and verify the presented certificate against this set via some certificate chain. This use case is shown in Figure 6. A browser application received an X.509 certificate and needs to validate it. In order to do it, it uses the libmssf-certman interface:

1. To ask the libmssf-certman for the set of the system’s self-signed certificates
2. Libmssf-certman requests libmssf-crypt to verify the integrity of the certificate store
3. The system’s cryptographic services verify the integrity
4. If there is no compromise, libmssf-certman is notified
5. The set of certificates is returned to the browser

Another typical use case for the libmssf-certman usage is handling of a user’s private keys that can be used to authenticate a user and user’s data to a remote service. This use case is shown in Figure 7. An e-mail application would like to sign a user’s email and therefore needs the user’s private key which is stored in the certificate manager.

1. It requests the private key via libmssf-certman
2. Which checks the protection method for the requested private key
3. If the key is protected with a user passphrase, libmssf-certman requests it from the e-mail application
4. The e-mail application requests the passphrase from the user
5. The passphrase is passed to libmssf-certman by the e-mail application
6. Which decrypts the private key and returns it to the e-mail application

The libmssf-certman library also implements a standard PKCS#11 interface to manage X.509 certificates. This allows usage of the Certificate Manager subsystem for applications that can’t be changed in order to use the libmssf-certman interface directly.

External Documentation

MeeGo 2010 Conference

• MeeGo Security: What is it and why do we care?
• Mobile Simplified Security Framework Overview
• The Cost Of Security, A Developer's View

Publications

• Mobile Simplified Security Framework, Linux Symposium paper, File:MSSF OLS2010.pdf
• Mobile Simplified Security Framework, Linux Symposium slides, File:MSSF Slides OLS2010.pdf