Network working group Stephen R. Hanna, Sun Microsystems, Inc. Internet Draft January 2002 Expires: July 2002 draft-hanna-zeroconf-seccfg-00.txt Configuring Security Parameters in Small Devices Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Before a device is installed into a secure network, certain security parameters (such as keys) must be configured. This document describes several techniques for establishing these parameters and analyzes their advantages and disadvantages, considering especially their suitability for inexpensive devices and inexperienced operators. 1. Introduction The IETF's Zero Configuration Networking working group is working on protocols that allow devices to form a network with little or no configuration. Unfortunately, securing such a network is problematic. All proposed security techniques require some configuration. Otherwise, your new lamp won't know that it should respond to your commands and not your neighbors'. The challenge is to make this configuration as easy as possible and keep the per-device cost low. This document describes several techniques for establishing security parameters and analyzes their advantages and disadvantages, especially their suitability for inexpensive devices and inexperienced operators. This document does not describe the exact set of security parameters to be established or how those parameters should be used in a zeroconf environment. Another document will tackle that problem. But a simple example of such parameters would be a single symmetric key shared by all trusted devices on the network and used for encrypting and authenticating transmissions between those devices. 2. Evaluation Criteria Several criteria are examined for each configuration technique. For each criterion, I will rate the schemes on a 1-5 scale with 1 being unacceptable and 5 being excellent. No perfect solution has been found. Each technique provides different tradeoffs among the various criteria. 2.1. Device Cost Solutions should increase the cost of the device as little as possible. Cost is a crucial criterion for consumer goods. My goal is to keep incremental cost so low that anyone who creates a device with zeroconf networking abilities will include security. 2.2. Ease of Use Solutions should be as easy for the user as possible. A slow, complex, or cumbersome process is a barrier to use. 2.3. Security Solutions should be as secure as possible. Security is the point. See section 3 for a threat analysis. 2.4. Flexibility Solutions should be flexible, so that they can work with many different kinds of devices. For instance, a solution that requires the device to display a number won't work if the device doesn't have a display. 3. Threat Analysis The goal is to easily configure a device so that it can communicate securely with other devices on a network. I will only analyze configuration mechanisms, not the protocols used to communicate among devices. But it is still important to have a clear understanding of the threats against which these configuration mechanisms are designed to protect. I will examine attacker's goals, motivations, and abilities. 3.1. Attacker Goals and Motivations Attackers may want to read messages sent by the device, such as audio signals or other monitoring data from sensors. They may also want to control the device by sending it commands, such as the ability to open doors or windows, turn lights on and off, etc. Or they may just want to detect homes that have wireless networks and therefore might be good targets for burglary. Attackers' motivations may include curiosity, mischief-making, malicious destruction, or financial gain. 3.2. Ability to Read and Modify Network Data I assume that attackers can read or modify data sent over the network and inject arbitrary messages into the network. This is consistent with networks commonly used in zero configuration environments, such as a wireless or power line network. Layer 2 encryption can be used to secure such networks and should be employed when available. However, some layer 2 encryption systems are easily bypassed or broken. Also, some networks do not offer level 2 encryption and a zero configuration network can span multiple layer 2 networks, thus providing a vulnerability. Even a network completely protected against outside participation can be vulnerable to these attacks if some of the devices on the network become compromised or act as gateways for outside networks. In general, it's best to assume that attackers have access to the network. 3.3. Physical Security In general, I assume that attackers are not able to violate a device's physical security. With inexpensive devices, even a brief period of unmonitored physical access will generally allow a skilled attacker to compromise a device or replace it with an identical, compromised unit. In the zero configuration environment, these assumptions may not hold. Neighbors, workmen, and other partially trusted guests are often welcomed into one's home with little supervision. Even roommates or family members can become adversaries at times, perhaps resulting in "insider attacks". Device security cannot offer a great deal of protection against such problems. However, some of the configuration systems noted below provide a bit of protection against physical attacks, especially against unskilled attackers. I will note such protection where present. 3.4. Device Vulnerabilities The attacker may be able to take advantage of bugs and vulnerabilities in the device software or hardware to compromise the device (for instance, sending an invalid message that causes a buffer overflow and allows the attacker to execute arbitrary code). Configuration solutions cannot offer much protection against such vulnerabilities. Device manufacturers often include backdoors that their support staff can use to help customers gain access. Such backdoors can represent a serious security hole. If they decide that backdoors are required, manufacturers should design them so that they require physical access to the device. 3.5. Denial Of Service An attacker who can send data on the network can probably easily jam the network with packets (or just with noise). Configuration techniques can't provide much protection against such attacks. However, this sort of active attack may make it easier to find an attacker. 3.6. Configuration Attack Most people probably won't ever enable security on their device. An attacker can mount a clever denial of service attack by configuring security on the device (or reconfiguring it, if it's already enabled) so that the user can't access the device. To prevent such attacks, security should be hard to enable (requiring physical access and perhaps a password shipped with the device) and easy to disable (if you have physical access to the device). Of course, this will make it easy for attackers with physical access to the device to disable security. But a home controller can quickly detect this and notify the owner. Requiring physical access to disable security (pressing a button) is a reasonable compromise. After all, device manufacturers will not include security features if they are likely to increase support costs. 3.7. Traffic Analysis Various attacks based on traffic analysis may be possible. One of the more obvious is for a burglar to drive around with a wireless networking antenna, detecting wireless network traffic to decide which homes are likely to have computers inside. Possible countermeasures could include using wired networking to make detection more difficult. Installing a monitored security alarm and purchasing sufficient theft insurance would also be prudent. In any case, this has little to do with configuration. 3.8. Summary Device security typically offers little protection against physical attacks and insider attacks. However, some protection can be offered by employing a controller that monitors devices and notifies the owner when devices change. Since device security can be used to lock someone out of their devices, it should be easy to disable device security if you have physical access to the device. The home controller should detect and log such changes, in case they were unauthorized. The primary area where device security can be effective is against attacks that are mounted remotely (through the network). Such attacks can be mounted with little risk or cost to the attacker and without raising the suspicions of the attacked party, especially when a wireless network is employed. The configuration techniques described in this document provide a way to configure security parameters (such as keys) that may be employed in protocols to protect against remote attacks. 4. Security Configuration Mechanisms On conventional systems, initial security parameters such as trusted keys and security policies are usually typed in with a keyboard or loaded from floppy disk or other removable storage device such as a CD-ROM or smart card. Once those initial parameters have been established, they can be used to securely deliver other things such as software and updated security parameters. Many consumer devices don't have a keyboard or removable storage device. Adding these things would increase the cost of the device too much. Some devices have a limited keyboard and display, but entering a long key into my microwave oven isn't my idea of fun! Here are some other ways that security parameters can be configured into consumer devices. 4.1. Secret stored in device during manufacturing With this solution, a cryptographic secret is stored in the device during manufacturing. This secret generally cannot be changed. The secret is also printed as a bar code, which is sealed in a tamper-evident manner and shipped with the device. When the device is purchased, the bar code is scanned into a home controller or other security manager. The security manager can now use this shared secret to send the security parameters to the device over an untrusted network (encrypting the data with the secret). The secret can be transferred to the security manager in many other ways. It can be printed in a human readable format and typed on a keyboard, stored on and read from a mag stripe card or a floppy disk, etc. In general, I will say that it is transported to the security manager via a "secure transport mechanism". Including a keyboard, barcode reader, or removable storage device in the security manager shouldn't be a big cost problem. You only need one security manager per home and it will probably have a keyboard and display to interact with the user, anyway. The secret could be transmitted from the device to the security manager over a secure network, such as a dedicated wire, a proximity network (like infrared or Bluetooth), or by touching electrical contacts. However, if a secure network is available, it is usually better to generate the secret on the fly (as describe in section 4.2). This reduces manufacturing cost and eliminates the risk of the user losing the secret. Therefore, this option is not analyzed any further. It is not good to just print the secret on the bottom of the device, or a casual visitor can read it without detection. Putting the secret on a storage mechanism (like paper) that is included with the device allows the user to keep this copy of the secret in a safe place, away from prying eyes. Making the secure transport mechanism tamper-evident (by wrapping it with a printed piece of plastic or using a sealed piece of paper) makes it less likely that someone will copy the secret before the user receives it, without their knowledge. This attack seems unlikely, especially if the user buys the device from a large store. Therefore, I conclude that tamper-resistance should only be used if it doesn't add much to the cost or decrease ease of use much. Another way to get the secret to the security manager is to have the security manager download the secret from a central server by providing the device's serial number or some other identifier. Unfortunately, such identifiers are usually not secret (or there would be no need to download the secret!). So it would be easy for an unauthorized party to find out the serial number and download the secret. So this isn't a great answer, either. In order to protect against configuration attacks (where someone turns on security and the owner doesn't know how to use it), there should be a switch, button, or other control on the device that enables and disables security. It should be shipped with security off, since most people won't want to use security. Someone with physical access to the device could use the switch to disable security, but the security manager should be able to detect this and notify the owner. Why not allow security to be enabled over the network? Because that means you can mount a configuration attack without physical access. 4.1.1. Evaluation Cost The device will need a place to store the secret. However, it would already need a place to store the security parameters, so this probably will not add much to cost. Including a switch to enable and disable security may add some significant cost (up to $1). Devices that already have a keyboard can use a special combination of keys for this, eliminating any incremental cost. Manufacturing cost will increase, due to the need to generate the secret, store it on the device, and place it on the secure transport mechanism. The cost of the secure transport mechanism must be considered, as well. And there must be a security manager that knows all of the device secrets and supports the secure transport mechanism (via a keyboard, a barcode reader, or some similar mechanism). However, this cost may be spread across many devices. Also, this device can serve other functions as well, such as providing a UI for controlling and configuring devices. The incremental cost per device will vary. For simple devices, the cost of the security switch may be significant. But increased manufacturing costs will probably be the greatest factor. I'll rate this scheme a 3 for cost. Ease of Use Scanning the secret into the security manager should be pretty easy. But what if the user loses the slip of paper first? Or what if their security manager breaks? They need to find the slip of paper to scan into the new security manager. In many households, the slip will be lost quickly. Flipping the switch to enable security is a minor irritant compared to this problem. I'll rate this scheme a 2 for ease of use. Security What if someone nasty learns the secret? They might see the slip of paper, take the security maneger, or some such. There's no way to change the secret. So they will have total control over the device. And the device's owner may not even know about this. I'll rate this scheme a 2 for security. Flexibility This scheme requires a switch or similar control to enable and disable security (unless you're willing to live with configuration attacks). It will be inconvenient for devices that are hard to access, such as a ceiling light. But enabling security should be a one-time event. Overall, this scheme gets high marks for flexibility. It should work with almost any kind of device. I'll rate this scheme a 4 for flexibility. 4.2. Secret established over a secure network When the user wants to enable security, she connects the device to a security manager via a secure network (such as a wire directly connecting the two). Then she presses a button on the device, which generates a new secret and sends it to the security manager over the network. Now the device can be removed from the secure network and security parameters can be downloaded securely from the security manager, using the secret. Security can be disabled by holding down the button for a longer period of time. As a further alternative, the secret can be generated by the security manager instead of the device. This makes more sense, since the security manager will probably include a good source of entropy. The device can send a secret request when the security button is depressed and the security manager can respond by sending a new secret. This also means that security could be disabled by disconnecting the device from the secure network, pressing the button to trigger a security request, and noting that no response was received. What kind of secure network can be used here? Many things will work: a dedicated wire (like a USB cable), a proximity network (like infrared or Bluetooth), or physical contact by touching electrical contacts. Probably the simplest thing to do is to use power line networking. Most devices have a power plug and the security manager can have a special socket that's isolated from the rest of the power grid. Devices that don't have a power plug may have a recharging stand that has a power plug and could relay communications to the device. There are a few obvious alternatives to the secure network. The security manager could display the secret after generating it and the user could type that value into the device's keyboard. But that's much too painful for the user and it requires the device to have a keyboard (and a display, to check for typos). If the device generates the secret and displays it, then the device only needs a display but the user still has to type the secret (which will typically be dozens of letters and numbers). The device could print the secret as a barcode or store it on a floppy disk or other storage device, but including a printer or storage device in every toaster and light switch is much too expensive. 4.2.1. Evaluation Cost The cost of storing the secret and the cost of the security button should be the same as with the previous scheme. The incremental manufacturing cost of the last scheme isn't required for this one, since there's no need to generate a secret, print it, etc. There may be extra cost for including the secure network. However, many devices that support zero configuration networking will probably already include support for power line networking, which means that no extra cost will be incurred. I'll rate this scheme a 4 for cost. Ease of Use Connecting the device to the security manager and pressing a button is pretty easy. I'll rate this scheme a 4 for ease of use. Security If a secret is compromised, it's easy to generate a new one with this system. As with the previous system, anyone with physical access to the device can disable security with the press of a button. But that's a good thing, since it makes it easy to recover from configuration attacks. And it should be easy for the security manager to notice if security is disabled on a device. I'll rate this scheme a 4 for security. Flexibility With a device that doesn't have a power plug (like a light switch), it may be difficult to establish a secure network. A secondary cable could be used, but this will require extra cost and it may be difficult to agree on a standard connector and cable type. I'll rate this scheme a 3 for flexibility. 4.3. Secret established over an insecure network Wouldn't it be nice if the device and the security manager could establish a shared secret over the normal zeroconf network? Then there would be no need to use a secure network, as in the last scheme. Actually, there is a way to do this, even if nasty folks are listening in. It's a Diffie-Hellman exchange. Here's a simplified description. A large prime number p and a generator g are chosen in advance and are well-known. The device and security manager each choose a random number between 1 and p-2. Call the device's random number a and the security manager's number b. The device computes g^a mod p and sends this value to the security manager. The security manager computes g^b mod p and sends this value to the device. Now each of them can compute g^(ab) mod p. And no eavesdropper can determine g^(ab) mod p without a *lot* of work. The problem with this system is that the device and the security manager can't be sure they're talking to each other. There might be a "man-in-the-middle" who has established a different shared secret with each of them. Or maybe the interloper just impersonated the security manager and the security manager wasn't aware of any exchange? Since the network is not secure, this sort of thing can happen. One way to overcome this problem is to have the device and the security manager hash the newly-established secret and display a few bits of this hash. The user can then compare the displayed values. If they match, then the secret has been established properly. This system has several problems. Most important, it requires too much work from the user. Also, it requires a display on the device. This isn't practical for light switches and other small or cheap devices. Finally, computing g^a mod p and g^(ab) mod p in a few seconds requires lots of compute power (or a p that's too small to be secure). And the device must have a good-quality random number generator. Much too expensive for a cheap device. 4.3.1. Evaluation Cost Including a display, high-quality random number generator, and serious computing power in the device will increase cost of goods substantially (probably $10 or more). I'll rate this scheme a 1 for cost. Ease of Use Copying down a long string of numbers and letters and comparing them to another set of numbers and letters isn't easy or pleasant. I'll rate this scheme a 1 for ease of use. Security If the user fails to compare the secrets, a man-in-the-middle attack is possible. The user has to do this for each device. I'll rate this scheme a 2 for security. Flexibility Small devices may not have space for a display. I'll rate this scheme a 3 for flexibility. 4.4. Other systems Many other solutions have been considered and rejected. Here's a brief description of some of these solutions. The user could choose a secret and enter it into the device and the security manager. But users don't generally choose good cryptographic keys (which must be very long and truly random numbers). An attacker with a computer could find a user-chosen key in a fraction of a second. The security manager could choose a secret and then have the user enter it into a keypad on the device. But this would not be easy for the user and it would require a keypad on the device (and a display, to check for errors). The device and/or the security manager could have a public-private key pair (and perhaps a certificate). But then I must securely configure the public key or certificate identifier for one into the other. This is similar to the problem of establishing a shared secret, above. And public key cryptography requires much more CPU power than symmetric cryptography. 5. Conclusions 5.1. Configuring Security Parameters Security parameters can be safely configured with the systems described above. Several of these systems are practical and add little or no extra cost per device. Some user configuration is required, but that seems to be inevitable. I recommend that a standard be created (maybe by the IETF, maybe by someone else) that describes the first two schemes listed above (Secret stored in device during manufacturing and Secret established over a secure network) and develops them into a form that can be incorporated into shipping products in an interoperable manner. Most devices should probably use the secure network technique, since this is easier for the user and less error-prone. Devices that do not have a power plug may want to use the secret stored during manufacturing technique. Certainly, there may be other good techniques. I welcome ideas from others. Please send them to my email address, listed below. 5.2. Zeroconf Security Currently, each of the zeroconf protocol specifications has its own security system. Each of these systems requires configuration and complexity. This is not practical. I recommend that the zeroconf working group create a security specification that either explains how these several security systems can be automatically bootstrapped using the mechanisms described above or (preferably) replaces these security mechanisms with a simpler system such as IPsec with a single group key shared by all authorized members of the zeroconf network. 6. Acknowledgments I would like to thank Erik Guttman, Radia Perlman, and Aiden Williams for useful discussions on these topics. Ross Anderson's Resurrecting Duckling paper [1] describes the need to "imprint" a device with security parameters and describes one solution (electrical contact). 7. Security Considerations This document is full of security analysis and proposed security solutions. 8. References [1] Stajano, F. and R. Anderson, "The Resurrecting Duckling: Security Issues for Ad-hoc Wireless Networks", from Security Protocols: 7th International Workshop Proceedings, Lecture Notes in Computer Science, 1999, Springer-Verlag. 9. Authors' Addresses Stephen R. Hanna Sun Microsystems, Inc. One Network Drive Burlington, MA 01803 USA Phone: +1.781.442.0166 Email: steve.hanna@sun.com 10. Intellectual Property Statement Sun Microsystems holds intellectual property rights pertaining to several of the ideas described in this document.