RE: [Web Crypto Next] Lets start discussing !

Hi HelpCrpyto

>>For example, if we give APDU access to smart-cards/sim-cards/secure-elements, how can we ensure that these won’t be used to bypass the security of a PKCS#11 module, or even a higher-level “sign what you see” function that may be made available sometime later?

>If you give that APDU api (and the browsers implement it), then all this conversation will be over.
>I'll send APDUs to each car until i find mines, and then use them directly, easily, and transparent for user.
>Have anyone supported this???

Not exactly in the card space, but this exposure of a simple transport API is what we get our Service Providers to do today when they want their TEE applications talking to cloud or browser services.

Today we have to “kludge” it, by adding a new protocol schema (e.g. TEE://)  to a devices schema list, and piping from the equivalent of APDU's through GET/POST commands to the TA Application via the GP TEE Client API and some Rich OS bridging app/translator.

I don’t see why the same method couldn’t be used to talk APDU's to smartcards via the SIMalliance SE API.

BUT while we can do that today on some devices, it is not a standard and it is restrictive in the format of the communication between browser or cloud app and the TEE/SE resident app.. For example, it is not good for supporting large buffer transfers, or allowing the device to distinguish between different browser or cloud resident apps for purposes of access control (See my earlier email).


BTW: I am not quite sure I understand how accessing SE or TEE is meant to " bypass the security of a PKCS#11 module...". 

What is the expected asset access exposed? From my POV, on a mobile device a PKCS#11 module is probably just an app running in an SE or TEE. If you trust an SE or TEE to run such a module then you also trust an SE or TEE to isolate that PKCS#11 app from the other apps running there (fTPM, DRM, etc etc). TEE's certainly do not share assets outside the owning TEE applications . 

If the PKCS#11 module is not running in the SE or TEE then why does access to the SE or TEE raise the risk? To talk to such a module you are already piping all the PKCS#11 commands through the Rich OS and the browser, both of which are hugely more vulnerable than the SE or TEE. 

If it is an expectation that the PKCS#11 module will be the root of all security on a device and therefor TEE's and SE's have a dependency on it, well I am afraid TEE's and SE's just don’t work like that.


Regards

Don Felton

From: helpcrypto helpcrypto [mailto:helpcrypto@gmail.com] 
Sent: 31 October 2014 08:00
To: Sean Michael Wykes
Cc: Anders Rundgren; public-web-security@w3.org
Subject: Re: [Web Crypto Next] Lets start discussing !

On Wed, Oct 29, 2014 at 3:10 PM, Sean Michael Wykes <sean.wykes@nascent.com.br> wrote:

I think PKCS#11 spec would be an excellent underlying fit for the “middle”-level box that integrates with Web-Crypto, especially when the key discovery mechanism (and cert-discovery) can be used to get a handle on a group of PKCS#11 objects, specifically the triple private-key, public-key and certificate, matched by the same object-id (CKA_ID) as per actual NSS implementation. The PKCS#11 security-model AFAIK is somewhat restrictive (only supporting User-PIN/SO-PIN), with per-token access-control, and thus relatively easy to support.
Cross-browser issue: Will MS support PKCS#11 in IE?
IE should support/implement W3C stantdars, but sometimes they don't.
If Microsoft is present on the group member list, it implies they have interest on this and we could know their position.
 
The “use” of PKCS#11 with pre-provisioned keys and certs is a low-hanging fruit. Your proposed extension would be excellent for this. However, supporting provisioning of tokens, key-generation, certificate-less keys, pin-unblock and the many edge-cases is a bit more difficult.
I agree, if we can see a route forward to supporting the rest (provisioning, admin) and an adequate security model.

One thing that troubles me is how to “increment” security or functionality of any “first-try” solution, once we have an advanced solution available. What is to stop a compromised web-site from calling the “first-try” solution as a means of bypassing higher-level security checks.

For example, if we give APDU access to smart-cards/sim-cards/secure-elements, how can we ensure that these won’t be used to bypass the security of a PKCS#11 module, or even a higher-level “sign what you see” function that may be made available sometime later?
If you give that APDU api (and the browsers implement it), then all this conversation will be over.
I'll send APDUs to each car until i find mines, and then use them directly, easily, and transparent for user.
Have anyone supported this???

Two or three cases here - user-controlled, domain-controlled and “open” (multiple-domain, any-domain).
For the PKCS#11 case, you could probably just default to a “user-controlled” permission (do you want to allow siteX to access certificateY for signatures/encryption [y-once]/[y-forever]/[n]). 

Permissions for the token-administration/provisioning case are more sensitive.
Cards itself usually have an owner/issuer.
In our case, card are from Gemalto but we, as company, are the owners.
Users dont have SO_PIN so we are the only ones capable of unlocking the card.


On Wed, Oct 29, 2014 at 3:44 PM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>Since it is the browser-vendors that eventually have to support the
>solution, the ball is effectively in their court.
Isn't the role of W3C to tell browsers "what/how to implement"?
My bet: we have to find a solution which includes current scenario, altough it could also expand to new approaches, but dumping smartcards isnt going to work.

To sum-up:
 A - Although cards are not web-oriented if we find a solution to include them in WebCrypto, it will be positive
 B - Card management (PIN/PUK) can be done by the owner/issuer or even the user using specific applications, imho: out of scope
 C - Card usage from Webcrypto: seems we all agree its quite ok to use an already populated card.
 D - Key usage: keys/certs could/should be restricted to specific domains (actually hard to do it). user must know what is happening.
 E - Key provisiong: is where most of the problems arise
Are those bullets correct?
Regards.

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