Hardware-based secure services past and future Olivier POTONNIEE, Aurélien COUVERT, Virginie GALINDO April 2016

What we did around Secure Element …. W3C status – Sept Sys APP WG proposal Opening a communication channel with Secure Element Does not fit Web Crypto API for hardware token Too early Web Crypto. Next workshop in Sept 2014 Promoting secure element and FIDO authentication Web Authentication WG Up and running

Why is not there yet an API to access Secure Element ? W3C perspectives on SE – internal use only 3 Education matters Web dev don’t want to speak APDU Browser makers neither Power industry matters We are only few security vendors in W3C More device and security players are joining : Banks, Visa, Tyfone, Chipset makers, … SE value are not straightforward for browser makers They live in a on-line, real time, risk management world They know how to deal with secure browser, secure enough storage… Concern with privacy and security Services in SE made accessible to everyone is a privacy concern No security solution for access control has been convincing enough up to now

What we see for the open web platform…. W3C status – Sept There are some standard services that web app could benefit Cryptography operation and storage Citizen identity Payment services Abstraction : what ever is the hardware-based token flavor The W3C should not worry about integration aspects TEE and secure element are used in transparent way in platforms See iOSSecure Enclave, android hardware-key, android Trusty framework, android fingerprint API, and some mobile payment solutions

Example of Web Authentication API…. W3C status – Sept The level of service is Enroll authenticator Authenticate W3C defines attestation, signature and service parameters The implementers manage the FIDO Client and enumeration/communication with the authenticators Security model is HTTPS SOP Centralized server checking device attestation, behing the web app domain

Our suggestion for having some hardware-based secure services happening W3C status – Sept Pick one or two use cases Design the basic services we need Prototype integration with UA vendor And improve

Sharing with you some technical thoughts…. Footer, 20xx-xx-xx 7

Low level Secure Element APIs PC/SC Open Mobile API (OMAPI) 8.1:  10:  8 Secure Elements in Web Applications

Cross-Platform Secure Element (SE) API Secure Elements in Web Applications 9 PC/SC (MSWindows, MacOS, Linux) PC/SC (MSWindows, MacOS, Linux) OMAPI (Android) OMAPI (Android) NFC Desktop Mobile Web Applications Web Runtime OS Secure Element API Access Control … …

Secure Element API Standardization Proposed to W3C (SysApps & WebCrypto WGs) Transferred to a GlobalPlatform WG Under public review here Implementation Included in Firefox OS 2.2 (June 2015) 10 Secure Elements in Web Applications

Web API for accessing Secure Element Secure Elements in Web Applications 11

Secure Element API Secure Elements in Web Applications 12 Transport-level API (similar to SIM Alliance’s OMAPI) Secure Element Manager Reader Session Channel Enumerate readers SE insertion / removal events Is SE present? Connect to SE SE ATR Connect to Applet Basic / Logical Transmit APDUs

Access Control Toolbox Secure Elements in Web Applications 13 PIN Secure Messaging Mutual AuthentN GlobalPlatform Access Control Secure Element Security Model Permissions: Access to device/resources (GPS, storage, etc…) Same Origin Policy (SOP): Data isolation per domain Web Security Model

Access Control (1/2): The Web Secure Elements in Web Applications 14 PIN Secure Messaging Mutual AuthentN GlobalPlatform Access Control Secure Element Security Model Permissions: Access to device/resources (GPS, storage, etc…) Same Origin Policy (SOP): Data isolation per domain Web Security Model

Domain-binded SE apps (SOP compliant) Secure Elements in Web Applications 15 An SE app with one credential per domain An SE app is tied to a single domain, which hosts a centralized service Other apps use a delegation protocol to use the centralized service Identity Provider SAML/OpenID Connect Login Authenticate Service Provider (Relying Party)

Access Control (2/2): Secure Elements Secure Elements in Web Applications 16 PIN Secure Messaging Mutual AuthentN GlobalPlatform Access Control Secure Element Security Model Permissions: Access to device/resources (GPS, storage, etc…) Same Origin Policy (SOP): Data isolation per domain Web Security Model

Access Control Enforcer GlobalPlatform Access Control Secure Elements in Web Applications 17 Access Rules SE Application SE Application Cached Access Rules User Device Application Access Rule: Authorizes a specific app on device to access a specific app on SE [and send specific commands]

Secure Element API to build Trusted Services AuthentN Signature Payment Reload Web Applications … Public APIs Restricted APIs Web Runtime Privilege apps, e.g. Extensions 18 Secure Elements in Web Applications Secure Element API Access Control

The security palette Secure Elements in Web Applications 19 Secure Element Built-ins GlobalPlatform Access Control Trusted Services Domain Binding

Or something completely different ! Footer, 20xx-xx-xx 20 a REST API provided by those privileged apps No need to comply with SOP but authentication could be managed by well deplowed techno like OAUTH Permission, privileged context, SRI, CSP, CORS …