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

Reply via email to