1 / 8

Secure Credential Manager

Secure Credential Manager. Claes Nilsson - Sony Ericsson 2009-12-15. Content of presentation. A proposal for a “Secure Credential Manager” for web applications using “Fine Granularity Policy Based Device Access Security”. Secure Credential Manager. Motivations:

tal
Download Presentation

Secure Credential Manager

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. Secure Credential Manager • Claes Nilsson - Sony Ericsson • 2009-12-15

  2. Content of presentation A proposal for a “Secure Credential Manager” for web applications using “Fine Granularity Policy Based Device Access Security”

  3. Secure Credential Manager • Motivations: • Many web services, e.g. Social Networking Services, enforce application authentication by requiring an API key (credentials) to be able to access APIs . • To achieve a high secure solution the credentials are not recommended to be deployed in the application itself, instead the credentials must be stored securely outside the application. • A Secure Credential Manager is used to manage the secret credentials and the credentials are retrieved by Web Applications using a JavaScript API.

  4. Typical use case for “Secure Credential Manager” • The social web site Happy Social lets Mr Good create Happy Social Web Widget • To give access to a number of web APIs the Happy Social Web Widget needs to login to the Happy Social web site using a secret API key (“Credentials”). • When Mr Good has created the widget it is submitted to the "authorities" of Happy Social that reviews the widget to check that the widget is not doing anything evil. If ok the widget is signed, which means that all content of the widget is integrity protected. • The widget is placed at an appropriate application store to be available for download • Ella is downloading the widget into her brand new W3C DAP capable handset • The W3C DAP policy framework is used to verify that the widget is allowed to access the “Secure Credential Manager" API. • Each data entry in the " Secure Credential Manager " contains: • AppId (Id for the application that is allowed to access this data) • CredId • Credential • This data has been pre-provisioned into the device (might be a subject for later standardization) • The widget's digital signature is verified. If the signature is valid the identity of the widget is used to give access to the correct entry in the “Secure Credential Database". The identity of the widget could be included in the widget's configuration file but that assumes some kind of centralized widget signing or it could be included in the certificate, which makes distributed signing possible. • The secret API-key (“Credential”) is retrieved from the " Secure Credential Database" and used for application login to access APIs at the Happy Social site. All security issues during the transport is out of scope for this discussion but would typically mean TLS/SSL or any other means for secure transport. Notes: • It is assumed that Mr Good is responsible and implements the widget so that it does not download code from any unreliable site. If this is not the case the widget shall not be approved and signed. • Any attempts for Mr Good, turning out to be evil, to change the widget after it has been approved and signed will fail as the device will find the signature invalid. • Any attempts from Mr Evil to copy the widget and change the content will fail as the device will find the signature invalid. • It is a basic assumption that the platform on which this API is implemented provides application memory protection so that applications are prevented from accessing other application's entries in the "secure data storage".

  5. Proposal for support of “Secure Credential Manager” for web applications • Based on proposal for a “Fine Granularity Policy Based Device Access Security” • Assumptions: • The device platform provides sufficient application memory protection for web applications

  6. Web Execution Environment Dig Signature Web Application , e.g. Social App Widget package html CSS JS Confdoc Trust Policy cert 1. navigator.device.CredAPI.get(CredId_1) 2. GetTrustAttributes Trust Manager Content Engine 3. GetTrustDomain(TrustAttributes, TrustPolicy) Returns OriginURl, Certificate,Digital Signature, Conf Doc,etc Returns TrustDomain_Man + AppId_a AccessPolicy 4. GetSecureCred(CredId_1, TrustDomain_Man,AppId_a) 5. Access allowed? (TrustDomain_Man, AccessPolicy) Access Manager Secure Credentials API Returns Allowed/ NotAllowed 6. Credential = Get (AppId_a, CredID_1) • Assumptions: • The origin and integrity of the web application can be securely verified. • The identity of the web application can be securely verified. • The device platform provides application memory protection Returns “Credential_a1 “, which will be a callback to navigator.device.CredAPI.get AppId_a CredId_1 “Credential_a1” AppId_a CredId_2 “Credential_a2” AppId_b CredId_1 “Credential_b1” Secure Credential Database Data provisioned by some “out of band method”

  7. Logical flow for a “Secure Credential Manager JS API” use case • The web application, e.g. a signed Social Networking Service web widget, contains a call to the Secure Credential API with the identity of the required credential (CredId_1 in this example) as input. • 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 id, passing the relevant trust attributes, and the path to the appropriate trust policy to the trust manager. The application id (AppId_a in this example) could for example be included in a widget's (signed) configuration (assumes some kind of centralized widget signing) or it could be included in the certificate (makes distributed signing possible). In this example it is assumed that the trust domain is TrustDomain_Man (“manufacturer”) • The content engine makes a call to the Secure Credentials API, passing CredId_1, TrustDomain_Man and AppId_a as input parameters. • The Secure Credentials API implementation creates a security session with the access manager, passing the path to the appropriate access policy and the TrustDomain_Man. The Secure Credentials 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 Secure Credentials API implementation invokes the requested operation towards the Secure Credential Database, passing AppId_a and CredId_1 as parameters, or throws a security exception. The Secure Credential Database will return Credential_a1 that will chain back and give a callback to the original JS call.

  8. Questions / Issues • The JavaScript execution environment has a dynamic nature and security limitations. Consider e.g. section 3.1 in http://lib.tkk.fi/Dipl/2009/urn100073.pdf • It is proposed to reference existing security mechanisms (Digital signing, TLS/SSL, WARP, etc) for a JS API to a “Secure Credential Manager”. • Should the “Secure Credential Manager” be an API of its own or should it be the “File API” accessed with the granularity of AppId?

More Related