Hardware-Based Secure Services CG -- 26 Apr 2016

<chackett> Hello everybody, Conor Hackett from Worldpay here.

<screen> Welcome!

<wseltzer> Wendy Seltzer from W3C

<acouvert> Hello, Aurelien Couvert from Gemalto

<drogersuk> Introduction from Susan McLean of MoFo

<screen> Sue: MoFo, supporting the workshop

<wseltzer> Sue: MoFo is happy to provide legal support to tech companies

<wseltzer> ... data privacy and security practice

<wseltzer> ... Welcome!

<mkuhn> Markus Kuhn, University of Cambridge, here, hi everone!

<wseltzer> ... Women in Wireless, UK tech organization

<drogersuk> Susan McLean talking about Women in Wireless

<virginie> Agenda is here : https://github.com/w3c/websec/wiki/hb-secure-services-workshop-:-agenda

<drogersuk> Wendy Seltzer introduces the two days

<virginie> We will need to review it

<virginie> Dont forget to list topics you want to address

<drogersuk> ...developing a really solid plan of how we bring hardware security to the web

<drogersuk> ..user expectations and the ecosystem

<drogersuk> ..this is IRC!

<drogersuk> ..we use IRC in W3C fer recording minutes and text in realtime

<drogersuk> ...we produce the minutes as we're meeting

<drogersuk> ..[like this]

<wseltzer> https://github.com/w3c/websec/wiki/hb-secure-services-workshop-:-agenda

<drogersuk> ...now introductions

<drogersuk> ...Wendy: I am part of the W3C team. This is a community group - to get early ideas for standardisation

<drogersuk> ...we often incubate ideas through workshops which can reach standardisation through our recommendations

<drogersuk> ...my role as W3C team is to help you to do that.

<drogersuk> Virginie Galindo: I am co-chairing this CG

<drogersuk> ..I have an interest in this work from my company perspective, Gemalto

<wseltzer> drogersuk: David Rogers, Copper Horse

<wseltzer> ... W3C; chair GSMA device security

<drogersuk> ...proposals here need to be attractive enough for browser vendors

<wseltzer> Conor_Hackett: WorldPay

<wseltzer> Aurelien_Couvert: Gemalto; previously worked with web secure element API

<wseltzer> Brian_Sullivan: VISA Europe. Payments security

<wseltzer> Arnold: Samsung, crypto and security

<wseltzer> Colin_Whorlow: CESG

<wseltzer> Paul: CESG, TCG, GlobalPlatform, FIDO

<wseltzer> Sebastien: Morpho, identity and secure services

<wseltzer> Habib Virji: Samsung, browser and security

<wseltzer> Natasha: GSMA, mobile operators

<wseltzer> Michelle: NokNok Labs, one of the founders of FIDO Alliance

<wseltzer> Les: Southampton Web Sciences Insitute

<wseltzer> Susan: Univ. Southampton

<wseltzer> Klas Lindfors: Yubico

<wseltzer> Markus_Kuhn: Univ of Cambridge

<wseltzer> Robert_Lee: Royal Holloway smartcard center

<wseltzer> Joerg_Heuer: DT Labs. ID management, secure element, sim card

<wseltzer> Peter: DT, security consultant on HW sec

<wseltzer> Philip_Hoyer: HID Global

<wseltzer> Adrian_Castilio: HID Global hw credentials

<drogersuk> Wendy introduces the W3C objectives, 400 members worldwide

<drogersuk> ...consensus to produce recommendations for the web

<drogersuk> ...e.g. html, css, web crypto api

<drogersuk> ......things that help web services interoperate

<drogersuk> ...no power to compel - help people to recognise the value of the work we're creating

<drogersuk> ...so that it is adopted in browsers

<drogersuk> ...we can take advantage of hardware capabilities for the web

<drogersuk> ...for example - authorisation, key storage, processing - better

<drogersuk> ...we can do it on the web platform if we convince the participants that these are services that we need and implementable, sensible and at the right level of abstraction.

<drogersuk> ...over the next two days, the goal is to see how specific we can get about early prototype services for the web

<drogersuk> ...what does the web need and what can we get out of those APIs

<drogersuk> ...let's try and whiteboard how we get there

<drogersuk> ..the recommendations go out for votes among the membership.

<drogersuk> ...We got responses on this particular charter, but we got some pushback in terms of it being too broad. We also got substantial support for the work.

<drogersuk> ...So let's take a step back and look at the charter again so that it meets all the necessary needs.

<drogersuk> ...We have a Royalty Free patent policy which has been very successful

<drogersuk> ..the scope is therefore extremely important in working group charters.

<drogersuk> ...We also have other groups in W3C that are looking at things like web authentication - this is a layer above where we are looking at.

<drogersuk> ...We also have the web crypto API which is nearly finished, at Candidate Recommendation status

<drogersuk> ...how can we support that functionality with hardware?

<drogersuk> ...We also have a web payments working group, chartered to look at bringing payments to the web. They are not doing security in that group

<drogersuk> ...we could also be looking to support security for the web payments work.

<wseltzer> Michael: G&D, on the phone line

<wseltzer> Philip: What has changed from a few years ago?

<wseltzer> ... more devices incorporate NFC; technologies of hw sec have decreased in price

<wseltzer> ... tech trends that would lead to solution

<wseltzer> 2014 workshop

<wseltzer> virginie: Secure services, not specific implementation

<virginie> The charter which was sent for review to W3C members is : https://w3c.github.io/websec/hasec-charter

<drogersuk> Wendy: we have seen feedback that incubation of this work is necessary and members don't want to see R&D without feedback from implementation and use

<drogersuk> ..one of the ways is to start to draft

<drogersuk> ..not just use cases and need

<drogersuk> ...what does this look like in practice?

<drogersuk> ...what is the shape of the API? How does this protect privacy against linkage across websites? What are the security, accessibility and internationalisation considerations?

<drogersuk> ...some use cases discussed already

<virginie> The list of item to discuss is here : https://github.com/w3c/websec/wiki/hardware-based-secure-services-:-topics-for-the-workshop

<drogersuk> ...citizen identity and services seems to be an important point in Europe

<wseltzer> jheuer: implementability and economic sustainability are key

<drogersuk> Joerg Heuer: maybe not specific implementation but implementability important

<drogersuk> ...use of hardware is a reality for almost everyone across the world

<drogersuk> ...just look at the Oyster card in Lonodn

<wseltzer> virginie: Reviewing agenda

<drogersuk> 5 presentations from different companies coming up this morning, @drogersuk will chair

<virginie> This is where we want to re things : https://v.etherpad.org/p/Hardware_Security

<wseltzer> Paul: Paul Waller, CESG

<drogersuk> Paul Waller presenting from CESG

<drogersuk> Paul is Technical Director in CESG for platform security

<drogersuk> ...getting security right in govenrment platform and systems

<drogersuk> ..improving government services, improving usability without compromising security

<drogersuk> ...if it isn't viable it isn't going to work

<drogersuk> ...when we talk about authnetication and managing crypto on the web, we really do need hardware for that

<drogersuk> ...software based crypto etc. exposes more people to attack

<drogersuk> ...as we see increased usage

<drogersuk> ...reducing reliance on passwords

<drogersuk> ...We help risk management - government as an enterprise for small, medium and large gov departments

<drogersuk> ..usually on corporately managed laptops, increasingly more other types of devices.

<drogersuk> ...The other thing is government services online (same as businesses)

<drogersuk> ...we don't want a bucket load of passwords

<drogersuk> ...we want it to be seamless and by default

<drogersuk> ...easy to use the most secure option

<drogersuk> ....I have been a contributor to a lot of standards - TCG, Global Platform and more recently in FIDO Alliance

<drogersuk> ...for users - very difficult to explain what that is they just need to know it is ok

<drogersuk> ...can I offer a better service if that is authenticated more strongly?

<drogersuk> ...what does that mean? how do I tell? how can I get more confidence?

<drogersuk> ...would love to see a solution to user interface security and user perceptions and display of information

<drogersuk> ...is it beyond the scope?

<drogersuk> ...I would like to have some confidence that I can send something to a device that I don't trust

<drogersuk> ... think we need to break this down into chunks we can deliver

<drogersuk> ...if I was a bank, how can different hardware work with other banks / consumers / tell the difference is going to be key

<drogersuk> ...I think the work of this group is to make the business case for it and understand how to plug all the bits together

<wseltzer> drogersuk: eIDAS?

<drogersuk> ...there are also other schemes - eVerify

<drogersuk> ...this stuff is coming

<drogersuk> ...it just is going to be less cumbersome than what we're already doing

<drogersuk> ...a bit clunky at the moment

<wseltzer> drogersuk: We should both be capturing long-term objectives and immediate priorities

<wseltzer> Arnold: thoughts about citizen services? single-identity per citizen, or federated?

<wseltzer> Paul: Govt' program, Verify, use IDPs from industry, federate across govt services

<wseltzer> ... don't believe goal is single ID per citizen

<wseltzer> ... for privacy reasons

<virginie> service program mentionned by Paul : https://www.gov.uk/government/publications/introducing-govuk-verify/introducing-govuk-verify

<wseltzer> Markus: hw sec is difficult to deploy, because you need to get the hardwarwe out

<wseltzer> ... differentiate between security services done at W3C, then talk about implementation in hardware

<wseltzer> ... start with software, then improve by hardware

<wseltzer> ... Should we talk about HTTP, HTML security services?

<wseltzer> Paul: Lots of the hardware is there. TPMs, TEEs, keystore

<wseltzer> ... there's not yet mass adoption

<wseltzer> ... attestation can help to provide a step-up in security

<wseltzer> wseltzer: e.g. needs of WebCrypto users for secure keystorage

<wseltzer> Markus: idp services are currently server-side

<wseltzer> Sebastien: using browser as IDP, means that key is identity; you might also have different credentials

<wseltzer> drogersuk: don't break the web. Also think about what happens wehn one of these services is not present. Graceful degradation

<drogersuk> ..anti-patterns need to be captured

<drogersuk> Phillip Hoyer from HID Global presenting now

<virginie> [material to be sent by Philip Hoyer]

<wseltzer> etherpad, https://v.etherpad.org/p/Hardware_Security

<wseltzer> jheuer: important that user can choose *as whom* they are recognized

<wseltzer> ... pseudonymity of the web

<wseltzer> ... as a driver of user confidence

<wseltzer> Philip: binding to the device is common

<wseltzer> wseltzer: accommodate a range of user preferences for privacy

<virginie> [Aurélien to send the material]

<virginie> Aurélien : the web security model and the SE based security model must be gapped

<virginie> ... on the web side, the user chooses permission

<rigo> ungapped?

<virginie> ... the web uses the SOP

<virginie> ... there is the marge use of authentication by third party (OAuth like)

<virginie> ... on the smart card habits, there is pin management, or credential management in security domains in the card

<virginie> ... on the mobile area, there is a technology known as access ocntrol enforcer : a list in the secure element checks a mob app can access the service

<virginie> .... the solution should be public APIs to allow web app to access services in TEE or SE

<virginie> the key point will be the access control, making sure only authorized entity can use the service

<virginie> ... the question is : how do we build the access control ?

<virginie> ... we have a lot of things, we need to pick some parts and build on that

<virginie> ... or we can think at web services, based on REST services, relying on authent mecanisms

<virginie> .... we can rely on other techno like priviliedged context and all security tools designed by the W3C

<virginie> ... this is entry point to technical discussions

<virginie> ... how to add new authorized services into this solution (once we have an access control)

<virginie> phill : do we have an history of the workshop, we tried to adress everything, and did not succeed. We should revisit all the security tools and see if it is relevant for our use cases

<virginie> phil : what does happen if there is no access control ?

<virginie> Aurélien : we need to have an intermediate step between web app accessing the APDU stack, like web app accessing a specific service

<virginie> Phil : we discussed about priviledged application in FFOS

<wseltzer> phil: privileged javascript?

<virginie> David Rogers : FFOS is only maintained

<virginie> Aurélien : we implemented a U2F FIDO service

<wseltzer> drogersuk: top-up of transportation cards example?

<virginie> Phil : it seems there is a common set of interest in different markets ?

<rigo> boxes could be categorized by use cases and then done in liaisons

<virginie> Phil : is there any official liaison ?

<virginie> Brian : there is no, but it could be

<virginie> Brian : it would make sense

<rigo> -> no, there is no liaison done at the moment, internally, could liaise with payment

<virginie> Wendy : a common sense in W3C is to reuse what other industry develop

<virginie> ... we used to ping EMVCO for the payment aspects

<virginie> Paul : This slide #18 is an interesting slide to let the browser know the different technos

<virginie> Paul ; we need to define what is the blue box content

<virginie> (note that blue box label are payment/relaod/signature/authent)

<virginie> wendy : Same origin - the web sec is working well enough, while being challenged

<rigo> drogersuk: web crypto group had a discussion on high level vs low level apis

<virginie> ... SOP is a good basis today to bring security to web application

<virginie> ... what we've got make a reasonnable job against threat

<virginie> .... we have to work with it, until someone redesign a better approach

<virginie> ... thinking about addional concept like trusted javascript could be a good direction

<virginie> ... keeping in mind that SOP is the framework we have

<virginie> David : we should think about policies, other maybe...

<virginie> Joerg : on hardware security, we talk about SOP. It is with different ways, different browsers.

<virginie> ... we need to understand how to use the service from different browsers and sessions

<wseltzer> jheuer: another real-world fact is multiple browsers and devices

<virginie> https://v.etherpad.org/p/Hardware_Security

<virginie> David : we should also have a look at the work that all the people are doing to avoid the SOP

<virginie> David : we have time for one more presentation

<virginie> Joerg and Peter will present use cases

<rigo> JH: communication path that are guaranteed by hardware (bluetooth)

<virginie> joerg : two qualities we are using in our use case (1) communications paths available garanteed such as BLE/NFC (2) secure element is secured for execuiton and storage

<rigo> ... other story is where keys are stored etc

<virginie> joerg : we prototyped digital wallet to allow user to keep everything they need (ticket, key, access control ...) and reuse in any browser

<rigo> ... can keep state outside the browser, but have to communicate through the browser

<rigo> .... presents T-Systems

<rigo> ... want to have a ticket to Vienna, they will give you a bar code or a QR code. There is nothing to replace that, very unsecure.

<rigo> ... have already integrated lots of keys and access tokens across and have even an interface

<rigo> ... virtual car key in the user's wallet

<rigo> ... ticketing is special case, very limited. Public transport organisations in Germany, came together from private side, have contracts since 100 years, can't change that. Need to securely process in the world. Smartcards work, now have done QR codes as SM did not work.

<rigo> ... payment also an issue. Hope for Mastercard or Visa to allow us secure online payment. But there are procedural issues. But instead of having "card not present" we could have nice hardware support

<rigo> virginie: take care about implementability. Payment and transportation are different. Payment is with a wallet. Allows a browser to interface with wallet

<rigo> ... helpful to disfragment the market

<rigo> ... how to make sure that the 10000k different transportation schemes get some interoperability for the browsers?

<drogersuk> virginie asks, how do we make a single, productive interface

<wseltzer> jheuer: we need to enable ecosystems; meet industry needs, then see where there's common demand for interfaces

<rigo> JH: we need to allow proprietary extensions, so that they can interface to the web. We need to talk to those makers of key schemes. They will adopt FIDO because that's the scheme that will always work.

<wseltzer> ... start from the verticals

<Zakim> virginie, you wanted to comment on the business model and deloyment fragmentation for transportation or automotive

<rigo> ... but if we don't approach the verticals, they will perhaps go that route. Or have some big internet corps being THE ticket provider for the internet world

<rigo> drogersuk: please beware of card clash... too many cards in one wallet. Challenge for the user. Not having to make a choice.

<rigo> ... given the prob space here, if choice, what would be the single quick deliverable you would work on

<wseltzer> phofmanntsy: couponing and loyalty, for online purchases

<rigo> Peter: payments and loyality, with secure elements, services applets to make that accessible for online payments

<rigo> ... authentication, hb-based authentication, keys, one time passwords etc

<rigo> .... car keys, ticketing, many different solutions out there. No ticketing on the Web

<rigo> .... digital commerce cases are low hanging fruit here.

<rigo> Peter: as long as there is discussion about using native apps, we will have that challenge

<rigo> ... standardised scheme could have value for smaller layers

<rigo> ... big hole in standardisation, ??

<rigo> ... gap to native is access to secure element. FirefoxOS had it and was best way to work with cloud etc...

<rigo> ... have access over multiple platforms and using several different underlying elements

<rigo> virginie: technical aspect, can you share the implementation architecture?

<rigo> Peter: can do,

<rigo> JH: unfortunately did not know that demo slot was still available

<rigo> virginie: what is common to all the use cases so we can attack it.

<rigo> == Sebastian presenting ==

<rigo> EID use cases and e-citizenship (shows map)

<drogersuk> ...eID use cases in e-citizenship

<rigo> Sebastien: Motivation to create eID schemes: includes public safety

<rigo> ... strong authentication, digital services, prevent identity theft.

<rigo> ... But we have no access to secure element in browser.

<rigo> ... define and recognize level of assurance. Difference between FIDO and secure element. FIDO is binding to a specific service provider, secure element is not

<rigo> ... X.509 ID & secure element. Could provide ID & security level.

<rigo> ... in a secure element, there is always some identity in the secure element that currently is still usable universally

<rigo> ... most banks and governments agree on secure element as it ties to a key or identity.

<rigo> ... there is nothing providing consent, so need that and FIDO will not provide it

<rigo> .... Smartcards and authentication are same level as OTP via mobile phone

<rigo> ... can be faked quite easily

<rigo> ... EMV CAP already known attacks, so have to do better

<rigo> ... ehealth, Servida avoided to put common criteria into regulation because there was no way to connect smartcards through the browser

<rigo> ... not willing to deploy FIDO at this time, they need to manage user experience. User has same key for different providers. Very difficult to understand for users

<rigo> .... at broader level only 3 tools? Native apps. PKCS#11, TLS for authentication.

<rigo> ... Signing hash is not an option, user should sign document

<rigo> ... for browser makers GSAPI is a nightmare as they will not see what is going through

<rigo> .... remote middleware that relies on PCSC, but doesn't work on mobile, NP-API is a dead end

<rigo> .... API as proposed could make sense for Browsers

<rigo> virginie: in global platform, there is API on web access. Aureilien had mentioned it. This API is now public.

<drogersuk> ...virginie discussing the history of APDU access

<rigo> ... gemalto vision: OMAPI -> APIU-level. Gemalto has promoted APU to W3C, but was rejected. Web Devs don't speak APU

<drogersuk> ...group in GlobalPlatform called webAPI - the web version of the OMAPI API is now up and running

<drogersuk> ...this would still be at a lower layer

<drogersuk> ...we don't now see W3C at this layer - they are higher up

<rigo> ... created WebAPI - is like OMAPI for the Web. Is directly implementable now. But not where W3C is. W3C is higher. Lower level is open source browsers accepting contributions

<drogersuk> ...the question is how are we going to create the access to a Trusted Execution Environment

<rigo> ... is TEE and secure element industry should push that. C

<drogersuk> Question: is there a liaison between W3C and GP?

<drogersuk> Answer: yes there is. Gil Bernabeau is the contact at GP

<rigo> .... there is a liaison with Global platform. Gilles Bernabeu is the liaison person

<rigo> Sebastien: FIDO is good because end user can accept or reject. How can we manage other use cases based on that.

<virginie> the Web API allowing to access to Secure Elelement is under public review here : http://globalplatform.github.io/WebApis-for-SE/doc/.

<virginie> Your review would be appreciated

<rigo> paul: transaction confirmation is useful. But there you also need trusted output and trusted input

<rigo> Sebastien: definitely has to be related to the end user, show document.

<rigo> PhilHoyer: also from service provider side view, liability

<rigo> Sebastien: manage lifecycle of FIDO, link to the token. Can be quite easy. But for them it is very difficult to prove that you signed a document

<rigo> ... common criteria needs WhatYouSeeIsWhatYouSign

<rigo> RRSAgent: please draft minutes

<wseltzer> [resuming from lunch]

Use cases and demos

<wseltzer> Adrian: remote card diagnostics

<wseltzer> Aurelien: FIDO U2F

<wseltzer> virginie: Sharing of common experience from use cases and implementations

<wseltzer> wseltzer: Please join the CG: https://www.w3.org/community/hb-secure-services/

<wseltzer> Hardware Based Secure Services CG

<wseltzer> Etherpad

<LJWatson> Hello. It seems that those of us dialled in can hear the room, but that you can't hear us.

<drogersuk> Dinner location (90% sure): Bleeding Heart Tavern: http://bleedingheart.co.uk/

<LJWatson> Ok. No problem.

<FMK> I can also hear you but you do not seem to be able to hear me.

<rigo> scribe: colin

<rigo> scribenick: colin

<FMK> Phone bridge lost?

adrian something to provide bridge. for certain browsers.

not only implementation available.

describing cardid/webcard

cannot anticipate all possible protocols

scribe: idea is for remote diagnostics for cards.
... cardID provides mechanism to access data in smart cards from your browser.

apologies from scribe. forgot the dots!

<wseltzer> [Adrian demonstrates plugin.cardid.org]

<wseltzer> [plugin exchanges APDUs]

adrian: multi-application.
... if no key then cant access
... no concept of privacy protection in card
... something i just implemented. mapping of use

<wseltzer> adrian: this map shows that people are willing to install plugins from random people to run APDUs on their cards!

<wseltzer> ... many people

adrian: just start with something. better than nothing.
... encouraging to see other initiatives. bridges between webpage and card
... feel free to visit page. i will provide the link to irc.

virginie idea is to enumerate apps in the token and provide secure channel. is that right?

scribe: so you need keys.

adrian service is useful for card issuer.

virginie thank you Adrian. try to get Leonie Watson audio. success!

leonie: sorry cant be there in person. talk about accessibility and security
... describe couple of situations where they work or dont work together
... biometrics wont work f you dont have a retina. also not everyone has fingerprints

<Adrian> Sample plugin code is at https://github.com/cardid/WebCard

<wseltzer> [LJWatson describes a challenging experience using NFC payment in the London Tube]

<wseltzer> LJWatson: Trust, confidence in the system matter; accessibility matters in security

<virginie> See the conversation about the ARIA role 'password' https://lists.w3.org/Archives/Public/public-web-security/2016Apr/0025.html

joerg question. would it be helpful to have tool that allows general communication with devices

scribe: we are talking about secure communication.

leonie cant hear question

<wseltzer> LJWatson: It is helpful to have a device acting as the user's agent, as interface to other devices and systems

<wseltzer> virginie: next up in descriptions from implementers, Sebastien

<wseltzer> Sebastien: proof of concept implementation

<wseltzer> ... browser extension with json array

<wseltzer> ... key management

<wseltzer> [on-screen diagram]

<wseltzer> ... trusted UI

<wseltzer> ... service: confirming a transaction with an existing certificate

<wseltzer> ... operates in different modes, with different hardware capabilities

<wseltzer> virginie: what's in the browser?

<wseltzer> Sebastien: just a simple extension with new API

<wseltzer> ... browser receives the signed data

<wseltzer> ... js:trust.confirm({"op":"the operation to confirm"}}

<wseltzer> Paul: how do you explain to the user to difffeerentiate trusted display?

<wseltzer> Sebastien: nothing at this point.

<wseltzer> ... up to the service provider to determine what they need, based on attestation

<wseltzer> ... SE, SE+TEE, TEE, or nothing

<wseltzer> ... SE is a FIDO authenticator, has attestation

<wseltzer> ... extension + native plugin

<wseltzer> jheuer: API looks the same even if some elements aren't present?

<wseltzer> Sebastien: Yes

<wseltzer> jheuer; I think that's important

<wseltzer> ... up to the service provider to see attributes, decide whether to provide servies

<wseltzer> Sebastien: passive authentication, active

<wseltzer> virginie: who qualifies the level of secure services? browser, app developer/service provider, certifier?

<wseltzer> virginie: next up, FIDO technologies

<wseltzer> ... Web Authentication WG launched earlier this year, now building FIDO 2.0 tech into browsers

<wseltzer> ... let's see what worked well for them

<wseltzer> Aurelien: overview of our architectures

<wseltzer> ... use U2F FIDO to authenticate to Google services

<wseltzer> ... U2F applet in SE

<wseltzer> ... we used websocket channel to communicate between browser and websocket server on android

<wseltzer> ... to access SE API

<rigo> websocket server maps everything to smartcard I/O

<rigo> no access control so far

<rigo> PhilHoyer: How do you bind the device?

<rigo> aurélien: we bind to the user

<rigo> ...listening on a specific port on localhost

<rigo> Adrian: does websocket approach work, or better in browser?

<rigo> Aurélien, not for all use cases. for authentication you need to be in the browser

<rigo> .... can access web socket server from outside the browser. We can rely on global platform ACL

<rigo> Arnold: no concept limiting the number of authentication requests

<rigo> Aurélien: yes, no limit. If FIDO, you expect USB token. Waits for that event. You have to mimic that

<rigo> ... then listening to the event

<wseltzer> Arnold: many attacks based on repeated requests, e.g. to authenticate, so it's useful to rate-limit

Technical Requirements

<rigo> virginie: 2 tasks 1/ Specific services that are in the browser (generic framework to host secure services)

<rigo> ...2/ small groups discussing user consent and security working on integration and that interface can be plugged on lower level

<rigo> wseltzer: where does the momentum come from? We need a solid specification that is implementable and testable

<rigo> ... small groups or more conversational?

<rigo> Adrian: start with the requirements

<wseltzer> rigo: a key requirement from the browsers, no unscoped bearer tokens

<wseltzer> ... how do we translate things usable by secure elements, TEEs, to the Web

<wseltzer> .... how do we pass messages in the API?

<wseltzer> ... if they're unscoped, no browser wants to operate with them

<wseltzer> Adrian: Google chrome lets you use USB

<wseltzer> Markus: but you don't get full USB access

<wseltzer> ... re open-scoped bearer tokens

<wseltzer> ... smartcards make assumptions about how they will be used, in what context

<wseltzer> ... if we open an API for any app to talk to any smartcard, you're mixing assumptions

<wseltzer> ... you'll get catastrophe

<wseltzer> ... you can design a new smartcard standard, with a new end-to-end authN protocol on top

<wseltzer> ... if that's the only protocol you're allowd to pass to the smartcard

<wseltzer> ... then it's only the new smartcards designed safely

<wseltzer> Sebastien: you're talking about creating new standards, not talking to existing deployeed cards

<wseltzer> Markus: yes

<wseltzer> ... it's dangerous to open interfaces to legacy cards

<rigo> MK: having web talking to EMV smart cards is extremely dangerous

<wseltzer> Markus: end-to-end auth to the HSM

<wseltzer> Peter: GP secure channel protocols are end-to-end

<rigo> ... it is not selecting a channel, it is talking through to the other end on the server

<wseltzer> Markus: browser must be able to talk only to interfaces designed for it

<wseltzer> ... lots of security problems come from combining systems

<rigo> phil: end to end, global platform applet on the security itself. New EMV

<rigo> MK: still tokenization

<rigo> Phil: verious ways to do

<rigo> MK: tokenized protocols (EMV) on top of that you create a nounce that is unique. Still don't have consent, the assurance, etc

<rigo> virginie: end-to-end solution is secure. There is no value for browser makers to let such a channel happen. Content protection model perhaps

<wseltzer> virginie: speaking as Gemalto, an end-to-end solution could be secure; I don't see support from browsers

<wseltzer> rigo: don't let perfect be enemy of very good

<wseltzer> ... proportionality between security and utility

<wseltzer> Markus: the smartcard can talk to the browser a protocol that describes its context

<wseltzer> ... wrapped in non-backwards-compatible protocol, so the browser speaks only to hardware designed for it

<rigo> MK: make sure that the smartcard knows from which context it is contacted, know everything the browser knows. Only talk to new protocols

<wseltzer> Klas: some of this sounds like FIDO U2F with origin-bound keys

<wseltzer> rigo: Smartcard has a possession element, legally important at least in Europe

<wseltzer> Adrian: hard to motivate, since there are no smartcards with that new protocol

<rigo> Adrian: no smartcard with only new protocol

<wseltzer> ... how can we allow people to use documents they already have

<virginie> Rigo : eIDAS is coming and we may need a new protocol

<virginie> (rigo, please correct)

<virginie> wendy : where do we position between the chicken and the egg to have momentum

<rigo> eIDAS has drawn up a full set of protocols within 2 years. So having a new protocol isn't that impossible

<virginie> Wendy : how do me choose between supporting legacy smart card and this idea of new smart cards designed for the web

<rigo> JH: most smartcards are on the same basis. How they do things is very different. If we have only one standard, it may have a bug and fail

<virginie> Joerg : We need to offer something which is attractive, secured, deployed in a standardized way

<virginie> Joerg : we need to balance the risk by user consent, authentication features, and provisding a flexible and adaptative solution

<virginie> markus : dont believe smart card has a bright future, and the underlying problem is no user interface, user need to trust the user interface

<rigo> MK: underlying prob with smart cards is that they have no UI. At the end I have all my trust in the UI device. Some of the devices rival smartcards security

<virginie> markus : the secure enclave is a way to bring a new security technology, that is integrated, and starting to provide similar services as smart card

<rigo> ... smartphone will be comparable to what smartcards can do.

<virginie> markus : what are the technical merits of smartphones that can be leveraged by the browser

<virginie> markus : this is the challenge W3C is facing

<rigo> MK: question for W3C: what an App can do what the Web can't do. App has access to OS, has appstore, keychain facilities, pin retry counters etc

<virginie> markus : exemple : secure storage, sandbxing, key storage, key chain facilities, linked to biometry, pin retry counters

<rigo> virginie: different type of security. trusted execution env. What can the browser leverage the next generation of secure technos

<rigo> ... what is already in the native space, secure element etc, how to make that available to the Web

<virginie> adrian : developers need to be responsable for what they are using, you already have native services that are well described with their security merits

<rigo> Adrian: real competition is native app, agree (enumerates). Devs need to know what they are doing.

<virginie> adrian : assuming that web dev knows how to take care of the security aspects

<virginie> rigo : the smart card debated is not the right debate, a smartphone is a smart card, and the possession is the key point that makes the difference

<virginie> rigo : we need to drive to the secure element some contextual infrmation, so that they can operate, we may design a new smart card for that

<virginie> rigo : what we want is an interoperability layer

<virginie> markus : we need to have more information being passed to the user, to get more context (recipient, purpose, amount of transaction, ...)

<virginie> rigo : you can use the XHTML to do that, you can still have the browser but you will be back to the paper stage, to check everything

<virginie> markus : we may gave an indicator that the web page was constructed by the browser

<rigo> phofmanntsy: important native apps and web compete: Why are native apps are winning? They have access to OS and TEE and stuff

<virginie> peter : all the ressources of the platform used by native applications are not made available to the browser (TEE, ...)

<rigo> ... browser may invoke native app in payments e.g. but can't really respond itself

<virginie> peter : this is a good saling point to brwser to compete with native apps

<rigo> wseltzer: great marketing and technical pitch combine. Web lacks capabilities that people need. Can we bring them to the Web?

<rigo> ... on trusted UI Web App Sec is considering some visibility response

<rigo> ... request visibility API ..

<rigo> MK: typography is a tricky field

<rigo> wseltzer: see WebAppSec RequestVisibility() API. e.g., was someone shown hte ad, a payment symbol etc...

<rigo> MK: if smartcard acts like a web server and has a very simple template

<rigo> virginie: 5 years ago java card 3 framework. Had no attraction ....

<virginie> virginie : and the industry designed the famous smart card web server in OMA standardization body

<rigo> JH: can we be better in the browser than in OS? Can check integrity

<rigo> ... problem occurs once you use special capabilities like UI

<rigo> ... can switch off the virtual card in isolated env. As soon as procedural information, we are stuck

<rigo> MK: browser is at merci of OS, mobile OS are different

<rigo> .... browser does not communicate its OS it is not verified.

<rigo> RW: perhaps leverage the lesser functionality of the Web.

<rigo> MK: privacy preserving attestion

<rigo> wseltzer: will see more of that

<rigo> ... perhaps let pass a certain amount of attestions if in need of authenticated communications

<virginie> wendy : we have a bunch of use case that may be attractive

<virginie> .... * secure credential storage, keychains, and protections * attestation * trusted UI * biometry * a strong application security management (access control, digital signature, permissions, ...)

<virginie> ... is that helpful listing ? is there any other capabilities w ebelieve are critical to native app, to be made available to the web apps ?

<virginie> PhilH : in the workshop 2 years ago, we see the device communicating with proximity protocols

<virginie> philP : that was raising the question of the discovery

<virginie> philH : it means that there is a notion of human reminding what device was used

<virginie> philH : this is a package discovery

<virginie> Arnold Yau : (from samsung) there is the notion of veting/curation of the apps

<virginie> wendy : a doable first step would be to think of the minimum viable product we could construct ?

<virginie> wendy : we may work on it and make sure we work on security, pricavy and accessibility constraints

<virginie> markus : I regret web browser to try to have a decent key exchange protocol to remove passwords

<rigo> MK: look into protocols like JAKE, patents have expired

<virginie> markus : there might have ways to include that, but it can may come with some securitychallenges

<virginie> wendy : some of those discussions are happening in IETF, for adressing the HTTP layers

<virginie> markus : this is weird as passwords are in the domain of W3C

<rigo> MK: all OS have keychains, browser could provide interface. But probably needs POSIX spec for keychains

<rigo> => Virginie filtering actual suggestions on the chart

<wseltzer> PhilH: continuous authentication support, risk assessment feedback mechanism

<wseltzer> rigo: which information can be transported from web-hardware and hardware-web

<rigo> a useful document would be to have a list point-by-point of the information that can be carried from the hardware layer in a given use case and what information (e.g. browsing context) should be transported to the smart card layer

<FMK> I would vote for secure credential storage and attestation.

<virginie> note : the use cases wiki will have to be updated

<FMK> I lost the phone connection. Is the bridge still active?

<rigo> transcation confirmation: Online benefit distribution with the Web

<rigo> what you see what I want to confirm

<FMK> Nice music, but will the phone bridge be re-activated?

<rigo> => discussion about attestations

<rigo> wseltzer: at some point a browser mediated web payment, someone will ask how do we make sure the user had the opportunity to chose the right transaction

<wseltzer> rigo: we don't need to repeat the failed digital signature work, that failed because it had no middle ground

<wseltzer> Virginie: we'll work from use cases tomorrow, look at architecture, privacy, security, accessibility requirements

<wseltzer> Virginie: I think you're free now

<wseltzer> [applause]

- DRAFT -

Hardware-Based Secure Services CG

26 Apr 2016

Attendees

Contents

Use cases and demos

Technical Requirements

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output