RE: [Web Crypto Next] Lets start discussing !

Hi Andres and all,

> One reason why simply bolting NSS et. al. to the web wasn't considered is
> because NSS wasn't designed to be called by arbitrary, potentially malicious,
> transiently downloaded web-code.  The same is valid for EMV-cards which are
> to be used in specific terminals equipped with certified software.

In general a sensible SE resident application should not be assuming it will be plugged into a certified terminal, as clearly the first fraudulent act will be to plug it into a non-secure terminal. If an SE resident application needs trust, then its first act must be to validate the far endpoint. 

As such, properly written SE (and similarly TEE) resident applications should be written to be proof vs unauthorised external entities. Typically this is achieved by bringing up a secure channel (at least end to end authentication) to the critical endpoint, over whatever transport channel is offered.

The world is not properly written. I agree there are some poor application interface designs on some SE's that are susceptible to attack (e.g. EMV and UICC PIN injection weaknesses that lock the device/card). Generally these were put in place before connectivity expanded. That is where device level firewalls (such as the GlobalPlatform SE Access Control (GP SEAC)) provide critical protection underneath general access channels (such as the SIMalliance SE API or GP TEE Client API) come in to play.

A browser or cloud resident application communicating to the SE or TEE resident application has to provide some sort of authentication appropriate to the SE or TEE asset it is interfacing to.
A browser or cloud resident application communicating to security services (PKCS#11, DRM, FIDO etc) being offered by the browser on behalf of an SE or TEE also has to provide some sort of authentication appropriate to the SE or TEE asset it is interfacing to.

So my question is then - do we need to mandate such an authentication based, TEE/SE resident application access limiting, firewall or is presence of such a firewall an implementation specific choice? 
If we do mandate such a firewall then we need to extend existing schemas that enable the firewall to trust the identity of the endpoint.

My opinion is that for TEE/SE resident application access, the presence of a firewall at all should be a device implementation choice. There are SE's which have old weaknesses (such as the PIN locking issue), and against that, TEE's and SE's being used for new tasks which don’t have such weakness's, and there are classes of device where those weak SE's don’t exist or are not accessible.

Frankly a "firewall" is a terrible thing and I would instead like to drop certain classes of SE's with weak applications on them from the browser exposed interface set. But (and its quite a big BUT)  that group includes UICC's so I guess the MNO community would be upset if our new browser interfaces couldn’t talk to their card base, and frankly the UICC is probably the most widely deployed SE with potential internet connectivity today. 

Just to be clear, above I am not talking a user or SO authentication (approving some unknown code to do a privileged operation) I am talking about trust in the code on top of trust in the user.

I will leave it to the browser experts as to how they authenticate a block of javascript or other browser or cloud resident app to the underlying device end systems.

Regards

Don Felton

((For those who aren’t aware, GP SEAC provides an application ID based firewall scheme for interfaces such as SimAlliance SE API and GlobalPlatform TEE SE API 1.0. Creation and validation of that ID is an OS level task but the endpoint identification principal is applicable in a wider scope. Management of the firewalls rules is via designated remote entities. I am only using the GP SEAC as an example.))

> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com]
> Sent: 30 October 2014 04:07
> To: Siva Narendra
> Cc: helpcrypto helpcrypto; public-web-security@w3.org
> Subject: Re: [Web Crypto Next] Lets start discussing !
> 
> Hi Siva,
> 
> As seen from the messages on this list we are not anywhere near consensus on
> what to do so the best I can do is elaborating a bit on my conclusions which are
> both based on facts and on observations
> 
> One reason why simply bolting NSS et. al. to the web wasn't considered is
> because NSS wasn't designed to be called by arbitrary, potentially malicious,
> transiently downloaded web-code.  The same is valid for EMV-cards which are
> to be used in specific terminals equipped with certified software.
> 
> FIDO's U2F addresses this problem in a novel way which though requires new
> middlware, hardware and browser upgrades.
> 
> The problem (that we agree on), is that U2F (in its current incarnation) is not a
> replacement for existing smart cards.
> 
> Various solutions have indeed been suggested but since these have all been
> dismissed/ignored by the browser vendors, it is really up to the browser vendors
> stating their take on the matter.
> 
> The Swedish banks have after the removal of browser plugin support replaced
> their web-based PKI-solution with iOS and Android apps. It is not pretty but it is
> better than nothing :-)
> 
> Sincerely,
> Anders Rundgren
> 
> On 2014-10-30 03:28, Siva Narendra wrote:
> > Dear Anders --
> >
> > Some clarifications:
> >
> >  1. Apple Pay with Apple Watch will work on older iPhones as well as iPhone 6.
> >
> >  2. Let us not confuse smart card plastic with smart card chips. Just because
> smart card plastic cannot be plugged into a PC/client device doesn't means
> smart cards cannot be through USB, BLE, or NFC.
> >
> >  3. It is not that smart cards (chips) are not designed for the web. Web
> browsers (other than Firefox and to some extent IE) are not designed to easily
> integrate to the smart card (chips). If all of the browsers implemented NSS,
> smart cards will work out of the box with them. There are other alternatives, but
> the standardization that is missing is on the browser side. Not on the smart card
> side. FIDO is one possible solution, but has virtually zero penetration. And I do
> not know of a single company that would bet the farm only on FIDO. Globally
> there are lot more smart card (plastic and chips) what work with the web as
> opposed to FIDO devices. In fact from what I understand FIDO devices will also
> use smart card chips.
> >
> > -Siva
> >
> >
> > /
> >
> > /--/
> > //Siva G. Narendra Ph.D.
> > /CEO - //Tyfone, Inc.
> > Portland | Bangalore | Taipei/
> > www.tyfone.com <http://www.tyfone.com>/
> > /Voice: +1.661.412.2233/
> > /
> > /
> >
> > On Tue, Oct 28, 2014 at 11:48 PM, Anders Rundgren
> <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>
> wrote:
> >
> >     Apple didn't try to retrofit the old devices when they created Apple Pay.
> >
> >     Although there are business models involved as well, Apple would also
> >     have created huge problems for banks (and users) if everybody have
> >     had to implement (and use) a "fallback" solution as well.
> >
> >     I.e. you should IMHO not expect PKCS #11 and existing smart cards to
> become
> >     a part of the plot because they were simply put not designed for the web.
> >
> >     Regards
> >     Anders Rundgren
> >
> >     On 2014-10-28 09:09, helpcrypto helpcrypto wrote:
> >
> >         Hi
> >
> >
> >         Don't know if I'm late, but as nvdbleek proposed [1], we are truly
> interested in a web-document signing approach.
> >
> >         Actually we suffer Java applets, and dream about a Javascript alternative
> (like Webcrypto) but with the possibility of looking for an specific key (even at
> specific card).
> >
> >         So, something like findCertificate(token,filter) where filter can be subject,
> issuer or a combination of them would be great.
> >
> >         Regarding to population, we have several smartcards from different
> manufacturers which -sadly- use different PKCS#11, so
> generateKey(token,keyinfo) could also be interesting.
> >
> >         Finally, we do batch signing, where one PIN let the user sign a batch of
> documents (currently hashes), so this feature is also very interesting.
> >
> >
> >         With these constraints in mind, we propose -more or less- the following
> API:
> >
> >           - optional getToken to retrieve a token handle to work with. This could
> be also issues to secure communications between server and client, using SM
> and/or component certificates like some eID.
> >           - getCertificate(filter) which can allow us to filter and show a "filtered
> dialog". some exaples: fingerprint, issuer, subject, keyUsage...using a json-like
> filter which allows combination seems to be much better.
> >
> >         Signatures are made in 3 steps:
> >           - init: needed initialization
> >           - add: invoked for each document we want to sign. the document is sent
> to the component/browser and stored internally
> >           - final: a final "you are going to sign this" dialog is shown. It will be
> possible to even show a preview of the documents (pdf,xml+xslt,...) using other
> plugins. asks for pin
> >
> >         Of course, all this must be Js asynchronous
> >
> >         We usually do XAdES or PAdES signing. probably a signed js library or
> something lika that could be great to extend usage.
> >
> >
> >         This is what actually our applet does, and its the use case we would live to
> have on Webcrypto.
> >
> >         Don't hesitate to contact me if you want to discuss this in deep.
> >         Regards
> >
> >
> >         [1] http://www.w3.org/2012/webcrypto/webcrypto-next-

> workshop/papers/Using_the_W3C_WebCrypto_API_for_Document_Signing.ht
> ml
> >
> >
> >
> >
>

Received on Friday, 31 October 2014 16:16:52 UTC