Re: [opensc-devel] Clarification of OpenSC capabilities regarding hardware operations.
On Apr 1, 2010, at 23:59 , Martin Paljak wrote: > Hello, > > PKCS#11 is an API for cryptographic devices that perform cryptographic > operations. > The API itself does not mandate the use of hardware (in fact, there are > several competing software PKCS#11 modules) but in the context of OpenSC, a > smart card library, it is obvious that the interface provided by OpenSC deals > exclusively with smart cards. > It would be reasonable to expect that all of the operations exposed via > PKCS#11 take place inside the security boundaries of the cryptographic smart > card module. > > Most of the time, if smart cards are used, they are used because they can > generate keys on the card that never leave the card. Sometimes pre-generated > keys are loaded to smart cards for transportation or use. But usually smart > cards are used for security reasons and the only security smart cards provide > is the physical and logical access control to the plaintext key material. > > OpenSC has currently a very lax implementation of the actual functionality as > well as for the flags that should signal the difference. These flags are: > (from PKCS#15) native, sensitive, extractable, alwaysSensitive, > neverExtractable and local > > related PKCS#11 functions: > C_WrapKey > C_UnwrapKey > > and usage flags: wrap, unwrap > and also includes transparent key generation in software. Here's a first bunch that removes software key generation. What is changed: * pkcs15-init: remove the possibility to generate keys in the software * PKCS#11: get rid of software secret keys and remove everything related to C_UnwrapKey * PKCS#11: Remove software key generation when generating keypairs hardware-only.diff Description: Binary data Correcting different flags in different cases still needs testing with different tools and different profiles and scenarios. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Clarification of OpenSC capabilities regarding hardware operations.
On Apr 2, 2010, at 11:33 , Anders Rundgren wrote: > Hi, > > I thought that the main point with SCP (Secure Channel Protocol) was for > performing secure (end-to-end) card initialization and updates. Yes, that is one option. But not related to what I'm trying to achieve (that with whatever type of card connections no key material exists/is created in plaintext outside of the smart card unless asked explicitly by the caller of OpenSC PKCS#11 module or command line utility) What I was talking about has zero relation to secure messaging. I want to: - remove code from OpenSC that deals with key generation (key generation has to be done by some other tool) - remove code that creates keys as session objects in software (unless required by some application) - add code that can wrap/unwrap keys inside hardware, for supported cards. - make sure that extractable/native/local/sensitive flags actually represent reality OpenSC deals with smart cards which usually means keys generated onboard of a smart card. Plaintext key material should never be created by OpenSC code and only exist if explicitly given as input argument or asked by some software (exportable keys). > Since SCP > works on the APDU-level I have some difficulties understanding how you > make it useful from PKCS #11 since the mapping is not one-to-one. Secure messaging is currently not implemented in OpenSC, if you have questions/thoughts/ideas/proposals on how this could be done, feel free to voice in! > Other ref: > http://technet.microsoft.com/en-us/library/cc708681(WS.10).aspx Uh. I don't want to write XML to exchange APDU-s, no thanks (like http://www.codeproject.com/KB/smart/SmartcardFmwk.aspx ) I'm not a believer in the "look, don't have to write code, just xml!" cult. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Clarification of OpenSC capabilities regarding hardware operations.
Hi, I thought that the main point with SCP (Secure Channel Protocol) was for performing secure (end-to-end) card initialization and updates. Since SCP works on the APDU-level I have some difficulties understanding how you make it useful from PKCS #11 since the mapping is not one-to-one. Other ref: http://technet.microsoft.com/en-us/library/cc708681(WS.10).aspx Anders - Original Message - From: "Martin Paljak" To: "Anders Rundgren" Cc: "OpenSC-devel (opensc-devel)" Sent: Friday, April 02, 2010 10:10 Subject: Re: [opensc-devel] Clarification of OpenSC capabilities regarding hardware operations. On Apr 2, 2010, at 10:00 , Anders Rundgren wrote: > Hi, > How does GlobalPlatform's SCP fits into this picture? If you mean GP secure channel then it does not relate to this problem, AFAIK, at least not directly. If the channel is set up between two hardware modules then it would matter. For "casual pc usage" the endpoint of the the channel would be a casual PC ? m. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Clarification of OpenSC capabilities regarding hardware operations.
Anders Rundgren wrote: > Hi, > How does GlobalPlatform's SCP fits into this picture? > IMHO, GP SCP is not related this subject; roughly, SCP is secure transport layer at the APDUs level. > Anders > > Martin Paljak wrote: > >> Hello, >> >> PKCS#11 is an API for cryptographic devices that perform cryptographic >> operations. >> The API itself does not mandate the use of hardware (in fact, there are >> several competing software PKCS#11 modules) but in the context of OpenSC, a >> smart card library, it is obvious that the interface provided by OpenSC >> deals exclusively with smart cards. >> It would be reasonable to expect that all of the operations exposed via >> PKCS#11 take place inside the security boundaries of the cryptographic smart >> card module. >> >> Most of the time, if smart cards are used, they are used because they can >> generate keys on the card that never leave the card. Sometimes pre-generated >> keys are loaded to smart cards for transportation or use. But usually smart >> cards are used for security reasons and the only security smart cards >> provide is the physical and logical access control to the plaintext key >> material. >> >> OpenSC has currently a very lax implementation of the actual functionality >> as well as for the flags that should signal the difference. These flags are: >> (from PKCS#15) native, sensitive, extractable, alwaysSensitive, >> neverExtractable and local >> >> related PKCS#11 functions: >> C_WrapKey >> C_UnwrapKey >> >> and usage flags: wrap, unwrap >> and also includes transparent key generation in software. >> >> To make it clear and meet the expectations of the user, I would like to >> suggest to remove all code from OpenSC that would generate or reveal >> plaintext key material in software, outside the smart card. If keys are to >> be generated somewhere else and transfered in plaintext, then there are >> tools that can do it (like openssl genrsa) and OpenSC can limit itself to >> implementing only functionality that really deals with the smart card, >> inside the crypto module. >> >> In addition to my interest in using key wrapping functionality I found the >> code behind pkcs15-init --extractable and --insecure somewhat odd. >> >> What do you think? >> Nice intention. Kind wishes, Viktor. > > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Clarification of OpenSC capabilities regarding hardware operations.
On Apr 2, 2010, at 10:00 , Anders Rundgren wrote: > Hi, > How does GlobalPlatform's SCP fits into this picture? If you mean GP secure channel then it does not relate to this problem, AFAIK, at least not directly. If the channel is set up between two hardware modules then it would matter. For "casual pc usage" the endpoint of the the channel would be a casual PC ? m. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Clarification of OpenSC capabilities regarding hardware operations.
Hi, How does GlobalPlatform's SCP fits into this picture? Anders Martin Paljak wrote: > Hello, > > PKCS#11 is an API for cryptographic devices that perform cryptographic > operations. > The API itself does not mandate the use of hardware (in fact, there are > several competing software PKCS#11 modules) but in the context of OpenSC, a > smart card library, it is obvious that the interface provided by OpenSC deals > exclusively with smart cards. > It would be reasonable to expect that all of the operations exposed via > PKCS#11 take place inside the security boundaries of the cryptographic smart > card module. > > Most of the time, if smart cards are used, they are used because they can > generate keys on the card that never leave the card. Sometimes pre-generated > keys are loaded to smart cards for transportation or use. But usually smart > cards are used for security reasons and the only security smart cards provide > is the physical and logical access control to the plaintext key material. > > OpenSC has currently a very lax implementation of the actual functionality as > well as for the flags that should signal the difference. These flags are: > (from PKCS#15) native, sensitive, extractable, alwaysSensitive, > neverExtractable and local > > related PKCS#11 functions: > C_WrapKey > C_UnwrapKey > > and usage flags: wrap, unwrap > and also includes transparent key generation in software. > > To make it clear and meet the expectations of the user, I would like to > suggest to remove all code from OpenSC that would generate or reveal > plaintext key material in software, outside the smart card. If keys are to be > generated somewhere else and transfered in plaintext, then there are tools > that can do it (like openssl genrsa) and OpenSC can limit itself to > implementing only functionality that really deals with the smart card, inside > the crypto module. > > In addition to my interest in using key wrapping functionality I found the > code behind pkcs15-init --extractable and --insecure somewhat odd. > > What do you think? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Clarification of OpenSC capabilities regarding hardware operations.
Hello, PKCS#11 is an API for cryptographic devices that perform cryptographic operations. The API itself does not mandate the use of hardware (in fact, there are several competing software PKCS#11 modules) but in the context of OpenSC, a smart card library, it is obvious that the interface provided by OpenSC deals exclusively with smart cards. It would be reasonable to expect that all of the operations exposed via PKCS#11 take place inside the security boundaries of the cryptographic smart card module. Most of the time, if smart cards are used, they are used because they can generate keys on the card that never leave the card. Sometimes pre-generated keys are loaded to smart cards for transportation or use. But usually smart cards are used for security reasons and the only security smart cards provide is the physical and logical access control to the plaintext key material. OpenSC has currently a very lax implementation of the actual functionality as well as for the flags that should signal the difference. These flags are: (from PKCS#15) native, sensitive, extractable, alwaysSensitive, neverExtractable and local related PKCS#11 functions: C_WrapKey C_UnwrapKey and usage flags: wrap, unwrap and also includes transparent key generation in software. To make it clear and meet the expectations of the user, I would like to suggest to remove all code from OpenSC that would generate or reveal plaintext key material in software, outside the smart card. If keys are to be generated somewhere else and transfered in plaintext, then there are tools that can do it (like openssl genrsa) and OpenSC can limit itself to implementing only functionality that really deals with the smart card, inside the crypto module. In addition to my interest in using key wrapping functionality I found the code behind pkcs15-init --extractable and --insecure somewhat odd. What do you think? -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
