Post by thread:Smart cards

<< Subj: Re: Magnetic card reader. Date: 97-08-19 16:49:30 EDT From: spam_OUTkcw.kcwccTakeThisOuTSYMPATICO.CA (KcW) I agree. Magnetic cards are old hat. Standalone smart card reader/writers can be built very inexpensively (read <$20 in pats) and the ISO7815 cards are about a buck in small quantities with gobs of room for data. As well, the cards can be made secure, reducing the need for PIC based algorithms. >> Does any one know of any links or other info on smart cards? Any kind of introduction or beginner info would be great. Rich

Rick Trostel wrote: > > << Subj: Re: Magnetic card reader. > Date: 97-08-19 16:49:30 EDT > From: .....kcw.kcwccKILLspam@spam@SYMPATICO.CA (KcW) > > I agree. Magnetic cards are old hat. Standalone smart card reader/writers > can be built very inexpensively (read <$20 in pats) and the ISO7815 cards > are about a buck in small quantities with gobs of room for data. As well, > the cards can be made secure, reducing the need for PIC based algorithms. > >> > > Does any one know of any links or other info on smart cards? > Any kind of introduction or beginner info would be great. > > Rich http://www.xicor.com

>> I agree. Magnetic cards are old hat. Standalone smart card reader/writers >> can be built very inexpensively (read <$20 in pats) and the ISO7815 cards >> are about a buck in small quantities with gobs of room for data. As well, >> the cards can be made secure, reducing the need for PIC based algorithms. > >Does any one know of any links or other info on smart cards? >Any kind of introduction or beginner info would be great. > >Rich Not only are mag-stripe cards old hat, but contacted (ISO-7816, not -7815) smartcards are old hat, too! See our contactless smartcard web page at http://www.racom.com. Peter F. Klammer, Racom Systems Inc. PKlammerKILLspamACM.Org 6080 Greenwood Plaza Boulevard (303)773-7411 Englewood, CO 80111 FAX:(303)771-4708

part 0 274 bytes Talking about old hats - I thought all personal identification was done in fingerprint scanners nowadays? No cards to issue, carry around, forget and lose... Identifying vehicles (which was originally the topic) should of course be done via license-plate reading cameras.

Hi I like the technology of smartcards but the stick in a slot action is not as pleasing as swiping a card through a reader. How about a swipe based card anyone? Tim At 16:27 20/08/97 +-200, you wrote: >>Not only are mag-stripe cards old hat, but contacted (ISO-7816, not -7815) >>smartcards are old hat, too! See our contactless smartcard web page at >>http://www.racom.com. > >Talking about old hats - I thought all personal identification was done in fingerprint scanners nowadays? No cards to issue, carry around, forget and lose... Identifying vehicles (which was originally the topic) should of course be done via license-plate reading cameras. > > >Attachment Converted: "e:\eudora\attach\Re Smart cards" > ------------------------------------------------------------------ Personal Web Pages: http://web.ukonline.co.uk/members/tim.kerby/ Email: .....tim.kerbyKILLspam.....ukonline.co.uk ------------------------------------------------------------------

Hi, Could you please advise as to what format your attachment is in. Thanks -David At 04:27 PM 20/08/97 -0200, you wrote: >>Not only are mag-stripe cards old hat, but contacted (ISO-7816, not -7815) >>smartcards are old hat, too! See our contactless smartcard web page at >>http://www.racom.com. > >Talking about old hats - I thought all personal identification was done in fingerprint scanners nowadays? No cards to issue, carry around, forget and lose... Identifying vehicles (which was originally the topic) should of course be done via license-plate reading cameras. > > >Attachment Converted: "C:\EUDORA\ATTACHMT\Re Smart cards" >

>>Not only are mag-stripe cards old hat, but contacted (ISO-7816, not = >-7815) >>smartcards are old hat, too! See our contactless smartcard web page at >>http://www.racom.com. > >Talking about old hats - I thought all personal identification was done = >in fingerprint scanners nowadays? No cards to issue, carry around, = >forget and lose... Identifying vehicles (which was originally the topic) = >should of course be done via license-plate reading cameras. But a smartcard is a writeable, portable reservoir of data; your fingertip can't do that! (You really don't propose a fingerprint database to allow entering a subway or bus, do you?) A smartcard can be a vessel of value, or a delegated agent to execute your bidding. You're thinking of something like ``RFID'' -- which is read-only. We do ``RFTP'' -- Radio-Frequency Transaction Processing, which is read AND write, with security, at a wave of your hand. Peter F. Klammer, Racom Systems Inc. EraseMEPKlammerspam_OUTTakeThisOuTACM.Org 6080 Greenwood Plaza Boulevard (303)773-7411 Englewood, CO 80111 FAX:(303)771-4708

Tim Kerby wrote: > I like the technology of smartcards but the stick in a slot > action is not as pleasing as swiping a card through a reader. > How about a swipe based card anyone? Well, there is a small problem with maintaining a continuous power supply to the smartcard while it's being swiped... In fact, there have been so many problems with the cards being removed halfway through a write to the eeprom that most manufacturers are now designing captive card readers. The card is physically pre- vented from being removed until the memory update is complete. ___Bob

> Tim Kerby wrote: > > I like the technology of smartcards but the stick in a slot > > action is not as pleasing as swiping a card through a reader. > > How about a swipe based card anyone? > Well, there is a small problem with maintaining a > continuous power supply to the smartcard while it's > being swiped... > > In fact, there have been so many problems with the > cards being removed halfway through a write to the > eeprom that most manufacturers are now designing > captive card readers. The card is physically pre- > vented from being removed until the memory update > is complete. > ___Bob Which is EXACTLY why we DON'T rely on EEPROM; we use FRAM! Ferroelectric RAM (there's nothing magnetic about it, folks, the ``ferro'' moniker is historical accident) is batteryless nonvolatile RAM which writes and reads as fast and low power as SRAM. Inevitably (even with a contacted card in a slot) you still have to cope with abrupt ``tear-out'' transaction interruption, but when you can complete a transaction in 100 msec, it becomes a rare event, not a common one. (And one that any competent database-aware computer scientist knows how to handle reliably.) Spend time at http://www.racom.com to see what I'm talking about. Peter F. Klammer, Racom Systems Inc. PKlammerspam_OUTACM.Org 6080 Greenwood Plaza Boulevard (303)773-7411 Englewood, CO 80111 FAX:(303)771-4708

> Which is EXACTLY why we DON'T rely on EEPROM; we use FRAM! Ferroelectric > RAM (there's nothing magnetic about it, folks, the ``ferro'' moniker is > historical accident) is batteryless nonvolatile RAM which writes and reads > as fast and low power as SRAM. Inevitably (even with a contacted card in > a slot) you still have to cope with abrupt ``tear-out'' transaction > interruption, but when you can complete a transaction in 100 msec, it > becomes a rare event, not a common one. (And one that any competent > database-aware computer scientist knows how to handle reliably.) Unfortunately, Ramtron's two-wire FRAM products are more succeptible than two-wire EEPROMs to a particular type of glitch that has caused much annoyance: if the clock wire starts thrashing during a the "write" part of a transaction, data in the device may be erased (WILL be erased if the clock thrashes enough times). Given that all read operations must be preceded by a "write" to set the address, it's possible for this to happen even if no code in the processor deliberately tries to write the data in the chip. The problem with FRAMs that makes them prone to this failure is that there is no checking to ensure that a command is terminated properly. On many of the EEPROM devices, failure to receive a proper "stop" condition following a byte-write or page-write command will result in the entire command being ignored. Since it's unlikely that a flailing CPU would generate a valid stop condition at just the right time, the glitched command would most likely not disrupt anything. Unfortunately, the FRAM has no "page-write" structure; every byte received is written to the chip immediately. Since it is perfectly legal for the CPU to hold the data line low continuously while sending zero bytes(*) the FRAM will write all the zeroes it receives to memory without realizing anything is wrong. By the time the FRAM receives an improper start/stop sequence, bad data will have already been written and undoing the command will be impossible. (*) The FRAM could, I suppose, look for the CPU to let the data line float after clocking out the LSB of a byte. I think normal I2C behavior, however, suggests that the FRAM should assert its data line as soon as it sees the clock go low following the LSB; consequently it would have no way of knowing that the CPU was also holding it low. Perhaps it could let the line float and pull it low once it's been observed to float, but this would introduce some additional timing complexities and is not, as far as I recall, part of the I2C specification. Unless/until Ramtron remedies this defect, I would not recommend the use of an FRAM in applications where reliability is important(**). (**) In the particular application which failed, unexpected disconnection of CPU power would have about a 0.5% chance of disrupting memory contents. Not terribly common, but if you plugged/unplugged the thing a lot it would fail. Although the addition of a CPU/power monitor chip solved the problem, I'm still leery of the device for having that failure mode. (***) This particular project used an 8x51-style processor, with the FRAM's data tied to P3.6; the stuff on port 0 happened to produce a "MOVX A,@R1" opcode. Those familiar with the 8x51 can probably see what this means. For those unfamiliar with the 8x51, it will attempt to fetch code from any address; addresses inside the chip are mapped internally. For those outside the chip, it outputs the address on some port pins and then tries to read the data from port 0. The "MOVX A,@R1" command, as part of its functioning, briefly asserts P3.6 [which doubles as /RD for external memory]. Since P0 always has the "MOVX A,@R1" code on it, the 8x51 will do nothing but flail P3.6 repeatedly. Oops... Anyway, I'm sure many people have used FRAMs without problem, but given the above experience I'm a bit reluctant to do so... after all, there's never "just one" bug lurking in the corner...

John Payson wrote: > > Which is EXACTLY why we DON'T rely on EEPROM; we use FRAM! > > Unfortunately, Ramtron's two-wire FRAM products are more succeptible than > two-wire EEPROMs to a particular type of glitch... Umm, Peter didn't say anything about using a Ramtron FRAM chip. He only indicated the use of memory based on FRAM technology. ___Bob

Hi John (John Payson), in <@spam@199708230633.BAA22381KILLspamKitten.mcs.com> on Aug 23 you wrote: > Unfortunately, Ramtron's two-wire FRAM products are more succeptible than > two-wire EEPROMs to a particular type of glitch that has caused much > annoyance: if the clock wire starts thrashing during a the "write" part of > a transaction, data in the device may be erased (WILL be erased if the > clock thrashes enough times). Given that all read operations must be > preceded by a "write" to set the address, it's possible for this to happen > even if no code in the processor deliberately tries to write the data in > the chip. Thank you for explaining the problem in such detail. I was not aware of it, working on an FRAM implementation right now. Another note to the topic: Some FRAMs (24C16 for example) have a write protection, which allows to protect the upper half of its memory. You can control it with one pin, so you end up with a 3-wire-comm in case you want to protect your memory.

Could you tell me the difference between a keeloq smartcard versus PIC16f84 smartcards? 1.Have anyone used keeloq smartcards? 2.Is it easy to interface to any Pics? 3.Any suggestion on costs? 4.How about 16F84 smarcards, it seems even more pwerful than keeloq? Please comment. Thanks. Norayr