Upload
elena-reshetova
View
1.347
Download
4
Embed Size (px)
DESCRIPTION
The overall architecture description of Mobile Simplified Security Framework
Citation preview
© 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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK2
Agenda
• Security goals• Introduction• Chipset security & boot process• Integrity Protection• Access Control• Privacy Protection• Q&A
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK3
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK4
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK5
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK6
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK7
Chipset Security
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK8
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK9
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK10
Integrity protection
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK11
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK12
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK13
Access Control
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK14
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.
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK15
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK16
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.
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK17
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK18
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK19
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK20
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK21
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.
User spaceUser space
Linux KernelLinux Kernel
PackageManager
1
2
3
Package Manifest
SecurityPolicy
CredentialsPolicy
DBUSPolicy
4
RuntimeCredentials
Policy
5
CredentialsManager
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK22
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
User spaceUser space
Linux KernelLinux Kernel
PolicyLoader
1.1
2
3
CredentialsPolicy
DBUSPolicy
4
RuntimeCredentials
Policy
Modify CredentialsManager
ProcessCredentials
LinuxReference
Monitor
Object ACL
DBUSdaemon
1.3
1.2
Application
5
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK23
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"));
}
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK24
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.
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK25
Privacy protection
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK26
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK27
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK28
Q&A
• Public project on• http://meego.gitorious.org/meego-platform-security• Kernel, libraries
Thank You
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK29
Extra slides
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK30
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
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK31
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>
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK32
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>
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK33
DBUS manifest example - client
• Client<aegis>
<request>
<credential name="aegis-dbus-server::access" />
<for path="/usr/bin/aegis-dbus-client" />
</request>
</aegis>
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK34
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>
© 2010 Nokia / Mobile Simplified Security Framework / OLS 2010 / 14.07.2010 / DK35
More examples
•<aegis>
<request>
<credential name="UID::email" />
<credential name="GID::email" />
<for path="/usr/bin/aegis-dbus-server" />
</request>
</aegis>