2 min read

ANSI X9.24-1-2017: The General Key Management Requirements

ANSI X9.24-1-2017: The General Key Management Requirements

The ANSI X9.24-1-2017 norm details how symmetric cryptographic keys should be managed and handled by the relevant actors of the retail financial services companies. Here we outline the general techniques and methodologies that are required or suggested by the standard.

Outlining the General Requirements

Deploying Centralized Key Management with CKMS symmetric asymmetric keysAs the name suggests, the General Key Management Requirements section in X9.24-1-2017 is an overview of the main requirements and describes a range of notions at a high-level.

The first notion introduced is split knowledge. This is a security technique that prevents a single individual, usually a crypto officer from knowing the complete value of a cryptographic key or a related passphrase.

With split knowledge, two or more people (crypto officers) must know parts and only parts of the key’s value.

Ideally, each part will have equal cryptographic strength and all the individuals must be present to create or re-create the cryptographic key (or passcode). Additionally, the standard requires dual control involving two entities (individuals and/or machines) who will cooperate to gain access to a control system. These techniques must be used when dealing with keys that are not encrypted.

ANSI X9.24-1-2017 also defines permissible key forms, which determine what key formats are acceptable in the context of symmetric cryptographic operations performed by the actors in retail financial services:

  • Stored in an SCD (Secure Cryptographic Device);
  • Encrypted and stored outside an SCD:

The ciphered key must, therefore, respect strict guidelines;

  • In cleartext and outside an SCD:

Dual control and split knowledge must be achieved.

The standard requires that all manual key operations (creation, destruction, etc.) are recorded so that such operations are tracked and logged, and that the individuals responsible for such operations are known. Note that there is no indication about the way such operations are to be stored, like in a database, on magnetic tapes, on paper, etc. 

Keys are not to be proliferated, and should only be found in the limited number of key locations, where they are needed. Simply put, retail financial organizations must not make inordinate backups and copies of keys that are not essential.

According to ANSI X9.24-1-2017, key strength must be a minimum of 2 x 56=112 bits, considering Triple-DES with double-length key as the minimum key strength. AES keys can be a minimum of 128 bits. Be aware that according to the norm, the key strength is defined as the minimal strength of the key AND all keys used to encrypt it. As an example, if an AES key K1 of length 256 bits is encrypted by a 112 bit 3-DES key K2, then the strength of K1 is defined as min( length(K1),length(K2)), that is to say 112 bits only.

Finally, the norm covers key usage and reminds us that keys must be used for one purpose only, such as keys that cipher other keys (KEKs) must not be used for something else, etc.

Comments on ANSI X9.24-1-2017

The general key management requirements section in ANSI X9.24-1-2017 are very high-level, whereas each security notion mentioned here are specified in further detail in the following sections of the standard. 

While they are mostly clear, some of the general key management requirements lack further specification and allow a wide range of interpretations such as this one:

 “Each person or group of persons responsible for injecting cleartext keys from one SCD to another SHALL have received adequate training and signed an acknowledgement of the responsibilities entrusted to them.“

What ANSI X9.24-1-2017 does not detail is what sort of ‘adequate’ training must be performed, what sort of documents shall be signed by the parties, and if these documents will have any legal binding, or only considered to be used privately. Therefore, it seems there is a great deal of latitude within this area.

Also, the split knowledge mechanism, except when an SCD is used, is not very detailed. Therefore, parties could use parts of different strengths and still respect the standards, leading to a possible weakness.

 

Read White Paper

 

References, Side Notes and Further Reading