Cryptography in OpenBSD

"The mantra of any good security engineer is: "Security is not a product, but a process." It's more than designing strong cryptography into a system; it's designing the entire system such that all security measures, including cryptography, work together."

-- Bruce Schneier, author of "Applied Cryptography".

Cryptography

Index
Why do we ship cryptography?.
OpenSSH.
Pseudo Random Number Generators (PRNG): ARC4, ...
Cryptographic Hash Functions: MD5, SHA1, ...
Cryptographic Transforms: DES, Blowfish, ...
Cryptographic Hardware support
International Cryptographers wanted
Further Reading

Why do we ship cryptography?

In three words: because we can.

The OpenBSD project is based in Canada.

The Export Control List of Canada places no significant restriction on the export of cryptographic software, and is even more explicit about the free export of freely-available cryptographic software. Marc Plumb has done some research to test the cryptographic laws.

Hence the OpenBSD project has embedded cryptography into numerous places in the operating system. We require that the cryptographic software we use be freely available and with good licenses. We do not directly use cryptography with nasty patents. We also require that such software is from countries with useful export licenses because we do not wish to break the laws of any country. The cryptographic software components which we use currently were written in Argentina, Australia, Canada, Germany, Greece, Norway, and Sweden.

When we create OpenBSD releases or snapshots we build our release binaries in free countries to assure that the sources and binaries we provide to users are free of tainting. In the past our release binary builds have been done in Canada, Sweden, and Germany.

OpenBSD ships with Kerberos IV included. The codebase we use is the exportable KTH-based release from Sweden. Our X11 source has been extended to make use of Kerberos IV as well.

The next release will ship with the Heimdal implementation of Kerberos V, also from KTH in Sweden.

OpenBSD was the first operating system to ship with an IPsec stack. We've been including IPsec since early OpenBSD 2.1 release in 1997. Our fully conformant in-kernel IPsec stack, with hardware acceleration based on a number of cards, and our own free ISAKMP daemon, is used as one of the machines in the IPsec conformance testbed run by VPNC.

Today cryptography is an important means for enhancing the security of an operating system. The cryptography utilized in OpenBSD can be classified into various aspects, described as follows.

OpenSSH

What is the first thing most people do after installing OpenBSD? They install Secure Shell (ssh) from the ports tree or the packages on the FTP sites. Until now, that is.

As of the 2.6 release, OpenBSD contains OpenSSH, an absolutely free and patent unencumbered version of ssh. As of the OpenBSD 2.6 release date, OpenSSH interoperated with ssh version 1 and had many added features,

all components of a restrictive nature (i.e., patents, see ssl)) had been directly removed from the source code; any licensed or patented components used external libraries.
had been updated to support ssh protocol 1.5.
contained added support for kerberos authentication and ticket passing.
supported one-time password authentication with skey.

Roughly, we took a free license release of ssh and OpenBSD-ifyed it. We get around the USA-based RSA patent by providing an easy way to automatically download and install a RSA-enabled package containing shared library versions of libcrypto and libssl. These packages are based on OpenSSL. People living outside the USA can freely use the RSA patented code, while people inside the USA can freely use it for non-commercial purposes. It appears as if companies inside the USA can use the RSA libraries too, as long as RSA is not used in a profit generating role.

But this way almost everyone will get ssh built into their OS.

NEW! OpenSSH supports protocol 2.0!

Recently, we have extended OpenSSH so that it also does SSH 2 protocol. Having a ssh daemon which can do all 3 major SSH protocols (1.3, 1.5, 2.0) permits us much flexibility. Protocol 2.0 does not use RSA for it's public key cryptography, relying instead on the DH and DSA algorithms. In OpenBSD 2.7 -- which will ship with the new OpenSSH -- you get protocol 2.0 support right out of the box! If you wish to also support protocol 1.3 and 1.5, you simply add the RSA package (as described our ssl manual page), and restart the daemon.

Pseudo Random Number Generators

A Pseudo Random Number Generator (PRNG) provides applications with a stream of numbers which have certain important properties for system security:

It should be impossible for an outsider to predict the output of the random number generator even with knowledge of previous output.
The generated numbers should not have repeating patterns which means the PRNG should have a very long cycle length.

A PRNG is normally just an algorithm where the same initial starting values will yield the same sequence of outputs. On a multiuser operating system there are many sources which allow seeding the PRNG with random data. The OpenBSD kernel uses the mouse interrupt timing, network data interrupt latency, inter-keypress timing and disk IO information to fill an entropy pool. Random numbers are available for kernel routines and are exported via devices to userland programs. So far random numbers are used in the following places:

Dynamic sin_port allocation in bind(2).
PIDs of processes.
IP datagram IDs.
RPC transaction IDs (XID).
NFS RPC transaction IDs (XID).
DNS Query-IDs.
Inode generation numbers, see getfh(2) and fsirand(8).
Timing perturbance in traceroute(8).
Stronger temporary names for mktemp(3) and mkstemp(3)
Randomness added to the TCP ISS value for protection against spoofing attacks.
random padding in IPsec esp_old packets.
To generate salts for the various password algorithms.
For generating fake S/Key challenges.
In photurisd and isakmpd to provide liveness proof of key exchanges.

Cryptographic Hash Functions

A Hash Function compresses its input data to a string of constant size. For a Cryptographic Hash Function it is infeasible to find:

two inputs which have the same output (collision resistant),
a different input for a given input with the same output (2nd preimage resistant).

In OpenBSD MD5, SHA1, and RIPEMD-160 are used as Cryptographic Hash Functions, e.g:

In S/Key to provide one time passwords.
In IPsec, photurisd and isakmpd(8) to authenticate the data origin of packets and to ensure packet integrity.
For FreeBSD-style MD5 passwords (not enabled by default), see passwd.conf(5)
For TCP SYN cookie support (not enabled by default), see options(4)
In libssl for digital signing of messages.

Cryptographic Transforms

Cryptographic Transforms are used to encrypt and decrypt data. These are normally used with an encryption key for data encryption and with a decryption key for data decryption. The security of a Cryptographic Transform should rely only on the keying material.

OpenBSD provides transforms like DES, 3DES, Blowfish and Cast for the kernel and userland programs, which are used in many places like:

In libc for creating Blowfish passwords. See also the USENIX paper on this topic.
In IPsec to provide confidentiality for the network layer.
In Kerberos and a handful of kerberized applications, like telnet, cvs, rsh, rcp, and rlogin.
In photurisd and isakmpd to protect the exchanges where IPsec key material is negotiated.
In AFS to protect the messages passing over the network, providing confidentiality of remote filesystem access.
In libssl to let applications communicate over the de-facto standard cryptographically secure SSL protocol.

Cryptographic Hardware Support

OpenBSD, starting with 2.7, has begun supporting some cryptography hardware such as accelerators and random number generators.

IPsec crypto dequeue
Our IPsec stack has been modified so that cryptographic functions get done out-of-line. Most simple software IPsec stacks need to do cryptography when processing each packet. This results in synchronous performance. To use hardware properly and speedily one needs to separate these two components, as we have done. Actually, doing this gains some performance even for the software case.
Hifn 7751
Cards using the Hifn 7751 can be used as a symmetric cryptographic accelerator (i.e., PowerCrypt). Current performance using a single Hifn 7751 on each end of a tunnel is 64Mbit/sec for 3DES/SHA1 ESP, nearly a 600% improvement over using a P3/550 CPU. Further improvements are under way to resolve a few more issues, but as of April 13, 2000 the code is considered stable. We wrote our own driver for supporting this chip, rather than using the (USA-written) PowerCrypt driver, as well our driver links in properly to the IPsec stack. The 7751 is now considered slow by industry standards and many vendors have faster chips (even Hifn now has a faster but more expensive chip). Peak performance with 3DES SHA1 ESP is around 64Mbit/sec.
(As an aside, Hifn was a difficult company to deal with; they even threatened to sue us over our non-USA reverse engineering of their crypto unlock algorithm).
Hifn 6500
This device is an asymmetric crypto unit. It has support for RSA, DSA, and DH algorithms, as well as other major big number functions. It also contains a very high performance random number generator. We have one device, full documention, and sample code. Development has not yet started.
Broadcom BCM5805 (or beta chip Bluesteelnet 5501)
Just after the OpenBSD 2.7 release, we succeeded at adding preliminary support for these early release parts provided to us by the vendor, specifically starting with the test chip 5501. These devices provide the highest performance symmetric cryptography we have seen.
Bluesteelnet was bought by Broadcom and started making real parts. Their new BCM5805 is similar, except that they also add an asymmetric engine for running DSA, RSA, and other such algorithms. With approximate performance starting at more than four times as fast as the Hifn, hopefully this chip will become more common soon.
The Broadcom/Bluesteelnet people have been great to deal with. They gave us complete documentation and sample code for their chips and a sufficient number of cards to test with.
Post 2.8, this driver was also modified to generate random numbers on the BCM5805 and similar versions, and feed that data into the kernel entropy pool.
Securealink PCC-ISES
The PCC-ISES is a new chipset from the Netherlands. We have received sample hardware and documentation, and work on a driver is in progress. At the moment, the driver is capable of feeding random numbers into the kernel entropy pool.
SafeNet SafeXcel 2141
We have received documentation and sample hardware for the SafeNet crypto cards. Work to support at least the symmetric cryptography of these devices has started.
3com 3c990
3com gave us a driver to support the ethernet component of this chipset, and based on that, we have written our own ethernet driver. This driver has now been integrated once we were able to get a free license on the microcode. We have also received the information needed for supporting the cryptographic functions, which will require a little bit of IPsec subsystem rearranging. Check back later..
Intel IPsec card
Much like Intel does for all their networking division components, and completely unlike most other vendors, Intel steadfastly refuse to provide us with documentation. We have talked to about five technical people who are involved in the development of those products. They all want us to have documentation. They commend us on what we have done. But their hands are tied by management who does not perceive a benefit to themselves for providing documentation. Forget about Intel. (If you want to buy gigabit ethernet hardware, we recommend anything else... for the same reason: most drivers we have for Intel networking hardware were written without documentation).
Intel 82802AB/82802AC Firmware Hub RNG
The 82802 FWH chip (found on i810, i820, i840, i850, and i860 motherboards) contains a random number generator (RNG). High-performance IPsec requires more random number entropy. As of April 10, 2000, we support the RNG. We will add support for other RNGs found on crypto chips.
OpenSSL
We have grand schemes for supporting crypto cards that can do RSA or DSA, and exporting the functions of all crypto cards to OpenSSL so that userland programs (i.e., ssh, apache https, etc) can benefit.

If people wish to help with writing drivers, come and help us.

International Cryptographers Wanted

Of course, our project needs people to work on these systems. If any non-American cryptographer who meets the constraints listed earlier is interested in helping out with embedded cryptography in OpenBSD, please contact us.