Andreas Jellinghaus wrote: > Am Dienstag 27 Januar 2009 19:14:31 schrieb Stanislav Brabec: > > Ludovic Rousseau wrote: > > > 2009/1/23 Stanislav Brabec <sbra...@suse.cz>: > > > > I don't know, whether multi-slot devices use more USB devices, more USB > > > > interfaces or only one interface and multi-slot protocol. > > > > > > A multi-slot reader is just one USB device. The only difference is the > > > value of the bMaxSlotIndex field in the CCID descriptor. > > > > > > > > > I don't know if you should have two categories: readers and tokens. > > > > Probably only one "category": iso7816, but more "capabilities". > > I guess the "category" should be something the end user understands. > thus my preference would be "smart_card_reader" and "usb_crypto_token".
We need a "category" string that covers both and use it for both, otherwise we will have problems in defining generic rules (especially in case, when we know, that it is ISO 7816 device, but don't know, which one). Possibilities: iso7816 = smart_chip* iso7811 = magnetic_stripe* (serial protocol, probably no connection with smart_chip* devices). iso7810 = identification* (we probably don't need this vague category) Here are things we should define: For reader: - That it "smart chip" device (ISO 7816) Possible proposal: category = 'smart_chip_device' (string) - Define policy for ACL (see freedesktop Bugzilla) - What type of device is it (smart card reader, smart token) Possible proposal: capabilities = { 'smart_token', 'smart_card_reader' } - Optionally (for openct package), a keyword, that will be used for calling hald-openct-addon (HAL specification proposes separating of information and policy, so one of possible implementation would be adding a keyword in information phase and calling addon in policy phase. Another solution is all-in-one - call addon for selected USB IDs.) - Optionally PC/SC driver Possible proposal: info.pcsc.driver = 'ccid' (istring) For slot: - Form factor Possible proposal: smart_chip.reader.form_factor = 'ID-00' (string) - Class Possible proposal: smart_chip.reader.class = '3' (int or string) - For smart tokens, the structure must be appropriately similar. For cards and token chips: - ATR code of card (device ID) Possible proposal: smart_chip.atr = '3b:be:18:00:00:41:05:10:00:00:00:00:00:00:00:00:00:90:00' (string) - Type of card (EMV, ID card, phone SIM,...), if known. Possible proposal: smart_chip.card_type = 'EMV' (string), optional - Maybe a separate key whether it is a crypto card Possible proposal: smart_chip.crypto = 'yes' (boolean) - Optionally opensc driver Possible proposal: info.opensc.driver = 'oberthur' (string) ... (For example Firewire uses ieee1394.) You can have only one category. If you know, that this is a crypto device, but don't > cases where a usb crypto token implements ccid and thus is recognized as > smart_card_reader are fine with me. Yes, smart token / smart card reader should be just only "bonus info", nothing substantial for the rest of the structure. > "iso7816" was more like a hint for techies, like what cards the reader > supports. (we could even extend it do the differrent formats like id1 > (credit card size) and id0 (sim card size), Form factor is specified in ISO 7810. ISO 7816 specifies chip. And it is a property of slot, not the reader (I can imagine a reader with one SIM and one card slot). > but I think that is more work > than we want to do. (forgive me if I mixed up id0/1/2/...) Yes, it is. I am just thinking "how it can be done, when somebody will want to do it". > > > How do you differentiate them? The form factor? > > > > Knowing the model USB ID, we can provide this information. > > well, sometimes we simply say "everything marked as ccid (i.e. interfaceClass > 11 or whatever it was in usb speak)" is supported by our ccid driver. > then we have no other knowledge than "generic ccid device". but the > hald can copy over vendor and product id strings, if it has something like > that. That is why all parts of the implementation should be exactly the same for card readers and tokens, only say "and if you are interested, this one is a smart token". > > It is possible to detect form factor (credit card size, SIM size)? Is it > > the same way that can be used to detect contact less reader? > > card size doesn't matter, most readers support credit card size and have > some plastik that will be used with sim size cards. the card is the same, > only more plastik with no functionality around the chip and contact field. Yes, in most cases it does not matter. Again, it may be only an additional hint, nothing substantial. I have even seen devices that are on half of way between smart tokens and smart card readers. They are smart tokens with slot for SIM smart card. > contact less readers: there are several different protocols, so we should > somehow signal which protocols a reader supports (e.g. iso14443A, iso14443B > and mifare (or which of the mifare protocols)). > > most contactless readers are multiformat and have one chip for everything. So, it will be again presented to USB as one device? And CCID will present contact and contactless chip similarly as two slots? > 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). 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. > 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. Just now only ACL policy and new device category are required. We just should be ready to future extensions. -- 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 Republic http://www.suse.cz/ _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel