1 / 6

Fine Granularity Policy Based Device Access Security

Fine Granularity Policy Based Device Access Security. Claes Nilsson - Sony Ericsson 2009-12-18. Content of presentation. A proposal for “Fine Granularity Policy Based Device Access Security”. This is response to ACTION-38: “Should issue recommendation on the granularity of the security system”.

reba
Download Presentation

Fine Granularity Policy Based Device Access Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Fine Granularity Policy Based Device Access Security • Claes Nilsson - Sony Ericsson • 2009-12-18

  2. Content of presentation A proposal for “Fine Granularity Policy Based Device Access Security”. This is response to ACTION-38: “Should issue recommendation on the granularity of the security system”

  3. Use cases • In a file API access to certain data is restricted to certain applications • In a file or contacts API differentiation based on application identity between "read-only" and “read and write” access • A "Secure credential manager“ for retrieving API-keys used for application log in to social networking web services

  4. Proposal for “Fine Granularity Policy Based Device Access Security” • Based on “Policy Based Device Access Security” (Steve Lewontin/Nokia http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/att-0012/SecurityPolicy_09.pdf) • Added finer granularity to restrict access to APIs based on application identity • Assumptions: • The origin and integrity of the web application can be securely verified. Examples: • Signed web widget • Web application accessed through SSL/TLS • The identity of the web application can be securely verified. Examples: • The application identity isincluded in a widget's (signed) configuration file (assumes some kind of centralized widget signing) • The application identity is included in a widget's certificate (makes distributed signing possible)

  5. Web Execution Environment Dig Signature Web Application , e.g. Widget package html CSS JS Confdoc Trust Policy cert 1. navigator.device.API.method(Params…) 2. GetTrustAttributes Trust Manager Content Engine 3. GetTrustDomain(TrustAttributes, TrustPolicy) Returns OriginURl, Certificate,Digital Signature, Conf Doc,etc Returns TrustDomain + AppId AccessPolicy 4. CallAPI (Params…, TrustDomain,AppId) 5. Access allowed? (TrustDomain, Access Policy) Access Manager “Device API” Returns Allowed/ NotAllowed 6. Result = AccessDeviceFunc (AppId, Params….) • Assumptions: • The origin and integrity of the web application can be securely verified. • The identity of the web application can be securely verified. Returns “Result “, which will be a callback to navigator.device.API.method( “Device functionality to be accessed with the granularity of AppId”

  6. Logical flow for “Fine Granularity Policy Based Device Access Security” • The web application, e.g. a signed web widget, accesses device functionality that is restricted to this specific application. • The content engine loads the content and gets any needed content trust attributes, e.g. the origin URL, the digital signature, the certificate, the configuration document etc. • The content engine queries the trust manager to get the trust domain of the content and the application identity, passing the relevant trust attributes, and the path to the appropriate trust policy to the trust manager. The actual name/id of the application could for example be included in a widget's (signed) configuration document (assumes some kind of centralized widget signing) or it could be included in the certificate (makes distributed signing possible). The application’s name/id must be relative to the origin of the application, typically the PKI-identity, e.g. the Certificate Authority (CA) of a signed widgets certificate. This means that the CA must coordinate the application names/ids . So, an application identity (AppId) consists of two parts:- Origin of the application, typically the PKI-identity- Actual name/id of application • The content engine makes an API request, passing relevant parameters and the trust domain and application id to the device API implementation. • The device API implementation creates a security session with the access manager, passing the path to the appropriate access policy and the content trust domain. The device API implementation asks the security manager for an access decision (via the security session) passing the required capabilities. • Based on the result of the access control decision, the service invokes the requested operation, passing the application id, or throws a security exception. The “Device Functionality” will only open up the part that is available for this application according to the application id.

More Related