4.2 Encryption Standard
4.2.1. Overview
See Purpose.
4.2.2. Purpose
The purpose of this standard 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. Additionally, this standard provides direction to ensure that Federal regulations are followed, and legal authority is granted for the dissemination and use of encryption technologies outside of the United States.
4.2.3. Scope
This standard applies to all Highline College employees and affiliates.
4.2.4. Standard
4.2.4.1 Algorithm Requirements
4.2.4.1.1 Ciphers
Ciphers in use must meet or exceed the set defined as “AES-compatible” or “partially AES-compatible” according to the IETF/IRTF Cipher Catalog, or the set defined for use in the United States National Institute of Standards and Technology (NIST) publication FIPS 140-2, or any superseding documents according to the date of implementation. The use of the Advanced Encryption Standard (AES) is strongly recommended for symmetric encryption.
4.2.4.1.2
Algorithms in use must meet the standards defined for use in NIST publication FIPS 140-2 or any superseding document, according to date of implementation. The use of the RSA and Elliptic Curve Cryptography (ECC) algorithms is strongly recommended for asymmetric encryption.
4.2.4.1.3 Signature Algorithms
Algorithm |
Key Length (min) |
Additional Comment |
| ECDSA | P-256 | Cisco Legal recommends RFC6090 compliance to avoid patent infringement. |
| RSA | 2048 | Must use a secure padding scheme. PKCS#7 padding scheme is recommended. Message hashing required. |
| LDWM | SHA256 | Refer to LDWM Hash-based Signatures Draft |
4.2.4.2 Hash Function Requirements
In general, Highline College adheres to the NIST Policy on Hash Functions.
4.2.4.3 Key Agreement and Authentication
4.2.4.3.1 Key exchanges must use one of the following cryptographic protocols: Diffie-Hellman, IKE, or Elliptic curve Diffie-Hellman (ECDH).
4.2.4.3.2 End points must be authenticated prior to the exchange or derivation of session keys.
4.2.4.3.3 Public keys used to establish trust must be authenticated prior to use. Examples of authentication include transmission via cryptographically signed message or manual verification of the public key hash.
4.2.4.3.4 All servers used for authentication (for example, RADIUS or TACACS) must have installed a valid certificate signed by a known trusted provider.
4.2.4.3.5 All servers and applications using SSL or TLS must have the certificates signed by a known, trusted provider.
4.2.4.4 Key Generation
4.2.4.4.1 Cryptographic keys must be generated and stored in a secure manner that prevents loss, theft, or compromise.
4.2.4.4.2 Key generation must be seeded from an industry standard random number generator (RNG). For examples, see NIST Annex C: Approved Random Number Generators for FIPS PUB 140-2.
4.2.5. Compliance
4.2.5.1 Compliance Measurement
ITS will verify compliance to this standard through various methods, including but not limited to, periodic walk-throughs, video monitoring, business tool reports, internal and external audits, and feedback to the standard owner.
4.2.5.2 Exceptions
Any exception to the standard must be approved by ITS in advance.
4.2.5.3 Non-Compliance
An employee found to have violated this standard may be subject to disciplinary action, up to and including termination of employment.
4.2.6. Related Standards, Policies, and Processes
National Institute of Standards and Technology (NIST) publication FIPS 140-2,
4.2.7. Revision History
| Date | By | Summary |