Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
Hi, On Tue, May 22, 2012 at 10:18 PM, Peter Marschall pe...@adpm.de wrote: Martin started the extension of pkcs15-openpgp.c to support OpenPGP v2 cards which I continued. (but again: without write support) What was basically removing some v1 related hard-coded constants (like 1024 bit keys) and adding some more parsing of on-card structures, created with gpg --card-edit. Martin's works is already in opensc's staging branch at github, as I took it as a base for some of my changes and had it pulled in. Best PEter -- Peter Marschall pe...@adpm.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
Hi, On Wednesday, 23. May 2012, Nguyễn Hồng Quân wrote: Or the layout with PKCS15-AppDF is mandatory from the pkcs15 view? The string 5015 does not occur in the PKCS#15 specs ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-15/pkcs-15v1_1.pdf So, in my opinion it does not seem to be required. But I'd like to have more confirmation for that opinion. Can anyone corrobate this assumtion? Viktor, Martin? Nevertheless it is hard-coded in * src/libopensc/pkcs15.c: sc_pkcs15_bind_internal() * src/tools/pkcs15-init.c: do_assert_pristine() If yes, I will consider to change the emulated file system layout in the OpenPGP driver. If it is not requested in the specs, I ocnsider relying on it an error which should be fixed in the files I mentioned above. In my opinion, removing false assumptions from opensc's code would make it more standards compliant, while changing the emulated file structure in card-openpgp.c would only be a kludge fro this special case. @Peter Marschall: You and me are working on OpenPGP. How do u think about changing the emulated file layout. How should I do to not break too much the code base? I'd rather not change the openpgp file layout unless it is absolutely required by the PKCS#15 spec. If you are going to use the common pkcs15 and pkcs15init framework , you have to fill at least the 'write' hadle with the meanigfull actions . https://github.com/hongquan/OpenSC-OpenPGP/blob/openpgp/src/libopensc/car d-openpgp.c#L827 Inside this handle the 'PUT DATA' or else can be used -- it's doesn't matter. Not thinking about that yet - first we need to find out whether 5015 is required by PKCS#15 Best -- Peter Marschall pe...@adpm.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
On Wednesday, 23. May 2012, Peter Koch wrote: Hi Quân [ ... ] So the only thing pkcs1-init might do is to change the contents of certain already existing DOs on an OpenPGP card. And this might happen via emulated UPDATE BINARY commands (which would do PUT DATA instead). With CREATE / WRITE / UPDATE commands properly emulated, it might even work with them (i.e. they'd need to map to PUT DATA sowehow). Of course this would only work with opensc, not with pute APDUs sent. But changing the contents of DOs on an OpenPGP card is exactly what the gpg administration tools do, so why reimplementing this into pkcs15-init Because it * looks possible ;-) * helps to better understand PC/SC, opensc, gpg, ... * is fun * may improve opensc's PKCS#* support for OpenPGP cards * ... And I'm afraigth that those things that gpg --edit-card cannot do are impossible to do. How can one write a certificate to an OpenPGP card using gpg? What about the DOs 0101 - 0104? You cannot create a private key file on an OpenPGP card. There are 3 of them already on every OpenPGP card and the only thing you can do is to replace their contents. For the physical layer you're absolutely right. But why shouldn't it be possible on the emulated logical layer. By opensc's abstraction machanism we have more freedom here. Same situation with certificates: You cannot create them. There's one DO on an OpenPGP card meant to store one certificate. You can replace its content with a PUT DATA but I don't see any possibility to create additional certificates. Dito I consider Quân's goal a very honorable one. Even if we do not reach 100% compatibility, his work should be honored. Peter Dito ;-) -- Peter Marschall pe...@adpm.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
Hi Peter But changing the contents of DOs on an OpenPGP card is exactly what the gpg administration tools do, so why reimplementing this into pkcs15-init Because it * looks possible ;-) * helps to better understand PC/SC, opensc, gpg, ... * is fun * may improve opensc's PKCS#* support for OpenPGP cards * ... I did not know that the pkcs15-init routines are used by opensc-pkcs11. So I was wonderung why Quân was trying to extend the functionality of the pkcs15-init executable. In the meantime I understood what he is trying to do And I'm afraigth that those things that gpg --edit-card cannot do are impossible to do. How can one write a certificate to an OpenPGP card using gpg? gpg does not use certificates so you cannot store a cert into an OpenPGP card with gpg. I use my own PKCS#11-library (available at www.smartcard-auth.de) and download the cert with Firefox. Firefox will then store the certifiate into my Cryptostick. What about the DOs 0101 - 0104? These are DOs that are not used by gpg. Unfortunately the maximal length of these DOs is 254 bytes. Otherwise one could use then to store additional certificates. When TrueCrypt is configured with my OpenPGP PKCS#11-library I'm using one of these DOs to store the TrueCrypt key. I consider Quân's goal a very honorable one. So do I Even if e do not reach 100% compatibility, his work should be honored. Absolutely right, My only intention was to start a discussion about the direction Quân should take. Peter Dito ;-) Dito :-) ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
On 05/27/2012 10:20 PM, Peter Marschall wrote: How can one write a certificate to an OpenPGP card using gpg? To share with you, the GPG2 has supported to write certificate to OpenPGP card (though it is not used by GPG ^^) http://lists.gnupg.org/pipermail/gnupg-users/2011-February/040661.html -- Regards, Quân ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
Hello, On Tue, May 22, 2012 at 10:18 PM, Peter Marschall pe...@adpm.de wrote: Martin started the extension of pkcs15-openpgp.c to support OpenPGP v2 cards which I continued. (but again: without write support) What was basically removing some v1 related hard-coded constants (like 1024 bit keys) and adding some more parsing of on-card structures, created with gpg --card-edit. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
Hi Quân I still don't understand what you are trying to do - maybe you can explain that in more detail: The purpose of pkcs15-init is to create a PKCS#15 filesystem layout on a card. The purpose of a pkca15-emulation routine is to make OpenSC believe that a card has a PKCS#15 filesystem which in reality does NOT have such a layout. We have such an emulation for OpenPGP cards and OpenPGP cards don't have a PKCS#15 layout and there is no way to create such a layout on an OpenPGP card due to the lack of a CREATE EF/DF/DO command. So the only thing pkcs1-init might do is to change the contents of certain already existing DOs on an OpenPGP card. And this might happen via emulated UPDATE BINARY commands (which would do PUT DATA instead). But changing the contents of DOs on an OpenPGP card is exactly what the gpg administration tools do, so why reimplementing this into pkcs15-init And I'm afraigth that those things that gpg --edit-card cannot do are impossible to do. You cannot create a private key file on an OpenPGP card. There are 3 of them already on every OpenPGP card and the only thing you can do is to replace their contents. Same situation with certificates: You cannot create them. There's one DO on an OpenPGP card meant to store one certificate. You can replace its content with a PUT DATA but I don't see any possibility to create additional certificates. Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
Hi Peter, I do not intent to use pkcs15-init to *create* file system. I just need it to *modify* file content from PKCS#11 interface. I wish I could avoid pkcs15-init, but there is no other way, as Viktor confirmed. The OpenSC-PKCS11 always refers to pkcs15-init to do writing/updating. The purpose of pkcs15-init is to create a PKCS#15 filesystem layout on a card. In fact, it does more things than just creating PKCS#15 file system. You can see the sc_pkcs15init_operations struct in pkcs15-init.h file. It has members store_key, generate_key, emu_store_data which I may want to use. So the only thing pkcs1-init might do is to change the contents of certain already existing DOs on an OpenPGP card. And this might happen via emulated UPDATE BINARY commands (which would do PUT DATA instead). Yes, that's what I need from pkcs15-init. But changing the contents of DOs on an OpenPGP card is exactly what the gpg administration tools do, so why reimplementing this into pkcs15-init Because I want it possible to do those administrative things from Firefox/Thunderbird, via PKCS#11. For example, I want to use Firefox to import X.509 certificate from *.p12 file to OpenPGP card. Or when a website use Firefox API to generate key and certificate (like startssl.com), I want the generated certificate to be stored right into the card. And I'm afraigth that those things that gpg --edit-card cannot do are impossible to do. You cannot create a private key file on an OpenPGP card. There are 3 of them already on every OpenPGP card and the only thing you can do is to replace their contents. Same situation with certificates: You cannot create them. There's one DO on an OpenPGP card meant to store one certificate. You can replace its content with a PUT DATA but I don't see any possibility to create additional certificates. Yes, I don't want to create, just want to change. I won't implement the create parts in pkcs15-init, just the update parts. For the create parts, I will redirect it to change existing objects. If my explanation is not clear, don't hesitate to ask more :). Thank for your care. -- Regards, Quân ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
Hi, On Sunday, 20. May 2012, Peter Koch wrote: Peter Marshall seems to have written most of the current OpenPGP driver and Jan Suhr from German Privacy Foundation told me that Martin Paljak already tried to enhance the driver. I mostly re-factored card-openpg.c for better extensibility and extended it to also support OpenPGPv2 cards. The basic idea of the otriginal emulation was untouched I aso tried to lay foundations for (maybe very limited) write support, but a) real life took its toll b) I did not get the real idea for thw write support Martin started the extension of pkcs15-openpgp.c to support OpenPGP v2 cards which I continued. (but again: without write support) While I currently don't have an idea for a breakthrough, I'll try to stay up- to-date, adding small fixes where needed (and hoping for genius striking me ;-) Could you give us some information what the status of OpenPGP support is right now. See above ;-) Here are my own impressions - if they are wrong, please correct me: 1: OpenPGP cards do NOT have a filesystem like other smart cards. Instead of storing informations in EFs which are located in DFs an OpenPGP card stores information in Data Objects. Correct, but card-openpgp.c emulates a file system by treating plain DOs as EFs and constructed (via ASN.1's TLV encoding) as DFs with the ASN.1 label inside as the EFs / DFs in the next level down. Simply try opensc-explorer on an initialized OpenPGPv2 card, and you'll get the idea. Here my conclusion is: Without EFs and DFs and in particular without commands to create EFs and DFs pkcs15-init does not make any sense. Hmm, it depends. While you cannot create real DFs or EFs, I do not consider it impossible to implement write support through the emulation: i.. * for a DO that gets emulated to an EF, it should be possible to detect the write to the EF in the emulation layer and convert this to an DO update * for DFs it might become a bit more tricky. (Maybe this is not needed - needs a very close look at the specs + the right ideas ;-) 2: The current driver emulates SELECT and READ BINARY APDUs by reading from the corresponding Data Objects. I believe this was done in order to emulate a (read only) PKCS#15 file layout. If that was true - is there any hope to extend this emulation? I'd personally would not hold my breath. But maybe Nguyễn Hồng Quân is the one with that idea that give the breakthrough. 3: What features are missing in the current implementation and what bugs should be fixed? I definitely cannot tell, as I do not know what is needed in the PKCS15 and/or PCS11 levels. I consider opensc heaily under-documented w.r.t how everything is tied togeth (this is not specific to opensc alone, but seems to be specific to security related software in general ;-) Best Peter -- Peter Marschall pe...@adpm.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
Hi Viktor,
Thanks for your guide, but...
On 05/21/2012 09:00 PM, Viktor Tarasov wrote:
5015 comes from your pkcs15init profile
https://github.com/hongquan/OpenSC-OpenPGP/commit/9b2ea7689b461c31b7ffda736d2c9dc332491562#L1R59
where your crypto objects are put inside the 'DF PKCS15-AppDF'.
Path for this DF is not defined in openpgp profile,
so, it takes it from the upper profile -- pkcs15.profile.
https://github.com/hongquan/OpenSC-OpenPGP/blob/openpgp/src/pkcs15init/pkcs15.profile#L135
Never tried it myself, but you can try the openpgp profile without
'PKCS15-AppDF'.
I removed the PKCS15-AppDF from the openpgp.profile (see my attachment)
and bring up template key-domain block to right under DF MF, but the
pkcs15-init still fills 5015 to the path:
0xb72236c0 09:33:58.561 [pkcs15-init]
pkcs15-lib.c:1530:sc_pkcs15init_store_certificate: Store
cert(Certificate,ID:707d8f9e04a18d5e7a4b3c3adebe8124cda8c310,der(0x9dd82a0,753))
0xb72236c0 09:33:58.562 [pkcs15-init]
pkcs15-lib.c:1720:sc_pkcs15init_store_data: called
0xb72236c0 09:33:58.562 [pkcs15-init]
pkcs15-lib.c:2274:select_object_path: called
0xb72236c0 09:33:58.562 [pkcs15-init]
pkcs15-lib.c:2299:select_object_path: key-domain.certificate @3f005015
(auth_id.len=0)
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:691:sc_profile_instantiate_template: Instantiating template
key-domain at 3f005015
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:774:sc_profile_instantiate_file: Instantiated private-key at
3f0050155f48
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:775:sc_profile_instantiate_file: parent=PKCS15-AppDF@3f005015
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:774:sc_profile_instantiate_file: Instantiated public-key at
3f0050157f49
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:775:sc_profile_instantiate_file: parent=PKCS15-AppDF@3f005015
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:774:sc_profile_instantiate_file: Instantiated certificate at
3f0050157f21
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:775:sc_profile_instantiate_file: parent=PKCS15-AppDF@3f005015
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:774:sc_profile_instantiate_file: Instantiated privdata at
3f0050150101
0xb72236c0 09:33:58.562 [pkcs15-init]
profile.c:775:sc_profile_instantiate_file: parent=PKCS15-AppDF@3f005015
0xb72236c0 09:33:58.562 [pkcs15-init]
pkcs15-lib.c:2321:select_object_path: instantiated template path
3f0050157f21
0xb72236c0 09:33:58.562 [pkcs15-init]
pkcs15-lib.c:2350:select_object_path: returns object path '3f0050157f21'
...
0xb72236c0 09:33:58.562 [pkcs15-init]
pkcs15-lib.c:528:sc_pkcs15init_delete_by_path: trying to delete
'3f0050157f21'
0xb72236c0 09:33:58.562 [pkcs15-init] card.c:571:sc_select_file: called;
type=2, path=3f0050157f21
0xb72236c0 09:33:58.562 [pkcs15-init]
card-openpgp.c:714:pgp_select_file: called
0xb72236c0 09:33:58.562 [pkcs15-init]
card-openpgp.c:739:pgp_select_file: returning with: -1201 (File not found)
Or the layout with PKCS15-AppDF is mandatory from the pkcs15 view?
If yes, I will consider to change the emulated file system layout in the
OpenPGP driver.
@Peter Marschall: You and me are working on OpenPGP. How do u think
about changing the emulated file layout. How should I do to not break
too much the code base?
If you are going to use the common pkcs15 and pkcs15init framework ,
you have to fill at least the 'write' hadle with the meanigfull actions .
https://github.com/hongquan/OpenSC-OpenPGP/blob/openpgp/src/libopensc/card-openpgp.c#L827
Inside this handle the 'PUT DATA' or else can be used -- it's doesn't
matter.
Thanks.
--
Regards,
Quân
#
# PKCS15 profile, generic information.
# This profile is loaded before any card specific profile.
#
cardinfo {
min-pin-length = 6;
# max length should be overridden in the per-card profile
max-pin-length = 12; # To be defined
}
# Default settings.
# This option block will always be processed.
option default {
macros {
protected = *=$SOPIN, READ=NONE;
unprotected = *=NONE;
so-pin-flags= local, initialized, soPin;
so-min-pin-length = 8;
so-pin-attempts = 3;
so-auth-id = FF;
odf-size= 256;
aodf-size = 256;
cdf-size= 512;
prkdf-size = 256;
pukdf-size = 256;
dodf-size = 256;
}
}
# Define reasonable limits for PINs and PUK
# Note that we do not set a file path or reference
# for the user pin; that is done dynamically.
PIN user-pin {
attempts= 3;
flags = local, initialized;
}
PIN so-pin {
auth-id = $so-auth-id;
attempts= $so-pin-attempts;
min-length = $so-min-pin-length;
flags = $so-pin-flags;
}
filesystem {
DF MF {
path= 3F00;
type= DF;
#
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
On Mon, May 21, 2012 at 3:48 AM, Nguyễn Hồng Quân quanngu...@mbm.vn wrote: Hi Peter, On 05/21/2012 04:35 AM, Peter Koch wrote: Here are my own impressions - if they are wrong, please correct me: 1: OpenPGP cards do NOT have a filesystem like other smart cards. Instead of storing informations in EFs which are located in DFs an OpenPGP card stores information in Data Objects. Here my conclusion is: Without EFs and DFs and in particular without commands to create EFs and DFs pkcs15-init does not make any sense. Yes, but the pkcs15-init binding for OpenPGP card will implement only a small part: importing certificate, generate keys. It won't create DF EFs. The reason why I need pkcs15-init binding is that I want it possible to import certificate via PKCS#11 interface (using Firefox). While researching how to achieve it, I tried with the pkcs11-tool and found that doing import certificate needs the pkcs15-init binding. I will appreciate if someone point me another way to do, avoiding pkcs15-init. No other way if you are going to use the pkcs11 framework of OpenSC. The pkcs11 framework uses pkcs15init API. 2: The current driver emulates SELECT and READ BINARY APDUs by reading from the corresponding Data Objects. I believe this was done in order to emulate a (read only) PKCS#15 file layout. If that was true - is there any hope to extend this emulation? Yes, but it seems that this emulated file layout does not match the PKCS#15 very well, leading to the problem which I described in this topic http://www.opensc-project.org/pipermail/opensc-devel/2012-May/018018.html Card specific emulator do not emulates the file system but exposes the pkcs15 objects with their attributes. These attributes genarally contain some 'path'. This 'path' can-be/is treated by the card specific libopensc driver. To resume, in the card specific pkcs15 emulator you can assign some attribute value, that will have some meaning in your card specific libopensc driver, that in its turn will perform a card specific low level operation. In that manner the card specific implementation of 'file system' is hidden from pkcs15 level. 3: What features are missing in the current implementation and what bugs should be fixed? What's new in my own branch: - Write support for normal DOs (the Extended Header List DO - 4D - is not supported yet. This DO is used for key import). - Expose certificate (stored in the 7F21 DO) to PKCS#11 app. Things I want to do next is to support key import and certificate import. Beside the absence of pkcs15init support, afais, the openpgp libopensc driver have no support for any operation that could change the card's content: write, update, delete, generate, import, ... -- Regards, Quân ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
Hi Viktor, On 05/21/2012 05:10 PM, Viktor Tarasov wrote: 2: The current driver emulates SELECT and READ BINARY APDUs by reading from the corresponding Data Objects. I believe this was done in order to emulate a (read only) PKCS#15 file layout. If that was true - is there any hope to extend this emulation? Yes, but it seems that this emulated file layout does not match the PKCS#15 very well, leading to the problem which I described in this topic http://www.opensc-project.org/pipermail/opensc-devel/2012-May/018018.html Card specific emulator do not emulates the file system but exposes the pkcs15 objects with their attributes. These attributes genarally contain some 'path'. This 'path' can-be/is treated by the card specific libopensc driver. I think this is right for pkcs15 binding in libopensc folder, but not for pkcs15init binding in pkcs15init folder. For example, here is how I expose the certificate object, located at path 3F007F21, to pkcs15: sc_format_path(3F007F21, cert_info.path); strlcpy(cert_obj.label, Cardholder certificate, sizeof(cert_obj.label)); r = sc_pkcs15emu_add_x509_cert(p15card, cert_obj, cert_info); However, when come to pkcs15init, the path is read from the pkcs15.profile, then openpgp.profile, and it is 3F0050157F21 instead 3F007F21 (the additional 5015 comes from pkcs15.profile). I have not found a way to intervene the path reading to change 3F0050157F21 to 3F007F21 (what the lower driver needs) yet. Beside the absence of pkcs15init support, afais, the openpgp libopensc driver have no support for any operation that could change the card's content: write, update, delete, generate, import, ... At low level, the OpenPG card uses PUT DATA command instead of UPDATE BINARY to write content. I implemented that put_data function for OpenPGP driver in my github repository (https://github.com/hongquan/OpenSC-OpenPGP/commits/openpgp). -- Regards, Quân ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
On Mon, May 21, 2012 at 1:22 PM, Nguyễn Hồng Quân quanngu...@mbm.vn wrote: Hi Viktor, On 05/21/2012 05:10 PM, Viktor Tarasov wrote: 2: The current driver emulates SELECT and READ BINARY APDUs by reading from the corresponding Data Objects. I believe this was done in order to emulate a (read only) PKCS#15 file layout. If that was true - is there any hope to extend this emulation? Yes, but it seems that this emulated file layout does not match the PKCS#15 very well, leading to the problem which I described in this topic http://www.opensc-project.org/pipermail/opensc-devel/2012-May/018018.html Card specific emulator do not emulates the file system but exposes the pkcs15 objects with their attributes. These attributes genarally contain some 'path'. This 'path' can-be/is treated by the card specific libopensc driver. I think this is right for pkcs15 binding in libopensc folder, but not for pkcs15init binding in pkcs15init folder. For example, here is how I expose the certificate object, located at path 3F007F21, to pkcs15: sc_format_path(3F007F21, cert_info.path); strlcpy(cert_obj.label, Cardholder certificate, sizeof(cert_obj.label)); r = sc_pkcs15emu_add_x509_cert(p15card, cert_obj, cert_info); However, when come to pkcs15init, the path is read from the pkcs15.profile, then openpgp.profile, and it is 3F0050157F21 instead 3F007F21 (the additional 5015 comes from pkcs15.profile). I have not found a way to intervene the path reading to change 3F0050157F21 to 3F007F21 (what the lower driver needs) yet. 5015 comes from your pkcs15init profile https://github.com/hongquan/OpenSC-OpenPGP/commit/9b2ea7689b461c31b7ffda736d2c9dc332491562#L1R59 where your crypto objects are put inside the 'DF PKCS15-AppDF'. Path for this DF is not defined in openpgp profile, so, it takes it from the upper profile -- pkcs15.profile. https://github.com/hongquan/OpenSC-OpenPGP/blob/openpgp/src/pkcs15init/pkcs15.profile#L135 Never tried it myself, but you can try the openpgp profile without 'PKCS15-AppDF'. Beside the absence of pkcs15init support, afais, the openpgp libopensc driver have no support for any operation that could change the card's content: write, update, delete, generate, import, ... At low level, the OpenPG card uses PUT DATA command instead of UPDATE BINARY to write content. I implemented that put_data function for OpenPGP driver in my github repository ( https://github.com/hongquan/OpenSC-OpenPGP/commits/openpgp). If you are going to use the common pkcs15 and pkcs15init framework , you have to fill at least the 'write' hadle with the meanigfull actions . https://github.com/hongquan/OpenSC-OpenPGP/blob/openpgp/src/libopensc/card-openpgp.c#L827 Inside this handle the 'PUT DATA' or else can be used -- it's doesn't matter. -- Regards, Quân Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
Hi all! Early this year I was asked by the German Privacy Foundation wether I was willing to enhance OpenSC support for their CryptoStick. http://www.crypto-stick.com/2011/opensc-pkcs11-driver-development I wrote a PKCS#11-library for OpenPGP cards in 2010 so I have some experience with this kind of card. But I did not have enough time to do this job and I was unsure wether full OpenSC support for OpenPGP card was passible or not. Now Nguyễn Hồng Quân is trying to do this and I'm not sure wether he is going into the right direction. So my suggestion is to discuss the right direction first here on the mailing list. Peter Marshall seems to have written most of the current OpenPGP driver and Jan Suhr from German Privacy Foundation told me that Martin Paljak already tried to enhance the driver. Could you give us some information what the status of OpenPGP support is right now. In the end of last year there has be an initiative by the German Privacy Foundation to extend OpenSC's support of OpenPGP [1]. I don't know about it's exact status, but the Job's status of the job offer is closed as fixed [2]. I think, Nguyễn, you should try to find out if they have what you need. At least the job's description looks like the stuff you are trying to realize. [1] http://www.opensc-project.org/pipermail/opensc-devel/2011-December/017541.html [2] https://www.freelancer.com/projects/C-Programming-Computer-Security/patch-OpenSC-support-OpenPGP-Card.html -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACE http://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc pgpiM7I2uQNx2.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenPGP card / Cryptostick - current status???
Hi Early this year I was asked by the German Privacy Foundation wether I was willing to enhance OpenSC support for their CryptoStick. http://www.crypto-stick.com/2011/opensc-pkcs11-driver-development I wrote a PKCS#11-library for OpenPGP cards in 2010 so I have some experience with this kind of card. But I did not have enough time to do this job and I was unsure wether full OpenSC support for OpenPGP card was passible or not. Now Nguyễn Hồng Quân is trying to do this and I'm not sure wether he is going into the right direction. So my suggestion is to discuss the right direction first here on the mailing list. Peter Marshall seems to have written most of the current OpenPGP driver and Jan Suhr from German Privacy Foundation told me that Martin Paljak already tried to enhance the driver. Could you give us some information what the status of OpenPGP support is right now. Here are my own impressions - if they are wrong, please correct me: 1: OpenPGP cards do NOT have a filesystem like other smart cards. Instead of storing informations in EFs which are located in DFs an OpenPGP card stores information in Data Objects. Here my conclusion is: Without EFs and DFs and in particular without commands to create EFs and DFs pkcs15-init does not make any sense. 2: The current driver emulates SELECT and READ BINARY APDUs by reading from the corresponding Data Objects. I believe this was done in order to emulate a (read only) PKCS#15 file layout. If that was true - is there any hope to extend this emulation? 3: What features are missing in the current implementation and what bugs should be fixed? Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
Hi Peter, On 05/21/2012 04:35 AM, Peter Koch wrote: Here are my own impressions - if they are wrong, please correct me: 1: OpenPGP cards do NOT have a filesystem like other smart cards. Instead of storing informations in EFs which are located in DFs an OpenPGP card stores information in Data Objects. Here my conclusion is: Without EFs and DFs and in particular without commands to create EFs and DFs pkcs15-init does not make any sense. Yes, but the pkcs15-init binding for OpenPGP card will implement only a small part: importing certificate, generate keys. It won't create DF EFs. The reason why I need pkcs15-init binding is that I want it possible to import certificate via PKCS#11 interface (using Firefox). While researching how to achieve it, I tried with the pkcs11-tool and found that doing import certificate needs the pkcs15-init binding. I will appreciate if someone point me another way to do, avoiding pkcs15-init. 2: The current driver emulates SELECT and READ BINARY APDUs by reading from the corresponding Data Objects. I believe this was done in order to emulate a (read only) PKCS#15 file layout. If that was true - is there any hope to extend this emulation? Yes, but it seems that this emulated file layout does not match the PKCS#15 very well, leading to the problem which I described in this topic http://www.opensc-project.org/pipermail/opensc-devel/2012-May/018018.html 3: What features are missing in the current implementation and what bugs should be fixed? What's new in my own branch: - Write support for normal DOs (the Extended Header List DO - 4D - is not supported yet. This DO is used for key import). - Expose certificate (stored in the 7F21 DO) to PKCS#11 app. Things I want to do next is to support key import and certificate import. -- Regards, Quân ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
