Hardware based Secure Services CG : report from the London workshop

_The Hardware Based Secure Services Community Group met on the 26th and 27th of April at Morrison & Foerster’s offices in London. 30 people representing 15 companies and universities were present as outlined in the list below. For the two days of the workshop, the group discussed the opportunity for browsers to integrate secure services offered by hardware technology (such as secure elements and trusted execution environments (TEEs)). The discussion covered the use cases, technical constraints, the user perspective and potential technical solutions. _

Summary of findings:

Use cases

The increasing demand from service providers and users to have more guarantees and indication with respect to the security associated with services is a clear trend. The following use cases were listed as having a particular strong expectation in that area: (1) Authentication for the secure management of webmail, web services and VPNs in corporations or in governments, (2) Improving security and usability in online citizen services by reducing password usage (replaced by cryptographic tokens) and improving the trust in user input and output (thanks to trusted UI), (3) Improve use cases such as citizen or consumers recording information, signing and voting steps on line, (4) Identity management: creating an identity credential, update a profile, renew credit, with an adapted procedure in terms of security (i.e. adapting the procedure to the security level), including proof of possession and knowledge, (5) Signatures for legal binding or for users who wish to have verified public posts (comments on social media, applications etc.), including a delegation model (citizen and attorney, consumer and agency etc.).

In addition it was discussed that many hardware based technology and devices were available in today’s web-connected devices such as UICCs, embedded secure elements, trusted execution environments, secure chips and NFC readers. At the same time some removable hardware devices are used. The usage of these technologies for services, or for offering services to app developers is gaining momentum. ApplePay, Trusty in Android, biometric APIs, secure key management backing in hardware APIs and secure enclave all represent the wide range of examples in the market now amongst others available.

This technology will assist the open web platform in retaining its leading position, by offering similar functionalities, especially while the security expectation from users and service providers is increasing. It will also serve to bolster web platform security in its own right.

Identifying Specific Features

The group decided to focus on two specific technology pieces, generating beta APIs. Both features would support the use cases outlined above. These were:

1. Transaction Confirmation API
2. Secure Credential Storage

Feature 1: Transaction Confirmation This feature allows a web application to trigger a user confirmation based on a secure user interface, including a specific message such as “do you want to digitally sign this transaction?”. It would also allow the request of security information about the context of execution. Suggested code and a flow are in draft and available here: https://github.com/w3c/websec/blob/gh-pages/hb-secure-services/etherpad-04-26-27.md

Editor : Sébastien Bahloul

Feature 2: Secure Credential Storage This feature allows the generation, usage and administration of a credential such as a key. It includes some additional information allowing for management, including access control rules, lifecycle and renewal. A suggested flow is available at: https://github.com/w3c/websec/blob/gh-pages/hb-secure-services/etherpad-04-26-27.md

Editor: To be agreed

Liaison with other W3C work and groups Liaison is expected with the following W3C groups: Web Authentication WG, Web Payment WG, Web Crypto WG, Web App Sec WG,

Initial Requirements

The following is an initial set of technical and security requirements, applying to both features:

• Virtualize the credentials available in hardware, being agnostic in terms of the technology used (e.g. secure chip, TEE, with any physical link supported). • Let the user choose the credentials in hardware based technology he/she wants to use. • Give clear security indication to the service provider and to the user (i.e. generate an indication of the security level across a large set of components in the stack which help to store, execute and present a transaction). • Allow the browser to qualify the security context for operation execution and display, and keep the information consistent and safe. • Re-use existing technology e.g. token access control, Same Origin Policy (SOP), Content Security Policy (CSP) etc. • Prevent any re-use of bearer tokens, replay attacks, all major state-of-the-art software attacks, time-stamp (if used) abuse, semantic attack etc. • Request user consent for service requests relying on hardware based technology owned by the user, permit user control over usage/non-usage, including the ability to change that decision at any time. • Credential handling should support a chain of trust (i.e. be able to manage delegation of trust, between user, representative and issuer). • Credentials should have a set of information associated easing lifecycle management and authorisations (but not limited to the X.509 certificate model). • Manage errors gracefully such as denying domain access, user not permitting access, invalid keys (validation, black list, etc.), network latency, etc. • Take into account accessibility practices, for example making sure the security context is explicitly available to assistive tools without compromising security. • Preserve the user/service provider confidentiality. • Allow service provider customisation (to integrate branding/contextual aspects).

Technical Challenges

Some technical challenges are obviously associated with the capability to offer secure services to web developers. These result in a set of requirements as follows:

• Ensure the browser can reliably obtain execution and storage security information. • Ensure the integration from the browser to the hardware based technology is available. This will be an industry effort to make sure lower layers are implemented; for more details see GlobalPlatform on Web API to access secure element: http://globalplatform.github.io/WebApis-for-SE/doc/ • Design a security model compatible with the SOP.

Some Immediate Actions

1. In order to progress on the delivery of relevant features, the attendees of the workshop are invited to test the idea of those features with their partner/customers/teams (All)
2. Having a technical draft eases conversations, editors should draft an API which envisages services, parameters and code examples, to be reviewed in 3 weeks (Editors)
3. The community group hosting that conversation needs to continue on a regular basis and attendees need to get on board. A doodle for bi-weekly call will be sent (Chairs)

**Complete minutes ** Minutes of the meeting can be found at: First day https://www.w3.org/2016/04/26-hb-secure-services-minutes.html Second day : https://www.w3.org/2016/04/27-hb-secure-services-minutes.html Raw findings are available under https://github.com/w3c/websec/blob/gh-pages/hb-secure-services/etherpad-04-26-27.md