Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Maemo 6 Platform Security

This is a presentation on the concepts of the Maemo 6 platform security, which will enable more mainstream content business.

  • Login to see the comments

Maemo 6 Platform Security

  1. 1. Maemo 6 Platform Security Principles and Building blocks Elena Reshetova Senior Security Engineer, Nokia 1
  2. 2. What is Platform Security? Set of a mechanisms and techniques, which are used to protect the entire SW platform 2
  3. 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. 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. 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. 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. 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 ... Source N repositories • Aegis Security Policy file • accessible only for installer • contains mapping between SW sources and allowed resources 7
  8. 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. 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. 10. • Most of the Security FW will be open sourced • Your feedback and reports are welcome: 10