OpenBSD Cryptographic Framework

  To improve the performance of the cryptographic operations in IPsec, we developed a framework for cryptographic services in OpenBSD that abstracts the details of specific cryptographic hardware accelerator cards behind a kernel-internal API. The details of the framework are beyond the scope of this paper. However, we give a brief description here so the reader has the proper context within which to consider our measurements.

Besides abstracting the API for accessing these cards, the framework was designed with these goals in mind:

• Asynchronous operation: The kernel should not have to wait until the hardware finished the requested operation.
• Load balancing: If multiple cryptographic accelerators are present, they should be utilized such that throughput is maximized.
• No dependence on hardware: If no hardware accelerators are present, the system should offer the same services (albeit at lower performance).
• Application independence: Although the framework was initially developed for use with IPsec, it should be possible to use it to accelerate other kernel operations (e.g., filesystem or swap encryption) and user-level applications (e.g., the OpenSSL library).
• Support for public key operations. This is currently work in progress.

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.

  

Figure 1: Cryptographic card performance.