Re: [Web Crypto Next] Lets start discussing !

[Anders Rundgren]

On 2014-10-31 10:00, Don Felton wrote:
Hi Don,
comments-in-line.

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.

What you are talking about here is outside of NSS which was what I was aiming 
at.
Related: http://webpki.org/papers/key-access.pdf

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.

Personally I don't see UICCs as a suitable target for WebCrypto.Next:
http://lists.w3.org/Archives/Public/public-web-security/2014Oct/0058.html

Regards,
Anders Rundgren

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....@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....@gmail.com <mailto:anders.rundgren....@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