Body
University Standard
Title
University of North Carolina at Chapel Hill Standard on Encryption Key Management
Introduction
Purpose
Encryption forms the basis of many information security tools and practices. Encryption only works to keep data safe if the keys to that encryption are secured properly. Data exposure is often caused by mistakes in selecting keys, the encryption/decryption process, or key management.
This Standard outlines requirements for key generation, distribution, storage, access, and destruction, and provides direction for managing the entire key lifecycle. Using encryption keys puts them at risk, so this document outlines security standards and practices for each stage of key handling.
Scope
Applies to all Responsible Persons and University of North Carolina at Chapel Hill ("UNC-Chapel Hill" or "University") IT with encryption requirements under the Information Security Controls Standard (MSS). Applies to anyone with access to encryption keys or related secrets covered under this Standard. (Note: API keys, passwords, and other authentication methods covered by the Standard on Passwords, Pass-phrases, and Other Authentication Methods are not in scope.)
Standard
Every Responsible Person whose University IT is required to use encryption under the MSS must adhere to these requirements for generating, securing, accessing, and retiring keys and related secrets. Transmission of encryption keys (keys are Tier 3 data requiring at least High obligation protections plus any external obligations applicable) must follow the Transmission of Sensitive Information Standard. There are two types of keys, symmetric keys that rely on a shared secret and asymmetric keys that consist of private and public components.
Generating Keys
To successfully perform the following requirements through the lifecycle of the key, planning for key retention and change through staff turnover is essential. Use NIST-approved security functions/algorithms outlined in the current version of NIST SP 800-131 (currently Ar3). Each key must be used for only one purpose (e.g., encryption, data integrity authentication, or digital signatures) to limit damage done if compromised. Generate new keys for additional uses.
- To ensure good cryptographic randomness, generate encryption keys on a system that has not been rebooted or powered off in the last day or use a security chip. A high protection key should be created only on a system with a high protection level. When transmission of a private key is required, follow the Transmission of Sensitive Information Standard.
- Private keys must not be reused for other purposes.
- Key-encrypting keys must be at least as strong as the data encrypting keys they protect.
- If using a hash to produce a key, use a current hashing algorithm (such as SHA-2-256 or SHA-3-256).
- Annually, check tools and processes to produce new keys to ensure that new keys are produced under then-current methods.
- Replace a key if it has been exposed, or if anyone with access to the key has left their role at the University but would have continued access to use the key.
See Encryption Methods below for appropriate standards of encryption.
Securing Keys at Rest
Encryption keys are Tier 3 data and must be protected at a High obligation level at rest. If the key applies to a system with additional external obligations, those also apply to the key. You must take appropriate measures to ensure that data encrypted at rest remains accessible. Examples might include: copying a key to a physical or electronic vault; ensuring that more than one person has access to the data and key (i.e., setting up multiple authorized users).
- Never store keys in insecure places (e.g., Word documents, source code, Gitlab/Github). Instead, use secure and encrypted methods, tools, and locations including:
- Dedicated key or “secrets” management tools with a University agreement in place (such as an Enterprise version of a common password vault);
- An encrypted key store or otherwise encrypted form (such as a purpose-built Azure function cloud service specifically designed to manage, store, and rotate secrets);
- Hardware security tokens; and/or
- Browser password vault, unless synced with personal accounts (local browser vault on UNC-Chapel Hill IT device or synced with a UNC-Chapel Hill account).
- Password management systems.
- Cryptographic hardware designed for the purpose.
- Privileged Access Management (PAM) systems.
- Physical safes within locked rooms.
- Limit access to keys only to essential people. Quickly remove access to key vaults when authorized people leave the University or their role.
- Manage key access for continuity of access in urgent situations.
- Encryption keys must be stored separately from systems they protect.
- Encryption keys for backups must be stored separately from the systems they protect, from the backups themselves, and must be available for restoration.
- Offline copies (properly stored) are a good approach to ensure separation, security, reliability, and availability.
- Keys protected by a passphrase must follow the Standard on Passwords, Pass-phrases, and Other Authentication Methods. Use Onyen (With Multi-factor Authentication (MFA) if possible) or other strong credentials to open a key vault.
- Log key access for keys protecting Tier 3 data per the MSS. Maintain audit logs as required by the MSS.
Accessing Keys
Responsible Persons must have auditable procedures in place to provide access to private keys for Moderate or High Obligation systems in the event of an emergency and/or the passphrase holder being unavailable.
Retiring Keys
Follow University protocols and security controls appropriate for destruction of Tier 3 information when retiring an encryption key. If a key is compromised, immediately report that event under the Information Security Incident Management Standard. Take no further action until in communication with an Incident Handler. Consult the Incident Handler if the key was compromised; they may direct you to change that key.
Encryption Methods
Use current NIST-approved encryption services, standards, and methods appropriate to the use, in compliance with NIST SP 800-131. For example:
- Symmetric Algorithms such as AES (Advanced Encryption Standard) (128, 192, or 256 bit);
- Public Key Asymmetric Algorithms such as RSA (Rivest–Shamir–Adleman) 4096 bit, ECC (Elliptic Curve Cryptography) 384 bit;
- Digital Signature Algorithms such as RSA 4096 bit using SHA2-256 (Secure Hash Algorithm); and
- Quantum-resistant algorithms such as ML-KEM-512 or X25519MLKEM768 (Module-Lattice-Based Key-Encapsulation Mechanism).
Plan for cryptographic agility to facilitate transitions to quantum-resistant algorithms where needed.
If you are unsure whether a method you intend to use is acceptable, consult with your unit's Delegated Security Authority (DSA), who can get confirmation from the Information Security Office (ISO).
Exceptions
For High or above, the DSA must document and submit the exception to the ISO following the Unit and ISO MSS Exception processes.
Other exceptions to this Standard may be authorized in writing by the CISO or according to an ISO exception process they designate.
Encryption keys and other secrets that protect a system do not increase the system's protection obligation level (e.g., secrets are High obligation, but the use of secrets does not increase a Low Obligation system to High obligation).
Definitions
Please refer to the Information Security Defined Terms Standard.
Related Requirements
External Regulations
University Policies, Standards, and Procedures
Contact Information
Primary Contact
Name: ITS Policy Office
Email: its_policy@unc.edu
Other Contacts
Subject: University Information Security Office
Online: help.unc.edu
Email: security@unc.edu
Publication Details
Issuing Officer: Paul Rivers, Chief Information Security Officer
Effective Date: June 18, 2026
Next Review Date: June 18, 2029