openssh unix dev - Sep 2015 - [PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent

Hi,

I have made a patch for enabling the use of ECDSA keys in the PKCS#11
support of ssh-agent which will be of interest to other users.

I have tested it with P-256 keys. P-384 and P-521 should work
out-of-the box. The code is ready for non-FIPS curves (named or
explicit), but OpenSSH currently limits ECDSA to those 3 curves.

At high level it works like the support for RSA, but because of
differences in OpenSSL between RSA and EC_KEY, implementation has a
few differences. The RSA and RSA_METHOD structures are exposed and the
existing ssh-pkcs11 code uses that to create an RSA_METHOD object for
each key.

Because of APIs (in addition to ECDSA support) needed by the patch
this currently works with:

- LibreSSL >= 2.2.2: until LibreSSL 2.1.2 (which is the what I am
  testing for), the ECDSA_METHOD structure was defined in a private
  header. But the LIBRESSL_VERSION_NUMBER constant was not updated
  until 2.2.2.

- OpenSSL >= 1.0.2: creating your own ECDSA_METHOD is not possible
  before because the ECDSA_METHOD structure if opacified. In OpenSSL
  1.0.2, they added the option to create new ECDSA_METHOD object if
  this is detectable with the ECDSA_F_ECDSA_METHOD_NEW define.

A few notes to understand the patch:

- A few places assumed RSA keys, I added a key type field and use it
  to handle the differences. I also renamed some function to reflect
  their link to RSA.

- I moved some code out of pkcs11_rsa_private_encrypt into a separate
  function pkcs11_login to share it with pkcs11_ecdsa_sign

- For EC_KEY, the pointer to the struct pkcs11_key object is not in
  the method but in the EC_KEY itself using ECDSA_set_ex_data and
  ECDSA_set_ex_data. This allows having a single ECDSA_METHOD for
  all keys.

- Unlike the RSA_METHOD, ECDSA_METHOD does not include a "finish"
  method to clean up the associated data. This was only a problem for
  ssh-pkcs11-helper.c that called key_free on struct sshkey objects
  created by ssh-pkcs11.c. To work around that I added a function
  pkcs11_del_key(struct sshkey *) to the list of functions exported by
  ssh-pkcs11.c that allows us to properly clean up ECDSA keys.

I tried to:
- be as consistent as possible with the RSA part,
- minimize the size of the patch and the number of locations,
- document some of the additional quirks specific to ECDSA.

I added this patch and text as
https://bugzilla.mindrot.org/show_bug.cgi?id=2474

Sincerely,
-- 
Mathias Brossard

Mathias Brossard <mathias at brossard.org> writes:
> Hi,
>
> I have made a patch for enabling the use of ECDSA keys in the PKCS#11
> support of ssh-agent which will be of interest to other users.
Nice!  What would it take to add support for Ed25519 too?  Do we need to
allocate any new PKCS#11 identifiers?  The Gnuk smartcard supports
Ed25519 but I don't know if it is common to use it with OpenSSH through
PKCS#11 (I would expect it to be used with OpenSSH through GnuPG's
gpg-agent).  At least it might be useful as a test case.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151008/011a5f2c/attachment.bin>

On 10/8/2015 4:49 AM, Simon Josefsson wrote:
> Mathias Brossard <mathias at brossard.org> writes:
>
>> Hi,
>>
>> I have made a patch for enabling the use of ECDSA keys in the PKCS#11
>> support of ssh-agent which will be of interest to other users.
>
> Nice!  What would it take to add support for Ed25519 too?  Do we need to
> allocate any new PKCS#11 identifiers?
Yes, and PKCS#11 allows for *_VENDOR_SUPPLIED identifiers. But using these can
get out of hand. Best to try and get them in the standard. OASIS controls the
standard From 14 April 2015:

  http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.html

2.40 does not define Ed25519.
> The Gnuk smartcard supports
> Ed25519 but I don't know if it is common to use it with OpenSSH through
> PKCS#11 (I would expect it to be used with OpenSSH through GnuPG's
> gpg-agent).  At least it might be useful as a test case.
>
> /Simon
>
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
-- 

  Douglas E. Engert  <DEEngert at gmail.com>

On Thu, Oct 8, 2015 at 2:49 AM, Simon Josefsson <simon at josefsson.org>
wrote:
> Mathias Brossard <mathias at brossard.org> writes:
> > I have made a patch for enabling the use of ECDSA keys in the PKCS#11
> > support of ssh-agent which will be of interest to other users.
>
> Nice!  What would it take to add support for Ed25519 too?  Do we need to
> allocate any new PKCS#11 identifiers?  The Gnuk smartcard supports
> Ed25519 but I don't know if it is common to use it with OpenSSH through
> PKCS#11 (I would expect it to be used with OpenSSH through GnuPG's
> gpg-agent).  At least it might be useful as a test case.
>
This raises a lot of different questions. I'll try to be brief and not too
controversial
(so I'll skip the PKCS#11 in GnuPG question).

PKCS#11 is the standard API to access smartcards and if you want, for
instance,
browsers to support Ed25519 for TLS authentication (I'm sure you're
familiar with
https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-02), this will be a
necessary
step.

For supporting Ed25519 in ssh-agent through PKCS#11, it should be possible
using the same path as my ECDSA patch. The current implementation for
PKCS#11 uses OpenSSL as scaffolding and essentially overloads the signing
method with its own.

Now the question becomes how should Ed25519 on PKCS#11. I hadn't subscribed
to the mailing list so I missed a few mails.

The key type CKK_ECDSA has been renamed CKK_EC and
CKA_ECDSA_PARAMS is now CKA_EC_PARAMS, which I take is a signal from
the PKCS#11 TC to say that if you can fit into this framework, you are
encouraged
to do so. For CKA_EC_PARAMS, using named curves is definitely the preferred
way to do it.

For the mechanism I can not pretend to be well versed in EdDSA, but
signature
seems to return a (R,s) tuple. So application could possibly be using
CKM_ECDSA to minimize the number of execution paths (and distinguish with
CKA_EC_PARAMS if necessary). A technical problem might come up, or it might
be judged by the PKCS#11 TC to be too confusing, so a switch to CKM_EDDSA
(or CKM_EC_EDDSA).

As a first step and while the RFCs and TCs are assigning new magic values, I
would suggest:
- CKA_KEY_TYPE: CKK_EC
- CKA_EC_PARAMS: 1.3.6.1.4.1.11591.15.1
- CKA_ALLOWED_MECHANISMS: [ CKM_ECDSA ]

If adding Ed25559 support in PKCS#11 is in the work for the (OpenSC or
otherwise), I could help adding the support to ssh-agent.

Sincerely,
-- 
Mathias Brossard

On Mon, Sep 28, 2015 at 1:17 AM, Mathias Brossard <mathias at
brossard.org>
wrote:
> I have made a patch for enabling the use of ECDSA keys in the PKCS#11
> support of ssh-agent which will be of interest to other users.
>
> I have tested it with P-256 keys. P-384 and P-521 should work
> out-of-the box. The code is ready for non-FIPS curves (named or
> explicit), but OpenSSH currently limits ECDSA to those 3 curves.
>
I've now been able to test the patch with 2 different smart-cards with
P-256 and a software token with P-256, P-384 and P-521.

> I added this patch and text as
> https://bugzilla.mindrot.org/show_bug.cgi?id=2474
>
The patch has been updated in the ticket with two bugs fixed.

Sincerely,
-- 
Mathias Brossard