A large part of the .NET APIs are common to both .NET Core and .NET Framework. Microsoft even released the .NET Standard, a subset of .NET APIs provided by all .NET implementations, to simplify things for cross-implementation developers. However, there are still significant differences between Core and Framework, and cryptography is one of them.
Continue reading →
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.
Update March 2018 You can read about how to test PCI-DSS crypto compliance using our Analyzer software.
Original post:
The 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:
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.
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.