Hodnocení a certifikace kryptografických zařízení Vítězslav Šidlo
[email protected]
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
Hodnotitel ano, vyrobené je TOHLE
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
Popis bezpečnosti dokumenty chci TOHLE =
Protection Profile
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
Security Target
• Ú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í
• Ú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
Jednotlivá
zdůvodnění Bezpečnostní požadavky
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
Threats and Organizational Policies
O.AUTHORIZATION
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
Element
…
…
FIA_UAU.4 Autentizační mechanismy na jedno použití
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 1
FDP_ETC Export mimo oblast řízení TSF 2 1
2
3
4
FDP_ITT Přenos uvnitř TOE 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
Bezpečnostní cíl (ST)
FMT_SMR.2 Omezení bezpečnostních rolí.
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].
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, 42 operátor OM.
21
Úpravy SFR (en) ISO 15408 část 2
Bezpečnostní cíl (ST)
FMT_SMR.2 Restrictions on security roles
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.
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 46 instalaci, generování a spuštění bezpečná konfigurace.
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
EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7
ACM ADO
ADV
AGD ALC ATE AVA
ACM_AUT ACM_CAP ACM_SCP ADO_DEL ADO_IGS ADV_FSP ADV_HLD ADV_IMP ADV_INT ADV_LLD ADV_RCR ADV_SPM AGD_ADM AGD_USR ALC_DVS ALC_FLR ALC_LCD ALC_TAT ATE_COV ATE_DPT ATE_FUN ATE_IND AVA_CCA AVA_MSU AVA_SOF AVA_VLA
1 4 2 2 1 2 2 1
1
2
1 1
1 1 1 1
3 1 1 1 1 2
1
1
1
1 1
1 1
1 1 1
1 1 1 1 1 1
1 2
2 1 1 2
1 1 2 1 1 2
1 1
1 1 1
2 1 2
1
1
1 4 3 2 1 3 3 2 1 1 2 3 1 1 1
2 5 3 2 1 3 4 3 2 2 2 3 1 1 2
2 5 3 3 1 4 5 3 3 2 3 3 1 1 2
2 2 2 2 1 2 1 2 1 3
2 3 3 2 2 2 2 3 1 4
3 3 3 3 2 3 2 3 1 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
