On Fri, Sep 25, 2015 at 11:15 AM, Andreas Schwier < andreas.schwier...@cardcontact.de> wrote:
> 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. > If you are talking about 7816 SM, we can't, cause the provider doesn''t give us the needed keys. > 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. > Our card doesn't support that. Also note that not only the PIN is exposed, but the requests for signature. (I send 5 documents to be signed, evil application add 1 and the user signed 6 without our knowledge) > 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. > Sadly, our card is "closed" and we are not able to do anything...otherwise i could load a Javacard applet to do what I need in a secure way. > 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. > Have to have an eye on [1]! > > > 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 > I really have to read about this, but I don't know if our card will support it. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
