April 3, 2020

FIPS 140-3 Compliant Cryptography

Adjusting to the new world of NIST cryptographic module standards

We have had a number of queries recently at Cryptosense from people trying to figure out what FIPS 140-3 is, and how they can supply a FIPS 140-3 compliant solution to their customers.

To make sense of this question we first need to understand a little background. Maintained by NIST, the Federal Information Processing Standards (FIPS) gives guidance to external suppliers regarding the standards their products have to reach for use by the US Government. Over time, they have become de facto standards for other sectors and other countries.

Continue reading →

April 23, 2019

How common is insecure cryptography?

Application security teams have limited resources for improving security. Deciding where to deploy them is not easy, and the right answer will vary for different organisations. However, one question we’re often asked by teams considering our Analyzer software is, how common are the kind of “rubber hits the road” deployment of crypto flaws that it detects?

Continue reading →

July 26, 2018

Cloud HSMs – The New Wave

Hardware Security Modules (HSMs) are generally viewed as expensive and painful to maintain. It’s not surprising that a lot of HSM users are looking for a cloud-based solution that would allow them to hand over maintenance to a third party and move to an opex instead of capex model (i.e. rent the HSM instead of buying it).

At the same time, companies looking to migrate their more complex business-critical applications are finding that Cloud Service Provider (CSP) key management APIs (e.g. AWS KMS, GCP KMS, and Azure keyvault as covered in an earlier post) often don’t offer the cryptographic flexibility they need to migrate securely and in compliance.

Responding to these market forces, a new wave of cloud-hosted HSMs is arriving. Equipped with standard APIs like PKCS#11, they offer the promise of flexible crypto services while keeping keys secure from cloud application compromise.

Continue reading →

May 31, 2016

New Crypto Requirements in PCI DSS 3.2

Update March 2018 You can read about how to test PCI-DSS crypto compliance using our Analyzer software.

Original post:

PCI logoThe new version (3.2) of the PCI DSS compliance requirements for the payment card industry was released a few weeks ago. While the PCI definition of strong cryptography remains unchanged, the new version contains some other interesting new measures around secure use of cryptography:

 

  • The deprecation of SSLv3 and TLSv1.0/1.1 are confirmed. However, to stay compliant, you still have two years to remove them before the deadline of June 2018.
  • A new requirement has been introduced for service providers to map out their cryptography use:

    3.5.1 Additional requirement for service providers only: Maintain a documented description of the cryptographic architecture that includes:
     Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date
     Description of the key usage for each key
     Inventory of any HSMs and other SCDs used for key management

(a “service provider” is defined here as someone who is “directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity.”)

No doubt many service providers already maintain such documentation, but the reality is that sometimes externally sourced applications that encrypt cardholder data for storage or transmission may be using undocumented cryptographic methods that the service provider is not aware of. Here the PCI standard is making it clear that it’s the service provider’s responsibility to know want crypto they are using.

Crypto Cartography Software

Cryptosense software can detect the crypto used by applications using common cryptographic libraries like Java and OpenSSL, and test its security and compliance with PCI-DSS. Get in touch to find out more.


Get a free trial of Cryptosense Analyzer