Cryptography control procedure

Contents

Policy statement

This control procedure defines the University’s approach to communications security, and directly supports the following policy statement from the Information Security Policy: “The University will provide guidance and tools to ensure proper and effective use of cryptography to protect the confidentiality, authenticity and integrity of information and systems.”

Audience

This procedure is intended to be read and understood by any users accessing the University’s information, IT systems, networks or software using any University or personally owned device, where there is a need to apply additional controls to protect data at rest or data in transit.

Control statements

The purpose of this policy is to provide guidance:

  • that limits the use of encryption to those algorithms that have received substantial public review and have been proven to work effectively
  • to protect cryptographic keys against modification and loss, unauthorised use or disclosure
  • to detail the specification and deployment of data encryption software for the protection of electronic information held by the University
  1. Requirements
  2. Key generation
  3. Client device encryption
  4. Database encryption
  5. Transferring data
  6. Remote network access

1. Symmetric encryption

  • AES256 or higher must be used
  • AES128 permissible only in cases where technical constraints exist
  • Other algorithms must not be used
Asymmetric encryption
  • RSA with a minimum key length of 3072 must be used
  • The DH key exchange protocol should be used where appropriate for key exchange and must use a minimum key size of 2048
  • Private keys must be subject to periodic review to identify compromise
  • Other asymmetric encryption must not be used
Hash functions
  • SHA-2 with a digest value of 256 or higher should be used
  • SHA-3 may be used in place of SHA-2
  • MD5, SHA-1 must not be used without a formal exception agreed by the Information Security team 
  • Other algorithms not listed must not be used
  • Cryptographic salt should be used in combination with all implementations of hash functions except for file validation
Cipher suites for SSL/TLS
  • EECDH+AESGCM
  • EDH+AESGCM
  • AES256+EECDH
  • AES256+EDH
  • TLS v1.1 must not be used without a formal exception agreed with the Information Security team
  • TLS v1.2 Accepted
  • TLS v1.3 Preferred
  • Other cipher suites must be disabled

2. Key generation

Cryptographic keys must be generated and stored in a secure manner that prevents loss, theft, or compromise. Keys need to be communicated by reliable and secure methods and kept confidential.

Key generation must be seeded from an industry standard random number generator (RNG).

Where user-generated passwords are required to decrypt data – either as the key or as input to a key derivation function – these should follow the University’s Control Procedure for Password Management. Local procedures must be put in place to ensure that passwords used to encrypt devices are communicated to teams on a need-to-know basis, so that if an individual leaves the University access can still be gained to the University’s data.

3. Client device encryption

All University-managed computers require encryption for the protection of vulnerable and sensitive data. Computers running Microsoft Windows will use Bitlocker drive encryption. Access to the list of the keys in the Active Directory is restricted to the Server Management team. Computers running alternative operating systems will have native encryption enabled where available.

Mobile devices synchronising email with the University email system must be forced to use encryption by the Active Sync settings pushed to the device.

Devices not under University management should have encryption enabled where possible at the user’s discretion, but the University reserves the right to restrict devices from the network or defined network resources where they do not meet these and other security requirements.

4. Database encryption

University-managed databases will have transparent database encryption enabled by default unless an exception has been agreed with the Information Security team. As newer versions of database technology include more native encryption options, these should be enabled by default unless an exception has been agreed with the Information Security team.

5. Transferring data

Sensitive information shall only be removed from the University network with adequate protection, in line with the Information Classification Scheme. Tools for protecting information are offered by IT & Digital, including built-in encryption in Microsoft Office products, encrypted USB devices, and Criminal Justice Secure Mail (CJSM) for email encryption to secure government and public sector networks. Further information is available from IT & Digital.

6. Remote network access

Facilities for connection to the University’s IT systems and services via networks not fully within the control of the organisation’s security management (such as the internet or wireless access) will be secured according to the standards in this procedure.

Compliance

Failure to comply with this procedure could result in action in line with the University’s disciplinary procedure or performance improvement procedure.

Compliance checks will be undertaken by the University’s information governance functions. The results of compliance checks, their risk assessment and their remediation will be managed by the Information Governance Board.

Related documents

This control procedure needs to be understood in the context of the other policies and procedures constituting the University’s Information Security Management System.

Browse Information Security policies and control procedures

Review

A review of this policy will be undertaken by the Information Security team annually or more frequently as required, and will be approved by the Information Governance Board.

  • Version: 4.4
  • Release date: 22/10/2024
  • Review date: 22/09/2025