RavKav Online

[Micha Bailey]

(in reply to this thread:
http://mailman.cs.huji.ac.il/pipermail/linux-il/2017-March/012522.html )

The reason a physical hardware reader (either an Android phone with NFC or
a USB card reader) is necessary is that Rav Kav is based on the Calypso
standard, and the card is a full microprocessor smart card that carries all
the relevant information (passenger information, contracts, etc.) onboard
the card itself. All transactions (loading/validating) are performed
offline, with communication between the ticketing device and the card. This
is as opposed to some other systems around the world, in which the card
simply carries a static identifier and the ticketing system is based on a
database that can be checked in real time. Here in Israel, while there is a
database, it's not used online - instead it's updated at some later point
with data downloaded from the buses etc. For this reason, for example, if a
card is lost or stolen, there's a three day waiting period before the
balances can be restored to the card. This is because the ticketing devices
on buses are not all equipped for full reliable online connectivity (and in
some cases, any connectivity), and because it's one unified, national card
that needs to work with the different systems used by the different
companies, it's not feasible to upgrade all the systems the way single,
unified transport authorities in e.g. London can.

In terms of the website and the program itself, I did a bit of analysis a
few weeks ago. It uses the system PC/SC APIs, using the javax.smartcardio
library. The code has a list of regexes that it checks, with the different
models of reader that they've distributed/sold since launching the website,
and doesn't use any reader that doesn't match. I don't know why they do
that, but I can confirm that there's no technical reason for it - I
happened to have a different reader on hand (some Athena model that I
received with my Teudat Zehut), and when I edited the regex to match it it
just worked.

I don't know if it's possible for websites to interact with the PC/SC stack
- I'm guessing not - so the way it works is that the browser side opens a
Websocket connection to a server, IIRC wss://proxy.ravkavonline.co.il/<random
UUID here>, and triggers a navigation to the same URL prefixed with the
ravkav: scheme. This launches the client, which establishes a Websocket
connection to the same URL, with the proxy server simply passing any
messages along to the other side of the connection. This connection is used
to send commands from the webapp to the client, and responses, reader
status, etc. from the client back to the webapp. To perform any action with
the card, a command is sent saying essentially "open a session with the
card at this URL". The client connects to the URL and exchanges JSON
messages that appear to carry base64-encoded raw APDUs and responses, which
are relayed as-is between the card and the server (in the case of a simple
"read card" operation, a fixed URL at datamodel.ravkavonline.co.il. In the
case of operations that need to modify the card contents, such as loading a
contract onto the card, once the transaction is approved, the server-side
generates a URL at some other server, presumably one that's connected to a
SAM so it can sign the session with the card). At the end of the session
with the card communication server, the server returns the result (for
example, in the case of a simple dump of the card contents, a JSON document
listing the contracts and history), which is then passed through the proxy
server to the webapp.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20171012/593b9626/attachment-0001.html>