Network Authentication API
We developed an API to support network based authentication. The API can be used as the basic building blocks in arbitrary applications to ensure that legitimate clients are interacting with the server. In this section, we provide details about the API and discuss the limitations and tradeoffs. The API provides the following functions (see bio_lib.h as appendix A for more details):
WriteToFile
This function allows the application developer to write a finger print to file. The file is a binary file that contains the data structure used by BioAPI Consortium standard. It can be broken down into two sections: (1) meta information about the finger print such as length of the data section, and (2) binary data corresponding to the finger print itself. This function is necessary for the server to generate new users.
ReadFromFile
This function allows the application developer to read a finger print from file (written by WriteToFile). The application developer is responsible for identifying the target file and instantiating a file handle. This provides the application developer the most flexibility in naming and storing of the finger print. ReadFromFile allocates memory for the data section (which can be arbitrarily large). To ensure the memory is reclaimed, the application developer must use our function, Reclaim (more details follow). This function will typically be used on the server to authenticate clients.
WriteToSocket
This function allows the application developer to send finger print data over a socket. The application developer is responsible for opening their own socket (and securing it as necessary). A finger print stored in a data structure conforming to the BioAPI Consortium standard will be marshaled and the socket will be used to send the data. Meta information is transmitted in the first send. A second send is used to transmit the actual finger print data. This function will typically be used by clients to send finger print data to the server for authentication.
ReadFromSocket
This function allows the application developer to receive finger print data over a socket. Again, the application developer is responsible for opening their own socket. The receive function call will block and wait for a corresponding WriteToSocket using the same socket. The meta data is transmitted first. This is used to fill in the data structure conforming to the BioAPI Consortium standard. It is also used to coordinate the size of the data to be received and allows for the allocation of the necessary memory. Since ReadFromSocket allocates memory for the data section (which can be arbitrarily large) the application developer must use our function, Reclaim to get the memory back. This function will typically be used on the server to authenticate clients. This function will typically be used by the server to read finger print data from the clients for authentication.
Init
This function must be called before performing any biometric function calls. It serves two purposes: (1) a call to the BioAPI Consortium init function, and (2) allocates and initializes a state tracker. The state tracker’s purpose is to keep track of buffers allocated using the ReadFromFile and ReadFromSocket function calls.
Reclaim
This function must be performed after all biometric function calls. It de-allocates all memory used in ReadFromFile and ReadFromSocket. It uses the data structure “state tracker” to perform this task.
This simple API provides the basic building blocks necessary to replace the old user name and password pair with a user name and finger print pair in client / server applications. There are a few things the application programmer should do to ensure security (these were not covered by our API to provide the most flexibility):
- The application programmer is responsible for opening their own sockets. It is recommended that the socket be a secured channel (via encryption). Thus it is the responsibility of the application developer to ensure their application is not susceptible to any of the attacks mentioned in the Methodology and Background section.
- The application programmer is responsible for opening their own file handles for reading and writing. The files for writing must be opened in write and binary modes. The files for reading must be opened in read and binary mode.