Hardware Based Secure Services Report

Status of This Document

This specification was published by the Hardware Based Secure Services. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

Working copy

Table of Contents

• 1. Introduction
• 2. Problem Statement
• 3. Use cases
• 4. API
• 5. Architectures and security requirements
• A. References

1. Introduction

1.1 Terminology

• Secure Service: any service that should manage sensitive operations and that would benefit of/depends upon the use of an hardware based security solution.
• Relying party: the Web application providing the Secure Service and requesting the hardware access
• Issuing authority: well known in X509 certificates scheme as certificate authority, the issuing authority is in charge of issuing a associated key/identity pair to a known identity and to maintain its lifecycle. The end-user identification is out-of-scope of this document but is clearly mandatory to associate a key to a genuine identity.
• Origin: in reference to the Single Origin Policy, an origin is referred in this document to an HTTP URL with scheme, host, port without path
• Secure Element: A secure element is a tamper proof device, providing a secure storage and execution environment for sensitive data and processing. It offers both physical and logical protection against attacks, ensuring integrity and confidentiality of its content.
• User Verification Method: This is the way the Secure Element authorize keys usage only to the genuine user. Could be what you know like a PIN code or what you are through a biometric face/finger/iris... end-user authentication
• Identity: to be verified by the issuing authority, the identity is cryptographically linked to the key demonstrating who has confirmed a transaction or signed a document
• Key: asymmetric cryptographic public/private key pair, sometimes linked to an identity
• Trusted User Interface: User interface component outside the direct browser scope providing an additional level of trust in regards to the context presented to the end-user to acquire its acknowledgment

2. Problem Statement

At this time Secure Element are not anymore usable by web applications. For years, various form factors have been usable thanks to many API and technologies (PKCS#11, Microsoft API like CSP / Minidriver, Java applet ...). Use cases are still here but not the browser access, especially on the mobile devices. This document is targeting to define the next generation Javascript API for hardware based keys management and usage, including the corresponding underlying components requirements to re-enable a strong security and identity ecosystem.

Single Origin Policy: one main matter of interest of this report is how to protect key usage outside the issuing origin:

Let's consider that a domain foo.com issue a key. Because the keys won't be accessible with a Javascript API from any domain, how the domain bar.com is allowed to use this key ? There is strong need for an access control model because the hypothesis of a trusted environment that every Secure Element relies on is not anymore valid with an API on the browser.

This first version of the report will not address this important issue but will focus on:

• pre-existing X509 certificates accessible under the full control of the end-user to any transaction confirmation request.
• any API issued key MUST only be managed and used by its origin

Position to FIDO and WebAuth standards: this document is focusing on providing web developers means to issue and use identity keys (whether they are X509 certificates or any other cryptographic model with underlying asymmetric cryptography). FIDO standards is related to device authentication: in the FIDO vision, it is up to the relying party to manage the link between the credential and the identity.

Position to WebCryptoAPI standards: this report includes to WebCryptoAPI so that web developers can rely upon the same API but with a different initialization (like Java Cryptographic Engine with hardware provider).

2.1 Keys access

2.2 Keys management

2.3 User verification method

The user verification method is out of scope of this specification. But it should be clear whether a key is protected by

• the user presence confirmation (presence)
• the underlying OS user verification method like an handle to the registered fingerprint template (os)
• a specific and private key binded user verification method like a specific PIN or a specific fingerprint/iris template (active)

• with the passive option, there won't be any effective user confirmation - it's only about device authentication
• with the presence option there is no assurance that the right user is really behind the user-agent
• with the os option, there is options provided by the OS manufacturer to manage real world use cases - i.e. sensor not capturing the fingerprint switching to the PIN code

3. Use cases

QUESTION: Need to provide here names of well-known customers to help pushing the standards to browser makers?

3.1 Governments with eID for digital public services

• eEstonia
• Belgium eID with eService ecosystem
• Sweden: Tax Agency card, Telia eID
• Norway: ID-porten
• Any other middleware based local solution

  3.2 Banks with smartcards for corporate operations signature

  To request to a bank

  3.3 Hospitals with health cards for eHealth

  ???

  3.4 Transparent device authentication for online payment confirmation on 3DSecure scheme

  To be completed by Brian (Visa Europe)

  4. API

  This API is defined to cover the various hardware based use cases including usage and lifecycle.

  4.1 Usage

  This subpart of the API is relying upon pre-existing keys.

  4.1.1 Overview

  Goal: to give some assurance to a remote entity that a transaction is confirmed. Confirm that what was sent was communicated to the user, and what was displayed to the user is what was confirmed (What You See Is What You Confirm)

  This first section covers the various usages of keys. These use cases are not highly sensitive in terms of transaction context confidentiality, which means that standard SOP rules are considered sufficient without any need for end-to-end encryption (like secure messaging).
  To avoid context swapping, it is mandatory that the non-repudiation message contains specific data for the requested transaction with the requesting party, the purpose of the transaction and the date of the operation.

  
  [NoInterfaceObject]
  enum UVMMode { "passive", "presence", "os", "active" };
  
  [Exposed=(Window)]
  interface HBSS {
  	Promise confirm(DOMString origin, DOMString NRMessage, UVMMode mode, ArrayBuffer[] issuingAuthorities);
  	Promise deviceAuthentication(DOMString origin, BufferSource challenge, ArrayBuffer[] issuingAuthorities);
  	Promise sign(DOMString origin, DOMString NRMessage, BufferSource data, UVMMode mode, ArrayBuffer[] issuingAuthorities);
  }
  

  4.1.2 Transaction confirmation

  This operation is defined to request from the browser and underlying security capabilities to ensure that the context has been presented to the end-user and provide non-repudiation

  4.1.3 Device authentication

  This operation should be used when the relying party is trying to use a hardware key to authenticate the device without any user consent

  4.1.4 Digital signature

  This operation is defined to allow binary data signature.

  Assumption: for many different reasons, complex data are not the right format to get the end-user consent and confirm her/his acknowledgment:

  • Liability: The major reasons is that this type of API is targeting valuable transactions with liability. And for most regulations, liability relies upon the end-user capability to understand the message and confirm it. So only the simplest format should be considered: no color, no emphasis, no image.
  • Technical: structured documents (XHTML, XML, RDF, PDF ...) cannot be presented in trusted UI
  • Accessibility: no image should be used
  So it should be:
  • text only
  • not too short: it should give enough context information to protect against social engineering and replay attacks
  • not too long: it should be displayable on almost every end-user terminal and read by the end-user
  • scoped: it should target a particular operation (type, amount, beneficiary ...) at a particular time
  • localized (UTF-8)
  What is should not be:
  • full list of terms and conditions - but it can be the operation to confirm that the end-user agree with a particular version of the terms and conditions
  • a generic operation request because it would not be scoped
  NOTE: a particular attention should be paid to UTF-8 characters support with the wide variety of similar characters. Therefore, both the context and the data should be signed at the same time with the same key. It is then up to the relying party to ensure that the data associated with the context are both signed and they match the initial request The user has accepted the context (and liability may rely only on that context in regards to this cryptographic operation) But thanks to that he/she has produced with its own cryptographic key the binary data signature. The data signature (i.e. PDF signature) is then a way to embed into the data the user consent.

  SECURITY NOTE: it could occur that the binary data are altered before signature by a malware or javascript or even the browser. So the altered binary data would be successfully signed on the user agent side. But in this case this is the relying party responsibility to check that the data and the context received are signed with the same key and at the same time. It MUST reject any attempt to submit binary signed data if they are not provided with a valid signed context.

  Within this operation, the mode for the user verification method MUST NOT be "presence".

  4.2 Secure Credential Storage

  4.1.1 General consideration

  ... Relation to Web Crypto API: same API but with a different initialization engine...

  4.1.2 Key discovery

  4.1.3 Key issuance

  5. Architectures and security requirements

  These samples are provided to split the responsibilities of each vendor / software providers.

  5.1 PC-like environments

  It is typically the environment where secure elements - either smartcards with readers or usb tokens - are used with middleware through PKCS#11 or Microsoft Minidriver. In this architecture, the trusted UI is:

  • Either the middleware for PKCS#11
  • Microsoft operating system which manage the secure element user interface
  In terms of user experience, browser implementers will be invited to support a mechanism of white and black lists of authorized domains related to each key, so that an end-user could reject any request outside a specific origin for a particular key NOTE: it would require a Mini driver interface update to allow the Non Repudiation message to be provided to the API, instead of a basic data to sign.

  5.2 Mobile environments

  In mobile environments, Secure Elements are either:

  • device binded like embedded Secure Element
  • roaming like SIM or external NFC/BLE factors
  But there is no capability to add middleware. It is up the OS manufacturer to provide support for the Secure Elements and provide an API for third party applications including browsers.

  5.2.1 Generic mobile environments

  In this situation, the trusted user interface should be part of the Operating System, interacting with the Secure Credential Storage

  5.2.2 Mobile environments with Trusted Execution Environment

  In this situation, the browser is a trusted app and the trusted UI is relying upon the existing TEE functions (See [GP_TEE])

  5.3 About implementations considerations

  Implementation into a mobile phone will require:

  • browser modifications to interact with TEE
  • a trusted application interacting with the Secure Element

  A. References

  A.1 Normative references

  WebCryptoAPI

  W3C WebCryptoAPI, Ryan Sleevi, Mark Watson. W3C.

  A.2 Informative references

  CryptoAPI

  Cryptography Reference, Microsoft Corporation.

  PKCS#11

  PKCS #11: CRYPTOGRAPHIC TOKEN INTERFACE STANDARD, RSA Laboratories/EMC.

  PC/SC

  PCSC, standard for integrating smart cards and smart card readers, PC/SC Workgroup.

  Trusted Execution Environment

  Trusted Execution Environment, Global Platform.

  OpenTEE

  OpenTEE project.