Information Security Policy Documentation

IMPLEMENTATION DETAILS

Policy: ISP-I7
Title: Cryptography Implementation
Status: Approved
1. Introduction
1.1. This document gives additional details about implementing the policies stated in
Cryptography Policy (ISP-S16). How use of encryption will be supported, facilities
available and some guidance for computer support staff is outlined below.
1.2. IT Services will work with departmental computing staff to assist members of the
University that have a requirement to use encryption in their work. An explanation of
where using cryptography is required, or may be appropriate, is given in “Cryptography
Policy (ISP-S16)”.
1.3. Specific details are to be made available, e.g. via the Web, of currently recommended
encryption solutions and whether they are supported by IT Services or within departments.
1.4. It will be practical for computing staff to support a limited range of encryption solutions.
However; other encryption solutions that meet all necessary requirements may be used.
1.5. The encryption technology to be used for a particular purpose must comply with
requirements of an external body where applicable, and at least be deemed suitable by
the University.
1.6. Minimum cryptography standards suitable for general University use, at the time of
writing, are outlined in this document. (This document should be revised periodically.)
2. Encryption of data in general
2.1. Where it is required to encrypt personal or sensitive data, encryption must be:
Either to the standard specified in an agreement between the University and an
external organisation relating to the data in question or,
Where another organisation has not specified any encryption requirements the
data must be secured to at least minimum University standards as specified below.
2.2. Before an agreement is made with an external organisation that specifies use of
encryption, it must be ascertained whether it is feasible to implement the encryption
standards demanded.
2.3. Advice and assistance in the use of encryption is offered by the IT Services
department. IT Services will support use of a limited range of encryption solutions that:
Equal or exceed the minimum standards indicated below and,
Where possible, equal or exceed typical requirements currently being specified for
handling data from external organisations.
2.4. To ensure that locally stored data can be recovered in the event of a computer
problem, such as a hard disk failure, it is vital that recoverable backups are maintained.
Use of encryption does affect the need for backups; if anything it makes them more
important because it is likely to remove the chance of recovering any data from a failed
system.

Cryptography Implementation (ISP-I7).docx Page 1 of 7

 2.5. Where encryption is used careful management of recovery keys and passwords is
essential, see also Management of encryption keys in Cryptography Policy (ISP-S16).
3. Encrypting email
3.1. Unless information sent by email is encrypted before sending, its confidentiality
should not be assumed. This applies to email either sent within the University or between
the University and another organisation. (The University email system may encrypt its
network communications with an email system at another site, provided the remote email
server is also configured to support encryption. Although this type of encryption reduces
opportunities for eavesdropping it does not guarantee that the content of an email
message could only be seen by the intended recipient.)
3.2. Whilst unencrypted (plain text) email messaging is adequate for general purpose
communications, there may be occasions where it is necessary or prudent to use
encryption. There may, for example, be a requirement to use encryption when
communicating by email with certain other organisations.
3.3. Where it is necessary to send encrypted information by email the current
recommendation is to send it as an encrypted attachment. The attached file should be first
encrypted using a suitable tool (see “Encrypting Microsoft Office documents” and
“Encrypting files and folders” below).
4. Encrypting Microsoft Office documents
4.1. The encryption option built into Office 2007 uses a strong algorithm, AES 128-bit, by
default. This is suitable for official University purposes; however, other organisations may
require use of even stronger algorithms when working with their data.
4.2. Encrypted files created using Office 2007 may be decrypted using Office 2003 using
the Office 2007 Compatibility Pack (which can be downloaded from Microsoft’s website).
4.3. Do not rely on the strength of the encryption features in Microsoft Office software
previous to Office 2007.
4.4. Brute force is currently considered the only way to break into encrypted Office 2007
documents. Therefore to ensure security, difficult to guess passwords must be used. Use
passwords that combine uppercase and lowercase letters, numbers, and symbols.
Passwords should be 8 or more characters in length. A pass phrase that uses 14 or more
characters is safer.
4.5. Neither IT Services nor Microsoft can recover encrypted Office 2007 documents or
forgotten passwords.
5. Encrypting files and folders
5.1. There may be a requirement to encrypt a single file or a collection of files and folders.
This may be useful where the encrypted data is to be sent as an email attachment, burnt
onto CD/DVD for posting etc.
5.2. 7-Zip is a free open source file compression and archiving program that features
optional password protection for the archive files that it creates (in 7z or ZIP formats).
When a password is set the data in the archive is encrypted using a strong algorithm
(AES-256). Provided strong passwords are used this software is suitable for encrypting
files and folders. (Note that 7-Zip does not encrypt data unless a password is specified
when creating an archive file.)
6. Encrypting whole disk drives

Cryptography Implementation (ISP-I7).docx Page 2 of 7

 6.1. “Whole disk encryption” will be the most satisfactory encryption solution for many
users of portable devices who regularly deal with personal data. (In some cases, use of
whole disk encryption may be stipulated by suppliers of the data being handled.)
6.2. Manually keeping track of whether there are unencrypted copies of sensitive files on a
system is prone to oversight. There is normally no need, however, for a user to explicitly
manage encryption of specific files and folders when they reside on an encrypted disk;
everything on the disk is always encrypted. However; it should be noted that file level
encryption may be needed, in addition to whole disk encryption, to secure documents
against access by other authorised users of the computer (particularly anyone with
administrator privilege).
6.3. Any new device purchased by the University that features a disk drive may sooner or
later be used to store confidential data. Where such purchases are being made, the
possible need to use whole disk encryption should therefore be carefully considered.
Whole disk encryption can be achieved using hardware or software based solutions.
6.4. Existing disk drives in certain devices, including Windows laptops and some PDAs,
may be protected by installing whole disk encryption software. Encryption software is
installed after the operating system, and can be installed to a system that has already
been in use with applications and data.
6.5. Beware that when using whole disk encryption solutions, data copied to local media
such as CD may not be encrypted – see also “Encrypted USB drives DVDs/CDs etc.”
below.
6.6. Disk drives with built-in encryption
Internal and external hard drives incorporating encryption technology are now
available. These have the benefit of placing minimal processing load on the CPU
and do not require installation of separate encryption software.
Use of hard drives with built-in encryption is likely to become commonplace;
however, at the time of writing this document, few laptop suppliers offer supported
models incorporating internal hardware encrypted drives. Staff contemplating new
laptop purchases should, nevertheless, consider this option and if necessary
consult suppliers and computing staff for the latest advice.
Where a hardware encrypted drive is to be used to store personal or sensitive data
provided by another organisation, it should be established whether the encryption
provided meets the standards stipulated by that organisation.
6.7. Whole disk encryption software
Whole disk encryption software encrypts disk partitions. Solutions typically encrypt
the operating system drive and use “pre-boot authentication”, so completely
preventing unauthorised use of the computer, tampering or access to its data.
(Some solutions may also be able to encrypt other drives or create virtual
encrypted disks within files.)
IT Services will recommend a limited range of software whole disk encryption
packages for which it is able offer some support. Contact IT Services for the latest
information.
Vista Enterprise version operating system can be installed and configured to use
BitLocker encryption on the entire C: drive of a PC or laptop. This has some
impact on performance and it is preferable, though not essential, to have a PC
with a Trusted Platform Module (TPM) hardware chip, version 1.2 or better.
BitLocker has not yet been evaluated by IT Services and support may not be

Cryptography Implementation (ISP-I7).docx Page 3 of 7

 offered. (Since this option requires use of Vista and installing the operating system
from scratch it is anticipated that other more flexible software based whole disk
encryption solutions will be preferred.)
Where a software encrypted drive is to be used to store personal or sensitive data
provided by another organisation, it should be established whether the encryption
provided meets the standards stipulated by that organisation.
7. Encrypted USB drives DVDs/CDs etc.
7.1. Encryption of data on portable storage devices or media may be a requirement, where
it is the subject of an agreement, or may be highly advisable. Where such devices are to
contain confidential data an assessment must be made of the likelihood and implications
of the data being lost, stolen or accessed by the “wrong person”.
7.2. Options for encrypting data on portable storage devices include:
Using a device with built-in encryption. External hard drives and flash drives are
available with built in encryption. Access to such drives may typically be controlled
by one or two factor authentication (e.g. password and fingerprint). Contact IT
Services for the latest information about any recommendations in this area.
Encrypting files before they are copied or written to the device e.g. using a
program such as 7-Zip.
Using a software application installed on the local system that is designed to
encrypt data automatically as it is written to an external storage device. Suppliers
of whole disk encryption software typically also offer such software. Subject to
demand and satisfactory evaluation, IT Services may provide support for a limited
range of such software. Contact IT Services for the latest information.
8. Encrypted backups and archives
8.1. There must be an assessment of the need to encrypt backup or archive media. It
should take into account sensitivity or value of the data, and the physical and technical
protections in place. This is particularly important if the media is sent or held offsite.
8.2. If encrypted backups are created, key management is particularly important. It must
be possible for keys to be readily found in a disaster recovery situation.
8.3. Where encrypted media is archived the keys must also be separately and securely
archived to ensure that the media remains usable.
8.4. Beware that when using whole disk encryption solutions, data backed up to local
media or remote storage will not necessarily be encrypted – see also “Encrypted USB
drives DVDs/CDs etc.” above.
9. Encrypted databases
9.1. Where databases hold very sensitive information then an assessment should be
undertaken of the risk of unauthorised access to the data whilst in storage or in transit
between the database server and any applications which access the data. It may be that
additional encryption measures would be needed to secure the data in storage or network
transit.
10. Minimum cryptography requirements for University data
10.1. This section is primarily intended for computer support staff involved in selecting or
configuring encryption solutions. It gives a summary of cryptography standards
considered suitable for use in the University in situations where more specific

Cryptography Implementation (ISP-I7).docx Page 4 of 7

 requirements do not apply. (Acceptable standards may change over time and this
document should be periodically revised to take that into account.)
10.2. Symmetric ciphers with key lengths of at least 128 bits. (Symmetric ciphers use the
same key to encrypt and decrypt the data.) The following symmetric block ciphers, in
which a block of plain text is encrypted to produce a block of text the same length, are
suitable for University use:
AES (Advanced Encryption Standard). Key size of 128 bits or more should be
used. This is the preferred block cipher.
Triple-DES (or 3DES). Data is encrypted three times using three 64 bit keys.
Blowfish with at least 256 bit key size.
10.3. The following symmetric stream ciphers, in which a digital data stream is encrypted
one bit or byte at a time, are suitable for University use where a better alternative is
unavailable:
Rivest Cipher 4 (RC4) with key length at least 128 bits. Where poorly
implemented RC4 may be vulnerable to attack and it is recommended to migrate
to AES/3DES block ciphers if possible.
10.4. Asymmetric ciphers with strength considered comparable or better than a 128 bit key
symmetric cipher. (Asymmetric ciphers are used in public key cryptography. Two keys are
used: public and private. The private key is kept securely and the public key is published.)
RSA with 1024 bit composite modulus
10.5. Use of industry standard “key agreement” or “key exchange” methods. (In key
agreement two or more parties to agree upon the same key value to use without the need
for a previously-established shared secret. In key exchange the key to be exchanged is
encrypted with the recipient’s public key. The recipient can decode the exchanged key by
using their private key.) Suitable algorithms include:
Diffie-Hellman with 1024 bit prime and 160 bit generator - for key agreement
RSA with 1024 bit composite modulus - for key exchange
Elliptical Curve Diffie-Hellman (ECDH) - for key exchange
10.6. Use of industry standard digital signing. (A digital signature is a hash value
encrypted with the sender’s private key.) Suitable cryptographic primitives for use in digital
signing used by the University include:
DSS with 1024 bit prime and 160 bit long term private key
RSA with 1024 bit composite modulus
Elliptic Curve Digital Signature Algorithm (ECDSA)
10.7. Where University data is to be encrypted for network transmission, especially to
wrap any clear text protocol or service not encrypted by another method, the cryptography
requirements are:
SSLv3
TLSv1
SSH2
Kerberos
pcAnywhere

Cryptography Implementation (ISP-I7).docx Page 5 of 7

 PGP
Terminal Services
IPSec
10.8. Hashing algorithms take a variable length input and produce a fixed length output.
The output value is known as a “message digest” or “hash value”. Basic requirements of
hashing algorithms are:
The output of the algorithm must not be invertible i.e. the operation must be one-
way.
The algorithm must also be highly collision resistant, i.e. the chance that distinct
inputs will produce the same hash value must be extremely small.
10.9. Use of a one-way hash function to irreversibly encrypt data should be used for:
Authentication information e.g. passwords.
Integrity checksums e.g. as a tamper-evident seal for a file.
Digital signatures (used with asymmetric algorithms).
10.10. These cryptographic hashing algorithms are suitable for use by the University:
SHA-256
SHA-512
Whirlpool
RIPEMD-160
10.11. Use of the following cryptographic hashing algorithms is not recommended. These
should be phased out in due course because of proven vulnerability to collision attacks:
SHA-1
MD5
10.12. (H)MAC – (Hashed) Message Authentication Code is used to provide a means of
data integrity and origin authentication. A secret key shared between the sender and
recipient is concatenated with the message and the result is put through a hashing
algorithm (possibly one of those mentioned above). It is possible for the recipient to be
sure where the message came from and that it has not been intercepted and modified.
HMAC is utilised within various cryptographic protocols including TLS and IPsec. The
following documents are considered to describe suitable HMAC implementations and
standards:
HMAC FIPS 198
HMAC RFC 2104

Failure to comply with University Policy may lead to disciplinary action.

Cryptography Implementation (ISP-I7).docx Page 6 of 7

Document history:

18 June 2008 (C. Nelson) Began first draft.

5 November 2008 (G. Hamp) Minor changes made.

9 December 2008 (C. Nelson) Revised following feedback from the Steering Group.

23 January 2009 (C. Nelson) Revised based on input from the Steering Group.

29 January 2010 (C. Nelson) Removed reference to Outlook email signing and
encryption support by IT Services.

18 May 2011 (C. Nelson) Revisions resulting from review within IT Services.

The official version of this document will be maintained on-line. Before referring to any
printed copies please ensure that they are up-to-date.

Cryptography Implementation (ISP-I7).docx Page 7 of 7