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.
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.
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.
Jenkins is a popular tool for managing continuous integration (CI), i.e. coordinating builds, tests and deployment of a software project in an automated way.
In an enterprise context Jenkins has some security requirements, like ensuring that only users with the right permissions can access certain projects and carry out certain tasks, protecting sensitive data such as tokens for access to APIs, etc.
Continue reading →