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

On Feb 14, 2014 1:37 AM, "Jeffrey Walton" <noloader@gmail.com> wrote:
>
> > 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".
>
> There's an architectural defect here, and 2FA is just doing the "dumb
> thing" twice.
>
> The dumb thing is using basic_auth like schemes, where the username,
> password are put on the wire after the SSL/TLS tunnel is setup.
> Sending the second factor the same way means you made the same mistake
> twice.
>
> When the authentications (server vs client) are disjoint or
> asymmetric, the channel must be bound in some way. But that's not
> happening and the bad guys have been making us pay the price.
>
> 2FA kind-of partially solves the problem. Even with 2FA, the
> {username, password, otp} will still be vulnerable for use by the
> attacker during a window. The argument goes that after 1 or 5 minutes
> or so, the bad guy will only have the username and password, and not
> the new otp.
>
> Hoping that the bad guy cannot begin predicting the otp is simply
> foolish (cf., "A closer look into the RSA SecureID software token",
> http://www.sensepost.com/blog/7045.html). Also, what happens when a
> server is compromised and all the algorithms and parameters are lost
> for a user base so the attacker can begin minting token generators?
>
> Jeff
>

If you read the FIDO spec, you will see it is not OTP like you described.
It actively mitigates MITM and phishing the OTP.

Cheers.

> On Fri, Feb 14, 2014 at 3:42 AM,  <Axel.Nennker@telekom.de> wrote:
> >
> > 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
> >
>