Re: [opensc-devel] Debian lenny: unplugging the chipcard reader
--On Monday, February 02, 2009 07:38:23 PM +0100 Andreas Jellinghaus wrote: > but keeping openct around with or without ccid > driver, or having some other drivers around > to implement non-ccid drivers all ends up with > the same result: lots of common functionality in > several places. The solution to this, I think, is some kind of library containing common code. That could be part of pcscd, or a separate library that drivers link against, though in the latter case we'd have to take some care to avoid excessive amounts of duplicate code in the binaries, avoid symbol collisions, and make sure it is possible to load multiple drivers that depend on different versions of the library. I don't think the solution to the common-code problem is to have one giant complex driver that tries to support every device. > is there any way we can obsolete openct by having a driver > for pcscd, that supports (almost?) every reader openct supports? > for example adding drivers to ccid, or building several drivers > from one common source? It's possible that, rather than a library, it might work better to pull more drivers up into the pcsc-lite distribution and build them from common source. The main problem with that is that it puts the burden on Ludovic to maintain them, or at least coordinate their maintenance. I'm not sure that would be all bad, but I'd rather be stuck with the current level of duplication than have Ludovic give up because the job has become too big. I've been speculating for a while now that it might not be too hard to produce a sort of driver adapter which would plug into pcscd in the same place as any other ifdhandler, and work by communicating with openct drivers. This would let us get support for any devices for which openct has drivers, and might ease the path for people who want to provide drivers but find pcsc-lite's interface too painful to work with. -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Debian lenny: unplugging the chipcard reader
--On Monday, February 02, 2009 07:52:30 PM +0200 Alon Bar-Lev wrote: > On Mon, Feb 2, 2009 at 7:41 PM, Jeffrey Hutzelman wrote: >> --On Monday, February 02, 2009 04:28:22 PM +0200 Alon Bar-Lev >> wrote: >> >>> The client library monitors /var/run/libscreader for changes >> >> That sounds really nonportable. >> > > I have it working for Linux (inotify) and BSD (kevent). > Solaris has FEM or something similar that use ports. > I am sure major arch has similar mechanism. > All other archs can poll or use some other system specific broadcast. > > The minimum required functionality is an event that be be triggered by > many processes, > and accepted by many clients without message lost. > > If you have a better idea, it would be great. > > I wish to avoid running application be connected to all reader processes > even if it does not use them, and still be able to detect reader > plugin/plugout and card plugin/plugout. The way to do this is to have a single service which provides a rendesvous point for clients and readers, keeps track of what readers exist and of their state, informs clients of changes they are interested in, and mediates when more than one client wishes to access the same reader. This is more reliable than depending on communicating via a filesystem whose state does not automatically change in exceptional circumstances such as when a reader process exits, more portable than depending on inotify, and more efficient than including copies of the server and mediation code in every reader driver and copies of the reader enumeration, selection, and monitoring code in every client application. -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Debian lenny: unplugging the chipcard reader
--On Monday, February 02, 2009 04:28:22 PM +0200 Alon Bar-Lev wrote: > The client library monitors /var/run/libscreader for changes That sounds really nonportable. ___ 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)
--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)
--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] OpenSC Security Vulnerability and new Versions of OpenSC, OpenCT, LibP11, Pam_P11, Engine_PKCS11
--On Wednesday, January 28, 2009 12:51:05 PM +0200 Alon Bar-Lev wrote: >> It assumes the pcsclite library is in a particular location, instead of >> searching for it. This means it will fail to find libpcsclite on a >> system where it is installed in /usr/local, for example. Further, the >> location in question is not derived from $prefix, but rather is >> hardcoded, which is generally considered to be poor behavior for >> configure scripts. If you're going to make an assumption, the correct >> assumption is $libdir, not /usr/lib. > > You can configure this via /etc/opensc.conf Sure, but it shouldn't make a bogus assumption in the first place. >> It loads a library named "libpcsclite.so", which is wrong. That name is >> reserved to refer to a library used at link time; programs referring to >> the library should (and do, if you just link instead of using dlopen) >> always use the library's soname, which in this case is >> "libpcsclite.so.1". This is important because it allows one to affect >> what library is used when linking new programs without changing the >> behavior of existing programs in any way. It also insures that things >> won't break if a new version of libpcsclite comes along with a >> different ABI, because that will have a different soname and it will be >> possible for both versions to be present at the same time. > > You can configure this via /etc/opensc.conf Again, true, but the default is wrong. >> It ignores the headers that go with the pcsclite library, and instead >> uses a built-in header that may or may not agree with the library in >> particulars such as the type signatures of the functions provided. >> It's not possible to get run-time checks of type compatibility in any >> event, but at least you have a fighting chance if you build against the >> same headers as the library. > > This was fixed. Since 0.11.6? Apparently so, since I see the version on the trunk includes if that exists. OK. >> Is there some reason I'm not seeing why dynamically loading this >> library is better than simply linking against it? > > The entry points are part of PC/SC spec. > The code works the exact way in win32, win64 and POSIX. The API is part of the spec. But it is possible for an ABI to stay the same while the API changes. For example, in the case of pcsc-lite this would happen on some architectures if we were to change the definition of DWORD to always be a 32-bit type, as is the case on Windows, rather than being an unsigned long, as it is currently defined both in internal-winscard.h and in the winscard.h shipping with pcsc-lite. Such a change would massively break opensc (but not on 32-bit Linux, where unsigned long is 32 bits, so it might be hard to notice), because the binary interface provided by libpcsclite.so would no longer be the same. But you haven't answered my question, which is... Why is it _better_ to do this explicit dynamic loading of a shared library than to link against it in the normal fashion? I assume there was actually some specific reason for the change, and perhaps we'll hear about it when Andreas has a chance to respond. -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC Security Vulnerability and new Versions of OpenSC, OpenCT, LibP11, Pam_P11, Engine_PKCS11
--On Thursday, July 31, 2008 05:40:40 PM +0200 Andreas Jellinghaus wrote: > Changes in OpenSC 0.11.5 released 2008-07-31 > * PC/SC library is dynamic linked no longer compile time dependency. WHY What was wrong with using pkg-config to find the library, and then linking against it? This approach is broken in several ways: It assumes the pcsclite library is in a particular location, instead of searching for it. This means it will fail to find libpcsclite on a system where it is installed in /usr/local, for example. Further, the location in question is not derived from $prefix, but rather is hardcoded, which is generally considered to be poor behavior for configure scripts. If you're going to make an assumption, the correct assumption is $libdir, not /usr/lib. It assumes that no particular compiler options or other configuration are required to be compatible with that library, where these would normally be provided by pkg-config (this alone is not such a terrible assumption to make, because it is almost always true, but only _almost_ always. For example, on some platforms, if the library used pthreads and the loading program were not built against the pthreads package, things could break in rather bizarre ways). It loads a library named "libpcsclite.so", which is wrong. That name is reserved to refer to a library used at link time; programs referring to the library should (and do, if you just link instead of using dlopen) always use the library's soname, which in this case is "libpcsclite.so.1". This is important because it allows one to affect what library is used when linking new programs without changing the behavior of existing programs in any way. It also insures that things won't break if a new version of libpcsclite comes along with a different ABI, because that will have a different soname and it will be possible for both versions to be present at the same time. It ignores the headers that go with the pcsclite library, and instead uses a built-in header that may or may not agree with the library in particulars such as the type signatures of the functions provided. It's not possible to get run-time checks of type compatibility in any event, but at least you have a fighting chance if you build against the same headers as the library. Is there some reason I'm not seeing why dynamically loading this library is better than simply linking against it? -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] current status?
--On Thursday, January 08, 2009 11:40:54 AM +0100 Andreas Jellinghaus wrote: > Late reply to jeffreys mails (I read them in our web archive): > 1.) yes, we reduce usability with these changes. > 2.) I think those are better defaults, you think otherwise. > what does everyone else think about these changes? It sure would be nice if anyone at all would comment on this. I'm not going to push real hard on this one, though; if you think disabling off-card key generation by default is the better choice, and no one else objects, then let's try it. > 3.) similiar to lock_login. also (not 100% sure here), I think some > apps behave differently (e.g. you get strange warnings etc) if > lock_login is off. This I'm a little more concerned about, because I don't like the idea of firefox or whatever sitting on any token it sees and preventing anything else from using it. I have plenty of uses for smartcards that have nothing to do with my web browser. As I said, I think the long-term answer is to fix opensc so we can handle multiple clients without lock_login. Of course, that will require some developer time, and as you point out, we're a bit short on that right now. In the meantime, as long as I can turn lock_login off, I suppose I can live with the default changing. Again, it'd be nice if there were anyone else commenting on this stuff. > private data objects are used for storing secrets, e.g. the aes key you > use for decrypting your hard disk. data objects are blobs to the card, it > can't do anything other than store them, and allow to read them. private > means you should be only allowed to read or write to them after your pin > was verified. I did change all profile files to add the new priv-data > class. but I could only test cryptoflex myself. (note: I didn't edit the > oberthur profile, I have too little clue about it, but I hope it was > correct in the beginning, since IIRC the code was initially written for > this card). Yup; I figured that out from alon's explanation. Thanks. > your commend on "no so pin" is strange - "pkcs15+onepin" option is exactly > the way opensc initializes a card to have a single pin (i.e. no sopin). I think I was talking about the difference between '-p pkcs15+onepin' and '--no-so-pin'. It's probably not important. > the change in file id's: it seems that every type of object had a special > file id as starting number, so I hope this works. 4600 is some opensc > specific default I think, couldn't find anything on it in the spec. but > again, I only searched in the spec, I'm no expert on it, and not even > sure if I ever read it completely. Yeah, this makes sense. When I wrote that, I was confused into thinking you'd changed the behavior for non-private data objects, rather than adding support for private ones. What you did makes sense to me, now that I understand what's going on. > about the ACL for PIN objects: > currently you need only the transport key to delete a card. I find this > nice for testing and learning. but it is not the most secure setting, I > agree. > > maybe we could use an option mechanism for such a change? > also if cryptoflex has it this way, most other cards will be the same I > think. It looks to me like only cryptoflex, cyberflex, and oberthur currently have this behavior. It's not urgent to me, and in fact I prefer being able to wipe a card clean without having to know any of the existing PIN's. I just thought I'd bring up the issue for people to consider, given that the comments in the profile indicate the intent was always to change it eventually. > so right now I'm happy at least we could find and fix a security issue, > and my plan is only to get some feedback whether that change works, > write a security advisory, and publish a new release. Hrm. Some would argue that the change for that issue should be in its own release, separate from anything else. In practice, it probably doesn't matter in this case. > also it would be good to push the new release to debian and friends, > as they didn't update opensc for quite some time - I guess because > the build process was changed and some changes introduced problems, > but those have been fixed in the meantime, as far as I know. It looks like debian-testing has 0.11.4, which is not too bad. I bet they'd pick up a newer release if someone prodded them. -- 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)
--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] Making a module driver on opensc-0.11.6
--On Friday, January 23, 2009 12:38:54 PM +0100 Andreas Jellinghaus wrote: > hmm. I always wondered if loading binary only pkcs#11 libraries > via pam_p11/pkcs11 into login and gdm/kdm would be ok. Loading? Yes, always -- despite the FSF's best efforts to force people to use only open-source software, the GPL does not actually place any restrictions on the ways in which you may _use_ GPL'd software, only on what you can distribute and how. I don't think a long argument about what the GPL means is likely to be productive here ___ 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
--On Thursday, January 22, 2009 08:49:33 PM +0200 Alon Bar-Lev wrote: > Poll the reader to detect card insert. Yeah, that's still a problem, and certainly one I'd like to see fixed. It's also per-driver, and I'm not sure it even _can_ be fixed for all kinds of devices. >> > 5. The udev support was dropped in favor of hal, which added >> > dependency for all scenarios. >> > >> >> Nothing was dropped in favor of HAL. It is possible to configure pcscd >> to use HAL for USB device detection, but it is by no means mandatory, >> and it is still possible to inform pcscd of new devices by running pcscd >> --hotplug, whether or not it is compiled with HAL support. > > The rules are not provided nor maintained. Hm. Shouldn't they come with the individual drivers, rather than with pcsc-lite itself? I certainly intend to provide udev rules with ifd-egate, as soon as I can figure out what they need to be. >> >> > 6. The libusb support polls the USB bus... So it is irrelevant. >> > >> >> Only if there are drivers that do not advertise IFD_GENERATE_HOTPLUG. >> If all drivers support hotplugging, then the USB bus is scanned only >> when someone runs pcscd --hotplug. It's true that on Linux there is no >> way short of HAL for pcscd to automatically detect new USB devices. As >> far as I know that has always been the case. > > Installing pcscd within mdev environment without libusb is quite > difficult. How do you propose for USB device drivers to talk to their devices, if not using libusb? Remember, we'd like to be portable here; the whole world's not Linux. > 1. Be usable in initramfs configuration, so that I can decrypt the > root filesystem. At this environment I don't have udev, hal or > usbfs... > 2. Drop libusb requirement for coldplug and use sysfs directly. Ouch. -- 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
--On Thursday, January 22, 2009 08:14:20 PM +0200 Alon Bar-Lev wrote: > Well, Ludovic knows my arguments... > 4. Due to the threading limitation of libusb or kenrel pcscd polls > readers every 2 seconds which waste CPU and power resources. Only if you have reader drivers which require this. If all of your reader drivers support hotplugging, then pcscd does not need to poll. > 5. The udev support was dropped in favor of hal, which added > dependency for all scenarios. Nothing was dropped in favor of HAL. It is possible to configure pcscd to use HAL for USB device detection, but it is by no means mandatory, and it is still possible to inform pcscd of new devices by running pcscd --hotplug, whether or not it is compiled with HAL support. > 6. The libusb support polls the USB bus... So it is irrelevant. Only if there are drivers that do not advertise IFD_GENERATE_HOTPLUG. If all drivers support hotplugging, then the USB bus is scanned only when someone runs pcscd --hotplug. It's true that on Linux there is no way short of HAL for pcscd to automatically detect new USB devices. As far as I know that has always been the case. But given your other arguments, I suspect we will have to agree to disagree, and taking this much further is probably not productive. -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Making a module driver on opensc-0.11.6
--On Thursday, January 22, 2009 06:24:58 PM +0100 Andreas Jellinghaus wrote: > my point of view is: > there is not a single external driver that I'm aware off. > thus we could remove the whole code for allowing external > loadable drivers, as there are none, and that would simplify > the code. Yes, and then you could totally give up on providing a well-defined interface for drivers, and then people wouldn't be able to have separately-maintained drivers, wehther or not we know or care about them. The Linux kernel people went that route, and it screws me more or less every day. So, more on principle than anything else, please don't do this. > about the internal/external situation: our long term goal > should be to allow only internal tool to use the internal > api, and suggest using the pkcs#11 interface to everyone. For applications, this is OK, more or less. I'm not sure that's good enough for tools that initialize cards, but it might be. > the only one using the internal api is openssh, and it can be ported > to pkcs#11 I'd like to see that. - alon has done that, but it is a part of a huge change that > is unlikely to find many adopters (my personal guess - I think people > like that ssh is very easy and simple, and adding x.509 results in a quite > complex thing I guess). ssh is not very easy and simple; it is a hugely complex protocol. That it looks easy and simple to its users is a testament to the excellent job many of its implementors have done. Support for X.509 certificates in the SSH protocol is something that has been talked about from time to time, first in the SECSH working group (now concluded) and more recently on its still-active mailing list. I've also seen mention of interest in a couple of other places. Note that getting _anything_ into OpenSSH is quite difficult; they are a bit overparanoid and, besides requiring adequate review, are sometimes very resistant to adding new functionality. > I think we should discuss this scenario: > is it ok if someone uses opensc, changes it as he likes, and published the > resulting code and binaries - with one file only published as *.o (his new > card driver)? I guess that captures the spirit of the LGPL quite nicely > and is quite usable too. (but I have not checked the wording of the LGPL > to find out if that is ok, and I'm no lawyer either...) I think that _should_ be OK -- the interface between card drivers and the framework is or should be a natural boundary, and I think it's self-defeating to basically tell people they can't use opensc (or any open-source software) with particular hardware not because the vendor is unwilling to provide a driver, but because they are unwilling or unable to provide source. I think it's also important to consider cases where there _is_ an open-source driver, but with a GPL-incompatible license. -- 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)
--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
--On Thursday, January 22, 2009 01:18:44 PM +0100 Stanislav Brabec wrote: >> I cannot >> imagine any vendor shipping policy that would allow ordinary users >> direct access to smartcard devices. > > openSUSE has to do it, at least for selected readers, otherwise users of > these applications complain. Adding a PolicyKit restriction would be a > step forward, not back. > >> > PolicyKit can ensure, that only users physically sitting at the desk >> > can use the card. >> >> Unless, as Alon points out, the user is using pcsc-lite or openct, in >> which case the daemon accesses the device, rather than the user doing >> so directly. > > PolicyKit may be useful for pcsc-lite/openct as well, to block remote > users access to daemon. I'm not sure how you intend to do that, or even that it's a good idea. In fact, I'm pretty sure it's not a good idea to assume that all cards belong to a user physically sitting at some terminal; I expect to see a usage model in my organization that involves forwarding of reader access over an ssh connection, in a manner analogous to how the ssh agent works. >> HAL _can_ report these devices, and does, to pcscd. > > Yes, it reports them, but as unknown USB devices. Which is OK, because all smartcard reader devices are _not_ alike, and pcscd needs to identify the device specifically in order to determine which driver to use. > As I wrote in other replies, I am not going to launch anything. No, but you're arguing that a use case for your proposal is to enable launching an application when a reader appears, and that's not the right time to do so. -- 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
--On Thursday, January 22, 2009 02:57:10 PM +0200 Alon Bar-Lev wrote: > On 1/22/09, Stanislav Brabec wrote: >> Alon Bar-Lev wrote: >> > On 1/21/09, Stanislav Brabec wrote: >> Yes, udev supports it as well. But most vendors prefer HAL for this >> purpose nowadays. > > vendors? You mean Novell, right? Most of the major Linuxes, both commercial and otherwise. I believe Sun is also going down this path. >> My current intention was: >> - Define HAL standard keywords for smart card readers (and maybe for >> their features). >> - Identify all Smart Cards by HAL. > > Smartcards or readers? > I guess you mean smartcard. Yeah, see, that's the problem. The OP is still conflating readers and cards, probably because he's spending two much time with hardware in which the two are inseparable. The proposed HAL configuration is centered around detecting readers, which is not entirely inappropriate, but the use cases are all about doing things when a _card_ appears. Things that appear on USB busses are _not_ smartcards, _ever_. Smartcards appear _only_ in readers, which means that applications which wish to do something when a smartcard appears need only watch pcscd (or openct) and take action when a card appears. It doesn't need to know about HAL, and HAL doesn't need to know about smartcards, because there is _already_ an appropriate abstraction here. >> - And finally move pcscd hotplug from udev to hal. With a bit of >> configuration, it may support serial port readers. > > I think it is already implemented using hal. One of the reasons why I > turned to openct. Yes, pcscd supports using HAL to detect hotplugging of USB devices. It also supports using libusb directly, so not wanting to use HAL is not a reason to abandon pcsc-lite. Please, come back. :-) >> Smart card token is just unplugged => save and kill the session, logout > > And if you have two plugged in? > The pam_pkcs11 has a simple process that takes care of this without > any complex configurations. I have to agree here -- automatic logout needs to be tied to the particular card used to log in, if any. I perform tasks fairly frequently in which I insert a card for a short time, to authenticate to some service, and then remove it when I'm done using the service. > I am truly sorry... But I don't see the benefit. For me, it actually comes down to this. Leaving all other issues aside, the real question is what are the actual use cases that will benefit? -- 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
--On Wednesday, January 21, 2009 07:27:03 PM +0100 Stanislav Brabec wrote: > Alon Bar-Lev wrote: >> I don't understand the motivation. >> Why do you care if readers are accessible by all users? > > 1) There are applications, that need direct access to the reader, not > using pcsc-lite (example: cyberjack utilities). And how do these devices know how to talk to readers? Do they have their own reader drivers, separate from those included with pcsc-lite or openct? > That is why it should > allow to access not only to pcsc daemon, but also to users. The purpose of pcscd or openct's equivalent, among other things, is to multiplex access to smartcard devices and provide for the temporary exclusivity that is necessary for all but the most trivial of operations. Bypassing these services is perilous, both to the application doing so and to other applications, whether or not running as the same user. I cannot imagine any vendor shipping policy that would allow ordinary users direct access to smartcard devices. > PolicyKit can ensure, that only users physically sitting at the desk can > use the card. Unless, as Alon points out, the user is using pcsc-lite or openct, in which case the daemon accesses the device, rather than the user doing so directly. > 2) Up to now, HAL has no keyword for these devices and cannot report its > presence. HAL _can_ report these devices, and does, to pcscd. > HAL can easily recognize this device type (at least for USB). It allows > to write simple applications: If smart card reader/token is plugged, do > something (e. g. launch banking application). If you're going to launch an application, it should happen on the basis of the presence of a card, not of a reader. Even then, there is no reason to assume that the presence of a card means that a particular reader should be launched; cards may be useful for ssh, PGP, web certificates, and so on. How would you know which application to launch? Again, I cannot imagine any vendor actually shipping policy that did this, unless/until there is quite a bit more work done on figuring out how to map particular cards to particular applications, and that's not likely to pan out so well. -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] current status?
--On Thursday, January 08, 2009 11:40:54 AM +0100 Andreas Jellinghaus wrote: > Happy new year everyone! > > I was offline for a week or so, and due to a mail problem > all my email was lost. So what is our current status? > > Did anyone have time to test the opensc pre-release, > does it work for you? > > Any new changes added since then or stuff we need to add? > > Late reply to jeffreys mails (I read them in our web archive): Unfortunately, the mailing list seems to have been stuck for a while, so I only just now saw this, even though you sent it a couple of weeks ago. I'm about to leave but will respond to this later today. -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Marx CrypToken MX2048-JCOP
--On Monday, January 19, 2009 06:40:39 AM +0100 Peter Stuge wrote: > http://www.cryptoken.com/en/products/hardware/ct2000.php > > Anyone know about this product? Claims Linux support. I can't say for certain, but it claims to be a JavaCard, which suggests one could load the muscle applet and get it to do something useful. And the corresponding page for the non-Java "CrypToken M2048" claims that that token is a CCID device, so perhaps this one is also. -- 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] preview for opensc 0.11.7
--On Wednesday, December 31, 2008 09:07:52 AM +0200 Alon Bar-Lev wrote: >> Are they actually supposed >> to be private, per PKCS#15? None of the profiles I looked at do this; >> are you updating them all, or just cryptoflex? > > The PKCS#15 implementation already supported private data objects, if you > set --auth-id when you used the --store-data at pkcs15-init. The problem > is that nobody finished the task, and the profile always marked them as > public. The above change fixes PKCS#15 too... So that if you use > pkcs15-init you can store private and public objects. > Andreas changed all the profiles to support the new directory. I checked > it also using asepcos. OK; this now makes perfect sense to me. >> Why the change in fileid? It's not like I have the documentation in >> front of me, but I'm pretty sure that's not one of the special ones. >> In any case, the fileID's you mention are specific to the cryptoflex >> profile. > > Can you please check it out? Yeah, I'm pretty sure that only the PIN and KEY fileid's are magical; the others are just chosen to be conveniently different from anything else in the PKCS#15 DF and so that OR'ing them with a PIN or key ID doesn't result in something that collides with a magical ID (for example, , 0100, or 1000 would be poor choices for prefixes). 4700 should be safe. I have a blank cryptoflex here I can test on; I'll give your changes a try in the next few days, just to give independent confirmation that everything works as expected. -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] preview for opensc 0.11.7
--On Sunday, December 28, 2008 06:47:46 PM +0100 Andreas Jellinghaus wrote: > here is a preview for opensc 0.11.7: > http://www.opensc-project.org/files/opensc/testing/opensc-0.11.7-pre1.tar > .gz > > this new version has a number of changes for security: > * lock_login is now on as default. if you want to run thunderbird and > firefox at the same time, both with smart card support, you need to turn > this option off. but that would allow any application to talk to your > card, and steal a signature. Ugh. This doesn't improve security; any application can already talk to your card if no one happens to already be using it, and really, there is already plenty of opportunity for a program running as you to steal your PIN. I'm inclined to agree with Alon here; the right answer is to fix opensc to correctly support concurrent access from multiple PKCS#11 clients. > * software key generation: I think people expect the smart card to > generate rsa keys, not the opensc software on your host. but opensc can > do that, for example if the card cannot generate rsa keys itself, or for > corner cases like the cardos split key hack. now soft_keygen_allowed is > off in the default configuration. if you want to use cards, that cannot > create rsa keys themself or need special hacks, then you need to turn on > this option. Again, ugh. While there's certainly a security consideration here, I don't believe the marginal improvement gained by making people who have these cards make a configuration change is worth the pain. There is an actual improvement in security only if those people choose instead not to use the card, which somehow seems unlikely. I think here you're proposing trading real usability for false security. > * private data objects were not implemented securely: the > old code stored them with a flag "ask for the pin", but did nothing to > protect the data, thus everyone can read it. The new code sets the > access control right for such data objects, at least with the cryptoflex > 32k card I tried. please give the code a try, and let me know, if your > card still work. It's not clear to me what data objects are for. Are they actually supposed to be private, per PKCS#15? None of the profiles I looked at do this; are you updating them all, or just cryptoflex? > note for testing: > * you need to initialize the card with "pkcs15-init -p pkcs15+onepin" so >that you can store things with pkcs11-tool. Hrm. Ew. But, I suppose this is really just a limitation of PKCS#11. I expect it should also work to initialize with no SO pin, for cards where that works (e.g. cryptoflex). > * after storing data with pkcs11-tool, you can use opensc-explorer to >try to download the data. with the old version "cd 5015" and "get 4601" >would download the first data object, even if it was marked secure. >with the new code the file is now 4701 and protected with a proper ACL, >so you need to present the pin to the card before downloading that > data. Why the change in fileid? It's not like I have the documentation in front of me, but I'm pretty sure that's not one of the special ones. In any case, the fileID's you mention are specific to the cryptoflex profile. > also side note: I'm not sure about this, but I think we cannot fix old > cards with private data objects. what you can do is: > * download the data > * overwrite the data on the card with random data > * store the secret data once more, this time with the new code, so it is > properly secured this time. now you can delete the secret data from your > desktop/laptop (use the "wipe" command to do that securely). This is going to depend on the card. On cryptoflex, I'm pretty sure you cannot change the ACL on an existing file, but the approach you describe should work if there is enough room in the PIN directory. You could also delete the existing data EF, if it was the last thing created in the PIN directory. Incidentally, it is arguably time to change the DELETE ACL's on PIN and key directories in the cryptoflex and cyberflex access profiles to $SOPIN instead of NONE. Anyone have a comment on this? -- Jeff ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
