Sous-projet 5 - Modélisation et preuves de sécurité. Fourniture 5.4. Modèles, analyse et exigences Critères Communs

Transcription

1 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

2 Table des matières I Introduction 4 II PP Cryptographic Modules, Security Level Enhanced 5 1 Les objectifs de sécurité du PP 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 Données, services et accès Machine DATAS Machine SERVICES Machine ObjectACrules Roles et accès Machine ROLES Machine RoleACrules Modèle dynamique Machine ComposedMonitor Niveau Mode courant du module et contrôle d accès sur ChangeMode Machine MODES Machine MODErules Modèle dynamique

3 3.2.1 Machine ModeRefMonitor Niveau Modèle dynamique Machine InterfMonitor IV Conclusion 19 5 Conclusion 19 V Annexe A 23 3

4 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 [FIP01] qui définit les exigences de sécurité que doivent satisfaire des modules cryptographiques non classifiés. La FIPS 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 2. De part la notorité de la FIPS 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 Secured Hardware Immune Versatile Architecture : http ://shiva.minalogic.net/ 2. http ://atsec.com/us/fips resources.html

5 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

6 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 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

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

8 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

9 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 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 :// 9

10 d exécution des services. 2.1 Données, services et accès 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 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

11 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] Machine ROLES SYSTEM ROLES SETS Role = {CryptoOfficer, AuthUser, UnAuthUser} 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

12 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 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

13 (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

14 3.1 Mode courant du module et contrôle d accès sur ChangeMode Machine MODES La machine MODES décrit les différents modes du module. SYSTEM MODES SETS Mode={CryptoOfficerMode,KeyCSPEntryMode, UserMode, SelfTestMode, ErrorMode, StartMode} 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 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

15 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

16 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 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

17 (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

18 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

19 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

20 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

21 Références [Abr96] J.R. Abrial. The B-Book. Cambridge University Press, [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 [cc006a] Common Criteria for Information Technology Security Evaluation, Part 2 : Security functional components. Technical Report CCMB , v3.1, sept [cc006b] Common Criteria for Information Technology Security Evaluation, Part 3 : Security assurance components. Technical Report CCMB , v3.1, sept [cc006c] Common Criteria for Information Technology Security Evaluation, version 3.1. Technical Report CCMB , sept [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, [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, Boutheina Chetali and Quang Huy Nguyen. Industrial use of formal methods for a high-level security evaluation. In FM, volume 5014 of LNCS, pages Springer, [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, [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, [FIP01] FIPS : Security requirements for cryptographic modules. Technical Report MD , National Institute of Standards and Technology, 25 May [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, [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, [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 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,

22 [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 : , Iman Narasamdya and Michaël Périn. Certification of smart-card applications in common criteria. In FASE, volume 5503 of LNCS, pages Springer, 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,

23 Cinquième partie Annexe A 23

24 Agenda A secure product from the CC perspectivep A secure product from the FIPS perspective From FIPS to CC Yi Mao PH.D. CISSP, PCI QSA atsec Information Security Cooperation yi@atsec.com The common security checkpoints in CC and FIPS Viewing FIPS as a pseudo Protection Profile (PP) The benefits gained from a FIPS certified Cryptographic Module (CM) Conclusion 12 th ICCC, September 2011, Selangor, Malaysia atsec information security, 2011 atsec information security, About the Product AS Secure Product from the CC Perspective What is the TOE to be evaluated? E.g. atsec information security, atsec information security,