I am going for a FIPS 140-2 validation process of my software module. I have studied the relevant material but I am still not clear of one thing that can I use third party FIPS validated approved algorithms in my to be fips validated module? or Do i need to write my own implementation of approved algorithms and get them approved from NIST first?
I am confused because; in Fips validation module list, most of the companies have their own validated algorithms in their fips validated module which gives me impression that one has to get the validation of his own algorithm implementation first and then use it in to be validated crypto module. Is this right?
Any help would be appreciated.
The FIPS certification lab doesn't care where the algorithm came from, only that your implementation conforms to the FIPS 140-2 standard. If your implementation conforms, then you get a certificate for it.
For example, if you look at the AES certification list, you'll see that many people use OpenSSL's AES implementation. Hardware implementations likely use an encryption core from a vendor rather than each organization re-implementing AES in hardware.
What you do have to do though is make the third-party implementation conform to the FIPS 140-2 standard. So you may have to write power-on self tests and continuous self tests and so on. You may even have to fix bugs in the implementation to make it pass the certification tests. For example, OpenSSL's RSA implementation up to 0.9.7j/0.9.8b (from 2006) is vulnerable to the Bleichenbacher RSA forgery attack, so if you were using that old RSA implementation, you'd have to fix it.
To be clear, your third-party implementation does not have to have been previously FIPS certified. Your certification lab will test it as part of your implementation and certify it then.
Related
I'm considering doing multisig with one of signatures using iOS Secure Enclave. However it only supports NIST P-256 curve.
I know it's not supported on protocol level, but is it possible to implement it in Rust smart contract? If so – where do I start?
Currently even if you can verify inside the smart contract NIST P-256 curve (here are libraries for verification, for example - https://github.com/RustCrypto/elliptic-curves/tree/master/p256), you would still need to sign the transaction with some ED25519 or SECP-256K1 key first to actually get blockchain to accept it before the contract code will be execute.
My understanding is that right now you can just store sequence of bytes in secure enclave and read it out and sign any function in user land. Here how it can be done securely - https://github.com/AlphaWallet/alpha-wallet-ios/pull/1272
If this is an important consideration to support iOS secure enclave singing, you can create a spec change proposal to add SECP-256P1 (which is NIST P-256) as an alternative key type to NEAR. It would have obvious downsides, but this is a clear upside as well and it's optional so each individual user can decide which curve they prefer to use.
I was researching on various key generation algorithms used in different kinds of blockchains out there in market.
I wanted to know which algorithms are used to generate public/private key pairs in following blockchains:
Ethereum
Hyperledger-Fabric
R3 Corda
Can someone help me with this?
I can't comment on the signature schemes supported by Ethereum or Hyperledger Fabric.
Corda is cryptographically agile, with multiple signature schemes available based on the desired trade-offs between cryptographic strength, compatibility with various HSM vendors, algorithm standardisation, variety of cryptographic primitives, business demand, option for post-quantum resistance, side channel security, efficiency and degree of testing.
As of version 3, Corda supports five signature schemes:
1. Pure EdDSA using the ed25519 curve and SHA-512
EdDSA is the current state of the art in mainstream cryptography. It implements elliptic curve cryptography with deterministic signatures, a fast implementation, explained constants, side channel resistance and many other
desirable characteristics. However, it is relatively new and not widely supported. For example, you can’t use it in TLS yet (a draft RFC exists but is not standardised yet).
This is the default signature scheme for the node's well-known and confidential identities, and for the network bootstrapper.
2. ECDSA using the NIST P-256 curve (secp256r1) and SHA-256
This is the default choice for most systems that support elliptic curve cryptography today and is recommended by NIST. It is also supported by the majority of the HSM vendors.
This is the default signature scheme for the root network certificate authority, the doorman, the node certificate authority (which issues the node's identity and TLS keys), the node's TLS keys, and the network map on the Corda Network.
3. ECDSA using the Koblitz k1 curve (secp256k1) and SHA-256
secp256k1 is the curve adopted by Bitcoin and as such there is a wealth of infrastructure, code and advanced algorithms designed for use with it. This curve is standardised by NIST as part of the “Suite B” cryptographic algorithms and as such is more widely supported than ed25519. By supporting it, Corda gains access to the ecosystem of advanced cryptographic techniques and devices pioneered by the Bitcoin community.
4. RSA (3072bit) PKCS#1 and SHA-256
RSA is well supported by any sort of hardware or software as a signature algorithm no matter how old. For example, legacy HSMs will support this, as will obsolete operating systems. RSA is using bigger keys than ECDSA and thus it is recommended for inclusion only for its backwards compatibility properties, and only for usage where legacy constraints or government regulation forbids the usage of more modern approaches.
5. SPHINCS-256 and SHA-512 (experimental)
SPHINCS-256 is a post-quantum secure algorithm that relies only on hash functions. It is included as a hedge against the possibility of a malicious adversary obtaining a quantum computer capable of running Shor’s algorithm in future. SPHINCS is based ultimately on a clever usage of Merkle hash trees. Hash functions are a very heavily studied and well understood area of cryptography. Thus, it is assumed that there is a much lower chance of breakthrough attacks on the underlying mathematical problems. However, compared to the EdDSA, ECDSA and RSA algorithms, SPHINCS uses relatively big public keys, it is slower, and it outputs bigger signatures.
Searched the web to find if Apache Cassandra is FIPS 140-2 compliant but did not find any reference. Any pointer or details in this regard would help.
Is Cassandra FIPS 140-2 certified?
According to NIST's Validated FIPS 140-1 and FIPS 140-2 Cryptographic Modules, there are no modules named "Apache" or "Cassandra" that are FIPS validated.
There's also a Modules in Progress, which lists binaries that are in various stages of testing. Neither "Apache" nor "Cassandra" are listed there, either.
You should check the underlying security library, like NSS or OpenSSL. It could be the module Cassandra uses FIPS validated cryptography from another library, like NSS or OpenSSL. The manual should discuss it, even if its only one paragraph.
PBKDF2 algorithm is used in SimpleMembership provider (Universal Provider) 2.0. Is it a Non-FIPS Complaint Algorithm? Please ensure the correct solutions?
PBKDF2 algorithm is used in simplemembership provider(universalprovider) 2.0 is a Non- FIPS Complaint Algorithm.
If I am reading this correctly, there are three questions here. First, you are asking about an implementation detail of SimpleMembership. Second, you are asking if PBKDF2 is approved for use in FIPS validated cryptography. Third, you are asking if SimpleMembership's PBKDF is approved for use.
First
I seem to recall SimpleMembership uses a non-standard PBKDF. You should be using Rfc2898DeriveBytes in System.Security.Cryptography.
Generally speaking, the FIPS approved algorithms and validated implementations are located in System.Security.Cryptography and they are non-managed. In fact, according to KB 811833, "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting effects in Windows XP and in later versions of Windows:
Microsoft .NET Framework applications such as Microsoft ASP.NET only
allow for using algorithm implementations that are certified by NIST
to be FIPS 140 compliant. Specifically, the only cryptographic
algorithm classes that can be instantiated are those that implement
FIPS-compliant algorithms. The names of these classes end in
"CryptoServiceProvider" or "Cng." Any attempt to create an instance of
other cryptographic algorithm classes, such as classes with names
ending in "Managed," cause an InvalidOperationException exception to
occur.
Second
PBKDF2 is approved for use if its using an approved hash. Since Rfc2898DeriveBytes uses HMAC/SHA-1, you will not be able to use it. NIST SP800-56 and SP800-57 are pretty clear about the choice of hashes for collision resistance.
However, your use case is a little different - SHA-1 is being used as a Pseudo Random Function (PRF). But I'm only aware of one exception where SHA-1 is allowed to be used as a PRF, and that's in TLS. The exception is a footnote in SP800-108 (IIRC).
Third
SimpleMembership's PBKDF is not approved for use.
I read that SHA-1 is being retired from the FIPS 180-2 standard.
Apparently there are weaknesses in SHA-1 that led to this decision. Can anyone elaborate on the basis for that decision? Are there implications for the use of SHA-1 in commercial applications?
My real questions are:
What is the state of SHA-2 support in various class libraries and platforms?
Should I attempt to move to SHA-2?
Interested in mainstream platforms: .NET, Java, C/C++, Python, Javascript, etc.
Sha1, Sha0, md4 and md5 have all been found to be insecure over the past few years. The problem is that if an attacker can generate 2 different messages that produce the same resulting hash, this is called a collision. This causes a lot of problems for PKI's, password management, file integrity checks and more. Currently sha1 only provides 2^52 bits of security which is within reach of attackers. Where as SHA-256 (smallest member of the sha2 family) is provides 2^256 bits.
All platforms should have a SHA-256 implementation, although not all of them are native. In PHP you have to use the mhash extension. Its rather baffling that some platforms don't provide secure hash functions, I honestly believe its because they don't care about secuirty. In the case of PHP I know for a fact that they don't care about secuirty.
Currently there is nothing wrong with SHA-2 and it has a very large margin of safety. You can use SHA-512 if you are really paranoid. Sha-3 will be out in 2012, you should patch whatever you can with sha-2 like your PASSWORDS, and then move to SHA-3 when you can but SHA-512 will be good for a VERY long time.
Windows Vista and later supports SHA-2 in the Microsoft Enhanced RSA and AES Cryptographic Provider for CryptoAPI, and the .NET Framework has supported SHA-2 since .NET 1.1.
Most platforms now support the SHA-2 family. However, SHA-1 is still used in many applications, like SSL, and will be in use for a while.
A competition for "SHA-3" is well underway. It might be reasonable to jump from SHA-1 to the new SHA-3 standard when it arrives.