Encryption at the University of California: Overview and Recommendations

1 Introduction

Encryption is the process of converting data into a cipher or code in order to prevent unauthorized access. The technique obfuscates data in such a manner that a specific algorithm and key are required to interpret the cipher. The keys are binary values that may be interpretable as the codes for text strings, or they may be arbitrary numbers. Appropriate key management allows one to store or transmit encrypted data "in plain sight" with little possibility that it can be read by an unauthorized entity. For example, encryption can protect the privacy of restricted data¹ that is stored on a laptop computer, even if that laptop computer is stolen. Similarly, it can protect data that is transmitted, for example, over a network, even if that network is tapped by an unauthorized third party.

The best way to protect data is not to have it. Restricted data should be retained only when necessary. When it is necessary to retain restricted data, encryption can be an effective protection.

Encryption is not, however, a panacea. It is not a substitute for other security measures, such as authentication, authorization, and access control, and must be used in conjunction with those other measures. Careful analysis of candidate systems is needed to determine encryption's applicability.

The purpose of encryption is to prevent unauthorized access to data while it is either in storage or being transmitted. In order to accomplish this, proper key management is crucial. If a key gets into the wrong hands, unauthorized access to information can result. Conversely, if a key is lost or destroyed, critical information may become unavailable to authorized personnel.

This document describes a variety of scenarios where encryption can protect restricted data. It also emphasizes other security measures that may be required in conjunction with encryption (or substituted for encryption) to achieve full security.

2 Encryption of Data "At Rest" and "In Flight"

Data can be in an encrypted state while it is in storage ("at rest") or while it is being transmitted ("in flight"), as illustrated in the following diagram, which depicts two computers, each with local disk storage, that are connected over a network. The computers may be of any type, desktop, laptop, PDA, smart phone, etc. with any type of storage medium. Similarly, the network may be of any type, wired or wireless. The two types of shading indicate what is protected by these two types of encryption.

N.B. Encryption does not protect data while it is being processed by a computer, only while it is being stored or transmitted. By its very nature, encrypted data must be decrypted before it can be processed; the only things computers can do with encrypted data is store or transmit it. Other protections, such as strong identity management with authorization and access control must be utilized to provide protection while data is being processed by a computer.

2.1 Encryption for Data Storage

Over half of the University's unauthorized releases of personal information could have been avoided if lost or stolen laptops' hard drives had been encrypted. While operating systems provide access control mechanisms that can prevent unauthorized access to sensitive data, a data thief with physical access to a computer can bypass these protections, either by moving the storage to another computer or simply by starting the operating system in a manner that grants access to the thief. Encrypting data "at rest" protects the confidentiality of the data in this situation. Storage encryption may not, however, provide protection against a direct attack on a computer's access controls.

2.2 Encryption for Data Transmission

Data transmitted over a network is vulnerable to interception by unauthorized personnel. Wireless networks are particularly susceptible to unauthorized interception, and the commonly available wireless encryption solutions are not generally very secure. Encrypting data "in flight," while it is transmitted over a network, protects the confidentiality of that data.

The phrases trusted network and untrusted network appear multiple times in this document, referring to the security of the network or networks used to transmit data. Unfortunately, there is no hard line dividing trusted and untrusted, and no network is 100% secure. The determination of whether a network is trusted is dependent on the nature of the data and the transmission and should consider physical, administrative, and technical security measures that have been implemented for the networks involved in the transmission. In most cases, it is safest to assume that networks are untrusted.

It should be noted that there is another way to move data that does not involve data transmission over a network. Data can be stored on portable media, such as CD-ROMs or USB "thumb" drives, and physically transported to its destination:

In this case, storage encryption can be used to protect data while it is "resting" in a vehicle.

2.3 Real World Examples

The following diagram shows a mix of servers, desktops, laptops, and PDAs that can communicate over the Internet. These devices are shown within the boundaries of various security domains that are separated by network firewalls:

1. Enterprise (Campus) Network in a Physically Secured Data Center with Appropriate Administrative, Physical, and Technical Access Controls, as defined in Business and Finance Bulletin IS-3, Electronic Information Security,
2. Enterprise (Campus) Network in a Physical Space without Appropriate Access Controls, and
3. Internet External to Enterprise (Campus) Network
   

As can be seen in this diagram:

1. Data stored on devices within a data center is likely protected from unauthorized access because of the physical security and physical access control provided within the data center.

2. Sensitive data stored within other areas of an enterprise is less likely to be appropriately secure without encryption, unless a secured room or other suitable space has been prepared with appropriate physical access controls.

3. Sensitive data stored outside of the enterprise is not likely to be appropriately secure without encryption.

4. Data exchange among devices within a secure facility like a data center is likely secure without the use of encryption, assuming the traffic never leaves the physically secure boundaries of the facility. It should be noted, however, that the security of all systems within the secure facility is crucial, as a compromised system within a physically secure facility could be subverted to intercept traffic on behalf of an intruder.

5. Data exchange among devices within a single enterprise network is less likely to be secure without encryption than within a secure facility. Many portions of the enterprise network are not likely to provide an appropriate level of physical security for sensitive data.

6. Data exchange among devices not contained within a single enterprise network is not secure without encryption. This is true even when each of the devices is contained within a (separate) secure facility.

3 Use of Encryption for Data Storage

As required in Business and Finance Bulletin IS-3, Electronic Information Security, restricted data must be encrypted wherever it is stored in locations that are not physically secured with physical and technical access controls appropriate to the sensitivity of the data. This section discusses common scenarios where storage encryption can enhance security.

3.1 "Whole Disk" Encryption

Computing devices, such as laptops, PDAs, and smart phones, as well as storage media, such as CDs, DVDs, and USB drives, all have the potential of falling into the wrong hands, particularly when they are not stored in a secure location. Even non-mobile devices, such as desktop computers, have this potential. "Whole disk" encryption solutions that encrypt entire disks or disk partitions can be used to protect information on such devices. Encryption solutions that automatically encrypt all files that match configured filters can also be appropriate to protect data in some environments.

Operational Issues

Key management for whole device encryption is usually very important. If a key is lost, it is likely that the data on the device cannot be recovered, particularly if there are no other copies of the data available. In effect, key loss is not much different from a disk head crash. Care should be taken to ensure the integrity of the key repository. This repository is restricted data in itself, so strong protections, such as encryption and access control, must be implemented. (See Section 7, Key Management)

An unencrypted backup solution may be an appropriate substitute for key management, depending on tolerance for loss between the time of the most current backup and the time a key is lost. Note, though, that unencrypted backup media can represent a vulnerability; see Section 3.4, Backup and Archiving.

An encrypted disk reduces the risk of unauthorized disclosure of data when the disk is disposed of. Nevertheless, steps must be taken for the complete removal of restricted data before disposition.

It should be noted that whole disk encryption does not generally provide security from the authorized users of an encrypted disk. Operating system access controls and other security measures will likely be required for multi-user systems. Similarly, since servers with encrypted disks will likely provide unencrypted data over the network, encryption for data transmission (see Section 4, Use of Encryption for Data Transmission) should also be considered.

Recommendations

If the data on mobile devices or media is restricted, it should be encrypted through the use of a "whole disk" encryption tool or one that can at least be configured to encrypt all restricted data. Further, any computing devices and media have the potential of being lost or stolen if sufficient physical security is not provided for them. Resource Proprietors and Custodians of restricted information should consider the following priority list when selecting candidates for storage encryption:

1. Mobile devices and media. This includes laptops, PDAs, smart phones, and media that are carried by mobile workers. Sufficient physical security can rarely be provided for mobile devices.
2. Movable devices and media that are kept in public or other areas that do not provide appropriate physical security. Cubicles and most offices will not generally provide appropriate physical security for restricted data.

Campuses should implement managerial and technical infrastructures to facilitate the encryption of mobile devices and media. As of this writing, system-wide contracts are being completed with two vendors of products that address the technical infrastructure.

3.2 File Encryption

It is often necessary to encrypt individual files. This is usually done to facilitate secure transport of those files. As discussed in Section 4.2, File Transfers, this allows for secure transport over a network without transmission encryption. It also allows secure transport of files on off-line storage devices, such as a CD-ROMs or "thumb" drives.

Operational Issues

The keys needed to decrypt the files must be sent to the recipient via some method other than how the file is transmitted to ensure that the encrypted files and the keys cannot be intercepted together.

Recommendations

Campuses should promulgate recommended tool sets to facilitate file encryption.

3.3 Database Storage

Encryption of database storage is often needed for reasons similar to whole disk encryption. In fact, encryption of database storage can often be implemented through the use of a "whole disk" encryption tool, but database server software may also provide this capability. A database server-based encryption solution is generally required to selectively encrypt specific tables or columns of a database and may also be required to segregate access rights among multiple applications that utilize a single database server.

Operational Issues

Database storage encryption does not imply that data in the database will be encrypted when it is transmitted over a network. In general, data is decrypted by the database server before it is transmitted, so encryption for data transmission (see Section 4, Use of Encryption for Data Transmission) should also be considered.

An encrypted database reduces the risk of unauthorized disclosure of data when the database's disk media are disposed of. Depending on the sensitivity of the data, it may not be necessary to contract for disk destruction services.

The decision of whether to use whole disk or database server encryption is dependent on a number of factors, such as the existence of multiple applications, system administration, performance, cost, and backup requirements.

3.4 Backup and Archiving

Backup and archival copies of restricted data are, themselves, restricted data. The media used for backup and archiving represent an opportunity for unauthorized access to data. Encryption can be used to protect that data.

Operational Issues

When storage encryption has been implemented, backup strategies should be reevaluated. Depending on the specific storage encryption and backup solutions used, the backups may or may not be encrypted.

More importantly, the backup media represent a copy of data that may require encryption. An assessment must be done of the need to encrypt the backup media, based on the sensitivity of the data and the physical and technical protections in place, particularly if the media are sent off-site.

If encrypted backups are created, key management becomes particularly important, especially in disaster recovery scenarios. A further issue for key management occurs when a backup must be archived for a long period of time. The archived media will be unusable if the keys are not similarly (but separately) archived.

Recommendations

Backup procedures should be assessed to ensure that backup copies of restricted data are appropriately protected, by physical and/or technical means, particularly when they are sent off-site.

4 Use of Encryption for Data Transmission

As required in Business and Finance Bulletin IS-3, Electronic Information Security, restricted data must be encrypted when it is transmitted across an untrusted network, and very few networks can be trusted. The possibility of interception by an unauthorized party is very real, even for "point-to-point" links. The following sections discuss various communication scenarios where encryption can protect restricted data in transit.

4.1 Interactive Sessions

Remote login sessions can represent a significant vulnerability to restricted data that is transmitted between the end-user and the server, particularly login passwords. Examples of remote login solutions include telnet, ssh, tn3270, and "remote control" software for PCs.

Recommendations

Interactive sessions that transmit restricted data should be encrypted. Note that login passwords should often be considered restricted, even when no other restricted data is transmitted.

4.2 File Transfers

Encryption for file transfers can be accomplished in one of two ways: 1) encryption of the transmission itself, or 2) transmission of an encrypted file.

1. Many tools exist to encrypt transmission of data; the ssh tool suite, particularly sftp and scp, is most common, but others can also provide appropriate protection. As with interactive sessions, key management is generally not an issue.
2. Transmission of encrypted files requires a file encryption tool. (See Section 3.2, File Encryption.) Files are encrypted prior to transmission and decrypted afterwards; the transmission protocol does not, itself, encrypt. The advantage of this strategy is that it enables use by "store and forward" transmission systems, such as electronic mail, without the possibility that the data can be accessed while it is stored on an interim server. This strategy does, however, require a key management scheme that is used mutually by the sender and receiver of a file.

Operational Issues

The encryption key for an encrypted file containing restricted data is also restricted data. Appropriate protections must be implemented for the encryption key.

It is not always practical to implement complete "end to end" encryption for file transfers, although this is desirable. When the two ends do not support mutually interoperable encryption solutions, files may be transferred without encryption to or from proxy systems that do support interoperable encryption and have a trusted system administration. That proxy system must be near enough to the real end-system (e.g., in the same data center) that unauthorized observation of the file is very unlikely when moved between an end-system and its proxy.

Recommendations

When encrypted files are transmitted, the keys should be transmitted via a separate, secure channel to minimize the possibility that the keys are intercepted along with the data they encrypt.

4.3 Web-Based Applications

Encryption for communication of restricted data between users' browsers and web-based applications and content is provided through the use of the HTTPS protocol, which incorporates TLS/SSL.

Operational Issues

Use of HTTPS requires installation of an X.509 digital certificate for the application's server. Since these certificates expire after a specified period of time, a process must be implemented to renew expiring certificates.

If the Certificate Authority used to generate a server certificate is not configured in a user's browser, the user will receive an error message saying that the server certificate is not valid.

Typically, information that is retrieved by a web browser is stored in a "cache" file directory on the browser's computer in an unencrypted form. This cache may be available to other people who access (or compromise) that computer.

Recommendations

The X.509 certificates installed on servers should be acquired from Certificate Authorities that are included in common browser distributions.

Display of restricted data should be limited to only what is required by the application. When restricted data must be displayed, however, that data should be sent with the "Cache-Control: no-cache" HTTP header to limit caching by web browsers. Application developers should also be aware that not all browsers honor this control for all file types.

Authorized users of applications that display restricted data should be cautioned not to use web browsers that are shared with people who do not have the same level of authorization.

4.4 Electronic Mail

• when it is being delivered across a network
• when it is stored on a mail relay
• when it is in the sender's or receiver's message store
• when it is accessed across a network from the sender's or receiver's message store (e.g., when message store is on an IMAP server)

S/MIME is an open, standard solution that solves all of these problems by encrypting the body of the message itself, using either PKI or PGP for key management. S/MIME also enables the use of digital signatures to verify the authenticity of the sender and the message. Unfortunately, it is not widely deployed, so it is really only of general utility within a well-identified community.

Various vendors, such as PostX, Tumbleweed, Voltage, and ZixCorp, provide server-based solutions that use electronic mail simply to notify recipients when a message has been stored for them on a secure web server. This also provides security, but requires the use of a second, web-based mail system, as well as a strategy for sharing encryption keys in a secure manner.

Operational Issues

Unfortunately, none of these solutions are widely deployed. It may be necessary to implement multiple solutions for different segments of the community. The most pragmatic approach at this point in time may be to put restricted data in an encrypted file and attach the file to an otherwise unencrypted mail message. (See Section 3.2, File Encryption.) This requires a strategy for sharing encryption keys in a secure manner.

Recommendations

Campuses should promulgate recommended tools for sending encrypted data through electronic mail. This is likely to include the tool set identified under "File Encryption."

4.5 Network Printer Communication

When restricted data is output to a network-attached printer, there is a vulnerability of unauthorized interception. When it is required to print restricted information, products such as JetDirect can be used to provide encryption. Alternatively, the printer can be directly attached to a server that utilizes a protocol, such as IPP, that can encrypt its network traffic.

Operational Issues

There may be a greater risk of people reading the printed material than intercepting the network traffic when the destination printer does not have sufficient access controls, either by being in a secure facility or through some authentication mechanism provided by the printer. The University has a growing number of applications that require employees to print restricted information, such as personal health care information or pay advice stubs. Resource providers should consider printer security when this is the case.

Many printers do not support encryption, and the cost and space requirements for dedicated print servers may be high. When restricted information must be printed, printers and associated encryption solutions must be selected to fit within the printing infrastructure, as well as providing encryption.

Recommendations

Resource Custodians for departmental and campus print services should assess the secure printing needs of their communities and provide solutions and education, as appropriate.

4.6 Remote File Services

Restricted information on file servers (e.g., servers that are mounted by client workstations to provide shared file directories) is vulnerable to unauthorized interception when that information is accessed over a network.

Operational Issues

Commonly used file server protocols, such as Microsoft's CIFS, do not support encryption. The WebDAV protocol, which is supported uniformly on all popular operating systems, can often be used as an alternative to provide encryption.

Recommendations

Resource Custodians for departmental and campus file services should assess the need to protect restricted data on their servers and implement encrypted protocols (and provide user education) as appropriate.

4.7 Database Access

Communication between an application server and a database server over a network is vulnerable to unauthorized interception if encryption is not employed.

Operational Issues

Encryption for communication with a database server is generally provided as part of, or an option to, the database server software.

In many common scenarios, it may not be necessary to encrypt the communication with a database server. For example, if access to a database is always through an application, and the application server is co-located with the database server in a data center, then communication between the two is unlikely to be observed by unauthorized personnel, and encryption is probably not needed. A corollary to this is that encrypting database access probably does not obviate the need for encryption in other aspects of a system. For example, it may still be important to encrypt the exchange of data between the application server and a user's web browser.

4.8 Application-to-Application Communication

Direct communication between cooperating applications is becoming more common; Web Services rely on this capability. As always, this communication is vulnerable to unauthorized interception.

Operational Issues

Modern application-to-application communication protocols, such as SOAP, are based on web protocols. When those protocols are used to transmit restricted data, HTTPS can be used to enable encryption. Because HTTPS's encryption is based on PKI, this also can guard against spoofing attacks by authenticating the applications to each other.

Application protocols that are not web-based often have a proprietary encryption option that can be used. When this is not possible, the only alternative may be to implement a Virtual Private Network (see Section 4.9, Virtual Private Network (VPN).).

Recommendations

Use SOAP with HTTPS or some other commonly-available encrypted protocol to transmit restricted data when possible. When not possible, restricted data should be transmission by means of a Virtual Private Network.

4.9 Virtual Private Network (VPN)

Operational Issues

VPNs are commonly engineered to encrypt traffic between an enterprise network and locations outside of that network, so traffic is often not encrypted within the enterprise network. If all traffic to a specific server, say a file server, should be encrypted, careful engineering of the VPN will be required.

In general, all members of a VPN will have equal access to all other members. It is difficult, for example, to use a VPN to ensure that the two computers exchanging data are the only two that can decrypt the traffic, increasing the likelihood that a third, compromised computer will be able to intercept the traffic.

It is difficult to configure a device to be a member of multiple VPNs. This can complicate situations where, for example, a single PC must access multiple secure applications provided by multiple organizations.

Recommendations

VPNs should be used to protect restricted information when other alternatives are not feasible.

Campuses should assess the need for a VPN to encrypt traffic for devices in untrusted or hostile portions of the network, such as campus wireless networks or the rest of the Internet.

5 Application-Level Encryption

It is nearly always best to design systems to use common encryption solutions, such as those discussed in other sections of this document. There may, however, be scenarios where it is necessary for applications to implement their own encryption. This typically would be required either when encryption is not available from the underlying software/hardware infrastructure, or when that underlying infrastructure cannot be trusted for the sensitivity of data being processed. When it is not possible to avoid application-level encryption, the following issues should be considered:

• The science of cryptology is based on subtle mathematics; it is not uncommon for software implementers to increase risk unintentionally through poor implementation.

• It is difficult to eliminate all untrusted infrastructure. In the end, it is likely that restricted information will need to be processed and displayed by a web browser or other client-based software that is difficult to control.
  

See Federal Information Processing Standards Publication 140-2, Security Requirements for Cryptographic Modules (http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf) for more information.

Recommendations

When it is necessary to implement encryption within an application, utilize a suitably strong, well-tested encryption algorithm, preferably from an "off the shelf" library.

6 Encryption Strength

Not all encryption algorithms provide them same level of protection. This is a function of the algorithm used and the length of the encryption key. For most commonly-deployed encryption algorithms, this typically means a key length of 128 bits to 256 bits.

7 Key Management

As observed earlier, proper management of keys is crucial if encryption is utilized to prevent unauthorized access to data. Improper disclosure or loss of a key can result in improper loss or disclosure of encrypted data. Assigning a new key will require re-encryption of the data.

For data transmission, the protocols often manage keys in an automated and secure fashion. Storage encryption, however, may require that keys be retained for the lifetime of the encrypted data. For this reason, when keys are retained, they must be managed in a manner appropriate to the security requirements of the data being encrypted.

If a key is used to protect restricted data, then that key is also considered to be restricted.

A badly-managed key increases risk to encrypted resources, perhaps to a point where it would have been better not to encrypt.

A key management infrastructure will likely be considered both restricted and critical, as defined in Business and Finance Bulletin IS-3, Electronic Information Security, bringing IS-3's requirements for management, physical, and logical controls into play. In particular, the following should be considered:

• The encryption key management plan must ensure that data can be decrypted when access to data is necessary. This requires backup or other strategies, such as key escrow, to enable decryption, thereby ensuring that data can be recovered in the event of loss or unavailability of cryptographic keys.

• The encryption key management plan must address handling the compromise or suspected compromise of encryption keys. A contingency plan should address what actions should be taken in the event of a compromise, such as with system software and hardware, cryptographic keys, or encrypted data.

• Encryption keys should be managed in a manner similar to passwords. For example, they should not be shared among multiple people, and they should be revoked when people leave the University.

• Users must be made aware of their unique role if they are given responsibility for maintaining control of cryptographic keys.
  

For more information on key management, please see NIST Special Publication 800-57 Recommendation for Key Management "" Part 1: General (http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf) and NIST Special Publication 800-57 Recommendation for Key Management "" Part 2: Best Practices for Key Management Organization (http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf).

Recommendation

Campuses should implement central key management services to ensure appropriate controls have been applied.

8 Other Uses for Encryption

8.1 One-Way Encryption

One-way encryption is a form of encryption that cannot be decrypted. It is typically used for passwords and other information that need only be verified, never retrieved. Note that the amount of data encrypted in this manner is often small, making this technique susceptible to brute force attacks. When the encrypted data is available to the attacker, many or all possible values can be encrypted to determine which unencrypted value generated a particular encrypted value.

8.2 Digital Signatures

Public key encryption can be used to verify the authenticity of documents or data, as well as the author or source of those documents or data. Key management is very important in this scenario, as unauthorized disclosure of a private key enables forgery that cannot be detected.

9 International Considerations

United States and foreign laws regarding encryption have changed many times over the past few decades. Some foreign countries, such as China, Korea, and Israel, currently regulate the import and use of encryption, and the United States currently regulates the export of encryption software source code. Travelers should investigate applicable laws before leaving the United States with, for example, an encrypted laptop computer. The United States State Department can provide assistance with domestic and foreign legal issues.

10 Summary of Recommendations

As required in Business and Finance Bulletin IS-3, Electronic Information Security, restricted data should be encrypted whenever it is stored in or transmitted across an untrusted environment. The following table provides recommendations that apply to all of the application scenarios in this document, as well as specific recommendations for selected scenarios.

11 Appendix: Encryption Technology

The following table shows specific technology solutions that can provide encryption for the various application scenarios described in this document.

12 Acknowledgments

This document is the result of work done by a subgroup of the University of California Information Technology Policy and Security Officers. The work group members were: