Hodnocení a certifikace kryptografických zařízení Vítězslav Šidlo vitezslav.sidlo@i.cz 2.11.2004 Motivace Zákazník / uživatel jak je to bezpečné? (co to znamená?) jak to vím? (kdo říká, že to je bezpečné?) kdy je to bezpečné? Dodavatel / vývojář co zákazník chce? (jak mám zákazníkovi říct, co dostal?) Hodnotitel co mám hodnotit? jak mám hodnotit? 2 1
Potřebují se domluvit chci TOHLE Dodavatel vyrobil jsem TOHLE Zákazník ano, vyrobené je TOHLE Hodnotitel 3 Hodnocení posouzení vlastností (odběratelem) / nezávislé (odborný) názor / proti etalonu, předpisu Certifikace certifikační schéma Norma = standard 4 2
Normy pro bezpečnost IT BS 7799-2 Information security management systems ISO 17799 Information security management; ISO TR 13335 Guidelines for the management of IT Security ISO 15408 - Evaluation criteria for IT security (Common Criteria) FIPS 140-2 Security requirements for cryptographic modules ISO 9797, FIPS 197 (AES) 5 FIPS PUB 140-2 Security requirements for cryptographic modules Národní norma USA Bezpečnostní požadavky na kryptografické moduly (sw, hw) Hodnocení v nezávislých laboratořích Čtyři úrovně (Level 1 Level 4) a 11 oblastí požadavků 6 3
Security Requirements Cryptographic Module Specification Cryptographic Module Ports and Interfaces Roles, Services, and Authentication Finite State Model Physical Security 7 Security Requirements 2. Operational Environment Cryptographic Key Management EMI/EMC Self-Tests tests Design Assurance Mitigation of Other Attacks p.20 8 4
Cryptographic Key Management Random Number Generators (RNGs) Key Generation Key Establishment Key Entry and Output Key Storage Key Zeroization 9 Key Establishment Key establishment may be performed by automated methods (e.g., use of a public key algorithm), manual methods (use of a manually-transported key loading device), or a combination of automated and manual methods. If key establishment methods are employed by a cryptographic module, only Approved key establishment methods shall be used. Approved key establishment methods are listed in Annex D to this standard. 10 5
Approved schválené metody (funkce) pro kryptografické operace, management klíčů, autentizační mechanismy uvedené v samostatně vydávaných přílohách odkazy na další dokumenty (FIPS 197 AES, PKCS#1 RSA, ANSI X9.17 ) Approved mode of operation pouze schválené metody 11 Záruka Zkoumáme funkčnost s jistotou můžeme prokázat, že nějaké tvrzení o vlastnostech produktu neplatí úplnou jistotu, že nějaké tvrzení (o produktu) platí, ale získáváme obtížně získáváme jen různou míru jistoty přesvědčení nebo důvěry (assurance) => záruka 12 6
Záruka podle FIPS 140-2 Požadavky na záruku (Design Assurance, Cryptografic Module Specification) stanoveny pro každou ze čtyř úrovní 13 Kritéria pro hodnocení bezpečnosti IT (Common Criteria) 14 7
ČSN ISO/IEC 15408 Informační technologie Bezpečnostní techniky Kritéria pro hodnocení bezpečnosti IT (Information technology Security techniques Evaluation criteria for IT security) Common Criteria for Information Security Evaluation (version 2.2.) 15 Historie Kanadská kritéria ->1993 TCSEC 1985 Federální kritéria 1992 CC 1993-> CC verze 2.1 Národní kritéria (G, Fr, UK,..) ITSEC 1991 ISO 1992-> ISO/IEC 15408 1999 16 8
Obsah normy Společný jazyk Katalog požadavků (včetně požadavků na hodnocení) Metodika hodnocení (jen CC) Certifikační schéma (jen CC) 17 Členění normy Část 1 Úvod a všeobecný popis Část 2 Bezpečnostní funkční požadavky (SFR) Část 3 Bezpečnostní požadavky na záruku (SAR) (celkem cca 630/450 stran) příklady 18 9
Navazující texty Common evaluation methodology (jen CC) Interpretations (jen CC) ISO/IEC TR 15446 - Guide for the production of protection profiles and security targets 19 Základní principy Nezávislé hodnocení Oddělení funkčnosti a záruky (Uznávání certifikátů jen CC) 20 10
Předmět hodnocení (TOE - Target of Evaluation) produkt nebo systém IT, který je předmětem hodnocení bezpečnostní funkce TOE (TSF - TOE security function) bezpečnostní politika TOE (TSP TOE security policy) 21 Security Target & Protection Profile bezpečnostní cíl (ST Security Target) = sada bezpečnostních požadavků a specifikací, která bude použita jako základ pro hodnocení identifikovaného TOE profil ochrany (PP Protection Profile) = na implementaci nezávislá sada bezpečnostních požadavků pro kategorii TOE, splňující specifické potřeby spotřebitelů 22 11
chci TOHLE = Protection Profile Popis bezpečnosti dokumenty Dodavatel vyrobil jsem TOHLE = Security Target Zákazník Hodnotitel ano, vyrobené TOE je TOHLE = certifikát 23 Dokumenty PP a ST Profil ochrany (PP Protection Profile) sada bezp. požadavků pro třídu produktů a nasazení vytváří zákazník, sdružení, stát např. firewally pro použití ve státní správě USA Bezpečnostní cíl (ST Security Target) sada bezp. požadavků a specifikací pro konkrétní produkt (TOE) vytváří výrobce např. CheckPoint FW-1 24 12
Struktura PP a ST Protection Profile Úvod PP Popis TOE Bezpečnostní prostředí Předpoklady Hrozby Organizační bezpečnostní politiky Bezpečnostní cíle Bezpečnostní požadavky funkční na záruku TOE XXXXXXXXX XXXXXXXXX Zdůvodnění Security Target Úvod ST Popis TOE Bezpečnostní prostředí Předpoklady Hrozby Organizační bezpečnostní politiky Bezpečnostní cíle Bezpečnostní požadavky funkční na záruku TOE Celková specifikace TOE Shoda s PP Zdůvodnění 25 Jak se tvoří PP/ST? Na počátku jsou schopnosti a vlastnosti, které od IT produktu vyžadujeme. Bezpečnostní prostředí Bezpečnostní cíle Bezpečnostní požadavky Jednotlivá zdůvodnění patří do dokumentu také. Specifikace TOE (jen ST) 26 13
Bezpečnostní prostředí Hrozby T.UNAUTH_ACCESS An unauthorized user may gain access to system data due to failure of the system to restrict access. Předpoklady A.LOCATE The processing resources of the TOE will be located within controlled access facilities that will prevent unauthorized physical access. Organizační bezpečnostní politiky P.ACCOUNTABILITY The users of the system shall be held accountable for their actions within the system. 27 Bezpečnostní cíle (security objectives) O.AUDITING The TSF must record the security relevant actions of users of the TOE. The TSF must present this information to authorized administrators. O.AUDIT_PROTECTION The TSF must provide the capability to protect audit information associated with individual users. 28 14
Bezpečnostní požadavky prozatím vynecháme 29 Specifikace TOE 6.1.1.1 Audit Collection The Event logger service creates the security event log, which contains the security relevant audit records collected on a system. There is one security log (audit log) per machine. The Local Security Authority (LSA) server collects audit events from all other parts of the TSF and For each audit event, the Event Logger stores the following data in each audit record: 30 15
Zdůvodnění (Rationale) Každý bod (cíl, požadavek, mechanismus ) vychází z předchozí kapitoly. Všechny body předchozí kapitoly jsou pokryty. Jsou splněny vzájemné závislosti (především u požadavků-requirements). 31 Zdůvodnění (Rationale) 2. IT Security Objectives O.AUTHORIZATION Threats and Organizational Policies T.UNAUTH_ACCESS T.SYSACC P.AUTHORIZED_USERS The following objectives are sufficient to address all of the threats and organizational policies in the ST: O.AUTHORIZATION Ensuring that the TOE and its resources are protected from unauthorized access counters the threats T.UNAUTH_ACCESS and T.SYSACC since the execution of these threats relies upon unauthorized access to the TOE. Additionally, this objective implements the policy P.AUTHORIZED_USER by ensuring that only authorized users gain access to the TOE and its resources. 32 16
Bezpečnostní požadavky na TOE Funkční bezpečnostní požadavky (SFR) + @ Bezpečnostní požadavky na záruku (SAR) na prostředí IT + @ non-it @ = výběr z katalogu, @ = vlastní formulace 33 Struktura požadavků Třída FIA Identifikace a autentizace Rodina FIA_UAU Autentizace uživatele Komponenta FIA_UAU.4 Autentizační mechanismy na jedno použití Element FIA_UAU.4.1 TSF musí zabránit opakovanému použití autentizačních dat souvisících s [přiřazení: identifikované autentizační mechanismy]. 34 17
Hierarchie komponent FDP_STI Integrita uložených dat 1 2 FDP_ETC Export mimo oblast řízení TSF 1 2 FDP_ITT Přenos uvnitř TOE 1 2 3 4 35 Bezpečnostní funkční požadavky (SFR) FAU: Bezpečnostní audit FCO: Komunikace FCS: Kryptografická podpora FDP: Ochrana uživatelských dat FIA: Identifikace a autentizace FMT: Správa bezpečnosti FPR: Soukromí FPT: Ochrana TSF FRU: Využití zdrojů FTA: Přístup k TOE FTP: Důvěryhodná cesta/kanály 36 18
Příklad SFR FCS_CKM.2 Distribuce kryptografických klíčů. Hierarchie: vůči žádným jiným komponentám. FCS_CKM.2.1 TSF musí distribuovat kryptografické klíče tak, aby byly v souladu se specifikovanou metodou pro distribuci kryptografických klíčů [přiřazení: metoda pro distribuci kryptografických klíčů], která splňuje následující: [přiřazení: seznam norem]. Závislosti: [FDP_ITC.1 Import uživatelských dat bez bezpečnostních atributů nebo FCS_CKM.1 Generování kryptografických klíčů], FCS_CKM.4 Zničení kryptografických klíčů, FCS_MSA.2 Bezpečné bezpečnostní atributy. 37 Příklad SFR FIA_AFL.1 Postup v případě selhání autentizace. Hierarchie: vůči žádným jiným komponentám. FIA_AFL.1.1 TSF musí detekovat, když se vyskytne [přiřazení: počet] neúspěšných pokusů o autentizaci vztahujících se k [přiřazení: seznam autentizačních událostí]. FIA_AFL.1.2 Když byl dosažen vymezený počet neúspěšných pokusů o autentizaci nebo byl překročen, musí TSF [přiřazení: seznam akcí]. Závislosti: FIA_UAU.1 Načasování autentizace. 38 19
Příklad SFR (en) FCS_CKM.2 Cryptographic key distribution Hierarchical to: No other components. FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method [assignment: cryptographic key distribution method] that meets the following: [assignment: list of standards]. Dependencies: [FDP_ITC.1 Import of user data without security attributes or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FMT_MSA.2 Secure security attributes 39 Příklad SFR (en) FIA_AFL.1 Authentication failure handling Hierarchical to: No other components. FIA_AFL.1.1 The TSF shall detect when [assignment: number] unsuccessful authentication attempts occur related to [assignment: list of authentication events]. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met or surpassed, the TSF shall [assignment: list of actions]. Dependencies: FIA_UAU.1 Timing of authentication 40 20
Úpravy SFR přiřazení (assigment) výběr (selection) rozšíření (extensions) zjemnění (refinement) iterace (iteration) 41 Úpravy SFR ISO 15408 část 2 FMT_SMR.2 Omezení bezpečnostních rolí. FMT_SMR.2.1 TSF musí udržovat role [přiřazení: autorizované identifikované role]. FMT_SMR.2.2 TSF musí být schopna přidružit uživatele k rolím. FMT_SMR.2.3 TSF musí být schopna zajistit, aby byly splněny podmínky [přiřazení: podmínky pro různé role]. Bezpečnostní cíl (ST) FMT_SMR.2 Omezení bezpečnostních rolí. FMT_SMR.2.1 TSF musí udržovat role administrátor, operátor KM, operátor OM. FMT_SMR.2.2 TSF musí být schopna přidružit uživatele k rolím. FMT_SMR.2.3 TSF musí být schopna zajistit, aby byla splněna podmínka: uživatel s rolí administrátor nesmí mít současně přiřazenu žádnou z rolí operátor KM, operátor OM. 42 21
Úpravy SFR (en) ISO 15408 část 2 FMT_SMR.2 Restrictions on security roles FMT_SMR.2.1 The TSF shall maintain the roles: [assignment: the authorised identified roles]. FMT_SMR.2.2 The TSF shall be able to associate users with roles. FMT_SMR.2.3 The TSF shall ensure that the conditions [assignment: conditions for the different roles] are satisfied. Bezpečnostní cíl (ST) FMT_SMR.2 Restrictions on security roles FMT_SMR.2.1 TSF shall maintain the roles: Administrator, KM Operator, OM Operator. FMT_SMR.2.2 The TSF shall be able to associate users with roles. FMT_SMR.2.3 TSF shall ensure that the following condition is satisfied: A user with the role of Administrator must not be assigned any of the following roles: KM 43 Operator, OM Operator. Požadavky na záruku (SAR) Zkoumáme, jestli (a chceme ujištěnízáruku, že): 1. vývojový proces je náležitě organizován, 2. ST je úplně a korektně implementován, 3. TOE dělá to, co se od něho očekává a nic jiného, 4. zákazník TOE správně použije. 44 22
Požadavky na záruku (SAR) 2. 1. ALC Life cycle support, ACM Configuration management 2. ADV - Development 3. AGD Guidance documents, ATE Tests, AVA Vulnerability assessment 4. ADO Delivery and operation, (ALC_FLR Flaw remedation) APE Protection Profile evaluation, ASE Security Targer evaluation AMA Maintenance of assurance 45 Příklad SAR ADO_IGS.1 Postupy pro instalaci, generování a spuštění Závislosti: AGD_ADM.1 Příručka správce Prvky činnosti vývojáře: ADO_IGS.1.1D Vývojář musí zdokumentovat postupy nezbytné pro bezpečnou instalaci, generování a spuštění TOE. Obsah a prezentace prvků důkazu: ADO_IGS.1.1C Dokumentace musí popisovat kroky nezbytné pro bezpečnou instalaci, generování a spuštění TOE. Prvky činnosti hodnotitele: ADO_IGS.1.1E Hodnotitel musí potvrdit, že poskytnuté informace vyhovují všem požadavkům na obsah a prezentaci důkazu. ADO_IGS.1.2E Hodnotitel musí stanovit, zda je výsledkem postupu pro instalaci, generování a spuštění bezpečná konfigurace. 46 23
Příklad SAR (en) ADO_IGS.1 Installation, generation, and start-up procedures Dependencies: AGD_ADM.1 Administrator guidance Developer action elements: ADO_IGS.1.1D The developer shall document procedures necessary for the secure installation, generation, and start-up of the TOE. Content and presentation of evidence elements: ADO_IGS.1.1C The documentation shall describe the steps necessary for secure installation, generation, and start-up of the TOE. Evaluator action elements: ADO_IGS.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADO_IGS.1.2E The evaluator shall determine that the installation, generation, and start-up procedures result in a secure configuration. 47 Míry záruky hodnocení (EAL Evaluation Assurance Levels) Předdefinované smysluplné balíčky komponent záruky (požadavků na záruku) Hierarchicky uspořádané EAL1 až EAL7 Lze libovolně doplnit o další komponenty (označení +, např. EAL3+) Nejvyšší dosažitelná v běžném komerčním prostředí je EAL 4 48 24
ACM ADO ADV AGD ALC ATE AVA EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7 ACM_AUT 1 1 2 2 ACM_CAP 1 2 3 4 4 5 5 ACM_SCP 1 2 3 3 3 ADO_DEL 1 1 2 2 2 3 ADO_IGS 1 1 1 1 1 1 1 ADV_FSP 1 1 1 2 3 3 4 ADV_HLD 1 2 2 3 4 5 ADV_IMP 1 2 3 3 ADV_INT 1 2 3 ADV_LLD 1 1 2 2 ADV_RCR 1 1 1 1 2 2 3 ADV_SPM 1 3 3 3 AGD_ADM 1 1 1 1 1 1 1 AGD_USR 1 1 1 1 1 1 1 ALC_DVS 1 1 1 2 2 ALC_FLR ALC_LCD 1 2 2 3 ALC_TAT 1 2 3 3 ATE_COV 1 2 2 2 3 3 ATE_DPT 1 1 2 2 3 ATE_FUN 1 1 1 1 2 2 ATE_IND 1 2 2 2 2 2 3 AVA_CCA 1 2 2 AVA_MSU 1 2 2 3 3 AVA_SOF 1 1 1 1 1 1 AVA_VLA 1 1 2 3 4 4 49 Takže EAL nemají nic společného s bezpečnostními vlastnostmi produktu Vyšší EAL pouze znamená vyšší jistotu, že ST = vyvinuto = používáno 50 25
Hodnocení PP ST TOE 51 Problematické oblasti CC Systémy složené ze subsystémů Požadavky na prostředí Interpretace některých SFR 52 26
Shrnutí FIPS 140-2 1. hodnocení bezpečnosti kryptografických modulů 2. pro každou úroveň spojuje požadavky na bezpečnost (vlastnosti) s požadavky na záruku ( vývoj ) 3. odkazuje na jiné dokumenty pro specifikace algoritmů aj. 53 Shrnutí CC 1. pro hodnocení bezpečnosti systémů IT 2. norma nepředepisuje bezpečnostní mechanismy ani jejich úroveň (splněné požadavky ani nemusí být vybírány z normy) 3. úroveň záruky (EAL) nemá přímý vztah k bezpečnosti 4. důležité jsou dokumenty Security target a Protection profile 5. je to složité 54 27
Zdroje FIPS 140 2: Cryptographic Module Validation Program: http://www.nist.gov/cmvp Common Criteria: Úvod L. Novák: Společná kritéria, DSM 2-4/2001 Norma (CC), profily ochrany, certifikované produkty - http://www.commoncriteriaportal.org ČSN ISO/IEC 15408 - velmi problematický překlad Informace od úvodů po detaily ICCC 2002 http://www.cse.dnd.ca/en/iccc/iccc.html CC na NIST http://www.niap.nist.gov/cc-scheme/ 55 Otázky? 56 28