Bonjour, Le vendredi 25 septembre 2015 10:36:53 UTC+2, helpcrypto helpcrypto a écrit : > 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.
If a call to C_GetTokenInfo() returns the flag CKF_PROTECTED_AUTHENTICATION_PATH, then there's no PIN code to be sent in calls to C_Login(), C_SetPin(), C_InitToken(), etc. And the real authentication is device/vendor specific. > 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. And if you had the required keys, they would also be susceptible to theft, just as your previous private key. > 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. Technically, it's possible. But it doesn't seem to be a shared goal. Anyway, this wouldn't solve your initial problem. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
