Communication between a SmartCard and a SodaMachine
This document describes the communication protocol between a smart card and
a soda machine.
List of keys:
| Km | Issued by bank, common to all soda machines and all smart cards. |
| Ksc | The unique shared key between the bank and a smart card. |
| Kasc | Issued by bank, common to all smart cards, not known by soda machines. |
| Ksm | The unique shared key between the bank and a soda machine. |
| Kasm | Issued by bank, common to all soda machines, not known by smart cards. |
| Kses | Session key for communication between a smart card and a soda machine |
Each smart card has a unique id IDsc stored in plain text on the smart card. It also has IDsc' on it; IDsc' is { IDsc }Kasm, since the smart card does not know the key, it cannot decrypt IDsc'. This can be viewed as the digital signature of the smart card verified by the certifying authority, the bank. Similarly each soda machines has a unique id IDsm stored in plain text on it. It also has IDsm' on it, IDsm' is { IDsm }Kasc. This again cannot be decrypted by the soda machine, and is the digital signature of the soda machine signed by the bank.
Now the protocol between the smart card and the soda machine proceeds in the
following manner: The protocol has two phases - Phase 1 and Phase 2. In Phase 1,
the smart card and the soda machine establish a session key. In Phase 2, they
use this session key to complete the transaction between them.
(In the following explanation SC stands for smart card and SM stands for soda
machine)
Phase 1:
| Steps | Explanation |
| SC -> SM : IDsm, { Na }Km | Smart card sends its ID and a nonce encrypted by the key Km to the soda machine |
| SM -> SC : { Kses, Na, Nb }Km | Soda machine replies with the nonce and another nonce, alongwith a session key it generates, everything encrypted by the shared key |
| SC -> SM : { Nb } Km | Smart card sends back the nonce to soda machine, from this point onwards both of them agree to use the session key for future communication i.e. in Phase 2 |
Phase 2:
| Steps | Explanation |
| SM -> SC : { IDsm, IDsm', Na }Kses | Soda machine sends its ID in plain text and its digital signature alongwith a nonce to the smart card, everything encrypted by the session key established in Phase 1 |
| SC -> SM : { IDsc, IDsc', B1, B2, Na, Nb }Kses | Smart card verifies the signature of the soda machine, then sends its own ID and signature, together with the plain text balance, and its encrypted form. It also sends back the nonce sent by soda machine. It generates a second nonce and sends it to the soda machine, everything is encrypted by the session key |
| At this point the soda machine verifies the signature of the smart card, verifies that B1 and B2 are okay, verifies that the smart card has sent the correct nonce. Then it displays the balance and waits for the user to chose a soda. After the user selects a soda, the following is done | |
| SM -> SC : { B1', B2', Logsm, Nb, Nc }Kses | Soda machine computes the new
balance B1', and its encrypted
form B2', sends the log of the
transaction encrypted by its
shared key with the bank, sends
back the nonce generated by the
smart card, and sends a new
nonce, everything is encrypted by
the session key.
The log is of the following form:
|
| At this point, the smart card checks if the nonce Nb sent by the soda machine is correct. It computes its own log from the difference in B1 and B1'. It commits B1', B2' and Logsm. | |
| SC -> SM : { commit, Logsc, Nc }Kses |
The smart card commits the above log,
it then generates its own log by
looking at the difference of B1 and
B1', and sends that encrypted by its
shared key with the bank, along with
the nonce sent by the smart card.
Everything is encrypted by the session
key.
The log is of the following form:
|
| At this point the soda machine checks if the nonce sent by the smart card is the correct one. Then it commits Logsc on its memory and dispenses the soda to the user. | |
Security Analysis:
Soda machine lies about its ID - This is not possible as the soda machine has to send its ID in plain text and also in an encrypted manner (the digital signature) that only the smart cards (and the bank) can decrypt. So, if the smart card finds there is a mismatch between these two forms of the soda machine's ID, it stops the protocol. Note however, the entire message will be encrypted by the session key.
Smart card lies about its ID - This again is not possible because the smart card has to send its ID in plain text and the digital signature of the same to the soda machine, and the soda machine makes sure that the two match. Note however, the entire message will be encrypted by the session key.
Smart card arbitrarily changes its balance - The smart card can arbitrarily change its balance, but won't be able to compute the encrypted form of the balance, and hence will be rendered useless at any soda machine. At the end of the month this can be caught at the bank.
Soda machine gives a bogus encrypted form of the balance - The smart card does not know what the encrypted form should be. So it innocently writes on its memory. Now, the plain text balance and the encrypted balance will not match and hence the smart card cannot be used at any other soda machine. This will be a DoS attack on the smart card. But when the user will go to the bank, the bank will be able to find out from the log which soda machine has acted maliciously.
Smart card changes amounts of transactions - The transaction log on the smart card has some plain text part, and some encrypted part which can only be decrypted by the bank and the soda machine which made this transaction, and these two parts must match. The smart card can change both the plain text and the encrypted text but he cannot match the encrypted text to be the encryption of the plain text. Hence it will be caught at the bank.
Soda machine changes amounts of transaction - The transaction log on the soda machine has some plain text part, and some encrypted part which can be decrypted by the bank and the smart card which made this transaction, these two parts must match. Similart to the previous scenario, if the soda machine changes the log then the discrepancy can be caught by the bank.
Replay attacks - Cryptyc proof shows that replay attacks are not possible.
Impersonation attacks - Neither any smart card nor any soda machine can impersonate any other smart card or soda machine respectively because of the use of digital signatures in our communication protocol.
While writing the transaction log on itself the smart card changes the ID of the soda machine - The bank will not be able to read the encrypted log entry. But then the bank will be able to read the correct log entry from the soda machine's log and hence the smart card will be caught.
Soda machine changes the ID of the smart card in the transaction log - In a similar manner as the previous case the bank will catch the soda machine.
Smart card and soda machine collude to do the previous two attacks simultaneously - The bank might not be able to catch them, but this way the malicious agents cannot create money. This is because if the smart card is used to get soda but the log is never updated then the smart card is supposedly getting sodas for free, however, the soda machine also does not report these transactions and hence it does not get paid for these transactions, thus loosing money. So the net gain of the attacker ( here the person colluding the soda machine and the smart card ) is zero. So we consider this to be an invalid threat scenario.
Attacks involving interruption of communication - If the last message of Phase 2 is lost then the user will not get a soda. The smart card will have entry for that particular transaction whereas the soda machine will not have any entry for that transaction and hence the smart card will get refunded at the end of the month (as per the project specifications). If any message of Phase 2 (including the last message) gets lost then the protocol times out and Phase 1 restarts. The protocol also times out (and restarts) if any message of Phase 1 is lost.
Smart card remembers the first B1 and B2 (as written by the bank) -
When the smart card gets an updated balance, B1 ( and the corresponding
encrypted balance, B2 ) from the bank ( when the user deposits money ) it can simply
remember this B1 and B2 and use it for all further communication with any soda
machine. The smart card simply ignores any update to these values that are sent
by a soda machine.
We have not been able to find a solution to this attack. However, if we assume
that only bank authorised software is allowed on the smart card then this is not
a valid threat.