• SOLUTIONS
      • Cryptosense Analyzer Platform
      • Cryptography Inventory
      • Secure Cloud Migration
      • PKCS#11 Device Audit
  • RESOURCES
      • Whitepapers
      • Webinars
      • Cloud Cryptography
      • Datasheets
      • Training Courses
      • Blog
  • COMPANY
      • About Us
      • Careers
      • Partners & Resellers
      • Contact
  • SUPPORT
  • GET IN TOUCH
November 8, 2019

Automated Attack Trees for TLS Vulnerabilities: Improving Cryptosense Discovery

What’s new?

Cryptosense Discovery is our free tool to test a host’s usage of cryptography for common configuration mistakes and vulnerabilities. Discovery’s new version discovers more hosts and more vulnerabilities, and improves the visual representation of attacks. We achieve this by using a well-known visualization method called attack trees. Attack trees do not simply report scores: they explain why a host is vulnerable and what the user must fix first. This greatly eases the hard job of correctly configuring TLS servers — especially at scale, when prioritizing tasks is not always trivial.
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 →

December 18, 2017

Cloud Crypto Providers – AWS vs Google vs Azure

With more and more sensitive applications being migrated to the public cloud, we’ve received several requests from our users to help them evaluate how the major cloud providers support crypto and key-management. In a series of posts, we’ll be taking a look at the cloud crypto APIs of AWS, Google, and Microsoft (Azure).

Continue reading →

April 7, 2017

Java Crypto Updates Delayed

In January 2017 Oracle released a Java update with a number of improvements to its crypto security. These included increasing minimum parameters (1024 bits for RSA XML signatures and DSA certificates, 256 bits for Elliptic curve keys used in TLS,..), and changing the treatment of a number of crypto operations (for example, JARs signed with less-than-1024-bit RSA keys are now considered unsigned).

However, these changes would be considered overdue my most standards agencies: both the 2016 NIST and ECRYPT standards consider 1024 bits RSA suitable only for legacy use. This highlights a problem with Java: every upgrade must take into account the vast amount of deployed code that might break when these parameters are changed.

Continue reading →

August 14, 2015

Dynamic records and enumerators: Open-sourcing OCaml libraries

Updated March 2018

We open-sourced a lot more libraries since this first post, including our popular OCaml Linter – take a look on our Github page.

Original post

The vast majority of the Cryptosense code base is built using OCaml. We’re excited to announce that we’re releasing a couple of the OCaml libraries we developed as free software: records and enumerators. Here we’ll describe what the two libraries do and what we use them for.

Continue reading →

May 25, 2015

Batch-GCDing Github SSH Keys

The security of RSA relies on the fact that factoring the public modulus of a key is computationally hard: for example, if the modulus is of the form p.q, where p and q are large primes, there is no known efficient algorithm for obtaining the factorisation. But suppose that we have a large number of keys available: we can try to compute the pairwise GCDs of these moduli. If two of them happen to share a common factor (that is, one is p.q and the other one is p.q’), their GCD will be p and it will be possible to factor these two keys.

An algorithm known as Batch-GCD makes it possible to compute the GCDs of a large set of numbers in a tractable way. It has become a standard technique in the cryptanalyst’s toolbox for investigating security of RSA keys. The birthday paradox makes it possible to quantify the frequency of these common factors, and they should be rare enough that this does not create a security risk. However, this assumes a good distribution of the generated prime numbers. That is why a bias in the key generation algorithm is fatal for the security of the key. Since 2012, several papers applied the method to keys found on the Internet and elsewhere resulting in tens of thousands of broken keys.

Here at Cryptosense we have a fast OCaml Batch-GCD implementation. To test it out, we downloaded a large number of public SSH keys from GitHub, which can be obtained from their API. We’ve informed GitHub of the results and will continue to update them. In recent days, results have emerged about the insecurity of some Github SSH keys for other reasons, so we felt the time was right to publish our findings.

TL;DR: Results

We found lots of small factors, then applied ECM factoring to the residues, resulting in a dozen fully factored 2048-bit keys and more than a hundred which are partially factored.

More details

Looking at the fully factored private keys, none of them were factored by a simple large shared prime. Instead, we typically found one or more small factors. After the first results, we started running trial division by the first 20 million primes. This resulted in a number of new factors. We then took the residues of the hundred or so moduli with one or more small factors, and applied elliptic curve factorisation à la Lenstra (we used the Zimmerman et al implementation). This has the specificity of finding the small factors first. So far 12 keys have succumbed to this method (that is, the remaining residue passes the Miller-Rabin primality test, so is almost certainly prime).

While there are valid reasons to use an RSA modulus consisting of the product of several large primes, in this case we found several small prime factors and one large one. Taken in context, this seems to indicate either a flawed key generator that is being used by a tiny number of people, or a corner-case flaw in a more widely used key generator that only exhibits itself very very rarely. It could also be something more banal like a corrupted single character somewhere in the base-64 encoding of the key. However, it’s impossible to identify how SSH keys were generated from the resulting public key, so for the moment we are in the dark. We have asked GitHub to help us contact the users to investigate this further. We will continue to update this post with further information.

Try Cryptosense Analyzer for Free

March 30, 2015

PKCS#11 Compliance Testing: Caml Crush

For the next instalment in our compliance testing series, we interviewed the creators of Caml Crush, an open source PKCS#11 project. Caml Crush is a filtering proxy that inserts itself between a PKCS#11 device and the calling application. As well as its inherent client/server architecture be it local or remote, Caml Crush can also apply filters which deal with some of the major security issues that affect PKCS#11 interfaces. We will take a look at how it works and how it affects the Compliance Checker results on a device.

The developers of Caml Crush (Ryad Benadjila, Thomas Calderon, and Marion Daubignard at the ANSSI) agree that “The PKCS#11 standard is not easy to use“, so how does Caml Crush help?

The filter

The filter that Caml Crush provides means that you can add restrictions and regulations to the commands or mechanisms that the device uses. For example, the filter can be configured to prevent the use of single-DES encryption and other insecure mechanisms. Other possibilities include segregating certain mechanisms or commands between the Security Officer and the User. To test the security of their filter configurations, the ANSSI team used Cryptosense Analyzer. A full description of their results appeared in a recent paper at the CARDIS conference. Upcoming packaged versions of Caml Crush for Fedora and Debian will ship with a “secure by default” configuration.

If the underlying PKCS#11 implementation has compliance errors, the filter won’t necessarily patch them. Our tests using our compliance checker with the filter and Opencryptoki bear this out. However, Caml Crush has an embedded plugin system which could be leveraged to address this.

Implementation advice

The producers of Caml Crush advise anyone implementing a PKCS#11 interface to “pay attention to all the footnotes – especially table 15.” as this can make the difference between a secure and a non-secure implementation. There are more than 200 footnotes in the standard.

Other ANSSI PKCS#11 Projects

Recently released on github, the opkcs11-tool provides handy low-level tools for working with PKCS#11 devices. It offers some functionality unavailable in other similar open source tools, like elliptic curve key generation, fine-grained management of object attributes, PSS and OAEP schemes.

Summary

The Caml Crush filter does a great job of adding an extra level of security to a device. To configure it to suit your application and key-management, the Cryptosense toolsuite is ideal.

If you would like your PKCS#11 project included in our series, get in touch.

Get our PKCS#11 Security Whitepaper

August 7, 2014

WebCrypto API Tracer

A tracer is a simple but important tool for auditing crypto security that allows the analyst to see the calls made by an application to a crypto interface. This is especially useful if the application and/or the crypto provider are only available in binary or black-box form (e.g. an HSM), but the crypto API is known. Even if source code is available, a simple tracer can save a lot of time compared to instrumenting code or manually setting trace points.

Recently we’ve been involved reviewing the draft W3C Web Crypto API. As a result of this and as part of our ongoing work on web crypto, our intern Gregoire put together a Chrome extension that traces calls to the WebCrypto API.

As you can see in the screenshots, a simple dropdown gives a list of all key objects in the session and their attributes.

key_view

Continue reading →

August 1, 2014

Cryptosense at the ICFP ML Workshop

As part of what some are describing as a fantastic programme, Thomas will present his work on well-typed smart fuzzing at the ICFP ML Workshop in Gothenburg in September. The smart fuzzing algorithm is a key part of the first phase of the Cryptosense test methodology. Read more about it here, or if you’re attending the ICFP workshops, why not ask for a demo – both Thomas and Romain will be there.

Try Cryptosense Analyzer for Free

July 21, 2014

Well-Typed Smart API Fuzzing

Since I joined Cryptosense in March, I’ve been working on a new implementation of the testing framework that we use to reverse-engineer cryptographic APIs. Last Friday, I gave a talk at the 7th Analysis of Security APIs workshop in Vienna where I explained some of the main ideas of this work. Here’s a high-level summary of my presentation.

When I arrived at Cryptosense I could see there had already been a huge investment in advancing the state of the art in automatic analysis of an API such as PKCS#11. The challenge was to generalise this tool to be able to test other crypto APIs in a scalable way, without reproducing all the effort.

Continue reading →

Search the Blog

Interested in Crypto News?

Article Categories

  • Archive (37)
  • Cloud Cryptography (11)
  • Crypto Agility (3)
  • Cryptographic Vulnerabilities (8)
  • Cryptography (66)
  • Cryptography Inventory (6)
  • Cryptosense Company News (18)
  • Encryption (8)
  • HSM Security (7)
  • Key Lifecycle Visibility (4)
  • Other (8)
  • Post-Quantum Cryptography Preparedness (1)
  • Products (24)
  • Security (83)
  • Tech (10)

Most Popular Posts

  • The End of Triple DES
  • BouncyCastle Keystore Security
  • Parameter choice for PBKDF2
  • How Ledger Hacked an HSM
  • New cryptography in .NET Core 3.0
  • Mighty Aphrodite - Dark Secrets of the Java Keystore
  • The Untold Story of PKCS#11 HSM Vulnerabilities
  • Algorithm Choice in PKCS#11 (part 5) - Block Cipher Modes
  • FedRAMP and FIPS 140-2 Cryptography
  • What is a Keyblock?
    • Solutions
      • Cryptosense Analyzer Platform
      • Cryptography Inventory
      • Secure Cloud Migrations
      • PKCS#11 Security Audit
      • Request Demo
    • Resources
      • Whitepapers
      • Webinars
      • Cloud Cryptography
      • Datasheets
      • Blog
      • Support
    • Company
      • About Us
      • Careers
      • Partners & Resellers
      • Contact

Follow us on Twitter FR: +33 (0)9 72 42 35 31 US: +1 646-893-7657

info@cryptosense.com

© 2012-2020 Cryptosense | All rights reserved.

  • Cryptosense Analyzer
  • Use Cases
  • Cloud Cryptography
  • Whitepapers
  • Webinars
  • About Us
  • Blog
  • Support
  • Contact
We use cookies to deliver our services. If you continue to use this site we assume you consent to our privacy policy.ACCEPTPrivacy policy