• 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
October 20, 2015

PKCS#11 Functionality Reports

When choosing an HSM or Smartcard to act as crypto provider for a PKCS#11 application, it’s important that the provider actually supports the specific cryptographic algorithms (or “mechanisms” in PKCS#11 terminology) required for the commands that the application will use. What’s more, if the device offers insecure mechanisms, an attacker might make use of them to compromise data. There are 224 mechanisms and 54 commands in v2.20 of the standard. How can I find out which ones a specific device implements?

To help with this problem we’ve added a functionality summary to the PKCS#11 compliance reports produced by our software. The output is designed to look like the “Mechanisms vs Functions” table (table 34 in v2.20) of the standard which shows which mechanisms are considered valid for each command. In our table, a cross indicates that we were able to use the mechanism in that row successfully for the command in that column.  

Updated March 2018

Functionality reports now feature in the stats output of Cryptosense Analyzer for all APIs, including PKCS#11. Try it out on your device.

Try Cryptosense Analyzer for Free

Get our PKCS#11 Security Whitepaper

 

 

October 16, 2015

The UBS Future of Finance Challenge

Cryptosense has been selected as a regional finalist in the UBS Future of Finance Challenge. Our entry was chosen from amongst 600 entries to take part in the regional final in London in November. The Challenge is a global competition to find entrepreneurs, start-ups or growing companies that could change the way finance works and how banks meet their client’s needs.

You can read more about the UBS Future of Finance Challenge here.


 

FFC_Logo_RegionalFinalist_blue

Update

We were one of the three winners of the London final.

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 →

July 16, 2015

Five reasons to upgrade to PKCS#11 v2.40

In April 2015, following its transfer to OASIS, the PKCS#11 standard for device crypto APIs got its first official update in ten years. There is always some lag time between a new standard and vendor adoption. Here are five good reasons you should be nagging your crypto hardware vendor to upgrade:

Comparing v2.40 to v2.20
  1. Authenticated Encryption
  2. One thing we learned since the last version of PKCS#11 is that Authenticated Encryption (AE) is not just a fancy crypto nicety, it’s a security necessity for almost any serious application. While you can build your own authenticated encryption from old PKCS#11 modes (here is one interesting way to do it), it’s simpler and more error-resistant to use a dedicated AE mode. PKCS#11 v2.40 contains two of these, GCM (as used, for example, in TLS) and CCM (as used in many embedded devices).

  3. MACs that are secure for variable-length messages
  4. The original PKCS#11 contained MAC modes that were used in the financial sector in applications where every message was a fixed-length block. Unfortunately, these modes give no guarantee of security if message length is variable. PKCS#11 v2.40 contains mechanisms like CMAC which are secure in the variable-length setting.

  5. PBKDF2 with SHA-512
  6. Password-based key derivation functions (PBKDFs) are often used to store passwords in a secure way by hashing and salting them. The idea of a good PBKDF is that it requires enough computational resource to calculate that a realistic adversary will not be able to brute-force guess your password if he obtains the hashed and salted version. PKCS#11 v2.20 only supported PBKDF2 with the SHA-1 hash, which is no longer a good choice for this application, since advances notably in hardware-based hash crackers have made brute-force guessing these passwords much more feasible. PKCS#11 v2.40 supports SHA-512 (and SHA-256) for PBKDF2, which makes these attacks much harder.

  7. Less legacy stuff
  8. A large amount of ancient cryptographic mechanisms like SKIPJACK and FASTHASH as well as broken functions like MD5 have been removed from the “current mechanisms” list. This should mean less chance of an error by an unwary programmer. However, take care, there are still insecure mechanisms in the list, like RSA PKCS#1v1.5 Encryption (recently removed from both TLS and the W3C Web Crypto API).

  9. CKA_COPYABLE and CKA_DESTROYABLE
  10. Two new attributes in PKCS#11 give you more fine-tuned control over key-management by marking keys that may be duplicated or deleted. Careful how you use them, though. Our Analyzer tool can help understand the security consequences of attribute configuration.

    Conclusion

    PKCS#11 v2.40 is a big step forward. If you want your crypto infrastructure to be secure, you should ask your vendor about their upgrade plans.

    Try Cryptosense Analyzer for Free

    Get our PKCS#11 Security Whitepaper

June 17, 2015

Cryptosense Software Finds Key-Disabling Bug in Thales HSM

The latest firmware update (v11.72) for the Thales eSecurity-nCipher net HSM includes a fix for a security issue found by the Cryptosense PKCS#11 compliance tester.

While using our software to test one of our clients’ HSMs, we discovered a bug that allowed an innocent-looking PKCS#11 command to set all the permission attributes on a private key to FALSE. Since these attributes include CKA_MODIFIABLE, this is a permanent change, and since CKA_EXTRACTABLE is set to false, the key can’t be exported and copied. All the cryptographic usage flags such as CKA_SIGN and CKA_DECRYPT are also set to FALSE, rendering the key unusable for any operation.

Since these devices are often used, for example, by Certification Authorities or in other similar signing applications where availability is critical, our clients considered this a serious issue, so we signalled it to Thales who included a fix in their most recent update. We’d recommend all Thales-nCipher HSM users to install the fix as soon as possible.

Over the next few weeks and months, we’ll be featuring more highlights of the results from our compliance tester on the blog . In the meantime, if you’d like to try a demo of the Analyzer, get in touch.

 

Try Cryptosense Analyzer for Free

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

May 5, 2015

Would you hire a Professional Hacker?

This question is the subject of a podcast interview with Cryptosense founder, Graham Steel, in which he talks to Karen Webster, CEO of PYMTS.com.

Cryptosense software can be described as an ‘automated hacker’, capable of systematically searching hardware configurations, software and APIs to find security flaws.

Automated hacking is a subject of particular interest to banks, whose security critical data is worth a huge amount of money to malicious hackers. Many banks are now realizing that the cost of hiring a friendly automated hacker is a great way to reduce the risk of data loss and make it easier to pass security audits.

Listen to the podcast on PYMTS.com.

May 1, 2015

Finding Flaws in Cryptography – IEEE S&P Article

Growth in cloud computing, smartphone use and interconnected devices means that even more of our private data is now at risk from hackers. Cryptography is being used more and more to secure this data, however it is notoriously hard to implement correctly.

Developers and hardware manufacturers are now looking for automated ways to test that their cryptography is as secure as they need it to be. Software packages such as Cryptosense’s Analyzer are at the forefront of automated crypto analysis.

As an expert in the field of automated crypto analysis, Cryptosense founder Graham Steel has been invited by IEEE to write an article in their journal Security & Privacy about this growing area of formal analysis.

Read the full article.

Purchase a copy of the journal.

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

February 4, 2015

Cryptosense PKCS#11 Compliance Testing: Opencryptoki

Update March 2018

Since we wrote this post our compliance criteria have been extended to over 100 covering PKCS#11 v2.40 and used to find a host of issues with live HSMs.

Original post:

Recently we’ve been trying out our PKCS#11 compliance tester on a number of open-source PKCS#11 implementations. We’ll be publishing the results here over the next few weeks, as well as sending the reports from our tools to the project developers. First up: Opencryptoki and its PKCS#11 software token.

Continue reading →

  • 1
  • 2
  • 3
  • 4

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