Opus En Ligne

( Last edited on 11/25/2016. )




  • We kept our Java installation up-to-date.










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



