Introduction

For several years now, the Naval Research Laboratory has, with the permission of the HPC Modernization Program, undergone a pilot program to evaluate a possible replacement for the SecurID hardware token currently used as a Kerberos preauthentication mechanism. The token chosen for this pilot program was the RB-1 token produced by the CRYPTOCard corporation.

This paper presents a technical comparison between the currently used SecurID token and the CRYPTOCard token, the results of this pilot program, and a recommendation as to the feasibility of migrating to the CRYPTOCard token within the HPC Program.

Technical Comparison

The CRYPTOCard RB-1 token is a credit-card sized challenge-response token. It is similar in size and appearance to the SecurID card currently in use; it has a numeric entry keypad and an eight-character LCD display. In pure physical construction it has one small advantage over the SecurID card; the front of the card only has glass over the LCD display instead of the whole card like the SecurID. This makes keypad entry much easier, as the user gets more tactile feedback when they press a key. Also, this in our experience makes the card more durable; when we used SecurID we had numerous failures of the SecurID card from damage to the glass that makes up the entire front panel.

The CRYPTOCard is powered by two user-replaceable lithium batteries (CR2032). Batteries can be change individually to retain card programming. With the exception of physical damage, the CRYPTOCard has an indefinite lifetime.

From an algorithmic perspective, it is a basic challenge-response token using the DES encryption algorithm. A user is displayed a challenge by the authentication software, enters the challenge onto the card, and the card displays the response to the challenge on the LCD display. The response is computed by using a stored DES key on the card to encrypt the challenge, and displaying the upper four bytes of the encryption output in hexadecimal. The card is PIN-protected by a locally stored PIN; the user must enter the PIN before the card is unlocked. The card can be programmed for a fixed or user-changeable PIN, a minimum PIN length, and a maximum number of tries before the card is locked. The DES key used on the card for challenge computation is programmed by the customer (in our case, it would be the HPC center that issued the card who would program the DES key onto the card).

To contrast this with the SecurID card, the SecurID card uses an until-recently undisclosed proprietary algorithm to generate a sequence of PINs. This algorithm has been publically disclosed on the Internet, but is still believed to be non-invertible (it's not possible to know the next PIN without knowing the secret programmed on the token). But since the SecurID algorithm has not been subjected to the same public scrutiny as DES, the cryptographic security of the SecurID algorithm is not as clear as DES.

The SecurID card secret is programmed into the token permanently by RSA Laboratories, which means not only does RSA hold the key to the token, if the token secret is compromised the token must be returned to RSA.

From a software standpoint, the CRYPTOCard includes a basic administration system, but for Kerberos hardware preauthentication all of the necessary software components are bundled into the Kerberos KDC. This means there is no requirement for an equivalent to the SecurID ACE Server; the Kerberos KDC implements this role completely. However, a CRYPTOCard programmer is required to initialize the token with the DES key stored on the KDC. This has the advantage that the cards themselves do not come with an corresponding card secret like the SecurID token, thus simplifying their management and reuse.

Results of NRL Pilot Program

During the NRL Pilot Program, we gave users in our realm who required HPC access CRYPTOCard tokens instead of the SecurID tokens. During this time, we observed the following:

• Users who have never used a hardware token before had, what we judged to be a ``normal'' number of problems. This is of course the usual set of problems with people grappling with something new, forgetting the PIN the first time, unfamiliar with the operation of the card, and other such issues.

• Users who have used SecurID cards before required some retraining. The biggest difference was that the user interface is different. Users must first enter the PIN to unlock the CRYPTOCard, then enter the "next response" code. This wasn't complicated, but it was a change that previous SecurID users had to adjust to. We were able to mitigate this partially by putting an instruction sheet into the wallet that comes with the CRYPTOCard.

• Once we got a user up and working with CRYPTOCard, they had a low administrative cost compared to SecurID. Because the CRYPTOCard does not utiliize a real--time clock, it cannot get out of sync if the card is not used for long periods of time. Other than physical/electrical card failure, we had very few user problems once they were set up.

• Once problem that we did encounter was the use of the PIN. Because the PIN is local to the card, it has a maximum number of failed attempts before the card is locked. When the card is locked, it is zeroized and must be reprogrammed. This involves either a fairly lengthy dialogue with the user to reprogram the secret onto the card (which we found most users are not capable of doing) or returning the card back to the center to be reprogrammed. We didn't find this to be a large problem, but it is a marked departure from the SecurID token (which does not have this problem). The card can be programmed to have an unlimited number of PIN attempts if this is a particularly troublesome issue, but we choose to stick with the PIN limit and reprogram cards that were zeroized by users.

Overall, we were pleased with the outcome of the pilot program. It proved to our satisfaction that the CRYPTOCard can serve as a reasonable replacement for SecurID.

Feasibility of Migration

• We recommend a gradual ``phase-in'' of the CRYPTOCards. Since a KDC can concurrently handle both CRYPTOCard and SecurID, the simplest approach would be to give new users, and users who SecurID card is expiring, CRYPTOCards. This also allows us to address problems with a much smaller user base.

• A concerted effort must be placed on training help desk and administrative staff on the differences between the CRYPTOCard and SecurID. Special emphasis must be placed on the difference in the PIN between the two cards.

• It would be possible to have a stack of pre-programmed CRYPTOCards available for off-site SAAAs (during the NRL Pilot Program we programmed each card as we needed it). This would mitigate some of the issues surrounding the PIN handling and inadvertent card zeroization. To do this, however, would require additional code to be written. If this is desired, sufficient time should be allocated to implement and test the code to manage the cards.

In conclusion, we feel that the CRYPTOCard is a viable replacement for the SecurID token, provided that the above recommendations are followed.