Encryption at the University of California: Overview and ...

• 1. Encryption at the University of California: Overview andRecommendations(April 20, 2006)Table of Contents1Introduction.....................................................................................................................22Encryption of Data At Rest and In Flight................................................................32.1 Encryption for Data Storage...........................................................................32.2 Encryption for Data Transmission..................................................................42.3 Real World Examples.....................................................................................53Use of Encryption for Data Storage................................................................................63.1 Whole Disk Encryption...............................................................................63.2 File Encryption...............................................................................................83.3 Database Storage............................................................................................83.4 Backup and Archiving....................................................................................84Use of Encryption for Data Transmission.......................................................................94.1 Interactive Sessions........................................................................................94.2 File Transfers................................................................................................104.3 Web-Based Applications..............................................................................104.4 Electronic Mail.............................................................................................114.5 Network Printer Communication.................................................................124.6 Remote File Services....................................................................................124.7 Database Access...........................................................................................134.8 Application-to-Application Communication................................................134.9 Virtual Private Network (VPN)....................................................................145Application-Level Encryption.......................................................................................146Encryption Strength......................................................................................................157Key Management..........................................................................................................158Other Uses for Encryption............................................................................................168.1 One-Way Encryption ...................................................................................168.2 Digital Signatures.........................................................................................169International Considerations.........................................................................................1610 Summary of Recommendations....................................................................................1711 Appendix: Encryption Technology...............................................................................2012 Acknowledgments.........................................................................................................22 EncryptionGuidelines-2006-04-20.odtPage 1

2. 1Introduction 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 data1 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 encryptions 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. 1 The phrase restricted data is used in this document with a liberal interpretation of its definition in Business and Finance Bulletin IS-3, Electronic Information Security. In general, it is better to decide to encrypt data than to leave it unencrypted, unless the overhead of key management or the encryption itself is an overriding issue.EncryptionGuidelines-2006-04-20.odtPage 2 3. 2Encryption 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. NetworkTransmissionEncryption (In Flight)Storage Encryption(At Rest) 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.1Encryption for Data StorageOver half of the Universitys unauthorized releases of personal information could havebeen avoided if lost or stolen laptops hard drives had been encrypted. While operatingsystems provide access control mechanisms that can prevent unauthorized access tosensitive data, a data thief with physical access to a computer can bypass theseprotections, either by moving the storage to another computer or simply by starting theoperating system in a manner that grants access to the thief. Encrypting data at restprotects the confidentiality of the data in this situation. Storage encryption may not,however, provide protection against a direct attack on a computers access controls.EncryptionGuidelines-2006-04-20.odtPage 3 4. 2.2Encryption for Data TransmissionData transmitted over a network is vulnerable to interception by unauthorized personnel.Wireless networks are particularly susceptible to unauthorized interception, and thecommonly available wireless encryption solutions are not generally very secure.Encrypting data in flight, while it is transmitted over a network, protects theconfidentiality of that data. The phrases trusted network and untrusted network appear multiple times in thisdocument, 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 is100% secure. The determination of whether a network is trusted is dependent on thenature of the data and the transmission and should consider physical, administrative, andtechnical security measures that have been implemented for the networks involved in thetransmission. 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 datatransmission over a network. Data can be stored on portable media, such as CD-ROMsor USB thumb drives, and physically transported to its destination: Storage Encryption (At Rest) In this case, storage encryption can be used to protect data while it is resting in avehicle. EncryptionGuidelines-2006-04-20.odt Page 4 5. 2.3Real World ExamplesThe following diagram shows a mix of servers, desktops, laptops, and PDAs that cancommunicate over the Internet. These devices are shown within the boundaries ofvarious security domains that are separated by network firewalls: A. 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,B. Enterprise (Campus) Network in a Physical Space without Appropriate Access Controls, andC. Internet External to Enterprise (Campus) NetworkAs 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. EncryptionGuidelines-2006-04-20.odt Page 5 6. 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.3Use 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.1Whole Disk EncryptionComputing 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 wronghands, particularly when they are not stored in a secure location. Even non-mobiledevices, such as desktop computers, have this potential. Whole disk encryptionsolutions that encrypt entire disks or disk partitions can be used to protect information onsuch devices. Encryption solutions that automatically encrypt all files that matchconfigured filters can also be appropriate to protect data in some environments. Operational IssuesKey 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 noother copies of the data available. In effect, key loss is not much different from a diskhead crash. Care should be taken to ensure the integrity of the key repository. Thisrepository is restricted data in itself, so strong protections, such as encryption and accesscontrol, must be implemented. (See Section 7, Key Management) EncryptionGuidelines-2006-04-20.odtPage 6 7. 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 timea 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 isdisposed of. Nevertheless, steps must be taken for the complete removal of restricteddata before disposition. It should be noted that whole disk encryption does not generally provide security fromthe authorized users of an encrypted disk. Operating system access controls and othersecurity measures will likely be required for multi-user systems. Similarly, since serverswith encrypted disks will likely provide unencrypted data over the network, encryptionfor data transmission (see Section 4, Use of Encryption for Data Transmission) shouldalso be considered. RecommendationsIf the data on mobile devices or media is restricted, it should be encrypted through the useof a whole disk encryption tool or one that can at least be configured to encrypt allrestricted data. Further, any computing devices and media have the potential of being lostor stolen if sufficient physical security is not provided for them. Resource Proprietorsand Custodians of restricted information should consider the following priority list whenselecting 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 theencryption of mobile devices and media. As of this writing, system-wide contracts arebeing completed with two vendors of products that address the technical infrastructure. EncryptionGuidelines-2006-04-20.odt Page 7 8. 3.2File EncryptionIt is often necessary to encrypt individual files. This is usually done to facilitate securetransport of those files. As discussed in Section 4.2, File Transfers, this allows for securetransport over a network without transmission encryption. It also allows secure transportof files on off-line storage devices, such as a CD-ROMs or thumb drives. Operational IssuesThe keys needed to decrypt the files must be sent to the recipient via some method otherthan how the file is transmitted to ensure that the encrypted files and the keys cannot beintercepted together. RecommendationsCampuses should promulgate recommended tool sets to facilitate file encryption. 3.3Database StorageEncryption of database storage is often needed for reasons similar to whole diskencryption. In fact, encryption of database storage can often be implemented through theuse of a whole disk encryption tool, but database server software may also provide thiscapability. A database server-based encryption solution is generally required toselectively encrypt specific tables or columns of a database and may also be required tosegregate access rights among multiple applications that utilize a single database server. Operational IssuesDatabase storage encryption does not imply that data in the database will be encryptedwhen it is transmitted over a network. In general, data is decrypted by the database serverbefore it is transmitted, so encryption for data transmission (see Section 4, Use ofEncryption for Data Transmission) should also be considered. An encrypted database reduces the risk of unauthorized disclosure of data when thedatabases disk media are disposed of. Depending on the sensitivity of the data, it maynot be necessary to contract for disk destruction services. The decision of whether to use whole disk or database server encryption is dependent ona number of factors, such as the existence of multiple applications, system administration,performance, cost, and backup requirements. 3.4Backup and ArchivingBackup and archival copies of restricted data are, themselves, restricted data. The mediaused for backup and archiving represent an opportunity for unauthorized access to data.Encryption can be used to protect that data. Operational IssuesWhen storage encryption has been implemented, backup strategies should be reevaluated.Depending on the specific storage encryption and backup solutions used, the backupsmay or may not be encrypted. EncryptionGuidelines-2006-04-20.odtPage 8 9. 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 thesensitivity of the data and the physical and technical protections in place, particularly ifthe 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 occurswhen a backup must be archived for a long period of time. The archived media will beunusable if the keys are not similarly (but separately) archived. RecommendationsBackup procedures should be assessed to ensure that backup copies of restricted data areappropriately protected, by physical and/or technical means, particularly when they aresent off-site.4Use 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.1Interactive SessionsRemote login sessions can represent a significant vulnerability to restricted data that istransmitted between the end-user and the server, particularly login passwords. Examplesof remote login solutions include telnet, ssh, tn3270, and remote control software forPCs. RecommendationsInteractive sessions that transmit restricted data should be encrypted. Note that loginpasswords should often be considered restricted, even when no other restricted data istransmitted. EncryptionGuidelines-2006-04-20.odt Page 9 10. 4.2File TransfersEncryption for file transfers can be accomplished in one of two ways: 1) encryption ofthe 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 IssuesThe 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 interoperableencryption solutions, files may be transferred without encryption to or from proxysystems that do support interoperable encryption and have a trusted systemadministration. That proxy system must be near enough to the real end-system (e.g., inthe same data center) that unauthorized observation of the file is very unlikely whenmoved between an end-system and its proxy. RecommendationsWhen 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 thedata they encrypt. 4.3Web-Based ApplicationsEncryption for communication of restricted data between users browsers and web-basedapplications and content is provided through the use of the HTTPS protocol, whichincorporates TLS/SSL. Operational IssuesUse of HTTPS requires installation of an X.509 digital certificate for the applicationsserver. Since these certificates expire after a specified period of time, a process must beimplemented to renew expiring certificates. If the Certificate Authority used to generate a server certificate is not configured in ausers browser, the user will receive an error message saying that the server certificate isnot valid. EncryptionGuidelines-2006-04-20.odt Page 10 11. Typically, information that is retrieved by a web browser is stored in a cache filedirectory on the browsers computer in an unencrypted form. This cache may beavailable to other people who access (or compromise) that computer. RecommendationsThe X.509 certificates installed on servers should be acquired from CertificateAuthorities 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 theCache-Control: no-cache HTTP header to limit caching by web browsers. Applicationdevelopers 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 touse web browsers that are shared with people who do not have the same level ofauthorization. 4.4Electronic MailElectronic mail messages are exposed to the possibility of unauthorized access at anumber of points: when it is being delivered across a networkwhen it is stored on a mail relaywhen it is in the senders or receivers message storewhen it is accessed across a network from the senders or receivers 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 thebody of the message itself, using either PKI or PGP for key management. S/MIME alsoenables the use of digital signatures to verify the authenticity of the sender and themessage. Unfortunately, it is not widely deployed, so it is really only of general utilitywithin 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 hasbeen stored for them on a secure web server. This also provides security, but requires theuse of a second, web-based mail system, as well as a strategy for sharing encryption keysin a secure manner. Operational IssuesUnfortunately, none of these solutions are widely deployed. It may be necessary toimplement multiple solutions for different segments of the community. The mostpragmatic approach at this point in time may be to put restricted data in an encrypted fileand attach the file to an otherwise unencrypted mail message. (See Section 3.2, FileEncryption.) This requires a strategy for sharing encryption keys in a secure manner.EncryptionGuidelines-2006-04-20.odt Page 11 12. RecommendationsCampuses should promulgate recommended tools for sending encrypted data throughelectronic mail. This is likely to include the tool set identified under File Encryption. 4.5Network Printer CommunicationWhen restricted data is output to a network-attached printer, there is a vulnerability ofunauthorized interception. When it is required to print restricted information, productssuch as JetDirect can be used to provide encryption. Alternatively, the printer can bedirectly attached to a server that utilizes a protocol, such as IPP, that can encrypt itsnetwork traffic. Operational IssuesThere may be a greater risk of people reading the printed material than intercepting thenetwork traffic when the destination printer does not have sufficient access controls,either by being in a secure facility or through some authentication mechanism providedby the printer. The University has a growing number of applications that requireemployees to print restricted information, such as personal health care information or payadvice stubs. Resource providers should consider printer security when this is the case. Many printers do not support encryption, and the cost and space requirements fordedicated print servers may be high. When restricted information must be printed,printers and associated encryption solutions must be selected to fit within the printinginfrastructure, as well as providing encryption. RecommendationsResource Custodians for departmental and campus print services should assess the secureprinting needs of their communities and provide solutions and education, as appropriate. 4.6Remote File ServicesRestricted information on file servers (e.g., servers that are mounted by clientworkstations to provide shared file directories) is vulnerable to unauthorized interceptionwhen that information is accessed over a network. Operational IssuesCommonly used file server protocols, such as Microsofts CIFS, do not supportencryption. The WebDAV protocol, which is supported uniformly on all popularoperating systems, can often be used as an alternative to provide encryption. RecommendationsResource Custodians for departmental and campus file services should assess the need toprotect restricted data on their servers and implement encrypted protocols (and provideuser education) as appropriate. EncryptionGuidelines-2006-04-20.odt Page 12 13. 4.7Database AccessCommunication between an application server and a database server over a network isvulnerable to unauthorized interception if encryption is not employed. Operational IssuesEncryption for communication with a database server is generally provided as part of, oran option to, the database server software. In many common scenarios, it may not be necessary to encrypt the communication with adatabase 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, thencommunication between the two is unlikely to be observed by unauthorized personnel,and encryption is probably not needed. A corollary to this is that encrypting databaseaccess 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 theapplication server and a users web browser. 4.8Application-to-Application CommunicationDirect communication between cooperating applications is becoming more common;Web Services rely on this capability. As always, this communication is vulnerable tounauthorized interception. Operational IssuesModern application-to-application communication protocols, such as SOAP, are based onweb protocols. When those protocols are used to transmit restricted data, HTTPS can beused to enable encryption. Because HTTPSs encryption is based on PKI, this also canguard against spoofing attacks by authenticating the applications to each other. Application protocols that are not web-based often have a proprietary encryption optionthat can be used. When this is not possible, the only alternative may be to implement aVirtual Private Network (see Section 4.9, Virtual Private Network (VPN).). RecommendationsUse SOAP with HTTPS or some other commonly-available encrypted protocol totransmit restricted data when possible. When not possible, restricted data should betransmission by means of a Virtual Private Network. EncryptionGuidelines-2006-04-20.odtPage 13 14. 4.9Virtual Private Network (VPN)A Virtual Private Network (VPN) may be an alternative solution to many communicationencryption problems, and it has the advantage that all network traffic can be encryptedwithin a VPN. Operational IssuesVPNs are commonly engineered to encrypt traffic between an enterprise network andlocations outside of that network, so traffic is often not encrypted within the enterprisenetwork. If all traffic to a specific server, say a file server, should be encrypted, carefulengineering of the VPN will be required. In general, all members of a VPN will have equal access to all other members. It isdifficult, for example, to use a VPN to ensure that the two computers exchanging data arethe 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 cancomplicate situations where, for example, a single PC must access multiple secureapplications provided by multiple organizations. RecommendationsVPNs should be used to protect restricted information when other alternatives are notfeasible. Campuses should assess the need for a VPN to encrypt traffic for devices in untrusted orhostile portions of the network, such as campus wireless networks or the rest of theInternet.5Application-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 forsoftware implementers to increase risk unintentionally through poor implementation. It is difficult to eliminate all untrusted infrastructure. In the end, it is likely that restrictedinformation 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.EncryptionGuidelines-2006-04-20.odtPage 14 15. 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.6Encryption 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.7Key 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-3s 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 whenaccess 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 orunavailability of cryptographic keys. The encryption key management plan must address handling the compromise orsuspected compromise of encryption keys. A contingency plan should address whatactions should be taken in the event of a compromise, such as with system software andhardware, cryptographic keys, or encrypted data. Encryption keys should be managed in a manner similar to passwords. For example, theyshould not be shared among multiple people, and they should be revoked when peopleleave the University. Users must be made aware of their unique role if they are given responsibility formaintaining control of cryptographic keys. EncryptionGuidelines-2006-04-20.odt Page 15 16. 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.8Other Uses for Encryption 8.1One-Way EncryptionOne-way encryption is a form of encryption that cannot be decrypted. It is typically usedfor passwords and other information that need only be verified, never retrieved. Note thatthe amount of data encrypted in this manner is often small, making this techniquesusceptible 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 valuegenerated a particular encrypted value. 8.2Digital SignaturesPublic key encryption can be used to verify the authenticity of documents or data, as wellas the author or source of those documents or data. Key management is very important inthis scenario, as unauthorized disclosure of a private key enables forgery that cannot bedetected.9International 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. EncryptionGuidelines-2006-04-20.odtPage 16 17. 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.Application Scenario Recommendations All Scenarios You dont need to protect data you dont have. Restricted data should be retained only when necessary. Resource Proprietors and Custodians should assess the sensitivity of the data they store or transmit. All copies of the data should be considered, including backup copies, shadow copies, and extractions used for analysis (e.g., spreadsheets) or software testing. When restricted data cannot be given an appropriate level of physical protection when it is stored or transmitted, it should be encrypted with an appropriate strength. For commonly-deployed encryption algorithms, this implies a key length of 128 bits to 256 bits. Restricted data cannot be protected with encryption while it is being processed. Other security measures must be employed to protect data while it is being processed. Whole Disk Encryption The priority for implementation of whole disk encryption should be 1) mobile devices and media, then 2) other devices and media for which appropriate physical security is not provided. Campuses should implement managerial and technical infrastructures to facilitate the encryption of mobile devices and media. File Encryption Campuses should promulgate recommended tool sets to facilitate file encryption. Backup and Archiving 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. Interactive Sessions Interactive sessions that transmit restricted data should be encrypted. Note that login passwords should often be considered to be restricted, even when no other restricted data is transmitted. File Transfers When encrypted files are transmitted, the keys should be transmitted via a method other than that used for the encrypted files themselves.EncryptionGuidelines-2006-04-20.odtPage 17 18. Application Scenario Recommendations Web-Based Applications 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 admonished not to use web browsers that are shared with people who do not have the same level of authorization. Electronic Mail Campuses should promulgate recommended tools for sending encrypted data through electronic mail. This is likely to include the tool set identified under File Encryption. Network Printer Resource Custodians for departmental and campus print Communication services should assess the secure printing needs of their communities and provide solutions and education, as appropriate. Remote File Services Resource Custodians for departmental and campus file service organizations should assess the need to protect restricted data on their servers and implement encrypted protocols (and provide user education) as appropriate. Application-to-Application Use SOAP with HTTPS or some other commonly-available Communication encrypted protocol to transmit restricted data when possible. When not possible, restricted data should be transmission by means of a Virtual Private Network. Virtual Private Network VPNs should be implemented to protect restricted (VPN) information when other methods 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. Application-Level Encryption 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. Encryption Strength Care must be taken to use an appropriately-strong algorithm. For commonly-deployed encryption algorithms, this implies a key length of 128 to 256 bits.EncryptionGuidelines-2006-04-20.odtPage 18 19. Application ScenarioRecommendations Key Management Campuses should implement key management services to ensure appropriate controls have been applied. EncryptionGuidelines-2006-04-20.odt Page 19 20. 11 Appendix: Encryption Technology The following table shows specific technology solutions that can provide encryption for the various application scenarios described in this document.Application Scenario Technology Solutions Whole Disk Encryption Pointsec and Credant were selected via RFP UCOPEMD2005-001. Information about those system- wide contracts is available from Information Resources and Communications at UCOP. File Encryption Well-tested encryption solutions, such as PGP, are available both as open source and commercial products. WinZip and other commonly-available file archiving utilities may also provide encryption, although they may not provide as high a level of protection as solutions whose primary purpose is encryption. Database Storage Database storage encryption solutions may be obtained from the database server software vendor or a third-party partner of that vendor. Backup and Archiving Backup and archiving solutions may be obtained from the software vendor or a third-party partner of that vendor. Interactive Sessions ssh provides strong encryption for interactive sessions with Unix and Linux systems. IBM mainframes running the z/OS and VM/ESA operating systems can encrypt TN3270 interactive sessions using TLS. Compatible client tools include Stunnel, Host on Demand, or any TN3270 emulator that supports TLS. File Transfers scp and sftp (both part of the ssh suite of tools) provide encrypted file transfer capability. As an alternative, PGP or some other file encryption tool can be used with ftp or any other unencrypted file transfer protocol. Web-Based Applications TLS/SSL is used to encrypt browser-to-application communication. Electronic Mail PostX, Tumbleweed, Voltage, and ZixCorp provide server- based electronic mail solutions. Most major electronic mail vendors support S/MIME and PGP as options to their products. As an alternative to encrypted electronic mail, tools such as PGP can be used to encrypt files that are then attached to unencrypted electronic mail.EncryptionGuidelines-2006-04-20.odt Page 20 21. Application ScenarioTechnology Solutions Network Printer Network printer encryption solutions may be obtained from Communication the printer vendor or a third-party partner of that vendor. Remote File Services Microsoft, Xythos, and most web servers provide WebDAV services. Database Access Database communication encryption solutions should be obtained from the database server software vendor or a third-party partner of that vendor. Application-to-Application TLS/SSL protocols are used to encrypt Web Services Communication communication using SOAP. Virtual Private Network Cisco and other networking vendors provide VPN solutions. (VPN) OpenVPN and other open source solutions can be used to implement VPNs. EncryptionGuidelines-2006-04-20.odtPage 21 22. 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: Jacqueline Craig, UC Office of the PresidentStephen Franklin, UC IrvineJon Good, UC Office of the PresidentKarl Heins, UC Office of the PresidentKatherine Kim, UC Office of the PresidentGeorge Lavender, UC BerkeleyRyan Means, UC BerkeleyRobert Ono, UC DavisTodd Wagner, UC BerkeleyDavid Walker, UC Office of the PresidentKen Wottge, UC San Diego Health Sciences EncryptionGuidelines-2006-04-20.odt Page 22