The announcement yesterday of this talk about HSM hacking on the BlackHat 2019 program has caused a stir, and for good reason: the authors claim to have discovered remote unauthenticated attacks giving full control of an HSM and complete access to keys and secrets stored on it.
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?
Interactive Application Security testing (IAST) first emerged as a concept in the early 2010s as application security companies looked to improve on static (SAST) and dynamic (DAST) testing by either combining results together, or looking for some kind of best-of-both-worlds approach.
Since that time, IAST has grown to about 20% of the AST market and is predicted to gain a larger share of this rapidly growing market in the coming years. However, in my opinion, the way IAST is understood and deployed today means that the acronym needs a tweak.
Continue reading →Amazon Simple Storage Service (S3) is one of the most widely-used cloud services. Most users of the service know it’s wise to encrypt sensitive data before storing it in S3. In this post we’ll look at how to do that securely using the AWS Java SDK, and how Cryptosense Analyzer will help you spot if you’ve done it wrong.
Note that in this post we’re talking about client-side encryption where the sensitive data must be encrypted locally before it’s sent to AWS S3 servers. There are also options for server-side encryption managed via the S3 console. These only treat the data while at rest, it will still be in clear inside AWS servers (at least briefly) each time it’s accessed.
There are several different client-side encryption modes for S3 offered by the Java S3 SDK. First you need to decide whether you want to manage your master keys yourself, or have AWS manage your master keys in their key management service (KMS).
There are several kinds of tool for testing applications for security vulnerabilities: Static Analysis Security Testing (SAST) looks at source code or compiled binaries and searches for patterns that suggest an issue. Dynamic Application Security Testing (DAST) tools test running code by sending inputs (typically to endpoints in a web application) and observing evidence of vulnerabilities.
At Cryptosense, we wanted to build a tool that would effectively identify and help fix vulnerabilities related to cryptography – something no other tool makes a good job of. We quickly realised that we would have to be able to test both code written by our users (to check the way it calls cryptographic libraries), the cryptographic libraries themselves (to look for known issues), framework components and dependencies (that are often using cryptography in insecure ways) and some kinds of behaviour that can only be observed at run-time (like key values loaded from keystores, passwords in configuration files, random number generators..).
Neither SAST nor DAST allow you to do all this – SAST does not see run-time aspects and DAST only sees the cryptography from the exterior of the application.
That’s why we built an IAST (Interactive Application Security Testing) tool, i.e. we instrument an application while it’s running to see all the cryptographic operations, and analyse these to detect crypto vulnerabilities.
Yesterday’s Oracle Critical Patch Update contains a credit to Cryptosense for CVE-2018-3210, a flaw found by one of our users while they were testing a Java application with our Analyzer software.
The bug involves a repeating IV in AES-CTR mode, a crypto mistake that can be hard to spot in code review. Our run-time testing approach detects it more easily. It’s also rather easy to exploit (see e.g. the Many-time Pad tool).
UPDATE: Graham recently contributed to this article in The Economist on Post-Quantum Cryptography.
Computers that exploit quantum mechanical properties offer the promise of (supposedly) unbreakable cryptography and other exciting applications, but they will also cause a huge, immediate problem: the day a large, practical quantum computer is developed, all existing widely-used asymmetric cryptography will be broken.
This will have serious consequences: massive amounts of secret information exchanged over the internet under public-key or hybrid cryptography could be revealed. Computers will no longer be able to ensure the updates they are downloading and installing are legitimate, since code signing will be broken. The owner of the first powerful quantum computer (which will probably be a large state organisation, who will keep it a secret) could have the power to take over almost every computer and mobile phone connected to the Internet. Even though nobody knows when this will occur, it makes sense to start preparing.
Our comparison of cloud crypto services is one of the most popular pages on our site, so we’re making an effort to keep it up to date as the “big three” providers announce new features. The latest update includes faster KMS speeds recently announced by Amazon, the PKCS#12 method for Bring-your-own-key that’s supported by Microsoft Azure (but not so easy to find details of), and the Google KMS support for asymmetric keys.
The latest version of the infographic is below. If you’re interested in integrating your application with cloud crypto services or cloud HSMs, you might want to check out our new cloud crypto whitepaper, where we compare in detail these services and various migration approaches.
Our recent work to add coverage of the Microsoft .NET API to Cryptosense Analyzer has led us into a dark and dangerous part of the internet: C# crypto tutorials.
It’s extremely dangerous to treat a cryptography API like just another interface where all you need to do is figure out how to “make it work”. It is theoretically possible to make, say, encryption and decryption “work” using a cryptography API while leaving a slew of terrible security holes. The C# Crypto API is no exception.
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.