Projet SHIVA Sous-projet 5 - Modélisation et preuves de sécurité Fourniture 5.4 Modèles, analyse et exigences Critères Communs Date : Décembre 2011 Auteurs : Marie-Laure Potet - Vérimag
Table des matières I Introduction 4 II PP Cryptographic Modules, Security Level Enhanced 5 1 Les objectifs de sécurité du PP-0045 5 2 Mécanismes de sécurité concernés par l étude 5 3 Exigences fonctionnelles de sécurité prises en compte 6 4 Exigences d assurance de sécurité prises en compte 6 5 Correspondances Critères Communs et modélisation formelle 7 III Le modèle B 9 1 Structure du modèle 9 2 Niveau 1 9 2.1 Données, services et accès........................... 10 2.1.1 Machine DATAS............................ 10 2.1.2 Machine SERVICES.......................... 10 2.1.3 Machine ObjectACrules........................ 11 2.2 Roles et accès.................................. 11 2.2.1 Machine ROLES............................ 11 2.2.2 Machine RoleACrules......................... 11 2.3 Modèle dynamique............................... 12 2.3.1 Machine ComposedMonitor...................... 12 3 Niveau 2 13 3.1 Mode courant du module et contrôle d accès sur ChangeMode....... 14 3.1.1 Machine MODES............................ 14 3.1.2 Machine MODErules.......................... 14 3.2 Modèle dynamique............................... 14 2
3.2.1 Machine ModeRefMonitor....................... 14 4 Niveau 3 16 4.1 Modèle dynamique............................... 16 4.1.1 Machine InterfMonitor......................... 16 IV Conclusion 19 5 Conclusion 19 V Annexe A 23 3
Première partie Introduction La tâche 5.4 du projet FUI SHIVA 1 avait pour objectif de proposer des modèles formels pouvant à terme être compatibles avec une démarche de certification Critères Communs, pour un niveau EAL 4+ ou EAL 5 [cc006c, cc006a, cc006b]. Les attendus de C-S Communications & Systèmes [CC10] sont à terme que le module Shiva soit compatible avec le standard BSI-CC-PP-0045 [KLR08]. Le profil de protection BSI-CC-PP-0045 est un profil dédié à l évaluation de modules cryptographiques. Il se rapproche du standard NIST FIPS 140-2 [FIP01] qui définit les exigences de sécurité que doivent satisfaire des modules cryptographiques non classifiés. La FIPS 140-2 est le standard le plus utilisé pour les modules cryptographiques mais elle ne correspond pas directement à un profil de protection Critères Communs. Une comparaison précise entre ces deux standards est proposée par la société @sec 2. De part la notorité de la FIPS 140-2 il nous a semblé opportun de joindre cette comparaison à ce livrable (voir Annexe A). Ce livrable est organisé en deux parties principales. Dans la partie II une présentation rapide du profil de protection BSI-CC-PP-0045 est faite, en lien avec la modélisation formelle proposée. Nous montrons en particulier les exigences qui sont couvertes par la modélisation proposée et de quelle façon. La partie III décrit la structure du modèle ainsi que les machines B. Ces machines décrivent la démarche de modélisation proposée ainsi qu une instanciation issue d exemples publics de modules cryptographiques certifiés FIPS-2 3. 1. Secured Hardware Immune Versatile Architecture : http ://shiva.minalogic.net/ 2. http ://atsec.com/us/fips-140-2-resources.html 3. http://csrc.nist.gov/groups/stm/cmvp/documents/140-1/140val-all.htm 4
Deuxième partie PP Cryptographic Modules, Security Level Enhanced 1 Les objectifs de sécurité du PP-0045 Le profil de protection BSI-CC-PP-0045 est un profil EAL 4+ dédié aux crypto-modules. Il s intéresse en particulier à la robustesse des algorithmes cryptographiques, à la protection et au management des paramètres critiques de sécurité (CSP) et à la résistance aux attaques élevées. La liste des objectifs de sécurité est donnée page 19, 20 et 21 du standard. Le modèle développé a pour objectif la prise en compte des objectifs de sécurité liés à la protection et au management des CSP ainsi qu à la séparation des données. Ce modèle ne s intéresse ni à la cryptographie (certification faite à partir de catalogues bien établis d algorithmes et d implémentations) ni à la protection contre les attaques physiques (émanation). En effet la modélisation ne peut prendre en compte que des aspects fonctionnels et, comme nous le verrons, les exigences en lien avec la protection des données constituent une partie importante de ce profil. 2 Mécanismes de sécurité concernés par l étude Les propriétés de sécurité attendues sont la confidentialité et l intégrité des paramètres critiques de sécurité comme par exemples les mots de passe, les master keys ainsi que la séparation des données rouges/noires. Les données rouges correspondent aux données non encore chiffrées et demandent donc une haute protection en confidentialité et/ou intégrité. Les données noires correspondent aux données cryptographiquement protégées. Les objectifs de sécurité concernent la séparation des espaces pour ces deux types de données et le contrôle des échanges entre ces deux domaines (par chiffrement et déchiffrement). Les mécanismes de sécurité assurant ces propriétés sont les suivants : différents niveaux de contrôle d accès permettant de contrôler l accès aux données et l accès aux services en fonction du rôle de l utilisateur la notion de mode qui permet de décrire l état du module (opérationnel/en erreur...) et les opérations possibles en fonction de cet état. Un automate d état fini décrit précisément les transitions autorisées par le module (voir section 4). les notions d interfaces et de ports qui imposent une séparation logique ou physique des données et des services accessibles en fonction de l utilisateur et du mode de fonctionnement du module. Une cible de sécurité Crières Communs repose à la fois sur des exigences fonctionnelles de sécurité (SFR [cc006a]) et des exigences d assurance de sécurité (SAR [cc006b]). Nous détaillons ci-dessous les exigences prises en compte par notre modèle. 5
3 Exigences fonctionnelles de sécurité prises en compte Les SFRs concernées sont relatives aux classes FDP (user data protection class), FMT (security management class) et FPT (protection of the TSF 4 class). Elles reposent principalement sur plusieurs contrôles d accès permettant de définir quel rôle peut exécuter quelle opération sur quel objet en fonction du mode courant du module. Ces contrôles d accès sont les suivants : Key Man qui définit quels sont les sujets qui peuvent gérer les CSP, comme par exemple l importation de clés Mode Trans qui définit quels sujets peuvent modifier le mode courant de module (par exemple un sujet dont le rôle n est pas CryptoOfficer ne peut pas passer en mode Key/CSPEntry) Oper qui définit quelles opérations peuvent être exécutées sur quels objets et par quels rôles. Les composants d exigences fonctionnelles de sécurité couverts par le modèle portent sur la définition de ces contrôles d accès (composants FDP ACC et FDP ACF), sur le management des attributs de sécurité (FMT SMR et FMT MSA), sur les opérations possibles en fonction du mode courant du module (FPT FLS) et la maîtrise des émanations à travers les interfaces et ports disponibles (FPT EMSEC). Dans le PP-0045 les objets de sécurité portent leurs propres attributs de sécurité. En particulier ils possèdent des règles qui décrivent quels accès sont autorisés (lecture, écriture, exécution mais aussi génération, destruction et mise à zéro) et par quels services. Ces règles peuvent évoluer lors du management des objets de sécurité. Bien que le profil de protection PP-0045 ne présentent pas ces règles par des composants FMT ACC et FMT ACF, nous avons choisi de les modéliser comme un contrôle d accès, les cibles de sécurité que nous avons pu voir dans le cadre de la FIPS 140-2 présentant généralement ces règles comme tel. Dans la suite nous nommerons DataAC ce contrôle d accès. 4 Exigences d assurance de sécurité prises en compte Un module cryptographique repose sur un ensemble de mécanismes assurant la sécurité. Comme expliqué section 2, en plus de la cryptographie et des contrôles d accès, le fonctionnement du module doit inclure la spécification d un automate d état fini décrivant les différents états possibles du module. Cet automate doit préciser les transitions d un état à un autre, les événements provoquant ces transitions et les sorties qui en résultent. Cet automate est relié à la notion de mode du module, comme décrit dans le contrôle d accès Mode Trans (section 3). Dans le profil de protection BSI-CC-PP-0045 cet automate est imposé dans l exigence d assurance ADV ARC dédiée à la description de l architecture de sécurité (raffinement de l exigence ADV ARC et note d application 32) et doit être décrit de manière semi-formelle. Un autre mécanisme de sécurité imposé par le raffinement associé à ADV ARC est la séparation des données et services à l aide d interfaces physiques ou logiques. Ce raffinement impose aussi de garantir que les sorties sont désactivées durant les phases de génération ou importation des clés et les auto-tests. La notion d interface et de port est renforcée dans l exigence ADV FSP qui impose le typage des interfaces (data input, data output, control input, status output) et des restrictions sur les interfaces/ports accessibles en fonction du mode courant du module. 4. fonctions de sécurité de la cible 6
5 Correspondances Critères Communs et modélisation formelle Les Critères Communs imposent l établissement de correspondance entre les différentes exigences d assurance et les éléments de la cible de sécurité qui permettent d établir la cohérence et la complétude des modèles [cc006b]. Nous nous intéressons ici aux correspondances classiquement liées à la classe ADV ainsi qu aux vérifications qui peuvent être déduites du profil de protection BSI-CC-PP-0045. Bien que ce profil n impose pas de modélisation formelle des politiques de sécurité (exigence SPM de la classe ADV), nous avons introduit un tel modèle et nous nous sommes intéressés aux correspondances induites en accord avec le document Modélisation formelle des politiques de sécurité d une cible d évaluation émis par la DCSSI en mars 2008 5. La partie droite de la figure Fig. 1 rappelle les correspondances classiques à établir dans la classe ADV SPM. ADV FSP est l exigence dédiée à la spécification fonctionnelle. Elle décrit les fonctions de sécurité offertes par le produit. Il doit être montré que cette spécification est cohérente avec les exigences fonctionnelles de sécurité, dont la politique formelle ADV SPM. Comme expliqué dans [BBG10] cette correspondance s exprime généralement à l aide d une relation de raffinement. ADV TDS décrit un modèle du design de l implémentation. Une correspondance doit être établie entre ce niveau et les spécifications fonctionnelles (ADV FSP) et la prise en compte des SFRs par ce niveau doit aussi être assurée. Pour les niveaux élevés de certification, ces correspondances peuvent être établies formellement, comme ceci a par exemple été fait dans [CN08, NP09, Che09]. Figure 1 Correspondences in CC and in PP-0045 ADV ARC (Security Architecture Requirement) est une nouvelle famille qui a été introduite dans les CC v3.1. Cette exigence est dédiée aux propriétés attendues en terme d auto-protection et de non contournement de la cible. Elle décrit aussi les exigences en terme de séparation des données et des flux. Enfin elle décrit le processus d initialisation sécurisé à mettre en oeuvre : les propriétés adressées par cette classe ne sont pas des propriétés fonctionnelles. Leur vérification se fait donc de manière globale. En particulier l exigence ADV TDS, décrivant les sous-systèmes et modules, devra expliciter la prise en compte des exigences relatives à la maîtrise des flux et la séparation des données. 5. circulaire.legifrance.gouv.fr/pdf/2009/04/cir_2037.pdf 7
Le profil de protection PP-0045 impose des choix d implémentation, décrits sous la forme de notes ou de raffinements attachés aux SARs. C est par exemple le cas de l exigence ADV ARC qui introduit explicitement la notion d automates d états, qui doit être conforme à la SFR Mode Trans. De manière similaire, l exigence ADV FSP impose, à l aide d un raffinement et d une note d application, d expliciter les interfaces logiques ou ports physiques ainsi que leur type (voir section 4). Les correspondances propres au profil de protection PP-0045 sont explicitées dans la partie gauche de la figure 1. 8
Troisième partie Le modèle B 1 Structure du modèle Le modèle a été développé à l aide de la méthode B [Abr96] qui est bien adaptée pour ce type de modélisation et a déjà été utilisée dans des approches de certification Critères Communs. Son langage de modélisation basé sur une logique ensembliste et les substitutions généralisées (langage impératif) rend facile l écriture et la compréhension des modèles. De plus la méthode B offre une notion de raffinement qui peut être exploitée pour implémenter les exigences de traçabilité imposée par les Critères Communs (correspondances de la classe ADV) [DPT08, CN08, NP09]. Les modèles ont été développés à l aide de l atelierb version 4.0 6. Cet outil est gratuit. Le modèle est construit en trois niveaux. Le premier niveau (machine ComposedAC- Monitor) décrit les opérations possibles et leur condition d exécution en fonctions des objets, de leur classification et du rôle courant de l utilisateur. Comme nous le verrons ce niveau correspond à un modèle ADV SPM. Le second niveau (refinement ModeRef- Monitor) introduit la notion de mode courant en accord avec l exigence ADV ARC. Il implémente le contrôle d accès Mode Trans. Conformément à la figure 1 ce second niveau est implémenté comme un raffinement de la machine ComposedACMonitor. Le dernier niveau (refinement InterfMonitor) introduit la notion d interfaces, en accord avec l exigence ADV FSP. Les interfaces implémentent la maîtrise des flux en accord avec les droits et le mode courant du module. Ce niveau est donc implémenté comme un raffinement de ModeRefMonitor. Dans le projet RNTL POSÉ [MPJa10] nous avons proposé une méthode pour modéliser des contrôles d accès, en lien avec la formulation des exigences Critères Communs [DLMP08, Mou10]. Cette approche repose sur un modèle statique décrivant les objets concernés par le contrôle d accès et les règles associées et un modèle dynamique décrivant comment ces objets et règles évoluent. L approche proposée permet de lier ces deux modèles et de produire par tissage un moniteur gérant les appels autorisés. Le modèle statique peut être assimilé aux SFRs FDP ACC et FDP ACF. Le modèle dynamique décrit le management des attributs de sécurité et concerne principalement des exigences de la classe FMT. Le moniteur produit par tissage peut être vu comme une exigence d assurance ADV SPM, relative à la formalisation des politiques de sécurité. Comme nous le verrons, le fait que cette exigence soit décrite de manière formelle permet d assurer sa prise en compte dans le développement de la partie fonctionnelle du système de manière formelle, comme fait par exemple dans [CN08, NP09]. Ce modèle peut aussi être utilisé pour produire des tests fonctionnels de sécurité, comme ceci a été mis en oeuvre dans le projet POSÉ. Nous décrivons ci-après les trois niveaux de spécification. 2 Niveau 1 Ce niveau est décrit en 3 groupes de machines : la description des objets et services et des droits de ces services sur les objets (ObjectACrules), les rôles et le contrôle d accès qu ils induisent (OPER et KEY MAN) et la dernière machine décrit les autorisations 6. http ://www.clearsy.com/ 9
d exécution des services. 2.1 Données, services et accès 2.1.1 Machine DATAS La machine DATAS introduit les différents types d objet (CSP, type de clés, donnée rouge/noire...). SYSTEM DATAS SETS Data ABSTRACT CONSTANTS CSP, /* The set of critical security paramters */ UserData, None, K AES, /* The component key attached to the AES component */ Passwd, /* a password */ K DIEC PUB, /* The public key of the cryptomodule */ K APP AES /* A session key for AES encryption/decryption */ PROPERTIES CSP Data UserData Data None Data None CSP None UserData CSP UserData= Passwd CSP K DIEC PUB CSP K APP AES CSP K AES CSP 2.1.2 Machine SERVICES La machine SERVICES décrit les différentes opérations offertes par le module et les organise en classe de services (opérations de mise à jour des CSP, opérations sur le mode courant...). SYSTEM SERVICES SETS Service={Import, Export, LoadKey, GenerateKey, AESEncrypt, AESDecrypt, Authenticate, PerformSelfTest, ChangeMode, Null} ABSTRACT CONSTANTS Man Service, Crypto Service, Other Service PROPERTIES Man Service Service Crypto Service Service Other Service Service Man Service={Import, Export, LoadKey} Crypto Service={GenerateKey, AESEncrypt, AESDecrypt, Authenticate, PerformSelfTest} Other Service={Authenticate, PerformSelfTest} 10
2.1.3 Machine ObjectACrules La machine ObjectACrules définit les règles du contrôle d accès qui précisent comment les services peuvent accéder aux objets (contrôle d accès DataAC de la section 3). Les droits considérés ici sont la lecture, l écriture, l exécution, la mise à zéro, la destruction et la génération des clés. SYSTEM ObjectACrules SEES SERVICES, DATAS SETS Action={Re, Wr, Ex, Ze, De, Ge} ABSTRACT CONSTANTS DataAC PROPERTIES DataAC F (Service CSP Action) (Import, Passwd, Wr) DataAC (Export, K DIEC PUB, Re) DataAC (GenerateKey, K APP AES, Wr) DataAC (LoadKey, K AES, Wr) DataAC (AESEncrypt, K AES,Re) DataAC (AESEncrypt, K APP AES,Re) DataAC (AESDecrypt, K AES,Re) DataAC (AESDecrypt, K APP AES,Re) DataAC (Authenticate, Passwd, Ex) DataAC 2.2 Roles et accès Le profil de protection PP-0045 impose un certain nombre de rôles ainsi que des règles de séparation des rôles. Par exemple un utilisateur ne peut posséder à la fois le rôle CryptoOfficer et Users. Nous n avons pas modélisé ici la gestion des authentifications, des utilisateurs et de leurs attributs de sécurité (classe FIA) mais ceci ne poserait pas de problème. Voir par exemple [Had07, Mou10] pour une modélisation complète de contrôles d accès à la RBAC [SFK00]. 2.2.1 Machine ROLES SYSTEM ROLES SETS Role = {CryptoOfficer, AuthUser, UnAuthUser} 2.2.2 Machine RoleACrules La machine RoleACrules implémente les deux contrôles d accès KEY MAN et OPER (voir section 3). Nous les avons regroupé ici en une seule machine mais ceci ne poserait aucune difficulté de les séparer en deux. SYSTEM RoleACrules SEES ROLES, SERVICES ABSTRACT CONSTANTS 11
KEY MAN, OPER PROPERTIES KEY MAN F (Role Man Service) OPER F (Role (Crypto Service Other Service)) (CryptoOfficer, Import) KEY MAN (CryptoOfficer, Export) KEY MAN (CryptoOfficer, LoadKey) KEY MAN (AuthUser, LoadKey) OPER (CryptoOfficer, LoadKey) OPER (CryptoOfficer, AESEncrypt) OPER (AuthUser, AESEncrypt) OPER (CryptoOfficer, AESDecrypt) OPER (AuthUser, AESDecrypt) OPER (UnAuthUser, Authenticate) OPER (CryptoOfficer, Authenticate) OPER (AuthUser, Authenticate) OPER (CryptoOfficer,PerformSelfTest) OPER (AuthUser, ChangeMode) OPER (CryptoOfficer, ChangeMode) OPER 2.3 Modèle dynamique La machine ComposedACMonitor compose les contrôles d accès précédents. Ici nous avons deux niveaux de granularité différents : le contrôle de l exécution des services (OPER et KEY MAN) et le contrôle de l accès aux données par les services (DataAC). Pour obtenir un niveau de granularité permettant d observer à la fois l exécution des accès de base et ceux des services nous avons découpé l exécution des services en deux étapes, Start Service et End Service, qui décrivent respectivement l activation et la fin d un service. Les opérations basiques comme la lecture, l écriture ou l exécution soient, quant à elles, représentées de manière atomique. La variable command permet de mémoriser le service en cours d exécution. L invariant de cette machine stipule qu à tout moment les règles des contrôle d accès sur les services sont respectées. 2.3.1 Machine ComposedMonitor La machine ComposedMonitor décrit tous les comportements admis en terme de séquences d évenements Start Service et End Service, encadrant possiblement des accès de base aux objets de manière conforme au contrôle d accès DataAC (section 3). Il y a trois groupes de services : les opérations de base (read, write,...) dont la garde correspond aux droits d accès DataAC, les services correspondant au management des attributs de sécurité (Import) et dont la garde impose le contrôle d accès KEY MAN et enfin les autres services dont la garde dépend des droits définis par le contrôle d accès OPER. SYSTEM ComposedACMonitor SEES ROLES, RoleACrules, DATAS, SERVICES, ObjectACrules VARIABLES command, current role, cc INVARIANT command Service current role Role cc CSP 12
(command Null (current role, command) OPER KEY MAN) (command Man Service (current role, command) KEY MAN) (command Crypto Service (current role, command) OPER) INITIALISATION command := Null cc : CSP current role :=UnAuthUser EVENTS Read = ANY csp WHERE csp CSP (command, csp, Re) DataAC THEN cc :=csp ; Write=ANY csp WHERE csp CSP (command, csp, Re) DataAC THEN cc :=csp ; Execute =ANY csp WHERE csp CSP (command, csp, Re) DataAC THEN cc :=csp ; Start Import= SELECT command=null (current role, Import) KEY MAN THEN command := Import ; End Import = SELECT command = Import THEN command :=Null ; Start AESEncrypt= SELECT command=null (current role, AESEncrypt) OPER THEN command :=AE- SEncrypt ; End AESEncrypt = SELECT command =AESEncrypt THEN command :=Null ; Start Authenticate= SELECT command=null THEN command := Authenticate current role : Role ; End Authenticate = SELECT command = Authenticate THEN command :=Null ; Start ChangeMode= SELECT command=null (current role, ChangeMode) OPER THEN command := ChangeMode ; End ChangeMode = SELECT command = ChangeMode THEN command :=Null ; Start PerformSelfTest= SELECT command=null (current role, PerformSelfTest) OPER THEN command := PerformSelfTest ; End PerformSelfTest = SELECT command = PerformSelfTest THEN command :=Null La machine ComposedACMonitor produit 23 obligations de preuve qui sont toutes prouvées automatiquement. 3 Niveau 2 Le second niveau introduit la notion de mode (machines MODES et MODErules) et un modèle dynamique correspondant, pour le mode, à l exigence ADV ARC (services autorisés en fonction du mode courant). 13
3.1 Mode courant du module et contrôle d accès sur ChangeMode 3.1.1 Machine MODES La machine MODES décrit les différents modes du module. SYSTEM MODES SETS Mode={CryptoOfficerMode,KeyCSPEntryMode, UserMode, SelfTestMode, ErrorMode, StartMode} 3.1.2 Machine MODErules La machine MODErules décrit le contrôle d accès Mode Trans qui définit quel rôle peut modifier le mode courant et comment, conformément aux SFRs FDP ACC/Mode Trans et FDP ACC/Mode Trans et en suivant la démarche préconisée dans [MPJa10]. SYSTEM MODErules SEES ROLES, MODES, SERVICES ABSTRACT CONSTANTS MODE TRANS PROPERTIES MODE TRANS F (Role Service Mode) (CryptoOfficer, ChangeMode, CryptoOfficerMode) MODE TRANS (CryptoOfficer, ChangeMode, KeyCSPEntryMode) MODE TRANS (CryptoOfficer, ChangeMode, UserMode) MODE TRANS (CryptoOfficer, ChangeMode, SelfTestMode) MODE TRANS (AuthUser, ChangeMode, UserMode) MODE TRANS 3.2 Modèle dynamique Le modèle dynamique va à la fois décrire le moniteur associé au contrôle d accès Mode Trans pour le service ChangeMode et aussi garantir que la nouvelle spécification proposée est cohérente avec la machine ComposedACMonitor (preuve de raffinement). Dans notre démarche de modélisation ceci revient d une part à construire le moniteur associé à Mode Trans et d autre part à établir la prise en compte de l exigence ADV ARC par les spécifications fonctionnelles. 3.2.1 Machine ModeRefMonitor Le raffinement ModeRefMonitor introduit la nouvelle variable mode. Elle redéfinit les événements de la machine ComposedACMonitor. Si ces événements ne sont pas modifiés (i.e. n affectent pas la variable mode) alors il n est pas nécessaire de les répéter. C est le cas des événements End Ev par exemple. Les événements Start Ev ont maintenant une garde qui s exprime en fonction du mode courant du module et non plus du rôle. L invariant de liaison établit le lien entre le mode et le rôle. L événement Start ChangeMode est maintenant gardé par la condition (current role, ChangeMode, value) MODE TRANS. 14
Cette garde est bien un raffinement de celle de la machine ComposedACMonitor car nous avons la propriété de cohérence suivante : rr, mm. (rr, ChangeMode, mm) MODE TRANS (rr, ChangeMode) OPER) L invariant du raffinement ModeRefMonitor garantit d une part que les règles du contrôle d accès MODE TRANS sont bien respectées. D autre part il établit la relation de cohérence entre le mode et le rôle courants. REFINEMENT ModeRefMonitor REFINES ComposedACMonitor SEES ROLES, RoleACrules, DATAS, SERVICES, ObjectACrules, MODES, MODErules ABSTRACT VARIABLES command, current role, mode, cc INVARIANT mode Mode (mode=usermode current role {AuthUser, CryptoOfficer}) (mode=keycspentrymode current role=cryptoofficer) (mode= CryptoOfficerMode current role=cryptoofficer) (mode=selftestmode current role = CryptoOfficer) (command=changemode (current role, ChangeMode, mode) MODE TRANS) INITIALISATION current role := UnAuthUser mode := StartMode command :=Null cc : CSP EVENTS /* Read, Write, Execute operations are unchanged */ /* End postambles are unchanged */ Start Import = SELECT command=null mode=keycspentrymode THEN command :=Import ; Start AESEncrypt= SELECT command=null (mode=cryptoofficermode mode=usermode) THEN command :=AESEncrypt ; Start Authenticate = BEGIN SELECT command=null THEN command := Authenticate CHOICE current role := CryptoOfficer mode := CryptoOfficerMode OR current role :=AuthUser mode := UserMode OR current role :=UnAuthUser mode := StartMode ; Start ChangeMode= ANY value WHERE command=null value Mode (current role, ChangeMode, value) MODE TRANS THEN mode :=value command := ChangeMode ; Start PerformSelfTest= SELECT command=null mode=selftestmode THEN command := PerformSelfTest CHOICE mode :=ErrorMode OR skip Le raffinement ModeRefMonitor engendre 29 obligations de preuve dont 24 sont prouvées automatiquement. Les 5 obligations de preuve non déchargées automatiquement sont relatives à l événement Start ChangeMode et consistent à montrer la préservation de l invariant sur les modes par cet événement sous l hypothèse du mode courant et de la définition 15
de MODE TRANS. Ces obligations de preuve nécessitent d expanser la valeur de la relation MODE TRANS. 4 Niveau 3 A ce niveau de modélisation nous prenons en compte la notion d interface (qui abstrait les interfaces logiques et les ports physiques), comme décrit dans l exigence ADV FSP. Nous avons distingué ici trois classes d interfaces : KeyManInterf relative aux services et aux transports des données pour le management des clés CryptoInterf relative aux services et aux transports des données pour l utilisation des primitives de cryptographie (usage courant du module) OtherInterf relative aux opérations de gestion du module (self test...) Le module doit gérer l accessibilité des interfaces en fonction du mode courant : par exemple en mode SelfTest aucun service lié à la cryptographie ne doit être disponible. Nous avons donc modélisé les interfaces qui doivent être rendues non disponibles (variable Close) et décrit par invariant les exigences de sécurité (interfaces non accessibles en fonction du mode). 4.1 Modèle dynamique 4.1.1 Machine InterfMonitor Les gardes des événements Start Service sont maintenant exprimées en terme des interfaces accessibles. La preuve de raffinement sur les gardes garantit ainsi que les interfaces sont gérées de manière conforme au mode courant (un événement ne peut pas être activé dans d autres conditions que celles imposées par le contrôle d accès). REFINEMENT InterfMonitor REFINES ModeRefMonitor /* Type of interfaces is not taken into account here. It can be added as a refinement. */ SEES ROLES, RoleACrules, DATAS, SERVICES, ObjectACrules, MODES, MODErules SETS Interface ={i1, i2, i3, i4, i5, i6, i7, i8, i9} CONSTANTS KeyManInterf, CryptoInterf, OtherInterf PROPERTIES KeyManInterf Interface CryptoInterf Interface OtherInterf Interface KeyManInterf CryptoInterf= KeyManInterf OtherInterf= CryptoInterf OtherInterf= ABSTRACT VARIABLES command, current role, mode, cc, Close INVARIANT Close Interface (mode=startmode KeyManInterf Close) (mode=startmode CryptoInterf Close) (mode=selftestmode KeyManInterf Close) (mode=selftestmode CryptoInterf Close) (mode=errormode KeyManInterf Close) 16
(mode=errormode CryptoInterf Close) (mode=keycspentrymode CryptoInterf Close) (mode=usermode KeyManInterf Close) (mode=cryptoofficermode KeyManInterf Close) ASSERTIONS ( (KeyManInterf Close) mode=keycspentrymode) ( (CryptoInterf Close) (mode=cryptoofficermode mode=usermode)) INITIALISATION current role := UnAuthUser mode := StartMode command :=Null cc : CSP Close :=KeyManInterf CryptoInterf EVENTS Start Import = SELECT command=null (KeyManInterf Close) THEN command :=Import ; Start AESEncrypt= SELECT command=null (CryptoInterf Close) THEN command :=AESEncrypt ; Start Authenticate = BEGIN SELECT command=null THEN command := Authenticate CHOICE current role := CryptoOfficer mode := CryptoOfficerMode Close :=Close KeyManInterf -CryptoInterf OR current role :=AuthUser mode := UserMode Close :=Close KeyManInterf - CryptoInterf OR current role :=UnAuthUser mode :=StartMode Close :=KeyManInterf CryptoInterf ; Start ChangeMode= ANY value WHERE command=null value Mode (current role, ChangeMode, value) MODE TRANS THEN command := ChangeMode mode :=value IF value=selftestmode THEN Close := Close KeyManInterf CryptoInterf ELSIF value=keycspentrymode THEN Close :=Close - KeyManInterf CryptoInterf ELSE Close :=Close KeyManInterf - CryptoInterf ; Start PerformSelfTest= SELECT command=null mode=selftestmode THEN command := PerformSelfTest CHOICE BEGIN mode :=ErrorMode Close := Close KeyManInterf CryptoInterf OR skip Le raffinement InterfMonitor engendre 75 obligations de preuve dont 73 sont déchargées 17
automatiquement. Les deux obligations de preuve restantes sont relatives à l événement Start ChangeMode et reviennent à montrer qu il n est pas possible de respecter la relation MODE TRANS et d être dans un des modes Start Mode ou Error Mode (preuve du else). 18
Quatrième partie Conclusion 5 Conclusion Ce livrable présente donc une étude du profil de protection BSI-CC-PP-0045 en particulier en ce qui concerne les exigences vis-à-vis de la protection des données (contrôle d accès, séparation des données...). En accord avec la tâche 5.4 du projet SHIVA, nous avons étudié comment ces exigences pouvaient être modélisées. Ce profil de protection contient plusieurs exigences en terme de contrôle d accès, ce qui se modélise bien. De plus les indications précises de conception imposées par ce profil (mode, automate d état, notion d interface activée ou non) suivant des règles bien établies ont rendu possible cette formalisation. Au vu de la figure 1 nous rappelons la manière dont les exigences sont couvertes par notre modèle : composant B Machine ComposedACMonitor Refinement ModeRefMonitor Refinement InterfMonitor SFRs et SARS couvertes OPER, KEY MAN (établis par invariant) Mode Trans par invariant, ARC par specification FTP par invariant et FSP par specification Un profil de protection est fait pour être instancé dans un cible d évaluation, pour un produit donné. Le modèle que nous avons développé est donc fait pour être réutilisé et instancié en fonction de l application concernée. Néanmoins le PP-0045 contient déjà un certain nombre d instances et de contraintes, comme les rôles qui doivent être présents ainsi que des contraintes associées à ces rôles ou comme les différents mdes du module et les interfaces accessibles en fonction de l état courant. Le modèle qui a été développé contient donc d une part une approche validée qui peut être réutilisée pour modéliser une instanciation de ce profil mais aussi des parties de modèles qui peuvent être directement réutilisées, car correspondant à des contraintes génériques imposées par le profil de protection. Nous explicitons ci-après plus précisémment comment ce modèle peut être réutilisé : Niveau 1 : machine DATAS machine SERVICES Machine ObjectACrules Machine ROLES Machine RoleACrules Machine ComposedMonitor à instancier suivant l application classifier les objets en CSP, Key... à instancier suivant l application classifier les services suivant les rôles à instancier suivant l application à compléter suivant application à instancier suivant SERVICES et ROLES respecter le typage de KEY MAN et OPER en fonction de la classification des services peut être produite systématiquement en fonction des autres machines Niveau 2 : machine MODES machine MODErules refinement ModeRefMonitor à compléter si autres modes (ex BypassMode) à étendre si modes ou contraintes supplémentaires à instancier suivant l automate d états 19
Niveau 3 : refinement InterfMonitor à instancier suivant découpage des interfaces Certaines exigences n ont pas été modélisées mais auraient pu l être sans aucune difficulté, comme tout ce qui a trait à l authentification (classe FIA). En ce qui concerne les contraintes sur l implémentation et le design, l étude développée ici pourrait être étendue en particulier pour mieux expliciter et valider la maîtrise des flux et des accès par les interfaces et les ports, comme fait par exemple dans [HALM06]). Néanmoins cette étude nécessitait de disposer du design complet d une application, ce qui dépassait le cadre de cette étude. 20
Références [Abr96] J.R. Abrial. The B-Book. Cambridge University Press, 1996. [BBG10] Bernhard Beckert, Daniel Bruns, and Sarah Grebing. Mind the gap : Formal verification and the Common Criteria. In Markus Aderhold, Serge Autexier, and Heiko Mantel, editors, 6th International Verification Workshop, VERIFY- 2010, Edinburgh, United Kingdom, July 20 21 2010. [cc006a] Common Criteria for Information Technology Security Evaluation, Part 2 : Security functional components. Technical Report CCMB-2006-09-002, v3.1, sept 2006. [cc006b] Common Criteria for Information Technology Security Evaluation, Part 3 : Security assurance components. Technical Report CCMB-2006-09-003, v3.1, sept 2006. [cc006c] Common Criteria for Information Technology Security Evaluation, version 3.1. Technical Report CCMB-2006-09-001, sept 2006. [CC10] Pierre Capillon and Antoine Casanova. Combining security assurance and high performance in hostile environments. In NATO Research and Technology Organisation, editors, RTO-MP-IST-091, Information Assurance and Cyber Defense, 2010. [Che09] [CN08] Boutheina Chetali. Security testing and formal methods for high levels certification of smart cards. In TAP : Tests and Proofs, volume 5668 of Lecture Notes in Computer Science, pages 1 5, 2009. Boutheina Chetali and Quang Huy Nguyen. Industrial use of formal methods for a high-level security evaluation. In FM, volume 5014 of LNCS, pages 198 213. Springer, 2008. [DLMP08] F. Dadeau, J. Lamboley, T. Moutet, and M-L Potet. A verifiable conformance relationship between smart card applets and security models. In ABZ, volume 5115 of LNCS. Springer, 2008. [DPT08] F. Dadeau, M-L Potet, and R. Tissot. A B Formal Framework for Security Developments in the Domain of Smart Card Applications. In SEC 2008 : 23th International Information Security Conference, IFIP proceedings. Springer, 2008. [FIP01] FIPS 140-2 : Security requirements for cryptographic modules. Technical Report MD 20899-8900, National Institute of Standards and Technology, 25 May 2001. [Had07] A. Haddad. Meca : a Tool for Access Control Models. In J. Julliand and O. Kouchnarenko, editors, B 2007 : Formal Specification ans Development in B, volume 4355 of LNCS. Springer, 2007. [HALM06] Constance L. Heitmeyer, Myla Archer, Elizabeth I. Leonard, and John D. McLean. Formal specification and verification of data separation in a separation kernel for an embedded system. In ACM Conference on Computer and Communications Security, 2006. [KLR08] [Mou10] Wolfgang Killmann and Kerstin Lemke-Rust. Cryptographic Modules, Security Level Enhanced, V 1.1. Technical report, Bundesamt fur Sicherheit in der Informationstechnik, 25 July 2008. Thierry Moutet. Description de propriétés de sécurité pour un processus de validation/vérification. Technical report, Mémoire d ingénieur CNAM en Informatique, 2010. 21
[MPJa10] [NP09] [SFK00] P-A. Masson, M-L Potet, J. Julliand, and all. An Access Control Model Based Testing Approach for Smart Card Applications : Results of the POSÉ project. Journal of Information Assurance and Security, 5 :335 351, 2010. Iman Narasamdya and Michaël Périn. Certification of smart-card applications in common criteria. In FASE, volume 5503 of LNCS, pages 309 324. Springer, 2009. Ravi S. Sandhu, David F. Ferraiolo, and D. Richard Kuhn. The NIST model for role-based access control : towards a unified standard. In ACM Workshop on Role-Based Access Control, pages 47 63, 2000. 22
Cinquième partie Annexe A 23
Agenda A secure product from the CC perspectivep A secure product from the FIPS 140-2 perspective From FIPS 140-2 to CC Yi Mao PH.D. CISSP, PCI QSA atsec Information Security Cooperation www.atsec.com yi@atsec.com The common security checkpoints in CC and FIPS 140-2 Viewing FIPS 140-2 as a pseudo Protection Profile (PP) The benefits gained from a FIPS 140-2 certified Cryptographic Module (CM) Conclusion 12 th ICCC, 27-29 September 2011, Selangor, Malaysia atsec information security, 2011 atsec information security, 2011 2 About the Product AS Secure Product from the CC Perspective What is the TOE to be evaluated? E.g. atsec information security, 2011 3 atsec information security, 2011 4
About the Process Is the development process well controlled? About the Environment Where and how is the TOE to be used? Put any restrictions in the ECG. VS. VS. atsec information security, 2011 5 atsec information security, 2011 6 Inspecting the Product Details Is the design secure? Does the implementation reflect the design? A Secure Design Means... A well-defined external interface TSFI A high-degree of modularity TOE decomposed into components A component decomposed into modules Identifiable security components/modules/functions Separation of security enforcing/supporting functions from security noninterfering ones Protecting itself against interference, tampering and bypass TOE protection Protecting TSF data and user data from unauthorized disclosure and modification Vulnerability analysis atsec information security, 2011 7 atsec information security, 2011 8
Security Functional Requirements (from the CC V3.1 Part II) 1. FAU (Security Audit) 2. FCO (Communication) 3. FCS (Cryptographic Support) 4. FDP (User Data Protection) 5. FIA (Identification and Authentication) 6. FMT (Security Management) 7. FPR (Privacy) 8. FPT (Protection of the TSF) 9. FRU (Resource Utilisation) 10. FTA (TOE Access) 11. FTP (Trusted Path/Channels) Mapping to Basic Security Concepts (from the CBK for CISSP Certification) Confidentiality: FCS, FDP, FTP Integrity: FCS, FMT, FPT Availability: FRU Accountability: FAU, FIA Privacy: FPR Identification: FIA Authentication: FIA Authorization: FTA Auditing: FAU Nonrepudiation: FCS, FCO atsec information security, 2011 9 atsec information security, 2011 10 FIPS 140-2 and CMVP AS Secure Product From the FIPS 140-2 Perspective FIPS 140-2 is the current version of the NIST (National Institute of Standards and Technology) and CSEC (Communications Security Establishment Canada) mandatory standard that specifies the security requirements for Cryptographic Modules, and is applicable to all federal agencies in the US and the Government of Canada that use cryptographic-based security system. Cryptographic p Module Validation Program (CMVP) is a joint effort between NIST and CSEC that oversees the FIPS 140-2 conformance through a module validation process. atsec information security, 2011 11 atsec information security, 2011 12
A Birds-eye View of FIPS 140-2 FIPS 140-2 security requirements cover 11 areas. For each area, a CM receives a security level rating (1-4, from lowest to highest) depending on what requirements are met. An overall rating is issued for the CM that is the minimum of the independent ratings received in all areas. FIPS 140-2 annexes specify approved security functions, protection profiles, random number generators, and key establishment techniques. CM validation testing is performed using the Derived Test Requirement (DTR) for FIPS 140-2. The CM must implement at least one FIPS-Approved security function. The involved approved cryptographic algorithms are tested under Cryptographic Algorithm Validation Program (CAVP). Security Areas Covered in FIPS 140-2 1. Cryptographic p Module Specification 2. Cryptographic Module Ports and Interfaces 3. Roles, Services, and Authentication 4. Finite State Model 5. Physical Security 6. Operational Environment 7. Cryptographic Key Management 8. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) 9. Self Tests 10. Design Assurance 11. Mitigation of Other Attacks atsec information security, 2011 13 atsec information security, 2011 14 Mapping to Product/Process/Environment Module Specification, Port and Interface, Roles/Services and Authentication, FSM, Physical Security, EMI/EMC, Key Management, Self-Tests, Mitigation of Attacks Design Assurance Operational Environment A Secure Design Means... A well-defined external interface Port and Interface A high-degree of modularity Module Specification, FSM Identifiable security components/modules/functions Separation of cryptographic p functions from others Protecting itself against interference, tampering and bypass Physical Security, Self-Tests Protecting CSPs (Cryptographic Sensitive Parameters) from unauthorized disclosure and modification Roles, Services, and Authentication, Key Management Vulnerability analysis Mitigation of other attacks atsec information security, 2011 15 atsec information security, 2011 16
Requirements for Key Management (from the FIPS 140-2 DTR Chapter 7) General Key Protection Mechanism Random Number Generators Key Generation Key Establishment Key Entry and Output Key Storage Key Zeroization The common checkpoints in CC and FIPS 140-2 All of the requirements reflect the well-known CIA security concepts. atsec information security, 2011 17 atsec information security, 2011 18 Counterparts between CC and FIPS 140-2 A Common Tripod Strategy of Product-Process-Environment CC FIPS 140-2 Target of Evaluation (TOE) Implementation under Test (IUT) Cryptographic Module (CM) Security Target (ST) Security Policy (SP) Security Functions Cryptographic security functions Evaluate the design and implementation of a CM/TOE: what is it and how does it work? Check its development process: how is it made? TOE Security Function (TSF) data and user data Keys and Cryptographic Sensitive Parameters (CSPs) Inspect its operational environment: how is it to be used? atsec information security, 2011 19 atsec information security, 2011 20
Same Set of Questions Addressed Assuring the Data Protection What is the scope and boundary of CM or TOE? Does it have a well-defined external interface? Does it have a high-degree of modularity? Does it have identifiable security functions? (e.g. authentication, authorization, access control, data encryption) How does it protect t itself against interference, tampering and bypass? Does it meet the data (TOE assets vs. FIPS CSP) protection requirements? protection against unauthorized disclosure/modification/ unauthorized substitution of data Are there any vulnerabilities? What are the countermeasures? Vulnerability analysis in CC vs. Mitigation of other attacks in FIPS Requirements in FIPS 140-2 Roles, Services, and Authentication Key Storage Key Entry Key Exit Key Generation Key Establishment Cryptographic functions Key Zeroization SFRs in CC Access control policy and functions (FDP_ACC and FDP_ACF) Import from outside of the TOE (FDP_ITC) Export from the TOE (FDP_ETC) Inter-TSF user data confidentiality transfer protection (FDP_UCT) Inter-TSF user data integrity transfer protection (FDP_UIT) Residual information protection (FDP_RIP) atsec information security, 2011 21 atsec information security, 2011 22 Relating FIPS 140-2 to CC Viewing FIPS 140-2 as a Pseudo Protection Profile In reality: FIPS 140-2 is a standalone standard distinct to CC family standards. When the operational environment of a CM is modifiable, the operating system requirements of the CC are applicable at FIPS Security Levels 2 and above. The analysis shows: Although FIPS 140-2 is specialized to address the security requirements for the cryptographic modules, it has much in common with CC. Possible comparisons: FIPS 140-2 requirements could be interpreted as a prescribed protection profile (in essence, rather than in format) for cryptographic modules. The definition of a PP turns the CC evaluation of products from the same product category into a de-facto conformance testing and FIPS 140-2 by definition is just that -- a conformance test. atsec information security, 2011 23 atsec information security, 2011 24
BSI PPs for Cryptographic Modules BSI-CC-PP-0044 (dated on 28 th October 2008) Common Criteria Protection Profile Cryptographic p Modules, Security Level Low BSI-CC-PP-0042 (dated on 7 th March 2008) Common Criteria Protection Profile Cryptographic Modules, Security Level Moderate BSI-CC-PP-0045 (dated on 24 th July 2008) Common Criteria Protection Profile Cryptographic p Modules, Security Level Enhanced SFRs in BSI CM PPs SFRs in PP 0044 SL Low FCS_CKM FCS_COP FCS_RNG FIA_ATD FIA_UID FIA_UAU FDP_ACC FDP_ACF FDP_ITC FMT_SMF FMT_SMR FMT_MOF FPT_STM FPT_TDC FPT_FLS FTP_ITC FIA_USB FIA_AFL FDP_ETC FDP_UCT FDP_UIT FMT_MTD FMT_MSA FPT_EMSEC FPT_PHP FPT_RVM FDP_RIP FPT_SEP FPT_TST Additional SFRs FMT_MOF MOF for FAU_GEN in PP 0042 SL Moderate Adm FMT_MTD for Audit FAU_SAR FAU_STG Stronger SFRs in PP 0045 SL Enhanced FMT_MSA FAU_STG.4 atsec information security, 2011 25 atsec information security, 2011 26 Crypto Requirements in US NDPP (10 December 2010, Version 1.0) Gained Benefits of a FIPS 140-2 Certified CM Applied to a CC evaluation SFRs of FCS in NDPP Referenced Crypto standards FCS_CKMCKM FIPS 140-2 2(Security Requirements for CM) FCS_COP ANSI X9.80 (Prime Number Generation and Testing) FCS_ RBG_ EXT ANIS X9.31 Appendix 2.4 using AES FCS_COMM_PROT_EXT NIST SP 800-57 (Recommendation for Key Management) NIST SP 800-56A (Recommendation for RSA-based Key Establishment Schemes) NIST SP 800-56B (Recommendation for elliptic curve-based Key Establishment Schemes) FIPS PUB 186-3 (Digital Signature Standard) FIPS PUB 197 (Advanced Encryption Standard) NIST SP 800-38A/B/C/D/E NIST SP 800-90 (Deterministic Random Bit Generator) CAVP Validation System (AESVS, RSAVS, DSAVS, ECDSAVS, HMACVS, RNGVS, etc.) atsec information security, 2011 27 atsec information security, 2011 28
Crypto Requirements in US NDPP (Continued) A Working Example FMT_MTD, MTD TSF data including crypto information FMT_SMF, managing the TOE updates by verifying the digital signature of the updates FPT_ITT, using FCS-specified service to protect TSF data from disclosure and to detect modification of TSF data FPT_TUD_(EXT), TUD using FCS-specified digital signature or hash function to verify the TOE updates FTP_ITC, using FCS-specified service to provide a trusted communication channel between itself and authorized IT entities to protect from data disclosure and to detect data modification FTP_TRP, TRP using FCS-specified service to provide a trusted communication path between itself and remote administrators to protect from data disclosure and to detect data modification Suppose an OpenSSL-like Crypto library version a.b.c was: Implemented the following cryptographic algorithms and protocol Ti Triple-DES AES HMAC SHA RSA KeyGen, SignGen and SignVer DRBG DH key establishment protocol Certified under FIPS 140-2 for a software module at SL 1 Embedded in a type of network device products, say routers, to primarily provide IPSec functionality. atsec information security, 2011 29 atsec information security, 2011 30 A Working Example (Continued) Gained Benefits Suppose that kind of routers version x.y.z z was: to be US NDPP compliant to be certified under CC Question: How much can having a FIPS 140-2 certified crypto component contribute toward its containing TOE becoming CC-certified? Note: The working example has the CM as its core component of the TOE and their boundary could be more or less the same. The larger the crypto portion of the TOE the more benefit you will have from the FIPS certification of the CM. The flip side of this is also true. The following required crypto-related t SFRs in the US NDPP are satisfied: FCS_CKM CKM (Crypto Key Management including generation and zeroization) FCS_COP (Cryptographic Operation) FCS_RBG_EXT (Random Bit Generation) FCS_ COMM_ PROT_ EXT (Communications Protection) FMT_MTD (Management of TSF Data) FMT_SMF (Specification of Management Functions) FPT_ITT (Internal TSF Data Transfer Protection) FPT_TUD_(EXT) (Trusted Update) FTP_ITC (Inter-TSF Trusted Channel) FTP_TRP (Trusted Path) The required self test SFR in the US NDPP is also satisfied: FPT_TST.(EXT) (TSF Testing during initial start-up) atsec information security, 2011 31 atsec information security, 2011 32
Gained Benefits (Continued) The required SARs in the US NDPP are met by the crypto library component and hence, are partially satisfied: ADV_FSP.1 (Basic Functional Specification) The Security Policy of the CM can serve as the FSP during CC evaluation. AGD_OPE.1 and AGD_PRE.1 (Operational and Preparative user guidance) Crypto officer and user guidance documentation for the Operational Environment requirements in FIPS 140-2 can be re-used for the AGD class during CC evaluation. ATE_IND.1 (Independent testing - conformance) Covered by the functional test done for the FIPS 140-2 conformance test. AVA_VAN.1 VAN (Vulnerability analysis) The thorough review on design documentation and source code, the functional and penetration test conducted contributes to the vulnerability analysis. ALC_CMC.1CMC.1 and ALC_CMS.1 CMS.1 (Labeling of the TOE and its CM coverage) The section of Design Assurance in FIPS 140-2 checks the healthy of the develop process including unique labeling of the component and the usage of configuration management system. Conclusion A FIPS 140-2 conformance test and a CC evaluation can go hand in hand. While achieving FIPS 140-2 certification has its own merits, in the meantime, it can also serve as a stepping stone to reach a CC certification, especially for organizations new to compliance with security standards. Those who desire to archive CC certification for products containing a crypto module should consider to get the CM FIPS 140-2 validated. Those who have got a FIPS 140-2 certificate for their crypto module could consider to advance to CC certification for products containing the certified CM. atsec information security, 2011 33 atsec information security, 2011 34 References Acknowledgements 1. Erin Connor, FIPS 140 & CC How do they get along, the 11 th ICCC 2. Eugene Polulyakh, FIPS and the Common Criteria finding the least common denominator, the 11th ICCC 3. Security Requirements for Network Devices (pp_nd_v1.0.pdf), pdf) 10 December 2010, Version 1.0, IAD 4. Common Criteria Protection Profile Cryptographic Modules, Security Level Low, BSI- CC-PP-0044, V1.0, 28 October 2008 5. Common Criteria Protection Profile Cryptographic Modules, Security Level Moderate, BSI-CC-PP-0042, V1.01, 7 March 2008 6. Common Criteria Protection Profile Cryptographic Modules, Security Level Enhanced, BSI-CC-PP-0045, V1.01, 24 July 2008 7. FIPS PUB 140-2 Security Requirements for Cryptographic Modules, Issued May 25, 2001 8. Derived Test Requirements for FIPS PUB 140-2, 4 January 2011, Draft A special thanks goes to: Ingo Hahlen for pointing me to the set of BSI cryptographic Module protection ti profiles Apostol Vassilev for reviewing the slides and for helpful comments Courtney Cavness for the language editing atsec information security, 2011 35 atsec information security, 2011 36
Thank you for your attention! atsec information security, 2011 37