Cryptography in Op enBSD: An Overview
Theo de Raadt, Niklas Hallqvist, Artur Grab owski, Angelos D. Keromytis, Niels Provos
fderaadt,niklas,art,angelos,provosg@op enbsd.org
The OpenBSD Project
Abstract trying to make their use as easy and, where p ossi-
ble, transparent to the end user. Thus, more work
Cryptographic mechanisms are an imp ortant se-
is done in those mechanisms that can be used to
curity comp onent of an op erating system in secur-
provide transparent security, e.g., IPsec.
ing the system itself and its communication paths.
With this pap er, weintend to give a good overview
Indeed, in many situations, cryptography is the
of the cryptography currently distributed and used
only to ol that can solve a particular problem, e.g.,
in Op enBSD, and of our plans for future work. We
network-level security. While cryptography by it-
hop e this will b e of interest b oth to end-users and ad-
self do es not guarantee security, when applied cor-
ministrators lo oking for b etter ways to protect their
rectly, it can signi cantly improve overall security.
host and networks, and to develop ers in other sys-
Since one of the main fo ci of the Op enBSD system is
tems free or otherwise that are considering sup-
security,various cryptographic mechanisms are em-
p orting some of these mechanisms. We should again
ployed in a numb er of di erent roles.
caution the readers, however, that cryptography
This pap er gives an overview of the cryptography
do es not solve all security problems in an op erat-
employed in Op enBSD. We discuss the various com-
ing system, and should not b e considered as an end
p onents IPsec, SSL libraries, stronger password en-
in itself, but rather as an imp ortant piece of the se-
cryption, Kerb eros IV, random numb er generators,
curity puzzle.
etc. , their role in system security, and their inter-
actions with the rest of the system and, where ap-
1.1 Pap er Organization
plicable, the network .
The remainder of this pap er is organized as
follows: section 2 describ es the various network
1 Intro duction
security facilities implemented and supp orted in
Op enBSD, section 3 covers the extensive use of ran-
An imp ortant asp ect of security in a mo dern op-
dom number generators, and section 4 brie y out-
erating system is cryptographic services and mecha-
lines our future plans in this area. Section 5 con-
nisms. While not a security panacea, cryptography
cludes the pap er.
is sometimes the right to ol in solving certain prob-
lems. In particular, cryptography is extremely useful
in solving a numb er of security issues in the following
2 Communications Security
three areas:
In an increasingly networked environment, com-
Network security.
munications security supp ort in an OS is extremely
Secure storage facilities.
imp ortant. As there are di erent mechanisms
and di erent layers where one may apply security,
Pseudo- Random numb er generators.
Op enBSD supp orts a number of security proto cols
and mechanisms, some of whichwere develop ed or
Since one of our goals in the Op enBSD pro ject
even designed by our develop ers. In some cases,
is to provide strong security,wehave implemented a
there is considerable overlap in functionality. One
numb er of proto cols and services in the base system.
of our goals is to eventually make it transparentto
An Op enBSD distribution thus has full supp ort for
the end user which such security mechanism is in
such mechanisms as IPsec, SSL, Kerb eros, etc, b eing
use.
una ected by exp ort restriction laws.
Simply supp orting these mechanisms, however, is The following sections give a brief overview of
not sucient for wide-spread use. We are constantly these mechanisms, some detail of their implemen-
tation and integration in Op enBSD, and our plans The proto cols are ESP Encapsulating SecurityPay-
for future work. As we already mentioned in sec- load [2, 15] and AH Authentication Header [1,14].
tion 1, we consider IPsec an extremely imp ortant Both provide integrity, authenticity, and replay pro-
to ol in network security, b oth b ecause of its p oten- tection, while ESP adds con dentiality to the pic-
tial for user-transparency and its exibility. This is ture. IPsec can also be made to protect IP data-
re ected by the more thorough coverage of IPsec in grams for other hosts. The IPsec endp oints in this
the text that follows. arrangement thereby b ecome security gateways and
Other p opular mechanisms, such as SSH [38], are take part in a virtual private network VPN where
not covered b ecause they are only part of our p orts ordinary IP packets are tunneled inside IPsec [36].
system. While virtually all the develop ers use SSH,
Network-layer securityhasanumberofvery im-
there is no free implementation we can add to our
p ortant advantages over security at other layers of
standard distribution. Furthermore, the currentver-
the proto col stack. Network-layer proto cols are gen-
sion of SSH is restricted by the RSA patentin the
erally hidden from applications, which can there-
US. We are waiting for a free implementation to b e-
fore automatically and transparently take advantage
come available as part of the IETF standardization
of whatever network-layer encryption services that
pro cess of SSH. Such an implementation would be
host provides. Most imp ortantly, network-layer pro-
linked with our libssl.
to cols o er a remarkable exibility not available at
higher or lower layers. They can provide security
2.1 SSL
on an end-to-end securing the data between two
hosts , route-to-route securing data passing over a
In Op enBSD libssl provides a to olkit for the
particular set of links , edge-to-edge securing data
Secure So cket Layer SSL v2/v3 and Transp ort
as it passes from a \secure" network to an \insecure"
Layer Security TLS v1 [6] which provide strong
one , or a combination of these.
cryptographic protection for network communica-
tion such as server authentication and data encryp-
2.2.2 Op eration
tion. The Secure So cket Layer is currently used by
web servers, e.g., Apache as shipp ed with Op enBSD,
Central to b oth ESP and AH are an abstraction
and browsers like Netscap e Communicator. In the
called security asso ciation, or SA. In each SA there
future, applications like telnet and ftp will be con-
is information algorithm IDs, keys, etc. stored
verted to use TLS, p ossibly even during our network
describing how the wanted protection should be
installation pro cess.
setup. For two p eers to be able to communicate
Due to patent restrictions, libssl in the
they need matching SAs at each end. When de-
Op enBSD distribution supp orts only digital signa-
ciding what SA should be used for outb ound traf-
tures with DSA [27], but an additional package is
c, some kind of security p olicy database needs to
provided for users outside the USA to add back
b e consulted. In Op enBSD, this is currently imple-
RSA-signature [19] supp ort. This is implemented
mented as an extension to the routing table, where
by providing two shared libraries: libssl.so.1.0
source/destination addresses, proto col, and p orts
has only function stubs for RSA supp ort, while
serve as selectors.
libssl.so.1.1 contains full RSA supp ort. Notice
Lo oking at the wire format, IPsec works by insert-
that shared library minor-version number changes
ing an extra header b etween the IP header and the
typically indicate interface-transparent bug xes.
payload. This header holds IPsec-sp eci c data, such
as an anti-replay sequence numb er, cryptographic
2.2 IP Security IPsec
synchronization data, and integritycheckvalues. If
the security proto col in use is ESP, a cryptographic
2.2.1 Background
transform is applied to the payload in-place, e ec-
tively hiding the data. As an example, an UDP data-
While IP has proven to be an ecient and robust
gram protected by ESP is shown in gure 1.
proto col when it comes to actually getting data
across the Internet, it do es not inherently provide This mo de of op eration is called transp ort mo de,
any protection of that data. There are no facili- as opp osed to tunnel mo de which is typically used
ties to provide con dentiality, or to ensure the in- when a security gateway is protecting datagrams for
tegrity or authenticityofIP[31] datagrams. In or- other hosts. Tunnel mo de di ers from transp ort
der to remedy the securityweaknesses of IP, a pair mo de by the addition of a new, outer, IP header con-
of proto cols collectively called IP Security, or IPsec sisting of the security gateways' addresses instead of
[3, 16] for short, has b een standardized by the IETF. the actual source and destination, as shown in gure
that has help ed us signi cantly in nding and xing
ating further development.
IP ESP UDP UDP bugs, and in motiv
tly, the API used to setup and maintain the
Header Header Header Data Recen
KEY SA database was switched to the standard PF
[23]. This API is much more exible than the
old PF ENCAP interface. Available algorithms for
Encrypted
encryption are DES [26], 3DES, Cast-128, Blow-
sh [35], and Skip jack supp ort for the latter, de-
Figure 1: IPsec Transp ort Mo de
spite its known weaknesses, was added after re-
quests byUSGovernment agencies using our IPsec
k . One-way hash algorithms are MD5, SHA1
IP ESPIP UDP UDP stac
,21,17]. For key management,
Header Header Header Header Data and RIPEMD160 [20
two daemons are available, isakmpd implementing
IKE [29, 22, 12] and photurisd implementing Pho-
turis [13].
Encrypted
2.2.4 Future Work in IPsec
Figure 2: IPsec Tunnel Mo de
Our IPsec implementation is under constant devel-
opment and improvement, as there remain a number
2.
of unresolved issues.
As was mentioned earlier, this mo de is ideal for
implementing VPNs.
Our IPv6 stack is not yet integrated with our
The last, but not least, part of the picture is a key
IPsec implementation.
management infrastructure. IPsec can only work if
Wewant a more exible, p ossibly uni ed p olicy
the keys in the SAs are synchronized and up dated
mechanism. In particular, we are lo oking into
in a secure fashion. To automate this task, di erent
merging routing, security p olicy, and proto col
proto cols have b een devised that allowtwo p eers to
blo ck lo okups.
compute identical keys without actually sending all
the data needed for it over the wire [7, 8]. The Inter-
Develop or b orrow a p olicy API, rather
net Key Exchange, IKE, is one such, and Photuris is
than use private extensions to PF KEY and
another. The main di erence b etween these two lies
PF ROUTE.
in the complexity level. IKE is a very complex proto-
col which, however, o ers considerable exibilityin
isakmpd has not yet covered all mandatory re-
negotiating and establishing SAs. IKE is the ocial
quirements in the RFCs.
IETF standard. Both proto cols work in a similar
A DNSSEC [9] implementation, and integration
vein, by rst building an encrypted application-level
in isakmpd and photurisd, will b e needed for op-
\tunnel" where further key exchanges take place.
p ortunistic encryption.
The Die-Hellman algorithm [7] is used to makeit
computationally hard to crack the key computation.
isakmpd and photurisd are not linked with lib-
Every SA is assigned a lifetime, either in wall-clo ck
ssl so they will not automatically supp ort RSA
time or in volume, and when such a lifetime expires,
when an RSA-supp orting libssl is installed.
the key management daemon renegotiates with the
p eer, creating new SAs with fresh keys.
We do not currently do on-demand keying
a facility available in the past through the
2.2.3 Op enBSD IPsec
ENCAP API . PF
Op enBSD's IPsec stackwas written by John Ioan-
Finally,weintend to supp ort some application
nidis and Angelos Keromytis [18] and later enhance-
API for requesting security and p ossibly other
ments and xes have b een provided by Niels Provos
services. With that in place, weintend to have
and Niklas Hallqvist. The core is stable and in pro-
all networking applications take advantage of
duction use securing data in many places all over
IPsec.
the world, as it do es not su er from US exp ort reg-
ulations. A number of companies, agencies, insti- All of these are improvements that we want to
tutions, and individuals are using the co de, a fact address in the time-frame for the next release.
2.3 Kerb eros integrate the Kerb eros 5 clone b eing develop ed at
KTH as so on as it is stable, esp ecially since Ker-
b eros IV only supp orts DES [26] encryption.
In a networked environment, it is very imp ortant
to b e able to authenticate users in a secure wayover
2.4 S/Key
insecure networks. Kerb eros is a network authenti-
cation proto col using a trusted third-party to pro-
vide authentication and basic session-key exchange.
S/Key [11, 10] is a one-time password system used
Kerb eros is built around a central key distribu- for authentication. It provides protection against
tion center KDC whichkeeps a database of clients
replay attacks where a third party captured a pass-
and servers called principals and their private keys. word, e.g., by means of network sning, and tries
Encryption in Kerb eros is based on DES [26]. When to reuse it in a new authentication session.
the client wants to use some service it issues a re-
S/Key uses a user supplied secret pass-phrase
quest to the KDC for a ticket for that service. The
which is pro cessed by a one-way function to gener-
server returns a message encrypted with the client's
ate a sequence of one-time passwords. In Op enBSD
private key, containing three parts: a session key
the one-way function can b e chosen from a variety
that can b e used for encryption b etween the client
of computationally non-invertible hash functions like
and the server, a timestamp, and a ticket. The ticket
MD5 [34] or SHA1 [28], available in libc. S/Key is
is encrypted with the private key of the server and
still useful when other cryptographic proto cols are
contains the name of the client, a timestamp, the
not available, or their implementations are not fully
clients network address, lifetime of the ticket, and
trusted, e.g., when using a conference terminal ro om
the same session key that the client obtained. The
to login to a home machine.
ticket can b e passed to the server for authentication.
Kerb eros [24] was originally develop ed by pro ject
Athena at MIT, but was not exp ortable from the US
3 Pseudo Random Number Genera-
due to legal restrictions. The cryptographic func-
tors
tionality was removed and a \Bones" distribution
was created and exp orted. The cryptographic in-
A Pseudo Random Number Generator PRNG
terfaces were added backby Eric Young, and KTH
provides applications with a stream of numb ers
The Royal Institute of Technology in Sto ckholm,
whichhave certain imp ortant prop erties for system
Sweden maintained the co de outside the USA. The
security:
Kerb eros implementation in Op enBSD is \kth-krb",
proto col version 4, and is used in a numb er of utili-
It should b e imp ossible for an outsider to pre-
ties.
dict the output of the random numb er generator
even with knowledge of previous output.
2.3.1 Practical Uses
The generated numb ers should not have rep eat-
The simplest use of Kerb eros is to authenticate users
ing patterns which means the PRNG should
lo cally on a workstation. The login, xdm, and su pro-
havea very long cycle length.
grams in Op enBSD have the necessary co de to allow
Kerb eros authentication. The next step is to provide
A PRNG is normally just an algorithm where
authentication for network proto cols. The rlogin,
the same initial starting values will yield the
rsh, and telnet programs have b een mo di ed to use
same sequence of outputs.
Kerb eros. In addition to that, they can use the ses-
sion key, obtained in the authentication phase, to
Some applications have criteria which a ect the
encrypt the data-stream for privacy. Another very
typ e of PRNG which is needed. For instance, later
practical use is in \kx" - a proto col to authenticate
on we will discuss IP datagram IDs and DNS [30]
and forward X11 connections in a secure way. Other
query-IDs, b oth of these issues have qualities which
programs using Kerb eros for authentication include
make it extremely desirable to have a PRNG which
cvs, sudo, and xlock. Kerb eros authentication is also
makes e orts to avoid emitting rep etitions thus rul-
used in AFS.
ing out use of a true-random source .
One of our future goals is to allowkerb erized ap- Many other op erating systems also have random
plications to use IPsec services when p ossible, thus number device drivers and other related mecha-
avoiding double-encryption and consequently de- nisms, but largely make no use of them. Some such
graded p erformance . Furthermore, we intend to systems even provide such supp ort only as optional
device drivers, therefore discouraging use i.e., re- For 16-bit non-rep eating numb ers, we used a
14 15
liance . Op enBSD deviates by actually using these prime 2 mechanisms in numerous ways. A few ma jor inter- erator for Z . Being a generator, g has the prop erty p y faces or techniques are used: that anyvalue 0 mo d p , for some value y . 14 /dev/?random and similar kernel interfaces We then pick random a, b and m with 2 15 2 so that arc4random 3 in lib c f n a f n 1 + b mo d m non-rep eating PRNG b ecomes a linear congruential generator LCG . Each of these, and their uses in Op enBSD, will b e We then determine the actual ID as covered in the following sections. f n ID n =w g mo d p ; 3.1 Kernel Randomness Pool where w is a random seed. After the linear con- Computers are generally deterministic devices gruential generator has b een exhausted, the most making it very hard to pro duce real random num- signi cant bit in ID n is toggled and all parame- b ers. The PRNGs we use in Op enBSD do not gen- ters g , a, b, m, and w from ab ove are chosen anew. erate random numb ers themselves. Rather, they ex- Because the linear congruential generator do es not pand the randomness they are given as input. For- rep eat itself and a new numb er space is chosen af- tunately, a multi-user op erating system has many ter reinitialization, the generated IDs do not rep eat external events from which it can derive some ran- themselves. The PRNG is typically seeded with ma- domness. In Op enBSD the kernel collects measure- terial from the kernel randomness p o ol. ments from various devices such as the inter-keypress timing from terminals, the arrival time of network 3.3.1 Randomness Used Inside the Kernel packets, and the nishing time of disk requests. The randomness from these sources is mixed into the ker- Dynamic sin p ort allo cation in bind 2 . nel's entropy pool. When a userland program re- When an AF INET so cket is b ound to a sp eci c quests random data from the kernel, an MD5 hash p ort numb er using the bind 2 system call, the is calculated over the whole entropy p o ol, \folded" pro cess can cho ose the sp eci c p ort, or elect in half byXOR-ing the upp er and lower word of the that the system cho ose. Normal UNIX b ehavior MD5 output, and returned. The user can cho ose the resulted in the system allo cating p ort numb ers quality of the generated random numb ers by reading starting at 1024 and incrementing. Our new output from the di erent /dev/?random devices. co de cho oses a random p ort, in the range 1024 to 49151. 3.2 arc4random 3 A similar issue existed with reserved p ort cre- ation, using the bindresvport 3 and rresv- The arc4random 3 interface, available in the port 3 library routines, which are supp osed to Op enBSD libc, makes use of the kernel random- pick a free p ort in the reserved range typically ness p o ol, describ ed in the previous section, for between 600 and 1023 . The old b ehavior was seeding the keystream generator employed by the to allo cate decreasing p ort numb ers starting at ARC4 cipher a cipher equivalent to RSADSI's 1023. The old co de for these library routines RC4 . The interface provides supp ort for applica- e ected this downward search using successive tions to \add" randomness to the pool maintained calls to bind 2 ;wehave replaced this with co de by arc4random 3 . This interface is intended as a using a newer kernel interface which is much drop-in replacement for the traditional Unix ran- more ecient and cho oses a random p ort num- dom 3 interface, for those applications that need b er within the reserved range. higher-quality random numb ers. There are a numb er of p o orly designed proto cols 3.3 Non-rep eating Random Numb ers e.g., rsh, ftp which are a ected by predictable p ort allo cation; we b elieve that our approachis In Op enBSD, we designed a non-rep eating making it harder for attackers to gain an edge. pseudo-random numb er generator that was very fast and did not require additional resources. Pro cess PIDs. struct timeval now; char buf[20]; gettimeofday &now ; sprintf buf, "/tmp/foo-d", getpid ; call_msg.rm_xid = getpid ^ now.tv_sec ^ void mkdir buf, 0600 ; now.tv_usec; Figure 3: The Wrong Way To Generate A Figure 4: Typical RPC Initialization Co de \Random" Directory NFS-exp orted lesystems by making it dicult Programmers often use this value as if it is ran- for an attacker to guess lehandles which are dom, p ossibly b ecause of the comp ellingly at- partially derived from ino de numb ers . tractive argument that \pid numb ers are e ec- tively random on a busy enough system." Co de IP datagram IDs. like \srandom getpid " is quite common, as is co de similar to that shown in gure 3. Each IP packet contains a 16-bit identi er which is used, if the packet has b een frag- In a normal system the attacker will havea very mented, for correctly p erforming reassembly at easy time predicting the PID and thus the obvi- the nal destination. Previously, this identi- ous race attack is trivial. The race is as follows: er simply incremented every time a new packet the attacker creates the directory rst, cho os- was sent out. By lo oking at the identi er in a ing the mo de and ownership; subsequently it is sequence of packets, an outsider can determine p ossible to lo ok at and replace les in the direc- how busy the target machine is. Another is- tory. sue was avoiding disclosure of information when In Op enBSD, we use randomized PIDs, with a using IPsec in tunneling mo de, as per section couple of obvious exceptions, e.g., init 8 . 2.2.2. A naive implementation might create a new IP header with an ID one more than the RPC transaction IDs XID . ID in the existing IP header. This could lead to Sun Microsystems Remote Pro cedure Call known-plaintext attacks [4] against IPsec. RPC messages contain a Transaction Identi- To avoid these problems, we use the non- er XID which matches a sent query against rep eating PRNG describ ed in section 3.3. its received reply. In most RPC systems, the XID of the rst message a pro cess transmits will Randomness added to the TCP ISS value for b e initialized using the co de shown in gure 4. protection against sp o o ng attacks. Subsequently, the XID for each packet is sim- Inside the kernel, a 32-bit variable called tcp iss ply incremented from this. Previously we men- declares the Initial Send Sequence Number tioned that a lo cal user might b e able to guess ISS to use on the next TCP [32] session. what kind of range the next PID on the sys- The predictability of TCP ISS values has b een tem might fall into; here we see that an outside known to b e a security problem for manyyears attacker might also be able to determine this [25]. Typical systems added either 32K, 64K, information. Our new co de uses arc4random or 128K to that value at various di erent times. to initialize the XID, and also avoids using two Instead, our new algorithm adds a xed amount identical numb ers consecutively. plus a random amount, signi cantly decreasing the chances of an attacker guessing the value NFS RPC transaction IDs XID . and thus b eing able to spoof connection con- The NFS proto col uses RPC packets for com- tents. munication. The RPC XID issue also applied to the NFS co de we encountered, and we now Random data-blo ck padding for cryptographic use the same mechanism for NFS XIDs. transforms, as in RFC1827 IPsec ESP [2]. Ino de generation numb ers. 3.3.2 Randomness Used in Userland Li- The fsirand 8 program makes use of braries arc4random 3 to generate random inode numb ers for lesystem ob jects les, direc- DNS query IDs typically start at 1 and incre- tories, etc. . This increases the security of ment for each subsequent query. An attacker can cause a DNS lo okup, e.g., by telneting to isakmpd and photurisd use the kernel random- the target host, and spoof the reply, since the ness p o ol for generating IKE \exchange identi- contentof the query and the ID are known or ers" i.e., proto col co okies and message IDs , easily predictable. Since host authentication is random Die-Hellman [7] values, and random still in wide-spread use, this is a serious secu- nonces. rity vulnerability present in virtually all sys- Certain games make use of the arc4random 3 tems. Toavoid this issue, wehave mo di ed our interface for higher quality random numb ers. in-tree copyofbind 8 and our libc resolver to make use of the non-rep eating PRNG. arc4random 3 seeding, as mentioned in section 4 Secure Storage 3.2. One of the areas of least development in Op enBSD Stronger temp orary names. has b een that of secure storage. While a number of Pro cesses typically create temp orary les by utilities e.g., vi 1 , ed 1 , bdes 1 , etc. directly generating a random lename via mktemp 3 supp ort encryption services, our goal is to provide and then op ening that le in the /tmp di- this service as transparently as p ossible to users. rectory. A more secure way for doing so is Ideally, we would like a layer either over or under through mkstemp 3 , which generates the le- the current native lesystem that would provide safe name and op ens the le in one atomic op era- storage services. tion, thus eliminating the p otential for races. As an interim solution, CFS [5] is included in the Both functions, which reside in libc, make use Op enBSD p orts system and can be readily used. of arc4random 3 to generate the random le- However, it do es not provide the level of trans- names, making it much harder for an attacker parency we would like, and its p erformance is well to guess the names in advance. b elow what we consider acceptable for general use. Clearly, more work is needed in this area. Generate salts for the various password algo- Another issue related to secure storage is that rithms. For some more details, see section 4.1. of secure logging. Logs and esp ecially security- related logs are extremely imp ortant in determin- 3.3.3 Randomness Used in Userland Pro- ing whether a system is under attack or has b een grams compromised. The current logging facility, syslog, For generating fake S/Key challenges. do es not provide any facilities for detecting log- tamp ering, other than the option to send log mes- One problem with most versions of RFC1938- sages to another host's syslogd. We are currently based one time password OTP systems is that p orting the ssyslog package [37] and are hoping to it is often p ossible to use them to determine seamlessly replace the currently-used syslogd. whether or not a user has an account on a ma- The remainder of this section brie y covers our chine. The most trivial example of this is sys- bcrypt, approach to protecting user passwords, de- tems that provide a di erent prompt if the user velop ed inside Op enBSD. has an entry in the OTP database. However, even for systems that always provide an OTP 4.1 Bcrypt prompt, the prompt itself is rarely convincing and can b e trivially identi ed as a fake. To ad- dress this problem, the OTP co de in Op enBSD Increasing computational p ower makes the use of generates a consistent, credible challenge for cryptography to further system security more fea- non-existent users and users without an entry sible and allows for more tuneable security param- in the OTP database. It do es so by generating eters such as public key length. However, one se- the prompt based on the hostname and a hash curity parameter - the length and entropy of user- of the username and the contents of a le gen- chosen passwords - do es not scale at all with comput- erated from the kernel random p o ol. This le ing power. Many systems still require user-chosen is usually created at install time and provides a secret passwords which are hashed to keep them constant source of random data. Thus, all three secret. When the UNIX password hash crypt 3 comp onents of the challenge are constant, but was intro duced in 1976, it could not hash more only the hostname and username are known to than four passwords p er second. With increasingly the attacker. more powerful attackers it is common to compute more than 200,000 password hashes p er second. In their systems. Op enBSD we use the bcrypt algorithm to make the cost of password hashing parameterizable. Its de- sign makes it hard to optimize bcrypt's execution 6 Acknowledgments sp eed or use commo dity hardware instead of soft- ware. bcrypt uses a 128-bit salt and encrypts a 192- We would like to thank Hugh Graham, Todd bit magic value. It takes advantage of the fact that Miller, and Chris Turan who provided comments the Blow sh algorithm used in the core of bcrypt and sometimes text in earlier versions of this pa- for password hashing needs a fairly exp ensive key p er. Wewould also like to thank all the Op enBSD setup, thus considerably slowing down dictionary- develop ers for the work they contribute to the based attacks. bcrypt uses the arc4random 3 in- pro ject, and our users for their continuing supp ort. terface for password salt-generation. A comparison between this approach and the mechanism used in certain other Unix systems for generating salts has 7 Availability shown that while arc4random 3 b ehaved extremely close to the statistical theoretical exp ectations; in All the software describ ed in the pap er is available contrast, other systems pro duced large numb ers of through the Op enBSD web page at collisions, making dictionary attacks faster. A sp ecial con guration le, passwd.conf 5 , is http://www.openbsd.org/ used to determine which typ e of password scheme is used for a given user or group. It is p ossible to use di erent password schemes for lo cal or YP pass- 8 Disclaimer words. For bcrypt, the numb er of rounds is also in- cluded. This facilitates adapting the password veri - Op enBSD is based in Calgary, Canada. All indi- cation time to increasing pro cessor sp eed. Currently, viduals doing cryptography-related work do so out- 6 the default numb er of rounds for a normal user is 2 , side countries that have limiting laws. 8 and 2 for \ro ot." bcrypt is used in Op enBSD as the default password scheme since version 2.1. For more details, see [33]. References [1] R. Atkinson. IP Authentication Header. RFC 1826, 5 Conclusion August 1995. [2] R. Atkinson. IP Encapsulating Security Payload. In this pap er, we gave an overview of the cryp- RFC 1827, August 1995. tography used in Op enBSD. We presented the sup- [3] R. Atkinson. Security Architecture for the Internet p orted network security mechanisms, with particu- Proto col. RFC 1825, August 1995. lar emphasis on IP security. We then discussed the [4] S. Bellovin. Probable Plaintext Cryptanalysis of the various uses of randomness throughout the system. IP Security Proto cols. In Proceedings of the Sympo- Finally,we brie y covered our plans for future work sium on Network and Distributed System Security, in the area of secure storage. pages 155{160, February 1997. A lot of work remains to be done. In the short [5] M. Blaze. A Cryptographic File System for Unix. term, we need to complete the remaining parts of In Proc. of the 1st ACM Conference on Computer those mechanisms still under development, keeping and Communications Security,Novemb er 1993. in mind of course that security and standards is amoving target, and constant maintenance and up- [6] T. Dierks and C. Allen. The TLS proto col ver- sion 1.0. Request for Comments Prop osed Stan- dating will b e needed. Beyond that, integration with dard 2246, Internet Engineering Task Force, Jan- existing and new utilities is a ma jor item in our uary 1999. agenda. Finally,we are considering new mechanisms that address di erent problems, e.g., untrusted-co de [7] W. Die and M.E. Hellman. New Directions in containment. Cryptography. IEEE Transactions on Information Theory, IT{22 6 :644{654, Nov 1976. It is imp ortant to note that all the mechanisms describ ed in this pap er are currently in use, solving [8] W. Die, P.C. van Oorschot, and M.J. Wiener. real problems. We hop e that this pap er will encour- Authentication and Authenticated Key Exchanges. Designs, Codes and Cryptography, 2:107{125, 1992. age others to add these or similar mechanisms in [9] D. Eastlake, 3rd, and C. Kaufman. Domain name [24] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. system security extensions. Request for Comments Saltzer. Kerb eros authentication and authorization Prop osed Standard 2065, Internet Engineering system. Technical rep ort, MIT, Decemb er 1987. Task Force, January 1997. [25] R. T. Morris. A Weakness in the 4.2BSD Unix [10] N. Haller. The S/KEY one-time password system. TCP/IP Software. Computing Science Technical Request for Comments Informational 1760, Inter- Rep ort 117, AT&T Bell Lab oratories, February net Engineering Task Force, February 1995. 1985. [11] Neil M. Haller. the s/key one-time password system. [26] Data Encryption Standard, January 1977. In Proceedings of the ISOC Symposium on Network [27] Digital Signature Standard, May 1994. and Distributed System Security, 1994. [28] Secure Hash Standard, April 1995. Also known as: [12] D. Harkins and D. Carrel. The internet key ex- 59 Fed Reg 35317 1994 . change IKE . Request for Comments Prop osed Standard 2409, Internet Engineering Task Force, [29] D. Pip er. The internet IP security domain of in- Novemb er 1998. terpretation for ISAKMP. Request for Comments Prop osed Standard 2407, Internet Engineering [13] P. Karn and W. Simpson. Photuris: Session-key Task Force, Novemb er 1998. management proto col. Request for Comments Ex- p erimental 2522, Internet Engineering Task Force, [30] J. Postel. Domain name system structure and del- March 1999. egation. Request for Comments Informational [14] S. Kent and R. Atkinson. IP authentication header. 1591, Internet Engineering Task Force, March 1994. Request for Comments Prop osed Standard 2402, [31] Jon Postel. Internet Proto col. Internet RFC 791, Internet Engineering Task Force, Novemb er 1998. 1981. [15] S. Kent and R. Atkinson. IP encapsulating security [32] Jon Postel. Transmission Control Proto col. Internet payload ESP . Request for Comments Prop osed RFC 793, 1981. Standard 2406, Internet Engineering Task Force, [33] Niels Provos and David Mazi eres. A Future- Novemb er 1998. Adaptable Password Scheme. In Proceedings of the [16] S. Kent and R. Atkinson. Security architecture for Annual USENIX Technical Conference, 1999. the internet proto col. Request for Comments Pro- p osed Standard 2401, Internet Engineering Task [34] R. Rivest. The MD5 Message-Digest Algorithm. Force, Novemb er 1998. Internet RFC 1321, April 1992. [17] A. Keromytis and N. Provos. The use of HMAC- [35] Bruce Schneier. Description of a New Variable- RIPEMD-160-96 within ESP and AH. Internet Length Key, 64-Bit Blo ck Cipher Blow sh . In Fast Draft, Internet Engineering Task Force, February Software Encryption, Cambridge Security Work- 1999. Work in progress. shop Proceedings, pages 191{204. Springer-Verlag, Decemb er 1993. [18] A. D. Keromytis, J. Ioannidis, and J. M. Smith. Implementing IPsec. In Proceedings of Global Inter- [36] William Simpson. IP in IP Tunneling. Internet RFC net GlobeCom '97, pages 1948 { 1952, November 1853, Octob er 1995. 1997. [37] Secure Syslog. http://www.core-sdi.com/Core- SDI [19] RSA Lab oratories. PKCS 1: RSA Encryption /english/slogging/ssyslog.htm l. Standard,version 1.5 edition, 1993. Novemb er. [38] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and [20] C. Madson and R. Glenn. The use of HMAC- S. Lehtinen. SSH proto col architecture. Internet MD5-96 within ESP and AH. Request for Com- Draft, Internet Engineering Task Force, February ments Prop osed Standard 2403, Internet Engi- 1999. Work in progress. neering Task Force, Novemb er 1998. [21] C. Madson and R. Glenn. The use of HMAC- SHA-1-96 within ESP and AH. Request for Com- ments Prop osed Standard 2404, Internet Engi- neering Task Force, Novemb er 1998. [22] D. Maughan, M. Schertler, M. Schneider, and J. Turner. Internet security asso ciation and key management proto col ISAKMP . Request for Comments Prop osed Standard 2408, Internet En- gineering Task Force, Novemb er 1998. [23] D. McDonald, C. Metz, and B. Phan. PF KEY Key Management API, Version 2. Request for Com- ments Informational 2367, Internet Engineering Task Force, July 1998.