Mobile Simplified Security Framework

© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK1

Mobile Simplified Security FrameworkMSSF

Dmitry Kasatkin, MeeGo devices, Nokia

OLS2010, Ottawa, Canada

14.07.2010


Agenda

• Security goals• Introduction• Chipset security & boot process• Integrity Protection• Access Control• Privacy Protection• Q&A


Security Goals

• Protection of the user• Disallow loss/stealing of owner's personal data

• E.g mallware sending user's contacts

• Miss-use of the device (unexpected costs)• E.g mallware sending sms to pay numbers

• Protection of the Device• Must meet regulatory requirements and specification

• Identity protection

• Disallow changing of RF, EM or WiFi tuning values


Security Goals

• Protection of the Business• Disallow braking of the SIM/Subsidy Lock

• Lose of business

• Limit what can be installed on the device• AT&T variant needs to stay AT&T variant

• To reduce fraud against Business• False service bills, Device cloning, back-door manufacturing

• Enable new services• Allow services such as Music store or App Store and support copy protection• Mobile payments and Billing


Security Framework – multilevel model

• Protect the entire platform using multiple technologies

• Chipset Security• secure cryptographic services for OS level security

• Integrity protection• Ensure protection of TCB, applications and data

• Access Control• Limits application access to critical resources

• Application privacy protection• Provides integrity and confidentiality protection for

applications and services

• Security Framework relies on the secure software distribution model.

• Ensures the authentication of a package's source.

Device

Access Control

Integrity Protection

Privacy Protection

Chipset Security

Secure S W

dist ribution


Device Modes

• Normal Mode – default• Access Control and integrity protection is enforced by the security policy• Unauthorized modification of the security policy is not allowed.• Device Keys are available

• Access to Services, Games, etc...• Optional Copy Protection

• Developer Mode• Enables low-level development and customization• Compile and flash your own kernel• Allows to modify security policy to access more resource without certification• Some functionality is limited

• Limited access to device keys• No access to protected content


Chipset Security


Chipset Security

• Chipset security is the key subsystem whole platform security relies on• Provides tamper resistant secure services similar to TPM• Provides

• Root symmetric device specific key• Is used to derive keys used for local cryptography operations• Is used to derive unique public identifier of the device

• Root Public Key• Is used to verify that software packages are coming from trusted source

• Trusted Boot• Verify integrity of the bootloader and SW image using Root Public Key

• Secure Services• Secure key management and cryptographic services

• Provides Secure Execution Environment (SEE)• It consists of secure ROM and RAM that is isolated from rest of the system to allow

execution of integrity protected applications for protected storage and DRM


Boot Process

• Boot ROM verifies Bootloader integrity using Root Public Key

• Bootloader verifies kernel image using Root public key

• If failed, checks SIM/Subsidy lock

Boot ROMBoot ROM

BootloaderBootloader

Checkbootloader Reset

CheckKernel SIM Locked

BootBootNormal ModeNormal Mode

BootBootOpen ModeOpen Mode

Failed

ok

ok

Failed

yes

no

RestrictRestrictSecurity functionalitySecurity functionality

Open modeallowed?

no

yes


Integrity protection


Integrity protection – Validator

• Protects integrity of kernel modules, executables, libraries and data files.• Primary goal is to protect components belonging to TCB• The Validator maintains a reference hash list of all protected files

• Includes SHA1, file attributes, and AC related data• Protected by the device specific signature

• Debian packages contains SHA1 hashes of files to be protected• Application Manager updates reference hash list upon package installation,

removal or upgrade• Integrity protection policy defines action when integrity verification fails –

currently blocks the execution• Validator has support for integrity protection of non-modifiable data files for

protecting critical configuration files


User spaceUser space

Integrity subsystem components

• Application Manager• installs new binaries and updates

reference hash list

• Validator-init• Loads new or updated reference hash

list into the kernel

• Validator• LSM module• Is called upon execve() or mmap()• calculates and compares hash and file

attributes.• Verification results are cached

Linux KernelLinux Kernel

PackagePackageManagerManager

ValidatorValidatorInitInit

1

2.1

ValidatorValidator LauncherLauncher

2.2

ReferenceHash List

3


Access Control


Design Goals

• Classical UNIX DAC• Multi user model – protect users from each other• POSIX capabilities are not really in use – root does everything• No process based access control

• MSSF Design goals• Process-based access control to protected resource

• protect processes from each other

• Minimal changes to the default Linux model• No need for centralized security policy

• Protected resource• virtual object which represents some functionality or data, such as tasks, files,

sockets, devices.


Credentials

• Traditional Linux credentials consist of UIDs, GIDs and POSIX capabilities• MSSF Access Control extends it with resource tokens and application identifier• Resource tokens

• Strings, naming protected resources – similar to labels in other security frameworks• Global: UserData, Cellular, Location, etc• Package specific: my-package::access

• Application ID• It is used to derived application specific cryptographic keys• Defined as: AppID = {SourceID, Package, Application Name}

• AppID = {ovi.com, CoolTools, AddressBookPlugIn}

• Properties: Unforgeable, unique, persistent.• Application name is given in Manifest file (optional)

• Applications declare provided and requested credentials in the Manifest file that is included in the package


Access Control framework components

• Manifest file• Manifest file is included to the package and contains list of executables and its credentials.• Additionally device security policy updates, integrity protection related information

• Device security policy• Located on the device and defines SW source trust level and credentials, which can be granted

to packages coming from that repository.

• Credentials policy• It is a file which contains mapping of credentials to executables. Package Manager updates

this file when packages are installed, upgraded or removed.

• Package Manager• In addition to installing the application, Package Manager updates Credentials Policy

database.

• Credentials policy loader• It is called during boot to read and import credentials policy into the kernel.

• Credentials Manager (kernel modules)• Provides credentials management and assignment to the process.


Manifest File

• Manifest file is provided with the package and defines credentials and policies for the package.

• Manifest file is written in XML and defines tags, such as:• <request> - requested credentials• <provide> - Provided credentials:• <credential name=“credential name”> - credential name• <for path=“path”> - absolute path to the executable• <dbus name=“dbus service name”> - D-bus service name:• <bus=“bus type”> - D-bus type (system or session)• <own=“credential name”> - Credential to bind to a specific d-bus service name• <interface name=“interface name”> - D-Bus interface name

• Package manager updates Credentials Policy based on the Manifest File and constraints from the Device Security Policy


Manifest file examples

• Server defines resource token UserData needed to access the server<mssf>

<provide>

<credential name="UserData" />

</provide>

</mssf>

• Client declares that it requires tokens UserData and Cellular<mssf>

<request>

<credential name="server-pkg::UserData" />

<credential name="Cellular" />

<credential name="CAP::net_admin" />

<for path="/usr/bin/userdatamanager"/>

<for path="/usr/bin/userdataclient"/>

</request>

</mssf>

• Both applications will get the same credentials


Device Security Policy

• Provides mapping between SW sources and allowed credentials• Contains entries for repositories in the format:

• {SourceID : Trust Level : Public Key : Allowed credentials}

• Where• SourceID is the name of the repository, e.g in a form of domain name• Trust Level is a number defining ranking of the repository. Packages can only

be updated from repository which has the same or higher trust level.• Public Key is a repository key to use for package verification• Allowed credentials is a list of credentials, which can be granted by this

repository.

• Example• {meego.com : 1 : ABCDEF : UserData, Cellular}

• Package manager verifies if all credentials from Manifest file can be granted


Credentials Policy

• A file which contains mapping of credentials to executables.• Produced from Manifest file and Device Security policy (intersection rule)• Package Manager updates this file when packages are installed, upgraded or

removed• Example Package: bluez

Source: com.nokia.maemo

Request:

CAP::net_bind_service

CAP::net_admin

CAP::net_raw

CAP::ipc_lock

Cellular

GRP::phonet

Object: /usr/sbin/hciconfig

Object: /usr/bin/hcitool

Object: /usr/bin/sdptool


Package Installation

1. Package comes with Manifest2. Package Manager checks the Device

Security policy for the information3. Package Manager updates the

Credentials Policy according to the ”Intersection rule”

4. Package Manager possibly updates D-Bus policy

5. Package Manager updates runtime credentials policy in the kernel.



PackageManager

1

2

3

Package Manifest

SecurityPolicy

CredentialsPolicy

DBUSPolicy

4

RuntimeCredentials

Policy

5

CredentialsManager


Startup

1. Credentials policy loader loads credentials policy to the kernel at boot

2. Upon application startup, Policy Manager modifies process’ credentials according to the policy.

3. File AC● Validator checks process credentials

using kernel API

4. D-Bus● D-Bus daemon checks client

credentials using libcreds

5. Client-server● Application checks client credentials

using libcreds



PolicyLoader

1.1

2

3

CredentialsPolicy

DBUSPolicy

4

RuntimeCredentials

Policy

Modify CredentialsManager

ProcessCredentials

LinuxReference

Monitor

Object ACL

DBUSdaemon

1.3

1.2

Application

5


Credentials API – libcreds

• Allows the server to read the credentials of the client process and to perform the desired credential checks.

• Policy enforcement is done at application side

• Example

int foo(){

creds_value_t value;creds_type_t type;require_type = creds_str2creds("UserData", &require_value);fd = accept(sockfd, &cli_addr, &clilen);ccreds = creds_getpeer(fd);allow = creds_have_p(ccreds, require_type, require_value);if (allow) write(fd, MESSAGE("GRANTED\n"));else write(fd, MESSAGE("DENIED\n"));

}


Kernel implementation

• Kernel modules:• Restok

• Provides a persistent mapping of strings to unique dynamically assigned identifier numbers. The generated identifiers are used as supplementary group numbers in the task structure and provide additional, dynamically configured credentials for processes.

• Credp• Provides credentials management and assignment to the process.• Registers a hook to: security/commoncap.c:cap_bprm_set_creds()

• Operations: credp_kload, credp_kunload, credp_kconfine, credp_kset.

• Creds• Provides an API for user space access control in client/server architecture. It allows

the server a way to read the credentials of the client process and to perform the desired credential checks

• Operations: creds_kget, creds_kcreds2str, creds_kstr2creds, creds_khave_p.


Privacy protection


Protected Storage & SecureFS

• Provides integrity and confidentiality protection• Allows to protect Security policies, certificates, configuration files• API based solution

• Storage types• Global / Private / shared• Signed / Encrypted

• Uses cryptography• Application specific key: K(AppID, device key)• Shared key: K(resource token, device key)

• SecureFS• FUSE-based file system to use standard file API• Manifest file contains description of mount points and their protection properties• Under development


Conclusions & Future work

• MSSF is a light-weight alternative to heavy security frameworks for mobile devices, provides complete end-to-end security infrastructure and is based on secure SW distribution.

• Future work• Access Control

• Socket protection under development• Resource token based file system access control is missing

• Integrity protection• When EVM comes to the kernel, it looks like possible alternative to MSSF Validator

solution


Q&A

• Public project on• http://meego.gitorious.org/meego-platform-security• Kernel, libraries

Thank You

http://meego.gitorious.org/meego-platform-security


Extra slides


Linux Kernel Security Implementations

• Classical UNIX DAC• Multi user model – protect user from one another• POSIX capabilities are not really in use – root does everything• No process based access control

• SELinux• Domain Type Enforcement (DTE)• Requires complex and centralized policy administration

• Tomoyo• Path-based access control• Utilizes “process invocation history” and requires administrative actions not

applicable for mobile device

• Smack• Simple MAC implementation• Uses labels to attach to components and applies access rules between the labels

defined by administrator


Manifest for Device Security Update<aegis>

<domain name=“MyDomain" rank="30">

<allow>

<credential match="*"/>

<deny>

<credential name="drm"/>

</deny>

</allow>

<origin>

<keyinfo>

mQGiBEO6XBMRBACFyO

</keyinfo>

</origin>

</domain>

</aegis>


DBUS Manifest example - server

• Server<aegis>

<provide>

<credential name="access" />

<dbus name="com.maemo.Aegis.example" own="aegis-dbus-server" bus="session">

<node name="/">

<interface name="Aegis.Example">

<annotation name="com.maemo.secure.Access" value="access"/>

</interface>

</node>

</dbus>

</provide>

<request>

<for path="/usr/bin/aegis-dbus-server" />

</request>

</aegis>


DBUS manifest example - client

• Client<aegis>

<request>

<credential name="aegis-dbus-server::access" />

<for path="/usr/bin/aegis-dbus-client" />

</request>

</aegis>


DBUS generated policy

•<busconfig>

<policy context="default">

<deny own="com.maemo.Aegis.example"/>

</policy>

<policy creds="aegis-dbus-server::aegis-dbus-server">

<allow own="com.maemo.Aegis.example"/>

</policy>

<policy context="default">

<deny send_destination="com.maemo.Aegis.example" send_interface="Aegis.Example"/>

<deny receive_sender="com.maemo.Aegis.example" receive_interface="Aegis.Example"/>

</policy>

<policy creds="aegis-dbus-server::access">

<allow send_destination="com.maemo.Aegis.example" send_interface="Aegis.Example"/>

<allow receive_sender="com.maemo.Aegis.example" receive_interface="Aegis.Example"/>

</policy>

</busconfig>


More examples

•<aegis>

<request>

<credential name="UID::email" />

<credential name="GID::email" />

<for path="/usr/bin/aegis-dbus-server" />

</request>

</aegis>

Mobile Simplified Security Framework

Technology

Transcript of Mobile Simplified Security Framework