Project

General

Profile

Bug #872

Smartcard ECDSA authentication

Added by Luka Logar over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Category:
libstrongswan
Target version:
Start date:
04.03.2015
Due date:
Estimated time:
Affected version:
dr|rc|master
Resolution:
Fixed

Description

Hi, there is a compatibility issue between pkcs11 (at least when using opensc-pkcs11) and openssl plugins. The public EC point that is read from the smartcard (via the pkcs11 plugin) has extra octet string wrapper around it which openssl plugin doesn't understand. I've searched the net and there seems to be ambiguity how the ECPoint (according to the X9.62) should be encoded - with or without the extra octet string wrap. Apparently opensc-pkcs11 (and possibly other pkcs#11 providers) do it one way and openssl the other way.

This very ugly patch removes the leading octet string encoding and makes plugins work together:

--- a/src/libstrongswan/plugins/pkcs11/pkcs11_library.c
+++ b/src/libstrongswan/plugins/pkcs11/pkcs11_library.c
@@ -671,6 +671,16 @@ static bool get_attributes(object_enumer
     /* get the data */
     rv = this->lib->f->C_GetAttributeValue(this->session, object,
                                            this->attr, this->count);
+    // Make CKA_EC_POINT openssl compatible
+    for (i = 0; i < this->count; i++)
+    {
+        if ((this->attr[i].type == CKA_EC_POINT) && (this->attr[i].ulValueLen > 3))
+        {
+            this->attr[i].ulValueLen -= 2;
+            memmove((char*)this->attr[i].pValue + 1, (char*)this->attr[i].pValue + 3, this->attr[i].ulValueLen - 1);
+        }
+    }
+
     if (rv != CKR_OK)
     {
         free_attrs(this);
@@ -887,6 +897,14 @@ METHOD(pkcs11_library_t, get_ck_attribut
         chunk_free(data);
         return FALSE;
     }
+
+    // Make CKA_EC_POINT openssl compatible
+    if ((attr.type == CKA_EC_POINT) && (data->len > 3))
+    {
+        data->len -= 2;
+        memmove(data->ptr + 1, data->ptr + 3, data->len - 1);
+    }
+
     return TRUE;
 }

Best regards
Luka

Associated revisions

Revision 4aab3153 (diff)
Added by Tobias Brunner over 5 years ago

pkcs11: Properly handle EC_POINTs returned as ASN.1 octet string

This is the correct encoding but we internally only use unwrapped keys
and some tokens return them unwrapped.

Fixes #872.

Revision 8c9a0b5f (diff)
Added by Tobias Brunner over 5 years ago

pkcs11: Properly encode EC_POINTs created on a token

Some tokens might not fail when creating EC public keys in the incorrect
format, but they will later not be able to use them to verify signatures.

References #872.

History

#1 Updated by Tobias Brunner over 5 years ago

  • Tracker changed from Issue to Bug
  • Category set to libstrongswan
  • Status changed from New to Feedback
  • Assignee set to Tobias Brunner
  • Target version set to 5.3.0

Thanks for the report. According to PKCS#11 CKA_EC_POINT contains the "DER-encoding of the ANSI X9.62 ECPoint value Q". Since I don't have access to X9.62 I refer to RFC 5480, section 2.2, which shows that an ECPoint is in fact encoded as OCTET STRING. So what your token or OpenSC does is definitely correct.

But it seems the tokens we originally used when implementing ECDSA support did it incorrectly, so we should probably support both cases. At least when reading CKA_EC_POINT objects. When creating public key objects on a token, that is, if the use_pubkey option of the pkcs11 plugin is enabled, we don't really know which format the token expects, so I guess we just use the correct format for now (if there are still tokens around that expect the incorrect format we could add a strongswan.conf option later).

I pushed two fixes for this to the pkcs11-ecdsa branch.

#2 Updated by Tobias Brunner over 5 years ago

  • Status changed from Feedback to Closed
  • Resolution set to Fixed

Merged to master.

Also available in: Atom PDF