AS 2805.6.9:2022 – Electronic funds transfers – Requirements for interfaces Part 6.9: Key management — AES Session keys – Node-to-node.
Section 4 Key confirmation and session key changes
4.1 Initialisation
The initialisation is the process of establishing the initial keying relationship between nodes. The result of the initialisation process is the secure exchange of the KBPK’s for each node. In every node-to-node logical link, two KBPKs shall be exchanged. Each node shall generate a KHPK. Each KBPK generated shall be securely transported, authenticated and installed at the other end of the logical link as a KBPK. When installed, the KBPK key shall be securely stored and exported under the host key for host storage.
4.2 Key confirmation
Before the first transmission of session keys, a node may confirm the correct installation of its KBPK at the other end.
To accomplish this, Node A requesting confirmation shall generate a random value (RN). encipher it with the KBPKEAB and send to Node B (see Figure 4.1). Node B shall decrypt the random value using KBPKDAB to obtain RN. Each bit of the RN shall be inverted to form a random complement value, —RN. The resultant —RN is then enciphered using the Node B KBPKKBA and returning this to the requester, Node A. Receipt of the original random value correctly inverted confirms that the Node A KBPKAK was correctly installed as KBPKDAR at Node B, and provides the necessary proof of end point.
4.3 Changing session keys
4.3.1 General
The session key change procedure consists of an initiation phase, tollowed by the processing ol messages by node systems to generate and install new session keys.
The node Initiating the key change generates a set of random session keys (KS) (i.e. Node A sends KSXAB to Node B). It sends them to the recipient in key block format protected by keys derived from KBPKs following AS ISO 20038. These keys will replace the receive session keys for the remote recipient node.
A change of session keys in one direction does not require a modification of session keys in the other direction.
4.3.2 Session key change
The application entity of either node can initiate the key change procedure. Further transactions may be processed during the key change process, provided that the receiving node can unambiguously identify the key set being used for any message
4.3.3 Synchronisation of session key changes
The synchronisation of session key changes relates to activating a new set of session keys. Depending on network design, a node can receive financial transaction messages that have been processed under a previous set of session keys. This situation could arise in networks that do not guarantee the preservation of message order, Ic. messages may not be received by the receiving node In the same order that the sending node sent them.
In these circumstances, the messages shall contain addnlonal Information to Indicate to the receiving node which set of session keys to use.
4.3.4 Resynchronbsation
tinder some circumstances, such as corruption ol the key block protection key, it will not be possible to successfully complete the session key change procedure. To allow resynchronisation attempts using a different key block protection key, the node shall revert to the session keys that were current immediately before Initiation of the current key change procedure.
Either node shall not use this resynchronisation procedure to avoid the need to change session keys.
Section 5 Storage and transport of keys
5.1 General
The key block mechanism defined In this document ensures session keys are transported or stored, in a format that prevents manipulation.
The scheme defined in this document makes use of the notation where nodes are represented as capital characters A and B. represents a key, where x is the key purpose with y as the sending node and z as the receiving node.
The scheme restricts the purpose of the key, as per the key usage notation of AS ISO 20038 below:
(a) Encrypt: E
(b) Decrypt:D
(c) MAC Verify:V
(d) MAC Generate;G
The scheme defined in this document makes provision for the following session keys:
(I) Privacy (Data) key (KD)
(ii) MAC key (KMAC)
(iii) PIN key (KP)
NOTE For example, KDEAB would represent a data encryption key from Node A towards Node B and similarly KD0, indicates a data decryption key from Node B to Node A.
The sending node shall use a KBPK to protect the keys listed in items (i) to (iii) above when transmitting keys externally to a physically secure environment. The distribution of session keys is initiated by a sending node distributing Its send keys. Each node should determine the change frequency of session keys, see Figure 5.1 below.