Kryptografia

Dlaczego włączamy kryptografię do systemu?

W dwóch słowach: poneważ możemy.

Projekt OpenBSD wywodzi się z Kanady.

Kanadyjska Lista Kontroli Eksportu nie nakłada żadnych znaczących ograniczeń dotyczących eksportu oprogramowania kryptograficznego, a wręcz jest otwarta na wolny eksport ogólnodostępnego oprogramowania kryptograficznego. Marc Plumb wykonał badania dotyczące tego tematu. Dzięki temu Projekt OpenBSD osadził kryptografię w wielu miejscach w systemie operacyjnym.

Od oprogramowania kryptograficznego, którego używamy, wymagamy swobody dostępu i odpowiedniej licencji. Nie korzystamy bezpośrednio z kryptografi opatrzonej nieakceptowalnymi patentami. Wymagamy także, aby oprogramowanie, pochodzące z innych krajów, także posiadało właściwe licencje eksportowe, ponieważ nie chcemy łamać prawa żadnego kraju. Komponenty kryptograficznego oprogramowani, którego obecnie używamy, zostały napisane w Argentynie, Australii, Kanadzie, Niemczech, Grecji, Norwegii oraz Szwecji.

Podczas tworzenia wydań (ang. releases), czy snapshot'ów OpenBSD, tworzymy binaria w wolnych krajach, aby upewnić się, iż źródła i binaria, które dostarczamy użytkownikom są wolne od skaz. W przeszłości, budowa binarnych wydań miała miejsce w Kanadzie, Szwecji i Niemczech.

OpenBSD dostarczane jest wraz z załączonym Kerberos IV i Kerberos V. Obie wersje oparte są na ogólnodostępnym wydaniu kodu źródłowego KTH ze Szecji. Nasze źródła X11 także zostały rozszeżone, aby współdziałać z Kerberos.

OpenBSD było pierwszym systemem operacyjnym, który wprowadził stos IPsec do swojego podstawowego wydania. Włączamy do systemu IPsec od wydania OpenBSD 2.1 w 1997. Nasz w pełni zgodny ze standardami, zaimplementowany w jądrze stos IPsec, wraz z sprzętową akceleracją bazującą na licznych urządzeniach oraz nasz własny, wolny demon ISAKMP, jest wykorzystywany przez VPNC jako jedna z maszyn do prowadzenia testów zgodności.

Obecnie kryptografia odgrywa istotną rolę w zwiększaniu bezpieczeństwa systemu operacyjnego. Wykorzystywana w OpenBSD kryptografia może być sklasyfikowana ze względu na różne aspekty, opisane poniżej.

OpenSSH

What is the first thing most people do after installing OpenBSD? They install Secure Shell (ssh(1)) 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(8)) 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(1) authentication and ticket passing.
• supported one-time password authentication with skey(1).

Roughly said, we took a free license release of ssh, OpenBSD-ifyed it. About a year later, we extended OpenSSH to also do SSH 2 protocol, the result being support for all 3 major SSH protocols: 1.3, 1.5, 2.0.

Pseudolosowe generatory liczb

Pseudolosowy generator liczb (ang. Pseudo Random Number Generator - PRNG) zapewniają aplikacjom strumień liczb, które mają bardzo duże znaczenie dla bezpieczeństwa systemu:

• Nie powinno być możliwości przewidzenia z zewnątrz wyniku generatora liczb losowych, nawet w przypadku posiadania wiedzy o wcześniej wygenerowanych liczbach.
• Generowane liczby nie powinny mieć powtarzających się schematów, co oznacza, że PRNG powinien mieć bardzo dużą długość cyklu.

PRNG jest zwykle jedynie algorytmem, dla którego identyczne ciągi wprowadzanych danych dają te same wyniki. W systemie operacyjnym o wielu użytkownikach istnieje mnustwo źródeł, które dostarczają losowe dane do PRNG. Jądro OpenBSD wykorzystuje odstępy czasu pomiędzy przerwaniami myszki (ang. mouse interrupt), opóźnienie przerwań przesyłania danych sieciowych (ang. network data interrupt latency), odstępy czasu pomiędzy wciskaniem klawiszy oraz informacje o wejściu/wyjściu dysków twardych do zapełnienia nieprzewidywalnego bufora. Liczby losowe są dostępne dla jądra oraz poprzez psełdo-urządzenia dla programów użytkownika (ang. userland programs). Jak dotąd, liczby losowe są wykorzystywane w następujących elementach systemu:

• Dynamiczne alokowanie sin_port w bind(2).
• Numery PID procesów.
• Numery ID diagramów IP.
• Numery ID tranzakcji RPC (XID).
• Numery ID tranzakcji NFS RPC (XID).
• Numery ID zapytań DNS.
• Numery generacji węzłów Inode, patrz getfh(2) i 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 isakmpd(8) 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(1) to provide one time passwords.
• In IPsec(4) 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)
• 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(4) to provide confidentiality for the network layer.
• In Kerberos and a handful of kerberized applications, like telnet(1), cvs(1), rsh(1), rcp(1), and rlogin(1).
• In isakmpd(8) 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., the Soekris VPN1201 or VPN1211 (to buy) or 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.

  After 2.9 shipped, support was added for the Hifn 7951 chip, a simplified version of the 7751 which adds a public key accelerator (unsupported) and a random number generator (supported). Cards were donated by Soekris Engineering.

  After 3.0 shipped, support was added for the Hifn 7811 chip, a faster version of the 7751 (around 130Mbit/s) with a random number generator. A card was donated by GTGI.

  After 3.2 shipped, support was added for the LZS compression algorithm used by ipcomp(4).

  Hifn was initially a difficult company to deal with (threatening to sue us over our non-USA reverse engineering of their crypto unlock algorithm), but more recently they have been very helpful in providing boards and support.

• 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 documentation, and sample code. As of OpenBSD 3.1, both the random number generator and big number unit are working.

• Hifn 7814/7851/7854
  This device is a packet processor and asymmetric crypto unit. It has support for RSA, DSA, and DH algorithms, as well as other major big number functions and also has a random number generator. Currently, only the big number engine and the random number generator are supported (no packet transforms).

• Broadcom BCM5801/BCM5802/BCM5805/BCM5820/BCM5821/BCM5822/5823 (or beta chip Bluesteelnet 5501/5601)
  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.

  Post 2.9, support was added for the BCM5820, which is mostly just a faster (64bit, higher clock speed) version of the BCM5805. Untested support for the BCM5821 was also added post 3.0.

  As of 3.1, the big num engine is supported, and RSA/DH/DSA operations can be accelerated.

  Support for the BCM5801, BCM5802, BCM5821 and BCM5822 was added before OpenBSD 3.2 (the untested BCM5821 support in 3.1 was broken because of some undocumented interrupt handling requirements).

  Partial support for BCM5823 was added for 3.4. The chip supports AES, but the driver does not.

• 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 3cr990
  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. Due to poor documentation and lack of cooperation (partly because of the high turnover rates at 3Com), the IPsec functions of the chip are not supported.... so this turned out to be a less than completely useful exercise.

• Intel IPsec card
  Much like Intel does for all their networking division components, and completely unlike most other vendors, Intel steadfastly refuses 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.

• VIA C3 RNG
  The newer VIA C3 cpu contains a random number generator as an instruction. As of 3.3 this random number generator is used inside the kernel to feed the entropy pool.

• OpenSSL
  Years ago, we had a grand scheme to support crypto cards that can do RSA/DH/DSA automatically via OpenSSL calls. As of OpenBSD 3.2, that support works, and any card that is supported with such functionality will automatically use the hardware, including OpenSSH and httpd in SSL mode. No application changes are required.

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.

Further Reading

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.

• A Future-Adaptable Password Scheme.
  Usenix 1999, by Niels Provos, David Mazieres.
  paper and slides.

• Cryptography in OpenBSD: An Overview.
  Usenix 1999, by Theo de Raadt, Niklas Hallqvist, Artur Grabowski, Angelos D. Keromytis, Niels Provos.
  paper and slides.

• Implementing Internet Key Exchange (IKE).
  Usenix 2000, by Niklas Hallqvist and Angelos D. Keromytis.
  paper and slides.

• Encrypting Virtual Memory.
  Usenix Security 2000, Niels Provos.
  paper and slides.

• The Design of the OpenBSD Cryptographic Framework.
  Usenix 2003, by Angelos D. Keromytis, Jason L. Wright, and Theo de Raadt.
  paper.