Re: [opensc-devel] HAL proposal for smart cards (clarification)
Am Mittwoch 28 Januar 2009 19:30:52 schrieb Stanislav Brabec: How to name the main category smart_card_reader or crypto_token? I think it is easer to explain, that a usb crypto token is a device consisting of a reduced smart card reader and a fixed build in smart card. I guess this is quite close to the truth. the other way would be more like the pkcs#11 document (they talk about tokens all the time, but cover software implementations too), and harder to explain I think. 2) Use smart_card_reader and invent a different name for the one with slot for cards. maybe something like slots:1 , slots:2, slots:fixed? or use the card size format here? (e.g. slots:id0,wireless ?) not 100% sure info.pcsc.* info.openct.* would never conflict. good idea. my concern was how to handle that info in openct code, but we will find a way for that sometime later. Two slots or one slots with two sizes? two real, independend slots. can be used with two different cards at the same time. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
Am Mittwoch 28 Januar 2009 19:02:39 schrieb Stanislav Brabec: In case of Smart Cards, it might be GID writability for scard group, allowing to run smart card daemon without root privileges. if pcscd or openct should run as non-root, then there should be: * one way how openct/pcscd can access the serial and usb devices (please document what users with serial smart card readers need to do) * one way how users allowed to access the readers can connect to openct/pcscd I think these two things should be kept seperated, and scard is already used for the later case. on the other hand I was made aware off, that tools like the cyberjack debug tools, or applications using the ct-api interface such as moneyplex still need to access the usb devices directly. I think accessing usb smart card readers directly is a very old and outdated design (forgive me for using the word stupid earlier), but we can't help if major applications still work that way and know no alternative. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
Am Mittwoch 28 Januar 2009 19:05:08 schrieb Alon Bar-Lev: Running software as root is the worst solution. Especially security centric software. not a good solution, but not the worst. remember old linux/unix systems with a bin user and group, and all binaries owned by them? that was worse. creating a stair where people can step by step get more privileges because nobody understands all the dependencies is worse than having the simple root or not approach, where root has most rights and there are few things you can do with out root, so you need to attack it directly. much easier to understand, secure and keep secure from my point of view. btw: many distributions have a group scard that regulates access to smart card reader middleware (pcscd and openct). (well, ok, debian and ubuntu have that group, not 100% sure about other distributions). I don't care how you call this group as long as you run daemons in least-privilege mode. it's not the daemon group, but the group users need to be in, so they are allowed to talk to the daemon. it would be very bad security practise, if the same group name is used for that in one distribution, and for the daemon access to the usb devices in some other distribution. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] HAL proposal for smart cards (clarification)
On 1/29/09, Andreas Jellinghaus a...@dungeon.inka.de wrote: Am Mittwoch 28 Januar 2009 19:02:39 schrieb Stanislav Brabec: In case of Smart Cards, it might be GID writability for scard group, allowing to run smart card daemon without root privileges. if pcscd or openct should run as non-root, then there should be: * one way how openct/pcscd can access the serial and usb devices (please document what users with serial smart card readers need to do) * one way how users allowed to access the readers can connect to openct/pcscd I added support to openct for multiple groups... So it can be in usb, serial and smartcard at the same time... The sysadmin should know which groups needed in order to access the resources. pcscd runs as root so no issues there. I try to work with Ludovic in order to create a new reader framework supported by all of us with the benefit of both openct and pcscd. I prepare to invest time in separating between the PC/SC API and the reader access. So that we have one process per reader which is started by the hotplug service, and PC/SC as a library only implementation. It will remove the PC/SC daemon, the dependency between reader drivers and Windows types, the need for threading of PC/SC and much more legacy. Something like: libpcsc-libscreaderRPClibscreaderd-reader implementation This will enable to use the reader in multiple APIs, such as CT or proprietary using the libscreader. I closed all the details and I ready to go and implement the libscreader. But I don't want to reapeat the openct mistake and end up with yet another competing project. So I need Ludovic on board. I hope he will approve. If we succeed the complexity of adding new reader will be somewhat similar to the complexity of adding a new reader to openct. While the formal application API may be PC/SC. And the reader framework will be much more POSIX and hotplug friendly than current IFDH implementation. I think accessing usb smart card readers directly is a very old and outdated design (forgive me for using the word stupid earlier), but we can't help if major applications still work that way and know no alternative. True. But still there are few scenarios where it make sense, example: firmware update. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] patch for Rutoken
Alon Bar-Lev:
Can you please update the openct trunk so that Rutoken use the new
event interface?
OK, the updated patch is attached.
On 1/28/09, Alon Bar-Lev alon.bar...@gmail.com wrote:
Thanks.
Applied.
Thanks!
diff -u -r openct-0.6.15.trunk-r1127/src/ifd/ifd-rutoken.c
openct-0.6.15.trunk-r1127_new/src/ifd/ifd-rutoken.c
--- openct-0.6.15.trunk-r1127/src/ifd/ifd-rutoken.c 2008-12-31
20:37:50.0 +0300
+++ openct-0.6.15.trunk-r1127_new/src/ifd/ifd-rutoken.c 2009-01-28
17:34:12.0 +0300
@@ -32,15 +32,14 @@
ifd_device_params_t params;
ifd_debug(1, rutoken_open - %s, device_name);
- ifd_debug(1, %s:%d rutoken_open(), __FILE__, __LINE__);
- reader-name = ruToken driver;
+ reader-name = Rutoken S driver;
reader-nslots = 1;
if (!(dev = ifd_device_open(device_name)))
return -1;
if (ifd_device_type(dev) != IFD_DEVICE_TYPE_USB) {
- ct_error(ruToken driver: device %s is not a USB device,
device_name);
+ ct_error(Rutoken: device %s is not a USB device, device_name);
ifd_device_close(dev);
return -1;
}
@@ -48,7 +47,7 @@
params = dev-settings;
params.usb.interface = 0;
if (ifd_device_set_parameters(dev, params) 0) {
- ct_error(ruToken driver: setting parameters failed,
device_name);
+ ct_error(Rutoken: setting parameters failed, device_name);
ifd_device_close(dev);
return -1;
}
@@ -56,25 +55,24 @@
reader-device = dev;
dev-timeout = 1000;
- ifd_debug(1, %s:%d Checkpoint, __FILE__, __LINE__);
+ ifd_debug(1, rutoken_open - %s - successful, device_name);
return 0;
}
static int rutoken_activate(ifd_reader_t * reader)
{
- ifd_debug(1, %s:%d rutoken_activate(), __FILE__, __LINE__);
+ ifd_debug(1, called.);
return 0;
}
static int rutoken_deactivate(ifd_reader_t * reader)
{
- ifd_debug(1, %s:%d rutoken_deactivate(), __FILE__, __LINE__);
+ ifd_debug(1, called.);
return -1;
}
static int rutoken_getstatus(ifd_reader_t * reader, unsigned char *status)
{
- //ifd_debug(1, );
if(ifd_usb_control(reader-device, 0xc1, USB_ICC_GET_STATUS,
0, 0, status, 1, 1000) 0 )
return -1;
@@ -102,8 +100,6 @@
static int rutoken_card_reset(ifd_reader_t * reader, int slot, void *atr,
size_t atr_len)
{
- ifd_debug(1, %s:%d rutoken_card_reset(), __FILE__, __LINE__);
-
int nLen = 0, i;
ifd_debug(1, rutoken_card_reset, slot = %X, slot);
if(ifd_usb_control(reader-device, 0x41, USB_ICC_POWER_OFF, 0, 0, 0, 0,
-1) 0)
@@ -150,8 +146,6 @@
*/
static int rutoken_set_protocol(ifd_reader_t * reader, int nslot, int proto)
{
- ifd_debug(1, set protocol: {%d}, proto);
-
ifd_slot_t *slot;
ifd_protocol_t *p;
@@ -178,7 +172,6 @@
static int rutoken_card_status(ifd_reader_t * reader, int slot,
int *status)
{
- //ifd_debug(1, );
*status = IFD_CARD_PRESENT;
return 0;
}
@@ -397,6 +390,33 @@
return -1;
}
+static int rutoken_get_eventfd(ifd_reader_t * reader)
+{
+ ifd_debug(1, called.);
+
+ return ifd_device_get_eventfd(reader-device);
+}
+
+static int rutoken_event(ifd_reader_t * reader, int *status, size_t
status_size)
+{
+ (void)reader;
+ (void)status;
+ (void)status_size;
+
+ ifd_debug(1, called.);
+
+ return 0;
+}
+
+static int rutoken_error(ifd_reader_t * reader)
+{
+ (void)reader;
+
+ ifd_debug(1, called.);
+
+ return IFD_ERROR_DEVICE_DISCONNECTED;
+}
+
static struct ifd_driver_ops rutoken_driver;
void ifd_rutoken_register(void)
@@ -408,6 +428,9 @@
rutoken_driver.card_status = rutoken_card_status;
rutoken_driver.set_protocol = rutoken_set_protocol;
rutoken_driver.transparent = rutoken_transparent;
+ rutoken_driver.get_eventfd = rutoken_get_eventfd;
+ rutoken_driver.event = rutoken_event;
+ rutoken_driver.error = rutoken_error;
ifd_driver_register(rutoken, rutoken_driver);
}
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] patch for Rutoken
On 1/29/09, Aktiv Co. Aleksey Samsonov samso...@guardant.ru wrote: Alon Bar-Lev: Can you please update the openct trunk so that Rutoken use the new event interface? OK, the updated patch is attached. Thanks! Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Fix for O2 Micro CCID SC Reader
I am attaching the tested patch to the file ifd-ccid.c to add support
for the reader. The reader's USB IDs that I tested with are 0b97:7762
and 0b97:7772. Without this patch the ifd-ccid.c code will not work with
these readers.
The patch is based on the work done in the pcsc-lite project. The patch
is made against openct-0.6.15-svn-r1127. I didn't make corresponding
updates to text configuration files.
Thank you.
--- openct-0.6.15-svn-r1127/src/ifd/ifd-ccid.c 2009-01-29 13:03:01.0
-0800
+++ openct-with-fix/src/ifd/ifd-ccid.c 2009-01-29 13:05:00.0 -0800
@@ -583,22 +583,50 @@
bEndpointAddress;
}
}
if (ok == 7)
break;
intf = NULL;
}
if (!intf)
continue;
if (!intf-extralen) {
- intf = NULL;
- continue;
+ int i;
+ /* Buggy O2 Micro CCID SC Reader has zero extra
len at interface level but not endpoint descriptor.
+* Patch the interface level field and proceed.
+* ProdID 7762 reader is in Dell Latitude D620
and 7772 is in D630.
+*/
+ if( de.idVendor == 0x0b97 (de.idProduct ==
0x7762 || de.idProduct == 0x7772) ) {
+ ct_error(ccid: extra len is zero,
patching O2 Micro support);
+ for (i=0; iintf-bNumEndpoints; i++) {
+ /* find the extra[] array */
+ if( intf-endpoint[i].extralen
== 54 ) {
+ /* get the extra[] from
the endpoint */
+ intf-extralen = 54;
+ /* avoid double free on
close, allocate here */
+ intf-extra =
malloc(54);
+ if( intf-extra ) {
+ memcpy(
intf-extra, intf-endpoint[i].extra, 54 );
+ break;
+ }
+ else {
+ intf = NULL;
+ continue;
+ }
+ }
+ }
+ }
+ else {
+ intf = NULL;
+ ct_error(ccid: extra len is zero,
continuing);
+ continue;
+ }
}
r = intf-extralen;
_class = intf-extra;
i = 0;
p = _class + i;
/* 0x21 == USB_TYPE_CLASS | 0x1 */
/* accept descriptor type 0xFF if force_parse != 0 */
while (i r p[0] 2
(p[1] != 0x21
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
