On 19/04/12 17:21 PM, helpcrypto helpcrypto wrote:
(to me, that question makes no sense. users can't talk to smart cards.
Only smart card readers and programs can. So what smart card reader and
what program is doing this? A dumb smart card reader and a browser,
following Javascript instructions from a website? That'd be game over...)
Why a website "cant" use javascript to communicate with the card?
I can see where this difficulty is, I've worked on smart cards and it is
... perverse. I'll see if I can explain it. As an aside I have no idea
what the NSS people think, I'm not speaking for them, and they don't
typically like what I say :) Apologies out of the way, onwards!
No, javascript or any other random agent cannot talk to the card ...
just willy nilly. The logic goes like this:
The architect cared enough about the business and its risks to go for a
very expensive security option - a smartcard. This design placed
important secrets into a trusted platform which would not reveal or
misuse them, and the only reason to use such an expensive and awkward
form factor is that the architect really really cared about the secrets.
Now, *if you are serious about the security model*, then you will have
to do all the work to make the entire platform suite up to the same
level of security. (Otherwise you are not serious.)
This means that you need to ensure that whoever gets the smart card to
do important things has to be also /at the same level of security/.
That is, a peer. There are several ways to do this, but let's look at
the most simple for explanation: by being the same, in other words, by
being a smart card.
Good smart card security models will have smart cards talking to smart
cards. To do that, they need some concept of communications, which is
what SMs are (I'm guesssing here). (There are other ways, but as I say,
this is for explanation.)
So, your issue here is how do you prove that your javascript website is
a peer to the card? Well, it must have a smart card ... which
communicates via SMs ... which changes the nature of the application
tremendously ...
and as far as I know, that's not available in Firefox. Therefore we are
left at some sort of compromise. The compromise is probably something
like Firefox having a very tight rein on what can be done ... and in
practice this is strictly to handle things it knows about. e.g., client
certs to help setup SSL sessions and decrypt mails / encrypt mails.
*Nothing else* because otherwise Firefox is opening itself up to
breaches, it thinks. So the compromise here is that Firefox is saying
that it is the peer, and no other agent can be part of that. Including
plugins (?) websites and the like.
A signed applet, for example, can read your hard drive
contents/execute, but only if you accept to do so.
Why cant we just show an allow/deny warning when trying to use a
pkcs#11 interface?
Sure. But, that's a different level of security. Disk drives and
signed applets are moderate-to-boring. Smart cards are several cuts
above that. Just as an example, a proper security model would never let
a user choose low level things out of its trusted platform. E.g., "pay
now" and "enter pin" are good user things, "read cert" is not.
At least i hope you understand what im asking for. You can think its a
good or bad idea, but i hope you understand "my needs".
Maybe. You want the smart card to authenticate itself to you? I think.
Have you thought about imposing client certs in Appache/httpd and
setting up an SSL connection? Then, in httpd, you can expose the
certificate and present it in program variables.
There was also some mention of document signing. Yeah, I think I
understand that application ... and I'd say you haven't got a lot of
hope there in getting the smart card open for that via Firefox. How
about a downloaded app?
Again, the main basic core question is:
I need to do control an smartcard from web. Is that a logical a
request? (No matter what protocol or system do we use...its reasonable
to request that)
See my emphasis above. If you really care about the security model, you
have to have something of equal security speak to the smart card and
communicate at its level.
In the alternate, you don't care enough. So you don't need smart cards
at all. You're better off using software techniques.
(It would be nice to use software client certificates, but I think you
can now see that the above security implications and especially the
compromises left software client certs in an equivalently strangled
position - they were treated as crippled smart cards rather than as
security-balanced tools, and the result was that they were broken on two
counts not just one.)
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
