Security Requirements of FIPS PUB 140 & Reconfigurable Hardware. G. Bertoni Politecnico di Milano

Transcription

1 Security Requirements of FIPS PUB 140 & Reconfigurable Hardware G. Bertoni Politecnico di Milano

2 What is FIPS PUB 140? It is a standard, issued by NIST and CSE, to define different levels of security requirements for cryptographic modules. All federal agency that use cryptography shall use modules FIPS 140 compliant 09 Jan

3 What is not FIPS 140 No cryptographic algorithms are defined For these we should refer to other FIPS PUB as FIPS 46 for DES FIPS 180 for SHA FIPS 186 for DSA and ECDSA FIPS 197 for AES Jan

4 History of FIPS140 The first FIPS 140 has been released in 1994, now we refer to that as FIPS 140-1; update of the standard has been issued in May 2001, FIPS Jan

5 What is a cryptographic module A Cryptographic module is the set of hardware, software, and/or firmware that implements Approved security functions (including cryptographic algorithms and key generation) and is contained within the cryptographic boundary. 09 Jan

6 Glossary CLD Configurable Logic Device RH Reconfigurable Hardware TOE Target of Evaluation CSP Critical Security Parameter 09 Jan

7 How devices are certified? The standard requires the presence of independent certifiers that test the cryptographic module and release the certify or discharge the device. The independent certifiers can not be consultant of the device manufacturer. 09 Jan

8 Security Requirements Area Different category that summarize the security aspect of a cryptographic module For each Area a level of security is reached by the TOE (Target Of Evaluation) The final level of security of the system is defined by the lower level reached, but intermediate result can be released. 09 Jan

9 09 Jan

10 Areas related to Reconfigurable Hardware Some areas of the security requirements are general and do not affect the implementation with Reconfigurable Hardware Since the crypto module can be implemented even in software this mean that there is no special restriction for CLD, a crypto module can reach Level 4 even if it is implemented in CLD. CLD is not a bottleneck for the security requirements of the crypto module 09 Jan

11 Security Requirements and Reconfigurable Hardware Some of the security requirements are connected with the CLD implementation Roles, Services and Authentication Operational environment Mitigation of other attacks 09 Jan

12 Roles, Services and Authentication This area specifies the possibility of performing special task as initialization, tests, status check... It is possible to define some special roles as Maintenance Role, which can perform physical or logical tests. In this case CSP should be zeroized Crypto Officer Role which perform initialization of the device The role does not correspond to an user of the crypto module, it could be performed even by a process 09 Jan

13 Operational Environment The operational environment refers to the management of the components required for the module to operate. The standard allow both modifiable and non modifiable operation environment. The standard focus attention on Operating System, referring to Common Criteria 09 Jan

14 Operational Environment For software and firmware the standard requires: A cryptographic mechanism using an Approved integrity technique (e.g., an Approved message authentication code or digital signature algorithm) shall be applied to all cryptographic software and firmware components within the cryptographic module. 09 Jan

15 Mitigation of other attacks The standard do not addresses to particular attacks, leave the possibility to the developers to release some information about crypto module features against specific attacks. 09 Jan

16 Conclusion There are no specific points in FIPS PUB 140 that should restrict the use of reconfigurable hardware 09 Jan

17 References Jan