Re: [opensc-devel] New Italian CNS/eID patch
On Sun, 2010-08-15 at 12:56 +0200, Emanuele Pucciarelli wrote: > Greetings, > > I have uploaded a new, updated patch for Italian CNS support against > the current trunk: > > http://www.opensc-project.org/opensc/attachment/ticket/177/itacns-patch3.diff > > Now all Secure Messaging bits are completely out (I'm working on that > separately) and there is only a tiny bit of dead code in apdu.c – I'm > unsure how to deal with that. The check *should* be there for short > Case 3 APDU's, but I can see no way to disable that only for Italian > CNS cards without fundamental changes to apdu.c (i.e. something like a > sc_trasnmit_apdu_without_check() function, or a "purposefully broken > APDU" flag in the sc_apdu_t structure). Actually you want to transmit a CASE 1 APDU ;) http://www.opensc-project.org/opensc/ticket/299 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Aug 27, 2010, at 12:55 PM, Andre Zepezauer wrote: > On Fri, 2010-08-27 at 11:12 +0300, Martin Paljak wrote: >> Hello, >> >> On Aug 26, 2010, at 6:34 PM, Andre Zepezauer wrote: >>> One application for the give_random() function is contained in the >>> attached patch. In short: C_SeedRandom() works fine with CardOS. Would >>> be interesting if the the other drivers will like it too. >> >> I don't see anything in the ETSI doc [1] that would suggest tat the GIVE >> RANDOM command actually seeds the onboard random generator. > > When seeding the rng isn't the task performed by this command, what else > does it do? Apparently the reverse of what GET CHALLENGE is used for: to give the random/nonce used in an authentication protocol. -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Fri, 2010-08-27 at 11:12 +0300, Martin Paljak wrote: > Hello, > > On Aug 26, 2010, at 6:34 PM, Andre Zepezauer wrote: > > One application for the give_random() function is contained in the > > attached patch. In short: C_SeedRandom() works fine with CardOS. Would > > be interesting if the the other drivers will like it too. > > I don't see anything in the ETSI doc [1] that would suggest tat the GIVE > RANDOM command actually seeds the onboard random generator. When seeding the rng isn't the task performed by this command, what else does it do? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
Hello, On Aug 26, 2010, at 6:34 PM, Andre Zepezauer wrote: > One application for the give_random() function is contained in the > attached patch. In short: C_SeedRandom() works fine with CardOS. Would > be interesting if the the other drivers will like it too. I don't see anything in the ETSI doc [1] that would suggest tat the GIVE RANDOM command actually seeds the onboard random generator. Checking for the presence of get_challenge before raising the CKF_RNG flag makes sense though. [1] http://www.etsi.org/deliver/etsi_ts/101200_101299/10120603/01.03.02_60/ts_10120603v010302p.pdf -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Tue, 2010-08-17 at 10:08 +0300, Martin Paljak wrote:
> Helo,
>
> On Aug 17, 2010, at 1:59 AM, Andre Zepezauer wrote:
> > On Mon, 2010-08-16 at 21:10 +0200, Emanuele Pucciarelli wrote:
> >>> @martin: When you are interested in improving iso7816.c, then rewrite
> >>> the select_file function. It is not very generic. For example it won't
> >>> work for my german debit card, which is of course iso-compliant. Also
> >>> get_data/put_data could be implemented.
> >>
> >> Speaking for myself here – examples and/or log traces would be
> >> helpful, I think. What doesn't work with your card, and you'd like to
> >> see improved?
> >
> > This particular card isn't important at all. But it shows, that the
> > select_file function doesn't work for an iso card. I had to write code,
> > to read the contents of this one. But I really would like to use
> > opensc-explorer for such a task. For example:
> > cat 2F00
> > cat 2F01
>
> Do you have a patch?
>
>
> >>> @ep: APDUs with Class Byte 0x80 are very misplaced in an iso-driver. I
> >>> guess that this was an accident.
> >>
> >> It isn't, to tell the truth; as the comment states, that APDU is not
> >> from ISO 7816, but rather from EN 726-3 (or ETSI TS 101 206-3, if you
> >> wish).
> >>
> >> The driver isn't using it any longer (as I'm looking at SM separately,
> >> following Viktor's work), so I don't "need" it. It may make sense to
> >> leave it there, though, as it is clearly marked not to be from ISO
> >> 7816 but from a different standard.
> >
> > There is still the question, if this is the right place for a command
> > not defined by iso. My answer is clearly not, because:
> > 1. Iso defines CLA 0x80 as proprietary which means, that every vendor
> > can code it's own proprietary commands in this class. Which in turn
> > leaves the possibility, that two different vendors define the same apdu
> > command in two completely different ways.
> > 2. Not even a single card driver overrides iso_ops->give_random. So
> > every driver would send this command down to the card. Which is not a
> > good idea (see point one).
>
> Don't take the iso7816.c as a strict ISO-7816-X driver but more like a
> "generic standards based driver other cards can extend". To bring this in
> action, some code needs to use the function and that code would expect this
> function to either work for a card or be overriden by the card driver.
One application for the give_random() function is contained in the
attached patch. In short: C_SeedRandom() works fine with CardOS. Would
be interesting if the the other drivers will like it too.
Regards
Andre
Index: pkcs11/framework-pkcs15.c
===
--- pkcs11/framework-pkcs15.c (revision 4654)
+++ pkcs11/framework-pkcs15.c (working copy)
@@ -1914,7 +1914,20 @@
return CKR_OK;
}
+static CK_RV pkcs15_seed_random(struct sc_pkcs11_card *p11card,
+CK_BYTE_PTR p, CK_ULONG len)
+{
+ int rv;
+ struct pkcs15_fw_data *fw_data = (struct pkcs15_fw_data *) p11card->fw_data;
+ struct sc_card *card = fw_data->p15_card->card;
+ if(card->ops->give_random == NULL)
+ return CKR_RANDOM_SEED_NOT_SUPPORTED;
+
+ rv = card->ops->give_random(card, p, (size_t)len);
+ return sc_to_cryptoki_error(rv, "C_SeedRandom");
+}
+
static CK_RV pkcs15_get_random(struct sc_pkcs11_card *p11card,
CK_BYTE_PTR p, CK_ULONG len)
{
@@ -1944,7 +1957,7 @@
NULL,
NULL,
#endif
- NULL, /* seed_random */
+ pkcs15_seed_random,
pkcs15_get_random
};
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
Hello! > What's the response to the select commands. Please can you post one. > Contains it something like that: A5:07:9F:65:04:02:02:01:01 > Important are the tags A5 and 9F65. If they are present, then it is most > likely that your card is a GlobalPlatform one. Redacted for brevity/clarity: ATR: 3b:6e:00:00:00:31:c0:71:c6:65:01:b0:01:03:37:83:90:00 $ ~/local/bin/opensc-explorer -m aid:a0:00:00:00:03:20:10 -vvv --> 00 A4 04 00 07 A0 00 00 00 03 20 10 .. . <-- 61 22 a" --> 00 C0 00 00 22 " <-- 6F 20 84 07 A0 00 00 00 03 20 10 A5 15 50 05 56 o ... ...P.V 20 50 41 59 87 01 02 5F 2D 08 69 74 65 6E 66 72 PAY..._-.itenfr 64 65 90 00 de.. --> 00 B2 01 0C 00 . (read record 1 from SFI 01) <-- 6C 29 l) --> 00 B2 01 0C 29 ) <-- 70 27 57 […] Bye, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
Hello Emanuele, On Sat, 2010-08-21 at 01:27 +0200, Emanuele Pucciarelli wrote: > On Tue, Aug 17, 2010 at 17:52, Andre Zepezauer > wrote: > > [about improving SELECT FILE in iso7816.c] > > > It would be nice, if the driver could be configured in a way to support > > such a scenario. The bits responsible for card detection should be > > placed in a function not part of the driver. > > FWIW, just to get one more data point, I have experimented this with > the two payments card I have. Both are EMV cards and have 31:c0 in > their historical bytes, meaning (according to the humble summaries of > 7816-4 that Google finds for me) they will only support application > selection by full or partial name. > > In fact, P1==04h is the only value that works for me with them; with > the current trunk you can use "info aid:xx:yy:zz..." to get some > information. What's the response to the select commands. Please can you post one. Contains it something like that: A5:07:9F:65:04:02:02:01:01 Important are the tags A5 and 9F65. If they are present, then it is most likely that your card is a GlobalPlatform one. > The info isn't exceedingly useful yet; the next steps are interpreting > the file type correctly and adding the capability to issue file > commands to that file by SFI. (It's in place in the API, e.g. through > the "flags" argument of sc_read_record(), but not in opensc-explorer.) > > Bye, > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Tue, Aug 17, 2010 at 17:52, Andre Zepezauer wrote: [about improving SELECT FILE in iso7816.c] > It would be nice, if the driver could be configured in a way to support > such a scenario. The bits responsible for card detection should be > placed in a function not part of the driver. FWIW, just to get one more data point, I have experimented this with the two payments card I have. Both are EMV cards and have 31:c0 in their historical bytes, meaning (according to the humble summaries of 7816-4 that Google finds for me) they will only support application selection by full or partial name. In fact, P1==04h is the only value that works for me with them; with the current trunk you can use "info aid:xx:yy:zz..." to get some information. The info isn't exceedingly useful yet; the next steps are interpreting the file type correctly and adding the capability to issue file commands to that file by SFI. (It's in place in the API, e.g. through the "flags" argument of sc_read_record(), but not in opensc-explorer.) Bye, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
Hello, On Aug 17, 2010, at 7:20 PM, Andre Zepezauer wrote: > On Tue, 2010-08-17 at 10:08 +0300, Martin Paljak wrote: >> For example, try to explain why the ISO GET CHALLENGE code from year 2001 >> reads the random from the card in 8 byte chunks? > > Because it's the most generic solution, that will work on every card. More likely that the code has been there since 2001 [1] and nobody has ever needed it or questioned it. What this basically means is that a lot of code is really old [2] and has seen zero improvement for years. Which is not bad per se, as "don't touch things that work" but what also means that a lot of code is slowly dying. Static code is dead code. Code that nobody knows why it exists or does something in a peculiar way that is hard to explain and without comments is bad, bad code. Especially if the original authors have left for new challenges long ago. I believe most cards can give a challenge for a full APDU size or at least 64-apdu_header_size bytes and save a few host<->card roundtrips. But a short peek in the OpenSC source reveals that the function is not really used at all, at least not for the original purpose (getting a challenge from the card for authentication purposes) but for random data generation. I would assume that the challenge used for mutual authentication would need to be asked in a single chunk instead of multiple small chunks. Nevertheless, I don't believe that the implementation of iso7816_get_challenge is correct, but don't rush to fix it either, because it seems to work for what it has been used for this far. Same applies to iso7816 select_file. Apparently the incomplete or incorrect implementation has not been the itch that needs scratching. Patches that fix (I'm sure there are many fixable issues in code) and/or improve OpenSC are most welcome. [1] http://www.opensc-project.org/opensc/changeset/89 [2] http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/iso7816.c?annotate=blame&rev=4627#L397 -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Tue, 2010-08-17 at 10:08 +0300, Martin Paljak wrote: > Helo, > > On Aug 17, 2010, at 1:59 AM, Andre Zepezauer wrote: > > On Mon, 2010-08-16 at 21:10 +0200, Emanuele Pucciarelli wrote: > >>> @martin: When you are interested in improving iso7816.c, then rewrite > >>> the select_file function. It is not very generic. For example it won't > >>> work for my german debit card, which is of course iso-compliant. Also > >>> get_data/put_data could be implemented. > >> > >> Speaking for myself here – examples and/or log traces would be > >> helpful, I think. What doesn't work with your card, and you'd like to > >> see improved? > > > > This particular card isn't important at all. But it shows, that the > > select_file function doesn't work for an iso card. I had to write code, > > to read the contents of this one. But I really would like to use > > opensc-explorer for such a task. For example: > > cat 2F00 > > cat 2F01 > > Do you have a patch? I don't have one, because the apdus are assembled right in the main function of my little custom app. > >>> @ep: APDUs with Class Byte 0x80 are very misplaced in an iso-driver. I > >>> guess that this was an accident. > >> > >> It isn't, to tell the truth; as the comment states, that APDU is not > >> from ISO 7816, but rather from EN 726-3 (or ETSI TS 101 206-3, if you > >> wish). > >> > >> The driver isn't using it any longer (as I'm looking at SM separately, > >> following Viktor's work), so I don't "need" it. It may make sense to > >> leave it there, though, as it is clearly marked not to be from ISO > >> 7816 but from a different standard. > > > > There is still the question, if this is the right place for a command > > not defined by iso. My answer is clearly not, because: > > 1. Iso defines CLA 0x80 as proprietary which means, that every vendor > > can code it's own proprietary commands in this class. Which in turn > > leaves the possibility, that two different vendors define the same apdu > > command in two completely different ways. > > 2. Not even a single card driver overrides iso_ops->give_random. So > > every driver would send this command down to the card. Which is not a > > good idea (see point one). > > Don't take the iso7816.c as a strict ISO-7816-X driver but more like a > "generic standards based driver other cards can extend". To bring this in > action, some code needs to use the function and that code would expect this > function to either work for a card or be overriden by the card driver. > > As long as it is not used currently, it can as well be removed for you peace > of mind for now. As long as card options is arbitrarily extended with the > function when needed, I don't see why it could not be in iso7816.c with a > nice "warning" in the source code. > > For example, try to explain why the ISO GET CHALLENGE code from year 2001 > reads the random from the card in 8 byte chunks? Because it's the most generic solution, that will work on every card. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Tue, 2010-08-17 at 16:02 +0200, Emanuele Pucciarelli wrote: > On Tue, Aug 17, 2010 at 03:07, Andre Zepezauer > wrote: > > > Cards which comply with chapter "9 Application-independent card > > services" of 7816-4 must implement 1,2,4. The preferred values used by > > the iso driver are 0,8,9. > > Now I think I see what you are after. :) > > So, you'd like the iso7816 driver to: > > - try to read the historical bytes and the 2F00/2F01 files > - establish the supported ways of using SELECT FILE > - remember them and pick the right one every time > iso7186_select_file() is invoked, to improve interoperability. > > Is that correct? It would be nice, if the driver could be configured in a way to support such a scenario. The bits responsible for card detection should be placed in a function not part of the driver. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Tue, Aug 17, 2010 at 03:07, Andre Zepezauer wrote: > Cards which comply with chapter "9 Application-independent card > services" of 7816-4 must implement 1,2,4. The preferred values used by > the iso driver are 0,8,9. Now I think I see what you are after. :) So, you'd like the iso7816 driver to: - try to read the historical bytes and the 2F00/2F01 files - establish the supported ways of using SELECT FILE - remember them and pick the right one every time iso7186_select_file() is invoked, to improve interoperability. Is that correct? Bye! -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
Helo, On Aug 17, 2010, at 1:59 AM, Andre Zepezauer wrote: > On Mon, 2010-08-16 at 21:10 +0200, Emanuele Pucciarelli wrote: >>> @martin: When you are interested in improving iso7816.c, then rewrite >>> the select_file function. It is not very generic. For example it won't >>> work for my german debit card, which is of course iso-compliant. Also >>> get_data/put_data could be implemented. >> >> Speaking for myself here – examples and/or log traces would be >> helpful, I think. What doesn't work with your card, and you'd like to >> see improved? > > This particular card isn't important at all. But it shows, that the > select_file function doesn't work for an iso card. I had to write code, > to read the contents of this one. But I really would like to use > opensc-explorer for such a task. For example: > cat 2F00 > cat 2F01 Do you have a patch? >>> @ep: APDUs with Class Byte 0x80 are very misplaced in an iso-driver. I >>> guess that this was an accident. >> >> It isn't, to tell the truth; as the comment states, that APDU is not >> from ISO 7816, but rather from EN 726-3 (or ETSI TS 101 206-3, if you >> wish). >> >> The driver isn't using it any longer (as I'm looking at SM separately, >> following Viktor's work), so I don't "need" it. It may make sense to >> leave it there, though, as it is clearly marked not to be from ISO >> 7816 but from a different standard. > > There is still the question, if this is the right place for a command > not defined by iso. My answer is clearly not, because: > 1. Iso defines CLA 0x80 as proprietary which means, that every vendor > can code it's own proprietary commands in this class. Which in turn > leaves the possibility, that two different vendors define the same apdu > command in two completely different ways. > 2. Not even a single card driver overrides iso_ops->give_random. So > every driver would send this command down to the card. Which is not a > good idea (see point one). Don't take the iso7816.c as a strict ISO-7816-X driver but more like a "generic standards based driver other cards can extend". To bring this in action, some code needs to use the function and that code would expect this function to either work for a card or be overriden by the card driver. As long as it is not used currently, it can as well be removed for you peace of mind for now. As long as card options is arbitrarily extended with the function when needed, I don't see why it could not be in iso7816.c with a nice "warning" in the source code. For example, try to explain why the ISO GET CHALLENGE code from year 2001 reads the random from the card in 8 byte chunks? Conclusion: please point out exact issues or provide a patch. -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Tue, 2010-08-17 at 02:08 +0200, Emanuele Pucciarelli wrote: > On Tue, Aug 17, 2010 at 00:59, Andre Zepezauer > This particular card isn't important at all. But it shows, that the > > select_file function doesn't work for an iso card. I had to write code, > > to read the contents of this one. But I really would like to use > > opensc-explorer for such a task. For example: > > cat 2F00 > > cat 2F01 > > I still think it wouldn't be bad if you could give an example of what > does not work and what does, because then, perhaps, someone would be > willing to help implement the missing (or wrong) functionality – > especially as you've already written your own code. > > As far as debit cards are concerned (EMV), my experience is that > opensc-explorer does not work because it tries to select the Master > File upon startup. A small patch to let the user choose a different > file, or not file at all, at startup, would overcome that. (Surely > there would be other problems later.) I'm unsure about your example of > "cat 2F00, cat 2F01", because I'm under the impression that EMV cards > use file selction by name (and not by file ID), but I may very well be > wrong here. The IIN is 672518 (Maestro debit cards (Germany)). I haven't looked close enough to be sure if it is a EMV. It has a MF (implicitly selected after reset), a lot of files (selected by fid) and a handful of application DFs (selected by aid/fid). The select command supports only the p1-values: 1: select df under current df 2: select ef under current df 3: select parent df 4: select df by name Cards which comply with chapter "9 Application-independent card services" of 7816-4 must implement 1,2,4. The preferred values used by the iso driver are 0,8,9. > > There is still the question, if this is the right place for a command > > not defined by iso. My answer is clearly not, because: > > 1. Iso defines CLA 0x80 as proprietary which means, that every vendor > > can code it's own proprietary commands in this class. Which in turn > > leaves the possibility, that two different vendors define the same apdu > > command in two completely different ways. > > Yes, this is possible in principle, although many sensible COS > manufacturers (or even developers writing BasicCard/JavaCard applets) > would question the opportunity of defining a proprietary command > overriding an international standard (EN 726) that's been in place for > so long. But the point is moot, because… > > > 2. Not even a single card driver overrides iso_ops->give_random. So > > every driver would send this command down to the card. Which is not a > > good idea (see point one). > > …as far as I am able to tell, this means that no driver at all will > ever send this command to the card, until someone decides to use it > somewhere in the code. > > That said, I'll reiterate: if give_random is significantly > controversial, I won't object to removing it, as it isn't being used. > > Bye! > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Tue, Aug 17, 2010 at 00:59, Andre Zepezauer This particular card isn't important at all. But it shows, that the > select_file function doesn't work for an iso card. I had to write code, > to read the contents of this one. But I really would like to use > opensc-explorer for such a task. For example: > cat 2F00 > cat 2F01 I still think it wouldn't be bad if you could give an example of what does not work and what does, because then, perhaps, someone would be willing to help implement the missing (or wrong) functionality – especially as you've already written your own code. As far as debit cards are concerned (EMV), my experience is that opensc-explorer does not work because it tries to select the Master File upon startup. A small patch to let the user choose a different file, or not file at all, at startup, would overcome that. (Surely there would be other problems later.) I'm unsure about your example of "cat 2F00, cat 2F01", because I'm under the impression that EMV cards use file selction by name (and not by file ID), but I may very well be wrong here. > There is still the question, if this is the right place for a command > not defined by iso. My answer is clearly not, because: > 1. Iso defines CLA 0x80 as proprietary which means, that every vendor > can code it's own proprietary commands in this class. Which in turn > leaves the possibility, that two different vendors define the same apdu > command in two completely different ways. Yes, this is possible in principle, although many sensible COS manufacturers (or even developers writing BasicCard/JavaCard applets) would question the opportunity of defining a proprietary command overriding an international standard (EN 726) that's been in place for so long. But the point is moot, because… > 2. Not even a single card driver overrides iso_ops->give_random. So > every driver would send this command down to the card. Which is not a > good idea (see point one). …as far as I am able to tell, this means that no driver at all will ever send this command to the card, until someone decides to use it somewhere in the code. That said, I'll reiterate: if give_random is significantly controversial, I won't object to removing it, as it isn't being used. Bye! -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Mon, 2010-08-16 at 21:10 +0200, Emanuele Pucciarelli wrote: > Hi Andre! > > Thanks for the remarks! > > > It works very well, right now. I have a modified cardos driver, which > > uses both functions (signing and decipherment from iso7816.c) with keys > > of 2048 bit. Seems to me, that there is nothing to be done here. > > Good to hear. Are you using reader-pcsc? Yes I do. The reader is a device manufactured by omnikey. The IFD-Handler is proprietary. > > @martin: When you are interested in improving iso7816.c, then rewrite > > the select_file function. It is not very generic. For example it won't > > work for my german debit card, which is of course iso-compliant. Also > > get_data/put_data could be implemented. > > Speaking for myself here – examples and/or log traces would be > helpful, I think. What doesn't work with your card, and you'd like to > see improved? This particular card isn't important at all. But it shows, that the select_file function doesn't work for an iso card. I had to write code, to read the contents of this one. But I really would like to use opensc-explorer for such a task. For example: cat 2F00 cat 2F01 > > @ep: APDUs with Class Byte 0x80 are very misplaced in an iso-driver. I > > guess that this was an accident. > > It isn't, to tell the truth; as the comment states, that APDU is not > from ISO 7816, but rather from EN 726-3 (or ETSI TS 101 206-3, if you > wish). > > The driver isn't using it any longer (as I'm looking at SM separately, > following Viktor's work), so I don't "need" it. It may make sense to > leave it there, though, as it is clearly marked not to be from ISO > 7816 but from a different standard. There is still the question, if this is the right place for a command not defined by iso. My answer is clearly not, because: 1. Iso defines CLA 0x80 as proprietary which means, that every vendor can code it's own proprietary commands in this class. Which in turn leaves the possibility, that two different vendors define the same apdu command in two completely different ways. 2. Not even a single card driver overrides iso_ops->give_random. So every driver would send this command down to the card. Which is not a good idea (see point one). > Greetings, > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
Hi Andre! Thanks for the remarks! > It works very well, right now. I have a modified cardos driver, which > uses both functions (signing and decipherment from iso7816.c) with keys > of 2048 bit. Seems to me, that there is nothing to be done here. Good to hear. Are you using reader-pcsc? > @martin: When you are interested in improving iso7816.c, then rewrite > the select_file function. It is not very generic. For example it won't > work for my german debit card, which is of course iso-compliant. Also > get_data/put_data could be implemented. Speaking for myself here – examples and/or log traces would be helpful, I think. What doesn't work with your card, and you'd like to see improved? > @ep: APDUs with Class Byte 0x80 are very misplaced in an iso-driver. I > guess that this was an accident. It isn't, to tell the truth; as the comment states, that APDU is not from ISO 7816, but rather from EN 726-3 (or ETSI TS 101 206-3, if you wish). The driver isn't using it any longer (as I'm looking at SM separately, following Viktor's work), so I don't "need" it. It may make sense to leave it there, though, as it is clearly marked not to be from ISO 7816 but from a different standard. Greetings, -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Sun, 2010-08-15 at 17:11 +0300, Martin Paljak wrote:
> On Aug 15, 2010, at 4:21 PM, Emanuele Pucciarelli wrote:
> > On Sun, Aug 15, 2010 at 13:45, Martin Paljak wrote:
> >> iso7816.c should not be taken as a final, static code, if there are checks
> >> missing from there, it is OK to improve iso7816.c as well :)
> >
> > I think that the checks already in place are all right. I guess that
> > implementation quirks may arise if and when 2048-bit keys are
> > supported, but currently I know of no CNS card with keys longer than
> > 1024 bit, so it's safe for the time being.
>
> That's a good example: iso7816.c should be eventually updated to work with
> extended APDU-s and 2048b keys as well.
It works very well, right now. I have a modified cardos driver, which
uses both functions (signing and decipherment from iso7816.c) with keys
of 2048 bit. Seems to me, that there is nothing to be done here.
@martin: When you are interested in improving iso7816.c, then rewrite
the select_file function. It is not very generic. For example it won't
work for my german debit card, which is of course iso-compliant. Also
get_data/put_data could be implemented.
@ep: APDUs with Class Byte 0x80 are very misplaced in an iso-driver. I
guess that this was an accident.
> >> I guess #237 would solve the problem almost cleanly for you.
> >>
> >> I remember a similar problem with Estonian ID card but after some digging
> >> in the specs and card manual it turned out to be somewhat sensible (Maybe
> >> something like 0x00 Le indicating "give me as much as you have", like in
> >> deciphering comments) but I can't locate the details nor changesets about
> >> it now.
> >
> > This was the right hint – I hadn't thought of that. :)
> >
> > Even though certainly no data is expected from the card when issuing a
> > MSE command, I switched to a Case 2 APDU with Le = 0. The transmitted
> > APDU is exactly the same (P3 set to 0), and I think that leaving room
> > for a small buffer on the stack is a less ugly workaround than
> > disabling the check logic in apdu.c. So the driver can live without
> > #237 :)
> Glad I could help. The transmit_bytes solution would also be nice but
> unfortunately the patch did not compile and I don't know the use case of
> ticket poster well enough to decide on the right approach (transmit to a card
> or transmit to a reader...)
>
> > The revised patch is now at
> > http://www.opensc-project.org/opensc/attachment/ticket/177/itacns-patch4.diff
> > , and I feel it addresses all points that have been brought up.
> Yes :)
>
> Some things to consider
> * javacard driver really should be the last but one driver before default.
> It is as dummy by nature as the default driver.
> * card->name vs driver->name. Currently the card driver name is long and in
> Italian ("Carta Nazionale dei Servizi") while the card name is short and in
> English. Keep in mind that the driver name is hidden from most users and the
> card name pops up with opensc-tool -n and in your case in PKCS#11 token
> labels. You might want to balance between them, as long as OpenSC does not
> have localization support.
> * Also, you use the card name as the PKCS#15 card label. From personal
> experience I'd suggest to use something personal instead of that, so that
> Firefox or thunderbird could differentiate between two cards of the same
> type. For the Estonian ID-card it used to be "ID-kaart" as well, but "MARTIN
> PALJAK (PIN1)" prompt beats "ID-kaart (PIN1)" prompt.
>
> Can I go ahead and commit it?
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Aug 15, 2010, at 4:21 PM, Emanuele Pucciarelli wrote:
> On Sun, Aug 15, 2010 at 13:45, Martin Paljak wrote:
>> iso7816.c should not be taken as a final, static code, if there are checks
>> missing from there, it is OK to improve iso7816.c as well :)
>
> I think that the checks already in place are all right. I guess that
> implementation quirks may arise if and when 2048-bit keys are
> supported, but currently I know of no CNS card with keys longer than
> 1024 bit, so it's safe for the time being.
That's a good example: iso7816.c should be eventually updated to work with
extended APDU-s and 2048b keys as well.
>> I guess #237 would solve the problem almost cleanly for you.
>>
>> I remember a similar problem with Estonian ID card but after some digging in
>> the specs and card manual it turned out to be somewhat sensible (Maybe
>> something like 0x00 Le indicating "give me as much as you have", like in
>> deciphering comments) but I can't locate the details nor changesets about it
>> now.
>
> This was the right hint – I hadn't thought of that. :)
>
> Even though certainly no data is expected from the card when issuing a
> MSE command, I switched to a Case 2 APDU with Le = 0. The transmitted
> APDU is exactly the same (P3 set to 0), and I think that leaving room
> for a small buffer on the stack is a less ugly workaround than
> disabling the check logic in apdu.c. So the driver can live without
> #237 :)
Glad I could help. The transmit_bytes solution would also be nice but
unfortunately the patch did not compile and I don't know the use case of ticket
poster well enough to decide on the right approach (transmit to a card or
transmit to a reader...)
> The revised patch is now at
> http://www.opensc-project.org/opensc/attachment/ticket/177/itacns-patch4.diff
> , and I feel it addresses all points that have been brought up.
Yes :)
Some things to consider
* javacard driver really should be the last but one driver before default. It
is as dummy by nature as the default driver.
* card->name vs driver->name. Currently the card driver name is long and in
Italian ("Carta Nazionale dei Servizi") while the card name is short and in
English. Keep in mind that the driver name is hidden from most users and the
card name pops up with opensc-tool -n and in your case in PKCS#11 token labels.
You might want to balance between them, as long as OpenSC does not have
localization support.
* Also, you use the card name as the PKCS#15 card label. From personal
experience I'd suggest to use something personal instead of that, so that
Firefox or thunderbird could differentiate between two cards of the same type.
For the Estonian ID-card it used to be "ID-kaart" as well, but "MARTIN PALJAK
(PIN1)" prompt beats "ID-kaart (PIN1)" prompt.
Can I go ahead and commit it?
--
Martin Paljak
@martinpaljak.net
+3725156495
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
On Sun, Aug 15, 2010 at 13:45, Martin Paljak wrote: > Great! IMO that's good to go, I have only one small comment: > * Do I miss something or does the itacns_compute_signature -> > do_compute_signature chain translate almost 1:1 to iso7816_compute_signature > with an additional check in itacns_compute_signature ? > * The same seems to apply for itacns_decipher -> do_decipher and > iso7816_decipher That's entirely correct. :) I have double-checked, and I have removed the "custom" functions from card-itacns.c altogether. > iso7816.c should not be taken as a final, static code, if there are checks > missing from there, it is OK to improve iso7816.c as well :) I think that the checks already in place are all right. I guess that implementation quirks may arise if and when 2048-bit keys are supported, but currently I know of no CNS card with keys longer than 1024 bit, so it's safe for the time being. > I guess #237 would solve the problem almost cleanly for you. > > I remember a similar problem with Estonian ID card but after some digging in > the specs and card manual it turned out to be somewhat sensible (Maybe > something like 0x00 Le indicating "give me as much as you have", like in > deciphering comments) but I can't locate the details nor changesets about it > now. This was the right hint – I hadn't thought of that. :) Even though certainly no data is expected from the card when issuing a MSE command, I switched to a Case 2 APDU with Le = 0. The transmitted APDU is exactly the same (P3 set to 0), and I think that leaving room for a small buffer on the stack is a less ugly workaround than disabling the check logic in apdu.c. So the driver can live without #237 :) > javax.smartcardio also does APDU mangling and it is not possible to send such > APDU-s, as it eats away the final zero... Thanks for the heads up. It might be that I'm going to play with it in the future (Roberto Resoli graciously pointed me to the Mocca project[1]). I hope that the CommandAPDU(ByteBuffer apdu) form does not try to mangle the APDU, but I've never tried. The revised patch is now at http://www.opensc-project.org/opensc/attachment/ticket/177/itacns-patch4.diff , and I feel it addresses all points that have been brought up. Thanks! [1] http://mocca.egovlabs.gv.at/ -- Emanuele > > >> Thank you in advance for any comment/feedback. I'm looking forward to >> getting this into shape for integration in trunk. > > > [1] http://www.opensc-project.org/opensc/ticket/237 > -- > Martin Paljak > @martinpaljak.net > +3725156495 > > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New Italian CNS/eID patch
Hello, On Aug 15, 2010, at 1:56 PM, Emanuele Pucciarelli wrote: > I have uploaded a new, updated patch for Italian CNS support against > the current trunk: > > http://www.opensc-project.org/opensc/attachment/ticket/177/itacns-patch3.diff Great! IMO that's good to go, I have only one small comment: * Do I miss something or does the itacns_compute_signature -> do_compute_signature chain translate almost 1:1 to iso7816_compute_signature with an additional check in itacns_compute_signature ? * The same seems to apply for itacns_decipher -> do_decipher and iso7816_decipher iso7816.c should not be taken as a final, static code, if there are checks missing from there, it is OK to improve iso7816.c as well :) > Now all Secure Messaging bits are completely out (I'm working on that > separately) and there is only a tiny bit of dead code in apdu.c – I'm > unsure how to deal with that. The check *should* be there for short > Case 3 APDU's, but I can see no way to disable that only for Italian > CNS cards without fundamental changes to apdu.c (i.e. something like a > sc_trasnmit_apdu_without_check() function, or a "purposefully broken > APDU" flag in the sc_apdu_t structure). I guess #237 would solve the problem almost cleanly for you. I remember a similar problem with Estonian ID card but after some digging in the specs and card manual it turned out to be somewhat sensible (Maybe something like 0x00 Le indicating "give me as much as you have", like in deciphering comments) but I can't locate the details nor changesets about it now. javax.smartcardio also does APDU mangling and it is not possible to send such APDU-s, as it eats away the final zero... > Thank you in advance for any comment/feedback. I'm looking forward to > getting this into shape for integration in trunk. [1] http://www.opensc-project.org/opensc/ticket/237 -- Martin Paljak @martinpaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] New Italian CNS/eID patch
Greetings, I have uploaded a new, updated patch for Italian CNS support against the current trunk: http://www.opensc-project.org/opensc/attachment/ticket/177/itacns-patch3.diff Now all Secure Messaging bits are completely out (I'm working on that separately) and there is only a tiny bit of dead code in apdu.c – I'm unsure how to deal with that. The check *should* be there for short Case 3 APDU's, but I can see no way to disable that only for Italian CNS cards without fundamental changes to apdu.c (i.e. something like a sc_trasnmit_apdu_without_check() function, or a "purposefully broken APDU" flag in the sc_apdu_t structure). Thank you in advance for any comment/feedback. I'm looking forward to getting this into shape for integration in trunk. Bye! -- Emanuele ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
