On 09/25/2015 01:36 AM, helpcrypto helpcrypto wrote:
While dialog pin prompts don't really help all that much (if the attacker has your machine, they can pop up their own dialogs, just because the PKCS #11 software enforces a login, doesn't mean that the cards do. At the bottom the application can always talk directly to the card).Hi allI 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.
If you want dialog pin prompts, you can always just use protected pin path tokens, but then your application will only work with protected pin path tokens.
If your machine is compromised to the point that the attacker can insert PKCS11SPY into your PKCS #11 chain, there's very little you can do.
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.
Open source doesn't make this any worse, your proprietary app can be changed to accept the new checksum, or skip the checksum step altogether. In order to proxy PKCS #11 this way you need to be able to install a PKCS #11 module that does the proxying.
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!)
Short answer: No. Long answer: The best you can do is under certain conditions the server can know the authentication key is in a token, but only if the server is part of the infrastructure that issued the cert and key and performed the appropriate checks to verify the key is in the token (and only in the token).
Every card does that. The connection between the computer and the reader is considered 'secure'.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.
bob
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.
You'd need your own protocol for this. Card management systems usually do this with their own protocol where the server talks to the card directly through a global platform secure channel. This only works because the server is part of the trusted base for the card management system (e.i. the server knows the keys that even the user doesn't know for his card). Even then, you don't know that the user saw want documents he thinks he's signing because in your scenario the client computer is fundamentally untrusted. In the case where the computer is untrusted you can't get any guarantees. That's why most protocols assume that the client is at least trusted by the user of the client.
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.
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
