Besides abstracting the API for accessing these cards, the framework was designed with these goals in mind:
Work on the framework is still in progress, but the main skeleton is present and has been in use with IPsec since OpenBSD 2.8.
The framework presents two interfaces: one to device drivers, which register with the framework and specify what algorithms and modes of operations they support; and one to applications (e.g., IPsec), which create ``sessions'' and then queue requests for these.
Sessions are used to create context in specific drivers (selected by the framework based on a best-match basis, with respect to the algorithms used) and can migrate between different cryptographic accelerators (e.g., if a card fails or is plugged out of the system, as may be the case with PCMCIA adaptors, or if a higher-priority session arrives). This is achieved by requiring that all necessary context is provided with every request, regardless of the fact that a session has been created (the context is kept at the application and inside the accelerator cards and is not cached by the framework itself).
Applications queue requests on sessions, and the cryptographic framework, running as a kernel thread and periodically processing all requests, routes them to the appropriate driver. Once the request has been processed, a callback function provided by the application is invoked, which continues processing (in the IPsec case, passes the packet to ip_output() for transmission). A software pseudo-driver registers with the framework as a driver of last resort (if any other driver can process the session, it will be preferred).
User-level applications (e.g., the OpenSSL library or the SSH daemon) can access the hardware through the /dev/crypto device, which acts as another kernel application to the framework, using the same API. Public key operations are modeled in the same way.