home home  
 
 
 
 
 
 

Technical Specifications



Proposed Strategy for Encryption of Client Identifiers

  1. About this Document

    1.1 Introduction

    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.

  2. Image: Figure 1: AES-CTR Encryption

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

    2.1.2 Authentication

    Many sources note the importance of implementing AES-CTR in conjunction with an authentication function such as HMAC-SHA-1-96; whether such a precaution is required for IIROC’s purposes has yet to be determined.

    Image: Figure 2: Encrypted Value Structure

    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, the 16-byte counter block and the encrypted value; an example of this structure is illustrated in Figure 2.

    • The encrypting dealer ID 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 counter block should be comprised of a 64-bit nonce concatenated with a 64-bit initial counter value; 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. Both the counter block and ciphertext should be restricted to printable UTF-8 characters.

    • 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 and refreshed every 12 months. (Globalscape offers enterprise-level security and is already used by IIROC Dealer Members for the submission of their debt and repo trades.)

    It is anticipated that a strict key rotation schedule will need to be devised to ensure that Dealer Members refresh their encryption key on the prescribed date; this schedule will need to incorporate:

    • Communicating to each Dealer Member that a new key is available

    • Communicating to each Dealer Member the first date on which the new key should be used

    • Receiving confirmation from each Dealer Member that the new key has been collected

    • Sufficient time for resolving collection problems, and reminding Dealer Members who have failed to collect the new key

 

arrowback to top

 

Fix Specifications

Content coming soon.

 

arrowback to top