Secure Credential Manager Claes Nilsson - Sony Ericsson

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: – 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.

Typical use case for “Secure Credential Manager” 1.The social web site Happy Social lets Mr Good create Happy Social Web Widget 2.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”). 3.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. 4.The widget is placed at an appropriate application store to be available for download 5.Ella is downloading the widget into her brand new W3C DAP capable handset 6.The W3C DAP policy framework is used to verify that the widget is allowed to access the “Secure Credential Manager" API. 7.Each data entry in the " Secure Credential Manager " contains: – AppId (Id for the application that is allowed to access this data) – CredId – Credential 8.This data has been pre-provisioned into the device (might be a subject for later standardization) 9.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. 10.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".

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

Web Execution Environment Web Application, e.g. Social App Widget package html CSS JS Dig Signature cert Conf doc Content Engine 2. GetTrustAttributes Returns OriginURl, Certificate, Digital Signature, Conf Doc,etc 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 Trust Manager 3. GetTrustDomain(TrustAttributes, TrustPolicy) Secure Credentials API 4. GetSecureCred(CredId_1, TrustDomain_Man, AppId_a) Access Manager 5. Access allowed? (TrustDomain_Man, AccessPolicy) Returns TrustDomain_Man + AppId_a 1. navigator.device.CredAPI.get(CredId_1) Returns Allowed/ NotAllowed 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” Data provisioned by some “out of band method” Secure Credential Database Trust Policy Access Policy

Logical flow for a “Secure Credential Manager JS API” use case 1.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. 2.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. 3.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”) 4.The content engine makes a call to the Secure Credentials API, passing CredId_1, TrustDomain_Man and AppId_a as input parameters. 5.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. 6.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.

Questions / Issues The JavaScript execution environment has a dynamic nature and security limitations. Consider e.g. section 3.1 in – 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?