Implementing Ticketing
If you can rely on both the mobile phone and the bus ticket machine having a good Internet connection at all times, it's simple enough for the ticket just to be a random number. The ticket machine validates it by querying the bus company's servers; every random number actually issued will be a key into a database, the rest of the record indicating the journey details or "already spent".
The difficulty is that you cannot rely on an Internet connection at the time of boarding -- but you equally cannot rely on the contents of the mobile phone being secure. So you have to assume that the ticket is susceptible to cloning. As long as the ticket is booked for a specific date, though, the risks are somewhat mitigated. And the thing you really want to guard against, is giving away the instructions to create any valid ticket from scratch. That's the real keys to the kingdom.
Now, there has to be an Internet connection from the phone at the time of payment; so it would be entirely possible to receive a secret token at that time. And we can assume there is a way to transfer data to and from the bus ticket machines at the bus depôt. What I would do is send all the relevant data -- time of validity, route, boarding stage, fare and so forth; i.e., all the stuff you would need to know to produce a bus ticket -- to the bus company's servers along with the payment request; and if payment is successful, I get a hash computed from all that information plus some secret, which is shared -- under the bus company's control -- by a separate channel with the ticket machines on buses. (It can be stored in RAM and erased in the event of tampering; only a bus driver can reset it). The actual ticket contains the "cleartext" and the hash which can only possibly have been calculated by the bus company, since nobody else knows the pre-shared secret.
The mobile phone just has to send the hash and the cleartext to the ticket machine somehow (over NFC, or by displaying something optically readable like a QR code). The ticket machine recalculates the hash by combining the cleartext with its own copy of the key, and indicates acceptance or otherwise.
A hacker cannot make a ticket from scratch without knowing the bus company's secret which is used to create the hash. The only places that secret is kept are the ticket machines -- which you have to assume have some physical security measures in place -- and the bus company's servers. The most you can do is clone another valid ticket. There are some measures that the bus company can take to guard against this: a ticket machine that has already seen a ticket before can refuse to accept it again, so a whole group of people can't all travel at the same time for just one person's fare. And at the end of each day, if an impossible situation is noticed (such as the same ticket being used to board two buses going in different directions, from different stops, at such times as there was no way for someone to have got off the first bus in time to catch the second) the ticket serial numbers involved can be flagged up. There isn't much you can do about ordinary one-way and return tickets being cloned, but multiple copies of a weekly or season ticket are easily spotted. Out of n tickets, at least n-1 must be forged; and the owner of the nth one is probably in on the scam.
It might well be possible, by means of a distributed effort, to determine the format of the cleartext portion of the ticket. But the intrinsic many-to-one mapping of a hash function makes it computationally expensive to brute-force the secret needed to calculate the hash.
That's just off the top of my head. I'm sure there are problems I have not thought of, and look forward to the opportunity to learn where I went wrong.
Biting the hand that feeds IT
