Mobile Security Framework

Mobile Simplified Security Framework
MSSF

Dmitry Kasatkin, MeeGo devices, Nokia
OLS2010, Ottawa, Canada
14.07.2010

1 © 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK

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
Device
• Protect the entire platform using multiple

Secure SW distribution
technologies Privacy Protection

• Chipset Security Access Control
• secure cryptographic services for OS level security
Integrity Protection
• Integrity protection
• Ensure protection of TCB, applications and data Chipset Security
• 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 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

• Boot ROM verifies Bootloader integrity
using Root Public Key Failed
Check
Reset
• Bootloader verifies kernel image using bootloader

Root public key ok no
• If failed, checks SIM/Subsidy lock yes
Bootloader Open mode
allowed?

yes
Failed
Check
SIM Locked
Kernel

ok no

Restrict
Security functionality

Boot Boot
Normal Mode Open Mode

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


Integrity subsystem components
• Application Manager User space
Package
• installs new binaries and updates Manager

reference hash list 1
2.1
• Validator-init Validator Reference
Hash List
Init
• Loads new or updated reference hash
list into the kernel
2.2
• Validator
• LSM module Linux Kernel

• Is called upon execve() or mmap() 3
Validator Launcher
• calculates and compares hash and file
attributes.
• Verification results are cached


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 Manifest
Manifest
2. Package Manager checks the Device Package

Security policy for the information
1
3. Package Manager updates the
User space
Credentials Policy according to the Security 2 Package
Policy
”Intersection rule” Manager

4. Package Manager possibly updates D- 4 3
Bus policy
DBUS Credentials
5. Package Manager updates runtime Policy Policy
credentials policy in the kernel.

Linux Kernel 5
Runtime
Credentials Credentials
Policy Manager


Startup
1. Credentials policy loader loads User space
credentials policy to the kernel at boot
DBUS Credentials
2. Upon application startup, Policy Policy Policy

Manager modifies process’ credentials Application 1.1
according to the policy.
DBUS Policy
3. File AC 5 daemon Loader

●
Validator checks process credentials
using kernel API 1.2
Linux Kernel 4
4. D-Bus
Process Modify Credentials
●
D-Bus daemon checks client Object ACL
Credentials Manager
2
credentials using libcreds 1.3
3
5. Client-server Linux Runtime
Credentials
●
Application checks client credentials Reference
Monitor Policy
using libcreds


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("GRANTEDn"));
else
write(fd, MESSAGE("DENIEDn"));
}


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


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 Security Framework

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Mobile Security Framework

Ähnlich wie Mobile Security Framework (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Mobile Security Framework