Re: [opensc-devel] questions on {ERASE, WRITE, UPDATE} BINARY commands
Hi Andreas, thanks a ton. That explains it very well and answers all my questions. On Friday, 8. June 2012, Andreas Schwier (ML) wrote: Hi Peter, ERASE and WRITE are left-overs from the old smart card days. Most - if not all - cards and applications today only implement UPDATE BINARY. There is also no common understanding that UPDATE BINARY must not extend the length of an EF. Some implementations maintain a maximum EF and a current EF size. The maximum size is typically set in CREATE FILE, whereas the current EF size depends on the amount of data written to the EF. An EF may start with no data contained and and UPDATE BINARY command with P1|P2 = Length of EF (or zero based offset after last byte ;-) appends the amount of data provided in the C-Data of the APDU. Usually gaps are not allowed, so an offset beyond end-of-file + 1 gives SW1/SW2=6B00. Other implementations allocate the full EF size at creation, so you can immediately read from the EF, even though no data has been written yet. Hope this helps, Andreas Am 07.06.2012 22:01, schrieb Peter Marschall: Hi, thanks for the quick reply/correction. On Thursday, 7. June 2012, Martin Paljak wrote: On Thu, Jun 7, 2012 at 10:35 PM, Martin Paljak mar...@martinpaljak.net wrote: Hello, On Thu, Jun 7, 2012 at 10:24 PM, Peter Marschall pe...@adpm.de wrote: Here they are: * What's the exact difference between WRITE BINARY UPDATE BINARY? My understanding of the spec is that WRITE BINARY can extend a file's size, while UPDATE BINARY can only update data elements that are already within the file (i.e. in the range [0 .. file_size-1]). Is my understanding correct or did I misunderstand the specscompletely? AFAIU either can change file size (which can be done though 7816-9). Correction, can NOT change file size. Does that mean that none of them can change the number of data elements that are in the file ? This seems to contradict the sentence in ISO 7816-4 7.2.4 WRITE BINARY which states: - the write-once of the bits given in the command data field (the command shall be aborted if thestring of data units is not in the logical erased state) To me that sentence sounds like WRITE BINARY is an operation that A) can only be used on data that is logically reset, (i.e. once WRITE_BINARY was performed, it cannot be used on the same data any more without a preceding ERASE BINARY of that region) B) can extend the number of data units in the file (this is what I sloppily called existing_file_size in my previous mail) In the other hand, ISO 7816-4 7.2.4 UPDATE BINARY says: the command initialtes the update of the bits already present in an EF ... This is what I interpret as can only update existing data units in the file, but not create more. Am I completely wrong? Are there interpretation helpers for the spec available somewhere? While I am at it: Would you mind to pull Pull Request #53 https://github.com/OpenSC/OpenSC/pull/53 into the staging branch of github's open/opensc? (It is a little bit frustrating to not get any feedback at all for a PullReq ;-) Thanks 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
[opensc-devel] questions on {ERASE,WRITE,UPDATE} BINARY commands
Hi,
I have questions on the {ERASE,WRITE,UPDATE} BINARY commands for which I do
not find the answer in the spec (ISO-7816-4).
Here they are:
* What's the exact difference between WRITE BINARY UPDATE BINARY?
My understanding of the spec is that WRITE BINARY can extend a file's size,
while UPDATE BINARY can only update data elements that are already within
the file (i.e. in the range [0 .. file_size-1]).
Is my understanding correct or did I misunderstand the specscompletely?
* Is it to be considered an error if UPDATE BINARY
a) uses an idx = existing_file_size ?
b) wants to update 0 data elements (i.e. count = 0) ?
c) idx + count = existing_file_size?
* Similar for ERASE BINARY
a) Can it set data elements to logical erased state beyond the file size?
i.e. idx + count = existing_file_size
b) Is it an error to erase 0 data alements
i.e. count = 0
c) If idx + count = file_size, does the file get zapped (=shortened)
to idx data elements?
Thanks in advance
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] questions on {ERASE, WRITE, UPDATE} BINARY commands
Hi Martin, thanks for the quick reply. On Thursday, 7. June 2012, Martin Paljak wrote: On Thu, Jun 7, 2012 at 10:24 PM, Peter Marschall pe...@adpm.de wrote: Here they are: * What's the exact difference between WRITE BINARY UPDATE BINARY? My understanding of the spec is that WRITE BINARY can extend a file's size, while UPDATE BINARY can only update data elements that are already within the file (i.e. in the range [0 .. file_size-1]). Is my understanding correct or did I misunderstand the specscompletely? AFAIU either can change file size (which can be done though 7816-9). UPDATE will *set* the bits as given in the command, whereas WRITE can allow some bit-fiddling. Why the question? If there would be a card that implements both, I think you would want to use UPDATE, at least in the context of OpenSC, unless it is *not* supported and WRITE is supported. What exactly is the context? The wish to implement them correctly for the OpenPGP card. * Is it to be considered an error if UPDATE BINARY a) uses an idx = existing_file_size ? Probably. '6B00' (offset outside the EF) b) wants to update 0 data elements (i.e. count = 0) ? IMHO should not, but implementations might vary, of course. c) idx + count = existing_file_size? Probably. '6B00' (offset outside the EF) * Similar for ERASE BINARY a) Can it set data elements to logical erased state beyond the file size? i.e. idx + count = existing_file_size b) Is it an error to erase 0 data alements i.e. count = 0 c) If idx + count = file_size, does the file get zapped (=shortened) to idx data elements? Ditto. Martin -- 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] questions on {ERASE, WRITE, UPDATE} BINARY commands
Hi, thanks for the quick reply/correction. On Thursday, 7. June 2012, Martin Paljak wrote: On Thu, Jun 7, 2012 at 10:35 PM, Martin Paljak mar...@martinpaljak.net wrote: Hello, On Thu, Jun 7, 2012 at 10:24 PM, Peter Marschall pe...@adpm.de wrote: Here they are: * What's the exact difference between WRITE BINARY UPDATE BINARY? My understanding of the spec is that WRITE BINARY can extend a file's size, while UPDATE BINARY can only update data elements that are already within the file (i.e. in the range [0 .. file_size-1]). Is my understanding correct or did I misunderstand the specscompletely? AFAIU either can change file size (which can be done though 7816-9). Correction, can NOT change file size. Does that mean that none of them can change the number of data elements that are in the file ? This seems to contradict the sentence in ISO 7816-4 7.2.4 WRITE BINARY which states: - the write-once of the bits given in the command data field (the command shall be aborted if thestring of data units is not in the logical erased state) To me that sentence sounds like WRITE BINARY is an operation that A) can only be used on data that is logically reset, (i.e. once WRITE_BINARY was performed, it cannot be used on the same data any more without a preceding ERASE BINARY of that region) B) can extend the number of data units in the file (this is what I sloppily called existing_file_size in my previous mail) In the other hand, ISO 7816-4 7.2.4 UPDATE BINARY says: the command initialtes the update of the bits already present in an EF ... This is what I interpret as can only update existing data units in the file, but not create more. Am I completely wrong? Are there interpretation helpers for the spec available somewhere? While I am at it: Would you mind to pull Pull Request #53 https://github.com/OpenSC/OpenSC/pull/53 into the staging branch of github's open/opensc? (It is a little bit frustrating to not get any feedback at all for a PullReq ;-) Thanks 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
[opensc-devel] basic openpgp write support for staging
Hi, would any one with commit support for OpenSC's repo on github consider pulling https://github.com/OpenSC/OpenSC/pull/53 It add basic write support to OpenPGP, should apply cleanly to staging, consists of small commits, each only covering one topic, constrains itself to the files relevant for OpenPGP, and is a prerequsite for further work there. In addition, one commits also adds working 'put_data' support for opensc- explorer, a feature that has been there as a function since ages, but up-to- now only showed the usage info. Thanks for your support 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
[opensc-devel] Docs/Specs on ACLs / security attributes?
Hi, I am trying to extend openpgp-tool to load data to the various writable DOs, and - if possible - I want it to determine automatically the permissions of the (emulated) files using standard interfaces, i.e. security attributes or preferably ACLs. As the file system on openPGP cards only is emulated using opensc, I need to emulate these data structures too. I searched the net, but did not get anything that that really helped (I guess, I did not know/ use the correct search terms ;-) I found that ISO 7816-9 should contain info on security attributes, but I am not really keen on paying ~€60 for this information alone. Unfortunately I did not find anything on ACLs on EFs/DFs (Google only gave me tons of info an ACLs in Windows ;-) Does anyone have documentation or specs on ACLs (preferred) or security attributes. Thanks in advance 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 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
[opensc-devel] partial/limited OpenPGP write support in my github repo
Hi, Success, OpenPGP write support is here (atl east the first steps)!!! Quân's patches for OpenPGP write support are merged into the branch testing on my github repo https://github.com/marschap/OpenSC/tree/testing which is based on OpenSC's staging branch. I also created a pull request (https://github.com/OpenSC/OpenSC/pull/46) in order to get these changes into OpenSC's staging branch. Here's a short transcript of a shell session $ src/tools/opensc-explorer OpenSC Explorer version 0.12.3-pre1 Using reader with a card: SCM Microsystems Inc. SCR 335 [CCID Interface] (60600adc) 00 00 OpenSC [3F00] verify chv2 my password Code correct. OpenSC [3F00] do_put 0101 Success! Thanks to hongquan PUT DATA works with OpenPGP cards. Total of 62 bytes written. OpenSC [3F00] cat 0101 : 53 75 63 63 65 73 73 21 20 54 68 61 6E 6B 73 20 Success! Thanks 0010: 74 6F 20 68 6F 6E 67 71 75 61 6E 20 50 55 54 20 to hongquan PUT 0020: 44 41 54 41 20 77 6F 72 6B 73 20 77 69 74 68 20 DATA works with 0030: 4F 70 65 6E 50 47 50 20 63 61 72 64 73 2E OpenPGP cards. OpenSC [3F00] quit $ src/tools/openpgp-tool Using reader with a card: SCM Microsystems Inc. SCR 335 [CCID Interface] (60600adc) 00 00 Account: marschap URL: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x3CA6ACA2B35BD0B4 Name: Marschall Peter Language: de Gender:male DO 0101: Success! Thanks to hongquan PUT DATA works with OpenPGP cards. $ gpg --card-status Application ID ...: D2760001240102050ADA Version ..: 2.0 Manufacturer .: ZeitControl Serial number : 0ADA Name of cardholder: Peter Marschall Language prefs ...: de Sex ..: male URL of public key : http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x3CA6ACA2B35BD0B4 Login data ...: marschap Private DO 1 .: Success! Thanks to hongquan PUT DATA works with OpenPGP cards. Private DO 2 .: [not set] Signature PIN : forced Key attributes ...: 2048R 2048R 2048R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 3 3 Signature counter : 25 Signature key : E163 6F1F 2C91 2EE7 E8C7 E745 4A78 EC36 871E F692 created : 2011-04-14 17:25:41 Encryption key: [none] Authentication key: BC74 C977 4F22 55A0 CBF4 D492 CC27 5984 6459 4049 created : 2011-04-14 17:25:14 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] PKCS15init profile to omit a part of path
Hi,
On Friday, 25. May 2012, Martin Paljak wrote:
In the long run, I don't think that it helps to emulate a filesystem
on top of non-filesystem cards (like OpenPGP or Muscle). Or to try to
make it fit into the filesystem-oriented stack of OpenSC.
Why?
If it works (even in a limited/restricted way), it is better than not having
any support at all.
After all the openPGP card / GPF Cryptostick os one of those smartcards /
tokens that can be bought by individuals in small quantities.
It is nice to be able to poke around with opensc-explorer, but the
notion of a file and a path should mean that the file is actually
selectable with ISO SELECT command. Which is not true (a plain APDU,
outside of the libopensc emulation layer, would fail).
I do not understand that argument, especially if we're talking about
an emulation within the opensc software stack.
Why should it matter that the emulation does not exist outside opensc?
When it works (even only partiallly) with opensc, it works.
When it does not work with opensc it works nowhere.
In case of OpenPGP, where no files or PKCS#15 data structures are
written to the card (the card already has a fixed profile, with fixed
data slots), it makes no sense. The main utility of pkcs15-init is
creating (and storing) PKCS#15 ASN.1 structures to the card, when such
slots for keys or certificates are created as a side-product. If ASN.
shall not be created, pcks15-init should IMHO not be used.
Well, pkcs15-init might not be the tool suitable for the job.
But please, let Quân continue trying - maybe he can make the emulation work.
All his changes were in files specific to the OpenPGP cards only (card-
openpgp.c, pkcs15-openpgp.c).
If his approach (try to make the emulation so good that it allows using the
standard tools) does not work out, extending the new openpgp-tool to do what
he wants, should be even easier.
The fact that pkcs15-init is the main interface for generating
keys/storing certificates, is thus somewhat misleading. You can't
create more keys than 3 on OpenPGP, nor can you write more
certificates. You can't create additional arbitrary slots on the
card.
Yes, but you can (re)create any of the three keys and import keys into any of
the three existing slots.
If the emulation becomes good enough to support that, then why not use it?
Maybe it would be better to have a single sticky pkcs15-ish mapping
for a fixed profile card in a single location (like the pkcs15
emulation drivers) and allow pkcs15-tool (which does not try to create
any PKCS#15 structures) to re-generate exposed key slots and replace
exposed certificate slots. And extend that API as needed.
As I explained above: all of Quân's changes for OpenPGP card support
are limited to the files responsible for OpenPGP cards:
src/lib/opensc/{card,pkcs15}-openpgp.c
Any other changes he made, fix omissions in existing tools, e.g. he made
opensc-explorer's do_put command really functional instead of only printing
the usage message.
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] PKCS15init profile to omit a part of path
Hi all, On Friday, 18. May 2012, Nguyễn Hồng Quân wrote: I need a help to create pkcs15init profile structure so that I can change/rewrite the canonical path. All, please note, Quân is looking for something that shall be specific to OpenPGP. He I do not want to change the pkcs15 part of opensc, unless it is broken ;-) In general, the path to a file AABB in PKCS15 is as: 3F005015AABB, in which 3F00 is the MF, 5015 is the PKCS15-AppDF's file-id. Is it possible to have a PKCS#15-compliant card without the DF 5015? (I did not find the string 5015 in the PKCS#15 spec) If not, the question below is moot, and we will need to resort to changes in OpenPGP's file system emulation layer. If yes, is it possible in opensc? Now, because the virtual file system of my OpenPGP card (which is non-pkcs15) is constructed as: MF (3F00) +-- File_1 (AABB) +-- File_2 (AACC) +--- Directory (DDCC) +-- File_3 (CCEE) the real path to the file is 3F00AABB. How would I define the profile file to omit the PKCS15-AppDF, i.e. the 5015, in the path? Thanks in advance for your answers. 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 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] PKCS15init profile to omit a part of path
Hi, This is not directly related to your question, but more general: You wrote about implementing write support for OpenPGP cards. Is there a chance to see the code you already have? maybe e.g. on github ;-) 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] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
Hi, On Monday, 22. August 2011, Andreas Jellinghaus wrote: Hi Daniel, Am Sonntag 21 August 2011, 23:23:36 schrieb Daniel Kahn Gillmor: On 08/21/2011 12:36 PM, Peter Marschall wrote: * renable zlib readline support [...] what about a new, official Debian package, with my changes as the starting point as starting point? i don't think these are compatible with the DFSG, alas. GNU readline (at least) is GPL-licensed, and opensc links against OpenSSL. So building a package that links to both of them creates a non-redistributable work :( http://people.gnome.org/~markmc/openssl-and-the-gpl.html I agree with this. No problem with me. I am more interested in getting an updated opensc package in Debian than to have libreadline included in the official package. I can keep these patches locally. That's why I wrote starting point in my original mail: - take the things from the repo you consider appropriate, - leave others out that you do not consider appropriate, - add additional things, ... and build an updated official Debian package ;-) On the other hand: what part of opensc benefits from using readline? I guess the only place it might be used is the opensc-explorer, and it works fine for me without readline - so I say lets remove the readline code to avoid this. Please do not remove the code from upstream. Having it had helped me a lot with the update of the openpgp driver. It is in a configure option and can be en-/ or disabled as required. An alternative is to replace libreadline by another editline library with a different license, e.g. libedit (also in Debian). Best regards 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] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
Hi, On Tuesday, 23. August 2011, Jean-Michel Pouré - GOOZE wrote: Do you also plan to build daily packages as well? No, publishing the repo was meant as a hint help for the Debian maintainers to update the official Debian opensc package. 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] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
Hi,
On Sunday, 21. August 2011, you wrote:
On 08/21/2011 12:36 PM, Peter Marschall wrote:
* renable zlib readline support
[...]
what about a new, official Debian package, with my changes as the
starting point as starting point?
i don't think these are compatible with the DFSG, alas.
GNU readline (at least) is GPL-licensed, and opensc links against
OpenSSL. So building a package that links to both of them creates a
non-redistributable work :(
http://people.gnome.org/~markmc/openssl-and-the-gpl.html
Is there any way to have OpenSC build against some crypto libraries
other than OpenSSL (preferably licensed in GPL-compatible ways) so we
could link it to readline without violating one license or the other?
OK, let's leave out libreadline (simple changes in debian/{rules,control}).
My interest is less in libreadline - although it makes opensc-explorer
a lot more comfortable - but in an update to opensc in Debian.
What about that?
Best
Peter
PS: if zlib has similar issues, then maybe leave it away too.
--
Peter Marschall
pe...@adpm.de
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
Hi, I have put an unofficial fork of the official OpenSC repo for the Debian packages ( git://git.debian.org/git/pkg-opensc/opensc.git ) onto github. It is available at git://github.com/marschap/pkg-opensc.git The branches erics-upsream erics-master are the upstream master branches from Eric's repo at git.debian.org The branches upstream master are my going at 0.12.2 packaging. Rough overview of the changes: * get rid of unecessary Build-Depends: libxt-dev * renable zlib readline support * add westcos-tool its man page: new with 0.12.2 * explicitely nable building of man pages * add *.profile files * don't use dh_autoconfigure in override_dh_autoconfigure, but call bootstrap (see below) configure directly * simplify opensc.install - get rid of debian/tmp - new file opensc.manpages - extend opensc.docs * empty 'dependency_libs' in .la files (please lintian) Are those .la files necessary at all (for dlopen, ...)? Details can be found in the commit messages. Using the changes I was able to successfully build private opensc 0.12.2-0pm1 (please forgive my private release numbering scheme ;-) packages for i386 and amd64. A few things I have not yet done/solved: * not 100% lintian clean: 3 or 4 warnings left I was too lazy. * In debian testing, trying to build the package using git-buildpackage with the autotools provided in the upstream tar ball failed. (Funnily it worked when doing a simple buildpackage) For this reason I am calling the ./bootstrap script at the beginning the configure phase which makes the package build, but creates a rather large debian diff. Feel free to play with it. Eric, what about a new, official Debian package, with my changes as the starting point as starting point? Best regards 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
[opensc-devel] Patch series for pkcs15-profile documentation
Hi, please find my latest patches for the pkcs15-profile documentation on: https://github.com/marschap/OpenSC/commits/doctools-20110604 Here's what they do: [PATCH 1/2] pkcs15-profile.xml: remove empty SYNOPSIS section This makes the man page look better by removing the empty SYNOPSIS section. [PATCH 2/2] pkcs15-profile.xml: allow substitution of @pkgdatadir@ Rename pkcs15-profile.xml to pkcs15-profile.xml.in and use this input file to idynamically create pkcs15-profile.xml with @pkgdatadir@ substituted by the value set in the configure step. This fixes a bug in the pkcs15-profile.5 man page where @pkgdatadir@ is shown directly. It would be great if they could be added to OpenSC's mainline. Thanks 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] SVN-Git move.
Hi, On Thursday, 2. June 2011, Martin Paljak wrote: Hello, A question: how many current commiters don't yet use Git (and/or git-svn) for OpenSC development? Although I am no committer, I'd like to see OpenSC switch to git [the earlier the better ;-] Being used to working in git more than in SVN, the current development situation make it necessary for me to juggle around with lots of branches: * trunk in SVN, pulled via gits-svn * development in a local git branch based on the pulled trunk * publishing my changes to a fork of Martin's github repo. (which may be not as up-to-date as trunk) Having trunk/master in git would make creating patches way easier. Thanks for all your work on/for OpenSC 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
[opensc-devel] Patch series for opensc-tool opensc-explorer
Hi, please find my latest patches for opensc-tool opensc-explorer on: https://github.com/marschap/OpenSC/commits/tools-20110603 I am not attaching them here as they may be too big for the mailing list, and according to other posts on the mailing list, OpenSC is slowly migrating to git anyway. so,. I guess this form of virtual pull request is OK ,-) Here's what they do: [PATCH 01/16] opensc-explorer: convert do_info() to using tables * use ID-name tables instead of arrays of strings where the index was treated like some magic constant. With the new mapping tables, the meaning is obvious. * fix a bug with ac_ops_df[]: before the conversion, it was a list of pointers to strings but was in one case treated like it was a mapping table. With the conversion to a mapping table, and the adaption of other code parts this bug got fixed automagically ;-) * use common code to cleanly print ACLs for DFs EFs * harmonize EF structure names to the ones used in ISO 7816-4 [PATCH 02/16] opensc-tool: update EF structure names Use EF structure names that are more sensible grammatically more correct. [PATCH 03/16] opensc-tool: no unnecessary spaces around DF [PATCH 04/16] opensc-explorer: centralize usage * extend cmds struct by a new element args for a description of the arguments * use args in help texts * new function usage() for centralited dispaly of usage info * harmonize argument strings for usage / help texts * re-sort cmd list shown in help texts * add function help to cwallow asking for for help * space-police [PATCH 05/16] opensc-explorer: consolidate string/hexdata parsing * add new function parse_string_or_hexdata() that parses a double-quoted string or a hex-data string (e.g: AA:BB:CC) into a buffer * use parse_string_or_hexdata() wherever strings or hexdata gets parsed into a buffer [PATCH 06/16] opensc-explorer: fix argc checks in do_update_*() do_update_binary() and do_update_record() expect a fixed number of parameters each: adapt the checks for argc so that they do the right thing. [PATCH 07/16] opensc-explorer: consolidate string parsing in do_update_record() Update do_update_record() to use parse_string_or_hexdata() instead of the old hex2binary(). This change allows to use double-quoted strings in the update_record command. [PATCH 08/16] opensc-explorer: detect AID conversion errors in arg_to_path() Convert arg_to_path() to using the standard sc_hex_to_binary() instead of the local hex2binary(). While at it, return errors on failed conversions. [PATCH 09/16] opensc-explorer: remove hex2binary() With the last users gone, there's no need to keep hex2binary(). [PATCH 10/16] opensc-explorer: remove unnecessary var's in do_update_*() The variables in_str in do_update_binary() do_update_record() do not serve a purpose: use argv[x] directly remove them. [PATCH 11/16] opensc-explorer: simplify arg parsing in do_change() do_unblock() Simplify argument handling in do_change() and do_unblock(), making the functions shorter and deasier to understand., [PATCH 12/16] opensc-explorer: convert all mapping tables to id2str_t Use type id2str_t for all mapping tables mapping IDs-names. [PATCH 13/16] opensc-explorer: re-factor do_apdu() * allow double-quoted strings besides hexdata in ADPU generation * detect errors in parameter parsing * use utility function to print bytes sent, fixing an error that only showed parts of the APDU wheni it was generated from multiple arguments [PATCH 14/16] opensc-explorer: replace if..else with ?: Use the easier to read shorter expression path-type = (is_id) ? SC_PATH_TYPE_FILE_ID : SC_PATH_TYPE_PATH; instead of the longer, but equivalent if () .. else construction. [PATCH 15/16] opensc-explorer: use util_hex_dump() in do_info() Use standard function util_hex_dump() in do_info() instead of enumerating lists of bytes ourselves. [PATCH 16/16] opensc-explorer: consolidate filename generation * add new function path_to_filename() that converts a path into filename, and returns a static buffer to it * convert all occurrences where file names get generated to using this function Plase consider including them into OpenSC mainline -- Peter Marschall pe...@adpm.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Patch series for OpenPGP card driver
Hi, please find my latest patches for the OpenGP card driver on: https://github.com/marschap/OpenSC/commits/OpenPGP-20110603 Here's what they do: [PATCH 1/8] OpenPGP: fix algorithms key lengths calculation Also include forgotten DO C3 in keylength calculation. It contains the parameters for the authentication key. [PATCH 2/8] OpenPGP: remove DO info entry for DO FF DO FF is a catch-all DO that returns all the infos contained in the other DOs in one hierarchy. It is hence duplicate and not necessary. [PATCH 3/8] OpenPGP: immediately quit on allocation errors in init [PATCH 4/8] OpenPGP: re-factor gpg_new_blob() * get file as parameter fail if it is NULL * allow parent to be NULL * do not rely on DO info to be passed as parameter, search it yourself using the global DO info list for the card. * infer file type automatically from DO info matching the file ID. [PATCH 5/8] OpenPGP: update pgp_list_files() * fail if buffer passed as parameter is too small * only list readable objects [PATCH 6/8] OpenPGP: add DO info entries for MF For consistency, add DO info entries for the MF 3F00. [PATCH 7/8] OpenPGP: use pgp_new_blob() to setup MF blob Use the standard way to create blobs, pgp_new_blob(), also for the MF. [PATCH 8/8] OpenPGP: unlink blob from blob tree in pgp_free_blob() Remove links pointing to the blob to be deleted from other blobs in the blob tree structure, so that removing a subordinate blob does not hurt its parent or siblings. Please consider including them in OpenSC mainline/trunk/master Thanks for OpenSC 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] extensions and fixes for opensc-tool ???opensc-explorer
Hi, On Wednesday, 20. April 2011, Martin Paljak wrote: On Apr 19, 2011, at 14:41 , Frank Morgner wrote: On Tuesday, April 19 at 02:03PM, Martin Paljak wrote: On Mon, Apr 18, 2011 at 23:22, Peter Marschall pe...@adpm.de wrote: Looking at your patch - I like the approach more: - removes code duplication (there's one more instance in piv-tool.c) - feels like easier to read (but verification would need attention what I can't afford right now, sickathome) - has a nice debug log statement. It would be nice if the patch - removed the 3rd instance of same code in piv-tool.c (and reverted r5370) - had some doxygen documentation in apdu.c and opensc.h - not really important, but probably would be good if the function had a name similar to the reverse function (apdu2bytes) Peter, can you verify if this works for you as well (and/or is it free of the mentioned memory overrun problem) ? Yes Frank's patch works for me too [he is right: my patch has a bug], and his patch is also OK wrt to the memory overrun: Frank correctly checks length before further actions (the bug was in the original code in opensc-tool.c opensc-explorer.c. In #260 I have attached an update of Frank's patch that applies to r5378 (as of today 15:00 CET DST): it backs out the changes of my patch and restores his version again. 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] extensions and fixes for opensc-tool opensc-explorer
Hi Martin,
On Monday, 18. April 2011, Martin Paljak mar...@martinpaljak.net wrote:
On Sun, Apr 17, 2011 at 12:44, Peter Marschall pe...@adpm.de wrote:
please find attached 3 patches to opensc-tool and opensc-explorer:
* [PATCH 1/3] opensc-tool: make list_algorithms() table driven
* The patch has a lot of extra whitespaces at end of lines.
Hmm, I do not completely understand.
I usually check the spaces at EOL before commit.
And I admit I overlooked one (the one in the 159th line of the patch file ;-).
In my opinion: 1 != many.
All other ones have been in before.
If you
change the line in options table for list-algorithms, you could maybe
nicely space-align the rest of the table as well ? :)
I am not sure I understand your request.
I aligned all tables that I either touched or created new.
Within each table, all columns start at the same position and the
closing brace of a line is at the same position.
Between any two column in each table there is minimal 1 space
(for the longest item in the left column).
Is it possible you are viewing the patches with a variable-width font?
Regarding this request I am at a loss.
Can you help me?
* Do you want me to have all tables the same width overall ?
* Do you want me to align the options[] table ?
I did not do it as it had nothing to do with my patches
and I wanted them to as small as possible.
* Do you want me to convert spaces within tables to tabs ?
* Do you want me to be space police on these tools
and remove all trailing spaces where they occur?
If you use git,
enable the sampel pre-commit hook in .git/hooks to detect such
whitespace errors.
Thanks that's a good hint.
Unfortunately the pre-commit.sample in my installation seems to be different
from yours as it does a lot more than simply calling git diff, which is what I
do before commits anyway to spot trailing blanks errors (+ testing, of course
;-).
* Why the commented out none entries for hashes and paddings and
special handling in the loop for none? As a general rule: please don't
do c++ comments and no commented out code in new commits
sorry my fault (I have the habit to list _all_ ID entries in a table ;-)
Please find attached the updated first patch.
Changes to the previous version:
* all ( = 1 ;-) new trailing whitespace removed
* commented table contents removed.
Sorry for doing it again via mail this time.
Give me time until Easter to try github.
* [PATCH 3/3] opensc-{explorer,tool}: allow sending extended APDUs
In do_apdu() resp. send_apdu/(, flexibilize parsing the APDU string
passed so that extended APDUs are accepted a valid APDUs too.
OK. Also related is #237, at least to the extent that is described in
commend 12 [1]. As you already notices, that's copied code. Pushing it
to a single location and re-using would be a better choice.
I wanted to start small ;-)
First get the code updated/fixed, then think about getting it into some common
library (either a new one or an existing one).
I guess the library should be deferred for later.
It may need discussions where the code shall go: maybe even directly into
libopensc ;-)
Best
Peter
--
Peter Marschall
pe...@adpm.de
From 40f710e971744ddf0b15f16c4e7533bedaa11744 Mon Sep 17 00:00:00 2001
From: Peter Marschall pe...@adpm.de
Date: Sat, 16 Apr 2011 14:28:03 +0200
Subject: [PATCH] opensc-tool: make list_algorithms() table driven
Use easily extensible tables instead of explicit coding to display
algorithm names and options in list_algorithms.
Leverage the new tables to add more RSA hashes.
Signed-off-by: Peter Marschall pe...@adpm.de
---
src/tools/opensc-tool.c | 120 +-
1 files changed, 65 insertions(+), 55 deletions(-)
diff --git a/src/tools/opensc-tool.c b/src/tools/opensc-tool.c
index aaabf33..5d7ffd5 100644
--- a/src/tools/opensc-tool.c
+++ b/src/tools/opensc-tool.c
@@ -34,6 +34,12 @@
#include libopensc/cardctl.h
#include util.h
+/* type for associations of IDs to names */
+typedef struct _id2str {
+ unsigned int id;
+ const char *str;
+} id2str_t;
+
static const char *app_name = opensc-tool;
static int opt_wait = 0;
@@ -556,81 +562,85 @@ static void print_serial(sc_card_t *in_card)
static int list_algorithms(void)
{
int i;
- const char *aname;
+ const char *aname = unknown;
+
+ const id2str_t alg_type_names[] = {
+ { SC_ALGORITHM_RSA, rsa},
+ { SC_ALGORITHM_DSA, ec },
+ { SC_ALGORITHM_DES, des},
+ { SC_ALGORITHM_3DES, 3des },
+ { SC_ALGORITHM_MD5, md5},
+ { SC_ALGORITHM_SHA1, sha1 },
+ { SC_ALGORITHM_PBKDF2,pbkdf2 },
+ { SC_ALGORITHM_PBES2, pbes2 },
+ { SC_ALGORITHM_GOSTR3410, gost },
+ { 0, NULL }
+ };
+ const id2str_t alg_flag_names[] = {
+ { SC_ALGORITHM_ONBOARD_KEY_GEN, onboard key generation },
+ { SC_ALGORITHM_NEED_USAGE, needs usage},
+ { 0, NULL }
+ };
+ const id2str_t rsa_flag_names[] = {
+ { SC_ALGORITHM_RSA_PAD_PKCS1
[opensc-devel] extensions and fixes for opensc-tool opensc-explorer
Hi,
please find attached 3 patches to opensc-tool and opensc-explorer:
* [PATCH 1/3] opensc-tool: make list_algorithms() table driven
Use easily extensible tables instead of explicit coding to display
algorithm names and options in list_algorithms.
Leverage the new tables to add more RSA hashes
* [PATCH 2/3] opensc-tool: convert print_file() to using tables
Use ID-name tables in print_file() innstead of arrays of strings where
the index was treated like some magic constant. With the new mapping
tables, the meaning is obvious.
While on it, fix a bug with ac_ops_df[]: before the conversion, it was a list
of pointers to strings but was in one case treated like it was a mapping
table.
With the conversion to a mapping table, and the adaption of other code parts
this bug got fixed automagically ;-)
* [PATCH 3/3] opensc-{explorer,tool}: allow sending extended APDUs
In do_apdu() resp. send_apdu/(, flexibilize parsing the APDU string passed
so that extended APDUs are accepted a valid APDUs too.
While at it, fix a bug where more data than available would have been copied,
potentially leading to a SIGSEGV.
Please consider including them into trunk, as they
a) fix potential bugs
b) help development: send extedned APDUs
c) allow tools to give more complete information
Thanks in advance
PEter
--
Peter Marschall
pe...@adpm.de
From af08131050655c05111cc10548c6e0156351e502 Mon Sep 17 00:00:00 2001
From: Peter Marschall pe...@adpm.de
Date: Sat, 16 Apr 2011 14:28:03 +0200
Subject: [PATCH 1/3] opensc-tool: make list_algorithms() table driven
Use easily extensible tables instead of explicit coding to display
algorithm names and options in list_algorithms.
Leverage the new tables to add more RSA hashes.
Signed-off-by: Peter Marschall pe...@adpm.de
---
src/tools/opensc-tool.c | 122 ++-
1 files changed, 67 insertions(+), 55 deletions(-)
diff --git a/src/tools/opensc-tool.c b/src/tools/opensc-tool.c
index 529e842..5857228 100644
--- a/src/tools/opensc-tool.c
+++ b/src/tools/opensc-tool.c
@@ -34,6 +34,12 @@
#include libopensc/cardctl.h
#include util.h
+/* type for associations of IDs to names */
+typedef struct _id2str {
+ unsigned int id;
+ const char *str;
+} id2str_t;
+
static const char *app_name = opensc-tool;
static int opt_wait = 0;
@@ -556,81 +562,87 @@ static void print_serial(sc_card_t *in_card)
static int list_algorithms(void)
{
int i;
- const char *aname;
+ const char *aname = unknown;
+
+ const id2str_t alg_type_names[] = {
+ { SC_ALGORITHM_RSA, rsa},
+ { SC_ALGORITHM_DSA, ec },
+ { SC_ALGORITHM_DES, des},
+ { SC_ALGORITHM_3DES, 3des },
+ { SC_ALGORITHM_MD5, md5},
+ { SC_ALGORITHM_SHA1, sha1 },
+ { SC_ALGORITHM_PBKDF2,pbkdf2 },
+ { SC_ALGORITHM_PBES2, pbes2 },
+ { SC_ALGORITHM_GOSTR3410, gost },
+ { 0, NULL }
+ };
+ const id2str_t alg_flag_names[] = {
+ { SC_ALGORITHM_ONBOARD_KEY_GEN, onboard key generation },
+ { SC_ALGORITHM_NEED_USAGE, needs usage},
+ { 0, NULL }
+ };
+ const id2str_t rsa_flag_names[] = {
+ // { SC_ALGORITHM_RSA_PAD_NONE, none },
+ { SC_ALGORITHM_RSA_PAD_PKCS1, pkcs1 },
+ { SC_ALGORITHM_RSA_PAD_ANSI, ansi },
+ { SC_ALGORITHM_RSA_PAD_ISO9796,iso9796 },
+ // { SC_ALGORITHM_RSA_HASH_NONE, none },
+ { SC_ALGORITHM_RSA_HASH_SHA1, sha1 },
+ { SC_ALGORITHM_RSA_HASH_MD5, MD5 },
+ { SC_ALGORITHM_RSA_HASH_MD5_SHA1, md5-sha1 },
+ { SC_ALGORITHM_RSA_HASH_RIPEMD160, ripemd160 },
+ { SC_ALGORITHM_RSA_HASH_SHA256,sha256},
+ { SC_ALGORITHM_RSA_HASH_SHA384,sha384},
+ { SC_ALGORITHM_RSA_HASH_SHA512,sha512},
+ { SC_ALGORITHM_RSA_HASH_SHA224,sha224},
+ { 0, NULL }
+ };
if (verbose)
printf(Card supports %d algorithm(s)\n\n,card-algorithm_count);
for (i=0; i card-algorithm_count; i++) {
- switch (card-algorithms[i].algorithm) {
- case SC_ALGORITHM_RSA:
- aname = rsa;
- break;
- case SC_ALGORITHM_DSA:
- aname = dsa;
- aname = ec;
- break;
- case SC_ALGORITHM_DES:
- aname = des;
- break;
- case SC_ALGORITHM_3DES:
- aname = 3des;
- break;
- case SC_ALGORITHM_MD5:
- aname = md5;
- break;
- case SC_ALGORITHM_SHA1:
- aname = sha1;
- break;
- case SC_ALGORITHM_PBKDF2:
- aname = pbkdf2;
- break;
- case SC_ALGORITHM_PBES2:
- aname = pbes2;
- break;
- case SC_ALGORITHM_GOSTR3410:
- aname = gost;
- break;
- default:
- aname = unknown;
- break;
- }
-
+ int j;
+
+ /* find algorithm name */
+ for (j = 0; alg_type_names[j].str != NULL; j++) {
+ if (card-algorithms[i].algorithm == alg_type_names[j].id) {
+aname = alg_type_names[j].str;
+break;
+ }
+ }
+
printf(Algorithm: %s\n, aname);
printf(Key length: %d\n, card-algorithms[i].key_length);
printf(Flags:);
- if (card-algorithms[i].flags
[opensc-devel] finally OpenPGP card 2.0 support
Hi, please find attached the third round of my patches to the OpenPGP card driver, that now can - at least partially - deal with OpenPGP 2.0 cards while still compatible with OpenPGP 1.1 cards (tested with both card types). Here's what they do (copied from the commit message of each patch): * [PATCH 01/15] OpenPGP: fix top-level DOs according to spec Added: * 00c4: new top-level DO in 2.0 can also be found inside constructed DOs 006E/0073 in 2.0 1.1 * 0101: new optional top-level DO starting in 1.1 for private use max 254 bytes; access: read - always; write - verify CHV2 * 0102: new optional top-level DO starting in 1.1 for private use max 254 bytes; access: read - always; write - verify CHV3 * 0103: new optional top-level DO starting in 1.1 for private use max 254 bytes; access: read - verify CHV2; write - verify CHV2 * 0104: new optional top-level DO starting in 1.1 for private use max 254 bytes; access: read - verify CHV3; write - verify CHV3 * 5f52: new top-level DO in 2.0 can also be found inside constructed DOs 006E in 2.0 * 7f21: new optional top-level DO in 2.0 use: card holder certificate (e.g. X.509) for the AUT key in the card Removed: * 0073: never a top-level DO, but part of top-level constructed DO 006E Changed: * 005e: not a constructed DO, but a simple/primitive DO Note: Trying to read non-existent top-level DOs or top-level DOs that weren't defined in a spec version later than the current card's version does not hurt. They are returned as empty. * [PATCH 02/15] OpenPGP: add indication of 2048 RSA agorithm for OpenPGP 2.0 cards * [PATCH 03/15] OpenPGP: try to match flags with specification * [PATCH 04/15] OpenPGP: re-factor pgp_enumerate_blob() Leverage the fact that OpenPGP cards use TLV encoding according to ASN.1 BER-encoding rules and use sc_asn1_read_tag() as the workhorse within pgp_enumerate_blob(). There's one peculiarity though: OpenPGP cards expect 'cla' to be merged into 'tag'. This is done manually after calling sc_asn1_read_tag(). * [PATCH 05/15] OpenPGP: implement function to free the fake file system * pgp_iterate_blobs(): walk through the blob tree * pgp_free_blob(): free a blob * [PATCH 06/15] OpenPGP: NULL-ify free()'d pointer * [PATCH 07/15] OpenPGP: re-factor pgp_set_blob() * NULL-ify freed data pointer * avoid unnecessary malloc() calls * cope with malloc() errors * do not rely on blob-file for be set * [PATCH 08/15] OpenPGP: add some comments * [PATCH 09/15] OpenPGP: use symbolic names for errors/success * [PATCH 10/15] OpenPGP: catch calloc() errors in pgp_new_blob() Detect and react on out of memory errors in pgp_new_blob() and its callers. * [PATCH 11/15] OpenPGP: update card capabilities from historical bytes According to OpenPGP card specs 1.1 2.0 historical bytes in the ATR indicate capabilities: * bit 0x40 of the 3rd byte of the compact-TLV entry with TL 0x73 tells whether the card supports extended Lc/Le fields in APDUs. In addition, OpenPGP card 2.0 spec specifies the optional DO 5f52 which also contains the histoirical bytes (just in case). If available use this value to override capabilties from ATR. * [PATCH 12/15] OpenPGP: use card extended Lc/Le capabilities Adapt pgp_get_pubkey() and pgp_read_blob() to make use of the information about the extended Lc/Le capabilities. This allows reading OpenPGP Card v2.0 keys!Yippie!! * [PATCH 13/15] OpenPGP: allow extended APDUs in all functions Depending on the card's capabilities and the necessity (requested response size 256) allow extended APDUs in all functions talking to the card. * [PATCH 14/15] OpenPGP: free memory when selecting the application fails free() the memory already reserved when the file identifying the OpenPGP application fails reset the pointers in the card strcuture back to NULL. * [PATCH 15/15] OpenPGP: implement card_ctl() command SC_CARDCTL_GET_SERIALNR Implement card_ctl(), crrently restricted only to SC_CARDCTL_GET_SERIALNR. The card's serial number is copied from the respective bytes in the AID. Please include them into the trunk as they: a) fix lots of bugs b) make the code conform to the ABI: free locally allocated memory, .. c) extend features: OpenPGP Card 2.0 support (at least partially) Thanks in advance Peter -- Peter Marschall pe...@adpm.de From 8319b2627fdbcf9465ffe6383d6b60cebe3da9a4 Mon Sep 17 00:00:00 2001 From: Peter Marschall pe...@adpm.de Date: Sun, 13 Mar 2011 21:41:12 +0100 Subject: [PATCH 01/15] OpenPGP: fix top-level DOs according to spec Added: * 00c4: new top-level DO in 2.0 can also be found inside constructed DOs 006E/0073 in 2.0 1.1 * 0101: new optional top-level DO starting in 1.1 for private use max 254 bytes; access: read - always; write - verify CHV2
Re: [opensc-devel] fixes for a few glitches in card-opengpg.c
Hi, On Monday, 21. March 2011, Martin Paljak wrote: Hello Peter, Before I go on testing with CryptoStick (OpenPGP v2.0) could you explain what happens with the overall behavior of OpenSC after your patches? Do you get further with the card/token? Any other comments? Together with the changes to opensc-explorer [see other mail from me on Sunday] it even helped improve the situation with 1.1 cards. * 0001-OpenPGP-fix-top-level-DOs-according-to-spec.patch align the list of top-level data objects with the spec Are these changes between v1.1/2.0 or just mistakes? I don't think that the v1.0/1.1 support is that relevant in near future, but it would be nice if the code tried to explicitly maintain changes needed to support both 2.0 and 1.1 cards. I'm not sure if v2.0 is backwards compatible with 1.1 and 1.0. If you know more and have studied both v1.1 and v2.0 specs, please provide pointers and/or insight. IMHO these were simply errors even in the 1.1 support. E.g. the DO with id 0073 is not a top level DO but contained within another DO. AFAICS spec 2.0 is compatible with 1.1 and only extends it. The reference for the IDs of the DOs and how DOs are nested can be found in the specs. If you do change something because of spec issues, delete/fix the offending code, don't comment out. If something breaks, version control should support recovery, not editor comments. IMHO I did it with the exception of the DO 0073. For the two other comments regarding DOs 0103 0104: they are optional but require authentication for reading. As I do not know yet how to deal with them, I added them as comments in order to not forget the issue. Fiddling the driver to a state where it would work with 2.0 cards by sacrificing older cards support would be OK as well, but in that case do add comments (XXX: hardcoded for v2.0 support or something similar). As far as I can say this is not the case !!! * 0002-OpenPGP-add-indication-of-2048-RSA-agorithm-for- Open.patch indicate 2048-bit support for version 2.0 cards In fact, 3072 :) But that would be an interesting stress test for the overall forward-support of OpenSC and software that use it... I am not so sure. http://www.g10code.com/p-card.html tells about 3 2048-bits, and 3072 for signature keys only. BTW the 2.0 cards share the ATR with the crypto stick. I got one recently, but did not get round to putting keys on it. * 0005-OpenPGP-document-TLV-encoding-use-symbolic- values.patch add comments to document the funny TLV encoding It looks similar to sc_asn1_read_tag, are you sure it can not be re-used? I only added comments. Thanks for the hint. What about improving the whole thing iteratively and commit that part now? Next step I'll take is whether sc_asn1_read_tag may be used. * 0008-OpenPGP-only-malloc-when-we-need-to.patch avoid an unnecessary malloc(0) malloc is not checked for NULL It hasn't been checked before too. Thanks again. This gives me hints about the next steps. * 0009-OpenPGP-add-some-comments.patch a few more comments Comments are always nice! I'll give the changes a spin, if you could add some more background information and updates, it would be easier to fix. All the changes have been checked using opensc-explorer against a 1.1 card. Details about the DO IDs used are in the specs. Sorry for not sending in perfect patches yet ;-) Nonetheless it would be cool if some would be included to mainline to give a positive feedback. (card-openpgp did not get much love recently) By the way, if you use git you can fork on github [1] to allow the pulling, mechanism over there do some tricks. I'm using 'git svn' locally. As I only have read access to SVN, I currently consider this the easiest way to stay up-to-date For patches, the mailing list / ticket system is OK with me. Do you have any plans to migrate from SVN to git? 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
[opensc-devel] fixes for a few glitches in card-opengpg.c
Hi,
this is my first post to the list, so please bear with me, if I do not follow
the standard procedure for sending in patches.
Please find attached a few patches to src/libopensc/card-openpgp.c
* 0001-OpenPGP-fix-top-level-DOs-according-to-spec.patch
align the list of top-level data objects with the spec
* 0002-OpenPGP-add-indication-of-2048-RSA-agorithm-for-Open.patch
indicate 2048-bit support for version 2.0 cards
* 0003-OpenPGP-try-to-match-flags-with-specification.patch
get algorithm flags from the spec (commented out)
* 0004-OpenPGP-according-to-spec-DO-5E-is-not-constructed.patch
additional fix to align top-level data objects with the spec
* 0005-OpenPGP-document-TLV-encoding-use-symbolic-values.patch
add comments to document the funny TLV encoding
* 0006-OpenPGP-implement-function-to-free-the-fake-file-sys.patch
free the fake file hierarchy created during run time
* 0007-OpenPGP-NULL-ify-free-d-pointer.patch
set a free'd pointer to NULL
* 0008-OpenPGP-only-malloc-when-we-need-to.patch
avoid an unnecessary malloc(0)
* 0009-OpenPGP-add-some-comments.patch
a few more comments
It would be cool if you included them into OpenSC mainstream
Best regards
Peter
--
Peter Marschall
pe...@adpm.de
From d5667b06dec42be7c92b3aafff28a5ce4d24f792 Mon Sep 17 00:00:00 2001
From: Peter Marschall pe...@adpm.de
Date: Sun, 13 Mar 2011 19:32:05 +0100
Subject: [PATCH 9/9] OpenPGP: add some comments
Signed-off-by: Peter Marschall pe...@adpm.de
---
src/libopensc/card-openpgp.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/libopensc/card-openpgp.c b/src/libopensc/card-openpgp.c
index 53a89c9..1c7a416 100644
--- a/src/libopensc/card-openpgp.c
+++ b/src/libopensc/card-openpgp.c
@@ -61,8 +61,8 @@ static struct sc_card_driver pgp_drv = {
* Everything else is mapped to file IDs.
*/
struct blob {
- struct blob * next;
- struct blob * parent;
+ struct blob * next; /* pointer to next sibling */
+ struct blob * parent; /* pointer to parent */
struct do_info *info;
sc_file_t * file;
@@ -71,7 +71,7 @@ struct blob {
unsigned char * data;
unsigned int len;
- struct blob * files;
+ struct blob * files; /* pointer to 1st child */
};
struct do_info {
--
1.7.4.1
From acc0137ef938bb4a0cd9debfeeace35941b9d005 Mon Sep 17 00:00:00 2001
From: Peter Marschall pe...@adpm.de
Date: Sun, 13 Mar 2011 19:26:35 +0100
Subject: [PATCH 8/9] OpenPGP: only malloc() when we need to
Signed-off-by: Peter Marschall pe...@adpm.de
---
src/libopensc/card-openpgp.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/libopensc/card-openpgp.c b/src/libopensc/card-openpgp.c
index 72defed..53a89c9 100644
--- a/src/libopensc/card-openpgp.c
+++ b/src/libopensc/card-openpgp.c
@@ -234,8 +234,11 @@ pgp_set_blob(struct blob *blob, const u8 *data, size_t len)
free(blob-data);
blob-len= len;
blob-status = 0;
- blob-data = malloc(len);
- memcpy(blob-data, data, len);
+ blob-data = NULL;
+ if (len 0) {
+ blob-data = malloc(len);
+ memcpy(blob-data, data, len);
+ }
blob-file-size = len;
return 0;
--
1.7.4.1
From 692b4bb21bb90c77e6dc8fc81ea1248eaceaa32c Mon Sep 17 00:00:00 2001
From: Peter Marschall pe...@adpm.de
Date: Sat, 19 Mar 2011 20:06:42 +0100
Subject: [PATCH 6/9] OpenPGP: implement function to free the fake file system
* pgp_iterate_blobs(): walk through the blob tree
* pgp_free_blob(): free a blob
Signed-off-by: Peter Marschall pe...@adpm.de
---
src/libopensc/card-openpgp.c | 57 --
1 files changed, 49 insertions(+), 8 deletions(-)
diff --git a/src/libopensc/card-openpgp.c b/src/libopensc/card-openpgp.c
index 5f0e43b..bb80b7f 100644
--- a/src/libopensc/card-openpgp.c
+++ b/src/libopensc/card-openpgp.c
@@ -82,8 +82,11 @@ struct do_info {
int (*put_fn)(sc_card_t *, unsigned int, const u8 *, size_t);
};
+static void pgp_iterate_blobs(struct blob *, int, void (*func)());
+
static struct blob * pgp_new_blob(struct blob *, unsigned int, int,
struct do_info *);
+static void pgp_free_blob(struct blob *);
static int pgp_get_pubkey(sc_card_t *, unsigned int,
u8 *, size_t);
static int pgp_get_pubkey_pem(sc_card_t *, unsigned int,
@@ -115,7 +118,7 @@ static struct do_info pgp_objects[] = {
#define DRVDATA(card)((struct pgp_priv_data *) ((card)-drv_data))
struct pgp_priv_data {
- struct blob mf;
+ struct blob * mf;
struct blob * current;
sc_security_env_t sec_env;
@@ -148,6 +151,12 @@ pgp_init(sc_card_t *card)
priv = calloc (1, sizeof *priv);
if (!priv)
return SC_ERROR_OUT_OF_MEMORY;
+ priv-mf = calloc(1, sizeof(struct blob));
+ if (!priv-mf) {
+ free(priv);
+ return SC_ERROR_OUT_OF_MEMORY;
+ }
+
card-drv_data = priv;
card-cla = 0x00;
@@ -185,15 +194,15 @@ pgp_init(sc_card_t *card)
file-type = SC_FILE_TYPE_DF;
file-id = 0x3f00;
- priv-mf.file = file;
- priv-mf.id = 0x3F00;
+ priv-mf-file = file;
+ priv-mf-id = 0x3F00
[opensc-devel] Fwd: a little love for opensc-explorer.c
Hi,
please find attached a few patches for opensc-explorer.c
* 0001-opensc-explorer-support-writing-to-stdout-in-get.patch
new feature: use filename '-' as an indicator tow write to stdout in 'get'
* 0002-opensc-explorer-re-factor-print_file.patch
re-factor: simplify code
* 0003-opensc-explorer-re-factor-do_cat.patch
re-factor: bring logocal parts closer to each other
* 0004-opensc-explorer-use-relative-addressing-in-do_cat.patch
bug fix (at least I think it is one):
according to the usage message 'cat' uses file ids, just as e.g. 'get'
IMHO it should then use relative addressing instead of absolute
addressing.
This change made 'cat' useful with my OpenPGP cards
(before it baled out crying unable to select file: Invalid arguments)
It would be cool if the changes made it into OpenSC mainline
Best
Peter
--
Peter Marschall
pe...@adpm.de
From abe0fd986c9e3c47c05464c9453ca229cab74c4a Mon Sep 17 00:00:00 2001
From: Peter Marschall pe...@adpm.de
Date: Sat, 19 Mar 2011 14:56:44 +0100
Subject: [PATCH 1/4] opensc-explorer: support writing to stdout in 'get'
Treat the value '-' of the second parameter to get special.
If it is given, use stdout as the file to write to.
Signed-off-by: Peter Marschall pe...@adpm.de
---
src/tools/opensc-explorer.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/tools/opensc-explorer.c b/src/tools/opensc-explorer.c
index d8b2beb..7cc7d9a 100644
--- a/src/tools/opensc-explorer.c
+++ b/src/tools/opensc-explorer.c
@@ -903,7 +903,9 @@ static int do_get(int argc, char **argv)
fbuf[5*i-1] = 0;
filename = fbuf;
}
- outf = fopen(filename, wb);
+ outf = (strcmp(filename, -) == 0)
+ ? stdout
+ : fopen(filename, wb);
if (outf == NULL) {
perror(filename);
goto err;
@@ -936,14 +938,19 @@ static int do_get(int argc, char **argv)
idx += r;
count -= r;
}
- printf(Total of %d bytes read from %s and saved to %s.\n,
- idx, argv[0], filename);
+ if (outf == stdout) {
+ fwrite(\n, 1, 1, outf);
+ }
+ else {
+ printf(Total of %d bytes read from %s and saved to %s.\n,
+ idx, argv[0], filename);
+ }
err = 0;
err:
if (file)
sc_file_free(file);
- if (outf)
+ if (outf != NULL outf != stdout)
fclose(outf);
select_current_path_or_die();
return -err;
--
1.7.4.1
From a2446ed4ce6d302466375b7618f30c80d0342ba5 Mon Sep 17 00:00:00 2001
From: Peter Marschall pe...@adpm.de
Date: Sat, 19 Mar 2011 16:13:47 +0100
Subject: [PATCH 2/4] opensc-explorer: re-factor print_file()
Signed-off-by: Peter Marschall pe...@adpm.de
---
src/tools/opensc-explorer.c | 19 +--
1 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/src/tools/opensc-explorer.c b/src/tools/opensc-explorer.c
index 7cc7d9a..2c6fb4e 100644
--- a/src/tools/opensc-explorer.c
+++ b/src/tools/opensc-explorer.c
@@ -164,17 +164,9 @@ static int arg_to_path(const char *arg, sc_path_t *path, int is_id)
static void print_file(const sc_file_t *file)
{
- const char *st;
+ const char *format = %02X%02X ;
+ const char *st = ???;
- if (file-type == SC_FILE_TYPE_DF)
- printf([);
- else
- printf( );
- printf(%02X%02X, file-id 8, file-id 0xFF);
- if (file-type == SC_FILE_TYPE_DF)
- printf(]);
- else
- printf( );
switch (file-type) {
case SC_FILE_TYPE_WORKING_EF:
st = wEF;
@@ -183,12 +175,11 @@ static void print_file(const sc_file_t *file)
st = iEF;
break;
case SC_FILE_TYPE_DF:
+ format = [%02X%02X];
st = DF;
break;
- default:
- st = ???;
- break;
}
+ printf(format, file-id 8, file-id 0xFF);
printf(\t%4s, st);
printf( %5lu, (unsigned long)file-size);
if (file-namelen) {
--
1.7.4.1
From 61dbed8084fe3aa920e31da33a2b3e919507fd1c Mon Sep 17 00:00:00 2001
From: Peter Marschall pe...@adpm.de
Date: Sat, 19 Mar 2011 17:51:20 +0100
Subject: [PATCH 3/4] opensc-explorer: re-factor do_cat()
* use strlen(..) instead of sizeof(..)-1
- easier to read
- avoids errors if string is defined with explicit size
* bring sfi:-related code closer together
Signed-off-by: Peter Marschall pe...@adpm.de
---
src/tools/opensc-explorer.c | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/src/tools/opensc-explorer.c b/src/tools/opensc-explorer.c
index 2c6fb4e..636856d 100644
--- a/src/tools/opensc-explorer.c
+++ b/src/tools/opensc-explorer.c
@@ -342,7 +342,6 @@ static int do_cat(int argc, char **argv)
sc_file_t *file = NULL;
int not_current = 1;
int sfi = 0;
- const char sfi_prefix[] = sfi:;
if (argc 1)
goto usage;
@@ -351,17 +350,10 @@ static int do_cat(int argc, char **argv)
file = current_file;
not_current = 0;
} else {
- if (strncmp(argv[0], sfi_prefix, sizeof(sfi_prefix)-1)) {
- if (arg_to_path(argv[0], path, 1) != 0)
-goto usage;
- r = sc_select_file(card, path, file);
- if (r) {
-check_ret(r, SC_AC_OP_SELECT, unable to select file,
- current_file);
-goto err;
- }
- } else {
- const char *sfi_n
