Opus En Ligne

( Last edited on 11/25/2016. )

On the Island Of Montreal, bus and subway fares have been handled for many years via a contact-less smart-card, called our “Opus Card”. Most residents “recharge” their fares at designated commercial establishments, but those so inclined may instead buy a USB-connected reader for this card, which also has contacts, which the privately-used readers use to recharge them.

I am one passenger, who chooses to pay their fares this way at home, by plugging the USB-cable of the card-reader into my remaining Windows 7 computer named ‘Mithral’, and by going to a Web-site, where we can provide payment information.

Until last month, the way in which this system worked was:

  • We install a device-driver for the actual card reader – which is chosen for us by the designated site.
  • We kept our Java installation up-to-date.
  • The site charges our payment method, validated on their side.
  • The Web-site deployed and launched a Java application with each use, that connected to the card reader and wrote changes to the data on the card.

At least in theory it was possible to say, that this system was based on an open standard, that being Java.

But as of this month, the transit authority has switched to a different system. We still need the actual USB driver for the card reader. But now we must also download what they call their ‘SmartCardPlugin’, which is given to us from the site as an .MSI File in the case of Windows users. This plug-in actually forms the bridge, between their Web-application and the recognized card reader.

While this system seems to work quite well, based on my first use today, I would say it represents bad programming aesthetics. Even though the actual software-components were provided by Xerox, this system does not install a PKCS#11 security device, nor anything approaching a CAC card reader, with PKI. Instead, this service is based on an .EXE File, and leaves its hook in our browser, which in the case of Firefox, we can find under Tools -> Options -> Applications.

What this means is that the site will display an Web-object, that needs to be ‘opened’ by a specific application, associated by the Web-browser.

The most positive aspect to how this works seems to be, that indeed, it provides compatibility with Firefox, Chrome, IE etc..

But instead of providing strong security, this method is only as secure as the SSL connection to the site.

It may be interesting to note, that even when this system was based on Java, none of the officials ever promised that it would work under Linux, so I see no loss there.

Some users have complained, in that this system fails to meet their expectations, in one day combining the payment service as a smart-phone, NFC service. I have to concur with this hope. I also find it a bit clumsy right now, to have to plug in my Opus Card into a USB port, and to open a site which asks me for my payment credentials – ‘the old-fashioned way’.

But OTOH, I do not see much of a practical loss, compared with how it used to work. And one reason the officials may be doing it this way, could be a negative prognosis for the future of Java itself.

It just so happens that I prefer proven standards.


(Edit 11/24/2016 : ) There is no specific reason to assume, that an .EXE File under Windows is somehow incapable. It would be capable of doing anything which an application could generally do, including to encrypt content, to validate digital signatures, etc. As to whether specifically this .EXE File is complicated in how it communicates with its Web-site, I do not know.

I do know that it possesses an associated .DLL File, which exists because it is standard practice in programming, to link only the most essential object-code into the actual executable, and to link most of the code which does the work – i.e. most of the subroutines – into one shared library for that application. Linux does this just as Windows does, and does not even list this library, which is usually assumed to exist, as a package dependency, only as one component of a package.

I suppose that one way in which Linux differs from Windows however, is that under Linux, even these specific shared libraries – .SO Files – are located in a special directory for them, while under Windows, they are often placed in the same folder as the one which contains the executable.

It is important to note however, that the way most browser plug-ins are coded and linked, also results in a shared library, which does not assume the same purpose the DLL assumes, in the example this post is writing about. In this example, it is an opaque EXE File that makes up the plug-in.

(Edit 11/25/2016 : ) There do exist chip-cards, which have PKI features (Public-Key Infrastructure). Those can be used to achieve a kind of log-in into a Web-site, which would otherwise be provided by the browser as a certificate-based log-in…

But in order for the chip-card to provide that, its CPU must be strong enough, to perform a one-time decryption of a message using a private key, which was encrypted using the public key. This message could be a one-session, symmetrical key, or a challenge for the client to prove ownership of the key-pair.

In order for such a chip-card to provide real security, it must be programmed so as never to give out its private key, but to give out its public certificate. This is also why such a chip-card can be registered with the browser, or with other software, as a Cryptographic Security Device, aka a PKCS#11 object. Only the public key would ever be stored in the browser, or the software.

Because Montreal introduced its Opus Card around the year 2008, I have to assume that the CPU on these cards would not be strong enough, to provide that type of encryption. Also, they are not meant to provide secure access to a Domain, but rather to restrict unauthorized additions to their fares list.

And so the maximum the Opus card can be expected to do, is to verify a signature from the authority, which confirms that the fares can be added. This might only require storing the public key on the card, or storing that in the software on the PC, which accesses the card.

Needless to say, storing the keys on the card and only accessing them with its CPU, would be more secure, than to store them on the PC, since there might always be users willing to try to hack the software on their PC. Relying on SSL to provide all the security has as main drawback, that the user can modify the browser, and thus access unencrypted data on the client-side, since SSL is not encrypted at the end-points.

But then again, only storing the public key on the PC is not so weak, because even if the user tries to hack that, he will only gain knowledge of the public key, and will still not be able to derive what the private key is, needed to sign a fares addition, using the correct software.


I should offer, that there exist computationally-simpler methods to establish a ‘shared secret’ between two end-points, than RSA per se.

For example, the client could have a long-term secret set of digits stored which the server also knows, and could receive a variable set of digits, that can be considered compromised and publicly visible. This variable set of digits could also be ‘the fare to add’.

The secret digits can simply be appended to the variable digits, and the result hashed. The resulting hash can be the new, per-session shared secret, used to encrypt a connection. Or alternatively, the resulting hash could be the signature.

Because the long-term, secret digits are never communicated, if the hash-codes match, it can be inferred that the same digits were appended to the publicly-known set of digits.

Or, if the hash-code is never communicated either, because a certain constant subset of the digits was secret, this hash-code can also be assumed secret, and used to encrypt a connection.



Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>