A Couple “ID Tool ToGo” Questions Addressed
Thanks to Michael Berman over at Grok Computer Security for the mention Friday, following the announcement of ID Tool ToGo. Also a nice article over at Dark Reading “Authentication Goes USB Route“.
I thought I’d respond here to Michael Berman’s comments and provide a couple confirmations and clarifications:
Yes, we use two authentication “stores”. In the TriCipher solution (our name alludes to our 3-key technology) set, we use public key crypto, but instead of having a single private key and public key, each user has 2 private keys and a public key. A private key the user controls and a second private key kept on the TriCipher ID Vault appliance. Of course, then there is a 3rd key, the public key.
For our “USB key” feature, the USB device serves as the 2nd “what you have” factor and of course works in conjunction with the user’s password. These two components are used to recreate what is best to think of as the “user’s key”. Note that loss or theft of the USB key provides an attacker no attack vector to guess or work backward to the password. Same with theft of the password. Whether phished, pharmed, keylogged or social engineered in any way, possession of the password alone is useless without the USB key.
The “user’s key” is used in conjunction with the other private key for that user kept on the ID Vault (ID Vault key). To properly authenticate both the user’s key and the ID Vault key are used to co-sign, if you will, and consequently create a standard, x.509 certificate based, verifiable signature for any client-SSL enabled relying party site. A decent analogy is going into a bank to open a safety deposit box where the bank manager has a key and you have a key. The safety deposit box can only be opened when both parties are present and perform their function.
Couple important points:
- Relying party needs no TriCipher code to accomplish this standards-based function.
- The two private keys for each user are never recombined anywhere to be compromisable in a single location.
- The user’s private key is never stored anywhere, ever.
While an understandably confusing point, no, we do not get in the middle between authenticating sites and users. We utilize the true two-way, mutual authentication SSL mechanism built into both the server and client ends. All our “magic sauce” briefly described above is done between the client and the TriCipher ID Vault directly. It is pretty accurate to think of the connection between the client and the ID Vault as forming a secure, virtual smart card. Certainly as far as all the client code is concerned, the signature is performed by a local, smart card as we again use the existing standards for signing procedures, CAPI and PKCS11.
Of course, there is a lot more to tout about the benefits of our solution, but I’ll restrain myself to hopefully clarifying a couple points this particular product function raised.