SECURITY-INTRO(2) SECURITY-INTRO(2)
NAME
intro - introduction to security
SYNOPSIS
include "keyring.m";
include "security.m";
DESCRIPTION
This is an introduction to some of the principals behind
computer security as well as a description of how these
principals are used in Inferno. More detailed descriptions
of the methods and principals for ensuring secure
communications on computers can be found in texts such as
Applied Cryptography by Bruce Schneier (published 1996, J.
Wiley & Sons, Inc.).
Inferno provides several levels of security:
+o Mutual authentication means that two users or applica-
tions that want to communicate can establish that they
are who they say they are. It is the basic level of
security provided by Inferno. Thus, for example, when a
user connects to an Inferno service, they can and must
establish that they are a legitimate user.
+o Message digesting is a technique to ensure that an
interloper cannot modify messages sent between users.
+o Encryption protects the confidentiality of messages so
that only the party or parties for whom the messages
are intended can decrypt and read them. Inferno makes
it easy to enforce any one or all of these levels of
security.
Mutual Authentication
Authentication requires a combination of elements: a third
party that each user can trust, an algorithm or mathematical
method to secure messages between users, and a protocol for
exchanging messages that ensures that a third party or
intruder cannot pretend to be one of the users, or use some
other method to undermine their communication.
One important method for authenticating users in Inferno is
the use of digital signatures. Like signing a letter a digi-
tal signature testifies to the identity of the sender. For-
tunately, it is much more difficult to forge a digital sig-
nature.
Even after users are authenticated to each other, it is pos-
sible for someone `listening' to their communication to read
Page 1 Plan 9 (printed 12/21/24)
SECURITY-INTRO(2) SECURITY-INTRO(2)
and possibly modify their messages without the users knowing
it. So authentication solves one security requirement, but
not all of them.
Message Digesting
Message digesting uses a mathematical hashing algorithm to
convert a message into an indecipherable string of fixed
length (a digest). By appending the hashed value to the
message, the authenticity of the message can be verified.
The recipient takes the message, applies the same hashing
algorithm used by the sender, and compares the value to the
one sent. If the values are the same, then the message
received must be the same as the one that was sent.
Inferno includes a counter in the digest to check that mes-
sages were received in the correct order and that no mes-
sages were inserted by a third party listening in on the
line. A secret key is also included in the digest to verify
the identity of the sender.
A message digest ensures that no one has tampered with a
message. It does not prevent someone from reading it.
Message Encryption
The traditional notion of encryption is translating a mes-
sage, called a plaintext in cryptography, into something
unreadable, called a ciphertext. Its most obvious use is to
provide confidentiality. Only someone able to decrypt the
message, or translate it back to its original form, can
interpret it.
A mathematical algorithm is used to both encrypt and decrypt
a message. Encryption algorithms depend on keys or bit
strings of a specified length for encryption and decryption.
The nature of an algorithm and the size of the key determine
the degree of security.
Two basic types of algorithms are used in cryptography: pri-
vate key (or symmetric key) and public key algorithms. With
symmetric algorithms the same key is used to encrypt and
decrypt a message. This key must be a secret, known only to
the users who want to communicate. It is often called a pri-
vate or secret key.
A public key algorithm may use a private or secret key to
encrypt a message and a public key to decrypt it, or vice-
versa. The private or secret key is known only to one user.
The public key, however, does not have to be kept secret and
may be distributed to anyone the user wishes to communicate
with.
Inferno uses a public key algorithm for digital signatures
Page 2 Plan 9 (printed 12/21/24)
SECURITY-INTRO(2) SECURITY-INTRO(2)
and symmetric key algorithms for encryption.
A user can encrypt a message with or without appending a
message digest.
Algorithms Supplied With Inferno
Some of the considerations when choosing algorithms are
speed, degree of security, and political restrictions on
export. The algorithms used in Inferno are well known and
rigorously tested.
One-way hashing algorithms
SHA and MD5 are well known (in cryptographic circles)
one-way hashing algorithms. MD5 is a high-speed, 128-
bit hash. SHA is a somewhat slower but more secure
160-bit hash.
ElGamal public key signature algorithm
ElGamal is a public key system widely used for creating
digital signatures. It uses a private key for signing a
message and a public key for verifying it. Because
Inferno initially used ElGamal keys, it does not assume
that either a private or public key can be used for
encryption or decryption. With constant advances in the
field of cryptography, one of the design goals of
Inferno is to create a security component that will be
easy to enhance as new algorithms are developed.
Encryption algorithms
DES (the Data Encryption Standard) was adopted by the
US government in 1976 as a standard
encryption/decryption system for unclassified data in
the United States. It is widely used, especially by the
financial services industry. Two types of DES are
offered: DES-ECB and DES-CBC. ECB or Electronic Code
Book and CBC or Chain Block Coding are part of the ANSI
Banking Standard. CBC is more complex and less vulnera-
ble than ECB. Both versions of DES provide 56-bit keys.
RC4 is a symmetric or private key system that is about
10 times faster than DES.
Diffie-Hellman key exchange algorithm
Diffie-Hellman is an algorithm for creating a secret
key to be shared by users for encrypting messages
(sometimes called a shared secret). It requires each
user to exchange certain information with the other.
This information can be exchanged in the open, that is,
without encryption. Each user is able to create the
same, secret key from this information. However, no one
else listening to their exchange would be able to cre-
ate or determine the secret key.
Page 3 Plan 9 (printed 12/21/24)
SECURITY-INTRO(2) SECURITY-INTRO(2)
Security Protocols
Cryptanalysis is the study of how to break cryptographic
systems. Attempts to disrupt or listen to confidential com-
munications are called attacks. Usually the objective of an
attack is to figure out the secret key, decrypt a message,
or add or modify messages in some way.
There are many methods or strategies for attacking a confi-
dential communication. One method is called a man-in-the-
middle attack, where someone listening to a communication
pretends to be one of the parties; another is a replay
attack, where an interloper reuses messages that have
already been exchanged in an attempt to discover a pattern.
In order to thwart such attacks and establish some level of
trust between communicating parties, it is necessary to
employ certain protocols. Inferno uses two well-established
protocols to permit keys to be exchanged and to permit
mutual authentication of the identities of two communicating
parties.
A digital signature is one way to guarantee that a message
sent by a user is indeed from that user and not someone
else. A signature does not require that a message be
encrypted. It can be appended to a message in order to guar-
antee the identity of the sender. With ElGamal, creating a
signature requires that the user have a secret or private
key. Uniquely associated with the private key is another key
that can be distributed publicly. This public key is used
along with the private key to create a signature, and is
used by others to verify the signature.
To create a signature the ElGamal algorithm is applied to a
combination of the private key, the public key, and the mes-
sage to be signed. The output of the algorithm is the signa-
ture.
To verify the signature the receiver applies the ElGamal
algorithm to the public key and the signature. If the output
is the same message that was sent with the signature, then
the signature is valid. This method ensures that the user
receiving a message is indeed communicating with someone who
owns the public key.
The next step is to determine who the owner of the public
key is, and to ensure that it belongs to the user that the
receiver wants to communicate with. This is accomplished by
having a third party create a certificate testifying to the
identity of the owner of the public key. This third party is
called a certifying authority (CA). If a user trusts the
certifying authority, a copy of a certificate is sufficient
to determine the ownership of a public key, and therefore,
Page 4 Plan 9 (printed 12/21/24)
SECURITY-INTRO(2) SECURITY-INTRO(2)
the signature and identity of the user sending a message.
A certificate includes a variety of information: a user's
public key, the identity of the user, Diffie-Hellman parame-
ters, an expiration time for the certificate, and the signa-
ture of the CA. The CA's public key is sent to the user
along with the certificate to verify the CA's signature.
Inferno provides two different methods for obtaining a cer-
tificate depending on whether a user has access to a key-
board or not. For users with a keyboard, Inferno offers a
variation of the Encrypted-Key-Exchange (EKE) protocol,
described in login(6). The protocol depends on establishing
trust between a user and a CA using a shared secret (pass-
word). The secret must initially be established at the CA
by some secure means: typing a password on a secure console
at the CA, or transmitting the password securely off-line,
perhaps by unintercepted letter or untapped phone call. To
obtain a certificate, a user can subsequently enter the
secret on the client machine's keyboard; the protocol
obtains a certificate without revealing the secret.
For an application or user on a set-top box, which normally
does not have a keyboard, entering a password would be dif-
ficult. Therefore, Inferno provides a different method to
establish trust. When the set-top box is turned on, it cre-
ates a private/public key pair and dials the service
provider's CA to get a certificate. The CA returns a cer-
tificate blinded or scrambled with a random bit string known
only to the CA. A hashed version of the string is displayed
on the user's screen. The user telephones the CA and com-
pares what is displayed with what the CA has sent. If they
match, and the user can prove his or her identity, the CA
makes the random bit string known to the user, so the cer-
tificate can be unscrambled.
Authentication
Mutual authentication in Inferno requires that two parties
who want to communicate must have a certificate from the
same CA. As described above, the public key of the CA is
used to check the certificate sent by the other user. The
certificate is used to verify that the public key belongs to
the party that the user wants to communicate with.
If a user can trust the public key, then the key can be used
to check the signature sent by the other party. If the pub-
lic key unlocks the signature, then whoever sent the signa-
ture must have the corresponding secret key, and therefore,
must be the owner of the public key.
The default protocol provided by Inferno for mutual authen-
tication is the station-to-station protocol described in
Page 5 Plan 9 (printed 12/21/24)
SECURITY-INTRO(2) SECURITY-INTRO(2)
auth(6). It has the property that both parties can derive
the same key from exchanged and validated data but no eaves-
dropper can determine the key.
Security at the Application Layer
An application can make use of the algorithms and protocols
described previously by using only a few library routines
such as: security-login(2), security-auth(2) and connect
(see security-ssl(2)). The Login module enables an applica-
tion that shares a password with a server acting as the CA
to obtain a certificate. After obtaining certificates, two
applications establish a mutually authenticated connection
by calling auth. Auth performs the entire STS protocol.
Connect connects an application to an SSL (security sockets
layer) device. Each application can create message digests
or encrypt messages by writing to this device. Messages are
received and decrypted by reading from the SSL device.
Although Inferno provides these routines to make it easy to
establish secure communications, an application is not
restricted to their use. Lower-level routines used by login
and auth are also available to an application. These rou-
tines enable an application to create alternate methods for
establishing security, or to perform specialized functions
like signing files.
Inferno also provides security routines tailored for set-top
boxes. For example, a set-top-box can use register(8)
instead of login (see security-login(2)). Register obtains a
certificate without requiring a user to enter a password.
There are also commands in section 8 that establish a server
as a Certifying Authority or `signer'. For example, a CA
needs a key and password to create a certificate. These can
be created on the server using the commands changelogin(8)
and createsignerkey(8).
Page 6 Plan 9 (printed 12/21/24)