About this Document
IIROC has proposed amendments to the Universal Market Integrity Rules (UMIR) which require client identifiers and/or certain designations to be included on all orders and trades for an equity security sent to a marketplace. The client identifiers will be encrypted by the originating Dealer Member such that they are visible by the regulator and not the marketplaces. This document attempts to provide a basis for discussion regarding the preferred method of encryption and the attendant infrastructure required for its successful implementation (representation of the ciphertext on the FIX feed, key management, etc.)
1.2 Intended Audience
This document was initially written for the benefit of IIROC Client Identifiers Implementation Committee, but could be expanded at a later date for use by information security, business analysis, development and quality assurance staff involved in the implementation of client identifier encryption.
Proposed Method of Encryption (amended on December 6, 2019)
2.1 Advanced Encryption Standard
The Advanced Encryption Standard (AES) is a specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology (NIST). Now used internationally, it is the only publicly accessible cipher approved by the National Security Agency (NSA) and was adopted by the U.S. as a federal government standard in 2002.
The AES describes a ‘block cipher’ and is a symmetric-key algorithm (i.e. the same key is used for both encryption and decryption); key size may be 128, 192 or 256 bits. IIROC proposes using 128-bit keys to minimize impact to system performance while maintaining a sufficient level of information security.
2.1.1 Mode of Operation – AES-CTR
A mode of operation is an algorithm used in conjunction with a block cipher to enhance information security. There exists a wide range of modes that encompass varying guarantees of security and efficiency; IIROC proposes using the Counter (CTR) mode since it offers a number of efficiency advantages over other modes without weakening security (e.g. it is highly parallelizable, and securely transforms of a block cipher into a stream cipher (thereby removing the need for block padding)).
With the plaintext having been divided into blocks, the basic algorithm combines a ‘nonce’ (or ‘initialization vector’) – an arbitrary, unpredictable value such as a random or pseudo-random number – with a counter that increments with each block; this combination is then encrypted using the key and the result is XOR’d with the plaintext to generate the ciphertext. A simplified description of the process is illustrated in "Figure 1".
2.2 Encryption of FIX Values
The relevant FIX tags should be populated with a string comprised of three concatenated elements:
a 3-byte zero-padded number identifying the encrypting Dealer Member
a 16-byte counter block and
a 20-byte encrypted value;
The concatenated binary data will be then encoded with Base64 to a 52-character string value assigned to the relevant FIX tag as the figure 2 illustrated below:
The counter block should be comprised of a 64-bit (8-byte) nonce concatenated with a 64-bit (8-byte) initial counter value; both shall be stored in Little Endian order.
It is expected that, in accordance with recommended practice, a unique and unpredictable nonce will be provided on each order message – this will ensure that the ciphertext of an LEI is never repeated since a key-counter block pair is used only once.
The initial counter value can be any 8-byte unsigned integer.
The encrypting dealer ID shall be added to the beginning of the counter block; it is required for IIROC to identify the appropriate key for decryption of a given LEI; this ID will be assigned when the initial encryption keys are disseminated.
The concatenated dealer ID, counter block and encrypted client LEI is a 39-byte arbitrary binary data which shall be turn into a readable 52-character ASCII text using Base64 encoding.
Where an executing Participant receives an order from a non-executing Dealer Member that is trading for its client and the client LEI is not encrypted, the executing Participant will use its own encryption key to encrypt the non-executing Dealer Member’s client’s LEI. An executing Participant can identify whether or not an LEI is encrypted (and therefore whether or not to initiate its own encryption) by examining the length of the LEI field in the message transmitted by the non-executing Dealer Member: if the field’s value is longer than 20 characters (the length of an unencrypted LEI), the LEI can be assumed to have been already encrypted by the non-executing Dealer Member.
2.3 Key Management
A different encryption key will be provided to each originating Dealer Member. The key will be disseminated via IIROC’s Globalscape EFT (Enhanced File Transfer) server. (Globalscape offers enterprise-level security and is already used by IIROC Dealer Members for the submission of their debt and repo trades.) Keys will be refreshed every 12 months; IIROC will generate and disseminate keys on an annual basis (as opposed to disseminating multiple years’ keys at once) – it is believed that this approach will minimize potential uncertainty around when to refresh keys, which keys should be used etc.
The proposed key rotation schedule will operate as Figure 3 illustrates:
Two months before the current key expires, IIROC will generate a new key
The new key will be deposited in the corresponding Dealer Member’s Globalscape account
An e-mail will be sent notifying the Dealer Member that a new key is available, quoting the first date on which IIROC expects the key to be used for LEI encryption
IIROC expects to receive prompt formal acknowledgement from the Dealer Member of the key and the date of its introduction
If the Dealer Member fails to download the new key within a week of notification, a reminder e-mail will be sent; further reminders will be sent for each subsequent week the Dealer Member fails to download the new key
In the event a Dealer Member fails to download the new key before the first date of expected use, IIROC will on a temporary basis, continue to use the old key for decryption until receipt of the new key has been acknowledged by the Dealer Member.
back to top
Historical versions of Proposed Strategy for Encryption of Client Identifiers
Encryption Proposal v.1.4 (added on 12/06/2019)
back to top
Fix Specifications (added on 12/05/2019)
back to top