CONSEILS EN MATIÈRE DE SÉCURITÉ POUR LES PRODUITS COMMERCIAUX (CSPC) RÉSEAUX PRIVÉS VIRTUELS (RPV)

Transcription

1 CONSEILS EN MATIÈRE DE SÉCURITÉ POUR LES PRODUITS COMMERCIAUX (CSPC) RÉSEAUX PRIVÉS VIRTUELS (RPV) CSG-01\G Août

2 Page intentionnellement laissée en blanc.

3 Avant-propos Le document est NON CLASSIFIÉ et il est publié avec l autorisation du chef du Centre de la sécurité des télécommunications Canada (CSTC). Les propositions de modification devraient être envoyées par les voies sécurisées du ministère concerné au représentant des Services à la clientèle du CSTC. Pour de plus amples renseignements, prière de communiquer avec les Services à la clientèle de la Sécurité des TI du CSTC, par courriel à l adresse itsclientservices@csecst.gc.ca, ou par téléphone au Date d entrée en vigueur La présente publication entre en vigueur le 28 août. Carey Frey Directeur, Programme avec l industrie de la Sécurité des TI Gouvernement du Canada, Centre de la sécurité des télécommunications Canada Il est interdit de faire des copies de cette publication ou d extraits de cette publication sans la permission écrite du CSTC. i

4 Page intentionnellement laissée en blanc. ii

5 Table des matières Avant-propos... i Date d entrée en vigueur... i Table des matières... iii Liste des tableaux... iv 1 Introduction Aperçu des RPV Types de RPV fonctionnel RPV à accès distant RPV de site à site Technologie RPV RPV utilisant le protocole IPSec RPV utilisant le protocole TLS Problèmes liés à la sécurité Confidentialité Chiffrement Gestion des clés et des certificats Disponibilité Bande passante et capacité Déni de service Intégrité Authentification Authentification de l origine des données Protection contre les tentatives de réinsertion Attaques par accès en parallèle Architecture Sécurité de l hôte Tunnellisation partagée Interopérabilité des produits RPV Glossaire et acronymes Glossaire Acronymes iii

6 Liste des tableaux Tableau 1 : Liste de contrôle des fonctions recommandées Produits RPV iv

7 1 Introduction La présente annexe au catalogue des listes de contrôle des fonctions de sécurité des technologies de l information (TI) porte spécifiquement sur les réseaux privés virtuels (RPV). On entend par «réseau privé virtuel» toute connexion réseau protégée ou à utilisation restreinte qui emploie la tunnellisation, le chiffrement et d autres contrôles de sécurité pour offrir les services d une livraison spécialisée dans un réseau public. Par «tunnellisation» on entend l encapsulation ou la transmission de paquets de données d un protocole réseau donné dans des paquets de données correspondant à un protocole différent. Il est à noter que la présente liste de contrôle décrit un produit optimal; il est possible qu un unique produit ne satisfasse pas à tous les besoins de l utilisateur. Il peut être nécessaire d évaluer plus d un produit pour déterminer les utilisations qui se chevauchent. De plus, de nombreux produits actuellement offerts sur le marché combinent la technologie RPV à d autres produits de sécurité, par exemple des coupe-feu et/ou des systèmes de détection des intrusions. La présente liste de contrôle porte spécifiquement sur les caractéristiques RPV de tels produits. Pour évaluer les autres fonctions associées à ces produits, l utilisateur doit consulter la liste de contrôle appropriée dans la présente publication. 1

8 2 Aperçu des RPV Les RPV sont couramment utilisés pour tunnelliser un protocole de couche liaison sur un protocole de couche réseau (tel le protocole Internet IP) afin de simuler une connexion de type «réseau local» (LAN pour Local Area Network) vers un serveur de fichiers ou d applications situé à un autre endroit. Il est ainsi possible pour des utilisateurs distants d accéder aux ressources ministérielles par Internet comme s ils avaient ouvert une session depuis un poste de travail connecté directement au LAN ministériel. De même, une connexion RPV permettra aux bureaux éloignés d une organisation de se connecter au siège social ou à un bureau régional par l intermédiaire d un réseau public tel qu Internet, au lieu de liaisons louées. Les connexions RPV sont normalement chiffrées afin de protéger le trafic contre l écoute clandestine et d autres attaques lancées depuis Internet. 2.1 Types de RPV fonctionnel En théorie, un réseau peut être constitué d un grand nombre de nœuds isolés, tous connectés les uns aux autres par Internet au moyen d un réseau virtuel. En réalité, toutefois, les RPV appartiennent la plupart du temps à l une de deux catégories fonctionnelles : le RPV à accès distant, dans lequel un utilisateur distant se connecte à une passerelle RPV à l aide d une liaison chiffrée, et le RPV de site à site, dans lequel deux réseaux locaux sont reliés grâce à une liaison chiffrée établie entre deux passerelles RPV RPV à accès distant Un RPV à accès distant permet à un utilisateur distant de se connecter aux ressources d un ministère par l intermédiaire d un réseau public ou partagé, par exemple Internet. L utilisateur distant établit une connexion à un serveur ou concentrateur RPV situé dans les installations du ministère (au moyen d un navigateur Web ou d une application cliente RPV spécialisée). L utilisateur s authentifie auprès du serveur RPV, puis l application cliente installée sur le poste de travail de l utilisateur et le serveur négocient une clé de session qui servira au chiffrement des données pour cette session spécifique. Le serveur RPV attribue une adresse de réseau virtuelle au poste de travail de l utilisateur, de manière à ce que ce poste de travail semble appartenir au réseau interne du ministère pour les serveurs de fichiers et d applications ministériels. Les RPV à accès distant constituent une solution idéale pour les travailleurs mobiles et les télétravailleurs, qui nécessitent une connexion sécurisée aux ressources de leur ministère telles que le courrier électronique et autres applications ministérielles RPV de site à site Dans le cas d un RPV de site à site, une organisation utilise du matériel spécialisé pour établir une connexion entre deux ou plusieurs sites géographiquement séparés, afin de faciliter l échange des ressources organisationnelles. Dans ce scénario, tous les utilisateurs d un site donné peuvent accéder aux systèmes des autres sites (assujettis aux politiques en matière de contrôle d accès), et il n est pas nécessaire d installer des clients RPV spécialisés sur leurs postes 2

9 de travail. Le RPV de site à site permet à un utilisateur de se connecter à des ressources distantes comme si elles résidaient sur le réseau local. Les RPV de site à site sont particulièrement utiles pour les divisions ou les bureaux régionaux et les organisations partenaires qui ont besoin d accéder aux ressources ministérielles. 2.2 Technologie RPV Les RPV peuvent également être classés en fonction de la technologie utilisée pour tunnelliser et chiffrer le trafic. Les deux technologies RPV les plus utilisées sont le protocole IPSec et le protocole SSL/TLS RPV utilisant le protocole IPSec On utilise l IPSec dans les RPV depuis plus longtemps que le protocole SSL/TLS.2 Il s agit d un ensemble normalisé de protocoles de chiffrement au niveau de la couche réseau permettant d offrir des services de confidentialité des données, d authentification et de non-répudiation. L IPSec offre deux modes de fonctionnement : le mode transport et le mode tunnel. En mode transport, seules les données utiles dans chaque paquet IP sont chiffrées et/ou authentifiées. En mode tunnel, toutes les données de chaque paquet IP, y compris les en-têtes, sont chiffrées et/ou authentifiées. Le paquet doit être encapsulé dans un autre paquet IP pour être acheminé par Internet. L IPSec comporte deux principaux protocoles : les en-têtes d authentification (AH pour Authentication Header) et l encapsulation des données utiles (ESP pour Encapsultaing Security Payload). Le protocole AH assure les services d intégrité, d authentification et de non-répudiation, tout dépendant des algorithmes de chiffrement utilisés. Le protocole ESP assure en premier lieu la confidentialité; l authentification et l intégrité sont facultatives. L IPSec prend en charge les normes Triple DES et AES pour assurer la confidentialité des données, ainsi que les normes SHA-1 et SHA-2 pour assurer la protection de l intégrité3. Pour la gestion et l échange de clés cryptographiques, l IPSec prend en charge les protocoles IKE et ISAKMP Normes IPSec L IPSec est régie par différentes normes décrites dans les documents RFC publiés par l IETF (Internet Engineering Task Force). Tous les documents RFC ci-dessous appartiennent à la catégorie «normes», sauf dans les cas spécifiquement indiqués : RFC 2401 Security Architecture for the Internet Protocol RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH 1 Le protocole SSL, développé par des fournisseurs privés, a été formalisé en tant que norme TLS (Transport Layer Security), bien que de nombreux utilisateurs la désigne encore sous l appellation SSL. Le recours au protocole SSL n a pas été approuvé par le CSTC. Le présent document recommande le recours à la norme TLS. 2 L IPSec ne constitue pas le seul protocole pouvant être utilisé pour mettre en œuvre un RPV au niveau de la couche réseau. On peut également utiliser, entre autres, le protocole L2TP et le protocole PPTP. Ces deux protocoles permettent de transmettre et d encapsuler le trafic d un protocole donné (p. ex. IPX) au moyen d un autre protocole (p. ex. IP). Toutefois, ces protocoles de tunnellisation offrent un niveau de sécurité limité, et doivent être combinés à l IPSEC pour assurer les services d authentification et de confidentialité. 3 On trouvera dans la publication spéciale du NIST, la norme FIPS 197 et la norme FIPS les spécifications relatives à ces algorithmes de chiffrement. 3

10 RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP) RFC 2409 The Internet Key Exchange (IKE) RFC 2411 IP Security Document Roadmap (catégorie : information) RFC 2412 The OAKLEY Key Determination Protocol (catégorie : information) RFC 2451 The ESP CBC-Mode Cipher Algorithms RFC 3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) RFC 3602 The AES-CBC Cipher Algorithm and Its Use with IPSec RFC 3686 Using Advanced Encryption Standard (AES) Counter Mode With IPSec Encapsulating Security Payload (ESP) RFC 3706 A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers (catégorie : information) RFC 3715 IPSec-Network Address Translation (NAT) Compatibility Requirements (catégorie : information) RFC 3947 Negotiation of NAT-Traversal in the IKE RFC 3948 User Datagram Protocol (UDP) Encapsulation of IPSec ESP Packets RFC 4106 The Use of Galois/Counter Mode (GCM) in IPSec Encapsulating Security Payload (ESP) RFC 4301 Security Architecture for the Internet Protocol RFC 4302 IP Authentication Header RFC 4303 IP Encapsulating Security Payload (ESP) RFC 4304 Extended Sequence Number (ESN) Addendum to IPSec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) RFC 4305 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) RFC 4306 Internet Key Exchange (IKEv2) Protocol RFC 4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) RFC 4308 Cryptographic Suites for IPSec RFC 4309 Using Advanced Encryption Standard (AES) CCM Mode with IPSec Encapsulating Security Payload (ESP) RFC 4478 Repeated Authentication in Internet Key Exchange (IKEv2) Protocol (catégorie : expérimental) RFC 4543 The Use of Galois Message Authentication Code (GMAC) in IPSec ESP and AH RFC 4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE) RFC 4621 Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol (catégorie : information) 4

11 RFC 4718 IKEv2 Clarifications and Implementation Guidelines (catégorie : information) RFC 4753 ECP Groups for IKE and IKEv2 RFC 4754 IKE and IKEv2 Authentication Using ECDSA RFC 4806 Online Certificate Status Protocol (OCSP) Extensions to IKEv2 RFC 4809 Requirements for an IPSec Certificate Management Profile (catégorie : information) RFC 4868 Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPSec RFC 4869 Suite B Cryptographic Suites for IPSec RFC 4945 The Internet IP Security Public Key Infrastructure (PKI) Profile of IKEv1/ISAKMP, IKEv2, and PKIX Logiciels clients IPSec Un RPV fondé sur l IPSec nécessite la mise en œuvre de la pile de protocoles IPSec dans le système d exploitation installé sur l ordinateur distant. Tout le trafic de réseau est chiffré et encapsulé avant sa transmission à travers le réseau de transfert (Internet). Le trafic RPV IPSec est aboutit à un serveur RPV installé dans le site principal du ministère. Depuis ce serveur, le trafic est transféré en clair sur le réseau interne du ministère. L utilisateur distant a ainsi entièrement accès à ce réseau (tout dépendant des contrôles d accès au réseau), tout comme s il y était relié directement. En général, un RPV IPSec constitue la meilleure option pour une configuration de site à site, dans laquelle le RPV relie du matériel fixe et doit servir des utilisateurs multiples à un emplacement donné à long terme. Lorsqu il est utilisé pour un RPV de site à site, le protocole IPSec peut être installé et configuré sur un concentrateur ou une plateforme similaire à chaque site, ce qui permet d éliminer la nécessité d installer un logiciel client sur chaque poste de travail du site. Aussi, les RPV IPSec constituent un choix approprié pour les utilisateurs distants qui se connectent toujours au moyen du même poste de travail (de préférence un poste de travail géré par le ministère, plutôt que l ordinateur personnel de l utilisateur) Inconvénients associés à l IPSec Les ordinateurs tournant sous un système d exploitation qui mettent en œuvre une pile de protocoles IPSec doivent être configurés par un administrateur système. Ce processus peut se révéler plus compliqué que l accès à un RPV TLS (pour Transport Security Layer) au moyen d un navigateur Web. De plus, il sera nécessaire de configurer les coupe-feu de l organisation de manière à laisser passer le trafic IPSec. Dans certaines situations, il est possible qu un coupe-feu installé sur le site distant bloque le trafic IPSec et empêche un utilisateur de se connecter, même si tous les autres paramètres sont correctement configurés. 5

12 2.2.2 RPV utilisant le protocole TLS Le TLS est un protocole normalisé de couche application développé initialement pour sécuriser les connexions entre les navigateurs Web et les serveurs Web. Le trafic est chiffré au niveau de la couche application, plutôt qu au niveau de la couche réseau comme dans le cas des RPV IPSec. Le TLS permet d offrir des services d authentification et de confidentialité unidirectionnels (côté serveur) ou bidirectionnels (côté serveur et côté client). Le recours aux RPV TLS a découlé de la nécessité de permettre à des utilisateurs distants de se connecter aux ressources ministérielles depuis des emplacements non contrôlés tels que les postes de déclaration dans les aéroports, les organisations partenaires et les ordinateurs personnels (c est-à-dire n appartenant pas au ministère). Au moment où ce besoin devait être comblé, le protocole TLS était déjà largement répandu au sein des différents navigateurs Web et était bien compris par les utilisateurs. Il a donc été adopté en tant que solution RPV viable pour les situations concernant des ordinateurs distants non contrôlés par un ministère. Dans un RPV TLS, il n est pas nécessaire de déployer des logiciels clients à l avance sur les postes de travail; n importe quel navigateur Web moderne peut agir à titre d application d accès à distance. De plus, puisque le protocole TLS est mis en œuvre au niveau de la couche application, il permet aux administrateurs de contrôler l accès à des applications dorsales spécifiques. Les RPV TLS sont normalement acheminés par l intermédiaire d applications mandataires TLS, qui offrent une gamme complète de services de journalisation et de vérification. Des percées récentes en matière de RPV TLS permettent maintenant un accès au réseau ministériel au niveau de la couche réseau au besoin, ainsi que le téléchargement dynamique d applets dans le navigateur, de manière à offrir des fonctions d accès additionnelles Normes TLS L architecture TLS est gouvernée par différentes normes décrites dans les documents RFC (pour Request for Comments) publiés par l IETF (Internet Engineering Task Force). Tous les documents RFC ci-dessous appartiennent à la catégorie «normes», sauf dans les cas spécifiquement indiqués : RFC 2246 The TLS Protocol Version 1.0 RFC 3268 Advanced Encryption Standard (AES) Cipher suites for Transport Layer Security (TLS) RFC 4346 The Transport Layer Security (TLS) Protocol Version Inconvénients associés au protocole TLS Les premiers RPV TLS permettaient seulement l accès aux applications Web dorsales. La plupart des fournisseurs de solutions TLS ont maintenant corrigé cet inconvénient en mettant en œuvre des téléchargements dynamiques permettant un accès de type client-serveur aux applications non Web dans un RPV TLS. 3 Problèmes liés à la sécurité Les RPV posent plusieurs problèmes en matière de sécurité : 6

13 3.1 Confidentialité L expéditeur devrait être en mesure de chiffrer les données avant de les transmettre via un réseau Chiffrement Il faut que la méthode de chiffrement utilisée corresponde au niveau de sensibilité des données passant par le RPV Gestion des clés et des certificats Le RPV doit comporter un système adéquat de gestion des clés. Si on utilise la cryptographie à clé publique, il doit être possible de gérer les certificats de clé publique et les clés privées. 3.2 Disponibilité Bande passante et capacité Un RPV devrait disposer d une capacité et d une puissance de traitement suffisantes pour gérer le nombre maximal de connexions prévu dans le cadre des activités normales. De plus, puisqu il est vraisemblable que le nombre d employés travaillant hors lieu augmentera considérablement dans un scénario d interruption des activités, la conception du RPV devrait prendre en compte les scénarios les plus pessimistes décrits dans le plan de continuité des activités (PCA) et devrait assurer au minimum les services de base à la suite de l entrée en vigueur du PCA Déni de service La passerelle RPV devrait être conçue de manière à pouvoir résister aux attaques par déni de service (DoS pour Denial of Service) connues. La disponibilité d un RPV est toujours limitée par la disponibilité du réseau sous-jacent. Puisqu un RPV n accroît aucunement la disponibilité, il n est pas recommandé d utiliser un tel réseau sur un réseau public partagé (par exemple Internet) pour l accès à des systèmes essentiels à la mission comportant des exigences élevées en matière de disponibilité. 3.3 Intégrité Le destinataire devrait être en mesure de s assurer que les données n ont été modifiées en aucune façon, intentionnellement ou accidentellement, depuis leur transmission. 3.4 Authentification Dans le cas d un RPV à accès distant, il faut être en mesure d authentifier les utilisateurs distants de manière à confirmer leur identité. Dans le cas d un RPV de site à site, les passerelles RPV aux deux extrémités de la liaison doivent être en mesure de s authentifier mutuellement pour empêcher l établissement d une liaison non autorisée au moyen d une passerelle RPV malveillante qui tenterait de se faire passer pour un partenaire légitime. 7

14 Un RPV devrait pouvoir prendre en charge des méthodes d authentification multiples, notamment les noms d utilisateurs et mots de passe, les certificats de clé publique, les cartes à puce et les processus d authentification à deux facteurs Authentification de l origine des données Après l établissement d une session RPV, le destinataire devrait être en mesure d authentifier la source de chaque paquet, pour prouver que les données ont bel et bien été envoyées par l utilisateur autorisé. Il sera ainsi possible d empêcher un attaquant d injecter des données dans le flux de données en vue de perturber ou de détourner une connexion RPV Protection contre les tentatives de réinsertion La protection contre les tentatives de réinsertion (replay) désigne la capacité de détecter et de prévenir les attaques au cours desquelles un intrus saisit le trafic transmis par un utilisateur légitime et le réexécute en tout ou en partie, à une date ultérieure ou dans un format modifié Attaques par réinsertion Dans une attaque par réinsertion, un attaquant enregistre des paquets transmis au cours d une session légitime et les réexécute par la suite auprès du destinataire, dans le but d amener celui-ci à exécuter des opérations non autorisées Attaques par interception Dans une interception (man-in-the-middle), un attaquant s insère au milieu d une liaison de communication établie entre deux parties légitimes et, en interceptant et en transmettant les communications entre les deux parties (peut-être grâce à des modifications non autorisées), parvient à les convaincre qu elles communiquent directement l une avec l autre. En interceptant, et peut-être en modifiant, puis en transmettant les communications entre les deux parties légitimes, l attaquant espère obtenir des renseignements précieux. Par exemple, un intrus se faisant passer pour la passerelle RPV pourra établir une liaison chiffrée avec un client. En acheminant la session ouverte par le client à la vraie passerelle RPV, l attaquant pourra ensuite établir une liaison chiffrée distincte avec cette dernière. Le client et la passerelle seront tous deux convaincus qu ils communiquent directement l un avec l autre au moyen d une liaison chiffrée, et ignoreront que l attaquant peut déchiffrer et lire tous les paquets transmis dans les deux directions Attaques par accès en parallèle Dans une attaque par accès en parallèle (piggyback), également désigné «accès à califourchon», un intrus est en mesure de prendre le contrôle d une session de communication qui ne s est pas terminée correctement. Si un utilisateur ne met pas fin correctement à une session de 8

15 communication, l utilisateur suivant du terminal pourrait être en mesure de continuer simplement la session ouverte. 3.5 Architecture Sécurité de l hôte Si l ordinateur client distant n est pas sécurisé ou a été compromis, il pourra être utilisé comme point d entrée pour des accès non autorisés au réseau ministériel Tunnellisation partagée Dans une situation de tunnellisation partagée, un ordinateur distant a établi un tunnel RPV avec le réseau ministériel tout en maintenant une connexion à Internet par l intermédiaire de son fournisseur d accès. Dans cette situation, un trafic malveillant pourrait accéder à l ordinateur distant depuis Internet, puis accéder au réseau ministériel à partir de l ordinateur compromis. Pour contrer cette possibilité, il faut configurer le réseau ministériel en tant que mandataire Internet, de manière à ce que tout le trafic entre Internet et l ordinateur distant passe par le réseau ministériel. Lorsque le RPV est actif, le logiciel client RPV devrait désactiver tout accès à Internet qui ne passe pas par le RPV; autrement dit, la tunnellisation partagée devrait être désactivée Interopérabilité des produits RPV Un produit RPV fondé sur les normes établies et provenant d un fournisseur donné devrait être en mesure d établir une session RPV avec un produit fondé sur les mêmes normes mais provenant d un autre fournisseur. Le Virtual Private Network Consortium (VPNC) vérifie l interopérabilité des produits RPV fondés sur les protocoles IPSec et TLS et accorde des logos de conformité aux produits qui réussissent les tests d interopérabilité. 9

16 4 Glossaire et acronymes 4.1 Glossaire Passerelle Nœud servant de point d accès à un autre réseau. Les passerelles sont le plus couramment utilisées pour transférer des données entre un réseau privé et Internet. Profil de protection (PP) Ensemble d'exigences et d objectifs de sécurité valables pour une catégorie de produits ou de systèmes, indépendant de leur implémentation, qui satisfait des besoins similaires d'utilisateurs de produits de sécurité des TI. Un PP est normalement réutilisable et doit définir des exigences qui permettent d atteindre efficacement les objectifs fixés. Le concept de PP a été élaboré pour soutenir la définition des normes fonctionnelles et pour faciliter la formulation des spécifications d achat. Cible de sécurité (ST) Document décrivant les objectifs et exigences en matière de sécurité des TI pour une cible d évaluation (TOE) spécifique et définissant les mesures fonctionnelles et les mesures d assurance mises en œuvre par cette TOE pour satisfaire aux exigences énoncées. La ST peut être conforme à un ou plusieurs PP, et constitue le fondement de toute activité d évaluation. Cible d évaluation (TOE) Produit ou système TI assujetti à une évaluation de la sécurité. Politique de sécurité de la TOE (TSP) Ensemble des règles définissant le comportement de sécurité exigé pour une cible d évaluation donnée. Fonction de sécurité de la TOE (TSF) Ensemble des éléments d une cible d évaluation qui sont nécessaires pour assurer l application de la TSP. Concentrateur RPV Passerelle RPV Passerelle RPV permettant d établir un grand nombre de connexions RPV à bande passante relativement étroite avec un réseau interne à bande passante plus large. Passerelle permettant de relier un réseau interne à un réseau privé virtuel. 10

17 4.2 Acronymes AES AH CAVP CBC CMVP CSTC DES DoS DSL EAL ESP FIPS GC ICP IKE IP IPSec ISAKMP IV L2TP LAN LCR NAT OCSP PP RPV SSL ST TCP TCP/IP TLS TOE Advanced Encryption Standard Authentication Heading Programme de validation des algorithmes cryptographiques Enchaînement de blocs de chiffrement Cryptographic Algorithm Validation Program Centre de la sécurité des télécommunications Canada Data Encryption Standard Déni de service Ligne d abonné numérique Niveau d assurance de l évaluation Encapsulation Federal Information Processing Standard Gouvernement du Canada Infrastructure à clé publique Internet Key Exchange Protocole Internet Internet Protocole Security Internet Security Association and Key Management Protocol Vecteur d initialisation Layer 2 Tunneling Protocol Réseau local Liste des certificats révoqués Traduction d adresse réseau Online Certificate Status Protocol Profil de protection Réseau privé virtuel Secure Sockets Layer Cible de sécurité Transmission Control Protocol Transmission Control Protocol/Internet Protocol Transport Layer Security Cible d évaluation 11

18 TSP TSF UIT VPNC Politique de sécurité de la TOE Fonction de sécurité de la TOE Union internationale des télécommunications Virtual Private Network Consortium 12

19 Tableau 1 : Liste de contrôle des fonctions recommandées Produits RPV Nom du produit Élément Liste de contrôle des fonctions de sécurité pour les produits RPV 1.0 Fonctions de sécurité de base 1.1 Chiffrement Le produit devrait être en mesure de chiffrer toutes les données qui transitent par le produit conformément aux normes cryptographiques. 1.2 Bande passante La passerelle RPV devrait disposer d une capacité et d une puissance de traitement suffisantes pour gérer le nombre maximal de connexions prévu dans le cadre des activités normales Planification de la continuité des activités La passerelle RPV devrait disposer d une capacité et d une puissance de traitement suffisantes pour gérer le nombre maximal de connexions prévu à la suite d une interruption des activités et de l activation du plan de continuité des activités (PCA) Déni de service 1.3 Intégrité La passerelle RPV devrait être conçue de manière à pouvoir résister aux attaques par déni de service (DoS) connues. Après l établissement d une session RPV, le destinataire devrait être en mesure de vérifier et de confirmer l intégrité de chaque paquet, pour prouver que les données n ont pas été modifiées en cours de transmission Authentification de l origine des données Après l établissement d une session RPV, le destinataire devrait être en mesure d authentifier la source de chaque paquet, pour prouver que les données ont bien été envoyées par l utilisateur autorisé Protection contre les attaques par réinsertion Le produit devrait utiliser un protocole de question-réponse de manière à pouvoir détecter les tentatives de réinsertion par un attaquant de messages enregistrés antérieurement à l occasion d une session de communication légitime Protection contre les attaques par interception Le produit devrait permettre l authentification mutuelle entre le client et la passerelle (respectivement, entre deux passerelles) Protection contre les attaques par accès en parallèle Le produit devrait pouvoir être configuré de manière à mettre fin automatiquement à une session après une certaine période d inactivité. 1.4 Analyse de la sécurité de l hôte L infrastructure RPV devrait être en mesure de valider la sécurité d un hôte qui se connecte au réseau. Une telle validation devrait comporter, au minimum, l évaluation du logiciel antivirus et du coupe-feu installés sur le poste de travail client, ainsi que la vérification de la présence des mises à jour, et des niveaux des correctifs de sécurité. En règle générale, un RPV de service TLS ne nécessite pas de client RPV, tandis que le logiciel client nécessaire pour un RPV IPSEC est installé par défaut sur la plupart des postes de travail tournant sous Windows XP ou Vista. Il est possible qu une organisation exerce peu ou pas de contrôle sur le poste de travail client à partir duquel un utilisateur se connecte au réseau. La présente fonction de sécurité permet d empêcher un ordinateur non sécurisé de se connecter au réseau interne. 1.5 Interopérabilité des produits RPV Le produit a subi avec succès des tests d interopérabilité avec d autres produits RPV fondés sur les mêmes normes offerts par d autres fabricants dans la même catégorie (p. ex., IPSec ou TLS). 2.0 Conformité aux normes de protocole 13

20 Nom du produit Élément 2.1 Technologies RPV Protocole IPSec Liste de contrôle des fonctions de sécurité pour les produits RPV Le produit devrait être fondé sur l une des normes suivantes : IPSec TLS (mais non SSL) Le produit devrait prendre en charge l IPSec pour le chiffrement et l authentification. Cette norme prend en charge le protocole AH pour l authentification et le protocole ESP pour l authentification et le chiffrement (produits IPSec). La liste des documents RFC pertinents publiés par l IETF figure à la section Internet Key Exchange (IKE) Le produit devrait prendre en charge la norme IKE pour l échange de clés (produits IPSec) Transport Layer Security Certificats TLS 3.0 Authentification Le produit devrait prendre en charge la norme TLS pour le chiffrement et l authentification (produits TLS). Le produit devrait prendre en charge les certificats TLS X.509 (produits TLS). 3.1 Mots de passe robustes Le produit devrait prendre en charge les mots de passe robustes, comportant au moins huit caractères alphanumériques Compatibilité des mots de passe Lorsque des mots de passe sont utilisés, le produit devrait prendre en charge différents formats et longueurs de mots de passe conformes à la politique ministérielle en matière de mots de passe. 3.2 Authentification fondée sur l ICP Le produit devrait prendre en charge l authentification fondée sur l ICP. 3.3 Authentification à facteurs multiples Le produit devrait prendre en charge l authentification à deux facteurs ou à trois facteurs. 4.0 Normes relatives à l infrastructure à clé publique 4.1 Certificats à clé publique X.509 Le produit devrait prendre en charge la norme X.509 de l Union internationale des télécommunications (UIT) relative aux certificats de clé publique. 4.2 Annuaire LDAP Le produit devrait prendre en charge l intégration à une base de données LDAP (Lightweight Directory Access Protocol) (document RFC 4510). 4.3 Révocation de certificats Le produit devrait prendre en charge la révocation des certificats, soit par la publication de listes des certificats révoqués (LCR) (document RFC 3280) dans un annuaire public, soit par l accès en ligne aux renseignements pertinents sur la révocation des certificats au moyen du protocole OCSP (document RFC 2560). 4.4 Algorithmes cryptographiques Le produit devrait prendre en charge au moins un des algorithmes spécifiés à la section «Normes cryptographiques». 5.0 Normes cryptographiques 14

21 Nom du produit Élément 5.1 Algorithmes de chiffrement Liste de contrôle des fonctions de sécurité pour les produits RPV Le produit devrait utiliser l un des algorithmes de chiffrement suivants, qui sont approuvés par le CSTC pour le chiffrement des renseignements protégés du gouvernement du Canada : Advanced Encryption Standard (AES) avec une longueur de clé de 128, 192 ou 256 bits (option privilégiée) Triple DES avec option à deux ou trois clés CAST5 avec une longueur de clé de 128 bits SKIPJACK 5.2 Algorithmes d établissement de clés Le produit devrait utiliser l un des algorithmes suivants, qui sont approuvés par le CSTC pour l établissement des clés de chiffrements utilisées par le gouvernement du Canada : Rivest, Shamir, Adleman (RSA) Autres algorithmes fondés sur l exponentiation dans un corps fini (p. ex, Diffie-Hellman) Key Exchange Algorithm (KEA) Algorithmes à courbe elliptique 5.3 Algorithmes de signature numérique Le produit devrait utiliser l un des algorithmes suivants, qui sont approuvés par le CSTC pour la signature numérique des données du gouvernement du Canada : RSA Digital Signature Algorithm (DSA) Autres algorithmes fondés sur l exponentiation dans un corps fini (p. ex, El-Gamal) Elliptic Curve Digitale Signature Algorithm (ECDSA) 5.4 Algorithmes de hachage S il y a lieu, le produit devrait utiliser l un des algorithmes de hachage suivants, qui sont approuvés par le CSTC pour utilisation par le gouvernement du Canada : Secure Hash Algorithm 1 (SHA-1) SHA-224 SHA-256 SHA-384 SHA Cryptopériode S il y a lieu, le produit devrait permettre le remplacement des clés cryptographiques à des intervalles ne dépassant pas l intervalle spécifié approuvé par le CSTC pour chaque algorithme cryptographique. 6.0 Normes en matière d assurance 6.1 Normes FIPS Le produit devrait mettre en œuvre un module cryptographique validé par le Programme de validation des modules cryptographiques selon l une des normes FIPS (Federal Information Processing Standards) suivantes : FIPS FIPS La norme FIPS a été publiée le 25 mai 2001 et remplace la norme FIPS Les modules validés comme étant conformes à la norme FIPS et à la norme FIPS sont acceptés par les agences fédérales canadiennes et américaines pour la protection des renseignements sensibles. Toutefois, une agence fédérale peut décider de faire l acquisition d un module validé uniquement à la norme FIPS ( Une validation à la norme FIPS sera acceptée comme équivalence à la norme FIPS pour les produits plus anciens. 15

22 Nom du produit Élément Liste de contrôle des fonctions de sécurité pour les produits RPV 6.2 Programme de validation des algorithmes cryptographiques Le module cryptographique devrait mettre en œuvre des algorithmes cryptographiques validés par le Programme de validation des algorithmes cryptographiques (CAVP) selon la norme spécifiée. 6.3 Critères communs Niveau d assurance d évaluation Dans le cas d un produit évalué en vertu des Critères communs, le produit doit satisfaire au niveau EAL 3 ou à un niveau supérieur Profil de protection ou cible de sécurité Dans le cas d un produit évalué en vertu des Critères communs, le produit devrait être évalué pour un profil de protection ou une cible de sécurité décrivant des fonctionnalités de sécurité pertinentes pour l organisation. 7.0 Configurabilité 7.1 Valeurs par défaut modifiables Le produit devrait permettre la modification des valeurs par défaut, et ces valeurs par défaut devraient être modifiées au moment de l installation. 7.2 Tunnellisation partagée (produits IPSec) Le produit devrait être configurable de manière à empêcher le client RPV de se connecter simultanément à plus d une destination. Plus spécifiquement, il doit pouvoir empêcher le client RPV d établir simultanément une connexion sécurisée (RPV) et une connexion non sécurisée (Internet). 7.3 Activation et désactivation du chiffrement Le produit devrait être configurable de manière à activer le chiffrement au besoin. 7.4 Activation et désactivation de l authentification 7.5 Journalisation Le produit devrait être configurable de manière à activer l authentification au besoin. Le produit devrait être configurable de manière à pouvoir inscrire toutes les transactions dans un journal, et cette fonction devrait être activée au moment de l installation. 7.6 Passage des données Le produit devrait être configurable par les administrateurs de manière à permettre ou à interdire certains protocoles (p. ex., LDAP) de transiter des données non chiffrées, s il y a lieu. 8.0 Convivialité 8.1 Configuration par les utilisateurs Le produit ne devrait nécessiter aucune configuration par l utilisateur. 8.2 Authentification par les utilisateurs Le produit devrait exiger au plus une seule transaction d authentification par l utilisateur avant de devenir pleinement fonctionnel. 8.3 Maintenance par les administrateurs Le produit devrait nécessiter un niveau de maintenance et de soutien technique au plus équivalent à celui d un système d exploitation de serveur commercial conventionnel. 8.4 Reconfiguration par les administrateurs 9.0 Gérabilité Le produit ne devrait pas nécessiter des reconfigurations quotidiennes ou hebdomadaires par les administrateurs, après une période de configuration initiale de plusieurs mois. 16

23 Nom du produit Élément Liste de contrôle des fonctions de sécurité pour les produits RPV 9.1 Chiffrement du trafic de gestion La totalité du trafic administratif et du trafic de gestion entre la console centrale et les produits distribués devrait être chiffrée conformément aux normes cryptographiques. 9.2 Gestion centralisée Le produit devrait pouvoir être géré et administré de façon centralisée sur un réseau TCP/IP. 9.3 Authentification du trafic de gestion 10.0 Extensibilité La totalité du trafic administratif et du trafic de gestion entre la console centrale et les produits distribués devrait être authentifiée conformément aux critères d authentification indiqués à la section 3.0 ci-dessus Le produit devrait être adaptable aux besoins de tout réseau, quelle que soit sa taille, c.-à-d. tout autant un réseau convenant à une petite organisation (moins de 500 utilisateurs) qu un réseau conçu pour une organisation de grande taille ( utilisateurs ou plus). 17