Security domain overview

This section contains a high-level architectural description of the MeeGo 1.2 Harmattan security framework. For more information on security features, see the Security guide.

The purpose of the Harmattan security framework is to protect the users of a Harmattan device against getting their personal data and passwords from being stolen and used for malicious purposes, to prevent malware from misusing the device and the user incurring extra costs, 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 done by the following means:

• Fine-grained configurable access control framework, which can restrict the set of allowed operations according to the source and identity of applications.
• Extensive integrity checking to ensure the authenticity of all executable files (starting from the bootloader and the kernel, up to the less significant applications), as well as important configuration files and policies.
• Protection of sensitive data by means of encryption and signing, using a key derived from a hardware-protected, device-specific key.
• Protection of the software deployment chain by cryptography-based software source authentication and software source ranking to prevent attacks through malicious repositories.

The main design goal is to achieve all this without performance and usability significantly suffering, and having all implementation open-sourced. Another goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with the Harmattan operating system.

Goals of Harmattan security framework

The main goals of the Harmattan security framework are as follows:

• Protect the user

Malicious applications may try to compromise users' privacy by publishing their phonebook contacts or private messages to the internet. They also may try to incur users extra costs by calling to expensive premium numbers or extensively using the GPRS data connection while roaming. Another possibility is simply damaging users' data.

• Protect the device

Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, become unusable. For example, changing the battery charging levels may lead to the battery explosion. Additionally, malicious applications should not be able to change the device parameters in a way that the device would violate regulations by the mobile operators or the legislation in different countries.

• Protect the business

Some Harmattan devices are sold through the operator channels, which may require support for the SIM lock. A malicious user or malicious application should not be able to disable such a lock. Additionally, some Harmattan device distribution channels may require installation or blocking of certain applications or services without a possibility for users or applications to change these settings.

• Enable new services

Services, such as mobile payments and copyright protection, require a strong security support from the operating system. The security of these services is essential to their usage, which is why such enablers should be provided by the Harmattan security framework.

System context

The following figure illustrates the external and internal dependencies between the Harmattan security framework subsystems and other Harmattan domains and subsystems.

Domains and subsystems on which the Harmattan security framework depends

Domain or subsystem	Harmattan security framework subsystem	Reason
Linux Kernel subsystem of Core domain	Access Control Framework, Integrity Protection Framework, TEE Services	Provides a number of interfaces, such as securityfs, LSM and other kernel APIs for the kernel modules and user space components.
Product Validation domain	TEE Services	Provides the libcal library, which is used to access the CAL area in order to manage device security configuration parameters.
Freedesktop Essentials subsystem of System SW domain	Certificate Manager	Provides necessary interfaces for the D-Bus communication between libaegis-certman and Certificate Manager Settings applet.
Application Framework domain	Certificate Manager	Provides necessary graphical primitives for the Certificate Manager Settings applet.
GNOME Essentials subsystem of System SW domain	Certificate Manager, Crypto Services	Provides the expat XML library, which is used for the parsing the internal XML configuration files.

Harmattan security framework subsystem inter-dependencies

Harmattan security framework subsystem	Dependent Harmattan security framework subsystem(s)	Reason
Access Control Framework	Crypto Services, SW Distribution Security, Certificate Manage, Security Qt API	Provides libcreds2 APIs for checking credentials of other processes during run-time to make access control decision on data access or other request (used by the Crypto Services and Certificate Manager subsystems). Also provides APIs to load access control policies to the access control kernel modules (used by the SW Distribution Security subsystem).
Integrity Protection Framework	SW Distribution Security	Provides APIs to load the reference hashes to the Validator kernel module.
Crypto Services	Certificate Manager, Integrity Protection Framework, SW Distribution Securit, Security Qt API	Provides libaegis-crypto APIs that are used to guarantee data integrity and confidentiality (certificate stores, file with reference hashes, security policies and so on).
Certificate Manager	SW Distribution Securit, Security Qt API	Provides libaegis-certman APIs to verify x.509 certificates that can be used during the installation of software packages.
TEE Services	SW Distribution Security, Crypto Services, Integrity Protection Framework	Provides libbb5 APIs for performing local cryptography operations inside TEE and other TEE services.

Structural view

The following figure illustrates the structural view of the Harmattan security framework subsystems.

Behavioural view

The Harmattan security framework has the following components, which are implemented by the separate subsystems:

• Trusted Execution Environment (TEE) Services

Provides secure cryptographic services and key management for other subsystems.

• Integrity Protection Framework

Ensures offline protection of the filesystem.

• Access Control Framework

Limits application access to protected resources.

• Crypto Services

Provides data integrity and confidentiality protection for applications.

• Secure Software Distribution

Harmattan security framework relies on the secure software distribution model, which ensures the authentication of software packages and allows managing security policies remotely.

• Certificate Manager

Provides interfaces to store and manage the X.509 signing certificates, user's own certificates and the related private keys.

• Security Qt API

Provides a Qt interface to the main user space libraries of other Harmattan security framework components (Access Control Framework, Crypto Services and Certificate Manager).

There are also a number of security policies that are control points of the Harmattan security framework. The device security policy is the main control point of the Harmattan security framework Access Control subsystem.

Access Control (AC)

The purpose of the Harmattan security framework Access Control (AC) 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 the Harmattan security framework AC, this section introduces some classic concepts.

Classic access control concepts

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

Subject is an active entity, which represents a system's user or system process in the computer system. By a subject, access control subsystem denotes a process in the system, which means that the access control is process-based.

Object is a passive entity, which represents a file, a system resource, or even a subject. The last means that, for example, an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system. The term resource is sometimes used to denote objects in the Harmattan system.

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

Now the principle of least privilege can be defined as "every subject must be able to access only such objects that are necessary to its legitimate purpose".

UNIX access control

After defining the goal of the Harmattan access control model, this subsection discusses why the current classic UNIX access control is not enough to achieve this goal. Unix AC was originally developed as "user-centric" access control. The goal of such AC is to separate the users, their access to each other's data, and so on. The model of an adversary for a classic UNIX model is a malicious user, who tries to obtain another user's data. However, currently most of the Harmattan devices are considered to be used mostly by a single user. The model of an adversary is also different nowadays: the main threat comes from malicious software that can be installed by a user and may cause many undesirable consequences.

So, the changed environment and the new adversary model require a change of an access control model. However, there were a number of attempts to extend the classic Unix AC model, for example, by introducing the POSIX capabilities. Unfortunately for the majority of the current Linux distributions, they all were given to a "root" user, and other users did not have any. Moreover, the limited number of defined POSIX capabilities led to some of them being used to protect quite a different function (for example, the CAP_SYS_ADMIN capability protects a wide range of system objects). This reduces the effect of capabilities' separation and diminishes the principle of least privileges. Additionally, POSIX capabilities were mostly introduced to protect the specified Linux interfaces and functionality, and thus mapping them to what that ordinary users are mostly concerned with (such as user's data, and user's location information) remains quite difficult.

Access Control concepts

The standard Linux access control cannot be used to meet the main goal of the access control. In order to do it, the following AC specific concepts are introduced:

A resource is a virtual object that represents a functionality. It can be a file, for instance, on the filesystem or a D-Bus service. Some system's resources are considered to be sensitive resources, because they provide access to a critical function or data. In order to access such sensitive resources, an application may be required to possess a certain 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 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". For example, the "Cellular" resource token represents access to cellular functionality on a device (GSM call, SMS, and GPRS data). The real system objects that are protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, higher level D-Bus interfaces, and so on. The initial set of protected resources is defined based on the risk analysis for the Harmattan platform. Moreover, each application has a possibility to define a new resource token, which the application itself provides and may use in order to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have an Aegis manifest file inside the application package. In this file, an application declares the credentials that it needs in order to work properly, and the credentials that are provided by this application. For more information, see Security guide.

The second credential type is an application identifier, which should meet the following requirements:

• Impossible to forge
• Unique (identify an application uniquely)
• Same for the application updates, between boot-ups, for the different instances of the same application, and after the application restart

Such an identifier in the system is represented by a triplet AppID = {SourceID, PackageName, ApplicationSpecificName} and generated by the package manager component. The SourceID is a unique identifier of a software source. It should be related to the cryptographic key that is used by this software source. However, the identifier should not depend on the key directly, as the key may be changed. For example, the identifier can be the current domain name of the software source (for example, Nokia, or MeeGo), or a unique identifier derived from a key certificate. PackageName is a package name without a version number. ApplicationSpecificName is defined by a developer, if a number of applications exist in the same binary package, and these applications need different access rights. ApplicationSpecificName is defined in the Aegis manifest file. If no such definition exists, all applications in the same package get the same application identity of a form of AppID = {SourceID, PackageName, None}.

For example, if an application identifier AppID = "com.nokia.meego.cool-tools.addressbookplugin", "com.nokia.meego" is the software source name, "cool-tools" is the package name, which has a number of plug-ins for different purposes, and the "addressbookplugin" is the application name. If the application name was not specified for this example, the application identifier would be AppID = "com.nokia.meego.cool-tools".

The purpose of introducing both the Harmattan security framework application identifier and resource tokens is to fill the gap, required in order to reliably identify an application during its entire life cycle, as well as to be able to assign the application a credential set that is understandable and meaningful for the manufacturers, application developers, and potentially for the users.

In the Harmattan security framework, resource tokens and application identifiers are implemented with the help of several kernel modules and user space components, which are described in more detail in the following section.

Access Control components and interaction

Access Control framework has the following user space components:

• Package Manager

Package Manager is "an entrance" for new applications, application updates, the device's policy updates and key updates. Package Manager component (in Harmattan, dpkg) was modified to bring the security context from the installation packages to the system. The main security task of Package Manager is to build a Credentials policy based on the Device Security Policy, and the Aegis manifest file from the software package.

• Credentials policy

The Credentials policy defines the list of the credentials that are assigned to an application during run-time. It currently contains the mapping between the full path name of the application executable and the allowed list of credentials.

• Device Security Policy

This policy defines software sources that are known by a device, their hierarchy and set of the credentials each of them can grant. Initially, the policy can be defined by a manufacturer or operator, if, for example, a device is supposed to be distributed through special promotions. Later it can only be changed by an authorised policy update. More information about the device security policy can be found in Device security policy section.

• D-Bus (Desktop bus) daemon and dbus access control policies

D-Bus is an inter-process communication (IPC) system for software applications to communicate with each other. D-Bus allows programs to register and offer services to others, and it also allows you to define access control rights for these services. Access control rights for each D-Bus service can be declared in the D-Bus configuration file. However, the current D-Bus daemon can make access control decisions based on a very limited static set of process attributes (such as user identifier and group identified). The Harmattan security framework provides modifications to the D-Bus daemon in order to take into account an extended set of run-time process credentials (such as POSIX capabilities, supplementary groups, resource tokens and application identifiers).

The following kernel space components are available:

• Credentials manager

The credential manager is a component that maintains the run-time credentials policy and assigns the credentials to a process during the execution.

• Run-time credentials policy

The run-time credentials policy contains the same information as credentials policy, but it is stored in a different representation in the kernel memory.

The following figure illustrates the interaction for application installation. Upon new application installation (1), the package manager checks the Device Security policy to find out if the software source is known and what set of credentials it can grant (2). It then checks the set of requested credentials listed in the package's Aegis manifest file. The result set of credentials, which are granted to the application after the installation, is defined by the intersection of both sets. After successful installation, the installer modifies the credentials policy (3) by adding a new rule for a new application. The installer also modifies the D-Bus policy if new application defines a new D-Bus interface protected with a credential (4). Additionally, the installer uploads the new credential policy rules to the run-time credential policy through the credential manager interface (5a).

The access control enforcement during run-time can occur in one of the following ways:

• Kernel level enforcement done by the Linux kernel itself

  The Linux kernel already performs access control related enforcement checks for the objects (filesystem objects, system calls provided by the functionality) protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups and POSIX capabilities.

• D-Bus daemon user space enforcement

  The D-Bus daemon was modified to perform the run-time credentials checking based on the D-Bus configuration policy.

• Application enforcement based on the Harmattan security framework libcreds library

  If necessary, each application can use the libcreds library in order to check the credentials (standard Linux ones and the Harmattan security framework specific ones) 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 for D-Bus interface/method.

Loading shared libraries

The Harmattan security framework access control is done on the process level. However, it is typical for a process to load a shared library during its execution to use some function the library provides. Unfortunately, this creates a possibility for a malicious library to be loaded to the process with a set of sensitive credentials and to misuse these credentials. Moreover, the case of plug-in based architecture is very common on the Harmattan platform, and the risk of an attack when an application loads a malicious plug-in is quite great. Thus there is a need to provide a way to secure the loading of shared libraries.

At the moment of loading a shared library, a process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, or resource tokens) than the software source of the library is allowed to grant. If this rule is violated, then a malicious library is able to misuse the credentials of the process, which it cannot get through legitimate means (manifest request and Device Security Policy restrictions).

The following figure illustrates the interaction diagram for the library loading case.

There is a new component called Library checker, currently implemented as part of Integrity Protection kernel module (Validator), which is called by the LSM hook on the mmap call. The main purpose of this component is to check that all the application’s credentials can be granted by the source of a library. It works as follows:

1. When an application tries to load a library, the kernel calls the mmap call to map the content of the library to the process memory space. At that moment, the LSM hook is called, and it calls the Library checker component.
2. Library checker checks the list of application’s credentials and allows the mapping of the library only if the library’s source can grant all the application’s credentials.
3. If the loading of a library fails, the kernel log gets an entry stating that the loading failed because of security reasons.

Another problem related to the loading of shared libraries: If there is a main program that does not need credentials to perform its task but loads many shared libraries that bring a new functionality (for example, extracting the contact information from the contacts database, or extracting the email information). Since the main program cannot know in advance the list of libraries that it would load, it does not know the list of credentials to declare in its Aegis manifest file. The Harmattan security framework solution to this problem is the following. Shared libraries also come inside Debian packages, and the package can contain the Aegis manifest file. If the library requires a credential that the main program does not have, it needs to request such a credential for the main program in its Aegis manifest file. The following figure illustrates the installation of such a shared library with an interaction diagram.

The installation process is very similar to the installation process of the application package. First, the package manager makes an intersection of requested credentials and allowed credentials for the package’s source. The resulting set can be called, for example, "LSet". This action is needed to check that the library source can grant the credentials that the library requests for the main program. However, this check can be omitted, since it would be automatically done by the Library checker component. The check is performed during the installation to prevent a library from adding unnecessary credentials to the main program, which it is not able to use anyway (since the main program is not able to load such a library). Afterwards, the package manager makes an intersection of LSet and the set of allowed credentials for the source of the main program. This check is needed in order to guarantee that the main program cannot indirectly get any credentials that cannot be granted by its source. The resulting set can be called "RSet". Finally, the package manager adds the RSet to the set of run-time credentials for the main program to the Credentials policy and installs the library. Restart the main program to get a new set of credentials.

After the restart of the main program, it tries to load its shared libraries again (including the one that was just installed), and the Library checker component verifies each loading of the library. It may happen that the new library has just added to the main program a credential that cannot be granted by the source of some old shared library. In this case, the old library cannot be loaded to the main program if it utilises the simplest policy. Unfortunately, such a feature can be used to perform a denial-of-service attack in which a malicious shared library tries to add a credential to the main program, which prevents the loading of some other shared libraries into the main program. The possible protection can include an additional check during the installation, in which Package Manager verifies the list of shared libraries that the main program needs to load, and, for example, gives a warning about the conflict between a new shared library and some of the old libraries.

If a shared library is about to be uninstalled, the credentials it requested for the main program are automatically removed from the Credentials policy of the main program by Package Manager.

Integrity Protection

As explained in Trusted Execution Environment (TEE) Services and the boot process, the integrity of software image is verified during the boot and after the kernel is booted, it is the responsibility of the Integrity Protection subsystem to verify the integrity of all user space components, and also some important configuration or data files, against possible run-time or offline modifications.

The main component of the Integrity Protection subsystem is the Validator kernel module, which primarily guarantees integrity of user space native executable content (libraries, binaries, and scripts) and kernel modules on the device during run time and between boot-ups. It also provides integrity protection for the configuration files if it has been specified in the Aegis manifest file. Validator stores on the device a list of reference hashes (initial hash values) for each component that is under its protection. The list is populated by Package Manager during the software package installation. Validator also has an internal Integrity Protection Policy, which defines an action if the integrity check fails. For example, it can block the execution of an application or lower its privileges. After verifying the reference hash list integrity, the validator-init user space component loads the reference hash list to the Validator kernel module during the operating system (OS) boot process.

During the packaging phase of an application, reference hashes are calculated automatically by a packaging tool, and written to a special file inside the Debian package. The procedure is as follows:

1. During the installation of a new application, Package Manager extracts these reference hashes from a package and adds them into the file that contains the list of reference hashes (1a).
2. Package Manager also adds the hashes directly to the Validator kernel module (1b).
3. During the OS boot process, the validator-init program verifies the integrity of the file with the reference hashes and loads them into the Validator kernel module(2).
4. When an executable (a binary, library, script, or kernel module) is loaded into the memory before execution for the first time, its hash will be computed by Validator and compared against the run-time reference hash (3-5). If a mismatch is found, the rules in the Integrity Protection policy are taken into account. Otherwise, the result of the check is cached. If there is an attempt to modify the executable, the information about this executable is removed from the cache. In this case, the next time it starts, the procedure of calculating a hash and a comparison against reference hash is done again.

The following figure illustrates this procedure:

Crypto Services

The Crypto Services subsystem provides an additional way to ensure the integrity and confidentiality of application data during run time and between the boot-ups. Crypto Services utilise the following TEE Services subsystem interfaces:

• Local cryptography services (encryption/decryption, signing/verification)
• Key Management

The access to the protected data can be defined in one of the following two ways:

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

The following figure illustrates on a high level the typical interaction scenario when an application protects the integrity of the data:

1. It calls the libaegis-crypto library API in order to compute a local message authentication code (MAC) over the data (1).
2. Then the libaegis-crypto transfers this request to a security driver (2) through libtee provided interface.
3. In turn (3), the security driver verifies if the application can perform the requested operation (if it has the necessary credential).
4. If it does, the MAC code is computed and returned to the application (4-5). From now on, every time the application requests to use the data (for example, if it stores the data in the filesystem), it can call the corresponding API in libaegis-crypto to check the integrity of the data. Afterwards, it is up to the application which actions are needed if the integrity check fails.

Certificate Manager

The Certificate Manager subsystem provides a 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 Harmattan (such as browser and mail) perform authentication of the remote party or, in the case of user's certificates and related private keys, authenticate a user towards some remote service. The main component of the Certificate Manger subsystem is a libaegis-certman library, which provides a user space interface for Harmattan applications in order to perform the actions described above.

When authenticating a remote service (for example, a web site or mail server), an application usually must be able to verify an X.509 signing certificate presented by this service. To do that, it needs to verify the authority that signed this certificate. This can be done by verifying the certificate signature against some known public key, which is stored inside another X.509 certificate, and so on. However, such a chain of certificates cannot be endless, which is why some certificates in this chain are usually self-signed certificates (also called root certificates), initially imported to the system and trusted by it. Thus, in order to verify a remote service's certificate, an application needs to retrieve a set of the system's self-signed root X.509 certificates and verify the presented certificate against this set through some certificate chain. The following figure illustrates a situation like that.

The browser application received an X.509 Certificate and needs to validate it. To do that, it uses the libaegis-certman interface to ask the set of the system's self-signed root certificates (1). Before returning the set of certificates to the browser application, libaegis-certman uses the libaegis-crypto to verify the integrity of the certificate store (2), which is done as described in Crypto Services (3). If the integrity is not compromised (4), the set of certificates is returned to the Browser application (5). Given the set of root certificates, the browser application can now verify the certificate by using the standard OpenSSL library functions.

Another typical use case for the libaegis-certman usage is the handling of user's private keys that can be used to authenticate a user and user's data to a remote service. The following figure illustrates that kind of a situation.

An email application requests to sign a user's mail for the mail server and thus needs to use the user's private key, which is stored in the certificate manager store. It requests the private key through the libaegis-certman library (1), which checks the protection method for the requested private key (2). If the private key is protected with a user passphrase, libaegis-certman requests it from the mail application (3). The mail application in turn requests it from the user (4) and returns back to the libaegis-certman (5), which decrypts the private key and returns it to the mail application (6).

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

Security aspects of 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 the software originated from a number of authenticated sources. This section provides the brief introduction to the main software distribution concepts.

Harmattan applications may come to Package Manager from different software sources, which can be either known or unknown. The notion of a "software source" is abstract: It can represent a different range of entities starting from software repositories, ending with individual developers who can publish signed software packets on their web pages. Package Manager has a list of known software sources and their public keys. Each software source has its trusted level, and the trusted level defines the software update rule. Packages that were installed from a software source with a higher trust level can only be updated from the same software source, or from a source which has a higher trust level. This update rule is used to ensure that more trusted software cannot be replaced by a less trusted one (even if the version is newer). In addition to the list of known software sources, Package Manager maintains one more software source, which is called "Unknown". All applications that cannot be considered to come from any known software source are considered to come from the "Unknown" source. The information about the software source of an application is preserved during the application lifetime.

Each Harmattan software source is supposed to check that its applications are not malicious, buggy, and so on. This can be done, for example, by running different tests and analysing the application. Note that it is almost impossible to make a formal verification for arbitrary software, especially since some software sources may only have an application binary to verify (for example, Nokia Store). However, the software source should do its best to find all possible software malfunctions. If the software source decides that a particular application is safe to be distributed, it signs the application with its own key (using either repository or package signing). The device security policy maintains a mapping between a list of known software sources and a set of credentials from a particular software source that can be at most granted to an application.

Device security policy

The device security policy defines the mapping between the software sources and a list of credentials that each software source can grant. The device security policy can be defined by the manufacturer or by the operator. It is assumed that some Quality Assurance (QA) process has been defined for the software source to check the applications that want to be distributed from that source. For simplicity, it is assumed here that the QA process is done by the software distributor, which is not always the case.

The Harmattan security framework can enforce different policies, ranging from the most strict to an open developer platform. The device owners define the device policy based on their needs and goals. Such flexibility enables a range of mobile devices that are aimed for different purposes but use the same security framework. For example, an operator may want a device to give the access to telephony functionality only to applications that originate from their own software source (for example, if a device was bought through a special operator's promotion). The flexibility of the device security policy makes it possible to give different access to the same application in devices with different security goals, and without any additional changes to an application.

Moreover, issuing updates of the device security policy allows faster reactions to different risk levels for the Harmattan platform. For example, if the risk to get malware for the Harmattan platform is currently quite low (due to the relatively small number of devices and restricted connectivity), the policy tries to protect only a small number of critical resources (such as telephony). However, if the situation changes (for example, a lot of malware is detected), the device security policy is updated to be stricter.

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, the following figure illustrates a Device Security policy that has two software sources defined: Nokia.com and Developer.org. The Nokia.com source can grant both Cellular and UserData resource tokens, while Developer.org only the UserData resource token. The Device Security Policy also always has a default software source, which is called "Unknown". If a package cannot be identified to belong to one of the known software sources (in this example case, it is either Nokia.com or Developer.org), then it is considered to originate from the "Unknown" source. The "Unknown" source has its own set of credentials (in this case, only "UserData" resource token).

Further information

For more information on security, see the following link:

• Security guide