Modifying an Exis.ng Commercial Product for Cryptographic Module Evalua.on

Transcription

1 Modifying an Exis.ng Commercial Product for Cryptographic Module Evalua.on ICMC16 O?awa, Canada May 2016 Presented by Alan Gornall

2 Introduc.on I provide cer.fica.on support to my clients: compliance audit, design, implementa.on, tes.ng, documenta.on, project management I have over 25 years of cer.fica.on experience and have completed over 50 cer.fica.ons Issue addressed by this presenta.on: How to modify an exis.ng commercial product to achieve FIPS cer.fica.on. ISO 19790/FIPS is also discussed.

3 What is a Module? Contains at least one approved func.on Meets the requirements of FIPS standard at chosen level

4 11 Sec.ons There are 11 sec.ons of the FIPS requirements, each one rela.ng to a different aspect of a cryptographic module: 1. Cryptographic Module Specifica.on 2. Cryptographic Module Ports and Interfaces 3. Roles, Services, and Authen.ca.on 4. Finite State Model 5. Physical Security 6. Opera.onal Environment 7. Cryptographic Key Management 8. EMI/EMC 9. Self-Tests 10. Design Assurance 11. Mi.ga.on of Other A?acks

5 Level 1 Level 2 Level 3 Level 4 Cryptographic Module Specifica:on Cryptographic Module Ports and Interfaces Roles, Services, and Authen:ca:on Finite State Model Specifica.on of cryptographic module, cryptographic boundary, Approved algorithms, and Approved modes of opera.on. Descrip.on of cryptographic module, including all hardware, so_ware, and firmware components. Statement of module security policy. Required and op.onal interfaces. Specifica.on of all interfaces and of all input and output data paths. Logical separa.on of required and op.onal roles and services. Role-based or iden.ty-based operator authen.ca.on. Data ports for unprotected cri.cal security parameters logically or physically separated from other data ports. Iden.ty-based operator authen.ca.on. Specifica.on of finite state model. Required states and op.onal states. State transi.on diagram and specifica.on of state transi.ons.

6 Level 1 Level 2 Level 3 Level 4 Physical Security Opera:onal Environment Cryptographic Key Management Produc.on grade equipment. Single operator. Executable code. Approved integrity technique. Locks or tamper evidence. Referenced PPs evaluated at EAL2 with specified discre.onary access control mechanisms and audi.ng. Tamper detec.on and response for covers and doors. Referenced PPs plus trusted path evaluated at EAL3 plus security policy modelling. Tamper detec.on and response envelope. EFP or EFT. Referenced PPs plus trusted path evaluated at EAL4. Key management mechanisms: random number and key genera.on, key establishment, key distribu.on, key entry/output, key storage, and key zeroiza.on. Secret and private keys established using manual methods may be entered or output in plaintext form. Secret and private keys established using manual methods shall be entered or output encrypted or with split knowledge procedures.

7 Level 1 Level 2 Level 3 Level 4 EMI/EMC 47 CFR FCC Part 15. Subpart B, Class A (Business use). Applicable FCC requirements (for radio). 47 CFR FCC Part 15. Subpart B, Class B (Home use). Self-Tests Power-up tests: cryptographic algorithm tests, so_ware/firmware integrity tests, cri.cal func.ons tests. Condi.onal tests. Design Assurance Configura.on management (CM). Secure installa.on and genera.on. Design and policy correspondence. Guidance documents. Mi:ga:on of Other ALacks CM system. Secure distribu.on. Func.onal specifica.on. High-level language implementa.on. Specifica.on of mi.ga.on of a?acks for which no testable requirements are currently available. Formal model. Detailed explana.ons (informal proofs). Precondi.ons and post-condi.ons.

8 What level do you need? FIPS is a market enabler. There are very few occasions when you will need more than level 1. Any cer.fica.on needs to be cost jus.fied. I am going to concern myself with level 1 as that can usually be retrofi?ed, however I will also discuss the possibili.es of gra_ing on compliance to higher levels

9 How much work do you want to do? Do a compliance audit on what you have already Define your cryptographic boundary Iden.fy the gaps Inves.gate what the implementa.on op.ons are Use this as a learning opportunity so that if you get the chance later to do a development from scratch, you will be prepared.

10 What will need to change? Almost guaranteed: Self-tests and key zeroiza.on Other areas that may/will need a?en.on: Algorithms Entropy Key Management

11 Algorithms Approved algorithms have to have CAVP test cer.ficates. Algorithm tes.ng is a prerequisite for module func.onal tes.ng. CAVP tes.ng is free. Labs will charge for administering issuing test vectors and check results and submissions. Test early. CAVP tes.ng is quick and the results are listed publicly on the NIST website.

12 Self-tests - 1 Power-up self-tests: Cryptographic algorithm test for all cryptographic func.ons of each approved algorithm implemented by the module So_ware/firmware integrity test for all validated components (must use an approved authen.ca.on technique if Opera.ng System requirements are applicable)

13 Self-tests - 2 Plus condi.onal tests as applicable. ISO treats self-tests slightly differently, but if you are star.ng with a FIPS module, then the integrity test is synonymous with the pre-opera.onal so_ware/firmware integrity test of ISO and the algorithm tests can be used to map onto the condi.onal cryptographic algorithm self-test of ISO

14 Entropy The strength of keys in a module depends on the quality of the DRBG and also on the quality of the entropy used to seed that DRBG. (AS7.13) The strength of the key is the weaker of these two factors. If you have no entropy, you have no key strength. IGs have been introduced in recent years that have added to the scru.ny that entropy sources are under. Need to demonstrate the quality of entropy sources through design evidence and sta.s.cal tes.ng.

15 Key Management - 1 Amount of work depends on the scope of the module. The wider the scope of the key management within the module (e.g. key distribu.on, transport, or deriva.on) the more standards need to be complied with and so the more work there is to do. If you do not generate keys/csps, then there is less work that if you do. In most cases, the key zeroiza.on requirement can be met procedurally.

16 Key Management - 2 Key management standards are listed in Annex D: IG D.2. FIPS SP A Rev 2 SP B Rev. 1 SP SP SP rev1 SP C SP F SP

17 Level 2/3/4 It may be possible to bolt-on level 2 compliance. Added to level 1: Tamper evident physical security Role-based authen.ca.on It is unlikely that level 3 can be bolted-on: Port separa.on Manual key transport security Tamper detec.on and response physical security Iden.ty based authen.ca.on Class B EMI/EMC Level 4 needs to be built-in due to the requirements for formal model and informal proofs for design.

18 Module, Product, Solu.on A cer.fied module needs to be part of a compliant solu.on. A module need not provide all of the security necessary to protect assets, but it does need to be part of a compliant solu.on. If you have control over where the cryptographic boundary is drawn, it can reduce the work required to provide a compliant module. This is usually only prac.cable with so_ware modules. Excluding as much key management as possible from a module makes it easier to cer.fy, but you need to bear in mind the context of the security of the whole solu.on.

19 Conclusion/The Future FIPS and ISO embody standardsbased cryptography and this embodiment increases over.me It is gejng harder to adapt proprietary solu.ons to meet the requirements of the CMVP. Cer.fica.on is always an exercise in cost jus.fica.on. Planning in conformance is usually cheaper than bol.ng it on a_erwards.

20 Contact Details Alan Gornall Rycombe Consul.ng Limited