March 20, 2020

Key Usage Detection in Cryptosense Analyzer

Cryptographic Key Usage

Identifying the cryptographic keys an application really uses, what they are used for, and how they are stored, is a critical step towards many transformation projects. For example: automating cryptography inventory, or preparing to migrate an application to the cloud. This information also allows us to check that all the right data is being protected, and find a cloud crypto service that can accommodate the keys the application needs.

Previously, this was a time-intensive manual job, which involved inspecting code or testing the application environment. Now, Cryptosense Analyzer can automate key usage detection.

How Analyzer Finds Key Usage Information

Unlike other tools on the market, Cryptosense Analyzer is able to see inside running applications, this gives it a unique insight into the real workings of the application.

Cryptosense Analyzer works by tracing all the calls an application makes to its crypto libraries in a IAST style. Once this information has been passed through our analysis engine, you get an output showing cryptography inventory information and vulnerability analysis on all the cryptographic operations the application carries out. Since February 2020, Analyzer also infers a list of cryptographic keys, and keeps track of what they are used for.

What the Key Lifecycle Report Looks Like

Here you can see the result we got when we ran Analyzer on the Jenkins application. The interface allows you to filter out certain keys, such as those that are unused (often public key certificates in TLS keystores), and ephemeral keys (like TLS session keys).

If you are planning a migration to cloud cryptography, you can also check which keys would be suitable for direct use as a bring-your-own key in cloud crypto services.

Usage of all application keys

For each key, you can click to drill down on all the operations carried out by that key.

And for each operation, you can see the exact lines of code that made the calls.

What’s next? More help with Cloud Migrations.

We have been testing the new Key Lifecycle detection feature with a group of early users. They have already found that having accurate information showing what keys are doing and how they are stored is a great help for speeding up migration work. It has also helped them to easily identify poorly protected keys and missing encryption.

We are working on making it even easier to transform key storage for the cloud. Sign up for our newsletter (box in the upper right) to keep up to date with new features as they’re released, or get in touch for a demo.

November 12, 2019

The Capital One Breach and Cloud Encryption

On 29th July 2019 CapitalOne Financial Corp announced a data breach affecting 140 000 of their customer’s social security numbers and 80 000 bank account numbers. CapitalOne is a major user of AWS cloud, and in this case the stolen data was stored in AWS S3 buckets. Since the perpetrator was arrested and left quite a long trail on social media, much more detail about this breach has become public than usual, allowing in-depth analysis of what went wrong.
Continue reading →

August 26, 2019

What is Cryptographic Inventory?

Companies that handle sensitive data are frequently required to demonstrate to internal or external auditors that they use cryptography appropriately as part of their data protection strategy. This requires them to use a definition of acceptable cryptography (that often comes directly from a standards body like NIST/FIPS or PCI-DSS), and evidence that this policy is enforced throughout their infrastructure.

An automated, up-to-date Cryptographic Inventory provides this evidence. It can also be leveraged to develop “crypto agility” (the ability to change cryptographic libraries and algorithms rapidly when required). But what exactly should you put in a “crypto inventory”, and how do you make one efficiently?

Continue reading →

June 8, 2019

How Ledger Hacked an HSM

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.

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 →

December 17, 2018

Why IAST should mean Instrumented Application Security Testing

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 →

December 7, 2018

Auditing AWS S3 Crypto Use

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).

Continue reading →

November 13, 2018

Why Cryptosense is an IAST Tool

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.

Continue reading →

October 17, 2018

Cryptosense Analyzer finds Crypto Flaw in Java EE

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).

Continue reading →