TriCipher divides keys to conquer security
TriCipher Armored Credential System combines multi-part keys and many modes of multi-factor authenticationFollow @infoworld
The TriCipher Armored Credential System really is a suite of utility programs and appliances that allow a company to have secure internal and external communications using authentication that’s difficult or impossible to compromise. TACS strengthens authentication by using multipart encryption keys, storing portions in separate locations, and providing multiple means of storing or deriving those keys to support a wide range of security requirements and user scenarios.
This means you can use features such as tokens, SecureID cards, embedded chips, or even passwords alone as part of the authentication process. And regardless of which methods you use, the split keys (one portion stored locally and the other on the TACS server) prevent the possibility of a compromise even if the user’s device, token, username, and password are all stolen.
If this sounds as if it could be complex, it is. There’s a lot you can do with TACS. The flexibility is remarkable. But putting it into operation will take work. The reason, of course, is that for most users TACS will exist as a collection of APIs. You must modify your applications to call on TACS for authentication.
For easier integration with existing applications, TriCipher will soon offer the TACS Authentication Gateway, which will sit between the authentication appliance and the Web application and handle authentication tasks for the application. Company reps say organizations lacking development support may find the Gateway a good fit, while organizations that require more control over authentication flows and related code may choose to use the APIs directly. The TACS Authentication Gateway wasn’t available for testing in time for this review.
TACS itself consists of the APIs, an appliance that handles key storage and authentication, some management utilities, and a client application. The client application is a Microsoft CAPI (Cryptographic Application Programming Interface) driver, called the TACS ID Tool, which is only required for certain types of credentials, such as device or token multifactor.
Exactly how all of this fits together depends on your mix of applications, users, and security requirements. For example, if you’re creating a Web-based application, you could use the system in a clientless environment in which multifactor authentication includes a browser cookie as part of one of the authentication keys. As always, the authentication server will store the other part of the key.
However, you could also use a more advanced means of authentication. In such a situation, you’d install the ID Tool client application on the Windows computer that’s accessing the protected network, and the client would communicate with TACS via an SSL channel that supports mutual authentication of the client and server. In this case, part of the multifactor authentication could involve a security chip in the PC (some IBM machines have this), a USB key, or even an iPod or digital camera. You could also use tokens and some biometrics. You could, in fact, use more than one of these methods at the same time, and you could use different methods for different users.
In any case, once the TACS client is running on a user’s machine, it’s basically transparent. Users will have to log on with a user name and password, but that doesn’t need to look any different than what they do now.