Transcript 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.

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:
– 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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Notes:
•
•
•
•
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.
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
Conf
doc
Trust
Policy
cert
Dig Signature
1. navigator.device.CredAPI.get(CredId_1)
2. GetTrustAttributes
3. GetTrustDomain(TrustAttributes, TrustPolicy)
Returns OriginURl, Certificate,
Digital Signature, Conf Doc,etc
Content Engine
Returns TrustDomain_Man +
AppId_a
Trust Manager
Access
Policy
5. Access allowed? (TrustDomain_Man, AccessPolicy)
Access Manager
Returns Allowed/
NotAllowed
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
4. GetSecureCred(CredId_1, TrustDomain_Man,
AppId_a)
Secure Credentials API
6. Credential = Get (AppId_a, CredID_1)
Returns “Credential_a1 “, which will be a callback to
navigator.device.CredAPI.get
Secure Credential Database
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”
Logical flow for a “Secure Credential
Manager JS API” use case
1.
2.
3.
4.
5.
6.
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.
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?