Friday, June 22, 2007

TriCipher Responds

After I published TriCipher USB key, Tim Renshaw, VP Field Solutions at TriCipher responded with the following confirmations and clarifications:
Yes, we use two authentication "stores". In the TriCipher solution (our name aludes 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.

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.

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.
I still have to wonder about the compromised computer kiosk. If I insert my USB key into an 0wned system, can that system rip the token from the key and log my password?

No comments: