PROFIL DE PROTECTION INFRASTRUCTURE DE GESTION DES … · B.4 Documents relatifs à la...

Commission Interministériellepour la Sécurité des Systèmes d’Information

PROFIL DE PROTECTION

INFRASTRUCTURE DE GESTION

DES CLES

6 janvier 1999

Version 1.9

Sommaire

Sommaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Chapitre 1Infrastructure de gestion des clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1 Identification du profil de protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Présentation du profil de protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapitre 2Description de la cible d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Définition de la cible d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Les services de la TOE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Chapitre 3Environnement de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 L’environnement physique de la TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Connexion de la TOE à son environnement. . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Les acteurs de la TOE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.4 Typologie des attaquants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.5 Les biens à protéger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.6 Les menaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.7 Description de la politique de sécurité organisationnelle. . . . . . . . . . . . . . . . . 143.8 Les hypothèses d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapitre 4Objectifs de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Objectifs de sécurité portant sur la cible d’évaluation . . . . . . . . . . . . . . . . . . . 164.2 Objectifs de sécurité portant sur l’environnement de la TOE . . . . . . . . . . . . . 17

Chapitre 5Exigences de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1 Exigences fonctionnelles de la cible d’évaluation . . . . . . . . . . . . . . . . . . . . . . 205.2 Liste des exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.3 Exigences d’assurance des TI de la cible d’évaluation. . . . . . . . . . . . . . . . . . . 50

Chapitre 6Notes d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.1 Traitement d’informations de sensibilité différentes . . . . . . . . . . . . . . . . . . . . 546.2 Législation applicable en France . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Chapitre 7Justification du profil de protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.1 Menaces non couvertes par le profil de protection. . . . . . . . . . . . . . . . . . . . . . 587.2 Justification des objectifs de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.3 Tableau croisé. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647.4 Justificatif des exigences de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.5 Dépendances des composants d’exigences. . . . . . . . . . . . . . . . . . . . . . . . . . . . 817.6 Dépendances des composantes d’assurance. . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Annexe AAbréviations et Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

A.1 Abréviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87A.2 Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Annexe BBibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

B.1 Documents relatifs aux IGC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93B.2 Profils de protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93B.3 Documents relatifs aux critères d’évaluation de la sécurité des systèmes

d’informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94B.4 Documents relatifs à la réglementation française. . . . . . . . . . . . . . . . . . . . . . . 94

Chapitre 1

Infrastructure de gestion des clés

1.1 Identification du profil de protection

1 Titre : Profil de protection infrastructure de gestion des clés (PP_ IGC).

2 Version : v1.9, du 6 janvier 1999.

3 Identifiant : PP/ 9805

4 Référence à d’autres profils de protection : PP/ 9804 (PP_OSM)

5 Ce profil de protection est conforme à la version 2.0 des Critères Communs.

1.2 Présentation du profil de protection

6 Ce profil de protection définit les exigences de sécurité nécessaires à la mise enoeuvre d’une infrastructure de gestion de clés (notée IGC) pour le traitementd’informations jusqu’à un niveau classifié de défense.

7 La cible d’évaluation (notée TOE) décrite dans ce document est constituée d’unensemble de composantes des technologies de l’information telles que des autoritésde certification, des autorités d’enregistrement, des tiers de confiance et des tiersd’horodatage.

8 Le rôle d’une IGC est d’assurer la gestion des certificats de clés publiques et deprotéger la confidentialité des secrets qu’elle gère.

9 Les applications susceptibles de bénéficier des services de la TOE sont par exempleune messagerie, du commerce électronique ou encore la sécurisation d’infrastructures de réseaux. Pour le traitement d’informations jusqu’au niveau desensibilité classifié de défense, les applications utilisant la TOE doivent être deconfiance, c’est-à-dire avoir été l’objet d’une évaluation selon les critèresd’évaluation et les référentiels en vigueur. Ce PP ne prend pas en compte ladiminution du niveau d’assurance garanti dans ce PP due à l’utilisation des servicesde la TOE pour des applications qui ne sont pas de confiance.

10 Des exigences complémentaires peuvent s’avérer nécessaires à la protection desinformations classifiées de défense, en particulier lorsque l’IGC est soumise à desmenaces autres que celles prises en compte par ce profil de protection (cf. chapitre7). Des exigences complémentaires peuvent aussi découler des choix de réalisationet d’implémentation de la cible d’évaluation, choix qui restent ouverts au niveau dece profil de protection.

Chapitre 2

Description de la cible d’évaluation

2.1 Définition de la cible d’évaluation

11 La cible d’évaluation (notée TOE) est composée d’un ensemble de composantes destechnologies de l’information parmi celles décrites ci-dessous.

a) Une ou plusieurs autorités d’enregistrement (notées AE): une AE représentel’interface entre l’IGC et les utilisateurs. Une AE collecte et vérifie les in-formations nécessaires à son identification et ses droits pour mettre enoeuvre la gestion des certificats d’un utilisateur. L’AE est chargée de com-muniquer les informations nécessaires à l’autorité de certification et/ou à latierce partie de confiance de l’IGC.

b) Une ou plusieurs autorités de certification (notées AC): une AC signe et pu-blie des certificats de clés publiques d’utilisateurs à partir des informationsvalidées qui lui sont communiquées par une AE. Elle peut assurer les fonc-tions d’une AE. L’ordonnancement des AC est hiérarchique et/ou maillé.Une TOE est constituée d’au moins une AC.

c) Un horodateur (noté HD) : ce tiers délivre un temps de référence partagé partoutes les composantes de la TOE. Une dérive de temps maximale (et pou-vant être nulle à une précision donnée) est définie entre les différentes com-posantes de la TOE.

d) Une autorité administrative (notée AA) : cette autorité politique définit etfait appliquer les politiques de certification et les déclarations relatives auxprocédures de certification.

Tab. 2.1 - Description de la TOE

2.2 Les services de la TOE

12 La TOE contribue à la sécurisation des flux d’informations internes à la TOE :

- entre composantes de l’IGC,

13 et en externe à la TOE :

- entre un utilisateur et la TOE,- entre une TOE et une IGC (sans aucune hypothèse de confiance),- entre plusieurs TOE.

14 La TOE offre trois types de services:

- les services vitaux de sécurité (notés SVS),- les services élémentaires,- les services complémentaires.

AC

ACHD

AE

TOE

Produit IT de confianceProduit IT

Utilisateur

Utilisateur distant

Transfert interne à la TOE

TransfertTransfert hors

Chemin de

Chemin de confiance

Fonctions

inter-TSF

confianceinter-TSF distantes

du champd’action des TSF

AA

15 Les services vitaux de sécurité sont:

- l’identification et authentification de l’utilisateur et des exploitants,- la révocation de certificats (demande de révocation, action de révoquer),- l’archivage des certificats,- l’audit et l’imputabilité des services de sécurité.

16 Les services élémentaires sont:

- l’enregistrement et le renouvellement des utilisateurs,- la génération des certificats,- la vérification des certificats,- la publication des certificats,- la publication des certificats révoqués,- un service d’accords de certification avec d’autres IGC.

17 Les services complémentaires sont:

- la génération de clés de confidentialité,- la génération de clés d’authentification,- la distribution des clés,- le recouvrement de clés (pour les utilisateurs ou les autorités légales),- la délivrance d’une datation de confiance.

Chapitre 3

Environnement de sécurité

3.1 L’environnement physique de la TOE

18 Les composantes de la TOE sont des plate-formes informatiques équipées au moinsd’une ressource cryptographique et d’applicatifs (base de données, logiciel demessagerie, applicatifs d’enregistrement, de certification, d’horodatage, depublication, réseaux locaux et/ou étendu, etc.).

19 L’accès physique à une composante de la TOE est un facteur qui doit être pris encompte dans la politique de sécurité qui définit les conditions d’usage de la TOE.Les composantes de la TOE sont protégées par un contrôle d’accès logique et/ouphysique.

3.2 Connexion de la TOE à son environnement

20 Les flux d’informations de la TOE définis en 2.3 transitent par des réseauxconsidérés dans ce profil de protection comme totalement dépourvus de services desécurité.

3.3 Les acteurs de la TOE

21 La TOE délivre une prestation de cryptographie pour le compte d’utilisateurs. Cet-te prestation consiste à signer le certificat de clé publique d’un utilisateur et à offrirdes services de gestion des certificats générés et des bi-clés manipulés.

22 Un utilisateur est une entité (utilisateur humain ou entité externe des technologiesde l’information) qui interagit avec la TOE par l’intermédiaire d’une application lo-gicielle accessible sur un poste informatique. L’IGC fournit à l’utilisateur les certi-ficats de clés publiques et des secrets nécessaires à des authentifications et à lasécurisation de messages.

23 Le fonctionnement de la TOE requiert un personnel formé pour délivrer les presta-tions cryptographiques. Les personnels autorisés à mettre en oeuvre les services dela TOE sont nommés exploitants. Ces exploitants sont des utilisateurs particuliersauxquels l’autorité de sécurité compétente de l’IGC a délivré des droits nécessaires.On distingue quatre rôles d’exploitants:

- l’opérateur, qui est responsable de la mise en oeuvre des services de lacomposante de la TOE pour laquelle il opère. Il est chargé de lancerl’exécution des fonctions cryptographiques.

- l’administrateur, qui fait respecter les politiques de certification et lesdéclarations relatives aux politiques de certification de la composante qu’il

administre. Il supervise les actions des opérateurs et est responsable desactions effectuées.

- le responsable de sécurité, qui est responsable de l’application de lapolitique de sécurité. Le responsable de sécurité de la TOE peut êtreconfondu avec le responsable de la sécurité des systèmes d’information dontla composante fait partie.

- l’ingénieur système, qui est chargé de l’administration système et réseau dela plateforme hébergeant la composante.

3.4 Typologie des attaquants

24 Les attaquants potentiels de la cible d’évaluation sont :

a) les utilisateurs autorisés mais pouvant omettre ou falsifier des donnéespersonnelles d’enregistrement,

b) un exploitant autorisé mais pouvant commettre une erreur par inadvertance,

c) les personnes ou machines qui disposent de moyens d’investigation etd’action sur la TOE et sur les réseaux supports.

3.5 Les biens à protéger

25 La TOE est destinée à protéger des informations sensibles nommées biens :

- les biens publics sont ceux publiés ou distribués par la TOE. Il s’agitessentiellement des certificats de clés publiques. Ces biens doivent êtreprotégés en intégrité. Pour les besoins propres de l’IGC les biens publicsdoivent être également protégés en disponibilité (pour les besoins desutilisateurs, la disponibilité des biens publics relève d’une politique depublication). Les biens publics protégés également en confidentialité sontappelés biens secrets utilisateurs.

- les biens secrets:

1) les biens secrets propres aux composantes de la TOE et appelésbiens secrets de la TOE (clés privées, informations classifiées dedéfense manipulées par l’IGC telles que les traces d’audit),

2) les biens secrets propres aux utilisateurs et appelés biens secretsutilisateurs (clés privées, clés symétriques, informationspersonnelles, rôle, fonction, appartenance ou non à un organisme).

Ces secrets doivent être protégés en intégrité et en confidentialité à l’aided’une ressource cryptographique. Dans le cas où les informations traitéessont classifiées de défense, cette ressource cryptographique devra êtreévaluée conformément au PP_OSM.

26 Le fonctionnement de l’IGC et les prestations qu’elle délivre nécessitent la créationet la conservation d’archives qui sont soit des biens publics soir des biens secrets.

27 Dans la suite de ce document, on entend par biens l’ensemble des biens publics etbiens secrets.

3.6 Les menaces

28 Toutes les menaces auxquelles la TOE est soumise ne sont pas prises en comptedans ce PP. Une liste non exhaustive de menaces non couvertes par ce PP mais iden-tifiées comme pouvant porter atteinte à la sécurité des services de l’IGC figure auchapitre 7.

3.6.1 Menaces portant sur la TOE

29 M.DYSFONC : Le dysfonctionnement non détecté d’une composante de la TOEpeut entraîner une perte de l’intégrité et de la confidentialité des biens gérés parcette composante, ainsi qu’une perte de l’intégrité fonctionnelle des services.

30 M.INTRUSION : Un attaquant obtient un accès physique ou logique non autoriséà une composante de la TOE, provoquant une perte de confidentialité des bienssecrets, une perte d’intégrité des biens ou une perte de disponibilité des biens et desservices.

31 Remarque: une intrusion peut être la conséquence d’un manque de contrôle d’accès.Un accès illicite physique peut entraîner entre autres le vol d’un matériel et rendreainsi indisponible des biens ou des services.

32 M.INITIALISATION : Lors de l’initialisation d’une composante de la TOE, unattaquant prend connaissance d’un bien secret.

33 Remarque : l’étape d’initialisation est une phase sensible du cycle de vie d’unecomposante.

34 M.CLONAGE : Un attaquant usurpe les services d’une composante de la TOE parcopie du support physique ou par simulation logique.

35 M.RESIDUEL : Des informations résiduelles peuvent persister sur un supportlogique (fichier temporaire, mémoire tampon, versions antérieures, etc.) ouphysique (disque dur, disquette, bande magnétique, etc.). La ré-utilisation de cessupports peut provoquer une perte de confidentialité des biens secrets éventuelle-ment contenus dans les informations résiduelles.

36 M.DENI : Un utilisateur ou un exploitant autorisé nie avoir commis une interactionavec la TOE sans que ses actes ne puissent lui être imputés, menaçant l’intégritéfonctionnelle de la TOE.

37 M.INCONSISTANT : Une action sur un bien géré par la TOE entraîne des incon-sistances dans la TOE.

38 Remarque : par exemple, un certificat est révoqué au niveau d’une composante etsuspendu au niveau d’une autre.

39 M.USAGE : Un certificat est utilisé à d’autres fins que celles précisées dans la poli-tique de certification selon laquelle il a été émis.

40 M.INVALIDE : L’utilisation volontaire ou non d’un certificat invalide (révoqué,au-delà de sa période de validité, etc.) constitue une menace sur l’intégrité et éven-tuellement la confidentialité des biens publics ou secrets manipulés par la TOE.

41 Remarque: l’utilisation d’un certificat invalide peut permettre à un attaquantd’usurper des droits ou accéder à des biens.

3.6.2 Menaces portant sur l’environnement de la TOE

42 M.MAINTENANCE : La non-maintenabilité des composants matériels ou logi-ciels de l’IGC (produits IT, logiciels, etc.) est une menace à la disponibilité et àl’intégrité fonctionnelle des services de la TOE.

43 M.SATURATION : La saturation des postes de travail ou des réseaux utilisés parla TOE peut rendre indisponible les services et les biens gérés par la TOE.

44 M.SINISTRE : Un sinistre physique (perte d’alimentation électrique, feu,inondation, foudre, tremblement de terre, godzilla, etc...) endommage ou détruit unecomposante de la TOE et rend indisponible les services ainsi que les biens publicset secrets gérés par la composante sinistrée (cf. chapitre 6).

45 M.VOL-SUPPORT : Le vol d’un disque ou d’une disquette ayant contenu oucontenant des biens secrets peut provoquer une perte de la confidentialité de cesbiens, ainsi qu’une perte de disponibilité de l’ensemble des biens.

46 M.VIRAL : Une attaque virale du poste informatique d’une composante ou laréception d’un bien contaminé peut porter atteinte à l’intégrité du système d’exploi-tation, des pilotes logiques d’extension de la ressource cryptographique et des bienssecrets gérés par cette composante.

47 M.MOYEN : Un exploitant met en oeuvre un moyen informatique non autorisé, surun poste informatique de la TOE.

48 M.FLUX-EXTERNE : Un attaquant prend connaissance ou modifie un bien secretlors d’un échange entre la TOE et un utilisateur.

49 Remarque : cette menace porte sur les données d’authentification délivrées auxutilisateurs par la TOE comme par exemple les mots de passe d’initialisation; elleporte également sur le secret du recouvrement légal. Si la TOE génère les clésprivées pour le compte des utilisateurs alors cette menace est majeure.

50 M.INTER-IT : Les échanges d’information entre une TOE évaluée selon ce profilde protection et un produit IT (évalué ou non selon des critères d’évaluation de lasécurité des systèmes d’information) ne sont pas le résultat d’accords de reconnais-

sance mutuelle ni de définitions précises des services fournis. Cette menace peutporter atteinte à l’intégrité fonctionnelle de la TOE, l’intégrité de l’ensemble desbiens et la confidentialité des biens secrets.

51 Remarque: cette menace peut être le résultat de l’absence d’accords sur les procé-dures d’échanges entre deux produits, l’absence ou une faille de sécurité du proto-cole de certification (lorsque le produit IT est une autre IGC). Elle peut causer lamauvaise interprétation du format d’un certificat.

3.7 Description de la politique de sécurité organisationnelle

52 P.UTILIS : Les fonctions de la TOE doivent être limitées aux services qu’ellefournit et décrits dans le chapitre 2.

53 P.ROLES : Les exploitants de la TOE n’ont accès qu’aux fonctions nécessaires àl’accomplissement des tâches qui leur sont attribuées. Leurs rôles, responsabilitéset attributions doivent être définis et conformes au document [ROLES_IGC].

54 P.RECOUVR : Une politique de sécurité de l’IGC définit les conditions de miseen oeuvre du service de recouvrement de clés de confidentialité pour le compted’utilisateurs, (perte de clé, départ d’un employé détenteur d’une bi-clé deconfidentialité, etc.) ou à des fins légales [L90-1170].

55 P.CERT : La TOE gére les certificats conformément à une politique de certificationet une déclaration relative aux procédures de certification [PC2] approuvées parl’autorité de sécurité compétente. Cette politique décrit également les accords dereconnaissance mutuelle entre IGC.

56 P.PUBLICATION : Le service de publication de la TOE met en oeuvre une poli-tique de sécurité contrôlant les accès à risque (accès répétés, requêtes destinées àsaturer le service, récupération par collecte d’informations d’une information clas-sifiée de défense, etc.).

57 Remarque : L’information de l’appartenance d’un utilisateur à une administrationn’est pas forçément une donnée classifiée de défense. Par contre, la liste de tous lespersonnels de cette administration peut être classifiée de défense.

58 P.PLAN-SECOURS : L’IGC prend en compte une politique définissant les moda-lités d’un plan de secours à appliquer en cas de sinistre. Ce plan doit être adapté àdivers niveaux de gravité du sinistre (de la panne matérielle jusqu’à la destructionde la totalité d’un site) (Cf. Chapitre 6).

3.8 Les hypothèses d’utilisation

3.8.1 Les hypothèses sur l’administration et l’utilisation de la TOE

59 H.USAGE : La TOE est administrée et utilisée par des personnels habilités etformés aux techniques nécessaires à l’administration et à l’utilisation de la TOE. Ilsdisposent des moyens nécessaires, et sont disponibles pour effectuer ces tâches.

60 H.RESP : Les utilisateurs et clients de la TOE connaissent les responsabilités finan-cières, civiles et pénales associées à l’usage et à l’administration de la TOE.

61 H.RESSOURCE : Les ressouces cryptographiques utilisées par les composantesde la TOE sont conformes au [PP_OSM].

Chapitre 4

Objectifs de sécurité

4.1 Objectifs de sécurité portant sur la cible d’évaluation

4.1.1 Objectifs portant sur les services de la TOE

62 O.ACCES : La TOE identifie et authentifie les utilisateurs et exploitants demanière unique. L’identification et l’authentification conditionne les autorisationsd’accès aux biens et aux fonctions de la TOE.

63 O.ACCUSE : La TOE est en mesure de prouver la réception de biens publics ousecrets.

64 O.ENREGISTREMENT : L’enregistrement d’un utilisateur a lieu après vérifica-tion des justificatifs fournis par l’utilisateur (relatifs à son identité, sa fonction,l’autorisation des son autorité de sécurité, etc.).

65 O.RESSOURCE : Les ressources de cryptologie utilisés pour la génération et lavérification des signatures, le chiffrement et le déchiffrement d’informations four-nissent les services attendus avec un niveau d’assurance donné.

66 O.REVOC : La TOE peut révoquer les certificats de clés publiques ou les clésprivées d’un utilisateur, d’un exploitant ou d’une composante de la TOE.

67 O.AUDIT : Un service de l’IGC garantit l’enregistrement des événements quiproduits sur la TOE ou par la TOE suite à une action extérieure, afin de permettrela traçabilité et l’imputabilité des actions. Les journaux d’audit résultant doiventêtre disponibles et fréquemment contrôlés.

68 O.ARCHIVES : La définition et la protection des biens archivés par la TOE estdéfinie, conformément à la politique de certification mise en oeuvre par la TOE.

69 O.VERIF : Tout bien publié par la TOE peut être authentifié.

70 O.EXPORT : Sur demande d’un utilisateur (conformément à la politique decertification) ou d’autorités légales (conformément à la loi [96-659]), la TOE est enmesure de mettre en oeuvre les biens secrets des utilisateurs qu’elle gère.

71 Remarque : la TOE n’est en mesure de réaliser la mise en oeuvre que des bienssecrets à usage de protection de la confidentialité.

72 O.DATE : Un temps de référence existe et est utilisé par la TOE.

4.1.2 Objectifs portant sur la TOE

73 O.INTEGRITE : Les biens exportés, importés ou gérés par la TOE sont protégésen intégrité.

74 Remarque : cet objectif porte sur les biens de la TOE (biens gérés par la TOE) et surson environnement (biens exportés et importés par la TOE).

75 O.CONFIDENTIALITE : Les biens secrets exportés, importés ou gérés par laTOE sont protégés en confidentialité.

76 Remarque : cet objectif porte sur la TOE (biens secrets gérés par la TOE) et sur sonenvironnement (biens secrets exportés et importés par la TOE).

77 O.DYSFONC : Aucun dysfonctionnement de la TOE ne permet l’exportation debiens secrets.

78 O.DISPO : Au moins les services vitaux de sécurité de la TOE sont disponibles etfonctionnellement intègres. En cas de problème (dysfonctionnement, sinistre, etc.)ils peuvent être récupérés sous un délai défini.

79 O.SEPARATION : Les biens gérés par la TOE sont regroupés en fonction de leursensibilité dans des domaines de sécurité distincts.

80 Remarque : par exemple, les domaines de sécurité permettant la génération dessecrets devront être séparés de ceux dédiés aux communications avec les compo-santes de l’IGC ou avec les utilisateurs.

81 O.ADMINISTRATION : Il existe un contrôle de la cohérence des actions sur lesbiens gérés par la TOE. Les actions des exploitants sur la TOE doivent laisser laTOE dans un état stable et de confiance.

4.2 Objectifs de sécurité portant sur l’environnement de la TOE

82 O.PLAN-SECOURS : Un plan de secours est opérationnel et respecte des délaisde recouvrement de services conformes à la politique de certification utilisée parl’IGC [VAR_TEMPS].

83 O.RESPONSABLE : Les utilisateurs et exploitants de la TOE connaissent lesresponsabilités financières, civiles et pénales associées à l’usage de la TOE.

84 O.GUIDE : L’exploitation et l’usage de la TOE sont correctement documentés.

85 O.DESTRUCTION : La réutilisation de supports physiques et logiques ne doit pasporter atteinte à la sécurité des biens secrets qu’ils contiennent.

86 O.ENV-INFO : L’exploitation et l’administration de l’environnement informa-tique de la TOE (plate-forme informatique, supports réseaux) ne porte pas atteinte

à la protection des biens secrets gérés par la TOE ni à la disponibilité des servicesde la TOE.

87 O.COHERENT : La TOE est en mesure de détecter les incohérences d’interpréta-tion des biens échangés entre la TOE et un autre produit IT (évalué ou non descritères d’évaluation des technologies de l’information).

88 Remarque : les incohérences d’interprétation peuvent porter sur le niveau d’assu-rance garanti, les services fournis, le format des biens échangées, etc.

Chapitre 5

Exigences de sécurité

5.1 Exigences fonctionnelles de la cible d’évaluation

89 Le tableau ci-dessous présente la liste des exigences fonctionnelles inclues dans ceprofil de protection.

90 Les raffinements qui ne sont pas définis dans ce chapitre devront être complétés lorsde la rédaction de la cible de sécurité.

Tab. 5.1 -Composantes de sécurité

Composantes Nom

FAU_ARP.1 Security alarms

FAU_GEN.1 Audit Data Generation

FAU_GEN.2 User identity association

FAU_SAA.2 Profile based anomaly detection

FAU_SAR.1 Audit review

FAU_SAR.2 Restricted audit review

FAU_SAR.3 Selectable audit review

FAU_SEL.1 Selective audit

FAU_STG.2 Guarantees of audit data availability

FAU_STG.4 Prevention of audit data loss

FMT_MOF.1 Management of security function behaviour

FMT_MSA.1 Management of security attributes

FMT_MSA.2 Secure security attributes

FMT_MSA.3 Static attribute initialisation

FMT_MTD.1 Management of TSF data

FMT_MTD.2 Management of limits on TSF data

FMT_MTD.3 Secure TSF data

FMT_REV.1 Revocation

FMT_SAE.1 Time-limited authorisation

FMT_SMR.2 Restrictions on security roles

FMT_SMR.3 Assuming roles

FCO_NRO.2 Enforced proof of origin

FCO_NRR.1 Selective proof of receipt

FCS_CKM.1 Cryptographic key generation

FCS_CKM.2 Cryptographic key distribution

FCS_CKM.3 Cryptographic key access

FCS_CKM.4 Cryptographic key destruction

FCS_COP.1 Cryptographic operation

FDP_ACC.2 Complete access control

FDP_ACF.1 Security attribute based access control

FDP_DAU.2 Data authentication with identity of guarantor

FDP_ETC.2 Export of user data with security attributes

FDP_IFC.2 Complete information flow control

FDP_IFF.1 Simple security attributes

FDP_ITT.2 Transmission separation by attributes

FDP_ITT.3 Integrity monitoring

FDP_RIP.1 Subset residual information protection

FDP_SDI.2 Stored data integrity monitoring and action

FDP_UIT.1 Data exchange integrity

Composantes Nom

FDP_UIT.2 Source data exchange recovery

FIA_AFL.1 Authentication failure handling

FIA_ATD.1 User attribute definition

FIA_SOS.1 Verification of secrets

FIA_SOS.2 TSF Generation of secrets

FIA_UAU.2 User authentication before any action

FIA_UAU.3 Enforgeable authentication

FIA_UAU.5 Multiple authentication mechanisms

FIA_UAU.6 Re-authenticating

FIA_UID.2 User identification before any action

FPT_AMT.1 Abstract machine testing

FPT_FLS.1 Failure with preservation of secure state

FPT_ITA.1 Inter-TSF availability within a defined availabilitymetric

FPT_ITC.1 Inter-TSF confidentialité during transmission

FPT_ITI.1 Inter-TSF detection of modification

FPT_ITT.1 Basic internal TSF data transfer protection

FPT_ITT.3 TSF data integrity monitoring

FPT_PHP.2 Notification of physical attack

FPT_RCV.3 Automated recovery without undue loss

FPT_RCV.4 Function recovery

FPT_RPL.1 Replay detection

FPT_SEP.2 SFP domain separation

FPT_SSP.1 Simple trusted acknowledgement

Composantes Nom

5.2 Liste des exigences fonctionnelles

5.2.1 Composante FAU


91 FAU_ARP.1.1 The TSF shall take [assignment: list of the least disruptive actions]upon detection of a potential security violation.


92 FAU_GEN.1.1 The TSF shall be able to generate an audit record of the followingauditable events:

a) Start-up and shutdown of the audit functions;

b) All auditable events for the [selection: minimum, basic, detailed, not speci-fied] level of audit; and

c) [assignment: other specifically defined auditable events].

93 Le niveau minimal requis pour choisir la génération de données d’audit est le niveaubasique.

94 FAU_GEN1.2 The TSF shall record within each audit record at least the followinginformation:

FPT_STM.1 Reliable time stamps

FPT_TDC.1 Inter-TSF basic TSF data consistency

FPT_TRC.1 Internal TSF consistency

FPT_TST.1 TSF testing

FTA_SSL.1 TSF-initiated session locking

FTA_SSL.2 User-initiated locking

FTA_SSL.3 TSF-initiated termination

FTA_TSE.1 TOE session establishment

FTP_ITC.1 Inter-TSF trusted channel

FTP_TRP.1 Trusted path

Composantes Nom

a) Date and time of the event, type of event, subject identity, and the outcome(success or failure) of the event; and

b) For each audit event type, based on the auditable event definitions of thefunctional components included in the PP/ST, [assignment: other auditrelevant information]


95 FAU_GEN.2.1The TSF shall be able to associate each auditable event with theidentity of the user that caused the event.


96 FAU_SAA.2.1 The TSF shall be able to maintain profiles of system usage, wherean individual profile represents the historical patterns of usage performed by themember(s) of [assignment: specify the profile target group].

97 FAU_SAA.2.2 The TSF shall be able to maintain a suspicion rating associated witheach user whose activity is recorded in a profile, where the suspicion ratingrepresents the degree to which the user’s current activity is found inconsistent withthe established patterns of usage represented in the profile.

98 FAU_SAA.2.3 The TSF shall be able to indicate an imminent violation of the TSPwhen a user’s suspicion rating exceeds the following threshold conditions[assignment: conditions under which anomalous activity is reported by the TSF].


99 FAU_SAR.1.1 The TSF shall provide [assignment: authorised users] with thecapability to read [assignment: list of audit information] from the audit records.

100 FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for theuser to interpret the information.


101 FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records,except those users that have been granted explicit read-access.


102 FAU_SAR.3.1 The TSF shall provide the ability to perform [selection: searches,sorting, ordering] of audit data based on [assignment: criteria with logicalrelations].


103 The TSF shall be able to include or exclude auditable events from the set of auditedevents based on the following attributes:

a) [selection: object identity, user identity, subject identity, host identity, eventtype]

b) [assignment: list of additional attributes that audit selectivity is basedupon].


104 FAU_STG.2.1 The TSF shall protect the stored audit records from unauthoriseddeletion.

105 FAU_STG.2.2 The TSF shall be able to [selection: prevent, detect] modificationsto the audit records.

106 FAU_STG.2.3 The TSF shall ensure that [assignment: metric for saving auditrecords] audit records will be maintained when the following conditions occur:[selection: audit storage exhaustion, failure, attack].


107 FAU_STG.4 The TSF shall [selection: ‘ignore auditable events’, ‘preventauditable events, except those taken by the authorised user with special rights’,‘overwrite the oldest stored audit records’] and [assignment: other actions to betaken in case of audit storage failure] if the audit trail is full.

108 Le tableau ci-dessous donne la liste des événements à auditer pour chaque exigencefonctionnelle choisie.

109 Le niveau de détail pour la génération des données d’audit est le niveau “basique”.Il a été choisi au niveau de de la composante FAU_GEN.1. La catégorisation desévénements auditables étant hiérarchique, les événements à auditer spécifiés auniveau “minimal” (hiérarchiquement inférieur au niveau “basique” choisi) doiventêtre inclus au même titre que les événements spécifiés pour le niveau “basique”.

110 Le rédacteur de la cible de sécurité peut adjoindre d’autres événements à auditer enplus de ceux proposés dans le tableau ci-dessous.

Table 5.2 - Niveau d’audit choisi par exigence fonctionnelle

Composante Niveau de détail choisi

FAU_ARP.1 Minimal : action taken due to imminent security violations.

FAU_GEN.1 There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.

FAU_GEN.2 There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.

FAU_SAA.2 Minimal : enabling and disabling of any of the analysis mechanisms ;Minimal : automated responses performed by the tool.

FAU_SAR.1 Basic : reading of information from the audit records.

FAU_SAR.2 Basic : unsuccessful attempts to read information from the audit records.

FAU_SAR.3 No specifications for the basic level.

FAU_SEL.1 Minimal : all modifications to the audit generation that occur while the audit collection functions are operating.

FAU_STG.2 There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.

FAU_STG.4 Basic : actions taken due to exceeding of a threshold.

FMT_MOF.1 Basic : all modifications in the behaviour of the functions in the TSF.

FMT_MSA.1 Basic : all the modifications of the values of security attributes.

FMT_MSA.2 Minimal : all offered and rejected values for a security attribute.

FMT_MSA.3 Basic : modifications of the default setting of permissibe or restrictive rules.Basic : all modifications of the initial values of security attributes.

FMT_MTD.1 Basic : all modifications to the values of the TSF data.

FMT_MTD.2 Basic : all modifications to the limits on TSF data.Basic : all modifications in the actions to be taken in case of violation of the limits.

FMT_MTD.3 Minimal : all rejected values of TSF data.

FMT_REV.1 Minimal : all attempts to revoke security attributes.Basic : unsuccessful revocation of security attributes.

FMT_SAE.1 Basic : specification of the expiration time for an attribute.Basic : action taken due to attribute expiration.



FMT_SMR.2 Minimal : modifications to the group of users that are part of a role.Minimal : unsuccessful attempts to use a role due to the given condi-tions on the roles.

FMT_SMR.3 Minimal : explicit request to assume a role.

FCO_NRO.2 Minimal :the invocation of the non-repudiation service.Basic : identification of the information, the destination, and a copy of the evidence provided.

FCO_NRR.1 Minimal: The identity of the user who requested that evidence of receipt would be generated.Minimal: The invocation of the non-repudiation service.Basic: Identification of the information, the destination, and a copy of the evidence provided.

FCS_CKM.1 Minimal : success and failure of the activity.Basic : the object attribute(s), and object value(s) excluding any sensi-tive information (e.g. secret or private keys).




FCS_COP.1 Minimal : success and failure, and the type of cryptographic operation.Basci : any applicable cryptographic mode(s) of operation, subject attributes and object attributes.

FDP_ACC.2 There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.

FDP_ACF.1 Minimal : successful requests to perform an operation on an object covered by the SFP.Basic : all requests to perform an operation on an object covered by the SFP.



FDP_DAU.2 Minimal : successful generation of validity evidence.Basic : unsuccessful generation of validity evidence.

FDP_ETC.2 Minimal : successful export of information.Basic : all attempts to export information.

FDP_IFC.2 There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.

FDP_IFF.1 Minimal : decisions to permit requested information flows.Basic : all decisions on requests for information flow.

FDP_ITT.2 Minimal : successful transfers of the user data, including identification of the protection method used.Basic : all attempts to transfer user data, including the protection method used and any errors that occurred.

FDP_ITT.3 Minimal : successful transfers of user data, including identification of the integrity protection method used.Basic : all attempts to transfer user data, including the integrity protec-tion method used and any errors that occurred.Basic : unauthorised attempts to change the integrity protection method.

FDP_RIP.1 There are no events identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.

FDP_SDI.2 Minimal : successful attempts to check the integrity of user data, inclu-ding an indication of the results of the check.Basic : all attempts to check the integrity of user data, including an indication of the results of the check, if performed.

FDP_UIT.1 Minimal : The identity of any user or subject using the data exchange mechanisms.Basic : The identity of any user or subject attempting to use the user data exchange mechanisms, but who is unauthorised to do so.Basic : A reference to the names or other indexing information useful in identifying the user data that was transmitted or received. This could include security attributes associated with the user data.Basic : Any identified attempts to block transmission of user data.



FDP_UIT.2 Minimal : The identity of any user or subject using the data exchange mechanisms.Minimal : Successful recovery from errors including they type of error that was detected.Basic : The identity of any user or subject attempting to use the user data exchange mechanisms, but who is unauthorised to do so.Basic: A reference to the names or other indexing information useful in identifying the user data that was transmitted or received. This could include security attributes associated with the user data.Basic: Any identified attempts to block transmission of user data.

FIA_AFL.1 Minimal: the reaching of the threshold for the unsuccesful authentica-tion attempts and the actions (e.g. disabling of a terminal) taken and the subsequent, if appropriate, restoration to the normal state (e.g. re-ena-bling of a terminal).

FIA_ATD.1 There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.

FIA_SOS.1 Minimal : rejection by the TSF of any tested secret.Basic : rejection or acceptance by the TSF of any tested secret.

FIA_SOS.2 Minimal : rejection by the TSF of any tested secret.Basic : rejection or acceptance by the TSF of any tested secret.

FIA_UAU.2 Minimal : unsuccessful use of the authentication mechanism.Basic : all use of the authentication mechanism.

FIA_UAU.3 Minimal : detection of fraudulent authentication data.Basic : all immediate measures taken and results of checks on the frau-dulent data.

FIA_UAU.5 Minimal : the final decision on authentication.Basic: the result of each activated mechanism together with the final decision.

FIA_UAU.6 Minimal : failure of reauthentication.Basic : all reauthentication attempts.

FIA_UID.2 Minimal: unsuccessful use of the user identification mechanism, inclu-ding the user identity provided.Basic: all use of the user identification mechanism, including the user identity provided.



FPT_AMT.1 Basic : execution of the tests of the underlying machine and the results of the tests.

FPT_FLS.1 Basic : failure of the TSF.

FPT_ITA.1 Minimal : the absence of TSF data when required by a TOE.

FPT_ITC.1 There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.

FPT_ITI.1 Minimal : the detection of modification of transmitted TSF data.Basic : the action taken upon detection of modification of transmitted TSF data.

FPT_ITT.1 There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.

FPT_ITT.3 Minimal : the detection of modification of TSF data.

FPT_PHP.2 Minimal : detection of intrusion.

FPT_RCV.3 Minimal : the fact that a failure or service discontinuity occurred.Minimal : resumption of the regular operation.Basic : type of failure or service discontinuity.

FPT_RCV.4 Minimal : if possible, the impossibility to return to a secure state after failure of a security function.Basic : if possible, the detection of a failure of a security function.

FPT_RPL.1 Basic: Detected replay attacks.

FPT_SEP.2 There are no actions identified that should be auditable if FAU_GEN Security audit data generation is included in the PP/ST.

FPT_SSP.1 Minimal : failure to receive an acknowledgement when expected.

FPT_STM.1 Minimal : changes to the time.

FPT_TDC.1 Minimal : successful use of TSF data consistency mechanisms.Basic : use of the TSF data consistency mechanisms.Basic : identification of which TSF data have been interpreted.Basic : detection of modified TSF data.



FPT_TRC.1 Minimal : restoring consistency upon reconnection.Basic : detected inconsistency between TSF data.

FPT_TST.1 Basic : execution of the TSF self tests and the results of the tests.

FTA_SSL.1 Minimal : locking of an interactive session by the session locking mechanism.Minimal : successful unlocking of an interactive session.Basic : any attempts at unlocking an interactive session.

FTA_SSL.2 Minimal : locking of an interactive session by the session locking mechanism.Minimal : successful unlocking of an interactive session.Basic : any attempts at unlocking an interactive session.

FPT_SSL.3 Minimal : termination of an interactive session by the session locking mechanism.

FTA_TSE.1 Minimal : denial of a session establishment due to the session establish-ment mechanism.Basic : all attempts at establishment of a user session.

FTP_ITC.1 Minimal : failure of the trusted channel functions.Minimal : identification of the initiator and target of failed trusted channel functions.Basic : all attempted uses of the trusted channel functions.Basic : identification of the initiator and target of all trusted channel functions.

FTP_TRP.1 Minimal : failures of the trusted path functions.Minimal : identification of the user associated with all trusted path failures, if available.Basic : all attempted uses of the trusted path functions.Basic : identification of the user associated with all trusted path invoca-tions, if available.



5.2.2

5.2.3 Composante FMT

FMT_MOF.1 Management of security functions behaviour

111 FMT_MOF.1 The TSF shall restrict the ability to [selection: determine thebehaviour of, disable, enable, modify the behaviour of] the functions [assignment:list of functions] to [assignment: the authorised identified roles].


112 FMT_MSA.1.1 The TSF shall enforce the [assignment: access control SFP,information flow control SFP] to restrict the ability to [selection: change_default,query, modify, delete, [assignment: other operations]] the security attributes[assignment: list of security attributes] to [assignment: the authorised identifiedroles].


113 FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted forsecurity attributes.


114 FMT_MSA.3.1 The TSF shall enforce the [assignment: access control SFP,information flow control SFP] to provide [selection: restrictive, permissive, otherproperty] default values for security attributes that are used to enforce the SFP.

115 FMT_MSA.3.2 The TSF shall allow the [assignment: the authorised identifiedroles] to specify alternative initial values to override the default values when anobject or information is created.


116 FMT_MTD.1.1 The TSF shall restrict the ability to [selection: change_default,query, modify, delete, clear, [assignment: other operations]] the [assignment: list ofTSF data] to [assignment: the authorised identified roles].


117 FMT_MTD.2.1 The TSF shall restrict the specification of the limits for[assignment: list of TSF data] to [assignment: the authorised identified roles].

118 FMT_MSA.2.2 The TSF shall take the following actions, if the TSF data are at, orexceed, the indicated limits: [assignment: actions to be taken].


119 FMT_MTD.3.1 The TSF shall ensure that only secure values are accepted for TSFdata.


120 FMT_REV.1.1 The TSF shall restrict the ability to revoke security attributesassociated with the [selection: users, subjects, objects, other additional resources]within the TSC to [assignment: the authorised identified roles].

121 FMT_REV.1.2 The TSF shall enforce the rules [assignment: specification ofrevocation rules].


122 FMT_SAE.1.1 The TSF shall restrict the capability to specify an expiration time for[assignment: list of security attributes for which expiration is to be supported] to[assignment: the authorised identified roles].

123 FMT_SAE.1.2 For each of these security attributes, the TSF shall be able to[assignment: list of actions to be taken for each security attribute] after theexpiration time for the indicated security attribute has passed.


124 FMT_SMR.2.1 The TSF shall maintain the roles: [assignment: the authorisedidentified roles].

125 FMT_SMR.2.2 The TSF shall be able to associate users with roles.

126 FMT_SMR.2.3 The TSF shall ensure that the conditions [assignment: conditionsfor the different roles] are satisfied.

127 Les différents rôles identifiés sont les suivants :

a) administrateur ;

b) opérateur ;

c) ingénieur système ;

d) officier de sécurité.


128 FMT_SMR.3.1 The TSF shall require an explicit request to assume the followingroles: [assignment: the roles].

Table 5.3 - Composante de management associée à chaque exigence fonctionnelle

Composante Management

FAU_ARP.1 - the management (addition, removal, or modification) of actions.

FAU_GEN.1 There are no management activities foreseen for this component..

FAU_GEN.2 There are no management activities foreseen for this component.

FAU_SAA.2 - maintenance (deletion, modification, addition) of the group of users in the profile target group.

FAU_SAR.1 - maintenance (deletion, modification, addition) of the group of users with read access right to the audit records.

FAU_SAR.2 There are no management activities foreseen for this component..

FAU_SAR.3 There are no management activities foreseen for this component..

FAU_SEL.1 - maintenance of the rights to view/modify the audit events.

FAU_STG.2 - maintenance of the parameters that control the audit storage capability.

FAU_STG.4 - maintenance (deletion, modification, addition) of actions to be taken in case of audit storage failure.

FMT_MOF.1 - managing the group of roles that can interact with the functions in the TSF.

FMT_MSA.1 - managing the group of roles that can interact with the security attributes.

FMT_MSA.2 There are no management activities foreseen for this component.

FMT_MSA.3 - managing the group of roles that can specify initial values.

- managing the permissive or restrictive setting of default values for a given access control SFP.

FMT_MTD.1 - managing the group of roles that can interact with the TSF data.

FMT_MTD.2 - managing the group of roles that can interact with the limits on the TSF data.

FMT_MTD.3 There are no additional management activities foreseen for this compo-nent.

FMT_REV.1 - managing the group of roles that can invoke revocation of security attributes;

- managing the lists of users, subjects, objects and other resources for which revocation is possible;

- managing the revocation rules.

FMT_SAE.1 - managing the list of security attributes for which expiration is to be supported;

- the actions to be taken if the expiration time has passed.

FMT_SMR.2 - managing the group of users that are part of a role;

- managing the conditions that the roles must satisfy.

FMT_SMR.3 There are no management activities foreseen for this component.

FCO_NRO.2 - the management of changes to information types, fields, originator attributes and recipients of evidence.

FCO_NRR.1 - the management of changes to information types, fields, originator attributes and third parties recipients of evidence.

FCS_CKM.1 - the management of changes to cryptographic key attributes. Examples of key attributes include user, key type (e.g. public, private, secret), validity period, and use (e.g. digital signature, key encryption, key agreement, data encryption).






FCS_COP.1 - the management of changes to cryptographic key attributes. Examples of key attributes include user, key type (e.g. public, private, secret), validity period, and use (e.g. digital signature, key encryption, key agreement, data encryption).

FDP_ACC.2 There are no management activities foreseen for this component.

FDP_ACF.1 - managing the attributes used to make explicit access or denial based decisions

FDP_DAU.2 - the assignment or modification of the objects for which data authentication may apply could be configurable in the system.

FDP_ETC.2 - the additional exportation control rules could be configurable by a user in a defined role.

FDP_IFC.2 There are no management activities foreseen for this component.

FDP_IFF.1 - managing the attributes used to make explicit access based decisions.

FDP_ITT.2 - if the TSF provides multiple methods to protect user data during transmission between physically separated parts of the TOE, the TSF could provide a pre-defined role with the ability to select the method that will be used.

FDP_ITT.3 - the specification of the actions to be taken upon detection of an integrity error could be configurable.

FDP_RIP.1 - the choice of when to perform residual information protection (i.e. upon allocation or deallocation) could be made configurable within the TOE.

FDP_SDI.2 - the actions to be taken upon the detection of an integrity error could be configurable.

FDP_UIT.1 There are no management activities foreseen for this component.

FDP_UIT.2 There are no management activities foreseen for this component.



FIA_AFL.1 - management of the threshold for unsuccessful authentication attempts.

- management of actions to be taken in the event of an authentication failure.

FIA_ATD.1 - if so indicated in the assignment, the authorised administrator might be able to define additional security attributes for users.

FIA_SOS.1 - the management of the metric used to verify the secrets.

FIA_SOS.2 - the management of the metric used to generate the secrets.

FIA_UAU.2 - management of the authentication data by an administrator.

- management of the authentication data by the user associated with this data.

FIA_UAU.3 There are no management activities foreseen for this component.

FIA_UAU.5 - the management of authentication mechanisms.

- the management of the rules for authentication.

FIA_UAU.6 - if an authorised administrator could request re-authentication, the management includes a re-authentication request.

FIA_UID.2 - the management of the user identities.

FPT_AMT.1 - management of the conditions under which abstract machine test occurs, such as during initial start-up, regular interval, or under specified conditions.

- management of the time interval if appropriate.

FPT_FLS.1 There are no management activities foreseen for this component.

FPT_ITA.1 - management of the list of types of TSF data that must be available to a remote trusted IT product.

FPT_ITC.1 There are no management activities foreseen for this component.

FPT_ITI.1 There are no management activities foreseen for this component.



FPT_ITT.1 - management of the types of modification against which the TSF should protect.

- management of the mechanism used to provide the protection of the data in transit between different parts of the TSF.

FPT_ITT.3 - management of the types of modification against which the TSF should protect.

- management of the mechanism used to provide the protection of the data in transit between different parts of the TSF.

- management of the types of modification of TSF data the TSF should try to detect.

- management of the actions that will be taken.

FPT_PHP.2 - management of the user or role that gets informed about intrusions.

- management of the list of devices that should inform the indicated user or role about the intrusion.

FPT_RCV.3 - management of who can access the restore capability within the maintenance mode.

- management of the list of failures/service discontinuities that will be handled through the automatic procedures.

FPT_RCV.4 There are no management activities foreseen.

FPT_RPL.1 - management of the list of identified entities for which replay shall be detected.

- management of the list of actions that need to be taken in case of relay.

FPT_SEP.2 There are no management activities foreseen for this component.

FPT_SSP.1 There are no management activities foreseen for this component.

FPT_STM.1 - management of the time.

FPT_TDC.1 There are no management activities foreseen for this component.

FPT_TRC.1 There are no management activities foreseen for this component.



5.2.4 Composante FCO


129 FCO_NRO.2.1 The TSF shall enforce the generation of evidence of origin fortransmitted [assignment: list of information types] at all times.

130 FCO_NRO.2.2 The TSF shall be able to relate the [assignment: list of attributes] ofthe originator of the information, and the [assignment: list of information fields] ofthe information to which the evidence applies.

131 FCO_NRO.2.3 The TSF shall provide a capability to verify the evidence of originof information to [selection: originator, recipient, [assignment: list of thirdparties]] given [assignment: limitations on the evidence of origin].

FPT_TST.1 - management of the conditions under which TSF self testing occurs, such as during initial start-up, regular interval, or under specified conditions.

- management of the time interval if appropriate.

FTA_SSL.1 - specification of the time of user inactivity after which lock-out occurs for an individual user.

- specification of the default time of user inactivity after which lock-out occurs.

- management of the events that should occur prior to unlocking the session.

FTA_SSL.2 - management of the events that should occur prior to unlocking the session.

FPT_SSL.3 - specification of the time of user inactivity after which termination of the interactive session occurs for an individual user.

- specification of the default time of user inactivity after which termination of the interactive session occurs.

FTA_TSE.1 - management of the session establishment conditions by the authorised administrator.

FTP_ITC.1 - configuring the actions that require trusted channel, if supported.

FTP_TRP.1 - configuring the actions that require trusted path, if supported.




132 FCO_NRR.1.1 The TSF shall be able to generate evidence of receipt for received[assignment: list of information types] at the request of the [selection: originator,recipient, [assignment: list of third parties]].

133 FCO_NRR.1.2 The TSF shall be able to relate the [assignment: list of attributes] ofthe recipient of the information, and the [assignment: list of information fields] ofthe information to which the evidence applies.

134 FCO_NRR.1.3 The TSF shall provide a capability to verify the evidence of receiptof information to [selection: originator, recipient, [assignment: list of thirdparties]] given [assignment: limitations on the evidence of receipt].

5.2.5 Composante FCS


135 FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with aspecified cryptographic key generation algorithm [assignment: cryptographic keygeneration algorithm] and specified cryptographic key sizes [assignment: crypto-graphic key sizes] that meet the following: [assignment: list of standards].


136 FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with aspecified cryptographic key distribution method [assignment: cryptographic keydistribution method] that meets the following: [assignment: list of standards].


137 FCS_CKM.3.1 The TSF shall perform [assignment: type of cryptographic keyaccess] in accordance with a specified cryptographic key access method [assign-ment: cryptographic key access method] that meets the following: [assignment: listof standards].


138 FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with aspecified cryptographic key destruction method [assignment: cryptographic keydestruction method] that meets the following: [assignment: list of standards].


139 FCS_COP.1.1 The TSF shall perform [assignment: list of cryptographic opera-tions] in accordance with a specified cryptographic algorithm [assignment: crypto-graphic algorithm] and cryptographic key sizes [assignment: cryptographic keysizes] that meet the following: [assignment: list of standards].

5.2.6 Composante FDP


140 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 andobjects covered by the SFP.

141 FDP_ACC.2.2 The TSF shall ensure that all operations between any subject in theTSC and any object within the TSC are covered by an access control SFP.


142 FDP_ACF.1.1 The TSF shall enforce the [assignment: access control SFP] toobjects based on [assignment: security attributes, named groups of security attri-butes].

143 FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an opera-tion among controlled subjects and controlled objects is allowed: [assignment: rulesgoverning access among controlled subjects and controlled objects usingcontrolled operations on controlled objects].

144 FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects basedon the following additional rules: [assignment: rules, based on security attributes,that explicitly authorise access of subjects to objects].

145 FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based onthe [assignment: rules, based on security attributes, that explicitly deny access ofsubjects to objects].


146 FDP_DAU.2.1 The TSF shall provide a capability to generate evidence that can beused as a guarantee of the validity of [assignment: list of objects or informationtypes].

147 FDP_DAU.2.2 The TSF shall provide [assignment: list of subjects] with the abilityto verify evidence of the validity of the indicated information and the identity of theuser that generated the evidence.


148 FDP_ETC.2.1 The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control SFP(s)] when exporting user data, controlled under theSFP(s), outside of the TSC.

149 FDP_ETC.2.2 The TSF shall export the user data with the user data’s associatedsecurity attributes.

150 FDP_ETC.2.3 The TSF shall ensure that the security attributes, when exportedoutside the TSC, are unambiguously associated with the exported user data.

151 FDP_ETC.2.4 The TSF shall enforce the following rules when user data is exportedfrom the TSC: [assignment: additional exportation control rules].


152 FDP_IFC.2.1 The TSF shall enforce the [assignment: information flow controlSFP] on [assignment: list of subjects and information] and all operations that causethat information to flow to and from subjects covered by the SFP.

153 FDP_IFC.2.2 The TSF shall ensure that all operations that cause any information inthe TSC to flow to and from any subject in the TSC are covered by an informationflow control SFP.


154 FDP_IFF.1.1 The TSF shall enforce the [assignment: information flow controlSFP] based on the following types of subject and information security attributes:[assignment: the minimum number and type of security attributes].

155 FDP_IFF.1.2 The TSF shall permit an information flow between a controlledsubject and controlled information via a controlled operation if the following ruleshold: [assignment: for each operation, the security attribute-based relationship thatmust hold between subject and information security attributes].

156 FDP_IFF.1.2 The TSF shall enforce the [assignment: additional information flowcontrol SFP rules].

157 FDP_IFF.1.3 The TSF shall provide the following [assignment: list of additionalSFP capabilities].

158 FDP_IFF.1.4 The TSF shall explicitly authorise an information flow based on thefollowing rules: [assignment: rules, based on security attributes, that explicitlyauthorise information flows].

159 FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on thefollowing rules: [assignment: rules, based on security attributes, that explicitlydeny information flows].

FDP_ITT.2 Transmission separation by attribute

160 FDP_ITT.2.1 The TSF shall enforce the [assignment: access control SFP(s) and/orinformation flow control SFP(s)] to prevent the [selection: disclosure, modification,loss of use] of user data when it is transmitted between physically-separated partsof the TOE.

161 FDP_ITT.2.2 The TSF shall separate data controlled by the SFP(s) when trans-mitted between physically-separated parts of the TOE, based on the values of thefollowing: [assignment: security attributes that require separation].


162 FDP_ITT.3.1 The TSF shall enforce the [assignment: access control SFP(s) and/orinformation flow control SFP(s)] to monitor user data transmitted between physi-cally-separated parts of the TOE for the following errors: [assignment: integrityerrors].

163 FDP_ITT.3.2 Upon detection of a data integrity error, the TSF shall [assignment:specify the action to be taken upon integrity error].


164 FDP_RIP.1.1 The TSF shall ensure that any previous information content of aresource is made unavailable upon the [selection: allocation of the resource to,deallocation of the resource from] the following objects: [assignment: list ofobjects].

165 Les objets concernés sont tous les biens secrets.


166 FDP_SDI.2.1 The TSF shall monitor user data stored within the TSC for [assign-ment: integrity errors] on all objects, based on the following attributes: [assign-ment: user data attributes].

167 FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [assignment:action to be taken].


168 FDP_UIT.1.1 The TSF shall enforce the [assignment: access control SFP(s) and/orinformation flow control SFP(s)] to be able to [selection: transmit, receive] userdata in a manner protected from [selection: modification, deletion, insertion,replay] errors.

169 FDP_UTI.1.2 The TSF shall be able to determine on receipt of user data, whether[selection: modification, deletion, insertion, replay] has occurred.


170 FDP_UIT.2.1The TSF shall enforce the [assignment: access control SFP(s) and/orinformation flow control SFP(s)] to be able to recover from [assignment: list ofrecoverable errors] with the help of the source Trusted IT Product.

5.2.7 Composante FIA


171 FIA_AFL.1.1 The TSF shall detect when [assignment: number] unsuccessfulauthentication attempts occur related to [assignment: list of authentication events].

172 FIA_AFL.1.2 When the defined number of unsuccessful authentication attemptshas been met or surpassed, the TSF shall [assignment: list of actions].


173 FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belon-ging to individual users: [assignment: list of security attributes].


174 FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [assi-gnment: a defined quality metric].


175 FIA_SOS.2.1 The TSF shall provide a mechanism to generate secrets that meet[assignment: a defined quality metric].

176 FIA_SOS.2.2 The TSF shall be able to enforce the use of TSF generated secrets for[assignment: list of TSF functions].


177 FIA_UAU.2.1 The TSF shall require each user to be successfully authenticatedbefore allowing any other TSF-mediated actions on behalf of that user.

FIA_UAU.3 Unforgeable authentication

178 FIA_UAU.3.1 The TSF shall [selection: detect, prevent] use of authentication datathat has been forged by any user of the TSF.

179 FIA_UAU.3.2 The TSF shall [selection: detect, prevent] use of authentication datathat has been copied from any other user of the TSF.


180 FIA_UAU.5.1 The TSF shall provide [assignment: list of multiple authenticationmechanisms] to support user authentication.

181 FIA_UAU.5.2 The TSF shall authenticate any user’s claimed identity according tothe [assignment: rules describing how the multiple authentication mechanismsprovide authentication].


182 FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions [assign-ment: list of conditions under which re-authentication is required].


183 FIA_UID.2.1 The TSF shall require each user to identify itself before allowing anyother TSF-mediated actions on behalf of that user.

5.2.8 Composante FPT


184 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 an authorised user, otherconditions] to demonstrate the correct operation of the security assumptionsprovided by the abstract machine that underlies the TSF.


185 FPT_FLS.1.1 The TSF shall preserve a secure state when the following types offailures occur: [assignment: list of types of failures in the TSF].

FPT_ITA.1 Inter-TSF availability within a defined availability metric

186 FPT_ITA.1.1 The TSF shall ensure the availability of [assignment: list of types ofTSF data] provided to a remote trusted IT product within [assignment: a definedavailability metric] given the following conditions [assignment: conditions toensure availability].

FPT_ITC.1 Inter-TSF confidentiality during transmission

187 FPT_ITC.1.1 The TSF shall protect all TSF data transmitted from the TSF to aremote trusted IT product from unauthorised disclosure during transmission.


188 FPT_ITI.1.1 The TSF shall provide the capability to detect modification of all TSFdata during transmission between the TSF and a remote trusted IT product withinthe following metric: [assignment: a defined modification metric].

189 FPT_ITI.1.2 The TSF shall provide the capability to verify the integrity of all TSFdata transmitted between the TSF and a remote trusted IT product and perform[assignment: action to be taken] if modifications are detected.


190 FPT_ITT.1.1 The TSF shall protect TSF data from [selection: disclosure, modifica-tion] when it is transmitted between separate parts of the TOE.


191 FPT_ITT.3.1 The TSF shall be able to detect [selection: modification of data, subs-titution of data, re-ordering of data, deletion of data, [assignment: other integrityerrors]] for TSF data transmitted between separate parts of the TOE.

192 FPT_ITT.3.2 Upon detection of a data integrity error, the TSF shall take thefollowing actions: [assignment: specify the action to be taken].


193 FPT_PHP.2.1 The TSF shall provide unambiguous detection of physical tamperingthat might compromise the TSF.

194 FPT_PHP.2.2 The TSF shall provide the capability to determine whether physicaltampering with the TSF’s devices or TSF’s elements has occurred.

195 FPT_PHP.2.3 For [assignment: list of TSF devices/elements for which active detec-tion is required], the TSF shall monitor the devices and elements and notify [assi-gnment: a designated user or role] when physical tampering with the TSF’s devicesor TSF’s elements has occurred.


196 FPT_RCV.3.1 When automated recovery from a failure or service discontinuity isnot possible, the TSF shall enter a maintenance mode where the ability to return theTOE to a secure state is provided.

197 FPT_RCV.3.2 For [assignment: list of failures/service discontinuities], the TSFshall ensure the return of the TOE to a secure state using automated procedures.

198 FPT_RCV.3.3 The functions provided by the TSF to recover from failure or servicediscontinuity shall ensure that the secure initial state is restored without exceeding[assignment: quantification] for loss of TSF data or objects within the TSC.

199 FPT_RCV.3.4 The TSF shall provide the capability to determine the objects thatwere or were not capable of being recovered.


200 FPT_RCV.4.1 The TSF shall ensure that [assignment: list of SFs and failurescenarios] have the property that the SF either completes successfully, or for theindicated failure scenarios, recovers to a consistent and secure state.


201 FPT_RPL.1.1 The TSF shall detect replay for the following entities: [assignment:list of identified entities].

202 FPT_RPL.1.2 The TSF shall perform [assignment: list of specific actions] whenreplay is detected.


203 FPT_SEP.2.1 The unisolated portion of the TSF shall maintain a security domainfor its own execution that protects it from interference and tampering by untrustedsubjects.

204 FPT_SEP.2.2 The TSF shall enforce separation between the security domains ofsubjects in the TSC.

205 FPT_SEP.2.3 The TSF shall maintain the part of the TSF related to [assignment: listof access control and/or information flow control SFPs] in a security domain fortheir own execution that protects them from interference and tampering by theremainder of the TSF and by subjects untrusted with respect to those SFPs.


206 FPT_SSP.1.1 The TSF shall acknowledge, when requested by another part of theTSF, the receipt of an unmodified TSF data transmission.


207 FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own use.


208 FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret[assignment: list of TSF data types] when shared between the TSF and anothertrusted IT product.

209 FPT_TDC.1.2 The TSF shall use [assignment: list of interpretation rules to beapplied by the TSF] when interpreting the TSF data from another trusted IT product.


210 FPT_TRC.1.1 The TSF shall ensure that TSF data is consistent when replicatedbetween parts of the TOE.

211 FPT_TRC.1.2 When parts of the TOE containing replicated TSF data aredisconnected, the TSF shall ensure the consistency of the replicated TSF data uponreconnection before processing any requests for [assignment: list of SFs dependenton TSF data replication consistency].


212 FPT_TST.1.1 The TSF shall run a suite of self tests [selection: during initial start-up, periodically during normal operation, at the request of the authorised user, atthe conditions [assignment: conditions under which self test should occur]] todemonstrate the correct operation of the TSF.

213 FPT_TST.1.2 The TSF shall provide authorised users with the capability to verifythe integrity of TSF data.

214 FPT_TST.1.3 The TSF shall provide authorised users with the capability to verifythe integrity of stored TSF executable code.

5.2.9 Composante FTA


215 FTA_SSL.1.1 The TSF shall lock an interactive session after [assignment: timeinterval of user inactivity] by:

c) clearing or overwriting display devices, making the current contentsunreadable;

d) disabling any activity of the user’s data access/display devices other thanunlocking the session.

216 FTA_SSL.1.2 The TSF shall require the following events to occur prior tounlocking the session: [assignment: events to occur].


217 FTA_SSL.2.1 The TSF shall allow user-initiated locking of the user’s owninteractive session, by:

e) clearing or overwriting display devices, making the current contentsunreadable;

f) disabling any activity of the user’s data access/display devices other thanunlocking the session.

218 FTA_SSL.2.2 The TSF shall require the following events to occur prior tounlocking the session: [assignment: events to occur].


219 FTA_SSL.3.1 The TSF shall terminate an interactive session after a [assignment:time interval of user inactivity].


220 FTA_TSE.1.1 The TSF shall be able to deny session establishment based on [assi-gnment: attributes].

5.2.10 Composante FTP


221 FTP_ITC.1.1 The TSF shall provide a communication channel between itself and aremote trusted IT product that is logically distinct from other communicationchannels and provides assured identification of its end points and protection of thechannel data from modification or disclosure.

222 FTP_ITC.1.2 The TSF shall permit [selection: the TSF, the remote trusted ITproduct] to initiate communication via the trusted channel.

223 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].


224 FTP_TRP.1.1 The TSF shall provide a communication path between itself and[selection: remote, local] users that is logically distinct from other communicationpaths and provides assured identification of its end points and protection of thecommunicated data from modification or disclosure.

225 FTP_TRP.1.2 The TSF shall permit [selection: the TSF, local users, remote users]to initiate communication via the trusted path.

226 FTP_TRP.1.3 The TSF shall require the use of the trusted path for [selection: initialuser authentication, [assignment: other services for which trusted path isrequired]].

5.3 Exigences d’assurance des TI de la cible d’évaluation

227 Le niveau d’assurance visé est EAL4 augmenté de plusieurs composantes d’assu-rance.

228 Ces compléments s’accordent avec la nécessité de sécuriser des informations clas-sifiées de défense et justifient le choix d’un niveau d’assurance EAL 4+.

229 Le niveau EAL4 est résumé dans le tableau 5.3.

Tab. 5.4 - Exigences d’assurance du niveau EAL4

Composantes Noms

ACM_AUT.1 Partial CM automation

ACM_CAP.4 Generation support and acceptance procedures

ACM_SCP.2 Problem tracking CM coverage

ADO_DEL.2 Detection of modification

ADO_IGS.1 Installation, generation, and start-up procedures

ADV_FSP.2 Fully defined external interfaces

ADV_HLD.2 Security enforcing high-level design

ADV_IMP.1 Subset of the implementation of the TSF

ADV_LLD.1 Descriptive low-level design

ADV_RCR.1 Informal correspondence demonstration

ADV_SPM.1 Informal TOE security policy model

AGD_ADM.1 Administrator guidance

AGD_USR.1 User guidance

ALC_DVS.1 Identification of security measures

ALC_LCD.1 Developer defined life-cycle model

ALC_TAT.1 Well-defined development tools

ATE_COV.2 Analysis of coverage

ATE_DPT.1 Testing: high-level design

Tab. 5.5 - Exigences d’assurance supplémentaires

230 La composante ADV_IMP.2 remplace la composante ADV_IMP.1 définie dans leniveau d’évaluation EAL 4. Elle requiert de la part du développeur de la TOE dedonner une représentation de l’implémentation complète de la TOE entière plutôtque de sous-ensembles de la TOE (ADV_IMP.1).

231 L’ajout de la composante d’assurance AVA_CCA.1 permet d’analyser la présencede canaux cachés et décrire les mesures à prendre en cas de découverte de telscanaux.

232 La composante AVA_MSU.3 remplace la composante AVA_MSU.2 définie dansle niveau d’évaluation EAL 4. Elle rajoute la nécessité de la part de l’évaluateurd’effectuer des tests permettant de prouver que tous les états instables possibles dela TOE sont documentés.

233 La composante AVA_VLA.4 remplace la composante AVA_VLA.2 définie dansle niveau d’évaluation EAL 4. Elle permet de garantir qu’une analyse de vulnérabi-lités est réalisée sur la TOE, garantissant la résistance de la TOE à un attaquantdisposant d’un fort potentiel d’attaque (par rapport à un un faible potentiel pourAVA_VLA.2)..

234 D’autre part, la présence de la composante d’assurance AVA_SOF.1 implique lanécessité de préciser le degré nécessaire de résistance des mécanismes de sécurité

ATE_FUN.1 Functional testing

ATE_IND.2 Independent testing - sample

AVA_MSU.2 Validation of analysis

AVA_SOF.1 Strength of TOE security function evaluation

AVA_VLA.2 Independent vulnerability analysis

Composantes Noms

ADV_IMP.2 Implementation of the TSF

AVA_CCA.1 Covert channel analysis

AVA_MSU.3 Analysis and testing for insecure states

AVA_VLA.4 Highly resistant

Composantes Noms

de la TOE à des attaques élaborées. Dans la mesure où la TOE est destinée à sécu-riser les informations classifiées de défense, elle peut être confrontée à des attaquesstratégiques qui justifient le niveau de résistance le plus élevé possible : SOF - high.

Chapitre 6

Notes d’application

6.1 Traitement d’informations de sensibilité différentes

235 Ce PP est adapté aux infrastructures de gestion de clés traitant d’informations nonsensibles, sensibles et classifiées de défense.

236 Ce chapitre rappelle que la réglementation [901] et l’instruction interministérielle[900] s’appliquent également à ce PP.

237 Pour les informations classifiées de défense:

a) “Lorsque les mesures de sécurité générales et particulières déjà prises nepermettent pas de traiter (en fait d’acheminer et de stocker) les informationsclassifiées de défense avec une protection correspondant à leur niveau declassification, il convient en outre de les chiffrer avec des moyens agrééspar le SCSSI.” [900].

b) “Lorsque les mesures générales et particulières de sécurité déjà prises nepermettent pas d’assurer à des informations classifiées de défense traitéespar un système informatique une protection correspondant à leur niveau declassification, il convient en outre de les protéger, soit à l’aide de moyens desécurité informtatique agréés, soit en ayant recours à des produits informa-tiques agréés. Cet agrément est prononcé par le SCSSI (...)” [900].

238 Pour les informations sensibles:

a) “Lorsque les mesures de sécurité générales et particulières déjà prises nepermettent pas de traiter (en fait d’acheminer et de stocker) les informationssensibles avec une protection correspondant à leur sensibilité, il peut êtreéventuellement fait appel à des moyens de cryptologie devant alors avoirreçu la caution du SCSSI.” [901].

b) “Pour les produits informatiques qui comportent des moyens de sécurité in-formatique, le SCSSI délivre un certificat qui atteste de leur niveau de sécu-rité. ce certificat est délivré à l’issue d’une évaluation effectuée par unlaboratoire agréé, conformément aux critères d’évaluation de la sécurité dessystèmes d’information.” [901].

6.2 Législation applicable en France

239 Plusieurs contraintes légales existent qui obligent les administrations et organismeslié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 (articles 410-1, 411-1 à414-9 du code pénal),

- la loi n°78-17, du 6 janvier 1978, relative à l’informatique, aux fichiers etaux libertés (articles 226-16 à 226-24 du code pénal),

- la loi relative au secret professionnel (article 226-13 du code pénal),

- loi 91-646 du 11 juillet 1991 relative au secret des correspondances (article226-15 du code pénal).

240 L’article 28 de la loi n°90-1170 du 29 décembre 1990 modifié par l’article 17 de laloi 96-659 du 26 juillet 1996 précise la réglementation applicable aux moyens etprestations de cryptologie. Les constructeurs, distributeurs et utilisateurs de la TOEdoivent prendre connaissance du décret ci-dessous :

- Décret n°98-101 du 24 février 1998 définissant les conditions danslesquelles sont souscrites les déclarations et accordées les autorisationsconcernant les moyens et prestations de cryptologie (Journal Officiel du 25/02/98 pp.2911).

241 Le terme TPC est utilisé dans ce PP pour tierce partie de confiance. La législationfrançaise emploie l’expression “organisme gérant pour le compte d’autrui desconventions secrètes de cryptologie” Le décret cité ci-dessous précise le termed’agrément de ces organismes :

- Décret n°98-102 du 24 février 1998 définissant les conditions danslesquelles sont agréées les organismes gérant pour le compte d’autrui desconventions secrètes de cryptologie en application de l’article 28 de la loi n°90-1170 du 29 décembre 1990 sur la réglementation destélécommunications (Journal Officiel du 25/02/98, pp. 2915).

242 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 laréglementation interministérielle s’applique:

- l’instruction générale interministérielle n°1300/SGDN/SSD [1300] du 12mars 1982, sur la protection du secret et des informations concernant ladéfense nationale et la sûreté de l’État,

- l’instruction interministérielle n°500bis/SGDN/TTS/SSI/DR [500], du 18octobre 1996, relative au chiffre dans la sécurité des systèmesd’information,

- l’instruction générale n°900/DISSI/SCSSI/DR [900], du 20 juillet 1993, surla sécurité des systèmes d’information qui font l’objet d’une classificationde défense pour eux-mêmes ou pour les informations traitées.

243 Dans le cas contraire, la recommandation n°901/DISSI/SCSSI [901], du 2 mars1994, 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.

Chapitre 7

Justification du profil de protection

7.1 Menaces non couvertes par le profil de protection

244 La cible d’évaluation décrite dans ce PP ne suffit pas à elle seule à sécuriser uneinfrastructure de gestion de clés. En particulier, les menaces citées dans la liste nonexhaustive qui suit, ne sont pas couvertes par le présent profil.

7.1.1 Menace non couverte portant sur les composantes de la TOE

245 MNC.TEMPEST : Les changements électromagnétiques du poste utilisateur et dela ressource cryptologique d’une composante sont des menaces portant sur la TOEcar les signaux parasites induits peuvent compromettre la sécurité des biens secretsde la TOE. Conformément à la directive [495], l’emploi de la TOE pour letraitement des informations classifiées de défense impose une politique de zonagedes lieux d’emploi pour vérifier que les rayonnements ne portent pas atteinte à lasécurité des biens secrets de la TOE. Cette menace n’est pas couverte pas le présentprofil.

7.1.2 Menaces non couvertes portant sur la TOE et le serveur de messagerie

246 MNC.UTILIS-CERTIF : L’ensemble des menaces liées à une mauvaiseutilisation ou à une utilisation inappropriée d’un certificat publié par la TOE n’estpas couvert par le présent profil.

247 Remarque: Ces menaces peuvent être le résultat de l’utilisation d’un certificatd’authentification à des fins de protection de la confidentialité, la sécurisation d’unmessage à destination d’un utilisateur qui n’a pas le besoin d’en connaître, l’usaged’un certificat révoqué, etc. Ce type de menace n’est pas couvert par le présentprofil de protection car il relève de la politique de sécurité des systèmesd’information et des applications bénéficiant des prestations de la TOE(messagerie, client - serveur).

7.2 Justification des objectifs de sécurité

248 Il s’agit de démontrer que les objectifs de sécurité énoncés dans le chapitre 7couvrent toutes les menaces portant sur la TOE exprimées dans le chapitre 3.

Tab. 7.1 -Couverture des menaces par les objectifs

Menaces Objectifs Justificatif

M.DYSFONC

O.DYSFONCO.CONFIDENTIALITEO.INTEGRITEO.GUIDEO.ADMINISTRATIONO.AUDIT

En cas de dysfonctionnement non détecté de laTOE, les biens secrets ne peuvent être exportés(O.DYSFONC) et la confidentialité et l’intégritédes biens est préservée (O.CONFIDENTIALITE,O.INTEGRITE) Un dysfonctionnement doit pouvoir être détecté etréparé (O.AUDIT, O.GUIDE, O.ADMINISTRA-TION).

M.INTRUSION

O.ACCESO.ENREGISTREMENTO.AUDITO.SEPARATIONO.CONFIDENTIALITEO.INTEGRITE

L’accès aux services de la TOE requiert l’identifi-cation et l’authentification (O.ACCES), privilègesaccordés qu’après vérification de l’identité du de-mandeur (O.ENREGISTREMENT).Tous les accès à la TOE sont audités, facilitant ladétection d’intrusion (O.AUDIT). La séparationdes fonctions de communication de la TOE de cel-les qui gèrent les biens secrets ne permet pas à unattaquant d’abuser de ses droits pour accéder àd’autres privilèges ou à des biens secrets (O.SE-PARATION).La protection des biens en intégrité (O.INTEGRI-TE) et des biens secrets en confidentialité(O.CONFIDENTIALITE) ne permet pas à un atta-quant de les protège contre tout attaquant ayantcommis une intrusion.

M.INITIALISATIONO.GUIDEO.ADMINISTRATIONO.CONFIDENTIALITE

Toute opération sur la TOE, y compris son initiali-sation est réalisée selon des procédures adaptées(O.GUIDE) et laisse la TOE dans un état stable etde confiance (O.ADMINISTRATION). Dans tousles cas, les biens secrets à l’initialisation sont pro-tégés en confidentialité (O.CONFIDENTIALI-TE).

M.CLONAGE O.ACCESO.CONFIDENTIALITE

Des contrôles d’accès physiques, et logiques(O.ACCES) préviennent la possibilité pour un at-taquant de créer un clône de la TOE.Le clônage de la TOE ne peut en aucun cas donneraccès à des biens secrets (O.CONFIDENTIALI-TE).

M.RESIDUEL O.CONFIDENTIALITEO.DESTRUCTION

Les méthodes de suppression des informationscontenues dans un support d’informations prévien-nent l’exploitation de données résiduelles pouvantcontenir des biens secrets (O.DESTRUCTION).De manière générale, les biens secrets sont proté-gés en confidentialité et sont inutilisables à tout at-taquant (O.CONFIDENTIALITE).

M.DENIO.AUDITO.ADMINISTRATIONO.ACCUSE

Toute action sur la TOE ou manipulation de biensgérés par la TOE est traçable et imputable à sonauteur (O.AUDIT). Les tâches d’administration in-cluent la mise en oeuvre des mécanismes d’audit,leur vérification et leur consultation (O.ADMI-NISTRATION). La TOE est en mesure deprouverla réception d’un bien et prévenirl’éventuel dénid’une interaction avec la TOE à un instant donné(O.ACCUSE).

M.INCONSISTANT O.ADMINISTRATIONO.GUIDE

La cohérence des actions des exploitants sur laTOE est contrôlée, et ne doit causer aucune dégra-dation des services de la TOE (O.ADMINISTRA-TION). L’utilisation et l’exploitation de la TOEétant documentée (O.GUIDE), un exploitant nepeut commettre par méconnaissance une erreur decohérence sur les opérations qu’il effectue.

M.USAGE O.COHERENTLes incohérences des biens échangés entre uneTOE et un produit IT sont contrôlés (O.COHE-RENT).

M.INVALIDEO.VERIFO.DATEO.REVOC

L’utilisation d’un bien publié par la TOE doit fairel’objet d’une vérification de son authentification(O.VERIF). La présence d’une datation de con-fiance constitue l’une des garanties quant à la vali-dité d’un certificat (O.DATE).Tout bien invalide doit être révoqué (O.REVOC).Tout utilisateur vérifiant la validité avant son utili-sation d’un bien ne peut être amené à utiliser invo-lontairement un certificat invalide.

Menaces Objectifs Justificatif

.

Tab. 7.2 -Couverture des menaces sur l’environnement de la TOE par les objectifs.

Menaces Objectifs et Politiques Justificatif

M.MAINTENANCEO.DISPOO.ADMINISTRATIONO.ENV-INFO

La garantie de la disponibilité des services vitauxde sécurité de la TOE (O.DISPO), son administra-tion (O.ADMINISTRATION) et l’administrationde son environnement informatique (O.ENV-IN-FO) préviennent la menace portée à la maintenabi-lité des composants matériels et logiciels de laTOE.

M.SATURATION

O.DISPOO.DYSFONCO.ADMINISTRATIONO.ENV-INFO

Les services vitaux de la TOE doivent être dispo-nibles (O.DISPO).Le dysfonctionnement non détecté par saturationdes services de la TOE ne porte pas atteinte à laconfidentialité des biens secrets (O.DYSFONC).L’administration de la TOE (O.ADMINISTRA-TION) ainsi que l’adminsitration de son environ-nement informatique préviennent la saturation desservices de la TOE.

M.SINISTRE

O.ARCHIVESO.GUIDEO.DISPOO.PLAN-SECOURS

Le plan de secours définit les mesures à prendre encas de sinistre (O.PLAN-SECOURS), incluant larécupération des archives (O.ARCHIVES), le re-couvrement des services vitaux de sécurité(O.DISPO), la mise en service du système(O.GUIDE).

M.VOL-SUPPORT O.CONFIDENTIALITEO.DESTRUCTION

Les biens secrets sont protégés en confidentialité(O.CONFIDENTIALITE).Les méthodes de destruction des supports prévien-nent la ré-utilisation des biens secrets qu’ils con-tiennent (O.DESTRUCTION).

M.VIRAL

O.DYSFONCO.INTEGRITEO.ADMINISTRATIONO.ENV-INFO

L’administration de la TOE (O.ADMINISTRA-TION), son environnement (O.ENV-INFO) etl’assurance de l’intégrité des biens importés(O.INTEGRITE) préviennent l’introduction d’unvirus au sein de la TOE.Le dysfonctionnement de la TOE ne nuit pas à laconfidentialité des biens secrets qu’elle gère(O.DYSFONC).

M.MOYENO.ENV-INFOO.ADMINISTRATIONO.AUDIT

La TOE ainsi que sa plate-forme informatique nepeut être utilisée à d’autres fins que celles auxquel-les elle est destinée (O.ENV-INFO).Toute action sur la TOE est auditée (O.AUDIT) etlaisse la TOE dans un état stable (O.ADMINIS-TRATION).

M.FLUX-EXTERNEO.CONFIDENTIALITEO.INTEGRITEO.EXPORT

Les biens importés ou exportés de la TOE sont pro-tégés en intégrité (O.INTEGRITE) et en confiden-t ia l i té pour les b ien s sec re ts(O.CONFIDENTIALITE). L’export de biens se-crets est régi par une polit ique de sécurité(O.EXPORT).

M.INTER-IT O.COHERENTLa vérification de la cohérence de l’interprétationdes biens échangés prévient une éventuelle incom-préhension entre deux IGC.

Tab. 7.3 -Couverture des politiques de sécurité par les objectifs de sécurité

Politiques de sécurité Objectifs de sécurité Justificatifs

P.UTILIS O.ADMINISTRATION

La TOE ne peut être utilisée qu’aux fins pour les-quelles elle est définie. (cf. définition des servicesde la TOE, Chapitre 2). Les actions résultant deson administration laissent la TOE dans un état sta-ble (O.ADMINISTRATION).

P.ROLES O.ADMINISTRATIONLa définition des rôles, responsabilités et attribu-tions des exploitants de la TOE garantit une admi-nistration optimale de la TOE.

P.RECOUVR O.CONFIDENTIALITEO.EXPORT

L’ex por t de b iens sec re ts es t poss ib le(O.EXPORT) et régi par une politique contrôlantaussi bien la confidentialité de ces biens (O.CON-FIDENTIALITE) que le destinataire du transfert.

Tab. 7.2 -Couverture des menaces sur l’environnement de la TOE par les objectifs.

Menaces Objectifs et Politiques Justificatif

249 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’utilisationexprimées dans le chapitre 3.

Tab. 7.4 - Couverture des hypothèses d’utilisation par les objectifs sur l’environnement de la TOE

P.CERT

O.ACCESO.ACCUSEO.ENREGISTREMENTO.RESSOURCEO.REVOCO.AUDITO.ARCHIVESO.VERIFO.EXPORTO.DATEO.GUIDE

Une politique de certification définit les procédu-res de fonctionnement des services et fonctions dela TOE (O.ACCES, O.ACCUSE, O.ENREGIS-TREMENT, O.RESSOURCE, O.REVOC,O.AUDIT, O.ARCHIVES, O.VERIF ,O.EXPORT, O.DATE, O.GUIDE) et seulementces services. Cette politique permet la réalisationd’une déclaration relative aux procédures de certi-fication de la TOE.

P.PUBLICATION O.DISPOO.VERIF

La politique de publication détermine les condi-tions de disponibilités des biens publics publiés(O.DISPO). Le processus de vérification de certi-ficat n’est valable que si une politique de publica-tion est mise en oeuvre (O.VERIF).

P.PLAN-SECOURS O.DISPOO.PLAN-SECOURS

Un plan de secours (O.PLAN-SECOURS) permetde rendre disponibles au moins les services vitauxde sécurité (O.DISPO) en un temps donné et sousdes conditions définies dans le plan de secours.

Hypothèses Objectifs sur l’environ-nement de la TOE Justificatifs

H.USAGE O.ENV_INFOO.GUIDE

L’environnement de la TOE (O.ENV-INFO) ainsiqu’un guide d’utilisation (O.GUIDE) à jour garan-tissent l’utilisation de la TOE dans des conditionsd’emploi adéquates.

Tab. 7.3 -Couverture des politiques de sécurité par les objectifs de sécurité

Politiques de sécurité Objectifs de sécurité Justificatifs

7.3 Tableau croisé

250 Le tableau croisé ci-dessous démontre que chaque objectif de sécurité répond aumoins à une menace ou à une politique de sécurité organisationnelle.

Tab. 7.5 -Tableau croisé objectifs de sécurité / menaces

H.RESP O.RESPONSABLELes utilisateurs et exploitants de la TOE doiventconnaitre les responsabilités qui leur incombentpour répondre à l’objectif O.RESPONSABLE.

H.RESSOURCE O.RESSOURCEO.CONFIDENTIALITE

Les ressources cryptographiques utilisées (O.RES-SOURCE) ont été évaluées selon des critèresd’évaluation de la sécurité des systèmes d’infor-mation en vigueur. (Dans le cas du traitement d’in-formations classifiées de défense, les ressourcescryptographiques sont conformes au [PP_OSM]).La ressource cryptologique garantit la protectionen confidentialité des biens secrets (O.CONFI-DENTIALITE).

Menaces sur la TOE


O.A

CC

ES

O.A

CC

US

E

O.E

NR

EG

IST

RE

ME

NT

O.R

ES

SO

UR

CE

O.R

EV

OC

O.A

UD

IT

O.A

RC

HIV

ES

O.V

ER

IF

O.E

XP

OR

T

O.D

AT

E

O.IN

TE

GR

ITE

O.C

ON

FID

EN

TIA

LITE

O.D

YS

FO

NC

O.D

ISP

O

O.S

EP

AR

AT

ION

O.A

DM

INIS

TR

AT

ION

O.P

LAN

-SE

CO

UR

S

O.R

ES

PO

NS

AB

LE

O.G

UID

E

O.D

ES

TR

UC

TIO

N

O.E

NV

-INF

O

O.C

OH

ER

EN

T

M.DYSFONC X X X X X X

M.INTRUSION X X X X X X

M. INIT IALISA-TION

X X X

M.CLONAGE X X

M.RESIDUEL X X

M.DENI X X X

Hypothèses Objectifs sur l’environ-nement de la TOE Justificatifs

Pa

ge 6

5

Ta

b. 7

.6 -

Tab

lea

u c

rois

é o

bject

ifs d

e s

écu

rité

/ m

ena

ces

sur

l’en

viro

nne

me

nt d

e la

TO

E

M.IN

CO

NS

IST

AN

TX

X

M.U

SA

GE

X

M.IN

VA

LID

EX

XX

Men

aces

sur

l’en

vi-

ronn

emen

t de

la

TO

E

Obj

ectif

s de

séc

urité

O.ACCES

O.ACCUSE

O.ENREGISTREMENT

O.RESSOURCE

O.REVOC

O.AUDIT

O.ARCHIVES

O.VERIF

O.EXPORT

O.DATE

O.INTEGRITE

O.CONFIDENTIALITE

O.DYSFONC

O.DISPO

O.SEPARATION

O.ADMINISTRATION

O.PLAN-SECOURS

O.RESPONSABLE

O.GUIDE

O.DESTRUCTION

O.ENV-INFO

O.COHERENT

M.M

AIN

TE

NA

NC

EX

XX

M.S

AT

UR

AT

ION

XX

XX

M.S

INIS

TR

EX

XX

X

M.V

OL

-SU

PP

OR

TX

X

M.V

IRA

LX

XX

X

M.M

OY

EN

XX

X

M.F

LU

X-E

XT

ER

-N

EX

XX

M.IN

TE

R-I

TX

Men

aces

sur

la

TO

E

Obj

ectif

s de

séc

urité

O.ACCES

O.ACCUSE

O.ENREGISTREMENT

O.RESSOURCE

O.REVOC

O.AUDIT

O.ARCHIVES

O.VERIF

O.EXPORT

O.DATE

O.INTEGRITE

O.CONFIDENTIALITE

O.DYSFONC

O.DISPO

O.SEPARATION

O.ADMINISTRATION

O.PLAN-SECOURS

O.RESPONSABLE

O.GUIDE

O.DESTRUCTION

O.ENV-INFO

O.COHERENT

Tab. 7.7 -Tableau croisé objectifs de sécurité / politiques de sécurité

7.4 Justificatif des exigences de sécurité

7.4.1 Tableau de couverture

251 Le tableau ci-dessous démontre que l’ensemble des objectifs de sécurité sontcouverts par au moins une exigence fonctionnelle et que toutes les exigencesatteignent au moins un objectif de sécurité.

Politiques et hypo-thèses de sécurité


O.A

CC

ES

O.A

CC

US

E

O.E

NR

EG

IST

RE

ME

NT

O.R

ES

SO

UR

CE

O.R

EV

OC

O.A

UD

IT

O.A

RC

HIV

ES

O.V

ER

IF

O.E

XP

OR

T

O.D

AT

E

O.IN

TE

GR

ITE

O.C

ON

FID

EN

TIA

LITE

O.D

YS

FO

NC

O.D

ISP

O

O.S

EP

AR

AT

ION

O.A

DM

INIS

TR

AT

ION

O.P

LAN

-SE

CO

UR

S

O.R

ES

PO

NS

AB

LE

O.G

UID

E

O.D

ES

TR

UC

TIO

N

O.E

NV

-INF

O

O.C

OH

ER

EN

T

P.UTILIS X

P.ROLES X

P.RECOUVR X X

P.CERT X X X X X X X X X X X

P.PUBLICATION X X

P.PLAN-SECOURS X X

H.USAGE X X

H.RESP X

H.RESSOURCE X X

Tab. 7.8 -Couverture Objectifs - Exigences

Exigencesfonctionnelles


O.A

CC

ES

O.E

NR

EG

IST

RE

ME

NT

O.R

ES

SO

UR

CE

O.R

EV

OC

O.A

UD

IT

O.A

RC

HIV

ES

O.V

ER

IF

O.P

UB

LICA

TIO

N

O.E

XP

OR

T

O.D

AT

E

O.IN

TE

GR

ITE

O.C

ON

FID

EN

TIA

LITE

O.D

YS

FO

NC

O.D

ISP

O

O.S

EP

AR

AT

ION

O.E

CH

AN

GE

O.A

DM

INIS

TR

AT

ION

FAU_ARP.1 X X X

FAU_GEN.1 X

FAU_GEN.2 X

FAU_SAA.2 X

FAU_SAR.1 X

FAU_SAR.2 X

FAU_SAR.3 X

FAU_SEL.1 X

FAU_STG.2 X X X

FAU_STG.4 X

FMT_MOF.1 X

FMT_MSA.1 X

FMT_MSA.2 X

FMT_MSA.3 X

FMT_MTD.1 X

FMT_MTD.2 X

FMT_MTD.3 X

FMT_REV.1 X X

FMT_SAE.1 X X X

FMT_SMR.2 X X X X X X X X X X X

FMT_SMR.3 X

FCO_NRO.2 X X X X

FCO_NRR.1

FCS_CKM.1 X

FCS_CKM.2 X X X

FCS_CKM.3 X X X X X X

FCS_CKM.4 X X

FCS_COP.1 X X X

FDP_ACC.2 X

FDP_ACF.1 X

FDP_DAU.2 X X

FDP_ETC.2 X

FDP_IFC.2 X X X X X

FDP_IFF.1 X X X X X

FDP_ITT.2 X X X X

FDP_ITT.3 X X

FDP_RIP.1



O.A

CC

ES

O.E

NR

EG

IST

RE

ME

NT

O.R

ES

SO

UR

CE

O.R

EV

OC

O.A

UD

IT

O.A

RC

HIV

ES

O.V

ER

IF

O.P

UB

LICA

TIO

N

O.E

XP

OR

T

O.D

AT

E

O.IN

TE

GR

ITE

O.C

ON

FID

EN

TIA

LITE

O.D

YS

FO

NC

O.D

ISP

O

O.S

EP

AR

AT

ION

O.E

CH

AN

GE

O.A

DM

INIS

TR

AT

ION

FDP_SDI.2 X

FDP_UIT.1 X X X

FDP_UIT.2 X

FIA_AFL.1 X

FIA_ATD.1 X

FIA_SOS.1 X X X

FIA_SOS.2 X X X X

FIA_UAU.2 X

FIA_UAU.3 X

FIA_UAU.5 X

FIA_UAU.6 X

FIA_UID.2 X

FPT_AMT.1 X

FPT_FLS.1 X

FPT_ITA.1 X

FPT_ITC.1 X X X

FPT_ITI.1 X X X

FPT_ITT.1 X X

FPT_ITT.3 X



O.A

CC

ES

O.E

NR

EG

IST

RE

ME

NT

O.R

ES

SO

UR

CE

O.R

EV

OC

O.A

UD

IT

O.A

RC

HIV

ES

O.V

ER

IF

O.P

UB

LICA

TIO

N

O.E

XP

OR

T

O.D

AT

E

O.IN

TE

GR

ITE

O.C

ON

FID

EN

TIA

LITE

O.D

YS

FO

NC

O.D

ISP

O

O.S

EP

AR

AT

ION

O.E

CH

AN

GE

O.A

DM

INIS

TR

AT

ION

7.4.2 Justifications

252 Les exigences fonctionnelles retenues dans ce profil de protection coopèrent etforment un tout cohérent.

FPT_PHP.2 X

FPT_RCV.3 X X

FPT_RCV.4 X

FPT_RPL.1 X

FPT_SEP.2 X

FPT_SSP.1

FPT_STM.1 X

FPT_TDC.1

FPT_TRC.1 X

FPT_TST.1 X X

FTA_SSL.1 X

FTA_SSL.2 X

FTA_SSL.3 X

FTA_TSE.1 X

FTP_ITC.1 X X X

FTP_TRP.1 X



O.A

CC

ES

O.E

NR

EG

IST

RE

ME

NT

O.R

ES

SO

UR

CE

O.R

EV

OC

O.A

UD

IT

O.A

RC

HIV

ES

O.V

ER

IF

O.P

UB

LICA

TIO

N

O.E

XP

OR

T

O.D

AT

E

O.IN

TE

GR

ITE

O.C

ON

FID

EN

TIA

LITE

O.D

YS

FO

NC

O.D

ISP

O

O.S

EP

AR

AT

ION

O.E

CH

AN

GE

O.A

DM

INIS

TR

AT

ION

7.4.3 Composante FMT

FMT_MOF.1 Management of security functions behaviour

253 La possibilité de modifier les fonctions de sécurité de la TOE est nécessaire à uneadministration (O.ADMINISTRATION).


254 La possibilité de modifier les attributs de sécurité de la TOE est nécessaire à uneadministration évolutive (O.ADMINISTRATION).


255 Cette exigence permet de s’assurer que la modification d’un attribut de securitélaisse cet attribut affecté à une valeur de confiance, et contribue à satisfaire en partieO.ADMINISTRATION.


256 A l’initilisation de la TOE, l’enregistrement d’un nouvel utilisateur ou la créationd’un nouveau bien, les valeurs par défaut doivent être de confiance et déterminéespar le personnel autorisé (O.ADMINISTRATION) (opérateur, administrateur, cf.[ROLES_IGC].


257 Cette exigence spécifie les rôles à modifier les valeurs par défaut des attributs desécurité et des fonctions de sécurité. En ce sens, elle satisfait partiellementO.ADMINISTRATION.


258 Cette exigence permet de définir un intervalle de confiance à l’intérieur duquel lesvaleurs d’un attribut de sécurité doivent se trouver, les rôles autorisés à déterminerles bornes ainsi que les mesures à prendre en cas de dépassement des limites fixées.Cette exigence contribue à satisfaire l’administration de la TOE(O.ADMINISTRATION).


259 La définition des variables propres à la TOE est fixée par cette exigencefonctionnelle à une valeur de confiance, répondant ainsi partiellement à l’objectifO.ADMINISTRATION.


260 La révocation des utilisateurs, exploitants ou composantes est effectuée selon desrègles prédéfinies (liées à la politique de certification [PC2]). par l’exploitant

autorisé. Cette exigence contribue à satisfaire en partie les objectifsO.ADMINISTRATION et O.REVOC.


261 L’enregistrement, le renouvellement (O.ENREGISTREMENT) et la révocation(O.REVOC) nécessitent une spécification et une gestion des dates d’expiration (cf.[VAR_TEMPS]). Cette exigence définit aussi les exploitants responsables de cettetâche ainsi que les actions à prendre en cas de dépassement de la date d’expirationd’un attribut de sécurité (O.ADMINISTRATION).


262 Cette exigence définit les rôles des exploitants nécessaires à l’exploitation etl’administration de la TOE (O.ADMINISTRATION). La définition des rôlesdétermine les actions attribuées à chaque type d’exploitant comme la gestion desaccès à la TOE (O.ACCES), l’enregistrement (O.ENREGISTREMENT) la mise enoeuvre des ressources cryptologiques (O.RESSOURCE), la vérification descertificats (O.VERIF), la révocation (O.REVOC), la consultation des journauxd’événements (O.AUDIT), la gestion des archives (O.ARCHIVES), la publication(O.PUBLICATION), la délivrance aux autorités légales (O.EXPORT) et la gestionde l’horodatage (O.DATE).

263 La composante précise aussi les cas d’exclusion mutuelle des différents rôles (cf.[ROLES_IGC]).


264 Cette composante précise que les contrôles d’accès sont intimement liés à lareconnaissance des rôles d’exploitants, facilitant ainsi l’administration de la TOE(O.ADMINISTRATION)

7.4.4 Composante FCO


265 La gestion des certificats de clés publiques à des fins d’intégrité (authentification etsignature) (O.INTEGRITE) impose un engagement légal de l’émetteur.

266 La preuve d’origine apparait à un niveau interne comme externe.

267 Deux types de besoins de preuve de l’origine d’attributs de sécurité apparaissent.

268 Le premier besoin est interne et est nécessaire à l’administration de la TOE(O.ADMINISTRATION) (imputabilité et non répudiation des actions desexploitants, authentification des objets importés et exportés de la TOE).

269 Le second besoin est externe et donne la possibilité à un utilisateur de s’assurer del’origine d’un certificat publié par la TOE (O.EXPORT etO.ENREGISTREMENT).


270

7.4.5 Composante FCS


271 Cette exigence spécifie les algorithmes à utiliser pour la génération des clés crypto-graphiques dans une ressource de confiance (O.RESSOURCE).


272 Cette exigence spécifie les méthodes de distribution de clés à utiliser pour la publi-cation des certificats (O.PUBLICATION) et la remise des clés de confidentialité(O.EXPORT) et l’exportation d’une clé de la ressource (O.RESSOURCE).


273 Cette exigence spécifie les méthodes d’accès aux clés gérées par la ressource(O.RESSOURCE) pour la publication (O.PUBLICATION), la délivrance des clés(O.EXPORT), les mécanismes de signature et de chiffrement (O.INTEGRITE,O.CONFIDENTIALITE), et la gestion des archives (O.ARCHIVES).


274 Cette exigence spécifie les méthodes de destruction d’un utilisateur ou d’unecomposante (O.REVOC) et l’effacement logique et/ou physique de clés dans lacomposante (O.RESSOURCE).


275 Cette exigence spécifie les modes opératoires des algorithmes et les protocolescryptographiques d’une IGC pour assurer la détection de perte d’intégrité (O.INTE-GRITE) et de confidentialité (O.CONFIDENTIALITE) dans la ressource crypto-graphique (O.RESSOURCE).

7.4.6 Composante FDP


276 Cette composante précise que tous les biens et ressources de la TOE sont régis parune politique de contrôle d’accès. Cette politique de contrôle d’accès est basée surle besoin d’en connaître, et le rôle de l’exploitant (O.ACCES).


277 Cette exigence précise sur quels attributs de sécurité (par exemple le rôle del’exploitant, un attribut propre à l’objet) et selon quelles règles sont basés lescontrôles d’accès (O.ACCES).


278 Cette exigence rend possible la génération d’une preuve de l’authentification del’auteur d’une action ou d’une information effectuée à l’intérieur de la TOE(O.ADMINISTRATION, O.AUDIT).


279 L’export de données à l’extérieur de la TOE est effectué en respect des règles desécurité garantissant également l’export des attributs de sécurité. Cette exigenceconcourt à satisfaire l’objectif (O.EXPORT).


280 Cette exigence précise que tous les services de sécurité qui nécessitent un fluxd’informations gérés par la TOE, doivent être couverts par une politique de sécuritédes flux (O.ENREGISTREMENT, O.REVOC, O.PUBLICATION, O.EXPORT,O.INTER-IT, O.ARCHIVES).


281 Cette exigence précise que les politiques de sécurité régissant les fluxd’informations gérés par la TOE sont basés sur les attributs de sécurité des objets etsujets de la TOE (O.ENREGISTREMENT, O.REVOC, O.PUBLICATION,O.EXPORT, O.INTER-IT, O.ARCHIVES).

FDP_ITT.2 Transmission separation by attribute

282 Cette exigence requiert des contrôles d’accès (O.ACCES) associés aux objetslorsque ceux-ci sont échangés entre deux parties distinctes de la TOE ou desdomaines de sécurité différents (O.SEPARATION), afin d’en préserver l’intégritéet la confidentialité (O.INTEGRITE, O.CONFIDENTIALITE).


283 Les contrôles d’accès (O.ACCES) permettent de détecter la perte d’intégrité desbiens gérés par la TOE (O.INTEGRITE, O.COHERENT).



284 Cette exigence permet de détecter la perte d’intégrité des biens conservés dans laTOE, satisfaisant en partie les objectifs O.INTEGRITE et O.COHERENT.


285 L’échange ou l’export de données (O.EXPORT, O.ECHANGE)ne porte pasatteinte à l’intégrité des biens gérés par la TOE (O.INTEGRITE, O.COHERENT).


286 Cette exigence rend possible le recouvrement de certains biens, moyennant lesautorisations nécessaires (O.EXPORT).

7.4.7 Composante FIA


287 Cette exigence détermine le nombre de tentatives d’authentification autorisées etles actions à prendre en cas d’échec. Cette exigence contribue à satisfaireO.ACCES.


288 Cette exigence définit les attributs de sécurité des personnes interagissant avec laTOE (O.ACCES).


289 Cette exigence définit la métrique des variables cryptographiques nécessairess àl’authentification des utilisateurs (O.ACCES) et la confidentialité des biens àprotéger (O.CONFIDENTIALITE). Ce mécanisme est implémenté dans laressource de cryptographie (O.RESSOURCE).


290 Cette composante définit la liste des méthodes employées par la TOE pour générerles variables cryptographiques secrètes générées (O.RESSOURCE) et employéespar la TOE pour l’identification des utilisateurs et exploitants (O.ACCES), laconservation de l’intégrité et de la confidentialite des biens échangés(O.INTEGRITE, O.CONFIDENTIALITE).


291 Cette exigence impose une authentification par la TOE avant l’exécution possiblede toute action. Elle concourt à satisfaire les objectifs O.ACCES.

FIA_UAU.3 Unforgeable authentication

292 La TOE doit être en mesure de prévenir et détecter une falsification des donnéesd’utilisateur (O.INTEGRITE).


293 La TOE supporte plusieurs mécanismes d’authentification pouvant varier entrecomposantes ou ressources (O.ACCES).


294 La ré-authentification est mise en oeuvre après un délai d’inactivité fixé par l’auto-rité de sécurité (en cas de non ré-authentification, la session d’utilisation de la TOEest close). Cette composante permet de réaliser en partie l’objectif O.ACCES.


295 Cette exigence impose l’authentification d’un utilisateur ou d’un exploitant avantl’exécution de toute action (O.ACCES).

7.4.8 Composante FPT


296 L’observation du fonctionnement de la TOE par rapport au résultats donnés par unmodèle abstrait permet de détecter les dysfonctionnements de la TOE(O.DYSFONC).


297 En cas de dysfonctionnement, cette exigence permet de spécifier la liste des inci-dents après lesquels un état stable de la TOE est assuré (O.DYSFONC).

FPT_ITA.1 Inter-TSF availability within a defined availability metric

298 Cette exigence spécifie que les clés privées de confidentialité doivent être disponi-bles à la TPC en cas de demande légale de recouvrement de clé (O.EXPORT).

FPT_ITC.1 Inter-TSF confidentiality during transmission

299 Cette exigence définit la protection de la confidentialité des données échangéesentre la TOE et une autre composante des systèmes d’information évaluée. Cetteprotection de la confidentialité concerne la protection des clés aux autorités légales(O.EXPORT), l’enregistrement (pour les données privées d’utilisateurs, (O.ENRE-GISTREMENT) et clés de confidentialité ou clé privées de signature (O.CONFI-DENTIALITE) ainsi que les motifs de révocation.


300 Cette exigence définit la protection de la confidentialité des données échangéesentre la TOE et une autre composante des systèmes d’information évaluée. Cetteprotection de la confidentialité concerne la protection des clés aux autorités légales(O.EXPORT), l’enregistrement (pour les données privées d’utilisateurs, O.ENRE-

GISTREMENT) et clés de confidentialité ou de signature (O.INTEGRITE) ainsique les motifs de révocation.


301 Par nature, la TOE protège en intégrité (O.INTEGRITE) et en confidentialité(O.CONFIDENTIALITE) les informations échangées entre les différentes compo-santes de la TOE.


302 Cette exigence impose un contrôle d’intégrité des informations transmises entredifférentes composantes de la TOE et les actions à prendre en cas de détectiond’atteinte à l’intégrité (O.INTEGRITE).


303 Les fonctions de sécurité de la TOE doivent permettre de détecter toute tentatived’attaque physique sur la TOE et satisfont ainsi en partie l’objectif O.DYSFONC.


304 Après détection d’un dysfonctionnement (O.DYSFONC), la TOE doit impérative-ment être dans un état stable dit de confiance, recouvrant au minimum les servicesvitaux de sécurité (O.DISPO).


305 Des scénarios de dysfonctionnement de la TOE sont prévus et des réactions adap-tées sont définies, afin que la TOE retrouve un état stable et de confiance(O.DYSFONC).


306 Les services de sécurité de la TOE permettent de détecter des accès répétés auservice de publication de la TOE. Cette exigence définit aussi les mesures à prendreen cas de détection d’accès répétés à ce service (O.PUBLICATION).


307 La séparation des services “communicants” de la TOE avec les services qui gèrentles biens secrets garantit la protection de la confidentialité des biens secrets(O.CONFIDENTIALITE).


308


309 La TOE fournit un temps de référence afin de satisfaire l’objectif O.DATE.


310 Cette exigence assure la détection d’une inconsistance (O.COHERENT) de l’inter-prétation d’un bien échangé entre la TOE et un autre produit de confiance.


311 Cette exigence assure que le partage des biens entre composantes de la TOEn’entraîne pas d’inconsistance de ces biens (O.ADMINISTRATION).


312 Les fonctions de sécurité de la TOE fournissent un ensemble de tests qui permettentde s’assurer de leur bon fonctionnement par rapport à un modèle abstrait (cf.FPT_AMT.1). En cas de détection de dysfonctionnement, des mesures conserva-toires doivent être prises pour contribuer à l’objectif O.DYSFONC et O.DISPO.

7.4.9 Composante FTA


313 Cette exigence assure le verrouillage de la session d’un utilisateur après un certaintemps d’inactivité. Elle satisfait en partie l’objectif O.ACCES.


314 Cette exigence donne la possibilité à l’utilisateur de verrouiller lui-même sasession. Elle satisfait en partie l’objectif O.ACCES.


315 Cette exigence assure la déconnexion de la session d’un utilisateur après un certaintemps d’inactivité. Elle satisfait en partie l’objectif O.ACCES.


316 Cette composante permet de filtrer les ouvertures de session en fonctiond’exigences de sécurité prédéfinies (O.ACCES).

7.4.10 Composante FTP


317 Lorsqu’une composante de la TOE communique avec un produit de sécurité deconfiance alors le canal de communication utilisé doit être sécurisé et distinct de

tous les autres canaux de communication. Cette exigence satisfait en partie lesobjectifs O.SEPARATION, O.INTEGRITE et O.CONFIDENTIALITE.


318 Cette exigence assure qu’un chemin de confiance relie la TOE à l’utilisateur et queles canaux de communication utilisés favorisent la séparation des domaines desécurité (O.SEPARATION).

7.4.11 Composante FAU


319 A la détection d’une violation potentielle de sécurité de la TOE, le système doitgénérer une alarme, contribuant ainsi à atteindre les objectifs O.DYSFONC etO.ACCES et O.AUDIT.

320 Remarque: le rédacteur de la ST devra rédiger une table de correspondance entredes événements susceptibles de porter atteinte à la sécurité de la TOE, des actionscorrectives à prendre et un délai de mise en oeuvre de ces actions. Il devra préciserpour chaque type d’événements l’opportunité de rendre compte à l’autorité desécurité.


321 Les différentes actions à auditer sont détaillées dans le tableau 3.2. L’audit sur cesactions contribue à satisfaire O.AUDIT.


322 Chaque événement audité doit être imputable à la personne (identifiant et rôle) ouau processus qui l’a exécuté, ce qui satisfait partiellement l’objectif O.AUDIT.


323 Des profils prédéfinis permettent de détecter toute action non autorisée par le profil.Cette composante satisfait en partie l’objectif O.AUDIT.


324 Cette exigence fonctionnelle impose que les traces d’audit soient lisibles etexploitables par des utilisateurs dûment autorisés. Cette exigence satisfait en partiel’objectif O.AUDIT.


325 Cette exigence fonctionnelle définit quels sont les utilisateurs ayant accès aux tracesd’audit. Cette exigence satisfait en partie l’objectif O.AUDIT.


326 Cette exigence fonctionnelle définit les différents types de requêtes possibles sur lestraces d’audit et la nature du filtre. Cette exigence facilite l’administration(O.AUDIT) de la TOE.


327 Cette exigence donne la possibilité d’ajouter ou de supprimer différents typesd’événements audités (à partir d’identifiants d’attributs). Cette exigence couvre enpartie l’objectif O.AUDIT en rendant l’administration évolutive.


328 Les traces d’audit sont des biens secrets de la TOE (cf. chapitre 3.4). A ce titre, leuraccès est contrôlé. Toute perte d’intégrité doit être détecté et ils doivent êtredisponibles pour les besoins d’adminsitration de la TOE. Cette exigence satisfait enpartie O.INTEGRITE, O.ACCES et O.AUDIT.


329 L’administration des traces d’audit prévoit une action en cas de dépassement de lataille limite des fichiers d’audit, et une action en cas de perte de ces fichiers. Cetteexigence satisfait en partie les objectifs O.AUDIT, O.ADMINISTRATION.

7.5 Dépendances des composants d’exigences

330 Pour l’évaluation de ce profil de protection, il est nécessaire de vérifier que toutesles dépendances sont satisfaites. Le tableau ci-dessous démontre l’absence dedépendances internes non satisfaites.

331 Le symbole “---” signifie que la composante n’admet pas de dépendance.

Tab. 7.9 -Dépendances des composantes d’exigences

Exigences fonctionnelles Nom Dépendances

CC Satisfaction

FAU_ARP.1 Security alarms FAU_SAA.1 FAU_SAA.2

FAU_GEN.1 Audit Data Generation FPT_STM.1 FPT_STM.1

FAU_GEN.2 User identity association FAU_GEN.1FIA_UID.1

FAU_GEN.1FIA_UID.2

FAU_SAA.2 Profile based anomaly detection FIA_UID.1 FIA_UID.2

FAU_SAR.1 Audit review FAU_GEN.1 FAU_GEN.1

FAU_SAR.2 Restricted audit review FAU_SAR.1 FAU_SAR.1

FAU_SAR.3 Selectable audit review FAU_SAR.1 FAU_SAR.1

FAU_SEL.1 Selective audit FAU_GEN.1FMT_MTD.1

FAU_GEN.1FMT_MTD.1

FAU_STG.2 Guarantees of audit data availability FAU_GEN.1 FAU_GEN.1

FAU_STG.4 Prevention of audit data loss FAU_STG.1 FAU_STG.2

FMT_MOF.1 Management of security functions behaviour FMT_SMR.1 FMT_SMR.2

FMT_MSA.1 Management of security attributes FDP_ACC.1 orFDP_IFC.1FMT_SMR.1

FDP_ACC.1

FMT_SMR.2

FMT_MSA.2 Secure security attributes ADV_SPM.1FDP_ACC.1 or FDP_IFC.1FMT_MSA.1FMT_SMR.1

ADM_SPM.1FDP_ACC.2

FMT_MSA.1FMT_SMR.2

FMT_MSA.3 Static attribute initialisation FMT_MSA.1FMT_SMR.1

FMT_MSA.1FMT_SMR.2

FMT_MTD.1 Management of TSF data FMT_SMR.1 FMT_SMR.2

FMT_MTD.2 Management of limits on TSF data FMT_MTD.1FMT_SMR.1

FMT_MTD.1FMT_SMR.2

FMT_MTD.3 Secure TSF data ADV_SPM.1FMT_MTD.1

ADV_SPM.1FMT_MTD.1

FMT_REV.1 Revocation FMT_SMR.1 FMT_SMR.2

FMT_SAE.1 Time-limited authorisation FMT_SMR.1FPT_STM.1

FMT_SMR.2FPT_STM.1

FMT_SMR.2 Restrictions on security roles --- ---

FMT_SMR.3 Assuming roles FMT_SMR.1 FMT_SMR.2

FCO_NRO.2 Enforced proof of origin FIA_UID.1 FIA_UID.2

FCO_NRR.1 Selective proof of receipt FIA_UID.1 FIA_UID.2

FCS_CKM.1 Cryptographic key generation FCS_CKM.2 orFCS_COP.1FCS_CKM.4FMT_MSA.2

FCS_CKM.2

FCS_CKM.4FMT_MSA.2

FCS_CKM.2 Cryptographic key distribution FDP_ITC.1 orFCS_CKM.1FCS_CKM.4FMT_MSA.2

FCS_CKM.1FCS_CKM.4FMT_MSA.2

FCS_CKM.3 Cryptographic key access FDP_ITC.1 orFCS_CKM.1FCS_CKM.4FMT_MSA.2


FCS_CKM.4 Cryptographic key destruction FDP_ITC.1 orFCS_CKM.1FMT_MSA.2

FCS_CKM.1FMT_MSA.2

FCS_COP.1 Cryptographic operation FDP_ITC.1 orFCS_CKM.1FCS_CKM.4FMT_MSA.2


FDP_ACC.2 Complete access control FDP_ACF.1 FDP_ACF.1


CC Satisfaction

FDP_ACF.1 Security attribute based access control FDP_ACC.1FMT_MSA.3

FDP_ACC.2FMT_MSA.3

FDP_DAU.2 Data authentication with identity of guarantor FIA_UID.1 FIA_UID.2

FDP_ETC.2 Export of user data with security attributes FDP_ACC.1FDP_IFC.1

FDP_ACC.2FDP_IFC.2

FDP_IFC.2 Complete information flow control FDP_IFF.1 FDP_IFF.1

FDP_IFF.1 Simple security attributes FDP_IFC.1FMT_MSA.3

FDP_IFC.2FMT_MSA.3

FDP_ITT.2 Transmission separation by attributes FDP_ACC.1 orFDP_IFC.1

FDP_ACC.2FDP_IFC.2

FDP_ITT.3 Integrity monitoring FDP_ACC.1 orFDP_IFC.1FDP_ITT.1

FDP_ACC.2

FDP_ITT.2

FDP_RIP.1 Subset residual information protection --- ---

FDP_SDI.2 Stored data integrity monitoring and action --- ---

FDP_UIT.1 Data exchange integrity FDP_ACC.1 orFDP_IFC.1FTP_ITC.1 orFTP_TRP.1

FDP_ACC.2

FTP_ITC.1

FDP_UIT.2 Source data exchange recovery FDP_ACC.1 orFDP_IFC.1FDP_UIT.1FTP_ITC.1

FDP_ACC.2

FDP_UIT.1FTP_ITC.1

FIA_AFL.1 Authentication failure handling FIA_UAU.1 FIA_UAU.2

FIA_ATD.1 User attribute definition --- ---

FIA_SOS.1 Verification of secrets --- ---

FIA_SOS.2 TSF Generation of secrets --- ---

FIA_UAU.2 User authentication before any action FIA_UID.1 FIA_UID.2

FIA_UAU.3 Enforgeable authentication --- ---


CC Satisfaction

FIA_UAU.5 Multiple authentication mechanisms --- ---

FIA_UAU.6 Re-authenticating --- ---

FIA_UID.2 User identification before any action --- ---

FPT_AMT.1 Abstract machine testing --- ---

FPT_FLS.1 Failure with preservation of secure state ADV_SPM.1 ADV_SPM.1

FPT_ITA.1 Inter-TSF availability within a definedavailability metric

--- ---

FPT_ITC.1 Inter-TSF confidentialité during transmission --- ---

FPT_ITI.1 Inter-TSF detection of modification --- ---

FPT_ITT.1 Basic internal TSF data transfer protection --- ---

FPT_ITT.3 TSF data integrity monitoring FPT_ITT.1 FPT_ITT.1

FPT_PHP.2 Notification of physical attack FMT_MOF.1 FMT_MOF.1

FPT_RCV.3 Automated recovery without undue loss FPT_TST.1AGD_ADM.1ADV_SPM.1

FPT_TST.1AGD_ADM.1ADV_SPM.1

FPT_RCV.4 Function recovery ADV_SPM.1 ADV_SPM.1

FPT_RPL.1 Replay detection --- ---

FPT_SEP.2 SFP domain separation --- ---

FPT_SSP.1 Simple trusted acknowledgement FPT_ITT.1 FPT_ITT.1

FPT_STM.1 Reliable time stamps --- ---

FPT_TDC.1 Inter-TSF basic TSF data consistency --- ---

FPT_TRC.1 Internal TSF consistency FPT_ITT.1 FPT_ITT.1

FPT_TST.1 TSF testing FPT_AMT.1 FPT_AMT.1

FTA_SSL.1 TSF-initiated session locking FIA_UAU.1 FIA_UAU.2

FTA_SSL.2 User-initiated locking FIA_UAU.1 FIA_UAU.2


CC Satisfaction

FTA_SSL.3 TSF-initiated termination --- ---

FTA_TSE.1 TOE session establishment --- ---

FTP_ITC.1 Inter-TSF trusted channel --- ---

FTP_TRP.1 Trusted path --- ---


CC Satisfaction

7.6 Dépendances des composantes d’assurance

332 Pour l’évaluation de ce profil de protection, il est nécessaire de vérifier quel’ensemble des composantes d’assurance retenue (cf. Tab. 5.3, 5.4) est consistant.

333 Par définition l’ensemble des classes d’assurance (Tab. 5.3) définissant le niveauEAL 4 est consistant.

334 Le tableau 7.10démontre comment les dépendances de toutes les composantesd’assurance (Tab 5.4) retenues pour augmenter le niveau EAL4 ont été satisfaites.

335

Tab. 7.10 -Dépendances des composantes d’exigences supplémenraires

336 Les dépendances des composantes d’assurance retenues sont toutes satisfaites.


CC Satisfaction

ADV_IMP.2 Implementation of the TSF ADV_LLD.1ADV_RCR.1ALC_TAT.1

ADV_LLD.1ADV_RCR.1ALC_TAT.1

AVA_CCA.1 Covert channel analysis ADV_FSP.2ADV_IMP.2AGD_ADM.1AGD_USR.1

ADV_FSP.2ADV_IMP.2AGD_ADM.1AGD_USR.1

AVA_MSU.3 Analysis and testing for insecure states ADO_IGS.1ADV_FSP.1AGD_ADM.1AGD_USR.1

ADO_IGS.1ADV_FSP.2AGD_ADM.1AGD_USR.1

AVA_VLA.4 Highly resistant ADV_FSP.1ADV_HLD.2ADV_IMP.1ADV_LLD.1AGD_ADM.1AGD_USR.1

ADV_FSP.2ADV_HLD.2ADV_IMP.2ADV_LLD.1AGD_ADM.1AGD_USR.1

Annexe A

Abréviations et Glossaire

A.1 Abréviations

- AC : Autorité de Certification de clés publiques.

- ANSI : American National Standard Institute.

- CC : Critères Communs d’Evaluation de la Sécurité des Technologies del’Information.

- EAL : Evaluation Assurance Level. Niveau d’assurance et d’évaluation. Unpaquet de composantes d’assurance tirées de la Partie 3 des CritèresCommuns qui représente un niveau de l’échelle prédéfinie de l’assurancedes CC [CC].

- IGC : Infrastructure de Gestion de Clés. Cette infrastructure est l’ensembledes tiers nécessaires à la gestion des clés d’authentification et de signatureet des clés de confidentialité. Les clés d’intégrité sont certifiées par les ACet les clés de confidentialité sont gérées par les TPC.

- IETF : Internet Engineering Task Force.

- IT : Information Technology. Technologies de l’information.

- PP : Protection Profile. Profil de protection. Un ensemble d’exigences desécurité valables pour une catégorie de TOE, indépendant de sonimplémentation, qui satisfait des besoins spécifiques d’utilisateurs [CC].

- SF : Security Functions. Fonctions de sécurité. Un ensemble qui estconstitué par tous les éléments matériels, logiciels et microprogrammés dela TOE sur lequel on doit s’appuyer pour l’application correcte de la TSP[CC].

- SFP : Security Function Policy. Politique de sécurité appliquée à une SF.

- SoF : Strength of Function. Résistance d’une fonction. Caractéristiqued’unefonction de sécurité de la TOE exprimant les efforts minimum à fournir pourmettre en défaut le comportement de sécurité attendu par attaque directe desmécanismes de sécurité sous-jacents [CC].

- ST : Security Target. Cible de sécurité. Un ensemble d’exigences desécurité et de spécifications à utiliser comme base pour l’évaluation d’uneTOE identifiée [CC].

- TOE : Target of Evaluation. Cible d’évaluation. Un produit ou un systèmeTI et la documentation associée pour l’administrateur et pour l’utilisateurqui est l’objet d’une évaluation [CC].

- TPC : Tierce Partie de Confiance.

- TSF : TOE Security Functions. Ensemble constitué de toutes lescomposantes de la TOE relevant de l’application de la TSP

- TSP : TOE Security Policy. Ensemble de règles qui précisent commentgérer, protéger, et distribuer les biens à l’intérieur de la TOE [CC].

A.2 Glossaire

Agrément : reconnaissance formelle que le produit ou système évalué peut protégerdes informations jusqu’à un niveau spécifié dans des conditions d’emploi définies[900].

Archives : ensemble de documents ou biens ne faisant plus l’objet d’une utilisationhabituelle et présentant un intérêt administratif ou historique. (cf. Article 46 del’instruction [1300]).

Attributs de sécurité : informations associées à des sujets, des utilisateurs ou desobjets, qui sont utilisées pour l’application de la TSP [CC].

Autorité de certification (AC) : tierce partie de confiance pour la génération, lasignature et la distribution des certificats de clés publiques.

Bi-clé : couple constitué d’une clé publique et d’une clé privée et utilisé dans desalgorithmes de cryptographie asymétrique.

Certificat : ensemble de données identifiant un utilisateur et une clé. Ces donnéessont signées par une autorité de certification. Le certificat est défini dans larecommandation X 509 version 3 de l’ANSI.

Chiffrement : transformation cryptographique de données produisant uncryptogramme. [ISO 7498-2]

Chiffrement de bout en bout : chiffrement de données à l’intérieur ou au niveaudu 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 7498-2]

Chiffrement de liaison : application particulière du chiffrement à chaque liasiondu système. Le chiffrement de liaison implique que les données soient du texte enclair dans les entités relais. [ISO 7498-2]

Clé de chiffrement: série de symboles commandant les opérations de chiffrementet de déchiffrement. [ISO 7498-2]

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’unmoyen ou d’une prestation de cryptologie pour des opérations de chiffrement ou devérification de signature.

Clés privées : une clé privée est associée à une clé publique pour former un bi-clé.

Clés symétriques : clés volontairement non publiées nécessaires à la mise en œuvred’un moyen ou d’une prestation de cryptologie pour des opérations de chiffrementou 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 servicesde sécurité.

Contexte de sécurité: ensemble des éléments nécessaires pour assurer les servicesde sécurité.

Confidentialité : propriété d’une information qui n’est ni disponible, ni divulguéeaux personnes, entités ou processus non autorisés. [ISO 7498-2]

Confidentiel Défense : cette mention est réservée aux informations qui neprésentent pas en elles-mêmes un caractère secret mais dont la connaissance, laréunion ou l’exploitation peuvent conduire à la divulgation d’un secret intéressantla Défense nationale et la sûreté de l’Etat. [Article 5 du décret n° 81-514 du 12 mai1981 relatif à l’organisation de la protection des secrets et des informationsconcernant la Défense Nationale et la sûreté de l’Etat].

Cryptogramme: données obtenues par l'utilisation du chiffrement. Le contenusémantique des données résultantes n'est pas compréhensible. [ISO 7498-2]

Cryptographie: discipline visant à transformer à l’aide de conventions secrètes desinformations ou signaux clairs en informations ou signaux inintelligibles pour destiers, ou à réaliser l’opération inverse, grâce à des moyens, matériels ou logicielsconçus à cet effet. [500]

Déchiffrement: opération inverse du chiffrement.

Distribution : délivrance par une autorité de distribution aux partiescommunicantes des clés à mettre en œuvre pour chiffrer ou déchiffrer desinformations, y compris, le cas échéant, des éléments propres à d’autres abonnés.

Domaine de sécurité : ensemble des ressources et entités sur lesquelles s'appliqueune même politique de sécurité, cet ensemble étant administré par une autoritéunique.

Donnée : représentation d’une information sous une forme conventionnelledestinée à faciliter son traitement [900].

Entité : individu utilisateur, processus ou serveur sécurisé.

Entité sujet: élément du modèle fonctionnel d'un service de sécurité qui désignel'acteur ou le bénéficiaire principal de ce service (par exemple un individu vis-à-visdu 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ésignela cible ou le bénéficiaire de ce service (par exemple une ressource ou uneinformation vis-à-vis du service de contrôle d'accès).

Entité fonctionnelle: élément du modèle fonctionnel d'un service de sécurité quidé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 service: Action attendue d’un produit (ou réalisée par lui) pourrépondre à un élément du besoin d’un utilisateur donné (source NF X 50-150). Leterme 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 conditionsprévues, un produit ou un système. C’est l’autorité responsable de la mise en oeuvredu produit ou du système qui délivre cette autorisation, conformément à laréglementation en vigueur [900].

Identité : ensemble de données univoque caractérisant une entité.

Identification : procédé permettant de reconnaître un utilisateur de manière sûrepar la récupération de données qui lui sont propres.

Information : élément de connaissance susceptible d’être représenté à l’aide deconventions pour être conservé, traité ou communiqué [FEROS]. Renseignementou é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étruitesde façon non autorisée [ISO 7498-2]. L’intégrité fonctionnelle fait référence au bonfonctionnement des services.

Non-répudiation: La non-répudiation avec preuve de l’origine permet audestinataire de données d’avoir la preuve de l’identité de l’expéditeur et interdittoute tentative de ce dernier de nier qu’il a envoyé ces données [500]. La non-répudiation avec preuve de la remise permet à l’expéditeur de données d’avoir lapreuve que les données ont été remises au bon destinataire et interdit à ce derniertoute tentative de nier qu’il a reçu ces données [500].

Politique de certification : ensemble de règles identifiées par un nom qui définit letype d’applications auxquelles un certificat est adapté ou dédié [PC2].

Politique de sécurité: ensemble des critères permettant de fournir des services desécurité [ISO 7498-2].

Politique de sécurité technique : ensemble des lois, règles et pratiques quirégissent le traitement des informations sensibles et l’utilisation des ressources parle 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. Saufprécision contraire, dans le présent document, le terme service désigne unregroupement de fonctions de sécurité ou de fonctions assurant le support de celles-ci.

Session : une session représente l’intervalle de temps entre le début d’un échange oud’une communication et sa fin.

Signature numérique: données ajoutées à une unité de données, ou transformationcryptographique d'une unité de données, permettant à un destinataire de prouver lasource et l'intégrité cette unité en la protégeant contre la contrefaçon (par ledestinataire par exemple). [ISO 7498-2]. La signature, définie par le couple(message, valeur), est l’opération qui consiste à calculer à l’aide d’une clé privéeasymétrique, une valeur dépendant de tous les éléments constituant le message. Lavérification de la signature fait appel à la clé publique asymétrique correspondante.

Système d’information : tout moyen dont le fonctionnement fait appel àl’électricité et qui est destiné à élaborer, traiter, stocker, acheminer, présenter oudétruire l’information. [900]

Système ouvert: système dont chacun des composants est indépendant de toutconstructeur. Système non-propriétaire. Système comprenant des interfaces decommunication normalisées entre ses composantes.

Système de chiffrement à clé symétrique (dit à clé secrète) : tout système danslequel 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èmedans 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 restersecrète, la clé de chiffrement (dite clé publique) est publiée. La clé de chiffrementet la clé de déchiffrement forment un couple (dit couple de clés asymétriques ou bi-clés) dont les éléments sont mathématiquement dépendants.

Tierce partie de confiance : organisme gérant pour le compte d’autrui desconventions secrètes de moyens ou de prestations de cryptologie permettantd’assurer des fonctions de confidentialité.[96-659].

Utilisateur : tout entité (utilisateur humain ou entité externe des technologies del’information) hors de la TOE qui interagit avec elle.

Zonage : le principe du zonage Tempest est de délimiter, à l’intérieur d’un domainecontrôlé, une ou plusieurs zones qui présentent, pour la propagation d’un signalrayonné, des niveaux d’affaiblissement dont les valeurs se situent dans une plagedonnée [495].

Annexe B

Bibliographie

B.1 Documents relatifs aux IGC

[DUE] Proposition de Directive du Parlement européen et du conseil sur un cadre communpour les signatures électroniques 98/0191 (COD) du 13 mai 1998.

[ISO 7498-2] ISO 7498-2 : Systèmes de traitement de l’information - Interconnexion de systèmesouverts - Modèle de référence de base - Partie 2 : Architecture de sécurité (1989).

[ISO 9796-2] Digital signature giving message recovery - Hash functions, ISO/IEC DIS.

[ISO 14888] Digital signature with appendix, ISO/IEC 14888 CD.

[PC2] Procédures de Politiques de Certification de Clés. Groupe Ad Hoc MessagerieSécurisée de la Sous-Commission Chiffre de la CISSI.

[PKIX] IETF : Internet Public Key Infrastructure, Internet Drafts.

- Part 1 : X.509 Certificate and CRL Profile, September 23, 1998.- Part 4 : Certificate Policy and Certification Practices Framework,

Septembre 1, 1997.

[ROLES_IGC]Rôles des exploitants d’une infrastructure de gestion de clés. Groupe Ad HocMessagerie Sécurisée de la Sous-Commission Chiffre de la CISSI.

[VAR_TEMPS]Définition des variables de temps intervenant dans une infrastructure de gestion declés. Groupe Ad Hoc Messagerie Sécurisée de la Sous-Commission Chiffre de laCISSI.

[X.509v3] ITU-T Recommandation X.509, “Information Technology - Open SystemsInterconnection - The directory : authentication framework”, 1997 Edition.

B.2 Profils de protection

[PP_OSM] Profil de protection pour les outils de sécurisation des messages - PP/9804.

B.3 Documents relatifs aux critères d’évaluation de la sécurité des systèmes d’informations

[CC] Common Criteria for Information Technology Security Evaluation, Version 2.0.

B.4 Documents relatifs à la réglementation française

[96-659] Article 28 de la loi 90-1170 du 29 décembre 1990 sur la réglementation destélécommunications modifié par l’article 17 de la loi 96-659 du 26 juillet 1996.

[495] Directive de zonage Tempest - Protection contre les signaux compromettants, N°495 SGDN/DISSI/SCSSI . Document en diffusion restreinte.

[500] Instruction interministerielle relative au chiffre dans la sécurité des systèmesd’information, N°500 bis/SGDN/TTS/SSI/DR. Document en diffusion restreinte.

[600] Protection des informations sensibles ne relevant pas du secret de défense, N°600DISSI/SCSSI, Mars 1993.

[901] Recommandation pour la protection des systèmes d’information traitant desinformation sensibles non classifiées de défense. N°901/DISSI/SCSSI.

[900] Instruction générale interministérielle sur la sécurité des systèmes d’informationqui font l’objet d’une classification de défense pour eux-mêmes ou pour lesinformations traitées. N°900/DISSI/SCSSI/DR. Document en diffusion restreinte.

[1300] Instruction générale intermnistérielle sur la protection du secret et des informationsconcernant la défense nationale et la sûreté de l’état. N°1300/SGDN/SSD, 12 mars1982. Document en diffusion restreinte.

PROFIL DE PROTECTION INFRASTRUCTURE DE GESTION DES … · B.4 Documents relatifs à la...

Documents

Transcript of PROFIL DE PROTECTION INFRASTRUCTURE DE GESTION DES … · B.4 Documents relatifs à la...