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

    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.  

  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 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 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é à une valeur compteur initiale de 64 bits (8 octets); le tout doit être stocké selon une architecture petit-boutiste;

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

    • La valeur initiale du compteur peut être tout entier non signé de 8 octets;

    • 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é sera déposée dans le compte Globalscape du courtier membre correspondant.

    3. Le courtier membre sera avisé par courriel de l’arrivée de sa nouvelle clé et de la date à partir de laquelle l’OCRCVM s’attend à ce qu’il commence à l’utiliser pour chiffrer les LEI.

    4. L’OCRCVM s’attend à ce que le courtier membre lui confirme rapidement qu’il a bien reçu la clé et la date de début de son utilisation.

    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é avant la date à laquelle il devrait commencer à l’utiliser, 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.4 (ajoutée le 2019-12-16)

     

    arrowHaut de la page

     

    Spécifications du protocole FIX

    Spécifications du protocole FIX (ajoutée le 2019-12-16)

     

    arrowHaut de la page