Discussion about OpenSC broken PKCS#11 compliance

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Discussion about OpenSC broken PKCS#11 compliance

Thomas Calderon
Hi all,

I would like to start a new discussion related to how OpenSC complies or rather do not complies with the PKCS#11 standard.

I understand the need for a multi-card support and appreciate the community effort that has been put towards supporting so many cards.
However, I feel that there is are numerous outstanding issues in the way OpenSC is designed.

First, the current pkcs11.h in OpenSC is a "custom" version derived from a draft of the standard. PKCS#11 v2.20 is long published and was amended 3 times already.
Second, the way OpenSC handles the card provisioning is broken. Let's take an example for IAS-ECC cards.

Suppose you want to inject a Private Key object on the token, but you want to restrict the key usage for this private key. You can do so using PKCS#11 attributes such as : 
  - CKA_SIGN
  - CKA_SIGN_RECOVER
  - CKA_DECRYPT
  - CKA_UNWRAP

Now, you only need this key for signing, therefore the PKCS#11 template you will use within your code will set CKA_SIGN=TRUE and other attributes to FALSE. The OpenSC object creation code will ignore your "least" privilege policy and enable all key usage for this key.
This is bad but there is worse. Since this key was generated "off-board", the PKCS#11 standards mandates that the CKA_LOCAL attribute should be set to FALSE. OpenSC hard-code this value to TRUE, thus lying to client applications !
Other important values such as CKA_ALWAYS_SENSITIVE and CKA_NEVER_EXTRACTABLE are wrongly set in this case.

The "on-board" generation code is also doing dirty tricks behing your back. First the requested PKCS#11 attributes are mapped to an X509 representation and mapped again to PKCS#15 attributes. During this process you loose some granularity on the attributes you required. For instance, request an "on-board" key pair generation for a "signing" key (CKA_SIGN=TRUE, rest to FALSE). Because of this double attribute mapping dance you end up with a private key with CKA_SIGN and CKA_SIGN_RECOVER set to TRUE although you set up CKA_SIGN_RECOVER to FALSE.

As a last example, there is not point in setting CKA_WRAP/CKA_UNWRAP to TRUE if the C_Wrap/C_Unwrap functions are not supported. Those should be the ones hard-coded to FALSE !

Is increased PKCS#11 compliance part of the OpenSC roadmap ?


Feedback appreciated.

Regards,

Thomas C.

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Discussion about OpenSC broken PKCS#11 compliance

Douglas E Engert


On 10/15/2014 9:20 AM, Thomas Calderon wrote:

> Hi all,
>
> I would like to start a new discussion related to how OpenSC complies or rather do not complies with the PKCS#11 standard.
>
> I understand the need for a multi-card support and appreciate the community effort that has been put towards supporting so many cards.
> However, I feel that there is are numerous outstanding issues in the way OpenSC is designed.
>
> First, the current pkcs11.h in OpenSC is a "custom" version derived from a draft of the standard. PKCS#11 v2.20 is long published and was amended 3 times already.
> Second, the way OpenSC handles the card provisioning is broken. Let's take an example for IAS-ECC cards.
>
> Suppose you want to inject a Private Key object on the token, but you want to restrict the key usage for this private key. You can do so using PKCS#11 attributes such as :
>    - CKA_SIGN
>    - CKA_SIGN_RECOVER
>    - CKA_DECRYPT
>    - CKA_UNWRAP
>
> Now, you only need this key for signing, therefore the PKCS#11 template you will use within your code will set CKA_SIGN=TRUE and other attributes to FALSE. The OpenSC object creation code will ignore
> your "least" privilege policy and enable all key usage for this key.
> This is bad but there is worse. Since this key was generated "off-board", the PKCS#11 standards mandates that the CKA_LOCAL attribute should be set to FALSE. OpenSC hard-code this value to TRUE, thus
> lying to client applications !
> Other important values such as CKA_ALWAYS_SENSITIVE and CKA_NEVER_EXTRACTABLE are wrongly set in this case.
>
> The "on-board" generation code is also doing dirty tricks behing your back. First the requested PKCS#11 attributes are mapped to an X509 representation and mapped again to PKCS#15 attributes. During
> this process you loose some granularity on the attributes you required. For instance, request an "on-board" key pair generation for a "signing" key (CKA_SIGN=TRUE, rest to FALSE). Because of this
> double attribute mapping dance you end up with a private key with CKA_SIGN and CKA_SIGN_RECOVER set to TRUE although you set up CKA_SIGN_RECOVER to FALSE.
>
> As a last example, there is not point in setting CKA_WRAP/CKA_UNWRAP to TRUE if the C_Wrap/C_Unwrap functions are not supported. Those should be the ones hard-coded to FALSE !
>
> Is increased PKCS#11 compliance part of the OpenSC roadmap ?

The standard answer, is yes, if you are willing to submit code...

This should also have to include PKCS#15 code to store and read the flags on the cards.
It looks like the bits you are interested in are in the PKCS#15, and as best as I can tell,
it is not implemented.

KeyAccessFlags ::= BIT STRING {
        sensitive (0),
        extractable (1),
        alwaysSensitive (2),
        neverExtractable (3),
        local (4)
        }

>
>
> Feedback appreciated.
>
> Regards,
>
> Thomas C.
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Discussion about OpenSC broken PKCS#11 compliance

helpcrypto helpcrypto
Hi Thomas.


I'll dare to say "everyone in here want to be more Pkcs#11/15 compliant".

Hence, my suggestion is, as we can see you have some knowledge about Pkcs#11 and OpenSC source, to fill separate bug for each problem, incompatibility or issue you detect. That, at least, will let everyone know where the isses are.

Regards.



On Wed, Oct 15, 2014 at 11:43 PM, Douglas E Engert <[hidden email]> wrote:


On 10/15/2014 9:20 AM, Thomas Calderon wrote:
> Hi all,
>
> I would like to start a new discussion related to how OpenSC complies or rather do not complies with the PKCS#11 standard.
>
> I understand the need for a multi-card support and appreciate the community effort that has been put towards supporting so many cards.
> However, I feel that there is are numerous outstanding issues in the way OpenSC is designed.
>
> First, the current pkcs11.h in OpenSC is a "custom" version derived from a draft of the standard. PKCS#11 v2.20 is long published and was amended 3 times already.
> Second, the way OpenSC handles the card provisioning is broken. Let's take an example for IAS-ECC cards.
>
> Suppose you want to inject a Private Key object on the token, but you want to restrict the key usage for this private key. You can do so using PKCS#11 attributes such as :
>    - CKA_SIGN
>    - CKA_SIGN_RECOVER
>    - CKA_DECRYPT
>    - CKA_UNWRAP
>
> Now, you only need this key for signing, therefore the PKCS#11 template you will use within your code will set CKA_SIGN=TRUE and other attributes to FALSE. The OpenSC object creation code will ignore
> your "least" privilege policy and enable all key usage for this key.
> This is bad but there is worse. Since this key was generated "off-board", the PKCS#11 standards mandates that the CKA_LOCAL attribute should be set to FALSE. OpenSC hard-code this value to TRUE, thus
> lying to client applications !
> Other important values such as CKA_ALWAYS_SENSITIVE and CKA_NEVER_EXTRACTABLE are wrongly set in this case.
>
> The "on-board" generation code is also doing dirty tricks behing your back. First the requested PKCS#11 attributes are mapped to an X509 representation and mapped again to PKCS#15 attributes. During
> this process you loose some granularity on the attributes you required. For instance, request an "on-board" key pair generation for a "signing" key (CKA_SIGN=TRUE, rest to FALSE). Because of this
> double attribute mapping dance you end up with a private key with CKA_SIGN and CKA_SIGN_RECOVER set to TRUE although you set up CKA_SIGN_RECOVER to FALSE.
>
> As a last example, there is not point in setting CKA_WRAP/CKA_UNWRAP to TRUE if the C_Wrap/C_Unwrap functions are not supported. Those should be the ones hard-coded to FALSE !
>
> Is increased PKCS#11 compliance part of the OpenSC roadmap ?

The standard answer, is yes, if you are willing to submit code...

This should also have to include PKCS#15 code to store and read the flags on the cards.
It looks like the bits you are interested in are in the PKCS#15, and as best as I can tell,
it is not implemented.

KeyAccessFlags ::= BIT STRING {
        sensitive (0),
        extractable (1),
        alwaysSensitive (2),
        neverExtractable (3),
        local (4)
        }

>
>
> Feedback appreciated.
>
> Regards,
>
> Thomas C.
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Discussion about OpenSC broken PKCS#11 compliance

Anders Rundgren-2
In reply to this post by Thomas Calderon
On 2014-10-15 16:20, Thomas Calderon wrote:
> Hi all,

IMO, it is pointless upgrading the provisioning scheme since this only
works for very limited card deployments.  Nobody (in their right mind...),
use PKCS #11 for card provisioning.  Maybe you are rather thinking of
HSM-usages?

Anders

>
> I would like to start a new discussion related to how OpenSC complies or rather do not complies with the PKCS#11 standard.
>
> I understand the need for a multi-card support and appreciate the community effort that has been put towards supporting so many cards.
> However, I feel that there is are numerous outstanding issues in the way OpenSC is designed.
>
> First, the current pkcs11.h in OpenSC is a "custom" version derived from a draft of the standard. PKCS#11 v2.20 is long published and was amended 3 times already.
> Second, the way OpenSC handles the card provisioning is broken. Let's take an example for IAS-ECC cards.
>
> Suppose you want to inject a Private Key object on the token, but you want to restrict the key usage for this private key. You can do so using PKCS#11 attributes such as :
>    - CKA_SIGN
>    - CKA_SIGN_RECOVER
>    - CKA_DECRYPT
>    - CKA_UNWRAP
>
> Now, you only need this key for signing, therefore the PKCS#11 template you will use within your code will set CKA_SIGN=TRUE and other attributes to FALSE. The OpenSC object creation code will ignore your "least" privilege policy and enable all key usage for this key.
> This is bad but there is worse. Since this key was generated "off-board", the PKCS#11 standards mandates that the CKA_LOCAL attribute should be set to FALSE. OpenSC hard-code this value to TRUE, thus lying to client applications !
> Other important values such as CKA_ALWAYS_SENSITIVE and CKA_NEVER_EXTRACTABLE are wrongly set in this case.
>
> The "on-board" generation code is also doing dirty tricks behing your back. First the requested PKCS#11 attributes are mapped to an X509 representation and mapped again to PKCS#15 attributes. During this process you loose some granularity on the attributes you required. For instance, request an "on-board" key pair generation for a "signing" key (CKA_SIGN=TRUE, rest to FALSE). Because of this double attribute mapping dance you end up with a private key with CKA_SIGN and CKA_SIGN_RECOVER set to TRUE although you set up CKA_SIGN_RECOVER to FALSE.
>
> As a last example, there is not point in setting CKA_WRAP/CKA_UNWRAP to TRUE if the C_Wrap/C_Unwrap functions are not supported. Those should be the ones hard-coded to FALSE !
>
> Is increased PKCS#11 compliance part of the OpenSC roadmap ?
>
>
> Feedback appreciated.
>
> Regards,
>
> Thomas C.
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Discussion about OpenSC broken PKCS#11 compliance

helpcrypto helpcrypto
I use PKCS#11 for card provisioning for my "old legacy not cryptogrtaphic not using opensc card".

OpenSC should be standard compliant, and use CKR_FUNCTION_NOT_SUPPORTED if needed.

On Thu, Oct 16, 2014 at 9:46 AM, Anders Rundgren <[hidden email]> wrote:
On 2014-10-15 16:20, Thomas Calderon wrote:
> Hi all,

IMO, it is pointless upgrading the provisioning scheme since this only
works for very limited card deployments.  Nobody (in their right mind...),
use PKCS #11 for card provisioning.  Maybe you are rather thinking of
HSM-usages?

Anders

>
> I would like to start a new discussion related to how OpenSC complies or rather do not complies with the PKCS#11 standard.
>
> I understand the need for a multi-card support and appreciate the community effort that has been put towards supporting so many cards.
> However, I feel that there is are numerous outstanding issues in the way OpenSC is designed.
>
> First, the current pkcs11.h in OpenSC is a "custom" version derived from a draft of the standard. PKCS#11 v2.20 is long published and was amended 3 times already.
> Second, the way OpenSC handles the card provisioning is broken. Let's take an example for IAS-ECC cards.
>
> Suppose you want to inject a Private Key object on the token, but you want to restrict the key usage for this private key. You can do so using PKCS#11 attributes such as :
>    - CKA_SIGN
>    - CKA_SIGN_RECOVER
>    - CKA_DECRYPT
>    - CKA_UNWRAP
>
> Now, you only need this key for signing, therefore the PKCS#11 template you will use within your code will set CKA_SIGN=TRUE and other attributes to FALSE. The OpenSC object creation code will ignore your "least" privilege policy and enable all key usage for this key.
> This is bad but there is worse. Since this key was generated "off-board", the PKCS#11 standards mandates that the CKA_LOCAL attribute should be set to FALSE. OpenSC hard-code this value to TRUE, thus lying to client applications !
> Other important values such as CKA_ALWAYS_SENSITIVE and CKA_NEVER_EXTRACTABLE are wrongly set in this case.
>
> The "on-board" generation code is also doing dirty tricks behing your back. First the requested PKCS#11 attributes are mapped to an X509 representation and mapped again to PKCS#15 attributes. During this process you loose some granularity on the attributes you required. For instance, request an "on-board" key pair generation for a "signing" key (CKA_SIGN=TRUE, rest to FALSE). Because of this double attribute mapping dance you end up with a private key with CKA_SIGN and CKA_SIGN_RECOVER set to TRUE although you set up CKA_SIGN_RECOVER to FALSE.
>
> As a last example, there is not point in setting CKA_WRAP/CKA_UNWRAP to TRUE if the C_Wrap/C_Unwrap functions are not supported. Those should be the ones hard-coded to FALSE !
>
> Is increased PKCS#11 compliance part of the OpenSC roadmap ?
>
>
> Feedback appreciated.
>
> Regards,
>
> Thomas C.
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Discussion about OpenSC broken PKCS#11 compliance

Thomas Calderon
I agree.
If OpenSC was not supposed to provision cards using PKCS#11 then why provide "pkcs11-tool" with object generation/creation capabilities. The code is here and some portions of it are non-compliant, it would be best to overhaul it.

Furthermode, I have to stress out that the issues I reported also affect general behavior and is not limited to card provisioning ("lying" on object locality). Fixing those issues has to be done to avoid breaking client applications.

I will do my best to isolate non-compliant behaviors and report them using the bugtracker, at least for IAS-ECC cards. Whenever possible, I will submit a patch.
However, this is a complex task, proportionate to the various cards supported by OpenSC.


On Thu, Oct 16, 2014 at 10:01 AM, helpcrypto helpcrypto <[hidden email]> wrote:
I use PKCS#11 for card provisioning for my "old legacy not cryptogrtaphic not using opensc card".

OpenSC should be standard compliant, and use CKR_FUNCTION_NOT_SUPPORTED if needed.

On Thu, Oct 16, 2014 at 9:46 AM, Anders Rundgren <[hidden email]> wrote:
On 2014-10-15 16:20, Thomas Calderon wrote:
> Hi all,

IMO, it is pointless upgrading the provisioning scheme since this only
works for very limited card deployments.  Nobody (in their right mind...),
use PKCS #11 for card provisioning.  Maybe you are rather thinking of
HSM-usages?

Anders

>
> I would like to start a new discussion related to how OpenSC complies or rather do not complies with the PKCS#11 standard.
>
> I understand the need for a multi-card support and appreciate the community effort that has been put towards supporting so many cards.
> However, I feel that there is are numerous outstanding issues in the way OpenSC is designed.
>
> First, the current pkcs11.h in OpenSC is a "custom" version derived from a draft of the standard. PKCS#11 v2.20 is long published and was amended 3 times already.
> Second, the way OpenSC handles the card provisioning is broken. Let's take an example for IAS-ECC cards.
>
> Suppose you want to inject a Private Key object on the token, but you want to restrict the key usage for this private key. You can do so using PKCS#11 attributes such as :
>    - CKA_SIGN
>    - CKA_SIGN_RECOVER
>    - CKA_DECRYPT
>    - CKA_UNWRAP
>
> Now, you only need this key for signing, therefore the PKCS#11 template you will use within your code will set CKA_SIGN=TRUE and other attributes to FALSE. The OpenSC object creation code will ignore your "least" privilege policy and enable all key usage for this key.
> This is bad but there is worse. Since this key was generated "off-board", the PKCS#11 standards mandates that the CKA_LOCAL attribute should be set to FALSE. OpenSC hard-code this value to TRUE, thus lying to client applications !
> Other important values such as CKA_ALWAYS_SENSITIVE and CKA_NEVER_EXTRACTABLE are wrongly set in this case.
>
> The "on-board" generation code is also doing dirty tricks behing your back. First the requested PKCS#11 attributes are mapped to an X509 representation and mapped again to PKCS#15 attributes. During this process you loose some granularity on the attributes you required. For instance, request an "on-board" key pair generation for a "signing" key (CKA_SIGN=TRUE, rest to FALSE). Because of this double attribute mapping dance you end up with a private key with CKA_SIGN and CKA_SIGN_RECOVER set to TRUE although you set up CKA_SIGN_RECOVER to FALSE.
>
> As a last example, there is not point in setting CKA_WRAP/CKA_UNWRAP to TRUE if the C_Wrap/C_Unwrap functions are not supported. Those should be the ones hard-coded to FALSE !
>
> Is increased PKCS#11 compliance part of the OpenSC roadmap ?
>
>
> Feedback appreciated.
>
> Regards,
>
> Thomas C.
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel



------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Discussion about OpenSC broken PKCS#11 compliance

Anders Rundgren-2
In reply to this post by helpcrypto helpcrypto
On 2014-10-16 10:01, helpcrypto helpcrypto wrote:
> I use PKCS#11 for card provisioning for my "old legacy not cryptogrtaphic not using opensc card".

I'm sure about that, I just questioned the value in updating a dated system for supporting
legacy cards.  But of course if somebody is interested in taking on this job which
probably is a true nightmare given the variance in cards, please don't let me hinder you :-)

http://fidoalliance.org/membership/members

The smart card industry is entering a rocky phase, where Google and Apple
have the momentum.  There's no PKCS #11 on this road AFAIK.

Anders

>
> OpenSC should be standard compliant, and use CKR_FUNCTION_NOT_SUPPORTED if needed.
>
> On Thu, Oct 16, 2014 at 9:46 AM, Anders Rundgren <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 2014-10-15 16:20, Thomas Calderon wrote:
>     > Hi all,
>
>     IMO, it is pointless upgrading the provisioning scheme since this only
>     works for very limited card deployments.  Nobody (in their right mind...),
>     use PKCS #11 for card provisioning.  Maybe you are rather thinking of
>     HSM-usages?
>
>     Anders
>
>      >
>      > I would like to start a new discussion related to how OpenSC complies or rather do not complies with the PKCS#11 standard.
>      >
>      > I understand the need for a multi-card support and appreciate the community effort that has been put towards supporting so many cards.
>      > However, I feel that there is are numerous outstanding issues in the way OpenSC is designed.
>      >
>      > First, the current pkcs11.h in OpenSC is a "custom" version derived from a draft of the standard. PKCS#11 v2.20 is long published and was amended 3 times already.
>      > Second, the way OpenSC handles the card provisioning is broken. Let's take an example for IAS-ECC cards.
>      >
>      > Suppose you want to inject a Private Key object on the token, but you want to restrict the key usage for this private key. You can do so using PKCS#11 attributes such as :
>      >    - CKA_SIGN
>      >    - CKA_SIGN_RECOVER
>      >    - CKA_DECRYPT
>      >    - CKA_UNWRAP
>      >
>      > Now, you only need this key for signing, therefore the PKCS#11 template you will use within your code will set CKA_SIGN=TRUE and other attributes to FALSE. The OpenSC object creation code will ignore your "least" privilege policy and enable all key usage for this key.
>      > This is bad but there is worse. Since this key was generated "off-board", the PKCS#11 standards mandates that the CKA_LOCAL attribute should be set to FALSE. OpenSC hard-code this value to TRUE, thus lying to client applications !
>      > Other important values such as CKA_ALWAYS_SENSITIVE and CKA_NEVER_EXTRACTABLE are wrongly set in this case.
>      >
>      > The "on-board" generation code is also doing dirty tricks behing your back. First the requested PKCS#11 attributes are mapped to an X509 representation and mapped again to PKCS#15 attributes. During this process you loose some granularity on the attributes you required. For instance, request an "on-board" key pair generation for a "signing" key (CKA_SIGN=TRUE, rest to FALSE). Because of this double attribute mapping dance you end up with a private key with CKA_SIGN and CKA_SIGN_RECOVER set to TRUE although you set up CKA_SIGN_RECOVER to FALSE.
>      >
>      > As a last example, there is not point in setting CKA_WRAP/CKA_UNWRAP to TRUE if the C_Wrap/C_Unwrap functions are not supported. Those should be the ones hard-coded to FALSE !
>      >
>      > Is increased PKCS#11 compliance part of the OpenSC roadmap ?
>      >
>      >
>      > Feedback appreciated.
>      >
>      > Regards,
>      >
>      > Thomas C.
>      >
>      >
>      > ------------------------------------------------------------------------------
>      > Comprehensive Server Monitoring with Site24x7.
>      > Monitor 10 servers for $9/Month.
>      > Get alerted through email, SMS, voice calls or mobile push notifications.
>      > Take corrective actions from your mobile device.
>      > http://p.sf.net/sfu/Zoho
>      >
>      >
>      >
>      > _______________________________________________
>      > Opensc-devel mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>      >
>
>
>     ------------------------------------------------------------------------------
>     Comprehensive Server Monitoring with Site24x7.
>     Monitor 10 servers for $9/Month.
>     Get alerted through email, SMS, voice calls or mobile push notifications.
>     Take corrective actions from your mobile device.
>     http://p.sf.net/sfu/Zoho
>     _______________________________________________
>     Opensc-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel