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.
Related
I'm trying to fix an old binary (sources unavailable of course...) that fails to connect now, probably because it's using outdated list of CAs.
However, when running through strace I don't see the binary attempting to read my CAs from /etc/ssl/certs.
Is it possible the list of CAs has been bundled into the binary itself ?
Thanks a lot,
Adam
To be clear, since you say source unavailable I assume you mean a custom program that uses OpenSSL library, since the source for the utility commandline-interface progam named openssl is still available for versions dating back to last century (and until 1.1.0 didn't change much, even when it probably should have).
Yes, definitely. A program using libssl (and libcrypto) can choose whether to use the standard file(s) for its truststore, or some other (custom) file(s) it specifies (often from configuration), or hardcoded data as you ask or data from some other source like a (secure, we hope!) database, or even no truststore at all if it uses ciphersuites that don't use certificate authentication -- anonymous, PSK or SRP -- which is rarely used but is supported by OpenSSL.
You might try strings on the program to see if they were basic enough to embed certs (and maybe other things) in PEM -- IINM that's how Lenovo Superfish was found. If they embedded binary 'DER', that still has enough redundancy you could find it, but not so easily.
Look at the network traffic with Wireshark or similar, or if you have access to the server check its logs, to see if the program is sending an alert in the range 41 to 49 in response to the server's first flight i.e. just after ServerHelloDone.
That would definitively indicate a certificate problem.
I'm after some concrete advice on how best to prevent (or at least deter) unauthorised software upgrades on an embedded system. It doesn't need to be bullet-proof and we can assume for now that the system itself is sufficiently locked down so that no-one can get unauthorised access to it.
My plan is to basically have an installer process running on the system which would receive update packages from anywhere but that could ensure those packages came from a trusted source (i.e., me) before attempting to install them.
In simple form, the update package would have the actual installation package, plus a matching digital signature that could only be generated by myself. Moreover, the signatures would be purely self-generated with no external authorities involved.
So these are my thoughts on the possible process:
Generate a private/public key pair and distribute the public key along with the embedded system itself.
When creating a software install package, pipe the contents of the package (or an MD5 of the package) through a signature generator using our private key.
Distribute the software install package along with that signature.
Have the installer check the signature against the software install package (using the public key it already has) and only install if there's a match.
If anyone can find any problems with this scheme, I'd appreciate the details, along with any specific advice on how to avoid them. In addition (though this is not the primary purpose of the question), any advice on tools to generate the keys would be appreciated.
I do not see any apparent problems with your solution. I can suggest improvements that you may have already taken into account
If the embedded software is sufficiently locked, it is not necessary to take additional measures to protect the integrity of the public key distributed with the software (e.g. by signing the installer itself and obfuscate, that could be a headache)
I've considered a TLS connection to download the updates, but it would not really needed, because packages are going to be protected with a digital signature
I suggest encapsulating the public key in an X509 certificate. This way you can control the period of validity and even a possible revocation if the private key has been compromised. In this case you will need a hierarchical Certificate Authority, with a root certificate that issues the signing certificates. Include in the truststore of the installer the public part of the root certificate. Then using a different signing certificate after expiration/revocation will be transparent to installer.
The root certificate has a long duration and a large key size (and should be conveniently secured), and the signing certificates have a shorter duration and can use a smaller key.
With this CA you could also generate a TLS certificate if you need some additional service: e.g check available updates. In this case include the certificate in the truststore of the installer to avoid man-in-the-middle attacks (SSL-pinning).
You can sign the full distribution or a hash. It does not affect security (see https://crypto.stackexchange.com/questions/6335/is-signing-a-hash-instead-of-the-full-data-considered-secure) but do not use MD5 because has extensive vulnerabilities. Use a SHA-2 function.
To generate the keys you can use openssl in command line or use the GUI application KeyStore-Explorer
I want to use Elliptic Curve Diffie-Hellman (ECDH) key exchange protocol for a key agreement process. It is already implemented in crypto++ library and I wanted to utilize it. I have already installed crypto++ (by typing sudo apt-get... command in a terminal) but since traditional ECDH is vulnerable to man-in-the-middle attack.
I want to use fully hashed menezes-qu-vanstone protocol. Although it is implemented for crypto++ it is not in the main stream so I need to patch it. There is an explanation here but it is for those who built the library from the source code.
Is there anyone who knows how to apply this patch to crypto++ that has been installed from Ubuntu repository? I am using Ubuntu 15.
but since traditional ECDH is vulnerable to man-in-the-middle attack.
What others often do is to pair ECDH with a signature scheme. For example, TLS uses ECDH with a scheme like RSA or ECDSA.
I'm not saying you should do it; I'm only letting you know what others are doing.
it is not in the main stream so I need to patch it...
We will be adding HMQV and FHMQV at the next release. The next release will be happening in the next couple of months.
Is there anyone who knows how to apply this patch to crypto++ that has been installed from Ubuntu repository?
The easiest thing to do would be to probably be to build a new version of the library, and then install it into /usr/local. I presume you know how to download and patch. To build and install:
# Crypto++ build directory
...
make static dynamic cryptest.exe
sudo make install PREFIX=/usr/local
You might be able to patch Ubuntu version because FHMQV is mostly a header-only implementation. However, cryptest.exe will not have the validation stuff included. You really need to build the library for it.
Download the patch and perform the following. fhmqv.h is the "meat and potatoes" of the patch.
sudo cp fhmqv.h /usr/include/cryptopp
You also need to add the following to eccrypto.h. Start by opening the file with privileges (i.e., sudo emacs /usr/include/cryptopp/eccrypto.h).
Then, add this to the top of eccrypto.h:
#include "fhmqv.h"
And add this to the bottom of eccrypto.h:
//! Fully Hashed Menezes-Qu-Vanstone in GF(p) with key validation,
/*! A Secure and Efficient Authenticated DiffieHellman Protocol
Note: this is FHMQV, Protocol 5, from page 11; and not FHMQV-C.
*/
template <class EC, class COFACTOR_OPTION = CPP_TYPENAME DL_GroupParameters_EC<EC>::DefaultCofactorOption, class HASH = SHA256>
struct FHMQV
{
typedef FHMQV_Domain<DL_GroupParameters_EC<EC>, COFACTOR_OPTION, HASH> Domain;
};
Most of the other stuff in the DIFF file is not needed, like the changes to wait.h and wait.cpp. It was added to address outstanding bugs. The bugs were cleared at Crypto++ 5.6.3.
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 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.