Re: [opensc-devel] HAL proposal for smart cards (clarification)
Andreas Jellinghaus wrote: 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. OK. Considering consensus on info.category: smart_card_reader, I will appropriately correct the patch in http://bugs.freedesktop.org/show_bug.cgi?id=19663 Nothing more is actually needed for PolicyKit. 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? smart_card_reader.num_stots. But I guess that we can live without this key, as separate key would be more flexible. To discriminate between these two types of devices, capabilities line smart_token and smart_card_slots would be sufficient. or use the card size format here? (e.g. slots:id0,wireless ?) not 100% sure No. It is not scalable. Once in future, your would want to assign another key to slot, and it would be impossible (or it would introduce ugly parsing problems). It would be better to postpone these keys to possible future separate HAL record for slot. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ 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)
Andreas Jellinghaus 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) This might work: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=linux.device_file string=/dev/ttyS0 merge key=info.category type=stringsmart_card_reader/merge /match /device /deviceinfo (Depending on system configuration, removing of modem capability would be useful.) * one way how users allowed to access the readers can connect to openct/pcscd Socket GID writeable for scard. By default, no users are in scard group. Then use e. g.: polkit-auth --constraint local /var/run/openct or something similar I think these two things should be kept seperated, and scard is already used for the later case. scard UID may be used for daemon access, scard GID may be used as a static alternative for these sysadmins, that don't want to use PolicyKit. Static style (rough draft): chown -R scard:scard /var/run/openct chmod -R 770 /var/run/openct chmod -R 770 /dev/path_to_the_reader Run daemon as scard user. Add selected users to groups scard. = Only users in group scard can access the reader. Dynamic way with HAL+PolicyKit (rough draft): - set PolicyKit according to http://bugs.freedesktop.org/show_bug.cgi?id=19663 chown -R scard:scard /var/run/openct chmod -R 770 /var/run/openct polkit-auth --constraint local /var/run/openct (/dev/path_to_the_reader is handled by PolicyKit automatically) Run daemon as scard user. Don't add anybody to groups scard. = Only users logged localy can access the reader (it can be changed in PolicyKit settings). -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ 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: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] HAL proposal for smart cards (clarification)
Andreas Jellinghaus wrote:
Am Dienstag 27 Januar 2009 19:14:31 schrieb Stanislav Brabec:
Ludovic Rousseau wrote:
2009/1/23 Stanislav Brabec sbra...@suse.cz:
I don't know, whether multi-slot devices use more USB devices, more USB
interfaces or only one interface and multi-slot protocol.
A multi-slot reader is just one USB device. The only difference is the
value of the bMaxSlotIndex field in the CCID descriptor.
I don't know if you should have two categories: readers and tokens.
Probably only one category: iso7816, but more capabilities.
I guess the category should be something the end user understands.
thus my preference would be smart_card_reader and usb_crypto_token.
We need a category string that covers both and use it for both,
otherwise we will have problems in defining generic rules (especially in
case, when we know, that it is ISO 7816 device, but don't know, which
one).
Possibilities:
iso7816 = smart_chip*
iso7811 = magnetic_stripe* (serial protocol, probably no connection with
smart_chip* devices).
iso7810 = identification* (we probably don't need this vague category)
Here are things we should define:
For reader:
- That it smart chip device (ISO 7816)
Possible proposal: category = 'smart_chip_device' (string)
- Define policy for ACL (see freedesktop Bugzilla)
- What type of device is it (smart card reader, smart token)
Possible proposal: capabilities = { 'smart_token', 'smart_card_reader' }
- Optionally (for openct package), a keyword, that will be used for
calling hald-openct-addon (HAL specification proposes separating of
information and policy, so one of possible implementation would be
adding a keyword in information phase and calling addon in policy
phase. Another solution is all-in-one - call addon for selected USB
IDs.)
- Optionally PC/SC driver
Possible proposal: info.pcsc.driver = 'ccid' (istring)
For slot:
- Form factor
Possible proposal: smart_chip.reader.form_factor = 'ID-00' (string)
- Class
Possible proposal: smart_chip.reader.class = '3' (int or string)
- For smart tokens, the structure must be appropriately similar.
For cards and token chips:
- ATR code of card (device ID)
Possible proposal: smart_chip.atr =
'3b:be:18:00:00:41:05:10:00:00:00:00:00:00:00:00:00:90:00' (string)
- Type of card (EMV, ID card, phone SIM,...), if known.
Possible proposal: smart_chip.card_type = 'EMV' (string), optional
- Maybe a separate key whether it is a crypto card
Possible proposal: smart_chip.crypto = 'yes' (boolean)
- Optionally opensc driver
Possible proposal: info.opensc.driver = 'oberthur' (string)
...
(For example Firewire uses ieee1394.)
You can have only one category. If you know, that this is a crypto
device, but don't
cases where a usb crypto token implements ccid and thus is recognized as
smart_card_reader are fine with me.
Yes, smart token / smart card reader should be just only bonus info,
nothing substantial for the rest of the structure.
iso7816 was more like a hint for techies, like what cards the reader
supports. (we could even extend it do the differrent formats like id1
(credit card size) and id0 (sim card size),
Form factor is specified in ISO 7810. ISO 7816 specifies chip.
And it is a property of slot, not the reader (I can imagine a reader
with one SIM and one card slot).
but I think that is more work
than we want to do. (forgive me if I mixed up id0/1/2/...)
Yes, it is. I am just thinking how it can be done, when somebody will
want to do it.
How do you differentiate them? The form factor?
Knowing the model USB ID, we can provide this information.
well, sometimes we simply say everything marked as ccid (i.e. interfaceClass
11 or whatever it was in usb speak) is supported by our ccid driver.
then we have no other knowledge than generic ccid device. but the
hald can copy over vendor and product id strings, if it has something like
that.
That is why all parts of the implementation should be exactly the same
for card readers and tokens, only say and if you are interested, this
one is a smart token.
It is possible to detect form factor (credit card size, SIM size)? Is it
the same way that can be used to detect contact less reader?
card size doesn't matter, most readers support credit card size and have
some plastik that will be used with sim size cards. the card is the same,
only more plastik with no functionality around the chip and contact field.
Yes, in most cases it does not matter. Again, it may be only an
additional hint, nothing substantial.
I have even seen devices that are on half of way between smart tokens
and smart card readers. They are smart tokens with slot for SIM smart
card.
contact less readers: there are several different protocols, so we should
somehow signal which protocols a reader supports (e.g. iso14443A, iso14443B
and mifare (or which of the mifare protocols)).
most contactless readers are multiformat and have one chip for
Re: [opensc-devel] HAL proposal for smart cards (clarification)
2009/1/28 Stanislav Brabec sbra...@suse.cz: We need a category string that covers both and use it for both, otherwise we will have problems in defining generic rules (especially in case, when we know, that it is ISO 7816 device, but don't know, which one). Possibilities: iso7816 = smart_chip* Please, please, please use smart_card instead of smart_chip. iso7811 = magnetic_stripe* (serial protocol, probably no connection with smart_chip* devices). iso7810 = identification* (we probably don't need this vague category) I have no idea what this 2 other ISO standards are for. Here are things we should define: For reader: - That it smart chip device (ISO 7816) Possible proposal: category = 'smart_chip_device' (string) Please use smart_card_reader. The smart card form factor is really not important: SIM size or full size. For cards and token chips: - ATR code of card (device ID) Possible proposal: smart_chip.atr = '3b:be:18:00:00:41:05:10:00:00:00:00:00:00:00:00:00:90:00' (string) - Type of card (EMV, ID card, phone SIM,...), if known. Possible proposal: smart_chip.card_type = 'EMV' (string), optional - Maybe a separate key whether it is a crypto card Possible proposal: smart_chip.crypto = 'yes' (boolean) - Optionally opensc driver Possible proposal: info.opensc.driver = 'oberthur' (string) ... To populate HAL with card information you will need the help of a PC/SC or OpenCT application. Maybe pcscd can do that if needed. Form factor is specified in ISO 7810. ISO 7816 specifies chip. And it is a property of slot, not the reader (I can imagine a reader with one SIM and one card slot). The Eutron SIM Pocket Combo [1] is such a reader. I have even seen devices that are on half of way between smart tokens and smart card readers. They are smart tokens with slot for SIM smart card. What is the smart token in this precise case? Bye [1] http://www.eutronsec.it/infosecurity/contents/productline/Details.aspx?IDProd=11IDFamiglia=3IDDett1lev=931 -- 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] HAL proposal for smart cards (clarification)
--On Wednesday, January 28, 2009 03:41:49 PM +0100 Ludovic Rousseau ludovic.rouss...@gmail.com wrote: (mostly I'm agreeing with Ludovic here and adding a few comments of my own) 2009/1/28 Stanislav Brabec sbra...@suse.cz: We need a category string that covers both and use it for both, otherwise we will have problems in defining generic rules (especially in case, when we know, that it is ISO 7816 device, but don't know, which one). Possibilities: iso7816 = smart_chip* Please, please, please use smart_card instead of smart_chip. In other words, please don't make up new terminology because you think it's more accurate or easier to understand. The phrase smart card is the proper name of a specific set of technologies, including some that are not shaped like cards. Users already have enough trouble with the confusing array of similar-sounding names for things; there's no need to confuse them further by using wrong names which sound similar to several of the others. iso7811 = magnetic_stripe* (serial protocol, probably no connection with smart_chip* devices). The only thing magnetic stripe cards have in common with smart cards is that they are the same shape and size. This information is likely only of interest to people who are physical credit-card-shaped cards intended to be used with both technologies. Please don't teach HAL to conflate smart cards and smart card readers with other devices with which they have nothing in common. I have even seen devices that are on half of way between smart tokens and smart card readers. They are smart tokens with slot for SIM smart card. What is the smart token in this precise case? Something like the Reflex reader which is really just an egate adapter. But I assume there are other USB-token-shaped devices with SIM slots that are full readers. BTW, note that even by interrogating the reader and card, you cannot always tell what form factor is in use. I can buy a cryptoflex card (if anyone is still selling them) in a credit-card-sized card with a SIM-sized knockout, use it first in a credit-card-sized reader, then pop out the knockout and use it in a SIM reader, then stuff it into a token with a SIM slot. It will be exactly the same card in all three cases. And if the readers in question are really egate adapters, then it will also be exactly the same USB device in all three cases. So as much as one might want to distinguish between readers and tokens, or cards and tokens, it's not always possible to do so. ___ 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/28/09, Andreas Jellinghaus a...@dungeon.inka.de wrote: - Define policy for ACL (see freedesktop Bugzilla) root,root 0600 is fine with me. distributions could create some system account, and use that system account for such usb devices and run pcscd and openct under these accounts (if that works, not 100% sure here - never tried). No. Should allow a group to access, such as root:usb 0660. This way you can add the openctd user (the user under which ifdhandler runs) to this group. Alon. ___ 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)
Andreas Jellinghaus wrote: Am Mittwoch 28 Januar 2009 18:06:33 schrieb Alon Bar-Lev: On 1/28/09, Andreas Jellinghaus a...@dungeon.inka.de wrote: - Define policy for ACL (see freedesktop Bugzilla) root,root 0600 is fine with me. distributions could create some system account, and use that system account for such usb devices and run pcscd and openct under these accounts (if that works, not 100% sure here - never tried). No. Should allow a group to access, such as root:usb 0660. This way you can add the openctd user (the user under which ifdhandler runs) to this group. someone has a group usb? ouch. I don't like this proposal. people might think lets add a user to that group, like we do with audio and video, so people can use usb devices. if then this would be implemented like alon suggested, a user can access a device, that is required for login authentication (if you configured smart card authentication). bad idea, at minimum this could be a denial of service attack. not sure if claiming an interface via usb control prevents every other process to see what you send to and receive from that device, but I hope it does. At least in openSUSE (and probably all other distros using HAL +PolicyKit), default handling of devices is deny everything. Additional permissions are assigned: - To groups, if group concept is sufficient. In case of Smart Cards, it might be GID writability for scard group, allowing to run smart card daemon without root privileges. - Using ACL to locally logged users. It was discussed last week as the controversial direct access to selected readers, if selected applications are installed. My recommendation stands: either run that software as root, or use a special user for these access rights. (is there a special reason not to have some user as the owner of the dynamically created device nodes? if so, a special group with one user only could help, but it should not have a generic name. and I don't know of any such reason) Yes. If the device will be identified as Smart Card device, GID write permission and ACL will be set by HAL+PolicyKit automatically. Smart card daemons don't need to care about it. 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). openSUSE used daemon up to now. Security team recommended a dedicated group, so I will create scard as well and set policy accordingly. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ 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/28/09, Andreas Jellinghaus a...@dungeon.inka.de wrote: someone has a group usb? ouch. I don't like this proposal. Gentoo has. people might think lets add a user to that group, like we do with audio and video, so people can use usb devices. if then this would be implemented like alon suggested, a user can access a device, that is required for login authentication (if you configured smart card authentication). bad idea, at minimum this could be a denial of service attack. not sure if claiming an interface via usb control prevents every other process to see what you send to and receive from that device, but I hope it does. Yes. It is exactly like video and audio. If users need direct access to USB they can be permitted to do so. My recommendation stands: either run that software as root, or use a special user for these access rights. (is there a special reason not to have some user as the owner of the dynamically created device nodes? if so, a special group with one user only could help, but it should not have a generic name. and I don't know of any such reason) Running software as root is the worst solution. Especially security centric software. 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. Alon. ___ 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)
Andreas Jellinghaus wrote:
We need a category string that covers both and use it for both,
otherwise we will have problems in defining generic rules (especially in
case, when we know, that it is ISO 7816 device, but don't know, which
one).
Possibilities:
iso7816 = smart_chip*
ok, but then please name it smart_card_reader.
the chip type depends on the card, th reader can talk to memory cards
too usualy.
Here is the last problem:
How to name the main category smart_card_reader or crypto_token?
1) Invent a good word for it.
2) Use smart_card_reader and invent a different name for the one with
slot for cards.
btw, is there some central site where policies like this will be kept and
published? hald source / freedesktop / somewhere else?
AFAIK only FDI files of HAL package itself and
http://people.freedesktop.org/~david/hal-spec/hal-spec.html
HAL has often surprising results: Several totally different USB devices
use the same USB ID: GPS/scanner, MP3 player/Memory stick.
iso7811 = magnetic_stripe* (serial protocol, probably no connection with
smart_chip* devices).
iso7810 = identification* (we probably don't need this vague category)
I have no clue about them.
ISO 7811: defines magnetic stripes. Most readers are serial character
devices sending characters from the stripe directly.
ISO 7810: Mechanical definition of both magnetic and chip cards.
I have no clue about them as well, but our POS team could have several
such readers.
- What type of device is it (smart card reader, smart token)
Possible proposal: capabilities = { 'smart_token', 'smart_card_reader' }
I never read smart_token before. so my suggestions are smart_card_reader
or usb_crypto_token - the later is a name I invented I guess, but it works
quite well and emphasises the difference to usb (memory) sticks.
I am OK with usb_crypto_token or crypto_token (usb is part of the path).
- Optionally (for openct package), a keyword, that will be used for
calling hald-openct-addon (HAL specification proposes separating of
information and policy, so one of possible implementation would be
adding a keyword in information phase and calling addon in policy
phase. Another solution is all-in-one - call addon for selected USB
IDs.)
driver:openct and driver:ccid (or driver:libccid or driver:pcscd?)
would be fine with me. also it gives the reader a clue what the keyword
is about. is : legal in such names?
Keys in HAL use dot convention. To prevent naming clash, we need to
prepend either category name or any other unique string.
For example kernel uses info.linux.driver, X11 uses input.x11_driver.
- Optionally PC/SC driver
Possible proposal: info.pcsc.driver = 'ccid' (istring)
hmm, we should find a concept so openct can have a driver coded in there too,
so we can remove internal / config file databases with driver maps.
info.pcsc.* info.openct.* would never conflict.
For slot:
- Form factor
Possible proposal: smart_chip.reader.form_factor = 'ID-00' (string)
not really important, maybe skip this? at least make it optional,
Surely optional.
(eutron gave me a two in one reader, one
for sim size and one in credit card size).
Two slots or one slots with two sizes?
For cards and token chips:
I see no reason to put every info we somewhere have into hald.
sure, we could. but what happened to keep it simple? :)
There is no need for it. You can understand it: Once in future, you may
define card info here.
This is our starting point: No changes in pcscd or openct. When it will
work in _may_ be used there.
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
-
SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republichttp://www.suse.cz/
___
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)
Jeffrey Hutzelman wrote: Something like the Reflex reader which is really just an egate adapter. I don't think there is a USB device until the egate is inserted. //Peter ___ 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 Thursday, January 29, 2009 03:36:42 AM +0100 Peter Stuge pe...@stuge.se wrote: Jeffrey Hutzelman wrote: the USB device is entirely in the card. They are nice. I was building my own expresscard egate adapter for a while there. That sounds like a useful item, and hopefully not too tricky. Too bad the cards are so hard to get these days. -- Jeff ___ 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)
Ludovic Rousseau wrote: 2009/1/23 Stanislav Brabec sbra...@suse.cz: I don't know, whether multi-slot devices use more USB devices, more USB interfaces or only one interface and multi-slot protocol. A multi-slot reader is just one USB device. The only difference is the value of the bMaxSlotIndex field in the CCID descriptor. I don't know if you should have two categories: readers and tokens. Probably only one category: iso7816, but more capabilities. How do you differentiate them? The form factor? Knowing the model USB ID, we can provide this information. That is a problem since all the CCID devices can be identified using the bInterfaceClass: 0x0B. Some are readers and some are tokens but the USB description does not provide this information. If we will not know, keeping iso7816 alone would not be a problem. And I also have CCID readers for contact less cards. For a PC/SC application they are used like any normal ISO 7816 readers. We may introduce a keyword (in capabilities or info.) of slot. It is possible to detect form factor (credit card size, SIM size)? Is it the same way that can be used to detect contact less reader? -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ 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)
2009/1/27 Stanislav Brabec sbra...@suse.cz: It is possible to detect form factor (credit card size, SIM size)? No. This information is not stored in any USB descriptor I know. Is it the same way that can be used to detect contact less reader? You can't detect a contactless reader from the USB descriptor. I don't know any way to know if a CCID reader is contact or contactless (at a programming level). 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] HAL proposal for smart cards (clarification)
Am Dienstag 27 Januar 2009 19:14:31 schrieb Stanislav Brabec: Ludovic Rousseau wrote: 2009/1/23 Stanislav Brabec sbra...@suse.cz: I don't know, whether multi-slot devices use more USB devices, more USB interfaces or only one interface and multi-slot protocol. A multi-slot reader is just one USB device. The only difference is the value of the bMaxSlotIndex field in the CCID descriptor. I don't know if you should have two categories: readers and tokens. Probably only one category: iso7816, but more capabilities. I guess the category should be something the end user understands. thus my preference would be smart_card_reader and usb_crypto_token. cases where a usb crypto token implements ccid and thus is recognized as smart_card_reader are fine with me. iso7816 was more like a hint for techies, like what cards the reader supports. (we could even extend it do the differrent formats like id1 (credit card size) and id0 (sim card size), but I think that is more work than we want to do. (forgive me if I mixed up id0/1/2/...) How do you differentiate them? The form factor? Knowing the model USB ID, we can provide this information. well, sometimes we simply say everything marked as ccid (i.e. interfaceClass 11 or whatever it was in usb speak) is supported by our ccid driver. then we have no other knowledge than generic ccid device. but the hald can copy over vendor and product id strings, if it has something like that. It is possible to detect form factor (credit card size, SIM size)? Is it the same way that can be used to detect contact less reader? card size doesn't matter, most readers support credit card size and have some plastik that will be used with sim size cards. the card is the same, only more plastik with no functionality around the chip and contact field. contact less readers: there are several different protocols, so we should somehow signal which protocols a reader supports (e.g. iso14443A, iso14443B and mifare (or which of the mifare protocols)). most contactless readers are multiformat and have one chip for everything. also while opensc is mostly concerned with smart cards and rsa crypto security, many contactless smart cards are stupid memory cards, or authentication depends on the serial number (which is easy to fake sometimes). or the card use a special shared-secret based crypto channel, so you can't access the card, unless you configure that crypto secret first, and other head- aches. note: I'm no expert here, but this is what I remember. so not sure if anyone one linux uses these cards, and if so will use them via openct or pcscd. also opensc at least does not encrypt and secure its communication with a card, as it should in a wireless scenario (note: maybe some driver does, depends on each driver). so not big deal, if our first shot at the wireless case is not perfect, or if we postpone that part of the work for now. 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 Tuesday, January 27, 2009 11:01:15 PM +0100 Ludovic Rousseau ludovic.rouss...@gmail.com wrote: 2009/1/27 Stanislav Brabec sbra...@suse.cz: It is possible to detect form factor (credit card size, SIM size)? No. This information is not stored in any USB descriptor I know. You certainly can't tell in all cases. For example, without looking at it visually, it is impossible to distinguish a SIM-sized cryptoflex card from one which has not yet been separated from its credit-card-sized carrier. -- Jeff ___ 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)
Andreas Jellinghaus wrote:
information: Identify selected devices.
info.category = 'smart_card_reader'
info.capabilities = { 'openct' }
openct or some other software should not matter IMO, why make it a capability?
HAL documentation recommends to discriminate between three types of FDI
files:
- preprobe: Actions before hal starts to identify the device
- information: Collecting information about the device
- policy: Perform actions
Current openct FDI file mixes information (that it is a Smart Card
reader) and policy (call hal addon).
One of possible ways to implement it better is an additional keyword.
Another way would be using of USB IDs known as Smart Card readers in
information and repeating USB IDs of readers known to work in policy.
Good idea! But iso7816 could make it more cryptic to ordinary users.
right. stick with smart_card_reader category and hope we don't need to
explain that a smart_card_reader is not a smart media card reader
too often? :)
I can imagine:
info.category = 'smart_card_reader'
info.capabilities = { 'openct', 'iso7816', 'smart_card_reader', 'usb_ccid'
ccid shouldn't matter. do you need to put the category as capability too?
It is a potentially interesting information, easily detectable from USB
ID.
we should have display and pinpad if capabilities are defined per
category.
if not, the capability name needs to be longer, so display is not mistaken
with displays (e.g. monitors, lcd etc.).
It is generic, as anybody can query for devices with particular feature
without specifying category. smart_card_reader.display would be OK.
A dumb question. Is following true or only reverse implication is valid?
no keywords = smart_card_reader.class1
smart_card_reader.pinpad = smart_card_reader.class2
smart_card_reader.display + smart_card_reader.pinpad = smart_card_reader.class3
The implication may be specified in FDI syntax:
match key=info.capabilities sibling_contains=smart_card_reader.class2
append key=info.capabilities
type=strlistsmart_card_reader.pinpad/append
/match
I expect one another change in near future: Fedora people will say Use
DeviceKit instead of hal.
maybe we can get their devicekit config file and document how to configure
device kit, so other distributions don't need to re-invent the wheel.
DeviceKit is not yet complete. Redhat plans to introduce it for Fedora
11 and port applications later.
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
-
SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republichttp://www.suse.cz/
___
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)
Andreas Jellinghaus píše v Pá 23. 01. 2009 v 13:27 +0100: Am Freitag 23 Januar 2009 12:59:57 schrieb Stanislav Brabec: HAL documentation recommends to discriminate between three types of FDI files: - preprobe: Actions before hal starts to identify the device - information: Collecting information about the device - policy: Perform actions Current openct FDI file mixes information (that it is a Smart Card reader) and policy (call hal addon). One of possible ways to implement it better is an additional keyword. Another way would be using of USB IDs known as Smart Card readers in information and repeating USB IDs of readers known to work in policy. ah, good point. cleaning this up is a good idea. Well, maybe capabilities is not a right place to add this keyword, but the idea remains. with hal, do we need to make sure only either openct fdi file or ccid fdi file is installed? or how can you manage, whether some device will be used by openct or by libccid+pcsc-lite? No. With append keyword, values from both are joined. But actually only openct needs FDI file for HAL hotplugging. pcsc-lite evaluates devices on its own. A separately maintained package would be another possible way to distribute FDI files: Scan all available driver packages, create a list of all known readers, their USB/PCI ids and capabilities (class, card format,...). Whether device will be used by openct: The dedicated keyword described above will introduce call of hald-addon-openct in the policy phase. Manipulation with this keyword can be done with third party FDI files (see XML example sent yesterday). Whether device will be used by pcsc-lite: pcsc-lite listens to all hotplug events. In theory, it may listen only to events containing smart_card_reader capability and even move driver detection to HAL. But I don't think, that it is a good idea. pcsc-lite has its own platform-independent standard way to do it. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ 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 Freitag 23 Januar 2009 14:40:18 schrieb Stanislav Brabec: Well, maybe capabilities is not a right place to add this keyword, but the idea remains. agree. with hal, do we need to make sure only either openct fdi file or ccid fdi file is installed? or how can you manage, whether some device will be used by openct or by libccid+pcsc-lite? No. With append keyword, values from both are joined. But actually only openct needs FDI file for HAL hotplugging. pcsc-lite evaluates devices on its own. ok, so always both software packages are notified about a new device, and we need to somehow manage which one gets the smart card reader (i.e. unless you disable one we have a race with an unpredictable outcome). not perfect, but fine with me. new topic: usb crypto tokens I think we should have both smart_card_reader and usb_crypto_token for those token with internal smart cards (e.g. aladdin etoken pro and friends). it could confuse the users if we say they are smart card readers. 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)
2009/1/23 Stanislav Brabec sbra...@suse.cz: Andreas Jellinghaus píše v Pá 23. 01. 2009 v 13:27 +0100: Am Freitag 23 Januar 2009 12:59:57 schrieb Stanislav Brabec: HAL documentation recommends to discriminate between three types of FDI files: - preprobe: Actions before hal starts to identify the device - information: Collecting information about the device - policy: Perform actions Current openct FDI file mixes information (that it is a Smart Card reader) and policy (call hal addon). One of possible ways to implement it better is an additional keyword. Another way would be using of USB IDs known as Smart Card readers in information and repeating USB IDs of readers known to work in policy. ah, good point. cleaning this up is a good idea. Well, maybe capabilities is not a right place to add this keyword, but the idea remains. with hal, do we need to make sure only either openct fdi file or ccid fdi file is installed? or how can you manage, whether some device will be used by openct or by libccid+pcsc-lite? No. With append keyword, values from both are joined. But actually only openct needs FDI file for HAL hotplugging. pcsc-lite evaluates devices on its own. If I want to run pcscd as non-root (in a future version) I will also need FDI files (to solve the same problem as openct: change the access rights of the smart card reader device). A separately maintained package would be another possible way to distribute FDI files: Scan all available driver packages, create a list of all known readers, their USB/PCI ids and capabilities (class, card format,...). I was thinking of generating the FDI file(s) dynamically. pcsc-lite knows all the vendorID and productID of the USB devices it supports thanks to the Info.plist of each driver. The best place to place an FDI would be in the driver package. The driver knows which USB device it can manage. But to be backward compatible the solution should work without changing every driver package (binary and source code). Whether device will be used by openct: The dedicated keyword described above will introduce call of hald-addon-openct in the policy phase. Manipulation with this keyword can be done with third party FDI files (see XML example sent yesterday). Whether device will be used by pcsc-lite: pcsc-lite listens to all hotplug events. In theory, it may listen only to events containing smart_card_reader capability and even move driver detection to HAL. But I don't think, that it is a good idea. pcsc-lite has its own platform-independent standard way to do it. Once the FDI files are in place pcscd could just listen to events containing smart_card_reader capability. I guess that having two FDI files (one form OpenCT and one from pcsc-lite) for the same USB device and doing the same action is not a problem? OpenCT and pcsc-lite do not work well together since they both (want to) claim the device. Bye PS: I am new to HAL and the FDI files :-) -- 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] HAL proposal for smart cards (clarification)
2009/1/23 Andreas Jellinghaus a...@dungeon.inka.de: new topic: usb crypto tokens I think we should have both smart_card_reader and usb_crypto_token for those token with internal smart cards (e.g. aladdin etoken pro and friends). it could confuse the users if we say they are smart card readers. Could usb_crypto_token be a subclass of smart_card_reader or something similar? If you consider a smart_card_reader as anything accessible using PC/SC (or OpenCT) then a usb_crypto_token is just a special case. One day we may have usb_crypto_token accessible directly in TCP/IP over USB using JavaCard 3 inside. 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] HAL proposal for smart cards (clarification)
On 1/23/09, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: anyway, old stories, long closed. using hald is supported upstream and easier, thus it is the recommend way from my point of view. I have the exact same (frustrating) experience with udev and pcsc-lite. Plus: - no udev event is generated when the device is removed There is, I sent you. Hal get this from somewhere... - it is not possible to use udev to register a callback in a program when an event occurs. You have to write script and use signals. True. libhal solved all the problems for me. But minimal system is Linux+udev+hal+(usbfs?)+pcscd. If we learn from this experience we find that in time more and more complimentary services will be added and core components will have more and more dependencies. It turns POSIX environments into Windows... You have about 20 processes which does nothing only to make system usable. I don't like this direction and prepare to work hard in order to help avoid reaching this state. Maybe for dekstop environment which already have large number of dependencies one more is valid... It is correct that udev did not make life easy, but it is not so complex and the modifications needed were minor. Alon. ___ 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)
Ludovic Rousseau wrote: 2009/1/23 Stanislav Brabec sbra...@suse.cz: A separately maintained package would be another possible way to distribute FDI files: Scan all available driver packages, create a list of all known readers, their USB/PCI ids and capabilities (class, card format,...). I was thinking of generating the FDI file(s) dynamically. pcsc-lite knows all the vendorID and productID of the USB devices it supports thanks to the Info.plist of each driver. Yes, it is possible as well. Major part of this work can be cone automatically using a bit of XML magic. The best place to place an FDI would be in the driver package. The driver knows which USB device it can manage. But to be backward compatible the solution should work without changing every driver package (binary and source code). Agree. Once the FDI files are in place pcscd could just listen to events containing smart_card_reader capability. Yes, if data from plist will be available to HAL, you can do it. In such case, you may even generate key info.pcscd.driver and move even driver selection heuristic to HAL. (benefits: It makes possible out-of-package FDI file in /etc/hal, which assigns driver to a new ID. It makes possible to assign driver to /dev/ttyS1). I guess that having two FDI files (one form OpenCT and one from pcsc-lite) for the same USB device and doing the same action is not a problem? OpenCT and pcsc-lite do not work well together since they both (want to) claim the device. HAL will successfully merge both FDI files and send signal to all listeners. The rest of the story is not a problem of HAL. PS: I am new to HAL and the FDI files :-) Me too. I spent two weeks of learning all this around to be able to correctly fix problems reported for smart cards and UPSes. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ 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)
Andreas Jellinghaus wrote: adding a few info.capability to the fci files is fine with me. the other side is: how these are evaluated. if I have a machine, where both gui access as well console login need the smart card reader, then giving exclusive rights to the one logged in, will break console login? Sharing the smart card is a job of underlaying software (pam_pkcs11 and smart card daemon). HAL an PolicyKit will help only and only by setting UNIX or ACL file permissions. I understand the things stanislav want to do, and agree they are nice. (I used to play redalert.wav in 93 in a linux mailbox and got the attention of the sysadmin quite fast :) ) but: unix user and groups don't work to implement this at all. PolicyKit uses ACL. Node will be owned by smartcard daemon and ACL will set permissions to user physically sitting at the desk. (if you are once logged as gui user and e.g. are included in the audio group, then all you need to do is copy the shell, make it setgid audio and you are done - later a login on the ssh where you don't get the audio group, you can run that setgid shell). sure, the linux security modules stuff can prevent this scenario... Yes, it is not possible with a classical UNIX permissions model. my private opinion is, that a server granting access to authenticated users is the best way This solution was used in SuSE in past. It was called resmgr (library that wraps device accesses allowing to keep source code unchanged). The solution was left in favor of simpler ACL and PolicyKit. But even ACL is not a perfect solution and opens. There is still a long run to get a 100% secure device access OS. User A logs in and turns on recording and leaves. User B opens a new session. User a has no more permission to access audio devices. But as recording was started before permissions were restricted, it continues to work. The only possible solution nowadays is a brutal fuser -k, very probably killing many of innocent desktop applications (mixer applet accesses sound - kill the panel). Fix is above the scope of this list and has to be solved on many levels (kernel, user space). It includes denying access on already opened files and the all code around to prevent crashing of user space applications. - X works fine that way e.g. and I think a central smart card daemon would be great, as you could e.g. enter the pin once during login and keep the card in a verified state so applications can use it without asking the user for the pin all the time. but we have no such software (and some people don't like the scenario), so that is only idle talk. For Class 1 authentication you can use one of desktop keyrings (gnome-keyring). Writing a binding should not be very complicated. suze can implement whatever they want, we can't stop them. and I think it is real nice of stanislav to contact us on the issue, and discuss the options they have, and synchronize e.g. which keywords to put into the hal fci file. I think that level of cooperation is great! Well, I have to do something for customers using cjgeldcarte and similar applications. I seen several irritating changes in HAL keywords in past. That is why I want to think twice before dumb creating of few keywords, that will have to be changed in few months. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ 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)
(joining two sub-threads)
Andreas Jellinghaus wrote:
new topic: usb crypto tokens
I think we should have both smart_card_reader and usb_crypto_token
for those token with internal smart cards (e.g. aladdin etoken pro and
friends). it could confuse the users if we say they are smart card readers.
Ludovic Rousseau wrote:
Could usb_crypto_token be a subclass of smart_card_reader or
something similar?
I have been thinking about it as well.
Regarding smart tokens, the smart_card_reader is confusing.
Returning back, iso7816 may be really better:
category: iso7816.smart_card_reader
category: iso7816.smart_token
Or maybe better:
Category: iso7816
Capabilities: smart_card_reader or smart_token
I'll consult it with HAL developers and ask, what they would suggest.
The information you should report are what you can do with the reader,
not how it works.
So it may be:
- manufacturer name
- product name
Done automatically by USB inquiry, but it's possible to overwrite.
- class 1
- class 2 : pinpad
- class 3 : pinpad + display
- number of slots ?
Agree.
It opens an implementation question:
Capabilities is a string.
That is why we may want dedicated keys:
iso7816.smart_card_reader.numslots = (int) (only reades may have more slots,
isn't it?)
iso7816.class = (int) {even tokens may have pinpad)
But not:
- ccid : this is of no use to the application
If we know that without any research, why not provide it.
- openct : idem
As I wrote in another mail, it a recommended way of assigning to driver.
However it should not be a part of cababilities.
You could reports all the fields of the USB CCID descriptor. See [2]
for an example. But that may be too much and non-CCID reader do not
report all these values.
I guess we can start with a small number of entries.
We will find, whether it is useful and well defined. Later it should be
possible to extend information in a compatible way.
Several notes are in Bugzilla about it:
http://bugs.freedesktop.org/show_bug.cgi?id=19663
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
-
SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republichttp://www.suse.cz/
___
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 Freitag 23 Januar 2009 16:15:39 schrieb Alon Bar-Lev: Plus: - no udev event is generated when the device is removed There is, I sent you. Hal get this from somewhere... hal remembers, udev does not. thus udev only knows that some usb device is gone, but does not remember e.g. vendor and product id and cannot perform the right user. hal keeps more information in memory as far as I know, so it it can do that. 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/23/09, Andreas Jellinghaus a...@dungeon.inka.de wrote: Am Freitag 23 Januar 2009 16:15:39 schrieb Alon Bar-Lev: Plus: - no udev event is generated when the device is removed There is, I sent you. Hal get this from somewhere... hal remembers, udev does not. thus udev only knows that some usb device is gone, but does not remember e.g. vendor and product id and cannot perform the right user. hal keeps more information in memory as far as I know, so it it can do that. All is needed is to be notified on removal. The kernel tells you that if you have an opened handle. And if there is a bug in kernel code when a device is gone (reported by udev) you can repoll your handles and verify existence. If I understand correctly, it was enough for pcscd. Alon. ___ 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)
before I forget: we also have at least one card reader with wireless interface. it supports iso 14433A and B and mifare protocols, if I'm not mistaken. the code to use it is librfid. I would prefer not to use the rfid name in any way, since has become a generic word for very different technologies (e.g. contactless smart cards akaiso 14443A and B and mifare, but also autoid tags aka ISO 18006-C and predecessors, and also active powered cards (not sure which protocol) etc.). but I'm not sure if the patches to get wireless smart cards going was ever merged, or if anyone uses them, so there is no urgency at all for this. 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)
2009/1/23 Stanislav Brabec sbra...@suse.cz: I don't know, whether multi-slot devices use more USB devices, more USB interfaces or only one interface and multi-slot protocol. A multi-slot reader is just one USB device. The only difference is the value of the bMaxSlotIndex field in the CCID descriptor. I don't know if you should have two categories: readers and tokens. How do you differentiate them? The form factor? That is a problem since all the CCID devices can be identified using the bInterfaceClass: 0x0B. Some are readers and some are tokens but the USB description does not provide this information. And I also have CCID readers for contact less cards. For a PC/SC application they are used like any normal ISO 7816 readers. 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] HAL proposal for smart cards (clarification)
Reading the discussion, I want to clarify the original problem and needed help: Primary problem: HAL recognizes Smart Card readers as unknown USB devices Proposal to fix: - Add a keyword for info.category (one word for device is permitted) to describe the device (other devices use for example 'sound', 'storage', 'scanner', 'biometic.fingerprint_reader' etc.) - Define keywords for info.capabilities (arbitrary number of words is possible for a single device (other devices use for example 'serial', 'input.keypad', 'block', 'camera'). Dot notation is often used to keep keywords unique. (more exact description = more chances for user software) Before proposing keywords, see http://bugs.freedesktop.org/show_bug.cgi?id=19663 We want to ensure, that these keywords don't conflict with other devices. - More is possible. For example, we can define keyword info.pcsc.driver. Needed help: Propose a smart set of keyword set to cover all Smart Card applications and related area (non-smart chip cards). Should we use keywords like 'smart_card_reader' or only 'card_reader' or even syntax like 'reader.card.iso', 'reader.card.sim', 'reader.smart_token'. What about memory card readers capable to read SIM etc. Secondary problem: Primary problem makes impossible to define Smart Card policy to PolicyKit. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ 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)
2009/1/22 Stanislav Brabec sbra...@suse.cz: Reading the discussion, I want to clarify the original problem and needed help: Primary problem: HAL recognizes Smart Card readers as unknown USB devices Why is that a problem? Why do you need HAL to know about smart card readers? I guess it is directly linked to your secondary problem. Secondary problem: Primary problem makes impossible to define Smart Card policy to PolicyKit. But why do you need to configure PolicyKit? What is the problem PolicyKit is trying to solve? 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] HAL proposal for smart cards (clarification)
Ludovic Rousseau wrote: 2009/1/22 Stanislav Brabec sbra...@suse.cz: HAL recognizes Smart Card readers as unknown USB devices Why is that a problem? Why do you need HAL to know about smart card readers? HAL detects correctly music players, scanners, fingerprint readers, UPSes (well, just only HID). Why Smart Cards should stay unknown devices? I guess it is directly linked to your secondary problem. Yes. It is linked to the secondary problem and in particular to granting device access to applications that don't use pcscd. Only some of them are open source and can be modified accordingly. But why do you need to configure PolicyKit? What is the problem PolicyKit is trying to solve? Grating access to users physically present at the computer. It uses standard UNIX ACL, so it can apply to both device nodes and sockets. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ 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)
Jeffrey Hutzelman wrote: HAL recognizes Smart Card readers as unknown USB devices Why is that a problem? Why do you need HAL to know about smart card readers? HAL detects correctly music players, scanners, fingerprint readers, UPSes (well, just only HID). Why Smart Cards should stay unknown devices? This is not a use case. Please show us an actual use case. As I wrote before, I have an application, that needs direct access to the reader and I need to permit direct access to selected readers just to the local user sitting at the machine. (Yes, I know that it is bad and deprecated way to access cards, but I didn't wrote these applications.) HAL policy is the preferred way to do it in openSUSE. That is why I need to identify Smart Card readers by HAL. I don't need anything more, but when it will be done, it would be good to do it a good way to prevent changes in future. That is why I am asking here. I can imagine more use cases: Launching applications was one of examples. Another example may be: When the Class 3 reader is attached, suggest to install additional applications. Just another: When a smart token is attached during system installation, ask user, whether to configure it for encrypted devices/boot/login. Here is a short example, what I intend to do: ?xml version=1.0 encoding=UTF-8? deviceinfo version=0.2 device match key=info.subsystem string=usb match key=usb.vendor_id int=0x076b match key=usb.product_id int=0x3821 merge key=info.category type=stringsmart_card_reader/merge append key=info.capabilities type=strlistsmart_card_reader/append append key=info.capabilities type=strlistsmart_card.iso/append append key=info.capabilities type=strlistsmart_card.class3/append append key=info.capabilities type=strlistsmart_card.ccid/append append key=info.capabilities type=strlistsmart_card.ccid/append merge key=info.pcsc.driver type=stringccid/merge /match /match /match /device /deviceinfo -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ 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)
adding a few info.capability to the fci files is fine with me. the other side is: how these are evaluated. if I have a machine, where both gui access as well console login need the smart card reader, then giving exclusive rights to the one logged in, will break console login? I understand the things stanislav want to do, and agree they are nice. (I used to play redalert.wav in 93 in a linux mailbox and got the attention of the sysadmin quite fast :) ) but: unix user and groups don't work to implement this at all. (if you are once logged as gui user and e.g. are included in the audio group, then all you need to do is copy the shell, make it setgid audio and you are done - later a login on the ssh where you don't get the audio group, you can run that setgid shell). sure, the linux security modules stuff can prevent this scenario... my private opinion is, that a server granting access to authenticated users is the best way - X works fine that way e.g. and I think a central smart card daemon would be great, as you could e.g. enter the pin once during login and keep the card in a verified state so applications can use it without asking the user for the pin all the time. but we have no such software (and some people don't like the scenario), so that is only idle talk. suze can implement whatever they want, we can't stop them. and I think it is real nice of stanislav to contact us on the issue, and discuss the options they have, and synchronize e.g. which keywords to put into the hal fci file. I think that level of cooperation is great! which reminds me that I nearly never get any feedback from any distribution but from time to time went around and looked at their setup and changes and patches, as nearly noone would send patches back upstream. thus any cooperation from distribution to upstream is very nice and something we should be glad to have! 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)
Andreas Jellinghaus wrote: Am Donnerstag 22 Januar 2009 15:54:07 schrieb Stanislav Brabec: But why do you need to configure PolicyKit? What is the problem PolicyKit is trying to solve? Grating access to users physically present at the computer. It uses standard UNIX ACL, so it can apply to both device nodes and sockets. so what happends with using smart cards readers for authentication (including login)? It involves no change to smart card utilities. PolicyKit can just refuse access to pcscd by remote users (at least by default). And it can do the same for direct access, if we will permit it for local users. login - PAM - runs as root - access permitted card use as local user - PolicyKit permits access to pcscd - pcscd has access permitted asking people to install hald on a server without any gui already adds many packages for no other good reason. I don't know much about Policykit, but please keep the server with minimal installation scenario in mind, where admins want to login using their smart card. You can live with static permissions and static references to device nodes, you can still live without both hal and udev. pcscd used hal just to listening to events. Compile time option allows to switch back to udev. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ 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)
Andreas Jellinghaus wrote:
openct already has a fci file, adding some
information into it so gui tools can identify
the result is not a bad idea I guess.
It's my plan to start with this file. This file uses smart_card_reader
for category. HAL specification recommends to use two FDI files in this
context.
information: Identify selected devices.
info.category = 'smart_card_reader'
info.capabilities = { 'openct' }
policy: Perform actions on these devices.
if capabilities contain 'openct' then add hald-addon-openct to
info.addons.
Example for disabling of openct for particular reader by (with a few
changes, pcsc-lite can be handled in a similar way):
?xml version=1.0 encoding=UTF-8?
deviceinfo version=0.2
device
match key=info.subsystem string=usb
match key=usb.vendor_id int=0x0973
match key=usb.product_id int=0x0001
remove key=info.capabilities type=strlistopenct/remove
/match
/match
/match
/deviceinfo
so please use smart card reader and friends. or even better, throw
in iso 7816 somewhere, as that technical term is the best way to clearly
say what we are talking about.
Good idea! But iso7816 could make it more cryptic to ordinary users.
I can imagine:
info.category = 'smart_card_reader'
info.capabilities = { 'openct', 'iso7816', 'smart_card_reader', 'usb_ccid' }
But we can introduce new keywords to not overload 'info.capabilities',
e. g. info.smart_card = { 'iso7816', 'usb_ccid' }
or even
info.smart_card.class = 3
I have no idea, what would be better in future.
please don't use card_reader, we already have trouble with people
only knowing comptact flash / smart media cards / ... and being confused
by what we call smart card.
There are already CF/SM/... card readers, that support SIM cards as
well. That is why I can imagine 'card_reader.iso7816'.
also I want to point out, that people might want to use smart card readers
for authentication. hal seems to be very gui-desktop centric, if I'm not
mistaken? (people still seem to use /etc/fstab to mount there filesystems,
and not a hal config file)
It is not GUI-centric, it is GUI-helpful. Tools for console users with
HAL exist as well.
The very simplistic example of HAL - GUI:
USB dongle inserted - IRQ - kernel (load driver) - udev (create /dev
node) - hal (scan partitions contents) - dbus - GUI is listening:
Device /...udi was inserted. It has following partitions with following
file systems.
GUI thinks and says: OK. Please mount with these options. - dbus -
hal (gets a mount request) - mkdir mount - kernel
Work is done. User does not need root privileges, but can still control
mount process or even completely reject.
People with a static devices configuration don't need HAL.
using udev was a huge pain for many years, everytime I thought now it
works, a few months later openct didn't work with the new udev. I'm sick
of that pain, and since the udev/hotplug/linux-usb folks tell us to use hal,
and hal seems to work, I think it is best to take their advice and do that:
use hal!
I expect one another change in near future: Fedora people will say Use
DeviceKit instead of hal.
I have too little clue about the further developments of hal and policykit
and what kde and gnome do, so I can't comment on that.
PolicyKit does not communicate with GNOME (with exception of local X
session registration). It only permits local access to ALSA and other
desktop centric devices.
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
-
SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republichttp://www.suse.cz/
___
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 Thursday, January 22, 2009 06:50:34 PM +0100 Andreas Jellinghaus a...@dungeon.inka.de wrote: more complex operations such as upload new firmware to card reader will most propably never work with pcscd (guessing only, I'm no expert here). I think that's going to depend on the reader driver. There certainly is a reader-level IFDHControl operation which could do pretty much arbitrary operations. Of course, such operations are likely to require close cooperation between the reader and application. OTOH, I don't think you want non-privileged users uploading new firmware to devices anyway. my personal recommendation is: * use libccid + pcsc-lite for all smart card readers and applications Well, all CCID readers, anyway. Obviously you need a different driver for non-CCID readers. * yes, that means not using openct. we need to admit, that openct has no proper pin entry code for readers with display and pinpad. Or openct could be improved in this area. Currently my preference is to continue using pcsc-lite, but as you can tell from the discussion Alon and I have been having, there are definitely tradeoffs involved. * yes, that also means not using the (most likely binary only?) code the vendor published. I'm pro open source here, sure. also I think distributions are much better off with one generic software, than they are with many vendor-specific incompatible solutions. I'm pro-open-source, too, but not to the exclusion of people being able to get work done. Open source is a means to an end, not an end in itself, and too often its advocates forget that. also I want to point out, that people might want to use smart card readers for authentication. hal seems to be very gui-desktop centric, if I'm not mistaken? Not really. HAL is an abstraction for device enumeration. It's not GUI-desktop-centric at all, but many of its current users are. (people still seem to use /etc/fstab to mount there filesystems, and not a hal config file) That's because most people aren't insane, and other than for certain special cases (mostly, removable media), HAL doesn't offer any improvement in this area over the existing model. using udev was a huge pain for many years, everytime I thought now it works, a few months later openct didn't work with the new udev. I'm sick of that pain, and since the udev/hotplug/linux-usb folks tell us to use hal, and hal seems to work, I think it is best to take their advice and do that: use hal! udev went through a lot of growing pains. I think that's been over for a while, but I haven't been watching closely, so I may be wrong. I'm perfectly happy to use HAL in situations where it's appropriate, but I agree with Alon that HAL is not appropriate for every situation. Particularly, it's unneeded complexity in embedded environments where there are a small number of possible hardware configurations and they don't change much. -- Jeff ___ 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)
information: Identify selected devices.
info.category = 'smart_card_reader'
info.capabilities = { 'openct' }
openct or some other software should not matter IMO, why make it a capability?
Good idea! But iso7816 could make it more cryptic to ordinary users.
right. stick with smart_card_reader category and hope we don't need to
explain that a smart_card_reader is not a smart media card reader
too often? :)
I can imagine:
info.category = 'smart_card_reader'
info.capabilities = { 'openct', 'iso7816', 'smart_card_reader', 'usb_ccid'
ccid shouldn't matter. do you need to put the category as capability too?
we should have display and pinpad if capabilities are defined per category.
if not, the capability name needs to be longer, so display is not mistaken
with displays (e.g. monitors, lcd etc.).
I expect one another change in near future: Fedora people will say Use
DeviceKit instead of hal.
maybe we can get their devicekit config file and document how to configure
device kit, so other distributions don't need to re-invent the wheel.
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 Donnerstag 22 Januar 2009 18:57:19 schrieb Alon Bar-Lev: On 1/22/09, Andreas Jellinghaus a...@dungeon.inka.de wrote: using udev was a huge pain for many years, everytime I thought now it works, a few months later openct didn't work with the new udev. I'm sick of that pain, and since the udev/hotplug/linux-usb folks tell us to use hal, and hal seems to work, I think it is best to take their advice and do that: use hal! It works correctly for me. Maybe I miss something. The changes in udev were minor and were not a reason to add more dependency. some combination of udev rules found in the real world, would cause udev to call the openct udev script before udev created the device file in /dev/bus/usb. at the same time distributions stopped using /proc/bus/usb (because they could put ACLs on /dev/bus/usb and favored it that way). sure, even such race conditions could be worked around (fork, sleep 1 sec, now the device should be there), but it still was annoying. this is only one example how openct got broken by udev. another time an essential info passed from kernel to userland for the hotplug events was missing, and needed to be re-added later. anyway, old stories, long closed. using hald is supported upstream and easier, thus it is the recommend way from my point of view. 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 Freitag 23 Januar 2009 01:49:05 schrieb Peter Stuge: Andreas Jellinghaus wrote: if anyone wants to walk into the opposite direction, write a daemon that monitors usb and then acts on any change, that is fine with me - I think pcscd does exactly that? not sure. Implementation should be simple at least for Linux. yes and no. it would be simple to scan the usb bus every 0.5 seconds and compare the result to the last scan to see if anything changed. but if you want to save power on laptops and idle as much as you can, I guess the code you need will be much more complex. also it might be difficult to write such code cross-plattform. at least mac OS X has a very different usb interface, and I'm not sure if libusb can abstract away all the pain of two different designs. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
