[BACK]Return to crypto.html CVS log [TXT][DIR] Up to [local] / www

File: [local] / www / crypto.html (download) (as text)

Revision 1.63, Sat Aug 19 17:04:09 2000 UTC (23 years, 9 months ago) by deraadt
Branch: MAIN
Changes since 1.62: +6 -1 lines

usenix security over

<!DOCTYPE HTML PUBLIC  "-//IETF//DTD HTML Strict Level 2//EN//2.0">
<html>
<head>
<title>Cryptography in OpenBSD</title>
<link rev=made href=mailto:www@openbsd.org>
<meta name="resource-type" content="document">
<meta name="description" content="OpenBSD cryptography">
<meta name="keywords" content="openbsd,cryptography,openssh,openssl,kerberos">
<meta name="keywords" content="ipsec,photuris,isakmp,ike,blowfish,des,rsa,dsa">
<meta name="distribution" content="global">
<meta name="copyright" content="This document copyright 1997 by OpenBSD.">
</head>

<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#23238E">
<img align=left alt="[OpenBSD]" height=166 width=197 SRC="images/blowfish-notext.jpg">
<br>
<br>
<br>
"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."<br>
<br>
-- Bruce Schneier, author of "Applied Cryptography".
<br clear=all>
<h2><font color=#e00000>Cryptography</font><hr></h2>

<strong>Index</strong><br>
<a href=#why>Why do we ship cryptography?</a>.<br> 
<a href=#ssh>OpenSSH</a>.<br> 
<a href=#prng>Pseudo Random Number Generators</a> (PRNG): ARC4, ...<br>
<a href=#hash>Cryptographic Hash Functions</a>: MD5, SHA1, ...<br>
<a href=#trans>Cryptographic Transforms</a>: DES, Blowfish, ...<br>
<a href=#hardware>Cryptographic Hardware support</a><br>
<a href=#people>International Cryptographers wanted</a><br>
<a href=#papers>Further Reading</a><br>
<p>
<hr>

<a name=why></a>
<h3><font color=#e00000>Why do we ship cryptography?</font></h3><p>

In three words:  <strong>because we can</strong>.<p>

The OpenBSD project is based in Canada.<p>

The <a href=ECL.html>Export Control List of Canada</a>
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
<a href=http://insight.mcmaster.ca/org/efc/pages/doc/crypto-export.html>
some research to test the cryptographic laws</a>.
<p>

Hence the OpenBSD project has embedded cryptography into numerous places
in the operating system.  We require that the cryptographic software we
use be <a href=policy.html>freely available and with good licenses</a>.
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.
<p>

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.<p>

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.  Kerberos V support will
appear sometime in 2000, but at present time a freely exportable
Kerberos V release does not exist.<p>

Today cryptography is an important means for enhancing the <a
href=security.html>security</a> of an operating system.  The
cryptography utilized in OpenBSD can be classified into various
aspects, described as follows.<p>

<a name=ssh></a>
<h3><font color=#e00000>OpenSSH</font></h3><p>

What is the first thing most people do after installing OpenBSD?
They install Secure Shell
(<a href=http://www.openbsd.org/cgi-bin/man.cgi?query=ssh>ssh</a>)
from the ports tree or the packages on the FTP sites. Until now, that is.<p>

As of the 2.6 release, OpenBSD contains
<a href="http://www.openssh.com/">OpenSSH</a>, an absolutely free and
patent unencumbered version of ssh.  
As of the OpenBSD 2.6 release date,
<a href="http://www.openssh.com/">OpenSSH</a> interoperated with ssh
version 1 and had many added features,	
<ul>
<li>
all components of a restrictive nature (ie. patents, see
<a href=http://www.openbsd.org/cgi-bin/man.cgi?query=ssl>ssl</a>))
had been directly removed from the source code; any licensed or
patented components used external libraries.
</li>
<li>
had been updated to support ssh protocol 1.5.
</li>
<li>
contained added support for
<a href=http://www.openbsd.org/cgi-bin/man.cgi?query=kerberos>kerberos</a>
authentication and ticket passing.
</li>
<li>
supported one-time password authentication with
<a href=http://www.openbsd.org/cgi-bin/man.cgi?query=skey>skey</a>.
</li>
</ul>
<p>

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.<p>

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

<strong>NEW!  OpenSSH supports protocol 2.0!</strong><p>

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
<a href=http://www.openbsd.org/cgi-bin/man.cgi?query=ssl>ssl</a>
manual page), and restart the daemon.

<a name=prng></a>
<h3><font color=#e00000>Pseudo Random Number Generators</font></h3><p>

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

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

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:<p>

<ul>
<li>Dynamic sin_port allocation in bind(2).
<li>PIDs of processes.
<li>IP datagram IDs.
<li>RPC transaction IDs (XID).
<li>NFS RPC transaction IDs (XID).
<li>DNS Query-IDs.
<li>Inode generation numbers, see getfh(2) and fsirand(8).
<li>Timing perturbance in traceroute(8).
<li>Stronger temporary names for mktemp(3) and mkstemp(3)
<li>Randomness added to the TCP ISS value for protection against
	spoofing attacks.
<li>random padding in IPSEC esp_old packets.
<li>To generate salts for the various password algorithms.
<li>For generating fake S/Key challenges.
<li>In <a href=http://www.physnet.uni-hamburg.de/provos/photuris/>photurisd</a> 
        and <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=isakmpd>isakmpd</a>
	to provide liveness proof of key exchanges.
</ul>

<p>
<a name=hash></a>
<h3><font color=#e00000>Cryptographic Hash Functions</font></h3><p>

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

<ul>
<li>two inputs which have the same output (collision resistant),
<li>a different input for a given input with the same output
	(2nd preimage resistant).
</ul>
<p>

In OpenBSD MD5, SHA1, and RIPEMD-160 are used as Cryptographic Hash Functions,
e.g:<p>
<ul> 
<li>In <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=skey>S/Key</a>
    to provide one time passwords.
<li>In <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=ipsec>IPsec</a>,
    <a href=http://www.physnet.uni-hamburg.de/provos/photuris/>photurisd</a>
    and
    <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=isakmpd>isakmpd(8)</a>
    to authenticate the data origin of packets and to ensure packet integrity.
<li>For FreeBSD-style MD5 passwords (not enabled by default), see
    <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=passwd.conf&sektion=5>
    passwd.conf(5)</a>
<li>For TCP SYN cookie support (not enabled by default), see
    <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=options&sektion=4>
    options(4)</a>
<li>In libssl for digital signing of messages.
</ul>
<p>

<p>
<a name=trans></a>
<h3><font color=#e00000>Cryptographic Transforms</font></h3><p>

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.<p>

OpenBSD provides transforms like DES, 3DES, Blowfish and Cast for the
kernel and userland programs, which are used in many places like:<p>
<ul>
<li>In libc for creating
    <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=blf_key>Blowfish</a>
    passwords.  See also the <a href=papers/bcrypt-paper.ps>USENIX paper</a>
    on this topic.
<li>In
    <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=ipsec>IPsec</a>
    to provide confidentiality for the network layer.
<li>In Kerberos and a handful of kerberized applications, like
    <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=telnet>telnet</a>,
    <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=cvs>cvs</a>,
    <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=rsh>rsh</a>,
    <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=rcp>rcp</a>,
    and
    <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=rlogin>rlogin</a>.
<li>In <a href=http://www.physnet.uni-hamburg.de/provos/photuris/>
    photurisd</a> and
    <a href=http://www.openbsd.org/cgi-bin/man.cgi?query=isakmpd>isakmpd</a>
    to protect the exchanges where IPsec key material is negotiated.
<li>In AFS to protect the messages passing over the network, providing
    confidentiality of remote filesystem access.
<li>In libssl to let applications communicate over the de-facto standard
	cryptographically secure SSL protocol.
</ul>

<p>
<a name=hardware></a>
<h3><font color=#e00000>Cryptographic Hardware Support</font></h3><p>

OpenBSD, starting with 2.7, has begun supporting some cryptography hardware
such as accelerators and random number generators.
<ul>
<li><b>IPSEC crypto dequeue</b><br>
    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 syncronous
    performance.  To use hardware properly and speedily one needs to seperate
    these two components, as we have done.  Actually, doing this gains some
    performance even for the software case.
<p>
<li><b>HiFn 7751</b><br>
    Cards using the <a href="http://www.hifn.com/products/7751.html">HiFn 7751</a>
    can be used as a cryptographic accelerator (ie.
    <a href="http://www.powercrypt.com">PowerCrypt</a>).
    Current performance using a single Hifn 7751 on each end of a tunnel
    is 63Mbit/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)
    <a href="http://www.powercrypt.com">powercrypt</a> 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 63MBit/sec.
    <p>
    (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).
    <p>
<li><b>Broadcom BCM5805 (or beta chip Bluesteelnet 5501)</b><br>
    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
    <a href="http://www.bluesteelnet.com/product.html">5501</a>.
    Bluesteelnet was bought by Broadcom and started making real parts.
    The new BCM5805 is similar, except that they also add an asymetric engine
    for running DSA, RSA, and other such algorithms.  With approximate
    performance starting at more than twice as fast as the HiFn, hopefully
    this chip will become more common soon.  Our driver still has bugs, so
    we do not yet have performance figures.
    <p>
    The Broadcom/Bluesteelnet people have been great to deal with.  They gave
    us complete documentation for their chips and a sufficient number of cards
    to test with.
    <p>

<li><b>Pijnenburg PCC-ISES</b><br>
    The <a href="http://www.pcc.pijnenburg.nl/pcc-ises.htm">PCC-ISES</a> is a
    new chipset from the Netherlands.  We have received sample hardware and
    documentation, and work to support this should start fairly soon.
    <p>
	
<li><b>IRE 2141</b><br>
    We have received documentation and sample hardware for the
    <a href="http://www.ire.com/OEM/OEMTechnologyDefault.htm">IRE</a> crypto
    cards based on the SafeNet chipset.  We would like to get started on
    supporting these soon.
    <p>

<li><b>Other cards</b><br>
    We are moving towards supporting other chips such as:
    <ul>

    <li><a href="http://www.3com.com/promotions/3c990promo/index.html">3com 3c990</a>
    <li>and others
    </ul>
    <p>
    Intel (and 3com to a lesser degree) don't yet fully understand how
    they could benefit from giving us documentation for their cryptography
    cards, so feel free to contact them independently and encourage them.
    We have given up talking to them, since it appears to be a waste of time.
    <p>
    <b>If people wish to help with writing drivers,
    <a href=#people>come and help us</a>.</b>
<p>
<li><b>Intel 82802AB/82802AC Firmware Hub RNG</b><br>
    The 82802 FWH chip (found on i810, i820, and i840 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 RNG's found on crypto chips.
<p>
<li><b>OpenSSL</b><br>
    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 (ie. <a href="http://www.openssh.com">ssh</a>,
    <a href="http://www.modssl.org/">apache https</a>, etc)
    can benefit.
</ul>

<p>
<a name=people></a>
<h3><font color=#e00000>International Cryptographers Wanted</font></h3><p>

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.<p>

<p>
<a name=papers></a>
<h3><font color=#e00000>Further Reading</font></h3><p>

A number of papers have been written by OpenBSD team members, about
cryptographic changes they have done in OpenBSD.  The postscript
versions of these documents are available as follows.<p>

<ul>
<li>A Future-Adaptable Password Scheme.<br>
    <a href=events.html#usenix99>Usenix 1999</a>,
    by <a href=mailto:provos@openbsd.org>Niels Provos<a/>,
    <a href=mailto:dm@openbsd.org>David Mazieres</a>.<br>
    <a href=papers/bcrypt-paper.ps>paper</a> and
    <a href=papers/bcrypt-slides.ps>slides</a>.
<p>
<li>Cryptography in OpenBSD: An Overview.<br>
    <a href=events.html#usenix99>Usenix 1999</a>,
    by <a href=mailto:deraadt@openbsd.org>Theo de Raadt</a>,
    <a href=mailto:niklas@openbsd.org>Niklas Hallqvist</a>,
    <a href=mailto:art@openbsd.org>Artur Grabowski</a>,
    <a href=mailto:angelos@openbsd.org>Angelos D. Keromytis</a>,
    <a href=mailto:provos@openbsd.org>Niels Provos</a>.<br>
    <a href=papers/crypt-paper.ps>paper</a> and
    <a href=papers/crypt-slides.ps>slides</a>.
<p>
<li>Implementing Internet Key Exchange (IKE).<br>
    <a href=events.html#usenix2000>Usenix 2000</a>,
    by <a href=mailto:niklas@openbsd.org>Niklas Hallqvist</a> and
    <a href=mailto:angelos@openbsd.org>Angelos D. Keromytis</a>.<br>
    <a href=papers/ikepaper.ps>paper</a> and
    <a href=papers/ikeslides.ps>slides</a>.
<p>
<li>Encrypting Virtual Memory</a><br>
    <a href=events.html#sec2000>Usenix Security 2000</a>,
    <a href=mailto:provos@openbsd.org>Niels Provos</a>.<br>
    <a href=papers/swapencrpaper.ps>paper</a>.
</ul>

<p>
<hr>
<a href=/index.html><img height=24 width=24 src=back.gif border=0 alt=OpenBSD></a>
<a href=mailto:www@openbsd.org>www@openbsd.org</a>
<br>
<small>$OpenBSD: crypto.html,v 1.63 2000/08/19 17:04:09 deraadt Exp $</small>

</body>
</html>