1) The document discusses platform security for the Maemo 6 operating system. It describes mechanisms like access control, hardware enablers, and integrity protection to secure the software platform. 2) Access control is based on a classical Unix multi-user model extended with application-level controls. Applications must declare needed resources in a manifest file. 3) Integrity protection validates executables against reference hashes stored securely to prevent offline attacks.

1. Maemo 6 Platform Security
Principles and Building blocks
Elena Reshetova
Senior Security Engineer, Nokia
1

2. What is Platform Security?
Set of a mechanisms and techniques, which
are used to protect the entire SW platform
2

3. Device modes
• Open source strategy • Bigger developer offering
• Easy to program for a device • Optional copy protection (DRM)
• The same functionality as earlier • More use cases for a device usage
• Compile and flash your own kernel • Games, Commercial applications
• Made a low-level platform development • More business models
• Ovi Store
• Comes with Music
3

4. Access control in Linux
• Classical Unix AC
• Based on multiuser model
• POSIX capabilities aren’t really in use (root has all, others none)
• Our criteria:
• Process level access control needed
• Minimal changes to the current model (enforcement phase)
• Good level of flexibility and granularity, easy to understand concept (KISS)
• Existing security extensions, no good match to criteria
• FreeBSD AC, MLS, Biba, SELinux, RBAC, AppArmor, TOMOYO Linux, …
• Our approach:
• Apply, and minimally extend Classical Unix AC to meet set criteria
• Re-use multiuser-model for application-level access control
• Architecture outlined in the next slides
4

5. Hardware enablers & Boot process
Nokia Signed
• Trusted Execution Environment SW Image
(TrEE) (for instance ARM Trust
Zone) with two main keys: Restrict security
functionality *
Reset
• Root public key
• Root device specific key
No
Device
SIM Locked?
Integrity is OK
• * includes:
• DRM keys are disabled
• Content from the previous mode
can’t be decrypted Integrity isn’t OK
5

6. Access Control
• Principle of least privileges
• Every application should be able to access
only limited set of needed resources
• Protected resources
• Things like Cellular functionality, Location and so on
• No final list yet
• Possibility to introduce new protected resources
• Application must declare resources, it needs
• Aegis Manifest File
• No security APIs by default Development is almost unchanged
• Complicated things are automated
6

7. Device Security Policy
• SW gets its rights based on its source Resource 1 Resource 1 Resource 2
Resource 2 Resource 3 Resource 3
and Aegis Manifest File
Create Aegis Manifest
Put your SW to a suitable repository/source
• Quality assurance (QA) checks in the Ovi Store maemo.org ... Source N
repositories
• Aegis Security Policy file
• accessible only for installer
• contains mapping between SW sources
and allowed resources
7

8. Privacy Protection - Aegis Protected Storage
• Ensures integrity of data and
configuration files after installation Place the files
into Protected
• Additional features: Storage
• Data encryption inside the storage
• Private, shared and global or externally
signed storages
Aegis
• Interface to TrEE, which is used to Protected
sign/verify, encrypt/decrypt the data Storage APIs
• Access to a protected storage is defined
by an application identifier or application
group
8

9. Integrity protection – Aegis Validator
Application
• Ensures integrity of the executable binary
components (binaries, libraries, ...)
• Run-time Yes
• Against Offline attacks
• Kernel module
• Calculates a cryptographic hash of the
executable (currently SHA-1)
• Reference hashes are stored in the No!
Aegis Protected Storage Get the
policy
9

10. • Most of the Security FW will be open sourced
• Your feedback and reports are welcome: elena.reshetova@nokia.com
10