home home  
 
 
 
 
 
 

Technical Specifications



Proposed Strategy for Encryption of Client Identifiers (amended on March 16, 2020)

  1. About this Document

    1.1 Introduction

    IIROC has amended the Universal Market Integrity Rules (UMIR) and Dealer Member Rules / IIROC Rules to require client identifiers and/or certain designations to be included on all orders and trades for an equity security sent to a marketplace. 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

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. 

Image: Figure 1: AES-CTR Encryption

2.2 Encryption of FIX Values

The relevant FIX tags should be populated with a string comprised of three concatenated elements:

    • a 3-byte unique dealer ID 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:

Image: Figure 2: Relevant FIX tag

  • 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.

  • The initial counter value can be any 8-byte unsigned integer.

  • We recommend randomizing the nonce and the initial counter value so that a unique and unpredictable counter block 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.

  • However this randomization of the nonce and the initial counter value is not mandatory on each order message, they can be a fixed value used to encrypt a client LEI as long as the client understands that its encrypted LEI as seen by the marketplaces will have the same string value across all order messages.

  • 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:

Image: Figure 3: key rotation schedule

1. Two months before the current key expires, IIROC will generate a new key.

2. The new key, along with the effective date of the new key and expiry date of the current key, will be deposited in the corresponding Dealer Member's Globalscape account.

3. An e-mail will be sent notifying the Dealer Member that a new key is available to download.

4. Once the new key is downloaded by Dealer Member, IIROC expects all trading by the Dealer Member must:

1.  continue to use the current key until it expires
     and
2.  use the new key starting on its effective date.

5. 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.  

6. In the event a Dealer Member fails to download the new key after the old key has expired, 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.


arrowback to top

 

Historical versions of Proposed Strategy for Encryption of Client Identifiers

Encryption Proposal v.1.6.1 (amended on 03/16/2020)

 

arrowback to top

 

Fix Specifications

Fix Specifications (amended on 04/01/2020)

 

arrowback to top