Updated march 2018
Since we wrote this post three years ago, several HSMs have added support for modern elliptic curves like curve25519. The yet-to-be-finalised PKCS#11v3.0 will likely have a number of new algorithms using this curve and variationsOriginal post:If you read the last post about choice of key lengths in PKCS#11, you may have been struck by the fact that the recommended key lengths for RSA, if you want to be secure in the future, are rather long. This is one of several reasons for moving to elliptic curve cryptography. But which curve to choose?
It turns out choosing a secure curve for use in PKCS#11 is not easy. First, unlike with other mechanisms, PKCS#11 doesn't actually specify exactly what curves can or should be supported. It provides a means for specifying domain parameters (following ANSI X9.62), but you will have to find out which curves your PKCS#11 device actually supports. Then you are left with the general problem of choosing a secure curve, which, taking into account that it's a highly technical subject and that fact that, post-Snowden, few of us would trust NIST/NSA to choose a curve for us, is not an easy business. For example, the CFRG was tasked to choose new curves for use in TLS about a year ago and has still not quite decided.
One strategy would be to take a look at what your provider offers, and compare it to the list at safecurves.cr.yp.to. However, we've yet to see a PKCS#11 implementation of one of the curves considered fully "safe" there (if you have one, get in touch and we'll update the post). The NIST and Brainpool curves have most support, but both of these are currently "unfashionable", in the sense of not having known practical attacks but being viewed with a certain amount of suspicion. Unfortunately, if you need a PKCS#11 curve now, you are most likely stuck with one of them.
Read our PKCS#11 white paper for more information.