9

According to https://groups.google.com/g/alt.folklore.computers/c/z4sm_W1MZXg

at the start of the century there were several efforts for secure payments involving chip cards (and chip readers).

in the internet home pc market, one payment brand added chip to their card and started providing "free" card readers. However, these were serial-port, possibly obtained at fire sale as obsolete. The consumer support problems (BSOD, requiring systems to be re-installed) resulted in rapidly spreading opinion in the financial industry that consumer chipcards were not practical in the home market (it actually wasn't chipcards, or card readers, but serial port devices).

My wife organized a review in Redmond with the kernel security group, what members of the former PC/SC group that could be found and several reps of the financial industry ... but the net was that it wouldn't be possible to reverse the financial industry impression of problems with smartcards in the home market.

This is a very interesting story, because if true, it describes a path dependency; a significant aspect of today's world would be noticeably different if not for a particular historical contingency, a single company happening to take a particular action at a certain time.

Is this story true? Did that episode with the serial port card readers actually happen? If so, what does it refer to, what company, and what year? And if it did happen, is the poster's analysis of the impact, actually correct, or were there other factors involved?

16
  • 3
    The links doesn't point to any posting containing the above citation. Would be important, as so far it seems quite dubious.
    – Raffzahn
    Aug 23, 2023 at 18:25
  • 4
    I suspect that if it si any grain of truth in this, it has absolutely nothing to do with the fact taht teh devices were serial per se, since the serial protocol is quite robust, wel defined and well tested, but that the driver program and/or teh devices abused the serial protocol and the crashes came from that.
    – UncleBod
    Aug 24, 2023 at 6:22
  • 4
    @user3528438: A Windows 3.1 machine I worked with at a client site would often instant reboot when an embedded system attached to a serial port crashed, even though the serial port otherwise acted just like an ordinary serial port and I'm unaware of any unusual serial port drivers being attached to it. I don't know whether flailing on the modem control lines caused interrupts to occur to fast or what, but I find the notion that some serial devices could crash windows machines by themselves plausible, because I know of a seemingly-ordinary machine where that happened.
    – supercat
    Aug 24, 2023 at 14:29
  • 7
    @supercat: On Windows 3.1, an application bug could take down the system. That's no evidence that "being serial" had anything to do with the crashes.
    – Ben Voigt
    Aug 24, 2023 at 15:50
  • 5
    The anecdote is definitely false, or at the least it's conflating multiple other stories together. The free card reader sounds like the CueCat, which was a barcode reader and not a smartcard reader, and had nothing to do with payment. Serial devices can't really cause BSODs, and even if they did, suffering a BSOD does not require a flatten and reinstall of the operating system.
    – Coxy
    Aug 25, 2023 at 6:18

2 Answers 2

24

I have some doubts regarding this story.

First, quite the opposite of what's claimed, one of the advantages of serial-port devices is that using them does not need any deep OS changes. Every OS at the time would already have had good built-in support for the serial port itself – after all, you'd connect your dial-up modem through serial – and would have offered a standard interface for it, so all the device-specific logic could remain in "userspace" (i.e. PC/SC could remain an ordinary process) from where it's considerably more difficult to BSOD even old Windows versions. All that the software needs to do is open COM1: in a standard way and it will work very reliably.

That's in contrast to other connection types (say, USB with an interface that the OS doesn't have native support for) which do require custom drivers that are a prime source of OS-crashing bugs. (For example, my first computer didn't have an Ethernet port; when we got ADSL, the modem had to be connected via USB, providing an Ethernet-over-USB interface that slightly predated standard CDC. The custom driver that Windows 98 needed for such a connection would tend to crash the OS during install, during reconnect, etc. – it was the leading cause of BSODs on that machine.)

Now the number of serial ports that a user had available might be an issue – one is typical, two is rare, three would need an expansion card. If you had only COM1 and were getting your Internet access through it (so that you could reach the online store!), there was no way to connect a serial-port card reader.

Second, consumer card readers are quite widespread now – many business laptops have a smartcard slot; my 2022 Thinkpad has a reader, as does my 2017 HP and 2006 Fujitsu. (Over here in the EU, there's also a wider market for standalone USB readers because several countries issue ID cards that can be used for digital signature.) They are meant for digital certificate cards but can recognize and talk to EVM payment cards as well, as the mechanical and electrical interfaces are the same; so the user barrier to entry would be quite low if banks had any interest in it…but they don't.

Right now I can actually sign in to my online banking using my national ID card, but it's a pain in the ass, as described below.


Finally... I've been messing around with modern smart cards a bit (which are USB-connected, either an integrated USB stick or a traditional reader that takes real chip cards). They're still garbage. How the readers connect to the machine actually doesn't matter all that much – nowadays it's USB using a standard CCID interface – the problem is that with the PC/SC architecture you still need an additional module that understands how to talk to the card itself through the reader, e.g. for certificate cards you need a PKCS#11 .dll that needs to be configured in each app. So even if I sit down at a computer that has a perfectly working reader, it won't recognize my Gemalto ID card straight away.

On Windows it is actually the "card" PC/SC modules, not the "reader" device drivers, that are mighty annoying to troubleshoot. If you have to install one vendor's modules, chances are it'll completely break interaction with another vendor's cards, even those that Windows had built-in support might suddenly stop working (and if you install software from two vendors, god help you). On top of that, it's a market that by its nature seems to make vendors incredibly resistant to open-source solutions (with maybe the only exception being US DoD having their open PIV standard).

To be fair, all of this is for certificate cards, whereas at least credit cards do have a single EVM standard and you probably would not need separate drivers for Visa and MasterCard... But you get the general impression – really, the problems with smartcards have very little to do with how the reader is connected.

7
  • 5
    My experience with PIV cards has been plug-and-play. Windows and MacOS know how to deal with them out of the box. The Government has conformance tests, at least for the stuff they buy. By the way, PIV is not DoD, it's the rest of the US Government; the DoD is CAC.
    – user71659
    Aug 23, 2023 at 23:07
  • 6
    This answer makes interesting points about using serial. Serial has been universally implemented, and well used/stable for decades. When USB peripherals first came out, it was always anyone's guess as to whether it would work or not - no matter what the OS. They were advertised as "Plug and Play", but we always said "Plug and Pray". If this question had cited a USB peripheral as a cause, I could really imagine it being a cause of great pain.
    – Kingsley
    Aug 24, 2023 at 0:45
  • 3
    @Kingsley well except that Windows 10 for example still contains the code to detect a serial mouse, which would sometimes cause my serial pressure sensor to be detected as a serial mouse and cause a mild panic that my PC was infected because of the erratic mouse movements. The issues I had with serial under Windows - I'd not consider it stable. Of course I had a Microsoft Explorer USB mouse, which reproducibly completely destroyed my Windows 98 installation when used as USB mouse, so I can understand that notion.
    – Arsenal
    Aug 24, 2023 at 12:47
  • 3
    @Arsenal: I'd had that happen in Windows 7 and thought it was crazy. Windows 10 still does that!?
    – supercat
    Aug 24, 2023 at 14:30
  • 2
    "if banks had any interest in it…but they don't" Pretty sure that is also different in the EU.
    – Ben Voigt
    Aug 24, 2023 at 15:47
8

There was (at least) one effort to add more security to online payments in the late 90s, and that was SET.

SET was developed by the SET Consortium, established in 1996 by Visa and Mastercard in cooperation with GTE, IBM, Microsoft, Netscape, SAIC, Terisa Systems, RSA, and VeriSign.[1] The consortium’s goal was to combine the card associations' similar but incompatible protocols (STT from Visa/Microsoft and SEPP from Mastercard/IBM) into a single standard.

SET required the use of certificates, and changed radically the way payments were processed. It was quite complex to implement for merchants, not to mention all the other actors (banks, payment processors, etc.). It also required new usernames to be assigned, certificates to be distributed, and setup on the user's computer.

A variant of SET called C-SET was mooted in France in 1997, which used a card reader and the users chip card (all Visa and Mastercard cards in France have had a chip since the 80s). This was supposed to simplify things for users and banks, re-using the cards already in the hands of the users.

There were initially two variants of C-SET, Cyber-card and e-Comm, each supported by different banks and other actors, which delayed development and deployment. They then merged into a single one, Cybercomm (!), but it came live only in 2000, and by that time, SET was already considered dead.

Cybercomm readers were sold, not given. There were (at least initially) two different readers, one using USB and the other a serial port. They apparently only sold a few thousand readers while only 27 merchants implemented it. Cybercomm was shut down in 2002.

I could not find anything saying it didn't work or there were any issues. It's just that it failed to reach critical mass.

There was a pilot to use smart cards and readers with SET in the US, driven by MasterCard, in 1998. Couldn't find any details about the reader, but again, the reader is just a small part of the overall SET complex ecosystem on all sides.

So both SET et and C-SET were all too complex, and never gained any significant traction.

SET was replaced by 3D Secure at the start of the century, and in most cases 3D Secure does not use cards or card readers (though the architecture does not care: it's up to the card issuer to decide how transactions are authenticated/authorized -- this has in most cases evolved from passwords to SMS to apps, but nothing prevents a bank from using OTP, chip cards, or whatever they like.

Note that many banks have used chip cards and readers to provide OTP for authentication (login to online banking) or authorization (confirm a bank transfer for instance), but in most cases those were stand-alone card readers, which just gave a pin to type into the browser rather than be directly connected to the computer to provide crypto-level security), and often a separate dedicated card rather than the user's existing payment card.

On the business side of things, there have been applications using smart cards or other secure tokens and readers, but that remained quite complex.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .