The following page gives a brief description and provides some references for hardware key tokens for protecting the private key corresponding to a Grid Certificate.
What are Key Tokens
Key tokens are generally devices, often in the form factor of a USB memory stick, which can store private keys PKCS#8. They are then inserted into a PC or laptop in a USB port. Drivers for the token are often required (see below); they must then be unlocked with a PIN. There can be two PINs, one for unlocking the key and one for the "administrator" who can reset the token and the key PIN. A token can hold more than one key, depending on its memory (64K is common, older ones have 32K).
Key tokens provide physical protection of the private key. The key is generated on the token, so you have an excellent level of assurance that the key is generated in a trustworthy way (with good random input) and is stored and protected in a well-defined way. In fact, the normal key tokens are certified to a US standard called FIPS 140-2 to level at least 2 (of 1-4.) (Hardware signing modules protecting CA keys are certified to Level 3 or 4, or, to be precise, they can be run in modes compliant with level 2, 3, or (sometimes) 4.)
Why Key Tokens
Key tokens prevent the key from going walkabout: it is physically in a token which is plugged into a machine - if the token is missing, you know it is missing. While this doesn't give 100% protection - an attacker could still break in and sign with an activated token, including things which are signed in the future (in principle.) Nevertheless, it does prevent the key from being stolen.
Key tokens are types of hardware signing modules (HSMs): the larger ones (PCI cards or networked modules) can also accelerate signing, making it faster than software signing. The small ones we cover here, the key tokens are typically slower than software signing, due to the need to load supporting libraries and drivers, etc.
Tokens cannot be backed up (only HSMs can). The only way to have a backup of the key is to generate it outside the token, and then import it, but we recommend that the key be generated on the token if it is used with an end entity (such as a robot). Tokens are quite resilient - in fact ESNET have reported tokens surviving a (unintentional) wash in a washing machine.
Tokens cannot be cloned (it's a feature, so the key cannot be stolen.)
In summary, the advantages of the key token are as follows (discussion):
- Key tokens offer extra levels of assurance, by protecting the key itself from being stolen: while in the grid world an attacker can sign a very long time proxy from it, which effectively "steals" the key, in the non-grid world, only signatures can be stolen, ie an attacker has to break in and also figure out how to access the token and get it to sign stuff - so an opportunisitic attacker is unlikely to figure it out, unlike with a softkey which can just be snarfed, but a determined attacker who knows what to go for and how to go for it could compromise the security.
- There is a bit of warm and fuzzy feeling about it, too, because if you mention that your key is in a key token they will probably believe that you know what you're doing.
- Key tokens actually offer two level protections of the key, namely something you have (the token) along with something you know (the PIN). Except in the case of automated clients, the tokens have to be activated continuously (or on reboot.)
Where to get key tokens
Aladdin eToken is a commonly used type of key token. Note that if you find a reseller, they may try to sell you drivers with the tokens, but you may not need the drivers. NIKHEF maintain a wiki with information about how to set them up and use them with your grid certificates.
- Installation, drivers: 
- Storing certificates:  and 
- Using it: 
- Using it with Firefox: 
The list of vendors change from time to time, and deep linking to their products breaks even more frequently. This list should be revised from time to time. Not all vendors are easy to use. Look out for the FIPS140 certification in datasheets!