opensc-devel — discussion of developement of OpenSC and related projects

[Opensc-devel] OpenSC at FOSDEM 2018

[Jakub J. <jj...@re...>]

Hello there,
this year I am going to FOSDEM and I will have a talk about Smart
Cards, OpenSC and friends [1]. If you want to hear it, meet me in
person or discuss something, let me know.

[1] https://fosdem.org/2018/schedule/event/smartcards_in_linux/

See you in Brussels,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.

Re: [Opensc-devel] OpenSC and Yubikey 4 (OpenPGP)

[Douglas E E. <dee...@gm...>]

I opened an issue yesterday on this:
  https://github.com/OpenSC/OpenSC/issues/1230

Can you try the simple fix in:
  https://github.com/OpenSC/OpenSC/issues/1230#issuecomment-354787390

This would show it the problem is in just the select file vs select AID
or if more is needed.



On 1/2/2018 9:37 AM, Jakub Jelen wrote:
> On Sun, 2017-12-31 at 14:56 +0100, Grzegorz Kulewski wrote:
>> I saw that issue before. Thank you for looking into it.
>>
>> What is the easiest/best way to disable PIV for now in the config
>> file?
> 
> Hello.
> The referenced issue is from my point of view about consecutive usage
> of OpenPGP card and PIV at the same time from PKCS#11 and PGP directly.
> 
> This question looks more like if we can access the OpenPGP card on
> yubikey using OpenSC.
> 
> We have a openpgp driver and if we adjust the driver priority using
> card_drivers in /etc/opensc.conf, we should achieve this.
> 
> But it does not work for me and I am not able to make the OpenSC detect
> the OpenPGP applet over PKCS#11 (with OpenSC 0.17.0). I don't have a
> lot of experience with OpenPGP, but it might be the case that the
> driver does not support the version on yubikey or the vice versa. The
> debug log should say more.
> 
> Regards,
> Jakub
> 
>> W dniu 31.12.2017 o 14:41, Douglas E Engert pisze:
>>> You may want to read this issue and the comment:
>>> https://github.com/OpenSC/OpenSC/issues/953#issuecomment-353591483
>>>
>>> The main problem comes from having two applets on the same card
>>> that can not both be active
>>> at the same time because they interfere with each other and lose
>>> the login state or two different applications
>>> try to have exclusive access to the card and lock each other out
>>> for long periods. Which makes it
>>> impossible to get the serial number or determine if the applet even
>>> exists or is being used.
>>>
>>> Yubico could have solved this by treating the PGP and PIV apps as
>>> separate USB devices on the same Yubikey.
>>> They already emulate multiple USB devices but all the CCID applets
>>> look like they are on the same device.
>>> Best I can tell U2F does not use CCID so to the OS the Yubikey
>>> looks like multiple devices and U2F can work
>>> independently from the PIV or PGP.
>>>
>>> Right now OpenSC does not have a good way to determine which applet
>>> the user wants to use, PIV or PGP,
>>> other then to turn off one of the drivers in the opensc.conf file.
>>> Right now, if there is a PIV applet
>>> It is selected.
>>>
>>> As I said in https://github.com/OpenSC/OpenSC/issues/953#issuecomme
>>> nt-353591483
>>> I am going to look at what it would take to change the PIV driver
>>> to see if the PIV applet looks
>>> like it is active i.e. has some certificate or other indication
>>> that it is initialized. If not, then
>>> let the PGP driver have a look at it. OR use environment variable
>>> to say which one to select. OR see
>>> if both the PIV and PGP applets could be selected within OpenSC and
>>> present then as multiple slots to PKCS#11.
>>>
>>> The Yubikey is the only device I know of that has two applets
>>> OpenSC can support and OpenSC only selects one.
>>>
>>>
>>>
>>> On 12/30/2017 6:25 PM, Grzegorz Kulewski wrote:
>>>> Hello,
>>>>
>>>> Excuse me if it was answered before but I can't find it anywhere.
>>>> Also excuse my ignorance in SC standards and protocols.
>>>>
>>>> I think that OpenSC supports normal OpenPGP cards for some time,
>>>> directly, without software like scute. For example there is
>>>> openpgp-tool and with opensc-pkcs11.so programs like Firefox can
>>>> access OpenPGP card as a key/cert store for TLS client
>>>> certificate auth.
>>>>
>>>> Yubikey 4 is supposed to emulate OpenPGP card (and support other
>>>> protocols, including PIV and U2F). But openpgp-tool doesn't seem
>>>> to work with Yubikey 4 and opensc-pkcs11.so loaded in Firefox
>>>> seems to only discover PIV side of Yubikey 4. Also https://github
>>>> .com/sektioneins/micro-ca-tool does not seem to talk with Yubikey
>>>> 4, probably because OpenSC doesn't recognize it as OpenPGP card.
>>>>
>>>> Since in our organization we care about compatibility with
>>>> "normal" OpenPGP cards, we want to configure OpenSC to support
>>>> Yubikey 4 as a normal OpenPGP card (in addition or instead of
>>>> PIV). Is it possible? If not: why? If yes: how?
>>
>>

-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] OpenSC and Yubikey 4 (OpenPGP)

[Jakub J. <jj...@re...>]

On Sun, 2017-12-31 at 14:56 +0100, Grzegorz Kulewski wrote:
> I saw that issue before. Thank you for looking into it.
> 
> What is the easiest/best way to disable PIV for now in the config
> file?

Hello.
The referenced issue is from my point of view about consecutive usage
of OpenPGP card and PIV at the same time from PKCS#11 and PGP directly.

This question looks more like if we can access the OpenPGP card on
yubikey using OpenSC.

We have a openpgp driver and if we adjust the driver priority using
card_drivers in /etc/opensc.conf, we should achieve this.

But it does not work for me and I am not able to make the OpenSC detect
the OpenPGP applet over PKCS#11 (with OpenSC 0.17.0). I don't have a
lot of experience with OpenPGP, but it might be the case that the
driver does not support the version on yubikey or the vice versa. The
debug log should say more.

Regards,
Jakub

> W dniu 31.12.2017 o 14:41, Douglas E Engert pisze:
> > You may want to read this issue and the comment:
> > https://github.com/OpenSC/OpenSC/issues/953#issuecomment-353591483
> > 
> > The main problem comes from having two applets on the same card
> > that can not both be active
> > at the same time because they interfere with each other and lose
> > the login state or two different applications
> > try to have exclusive access to the card and lock each other out
> > for long periods. Which makes it
> > impossible to get the serial number or determine if the applet even
> > exists or is being used.
> > 
> > Yubico could have solved this by treating the PGP and PIV apps as
> > separate USB devices on the same Yubikey.
> > They already emulate multiple USB devices but all the CCID applets
> > look like they are on the same device.
> > Best I can tell U2F does not use CCID so to the OS the Yubikey
> > looks like multiple devices and U2F can work
> > independently from the PIV or PGP.
> > 
> > Right now OpenSC does not have a good way to determine which applet
> > the user wants to use, PIV or PGP,
> > other then to turn off one of the drivers in the opensc.conf file.
> > Right now, if there is a PIV applet
> > It is selected.
> > 
> > As I said in https://github.com/OpenSC/OpenSC/issues/953#issuecomme
> > nt-353591483
> > I am going to look at what it would take to change the PIV driver
> > to see if the PIV applet looks
> > like it is active i.e. has some certificate or other indication
> > that it is initialized. If not, then
> > let the PGP driver have a look at it. OR use environment variable
> > to say which one to select. OR see
> > if both the PIV and PGP applets could be selected within OpenSC and
> > present then as multiple slots to PKCS#11.
> > 
> > The Yubikey is the only device I know of that has two applets
> > OpenSC can support and OpenSC only selects one.
> > 
> > 
> > 
> > On 12/30/2017 6:25 PM, Grzegorz Kulewski wrote:
> > > Hello,
> > > 
> > > Excuse me if it was answered before but I can't find it anywhere.
> > > Also excuse my ignorance in SC standards and protocols.
> > > 
> > > I think that OpenSC supports normal OpenPGP cards for some time,
> > > directly, without software like scute. For example there is
> > > openpgp-tool and with opensc-pkcs11.so programs like Firefox can
> > > access OpenPGP card as a key/cert store for TLS client
> > > certificate auth.
> > > 
> > > Yubikey 4 is supposed to emulate OpenPGP card (and support other
> > > protocols, including PIV and U2F). But openpgp-tool doesn't seem
> > > to work with Yubikey 4 and opensc-pkcs11.so loaded in Firefox
> > > seems to only discover PIV side of Yubikey 4. Also https://github
> > > .com/sektioneins/micro-ca-tool does not seem to talk with Yubikey
> > > 4, probably because OpenSC doesn't recognize it as OpenPGP card.
> > > 
> > > Since in our organization we care about compatibility with
> > > "normal" OpenPGP cards, we want to configure OpenSC to support
> > > Yubikey 4 as a normal OpenPGP card (in addition or instead of
> > > PIV). Is it possible? If not: why? If yes: how?
> 
> 
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.

Re: [Opensc-devel] OpenSC and Yubikey 4 (OpenPGP)

[Grzegorz K. <gk...@le...>]

I saw that issue before. Thank you for looking into it.

What is the easiest/best way to disable PIV for now in the config file?


W dniu 31.12.2017 o 14:41, Douglas E Engert pisze:
> You may want to read this issue and the comment:
> https://github.com/OpenSC/OpenSC/issues/953#issuecomment-353591483
> 
> The main problem comes from having two applets on the same card that can not both be active
> at the same time because they interfere with each other and lose the login state or two different applications
> try to have exclusive access to the card and lock each other out for long periods. Which makes it
> impossible to get the serial number or determine if the applet even exists or is being used.
> 
> Yubico could have solved this by treating the PGP and PIV apps as separate USB devices on the same Yubikey.
> They already emulate multiple USB devices but all the CCID applets look like they are on the same device.
> Best I can tell U2F does not use CCID so to the OS the Yubikey looks like multiple devices and U2F can work
> independently from the PIV or PGP.
> 
> Right now OpenSC does not have a good way to determine which applet the user wants to use, PIV or PGP,
> other then to turn off one of the drivers in the opensc.conf file. Right now, if there is a PIV applet
> It is selected.
> 
> As I said in https://github.com/OpenSC/OpenSC/issues/953#issuecomment-353591483
> I am going to look at what it would take to change the PIV driver to see if the PIV applet looks
> like it is active i.e. has some certificate or other indication that it is initialized. If not, then
> let the PGP driver have a look at it. OR use environment variable to say which one to select. OR see
> if both the PIV and PGP applets could be selected within OpenSC and present then as multiple slots to PKCS#11.
> 
> The Yubikey is the only device I know of that has two applets OpenSC can support and OpenSC only selects one.
> 
> 
> 
> On 12/30/2017 6:25 PM, Grzegorz Kulewski wrote:
>> Hello,
>>
>> Excuse me if it was answered before but I can't find it anywhere. Also excuse my ignorance in SC standards and protocols.
>>
>> I think that OpenSC supports normal OpenPGP cards for some time, directly, without software like scute. For example there is openpgp-tool and with opensc-pkcs11.so programs like Firefox can access OpenPGP card as a key/cert store for TLS client certificate auth.
>>
>> Yubikey 4 is supposed to emulate OpenPGP card (and support other protocols, including PIV and U2F). But openpgp-tool doesn't seem to work with Yubikey 4 and opensc-pkcs11.so loaded in Firefox seems to only discover PIV side of Yubikey 4. Also https://github.com/sektioneins/micro-ca-tool does not seem to talk with Yubikey 4, probably because OpenSC doesn't recognize it as OpenPGP card.
>>
>> Since in our organization we care about compatibility with "normal" OpenPGP cards, we want to configure OpenSC to support Yubikey 4 as a normal OpenPGP card (in addition or instead of PIV). Is it possible? If not: why? If yes: how?

-- 
Grzegorz Kulewski

Re: [Opensc-devel] OpenSC and Yubikey 4 (OpenPGP)

[Douglas E E. <dee...@gm...>]

You may want to read this issue and the comment:
https://github.com/OpenSC/OpenSC/issues/953#issuecomment-353591483

The main problem comes from having two applets on the same card that can not both be active
at the same time because they interfere with each other and lose the login state or two different applications
try to have exclusive access to the card and lock each other out for long periods. Which makes it
impossible to get the serial number or determine if the applet even exists or is being used.

Yubico could have solved this by treating the PGP and PIV apps as separate USB devices on the same Yubikey.
They already emulate multiple USB devices but all the CCID applets look like they are on the same device.
Best I can tell U2F does not use CCID so to the OS the Yubikey looks like multiple devices and U2F can work
independently from the PIV or PGP.

Right now OpenSC does not have a good way to determine which applet the user wants to use, PIV or PGP,
other then to turn off one of the drivers in the opensc.conf file. Right now, if there is a PIV applet
It is selected.

As I said in https://github.com/OpenSC/OpenSC/issues/953#issuecomment-353591483
I am going to look at what it would take to change the PIV driver to see if the PIV applet looks
like it is active i.e. has some certificate or other indication that it is initialized. If not, then
let the PGP driver have a look at it. OR use environment variable to say which one to select. OR see
if both the PIV and PGP applets could be selected within OpenSC and present then as multiple slots to PKCS#11.

The Yubikey is the only device I know of that has two applets OpenSC can support and OpenSC only selects one.



On 12/30/2017 6:25 PM, Grzegorz Kulewski wrote:
> Hello,
> 
> Excuse me if it was answered before but I can't find it anywhere. Also excuse my ignorance in SC standards and protocols.
> 
> I think that OpenSC supports normal OpenPGP cards for some time, directly, without software like scute. For example there is openpgp-tool and with opensc-pkcs11.so programs like Firefox can access OpenPGP card as a key/cert store for TLS client certificate auth.
> 
> Yubikey 4 is supposed to emulate OpenPGP card (and support other protocols, including PIV and U2F). But openpgp-tool doesn't seem to work with Yubikey 4 and opensc-pkcs11.so loaded in Firefox seems to only discover PIV side of Yubikey 4. Also https://github.com/sektioneins/micro-ca-tool does not seem to talk with Yubikey 4, probably because OpenSC doesn't recognize it as OpenPGP card.
> 
> Since in our organization we care about compatibility with "normal" OpenPGP cards, we want to configure OpenSC to support Yubikey 4 as a normal OpenPGP card (in addition or instead of PIV). Is it possible? If not: why? If yes: how?
> 
> Thank you in advance.
> 

-- 

  Douglas E. Engert  <DEE...@gm...>

[Opensc-devel] OpenSC and Yubikey 4 (OpenPGP)

[Grzegorz K. <gk...@le...>]

Hello,

Excuse me if it was answered before but I can't find it anywhere. Also excuse my ignorance in SC standards and protocols.

I think that OpenSC supports normal OpenPGP cards for some time, directly, without software like scute. For example there is openpgp-tool and with opensc-pkcs11.so programs like Firefox can access OpenPGP card as a key/cert store for TLS client certificate auth.

Yubikey 4 is supposed to emulate OpenPGP card (and support other protocols, including PIV and U2F). But openpgp-tool doesn't seem to work with Yubikey 4 and opensc-pkcs11.so loaded in Firefox seems to only discover PIV side of Yubikey 4. Also https://github.com/sektioneins/micro-ca-tool does not seem to talk with Yubikey 4, probably because OpenSC doesn't recognize it as OpenPGP card.

Since in our organization we care about compatibility with "normal" OpenPGP cards, we want to configure OpenSC to support Yubikey 4 as a normal OpenPGP card (in addition or instead of PIV). Is it possible? If not: why? If yes: how?

Thank you in advance.

-- 
Grzegorz Kulewski

[Opensc-devel] OpenSCToken: Use OpenSC in CryptoTokenKit

[Frank M. <fra...@gm...>]

With https://github.com/frankmorgner/OpenSCToken, OpenSC can now also be
used in CryptoTokenKit. See also https://github.com/OpenSC/OpenSC/pull/1179.

Regards, Frank.

2017-10-12 9:45 GMT+02:00 Ludovic Rousseau <lud...@gm...>:

> 2017-10-12 3:12 GMT+02:00 Matthew X. Economou <xen...@ir...>:
>
>> Actually, why doesn't the macOS installer disable pivtoken itself?  Does
>> disabling that break something else?
>>
>
> You may want to use the pivtoken provided by Apple to use with your PIV
> card and use OpenSC for a non-PIV card (maybe disabled PIV support from
> OpenSC).
>
> I think that OpenSC does not yet provide a CryptoTokenKit Smart Card
> Driver, but just a tokend (old technology). So using the Apple pivtoken may
> be better for some user.
>
> Bye
>
> --
>  Dr. Ludovic Rousseau
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>

[Opensc-devel] ENGINE_by_id creates ENGINE with load_ssl_client_cert = null

[Leszek K. <kos...@gm...>]

Hi everyone,

When I execute ENGINE_by_id ('pkcs11') I get a ENGINE structure where
load_ssl_client_cert (ENGINE_SSL_CLIENT_CERT_PTR type) is null.
I'm using Gemalto and Athena cards.

Is this behavior related to a card or a pkcs11 engine?

This is a problem because calling SSL_CTX_set_client_cert_engine and
ENGINE_load_ssl_client_cert calls AV in libeay32.dll.

How can I write my own function load_ssl_client_cert?

Regards
Leszek Kosowski

Re: [Opensc-devel] Removing engine_pkcs11 repository

[NdK <ndk...@gm...>]

Il 26/10/2017 16:35, Michał Trojnara ha scritto:

> People seem to use the code regardless of README.md...
> I don't want to confuse them.
What about adding a line like:
#error "libp11 should be used instead -- see README.md !"
somewhere in the code?

BYtE,
 Diego

Re: [Opensc-devel] Removing engine_pkcs11 repository

[Michał T. <Mic...@st...>]

On 10/26/2017 01:12 PM, Frank Morgner wrote:
> Please do not remove the repository; instead add a new commit that
> deletes all files and states in Readme.md that libp11 should be used.

Good point.  This is exactly what I'll do.

On 10/26/2017 01:30 PM, Ludovic Rousseau wrote:
> Why do you want to remove the project?

People seem to use the code regardless of README.md...
I don't want to confuse them.

Best regards,
	Dr. Michal Trojnara

Re: [Opensc-devel] Removing engine_pkcs11 repository

[Ludovic R. <lud...@gm...>]

2017-10-26 12:41 GMT+02:00 Michał Trojnara <Mic...@st...>:

> Hi Guys,
>

Hello,


> Could someone with appropriate privileges please remove
> https://github.com/OpenSC/engine_pkcs11 ?
>

Why do you want to remove the project?

The README.md
<https://github.com/OpenSC/engine_pkcs11/blob/master/README.md> explicitly
says we keep it on purpose:
" The engine_pkcs11 library has been merged into
https://github.com/OpenSC/libp11 version 0.4.0 and later. For the time
being, this repository is left intact to retain the history of changes
before made prior to the merge. "

Bye

-- 
 Dr. Ludovic Rousseau

[Opensc-devel] Removing engine_pkcs11 repository

[Michał T. <Mic...@st...>]

Hi Guys,

Could someone with appropriate privileges please remove
https://github.com/OpenSC/engine_pkcs11 ?

This code has been merged into https://github.com/OpenSC/libp11 in March
2016, where it is supported ever since.

TIA,
	Mike

Re: [Opensc-devel] new AK910 reader spotted

[Umberto R. a. U. <op...@gt...>]

Sorry, wrong list.
I just posted this one to the PCSC-Muscle list

On 10/20/2017 03:22 PM, Umberto Rustichelli aka Ubi wrote:
> Dear developers,
>
> I just stumbled on a smart card reader that should be an AK910, that 
> is packed with a hub plus storage, I think it would be a good thing to 
> have it supported.
>
> The seller page is https://www.pec.it/cns-arubakey.aspx (sorry, 
> language is Italian).
>
> The vendorID:deviceID are 2021:0002 (I see CCID has provisions for 
> 0001, 0011 and 0101 but not 0002).
>
>
> This is what I read in the logs at insertion time:
>
> Oct 20 16:39:40 pes-app-blank-01 kernel: usb 1-11: new high speed USB 
> device number 12 using xhci_hcd
> Oct 20 16:39:40 pes-app-blank-01 kernel: usb 1-11: New USB device 
> found, idVendor=058f, idProduct=6254
> Oct 20 16:39:40 pes-app-blank-01 kernel: usb 1-11: New USB device 
> strings: Mfr=0, Product=0, SerialNumber=0
> Oct 20 16:39:40 pes-app-blank-01 kernel: usb 1-11: configuration #1 
> chosen from 1 choice
> Oct 20 16:39:40 pes-app-blank-01 kernel: hub 1-11:1.0: USB hub found
> Oct 20 16:39:40 pes-app-blank-01 kernel: hub 1-11:1.0: 4 ports detected
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: new high speed 
> USB device number 13 using xhci_hcd
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: New USB device 
> found, idVendor=1307, idProduct=0165
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: New USB device 
> strings: Mfr=1, Product=2, SerialNumber=3
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: Product: USB Mass 
> Storage Device
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: Manufacturer: 
> USBest Technology
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: SerialNumber: 
> 000000000002BA
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: configuration #1 
> chosen from 1 choice
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: new full speed 
> USB device number 14 using xhci_hcd
> Oct 20 16:39:41 pes-app-blank-01 kernel: Initializing USB Mass Storage 
> driver...
> Oct 20 16:39:41 pes-app-blank-01 kernel: scsi7 : SCSI emulation for 
> USB Mass Storage devices
> Oct 20 16:39:41 pes-app-blank-01 kernel: usbcore: registered new 
> interface driver usb-storage
> Oct 20 16:39:41 pes-app-blank-01 kernel: USB Mass Storage support 
> registered.
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: New USB device 
> found, idVendor=2021, idProduct=0002
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: New USB device 
> strings: Mfr=1, Product=2, SerialNumber=0
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: Product: HKey
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: Manufacturer: AK910
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: configuration #1 
> chosen from 1 choice
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: ep 0x2 - rounding 
> interval to 64 microframes, ep desc says 80 microframes
> Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: ep 0x82 - 
> rounding interval to 64 microframes, ep desc says 80 microframes
> Oct 20 16:39:41 pes-app-blank-01 kernel: generic-usb 
> 0003:2021:0002.0001: hiddev96,hidraw0: USB HID v1.00 Device [AK910 
> HKey] on usb-0000:00:14.0-11.2/input0
> Oct 20 16:39:42 pes-app-blank-01 kernel: scsi 7:0:0:0: 
> Direct-Access                               0.00 PQ: 0 ANSI: 2
> Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: Attached scsi 
> generic sg2 type 0
> Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: [sdb] 1972744 
> 512-byte logical blocks: (1.01 GB/963 MiB)
> Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: [sdb] Write 
> Protect is off
> Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: [sdb] Assuming 
> drive cache: write through
> Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: [sdb] Assuming 
> drive cache: write through
> Oct 20 16:39:42 pes-app-blank-01 kernel: sdb:
> Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: [sdb] Assuming 
> drive cache: write through
> Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: [sdb] Attached 
> SCSI removable disk
>
>
> This is the lsusb output:
>
>
>
> Bus 001 Device 013: ID 2021:0002
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               1.10
>   bDeviceClass            0 (Defined at Interface level)
>   bDeviceSubClass         0
>   bDeviceProtocol         0
>   bMaxPacketSize0         8
>   idVendor           0x2021
>   idProduct          0x0002
>   bcdDevice            1.00
>   iManufacturer           1 AK910
>   iProduct                2 HKey
>   iSerial                 0
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           41
>     bNumInterfaces          1
>     bConfigurationValue     1
>     iConfiguration          0
>     bmAttributes         0x80
>       (Bus Powered)
>     MaxPower              100mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass         3 Human Interface Device
>       bInterfaceSubClass      0 No Subclass
>       bInterfaceProtocol      0 None
>       iInterface              0
>         HID Device Descriptor:
>           bLength                 9
>           bDescriptorType        33
>           bcdHID               1.00
>           bCountryCode            0 Not supported
>           bNumDescriptors         1
>           bDescriptorType        34 Report
>           wDescriptorLength      34
>          Report Descriptors:
>            ** UNAVAILABLE **
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x02  EP 2 OUT
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval              10
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x82  EP 2 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval              10
> Device Status:     0x0000
>   (Bus Powered)
>
> Best regards
>
>     Umberto Rustichelli
>
>
>
> ------------------------------------------------------------------------------ 
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
> -- 
> Questo messaggio e' stato analizzato con Libra ESVA ed e' risultato 
> non infetto.
> Seguire il link qui sotto per segnalarlo come spam: 
> https://esva.gt50.org/cgi-bin/learn-msg.cgi?id=37626400C3.AB22C
>
>

[Opensc-devel] new AK910 reader spotted

[Umberto R. a. U. <op...@gt...>]

Dear developers,

I just stumbled on a smart card reader that should be an AK910, that is 
packed with a hub plus storage, I think it would be a good thing to have 
it supported.

The seller page is https://www.pec.it/cns-arubakey.aspx (sorry, language 
is Italian).

The vendorID:deviceID are 2021:0002 (I see CCID has provisions for 0001, 
0011 and 0101 but not 0002).


This is what I read in the logs at insertion time:

Oct 20 16:39:40 pes-app-blank-01 kernel: usb 1-11: new high speed USB 
device number 12 using xhci_hcd
Oct 20 16:39:40 pes-app-blank-01 kernel: usb 1-11: New USB device found, 
idVendor=058f, idProduct=6254
Oct 20 16:39:40 pes-app-blank-01 kernel: usb 1-11: New USB device 
strings: Mfr=0, Product=0, SerialNumber=0
Oct 20 16:39:40 pes-app-blank-01 kernel: usb 1-11: configuration #1 
chosen from 1 choice
Oct 20 16:39:40 pes-app-blank-01 kernel: hub 1-11:1.0: USB hub found
Oct 20 16:39:40 pes-app-blank-01 kernel: hub 1-11:1.0: 4 ports detected
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: new high speed USB 
device number 13 using xhci_hcd
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: New USB device 
found, idVendor=1307, idProduct=0165
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: New USB device 
strings: Mfr=1, Product=2, SerialNumber=3
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: Product: USB Mass 
Storage Device
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: Manufacturer: 
USBest Technology
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: SerialNumber: 
000000000002BA
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.1: configuration #1 
chosen from 1 choice
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: new full speed USB 
device number 14 using xhci_hcd
Oct 20 16:39:41 pes-app-blank-01 kernel: Initializing USB Mass Storage 
driver...
Oct 20 16:39:41 pes-app-blank-01 kernel: scsi7 : SCSI emulation for USB 
Mass Storage devices
Oct 20 16:39:41 pes-app-blank-01 kernel: usbcore: registered new 
interface driver usb-storage
Oct 20 16:39:41 pes-app-blank-01 kernel: USB Mass Storage support 
registered.
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: New USB device 
found, idVendor=2021, idProduct=0002
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: New USB device 
strings: Mfr=1, Product=2, SerialNumber=0
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: Product: HKey
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: Manufacturer: AK910
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: configuration #1 
chosen from 1 choice
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: ep 0x2 - rounding 
interval to 64 microframes, ep desc says 80 microframes
Oct 20 16:39:41 pes-app-blank-01 kernel: usb 1-11.2: ep 0x82 - rounding 
interval to 64 microframes, ep desc says 80 microframes
Oct 20 16:39:41 pes-app-blank-01 kernel: generic-usb 
0003:2021:0002.0001: hiddev96,hidraw0: USB HID v1.00 Device [AK910 HKey] 
on usb-0000:00:14.0-11.2/input0
Oct 20 16:39:42 pes-app-blank-01 kernel: scsi 7:0:0:0: 
Direct-Access                               0.00 PQ: 0 ANSI: 2
Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: Attached scsi 
generic sg2 type 0
Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: [sdb] 1972744 
512-byte logical blocks: (1.01 GB/963 MiB)
Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: [sdb] Write Protect 
is off
Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: [sdb] Assuming 
drive cache: write through
Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: [sdb] Assuming 
drive cache: write through
Oct 20 16:39:42 pes-app-blank-01 kernel: sdb:
Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: [sdb] Assuming 
drive cache: write through
Oct 20 16:39:42 pes-app-blank-01 kernel: sd 7:0:0:0: [sdb] Attached SCSI 
removable disk


This is the lsusb output:



Bus 001 Device 013: ID 2021:0002
Device Descriptor:
   bLength                18
   bDescriptorType         1
   bcdUSB               1.10
   bDeviceClass            0 (Defined at Interface level)
   bDeviceSubClass         0
   bDeviceProtocol         0
   bMaxPacketSize0         8
   idVendor           0x2021
   idProduct          0x0002
   bcdDevice            1.00
   iManufacturer           1 AK910
   iProduct                2 HKey
   iSerial                 0
   bNumConfigurations      1
   Configuration Descriptor:
     bLength                 9
     bDescriptorType         2
     wTotalLength           41
     bNumInterfaces          1
     bConfigurationValue     1
     iConfiguration          0
     bmAttributes         0x80
       (Bus Powered)
     MaxPower              100mA
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       0
       bNumEndpoints           2
       bInterfaceClass         3 Human Interface Device
       bInterfaceSubClass      0 No Subclass
       bInterfaceProtocol      0 None
       iInterface              0
         HID Device Descriptor:
           bLength                 9
           bDescriptorType        33
           bcdHID               1.00
           bCountryCode            0 Not supported
           bNumDescriptors         1
           bDescriptorType        34 Report
           wDescriptorLength      34
          Report Descriptors:
            ** UNAVAILABLE **
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x02  EP 2 OUT
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0040  1x 64 bytes
         bInterval              10
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0040  1x 64 bytes
         bInterval              10
Device Status:     0x0000
   (Bus Powered)

Best regards

     Umberto Rustichelli

[Opensc-devel] Removing old card drivers from OpenSC

[Frank M. <fra...@gm...>]

Many of the internal card drivers have not been updated in years (card-*.c
and their pkcs15-*.c counterpart). Although they may have gotten touched
due to general security fixes, these changes are mostly untested with these
card drivers. Most likely these cards are not in use anymore. To reduce the
overall attack surface, I am planning to remove the old card drivers first
by disabling them in the default configuration and later by removing them
from the default compilation process.

The rationale when and how to remove a card driver is given in the wiki:
https://github.com/OpenSC/OpenSC/wiki/Removal-of-Old-Card-Drivers.
Progress about the implementation is tracked on Github:
https://github.com/OpenSC/OpenSC/projects/2
A first implementation is available as pull request:
https://github.com/OpenSC/OpenSC/pull/1175

What I like to know, is wether you think the time scales are chosen
approprietly. Of course, if you think some driver needs to stay in the
default configuration or the default binaries, please update the wiki page
indicating that it is still used (and ideally, add a link as prove).

Thanks for your feedback!

Regards,
Frank.

Re: [Opensc-devel] OpenSC 0.17 breaks PIV card auth on Safari/Citrix Receiver On macOS 10.12+

[Ludovic R. <lud...@gm...>]

2017-10-12 3:12 GMT+02:00 Matthew X. Economou <xen...@ir...>:

> Actually, why doesn't the macOS installer disable pivtoken itself?  Does
> disabling that break something else?
>

You may want to use the pivtoken provided by Apple to use with your PIV
card and use OpenSC for a non-PIV card (maybe disabled PIV support from
OpenSC).

I think that OpenSC does not yet provide a CryptoTokenKit Smart Card
Driver, but just a tokend (old technology). So using the Apple pivtoken may
be better for some user.

Bye

-- 
 Dr. Ludovic Rousseau

Re: [Opensc-devel] OpenSC 0.17 breaks PIV card auth on Safari/Citrix Receiver On macOS 10.12+

[Matthew X. E. <xen...@ir...>]

Actually, why doesn't the macOS installer disable pivtoken itself?  Does
disabling that break something else? 

-- 
"The lyf so short, the craft so longe to lerne."

Re: [Opensc-devel] OpenSC 0.17 breaks PIV card auth on Safari/Citrix Receiver On macOS 10.12+

[Matthew X. E. <xen...@ir...>]

Doug, Frank,

Thanks for your help.  Frank's suggestion to disable com.apple.CryptoTokenKit.pivtoken fixed the problem I was having.  I'll add this to the Mac docs on the OpenSC wiki, as I can't find it documented anywhere.

Best wishes,
Matthew

-- 
"The lyf so short, the craft so longe to lerne."

Re: [Opensc-devel] OpenSC 0.17 breaks PIV card auth on Safari/Citrix Receiver On macOS 10.12+

[Frank M. <fra...@gm...>]

*Apple's CryptoTokenKit breaks non-Apple software! *Only use OpenSC and
disable the PIVToken:



*sudo defaults write /Library/Preferences/com.apple.security.smartcard
DisabledTokens -array com.apple.CryptoTokenKit.pivtoken*
Regards, Frank.

2017-10-11 15:07 GMT+02:00 Douglas E Engert <dee...@gm...>:

>
> It sounds like one or both of the MacOS smart card code or OpenSC are
> accessing the card in exclusive mode. Both have support for PIV cards
> and use pcsc to access the reader.
>
> I do not use MacOS, but there are others on this mailing list that do
> and use PIV cards. I am surprised no else has responded.
>
> https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC
>
> See the OpenSC opensc.conf file debug= and debug_file= parameters to turn
> on debugging.
>
> Also look at the connect_exclusive, disconnect_action,
> transaction_end_action
> and reconnect_action. The default of disconnect_action=reset may be a
> problem.
> I would set it to disconnect_action=leave; But the MaocOS code may also be
> causing problems.
>
> https://github.com/OpenSC/OpenSC/wiki/macOS-Quick-Start
> might help. Search the wiki
>
> Google for: opensc Mac OS office safari Citrix
>
> Google for: pcsc Mac OS debugging
>
>
> On 10/10/2017 2:51 PM, Matthew X. Economou wrote:
>
>> Dear all,
>>
>> I use OpenSC on my Macs to use PIV cards with Office (e.g., signing
>> email).  However, this breaks logins to Citrix Receiver via Safari, and
>> I don't know how to troubleshoot it.  Uninstalling OpenSC restores the
>> original behavior, i.e., PIV card logins work with Safari/Citrix
>> Reciever but not Office.  Is there a knob that turns on debug logging
>> inside of OpenSC or one of its components?  Can I attach a debugger
>> somehow?  How would I go about figuring this out?
>>
>> Best wishes,
>> Matthew
>>
>>
> --
>
>  Douglas E. Engert  <DEE...@gm...>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

Re: [Opensc-devel] OpenSC 0.17 breaks PIV card auth on Safari/Citrix Receiver On macOS 10.12+

[Douglas E E. <dee...@gm...>]

It sounds like one or both of the MacOS smart card code or OpenSC are
accessing the card in exclusive mode. Both have support for PIV cards
and use pcsc to access the reader.

I do not use MacOS, but there are others on this mailing list that do
and use PIV cards. I am surprised no else has responded.

https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC

See the OpenSC opensc.conf file debug= and debug_file= parameters to turn on debugging.

Also look at the connect_exclusive, disconnect_action, transaction_end_action
and reconnect_action. The default of disconnect_action=reset may be a problem.
I would set it to disconnect_action=leave; But the MaocOS code may also be
causing problems.

https://github.com/OpenSC/OpenSC/wiki/macOS-Quick-Start
might help. Search the wiki

Google for: opensc Mac OS office safari Citrix

Google for: pcsc Mac OS debugging


On 10/10/2017 2:51 PM, Matthew X. Economou wrote:
> Dear all,
> 
> I use OpenSC on my Macs to use PIV cards with Office (e.g., signing
> email).  However, this breaks logins to Citrix Receiver via Safari, and
> I don't know how to troubleshoot it.  Uninstalling OpenSC restores the
> original behavior, i.e., PIV card logins work with Safari/Citrix
> Reciever but not Office.  Is there a knob that turns on debug logging
> inside of OpenSC or one of its components?  Can I attach a debugger
> somehow?  How would I go about figuring this out?
> 
> Best wishes,
> Matthew
> 

-- 

  Douglas E. Engert  <DEE...@gm...>

[Opensc-devel] OpenSC 0.17 breaks PIV card auth on Safari/Citrix Receiver On macOS 10.12+

[Matthew X. E. <xen...@ir...>]

Dear all,

I use OpenSC on my Macs to use PIV cards with Office (e.g., signing
email).  However, this breaks logins to Citrix Receiver via Safari, and
I don't know how to troubleshoot it.  Uninstalling OpenSC restores the
original behavior, i.e., PIV card logins work with Safari/Citrix
Reciever but not Office.  Is there a knob that turns on debug logging
inside of OpenSC or one of its components?  Can I attach a debugger
somehow?  How would I go about figuring this out?

Best wishes,
Matthew

-- 
"The lyf so short, the craft so longe to lerne."

Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC

[Frank M. <fra...@gm...>]

I think the current layout looks OK and you can proceed. The structure
should also be usable in the minidriver.

There is "connect_exclusive" in the pcsc section. There is also
"lock_login" from the pkcs11 section to achieve something similar. Locking
the token has the disadvantage that concurrent access is very limited.

We also recently introduced the pkcs11 option "atomic", which tracks the
login state and restores this on each transaction. This has the
disadvantage that much more operations with the card are carried out, but
it assures that the card is only locked for a short period of time while
the login state is safe from misuse This option could be extended to
tracking session objects...

The topic of secure    concurrent access in PKCS#11 is a big mess... On
Windows, for example, the OS handles concurrent access for the Minidriver
so that the middleware doesn't need this complexity.

To round this up, we also have a long term project of handling card resets
(from concurrent processes) correctly...
https://github.com/OpenSC/OpenSC/projects

Regards, Frank.

2017-10-06 9:42 GMT+02:00 Aventra Development <dev...@av...>:

> Thank you for your comments, good point about multiple applications. I
> think that while in a HSM it is normal functionality, on a smart card it
> would be quite difficult to track session objects of different sessions,
> because of limited resources. For our use case, it would be sufficient to
> restrict usage of these objects to one application at a time by
> documentation, and live with the fact that they are lost if another
> application resets the card. Is it possible to run OpenSC with PS/SC flag
> SCARD_SHARE_EXCLUSIVE using some setting in opensc.conf? That would ensure
> that sessions objects stay stable.
>
> However, it would be preferable that in OpenSC we could handle such
> situations cleanly, if another application resets the card. I think it
> would be ok that the driver returns an error if trying to access a sessions
> object which was lost in a reset, and we should be careful that such object
> don't leak in memory or cause other confusion. We should also make it
> possible to handle multiple sessions, if there is a card that supports it.
> Got to look into this.
>
> There definitely is work to be done in checking attributes of the target
> key, checking if the driver supports session keys and other attributes as
> well. As a side effect of this project, we may get more functionality to
> the secret key support in general into framework-pkcs15. I think that as
> there is now support to load secret keys in pkcs15init and the PKCS#15
> structures are defined, it would be relatively easy to implement C_Encrypt
> and C_Decrypt for secret keys.
>
> If we agree on the basic structure of the unwrap implementation, the next
> steps are to implement it on MyEID card and on driver level, add lots of
> checking to handle different key lengths, types and attributes, and
> implement key wrapping with a similar pattern.
>
> - Hannu
>
>
> -----Alkuperäinen viesti-----
> Lähettäjä: Douglas E Engert [mailto:dee...@gm...]
> Lähetetty: keskiviikko 4. lokakuuta 2017 17.22
> Vastaanottaja: ope...@li...
> Aihe: Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC
>
>
>
> On 10/4/2017 7:08 AM, Aventra Development wrote:
> > On 22. September 17, Douglas E Engert wrote:
> >> I assume the above is just for testing. In either case if you can
> support both token and session objects that would be good. Also keep in
> mind some card drivers emulate some of the PKCS#15 operations, which
> usually means they can support session objects but not token objects.
> >> (The may support token objects but not via PKCS#11 or PKCS#15 but some
> other means.
> >> The OpenSC C_DeriveKey was written for such a card to support ECDH.)
> >
> > Back to wrapping after doing some other work for a while. Yes, at this
> point this is just to demonstrate the logic I have planned.
> >
> > Regarding session objects, we want to support both software and hardware
> session objects. By PKCS#11 spec, they can be either implemented completely
> in software or stored in the token for the lifetime of the session. So we
> need to distinguish between software and on-card session objects. I added
> SC_CARD_CAP_ONCARD_SESSION_OBJECTS flag to let drivers tell if they can
> handle session objects on card.
> > For a hardware session object, we need to create the key object on card,
> but it is not needed to update the P15 directory file. With MyEID we are
> going to implement session objects so that the card will clean them out in
> the next reset. For us it is important to be able to create a temporary key
> object on card as a result of C_UnwrapKey, and be able to use that key
> using PKCS#11.
>
> OpenSC can be called by multiple applications. This could cause problems
> if multiple applications need a hardware session object and especially if
> one application does a reset. depending in the timing and how the hardware
> and software keep track of these session hardware objects, the hardware ans
> software could get confused.  This is similar to losing the login state to
> a card, which is a much easier problem, solved mostly by pin caching.
>
>
>
> >
> > I think the new features shouldn't affect cards that emulate PKCS#15
> operations. The code could be used to enable accessing these operations
> using PKCS#11 in future. Well, one thing to consider is that should we
> allow the unwrap function in the card driver to return the unwrapped key as
> a memory buffer, if the card cannot unwrap in hardware?
>
> That is more a function of what attributes are requested in the session
> key template and what the card can or can not do.
> I have not looked to see if PKCS#11 provides and help here.
> I think the code should be designed to handle either case, and if the card
> can not do it return unsupported or whatever CKR_* the specs say.
>
> > For now I didn't add a return buffer, because I think the whole point of
> unwrapping is to do it in hardware to keep the key safe, and if someone
> wants to unwrap keys to PC memory, it can be done using decrypt.
> >
> >>> We haven’t yet decided how to tell driver and card, which key file
> >>> should receive the unwrapped key. We have thought of using manage
> security environment, but haven’t yet find a card independent way to set it
> in pkcs15-sec.c.
> >> You could use the CKA_LABEL, or even a vendor supplied attribute for
> OpenSC, that could be used to pass info to pkcs15init when creating a key
> on the card.
> >> Side issue:OpenSC needs to fix how it assigns CKA_VENDOR_DEFINED
> attributes. see:
> >> https://github.com/OpenSC/OpenSC/pull/1131#issuecomment-323335738
> >> For session keys, the handle to the key is good enough since the handle
> is unique for the session.
> >
> > The empty target key is created in beginning of the operation (like in
> derive) and we get the object handle, containing file path if it's a token
> object, to the pkcs11-object.c level. I don't see problems here. Then we
> call sc_pkcs11_unwrap and go thru many function calls. Another thing is to
> transmit a reference in form of a file path or ID to the card driver for
> the actual crypto operation. For signing and decrypt operations the file
> ref to the key that performs the operation is transmitted to the driver in
> sc_security_env.file_ref. With many cards the driver transmits it to the
> card in an MSE:SET command APDU. We'd like to use the same logic for
> setting the target key for unwrapping. I added target_file_ref to
> sc_security_env struct to hold this file reference. ISO7816-4 or 8 don't
> clearly define how to use MSE:SET to prepare wrapping and unwrapping, but
> with this method drivers and cards could implement it in their own way.
>
> As a last resort, we could always add a vendor provided attribute.
>
> Sounds like you have most of the issues in hand, other then the multiple
> application problem of doing a reset in which case the login state, and the
> hardware session key are lost. The PKCS#11 code needs to handle what
> happens to the session objects if some other application resets the card.
> If its in memory it can still be used. If in hardware, it is most likely
> lost.
>
>
>
> >
> > Just pushed a new version to
> > https://github.com/hhonkanen/OpenSC/tree/wrapping
> > You can see there how I'm doing it.  This version can create a permanent
> target key object on card for a secret key using pkcs15init, in case
> CKA_TOKEN=TRUE.
> >
> > If you would like to run the code, I added a little test program to
> GitHub.
> > https://github.com/hhonkanen/WrapTest
> > You can run it with a normal MyEID card and it can do all other parts of
> the wrapping operation with these parameters, except actually decrypting
> the key to the target file. You have to generate or import an RSA key pair
> to the card first and encrypt some data with the public key, then put the
> encrypted data to CK_BYTE wrappedKey[] before calling C_UnwrapKey.
> >
> > I think we have to concentrate on the card implementation next to get
> further, but I am open to discussion and ideas about the OpenSC
> implementation. Especially I would like to hear what you like about passing
> the target file ref in sc_security_env_t and would there be some
> alternative ways.
> >
> > - Hannu
> >
> > -----Alkuperäinen viesti-----
> > Lähettäjä: Douglas E Engert [mailto:dee...@gm...]
> > Lähetetty: perjantai 22. syyskuuta 2017 21.30
> > Vastaanottaja: ope...@li...
> > Aihe: Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to
> > OpenSC
> >
> > On 9/22/2017 8:32 AM, Aventra Development wrote:
> >> Hi,
> >>
> >> I have committed the first version of C_UnwrapKey implementation to
> >> my branch at https://github.com/hhonkanen/OpenSC/tree/wrapping
> >>
> >> I hope you would have time to take a look.
> >>
> >> As we don’t yet even have a card that could perform the actual
> >> unwrapping operation, this code is not yet complete and it currently
> >> emulates unwrapping by doing a normal decrypt operation. It can be run
> and it goes all the way to the card driver when target object template has
> CKA_TOKEN=FALSE, but the code to store the pkcs#15 object is not yet
> complete. Anyway, from this commit you can see the logic I am planning to
> use.
> >
> > I assume the above is just for testing. In either case if you can
> support both token and session objects that would be good. Also keep in
> mind some card drivers emulate some of the PKCS#15 operations, which
> usually means they can support session objects but not token objects.
> > (The may support token objects but not via PKCS#11 or PKCS#15 but some
> other means.
> > The OpenSC C_DeriveKey was written for such a card to support ECDH.)
> >
> >
> > CKA_TOKEN=FALSE says the object is a session object which does not
> require any code to store the pkcs#15 object.
> > CKA_TOKEN=TRUE says the object is a token object, so you would need to
> tell the token what to do with it.
> >
> >
> >>
> >> This implementation follows the same pattern as C_DeriveKey. The call
> goes for PKCS#11 to the driver like this:
> >>
> >>   1. C_UnwrapKey --> sc_create_object->pkcs15_create_object, to create
> the target PKCS#15 object to receive the key.
> >>
> >>                                pkcs15_create_secret_key calls
> pkcs15init to create the PKCS#15 structure and key EF on card.
> >>
> >>   2. We have a handle to the target object. From now on the calls go in
> very similar way like a decrypt or key derivation operation:
> >>
> >> C_UnwrapKey --> sc_pkcs11_unwrap->sc_pkcs11_unwrap_operation->pkcs15_
> prkey_unwrap->sc_pkcs15_unwrap.
> >>
> >> Here we format and set security environment and call card:
> >>
> >> use_key->sc_set_security_env
> >>
> >> use_key->sc_unwrap->myeid_unwrap_key.
> >>
> >> Before I started coding, I thought of two alternative ways:
> >>
> >>   1. Implement most of the stuff in pkcs15init as you suggested and
> >> create new pkcs15init operations  2. Go C_DeriveKey style.
> >>
> >> It was not an easy decision, but the main motives to go C_DeriveKey way
> were:
> >
> > Good choice I like the C_DeriveKey choice especially for cards that are
> not true PKCS#15 cards.
> >>
> >>    * I noticed that after we have a target key object, the rest of the
> operation is actually similar to decrypt. The unwrapping operation is
> performed with a PKCS#11 key object, which supports specific
> >>      mechanisms. This initial version supports only RSA, but in future
> we could have several mechanism for each supported key type, for example
> CKM_AES_ECB, CKM_AES_CBC, CKM_RSA_PKCS, CKM_RSA_X_509
> >>      etc. The logic to handle a crypto operations with a specific
> object and a mechanism was already there.
> >>    * there already was unwrap_key method defined in
> sc_pkcs11_object_ops.
> >>    * there already was the working C_DeriveKey code. I thought it would
> be good to be consistent with it, because it does nearly the same thing.
> >>    * I think this model fits for C_WrapKey as well. As a crypto
> operation it has the same characteristics, the data just goes into other
> direction.
> >>
> >> We haven’t yet decided how to tell driver and card, which key file
> >> should receive the unwrapped key. We have thought of using manage
> security environment, but haven’t yet find a card independent way to set it
> in pkcs15-sec.c.
> >>
> >
> > You could use the CKA_LABEL, or even a vendor supplied attribute for
> OpenSC, that could be used to pass info to pkcs15init when creating a key
> on the card.
> >
> > Side issue:OpenSC needs to fix how it assigns CKA_VENDOR_DEFINED
> attributes. see:
> > https://github.com/OpenSC/OpenSC/pull/1131#issuecomment-323335738
> >
> > For session keys, the handle to the key is good enough since the handle
> is unique for the session.
> >
> >
> >> Another thing we have to think about is do we need to implement a new
> >> function in pkcs15init/pkcs15-lib.c to create an empty secret key file
> to receive the unwrapped key. There is a function to store a secret key:
> sc_pkcs15init_store_secret_key, but it doesn’t currently work without key
> data.
> >>
> >> I am really looking forward to find such architecture that the
> >> community can accept and to have the code merged into master when it’s
> functional. Hoping to hear opinions on is this as good way to go or should
> we take a different approach.
> >>
> >> - Hannu
> >>
> >> *Lähettäjä:*Frank Morgner [mailto:fra...@gm...]
> >> *Lähetetty:* maanantai 18. syyskuuta 2017 0.27
> >> *Vastaanottaja:* Aventra Development <dev...@av...>
> >> *Kopio:* ope...@li...
> >> *Aihe:* Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to
> >> OpenSC
> >>
> >> OK, we'll see when you're fine with some working code.
> >>
> >> One more pointer I'd like to give is ISO 7816-8, which gives some
> >> example on how to import a private key using PUT DATA with DO 7F48
> >> (card holder private key template). As far as I know, OpenSC used to
> implement the ISO style of card interactions first, which then got mapped
> to other type of cards as well. So using the existing get_data and put_data
> hooks of the card driver would also be usable for key import. That being
> said, I know that the concept has been softened. There is the
> read_public_key callback, which following the ISO style should have been
> implemented with get_data...
> >>
> >> 2017-09-14 14:10 GMT+02:00 Aventra Development <dev...@av...
> <mailto:dev...@av...>>:
> >>
> >>      Thank you for your comments!
> >>
> >>      I have got quite far in implementing the first case of C_UnwrapKey
> that we need, which is unwrapping a secret key using an RSA key. During
> coding I have also realized that at least the part that
> >>      creates the PKCS#15 object for the unwrapped key, adds it to SKDF
> and updates it to the card belongs naturally to pkcs15init. However, the
> part that performs the crypto operation to unwrap the key
> >>      is very similar to decrypt and derive operations, so I ended up
> adding sc_pkcs15_unwrap() to pkcs15-sec.c. So in my current implementation
> what happens is:
> >>
> >>       1. The call to C_UnwrapKey is first handled in pkcs#11 level
> (pkcs11-object.c and mechanism.c)
> >>       2. Via sc_pkcs11_object_ops we get into framework_pkcs15, I have
> added a function named pkcs15_prkey_unwrap()
> >>       3. I use sc_pkcs15init_bind like in some other framework_pkcs15
> functions, and call pkcs15init. I have added a new function
> sc_pkcs15init_unwrap_key()
> >>       4. sc_pkcs15init_unwrap_key() creates the new key object (key EF)
> into card, updates SKDF, and calls sc_pkcs15_unwrap() in pkcs15-sec.c to
> perform the actual crypto operation on card.
> >>       5. The card performs a decrypt operation and places the result
> into the key EF created by pkcs15init. (we don’t have this feature on card
> yet).
> >>
> >>      In driver level I initially added wrap and unwrap operations to
> sc_card_operations. I don’t have a strong opinion on which is better, this
> way or using sc_card_ctl. Still I think they fit quite
> >>      well on the same level with decipher and compute_signature
> operations. But in the whole job this is actually a minor detail and can
> still be changed easily.
> >>
> >>      I am still not sure, can we do this in a way that is card
> >> independent enough in pkcs15-sec, or would it be better to implement
> >> a new pkcs15init operation (a new function pointer to
> >>
> >>      sc_pkcs15init_operations) which each card vendor could implement
> in their own way. We’ll see how it looks as I progress.
> >>
> >>      When I get my code in buildable and more solid state, I’ll commit
> it into my fork and you could take a look.
> >>
> >>      Got to keep the minidriver spec in mind. I am not very familiar on
> how the OpenSC minidriver interacts with rest of OpenSC, and I hope this
> doesn’t add too much complexity into my implementation.
> >>      Probably the important thing is to make the low level
> implementation on card driver level usable with both minidriver and PKCS#11
> way, because in higher level a parallel implementation could be
> >>      added for the minidriver.
> >>
> >>      - Hannu
> >>
> >>      *Lähettäjä:*Frank Morgner [mailto:fra...@gm... <mailto:
> fra...@gm...>]
> >>      *Lähetetty:* torstai 14. syyskuuta 2017 11.16
> >>      *Vastaanottaja:* Aventra Development <dev...@av...
> <mailto:dev...@av...>>
> >>      *Kopio:* ope...@li...
> >> <mailto:ope...@li...>
> >>
> >>
> >>      *Aihe:* Re: [Opensc-devel] Implementing C_WrapKey and
> >> C_UnwrapKey to OpenSC
> >>
> >>      In general your approach sounds good! But I have objections
> regarding the software architecture. Historically, key generation and key
> import has been done in pkcs15init. There are some other cards
> >>      besides sc-hsm that are calling some control command in the card
> driver from pkcs15init. Basically, what you're asking for is to use
> pkcs15init functionality in PKCS#11. Instead of implementing
> >>      everything in PKCS#11, it would be better to make pkcs15init
> available as DLL/LIB that can be loaded into OpenSC's PKCS#11 library. With
> this approach you would implement key wrapping in your
> >>      card's operations in pkcs15init (possibly redirecting it to the
> driver in libopensc with a control command).
> >>
> >>      One more thing I'd like to throw in is that Microsoft also has its
> view of key wrapping. Have a look at Smart Card Minidriver Specification,
> v7.07 Figure B1. Process for key generation and
> >>      insertion (https://msdn.microsoft.com/en-us/library/windows/
> hardware/dn631754(v=vs.85).aspx). Please make sure that your
> implementation has this spec in mind so that key wrapping can also be added
> >>      to the minidriver.
> >>
> >>      Regards,
> >>
> >>      Frank.
> >>
> >>      2017-09-11 10:11 GMT+02:00 Aventra Development <
> dev...@av... <mailto:dev...@av...>>:
> >>
> >>          Thanks for the tip. Yes, the ECDH code looks like it can be
> used with slight modifications and expanded to perform unwrap.  Some more
> work is needed in the card/driver level to set up
> >>          properties of the new key in the key EF on card according to
> the PKCS#11 attributes in the template.
> >>
> >>          What do you think about adding wrap and unwrap into
> sc_card_operations in opensc.h? Is there a risk of causing some trouble or
> should all go fine as long they're just set to NULL on cards that
> >>          don't support them? If more cards would support these
> operations in future, this way each card wouldn't need to add new card
> specific SC_CARDCTL_xxx values.
> >>
> >>          - Hannu
> >>
> >>          -----Alkuperäinen viesti-----
> >>          Lähettäjä: Douglas E Engert [mailto:dee...@gm...
> <mailto:dee...@gm...>]
> >>          Lähetetty: perjantai 8. syyskuuta 2017 15.26
> >>          Vastaanottaja: ope...@li... <mailto:
> ope...@li...>
> >>          Aihe: Re: [Opensc-devel] Implementing C_WrapKey and
> >> C_UnwrapKey to OpenSC
> >>
> >>
> >>          The ECDH can derive a key, which may be returned by the card
> or kept on the card.
> >>          A Session object is created for the derived key. The code was
> written for a card that would return a secret key so the session object has
> CKA_TOKEN=FALSE.
> >>
> >>          So the derive code is very similar to the unwrap. You might
> want to start looking it.
> >>
> >>
> >>          On 9/8/2017 6:32 AM, Aventra Development wrote:
> >>           > Hi fellow OpenSC developers,
> >>           >
> >>           > Some of you may already know me from my contributions to
> mostly MyEID
> >>           > driver. We are now starting a larger development project so
> I thought
> >>           > a brief introduction would be appropriate. I am a developer
> at Aventra, Finland. Our target in this project is to implement C_WrapKey
> and C_UnwrapKey PKCS#11 functions into OpenSC and
> >>          initially to the MyEID driver. At the same time we are going
> to implement this functionality into MyEID card.
> >>           >
> >>           > I have created a branch named "wrapping" in my OpenSC fork
> at
> >>           > https://github.com/hhonkanen/OpenSC
> >>           >
> >>           > Before starting coding I have done some planning and split
> the work into sub tasks. Here are the tasks I have found:
> >>           >
> >>           > - implement wrapping and unwarpping in pkcs#15 level
> >>           > (framework-pkcs15.c)
> >>           >
> >>           >                             * sc_pkcs11_object_ops already
> contains unwrap_key operation. wrap_key operation must be added.
> >>           >
> >>           >                             * implement
> pkcs15_skey_wrap_key, pkcs15_skey_unwrap_key etc...in framework_pkcs15.c
> and map the functions to                        sc_pkcs11_object_ops.
> >>           >
> >>           >                             * changes to
> register_mechamisms and functions called from there (for example
> sc_pkcs11_new_fw_mechanism).
> >>           >
> >>           >                               set CKF_WRAP and CKF_UNWRAP
> when appropriate.
> >>           >
> >>           >                             * parse the CKA_xxxx attributes
> and create
> >>           > the needed PKCS#15 structures for the keys that will be
> created on
> >>           > card during                            unwrapping operations
> >>           >
> >>           > - implement wrapping and unwrapping in pkcs15-sec and card
> driver level:
> >>           >
> >>           >                             * add wrap/unwrap functions to
> sc_card_driver. In SC-HSM driver these are implemented as driver specific
> card_ctl commands.
> >>           >
> >>           >                               I am not sure if we should go
> this way or add the new operations directly to sc_card_operations.
> >>           >
> >>           >                             * implement them in card-myeid.c
> >>           >
> >>           > * seems like I have to create functions like
> sc_pkcs15_wrap_key and sc_pkcs15_unwrap_key to do the work between pkcs15
> and card layers.
> >>           >
> >>           > - implement the functions in PKCS#11 level:
> >>           >
> >>           >                            * implement C_WrapKey and
> C_UnwrapKey in
> >>           > pkcs11-object.c. Check mechanism and attributes and call
> >>           > framework_pkcs15
> >>           >
> >>           >                             * return the handle of wrapped
> key (in memory) or unwrapped key (on card) to the pkcs#11 level and to the
> caller.
> >>           >
> >>           > Some issues we have to think about:
> >>           >
> >>           > - It is still not totally clear to me how to begin
> implementing the
> >>           > operations from PKCS#11 side (C_WrapKey and C_UnwrapKey in
> pkcs11-object.c). I think I am going to follow a similar pattern as in
> C_SignInit and C_DecryptInit. This will probably become
> >>          clearer when I get started, but any tips are more than welcome.
> >>           >
> >>           > - Handling of secret key objects when CKA_TOKEN=FALSE.
> PKCS#11 doesn't
> >>           > define where such session objects should be stored, but
> leaves it up
> >>           > to implementation. We must have possibililty to have
> session objects on card. With this I mean key objects that are cleaned from
> the card in the next reset and the key material never leaves
> >>          the card. We need this kind of objects in chained key wrapping
> operation. I am planning to implement it so that drivers could tell whether
> they can handle in card session objects. If a driver
> >>          doesn't support them, they would be handled as in memory
> objects.
> >>           >
> >>           > - in addition to RSA and AES keys, we must be able to handle
> >>           > CKK_GENERIC_SECRET objects which might be somewhat
> different to implement,  because lots of the key handling code is related
> to the key algorithm.
> >>           >
> >>           > Any feedback, tips and contributions in testing/code review
> will be greatly appreciated.
> >>           >
> >>           > Best regards,
> >>           >
> >>           > Hannu Honkanen
> >>           >
> >>           > Aventra
> >>           >
> >>           >
> >>           >
> >>           >
> >> ---------------------------------------------------------------------
> >> -
> >>
> >>           > -------- Check out the vibrant tech community on one of
> >> the world's
> >>
> >>           > most engaging tech sites, Slashdot.org!
> http://sdm.link/slashdot
> >>           >
> >>           >
> >>           >
> >>           > _______________________________________________
> >>           > Opensc-devel mailing list
> >>           > Ope...@li... <mailto:
> Ope...@li...>
> >>           > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >>           >
> >>
> >>          --
> >>
> >>             Douglas E. Engert  <DEE...@gm...
> >> <mailto:DEE...@gm...>>
> >>
> >>
> >>          ------------------------------------------------------------
> ------------------
> >>          Check out the vibrant tech community on one of the world's
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> >>          Opensc-devel mailing list
> >>          Ope...@li... <mailto:Opensc-devel@lists.
> sourceforge.net>
> >>          https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >>          ------------------------------------------------------------
> ------------------
> >>          Check out the vibrant tech community on one of the world's most
> >>          engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>          _______________________________________________
> >>          Opensc-devel mailing list
> >>          Ope...@li... <mailto:Opensc-devel@lists.
> sourceforge.net>
> >>          https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >>
> >>
> >>      ------------------------------------------------------------
> ------------------
> >>      Check out the vibrant tech community on one of the world's most
> >>      engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>      _______________________________________________
> >>      Opensc-devel mailing list
> >>      Ope...@li... <mailto:Opensc-devel@lists.
> sourceforge.net>
> >>      https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> -------- Check out the vibrant tech community on one of the world's
> >> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>
> >>
> >>
> >> _______________________________________________
> >> Opensc-devel mailing list
> >> Ope...@li...
> >> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >>
> >
>
> --
>
>   Douglas E. Engert  <DEE...@gm...>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most engaging
> tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC

[Aventra D. <dev...@av...>]

Thank you for your comments, good point about multiple applications. I think that while in a HSM it is normal functionality, on a smart card it would be quite difficult to track session objects of different sessions, because of limited resources. For our use case, it would be sufficient to restrict usage of these objects to one application at a time by documentation, and live with the fact that they are lost if another application resets the card. Is it possible to run OpenSC with PS/SC flag SCARD_SHARE_EXCLUSIVE using some setting in opensc.conf? That would ensure that sessions objects stay stable. 

However, it would be preferable that in OpenSC we could handle such situations cleanly, if another application resets the card. I think it would be ok that the driver returns an error if trying to access a sessions object which was lost in a reset, and we should be careful that such object don't leak in memory or cause other confusion. We should also make it possible to handle multiple sessions, if there is a card that supports it. Got to look into this. 

There definitely is work to be done in checking attributes of the target key, checking if the driver supports session keys and other attributes as well. As a side effect of this project, we may get more functionality to the secret key support in general into framework-pkcs15. I think that as there is now support to load secret keys in pkcs15init and the PKCS#15 structures are defined, it would be relatively easy to implement C_Encrypt and C_Decrypt for secret keys.

If we agree on the basic structure of the unwrap implementation, the next steps are to implement it on MyEID card and on driver level, add lots of checking to handle different key lengths, types and attributes, and implement key wrapping with a similar pattern.

- Hannu


-----Alkuperäinen viesti-----
Lähettäjä: Douglas E Engert [mailto:dee...@gm...] 
Lähetetty: keskiviikko 4. lokakuuta 2017 17.22
Vastaanottaja: ope...@li...
Aihe: Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC



On 10/4/2017 7:08 AM, Aventra Development wrote:
> On 22. September 17, Douglas E Engert wrote:
>> I assume the above is just for testing. In either case if you can support both token and session objects that would be good. Also keep in mind some card drivers emulate some of the PKCS#15 operations, which usually means they can support session objects but not token objects.
>> (The may support token objects but not via PKCS#11 or PKCS#15 but some other means.
>> The OpenSC C_DeriveKey was written for such a card to support ECDH.)
> 
> Back to wrapping after doing some other work for a while. Yes, at this point this is just to demonstrate the logic I have planned.
> 
> Regarding session objects, we want to support both software and hardware session objects. By PKCS#11 spec, they can be either implemented completely in software or stored in the token for the lifetime of the session. So we need to distinguish between software and on-card session objects. I added SC_CARD_CAP_ONCARD_SESSION_OBJECTS flag to let drivers tell if they can handle session objects on card.
> For a hardware session object, we need to create the key object on card, but it is not needed to update the P15 directory file. With MyEID we are going to implement session objects so that the card will clean them out in the next reset. For us it is important to be able to create a temporary key object on card as a result of C_UnwrapKey, and be able to use that key using PKCS#11.

OpenSC can be called by multiple applications. This could cause problems if multiple applications need a hardware session object and especially if one application does a reset. depending in the timing and how the hardware and software keep track of these session hardware objects, the hardware ans software could get confused.  This is similar to losing the login state to a card, which is a much easier problem, solved mostly by pin caching.



> 
> I think the new features shouldn't affect cards that emulate PKCS#15 operations. The code could be used to enable accessing these operations using PKCS#11 in future. Well, one thing to consider is that should we allow the unwrap function in the card driver to return the unwrapped key as a memory buffer, if the card cannot unwrap in hardware?

That is more a function of what attributes are requested in the session key template and what the card can or can not do.
I have not looked to see if PKCS#11 provides and help here.
I think the code should be designed to handle either case, and if the card can not do it return unsupported or whatever CKR_* the specs say.

> For now I didn't add a return buffer, because I think the whole point of unwrapping is to do it in hardware to keep the key safe, and if someone wants to unwrap keys to PC memory, it can be done using decrypt.
> 
>>> We haven’t yet decided how to tell driver and card, which key file 
>>> should receive the unwrapped key. We have thought of using manage security environment, but haven’t yet find a card independent way to set it in pkcs15-sec.c.
>> You could use the CKA_LABEL, or even a vendor supplied attribute for OpenSC, that could be used to pass info to pkcs15init when creating a key on the card.
>> Side issue:OpenSC needs to fix how it assigns CKA_VENDOR_DEFINED attributes. see:
>> https://github.com/OpenSC/OpenSC/pull/1131#issuecomment-323335738
>> For session keys, the handle to the key is good enough since the handle is unique for the session.
> 
> The empty target key is created in beginning of the operation (like in derive) and we get the object handle, containing file path if it's a token object, to the pkcs11-object.c level. I don't see problems here. Then we call sc_pkcs11_unwrap and go thru many function calls. Another thing is to transmit a reference in form of a file path or ID to the card driver for the actual crypto operation. For signing and decrypt operations the file ref to the key that performs the operation is transmitted to the driver in sc_security_env.file_ref. With many cards the driver transmits it to the card in an MSE:SET command APDU. We'd like to use the same logic for setting the target key for unwrapping. I added target_file_ref to sc_security_env struct to hold this file reference. ISO7816-4 or 8 don't clearly define how to use MSE:SET to prepare wrapping and unwrapping, but with this method drivers and cards could implement it in their own way.

As a last resort, we could always add a vendor provided attribute.

Sounds like you have most of the issues in hand, other then the multiple application problem of doing a reset in which case the login state, and the hardware session key are lost. The PKCS#11 code needs to handle what happens to the session objects if some other application resets the card. If its in memory it can still be used. If in hardware, it is most likely lost.



> 
> Just pushed a new version to 
> https://github.com/hhonkanen/OpenSC/tree/wrapping
> You can see there how I'm doing it.  This version can create a permanent target key object on card for a secret key using pkcs15init, in case CKA_TOKEN=TRUE.
> 
> If you would like to run the code, I added a little test program to GitHub.
> https://github.com/hhonkanen/WrapTest
> You can run it with a normal MyEID card and it can do all other parts of the wrapping operation with these parameters, except actually decrypting the key to the target file. You have to generate or import an RSA key pair to the card first and encrypt some data with the public key, then put the encrypted data to CK_BYTE wrappedKey[] before calling C_UnwrapKey.
> 
> I think we have to concentrate on the card implementation next to get further, but I am open to discussion and ideas about the OpenSC implementation. Especially I would like to hear what you like about passing the target file ref in sc_security_env_t and would there be some alternative ways.
> 
> - Hannu
> 
> -----Alkuperäinen viesti-----
> Lähettäjä: Douglas E Engert [mailto:dee...@gm...]
> Lähetetty: perjantai 22. syyskuuta 2017 21.30
> Vastaanottaja: ope...@li...
> Aihe: Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to 
> OpenSC
> 
> On 9/22/2017 8:32 AM, Aventra Development wrote:
>> Hi,
>>
>> I have committed the first version of C_UnwrapKey implementation to 
>> my branch at https://github.com/hhonkanen/OpenSC/tree/wrapping
>>
>> I hope you would have time to take a look.
>>
>> As we don’t yet even have a card that could perform the actual 
>> unwrapping operation, this code is not yet complete and it currently 
>> emulates unwrapping by doing a normal decrypt operation. It can be run and it goes all the way to the card driver when target object template has CKA_TOKEN=FALSE, but the code to store the pkcs#15 object is not yet complete. Anyway, from this commit you can see the logic I am planning to use.
> 
> I assume the above is just for testing. In either case if you can support both token and session objects that would be good. Also keep in mind some card drivers emulate some of the PKCS#15 operations, which usually means they can support session objects but not token objects.
> (The may support token objects but not via PKCS#11 or PKCS#15 but some other means.
> The OpenSC C_DeriveKey was written for such a card to support ECDH.)
> 
> 
> CKA_TOKEN=FALSE says the object is a session object which does not require any code to store the pkcs#15 object.
> CKA_TOKEN=TRUE says the object is a token object, so you would need to tell the token what to do with it.
> 
> 
>>
>> This implementation follows the same pattern as C_DeriveKey. The call goes for PKCS#11 to the driver like this:
>>
>>   1. C_UnwrapKey --> sc_create_object->pkcs15_create_object, to create the target PKCS#15 object to receive the key.
>>
>>                                pkcs15_create_secret_key calls pkcs15init to create the PKCS#15 structure and key EF on card.
>>
>>   2. We have a handle to the target object. From now on the calls go in very similar way like a decrypt or key derivation operation:
>>
>> C_UnwrapKey --> sc_pkcs11_unwrap->sc_pkcs11_unwrap_operation->pkcs15_prkey_unwrap->sc_pkcs15_unwrap.
>>
>> Here we format and set security environment and call card:
>>
>> use_key->sc_set_security_env
>>
>> use_key->sc_unwrap->myeid_unwrap_key.
>>
>> Before I started coding, I thought of two alternative ways:
>>
>>   1. Implement most of the stuff in pkcs15init as you suggested and 
>> create new pkcs15init operations  2. Go C_DeriveKey style.
>>
>> It was not an easy decision, but the main motives to go C_DeriveKey way were:
> 
> Good choice I like the C_DeriveKey choice especially for cards that are not true PKCS#15 cards.
>>
>>    * I noticed that after we have a target key object, the rest of the operation is actually similar to decrypt. The unwrapping operation is performed with a PKCS#11 key object, which supports specific
>>      mechanisms. This initial version supports only RSA, but in future we could have several mechanism for each supported key type, for example CKM_AES_ECB, CKM_AES_CBC, CKM_RSA_PKCS, CKM_RSA_X_509
>>      etc. The logic to handle a crypto operations with a specific object and a mechanism was already there.
>>    * there already was unwrap_key method defined in sc_pkcs11_object_ops.
>>    * there already was the working C_DeriveKey code. I thought it would be good to be consistent with it, because it does nearly the same thing.
>>    * I think this model fits for C_WrapKey as well. As a crypto operation it has the same characteristics, the data just goes into other direction.
>>
>> We haven’t yet decided how to tell driver and card, which key file 
>> should receive the unwrapped key. We have thought of using manage security environment, but haven’t yet find a card independent way to set it in pkcs15-sec.c.
>>
> 
> You could use the CKA_LABEL, or even a vendor supplied attribute for OpenSC, that could be used to pass info to pkcs15init when creating a key on the card.
> 
> Side issue:OpenSC needs to fix how it assigns CKA_VENDOR_DEFINED attributes. see:
> https://github.com/OpenSC/OpenSC/pull/1131#issuecomment-323335738
> 
> For session keys, the handle to the key is good enough since the handle is unique for the session.
> 
> 
>> Another thing we have to think about is do we need to implement a new 
>> function in pkcs15init/pkcs15-lib.c to create an empty secret key file to receive the unwrapped key. There is a function to store a secret key: sc_pkcs15init_store_secret_key, but it doesn’t currently work without key data.
>>
>> I am really looking forward to find such architecture that the 
>> community can accept and to have the code merged into master when it’s functional. Hoping to hear opinions on is this as good way to go or should we take a different approach.
>>
>> - Hannu
>>
>> *Lähettäjä:*Frank Morgner [mailto:fra...@gm...]
>> *Lähetetty:* maanantai 18. syyskuuta 2017 0.27
>> *Vastaanottaja:* Aventra Development <dev...@av...>
>> *Kopio:* ope...@li...
>> *Aihe:* Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to 
>> OpenSC
>>
>> OK, we'll see when you're fine with some working code.
>>
>> One more pointer I'd like to give is ISO 7816-8, which gives some 
>> example on how to import a private key using PUT DATA with DO 7F48 
>> (card holder private key template). As far as I know, OpenSC used to implement the ISO style of card interactions first, which then got mapped to other type of cards as well. So using the existing get_data and put_data hooks of the card driver would also be usable for key import. That being said, I know that the concept has been softened. There is the read_public_key callback, which following the ISO style should have been implemented with get_data...
>>
>> 2017-09-14 14:10 GMT+02:00 Aventra Development <dev...@av... <mailto:dev...@av...>>:
>>
>>      Thank you for your comments!
>>
>>      I have got quite far in implementing the first case of C_UnwrapKey that we need, which is unwrapping a secret key using an RSA key. During coding I have also realized that at least the part that
>>      creates the PKCS#15 object for the unwrapped key, adds it to SKDF and updates it to the card belongs naturally to pkcs15init. However, the part that performs the crypto operation to unwrap the key
>>      is very similar to decrypt and derive operations, so I ended up adding sc_pkcs15_unwrap() to pkcs15-sec.c. So in my current implementation what happens is:
>>
>>       1. The call to C_UnwrapKey is first handled in pkcs#11 level (pkcs11-object.c and mechanism.c)
>>       2. Via sc_pkcs11_object_ops we get into framework_pkcs15, I have added a function named pkcs15_prkey_unwrap()
>>       3. I use sc_pkcs15init_bind like in some other framework_pkcs15 functions, and call pkcs15init. I have added a new function sc_pkcs15init_unwrap_key()
>>       4. sc_pkcs15init_unwrap_key() creates the new key object (key EF) into card, updates SKDF, and calls sc_pkcs15_unwrap() in pkcs15-sec.c to perform the actual crypto operation on card.
>>       5. The card performs a decrypt operation and places the result into the key EF created by pkcs15init. (we don’t have this feature on card yet).
>>
>>      In driver level I initially added wrap and unwrap operations to sc_card_operations. I don’t have a strong opinion on which is better, this way or using sc_card_ctl. Still I think they fit quite
>>      well on the same level with decipher and compute_signature operations. But in the whole job this is actually a minor detail and can still be changed easily.
>>
>>      I am still not sure, can we do this in a way that is card 
>> independent enough in pkcs15-sec, or would it be better to implement 
>> a new pkcs15init operation (a new function pointer to
>>
>>      sc_pkcs15init_operations) which each card vendor could implement in their own way. We’ll see how it looks as I progress.
>>
>>      When I get my code in buildable and more solid state, I’ll commit it into my fork and you could take a look.
>>
>>      Got to keep the minidriver spec in mind. I am not very familiar on how the OpenSC minidriver interacts with rest of OpenSC, and I hope this doesn’t add too much complexity into my implementation.
>>      Probably the important thing is to make the low level implementation on card driver level usable with both minidriver and PKCS#11 way, because in higher level a parallel implementation could be
>>      added for the minidriver.
>>
>>      - Hannu
>>
>>      *Lähettäjä:*Frank Morgner [mailto:fra...@gm... <mailto:fra...@gm...>]
>>      *Lähetetty:* torstai 14. syyskuuta 2017 11.16
>>      *Vastaanottaja:* Aventra Development <dev...@av... <mailto:dev...@av...>>
>>      *Kopio:* ope...@li...
>> <mailto:ope...@li...>
>>
>>
>>      *Aihe:* Re: [Opensc-devel] Implementing C_WrapKey and 
>> C_UnwrapKey to OpenSC
>>
>>      In general your approach sounds good! But I have objections regarding the software architecture. Historically, key generation and key import has been done in pkcs15init. There are some other cards
>>      besides sc-hsm that are calling some control command in the card driver from pkcs15init. Basically, what you're asking for is to use pkcs15init functionality in PKCS#11. Instead of implementing
>>      everything in PKCS#11, it would be better to make pkcs15init available as DLL/LIB that can be loaded into OpenSC's PKCS#11 library. With this approach you would implement key wrapping in your
>>      card's operations in pkcs15init (possibly redirecting it to the driver in libopensc with a control command).
>>
>>      One more thing I'd like to throw in is that Microsoft also has its view of key wrapping. Have a look at Smart Card Minidriver Specification, v7.07 Figure B1. Process for key generation and
>>      insertion (https://msdn.microsoft.com/en-us/library/windows/hardware/dn631754(v=vs.85).aspx). Please make sure that your implementation has this spec in mind so that key wrapping can also be added
>>      to the minidriver.
>>
>>      Regards,
>>
>>      Frank.
>>
>>      2017-09-11 10:11 GMT+02:00 Aventra Development <dev...@av... <mailto:dev...@av...>>:
>>
>>          Thanks for the tip. Yes, the ECDH code looks like it can be used with slight modifications and expanded to perform unwrap.  Some more work is needed in the card/driver level to set up
>>          properties of the new key in the key EF on card according to the PKCS#11 attributes in the template.
>>
>>          What do you think about adding wrap and unwrap into sc_card_operations in opensc.h? Is there a risk of causing some trouble or should all go fine as long they're just set to NULL on cards that
>>          don't support them? If more cards would support these operations in future, this way each card wouldn't need to add new card specific SC_CARDCTL_xxx values.
>>
>>          - Hannu
>>
>>          -----Alkuperäinen viesti-----
>>          Lähettäjä: Douglas E Engert [mailto:dee...@gm... <mailto:dee...@gm...>]
>>          Lähetetty: perjantai 8. syyskuuta 2017 15.26
>>          Vastaanottaja: ope...@li... <mailto:ope...@li...>
>>          Aihe: Re: [Opensc-devel] Implementing C_WrapKey and 
>> C_UnwrapKey to OpenSC
>>
>>
>>          The ECDH can derive a key, which may be returned by the card or kept on the card.
>>          A Session object is created for the derived key. The code was written for a card that would return a secret key so the session object has CKA_TOKEN=FALSE.
>>
>>          So the derive code is very similar to the unwrap. You might want to start looking it.
>>
>>
>>          On 9/8/2017 6:32 AM, Aventra Development wrote:
>>           > Hi fellow OpenSC developers,
>>           >
>>           > Some of you may already know me from my contributions to mostly MyEID
>>           > driver. We are now starting a larger development project so I thought
>>           > a brief introduction would be appropriate. I am a developer at Aventra, Finland. Our target in this project is to implement C_WrapKey and C_UnwrapKey PKCS#11 functions into OpenSC and
>>          initially to the MyEID driver. At the same time we are going to implement this functionality into MyEID card.
>>           >
>>           > I have created a branch named "wrapping" in my OpenSC fork at
>>           > https://github.com/hhonkanen/OpenSC
>>           >
>>           > Before starting coding I have done some planning and split the work into sub tasks. Here are the tasks I have found:
>>           >
>>           > - implement wrapping and unwarpping in pkcs#15 level
>>           > (framework-pkcs15.c)
>>           >
>>           >                             * sc_pkcs11_object_ops already contains unwrap_key operation. wrap_key operation must be added.
>>           >
>>           >                             * implement pkcs15_skey_wrap_key, pkcs15_skey_unwrap_key etc...in framework_pkcs15.c and map the functions to                        sc_pkcs11_object_ops.
>>           >
>>           >                             * changes to register_mechamisms and functions called from there (for example sc_pkcs11_new_fw_mechanism).
>>           >
>>           >                               set CKF_WRAP and CKF_UNWRAP when appropriate.
>>           >
>>           >                             * parse the CKA_xxxx attributes and create
>>           > the needed PKCS#15 structures for the keys that will be created on
>>           > card during                            unwrapping operations
>>           >
>>           > - implement wrapping and unwrapping in pkcs15-sec and card driver level:
>>           >
>>           >                             * add wrap/unwrap functions to sc_card_driver. In SC-HSM driver these are implemented as driver specific card_ctl commands.
>>           >
>>           >                               I am not sure if we should go this way or add the new operations directly to sc_card_operations.
>>           >
>>           >                             * implement them in card-myeid.c
>>           >
>>           > * seems like I have to create functions like sc_pkcs15_wrap_key and sc_pkcs15_unwrap_key to do the work between pkcs15 and card layers.
>>           >
>>           > - implement the functions in PKCS#11 level:
>>           >
>>           >                            * implement C_WrapKey and C_UnwrapKey in
>>           > pkcs11-object.c. Check mechanism and attributes and call
>>           > framework_pkcs15
>>           >
>>           >                             * return the handle of wrapped key (in memory) or unwrapped key (on card) to the pkcs#11 level and to the caller.
>>           >
>>           > Some issues we have to think about:
>>           >
>>           > - It is still not totally clear to me how to begin implementing the
>>           > operations from PKCS#11 side (C_WrapKey and C_UnwrapKey in pkcs11-object.c). I think I am going to follow a similar pattern as in C_SignInit and C_DecryptInit. This will probably become
>>          clearer when I get started, but any tips are more than welcome.
>>           >
>>           > - Handling of secret key objects when CKA_TOKEN=FALSE. PKCS#11 doesn't
>>           > define where such session objects should be stored, but leaves it up
>>           > to implementation. We must have possibililty to have session objects on card. With this I mean key objects that are cleaned from the card in the next reset and the key material never leaves
>>          the card. We need this kind of objects in chained key wrapping operation. I am planning to implement it so that drivers could tell whether they can handle in card session objects. If a driver
>>          doesn't support them, they would be handled as in memory objects.
>>           >
>>           > - in addition to RSA and AES keys, we must be able to handle
>>           > CKK_GENERIC_SECRET objects which might be somewhat different to implement,  because lots of the key handling code is related to the key algorithm.
>>           >
>>           > Any feedback, tips and contributions in testing/code review will be greatly appreciated.
>>           >
>>           > Best regards,
>>           >
>>           > Hannu Honkanen
>>           >
>>           > Aventra
>>           >
>>           >
>>           >
>>           >
>> ---------------------------------------------------------------------
>> -
>>
>>           > -------- Check out the vibrant tech community on one of 
>> the world's
>>
>>           > most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>           >
>>           >
>>           >
>>           > _______________________________________________
>>           > Opensc-devel mailing list
>>           > Ope...@li... <mailto:Ope...@li...>
>>           > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>           >
>>
>>          --
>>
>>             Douglas E. Engert  <DEE...@gm... 
>> <mailto:DEE...@gm...>>
>>
>>
>>          ------------------------------------------------------------------------------
>>          Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
>>          Opensc-devel mailing list
>>          Ope...@li... <mailto:Ope...@li...>
>>          https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>          ------------------------------------------------------------------------------
>>          Check out the vibrant tech community on one of the world's most
>>          engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>          _______________________________________________
>>          Opensc-devel mailing list
>>          Ope...@li... <mailto:Ope...@li...>
>>          https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>>
>>      ------------------------------------------------------------------------------
>>      Check out the vibrant tech community on one of the world's most
>>      engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>      _______________________________________________
>>      Opensc-devel mailing list
>>      Ope...@li... <mailto:Ope...@li...>
>>      https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>> -------- Check out the vibrant tech community on one of the world's 
>> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
> 

-- 

  Douglas E. Engert  <DEE...@gm...>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Opensc-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensc-devel

Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC

[Aventra D. <dev...@av...>]

>I think I now understand your choice of adding this functionality to framework-pkcs15.c instead of framework->pkcs15init.c. I think it's OK to do so, though in general, the design decision to draw such a sharp line between both >frameworks is not very desirable.

I agree, but in this case I haven’t found a better way (at least yet).

>I'm not convinced that adding new boilerplate is a good idea, if it's unused. In case >of SC_CARD_CAP_ONCARD_SESSION_OBJECTS we could simply say that only one way is implemented and the other yields an error.

There is still one reason why I think this flag could be useful. In sense of key security and cryptographic security it is significant, whether a specific key remains all of its lifetime in hardware designed to protect it (a smart card in this case), or does it get stored in PC’s memory at some point. This way the driver could inform its users that it can handle a session key in hardware. The information is significant for someone who designs a cryptographic system. Hardware session object are common in HSM’s. With them operations can be chained keeping the sensitive data in the hardware all the time.

>What I'm a bit puzzled about, is that the current version (and the old one) of `sc_pkcs15_unwrap ` is functionally >almost equivalent to `sc_pkcs15_derive`. The only difference is that sc_pkcs15_derive directly calls sc_decipher (via >use_key), whereas sc_pkcs15_unwrap calls the driver specific method unwrap, which then calls myeid_decipher. I >don't understand why you're adding the extra boiler plate on the card driver level and not just go with use_key and an >adjusted security environment. Maybe I don't fully understand the use of C_Unwrap... do you have an example use >case for that?

We don’t have the actual wrapping operation implemented in MyEID card yet. The code to calls myeid_decipher from myeid_unwrap is just for testing and demonstrating the logic that leads there from PKCS#11 level. It has to be changed, when the card can actually do key unwrapping.

The key differences between decipher, derive and unwrap operations are:

  *   decipher returns the deciphered data to host’s memory and finally to the caller
  *   derive, in case of ECDH, can either return a session key to host’s memory or with cards that support it, keep the derived key in the card
  *   unwrap: main purpose of the operation is to decrypt a key INSIDE the card to form a new key object. It is needed to transfer a key into a smart card from some other environment, for example a HSM, so that it is never handled in plaintext form outside secure hardware.

I think the operation could be performed using the existing decipher function pointer as well. But maybe it is bit of a matter of taste how to do it. Because it is a logically different operation from deciphering data or key derivation, I thought it would be more clear for developers to have a dedicated function. But I understand that there are also some advantages in keeping the driver model simple and avoiding changes there.

- Hannu


Lähettäjä: Frank Morgner [mailto:fra...@gm...]
Lähetetty: keskiviikko 4. lokakuuta 2017 23.04
Vastaanottaja: Aventra Development <dev...@av...>
Kopio: ope...@li...
Aihe: Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC

I think I now understand your choice of adding this functionality to framework-pkcs15.c instead of framework-pkcs15init.c. I think it's OK to do so, though in general, the design decision to draw such a sharp line between both frameworks is not very desirable.

I'm not convinced that adding new boilerplate is a good idea, if it's unused. In case of SC_CARD_CAP_ONCARD_SESSION_OBJECTS we could simply say that only one way is implemented and the other yields an error.

What I'm a bit puzzled about, is that the current version (and the old one) of `sc_pkcs15_unwrap ` is functionally almost equivalent to `sc_pkcs15_derive`. The only difference is that sc_pkcs15_derive directly calls sc_decipher (via use_key), whereas sc_pkcs15_unwrap calls the driver specific method unwrap, which then calls myeid_decipher. I don't understand why you're adding the extra boiler plate on the card driver level and not just go with use_key and an adjusted security environment. Maybe I don't fully understand the use of C_Unwrap... do you have an example use case for that?

ISO 7816-8 (2004) Annex C gives a small example on how to use a combination of PUT DATA and MSE to import a key. Maybe that would also be possible for unwrapping a key.

Regards,
Frank.

2017-10-04 14:08 GMT+02:00 Aventra Development <dev...@av...<mailto:dev...@av...>>:
On 22. September 17, Douglas E Engert wrote:
>I assume the above is just for testing. In either case if you can support both token and session objects that would be good. Also keep in mind some card drivers emulate some of the PKCS#15 operations, which usually means they can support session objects but not token objects.
>(The may support token objects but not via PKCS#11 or PKCS#15 but some other means.
>The OpenSC C_DeriveKey was written for such a card to support ECDH.)

Back to wrapping after doing some other work for a while. Yes, at this point this is just to demonstrate the logic I have planned.

Regarding session objects, we want to support both software and hardware session objects. By PKCS#11 spec, they can be either implemented completely in software or stored in the token for the lifetime of the session. So we need to distinguish between software and on-card session objects. I added SC_CARD_CAP_ONCARD_SESSION_OBJECTS flag to let drivers tell if they can handle session objects on card.
For a hardware session object, we need to create the key object on card, but it is not needed to update the P15 directory file. With MyEID we are going to implement session objects so that the card will clean them out in the next reset. For us it is important to be able to create a temporary key object on card as a result of C_UnwrapKey, and be able to use that key using PKCS#11.

I think the new features shouldn't affect cards that emulate PKCS#15 operations. The code could be used to enable accessing these operations using PKCS#11 in future. Well, one thing to consider is that should we allow the unwrap function in the card driver to return the unwrapped key as a memory buffer, if the card cannot unwrap in hardware? For now I didn't add a return buffer, because I think the whole point of unwrapping is to do it in hardware to keep the key safe, and if someone wants to unwrap keys to PC memory, it can be done using decrypt.

>> We haven’t yet decided how to tell driver and card, which key file
>> should receive the unwrapped key. We have thought of using manage security environment, but haven’t yet find a card independent way to set it in pkcs15-sec.c.
>You could use the CKA_LABEL, or even a vendor supplied attribute for OpenSC, that could be used to pass info to pkcs15init when creating a key on the card.
>Side issue:OpenSC needs to fix how it assigns CKA_VENDOR_DEFINED attributes. see:
>https://github.com/OpenSC/OpenSC/pull/1131#issuecomment-323335738
>For session keys, the handle to the key is good enough since the handle is unique for the session.

The empty target key is created in beginning of the operation (like in derive) and we get the object handle, containing file path if it's a token object, to the pkcs11-object.c level. I don't see problems here. Then we call sc_pkcs11_unwrap and go thru many function calls. Another thing is to transmit a reference in form of a file path or ID to the card driver for the actual crypto operation. For signing and decrypt operations the file ref to the key that performs the operation is transmitted to the driver in sc_security_env.file_ref. With many cards the driver transmits it to the card in an MSE:SET command APDU. We'd like to use the same logic for setting the target key for unwrapping. I added target_file_ref to sc_security_env struct to hold this file reference. ISO7816-4 or 8 don't clearly define how to use MSE:SET to prepare wrapping and unwrapping, but with this method drivers and cards could implement it in their own way.

Just pushed a new version to https://github.com/hhonkanen/OpenSC/tree/wrapping
You can see there how I'm doing it.  This version can create a permanent target key object on card for a secret key using pkcs15init, in case CKA_TOKEN=TRUE.

If you would like to run the code, I added a little test program to GitHub.
https://github.com/hhonkanen/WrapTest
You can run it with a normal MyEID card and it can do all other parts of the wrapping operation with these parameters, except actually decrypting the key to the target file. You have to generate or import an RSA key pair to the card first and encrypt some data with the public key, then put the encrypted data to CK_BYTE wrappedKey[] before calling C_UnwrapKey.

I think we have to concentrate on the card implementation next to get further, but I am open to discussion and ideas about the OpenSC implementation. Especially I would like to hear what you like about passing the target file ref in sc_security_env_t and would there be some alternative ways.

- Hannu

-----Alkuperäinen viesti-----
Lähettäjä: Douglas E Engert [mailto:dee...@gm...<mailto:dee...@gm...>]
Lähetetty: perjantai 22. syyskuuta 2017 21.30
Vastaanottaja: ope...@li...<mailto:ope...@li...>
Aihe: Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC

On 9/22/2017 8:32 AM, Aventra Development wrote:
> Hi,
>
> I have committed the first version of C_UnwrapKey implementation to my
> branch at https://github.com/hhonkanen/OpenSC/tree/wrapping
>
> I hope you would have time to take a look.
>
> As we don’t yet even have a card that could perform the actual
> unwrapping operation, this code is not yet complete and it currently
> emulates unwrapping by doing a normal decrypt operation. It can be run and it goes all the way to the card driver when target object template has CKA_TOKEN=FALSE, but the code to store the pkcs#15 object is not yet complete. Anyway, from this commit you can see the logic I am planning to use.

I assume the above is just for testing. In either case if you can support both token and session objects that would be good. Also keep in mind some card drivers emulate some of the PKCS#15 operations, which usually means they can support session objects but not token objects.
(The may support token objects but not via PKCS#11 or PKCS#15 but some other means.
The OpenSC C_DeriveKey was written for such a card to support ECDH.)


CKA_TOKEN=FALSE says the object is a session object which does not require any code to store the pkcs#15 object.
CKA_TOKEN=TRUE says the object is a token object, so you would need to tell the token what to do with it.


>
> This implementation follows the same pattern as C_DeriveKey. The call goes for PKCS#11 to the driver like this:
>
>  1. C_UnwrapKey --> sc_create_object->pkcs15_create_object, to create the target PKCS#15 object to receive the key.
>
>                               pkcs15_create_secret_key calls pkcs15init to create the PKCS#15 structure and key EF on card.
>
>  2. We have a handle to the target object. From now on the calls go in very similar way like a decrypt or key derivation operation:
>
> C_UnwrapKey --> sc_pkcs11_unwrap->sc_pkcs11_unwrap_operation->pkcs15_prkey_unwrap->sc_pkcs15_unwrap.
>
> Here we format and set security environment and call card:
>
> use_key->sc_set_security_env
>
> use_key->sc_unwrap->myeid_unwrap_key.
>
> Before I started coding, I thought of two alternative ways:
>
>  1. Implement most of the stuff in pkcs15init as you suggested and
> create new pkcs15init operations  2. Go C_DeriveKey style.
>
> It was not an easy decision, but the main motives to go C_DeriveKey way were:

Good choice I like the C_DeriveKey choice especially for cards that are not true PKCS#15 cards.
>
>   * I noticed that after we have a target key object, the rest of the operation is actually similar to decrypt. The unwrapping operation is performed with a PKCS#11 key object, which supports specific
>     mechanisms. This initial version supports only RSA, but in future we could have several mechanism for each supported key type, for example CKM_AES_ECB, CKM_AES_CBC, CKM_RSA_PKCS, CKM_RSA_X_509
>     etc. The logic to handle a crypto operations with a specific object and a mechanism was already there.
>   * there already was unwrap_key method defined in sc_pkcs11_object_ops.
>   * there already was the working C_DeriveKey code. I thought it would be good to be consistent with it, because it does nearly the same thing.
>   * I think this model fits for C_WrapKey as well. As a crypto operation it has the same characteristics, the data just goes into other direction.
>
> We haven’t yet decided how to tell driver and card, which key file
> should receive the unwrapped key. We have thought of using manage security environment, but haven’t yet find a card independent way to set it in pkcs15-sec.c.
>

You could use the CKA_LABEL, or even a vendor supplied attribute for OpenSC, that could be used to pass info to pkcs15init when creating a key on the card.

Side issue:OpenSC needs to fix how it assigns CKA_VENDOR_DEFINED attributes. see:
https://github.com/OpenSC/OpenSC/pull/1131#issuecomment-323335738

For session keys, the handle to the key is good enough since the handle is unique for the session.


> Another thing we have to think about is do we need to implement a new
> function in pkcs15init/pkcs15-lib.c to create an empty secret key file to receive the unwrapped key. There is a function to store a secret key: sc_pkcs15init_store_secret_key, but it doesn’t currently work without key data.
>
> I am really looking forward to find such architecture that the
> community can accept and to have the code merged into master when it’s functional. Hoping to hear opinions on is this as good way to go or should we take a different approach.
>
> - Hannu
>
> *Lähettäjä:*Frank Morgner [mailto:fra...@gm...<mailto:fra...@gm...>]
> *Lähetetty:* maanantai 18. syyskuuta 2017 0.27
> *Vastaanottaja:* Aventra Development <dev...@av...<mailto:dev...@av...>>
> *Kopio:* ope...@li...<mailto:ope...@li...>
> *Aihe:* Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to
> OpenSC
>
> OK, we'll see when you're fine with some working code.
>
> One more pointer I'd like to give is ISO 7816-8, which gives some
> example on how to import a private key using PUT DATA with DO 7F48
> (card holder private key template). As far as I know, OpenSC used to implement the ISO style of card interactions first, which then got mapped to other type of cards as well. So using the existing get_data and put_data hooks of the card driver would also be usable for key import. That being said, I know that the concept has been softened. There is the read_public_key callback, which following the ISO style should have been implemented with get_data...
>
> 2017-09-14 14:10 GMT+02:00 Aventra Development <dev...@av...<mailto:dev...@av...> <mailto:dev...@av...<mailto:dev...@av...>>>:
>
>     Thank you for your comments!
>
>     I have got quite far in implementing the first case of C_UnwrapKey that we need, which is unwrapping a secret key using an RSA key. During coding I have also realized that at least the part that
>     creates the PKCS#15 object for the unwrapped key, adds it to SKDF and updates it to the card belongs naturally to pkcs15init. However, the part that performs the crypto operation to unwrap the key
>     is very similar to decrypt and derive operations, so I ended up adding sc_pkcs15_unwrap() to pkcs15-sec.c. So in my current implementation what happens is:
>
>      1. The call to C_UnwrapKey is first handled in pkcs#11 level (pkcs11-object.c and mechanism.c)
>      2. Via sc_pkcs11_object_ops we get into framework_pkcs15, I have added a function named pkcs15_prkey_unwrap()
>      3. I use sc_pkcs15init_bind like in some other framework_pkcs15 functions, and call pkcs15init. I have added a new function sc_pkcs15init_unwrap_key()
>      4. sc_pkcs15init_unwrap_key() creates the new key object (key EF) into card, updates SKDF, and calls sc_pkcs15_unwrap() in pkcs15-sec.c to perform the actual crypto operation on card.
>      5. The card performs a decrypt operation and places the result into the key EF created by pkcs15init. (we don’t have this feature on card yet).
>
>     In driver level I initially added wrap and unwrap operations to sc_card_operations. I don’t have a strong opinion on which is better, this way or using sc_card_ctl. Still I think they fit quite
>     well on the same level with decipher and compute_signature operations. But in the whole job this is actually a minor detail and can still be changed easily.
>
>     I am still not sure, can we do this in a way that is card
> independent enough in pkcs15-sec, or would it be better to implement a
> new pkcs15init operation (a new function pointer to
>
>     sc_pkcs15init_operations) which each card vendor could implement in their own way. We’ll see how it looks as I progress.
>
>     When I get my code in buildable and more solid state, I’ll commit it into my fork and you could take a look.
>
>     Got to keep the minidriver spec in mind. I am not very familiar on how the OpenSC minidriver interacts with rest of OpenSC, and I hope this doesn’t add too much complexity into my implementation.
>     Probably the important thing is to make the low level implementation on card driver level usable with both minidriver and PKCS#11 way, because in higher level a parallel implementation could be
>     added for the minidriver.
>
>     - Hannu
>
>     *Lähettäjä:*Frank Morgner [mailto:fra...@gm...<mailto:fra...@gm...> <mailto:fra...@gm...<mailto:fra...@gm...>>]
>     *Lähetetty:* torstai 14. syyskuuta 2017 11.16
>     *Vastaanottaja:* Aventra Development <dev...@av...<mailto:dev...@av...> <mailto:dev...@av...<mailto:dev...@av...>>>
>     *Kopio:* ope...@li...<mailto:ope...@li...>
> <mailto:ope...@li...<mailto:ope...@li...>>
>
>
>     *Aihe:* Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey
> to OpenSC
>
>     In general your approach sounds good! But I have objections regarding the software architecture. Historically, key generation and key import has been done in pkcs15init. There are some other cards
>     besides sc-hsm that are calling some control command in the card driver from pkcs15init. Basically, what you're asking for is to use pkcs15init functionality in PKCS#11. Instead of implementing
>     everything in PKCS#11, it would be better to make pkcs15init available as DLL/LIB that can be loaded into OpenSC's PKCS#11 library. With this approach you would implement key wrapping in your
>     card's operations in pkcs15init (possibly redirecting it to the driver in libopensc with a control command).
>
>     One more thing I'd like to throw in is that Microsoft also has its view of key wrapping. Have a look at Smart Card Minidriver Specification, v7.07 Figure B1. Process for key generation and
>     insertion (https://msdn.microsoft.com/en-us/library/windows/hardware/dn631754(v=vs.85).aspx). Please make sure that your implementation has this spec in mind so that key wrapping can also be added
>     to the minidriver.
>
>     Regards,
>
>     Frank.
>
>     2017-09-11 10:11 GMT+02:00 Aventra Development <dev...@av...<mailto:dev...@av...> <mailto:dev...@av...<mailto:dev...@av...>>>:
>
>         Thanks for the tip. Yes, the ECDH code looks like it can be used with slight modifications and expanded to perform unwrap.  Some more work is needed in the card/driver level to set up
>         properties of the new key in the key EF on card according to the PKCS#11 attributes in the template.
>
>         What do you think about adding wrap and unwrap into sc_card_operations in opensc.h? Is there a risk of causing some trouble or should all go fine as long they're just set to NULL on cards that
>         don't support them? If more cards would support these operations in future, this way each card wouldn't need to add new card specific SC_CARDCTL_xxx values.
>
>         - Hannu
>
>         -----Alkuperäinen viesti-----
>         Lähettäjä: Douglas E Engert [mailto:dee...@gm...<mailto:dee...@gm...> <mailto:dee...@gm...<mailto:dee...@gm...>>]
>         Lähetetty: perjantai 8. syyskuuta 2017 15.26
>         Vastaanottaja: ope...@li...<mailto:ope...@li...> <mailto:ope...@li...<mailto:ope...@li...>>
>         Aihe: Re: [Opensc-devel] Implementing C_WrapKey and
> C_UnwrapKey to OpenSC
>
>
>         The ECDH can derive a key, which may be returned by the card or kept on the card.
>         A Session object is created for the derived key. The code was written for a card that would return a secret key so the session object has CKA_TOKEN=FALSE.
>
>         So the derive code is very similar to the unwrap. You might want to start looking it.
>
>
>         On 9/8/2017 6:32 AM, Aventra Development wrote:
>          > Hi fellow OpenSC developers,
>          >
>          > Some of you may already know me from my contributions to mostly MyEID
>          > driver. We are now starting a larger development project so I thought
>          > a brief introduction would be appropriate. I am a developer at Aventra, Finland. Our target in this project is to implement C_WrapKey and C_UnwrapKey PKCS#11 functions into OpenSC and
>         initially to the MyEID driver. At the same time we are going to implement this functionality into MyEID card.
>          >
>          > I have created a branch named "wrapping" in my OpenSC fork at
>          > https://github.com/hhonkanen/OpenSC
>          >
>          > Before starting coding I have done some planning and split the work into sub tasks. Here are the tasks I have found:
>          >
>          > - implement wrapping and unwarpping in pkcs#15 level
>          > (framework-pkcs15.c)
>          >
>          >                             * sc_pkcs11_object_ops already contains unwrap_key operation. wrap_key operation must be added.
>          >
>          >                             * implement pkcs15_skey_wrap_key, pkcs15_skey_unwrap_key etc...in framework_pkcs15.c and map the functions to                        sc_pkcs11_object_ops.
>          >
>          >                             * changes to register_mechamisms and functions called from there (for example sc_pkcs11_new_fw_mechanism).
>          >
>          >                               set CKF_WRAP and CKF_UNWRAP when appropriate.
>          >
>          >                             * parse the CKA_xxxx attributes and create
>          > the needed PKCS#15 structures for the keys that will be created on
>          > card during                            unwrapping operations
>          >
>          > - implement wrapping and unwrapping in pkcs15-sec and card driver level:
>          >
>          >                             * add wrap/unwrap functions to sc_card_driver. In SC-HSM driver these are implemented as driver specific card_ctl commands.
>          >
>          >                               I am not sure if we should go this way or add the new operations directly to sc_card_operations.
>          >
>          >                             * implement them in card-myeid.c
>          >
>          > * seems like I have to create functions like sc_pkcs15_wrap_key and sc_pkcs15_unwrap_key to do the work between pkcs15 and card layers.
>          >
>          > - implement the functions in PKCS#11 level:
>          >
>          >                            * implement C_WrapKey and C_UnwrapKey in
>          > pkcs11-object.c. Check mechanism and attributes and call
>          > framework_pkcs15
>          >
>          >                             * return the handle of wrapped key (in memory) or unwrapped key (on card) to the pkcs#11 level and to the caller.
>          >
>          > Some issues we have to think about:
>          >
>          > - It is still not totally clear to me how to begin implementing the
>          > operations from PKCS#11 side (C_WrapKey and C_UnwrapKey in pkcs11-object.c). I think I am going to follow a similar pattern as in C_SignInit and C_DecryptInit. This will probably become
>         clearer when I get started, but any tips are more than welcome.
>          >
>          > - Handling of secret key objects when CKA_TOKEN=FALSE. PKCS#11 doesn't
>          > define where such session objects should be stored, but leaves it up
>          > to implementation. We must have possibililty to have session objects on card. With this I mean key objects that are cleaned from the card in the next reset and the key material never leaves
>         the card. We need this kind of objects in chained key wrapping operation. I am planning to implement it so that drivers could tell whether they can handle in card session objects. If a driver
>         doesn't support them, they would be handled as in memory objects.
>          >
>          > - in addition to RSA and AES keys, we must be able to handle
>          > CKK_GENERIC_SECRET objects which might be somewhat different to implement,  because lots of the key handling code is related to the key algorithm.
>          >
>          > Any feedback, tips and contributions in testing/code review will be greatly appreciated.
>          >
>          > Best regards,
>          >
>          > Hannu Honkanen
>          >
>          > Aventra
>          >
>          >
>          >
>          >
> ----------------------------------------------------------------------
>
>          > -------- Check out the vibrant tech community on one of the
> world's
>
>          > most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>          >
>          >
>          >
>          > _______________________________________________
>          > Opensc-devel mailing list
>          > Ope...@li...<mailto:Ope...@li...> <mailto:Ope...@li...<mailto:Ope...@li...>>
>          > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>          >
>
>         --
>
>            Douglas E. Engert  <DEE...@gm...<mailto:DEE...@gm...>
> <mailto:DEE...@gm...<mailto:DEE...@gm...>>>
>
>
>         ------------------------------------------------------------------------------
>         Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
>         Opensc-devel mailing list
>         Ope...@li...<mailto:Ope...@li...> <mailto:Ope...@li...<mailto:Ope...@li...>>
>         https://lists.sourceforge.net/lists/listinfo/opensc-devel
>         ------------------------------------------------------------------------------
>         Check out the vibrant tech community on one of the world's most
>         engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>         _______________________________________________
>         Opensc-devel mailing list
>         Ope...@li...<mailto:Ope...@li...> <mailto:Ope...@li...<mailto:Ope...@li...>>
>         https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     Opensc-devel mailing list
>     Ope...@li...<mailto:Ope...@li...> <mailto:Ope...@li...<mailto:Ope...@li...>>
>     https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>
>
> ----------------------------------------------------------------------
> -------- Check out the vibrant tech community on one of the world's
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...<mailto:Ope...@li...>
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <DEE...@gm...<mailto:DEE...@gm...>>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Opensc-devel mailing list
Ope...@li...<mailto:Ope...@li...>
https://lists.sourceforge.net/lists/listinfo/opensc-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Opensc-devel mailing list
Ope...@li...<mailto:Ope...@li...>
https://lists.sourceforge.net/lists/listinfo/opensc-devel

Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC

[Frank M. <fra...@gm...>]

I think I now understand your choice of adding this functionality to
framework-pkcs15.c instead of framework-pkcs15init.c. I think it's OK to do
so, though in general, the design decision to draw such a sharp line
between both frameworks is not very desirable.

I'm not convinced that adding new boilerplate is a good idea, if it's
unused. In case of SC_CARD_CAP_ONCARD_SESSION_OBJECTS we could simply say
that only one way is implemented and the other yields an error.

What I'm a bit puzzled about, is that the current version (and the old one)
of `sc_pkcs15_unwrap ` is functionally almost equivalent to
`sc_pkcs15_derive`. The only difference is that sc_pkcs15_derive directly
calls sc_decipher (via use_key), whereas sc_pkcs15_unwrap calls the driver
specific method unwrap, which then calls myeid_decipher. I don't understand
why you're adding the extra boiler plate on the card driver level and not
just go with use_key and an adjusted security environment. Maybe I don't
fully understand the use of C_Unwrap... do you have an example use case for
that?

ISO 7816-8 (2004) Annex C gives a small example on how to use a combination
of PUT DATA and MSE to import a key. Maybe that would also be possible for
unwrapping a key.

Regards,
Frank.

2017-10-04 14:08 GMT+02:00 Aventra Development <dev...@av...>:

> On 22. September 17, Douglas E Engert wrote:
> >I assume the above is just for testing. In either case if you can support
> both token and session objects that would be good. Also keep in mind some
> card drivers emulate some of the PKCS#15 operations, which usually means
> they can support session objects but not token objects.
> >(The may support token objects but not via PKCS#11 or PKCS#15 but some
> other means.
> >The OpenSC C_DeriveKey was written for such a card to support ECDH.)
>
> Back to wrapping after doing some other work for a while. Yes, at this
> point this is just to demonstrate the logic I have planned.
>
> Regarding session objects, we want to support both software and hardware
> session objects. By PKCS#11 spec, they can be either implemented completely
> in software or stored in the token for the lifetime of the session. So we
> need to distinguish between software and on-card session objects. I added
> SC_CARD_CAP_ONCARD_SESSION_OBJECTS flag to let drivers tell if they can
> handle session objects on card.
> For a hardware session object, we need to create the key object on card,
> but it is not needed to update the P15 directory file. With MyEID we are
> going to implement session objects so that the card will clean them out in
> the next reset. For us it is important to be able to create a temporary key
> object on card as a result of C_UnwrapKey, and be able to use that key
> using PKCS#11.
>
> I think the new features shouldn't affect cards that emulate PKCS#15
> operations. The code could be used to enable accessing these operations
> using PKCS#11 in future. Well, one thing to consider is that should we
> allow the unwrap function in the card driver to return the unwrapped key as
> a memory buffer, if the card cannot unwrap in hardware? For now I didn't
> add a return buffer, because I think the whole point of unwrapping is to do
> it in hardware to keep the key safe, and if someone wants to unwrap keys to
> PC memory, it can be done using decrypt.
>
> >> We haven’t yet decided how to tell driver and card, which key file
> >> should receive the unwrapped key. We have thought of using manage
> security environment, but haven’t yet find a card independent way to set it
> in pkcs15-sec.c.
> >You could use the CKA_LABEL, or even a vendor supplied attribute for
> OpenSC, that could be used to pass info to pkcs15init when creating a key
> on the card.
> >Side issue:OpenSC needs to fix how it assigns CKA_VENDOR_DEFINED
> attributes. see:
> >https://github.com/OpenSC/OpenSC/pull/1131#issuecomment-323335738
> >For session keys, the handle to the key is good enough since the handle
> is unique for the session.
>
> The empty target key is created in beginning of the operation (like in
> derive) and we get the object handle, containing file path if it's a token
> object, to the pkcs11-object.c level. I don't see problems here. Then we
> call sc_pkcs11_unwrap and go thru many function calls. Another thing is to
> transmit a reference in form of a file path or ID to the card driver for
> the actual crypto operation. For signing and decrypt operations the file
> ref to the key that performs the operation is transmitted to the driver in
> sc_security_env.file_ref. With many cards the driver transmits it to the
> card in an MSE:SET command APDU. We'd like to use the same logic for
> setting the target key for unwrapping. I added target_file_ref to
> sc_security_env struct to hold this file reference. ISO7816-4 or 8 don't
> clearly define how to use MSE:SET to prepare wrapping and unwrapping, but
> with this method drivers and cards could implement it in their own way.
>
> Just pushed a new version to https://github.com/hhonkanen/
> OpenSC/tree/wrapping
> You can see there how I'm doing it.  This version can create a permanent
> target key object on card for a secret key using pkcs15init, in case
> CKA_TOKEN=TRUE.
>
> If you would like to run the code, I added a little test program to GitHub.
> https://github.com/hhonkanen/WrapTest
> You can run it with a normal MyEID card and it can do all other parts of
> the wrapping operation with these parameters, except actually decrypting
> the key to the target file. You have to generate or import an RSA key pair
> to the card first and encrypt some data with the public key, then put the
> encrypted data to CK_BYTE wrappedKey[] before calling C_UnwrapKey.
>
> I think we have to concentrate on the card implementation next to get
> further, but I am open to discussion and ideas about the OpenSC
> implementation. Especially I would like to hear what you like about passing
> the target file ref in sc_security_env_t and would there be some
> alternative ways.
>
> - Hannu
>
> -----Alkuperäinen viesti-----
> Lähettäjä: Douglas E Engert [mailto:dee...@gm...]
> Lähetetty: perjantai 22. syyskuuta 2017 21.30
> Vastaanottaja: ope...@li...
> Aihe: Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to OpenSC
>
> On 9/22/2017 8:32 AM, Aventra Development wrote:
> > Hi,
> >
> > I have committed the first version of C_UnwrapKey implementation to my
> > branch at https://github.com/hhonkanen/OpenSC/tree/wrapping
> >
> > I hope you would have time to take a look.
> >
> > As we don’t yet even have a card that could perform the actual
> > unwrapping operation, this code is not yet complete and it currently
> > emulates unwrapping by doing a normal decrypt operation. It can be run
> and it goes all the way to the card driver when target object template has
> CKA_TOKEN=FALSE, but the code to store the pkcs#15 object is not yet
> complete. Anyway, from this commit you can see the logic I am planning to
> use.
>
> I assume the above is just for testing. In either case if you can support
> both token and session objects that would be good. Also keep in mind some
> card drivers emulate some of the PKCS#15 operations, which usually means
> they can support session objects but not token objects.
> (The may support token objects but not via PKCS#11 or PKCS#15 but some
> other means.
> The OpenSC C_DeriveKey was written for such a card to support ECDH.)
>
>
> CKA_TOKEN=FALSE says the object is a session object which does not require
> any code to store the pkcs#15 object.
> CKA_TOKEN=TRUE says the object is a token object, so you would need to
> tell the token what to do with it.
>
>
> >
> > This implementation follows the same pattern as C_DeriveKey. The call
> goes for PKCS#11 to the driver like this:
> >
> >  1. C_UnwrapKey --> sc_create_object->pkcs15_create_object, to create
> the target PKCS#15 object to receive the key.
> >
> >                               pkcs15_create_secret_key calls pkcs15init
> to create the PKCS#15 structure and key EF on card.
> >
> >  2. We have a handle to the target object. From now on the calls go in
> very similar way like a decrypt or key derivation operation:
> >
> > C_UnwrapKey --> sc_pkcs11_unwrap->sc_pkcs11_unwrap_operation->pkcs15_
> prkey_unwrap->sc_pkcs15_unwrap.
> >
> > Here we format and set security environment and call card:
> >
> > use_key->sc_set_security_env
> >
> > use_key->sc_unwrap->myeid_unwrap_key.
> >
> > Before I started coding, I thought of two alternative ways:
> >
> >  1. Implement most of the stuff in pkcs15init as you suggested and
> > create new pkcs15init operations  2. Go C_DeriveKey style.
> >
> > It was not an easy decision, but the main motives to go C_DeriveKey way
> were:
>
> Good choice I like the C_DeriveKey choice especially for cards that are
> not true PKCS#15 cards.
> >
> >   * I noticed that after we have a target key object, the rest of the
> operation is actually similar to decrypt. The unwrapping operation is
> performed with a PKCS#11 key object, which supports specific
> >     mechanisms. This initial version supports only RSA, but in future we
> could have several mechanism for each supported key type, for example
> CKM_AES_ECB, CKM_AES_CBC, CKM_RSA_PKCS, CKM_RSA_X_509
> >     etc. The logic to handle a crypto operations with a specific object
> and a mechanism was already there.
> >   * there already was unwrap_key method defined in sc_pkcs11_object_ops.
> >   * there already was the working C_DeriveKey code. I thought it would
> be good to be consistent with it, because it does nearly the same thing.
> >   * I think this model fits for C_WrapKey as well. As a crypto operation
> it has the same characteristics, the data just goes into other direction.
> >
> > We haven’t yet decided how to tell driver and card, which key file
> > should receive the unwrapped key. We have thought of using manage
> security environment, but haven’t yet find a card independent way to set it
> in pkcs15-sec.c.
> >
>
> You could use the CKA_LABEL, or even a vendor supplied attribute for
> OpenSC, that could be used to pass info to pkcs15init when creating a key
> on the card.
>
> Side issue:OpenSC needs to fix how it assigns CKA_VENDOR_DEFINED
> attributes. see:
> https://github.com/OpenSC/OpenSC/pull/1131#issuecomment-323335738
>
> For session keys, the handle to the key is good enough since the handle is
> unique for the session.
>
>
> > Another thing we have to think about is do we need to implement a new
> > function in pkcs15init/pkcs15-lib.c to create an empty secret key file
> to receive the unwrapped key. There is a function to store a secret key:
> sc_pkcs15init_store_secret_key, but it doesn’t currently work without key
> data.
> >
> > I am really looking forward to find such architecture that the
> > community can accept and to have the code merged into master when it’s
> functional. Hoping to hear opinions on is this as good way to go or should
> we take a different approach.
> >
> > - Hannu
> >
> > *Lähettäjä:*Frank Morgner [mailto:fra...@gm...]
> > *Lähetetty:* maanantai 18. syyskuuta 2017 0.27
> > *Vastaanottaja:* Aventra Development <dev...@av...>
> > *Kopio:* ope...@li...
> > *Aihe:* Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey to
> > OpenSC
> >
> > OK, we'll see when you're fine with some working code.
> >
> > One more pointer I'd like to give is ISO 7816-8, which gives some
> > example on how to import a private key using PUT DATA with DO 7F48
> > (card holder private key template). As far as I know, OpenSC used to
> implement the ISO style of card interactions first, which then got mapped
> to other type of cards as well. So using the existing get_data and put_data
> hooks of the card driver would also be usable for key import. That being
> said, I know that the concept has been softened. There is the
> read_public_key callback, which following the ISO style should have been
> implemented with get_data...
> >
> > 2017-09-14 14:10 GMT+02:00 Aventra Development <dev...@av...
> <mailto:dev...@av...>>:
> >
> >     Thank you for your comments!
> >
> >     I have got quite far in implementing the first case of C_UnwrapKey
> that we need, which is unwrapping a secret key using an RSA key. During
> coding I have also realized that at least the part that
> >     creates the PKCS#15 object for the unwrapped key, adds it to SKDF
> and updates it to the card belongs naturally to pkcs15init. However, the
> part that performs the crypto operation to unwrap the key
> >     is very similar to decrypt and derive operations, so I ended up
> adding sc_pkcs15_unwrap() to pkcs15-sec.c. So in my current implementation
> what happens is:
> >
> >      1. The call to C_UnwrapKey is first handled in pkcs#11 level
> (pkcs11-object.c and mechanism.c)
> >      2. Via sc_pkcs11_object_ops we get into framework_pkcs15, I have
> added a function named pkcs15_prkey_unwrap()
> >      3. I use sc_pkcs15init_bind like in some other framework_pkcs15
> functions, and call pkcs15init. I have added a new function
> sc_pkcs15init_unwrap_key()
> >      4. sc_pkcs15init_unwrap_key() creates the new key object (key EF)
> into card, updates SKDF, and calls sc_pkcs15_unwrap() in pkcs15-sec.c to
> perform the actual crypto operation on card.
> >      5. The card performs a decrypt operation and places the result into
> the key EF created by pkcs15init. (we don’t have this feature on card yet).
> >
> >     In driver level I initially added wrap and unwrap operations to
> sc_card_operations. I don’t have a strong opinion on which is better, this
> way or using sc_card_ctl. Still I think they fit quite
> >     well on the same level with decipher and compute_signature
> operations. But in the whole job this is actually a minor detail and can
> still be changed easily.
> >
> >     I am still not sure, can we do this in a way that is card
> > independent enough in pkcs15-sec, or would it be better to implement a
> > new pkcs15init operation (a new function pointer to
> >
> >     sc_pkcs15init_operations) which each card vendor could implement in
> their own way. We’ll see how it looks as I progress.
> >
> >     When I get my code in buildable and more solid state, I’ll commit it
> into my fork and you could take a look.
> >
> >     Got to keep the minidriver spec in mind. I am not very familiar on
> how the OpenSC minidriver interacts with rest of OpenSC, and I hope this
> doesn’t add too much complexity into my implementation.
> >     Probably the important thing is to make the low level implementation
> on card driver level usable with both minidriver and PKCS#11 way, because
> in higher level a parallel implementation could be
> >     added for the minidriver.
> >
> >     - Hannu
> >
> >     *Lähettäjä:*Frank Morgner [mailto:fra...@gm... <mailto:
> fra...@gm...>]
> >     *Lähetetty:* torstai 14. syyskuuta 2017 11.16
> >     *Vastaanottaja:* Aventra Development <dev...@av...
> <mailto:dev...@av...>>
> >     *Kopio:* ope...@li...
> > <mailto:ope...@li...>
> >
> >
> >     *Aihe:* Re: [Opensc-devel] Implementing C_WrapKey and C_UnwrapKey
> > to OpenSC
> >
> >     In general your approach sounds good! But I have objections
> regarding the software architecture. Historically, key generation and key
> import has been done in pkcs15init. There are some other cards
> >     besides sc-hsm that are calling some control command in the card
> driver from pkcs15init. Basically, what you're asking for is to use
> pkcs15init functionality in PKCS#11. Instead of implementing
> >     everything in PKCS#11, it would be better to make pkcs15init
> available as DLL/LIB that can be loaded into OpenSC's PKCS#11 library. With
> this approach you would implement key wrapping in your
> >     card's operations in pkcs15init (possibly redirecting it to the
> driver in libopensc with a control command).
> >
> >     One more thing I'd like to throw in is that Microsoft also has its
> view of key wrapping. Have a look at Smart Card Minidriver Specification,
> v7.07 Figure B1. Process for key generation and
> >     insertion (https://msdn.microsoft.com/en-us/library/windows/
> hardware/dn631754(v=vs.85).aspx). Please make sure that your
> implementation has this spec in mind so that key wrapping can also be added
> >     to the minidriver.
> >
> >     Regards,
> >
> >     Frank.
> >
> >     2017-09-11 10:11 GMT+02:00 Aventra Development <
> dev...@av... <mailto:dev...@av...>>:
> >
> >         Thanks for the tip. Yes, the ECDH code looks like it can be used
> with slight modifications and expanded to perform unwrap.  Some more work
> is needed in the card/driver level to set up
> >         properties of the new key in the key EF on card according to the
> PKCS#11 attributes in the template.
> >
> >         What do you think about adding wrap and unwrap into
> sc_card_operations in opensc.h? Is there a risk of causing some trouble or
> should all go fine as long they're just set to NULL on cards that
> >         don't support them? If more cards would support these operations
> in future, this way each card wouldn't need to add new card specific
> SC_CARDCTL_xxx values.
> >
> >         - Hannu
> >
> >         -----Alkuperäinen viesti-----
> >         Lähettäjä: Douglas E Engert [mailto:dee...@gm... <mailto:
> dee...@gm...>]
> >         Lähetetty: perjantai 8. syyskuuta 2017 15.26
> >         Vastaanottaja: ope...@li... <mailto:
> ope...@li...>
> >         Aihe: Re: [Opensc-devel] Implementing C_WrapKey and
> > C_UnwrapKey to OpenSC
> >
> >
> >         The ECDH can derive a key, which may be returned by the card or
> kept on the card.
> >         A Session object is created for the derived key. The code was
> written for a card that would return a secret key so the session object has
> CKA_TOKEN=FALSE.
> >
> >         So the derive code is very similar to the unwrap. You might want
> to start looking it.
> >
> >
> >         On 9/8/2017 6:32 AM, Aventra Development wrote:
> >          > Hi fellow OpenSC developers,
> >          >
> >          > Some of you may already know me from my contributions to
> mostly MyEID
> >          > driver. We are now starting a larger development project so I
> thought
> >          > a brief introduction would be appropriate. I am a developer
> at Aventra, Finland. Our target in this project is to implement C_WrapKey
> and C_UnwrapKey PKCS#11 functions into OpenSC and
> >         initially to the MyEID driver. At the same time we are going to
> implement this functionality into MyEID card.
> >          >
> >          > I have created a branch named "wrapping" in my OpenSC fork at
> >          > https://github.com/hhonkanen/OpenSC
> >          >
> >          > Before starting coding I have done some planning and split
> the work into sub tasks. Here are the tasks I have found:
> >          >
> >          > - implement wrapping and unwarpping in pkcs#15 level
> >          > (framework-pkcs15.c)
> >          >
> >          >                             * sc_pkcs11_object_ops already
> contains unwrap_key operation. wrap_key operation must be added.
> >          >
> >          >                             * implement pkcs15_skey_wrap_key,
> pkcs15_skey_unwrap_key etc...in framework_pkcs15.c and map the functions to
>                        sc_pkcs11_object_ops.
> >          >
> >          >                             * changes to register_mechamisms
> and functions called from there (for example sc_pkcs11_new_fw_mechanism).
> >          >
> >          >                               set CKF_WRAP and CKF_UNWRAP
> when appropriate.
> >          >
> >          >                             * parse the CKA_xxxx attributes
> and create
> >          > the needed PKCS#15 structures for the keys that will be
> created on
> >          > card during                            unwrapping operations
> >          >
> >          > - implement wrapping and unwrapping in pkcs15-sec and card
> driver level:
> >          >
> >          >                             * add wrap/unwrap functions to
> sc_card_driver. In SC-HSM driver these are implemented as driver specific
> card_ctl commands.
> >          >
> >          >                               I am not sure if we should go
> this way or add the new operations directly to sc_card_operations.
> >          >
> >          >                             * implement them in card-myeid.c
> >          >
> >          > * seems like I have to create functions like
> sc_pkcs15_wrap_key and sc_pkcs15_unwrap_key to do the work between pkcs15
> and card layers.
> >          >
> >          > - implement the functions in PKCS#11 level:
> >          >
> >          >                            * implement C_WrapKey and
> C_UnwrapKey in
> >          > pkcs11-object.c. Check mechanism and attributes and call
> >          > framework_pkcs15
> >          >
> >          >                             * return the handle of wrapped
> key (in memory) or unwrapped key (on card) to the pkcs#11 level and to the
> caller.
> >          >
> >          > Some issues we have to think about:
> >          >
> >          > - It is still not totally clear to me how to begin
> implementing the
> >          > operations from PKCS#11 side (C_WrapKey and C_UnwrapKey in
> pkcs11-object.c). I think I am going to follow a similar pattern as in
> C_SignInit and C_DecryptInit. This will probably become
> >         clearer when I get started, but any tips are more than welcome.
> >          >
> >          > - Handling of secret key objects when CKA_TOKEN=FALSE.
> PKCS#11 doesn't
> >          > define where such session objects should be stored, but
> leaves it up
> >          > to implementation. We must have possibililty to have session
> objects on card. With this I mean key objects that are cleaned from the
> card in the next reset and the key material never leaves
> >         the card. We need this kind of objects in chained key wrapping
> operation. I am planning to implement it so that drivers could tell whether
> they can handle in card session objects. If a driver
> >         doesn't support them, they would be handled as in memory objects.
> >          >
> >          > - in addition to RSA and AES keys, we must be able to handle
> >          > CKK_GENERIC_SECRET objects which might be somewhat different
> to implement,  because lots of the key handling code is related to the key
> algorithm.
> >          >
> >          > Any feedback, tips and contributions in testing/code review
> will be greatly appreciated.
> >          >
> >          > Best regards,
> >          >
> >          > Hannu Honkanen
> >          >
> >          > Aventra
> >          >
> >          >
> >          >
> >          >
> > ----------------------------------------------------------------------
> >
> >          > -------- Check out the vibrant tech community on one of the
> > world's
> >
> >          > most engaging tech sites, Slashdot.org!
> http://sdm.link/slashdot
> >          >
> >          >
> >          >
> >          > _______________________________________________
> >          > Opensc-devel mailing list
> >          > Ope...@li... <mailto:
> Ope...@li...>
> >          > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >          >
> >
> >         --
> >
> >            Douglas E. Engert  <DEE...@gm...
> > <mailto:DEE...@gm...>>
> >
> >
> >         ------------------------------------------------------------
> ------------------
> >         Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> >         Opensc-devel mailing list
> >         Ope...@li... <mailto:Opensc-devel@lists.
> sourceforge.net>
> >         https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >         ------------------------------------------------------------
> ------------------
> >         Check out the vibrant tech community on one of the world's most
> >         engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >         _______________________________________________
> >         Opensc-devel mailing list
> >         Ope...@li... <mailto:Opensc-devel@lists.
> sourceforge.net>
> >         https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >
> >
> >     ------------------------------------------------------------
> ------------------
> >     Check out the vibrant tech community on one of the world's most
> >     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >     _______________________________________________
> >     Opensc-devel mailing list
> >     Ope...@li... <mailto:Opensc-devel@lists.
> sourceforge.net>
> >     https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >
> >
> >
> > ----------------------------------------------------------------------
> > -------- Check out the vibrant tech community on one of the world's
> > most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> >
> > _______________________________________________
> > Opensc-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >
>
> --
>
>   Douglas E. Engert  <DEE...@gm...>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most engaging
> tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>