Hi, you mention a common problem with PIN authentication and smart cards: To keep the PIN protected on the path between the PIN entry and chip must be protected.
There are two alternatives: 1. Establish a secure channel between the card and the PIN pad. 2. Replace PIN authentication with public key authentication The first is what TR-03110 does with PACE: The PIN is never traversing the path from PIN pad to the card. Alternatively you could use a protocol like ChipAuthentication to create the secure channel before PIN verification occurs. For C_Login the alternative is to use CKF_PROTECTED_AUTHENTICATION_PATH and have a PIN dialog in the PKCS#11 module. The second option is not very common with cards, even though that has a lot of potential for server based scenarios. In the current SmartCard-HSM we support creating a secure channel using ChipAuthentication and use that channel to submit the PIN. The secure channel is based on a 3 tier PKI that is used during device production to issue a device certificate for the ChipAuthentication public key. In the upcoming 2.0 release of the SmartCard-HSM we support public key authentication (PKA) as replacement for PIN. PKA can be used in combination with an n-of-m threshold scheme, so it is specifically suited for applications where access to keys must be shared between key custodians. > Furthermore, our *lovely* card sends APDU for login in plainText, so anyone > could see "1234" easily. And we are not able to establish a secure channel > cause we lack the required keys. > > > Seems what I really need is something like a Javacard applet with an > embebed "server public key", a component certificate and a session keypair > for mutual authentication and cipher communications between server and > client, but we aren't able to load this applet on the Card. That's what the SmartCard-HSM does. And this is the mechanism we use with the PKI-as-a-Service Demo [1]. A client (OCF) that acts as a reverse APDU proxy connects to the server. The server application talks to the remote card just like it talks to a locally connected card. It initially reads and validates the device certificate, establishes a secure channel with ChipAuthentication and then perform operations with the card. In the demo case, the PIN is entered locally at the client, either in pop-up or using a PIN pad reader. The PIN is then bound to the secure channel and if the secure channel terminates, the PIN authentication is reset. > > So, to sum up it seems it won't be possible to do what I need: a server > asking to sign 10 documents and being sure only those are signed. That can be done. I even know a web based application that can electronically sign document according to the strict German signature law. > > I understand this is Anders (& CO) argument about "smartcards were not > designed for Web" Not all smart cards are equals ;-) > > > In the other hand, do you think is possible to "extend" WebcryptoAPI to > generate/use keys to/from browser or system keystore? That is something I never understood. Why does WebcryptoAPI not support PKCS#11 ? What's the hidden agenda with software keys in the browser ? Is it because Google/NSA want to know the key ? > IMHO, how it actually works, sucks. FullAck. Andreas [1] http://demo.openscdp.org/paas.html > > > Regards (and thanks) > > PS: Never trust the client...that also sucks. > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > opensc-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
