We have to design and construct a system that signs files with sensible data, like evidences/proofs. The sign process is simple, basically calculate MD5 of the file content and encrypt the MD5 result with 3DES. The problem is primary the key storage and management.

The keys will be provided by government agency using an SmartCard (Cryptoflex) or by sending a file encrypted with our certificate.

The question is, can be construct such system using exclusively software modules, not HSM or similar, being such system FIPS 140-2 Level 2 compliant?

The idea is to load the keys into Windows CNG using Windows software KSP (Windows Server 2008 R2) and then, requesting CNG performing the cryptographic operations over the data to be signed.

Alternatively the system could be CC-1 low level or EAL 5 compliant.

Microsoft CNG is FIPS 140-2 Level 1 and seems there are plans to be Level 2 compliant. Also is stated that can be used to construct a system Level 2 compliant. Our question is about avoiding HSM or any HW solution to store the keys and/or performing cryptographic operations. Key loading using an Smart Card reader is ok due to is a cheap device (<100$?).

Any other software library can be used, in conjunction with Microsoft CNG or a complete replacement like some implementations of PKCS#11. Library must be .Net, preferably .Net 4. The last and final/harder question is, we are thinking executing this software in Microsoft IIS as a web application (intranet only), interacting with local database and local filesystem, this is a problem and should be designed as an standalone Windows application?

Any advice is appreciated.

  • What is your exact question? If your asking if this can be done I am sure it can, you even say it can be done, per your unnamed source.
    – Ramhound
    Commented Jun 20, 2012 at 11:01
  • Microsoft states that CNG can be used to build a Level 2 compliant system, but not specifies how nor if requires HW elements such as HSM. The key point is about key storage, if we need HSM to at least store keys or we can use CNG to store keys. Commented Jun 21, 2012 at 7:42
  • Microsoft says: CNG was designed to be usable as a component in a FIPS level 2 validated system. msdn.microsoft.com/en-us/library/windows/desktop/… Commented Jun 21, 2012 at 7:43
  • Note that MD5 is not an approved hashing algorithm for FIPS 140-2 except in some very extreme edge cases (such as used in TLS or DTLS or, I believe, as a method to self-test the integrity of the FIPS module before it is active). Commented Jun 21, 2012 at 7:58
  • I know. The FIPS 140-2 compliance question is more related to key storage. Commented Jun 21, 2012 at 8:51

2 Answers 2


OK, these are a lot of questions for one answer, and I think I can probably only hit two of them.. but here it goes:

FIPS 140-2 Level 2

The FIPS 140-2 requirements are centered around how keys are managed, protected, manipulated and stored. For reference, I'm reading the Security Requirements from the NIST site.

What I'm seeing is that in the transition from Level 1 to Level 2, the standard adds requirements that relate to the physical storage of key material - most strikingly tamperproofing on a physical level. The requirements move from working in Level 1 where the key storage could be software, to requirements where I can't see any way that you could hold the keys in the memory of a standard PC or laptop - you have to have a protected physical location for the key material.

That's not to say that the protected physical location has to be a $10,000 HSM - if I'm reading the Validated Cryptographic Modules list right, there are a few cases in there where vendors of what appear to be SmartCard based products are validated all the way to Level 3. Certainly some SmartCard products provide tamper evidence.

From my experience, when you are operating your key store in software, you can't really call the overall system a FIPS 140-2 level 2 solution - because you can't give that tamper-proof evidence strongly enough. But you can get software modules that can "operate in a FIPS 140-2 Level 2 mode" - meaning they will interoperate with a device that can provide tamper evidence at this level and the module will do so in a standards compliant way that doesn't move the key to any place it shouldn't go.

To try to nail down the question - if you can find a FIPS 140-2 level 2 compliant smart card product (and I think you can), you can make a lower-than-HSM cost solution work, but you have to realize that the SmartCard will need to be present whenever you want your solution to do crypto operations - because taking the keys off the card will destroy the purpose of tamper-proofing. So I'm not sure you're going to get to "Key loading using an Smart Card reader" which to me implies trying to get the protected keys off the card.

Alternate Standards - CC-1 and EAL 5

I'm a little confused here as these are not exactly the same thing. EAL 5 is for a fairly stringent level of verification that a product meets its defined security behavior. But it's not the same thing as the key protections provided by FIPS 140-2. Frequently, I've developed systems that have had to use both, because they offer different types of assurance. Having a really high EAL level will protect you in different ways from having Level 2 FIPS.

I'd be very reluctant to recommend interchanging these - you need to design a system that protects itself to the level of the risks in the environment and the value of information/operations it protects. Swapping between standards isn't going to do that - security analysis will.

Intranet or standalone

This really has to be based on the needs of an application. Where you situate it, how you control access, what purposes Intranet or local users will have for it, and what you need to protect will dictate where you put it and what protections you need for it.

Certainly, the more accessible you make the application, the wider your surface area for attack will be. But online systems may also be easier to update and maintain, and if availability in a crisis outweighs inaccessibility in case of attack, then online may well be better than standalone client.

I'd be wary of advice on this point that didn't stem from a fairly comprehensive discussion of your purpose and product.

  • Usually you need FIPS 140-2 compliance to sell in the Americas, EAL levels to sell in Europe. They are different standards with different characteristics, but I find the most striking difference to be the market segmentation. Commented Nov 24, 2012 at 0:48
  • Thanks for the clarification! The solution we are thinking now is to have a SmartCard with the keys permanently attached to the PC in order to perform the cryptographic operations as they are on-line by nature. Having a SmartCard permanently attached to a reader plugged to the PC is not the preferable way for us but the budget constrains of the project force us to such kind of solutions. Commented Nov 26, 2012 at 8:20
  • The card really needs to go with the user if the purpose is for signing. The whole point of the card is it provides a second layer of protection, "something you have and something you know". Tamper resistance also tends to imply someone is regularly 'looking' for tampering. The user inserting and removing the card meets this criteria, but a card that sits mostly hidden in a reader really isn't getting inspected.
    – VoteCoffee
    Commented Nov 10, 2014 at 20:21

Netscape's Security Services has a software FIPS-140 level 2 certification, but not on Windows: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#814

.Net wrappers for PKCS#11 exist: http://en.wikipedia.org/wiki/PKCS_%E2%99%AF11#PKCS_.2311_wrappers

But (i) don't expect to use MD5 in a FIPS compliant modules (ii) read up on the difference between HMAC and "hash and encrypt" and rethink your "signature" scheme.

  • Thanks, the "signature" scheme, MD5 and other design issues are out of our scope, as are demanded by the client and are mandatory. I know, they are "old" schemes, but they are enforced as official ("national") specs. Commented Feb 1, 2013 at 5:56
  • Fair enough, if you're doing it to comply with a client specification not because you've made it up, that's different.
    – armb
    Commented Feb 5, 2013 at 13:59
  • Yes! They are client/country specs. 3DES&MD5 signing is a bit outdated, but they must maintain compatibility with existing systems so they maintain the old signing scheme. Commented Feb 5, 2013 at 20:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .