According to my understanding, FIPS compliance is compliance at hardware as well as software level.
FIPS 140-2 is a big document centered around hardware. The guys writing the requirements were electrical engineers who built hardware. For example, Dr. Randy Easter runs the Cryptographic Module Validation Program (CMVP). Here's his brief CV: http://www.nist.gov/itl/csd/easter-randy.cfm. He's a double-E for sure ;)
When NIST and the CMVP back fitted the requirements to software, they pounded a square peg into a round hole. You will find lots of things that make absolutely no sense in the context of software. For example, OpenSSL (and other FIPS validated libraries) store the HMAC (symmetric) key to verify integrity of the software in the software itself. (Its a lot different when the key is burned into rom, with the fuses blown, on tamper resistant PCBs, and in tamper resistant enclosures).
For completeness, you can find the approved methods of integrity testing in the Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program. They really do include a CMAC and HMAC.
... Android app FIPS compliant ...
First things first :)
According to the Cryptographic Module Validation Program (CMVP), there are two types of cryptography: validated and not validated. "Compliant" means nothing (nor does "conforming", "approved", "equivalent", etc).
Your app will use validated cryptography, or it won't use validated cryptography. If you state your app is using "compliant" cryptography, then it is not using validated cryptography. Here's a typical marketing mistake: http://webdrive.com/support/webdrive/v11/fips_compliance.htm.
I know DHS pulled a bunch of switches out of Federal because the switch manufacturer's marketing department called them "FIPS Compliant" rather than "FIPS Validated".
1) If i want to make my Android app FIPS compliant, if i have
the only crypto module used in my project FIPS compliant, is it enough?
No. There are two parts to this No. First is procedural, and its set out in the module's security policy. For example, OpenSSL has a procedure to build it from sources, and you can't deviate from the procedures.
The second is usage (for lack of a better term), and it requires you to comply with FIPS 140-2 operational requirements. For example, you can't reuse keys and ivs when sending messages encrypted under AES.
Something that falls into both: you must call FIPS_mode_set, and it must return non-zero. Failing to call FIPS_mode_set is a procedural error and means you are not using validated cryptography. A failure from FIPS_mode_set is an operational error and means you are not using validated cryptography.
If you are using OpenSSL, you should also include "vendor affirmed" in your data sheet, and cite the 1747 certificate. I believe that's a requirement of the Security Policy, and failure to provide it means your cryptography is not validated!
Crypto module provided by Android SDK is the BouncyCastle
library and it is not FIPS compliant.
I don't use Bouncy Castle, so I don't know its status. If the library has been validated, then there will be a certificate issued by the CMVP. You can look them up at Validated FIPS 140-1 and FIPS 140-2 Cryptographic Modules.
I am using FIPS compliant OpenSSL library in my project
as per stackoverflow link
You should also try OpenSSL's wiki: FIPS Library and Android.
For completeness, you cannot use Android's build system for OpenSSL and then claim FIPS validated cryptography. Its a total divergence from the procedures published in the Security Policy, so it invalidates the validation.
According to the FIPS OpenSSL module for Android documentation,
the module has been tested on different Android devices of armv7
architecture.
This is a tough area to untangle. Steve Marquess tried to answer it at OpenSSL FIPS 2.0 Object Module platform questions.
Here's my (possibly incorrect) understanding: once a platform is validated, minor changes to the platform are tolerated by the Cryptographic Module Validation Program (CMVP). I'm avoiding just what a "platform" is, but it includes motherboard, processor, instruction set, and other operational influences. In general, it does not include environmental influences like runtime libraries.
For example, Apple can make minor modifications to the motherboard for an iPad with A6 processor (perhaps changing its form factor or supplying an improved integrated camera). It can even make minor modifications to the A6 processor itself (perhaps increasing the cache size). They can call it whatever they want (an IpAd 3, iPad 4, or whatever tickles the Fan Boi's). However, an A7 processor in the same motherboard would require another validation because its a major revision. The same applies to instruction sets: armv7 and armv7s requires separate validations.
As another example, consider ARMv7 processors. Snapdragon processor that uses ARMv7 is a different platform than a Classic ARM7EJ-S from ARM Holdings corporation. Both required separate validations. And a NEON is ARMv7, and it got a separate validation (I think it added a few multimedia instructions on top of ARMv7).
And the CMVP can change its mind at anytime and stop tolerating the minor platform modfications.
Will Android hardware not being FIPS compliant
matter here
No, as long as the platform (including hardware) was previously validated. If the platform was not previously validated, then its a problem ;)
3) AES algorithm is under FIPS compliance. Does this
mean that if i use AES algorithm in Java code instead
of using FIPS compliant OpenSSL library , its not
FIPS compliance.
Correct. The Java code is not FIPS validated, so your app cannot be using FIPS validated cryptography.
For completeness, there's also a Cryptographic Algorithm Validation Program (CAVP). The CAVP will sign-off on the AES implementation by issuing a certificate. For example, OpenSSL's AES implementation has been issued certificates 1884, 2116, 2234, 2342, 2394 and 2484.
Eventually, after other NIST departments (such as the CAVP) finish inspecting your module, then the CMVP will sign-off on the module (as a whole) and issue a certificate. For example, NIST issued Certificate 1747 for OpenSSL.
If AES is under FIPS compliance, what does it have to do with
Java or C# implementation of AES. Do they both have to pass
through the CMVP ?
Since you are using FIPS Validated OpenSSL, then you will have to:
- Under Android and Java, use JNI and call into a shared object. The shared object must provide OpenSSL's FIPS validated cryptography.
- Under C#, use P/Invoke or Inerop and call into a dynamic link library. The dynamic link library must provide OpenSSL's FIPS validated cryptography.
I have built my project library using the OpenSSL
library ie libssl.a and libcrypto.a configured
using FIPS module.
You cannot run fipsld and incore over static libraries, so it sounds like something is wrong. They can only be run on executables and shared objects. fipsld and incore work together and embed the the signature of the FIPS-related code and data into your executable, shared libary or app. The FIPS-related code and data come from (1) fipscanister.o and (2) fips_premain.c.
To bring it full circle, fipsld compiles fips_premain.c and links in fipscanister.o to your executable, shared object or app. Then incore writes the signature into your executable, shared object or app. When you call FIPS_mode_set, the integrity of the FIPS-related code an data is verified via an HMAC, and then the FIPS-related self tests are executed. If all succeeds, then FIPS_mode_set returns non-zero and you are using FIPS validated cryptography.
As a reference, OpenSSL provides a wiki page here: FIPS Library and Android. It discusses how to set up CC and FIPSCC_LD so fipsld and incore "just works" when make'ing your project.
There is no equivalent iOS page. But you can find the instruction in the OpenSSL FIPS User Guide 2.0, Appendix E.
