The chief differentiator between WiKID and other two-factor authentication providers is the use of asymmetric keys as opposed to single-use devices, smart cards or biometrics. The WiKID Client is the platform for the identification of the individual user and the provision of the passcode. Currently, WiKID supports Windows, Mac, Linux, PocketPC, Palm, RIM Blackberry™ devices and Java-enabled telephones. Other devices, such as BREW devices, are planned for future releases. Currently, only the J2SE client using RSA encrpytion algorthms is available under the GPL. We were unable to generate key pairs on wireless devices in an acceptable time using open source encryption packages. The client device requires the installation of a small WiKID client application. This application manages several key processes including key generation, registration, passcode request, passcode reception, and offline passcode verification. The token client can also be run from a USB harddrive. You should treat the WiKID token client as you would your PGP keys or a client certificate (though, WiKID is more secure than client certs, thanks to the PIN's location only on the server).

1. Key Generation. When the application is started for the first time, the application automatically generates an asymmetric key pair. These keys are used for the decryption of the payload from the WiKID Strong Authentication Server server and identification of the device. The keys are asymmetric, and the strength of the key pair is equivalent to RSA1024 bits. The time for the key generation process averages 14 seconds for wireless clients. Key generation times for the RSA-based GPL client are less than 3 seconds.
   
   WiKID has chosen to use the proprietary NTRU algorithm for encryption on our proprietary clients. It is generally accepted that the encryption strength of the NTRU algorithm is the same (or superior) to the existing elliptical curve or RSA asymmetric algorithms, but, with the inferior computing power of the wireless devices, WiKID selected the NTRU algorithm because it is much, much faster when running on a small device. It is important that the key generation be completed on the device, not on a PC or server and transferred to the device. In this way the local client key never leaves the device and is not subject to interception, electronic copying or redistribution. Thus, the WiKID Client functions similarly to a Smart Card. But unlike a Smart Card, it does not require a wired reader, which greatly reduces the cost of implementation and greatly increases portability.
2. Registration Process. Before a WiKID client can authenticate with the WiKID Strong Authentication Server, it must first be registered within the server and the security domain (more specific technical information on registration can be found in the Technical Considerations section of this document) . Each supported security domain requires approximately 1200 bytes of storage on the cilent. There are two methods for registering a device:
   1. Auto-registration. If the domain is configured for auto-registration, the WiKID Client can request registration through the client application. First, the user must use the client application to request that the device be added to the WiKID Strong Authentication Server and security domain in question. The Config menu is used to add a domain. The end-user must enter a server code. The technical security staff should provide this server code. Once this 12-digit code has been entered, the user must establish a PIN for the domain connection. A separate PIN can be provided for each domain, and it is recommended that the user establish unique PINs for each domain. At this point in the process, the public key that was generated in the key generation process is provided to the WiKID Strong Authentication Server. The server will then record the cryptographic key and provide the domain’s public key, a unique identifier for the instance of the device within the security domain and a large registration code. Additionally, the server will generate a second set of keys unique to that particular client device in the security domain for offline passcode verification (see below).

      The registration code is a one-use temporary element. It is not a passcode or password and cannot be used for access to the WiKID system. Instead, the registration code is used to associate the WiKID Client with a known user within a trusted system. When the user goes to the WiKID registration website (or other registration system), he or she is required to enter an existing user ID, identifying information and the registration code. This process associates the client device with the user, verifies the client device as valid within the security domain and activates the client device within the security domain.

   2. Manual Registration.If the domain is not configured for auto-registration, much of the auto-registration process is still followed. The key exchange is the same. The difference is in the final registration step. Instead of the user completing this step, the administrator of the WiKID Strong Authentication Server would associate the client device with the user ID and security domain and enable it. The manual process can be used when an existing user joins the WiKID system and continuity with the existing system is desired.