Secure Element Access from a Web browser

1. Secure Element Access from a Web browser W3C Workshop on Authentication, Hardware Tokens and Beyond Oberthur Technologies – Identity BU JAVARY Bruno

2. 01. INTRODUCTION • Agenda • 02. EXISTING : WHAT ARE THE DRAWBACKS • 03. USE CASE : PIV • 04. PERSPECTIVE AND PROPOSAL

3. 01. INTRODUCTION • Agenda • 02. EXISTING : WHAT ARE THE DRAWBACKS • 03. USE CASE : PIV • 04. PERSPECTIVE AND PROPOSAL

4. History : OT experience • June 20th 2013, London, Workshop on Web Applications and Secure Hardware • July 2013 : • October 15th 2013, Oberthur Technologies joins FIDO AllianceOT founding member of SIA • November 2013 : Presentation of PIV for eSE on OT booth demonstrating eservices. “my voice is my password” winner in the Trusted internet/Authentication category • February 24-27th 2013, Barcelona, GSMA Mobile World Congress : 1st worldwide demonstration of a FIDO authentication secured by the SIM • March 2014 : Mobile ID study starts with dedicated workforce with objective : “Smartcard Access from Web Browser” • Summer 2014, w3C call for papers, submission of position paper, result of internal study for eSE finalist

5. POSITION SUMMARY • To enable a common access for every single user to trusted services thanks to a secure element, the best candidate is the web browser • By consequence HTML and JavaScript will be the standard to access a secure element • Many examples already exist to access hardware • Video, webcam, geolocation, file system • Thanks to evolutions of standards

6. POSITION SUMMARY Several topics are to be considered • Authentication : • For Payment / Internet banking / Corporate network access / Social media • FIDO is an answer • Access to cryptographic operations : « Secure Operations Execution » • Web crypto api • Issue : define use cases exhaustively • Low level access to the secure element or hardware token • Access the closest possible to the hardware • Close to sysapp considerations

7. 01. INTRODUCTION • Agenda • 02. EXISTING : WHAT ARE THE DRAWBACKS • 03. USE CASE : PIV • 04. PERSPECTIVE AND PROPOSAL

8. EXISTING Middleware Software application that enhances the capacities of our computer applications by creating an abstraction layer Implements standard Good solution for a local use, it provides secure features established on standards in a controlled IT configuration. However it can’t be used as an online solution or in an opened device. Web browser extension Program integrated into a web browser and which provides new features Can be : plug-in, java applet, ActiveX The only solution right now but many drawbacks : • Heterogeneity of methods to access Smart Card • Security

9. EXISTING Most of the apis are proprietary (eg OT Micro SD) There are some promising technologies • NFC • Open Mobile API These communications layers remain low level Middleware and web browser extensions do not fit in a mobile environment Mobility

10. 01. INTRODUCTION • Agenda • 02. EXISTING : WHAT ARE THE DRAWBACKS • 03. USE CASE : PIV • 04. PERSPECTIVE AND PROPOSAL

11. PIV - PERSONAL IDENTITY VERIFICATION Definition Limitations US federal employee or contractor wears a PIV card defined by the National Institute of Standards and Technology (NIST). The card is required to enter a governmental building and to log on to computers (Physical and Logical Access Control). The federal employee can also sign emails or documents and authenticates to remote web sites in HTTPS. File decryption or signing must be done locally. In a world of cloud computing and “Software as a Service” it represents a real inconvenience. The agent must have an already configured PC or be granted with specific rights, which prevents from using devices “on the go” or “away from office” (in a hotel, an airport, at home). To use a Smartphone or a tablet, specific software and hardware (card reader) have to be set up.

12. 01. INTRODUCTION • Agenda • 02. EXISTING : WHAT ARE THE DRAWBACKS • 03. USE CASE : PIV • 04. PERSPECTIVE AND PROPOSAL

13. PROMOTE A STANDARDIZATION Position As a solution provider, we would like to push the standardization of a JavaScript API which allows web browser to communicate with Smart Card Objective is to open trusted services with secure element to the mainstream market In order to be implemented in all browsers and to ensure its liability, the API should be endorsed by W3C. Secure Element API This api is complete and well documented. It presents in details the technical background and use cases and gives a good visibility of Security, Permissions, Access Control and Conformance Security is at the heart of OT’s concerns; the proposed solution combines validation of the feature by the user and a specific access control mechanism The idea beyond is to propose a trusted access to a secure element from a service provider, preventing from unauthorized use.

14. PERSPECTIVE Let’s follow, jointly with all companies and associations sharing the same opinion and interest, action plan below: Action Plan Identify a charter to carry the project Define use cases and for each of them demonstrate the impact and validate the consistency of the current proposal. Meeting all stakeholders interested in the subject, be aware of each of them interest and create a common basis of communication and strategy Establish interactions with other standardizations (eg Open Mobile API) Gather work forces to create a proof of concept and decline it to use cases examples (eg eServices)

15. Thank you for your attention