[strongSwan-dev] StrongSwan 5.0.4 and IAS/ECC smartcards

Martin Willi martin at strongswan.org
Mon Jun 17 09:57:24 CEST 2013

Hi Hugo,

> 1) Why does changing from IKEv1 to IKEv2 changes the mechanism used with
> the smartcard (RSA_PKCS to SHA1_RSA_PKCS)?

IKEv2 works differently than IKEv1 when signing data for authentication.
In IKEv1, you directly sign the output of the negotiated PRF using RSA.
With IKEv2, however, you always use SHA1 to hash some data, which then
gets wrapped into a digestInfo, then signed.

> 2) Would it be possible to change the source code and use RSA_PKCS (which
> works) in IKEv2, or it is not allowed for some reason by the protocol ?
>     If it can be used, are there any side effects on security ?

I think it would be possible to extend our pkcs11 plugin to do
digestInfo creation in strongSwan, and then just use the RSA_PKCS method
to sign that data. Ideally we would detect the supported mechanism list
of the smartcard, and use that fallback if the hashing schemes are not

Alternatively, it might be simpler to extend OpenSC and add support for
this scheme for your smartcard, even if this gets done in software.

> 3) How much time would it take to implement an additional mechanism in
> StrongSwan (ex. SHA256_RSA_PKCS) ?

I did some experiments with non-SHA1 signature schemes in [1] about a
year ago. There are two problems, though:

      * There is no way to negotiate signature schemes in IKEv2. So
        you'd have to guess what you can use (for example use the same
        scheme that is used in the certificate).
      * Detecting the signature scheme has to be done in the public key
        backend, as the OID is in the signature. This requires
        significant changes in all of our public key backends to detect
        and return the used signature scheme. This might be non-trivial,
        or not even possible on some backends.

Of course you can hardcode a different signature scheme than SHA1. But
it is probably not a very good idea, given that RFC 5996 says you SHOULD
support SHA1.

Bringing support for proper signature scheme detection is more difficult
and requires changes in all public key backends.



More information about the Dev mailing list