What the hell actually is FIPS 140-2?

If, like me, you’ve poured through different resources trying to really understand FIPS 140-2 and what is required to achieve this standard then this article should hopefully give you the answers and links to more information.

Over the years I’ve worked with a number of customers who have some sort of requirement for FIPS 140-2, or have it imposed upon them – usually by a Government organisation. DES, Triple DES/3DES, public key and private key, hashing etc. all all different ways of encrypting or obfuscating data and there are a lot of resources available to understand these however I have found FIPS 140-2 very slippery in this regard; mostly when I have met this requirement I have simply passed on the requirement to a supplier to fulfil this on our behalf. I thought it was about time I really grasped an understanding of this.

This is what I have found:

  1. It is not an encryption or hashing method, but rather a standard defining a set of criteria that must be met i.e. it doesn’t impose one particular technology or algorithm
  2. It is a replacement of the previous standard FIPS 140-1 which ended service around the end of May 2002
  3. There are 4 levels of the standard, with the following requirements:
    1. Security Level 1: cryptographic module only
    2. Security Level 2: security level 1 must be met plus physical security consisting of tamper-evident devices to protect the module, role-based identification of users, an evaluated (EAL2) general purpose operating system that meets the Common Criteria Protection Profiles of the standard (see 1.2 of the publication)
    3. Security Level 3: security level 2 must be met plus physical security must be amplified to prevent an intruder from accessing the module and have a high probability of detecting and responding to attempts (e.g. strong enclosures and automatic erasure under unauthorised access), individual identification of users and role-based permissions, physical separation of ports or interfaces used for other means, an evaluated (EAL3 and Informal Target of Evaluation Security Policy Module) general purpose operating system that meets all of the Protection Profiles and Trusted Path of the standard (see 1.3 of the publication)
    4. Security Level 4: security level 3 must be met plus penetration of the module from any direction has a high probability of being detected thus resulting in erasure of keys, environmental conditions must be monitored (e.g. power and temperature) and detected which would also result in erasure of keys (alternatively, extensive testing should prove that this requirement is not necessary), an evaluated (EAL4 or higher) general purpose operating system that meets all of the requirements of security level 3 (see 1.4 of the publication)In most cases, a requirement of FIPS 140-2 (without the specification of a security level) will be satisfied by meeting security level 1.
  4. It (loosely) specifies that the cryptographic module is within a list of approved methods:
    1. Symetric Key: AES (128bit or above), Triple DES and EES
    2. Asymetric Key: DSS (DSA, RSA and ECDSA)
  5. Some authentication to access the key should be implemented even for single user access – this would suggest a standard username/password combination consisting of at least an 8 character password
  6. Transmission of the key should be conducted using one of the previously mentioned approved methods of equivalent or greater strength i.e. it must be encrypted to a secure standard that meets or exceeds itself
  7. All controls (including but not limited to those listed above) must be documented and tested regularly, any non-standard cryptographic module must be independently tested and rated i.e. unless absolutely necessary industry standard cryptographic modules should be used

NOTE: The purpose of this article is to give a summary understanding of FIPS 140-2, essentially a starting point. Anyone required to implement FIPS 140-2 or meet the standard in anyway should view the FIPS 140-2 standard.

I would like to thank Archimedes Newton for his excellent article which really helped me to get a basic understanding of FIPS 140-2.

About Stephen Pickett

Stephen Pickett is a programmer, IT strategist and architect, project manager and business analyst, Oracle Service Cloud and telephony expert, information security specialist, all-round geek. He is currently Technical Director at Connect Assist, a social business that helps charities and public services improve quality, efficiency and customer engagement through the provision of helpline services and CRM systems.

Stephen is based in south Wales and attended Cardiff University to study Computer Science, in which he achieved a 2:1 grading. He has previously worked for Think Consulting Solutions, a leading voice on not-for-profit fundraising, Fujitsu Services and Sony Manufacturing UK as a software developer.

Stephen is the developer of ThinkTwit, a WordPress plugin that allows you to display multiple Twitter feeds within a blog.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.