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: smart_card_reader (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)
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)
On 1/29/09, 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) > * 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->libscreaderRPC>libscreaderd->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)
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)
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: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)
--On Thursday, January 29, 2009 03:36:42 AM +0100 Peter Stuge 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)
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. //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 02:58:53 AM +0100 Peter Stuge wrote: > 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. That's correct. The adapter is just a very funny USB cable; the USB device is entirely in the card. ___ 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)
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)
On 1/28/09, Andreas Jellinghaus 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: > Am Mittwoch 28 Januar 2009 18:06:33 schrieb Alon Bar-Lev: > > On 1/28/09, Andreas Jellinghaus 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)
Am Mittwoch 28 Januar 2009 18:06:33 schrieb Alon Bar-Lev: > On 1/28/09, Andreas Jellinghaus 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. 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) 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). 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/28/09, Andreas Jellinghaus 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)
> 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. > 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. > - 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). > - 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. > - 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? > - 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. > 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, I doubt many people are interested in filling out the details. also some readers support several form factor (eutron gave me a two in one reader, one for sim size and one in credit card size). > 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"? :) also we have no events for "card inserted" or "card removed", so unless there is some application that blocks the reader and monitors it (and thus makes it unavailable for everything else), we can't monitor this information. > 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). hmm, ok. so lets keep it simple? btw, is there some central site where policies like this will be kept and published? hald source / freedesktop / somewhere else? > So, it will be again presented to USB as one device? And CCID will > present contact and contactless chip similarly as two slots? the two device I have are both not ccid I think. you need extra protocols etc. to talk to wireless readers. (librfid is the software, openct needs (or needed?) to be patched, the readers I have are the openpcd reader and some omnikey reader). > I guess, that ISO 7816 covers this as well. I was able to re-insert my > mobile phone SIM card to the plastic I purchased it with and then insert > to smart card reader. pcscd is capable to talk with that card, opensc is > not. wireless readers isiso 14443 A/B and other protocolls like mifare, as far as I remember. > We just should be ready to future extensions. good idea. maybe start small and put people interested in discussing extensions into a comment of the spec? 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 Wednesday, January 28, 2009 03:41:49 PM +0100 Ludovic Rousseau wrote: (mostly I'm agreeing with Ludovic here and adding a few comments of my own) > 2009/1/28 Stanislav Brabec : >> 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)
2009/1/28 Stanislav Brabec : > 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=11&IDFamiglia=3&IDDett1lev=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)
Andreas Jellinghaus wrote: > Am Dienstag 27 Januar 2009 19:14:31 schrieb Stanislav Brabec: > > Ludovic Rousseau wrote: > > > 2009/1/23 Stanislav Brabec : > > > > 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 mifar
Re: [opensc-devel] HAL proposal for smart cards (clarification)
--On Tuesday, January 27, 2009 11:01:15 PM +0100 Ludovic Rousseau wrote: > 2009/1/27 Stanislav Brabec : >> 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)
Am Dienstag 27 Januar 2009 19:14:31 schrieb Stanislav Brabec: > Ludovic Rousseau wrote: > > 2009/1/23 Stanislav Brabec : > > > 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)
2009/1/27 Stanislav Brabec : > 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)
Ludovic Rousseau wrote: > 2009/1/23 Stanislav Brabec : > > 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/23 Stanislav Brabec : > 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)
Andreas Jellinghaus wrote: > 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.). That is why keywords should be carefully selected. They should not be confusing, but must be sufficiently generic to be used on other similar devices. > 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. There is no urgency to define them, but it's nice to think about them. Well, and I have considered, that class and form factor cannot be assigned to card readers, but to slots. Readers with one Class 1 and one Class 3 slot are pretty common (Class 3 for credit card, Class 1 for identification of salesperson. So in the first phase (identifying USB device), we should not assign these keywords to the device: Structure may look as follows: Readers: USB device (category: iso7816.smart_card_reader, numslots) +-slot (category: iso7816.slot, class, form factor,...) +-card (whatever we will need in future) Tokens (maybe): USB device (category: iso7816.smart_token) +-token (category: iso7816.token_chip, class,...) Notes: To implement permissions, it is sufficient to implement just line 1 (and line 1 must have support in HAL). Details of lines 2 and 3 may be defined (and implemented) later. I don't know, whether multi-slot devices use more USB devices, more USB interfaces or only one interface and multi-slot protocol. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +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)
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)
On 1/23/09, Andreas Jellinghaus 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)
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)
(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)
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)
Ludovic Rousseau wrote: > 2009/1/23 Stanislav Brabec : > > 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)
On 1/23/09, Ludovic Rousseau 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)
2009/1/23 Andreas Jellinghaus : > 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)
2009/1/23 Stanislav Brabec : > 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)
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)
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 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. 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? > > 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. 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 yes. so "class1/2/3" might be better than pinpad/display to avoid confusion. btw: some vendors have also "class4", but in those cases the reader has some application specific firmware, and thus is currently not of concern to us. > DeviceKit is not yet complete. Redhat plans to introduce it for Fedora > 11 and port applications later. ah, ok. thanks for the information. 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: > > 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: smart_card_reader.pinpad > > 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)
2009/1/22 Andreas Jellinghaus : > Am Donnerstag 22 Januar 2009 18:57:19 schrieb Alon Bar-Lev: >> On 1/22/09, Andreas Jellinghaus 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. I have the exact same (frustrating) experience with udev and pcsc-lite. Plus: - no udev event is generated when the device is removed - 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. libhal solved all the problems for me. 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)
Hello, I have no objection to report more information about the smart card reader at the HAL interface. But as you said we should be careful of the names we use. 2009/1/22 Stanislav Brabec : > Here is a short example, what I intend to do: > > > > > > > > smart_card_reader > type="strlist">smart_card_reader > type="strlist">smart_card.iso > type="strlist">smart_card.class3 > type="strlist">smart_card.ccid > type="strlist">smart_card.ccid > ccid > > > > > Do not confuse smart_card and smart_card_reader. I do not know what "smart_card.class3" could be. "smart_card_reader.class3" may be valid. It is the reader that is class 3, not the smart card. 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 - class 1 - class 2 : pinpad - class 3 : pinpad + display - number of slots ? But not: - ccid : this is of no use to the application - openct : idem 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. PC/SC defines different ways to use a class 2/3 readers for PIN entry. Not all readers support the same features. This is a new mess for applications supporting different class 2/3 readers :-( I don't think it is possible to report information about the smart card without connecting to the reader (using OpenCT, pcsc-lite, or another framework). I don't even know what kind of information you can get. My program ATR_analysis [1] tries to identify the smart card from the ATR. But the information is not 100% accurate in all cases. Regards, [1] http://ludovic.rousseau.free.fr/softwares/pcsc-tools/index.html [2] http://svn.debian.org/viewsvn/pcsclite/trunk/Drivers/ccid/readers/GemPCPinpad.txt?rev=2649&view=auto -- 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 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
Re: [opensc-devel] HAL proposal for smart cards (clarification)
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. //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)
Am Donnerstag 22 Januar 2009 18:57:19 schrieb Alon Bar-Lev: > On 1/22/09, Andreas Jellinghaus 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)
> 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)
--On Thursday, January 22, 2009 06:50:34 PM +0100 Andreas Jellinghaus 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)
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): openct > 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)
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)
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)
On 1/22/09, Andreas Jellinghaus 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. 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)
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)? 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. 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)
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. 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". 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. I understand the distributions problems: they chose to ship the cyberjack utilities, and now need to live with the stupid design those have (direct access to the device). on the other hand I can't even blame them: while simple operations such as accessing a memory card should work well via pcscd, 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). my personal recommendation is: * use libccid + pcsc-lite for all smart card readers and applications * yes, that means not using openct. we need to admit, that openct has no proper pin entry code for readers with display and pinpad. * 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. 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) 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 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. 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. it would have saved me much, much time, if I had choosen that road many years ago. but at that time I thought it would be better to let the kernel do that, and get "signals" from the kernel (e.g. hotplug interface, later via udev). but now that hal+udev+kernel seem to work fine, I hope we can keep using them. 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)
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: smart_card_reader smart_card_reader smart_card.iso smart_card.class3 smart_card.ccid smart_card.ccid ccid -- 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 : > Ludovic Rousseau wrote: >> 2009/1/22 Stanislav Brabec : > >> > 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? It is just to have a pretty name in a program listing all the hardware connected to the computer? Why not. > Grating access to users physically present at the computer. > It uses standard UNIX ACL, so it can apply to both device nodes and > sockets. We already have that. What you want in fact is _denying_ access to users _not_ physically present at the computer. Why not. 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 Thursday, January 22, 2009 03:54:07 PM +0100 Stanislav Brabec wrote: > Ludovic Rousseau wrote: >> 2009/1/22 Stanislav Brabec : > >> > 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. -- Jeffrey T. Hutzelman (N3NHS) Carnegie Mellon University - Pittsburgh, PA ___ 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 : > > 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)
2009/1/22 Stanislav Brabec : > 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)
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