home  
 
 
 
 
 
 

Spécifications techniques



Stratégie proposée pour le chiffrement des identifiants des clients (ajoutée le 2020-03-16)

Au sujet du présent document

1.1 Introduction

L’OCRCVM a modifié les Règles universelles d’intégrité du marché (RUIM) et les Règles des courtiers membres / Règles de l’OCRCVM afin que les identifiants des clients et certaines désignations soient dorénavant indiqués pour l’ensemble des ordres sur titres de capitaux propres envoyés à un marché et l’ensemble des opérations qui en résultent. Les identifiants des clients seront chiffrés par le courtier membre duquel proviennent les ordres afin que seule l’autorité de réglementation voie les identifiants (et non les marchés). Le présent document pourra servir de fondement aux discussions sur la méthode de chiffrement privilégiée et l’infrastructure connexe requise pour réussir sa mise en œuvre (présentation du texte chiffré sur le signal FIX, gestion des clés, etc.).

1.2 Public visé

Le présent document a été initialement rédigé pour le comité de mise en œuvre des identifiants des clients de l’OCRCVM, mais pourrait être utilisé plus tard par le personnel de la sécurité de l’information, des analyses opérationnelles, du perfectionnement et de l’assurance de la qualité qui joue un rôle dans la mise en œuvre du chiffrement des identifiants des clients.

 

Méthode de chiffrement proposée

2.1 Norme de chiffrement avancé (AES)

La norme de chiffrement avancé (AES) est une spécification de chiffrement de données électroniques qui a été établie par le National Institute of Standards and Technology des États-Unis (NIST). Cette norme est maintenant utilisée à l'échelle internationale, et elle a trait au seul chiffrement publiquement accessible approuvé par la National Security Agency (NSA). Elle a également été adoptée par les États-Unis à titre de norme du gouvernement fédéral en 2002.

La norme AES est un algorithme symétrique de chiffrement par bloc (c.-à-d. que la même clé est utilisée pour le chiffrement et le déchiffrement). La taille des clés peut faire 128, 192 ou 256 bits. L'OCRCVM propose d'utiliser des clés de 128 bits pour réduire au minimum l'impact sur le rendement du système tout en maintenant un degré de sécurité de l'information suffisant.

2.1.1 Mode d’opération – norme AES-mode CTR

Un mode d'opération est un algorithme utilisé conjointement avec un chiffrement par bloc pour améliorer la sécurité de l'information. Il existe une grande variété de modes qui comportent un éventail de garanties de sécurité et d'efficacité; l'OCRCVM propose d'utiliser le mode compteur (mode CTR) puisqu'il offre de nombreux avantages en matière d'efficacité par rapport à d'autres modes, sans toutefois affaiblir la sécurité (p. ex. il est hautement parallélisable et passe de manière sécuritaire d'un chiffrement par bloc à un chiffrement par flot – le remplissage n'est alors plus nécessaire). 

Le texte en clair est d'abord divisé en blocs que l'algorithme de base combine à un nombre aléatoire (ou un « vecteur d'initialisation ») – une valeur arbitraire impossible à prévoir générée de manière aléatoire ou pseudo-aléatoire – et à un compteur qui progresse à chaque bloc. Cette combinaison est ensuite chiffrée au moyen d'une clé, et un XOR est appliqué au résultat avec le texte en clair pour générer le texte chiffré. La figure 1 décrit le processus de manière simplifiée.

Image: Figure 1 : Chiffrement norme AES-mode CTR

2.2 Chiffrement des valeurs FIX

Les champs FIX pertinents devraient contenir une chaîne composée de trois éléments concaténés :

·        un code de 3 octets unique identifiant le courtier membre à l'origine du chiffrement;

·        un bloc compteur de 16 octets; 

·        la valeur chiffrée de 20 octets.

Les données binaires concaténées sont ensuite encodées au moyen de Base64 pour former une chaîne de 52 caractères attribués au champ FIX pertinent, comme le montre la figure 2 ci-dessous :

Image: Figure 2 : Structure de la valeur chiffrée

 

  • Le bloc compteur devrait être composé d’un nombre aléatoire de 64 bits (8 octets) concaténé à un bloc compteur initial de 64 bits (8 octets); le tout doit être stocké selon une architecture petit-boutiste;

  • Le bloc compteur initial peut être tout entier non signé de 8 octets;

  • Nous recommandons de générer le bloc compteur de manière aléatoire, de façon à ce qu’un bloc compteur unique et impossible à prévoir soit attribué à chaque ordre. Ainsi, le texte chiffré d’un LEI ne sera jamais le même puisque chaque combinaison d’une clé et d’un bloc compteur sera utilisée une seule fois;

  • Il n’est cependant pas obligatoire de générer le bloc compteur de façon aléatoire pour chaque ordre. On peut utiliser un seul bloc compteur pour chiffrer le LEI d’un client. Dans ce cas, le client doit comprendre que le LEI chiffré qui sera attribué à tous ses ordres et vu par les marchés sera formé de la même chaîne de caractères.

  • Le code du courtier à l’origine du chiffrement doit être ajouté au début du bloc compteur; il permet à l’OCRCVM de déterminer la clé de déchiffrement appropriée pour un LEI donné. Ce code sera attribué au moment de la diffusion des clés de chiffrement initiales;

  • Le code du courtier concaténé, le bloc compteur et le LEI chiffré du client constituent des données binaires arbitraires de 39 octets qui doivent ensuite être transformées en texte ASCII lisible de 52 caractères au moyen de l’encodage Base64;

  • Lorsqu’un participant exécutant reçoit un ordre d’un courtier membre non exécutant qui souhaite exécuter un ordre pour son client et que le LEI du client n’est pas chiffré, il doit se servir de sa propre clé de chiffrement pour chiffrer le LEI. Un participant exécutant peut déterminer si un LEI est chiffré ou non (et, par conséquent, s’il doit utiliser sa propre clé de chiffrement ou non) en examinant la longueur du champ LEI dans le message transmis par le courtier membre non exécutant. Ainsi, si le champ contient plus de 20 caractères (20 caractères étant la longueur d’un LEI non chiffré), le participant peut présumer que le LEI a déjà été chiffré par le courtier membre non exécutant.

2.3 Gestion des clés

 

Une clé de chiffrement différente sera remise à chaque courtier membre duquel proviennent les ordres. Les clés seront distribuées par l’intermédiaire du serveur EFT (transfert optimisé de fichiers) Globalscape de l’OCRCVM. (Globalscape offre des services de sécurité à l’échelle de l’entreprise et est déjà utilisé par les courtiers membres de l’OCRCVM pour la présentation de leurs opérations sur titres de créance et de pension sur titres.) Les clés seront actualisées tous les 12 mois. L’OCRCVM générera et distribuera les clés une fois par année (plutôt que de distribuer en même temps des clés valides pour plusieurs années). Nous croyons que cette approche réduira au minimum l’incertitude potentielle à propos du moment de l’actualisation des clés, de leur utilisation, etc.

Le calendrier de rotation des clés proposé fonctionnera comme l’illustre la figure 3 :

Image: Figure 3 : Calendrier de rotation des clés

1.      Deux mois avant l'expiration de la clé, l'OCRCVM en générera une nouvelle.

2.      La nouvelle clé, accompagnée de sa date d'activation et de la date d'expiration de la clé existante, sera déposée dans le compte Globalscape correspondant du courtier membre.

3.      Le courtier membre sera avisé par courriel que sa nouvelle clé est prête à être téléchargée.

4.      Une fois que le courtier membre a téléchargé la nouvelle clé, l'OCRCVM s'attend à ce qu'il effectue toutes ses opérations en :

          a)     continuant d'utiliser la clé existante jusqu'à ce qu'elle expire;

          b)     commençant à utiliser la nouvelle clé dès qu'elle est activée.

5.      Si le courtier membre omet de télécharger la nouvelle clé dans la semaine suivant l'avis, un courriel de rappel lui sera envoyé. Par la suite, il recevra un rappel chaque semaine s'il ne procède pas au téléchargement.  

6.      Si le courtier membre omet de télécharger la nouvelle clé après que l'ancienne clé a expiré, l'OCRCVM continuera d'utiliser temporairement l'ancienne clé de déchiffrement jusqu'à ce que le courtier membre lui confirme qu'il a reçu la nouvelle.

 

arrowHaut de la page

 

Historique des versions de la stratégie proposée pour le chiffrement des identifiants des clients.

Stratégie proposée pour le chiffrement des identifiants des clients v.1.6.1 (ajoutée le 2020-03-16)

 

arrowHaut de la page

 

Spécifications du protocole FIX

Spécifications du protocole FIX (modifiée le 04/01/2020)

 

arrowHaut de la page