Re: [opensc-devel] Creation of card pkcs#15 structure
Hi, > From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of Viktor TARASOV > > On 13.01.2011 18:23, Aventra wrote: > > Hi, > > > >> From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel- > boun...@lists.opensc-project.org] On Behalf Of Viktor TARASOV > >> Do you use the myeid.profile that is actually in the trunk? > >> Normally you don't need SoPIN if you use it. The essentials CREATE, UPDATE > >> acls reference the User PIN. > >> In my tests with opensc tools (import PKCS#12, key generation) SOPIN was > not needed for MyEID card. > > Yes I agree that normally the SO-PIN is not needed, but I think we are > > talking about different things now. > > Somebody might want to protect the card more than others. At least in > > Finland it is very common to have 3 PIN codes (basic, sign and so-pin), > > and the SO-PIN protects these xDF files from deletion (not update of > > course). > > So, you are talking about profile that is more protected then the one that is > actually in trunk. Anybody can change the profile if they want to. We have defined a default profile for MyEID that suits common cases. > What do you think, will it be sufficient, during the card initialization, > to create all xDF files that have 'CREATE' protected by SOPIN ? What I mean is that OpenSC would create the whole structure defined in the profile, regardless of the ACL:s. I know that the driver can do this by itself, but why not implement it to OpenSC so that it would work for all cards? One thing it could do, is to check when initialization is done each of the known identifiers (PrKDF, PuKDF, CDF..), if these have been defined in the profile, it would create them. One additional feature that is lacking from OpenSC is that it does not create the PIN codes automatically (except the SO-PIN). > If yes, we don't need additional profile configuration option. > > If not, probably, we have to introduce some new profile configuration option > like 'create-all-xdfs', > or 'create-at-initialisation' option for every xDF file in profile, etc ... I don't see why this structure could't always be created, without any new configuration options. After all, the profile defines the desired structure. For me, card initialization means that after it has been done, the card can be used without any further creation of the structure (xDF files and other that describe the content of the card). At first these files would be empty of course. > >>> It would be important if OpenSC would create the > >>> entire structure defined in the myeid.profile. > >> Agree in the case when 'CREATE' of the xDF files is protected by SOPIN. > > I mean that I would like to have pkcs15-init create the entire pkcs#15 > > structure defined in the profile, no matter what the ACL:s are. > > Since other software doesn't know how to create these files if they don't > > exist. > > You still need to create certificate files, data files, probably more ... > They cannot have the same 'protected' ACLs as the xDFs. > > > On 13.01.2011 16:43, Aventra wrote: > > >> >> From:opensc-devel-boun...@lists.opensc-project.org [mailto:opensc- > devel-boun...@lists.opensc-project.org] On Behalf Of Viktor TARASOV > >> >> In your profile, do you have different 'CREATE' ACLs for xDF and object > data (for ex. certificates) files? > > > No these are the same. > > They cannot have the same 'protected' ACLs as the xDFs. Yes, I understand that there is no point in protecting e.g. a certificate with SO-PIN. Kind regards, Toni ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
Hello Andre, On 14.01.2011 04:24, Andre Zepezauer wrote: > please have a look at PKCS#15 "6.8.2 Pin objects" for the definition of > local and global PIN objects. There is no mention of storage location. There is mention of 'path'. The difference between 'global' and 'local' is that the first one can be verified from any location on the card, the second one is 'visible' only from somewhere under the DF (or application) where it's defined. So, we need (or, if you like, it's useful) to have 'path' defined for the local PINs, to be able to select it's path before verification. That's what sc_pkcs15_verify_pin() is actually doing. http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-pin.c#L246 > So, why trying to fix something that's not broken? No one said that something is broken. It's a kind reverence to some native PKCS#15 card structures that happens to not have 'path' in 'PinAttributes' for the local PINs. > BTW it segfaults. The 'valgrind' output or OpenSC debug logs would be greately appreciated . On of the possible reason is printing of not completely initialized 'sc_path' variables . 'AID' member was introduced into 'struct sc_path'. Actually in OpenSC source 'generally' this data type is initialized member by member, 'memset' is not always applied to the entire location . I was trying to track such a cases, but, probably, there are still some of them. Once more, your help would be appreciated a lot. > Regards > Andre Kind wishes, Viktor. > -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] unknown sc_pkcs15init_finalize_profile
Hello Victor, your changeset http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15.c?rev=5087 introduce sc_pkcs15init_finalize_profile in libopensc.export but seems unknow in source code, may I remove it since it prevent from building? François. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Creation of card pkcs#15 structure
On 14.01.2011 09:57, Aventra wrote: > Hi, > >> From: >> opensc-devel-boun...@lists.opensc-project.org[mailto:opensc-devel-boun...@lists.opensc-project.org] >> On Behalf Of Viktor TARASOV >> On 13.01.2011 18:23, Aventra wrote: From: opensc-devel-boun...@lists.opensc-project.org[mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of Viktor TARASOV Do you use the myeid.profile that is actually in the trunk? Normally you don't need SoPIN if you use it. The essentials CREATE, UPDATE acls reference the User PIN. In my tests with opensc tools (import PKCS#12, key generation) SOPIN wasnot needed for MyEID card. >>> Yes I agree that normally the SO-PIN is not needed, but I think we are >>> talking about different things now. >>> Somebody might want to protect the card more than others. At least in >>> Finland it is very common to have 3 PIN codes (basic, sign and so-pin), >>> and the SO-PIN protects these xDF files from deletion (not update of >>> course). >> So, you are talking about profile that is more protected then the one that >> is actually in trunk. > Anybody can change the profile if they want to. We have defined a default > profile for MyEID that suits common cases. Just for the sake of curiosity, can you post here an example of 'protected' profile for MyEID card? >> What do you think, will it be sufficient, during the card initialization, >> to create all xDF files that have 'CREATE' protected by SOPIN ? > What I mean is that OpenSC would create the whole structure defined in the > profile, regardless of the ACL:s. > I know that the driver can do this by itself, but why not implement it to > OpenSC so that it would work for all cards? Personally I have no objections, but we cannot take rapid decision for all the cards. I don't know if actually somebody considers as useful to not create all xDFs (including rarely used DODF, SKDF, ). We'll be waiting for the other opinions. What can be done easily is a new profile option "create-all-xDF". So that, you will have the possibility to do what you want in a non-intrusive for the other cards manner. Take also into consideration that all card profile are loaded after the general 'pkcs15.profile', where all xDF are defined. And so the list of xDFs to create is not completely controlled by the card's profile. > One thing it could do, is to check when initialization is done each of the > known identifiers (PrKDF, PuKDF, CDF..), > if these have been defined in the profile, it would create them. > > One additional feature that is lacking from OpenSC is that it does not > create the PIN codes automatically (except the SO-PIN). Sorry I do not follow what you mean. Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] unknown sc_pkcs15init_finalize_profile
Hello François, On 14.01.2011 10:26, francois.lebl...@cev-sa.com wrote: > your changeset > http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15.c?rev=5087 > > > introduce sc_pkcs15init_finalize_profile in libopensc.export but seems > unknow in source > > code, may I remove it since it prevent from building? Of cause, sorry. > François. Kind wishes, Viktor. > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[5071] iso7816: Don' t translate a returned FCP template from SELECT FILE to " unknown data received"
On Sun, Jan 09, 2011 at 10:17:09AM +, webmas...@opensc-project.org wrote: > Log Message: > --- > iso7816: Don't translate a returned FCP template from SELECT FILE to > "unknown data received" This log message looks like you wanted to actually change some behaviour, but in the code I don't see any behavourial change, only source clean-up that does not change the compiled code. > Modified Paths: > -- > trunk/src/libopensc/iso7816.c > Modified: trunk/src/libopensc/iso7816.c > === > --- trunk/src/libopensc/iso7816.c 2011-01-09 10:02:43 UTC (rev 5070) > +++ trunk/src/libopensc/iso7816.c 2011-01-09 10:17:08 UTC (rev 5071) > @@ -487,12 +487,12 @@ > card->ops->process_fci(card, file, apdu.resp+2, > apdu.resp[1]); > *file_out = file; > break; > - case 0x00: /* proprietary coding */ > + case 0x00: /* proprietary coding */ > SC_FUNC_RETURN(card->ctx, SC_LOG_DEBUG_VERBOSE, > SC_ERROR_UNKNOWN_DATA_RECEIVED); > default: > SC_FUNC_RETURN(card->ctx, SC_LOG_DEBUG_VERBOSE, > SC_ERROR_UNKNOWN_DATA_RECEIVED); > } > - return 0; > + return SC_SUCCESS; > } > > static int iso7816_get_challenge(sc_card_t *card, u8 *rnd, size_t len) ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Configure content of the log message
On 13.01.2011 21:20, Andre Zepezauer wrote:
> On Thu, 2011-01-13 at 17:58 +0100, Viktor TARASOV wrote:
>> On 13.01.2011 17:07, Andre Zepezauer wrote:
>>> Hello,
>>>
>>> OpenSC as a library doesn't need it's own logging system. Such things
>>> are better placed at application level. If debugging is necessary, then
>>> 'export OPENSC_DEBUG=9' + pkcs11-spy works for me.
>>>
>>> What would be the advantage of having logs of different instances of
>>> OpenSC intermixed in a single file?
>> To have shorter line in logs,
>> "card.c:322:sc_unlock: called"
>> instead of
>> "0x2b20d02e53f0 17:50:57.667 [opensc-explorer] card.c:322:sc_unlock:
>> called"
> Making the lines shorter isn't that bad. But making it configurable is a
> lot of overhead. Personally I wouldn't miss anything if a line would
> look like this: "card.c:322:sc_unlock: called"
If we have to make a binary choice between 'short' and 'long' message, I prefer
the long one.
I (my) real life timestamp in logs is extremely useful. Also PID, when opensc
is running on the server side.
But during development, when looking the logs, it's annoying to have 1/3 of the
screen filled with the unused information.
>> Well, I do not see general enthusiasm, let's forget it.
>>
>>> Regards
>>> Andre
>> Kind wishes,
>> Viktor.
>>
>>
>>> On Thu, 2011-01-13 at 16:14 +0100, Viktor TARASOV wrote:
Hi,
what do you think about possibility to configure content of the log
message.
I mean something like this in 'opensc.conf':
app default {
log_level = debug;
log debug {
debug = 8;
debug_file = /tmp/opensc-debug.log;
print_pid = false; #default true
print_timestamp = false; #default true
print_app_name = false; #default true
}
...
Kind wishes,
Viktor.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>
>
--
Viktor Tarasov
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[5071] iso7816: Don' t translate a returned FCP template from SELECT FILE to " unknown data received"
On Jan 14, 2011, at 11:34 AM, Lionel Elie Mamane wrote: > On Sun, Jan 09, 2011 at 10:17:09AM +, webmas...@opensc-project.org wrote: > >> Log Message: >> --- >> iso7816: Don't translate a returned FCP template from SELECT FILE to >> "unknown data received" > > This log message looks like you wanted to actually change some > behaviour, but in the code I don't see any behavourial change, only > source clean-up that does not change the compiled code. Indeed, it was mostly a NOP after a git merge, Viktor had done the same thing independently from what I did in r5062 -- @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] r5081
On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote: > Hello Andre, > > On 14.01.2011 04:24, Andre Zepezauer wrote: > > please have a look at PKCS#15 "6.8.2 Pin objects" for the definition of > > local and global PIN objects. There is no mention of storage location. > There is mention of 'path'. > The difference between 'global' and 'local' is that the first one can be > verified from any location on the card, > the second one is 'visible' only from somewhere under the DF (or application) > where it's defined. > > So, we need (or, if you like, it's useful) to have 'path' defined for the > local PINs, to be able to select it's path before verification. >From PKCS#15 6.8.2 Pin objects: "PinAttributes.path: Path to the DF in which the PIN resides. The path shall be selected by a host application before doing a PIN operation, in order to enable a suitable authentication context for the PIN operation. If not present, a card-holder verification must always be possible to perform without a prior `SELECT' operation." Regards Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
On 14.01.2011 13:37, Andre Zepezauer wrote: > On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote: >> Hello Andre, >> >> On 14.01.2011 04:24, Andre Zepezauer wrote: >>> please have a look at PKCS#15 "6.8.2 Pin objects" for the definition of >>> local and global PIN objects. There is no mention of storage location. >> There is mention of 'path'. >> The difference between 'global' and 'local' is that the first one can be >> verified from any location on the card, >> the second one is 'visible' only from somewhere under the DF (or >> application) where it's defined. >> >> So, we need (or, if you like, it's useful) to have 'path' defined for the >> local PINs, to be able to select it's path before verification. My previous assumptions comes from this citation. It seems that I am terribly missing something. Can you give more details? > > From PKCS#15 6.8.2 Pin objects: > "PinAttributes.path: Path to the DF in which the PIN resides. The path > shall be selected >by a host application before doing a PIN operation, in order to enable a > suitable >authentication context for the PIN operation. That's 'local' PIN. > If not present, a card-holder verification >must always be possible to perform without a prior `SELECT' operation." That's the global one. So we desperately need the 'path' for the local PINs. So that 'host application' can select the path 'before doing a PIN operation'. You probably know another way to do verification from the random location on the card ? > Regards > Andre Kind wishes, Viktor. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote: > On 14.01.2011 13:37, Andre Zepezauer wrote: > > On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote: > >> Hello Andre, > >> > >> On 14.01.2011 04:24, Andre Zepezauer wrote: > >>> please have a look at PKCS#15 "6.8.2 Pin objects" for the definition of > >>> local and global PIN objects. There is no mention of storage location. > >> There is mention of 'path'. > >> The difference between 'global' and 'local' is that the first one can be > >> verified from any location on the card, > >> the second one is 'visible' only from somewhere under the DF (or > >> application) where it's defined. > >> > >> So, we need (or, if you like, it's useful) to have 'path' defined for the > >> local PINs, to be able to select it's path before verification. > > My previous assumptions comes from this citation. > It seems that I am terribly missing something. Can you give more details? > > > > > From PKCS#15 6.8.2 Pin objects: > > "PinAttributes.path: Path to the DF in which the PIN resides. The path > > shall be selected > >by a host application before doing a PIN operation, in order to enable a > > suitable > >authentication context for the PIN operation. > That's 'local' PIN. > > > If not present, a card-holder verification > >must always be possible to perform without a prior `SELECT' operation." > That's the global one. > > > So we desperately need the 'path' for the local PINs. So that 'host > application' can select the path > 'before doing a PIN operation'. > You probably know another way to do verification from the random location on > the card ? Take Java Card with PKI applet as an example. Once the applet is selected, it is possible to perform the VERIFY command from every location within that applet. That's 'local' PIN too. Because it's only valid for that applet but not for the whole card. BTW care must be take with re-selecting an applet in Java Cards, because it may invalidate all previously verified PINs. Regards Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
On 14.01.2011 15:17, Andre Zepezauer wrote: > On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote: >> On 14.01.2011 13:37, Andre Zepezauer wrote: >>> On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote: Hello Andre, On 14.01.2011 04:24, Andre Zepezauer wrote: > please have a look at PKCS#15 "6.8.2 Pin objects" for the definition of > local and global PIN objects. There is no mention of storage location. There is mention of 'path'. The difference between 'global' and 'local' is that the first one can be verified from any location on the card, the second one is 'visible' only from somewhere under the DF (or application) where it's defined. So, we need (or, if you like, it's useful) to have 'path' defined for the local PINs, to be able to select it's path before verification. >> My previous assumptions comes from this citation. >> It seems that I am terribly missing something. Can you give more details? >> >> From PKCS#15 6.8.2 Pin objects: >>>"PinAttributes.path: Path to the DF in which the PIN resides. The path >>> shall be selected >>> by a host application before doing a PIN operation, in order to enable >>> a suitable >>> authentication context for the PIN operation. >> That's 'local' PIN. >> >>> If not present, a card-holder verification >>> must always be possible to perform without a prior `SELECT' operation." >> That's the global one. >> >> >> So we desperately need the 'path' for the local PINs. So that 'host >> application' can select the path >> 'before doing a PIN operation'. >> You probably know another way to do verification from the random location on >> the card ? > Take Java Card with PKI applet as an example. Once the applet is > selected, it is possible to perform the VERIFY command from every > location within that applet. That's 'local' PIN too. Because it's only > valid for that applet but not for the whole card. OK, let us adjust the terminology. I am talking about the PKCS#15 card. This card starts from some MF, where exist EF.DIR, probably EF.ATR, ..., as well as application DFs. The AID of application DFs are present in the EF.DIR records. The global PINs are defined at the MF level or above, the local ones are defined in application DFs. In my comprehension to create/use the PKCS#15 objects you don't need to jump higher then MF, and thus to reset status of 'global' PINs. You have another vision, examples ? > BTW care must be take with re-selecting an applet in Java Cards, because > it may invalidate all previously verified PINs. The AIDs of the applets of your Java Card, are they present in some EF.DIR ? Can its be discovered by the procedure previewed by PKCS#15 ? Our card starts from EF.DIR. Everything that is above this file is out of PKCS#15 context. > > Regards > Andre Kind wishes, Viktor. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Creation of card pkcs#15 structure
Hi, > From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel- > > Anybody can change the profile if they want to. We have defined a default > profile for MyEID that suits common cases. > > Just for the sake of curiosity, can you post here an example of 'protected' > profile for MyEID card? We don't have that kind of profile, but somebody could make one if they like. > > >> What do you think, will it be sufficient, during the card initialization, > >> to create all xDF files that have 'CREATE' protected by SOPIN ? > > What I mean is that OpenSC would create the whole structure defined in the > > profile, regardless of the ACL:s. > > I know that the driver can do this by itself, but why not implement it to > OpenSC so that it would work for all cards? > Personally I have no objections, but we cannot take rapid decision for all the > cards. I don't know if actually somebody considers as useful > to not create all xDFs (including rarely used DODF, SKDF, ). We'll be waiting > for the other opinions. > > What can be done easily is a new profile option "create-all-xDF". So that, you > will have the possibility to do what you want in a non-intrusive for the other > cards manner. > > Take also into consideration that all card profile are loaded after the > general 'pkcs15.profile', where all xDF are defined. > And so the list of xDFs to create is not completely controlled by the card's > profile. > OK, well then perhaps this should be implemented to the card driver. > > > One thing it could do, is to check when initialization is done each of the > > known identifiers (PrKDF, PuKDF, CDF..), > > if these have been defined in the profile, it would create them. > > > > One additional feature that is lacking from OpenSC is that it does not > > create the PIN codes automatically (except the SO-PIN). > Sorry I do not follow what you mean. I mean that currently when initializing a MyEID card you need to run the following commands: - pkcs15-init -C/* create structure */ - pkcs15-init -P -a 1 /* create user pin */ - pkcs15-init -F/* finalize (activate) card */ The first command actually asks for the User PIN but does not create it. It would be nice if it would create it. I have no experience with other cards, so don't know how if the User PIN is created using the first command or not. It's not a big issue, but still, it's one extra step you need to know when initializing cards. Kind regards, Toni > > Kind wishes, > Viktor. > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Creation of card pkcs#15 structure
On Fri, 2011-01-14 at 17:42 +0200, Aventra wrote: > Hi, > > > From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel- > > > Anybody can change the profile if they want to. We have defined a > default > > profile for MyEID that suits common cases. > > > > Just for the sake of curiosity, can you post here an example of > 'protected' > > profile for MyEID card? > > We don't have that kind of profile, but somebody could make one if they > like. > > > > > >> What do you think, will it be sufficient, during the card > initialization, > > >> to create all xDF files that have 'CREATE' protected by SOPIN ? > > > What I mean is that OpenSC would create the whole structure defined in > the > > > profile, regardless of the ACL:s. > > > I know that the driver can do this by itself, but why not implement it > to > > OpenSC so that it would work for all cards? > > Personally I have no objections, but we cannot take rapid decision for all > the > > cards. I don't know if actually somebody considers as useful > > to not create all xDFs (including rarely used DODF, SKDF, ). We'll be > waiting > > for the other opinions. > > > > What can be done easily is a new profile option "create-all-xDF". So that, > you > > will have the possibility to do what you want in a non-intrusive for the > other > > cards manner. > > > > Take also into consideration that all card profile are loaded after the > > general 'pkcs15.profile', where all xDF are defined. > > And so the list of xDFs to create is not completely controlled by the > card's > > profile. > > > OK, well then perhaps this should be implemented to the card driver. > > > > > > One thing it could do, is to check when initialization is done each of > the > > > known identifiers (PrKDF, PuKDF, CDF..), > > > if these have been defined in the profile, it would create them. > > > > > > One additional feature that is lacking from OpenSC is that it does not > > > create the PIN codes automatically (except the SO-PIN). > > Sorry I do not follow what you mean. > > I mean that currently when initializing a MyEID card you need to run the > following commands: > - pkcs15-init -C /* create structure */ > - pkcs15-init -P -a 1 /* create user pin */ > - pkcs15-init -F /* finalize (activate) card */ Looks like a simple shell script would be the right solution. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
On Fri, 2011-01-14 at 16:00 +0100, Viktor TARASOV wrote: > On 14.01.2011 15:17, Andre Zepezauer wrote: > > On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote: > >> On 14.01.2011 13:37, Andre Zepezauer wrote: > >>> On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote: > Hello Andre, > > On 14.01.2011 04:24, Andre Zepezauer wrote: > > please have a look at PKCS#15 "6.8.2 Pin objects" for the definition of > > local and global PIN objects. There is no mention of storage location. > There is mention of 'path'. > The difference between 'global' and 'local' is that the first one can be > verified from any location on the card, > the second one is 'visible' only from somewhere under the DF (or > application) where it's defined. > > So, we need (or, if you like, it's useful) to have 'path' defined for > the local PINs, to be able to select it's path before verification. > >> My previous assumptions comes from this citation. > >> It seems that I am terribly missing something. Can you give more details? > >> > >> > From PKCS#15 6.8.2 Pin objects: > >>>"PinAttributes.path: Path to the DF in which the PIN resides. The path > >>> shall be selected > >>> by a host application before doing a PIN operation, in order to > >>> enable a suitable > >>> authentication context for the PIN operation. > >> That's 'local' PIN. > >> > >>> If not present, a card-holder verification > >>> must always be possible to perform without a prior `SELECT' > >>> operation." > >> That's the global one. > >> > >> > >> So we desperately need the 'path' for the local PINs. So that 'host > >> application' can select the path > >> 'before doing a PIN operation'. > >> You probably know another way to do verification from the random location > >> on the card ? > > Take Java Card with PKI applet as an example. Once the applet is > > selected, it is possible to perform the VERIFY command from every > > location within that applet. That's 'local' PIN too. Because it's only > > valid for that applet but not for the whole card. > > > OK, let us adjust the terminology. > I am talking about the PKCS#15 card. This card starts from some MF, where > exist EF.DIR, probably EF.ATR, ..., as well as application DFs. > The AID of application DFs are present in the EF.DIR records. > The global PINs are defined at the MF level or above, the local ones are > defined in application DFs. > > In my comprehension to create/use the PKCS#15 objects you don't need to jump > higher then MF, and thus to reset status of 'global' PINs. > You have another vision, examples ? > > > > BTW care must be take with re-selecting an applet in Java Cards, because > > it may invalidate all previously verified PINs. > > The AIDs of the applets of your Java Card, are they present in some EF.DIR ? > Can its be discovered by the procedure previewed by PKCS#15 ? You only need to have a default applet that can handle "SELECT 2F00" and "READ BINARY" to dump EF.DIR. The next command would be a "SELECT BY NAME", which is handled by the runtime environment and switches form one applet to another. Now you can proceed with 5031 and 5032. The whole process is nearly transparent. There are only two issues I encountered so far: * there is no MF per default, but it could be simulated by the applets * "SELECT BY NAME" is handled by the Java RE which imposes it's own semantics for that command > Our card starts from EF.DIR. Everything that is above this file is out of > PKCS#15 context. > > > > > > Regards > > Andre > > Kind wishes, > Viktor. > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Creation of card pkcs#15 structure
On 14.01.2011 16:42, Aventra wrote: > Hi, > >> From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel- >>> Anybody can change the profile if they want to. We have defined a default >>> profile for MyEID that suits common cases. >> Just for the sake of curiosity, can you post here an example of 'protected' >> profile for MyEID card? > We don't have that kind of profile, but somebody could make one if they like. I see. What do you think, will it be sufficient, during the card initialization, to create all xDF files that have 'CREATE' protected by SOPIN ? >>> What I mean is that OpenSC would create the whole structure defined in the >>> profile, regardless of the ACL:s. >>> I know that the driver can do this by itself, but why not implement it to >>> OpenSC so that it would work for all cards? >> Personally I have no objections, but we cannot take rapid decision for all >> the cards. I don't know if actually somebody considers as useful >> to not create all xDFs (including rarely used DODF, SKDF, ). We'll be >> waiting for the other opinions. >> >> What can be done easily is a new profile option "create-all-xDF". So that, >> you will have the possibility to do what you want in a non-intrusive for the >> other cards manner. >> >> Take also into consideration that all card profile are loaded after the >> general 'pkcs15.profile', where all xDF are defined. >> And so the list of xDFs to create is not completely controlled by the card's >> profile. >> > OK, well then perhaps this should be implemented to the card driver. Why not. It's the most rapid and un-intrusive solution. >>> One thing it could do, is to check when initialization is done each of the >>> known identifiers (PrKDF, PuKDF, CDF..), >>> if these have been defined in the profile, it would create them. >>> >>> One additional feature that is lacking from OpenSC is that it does not >>> create the PIN codes automatically (except the SO-PIN). >> Sorry I do not follow what you mean. > I mean that currently when initializing a MyEID card you need to run the > following commands: > - pkcs15-init -C /* create structure */ > - pkcs15-init -P -a 1 /* create user pin */ > - pkcs15-init -F /* finalize (activate) card */ > > The first command actually asks for the User PIN but does not create it. It > would be nice if it would create it. > I have no experience with other cards, so don't know how if the User PIN is > created using the first command or not. > > It's not a big issue, but still, it's one extra step you need to know when > initializing cards. You can join all these commands in one. That's what I'm using to re-initialize MyEID card: # pkcs15-init -E # pkcs15-init -C --label "IDX-SCM" -P --auth-id 53434D --so-pin "12345678" --so-puk "123456" --pin "" --puk "" -F If you look into the source of pkcs15-init tool, you will see the execution order of the actions http://www.opensc-project.org/opensc/browser/trunk/src/tools/pkcs15-init.c#L263 'finalize' is called at the end of the all 'creative' actions. > Kind regards, > Toni King wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
On 14.01.2011 16:51, Andre Zepezauer wrote: > On Fri, 2011-01-14 at 16:00 +0100, Viktor TARASOV wrote: >> On 14.01.2011 15:17, Andre Zepezauer wrote: >>> On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote: On 14.01.2011 13:37, Andre Zepezauer wrote: > On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote: >> Hello Andre, >> >> On 14.01.2011 04:24, Andre Zepezauer wrote: >>> please have a look at PKCS#15 "6.8.2 Pin objects" for the definition of >>> local and global PIN objects. There is no mention of storage location. >> There is mention of 'path'. >> The difference between 'global' and 'local' is that the first one can be >> verified from any location on the card, >> the second one is 'visible' only from somewhere under the DF (or >> application) where it's defined. >> >> So, we need (or, if you like, it's useful) to have 'path' defined for >> the local PINs, to be able to select it's path before verification. My previous assumptions comes from this citation. It seems that I am terribly missing something. Can you give more details? >>From PKCS#15 6.8.2 Pin objects: > "PinAttributes.path: Path to the DF in which the PIN resides. The > path shall be selected > by a host application before doing a PIN operation, in order to > enable a suitable > authentication context for the PIN operation. That's 'local' PIN. > If not present, a card-holder verification > must always be possible to perform without a prior `SELECT' > operation." That's the global one. So we desperately need the 'path' for the local PINs. So that 'host application' can select the path 'before doing a PIN operation'. You probably know another way to do verification from the random location on the card ? >>> Take Java Card with PKI applet as an example. Once the applet is >>> selected, it is possible to perform the VERIFY command from every >>> location within that applet. That's 'local' PIN too. Because it's only >>> valid for that applet but not for the whole card. >> >> OK, let us adjust the terminology. >> I am talking about the PKCS#15 card. This card starts from some MF, where >> exist EF.DIR, probably EF.ATR, ..., as well as application DFs. >> The AID of application DFs are present in the EF.DIR records. >> The global PINs are defined at the MF level or above, the local ones are >> defined in application DFs. >> >> In my comprehension to create/use the PKCS#15 objects you don't need to jump >> higher then MF, and thus to reset status of 'global' PINs. >> You have another vision, examples ? >> >> >>> BTW care must be take with re-selecting an applet in Java Cards, because >>> it may invalidate all previously verified PINs. >> The AIDs of the applets of your Java Card, are they present in some EF.DIR ? >> Can its be discovered by the procedure previewed by PKCS#15 ? > You only need to have a default applet that can handle "SELECT 2F00" and > "READ BINARY" to dump EF.DIR. The next command would be a "SELECT BY > NAME", which is handled by the runtime environment and switches form one > applet to another. Now you can proceed with 5031 and 5032. Well, it seems that we are talking about the same thing. We've gone away from the original item. Do you have something against committed proposal to complete the missing 'path' for the local PINs when decoding AODF ? Here the 'local PIN' means the PIN for which the 'verified' status is lost when walking from the application DF, where it's defined, onto the MF (or similar level where the 2F00 is) or into the other application, mentioned in 2F00 (EF.DIR)? -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC 12 with minidriver
Hello: We have developed a mini driver which is used for Windows XP smart card login using OpenSC 0.11.13. We have tried to update it to use OpenSC 0.12, but for some reason sc_context_create() hangs until the card is removed. Does anyone have any idea what would cause this? Thanks, Brian Thomas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
On Fri, 2011-01-14 at 17:31 +0100, Viktor TARASOV wrote: > On 14.01.2011 16:51, Andre Zepezauer wrote: > > On Fri, 2011-01-14 at 16:00 +0100, Viktor TARASOV wrote: > >> On 14.01.2011 15:17, Andre Zepezauer wrote: > >>> On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote: > On 14.01.2011 13:37, Andre Zepezauer wrote: > > On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote: > >> Hello Andre, > >> > >> On 14.01.2011 04:24, Andre Zepezauer wrote: > >>> please have a look at PKCS#15 "6.8.2 Pin objects" for the definition > >>> of > >>> local and global PIN objects. There is no mention of storage location. > >> There is mention of 'path'. > >> The difference between 'global' and 'local' is that the first one can > >> be verified from any location on the card, > >> the second one is 'visible' only from somewhere under the DF (or > >> application) where it's defined. > >> > >> So, we need (or, if you like, it's useful) to have 'path' defined for > >> the local PINs, to be able to select it's path before verification. > My previous assumptions comes from this citation. > It seems that I am terribly missing something. Can you give more details? > > > >>From PKCS#15 6.8.2 Pin objects: > > "PinAttributes.path: Path to the DF in which the PIN resides. The > > path shall be selected > > by a host application before doing a PIN operation, in order to > > enable a suitable > > authentication context for the PIN operation. > That's 'local' PIN. > > > If not present, a card-holder verification > > must always be possible to perform without a prior `SELECT' > > operation." > That's the global one. > > > So we desperately need the 'path' for the local PINs. So that 'host > application' can select the path > 'before doing a PIN operation'. > You probably know another way to do verification from the random > location on the card ? > >>> Take Java Card with PKI applet as an example. Once the applet is > >>> selected, it is possible to perform the VERIFY command from every > >>> location within that applet. That's 'local' PIN too. Because it's only > >>> valid for that applet but not for the whole card. > >> > >> OK, let us adjust the terminology. > >> I am talking about the PKCS#15 card. This card starts from some MF, where > >> exist EF.DIR, probably EF.ATR, ..., as well as application DFs. > >> The AID of application DFs are present in the EF.DIR records. > >> The global PINs are defined at the MF level or above, the local ones are > >> defined in application DFs. > >> > >> In my comprehension to create/use the PKCS#15 objects you don't need to > >> jump higher then MF, and thus to reset status of 'global' PINs. > >> You have another vision, examples ? > >> > >> > >>> BTW care must be take with re-selecting an applet in Java Cards, because > >>> it may invalidate all previously verified PINs. > >> The AIDs of the applets of your Java Card, are they present in some EF.DIR > >> ? > >> Can its be discovered by the procedure previewed by PKCS#15 ? > > You only need to have a default applet that can handle "SELECT 2F00" and > > "READ BINARY" to dump EF.DIR. The next command would be a "SELECT BY > > NAME", which is handled by the runtime environment and switches form one > > applet to another. Now you can proceed with 5031 and 5032. > > > Well, it seems that we are talking about the same thing. > > We've gone away from the original item. > Do you have something against committed proposal to complete the missing > 'path' for the local PINs when decoding AODF ? Yes, the patch you have committed is a fix for cards not following PKCS#15 and ISO 7816-15. Therefore it is placed wrong. Your current proposal effects every card not only the broken ones. "If not present, a card-holder verification must always be possible to perform without a prior `SELECT' operation." Regards Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Building cardmod Mindriver using Build environment
I am trying to build the cardmod Windows Minidriver using the
http://www.opensc-project.org/opensc/wiki/MiniDriver
and
http://www.opensc-project.org/build/
and an svn checkout of the build trunk.
François sent me a prebuilt package last night that I may also try.
But I have some questions about the version of the cngsdk.msi to be used.
Build environment:
Ubuntu Lucid 32 bit
gcc-mingw32 4.4.2-3
mingw32-binutils 2.20-0.1
nsis 2.46-1
Test environment:
Vista 32 bit
Build command:
IMAGEROOT=`pwd`/image-win32 CHOST=i586-mingw32msvc CBUILD=x86_64-pc-linux-gnu
./build
Without cardmod the OpenSC package builds
opensc-i586-mingw32msvc-010-setup.exe
This installs on Vista, and pkcs11-tool appears to work as expected
with my PIV cards.
One minor change was needed to build.vars:
-OPENSC_VERSION="${OPENSC_VERSION:-0.12}"
+OPENSC_VERSION="${OPENSC_VERSION:-0.12.0}"
But to get cardmod to build, required some additional changes
to the build script (and it needs some more) but that is not the
main point of this note.
As instructed to do in the opensc/wiki/MiniDriver pages,
I copied SCardErr.h, WinSCard.h, WinSmCrd.h from Microsoft SDK v5.0
and (renamed to lowercase) and the cardmod.h from the
cnsgk.msi Version 2.0.0 published 4/27/2009
Is this the version of the cngsgk.msi to use? I see there may
be a 1.3.0 version also available?
With the 2.0.0 version I also need to copy the bcrypt.h file,
and the compiler was having errors with the cardmod.h and bcrypt.h
So I hacked the cardmod.h as it was doubling defining
CARD_DATA, *PCARD_DATA and
commented out the #include and copied 4 lines from
bcrypt.h to cardmod-mingw-compat.h to define BCRYPT_PKCS1_PADDING_INFO.
Is there some issue with the compiler I am using that requires the
changes to the cardmod.h file?
Does the 1.3.0 cardmod.h have the same issues?
The build/nsis scripts did not include cardmod.dll
or the registry files which I have not looked at yet.
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 12 with minidriver
On 1/14/2011 10:39 AM, Brian Thomas wrote: > *Hello:* > > We have developed a mini driver which is used for Windows XP smart card login > using OpenSC 0.11.13. Is this available? Have you looked a the cardmod code in OpenSC? > > We have tried to update it to use OpenSC 0.12, but for some reason > sc_context_create() hangs until the card is removed. > Do you have OpenSC debug output? > Does anyone have any idea what would cause this? Sounds like some issues I had with using the coolkey CSP See: http://www.opensc-project.org/pipermail/opensc-devel/2009-February/011905.html It could also have to do with bug #309 reported yesterday! dealing withthe setting of lock_login parameter in opensc.conf > > Thanks, > > Brian Thomas > > > > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
On 14.01.2011 17:53, Andre Zepezauer wrote: > On Fri, 2011-01-14 at 17:31 +0100, Viktor TARASOV wrote: >> On 14.01.2011 16:51, Andre Zepezauer wrote: >>> On Fri, 2011-01-14 at 16:00 +0100, Viktor TARASOV wrote: On 14.01.2011 15:17, Andre Zepezauer wrote: > On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote: >> On 14.01.2011 13:37, Andre Zepezauer wrote: >>> On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote: Hello Andre, On 14.01.2011 04:24, Andre Zepezauer wrote: > please have a look at PKCS#15 "6.8.2 Pin objects" for the definition > of > local and global PIN objects. There is no mention of storage location. There is mention of 'path'. The difference between 'global' and 'local' is that the first one can be verified from any location on the card, the second one is 'visible' only from somewhere under the DF (or application) where it's defined. So, we need (or, if you like, it's useful) to have 'path' defined for the local PINs, to be able to select it's path before verification. >> My previous assumptions comes from this citation. >> It seems that I am terribly missing something. Can you give more details? >> >> From PKCS#15 6.8.2 Pin objects: >>> "PinAttributes.path: Path to the DF in which the PIN resides. The >>> path shall be selected >>> by a host application before doing a PIN operation, in order to >>> enable a suitable >>> authentication context for the PIN operation. >> That's 'local' PIN. >> >>> If not present, a card-holder verification >>> must always be possible to perform without a prior `SELECT' >>> operation." >> That's the global one. >> >> >> So we desperately need the 'path' for the local PINs. So that 'host >> application' can select the path >> 'before doing a PIN operation'. >> You probably know another way to do verification from the random >> location on the card ? > Take Java Card with PKI applet as an example. Once the applet is > selected, it is possible to perform the VERIFY command from every > location within that applet. That's 'local' PIN too. Because it's only > valid for that applet but not for the whole card. OK, let us adjust the terminology. I am talking about the PKCS#15 card. This card starts from some MF, where exist EF.DIR, probably EF.ATR, ..., as well as application DFs. The AID of application DFs are present in the EF.DIR records. The global PINs are defined at the MF level or above, the local ones are defined in application DFs. In my comprehension to create/use the PKCS#15 objects you don't need to jump higher then MF, and thus to reset status of 'global' PINs. You have another vision, examples ? > BTW care must be take with re-selecting an applet in Java Cards, because > it may invalidate all previously verified PINs. The AIDs of the applets of your Java Card, are they present in some EF.DIR ? Can its be discovered by the procedure previewed by PKCS#15 ? >>> You only need to have a default applet that can handle "SELECT 2F00" and >>> "READ BINARY" to dump EF.DIR. The next command would be a "SELECT BY >>> NAME", which is handled by the runtime environment and switches form one >>> applet to another. Now you can proceed with 5031 and 5032. >> >> Well, it seems that we are talking about the same thing. >> >> We've gone away from the original item. >> Do you have something against committed proposal to complete the missing >> 'path' for the local PINs when decoding AODF ? > Yes, the patch you have committed is a fix for cards not following > PKCS#15 and ISO 7816-15. Therefore it is placed wrong. Your current > proposal effects every card not only the broken ones. Explain me please how it effects the other cards. The other 'normal' cards - for the local PINs they have 'local' set in their pinFlags and have the 'path' in pinAttributes; - for the global PIN they have no 'local' in pinFlags and have no path in pinAttributes. There are 'anormal' cards that for the local PINs have flag 'local' in pinFlags, but have no 'path' in pinAttributes. My proposal concerns these ones. Please, give me a detailed description of the PinAttributes that can be effected by this proposal. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
On Fri, 2011-01-14 at 18:31 +0100, Viktor TARASOV wrote: > On 14.01.2011 17:53, Andre Zepezauer wrote: > > On Fri, 2011-01-14 at 17:31 +0100, Viktor TARASOV wrote: > >> On 14.01.2011 16:51, Andre Zepezauer wrote: > >>> On Fri, 2011-01-14 at 16:00 +0100, Viktor TARASOV wrote: > On 14.01.2011 15:17, Andre Zepezauer wrote: > > On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote: > >> On 14.01.2011 13:37, Andre Zepezauer wrote: > >>> On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote: > Hello Andre, > > On 14.01.2011 04:24, Andre Zepezauer wrote: > > please have a look at PKCS#15 "6.8.2 Pin objects" for the > > definition of > > local and global PIN objects. There is no mention of storage > > location. > There is mention of 'path'. > The difference between 'global' and 'local' is that the first one > can be verified from any location on the card, > the second one is 'visible' only from somewhere under the DF (or > application) where it's defined. > > So, we need (or, if you like, it's useful) to have 'path' defined > for the local PINs, to be able to select it's path before > verification. > >> My previous assumptions comes from this citation. > >> It seems that I am terribly missing something. Can you give more > >> details? > >> > >> > From PKCS#15 6.8.2 Pin objects: > >>> "PinAttributes.path: Path to the DF in which the PIN resides. > >>> The path shall be selected > >>> by a host application before doing a PIN operation, in order to > >>> enable a suitable > >>> authentication context for the PIN operation. > >> That's 'local' PIN. > >> > >>> If not present, a card-holder verification > >>> must always be possible to perform without a prior `SELECT' > >>> operation." > >> That's the global one. > >> > >> > >> So we desperately need the 'path' for the local PINs. So that 'host > >> application' can select the path > >> 'before doing a PIN operation'. > >> You probably know another way to do verification from the random > >> location on the card ? > > Take Java Card with PKI applet as an example. Once the applet is > > selected, it is possible to perform the VERIFY command from every > > location within that applet. That's 'local' PIN too. Because it's only > > valid for that applet but not for the whole card. > OK, let us adjust the terminology. > I am talking about the PKCS#15 card. This card starts from some MF, > where exist EF.DIR, probably EF.ATR, ..., as well as application DFs. > The AID of application DFs are present in the EF.DIR records. > The global PINs are defined at the MF level or above, the local ones are > defined in application DFs. > > In my comprehension to create/use the PKCS#15 objects you don't need to > jump higher then MF, and thus to reset status of 'global' PINs. > You have another vision, examples ? > > > > BTW care must be take with re-selecting an applet in Java Cards, because > > it may invalidate all previously verified PINs. > The AIDs of the applets of your Java Card, are they present in some > EF.DIR ? > Can its be discovered by the procedure previewed by PKCS#15 ? > >>> You only need to have a default applet that can handle "SELECT 2F00" and > >>> "READ BINARY" to dump EF.DIR. The next command would be a "SELECT BY > >>> NAME", which is handled by the runtime environment and switches form one > >>> applet to another. Now you can proceed with 5031 and 5032. > >> > >> Well, it seems that we are talking about the same thing. > >> > >> We've gone away from the original item. > >> Do you have something against committed proposal to complete the missing > >> 'path' for the local PINs when decoding AODF ? > > Yes, the patch you have committed is a fix for cards not following > > PKCS#15 and ISO 7816-15. Therefore it is placed wrong. Your current > > proposal effects every card not only the broken ones. > > > Explain me please how it effects the other cards. > > The other 'normal' cards > - for the local PINs they have 'local' set in their pinFlags and have the > 'path' in pinAttributes; > - for the global PIN they have no 'local' in pinFlags and have no path in > pinAttributes. > > > There are 'anormal' cards that for the local PINs have flag 'local' in > pinFlags, but have no 'path' in pinAttributes. > My proposal concerns these ones. > > > Please, give me a detailed description of the PinAttributes that can be > effected by this proposal. Local PIN with no path required. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
On 14.01.2011 18:36, Andre Zepezauer wrote: > On Fri, 2011-01-14 at 18:31 +0100, Viktor TARASOV wrote: >> On 14.01.2011 17:53, Andre Zepezauer wrote: >>> On Fri, 2011-01-14 at 17:31 +0100, Viktor TARASOV wrote: On 14.01.2011 16:51, Andre Zepezauer wrote: > On Fri, 2011-01-14 at 16:00 +0100, Viktor TARASOV wrote: >> On 14.01.2011 15:17, Andre Zepezauer wrote: >>> On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote: On 14.01.2011 13:37, Andre Zepezauer wrote: > On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote: >> Hello Andre, >> >> On 14.01.2011 04:24, Andre Zepezauer wrote: >>> please have a look at PKCS#15 "6.8.2 Pin objects" for the >>> definition of >>> local and global PIN objects. There is no mention of storage >>> location. >> There is mention of 'path'. >> The difference between 'global' and 'local' is that the first one >> can be verified from any location on the card, >> the second one is 'visible' only from somewhere under the DF (or >> application) where it's defined. >> >> So, we need (or, if you like, it's useful) to have 'path' defined >> for the local PINs, to be able to select it's path before >> verification. My previous assumptions comes from this citation. It seems that I am terribly missing something. Can you give more details? >>From PKCS#15 6.8.2 Pin objects: > "PinAttributes.path: Path to the DF in which the PIN resides. > The path shall be selected >by a host application before doing a PIN operation, in order > to enable a suitable >authentication context for the PIN operation. That's 'local' PIN. > If not present, a card-holder verification >must always be possible to perform without a prior `SELECT' > operation." That's the global one. So we desperately need the 'path' for the local PINs. So that 'host application' can select the path 'before doing a PIN operation'. You probably know another way to do verification from the random location on the card ? >>> Take Java Card with PKI applet as an example. Once the applet is >>> selected, it is possible to perform the VERIFY command from every >>> location within that applet. That's 'local' PIN too. Because it's only >>> valid for that applet but not for the whole card. >> OK, let us adjust the terminology. >> I am talking about the PKCS#15 card. This card starts from some MF, >> where exist EF.DIR, probably EF.ATR, ..., as well as application DFs. >> The AID of application DFs are present in the EF.DIR records. >> The global PINs are defined at the MF level or above, the local ones are >> defined in application DFs. >> >> In my comprehension to create/use the PKCS#15 objects you don't need to >> jump higher then MF, and thus to reset status of 'global' PINs. >> You have another vision, examples ? >> >> >>> BTW care must be take with re-selecting an applet in Java Cards, because >>> it may invalidate all previously verified PINs. >> The AIDs of the applets of your Java Card, are they present in some >> EF.DIR ? >> Can its be discovered by the procedure previewed by PKCS#15 ? > You only need to have a default applet that can handle "SELECT 2F00" and > "READ BINARY" to dump EF.DIR. The next command would be a "SELECT BY > NAME", which is handled by the runtime environment and switches form one > applet to another. Now you can proceed with 5031 and 5032. Well, it seems that we are talking about the same thing. We've gone away from the original item. Do you have something against committed proposal to complete the missing 'path' for the local PINs when decoding AODF ? >>> Yes, the patch you have committed is a fix for cards not following >>> PKCS#15 and ISO 7816-15. Therefore it is placed wrong. Your current >>> proposal effects every card not only the broken ones. >> >> Explain me please how it effects the other cards. >> >> The other 'normal' cards >>- for the local PINs they have 'local' set in their pinFlags and have the >> 'path' in pinAttributes; >>- for the global PIN they have no 'local' in pinFlags and have no path in >> pinAttributes. >> >> >> There are 'anormal' cards that for the local PINs have flag 'local' in >> pinFlags, but have no 'path' in pinAttributes. >> My proposal concerns these ones. >> >> >> Please, give me a detailed description of the PinAttributes that can be >> effected by this proposal. > Local PIN with no path required. 1. If no path required, it means that it can be verified from every where in the card -- it's the global PIN. 2. Have you seen
Re: [opensc-devel] Building cardmod Mindriver using Build environment
At build script there is a comment:
# Disable until we solve license issue
# if [ -n "${BUILD_FOR_WINDOWS}" ]; then
# extra_opensc="${extra_opensc} --enable-cardmod"
# fi
I have modified cardmod.h to meet mingw, but was remove at revision
101 due to license issue.
2011/1/14 Douglas E. Engert :
> I am trying to build the cardmod Windows Minidriver using the
> http://www.opensc-project.org/opensc/wiki/MiniDriver
> and
> http://www.opensc-project.org/build/
> and an svn checkout of the build trunk.
>
> François sent me a prebuilt package last night that I may also try.
>
> But I have some questions about the version of the cngsdk.msi to be used.
>
> Build environment:
> Ubuntu Lucid 32 bit
> gcc-mingw32 4.4.2-3
> mingw32-binutils 2.20-0.1
> nsis 2.46-1
>
> Test environment:
> Vista 32 bit
>
> Build command:
> IMAGEROOT=`pwd`/image-win32 CHOST=i586-mingw32msvc CBUILD=x86_64-pc-linux-gnu
> ./build
>
> Without cardmod the OpenSC package builds
> opensc-i586-mingw32msvc-010-setup.exe
> This installs on Vista, and pkcs11-tool appears to work as expected
> with my PIV cards.
> One minor change was needed to build.vars:
> -OPENSC_VERSION="${OPENSC_VERSION:-0.12}"
> +OPENSC_VERSION="${OPENSC_VERSION:-0.12.0}"
>
> But to get cardmod to build, required some additional changes
> to the build script (and it needs some more) but that is not the
> main point of this note.
>
> As instructed to do in the opensc/wiki/MiniDriver pages,
> I copied SCardErr.h, WinSCard.h, WinSmCrd.h from Microsoft SDK v5.0
> and (renamed to lowercase) and the cardmod.h from the
> cnsgk.msi Version 2.0.0 published 4/27/2009
>
> Is this the version of the cngsgk.msi to use? I see there may
> be a 1.3.0 version also available?
>
> With the 2.0.0 version I also need to copy the bcrypt.h file,
> and the compiler was having errors with the cardmod.h and bcrypt.h
> So I hacked the cardmod.h as it was doubling defining
> CARD_DATA, *PCARD_DATA and
> commented out the #include and copied 4 lines from
> bcrypt.h to cardmod-mingw-compat.h to define BCRYPT_PKCS1_PADDING_INFO.
>
> Is there some issue with the compiler I am using that requires the
> changes to the cardmod.h file?
> Does the 1.3.0 cardmod.h have the same issues?
>
> The build/nsis scripts did not include cardmod.dll
> or the registry files which I have not looked at yet.
>
> --
>
> Douglas E. Engert
> Argonne National Laboratory
> 9700 South Cass Avenue
> Argonne, Illinois 60439
> (630) 252-5444
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Building cardmod Mindriver using Build environment
On 1/14/2011 12:48 PM, Alon Bar-Lev wrote:
> At build script there is a comment:
> # Disable until we solve license issue
> # if [ -n "${BUILD_FOR_WINDOWS}" ]; then
> # extra_opensc="${extra_opensc} --enable-cardmod"
> # fi
>
> I have modified cardmod.h to meet mingw, but was remove at revision
> 101 due to license issue.
I see that, but was trying to test if it could still be built
and work.
If the license issues can not be addressed, then maybe cardmod
could be built as a separate package by the user.
>
>
> 2011/1/14 Douglas E. Engert:
>> I am trying to build the cardmod Windows Minidriver using the
>> http://www.opensc-project.org/opensc/wiki/MiniDriver
>> and
>> http://www.opensc-project.org/build/
>> and an svn checkout of the build trunk.
>>
>> François sent me a prebuilt package last night that I may also try.
>>
>> But I have some questions about the version of the cngsdk.msi to be used.
>>
>> Build environment:
>> Ubuntu Lucid 32 bit
>> gcc-mingw32 4.4.2-3
>> mingw32-binutils 2.20-0.1
>> nsis 2.46-1
>>
>> Test environment:
>> Vista 32 bit
>>
>> Build command:
>> IMAGEROOT=`pwd`/image-win32 CHOST=i586-mingw32msvc
>> CBUILD=x86_64-pc-linux-gnu ./build
>>
>> Without cardmod the OpenSC package builds
>> opensc-i586-mingw32msvc-010-setup.exe
>> This installs on Vista, and pkcs11-tool appears to work as expected
>> with my PIV cards.
>> One minor change was needed to build.vars:
>> -OPENSC_VERSION="${OPENSC_VERSION:-0.12}"
>> +OPENSC_VERSION="${OPENSC_VERSION:-0.12.0}"
>>
>> But to get cardmod to build, required some additional changes
>> to the build script (and it needs some more) but that is not the
>> main point of this note.
>>
>> As instructed to do in the opensc/wiki/MiniDriver pages,
>> I copied SCardErr.h, WinSCard.h, WinSmCrd.h from Microsoft SDK v5.0
>> and (renamed to lowercase) and the cardmod.h from the
>> cnsgk.msi Version 2.0.0 published 4/27/2009
>>
>> Is this the version of the cngsgk.msi to use? I see there may
>> be a 1.3.0 version also available?
>>
>> With the 2.0.0 version I also need to copy the bcrypt.h file,
>> and the compiler was having errors with the cardmod.h and bcrypt.h
>> So I hacked the cardmod.h as it was doubling defining
>> CARD_DATA, *PCARD_DATA and
>> commented out the #include and copied 4 lines from
>> bcrypt.h to cardmod-mingw-compat.h to define BCRYPT_PKCS1_PADDING_INFO.
>>
>> Is there some issue with the compiler I am using that requires the
>> changes to the cardmod.h file?
>> Does the 1.3.0 cardmod.h have the same issues?
>>
>> The build/nsis scripts did not include cardmod.dll
>> or the registry files which I have not looked at yet.
>>
>> --
>>
>> Douglas E. Engert
>> Argonne National Laboratory
>> 9700 South Cass Avenue
>> Argonne, Illinois 60439
>> (630) 252-5444
>> ___
>> opensc-devel mailing list
>> opensc-devel@lists.opensc-project.org
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>
>
>
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5081
On Fri, 2011-01-14 at 18:50 +0100, Viktor TARASOV wrote: > On 14.01.2011 18:36, Andre Zepezauer wrote: > > On Fri, 2011-01-14 at 18:31 +0100, Viktor TARASOV wrote: > >> On 14.01.2011 17:53, Andre Zepezauer wrote: > >>> On Fri, 2011-01-14 at 17:31 +0100, Viktor TARASOV wrote: > On 14.01.2011 16:51, Andre Zepezauer wrote: > > On Fri, 2011-01-14 at 16:00 +0100, Viktor TARASOV wrote: > >> On 14.01.2011 15:17, Andre Zepezauer wrote: > >>> On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote: > On 14.01.2011 13:37, Andre Zepezauer wrote: > > On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote: > >> Hello Andre, > >> > >> On 14.01.2011 04:24, Andre Zepezauer wrote: > >>> please have a look at PKCS#15 "6.8.2 Pin objects" for the > >>> definition of > >>> local and global PIN objects. There is no mention of storage > >>> location. > >> There is mention of 'path'. > >> The difference between 'global' and 'local' is that the first one > >> can be verified from any location on the card, > >> the second one is 'visible' only from somewhere under the DF (or > >> application) where it's defined. > >> > >> So, we need (or, if you like, it's useful) to have 'path' defined > >> for the local PINs, to be able to select it's path before > >> verification. > My previous assumptions comes from this citation. > It seems that I am terribly missing something. Can you give more > details? > > > >>From PKCS#15 6.8.2 Pin objects: > > "PinAttributes.path: Path to the DF in which the PIN resides. > > The path shall be selected > >by a host application before doing a PIN operation, in order > > to enable a suitable > >authentication context for the PIN operation. > That's 'local' PIN. > > > If not present, a card-holder verification > >must always be possible to perform without a prior `SELECT' > > operation." > That's the global one. > > > So we desperately need the 'path' for the local PINs. So that 'host > application' can select the path > 'before doing a PIN operation'. > You probably know another way to do verification from the random > location on the card ? > >>> Take Java Card with PKI applet as an example. Once the applet is > >>> selected, it is possible to perform the VERIFY command from every > >>> location within that applet. That's 'local' PIN too. Because it's only > >>> valid for that applet but not for the whole card. > >> OK, let us adjust the terminology. > >> I am talking about the PKCS#15 card. This card starts from some MF, > >> where exist EF.DIR, probably EF.ATR, ..., as well as application DFs. > >> The AID of application DFs are present in the EF.DIR records. > >> The global PINs are defined at the MF level or above, the local ones > >> are defined in application DFs. > >> > >> In my comprehension to create/use the PKCS#15 objects you don't need > >> to jump higher then MF, and thus to reset status of 'global' PINs. > >> You have another vision, examples ? > >> > >> > >>> BTW care must be take with re-selecting an applet in Java Cards, > >>> because > >>> it may invalidate all previously verified PINs. > >> The AIDs of the applets of your Java Card, are they present in some > >> EF.DIR ? > >> Can its be discovered by the procedure previewed by PKCS#15 ? > > You only need to have a default applet that can handle "SELECT 2F00" and > > "READ BINARY" to dump EF.DIR. The next command would be a "SELECT BY > > NAME", which is handled by the runtime environment and switches form one > > applet to another. Now you can proceed with 5031 and 5032. > Well, it seems that we are talking about the same thing. > > We've gone away from the original item. > Do you have something against committed proposal to complete the missing > 'path' for the local PINs when decoding AODF ? > >>> Yes, the patch you have committed is a fix for cards not following > >>> PKCS#15 and ISO 7816-15. Therefore it is placed wrong. Your current > >>> proposal effects every card not only the broken ones. > >> > >> Explain me please how it effects the other cards. > >> > >> The other 'normal' cards > >>- for the local PINs they have 'local' set in their pinFlags and have > >> the 'path' in pinAttributes; > >>- for the global PIN they have no 'local' in pinFlags and have no path > >> in pinAttributes. > >> > >> > >> There are 'anormal' cards that for the local PINs have flag 'local' in > >> pinFlags, but have no 'path' in pinAttributes. > >> My proposal concerns these ones. > >> > >> > >> Ple
Re: [opensc-devel] Building cardmod Mindriver using Build environment
2011/1/14 Douglas E. Engert : > If the license issues can not be addressed, then maybe cardmod > could be built as a separate package by the user. On perfect world, it would have been possible to write cardmod that uses PKCS#11 interface, to enable any PKCS#11 provider to be used by CryptoAPI. The problem is that Microsoft specification is faulty, so changes within the opensc core is needed. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Canonical mailing list address
On Sat, Jan 08, 2011 at 03:14:54PM +0100, Andreas Jellinghaus wrote: > Am Donnerstag 06 Januar 2011, um 14:57:35 schrieb Peter Stuge: >> I also think the lists. name is important to drop, but having a >> canonical address is much more important. > Implemented. you shouldn't be able to send email to > opensc-d...@opensc-project.org any more. Then please change the Reply-To of the opensc-commit mailing list... Commit messages come with Reply-To: opensc-de...@opensc-project.org, opensc-devel@lists.opensc-project.org Messages sent by humans seem to contain Reply-To: opensc-de...@opensc-project.org which is "even more wrong". -- Lionel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Missing patch for public review
Hello Viktor, even not completed yet it's quite obvious what you want achieve with r5092 [1]. Its purpose is the selection of specific algorithms for the cryptographic operations sign and decipher. Tag 0x80 in the data field of MSE command and specific to each private key. That intention is novel of cause, because it's an enabler for cards with mixed key sets. In example RSA, ECC, GOST (3DES and AES) on a single card without heavy workarounds in the drivers itself. That's possible because selection of algorithms is done in a common place namely pkcs15-sec.c controlled by some PKCS#15 data structures. It should be noted that the right mechanisms are in place since nine years now [2] and that a completely working patch was presented some months ago [3]. That patch was fully PKCS#15 conform and capable of serving all drivers at once. In example the iso7816 driver was instantly passing tag 0x80 to the card without any modifications to the driver itself. So, my solution was presented for public review [3]. Please do the same and provide a similar patch [4]. And keep in mind that it is of general interest because lots of drivers can take advantage of it. Regards Andre [1] http://www.opensc-project.org/opensc/changeset/5092 [2] http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/iso7816.c?rev=177#L566 [3] http://www.opensc-project.org/pipermail/opensc-devel/2010-August/014618.html [4] http://www.opensc-project.org/opensc/wiki/DevelopmentPolicy#Mailinglist ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Canonical mailing list address
Lionel Elie Mamane wrote: > > Implemented. you shouldn't be able to send email to > > opensc-d...@opensc-project.org any more. > > Then please change the Reply-To of the opensc-commit mailing > list... Commit messages come with > > Reply-To: opensc-de...@opensc-project.org, > opensc-devel@lists.opensc-project.org > > Messages sent by humans seem to contain > > Reply-To: opensc-de...@opensc-project.org > > which is "even more wrong". No doubt. The only right thing is to never have lists add reply-to. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Canonical mailing list address
On Sat, Jan 15, 2011 at 12:51:19AM +0100, Peter Stuge wrote: > Lionel Elie Mamane wrote: >>> You shouldn't be able to send email to >>> opensc-d...@opensc-project.org any more. >> Then please change the Reply-To of the opensc-commit mailing >> list... Commit messages come with >> Reply-To: opensc-de...@opensc-project.org, >> opensc-devel@lists.opensc-project.org >> Messages sent by humans seem to contain >> Reply-To: opensc-de...@opensc-project.org >> which is "even more wrong". > No doubt. The only right thing is to never have lists add reply-to. I rather strongly agree, but well, I wasn't going to have one of my first ten emails to the list be opening that debate, being a passer-by in the community and all that. -- Lionel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
