A naive approach would be to just review the source code and search for cryptographic calls. However, this is both time-consuming and error-prone: what will the parameters be when this function is actually called? Which provider will respond to the call? Are we sure this isn’t dead code or an unused part of a library? On top of this, a lot of crypto in large applications is called by third party intermediate libraries and components of application frameworks for which source code might not even be available.
Cryptographic Vulnerabilities, News & Research
We often talk about the “big three” cloud providers: AWS, Azure and GCP. Reliable market share data is hard to come by, but common thinking is that GCP are a little way behind the “big two”. Meanwhile, Oracle’s IaaS offering OCI (Oracle Cloud Infrastructure) is a long way behind the “big three”, and figures only as a thin Larry Ellison tie on AWS’ own market share presentations.
— Arun Gupta (@arungupta) November 28, 2018
However, Oracle are now putting some very serious investment into their cloud in an effort to capitalise on their enterprise customer base. Several of our own large customers are looking at OCI as a possible alternative or complement to other CSPs.
A recent NIST paper recommending which steps to take to prepare for the advent of quantum computers proposes that users of cryptography look to achieve ‘crypto agility’ as soon as possible. The idea was further expanded by Gartner in a recent research note, and now crops up regularly. It’s sometimes described as ‘crypto-agnosticism’, but what does it mean, and how does one achieve it?
Designers of cryptographic protocols have talked for a long time about the idea of algorithm agility. The principle is simple: that a protocol will be designed in such a way that its function is, to some extent, independent of the choice of cryptographic algorithm used, therefore allowing you to switch algorithm. You might even have a set of recommended cipher suites that can be negotiated in each protocol exchange – this is how TLS works for example. There are now whole RFCs dedicated to the topic.
Crypto agility extends this idea from network protocols to all of the cryptography in use in an organisation. This means that an organisation can only become crypto-agile when the security team knows all of the algorithms, keylengths, crypto libraries and protocols in use in their applications and infrastructure, and has a plan that would allow them to change if necessary.
Interactive Application Security Testing (or as we recently argued it should be known, Instrumented Application Security Testing) works by adding hooks into a running application and analyzing its behaviour to look for security flaws. It has many advantages and it’s the technique we use to test crypto security in our Analyzer tool.
Modern versions of IAST (like ours) can detect flaws even when the application is executing standard functional tests – there is no need to simulate attacks. This enables these tools to be deployed early in the development lifecycle and integrated into CI toolchains. However, there’s one key feature that doesn’t figure on most IAST checklists: coverage checking.
Suppose I get a nice green report from my IAST tool saying there are no vulnerabilities in my app – how do I know that all the parts of my code where there might be issues were actually exercised during testing?Continue reading →
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).
When we started testing the cryptography in Java applications using our Analyzer software, one of the first results we found was the use of a 512-bit RSA key for signature verification.
At first this looks rather alarming since 512-bit RSA keys are easily breakable by brute force factorisation now.
Over the last few months we’ve updated our popular whitepapers.
- The Cloud Cryptography Migration whitepaper now covers the latest crypto features released by the big three cloud service providers (AWS, GCP and Azure).
- The Java crypto Security Whitepaper has been updated to take into account the changes Oracle made to the Java keystores after our vulnerability research work last year as well as several other smaller updates.
- Finally the PKCS#11 security whitepaper has been updated to reflect more closely how we’ve seen HSM users consider the security of these devices.
We always appreciate feedback and suggestions on our whitepapers, please don’t hesitate to get in touch.
I was the guest on the francophone infosec podcast NoLimitSecu this week, talking about TLS v1.3: why it’s important, how it’s different from previous versions of the protocol, and what real differences to security the new cryptographic design will make. Check it out and see if my French accent has improved.
Thanks to the regular podcasters for the warm welcome and the searching questions: Christophe Renard, Nicolas Ruff, Johanne Ulloa, Marc-Frederic Gomez, and Vladimir Kolla.
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.