Re: [opensc-devel] openct and ccid-1.10

[Peter Stuge]

Chaskiel M Grundman wrote:
> the ccid spec supports using an interrupt pipe message to notify
> the host of card insert/remove events, but devices are not required
> to implement that part. Even for devices that do, I don't
> understand enough of how usb and libusb handle interrupt endpoints
> to know if the messages are buffered indefinitely, or only when
> there's an outstanding urb.

USB is completely driven by the host, so unless an app keeps a
transfer pending for the interrupt pipe, nothing will be transfered.
The USB function (reader) detects that it couldn't send and takes
some action, typically either throwing the message away, or queueing
it for a retry later.


//Peter
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] memory leak in OpenCT/src/ifd/ifd-cyberjack.c

[Alon Bar-Lev]

Committed with some modification (single free).
Please review.

http://www.opensc-project.org/openct/changeset/1085

On 12/19/08, Ludovic Rousseau  wrote:
> Hello,
>
>  The tool cppcheck [1] detected a memory leak in src/ifd/ifd-cyberjack.c
>
>  Checking ./src/ifd/ifd-cyberjack.c...
>  [./src/ifd/ifd-cyberjack.c:390]: Memory leak: state
> Defines=''
>
>  The state variable is allocated but not freed in case of error.
>  I propose the attached patch. I am not sure it is correct. Please review.
>
>  Bye
>
>  [1] http://packages.debian.org/sid/cppcheck
>
>
>  --
>   Dr. Ludovic Rousseau
>
> ___
>  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] memory leak in OpenCT/src/ifd/ifd-cyberjack.c

[Ludovic Rousseau]

On Fri, Dec 19, 2008 at 9:46 PM, Alon Bar-Lev  wrote:
> Committed with some modification (single free).
> Please review.

I also prefer using one free() and some gotos.

Bye

-- 
 Dr. Ludovic Rousseau
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] openct and ccid-1.10

[Chaskiel M Grundman]

> >
> > I don't know. This is one of the things I don't know about usb apis.
> >  Looking at the linux kernel code suggests that it might work, but it is
> >  likely to be system dependent.
> >
>
> I don't mind to enable this feature on Linux and use current approach
> for other. It is just that now with Linux power workout OpenCT is one
> of the few last daemon that consume power at idle time.

Now that I've read src/ifd/sys-*.c, I see that ifd_usb_capture is already
implemented using poll on linux, bsd and non-sunray solaris. So it should
be possible to do this on those platforms.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] openct and ccid-1.10

[Alon Bar-Lev]

On 12/19/08, Chaskiel M Grundman  wrote:
> > I thought of polling the client socket and usb fds, so I exit the poll
>  > if I got a command or something was sent from the reader.
>  > Wouldn't this work?
>
>
> I don't know. This is one of the things I don't know about usb apis.
>  Looking at the linux kernel code suggests that it might work, but it is
>  likely to be system dependent.
>

I don't mind to enable this feature on Linux and use current approach
for other. It is just that now with Linux power workout OpenCT is one
of the few last daemon that consume power at idle time.

Thank you for your help!

Alon.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] openct and ccid-1.10

[Chaskiel M Grundman]

> I thought of polling the client socket and usb fds, so I exit the poll
> if I got a command or something was sent from the reader.
> Wouldn't this work?

I don't know. This is one of the things I don't know about usb apis.
Looking at the linux kernel code suggests that it might work, but it is
likely to be system dependent.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] openct and ccid-1.10

[Alon Bar-Lev]

On 12/19/08, Chaskiel M Grundman  wrote:
> > I thought to make the blocking poll() at ct_mainloop()
>
> The only reason ct_mainloop calls ifdhandler_poll_presence is so that the
>  status file is updated. If we don't care about the status file anymore,
>  then ct_mainloop doesn't need to know if there's a card inserted or not.

But we need somewho to provide notification in the API in stead, right?

>  > call a new
>  > method that may return event file descriptor from the reader driver
>
> The only way I'd be able to provide a file descriptor with the behavior I
>  think you want (becomes readable to poll() when the card status changes)
>  is to have a thread polling the device as it does now (but possibly with
>  much longer usb timeouts). How is pushing this work into each ifd helpful?

Oh... I want to avoid theads if possible.
I thought of polling the client socket and usb fds, so I exit the poll
if I got a command or something was sent from the reader.
Wouldn't this work?

>  In any case, the ccid feature doesn't actually help you achieve this goal,
>  so I'll stop participating in this discussion unless you'd prefer me to
>  keep paying attention. Once you have an architecture, I will probably help
>  adapt the ccid ifd to work with it.

Right. I should have modified the subject... I just recalled that
Antii suggested to help modifying the infrastructure to use sockets.

Thanks!
Alon.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] openct and ccid-1.10

[Chaskiel M Grundman]

> I thought to make the blocking poll() at ct_mainloop()
The only reason ct_mainloop calls ifdhandler_poll_presence is so that the
status file is updated. If we don't care about the status file anymore,
then ct_mainloop doesn't need to know if there's a card inserted or not.

> call a new
> method that may return event file descriptor from the reader driver
The only way I'd be able to provide a file descriptor with the behavior I
think you want (becomes readable to poll() when the card status changes)
is to have a thread polling the device as it does now (but possibly with
much longer usb timeouts). How is pushing this work into each ifd helpful?

In any case, the ccid feature doesn't actually help you achieve this goal,
so I'll stop participating in this discussion unless you'd prefer me to
keep paying attention. Once you have an architecture, I will probably help
adapt the ccid ifd to work with it.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] openct and ccid-1.10

[Alon Bar-Lev]

On 12/19/08, Chaskiel M Grundman  wrote:
> > I would like also to make the openct stop polling for readers if
>  > possible (CCID supports this).
>
>
> I assume you mean "stop polling for CARDS".

Via the reader... :)

>  the ccid spec supports using an interrupt pipe message to notify the host
>  of card insert/remove events, but devices are not required to implement
>  that part. Even for devices that do, I don't understand enough of how usb
>  and libusb handle interrupt endpoints to know if the messages are buffered
>  indefinitely, or only when there's an outstanding urb. In any case, there
>  is no asynchronous notification of the insert/remove events, so openct
>  would still have to poll the ifd to get the data. If you just don't want
>  to provide the card insert status to clients, then ccid's feature is
>  irrelevant
>

I've looked at the code, and I succeeded in understanding how to
detect the card in/card out event using the poll loop in
ccid_card_status().

I thought to make the blocking poll() at ct_mainloop() call a new
method that may return event file descriptor from the reader driver
and wait on these. If a command from a client received then a command
is sent and get_status is initiated again.

Then we need to modify the OpenCT client API to support
notification... And make OpenSC PKCS#11 stop poll... But we need to
start from the lowlevel implementation.

I believe It would be much easier to do this if the interface of
OpenCT would relay on sockets.

Am I missing something?

Alon.

The problem is that the infrastructure of OpenCT does not allow
waiting for event from the sockets.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] openct and ccid-1.10

[Chaskiel M Grundman]

> I would like also to make the openct stop polling for readers if
> possible (CCID supports this).

I assume you mean "stop polling for CARDS".

the ccid spec supports using an interrupt pipe message to notify the host
of card insert/remove events, but devices are not required to implement
that part. Even for devices that do, I don't understand enough of how usb
and libusb handle interrupt endpoints to know if the messages are buffered
indefinitely, or only when there's an outstanding urb. In any case, there
is no asynchronous notification of the insert/remove events, so openct
would still have to poll the ifd to get the data. If you just don't want
to provide the card insert status to clients, then ccid's feature is
irrelevant
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] openct and ccid-1.10

[Alon Bar-Lev]

On Thursday 08 May 2008, Alon Bar-Lev wrote:
> On 5/8/08, Antti Andreimann  wrote:
> > I have a patch somewhere in my bitbucket that gets rid
> >  of /var/run/openct/status and implements status functions by connecting
> >  to existing AF_UNIX sockets instead. It's a bit slower, but It would
> >  enable us to eventually write an application that can tunnel smartcard
> >  readers for thin-client use since all operations are on sockets and no
> >  mmap-ed file anymore. It would be immune to status file magically
> >  disappearing which is pretty hard to detect from C.
> >  Maybe it's a good time to consider this? I'm willing to blow the dust
> >  off from this patch if You think it's a good idea.

On Thursday 08 May 2008, Antti Andreimann wrote:
> Ühel kenal päeval, N, 2008-05-08 kell 21:24, kirjutas Alon Bar-Lev:
> 
> > It sounds great idea.
> > But I know nothing about current internals.
> > Sockets should be simpler to handle, right?
> 
> Ok, I'll see if I can find the patch and posti it for comments in a few
> days.
> 


Hello Antii,

Any news?
I would like also to make the openct stop polling for readers if possible (CCID 
supports this).

Alon.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] new releases before xmas?

[Douglas E. Engert]

Andreas Jellinghaus wrote:
> Hi,
> 
> maybe I can find some time to at least put out some new releases
> of everything (that has changes). is this a good idea?

Not sure if it a good idea to produce a release before Christmas.
What you want it to produce a pre release and get developers
to test it. Christmas is not a good time for me, as I am on vacation.
till January 5.

P.S.

I got the coolkey CSP to run on XP calling opensc-pkcs11.dll
for login to AD. It took some mods to coolkey which I wiull clean
up in January.


> 
> are there any patches waiting for a merge?
> and show-stopper bugs we should fix before (or patched to undo
> if they don't work ok right now)? 
> 
> alon, can you check if trunk is building ok with mingw? thanks.
> 
> Regards, Andreas
> ___
> 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] new releases before xmas?

[Aktiv Co. Aleksey Samsonov]

 > not sure if they follow this mailing list.

pkcs11-tool for Rutoken S is not yet supported (have problems).
pkcs15-tool is supported (almost all options).


Andreas Jellinghaus:
> Hi Pavel,
> 
> can you check with the rutoken authors?
> not sure if they follow this mailing list.
> I neither have a token nor documentation (nor time right now),
> so I can't be of any help.
> 
> rutoken is a new driver, so if it is not working 100% so far,
> that is not a show stopper for the next release. but of course
> it would be much better, if it worked.
> 
>  *  card-rutoken.c: Support for Rutoken cards
>  *
>  * Copyright (C) 2007  Pavel Mironchik 
>  * Copyright (C) 2007  Eugene Hermann 
> 
> I hope they can help!
> 
> Regards, Andreas
> ___
> 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] new releases before xmas?

[Andreas Jellinghaus]

Hi Pavel,

can you check with the rutoken authors?
not sure if they follow this mailing list.
I neither have a token nor documentation (nor time right now),
so I can't be of any help.

rutoken is a new driver, so if it is not working 100% so far,
that is not a show stopper for the next release. but of course
it would be much better, if it worked.

 *  card-rutoken.c: Support for Rutoken cards
 *
 * Copyright (C) 2007  Pavel Mironchik 
 * Copyright (C) 2007  Eugene Hermann 

I hope they can help!

Regards, Andreas
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] new releases before xmas?

[Pavel Volkovitskiy]

Andreas Jellinghaus wrote:
> Hi,
>
> maybe I can find some time to at least put out some new releases
> of everything (that has changes). is this a good idea?
>
> are there any patches waiting for a merge?
> and show-stopper bugs we should fix before (or patched to undo
> if they don't work ok right now)? 
>   
I tried to compile latest bits from svn and check how it works with rutoken

i get
"error: PKCS11 function C_CreateObject failed: rv = 
CKR_ATTRIBUTE_VALUE_INVALID (0x13)"
then i tried to write back signed cert

steps:

1) format card
$ pkcs15-init -E -p rutoken
Using reader with a card: ruToken driver

2) generate key pair
$ pkcs11-tool --keypairgen --key-type rsa:2048 --login --label "user" --id 1
Please enter User 
PIN:
Key pair 
generated:  
  

Private Key Object; 
RSA   
  label:  
user 

  ID: 
01   

  Usage:  decrypt, sign, 
unwrap   
Public Key Object; RSA 2048 
bits  
  label:  
user 

  ID: 
01   

  Usage:  encrypt, verify, wrap

3) generate csr and sign it
$ openssl req -engine pkcs11 -keyform engine -key 1 -new -text -out 
newcert.csr -subj "/CN=User"
engine "pkcs11" 
set.
   

PKCS#11 token PIN:

$ openssl x509 -req -days 365 -in newcert.csr -CA ca.crt -CAkey ca.key 
-set_serial 01 -out newcert.crt
Signature 
ok  
   

subject=/CN=User
 

Getting CA Private 
Key 
  


$ openssl x509 -in newcert.crt -outform der -out newcert.der

4) try to write it back
$ pkcs11-tool -w newcert.der --type cert --login --label "user" --id 1
Please enter User 
PIN:  
error: PKCS11 function C_CreateObject failed: rv = 
CKR_ATTRIBUTE_VALUE_INVALID (0x13)

Aborting.

last step with debug output:
[opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): 
CKA_TOKEN = TRUE
[opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): 
CKA_VALUE = 308203DA308201C2020101300D06092A864886F70D01010505003057310B3009
[opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): 
CKA_CLASS = CKO_CERTIFICATE
[opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): 
CKA_CERTIFICATE_TYPE = CKC_X_509
[opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): 
CKA_LABEL = user
[opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): 
CKA_ID = 01
[opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): 
CKA_SUBJECT = 300F310D300B0603550403130455736572
[opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): 
CKA_ISSUER = 
3057310B3009060355040613025255311330110603550408130A536F6D652D53
[opensc-pkcs11] pkcs11-object.c:43:C_CreateObject: C_CreateObject(): 
CKA_SERIAL_NUMBER = 020101
[opensc-pkcs11] card.c:285:sc_lock: called
[opensc-pkcs11] reader-openct.c:420:openct_reader_lock: called
[opensc-pkcs11] card.c:668:sc_card_ctl: called
[opensc-pkcs11] card-rutoken.c:1389:rutoken_card_ctl: called
[opensc-pkcs11] card-rutoken.c:1435:rutoken_card_ctl: 
SC_CARDCTL_LIFECYCLE_SET not supported
[opensc-pkcs11] card-rutoken.c:1436:rutoken_card_ctl: returning 
SC_ERROR_NOT_SUPPORTED
[opensc-pkcs11] card.c:675:sc_card_ctl: card_ctl(4) not supported
[opensc-pkcs11] card.c:532:sc_select_file: called; type=2, path=3f0050154946
[opensc-pkcs11] card-rutoken.c:383:rutoken_select_file: called
[opensc-pkcs11] card-rutoken.c:391:rutoken_select_file:
path =  3f 00 50 15 49 46
type = 2
[opensc-pkcs11] apdu.c:516:sc_transmit_apdu: called
[opensc-pkcs11] card.c:285:sc_lock: called
[opensc-pkcs11] card.c:312:sc_unlock: called
[opensc-pkcs11] card-rutoken.c:220:rutoken_check_sw: File (DO) not found
[opensc-pkcs11] card-rutoken.c:221:rutoken_check_sw: sw1 = 6a, sw2 = 82
[opensc-pkcs11] card-rutoken.c:469:rutoken_select_file: returning with: 
-1201
[opensc-pkcs11] card.c:554:sc_select_file: returning with: -1201
[opensc-pkcs11] profile.c:317:sc_profile_load: Trying profile file 
/usr/share/opensc/pkcs15.profile
[opensc-pkcs11] profile.c:325:sc_profile_load: profile 
/usr/share/opensc/pkcs15.profile loaded ok
[

[opensc-devel] memory leak in OpenCT/src/ifd/ifd-cyberjack.c

[Ludovic Rousseau]

Hello,

The tool cppcheck [1] detected a memory leak in src/ifd/ifd-cyberjack.c

Checking ./src/ifd/ifd-cyberjack.c...
[./src/ifd/ifd-cyberjack.c:390]: Memory leak: state
Defines=''

The state variable is allocated but not freed in case of error.
I propose the attached patch. I am not sure it is correct. Please review.

Bye

[1] http://packages.debian.org/sid/cppcheck

-- 
 Dr. Ludovic Rousseau
Index: src/ifd/ifd-cyberjack.c
===
--- src/ifd/ifd-cyberjack.c (révision 1081)
+++ src/ifd/ifd-cyberjack.c (copie de travail)
@@ -387,29 +387,34 @@ static int cyberjack_activate(ifd_reader
ifd_device_send( dev, (unsigned char*)"\x00\x04\x00" 
"\xe2\xc0\x00\x22", 7 ) != 7 )
{
cyberjack_ct_error(80, "cyberjack: failed to activate 1");
+   free(state);
return -1;
}

ifd_msleep( 100 );
if( (ret=cyberjack_recv_t1( state, 0xe2, read_buffer ))!=4 || memcmp( 
read_buffer, "\x2e\xe0\x00\xce", 4 )!=0 )  {
cyberjack_ct_error(80, "cyberjack: failed to activate 2: no 
cookie");
+   free(state);
return -1;
}
 
// send 20 11 00 00 
if( cyberjack_send_t1( state, "\x12\x00\x04" "\x20\x11\x00\x00", 7 ) != 
7 )  {
cyberjack_ct_error(80, "cyberjack: failed to activate 5");  

+   free(state);
return -1;
}
ret = cyberjack_recv_t1( state, 0x12, read_buffer );
if( ret < 0 )  {
cyberjack_ct_error(80, "cyberjack: failed to activate 5.1");

+   free(state);
return -1;
}
cyberjack_ifd_debug(1, 80+ret*3, "cyberjack: t1 response is : %s", 
ct_hexdump( read_buffer, ret ));
if( ret < 6 )  {
cyberjack_ifd_debug(1, 80, "cyberjack: response is short 6.1");
+   free(state);
return -1;
}
if( ret != 6 || read_buffer[3]!=0x90 || read_buffer[4]!=0 )
@@ -418,6 +423,7 @@ static int cyberjack_activate(ifd_reader
ct_hexdump( read_buffer, 6 ));
// could neever recover from this
cyberjack_ct_error(80, "cyberjack: failed to activate: failed 
to reset the reader");
+   free(state);
return -1;
}
 
@@ -431,6 +437,7 @@ static int cyberjack_activate(ifd_reader
ret = cyberjack_recv_t1( state, 0x2e, read_buffer );
if( ret < 3 || memcmp(read_buffer, "\x2e\xe0\x00", 3 )!=0 )  {
cyberjack_ct_error(80, "cyberjack: failed to activate 7.1");

+   free(state);
return -1;
}

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] code to format cardos

[Andreas Jellinghaus]

Hi,

here is a new idea:
what about adding a parameter where users can pass the
APDU to format a cardos card, if they know it?

we could even add some checksum for the commands we know,
to prevent users trying the wrong commands. yes, the whole
situation is silly, but without help from siemens it won't
improve.

what do you think?

Regards, Andreas
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] [opensc-commits] [OpenCT] #31: T1 protocol abort handling

[Alon Bar-Lev]

On 12/19/08, Ludovic Rousseau  wrote:
> I will try to merge my T=1 code in OpenCT. But not before a few weeks.
>  I remembered some objections when I proposed to do this a few years
>  ago. Maybe the situation has changed.

Great!
Thanks.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] [opensc-commits] [OpenCT] #31: T1 protocol abort handling

[Ludovic Rousseau]

On Thu, Dec 18, 2008 at 7:58 PM, OpenCT  wrote:
> #31: T1 protocol abort handling
> ---+
> Reporter:  alonbl  |   Owner:  Chaskiel Grundman
>Type:  defect  |  Status:  new
> Priority:  normal  |   Component:  ccid
>  Version:  trunk   |Severity:  normal
> Keywords:  |
> ---+
>
> Comment(by alonbl):
>
>  This is a great idea!
>
>  I tried to... But I reached to a point where there is too much
>  dependency... I believe you be more helpful than I am... :)
>
>  You have changed the context all function receives... Maybe you know how
>  to fix it up.
>
>  Is there a way we can have single interface for t1 abstraction so both
>  projects may benefit your work?
>
> --
> Ticket URL: 
> OpenCT 

I will try to merge my T=1 code in OpenCT. But not before a few weeks.
I remembered some objections when I proposed to do this a few years
ago. Maybe the situation has changed.

Bye

-- 
 Dr. Ludovic Rousseau
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel