RE: Proposed API Extension for X.509 Certificates and Smart Cards


I think this again comes down to the argument: 
What crypto tools do we put into the hands of inexperienced web developers.

The current state of affairs in the enterprise world is that IT departments install browser plugins on employee PCs.
Or use the dreaded Windows "looking for credential tiles" stuff for smartcard access which is restricting employees to Internet Explorer.

I would like to have a standard way to use my corporate smartcard in my browser of choice without needing plugins.

The "use case" in the first email of this thread was "sign a form using a smartcard key".
May be this is harder to abuse if we require an "authentication vector" like in Generic Bootstrapping Architecture and require the operation's result to be encrypted to the recipient too.
https://en.wikipedia.org/wiki/Generic_Bootstrapping_Architecture

http://www.tml.tkk.fi/Publications/C/22/papers/Olkkonen_final.pdf

The authentication vector is validated on the smartcard and it only signs bytes if the validation is successful. 
This scheme make abuse of the operation quite hard. The weak point is in the deployment of the key material because the attacker could convince the employee to accept the attackers key material to be used at the corporate portal.

FIDO is not solving the sign-bytes-with-hw problem, they are doing 2FA "only". By restricting the API to a more specific problem they come to an acceptable "solution".

I think we should not standardize an API for the sign-bytes-with-hw for any RP but better standardize sign-bytes-with-hw for known RPs.
My example was from the enterprise world and I think this more likely to be used but banks and telcos might have needs for this solution in the consumer space too.

-Axel


-----Original Message-----
From: Jeffrey Walton [mailto:noloader@gmail.com] 
Sent: Friday, February 14, 2014 7:45 AM
To: Anders Rundgren
Cc: public-webcrypto-comments@w3.org
Subject: Re: Proposed API Extension for X.509 Certificates and Smart Cards

> Regarding the attack-vectors you describe, I think it would be 
> extremely valuable having some kind of guidelines on how to build 
> secure sites using WebCrypto including cross-origin applications.
Same origin violations worry me too. I'm very concerned secrets will be accessible to unauthorized sites (and unintentionally to authorized sites).

"Fast and loose" could have a lot of negative consequences considering the abundance of misconfigurations and XSS in practice.

Jeff

On Fri, Feb 14, 2014 at 1:31 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> On 2014-02-14 00:17, Ryan Sleevi wrote:
>>
>>
>>
>> On Thu, Feb 13, 2014 at 1:09 PM, Samuel Erdtman <samuel@erdtman.se <mailto:samuel@erdtman.se>> wrote:
>>
>>     I do think that it would be useful to have some level of access to keys on secure storage, smart card, from javascript in the browser.
>>
>>     The use case that I think is relevant is:
>>     Organisations that does not trust other storage then e.g. smart cards wants to sign web forms. This problem has been solved by browser plugins and similar solutions. Or has been excluded from the possible use for the smart cards.
>>     With the suggested solution we could move away from browser plugins and still use keys on e.g. smart cards.
>>     Is that not a use case? or a problem worth solving?
>>
>>
>> "Is that not a use case" - No, not really. It fails to capture the problem the why of the problem you're trying to solve, which makes it impossible to consider other solutions other than the proposed solution.
>>
>> Look at http://www.w3.org/TR/webcrypto-usecases/ to understand that the goal of the use case should be to try to break requirements into decomposible operations - with the goal of demonstrating how there is missing "goop" that is needed.
>
> I did:
> http://www.w3.org/TR/webcrypto-usecases/#banking-transactions

>
> Unfortunately it doesn't match anything I have seen in spite of being a long-time user and more recently a vendor representative in this particular space.
>
> BTW, a primary reason for using smart cards is simply the fact that they are distributed (handed over to the user) physically.
>
> Regarding the attack-vectors you describe, I think it would be extremely valuable having some kind of guidelines on how to build secure sites using WebCrypto including cross-origin applications.  Your message seems to be that even well-written web-applications are susceptible to XSS. That's at least news to me (here disregarding self-induced XSS via the JS console).
>
> Cheers
> Anders
>
>
>>
>> Your use case fails to explain the trust relationship between organizations. Is the idea that every website I go to will issue me a new hardware token? Surely not, so now we're into situations where we're either talking about issuing parties and relying parties (ie: what everyone so far has really been talking about), and _why_ they don't trust storage, and _what_ they're trying to accomplish.
>>
>> The example of non-repudiation is a prime example of security snake oil. A smart card doesn't buy you any more protection from malware than storing the key on disk. Further, I think if we work through some of the flows, it MAY appear that other solutions - whether OpenID Connect, FIDO, Browser ID, or who knows what - may make a more sensible alternative for the web.
>>
>> It also helps highlight the security assumptions and threat models. What good is storing the key in hardware if hostile JS can sign arbitrary messages? The arbitrary JS may be from XSS on the site, from local extensions injecting into the DOM, or even from self-XSS (eg: via the JS console). Or consider CA compromise or misissuance - the latter of which is a problem of unknown scope. All the security benefits of a secure element disappear under such a MITM attack, and would be the modern-day equivalent of drive-by malware being added to users machines.
>>
>> Further, by establishing the composed operations, we can also more reasonably discuss whether a different solution is better suited for the web platform, or where there are gaps in the available technologies (independent of Web Crypto) that need to be filled. Consider "middleware" implemented as postMessage + Service Workers as an example of such a hypothetical.
>>
>>
>>     Regarding having to reissue lots of certificates, several setups that I have seen have self service for renewal of cards so it might not be super hard to do. Further certificates might be valid for three years i.e. within three years it would be possible to have this attribute on all certificates that needs it (seems reasonable in my world).
>>
>>
>>     Finally if a card is issed for a domain, then you cannot sell or leave that domain until those cards have expired, more or less three years (not an eternity). That will have to be a consideration to take into account when starting to issue certificates with this attribute.
>>
>>     Cheers
>>     //Samuel

Received on Friday, 14 February 2014 08:51:39 UTC