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 06:45:45 UTC