BioID uses cryptography technologies to fulfill its security requirements concerning privacy, authentication and integrity. To have privacy, we use data encryption and data decryption algorithms to keep anyone except the intended recipient from reading our data objects. For the authentication, the verification of the identity of BioID clients and servers, we use digital certificates and public key exchange (authentication services of the underlying operating system are also used). And finally, to keep our integrity by means of being sure that the data received is exactly the data that was sent, we use digital signatures.
All cryptographic operations need cryptographic keys. BioID uses two types of cryptographic keys: Session Keys and Public/Private Key Pairs.
Session keys, also called symmetric keys, are used with symmetric encryption algorithms. Symmetric algorithms are the most common type of encryption algorithm. They are called symmetric because they use the same key for both encryption and decryption. Session keys are frequently changed, usually using a different session key for each message encrypted.
Symmetric algorithms are faster than public-key algorithms. Thus, they are preferred when encrypting large amounts of data. Since a good deal of the activity involving session keys relates to keeping them secret, it is important to keep the number of people who possess a particular session key as small as possible. Thus usually only a BioID Server is able to decrypt the session keys (although they are most often created by clients).
BioID uses two kinds of session keys, randomly created keys and a password-derived key. The random keys are used to encrypt any kind of data. For their transport the random session keys are always encrypted with the receivers public key exchange key. The password derived session key is used to encrypt public signature keys in signatures where the receiver has no access to the sender's public key but knows the derived session key. Because the password derived session key is a secret within BioID applications it is never transported. Note: with BioID V3.1 the later mechanism is not used any longer.
Public/private key pairs are used for a more secure method of encryption called asymmetric encryption. Asymmetric encryption is used mainly to encrypt and decrypt session keys and digital signatures. Asymmetric encryption uses public-key encryption algorithms.
Public-key algorithms use two different keys: a public key and a private key. The private key member of the pair must be kept private and secure (BioID makes one exception under a certain circumstance, see below). The public key, however, can be distributed to anyone who requests it. The public key of a key pair is often distributed by means of a digital certificate. When one key of a key pair is used to encrypt a message, the other key from that pair is required to decrypt the message.
Unfortunately, public-key algorithms are very slow, - roughly 1,000 times slower than symmetric algorithms. It is impractical to use them to encrypt large amounts of data.
Similarly, because signing a message in effect encrypts the message, it is not practical to use public-key signature algorithms to sign large messages. Instead, a fixed-length hash is made of the message and the hash value is signed.
BioID has two public/private key pairs. One key pair is used to encrypt session keys and the other to create digital signatures. These are known as the key exchange key pair and the signature key pair, respectively.
BioID uses the public key exchange keys to encrypt session keys. Only the owner of the corresponding private key (or someone who has access to this private key) can decrypt the data. If a private key is used to encrypt a piece of data (BioID does not make use of it), only the corresponding public key will decrypt the data, thus indicating that the owner of the private key (or someone with access to this key) did the encryption. In the same way BioID uses the private signature keys to sign its data. The public key from the key pair can be used to validate the signature.
BioID in its current version 3.1 uses the Microsoft Enhanced Cryptographic Provider by default. The Microsoft Basic Cryptographic Provider is no longer supported.
Note: The BioID cryptography is implemented within a single library and can thus easily be adapted to other cryptographic providers or libraries.
| Operation | Algorithm | Key Length [bit] |
| Key Exchange | RSA public-key exchange algorithm | 1024-2048 |
| Signature | RSA public-key signature algorithm | 2048 |
| Encryption | Triple DES block cipher | 168 |
| Hashing | MD5 | - |
BioID signs all its data objects. This means, live data and Recordings are signed as soon as they are created, live features and Features are signed as soon as they are calculated and Templates are signed as soon as they are generated by a training process. The Record control, a central part of the BioID client, verifies the signatures of the Recordings and Features to ensure that no non-BioID data has been smuggled into the system. Not only the signature but also the timestamp within the signature is checked to ensure that BioID has not been infiltrated with latching objects. At the server side the Data Server, the central data management object, verifies any incoming data object (whereby the timestamp is not checked, because different computers may not be time-synchronal). Not only Recordings, Features and Templates are verified but also any other kind of data objects such as BioIDUser.
BioID always uses the local private signature key to sign objects. Not the objects' data itself is encrypted, but a hash that is generated from the data. The creation of the hash depends on the type of the object that has to be signed. Usually BioID encodes the object and creates a hash of all the encoded data. With objects that support IImagingSet, the data that is used for the hash is generated in a secret way. In any case the MD5 hashing algorithm is used.
After the hash is generated it will be encrypted using the RSA public-key signature algorithm with a 2048 bit public key, and is attached to the signed object together with the local computer name and the public signature key, encrypted with the password derived session key.
To verify the signature of an object, BioID needs the public signature key according to the private key that has been used to sign the object. But first of all the hash that has been encrypted, must be generated. This is done in exactly the same way as it has been done during the signing of the object (see above).
After that the signature is fetched from the object.
Now, if the object has been signed on the local computer we can use the local public signature key to verify the signature. Otherwise, if the object has been signed on a different computer, the public signature key of this computer must be available (a BioID client computer and its public signature key must be stored in the database or a BioID server certificate must be installed on a client computer). The stored key is then used to verify the signature.
To fulfill our privacy needs, BioID encrypts its sensitive data objects. Some objects such as the Features are encrypted as soon as they are created; other data objects are encrypted, when they are sent to the server, e.g. Recordings. Note that the implemented server proxies additionally use secure network protocols, e.g. we are using packet privacy with the DCOM protocol (NTLMSSP). So there is a second encryption layer as soon as data is sent over a network.
Generally a triple DES block cipher algorithm with three 56-bit session keys is used for encryption. The session key is encrypted using the RSA public-key exchange algorithm with a 2048 bit RSA key exchange key and is transported together with the encrypted data.
BioID supports the encryption of objects that support the generic BioID data object interface (IImagingSet).
To encrypt a data object BioID uses a randomly generated session key to encrypt the encoded data. The session key is encrypted with a public key exchange key and added to the newly created encrypted data object (IEncryptedImagingSet) that also contains the encrypted blob. The public key exchange key can be the local exchange key or a given exchange key. If a BioID client sends data to a server it gets the servers public key exchange key from a installed server certificate. When a server sends data to a client he uses the exchange key from the client table in the database.
According to the encryption, BioID supports the decryption of objects that support the encrypted BioID data interface (IEncryptedImagingSet).
To decrypt an encrypted object the encrypted session key that is stored within the object is decrypted using the local private key exchange key. Using this session key the object is now decrypted and reassembled to the original data object.