Commission Interministérielle pour la Sécurité des Systèmes d Information PROFIL DE PROTECTION OUTILS DE SECURISATION DES MESSAGES

Transcription

1 Commission Interministérielle pour la Sécurité des Systèmes d Information PROFIL DE PROTECTION OUTILS DE SECURISATION DES MESSAGES PP/9804 Version juin 1998

2 AVANT PROPOS Ce document est issu des réflexions du groupe ad-hoc Messagerie Sécurisée de la Commission Interministérielle pour la Sécurité des Systèmes d Information. Toute correspondance concernant ce profil de protection doit être adressée au Service Central de la Sécurité des Systèmes d Information : SCSSI Division CH/PP 18 rue du Doc Zamenhof Issy Les Moulineaux France

3 Sommaire Chapitre 1 Outils de sécurisation des messages Identification du profil de protection Présentation du profil de protection Chapitre 2 Description de la cible d évaluation Définition de la cible d évaluation Les services de la TOE Chapitre 3 Environnement de sécurité L environnement physique de la TOE Connexion de la TOE à son environnement Les acteurs Typologie des attaquants Les biens à protéger Les menaces Description de la politique de sécurité organisationnelle Les hypothèses d utilisation Chapitre 4 Objectifs de sécurité Objectifs de sécurité portant sur la cible d évaluation Objectifs de sécurité portant sur l environnement de la TOE Chapitre 5 Exigences de sécurité Exigences fonctionnelles de la cible d évaluation Liste des exigences fonctionnelles Exigences d assurance des TI de la cible d évaluation Chapitre 6 Notes d application Exploitation de la TOE Législation applicable en France Page i

4 Chapitre 7 Justification du profil de protection Menaces non couvertes par le profil de protection Justification des objectifs de sécurité Tableau croisé Justificatif des exigences de sécurité Dépendances des composantes fonctionnelles Dépendances des composantes d assurance Annexe A Abréviations et Glossaire A.1 Abréviations A.2 Glossaire Annexe B Bibliographie B.1 Document relatif aux messageries sécurisés B.2 Documents relatifs aux critères communs B.3 Documents relatifs à la réglementation française Page ii

5 Chapitre 1 Outils de sécurisation des messages 1.1 Identification du profil de protection 1 Titre : Profil de protection pour les outils de sécurisation des messages (PP_OSM). 2 Version : 1.5, du 6 juin Identifiant : PP/ Ce profil de protection est conforme à la version 2.0 Draft des Critères Communs. 5 La liste des abréviations ainsi qu un glossaire des termes utilisés dans ce profil de protection sont donnés en annexe A. 1.2 Présentation du profil de protection 6 L échange d informations par l intermédiaire de courrier électronique est un besoin majeur des utilisateurs des systèmes d information. 7 Lorsqu il s agit de documents sensibles ou classifiés de défense, le service de messagerie doit apporter des assurances supplémentaires à ses utilisateurs : l intégrité et la protection de la confidentialité des messages échangés et secrets cryptologiques. 8 La cible d évaluation décrite dans ce profil de protection est la ressource cryptologique installée sur un poste informatique destiné à sécuriser des messages. Cette cible d évaluation doit être une enceinte de confiance où sont conservés les secrets et où est effectué l ensemble des opérations cryptographiques nécessaires à la sécurisation des messages. 9 Ce profil de protection définit au sens des Critères Communs les exigences fonctionnelles et d assurance de la cible d évaluation qui sont nécessaires au traitement et aux échanges d informations classifiées de défense au niveau Confidentiel Défense. 10 Cependant, des exigences complémentaires peuvent s avérer nécessaires à la protection des informations classifiées de défense, en particulier lorsque la cible d évaluation est soumise à des menaces autres que celles prises en compte par ce profil de protection (cf. chapitre 3.6). Des exigences complémentaires peuvent aussi découler des choix de réalisation et d implémentation de la cible d évaluation, choix qui restent ouverts au niveau de ce PP. Page 1

6 11 Les exigences figurant dans ce PP sont indépendantes du degré de sécurité des réseaux de transport et indépendantes des protocoles d échanges de messages. 12 Les grandes lignes d une architecture de messagerie électronique pour l administration [Ad-hoc] sont rappelées dans la figure 1.1 ci-dessous. 13 La cible d évaluation décrite dans ce profil de protection est une sous partie de l architecture de messagerie qui est composée des entités décrites ci-dessous. a) Un poste utilisateur (PU) : il s agit d un micro-ordinateur connecté à un réseau. Un logiciel de messagerie (LM) est installé sur le poste. La sécurisation des messages par le logiciel de messagerie nécessite l emploi d une ressource cryptologique logicielle ou matérielle installée sur le PU. Cette ressource cryptologique est la cible d évaluation. b) Une infrastructure de gestion de clés (IGC) : l IGC se compose d un ensemble d organismes de confiance organisés le plus souvent en arborescence ou en réseau maillé. Les services offerts par ces tiers sont la certification et la distribution de clés, l horodatage et la notarisation des messages ainsi que la gestion des annuaires d abonnés au service de messagerie. Ces tiers utiliseront une TOE pour sécuriser les messages échangés. c) Des serveurs locaux de messagerie (SLM) : il s agit du bureau de poste pour un ensemble d utilisateurs. Le SLM a pour fonction l archivage, l envoi et la réception de messages entre les postes des utilisateurs et le réseau de serveurs de messagerie. Une passerelle de sécurite pourra renforcer la sécurité de l architecture de messagerie au moyen des services de sécurité d une TOE. d) Des serveurs de messagerie (SM) : un SM est optionnel dans l architecture. C est un routeur des messages entre les SLM qui lui sont attachés et le réseau étendu. Un SM peut éventuellement utiliser des services de sécurité d une TOE. Page 2

7 Réseau local Poste utilisateur (PU) Logiciel messagerie (LM) Ressource cryptologique Réseau local Serveur local de messagerie (SLM) et passerelle de sécurité Ressource cryptologique Serveur de messagerie (SM) Ressource cryptologique Serveur de messagerie (SM) et passerelle de sécurité Réseau étendu Infrastructures de gestion de clés (IGC) Ressource cryptologique Fig Diagramme d une architecture de messagerie. Page 3

8 Page 4

9 Chapitre 2 Description de la cible d évaluation 2.1 Définition de la cible d évaluation 14 La cible d évaluation (notée TOE dans la norme des Critères Communs - Target Of Evaluation -) est la ressource cryptologique nécessaire à la protection des messages par un logiciel de messagerie d un utilisateur ou par un serveur de l IGC. Cette ressource est par exemple un logiciel, une carte à puce, une carte PCcard, un boîtier externe (lecteur de carte à puce sécurisé, boîtier chiffrant). 2.2 Les services de la TOE 15 La TOE contribue à la sécurisation des messages échangés : - entre deux utilisateurs, - entre un utilisateur et l infrastructure de gestion de clés, - entre un utilisateur et un groupe d abonnés à l intérieur d un forum de discussion. 16 Cette section décrit la liste des services de sécurité qui doivent être offerts par la TOE : - identification de l utilisateur, - authentification des parties communicantes, - la génération de clés symétriques et asymétriques, - la génération de condensats, - la protection des clés conservées dans la TOE, - le chiffrement et le déchiffrement des messages et pièces jointes, - la vérification de l intégrité d un certificat de clé publique, - la génération et la vérification de la signature numérique des messages et pièces jointes. Page 5

10 Page 6

11 Chapitre 3 Environnement de sécurité 3.1 L environnement physique de la TOE 17 La TOE admet diverses représentations physiques (logiciel, cartes à puces, cartes internes ou externes PC, etc...). L accès physique à la TOE est un facteur qui doit être pris en compte dans la politique de sécurité qui définit les conditions d usage de la TOE. 3.2 Connexion de la TOE à son environnement 18 La TOE est reliée au poste utilisateur par un port série ou parallèle, ou par un bus PC d extension de périphérique. 19 L application de messagerie accède aux fonctions de sécurité de la TOE par l intermediaire d une interface conforme aux normes internationales (par exemple, IDUP-GSS-API ou MAPI). 3.3 Les acteurs Les utilisateurs 20 L utilisateur est défini comme une entité humaine extérieure à la TOE mais qui interagit avec la TOE par l intermédiaire d une application accessible par le poste informatique de l utilisateur. Par extension, l utilisateur peut être un processus informatique. 21 Pour ce profil de protection, l utilisateur est un individu autorisé par son autorité de sécurité à mettre en œuvre la TOE. Il obtient de l IGC les certificats de clés publiques et secrets nécessaires à son authentification et à la sécurisation des messages par la TOE L administrateur de sécurité 22 L administrateur de sécurité de la cible d évaluation est responsable de la mise en oeuvre de la politique de sécurité de la TOE. Il peut être confondu avec l administrateur de sécurité des systèmes d information incluant la TOE. On entend par autorité de sécurité l entité responsable de la définition et de l application d une politique de sécurité. Page 7

12 3.4 Typologie des attaquants 23 Les attaquants potentiels de la cible d évaluation sont : a) les utilisateurs autorisés mais pouvant commettre une erreur par inadvertance, b) les personnes ou machines qui disposent de moyens d investigation et d action sur la TOE elle-même et sur toutes les composantes de l architecture de messagerie (le poste utilisateur, les serveurs de messagerie, les tiers de l IGC et les réseaux locaux ou étendus, etc.). 3.5 Les biens à protéger 24 La TOE est destinée à protéger les informations sensibles appelées biens. Deux types de biens sont à distinguer : les biens directs et les biens indirects. 25 Les biens directs sont les messages et pièces jointes sécurisés au moyen de la TOE et échangés par les utilisateurs. Ces biens sont produits au moyen d un logiciel de messagerie ou de tout autre applicatif. Ils doivent être protégés en intégrité. Les biens directs protégés également en confidentialité sont appelés biens directs secrets. 26 Les biens indirects sont les informations nécessaires à la protection des biens directs. Il s agit de l ensemble des variables cryptographiques : les biens indirects secrets (clés privées et symétriques, germes d aléa) et les biens indirects publics (les certificats de clés publiques). 27 La TOE est considérée dans ce PP comme une enceinte de confiance où sont conservés les secrets et appliquées les fonctions cryptographiques. Tous les biens indirects conservés dans la TOE seront protégés en confidentialité et en intégrité. 3.6 Les menaces 28 Les menaces prises en compte dans ce profil de protection sont issues du répertoire EBIOS des menaces génériques (cf. [EBIOS], Outillage). 29 Toutes les menaces auxquelles la TOE est soumise ne sont pas prises en compte dans ce PP. Une liste non exhaustive de menaces non couvertes par ce PP mais identifées comme pouvant porter atteinte à la sécurité du service de messagerie figure au chapitre Menaces portant sur la TOE 30 M.INTRUSION : Un attaquant obtient un accès non autorisé à la TOE. 31 Remarque : L accès peut être obtenu suite au vol de la TOE ou par intrusion via le poste utilisateur, via une application installée sur le poste ou via le réseau. Les Page 8

13 conséquences de cette attaque sont l accès non autorisé de l attaquant à des fonctions de sécurité de la TOE et l accès à des biens indirects secrets conservés dans la TOE. Cette attaque est ludique, avide mais surtout stratégique; elle vise l intégrité et la confidentialité des biens à protéger par la TOE. De bonnes connaissances cryptographiques et techniques sont indispensables. 32 M.DYSFONC : Le dysfonctionnement de la TOE risque d entraîner une perte de l intégrité et de la confidentialité des biens indirects conservés dans la TOE. 33 Remarque : Cette menace provient soit de la défaillance accidentelle d un composant de la TOE soit de sa modification par un attaquant disposant d excellentes connaissances techniques et d un accès à la TOE. 34 M.CLONAGE : La reproduction de la TOE par copie de son support physique ou par simulation logique permet à l attaquant de reproduire toutes ou parties des fonctions de la TOE. 35 Remarque : Cette attaque est stratégique. Selon le mode de reproduction, les moyens financiers peuvent être conséquents et de bonnes connaissances cryptographiques et techniques nécessaires. 36 M.MODIFIE : La modification non détectée d un bien après sa sécurisation par la TOE est une menace sur l intégrité de ce bien. 37 Remarque : L attaque peut être localisée sur le poste utilisateur, sur le réseau local, ou étendu, ou dans un serveur de l architecture de messagerie. Cette attaque est ludique, avide ou stratégique; elle engendre une perte de l intégrité des biens à protéger. Aucune connaissance technique de la TOE et aucun accès physique à la TOE ne sont nécessaires. L attaquant doit seulement avoir des connaissances cryptologiques et maîtriser les protocoles de sécurisation et d échange des biens à protéger. 38 M.DIVULG : Un attaquant prend connaissance d un bien direct ou indirect secret alors qu il est protégé en confidentialité au moyen de la TOE. 39 Remarque : L attaque peut être localisée sur le poste utilisateur, sur le réseau support ou dans un serveur de l architecture de messagerie. Cette attaque est ludique, avide ou stratégique. Aucune connaissance technique de la TOE et aucun accès physique à la TOE ne sont nécessaires. Les moyens financiers sont importants et d excellentes connaissances cryptologiques sont indispensables. 40 M.ECHANGE : Un utilisateur autorisé échange involontairement un bien direct ou indirect secret avec un utilisateur non autorisé. 41 Remarque : Cette menace peut provoquer une perte de confidentialité du bien échangé. C est par exemple le cas si un certificat révoqué est utilisé par l une ou l autre des parties communicantes pour sécuriser l échange. L accès à la TOE n est pas indispensable, une faible connaissance technique et peu de moyens financiers sont nécessaires. Page 9

14 3.6.2 Menaces portant sur l environnement de la TOE 42 M.PILOTE : Un logiciel ou un matériel installé sur le poste utilisateur provoque une perte d intégrité non détectée des pilotes de périphériques nécessaires à l activation de la TOE par le poste utilisateur, impliquant une perte d intégrité des services de la TOE ou une perte d intégrité et de confidentialité des biens à protéger. 43 Remarque : Cette menace peut découler d une action d un utilisateur non averti ou d une attaque ludique ou stratégique. Une connaissance technique de la TOE est nécessaire à l attaquant, mais aucun moyen financier et aucun accès à la TOE ne sont indispensables; seul le poste utilisateur doit être accessible à l attaquant. 3.7 Description de la politique de sécurité organisationnelle 44 P.UTILIS : Les fonctions de la TOE doivent être limitées aux services décrits dans le chapitre 2. L usage et l administration de la TOE pour protéger des informations classifiées de défense nécessite son agrément par le SCSSI et éventuellement l agrément de l application ou du système d information utilisant la TOE [900]. 45 P.ADMIN : L administrateur de la sécurité de la TOE doit pouvoir joindre dans les plus brefs délais les utilisateurs de la TOE et inversement. 46 P.CSP : Une autorité de certification de clés publiques de l infrastructure de gestion de clés génère, publie ou révoque un certificat de clé publique conformément à une politique de certification (notée CSP) approuvée par l autorité de sécurité compétente. 3.8 Les hypothèses d utilisation Les hypothèses sur l administration et l utilisation de la TOE 47 H.USAGE : La TOE doit être administrée et utilisée par des personnes habilitées et disposant des moyens nécessaires à ces tâches. Les utilisateurs et administrateurs de TOE doivent être formés aux techniques nécessaires à l utilisation, respectivement à l administration, de la TOE. 48 H.RESP : Les utilisateurs de la TOE connaissent les responsabilités financières, civiles et pénales associées à l usage de la TOE (reconnaissance juridique de la signature numérique générée ou vérifiée par l usage d une TOE et contraintes réglementaires imposées pour le traitement d informations classifiées de défense protégées à l aide d une TOE) Les hypothèses sur l architecture de messagerie 49 H.MESSAGERIE : Les composantes des technologies de l information (par exemple : serveurs de messagerie, services de publication, gardes, autorités de certification, d enregistrement, de confiance et applications logicielles associées) Page 10

15 qui composent l architecture de messagerie doivent faire l objet d une évaluation selon les critères en vigueur. a) Pour les besoins de confidentialité, l utilisateur de la TOE est abonné auprès d un tiers de confiance agréé conformément au décret n du 24 février 1998 en application de l article 28 de la loi n du 29 décembre 1990 sur la réglementation des télécommunications. b) Pour les besoins d authentification et de signature numérique, les certificats de clés publiques sont générés par une autorité de certification et publiés dans un annuaire conformément à une politique approuvée par l autorité de sécurité compétente. Page 11

16 Page 12

17 Chapitre 4 Objectifs de sécurité 4.1 Objectifs de sécurité portant sur la cible d évaluation Les accès autorisés 50 O.TOE-ACCES : Seul un utilisateur autorisé par son autorité de sécurité doit pouvoir employer la TOE. Avant toute utilisation ou après une période d inactivité fixée par l autorité de sécurité, la TOE doit identifier et authentifier l utilisateur La protection des biens de la TOE 51 O.NOIR : Les biens indirects conservés dans la TOE sont protégés en confidentialité et en intégrité. 52 O.INTEGRITE : La TOE doit pouvoir contrôler l intégrité des biens qu elle reçoit et produire les informations nécessaires aux autres TOE pour contrôler l intégrité des biens à protéger qu elle exporte. 53 O.SECRET : Les biens directs ou indirects secrets exportés ou importés par la TOE doivent être protégés en confidentialité. 54 O.VOL : Le vol ou la perte d une TOE ne doit pas porter atteinte à la sécurité des biens gérés par les différentes TOE de la messagerie. 55 O.SECOURS : En cas de dysfonctionnement de la TOE, toute exportation de biens conservés ou en cours de traitement par la TOE doit être impossible. 56 O.AUTH : La TOE doit permettre l authentification des parties communicantes lors d un échange de biens. 4.2 Objectifs de sécurité portant sur l environnement de la TOE 57 O.GUIDE : L installation, l initialisation et l usage de la TOE doivent être correctement documentés. 58 O.USAGE : L administration et l emploi de la TOE ne doivent en aucun cas nuire à la sécurité des biens secrets gérés par la TOE. Les utilisateurs de la TOE connaissent les responsabilités financières, civiles et pénales associées à l usage de la TOE. 59 O.MESSAGERIE : Les composantes des technologies de l information (par exemple : serveurs de messagerie, services de publication, gardes, autorités de certification, d enregistrement, de confiance et applications logicielles associées) qui composent l architecture de messagerie doivent faire l objet d une évaluation Page 13

18 selon les critères en vigueur et doivent pouvoir traiter des informations classifiées de défense. 60 O.UTILIS : Les fonctions de la TOE ne sont pas détournables à des services non décrits dans le Chapitre 2. L utilisation de la TOE pour traiter des informations classifiées de défense nécessite un agrément du SCSSI et éventuellement l agrément de l application ou du système d information utilisant la TOE [900]. 61 O.ADMIN : Une infrastructure de communication opérationnelle doit exister entre l utilisateur et l administrateur. Page 14

19 Chapitre 5 Exigences de sécurité 5.1 Exigences fonctionnelles de la cible d évaluation 62 Le tableau ci-dessous présente la liste des exigences fonctionnelles inclues dans ce profil de protection. 63 Les exigences d administration (management) et les opérations (assignment, iteration, selection, refinement), doivent être complétées par le rédacteur de la cible de sécurité. Composantes Noms 1 FCO_NRO.2 Obligation de preuve de l origine 2 FCS_CKM.2 3 FCS_CKM.4 Génération des clés cryptographiques basée sur des standards Distribution des clés cryptographiques basée sur des standards 4 FCS_CKM.7 Destruction des clés cryptographiques 5 FCS_COP.2 Opération cryptographique basée sur des standards 6 FDP_ACC.2 Contrôle d accès total 7 FDP_ACF.1 Contrôle d accès basé sur les attributs de sécurité 8 FDP_ETC.2 Exportation des données de l utilisateur avec attributs de sécurité 9 FDP_IFC.1 Contrôle de flux d un sous-ensemble d informations 10 FDP_IFF.1 Attributs de sécurité simples 11 FDP_ITC.2 12 FDP_SDI.2 Importation de données de l utilisateur avec attributs de sécurité Contrôle de l intégrité des données stockées et mesures conséquentes Tab Composantes de sécurité Page 15

20 Composantes Noms 13 FDP_UCT.1 Confidentialité élémentaire de l échange de données 14 FDP_UIT.1 Intégrité de l échange de données 15 FIA_AFL.1 Action élémentaire en cas d échec d authentification de l utilisateur 16 FIA_SOS.1 Vérification des secrets 17 FIA_SOS.2 Génération des secrets par la TSF 18 FIA_UID.2 Identification de l utilisateur avant action 19 FIA_UAU.1 Temporisation de l authentification 20 FIA_UAU.5 Mécanismes multiples d authentification 21 FIA_UAU.6 Ré-authentification 22 FMT_MSA.1 Gestion des attributs de sécurité 23 FMT_MSA.2 Attributs de sécurité sûrs 24 FMT_MSA.3 Initialisation statique des attributs de sécurité 25 FMT_SMR.1 Rôles de sécurité 26 FPT_AMT.1 Machine abstraite de test 27 FPT_FLS.1 Conservation d un état sûr lors d une défaillance 28 FPT_ITC.1 Confidentialité inter-tsf pendant une transmission 29 FPT_ITI.1 Détection de modification inter-tsf 30 FPT_ITT.1 Protection élémentaire de données internes à la TSF 31 FPT_ITT.3 Surveillance de l intégrité des données de la TSF 32 FPT_PHP.3 Résistance aux attaques physiques 33 FPT_RCV.1 Recouvrement manuel 34 FPT_RVM.1 Non contournement de la politique de sécurité Tab (Suite) - Composantes de sécurité Page 16

21 Composantes 35 FPT_TDC.1 Noms Consistance élémentaire des données de la TSF inter- TSF 36 FPT_TST.1 Tests de la TSF 37 FTA_SSL.3 Fonction d abandon de session 38 FTA_TSE.1 Etablissement de session de la TOE 39 FTP_ITC.1 Canal sûr inter-tsf Tab (Suite) - Composantes de sécurité 5.2 Liste des exigences fonctionnelles Composante FCO FCO_NRO.2 Enforced Proof of Origin 64 FCO_NRO.2.1 The TSF shall enforce the generation of evidence of origin for transmitted [assignment: list of information types] at all times. 65 Types d information : tous les messages traités par la TOE (enveloppes, messages, pièces jointes et certificats). 66 FCO_NRO.2.2 The TSF shall be able to relate the [assignment: list of attributes] of the originator of the information, and the [assignment: list of information fields] of the information to which the evidence applies. 67 La liste des attributs comprend les signatures et certificats de clés publiques attachés aux messages gérés par la TOE et la désignation de l émetteur ou/et du rédacteur de ces messages. 68 La liste des champs d informations est décrite par le rédacteur de la cible de sécurité. 69 FCO_NRO.2.3 The TSF shall provide a capability to verify the evidence of origin of information to [selection: originator, recipient, [assignment: list of third parties]] given [assignment: limitations on the evidence of origin] Composante FCS FCS_CKM.2 Standards-Based Cryptographic Key Generation Page 17

22 70 FCS_CKM.2.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm and specified cryptographic key sizes which meet the following standard: [assignment: list of international standards, list of national standards, list of industry standards, list of organisational standards]. 71 Les fonctions de génération des clés de la TOE utilisent un générateur d aléa réel et/ou un générateur logiciel de pseudo-aléa. 72 La cible de sécurité décrira de façon précise les générateurs choisis et leur mise en oeuvre. FCS_CKM.4 Standards-Based Cryptographic Key Distribution 73 FCS_CKM.4.1 The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method which meets the following standard: [assignment: list of international standards, list of national standards, list of industry standards, list of organisational standards]. 74 Les méthodes décrites ci-dessous illustrent l usage des ressources de cryptographie lors de la distribution des clés d authentification et de confidentialité. 75 Méthode pour l obtention d un certificat de clé publique de signature : - L utilisateur A génère à l aide de sa TOE son bi-clé asymétrique de signature. - A communique à l autorité de certification (notée AC(a)) sa clé publique et son identité. Remarque : AC(a) s assure de l identité de A par une mesure non TI, par exemple une consultation d annuaire, la présentation par A d un document officiel ou un rapport facial entre A et un agent d enregistrement relevant de l autorité de AC(a). - AC(a) forge un certificat de la clé publique en signant à l aide de sa TOE le couple formé de la clé publique et des informations identifiant A. AC(a) publie le certificat de cette clé publique de A. 76 Méthode pour l obtention d une clé de chiffrement : - La tierce partie de confiance (notée TPC(a)) vérifie l identité de A, au besoin en communiquant avec l autorité de certification de A. TPC(a) génère un bi-clé de confidentialité à l aide de sa TOE et certifie la clé publique également à l aide de sa TOE. - TPC(a) protège la confidentialité de la clé privée de A au moyen de sa TOE. Eventuellement, la TPC(a) publie le certificat de la clé publique de confidentialité de A. FCS_CKM.7 Cryptographic Key Destruction Page 18

23 77 FCS_CKM.7.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method. 78 Le rédacteur de la cible de sécurité précisera la procédure d effacement des secrets conservés dans la TOE. FCS_COP.2 Standards-Based Cryptographic Operation 79 FCS_COP.2.1 The TSF shall perform [assignment: list of cryptographic operations] in accordance with a specified cryptographic algorithm and cryptographic key size which meet the following standard: [assignment: list of international standards, list of national standards, list of industry standards, list of organisational standards]. 80 Les opérations cryptographiques sont : - l authentification des parties communicantes, - la génération de clés symétriques et asymétriques, - la génération des condensats, - la protection des clés conservées dans la TOE, - la génération et la vérification de la signature numérique des messages et des pièces jointes, - la vérification de l intégrité d un certificat de clé publique, - le chiffrement et le déchiffrement des messages et pièces jointes qui sont échangés à l aide de la TOE. 81 Le rédacteur de la cible de sécurité raffinera la description de toutes les opérations cryptographiques présentées ci-dessus Composante FDP FDP_ACC.2 Complete Access Control 82 FDP_ACC.2.1 The TSF shall enforce the [assignment: access control SFP] on [assignment: list of subjects and objects] and all operations among subjects and objects covered by the SFP. 83 FDP_ACC.2.2 The TSF shall ensure that all operations between any subject in the TSC and any object within the TSC are covered by the SFP. FDP_ACF.1 Security Attribute Based Access Control 84 FDP_ACF.1.1 The TSF shall enforce the [assignment: access control SFP] to objects based on [assignment: security attributes, named groups of security attributes]. 85 FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed [assignment: rules Page 19

24 governing access among controlled subjects and controlled objects using controlled operations on controlled objects]. FDP_ETC.2 Export of User Data With Security Attributes 86 FDP_ETC.2.1 The TSF shall enforce the [assignment: access control SFP and/or information flow control SFP] when exporting user data, controlled under the SFP, outside of the TSC. 87 FDP_ETC.2.2 The TSF shall export the user data with the user data s associated security attributes. 88 FDP_ETC.2.3 The TSF shall ensure that the security attributes, when exported outside the TSC, are unambiguously associated with the exported user data. 89 FDP_ETC.2.4 The TSF shall enforce [assignment: additional exportation control rules] when user data is exported from the TSC. FDP_IFC.1 Subset Information Flow Control 90 FDP_IFC.1.1 The TSF shall enforce the [assignment: information flow control SFP] on [assignment: list of subjects, objects and operations among subjects and objects covered by the SFP]. FDP_IFF.1 Simple Security Attributes 91 FDP_IFF.1.1 The TSF shall enforce the [assignment: information flow control SFP] to enforce at least the following types of subject and object security attributes [assignment: the minimum number and type of security attributes]. 92 FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject and a controlled object via a controlled operation if the following rules hold [assignment: for each operation, the security attribute-based relationship that must hold between subject and object security attributes]. 93 FDP_IFF.1.3 The TSF shall enforce the [assignment: additional information flow control SFP rules]. 94 FDP_IFF.1.4 The TSF shall enforce the following [assignment: list of additional SFP capabilities]. FDP_ITC.2 Import of User Data with Security Attributes 95 FDP_ITC.2.1 The TSF shall enforce the [assignment: access control SFP and/or information flow control SFP] when importing user data, controlled under the SFP, from outside of the TSC. 96 FDP_ITC.2.2 The TSF shall use the security attributes associated with the imported user data. Page 20

25 97 FDP_ITC.2.3 The TSF shall ensure that the protocol used provides for the unambiguous association between the security attributes and the user data received. 98 FDP_ITC.2.4 The TSF shall ensure that interpretation of the security attributes of the imported user data is as intended by the source TSF. 99 FDP_ITC.2.5 The TSF shall enforce the following [assignment: additional importation control rules] when importing user data controlled under the SFP from outside the TSC. FDP_SDI.2 Stored Data Integrity Monitoring and Action 100 FDP_SDI.2.1 The TSF shall monitor user data stored within the TSC for [assignment: integrity errors] on all objects, based on the following [assignment: user data attributes]. 101 Toutes les données contenues dans la TOE (clés, certificats, attributs de sécurité, données d authentification, fonctions de cryptographie, logiciel, contextes d application) sont concernées. La rédacteur de la cible de sécurité complétera cette liste. 102 FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [assignment: action to be taken]. 103 La mesure à prendre en cas de détection de la perte d intégrité d un des objets est d inhiber toutes les fonctionnalités. FDP_UCT.1 Basic Data Exchange Confidentiality 104 The TSF shall enforce the [assignment: access control SFP and/or information flow control SFP] to be able to [selection: transmit, receive] objects in a manner protected from unauthorised disclosure. FDP_UIT.1 Basic Data Exchange Integrity 105 FDP_UIT.1.1 The TSF shall enforce the [assignment: access control SFP and/or information flow control SFP] to be able to [selection: transmit, receive] user data in a manner protected from undetectable [selection: modification, deletion, insertion, replay] errors 106 FDP_UIT.1.2 The TSF shall be able to determine on receipt of user data, whether [selection: modification, deletion, insertion, or replay] has occurred Composante FIA FIA_AFL.1 Basic authentication failure handling 107 FIA_AFL.1.1 The TSF shall detect when [selection: an authorised administrator configurable number of, [assignment: number]] unsuccessful authentication attempts occur related to [assignment: list of authentication events]. Page 21

26 108 FIA_AFL.1.2 After the defined number of unsuccessful authentication attempts has been detected, the TSF shall [assignment: list of actions]. FIA_SOS.1 Verification of secrets 109 FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [assignment: a defined quality metric]. FIA_SOS.2 TSF Generation of Secret 110 FIA_SOS.2.1 The TSF shall provide a mechanism to generate secrets that meet [assignment: a defined quality metric]. 111 FIA_SOS.2.2 The TSF shall be able to enforce the use of TSF generated secrets for [assignment: list of TSF functions]. FIA_UID.2 User Identification before any action 112 FIA_UID.2.1 The TSF shall require each user to identify itself before allowing any TSF-mediated actions on behalf of that user. FIA_UAU.1 Timing of authentification 113 FIA_UAU.1.1 The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the user to be performed before the user is authenticated. 114 FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. FIA_UAU.5 Multiple Authentication Mechanisms 115 FIA_UAU.5.1 The TSF shall provide [assignment: list of multiple authentication mechanisms] to support user authentication. 116 FIA_UAU.5.2 The TSF shall authenticate any user s claimed identity according to the [assignment: rules describing how the multiple authentication mechanisms provide authentication]. FIA_UAU.6 Re-authenticating 117 FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions [assignment: list of conditions under which re-authentication is required]. 118 Après un délai d inactivité fixé par l autorité de sécurité et précisé par le rédacteur de la cible de sécurité, l utilisateur doit de nouveau être authentifié. Page 22

27 5.2.5 Composante FMT FMT_MSA.1 Management of security attributes 119 FMT_MSA.1 The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to restrict the ability to [selection: change_default, read, modify, delete] the values of the security attributes [assignment: list of security attributes] to [assignment: the authorized identified roles]. FMT_MSA.2 Safe security attributes 120 FMT_MSA.2 The TSF shall ensure that only safe values are accepted for security attributes. FMT_MSA.3 Static Attribute Initialisation 121 FMT_MSA.3.1 The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to provide [selection: restrictive, permissive, other property] default values for object security attributes that are used to enforce the SFP. 122 FMT_MSA.3.2 The TSF shall allow the [assignment: the authorised identified roles] to specify alternate initial values to override the default values when an object is created. FMT_SMR.1 Security roles 123 FMT_SMR.1.1 The TSF shall maintain the roles [assignment: the authorised identified roles]. 124 FMT_SMR.1.2 The TSF shall be able to associate users with roles Composante FPT FPT_AMT.1 Abstract Machine Testing 125 FPT_AMT.1.1 The TSF shall run a suite of tests [selection: during initial start-up, periodically during normal operation, at the request of the authorised administrator, other conditions] to demonstrate the correct operation of the security functions provided by the abstract machine which underlies the TSF. FPT_FLS.1 Failure with Preservation of Secure State 126 FPT_FLS.1.1 The TSF shall preserve a secure state when [assignment: list of types of TSF failures] occur. FPT_ITC.1 Inter-TF Confidentiality During Transmission Page 23

28 127 FPT_ITC.1.1 The TSF shall protect any TSF data transmitted from the TSF to a remote TSF from unauthorized disclosure. FPT_ITI.1 Inter-TSF Detection of Modification 128 FPT_ITI.1.1 The TSF shall provide the capability to detect modification within [assignment: a defined modification metric] of all TSF data transmitted between the TSF and a remote trusted IT product. 129 FPT_ITI.1.2 The TSF shall verify the integrity of all TSF data transmitted between the TSF and a remote trusted IT product and perform [assignment: action to be taken] in case modifications are detected. FPT_ITT.1 Basic Internal TSF Data Transfer Protection 130 FPT_ITT.1.1 The TSF shall protect TSF data from [selection: disclosure, modification] when it is transmitted between physically-separated parts of the TOE. FPT_ITT.3 TSF Data Integrity Monitoring 131 FPT_ITT.3.1 The TSF shall be able to detect [selection: modification of data, substitution of data, re-ordering of data, deletion of data, other integrity errors] for TSF data transmitted between physically-separated parts of the TOE. 132 FPT_ITT.3.2 Upon detection of a data integrity error, the TSF shall [assignment: specify the action to be taken]. FPT_PHP.3 Resistance to Physical Attack 133 FPT_PHP.3.1 The TOE shall resist identified physical tampering attacks to the [assignment: list of devices/elements, physical tampering attack scenarios, work factors for which resistance to attack is required] 134 FPT_PHP.3.2 The TOE shall respond automatically to physical attacks to [assignment: list of devices/elements, physical tampering attack scenarios for which automatic response to attack is required] in such a way as to ensure that the TSP is not violated FPT_RCV.1 Manual Recovery 135 FPT_RCV.1.1 After a failure or service discontinuity, the TSF shall enter a maintenance mode where the ability to return the TOE to a secure state is provided. 136 Remarque : l état dit de confiance de la TOE après un dysfonctionnement ou une interruption de service peut être un vérouillage complet de la TOE qui peut nécessiter une repersonnalisation complète de la TOE. 137 FPT_RCV.1.2 The TSF shall provide the authorised administrator with the capability to restore the TSF data to a consistent and secure state. Page 24

29 FPT_RVM.1 Non-Bypassability of the TSP 138 FPR_RVM.1.1 The TSF shall ensure that TSP enforcement functions are invoked and succeed before assignment operation within the TSC is allowed to proceed. FPT_TDC.1 Inter-TSF Basic TSF Data Consistency 139 FPT_TDC.1.1 The TSF shall enforce the consistent interpretation of [assignment: list of TSF data types] between this TSF and another trusted IT product. 140 FPT_TDC.1.2 The TSF shall use [assignment: list of interpretation rules to be applied by the TSF] when interpreting the TSF data from another trusted IT product. FPT_TST.1 TSF Testing 141 FPT_TST.1.1 The TSF shall run a suite of self tests [selection: during initial startup, periodically during normal operation, at the request of the authorised administrator, at the conditions [assignment: conditions at which self test should occur]] to demonstrate the correct operation of the TSF. 142 FPT_TST.1.2 The TSF shall provide authorized administrators with the capability to verify the integrity of TSF data. 143 FPT_TST.1.3 The TSF shall provide authorised administrators with the capability to verify the integrity of stored TSF executable code Composante FTA FTA_SSL.3 TSF-initiated Termination 144 FTA_SSL3.1 The TSF shall terminate an interactive session after a [assignment: time interval] interval of user inactivity. FTA_TSE.1 TOE Session Establishment 145 FTA_TSE.1.1 The TSF shall be able to deny session establishment based on [assignment: attributes] Composante FTP FTP_ITC.1 Inter-TSF Trusted Channel 146 FTP_ITC.1.1 The TSF shall provide a communication channel between itself and a remote trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure. Page 25

30 147 FTP_ITC.1.2 The TSF shall permit [selection: only the TSF, the remote trusted IT product] to initiate communication via the trusted channel. 148 FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [assignment: list of functions for which a trusted channel is required]. Page 26

31 5.3 Exigences d assurance des TI de la cible d évaluation 149 Le niveau d assurance visé est EAL5 augmenté de plusieurs composantes d assurance. 150 Ce niveau est nécessairement élevé car le besoin exprimé par les utilisateurs est d employer une TOE pour sécuriser des informations classifiées de défense du niveau Confidentiel Défense avec à terme la possiblité d utiliser la TOE dans un système d information approuvé pour traiter des informations classifiées Secret Défense. 151 Par rapport au niveau EAL 4, le niveau retenu dans ce profil de protection apporte les assurances supplémentaires suivantes : - une description semi-formelle des fonctions de sécurité, - une visibilité totale de l implémentation de la TSF, - une représentation semi-formelle des correspondances entre les différentes représentations, - le développement d un modèle formel de politique de sécurité (contre un développement informel dans le cas de EAL 4), - un modèle du cycle de vie de la TOE basé sur un standard, - un niveau de détail plus élevé dans la réalisation de tests, - une représentation semi-formelle des interfaces utilisateurs, - une recherche systématique des attaques possibles sur la TOE, et la garantie de disposer d un système relativement résistant. 152 Ces compléments s accordent avec la nécessité de sécuriser des informations classifiées de défense et justifient le choix d un niveau d assurance EAL Le niveau EAL5 est résumé dans le tableau 5.2. Les composantes d assurance rajoutées sont listées dans le tableau 5.3. Composantes ACM_AUT.1 ACM_CAP.4 ACM_SCP.3 ADO_DEL.2 ADO_IGS.1 Noms Automatisation partielle de la gestion de configuration Génération de supports et procédures de recette Couverture de la gestion de configuration des outils de développement Détection de modification Procédures d installation, de génération, et de démarrage Tab EAL5 Page 27

32 Composantes ADV_FSP.3 ADV_HLD.3 ADV_IMP.2 ADV_INT.1 ADV_LLD.1 ADV_RCR.2 ADV_SPM.3 AGD_ADM.1 AGD_USR.1 ALC_DVS.1 ALC_LCD.2 ALC_TAT.2 ATE_COV.2 ATE_DPT.2 ATE_FUN.1 ATE_IND.2 AVA_CCA.1 AVA_MSU.2 AVA_SOF.1 AVA_VLA.3 Spécification fonctionnelle semi-formelle Conception générale semi-formelle Implémentation de la TSF Modularité (composante couverte par l augmentation) Conception détaillée descriptive Démonstration de correspondance semi-formelle Modèle formel de la politique de sécurité de la TOE Documentation de l administrateur Documentation l utilisateur Identification des mesures de sécurité Modèle standardisé du cycle de vie Conformité à des standards d implémentation Analyse de couverture Test- conception détaillée (composante couverte par l augmentation) Tests fonctionnels Test indépendant - échantillon Analyse des canaux cachés (composante couverte par l augmentation) Validation de l analyse Évaluation de la force des fonctions de sécurité de la cible d évaluation. Relativement résistant Noms Tab (Suite) - EAL5 Page 28

33 Composantes ADV_INT.3 ALC_FLR.3 ATE_DPT.3 AVA_CCA.3 Noms Minimisation de la complexité Réparation systématique Test - Implémentation Analyse exhaustive des canaux cachés Tab Exigences d assurance ajoutées 154 L ajout de la composante ADV_INT.3 permet de minimiser la complexité de l architecture de la TOE. Ces composantes viennent en complément de la composante ADV_IMP.2 en facilitant la compréhension de l implémentation de la TOE. 155 L ajout de la composante ALC_FLR.3 offre l assurance de la réaction systématique de l éditeur de la TOE après détection d un incident de sécurité de la TOE. 156 L ajout de la composante ATE_DPT.3 permet de tester l implémentation de la TOE à son plus bas niveau. 157 L ajout de la composante AVA_CCA.3 assure l adoption d une méthode exhaustive d analyse des canaux cachés de la TOE, par rapport à une analyse simple (AVA_CCA.1). 158 Dans la mesure où la TOE est destinée à sécuriser des informations classifiées de défense, elle peut être confrontée à des attaques stratégiques ce qui justifie, dans la composante AVA_SOF.1, le choix du niveau de résistance le plus élevé possible: SOF - high. Page 29

34 Page 30

35 Chapitre 6 Notes d application 6.1 Exploitation de la TOE 159 Les responsables de l exploitation de la TOE doivent être certains que la découverte d un dysfonctionnement de la TOE provoquera une réaction pertinente et rapide de du constructeur de la TOE au profit de l ensemble de ses utilisateurs de la TOE. 160 La disponibilité de la TOE peut diminuer si la TOE ne peut plus être maintenue pour réparation ou évolution en raison de la défaillance des fournisseurs des biens de supports (logiciels et materiels). L utilisation et l évolution de la TOE doivent être opérationnelles pour une durée fixée par l autorité de sécurité et figurant dans le contrat de fourniture de la TOE. 161 En conséquence, si la TOE ne peut plus être maintenue pour réparation ou évolution en raison de défaut d organisation administrative (absence de personnel spécialisé, défaut de budget) le niveau de sécurité de l environnement d emploi de la TOE peut diminuer et donc porter atteinte à la sécurité des biens traités par la TOE. 162 Les documents de spécification de la TOE sont séquestrés en lieu sûr et consultables uniquement par les personnes ayant le besoin d en connaître. 6.2 Législation applicable en France 163 Plusieurs contraintes légales existent qui obligent les administrations et organismes liés par tutelle ou contrat à l Etat à mettre en œuvre des mesures techniques visant à protéger les informations traitées par les administrations : - la loi relative à la protection du secret de défense (code pénal art 410-1, à 414-9), - la loi n 78-17, du 6 janvier 1978, relative à l informatique, aux fichiers et aux libertés, - la loi relative au secret professionnel (Code pénal : art et ), - loi du 11 juillet 1991 relative au secret des correspondances. 164 La loi n du 29 décembre 1990 modifiée sur la réglementation des télécommunications, notamment son article 28 précise la réglementation applicable aux moyens et prestations de cryptologie. Les constructeurs, distributeurs et utilisateurs de la TOE doivent prendre connaissance du décret ci-dessous : Page 31

36 - Décret n du 24 février 1998 définissant les conditions dans lesquelles sont souscrites les déclarations et accordées les autorisations concernant les moyens et prestations de cryptologie (J.O. du 25/02/98 pp.2911). 165 Le terme TTP est utilisé dans ce PP, la législation française emploie l expression organisme gérant pour le compte d autrui des conventions secrètes de cryptologie Le décret cité ci-dessous précise le terme d agrément de ces organismes : - Décret n du 24 février 1998 définissant les conditions dans lesquelles sont agréées les organismes gérant pour le compte d autrui des conventions secrètes de cryptologie en application de l article 28 de la loi n du 29 décembre 1990 sur la réglementation des télécommunications (J.O. du 25/02/98, pp. 2915). 166 Lorsque le contenu des messages, leur simple existence, y compris leur destinataire, récipiendaire ou date d envoi relève du secret de défense, l ensemble de la réglementation interministérielle s applique : - l instruction générale interministérielle n 1300/SGDN/SSD du 12 mars 1982, sur la protection du secret et des informations concernant la défense nationale et la sûreté de l État, - l instruction interministérielle n 500bis/SGDN/TTS/SSI/DR, du 18 octobre 1996, relative au chiffre dans la sécurité des systèmes d information, - l instruction générale n 900/DISSI/SCSSI/DR, du 20 juillet 1993, sur la sécurité des systèmes d information qui font l objet d une classification de défense pour eux-mêmes ou pour les informations traitées. 167 Dans le cas contraire, la recommandation n 901/DISSI/SCSSI, du 2 mars 1994, pour la protection des systèmes d informations sensibles non classifiées de défense, peut guider le développement et l utilisation d une messagerie électronique dans l administration. Page 32

37 Chapitre 7 Justification du profil de protection 7.1 Menaces non couvertes par le profil de protection 168 La cible d évaluation décrite dans ce PP ne suffit pas à elle seule à sécuriser un service de messagerie. En particulier, les menaces citées dans la liste non exhaustive qui suit, ne sont pas couvertes par le présent profil Menaces non couvertes portant sur la TOE 169 MNC.DYSFONC-D : Le dysfonctionnement de la TOE risque d entraîner une perte de disponibilité des biens indirects conservés dans la TOE. Cette vulnérabilité provient soit de la défaillance accidentelle d un composant de la TOE soit de sa modification par un attaquant. Cette menace n est pas couverte pas le présent profil. 170 MNC.VOL-TOE-D : Le vol de la TOE est une perte de disponibilité de ses fonctions de sécurité et des secrets qu elle conserve. Cette menace n est pas couverte par le présent profil. 171 MNC.TEMPEST : Les changements électromagnétiques du poste utilisateur et de la ressource cryptologique sont des menaces portant sur la TOE car les signaux parasites induits peuvent compromettre la sécurité des biens de la TOE. Conformément à la directive [495], l emploi de la TOE pour le traitement des informations classifiées de défense impose une politique de zonage des lieux d emploi pour vérifier que le rayonnement de la TOE et du poste utilisateur ne porte pas atteinte à la sécurité des biens directs ou indirects sécurisés par la TOE. Cette menace n est pas couverte pas le présent profil Menaces non couvertes portant sur le poste utilisateur 172 MNC.DYSFONC-PU : Le dysfonctionnement du matériel ou du système d exploitation du poste utilisateur ou encore des pilotes logiques d extension de la TOE risque de nuire à la disponibilité de la TOE. Cette menace n est pas couverte par le présent profil. 173 MNC.VOL-SUPPORT : Le vol d un disque ou d une disquette ayant contenu ou contenant des informations classifiées provoque une perte de confidentialité et de disponibilité de ces informations. Cette menace n est pas couverte par le présent profil. 174 MNC.RESIDUEL : L utilisation de logiciel bureautique pour créer des biens directs peut entraîner la persistance d information résiduelle (fichiers temporaires, mémoires tampons, versions antérieures, fichiers rémanant,..). Cette menace provoque une perte de la confidentialité des biens directs. Elle n est pas couverte Page 33

38 par le présent profil de protection car elle relève de la politique du SI et de la mise en oeuvre de procédures adéquates de création et de gestion de ces biens directs. 175 MNC.VIRAL : Une attaque virale du poste utilisateur ou la réception d un bien contaminé est une atteinte à l intégrité du système d exploitation, des pilotes logiques d extension de la TOE et des biens directs conservés. Cette menace n est pas couverte par le présent PP car elle relève de la politique de sécurité du SI et de la mise en oeuvre d une contre mesure efficace Menaces non couvertes portant sur la rédaction des messages 176 MNC.EDITION : L ensemble des erreurs éditoriales, de reproduction et de classification des informations par l utilisateur (par exemple, l émission d un message classifié sans protection de sa confidentialité) est une menace qui risque de nuire à la confidentialité des informations classifiées. Cette menace n est pas couverte par le présent profil Menaces non couvertes portant sur la TOE et le réseau local de l utilisateur 177 MNC.SATURATION : La perte de disponibilité de l applicatif utilisant la TOE par saturation du réseau reliant le poste utilisateur au serveur de messagerie n est pas une menace couverte par le présent profil. Cette menace doit être traitée au niveau de la politique de sécurité et de l administration technique du réseau. 178 MNC.ANALYSE : Le présent profil ne couvre pas les menaces d analyse du trafic des réseaux. Suivant le degré de sécurité du réseau exigé par l autorité de sécurité, la confidentialité du flux d information sera assurée par un moyen de chiffrement de voie Menaces non couvertes portant sur la TOE et le serveur de messagerie 179 MNC.BESOIN-CONNAITRE : L envoi d un message sécurisé à l aide de la TOE à un utilisateur n ayant pas le besoin d en connaître est une atteinte à la confidentialité du message. Cette menace n est pas couverte par le présent profil car elle relève de la politique du SI et de la mise en oeuvre au niveau du serveur de messagerie de mesures de vérification. Page 34

39 7.2 Justification des objectifs de sécurité 180 Dans le tableau ci-dessous, il s agit de démontrer que les objectifs de sécurité énoncés dans le chapitre 4 sont pertinents vis-à-vis des menaces portant sur la TOE et son environnement exprimées dans le chapitre 3. Menaces Objectifs Justificatifs M.INTRUSION M.DYSFONC M.CLONAGE O.TOE-ACCES O.NOIR O.VOL O.SECOURS O.TOE-ACCES O.NOIR Les mesures préventives telles que la conservation sous la forme chiffrée des secrets dans la TOE, l indentification et l authentification des utilisateurs, la gestion des dysfonctionnements, rendent impossible l usage de la TOE à son éventuel voleur ou attaquant cherchant à pénétrer dans la TOE. Des processus de diagnostic interne à la TOE et un blocage de la TOE en cas de dysfonctionnement détécté empêchent l exploitation de tout dysfonctionnement de la TOE au profit d un attaquant. Une modélisation des fonctions de cryptographie à partir d un clône de la TOE ne permet pas de mettre en oeuvre ces fonctions. En effet, la mise en oeuvre des fonctions de la TOE n est possible qu à l aide de biens inaccessibles grâce à O.NOIR et requiert l accès à la TOE, impossible grâce à O.TOE-ACCESS. M.PILOTE O.GUIDE Les documents et moyens informatiques fournis à l utilisateur de la TOE doivent contribuer à la detecter des pertes d intégrité des pilotes logiques d extension de la TOE. M.MODIFIE O.TOE-ACCES O.INTEGRITE Le contrôle d accès à la TOE, la signature des biens exportés et la vérification systématique de l intégrité de biens importés permettent la détection de toute perte d intégrité des biens échangés. Tab Couverture des menaces par les objectifs. Page 35

40 Menaces Objectifs Justificatifs M.DIVULG M.ECHANGE O.SECRET O.AUTH O.AUTH O.USAGE O.MESSAGERIE L authentification des parties communicantes et le chiffrement des biens neutralisent le risque d échanger des informations avec des utilisateurs non autorisés. L échange involontaire de biens secrets avec un utilisateur non autorisé est impossible dans la mesure où la TOE est correctement utilisée et administrée et où les parties communicantes sont authentifiables (O.MESSAGERIE) et authentifiées (O.AUTH). Tab (Suite) - Couverture des menaces par les objectifs. 181 Dans le tableau ci-dessous, il s agit de démontrer que les objectifs de sécurité énoncés dans le chapitre 4 sont pertinents vis-à-vis des politiques de sécurité organisationnelles exprimées dans le chapitre 3. Politique de sécurité de l organisme P.UTILIS P.ADMIN P.CSP Objectifs O.UTILIS O.ADMIN O.AUTH O.INTEGRITE O.SECRET O.MESSAGERIE Justificatif L objectif O.UTILIS imposant l impossibilité d utiliser la TOE à des fins non décrites dans le Chapitre 2 permet de réaliser la politique P.UTI- LIS. La présence d une infrastructure de communication opérationnelle entre l administrateur et l utilisateur permet de garantir que l administrateur peut joindre l utilisateur dans les plus brefs délais. La TOE participe à la réalisation de la politique P.CSP grâce O.AUTH qui permet l authentification, O.INTEGRITE et O.SECRET qui assurent l intégrité et la confidentialité des informations transmises. De plus, la présence de O.MESSAGERIE assure la mise en place d une infrastructure sûre, nécessaire à la mise en oeuvre de la politique. Tab Couverture des politiques de sécurité par les objectifs de sécurité Page 36

41 182 Dans le tableau ci-dessous, il s agit de démontrer que les objectifs de sécurité énoncés dans le chapitre 4 sont pertinents vis-à-vis des hypothèses d utilisation exprimées dans le chapitre 3. Hypothèses Objectifs Justificatifs H.USAGE H.RESP H.MESSAGERIE O.GUIDE O.USAGE O.USAGE O.MESSAGERIE L usage et de l administration de la TOE ne doivent pas nuire à la sécurité des informations classifiées de défense. Ces objectifs imposent une habilitation et une formation des personnels ainsi qu une documentation explicite d usage et d administration de la TOE. L usage de la TOE et son administration sont conditionels à une information complète de l utilisateur de la TOE sur sa responsabilité. L usage seul de la TOE ne suffit pas à sécuriser une messagerie électronique ou toute autre application. Il est indispensable que chaque composante traitant des informations classifiées de défense soit employée conformément à une politique de sécurité et soit évaluée pour apporter la preuve qu elle n affaiblit pas la sécurité de l application. Tab Couvertures des hypothèses d utilisation par les objectifs de sécurité Page 37

42 7.3 Tableau croisé 183 Le tableau croisé ci-dessous démontre que chaque objectif de sécurité répond au moins à une menace ou à une politique de sécurité organisationnelle ou encore à une hypothèse d utilisation sûre. Objectifs de sécurité Les menaces et la politique de sécurité organisationnelle et hypothèses O.TOE-ACCES O.NOIR O.INTEGRITE O.SECRET O.VOL O.SECOURS O.AUTH O.GUIDE O.USAGE O.MESSAGERIE O.UTILIS O.ADMIN M.INTRUSION X X X M.DYSFONC X M.CLONAGE X X M.PILOTE X M.MODIFIE X X M.DIVULG X X M.ECHANGE X X X P.UTILIS X P.ADMIN X P.CSP X X X X H.USAGE X X H.RESP X H.MESSAGERIE X Tab Tableau croisé Page 38

43 7.4 Justificatif des exigences de sécurité Tableau de couverture 184 Le tableau ci-dessous démontre qu au moins une exigence fonctionnelle répond à chaque objectif de sécurité de la TOE et que toutes les exigences atteignent au moins un objectif de sécurité. Exigences O.TOE-ACCES O.NOIR O.INTEGRITE O.SECRET O.VOL O.SECOURS O.AUTH FCO_NRO.2 X FCS_CKM.2 X X FCS_CKM.4 X X X FCS_CKM.7 X X X FCS_COP.2 X X X X X FDP_ACC.2 X X FDP_ACF.1 X X FDP_ETC.2 X X FDP_IFC.1 X X FDP_IFF.1 X X X FDP_ITC.2 X X FDP_SDI.2 X FDP_UCT.1 X FDP_UIT.1 X FIA_AFL.1 X FIA_SOS.1 X X X Tab Couverture Objectifs - Exigences Page 39

44 Exigences O.TOE-ACCES O.NOIR O.INTEGRITE O.SECRET O.VOL O.SECOURS O.AUTH FIA_SOS.2 X X X X X FIA_UID.2 FIA_UAU.1 FIA_UAU.5 FIA_UAU.6 FMT_MSA.1 X X X X X FMT_MSA.2 X X X X FMT_MSA.3 FMT_SMR.1 X X FPT_AMT.1 FPT_FLS.1 X X FPT_ITC.1 X X FPT_ITI.1 X X FPT_ITT.1 X X FPT_ITT.3 X X FPT_PHP.3 X X FPT_RCV.1 X FPT_RVM.1 X X X X X X X FPT_TDC.1 X X X FPT_TST.1 X Tab (Suite) - Couverture Objectifs - Exigences Page 40

45 Exigences O.TOE-ACCES O.NOIR O.INTEGRITE O.SECRET O.VOL O.SECOURS O.AUTH FTA_SSL.3 X FTA_TSE.1 X FTP_ITC.1 X Tab (Suite) - Couverture Objectifs - Exigences Justifications 185 Les exigences fonctionnelles retenues dans ce profil de protection coopèrent et forment un tout cohérent Composante FCO FCO_NRO.2 Obligation de preuve de l origine 186 Cette composante a été choisie pour définir la génération par la TOE des informations nécessaires à l authentification de l origine d un message échangé entre deux TOE. Cette authentification est imposée par l objectif de sécurité O.AUTH Composante FCS FCS_CKM.2 Génération des clés cryptographiques basée sur des standards 187 Les objectifs de sécurité O.INTEGRITE et O.SECRET impliquent la capacité de signer et chiffrer des données et donc de générer des quantités aléatoires ou pseudoaléatoires. La composante FCS_CKM.2 spécifie la génération des clés nécessaires à l usage de la TOE. FCS_CKM.4 Distribution des clés cryptographiques basée sur des standards 188 Cette composante précise les protocoles de distribution des clés gérées par la TOE ou par le logiciel de messagerie installé sur le poste utilisateur pour atteindre les objectifs de sécurité O.INTEGRITE, O.SECRET et O.AUTH qui imposent la capacité de signer et de chiffrer et donc de savoir échanger des clés. FCS_CKM.7 Destruction des clés cryptographiques Page 41

46 189 L objectif O.SECRET pose le problème de la durée de vie de la clé symétrique de chiffrement du message exporté de la TOE. La TOE devra oublier la clé après usage. Cet oubli sera obtenu par une réinitialisation des mémoires de conservation de cette clé. 190 Les objectifs O.TOE-ACCES et O.SECOURS imposent éventuellement que la TOE adopte des mesures de destruction physique de ses clés. FCS_COP.2 Opérations cryptographiques basées sur des standards 191 Cette composante définit toutes les opérations cryptographiques de la TOE. Les objectifs O.TOE-ACCES, O.NOIR, O.INTEGRITE, O.SECRET, O.AUTH ne peuvent être satisfaits que par l emploi de fonctions normalisées de cryptographie Composante FDP FDP_ACC.2 Contrôle d accès total 192 Cette composante précise les conditions d accès aux secrets (O.NOIR) et aux biens protégés en confidentialité (O.SECRET). FDP_ACF.1 Contrôle d accès basé sur les attributs de sécurité 193 Cette composante précise les attributs de sécurité des secrets (O.NOIR) et des biens protégés en confidentialité (O.SECRET). FDP_ETC.2 Exportation des données de l utilisateur avec attributs de sécurité 194 Les biens indirects exportés de la TOE sont associés de manière non ambiguë à leurs attributs de sécurité. Cette association est indispensable à la mise en oeuvre des moyens de protection de la confidentialité (O.SECRET) et de l intégrité (O.INTEGRITE) de ces biens. FDP_IFC.1 Contrôle de flux d un sous-ensemble d information 195 Cette composante permet au rédacteur de la cible de sécurité de définir les sousensembles d actions pour lesquelles un contrôle d accès (O.TOE-ACCES) sera requis lors des accès aux biens conservés par la TOE. Ceci permet de définir précisément la protection de la confidentialité des secrets de la TOE (O.NOIR). FDP_IFF.1 Attributs de sécurité simples 196 Cette composante précise les attributs de sécurité des secrets (O.NOIR), des biens signés (O.INTEGRITE) et des biens protégés en confidentialité (O.SECRET). FDP_ITC.2 Importation des données de l utilisateur avec attributs de sécurité Page 42

47 197 Les biens indirects importés de la TOE sont associés de manière non ambiguë à leurs attributs de sécurité. Cette association est indispensable à la mise en oeuvre des moyens de protection de la confidentialité (O.SECRET) et de l intégrité (O.INTEGRITE) de ces biens. FDP_SDI.2 Contrôle de l intégrité des données stockées et mesures conséquentes 198 Cette composante définit tous les biens indirects contenus dans la TOE (clés, certificats, attributs de sécurité, données d authentification, fonctions de cryptographie, logiciel, contextes d application) qui doivent être protégés en intégrité et confidentialité (O.NOIR). FDP_UCT.1 Confidentialité élémentaire de l échange de données 199 Cette composante définit les biens traités par la TOE qui devront être chiffrés (O.SECRET). FDP_UIT.1 Integrité des données 200 Cette composante définit les biens traités par la TOE dont l intégrité devra être conservée (O.INTEGRITE) Composante FIA FIA_AFL.1 Action élémentaire en cas d échec d authentification de l utilisateur 201 Cette composante détermine conformément à l objectif O.TOE-ACCES les conditions d échec de l authentification de l utilisateur. FIA_SOS.1 Vérification des secrets 202 Cette composante précise les tests appliqués aux secrets traités par la TOE afin de contribuer à atteindre l objectif de sécurité O.TOE-ACCES, O.SECOURS et O.NOIR (secrets internes à la TOE). FIA_SOS.2 Génération des secrets par la TSF 203 Cette composante définit la liste des méthodes employées par la TOE pour générer les secrets nécessaires à l identification (O.TOE-ACCES) de l utilisateur, à l authentification des parties communicantes (O.INTEGRITE et O.AUTH), à la confidentialité des biens échangés (O.SECRET) et à la conservation de l intégrité et la confidentialité des biens secrets contenus dans la TOE (O.NOIR). FIA_UID.2 Identification de l utilisateur avant action 204 Cette composante impose l identification de l utilisateur avant tout emploi des fonctions de sécurité de la TOE, et contribue donc à répondre à l objectif de sécurité O.TOE-ACCES. Page 43

48 FIA_UAU.1 Temporisation de l authentification 205 Cette composante définit les conditions d emploi par la TOE de l authentification pour contribuer à répondre à l objectif de sécurité O.TOE-ACCES. FIA_UAU.5 Mécanismes multiples d authentification 206 Cette composante requiert la description des différents mécanismes d authentification supportés par la TOE. Elle permet de contribuer à répondre à l objectif de sécurité O.TOE-ACCES. FIA_UAU.6 Ré-authentification 207 La ré-authentification est mise en oeuvre après un délai d inactivité fixé par l autorité de sécurité (en cas de non ré-authentification, la session d utilisation de la TOE est close). Cette composante permet de réaliser en partie l objectif O.TOE- ACCES Composante FMT 208 Pour chaque exigence fonctionnelle, les exigences d administration proposées doivent être renseignées par le rédacteur de la cible de sécurité. FMT_MSA.1 Gestion des attributs de sécurité 209 Cette composante permet de renforcer le contrôle d accès par l attribution de rôles et de droits aux utilisateurs. Elle renforce l objectif de sécurité O.TOE-ACCESS. FMT_MSA.2 Attributs de sécurité sûrs 210 Les attributs de sécurité sont définis et limités par des valeurs sûres, fixées par l autorité de sécurité compétente. Ces mesures permettent de renforcer la confidentialité et l intégrité des biens (O.INTEGRITE, O.SECRET, O.NOIR) ainsi que le contrôle d accès (O.TOE-ACCES). FMT_MSA.3 Initialisation statique des attributs de sécurité 211 Lors de la personnalisation électrique ou logique de la TOE, cette composante précise les attributs de sécurité sur l ensemble des objets (biens indirects et variables d états internes) de la TOE et contribue à répondre à l objectif de sécurité O.TOE-ACCES lors de la première session. FMT_SMR.1 Rôles de sécurité 212 Les fonctions de sécurité doivent pouvoir distinguer les différents utilisateurs, contribuant ainsi à résoudre l objectif de sécurité O.TOE-ACCES. Page 44

49 Composante FPT FPT_AMT.1 Machine abstraite de test 213 La détection d un dysfonctionnement de la TOE a lieu lors de la comparaison des resultats de tests internes à la TOE et les résultats donnés par un modèle abstrait. L objectif O.SECOURS est en partie satisfait par l application de tests et leurs comparaisons avec le modèle abstrait. FPT_FLS.1 Conservation d un état sûr lors d une défaillance 214 Cette composante précise que les TSF doivent permettre de retrouver un état stable dit de confiance après une défaillance, contribuant ainsi à satisfaire l objectif de sécurité O.SECOURS. FPT_ITC.1 Confidentialité inter-tsf pendant une transmission 215 Cette composante contribue à assurer la confidentialité (O.NOIR et O.SECRET) des secrets lors de la personnalisation électrique de la TOE par une station de confiance de personnalisation. FPT_ITI.1 Détection de modification inter-tsf 216 Cette composante contribue à assurer l intégrité des échanges lors de la personnalisation électrique de la TOE par une station de confiance de personnalisation. Les objectifs O.NOIR et O.INTEGRITE sont ainsi en partie satisfaits. FPT_ITT.1 Protection élémentaire de données internes à la TSF 217 Les transferts de données entre deux entités de la TOE, physiquement distinctes doivent être sécurisés contre la modification (O.INTEGRITE) ou la divulgation (O.NOIR). FPT_ITT.3 Surveillance de l intégrité des données par la TSF 218 Cette composante spécifie que la TSF doit être capable de détecter la perte d intégrité (O.NOIR) de données transmises d une partie de la TOE à une autre (physiquement distincte) et prendre des mesures adaptées en cas d erreur (O.SECOURS). FPT_PHP.3 Résistance aux attaques physiques 219 Cette composante spécifie que la TOE est capable de résister à des attaques sur ses fonctions de sécurité (O.SECOURS) et de contribuer à préserver l intégrité et la confidentialité des données qu elle contient (O.NOIR). FPT_RCV.1 Recouvrement manuel Page 45

50 220 Après détection d un dysfonctionnement, la TOE doit impérativement être dans un état stable dit de confiance. Cet état se caractérise par un verrouillage complet des fonctions de sécurité. L unique recouvrement manuel possible est alors une personnalisation électrique de la TOE. L objectif O.SECOURS est ainsi en partie satisfait. FPT_RVM.1 Non contournement de la politique de sécurité 221 Cette composante impose que les fonctions de sécurité ne soient pas contournables, afin de préserver la sécurité des accès à la TOE (O.TOE-ACCES), l authentification des parties communicantes (O.AUTH), la confidentialité et l intégrité des biens contenus dans la TOE (O.NOIR) ou des biens échangés (O.INTEGRITE, O.SECRET), ainsi que la sécurité des biens à protéger en cas de dysfonctionnement (O.SECOURS) ou de vol (O.VOL). FPT_TDC.1 Consistance élémentaire des données de la TSF inter-tsf 222 Cette composante contribue à assurer une cohérence entre les interprétations des biens et variables d états internes de la TOE lors d un échange avec une composante de confiance des technologies de l information. Les objectifs (O.INTEGRITE, O.SECRET, O.AUTH) portant sur la protection des biens importés ou exportés sont ainsi en partie couverts. FPT_TST.1 Tests de la TSF 223 Les TSF doivent fournir un ensemble de tests qui permettent de s assurer de leurs bons fonctionnements par rapport à un modèle abstrait (FPT_AMT.1). En cas de détection d un dysfonctionnement par rapport à ce modèle des mesures conservatoires devront être prises pour contribuer à l objectif O.SECOURS Composante FTA FTA_SSL.3 Fonction d abandon de session 224 Après une période d inactivité, la TOE clot la session de l utilisateur et rétablit une session après ré-authentification de l utilisateur (O.TOE-ACCESS). FTA_TSE.1 Etablissement de session de la TOE 225 Une TSF propre à la TOE peut refuser une demande d accès suivant des paramètres propres à la TOE et définis par l autorité de sécurité compétente. L objectif de sécurité O.TOE-ACCES est donc enrichi Composante FTP FTP_ITC.1 Canal sûr inter-tsf 226 L authentification de l utilisateur demande un canal sûr entre l utilisateur et la TOE. Ce canal peut être sûr logiquement par l usage de fonctions cryptographiques Page 46

51 et/ou physiquement par emploi d un support d authentification protégé, comme par exemple, une carte à puce et un lecteur de carte sécurisé. Ce canal sûr contribue à satisfaire l objectif O.TOE-ACCES. Page 47

52 7.5 Dépendances des composantes fonctionnelles 227 Pour l évaluation de ce profil de protection, il est nécessaire de vérifier que toutes les dépendances sont satisfaites. Le tableau ci-dessous démontre l absence de dépendances internes non satisfaites. 228 Le symbole --- signifie que la composante n admet pas de dépendance. Composantes Noms Dépendances CC Satisfactions FCO_NRO.2 Obligation de preuve de l origine. FIA_UID.1 FIA_UID.2 FCS_CKM.2 Génération des clés cryptographiques basée sur des standards. FCS_CKM.3 or FCS_COP.1; FCS_CKM.7 FMT_MSA.2 FCS_CKM.4 FCS_CKM.7 FMT_MSA.2 FCS_CKM.4 Distribution des clés cryptographiques basée sur des standards. FDP_ETC.1 or FCS_CKM.1; FCS_CKM.7 FMT_MSA.2 FCS_CKM.2; FCS_CKM.7 FMT_MSA.2 FCS_CKM.7 Destruction des clés cryptographiques. FMT_MSA.2; FDP_ITC.1 or FCS_CKM.1 FMT_MSA.2; FCS_CKM.2 FCS_COP.2 Opération cryptographique basée sur des standards FMT_MSA.2; FDP_ITC.1 or FCS_CKM.1; FCS_CKM.7 FMT_MSA.2; FCS_CKM.2; FCS_CKM.7 FDP_ACC.2 Contrôle d accès total FDP_ACF.1 FDP_ACF.1 FDP_ACF.1 Contrôle d accès basé sur les attributs de sécurité. FDP_ACC.1; FMT_MSA.3 FDP_ACC.2; FMT_MSA.3 FDP_ETC.2 Exportation des données de l utilisateur avec attributs de sécurité. FDP_ACC.1 and/or FDP_IFC.1; FTP_ITC.1 or FTP_TRP.1; FPT_TDC.1 FDP_ACC.2; FTP_ITC.1 ; FPT_TDC.1 FDP_IFC.1 Contrôle de flux d un sous-ensemble d informations. FDP_IFF.1 FDP_IFF.1 Tab Dépendances des composantes d exigences Page 48

53 Composantes Noms Dépendances CC Satisfactions FDP_IFF.1 Attributs de sécurité simples. FDP_IFC.1; FMT_MSA.3 FDP_IFC.1; FMT_MSA.3 FDP_ITC.2 Importation de données de l utilisateur avec attributs de sécurité. FDP_ACC.1 and/or FDP_IFC.1; FTP_ITC.1 or FTP_TRP.1; FPT_TDC.1. FDP_ACC.2; FDP_IFC.1; FTP_ITC.1; FPT_TDC.1 FDP_SDI.2 Contrôle de l intégrité des données stockées et mesures conséquentes FDP_UCT.1 Confidentialité élémentaire de l échange de données FTP_ITC.1 or FTP_TRP.1; FDP_ACC.1 and/or FDP_IFC.1; FTP_ITC.1 FDP_ACC.2 and FDP_IFC.1; FDP_UIT.1 Intégrité de l échange de données FTP_ITC.1 or FTP_TRP.1; FDP_ACC.1 and/or FDP_IFC.1; FTP_ITC.1 FDP_ACC.2 and FDP_IFC.1 FIA_AFL.1 Action élémentaire en cas d échec d authentification de l utilisateur FIA_UAU.1 FIA_UAU.1 FIA_SOS.1 Vérification des secrets FIA_SOS.2 Génération des secrets par la TSF --- FIA_UID.2 Identification de l utilisateur avant action FIA_UAU.1 Temporisation de l authentification FIA_UID.1 FIA_UID.2 FIA_UAU.5 Mécanismes multiples d authentification. --- FIA_UAU.6 Ré-authentification --- Tab (Suite) - Dépendances des composantes d exigences Page 49

54 Composantes Noms Dépendances CC Satisfactions FMT_MSA.1 Gestion des attributs de sécurité FDP_ACC.1 or FDP_IFC.1; FMT_SMR.1 FDP_ACC.2; FDP_IFC.1; FMT_SMR.1; FMT_MSA.2 Attributs de sécurité sûrs ADV_SPM.1; FDP_ACC.1 or FDP_IFC.1; FMT_SMR.1; FMT_MSA.1 ADV_SPM.3; FDP_ACC.2; FDP_IFC.1; FMT_SMR.1; FMT_MSA.1 FMT_MSA.3 Initialisation statique des attributs de sécurité ADV_SPM.1 FMT_MSA.1 FMT_SMR.1 EAL retenu FMT_MSA.1 FMT_SMR.1 FMT_SMR.1 Rôles de sécurité FIA_UID.1 FIA_UID.2 FPT_AMT.1 Machine abstraite de test FPT_FLS.1 Conservation d un état sûr lors d une défaillance ADV_SPM.1 ADV_SPM.3 FPT_ITC.1 Confidentialité inter-tsf pendant une transmission FPT_ITI.1 Détection de modification inter-tsf FPT_ITT.1 Protection élémentaire de données internes à la TSF FPT_ITT.3 Surveillance de l intégrité des données de la TSF FPT_ITT.1 FPT_ITT.1 FPT_PHP.3 Résistance aux attaques physiques FPT_RCV.1 Recouvrement manuel FPT_TST.1; FMT_SMR.1; AGD_ADM.1; ADV_SPM.1 FPT_TST.1; FMT_SMR.1; AGD_ADM.1; ADV_SPM.3 FPT_RVM.1 FPT_TDC.1 Non contournement de la politique de sécurité Consistance élémentaire des données de la TSF inter-tsf Tab (Suite) - Dépendances des composantes d exigences Page 50

55 Composantes Noms Dépendances CC Satisfactions FPT_TST.1 Tests de la TSF FPT_AMT.1 FPT_AMT.1 FTA_SSL.3 Fonction d abandon de session FTA_TSE.1 Etablissement de session de la TOE FTP_ITC.1 Canal sûr inter-tsf Tab (Suite) - Dépendances des composantes d exigences Page 51

56 7.6 Dépendances des composantes d assurance 229 Pour l évaluation de ce profil de protection, il est nécessaire de vérifier que l ensemble des composantes d assurance retenu (voir Tab. 5.2, 5.3) est cohérent. 230 Par définition l ensemble des classes d assurance (Tab. 5.2) définissant le niveau EAL 5 est cohérent. Le tableau 7.7 démontre comment les dépendances de toutes les composantes d assurance (Tab. 5.3) retenues pour augmenter le niveau EAL5 ont été satisfaites. Composantes Noms Dépendances CC Satisfactions ADV_INT.3 Minimisation de la complexité ADV_IMP.2 ADV_LLD.1 ADV_IMP.2 ADV_LLD.1 ALC_FLR.3 Réparation systématique ATE_DPT.3 Test - Implémentation ADV_IMP.2 ADV_HLD.2 ADV_LLD.1 ATE_FUN.1 AVA_CCA.3 Analyse exhaustive des canaux cachés ADV_FSP.1 ADV_IMP.2 AGD_ADM.1 AGD_USR.1 ADV_IMP.2 ADV_HLD.3 ADV_LLD.1 ATE_FUN.1 ADV_FSP.3 ADV_IMP.2 AGD_ADM.1 AGD_USR.1 Tab Dépendances des composantes d assurance supplémentaires 231 Les dépendances des composantes d assurance retenues sont toutes satisfaites. Page 52

57 Annexe A Abréviations et Glossaire A.1 Abréviations - ASSO : Architecture de Sécurité pour les Systèmes Ouverts. - AC : Autorité de Certification de clés publiques. - CC : Common Criteria for Information Technology Security Evaluation. - CSP : Politique de Sécurité de Certification. Cette politique précise la gestion des certificats de clés gérés par les autorités de certification. Cette politique est nécessaire à tout déploiement d une infrastructure de gestion de clés et à toute utilisation à grande échelle de moyen de cryptographie asymétrique. Elle précise entre autres les conditions de génération de distribution, d expiration et de révocation des certificats et permet la reconnaissance de certificat entre deux infrastructures distinctes de gestion de clés. - EAL : Evaluation Assurance Level. Un ensemble prédéfini de composantes d assurance des CC. Le rédacteur d un PP ou d une ST doit choisir un ensemble de composantes parmi sept prédéfinies dans les CC (EAL1 ) EAL7) auxquelles il peut ajouter des composantes d assurance supplémentaires. - IGC : Infrastructure de Gestion de Clés. Cette infrastructure est l ensemble des tiers nécessaires à la gestion des clés d authentification et de signature et des clés de confidentialité. Les clés d intégrité sont certifiées par les AC et les clés de confidentialité sont gérées par les TPC. - IT : Information Technology. Terme générique qui désigne l ensemble des technologies de l information. - PP : Protection Profile. Ensemble d exigences de sécurité indépendantes de tous choix d implémentation pour une catégorie de TOE et qui répondent aux besoins de sécurité et d assurance d une communauté d utilisateurs. Dans le cadre d un appel d offre, un PP contribue à la définition dans le cahier des charges du périmètre et des exigences de sécurité du marché. - SF : Security Function. Une ou plusieurs parties d une TOE qui relèvent de l application de la TSP. Page 53

58 - SFP : Security Function Policy. Politique de sécurité appliquée à une SF. - SoF : Strength of Function. Caractéristique des fonctions de sécurité de la TOE représentant l effort minimum nécessaire à fournir pour mettre en échec les mesures de sécurité de la TOE en attaquant directement ses mécanismes de sécurité. Les CC distinguent trois niveaux de force : basique, moyen ou fort. - ST : Security Target. Il s agit d un ensemble d exigences de sécurité et de spécifications pris comme base pour l évaluation d une TOE particulière. Un profil de protection (PP) est indépendant d une solution technique. A contrario, la cible de sécurité (ST) est dédiée à un produit ou à un système précis. L introduction et les chapitres 5 et 7 d une ST sont plus précis que ceux d un PP. - TOE : Target of Evaluation (ou cible d évaluation). - TPC : Tierce Partie de Confiance. - TSF : TOE Security Functions. Ensemble constitué de toutes les composantes de la TOE relevant de l application de la TSP. - TSP : TOE Security Policy. Ensemble de règles qui régit la manière dont les informations et les ressources sont gérées, protégées et distribuées dans la TOE. - TSC : TOE Scope of Control. Champ d application du contrôle de la TOE. A.2 Glossaire Agrément : reconnaissance formelle que le produit ou système évalué peut protéger des informations jusqu à un niveau spécifié dans des conditions d emploi définies [900]. Attributs de sécurité : informations (telles que l identité, le niveau d habilitation, le besoin d en connaître, etc.) relatives à un utilisateur autorisé, permettant d établir ses droits et privilèges. Authentification : procédure de vérification de l identité des parties communicantes et de l intégrité des messages. Autorité de certification (AC) : tierce partie de confiance pour la génération, la signature et la publication des certificats de clés publiques. Autorité de sécurité (AS) : entité responsable de la définition, de l implémentation et de la mise en oeuvre d une politique de sécurité. Page 54

59 Bi-clé : couple clé publique, clé privée (utilisées dans des algorithmes de cryptographie asymétriques). Certificat : ensemble de données identifiant un utilisateur et une clé. Ces données sont signées par une autorité de certification. Le certificat est défini dans la recommandation X 509 version 3 de l ANSI. Chiffrement: transformation cryptographique de données produisant un cryptogramme. [ISO ] Chiffrement de bout en bout : chiffrement de données à l intérieur ou au niveau du système extrémité source, le déchiffrement correspondant ne se produisant qu à l intérieur, ou au niveau du système extrémité de destination. [ISO ] Chiffrement de liaison : application particulière du chiffrement à chaque liasion du système. Le chiffrement de liaison implique que les données soient du texte en clair dans les entités relais. [ISO ] Clé de chiffrement: série de symboles commandant les opérations de chiffrement et de déchiffrement. [ISO ] Clé de session: clé dont la validité dure le temps d une session. Clés publiques : clés librement publiables et nécessaires à la mise en œuvre d un moyen ou d une prestation de cryptologie pour des opérations de chiffrement ou de vérification de signature. Clés privées : une clé privée est associée à une clé publique pour former un bi-clé. Clés secrètes : clés volontairement non publiées nécessaires à la mise en œuvre d un moyen ou d une prestation de cryptologie pour des opérations de chiffrement ou de déchiffrement. Client : entité demandant un service. Client-Serveur: communication mettant en relation un client et un serveur. Client Sécurisé ou Serveur Sécurisé : client ou serveur ayant besoin des services de sécurité. Condensat : chaîne de caractères produite par une fonction de hachage [ISO ]. Confidentialité : propriété d une information qui n est ni disponible, ni divulguée aux personnes, entités ou processus non autorisés. [ISO ] Confidentiel Défense : cette mention est réservée aux informations qui ne présentent pas en elles-mêmes un caractère secret mais dont la connaissance, la Page 55

60 réunion ou l exploitation peuvent conduire à la divulgation d un secret intéressant la Défense nationale et la sûreté de l Etat. [Article 5 du décret n du 12 mai 1981 relatif à l organisation de la protection des secrets et des informations concernant la Défense Nationale et la sûreté de l Etat]. Contexte de sécurité: ensemble des éléments nécessaires pour assurer les services de sécurité. Cryptogramme: données obtenues par l'utilisation du chiffrement. Le contenu sémantique des données résultantes n'est pas compréhensible. [ISO ] Cryptographie: discipline incluant les principes, moyens et méthodes de transformation des données, dans le but de cacher leur contenu, d empêcher que leur contenu ne passe inaperçu et/ou d empêcher leur utilisation non autorisée.[iso ] Déchiffrement: opération inverse d'un chiffrement réversible. [ISO ] Distribution : délivrance par une autorité de distribution aux parties communicantes des clés à mettre en œuvre pour chiffrer ou déchiffrer des informations, y compris, le cas échéant, des éléments propres à d autres abonnés. Domaine: ensemble des ressources et entités sur lesquelles s'applique une même politique de sécurité, cet ensemble étant administré par une autorité unique. Donnée : représentation d une information sous une forme conventionnelle, destinée à faciliter son traitement [900], [FEROS]. Entité : individu utilisateur, processus ou serveur sécurisé. Entité sujet: élément du modèle fonctionnel d'un service de sécurité qui désigne l'acteur ou le bénéficiaire principal de ce service (par exemple un individu vis-à-vis du service d'authentification ou de contrôle d'accès). Entité objet: élément du modèle fonctionnel d'un service de sécurité qui désigne la cible ou le bénéficiaire de ce service (par exemple une ressource ou une information vis-à-vis du service de contrôle d'accès). Entité fonctionnelle: élément du modèle fonctionnel d'un service de sécurité qui désigne une entité considérée du point de vue de son comportement, indépendamment de sa réalité physique ou technique. Evaluation : estimation de la sécurité d un produit ou d un système par rapport à des critères d évaluation définis [900]. Fonction de hachage: fonction qui transforme une chaîne de caractères en une chaîne de caractères de taille inférieure et fixe. Cette fonction satisfait deux propriétés. Il est difficile pour une image de la fonction de calculer l antécédent Page 56

61 associé. Il est difficile pour un antécedent de la fonction de calculer un antécédent différent ayant la même image. Fonction de service: action attendue d un produit (ou réalisée par lui) pour répondre à un élément du besoin d un utilisateur donné (source NF X ). Le terme utilisateur désigne ici des personnes ou des entités fonctionnelles du système. Homologation : autorisation d utiliser, dans un but précis ou dans des conditions prévues, un produit ou un système. C est l autorité responsable de la mise en oeuvre du produit ou du système qui délivre cette autorisation, conformément à la réglementation en vigueur [900]. Identification : procédé permettant de reconnaître un utilisateur de manière sûre par la récupération de données qui lui sont propres. Information : élément de connaissance susceptible d être représenté à l aide de conventions pour être conservé, traité ou communiqué [FEROS]. Renseignement ou élement de connaissance susceptible d être représenté sous une forme adaptée à une communication, un enregistrement ou un traitement [900] Intégrité : propriété assurant que des données n ont pas été modifiées ou détruites de façon non autorisée. [ISO ] Mécanisme de sécurité: logique ou algorithme qui implémente par matériel ou logiciel une fonction particulière dédiée à la sécurité ou contribuant à la sécurité. [ITSEC] Politique de sécurité: ensemble des critères permettant de fournir des services de sécurité. [ISO ] Politique de sécurité technique : ensemble des lois, règles et pratiques qui régissent le traitement des informations sensibles et l utilisation des ressources par le matériel et le logiciel d un système d information ou d un produit. [ITSEC] Répudiation : fait de nier avoir participé à des échanges, totalement ou en partie. Révocation : annonce qu une clé privée a perdu son intégrité. Le certificat de la clé publique correspondante ne doit plus être utilisé. Service: regroupement cohérent de fonctions de service visant à répondre à un élément du besoin d un utilisateur ou d entités fonctionnelles du système. Sauf précision contraire, dans le présent document, le terme service désigne un regroupement de fonctions de sécurité ou de fonctions assurant le support de cellesci. Session : une session représente l intervalle de temps entre le début d un échange ou d une communication et sa fin. Page 57

62 Signature numérique: données ajoutées à une unité de données, ou transformation cryptographique d'une unité de données, permettant à un destinataire de prouver la source et l'intégrité cette unité en la protégeant contre la contrefaçon (par le destinataire par exemple). [ISO ]. Système d information : tout moyen dont le fonctionnement fait appel à l électricité et qui est destiné à élaborer, traiter, stocker, acheminer, présenter ou détruire l information. [900] Système ouvert: système dont chacun des composants est indépendant de tout constructeur. Système non-propriétaire. Système comprenant des interfaces de communication normalisées entre ses composantes. Système de chiffrement à clé symétrique (dit à clé secrète) : tout système dans lequel les opérations de chiffrement et de déchiffrement font appel à la même clé, la clé devant rester secrète. Système de chiffrement à clé asymétrique (dit à clés publiques) : tout système dans lequel les opérations de chiffrement et de déchiffrement font appel à une clé différente. Contrairement à la clé de déchiffrement (dite clé privée) qui doit rester secrète, la clé de chiffrement (dite clé publique) est publiée. La clé de chiffrement et la clé de déchiffrement forment un couple (dit couple de clés asymétriques ou biclés) dont les éléments sont mathématiquement dépendants. Tierce partie de confiance (TPC) : organisme habilité à gérer des conventions secrètes pour le compte d autrui. Zonage : le principe du zonage Tempest est de délimiter, à l intérieur d un domaine contrôlé, une ou plusieurs zones qui présentent, pour la propagation d un signal rayonné, des niveaux d affaiblissement dont les valeurs se situent dans une plage donnée [495]. Page 58

63 Annexe B Bibliographie B.1 Document relatif aux messageries sécurisés [Ad-hoc] Messagerie électronique pour l administration française, version 12/11/97. Document rédigé par le groupe de travail Messagerie de la sous commission n 1 de la CISSI. B.2 Documents relatifs aux critères communs [CC v2] Common Criteria for Information Technology Security Evaluation, Version 2.0, Draft. [TTP_PP] Profil de Protection pour les tierces parties de confiance, TTP_PP, version 0.13, dated 9/10/97. B.3 Documents relatifs à la réglementation française [495] Directive de zonage Tempest - Protection contre les signaux compromettants, N 495 SGDN/ DISSI / SCSSI. Ce document est classifié Diffusion Restreinte. [500] Instruction interministerielle relative au chiffre dans la sécurité des systèmes d information, N 500 bis / SGDN/ TTS / SSI / DR. Ce document est classifié Diffusion Restreinte. [600] Protection des informations sensibles ne relevant pas du secret de défense, N 600 DISSI/SCSSI, Mars Ce document est classifié Diffusion Restreinte. [901] Recommandation pour la protection des systèmes d information traitant des information sensibles non classifiées de défense. N 901/DISSI/SCSSI. Ce document est classifié Diffusion Restreinte. [900] Instruction générale interministérielle sur la sécurité des systèmes d information qui font l objet d une classification de défense pour eux-mêmes ou pour les informations traitées. N 900/DISSI/SCSSI/DR. Ce document est classifié Diffusion Restreinte. [EBIOS] Expression des Besoins et Identification des Objectifs de Sécurité, Guide Technique SGDN/SCSSI, version Page 59