Cryptographic Controls

Introduction

This document defines standards for the implementation and use of Encryption technologies within UBC to maintain the confidentiality and integrity of UBC Electronic Information. For additional requirements, including where Encryption is required, see the Encryption Requirements standard.
Cryptographic controls provide an enhanced level of protection for UBC Electronic Information in the event of theft, loss or interception by rendering information unreadable by unauthorized individuals. Unless otherwise stated, University IT Support Staff are responsible for ensuring compliance with this standard.
The Chief Information Officer has issued this standard under the authority of Policy SC14, Acceptable Use and Security of UBC Electronic Information and Systems. Questions about this standard may be referred to information.security@ubc.ca.

Cryptographic Requirements

Encryption usage must be risk based and must take into account the sensitivity of information as per the Encryption Requirements standard.
Encryption strength must be AES-128 bit or equivalent, at a minimum; AES-256 bit or better Encryption is preferred as it provides greater protection.
Cryptographic hash ciphers must be strong: SHA256, SHA512, RipeMD-160, WHIRLPOOL or equivalent, and weak cryptographic hash ciphers must be disabled.
Whenever a password or passphrase is used as an Encryption Key (“Key”), it must follow the standards defined in the Passphrase and Password Protection standard, which details strong password/passphrase construction. Keys that are compromised (e.g. lost or stolen) must be reported immediately in accordance with the Reporting Cybersecurity Incidents standard. The Key must be revoked or destroyed and a new Key generated. Key re-assignments require re-encryption of the data.
Digital signatures should be supported by certificates issued by a trusted third-party Certificate Authority (CA); if the signatures are intended for legal signing then they must be supported third party CA certificates. The minimum acceptable hash algorithm is SHA2; SHA0 and SHA1 cannot be used as they are insecure.
The following requirements apply to X.509 certificates:
1. X.509 certificates used for the securing of Medium, High or Very High Risk Information during User transmission must be issued by a trusted third-party CA, as part of a Public-Key Infrastructure (PKI);
2. server-to-server transmissions should be encrypted and should use a trusted third-party certificate;
3. newly purchased or renewed X.509 certificates must be a minimum of 2048-bits; and
4. X.509 certificates may be purchased under the University’s Enterprise account, via security@ubc.ca.

Storage Encryption Risk and Classification Model

Storage Encryption is intended to mitigate the following unauthorized access risks:
1. Access Due to Physical Theft: unauthorized access to data on stolen Devices;
2. Filesystem Access: unauthorized access to data on mounted filesystems such as exploited servers and insider threats (including service providers);
3. File Access: unauthorized access to data in files, offline database (DB) files, backups and copies of files, both at rest and in transit; and
4. DB Data Access: unauthorized access to data in DBs that are online via DB connections, including, but not limited to, exploited applications.

3.2 Storage Encryption types are classified into tiers which mitigate the risks outlined in section 3.1 as follows:

§	Encryption Tier	Access Due to Physical Theft^[1]	Filesystem Access	File Access	DB Data Access
		Unauthorized Access Risk Mitigation
3.2.1	Tier 0 Encryption - no Encryption	No	No	No	No
3.2.2	Tier 1 Encryption - full disk, device-level and media-level Encryption	Yes	No	No	No
3.2.3	Tier 2 Encryption - full volume Encryption^[2]	Yes	No	No	No
3.2.4	Tier 3 Encryption - file-level Encryption or transparent database engine Encryption	Yes	Yes	Yes	No
3.2.5	Tier 3+ Encryption - application-level database Encryption^[3]	DB only	DB only	DB only	Yes

Key Management

For Encryption to be effective, Encryption Keys must be protected against unauthorized disclosure, misuse, alteration or loss. In order to reduce the risk of loss or exposure of Keys, all Key management processes should be performed with automated software.

A Key management plan must be in place that covers the following process areas:

§	Process Area	Process Description	Process Requirements
4.2.1	Key Generation	Secure creation of Keys (symmetric Encryption) or Key pairs (asymmetric Encryption).	Software-generated Keys must be used where technically possible and be created using cryptographically strong algorithms (see section 2, Cryptographic Requirements). Manually generated Keys must follow the standards defined in the Passphrase and Password Protection standard.
4.2.2	Key Distribution	Secure distribution of Keys using manual transport methods (e.g. file transfer, Key loaders), automated methods (e.g. Key transport and/or Key agreement protocols), or a combination thereof.	Keys must be encrypted when transmitted over communication lines. The exchange of Keys must employ Encryption using an algorithm that is at least as strong as the one that is used to encrypt the data protected by the Keys, and access must be strictly limited to those who have a need-to-know.
4.2.3	Key Storage and Protection	Protect all cryptographic Keys against modification, loss and destruction.	Keys and their associated software products must be securely maintained for the life of the archived data that was encrypted with that product. Keys must be protected using the same or superior level of security as the information that they are protecting, and access must be strictly limited to those who have a need-to-know. In public-private key Encryption, private Keys need protection against unauthorized disclosure. Keys must not be stored on the same storage media as the encrypted data. Equipment used to generate, store and archive Keys must be physically protected. To limit vendor access to UBC Electronic Information, Keys must be stored with UBC (and not the vendor) unless not technically possible.
4.2.4	Key Recovery	To prevent data loss, establish processes to ensure Keys can be recovered if they are forgotten.	Strategies must be implemented to enable Key recovery. See the Key Escrow guideline for additional information. The recovery process must be documented to ensure it will be effective when required.
4.2.5	Key Change	Revoke and publish new Keys when they are suspected of compromise or unauthorized disclosure, they reach the end of their lifetime, and/or the Key owner or delegated individual leaves the employ of UBC.	Key lifespan must be documented along with processes and rules for making changes to Keys. Clear authorization process for Key changes. Specific responses to suspected compromised Keys.

Additional Requirements for Merchant Systems

Users must not store authentication data collected in Merchant Systems after authorization (even if this data is encrypted). Authentication data includes:
1. the full contents of any track from the magnetic stripe or chip;
2. the card-verification code or value (three or four-digit number printed on the back/front of a payment card); and
3. the personal identifier number (PIN) or the encrypted PIN block.
Users must ensure that the credit card number is masked (the first six and last four digits are the maximum that can be displayed) whenever displayed (e.g. electronically, hard-copy, etc.).

Information Security Standard M7

Cryptographic Controls

Introduction

Cryptographic Requirements

Storage Encryption Risk and Classification Model

Key Management

Additional Requirements for Merchant Systems

Related Documents and Resources

CSS for Submitted By module

Custom CSS