TruePass Assures a Safe Journey for Internet Transactions: Page 4 of 5

From the Web client PC, I connected to the SAS URL and selected the "Zero Footprint Client Side Operations" option--the menu options can be customized to your company preferences. At this point I had to choose from three different credential storage options: software-based roaming credentials using SPEKE (Simple Password-authenticated Exponential Key Exchange) protocol, file system-based credentials or Microsoft Crypto API (CAPI), which is called "MS Security Framework" by default on the SAS customizable menu. CAPI contains two suboptions: storing credentials in the registry or on the smartcard.

Next, I selected the "Create Windows Security Framework User" option to store the TruePass credentials in CAPI and entered credentials that matched the shared secret text file. I also checked the option to put the credentials on the smartcard. The SAS server then verified the shared secret and triggered the SAS applet to begin key and certificate generation. The enrollment applet generated the private signing key and stored it on the Schlumberger card. I was also prompted to enter on the smartcard a PIN, which adds another level of authentication.

The applet then used the credentials (the private key) to digitally sign the challenge string that the servlet presented. After the challenge string was verified, a digitally signed session cookie was issued. According to Entrust, this session cookie could be presented to any TruePass-protected Web server in that domain or in affiliated domains. This feature would allow companies to protect back-end resources beyond the Web server.

Transaction Signing

The demo application provides a "Transaction Signing" option, which I selected. I was asked to fill out a sample stock purchase request and submit to the Entrust TruePass servlets. The result returned to the TruePass servlet was a read-only confirmation page for the transaction. The TruePass servlet made a copy of the confirmation and forwarded a copy to the applet. If you agree to sign the returned read-only transaction page, your digital signature is added to the HTML document, and the servlet compares the unsigned copy of the HTML page to verify that it has not been modified. If the pages match, the servlet adds its own signature to the read-only form as well. This double-signed confirmation page is sent to the transaction server and can be used later for nonrepudiation.