Inferno Security ---------------------------------------------------------------------------- Harvey Bernard (hbb@lucent.com) Lucent Technologies Bell Labs Innovations 600 Mountain Ave. Murray Hill, NJ 07974 ---------------------------------------------------------------------------- Summary Inferno is a network operating system that provides a software infrastructure for distributed, network applications. Inferno allows any application, written in the Limbo programming language, to run across multiple platforms and networks under the Dis virtual machine. Inferno provides an elegant file-like interface to resources and services that allows the dynamic construction of a user name space. An Inferno application can access the resources and services in its name space even though they may be distributed throughout the network. The Styx component of Inferno provides transparent comunications over a variety of networks with strong security capabilities built in. The Inferno team has not devised a new encryption algorithm or protocol. Existing cryptographic techniques are more than adequate. What the Inferno team has done is designed algorithms and protocols into an operating system in such a way as to provide a high degree of security, make them easily accessible to application programs, make them work across networks, and make them easy to replace or modify as requirements change. ---------------------------------------------------------------------------- Why We Need Security There is an increasing desire to protect information. Today with networking, companies and individuals need to protect proprietary information and communications, business-critical transactions, and electronic commerce. They need to secure personal and company business via e-mail, prevent viruses from infecting their systems, and identify who is accessing network services. Furthermore, they need to perform these functions across heterogeneous networks. When information and communications are compromised, the losses are significant and the impact potentially disastrous. Levels of Security Inferno enforces security in a number of important ways. Functions such as the security routines described in this paper as well as device drivers are built into the system so that they cannot be "spoofed" or replaced by other routines. Namespaces, one of the key features of Inferno, can be used to restrict access to network resources, making visible only the resources an application needs. In a hosted environment, Inferno can use the security features of the host operating system, including file permissions, to control access. In addition to these features, Inferno incorporates the latest cryptographic techniques into built-in security routines and an API. This paper describes these routines and how they are used to implement security. For licensing and export reasons, some of the algorithms mentioned in this paper are not included in the Web release. These algorithms, including DES-ECB and DES-CBC, can be ordered separately. The security routines of Inferno make it easy to provide any one or all of the following types of security: * Mutual authentication * Message digesting * Digital signatures * Encryption Mutual authentication means that two users or applications that want to communicate can establish that they are who they say they are. This is the most basic level of security provided by Inferno. It means, for example, that when someone signs on to a service provider that he or she can be established as a legitimate user. This user could be someone accessing a service from a desktop computer, a set-top box, or a hand-held device. Message digesting is a technique to ensure that an interloper cannot modify messages sent between users. This is especially important in financial transactions. Inferno combines digesting with digital signatures to provide undeniable transactions, which prevent someone, for example, from claiming that it was really someone else who requested a withdrawal from their bank account. Like signing a letter, a digital signature testifies to the identity of the sender. Fortunately, it is much harder to forge a digital signature. Encryption protects the confidentiality of messages so that only the party or parties for whom the messages are intended can decrypt and read them. 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 an intruder cannot pretend to be one of the users, or use some other method to undermine their communication. After users are authenticated to each other, it is possible for someone listening in on the line to eavesdrop and even modify the communication 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 take a message and digest it into an indecipherable string of fixed length, so that every message is digested to the same size. Inferno includes a counter as well as a secret key known only to the communicating parties in the message digest to ensure that messages are received in the correct order and that no messages are inserted by someone listening in on the line. It is almost impossible for two messages to digest to the same value. Digital signatures Inferno uses public key cryptography to create digital signatures. A secret key known only to the party sending a message is used to create the signature. A public key, or one that can be distributed openly, is used to verify the signature. A signature in Inferno includes a digest of a message, the signer's identity, and the names of the algorithms used for hashing and signing. Using the sender's public key, the receiving party is able to "unlock" the information in the signature and verify that the message has not been modified and has indeed been sent by the user claiming to have sent it. A message does not have to be encrypted to have a message digest appended to it. The digest ensures that no one has tampered with the message. It does not prevent someone from reading it. Likewise, digital signatures do not prevent an intruder from reading a message. Message Encryption The traditional notion of encryption is translating a message, called a plaintext in cryptography, into something unreadable, called a ciphertext. Cryptograms you see in the newspaper are simple examples of this. Its most obvious use is to provide confidentiality. Only someone who can decrypt the message, or translate it back to its original form, will be able to interpret it. Two basic types of algorithms are used in cryptography: private 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 securely. It is often called a private or secret key. In general, 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 the user sending a message. The public key, however, does not have to be kept secret and may be distributed to anyone the user wishes to communicate with. While public key algorithms offer a high degree of security, they are often slower than symmetric key cryptography. Inferno uses a public key algorithm for digital signatures and symmetric key algorithms for encryption. Supplied Algorithms Some of the tradeoffs related to choosing algorithms are speed, degree of security, and licensing restrictions (e.g., the U.S. government restricts which algorithms may be exported to other countries). All the algorithms used in Inferno are well known, commercially available, and rigorously tested. For message digesting: SHA, MD4, and MD5 are all well known (in cryptographic circles) one-way hashing algorithms. MD4 and MD5 are high-speed, 128-bit hashes. SHA offers more security by using a 160-bit hash, but is slower. MD5 is more secure but slower than MD4. For digital signatures: ElGamal is a widely used, public key system. It uses a private key for signing a message and a public key for verifying it. One property of ElGamal is that it makes it easier to adopt a different signature algorithm as requirements change compared with systems like RSA that use equivalent keys, where either a private or public key can be used for encrypting or decrypting. With constant advances in computing power and 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. For encryption: DES (the Data Encryption Standard) was adopted by the U.S. 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 vulnerable than ECB. Both versions of DES provide 56-bit keys. Neither is exportable outside the U.S. RC4 is a symmetric or private key system that is about 10 times faster than DES and is exportable with a key size of 40 bits. In the U.S., RC4 can be used with keys of virtually unlimited length. Diffie-Hellman is an algorithm for creating a secret key to be shared by users (sometimes called a shared secret) for encrypting messages. 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 then able to create the same, secret key from this information, although no one else listening to their exchange would be able to determine the secret key. Security Protocols Strict protocols are used to thwart attempts to disrupt or listen to confidential communications. These protocols establish a level of trust between communicating parties. In Inferno, two well established protocols, Encrypted Key Exchange (EKE) and Station-to-Station (STS), are used to permit keys to be exchanged and the identities of communicating parties to be verified. The record format used to transmit secure data between programs follows the SSL protocol proposed by Netscape, although Inferno uses a more secure, initial handshake. The Certifying Authority Signatures can be used to establish the identities of communicating parties, but a signature can only be trusted to the extent that the public key for verifying the signature can be trusted. Inferno allows for a third party, called a certifying authority, to create a certificate testifying to the identity of the user who owns the public key. Mutual authentication in Inferno requires that two parties who want to communicate must trust the same certifying authority or CA. Otherwise each party would not be able to trust that the certificate for the other party's key was valid. In Inferno, a certificate includes a variety of information: a user's public key, the identity of the user, Diffie-Hellman parameters, an expiration time for the certificate, along with the signature of the CA to confirm that the certificate is indeed from the party you know and trust. As part of the EKE protocol used to get a certificate, the CA's public key is also sent to each user. This enables the users to verify the CA's signature to confirm that the certificate is from the CA that they trust. Establishing trust between a CA and a user requires some out-of-band or non-computer communication (for example, a letter or phone call), since ultimately, secure communications depend on a level of trust that encryption algorithms and protocols cannot provide. In Inferno, a password can be communicated out-of-band between the CA and user for this purpose. This password ensures the identities of the user and CA, and together with the EKE protocol, protects the exchange of keys and certificates between them. Applications on a set-top box, which may not have a keyboard, can obtain a certificate using a different protocol that does not require a user to enter a password. With this protocol the CA sends a certificate to the set-top box encrypted with a bit pattern called a "blinding bit string." Without knowing this string, the box cannot produce a useable certificate. Only after the user has passed an out-of-band verification of their identity, does the CA send the blinding bit string to the set-top-box so that the certificate can be used. In addition to providing certificates to users, the CA in Inferno also determines the algorithm and size of the public key used for digital signatures. These are determined during the EKE protocol when the CA provides the user with a certificate. Using Certificates for Authentication If someone sends you a public key and certificate, can you verify that it is indeed the public key of the party they claim to be? Well if you have the same CA as the party sending you the key, then you can use the CA's public key that you received previously to check the signature on the certificate. If the certificate is valid, it will testify that this is the public key of a particular user. If you can trust the public key, then you can use it to check the signature that was sent to you. If the public key unlocks the signature, then whoever sent the signature must have the corresponding secret key, and, therefore, must be the owner of the public key. This method of establishing trust between two parties is called authentication. Protocol for Authentication: STS The following diagram shows how the STS or Station-to-Station protocol is used in Inferno to perform authentication. This diagram assumes there are two users, U0 and U1, who have already received certificates from the same CA. First, one user sends the other their public key and certificate along with a computation based on the Diffie-Hellman (DH) parameters contained in their certificate. These parameters will be used to create a shared secret key between U0 and U1. U1 returns a computation based on the same Diffie-Hellman parameters along with U1's public key and certificate. With each other's public key and certificate, along with the CA's public key that each has, U0 and U1 can verify that each has the other's public key. All they need is to provide each other with a signature that can be verified with the other's public key to prove that they are indeed communicating with each other and not some intruder. They each sign information that is known to both of them, and which they can verify. This information consists of the computations they passed each other previously. These computations using the DH parameters also enable U0 and U1 to compute a secret value that is known only to them and can be used as a shared secret key to encrypt later communications. The ability to derive the same key from the computations they passed back and forth such that no one else listening in on this protocol could determine the key, is a property of the Diffie-Hellman exchange. [Image] Preventing Attacks These are a few examples of design decisions to enhance security in Inferno. For ElGamal, Inferno uses a modulus of up to 4096 bits to determine key size. The key size for RC4 can be virtually unlimited. Large keys deter brute-force attacks to determine the values of keys. Use of the EKE and STS protocols protect against various types of attacks, for example, man-in-the-middle attacks where someone pretends to be one of the users. Random numbers are generated for each communication to create a new secret key. This makes it difficult for a would-be attacker to reuse previous communications to figure out the key. Passwords are protected by XORing them with an initialization vector that is generated each session. The DES algorithm is enhanced by padding messages. This makes it more difficult for someone to use a known-text attack, that is, to decipher text that may be easily recognized at the end of a message. Security at the Application Layer Applications have the choice of using security or not. An application can use the login function to obtain a certificate and can establish an authenticated connection with another application over a network with the auth function. Having authenticated their connection, each application connects to an ssl (secure sockets layer) device by calling the connect function. The applications then can write to and read from the ssl device using various algorithms such as SHA, MD5, and RC4 to digest and/or encrypt messages. The command interface for Inferno uses these same routines to provide secure connections. For example, the mount command to mount remote resources uses these routines to authenticate a connection and perform message digesting or encryption. In addition to application routines, Inferno provides commands to set up a secure network, for example, to establish a server as a Certifying Authority (CA) and to provide certificates for file servers and clients. The command createsignerkey is used to create a secret and public key on the CA. Changelogin is an interactive command that stores a hashed password on the CA, and getauthinfo is used to obtain a certificate. Inferno also provides special security routines for set-top boxes. On a set-top box, the register routine obtains a certificate without requiring a user to enter a password. Security routines for set-top boxes are demonstrated by the MUX application provided with Inferno. Although only a few routines are necessary to provide secure communications between applications, lower-level routines used by login and auth are also made available to applications that may have special security requirements. These routines provide functionality such as: * generating public and private keys for signatures * creating message digests * generating large, random numbers * performing exponentiation and modular arithmetic * providing digital signature and verification capability These are only some of the additional routines which the designers of Inferno felt could be useful to other developers. An application could use these lower-level routines to implement its own protocols, for example, or it might use the signature and verification routines to create secure files. Security Across the Network One of the powerful capabilities of Inferno is to enable applications to access resources across heterogeneous networks using namespaces. The security layer we have described enables applications to access these resources in a secure manner no matter what platforms the resources exist on. For example, an application on one system, A, might need to access resources on a system, D, several hops away with systems B and C in between. System A could be a set-top box, system B could be running UNIX, system C could have Windows 95, and system D could be running Windows NT. In this scenario, system C would mount the resources of system D and obtain an authenticated connection, and likewise, system B would mount the resources from system C and establish an authenticated connection. When system A mounts the resources it needs from system B and authenticates the connection, the application on system A can be assured that it is accessing resources that physically exist on System D in a secure manner, because a level of trust has been established across the network. Each system would have obtained a certificate from the same CA and would have used the STS protocol to authenticate the system it was mounting. [Image] As mentioned earlier, namespaces are also a key security feature in Inferno, since they control what resources an application can access. Contact Us Developers with specific requirements are encouraged to contact us. ---------------------------------------------------------------------------- [What's New?] [Image] [Support] [Download] [Contacts] [Home] Send comments to: infernoweb@lucent.com Copyright ©1997, Lucent Technologies. [Image]