Cryptographic Vulnerabilities, News & Research

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 30, 2018

512-bit RSA Keys and MD5-Digest Signatures in Oracle JRE

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.

Result form the Analyzer when detecting short RSA Keys

At first this looks rather alarming since 512-bit RSA keys are easily breakable by brute force factorisation now.

Continue reading →

November 15, 2018

Whitepaper Updates

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.

November 13, 2018

Cryptosense on the NoLimitSecu Podcast

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.

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 →

October 3, 2018

Post-Quantum Crypto: How to Start Preparing

post quantum crypto

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.

Continue reading →

August 27, 2018

Dangerous Tutorials: How not to learn C# cryptography

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.

Continue reading →