Hi all
I hope you can find a solution for my problem, cause I can't. (And perhaps it's impossible) Based on my knowledge of PKCS#11 standard, the spec is exposed to a MITM attack that steals the PIN when an application invokes C_Login against a PK#11 library. While using CryptoAPI it's the system who shows the "PIN dialog" making it harder to crack/extract the PIN, C_Login function receives the PIN in plaintext, and "an evil software", like PKCS11SPY, could get access to it. Sadly, using Pinpads is out of scope/beyond our possibilities. Of course my app could check pkcs#11 library checksum and other mechanisms to "ensure" it is the library and not a proxy, but if my application is opensource (I'll love to), I'm fu*ked. Is there any way to "trust" in the client? Can the server know the exe being executed is MY exe and an EVIL copy? (A private key embebed can also be cracked!) 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. 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. I understand this is Anders (& CO) argument about "smartcards were not designed for Web" In the other hand, do you think is possible to "extend" WebcryptoAPI to generate/use keys to/from browser or system keystore? IMHO, how it actually works, sucks. Regards (and thanks) PS: Never trust the client...that also sucks. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
