On Tue, Sep 29, 2015 at 2:26 AM, Robert Relyea <rrel...@redhat.com> wrote:
> On 09/25/2015 01:36 AM, helpcrypto helpcrypto wrote: > >> 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. >> > 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). > > 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. > Agree. > 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. > Open source make it easy, as you could simple "comment" the lines and compile. Propietary could be harder to crack. > 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). > Understood. > > 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. >> > Every card does that. The connection between the computer and the reader > is considered 'secure'. > apdu -f -d (or something similar) doesn't agree on Linux. > 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. I partially agree with you. If card has a unique server-trusted component certificate (hence we can know it is OUR card), the communications between card and server could be crypted in a way local application could never decrypt. Futhermore, if the Javacard applet loaded on the card verify server signed request before signing anything, then the protocol is secure ie: batch of 10 docs come with checksum+server signature. GP is the real alternative (I'm not reinventing the wheel), but as I said before, I have a little problem: my card is "closed", I don't have the keys to load/unload applets, neither I have the required keys to establish a secure channel. So, as for your comments, theres nothing I can do with THIS card. Thanks for your time. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
