home  
 
 
 
 
 
 

Spécifications techniques



Stratégie proposée pour le chiffrement des identifiants des clients

  1. Au sujet du présent document

    1.1 Introduction

    L’OCRCVM a modifié les Règles universelles d’intégrité du marché (RUIM) afin que les identifiants des clients et certaines désignations soient dorénavant indiqués pour l’ensemble des ordres sur titres cotés 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.

  2. Image: Figure 1: Chiffrement norme AES-mode CTR

  3. 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 comme un numéro 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.

    2.1.2 Authentification

     

    De nombreuses sources ont noté l’importance de mettre en œuvre la norme AES-mode CTR conjointement avec une fonction d’authentification telle que HMAC-SHA-1-96. L’OCRCVM n’a toutefois pas encore déterminé si une telle précaution est nécessaire.

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

    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 numéro de 3 octets complété par des zéros identifiant le courtier membre à l’origine du chiffrement, un bloc compteur de 16 octets et la valeur chiffrée. Vous trouverez un exemple de cette structure à la figure 2.

    • Le code du courtier à l’origine du chiffrement est requis pour que l’OCRCVM puisse 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 bloc compteur devrait être composé d’un nombre aléatoire de 64 bits concaténé à une valeur compteur initiale de 64 bits. On s’attend à ce que, conformément à la pratique recommandée, un nombre aléatoire 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 ne peut servir qu’une seule fois. Le bloc compteur et le texte chiffré devraient être restreints à des caractères UTF-8 imprimables.

    • 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 et actualisées tous les 12 mois. (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.)

    Nous prévoyons qu’il faudra mettre sur pied un calendrier strict de rotation des clés pour veiller à ce que les courtiers actualisent leur clé de chiffrement à la date donnée. Ce calendrier devra :

    • indiquer à chaque courtier membre qu’une nouvelle clé est disponible;

    • préciser à chaque courtier membre la date à partir de laquelle il devra commencer à utiliser la nouvelle clé;

    • indiquer la confirmation par chaque courtier membre du fait qu’il a récupéré la nouvelle clé;

    • accorder suffisamment de temps pour régler les problèmes liés à la récupération des clés et rappeler aux courtiers membres qu’ils doivent récupérer leur nouvelle clé si ce n’est pas déjà fait.

 

arrowHaut de la page

 

Spécifications du protocole FIX

Contenu à venir bientôt.

 

arrowHaut de la page