OpenSSL Enhancements

  In the past, programmers using OpenSSL (or its predecessor, SSLeay) directly called the generic crypto routines as they existed for each algorithm. More recently, programmers have been encouraged to use the EVP layer for dealing with symmetric algorithms. This provides a session-based model much like the /dev/crypto layer described in the previous section. Applications like OpenSSH, mod_ssl (the Apache SSL module we use), and sendmail have matured to use these interfaces.

Newer OpenSSL code-bases contain an ``engine'' component. This allows asymmetric algorithms to be directed to a hardware driver; a number of stub functions are provided which typically interface with vendor-specific shared libraries to actually do the operation on the vendor's accelerator. Many of these subsystems interact badly and do not consider the effects of chroot() or other strange Unix behaviors, resulting in weak security models. Since we run Apache in a chroot()'ed environment in which there exists no /dev/crypto device, we modified it to perform all necessary initializations prior to being sandboxed. We wrote our own engine modules that interacts directly with /dev/crypto, without any of these surprises. Symmetric operations from the EVP layer are directly mapped into OCF requests. One major weakness is that the EVP layer has no concept of bundling algorithms. Thus, protocols that use encryption and MAC on a message, such as TLS and SSH version 2, sequentially issue two separate requests to /dev/crypto through the EVP layer, resulting in unnecessary context switches, data copying, and DMA transactions. Thus, the EVP layer currently does not pass MAC operations to the OCF.