Picking out bits about contactless cards from the thread (and I write 'card' rather than 'smart media' throughout):
David Corcoran (relating to the query about crypto in a contactless card) wrote: > Philips makes some good platforms that support exactly this. IBM uses > this technology > in their JCOP platform. You can also imagine a scenario where a key > exchange occurs so pin > auth is never done over the wireless in the clear. Infineon do the same type of chip (just coming into production), and there's a Javacard OS for it. Philips have new products and have discontinued for new designs the silicon used for the JCOP30, and IBM are moving the JCOP OS to them. Atmel are working on something. All 3 companies have moved the western hemisphere goalposts by increasing the amount of memory to around 64K of EEPROM (Atmel might have added flash memory - I don't have the details). The silicon technology for smart cards has improved dramatically, taking the design parameters much closer than ever to those used in mainstream microprocessor design, and a side effect is much reduced power consumption. Pressures from the GSM market put crypto onto SIM cards with 10 mA max power consumption. Contactless really needs to have below 5 mA power consumption (after the rectifier on the chip), and we are now seeing the second generation of crypto chips like that - theoretically cost effective, but I have a suspicion that making them is not that easy at the moment. These new chips are the ones targeting the passport market. As reported on BBC Radio4 this morning, suppliers are pointing out that the total technology is not ready to meet the USA October deadline, and the USA State Dept says it will not have extra staff to handle the extra demand for visas next year. Maybe the predicted spectacle of queues 3 times round Grosvenor Square in London for visas will not happen - its more likely that we will have to book a slot 6 months ahead. The transport ticketing market wants card to terminal transaction times of less than 200 msec for some schemes, 300 msec for others. During this time they want to check a ticket (offline), or sell a ticket using a purse on the card, or decrement a carnet of tickets - this is for passage through gates. For sales at a vending machine, they want to take advantage of the same fast transaction time to allow you to just wave your card past the reader's aerial (rather than put the card in a tray). London's Oyster system (Cubic equipment, but (sic) the aerials are round rather than square) is like this. Anders Rundgren wrote: > > If we are talking IDs they should be usable also > > for remote work which requires PIN-codes and PKI. > > Is this a reality today? Seems pretty hard to > > get an assymetric crypto engine to run on feeble RF. > > And PIN-codes require a lot of interaction. David Corcoran: > > I'm actually quite impressed with the contactless smart cards that are > > emerging in the marketplace. > > There are a couple full featured ones that do everything a normal card > > would do and are quite fast. > > I like the idea of contactless cards used with passports. Although > > passports generally have a physical > > picture printed, a contactless card would provide a high speed, > > convenient mechanism to pass a > > trusted, digitally signed digital picture of the user as well. I don't yet know what the ICAO people are really intending to do. Last summer they put up a rather vague and simplistic proposal. How fast do they want the card to terminal transaction to be? They seem to want to store a 36K byte loss-less compressed facial image on the card, pull it out, calculate whatever template the camera equipment at the gate needs, and do the comparison. And their crypto was going to be a strong digital signature on the image, using asymmetric cryptography. Massive hot list and key distribution problems appear, both logistical and security - some of us spent an interesting day in London last summer listening to their part-formed ideas. David Everett keeps on reminding us that there are better ways of securing data than using a 2048 bit sledgehammer at the point where verification takes place (I paraphrase). David Corcoran: > > One of my big concerns on the emergence of contactless is that we are > > sort of starting over from a protocol perspective. > > Contact card readers are just now finally getting to the point where > > interfaces are standardized and a > > reader will work with lots of different cards without problems. As > > contactless emerges, I'm almost positive there > > will be similar issues with certain readers not working well with > > certain cards like we had with the contact cards > > a few years ago. Hopefully it won't take long before vendor A-Z's > > contactless cards will work with vendor B's contactless > > reader. Contactless works well now because the contactless provider > > provides the card and reader in most cases or has > > strategic relationships with another vendor that provides the reader. > > As this technology broadens, we may open ourselves up > > to problems we had with contact based cards a few years ago. ICAO is just learning about card to reader interoperability problems (Australia and Montreal are doing the work). ISO/IEC 14443 is not of good quality, and I don't think any serious electronic engineer was involved in its development - perhaps no-one has ever done the end to end gain calculations on the RF (air) interface. Its a 'near field' RF situation, with the magnetic field dominating, so card to terminal is a loose coupled transformer. The difficulties (and here I have been advised by a retired electronics engineeer, but, as he is retired, he says he's not going to do the tricky maths) are that the coil in the card is usually tuned (with a big spread from card to card) to a few MHz above the 13.56MHz carrier frequency, the coil in the reader is tuned to the carrier frequency (or just a bit off, which raises red flags), and 14443 says nothing about the parameters of either of these coils or of the receiver circuitry at each end. 14443 also probably doesn't say enough about the transmitter circuitry in the card. ISO/IEC SC17 WG8 has before it a work item to develop the spec of a reference card reader (probaly DSP based, so that it can provide diagnostic information), which can then be put out by WG1. This week there has been a WG1 meeting, and I hope to hear soon if there has been progress - I doubt it. Anders Rundgren wrote: > > > >> http://www1.chinadaily.com.cn/en/doc/2003-10/15/content_272271.htm > >> > >> But I believe a "Wireless Citizen Card" is much more > >> interesting long-term because if you are "identified" > >> you can "be" all the other things you need to be like > >> paying using 3D Secure which do not require a local > >> credit card (as it resides on secure servers). > >> > >> So far it looks like the EU will lose the initiative as > >> we have no dominant software vendors and other > >> important parties seem unable to go outside of their > >> own core business. > >> > >> I say it one more time: The smart ID card is dead and gone. > >> It is beyond repair. > >> > >> It is like X.500 versus the Web. > >> Or OSI versus TCP/IP. > >> Or BetaMax versus VHS. > >> > >> I saw it happen in "slow-motion"... > >> Is it necessary to do the same thing everywhere for every purpose? Currently countries issue travel documents (passports for those going out, visas for those coming in), and some of them issue separate national ID cards. Anders has for some time been saying we should use mobile devices, but countries are wedded to having something that has visible manifestations of it carrying your ID information. Countries need to learn how to add chips to their travel documents and get the infrastructure running, and then they can go on to 2nd generation devices (mobile devices, but you will still carry your paper passport on many cross border journeys), But we HAVE lost the initiative in the western hemisphere, because Japan has started to roll out their citizen service cards using slightly non-standard Type B 14443 cards and large memory chips (up to 1 Mbyte, I think). Their problem is that the chips use a bit too much power (worst case tolerancing, of course). But when the transaction time is long (>300 msec), the card really needs to be put in a tray or slot, so there isn't a real problem. Put the chip in a housing with power (e.g. a mobile device) and the power problem goes away. But then we should look at a different interface (e.g. the Philips near-field peer to peer interface where both sides have power, doubling up with 14443 functions when only a base station (reader) has power). A last note in something rather long: high performance chips for contact smart cards now have a USB interface and large memories - they will run off into Anders' nirvana but with wires attaching them to the host PC (or they will be embedded in the PDA). Of course, they can be packaged as plug-in USB tokens as well as in ID-1 fomat. Anders: get yourself to CardTechSecurTech (Washington, end April) and tell us where we can find you. Peter _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
