All staff who can work at home should continue to do so. Only with an explicit request from a supervisor should a staff member return to campus. For more information, review COVID-19 Workplace Guidance.
1607 PR.01 Endorsed Encryption Implementation Procedure
December 2, 2019
These encryption implementation procedures are designed to supplement the Yale University Policy 1607 Information Technology Appropriate Use Policy section 1607.2 F, which states:
“Encrypted material. Encrypted files, documents, and messages may be accessed by the University under the above guidelines. See 1607.1 - F, above.”
Users of Moderate Risk and High Risk data, as defined by Yale Policy 1604 Data Classification Policy, are required to encrypt files, documents, and messages for protection against inadvertent or unauthorized disclosure while in storage or in transit over data networks, while other users are encourage to use encryption where appropriate. The University makes available software and protocols endorsed by the Information Security Office (“ISO”) that provide robust encryption, as well as the capability for properly designated University officials to decrypt the information, when required and authorized under Policy 1607.
Users encrypting information are required to use only the endorsed software and protocols. Users who have encrypted Yale data using methods other than those endorsed by the University are expected to decrypt this data upon request by a university official. (See Policy 1607 Information Technology Appropriate Use Policy section 1607.2 Conditions of University Access.) A staff member may only encrypt with the permission of his or her supervisor.
These encryption implementation guidelines, including endorsed software and procedures, will be updated as technical solutions and University requirements change.
To support preservation of access to important data, the University has developed recommendations for data recovery (salvaging data stored on damaged media, such as magnetic disks and tapes) of encrypted persistent data (information that endures beyond a single instance of use). Business continuity in the event of a disaster, such as the endangerment of data access (loss of key personnel or passwords) for a University owned computing device is a serious concern, as is the concern that a Yale-owned computing device could use encryption to hide illegal activities.
The University has also established minimum standards for encryption to ensure that sensitive data is protected from disclosure, both when ‘in transit’ over computer networks and when stored on computing devices including servers, desktop machines and portable devices such as a PDA. The University is presently not concerned with maintaining a central data recovery decryption capability if it would prevent use of network privacy. Nor is the University planning to require the ability to decrypt traffic in transit over the campus network. The University understands that there are privacy concerns attached to these capabilities, as well as deployment problems.
It is also recognized that in the future federal or state law enforcement may ask for the capability to monitor and decode traffic in transit and that circumstances may lead the Yale University Information Security Office (“ISO”) to desire this same capability. However, the University currently believes that our capability to monitor encrypted network traffic at the endpoint(s) from system owners/administrators is the most reliable implementation. These system owners/administrators are required to cooperate with requests for decryption under the conditions specified in Yale University Policy 1607 Information Technology Appropriate Use Policy.
Information that is directly related to the business of Yale University (finance & administration, HR, student affairs, legal, primary source clinical and research data) should only be encrypted using a University approved method (e.g., PGP) which provides the ability for Yale to recover the data in the event of an emergency.
Only university-endorsed methods for encrypting data (email, files, documents, disks) may be used to encrypt Yale data. Yale is transitioning away from the PGP encryption standard in favor of newer, more integrated and more transparent encryption technologies. The following methods are the only endorsed methods of encryption at this time (e.g. TrueCrypt is not an endorsed encryption method due to weaknesses in the encryption method and issues with managing how this software encrypts devices and stores keys).
Microsoft BitLocker – the service must be configured to:
- Enabled enrollment through Active Directory group policy.
- Encrypt data using the BitLocker service native to Windows 7 and later.
- Escrow keys using Yale’s automated process(es).
Apple FileVault 2 – the service must be configured to:
- Encrypt data using a key provided by Yale.
- Encrypt data using the FileVault interface native to Mac OS X 10.7 and later.
Imation IronKey – the device must be:
- A device from Imation’s commercial (not consumer) line of products.
- A model that allows for central management of the device.
- Properly enrolled in Yale’s IronKey management service by an IT professional.
[Depricated] PGP (Pretty Good Privacy) – data should be:
- Encrypted using PGP software (version 6.0 or later) using the default CAST cipher (cipher text is unreadable until it has been converted into plain text, decrypted, with a key).
- Encrypted to the Yale ITS ADK (Additional Decryption Key) associated with the name email@example.com(fingerprint EE59 62A3 2193 6F7E 63D1 ECBC A42D 1AFE CBE3 F022) in addition to the other public keys to which the data is being encrypted. (ADK was added to the PGP software, so that government or other third parties like the University, could have a back door to PGP encrypted data)
- Encrypted only to public PGP 5/6 (Diffie-Hellman, not RSA) keys which have been stored on the Yale PGP Key servers (the LDAP and secure LDAP – LDAPS – servers) and are “signed” by the Yale ITS Certificate Authority Signing Key (KeyID # 0x102F1F65, fingerprint B876 3F26 CABA F0B5 B3DD 7679 8DF5 44F1 102F 1F65).
- Both the Yale ITS ADK and Certificate Authority Signing Key public keys are available for download via LDAP and “Secure” LDAP via the Yale PGP Key servers available via the name “PGPKEYS.ITS.YALE.EDU” (ldap://pgpkeys.its.yale.edu/ (Link 1) and ldaps://pgpkeys.its.yale.edu/ (Link 2))
PGP software that implements the above policies is downloadable for use by Yale faculty, staff and students who must conduct secure business, research or clinical activity on behalf of the University. For more information see:
Secure Socket Layer-SSL (version 3) or Transport Layer Security -TLS protocol is recommended for transmission of Yale University data via the World Wide Web on either the local campus network or the Internet: http://its.yale.edu/secure-computing/safe-mobile-computing/secure-web-email-ssl-tls.
(other than encryption implementations described above)
1. Login and access to Yale University owned servers is endorsed for the following secure protocols:
- SSH 1 & 2
- Kerberized Telnet (Note: should be used in encryption AND authentication mode).
- Kerberized POP (Note: does not provide e-mail content nor traffic encryption)
- IMAP over SSL
- FTP over SSL
- SMTP over SSL
- NetMeeting (Link 3)
- pcAnywhere (versions 8x, 9x & 10.x)
- NT Terminal Server Client (Link 4)
- Citrix ICA
2. The University Audit department currently has a requirement for independent private encryption of audit information kept on auditor’s hard disks and servers.
3. HIPAA (Health Insurance Portability and Accountability Act) compliance: Yale University must adhere to requirements of the Federal government (e.g., HIPAA and Federal agencies), business partners, as well as those imposed by contractual relationships (CHIME, vendors, University consortia, etc.). If the data is primary source PHI-Protected Health Information for TPO (treatment/payment/operations) or primary source PHI for approved research or pre-research, the only allowable method for encryption is the Yale University implementations of PGP.
- February 23, 2000
- February 25, 2003
- August 17, 2010
- December 11, 2014 – Clarification of encryption standards.
- December 16, 2014