Secure Mobile Transactions

In our third use case, we show how to use the TLR to perform secure transactions. Specif- ically, we want to enable customers to perform payments at point of sale (POS) terminals by simply waving the smartphone in front of the POS. A POS could be deployed in var- ious contexts: retail shopping, vending machines, toll booths, parking meters, etc. The mobile device keeps track of the customer’s credit card details, and engages in a payment protocol with the POS over wireless communication (e.g., NFC). No physical currency like credit card, debit card, or cash would be required. The role of the TLR is then to provide for the security of both (i) the credit card information stored on the phone, and (ii) the payment protocols executed between the device and a POS.

Figure 8.3 illustrates a possible mobile payment scenario involving three actors: the bank, which issues credit card information, the mobile payment trustlet, which keeps track of the credit card details, and the vending terminal (VT), i.e., a POS.

These actors engage in three protocols. The Setup protocol takes place between the bank and the trustlet, and ships the credit card information securely onto the phone. The Pay protocol occurs between the trustlet and a VT during a payment transaction. Lastly, the Commit protocol takes place between a VT and the bank (possibly at a

deferred point in time) in order to credit the payment amount into the vendor’s account. We now explain these protocols in detail.

One way to look at the requirements of the protocols is from the VT’s perspective. The VT must guarantee that the credit card information contained in the customer’s device is valid, and then generate a transaction record that proves to the bank that the payment was performed. To avoid leaking credit card details, the VT tells the mobile payment trustlet to endorse the credit card information and produce a transaction record. (This approach is similar to what is done in the mobile ticketing use case.) The VT then checks the authenticity of the trustlet based on a signature (σKTin message 3 of the Pay

protocol). This signature is issued by the trustlet with a private key KT certified by the bank (certificate certB(KT )) and enclosed in an envelope sealed to the mobile payment trustlet. The trustlet only issues the signature after receiving the payment details from the VT (payment amount and current date) and validating the credit card expiration date. This signature is sent along with certB(KT ) in message 3 to VT. By validating the signature against the certificate, the VT can check the authenticity of the trustlet. Message 3 serves as a transaction record that can be forwarded to the bank. (To prevent replay attacks, a nonce nv sent by VT to the device must be included in the signature.)

From the customers’ perspective, it is important to prevent the impersonation of legitimate terminals. To authenticate a VT, the trustlet verifies whether the VT owns a private key that has been certified by a trusted VT manufacturer. To enable this, the bank includes in the sealed envelope certificates of trusted VT manufacturers (field

certM(VT ) of the Setup protocol). Then, in the Pay protocol, the trustlet does not issue a payment signature unless it receives an authentication proof from the terminal. Such a proof consists of issuing a signature σVT(with the VT private key) of a trustlet chosen

nonce nd. The VT sends the signature and its certificate certM(VT ) so that the trustlet can validate them against the certificates of trusted VT manufacturers.

From the customers’ perspective, in addition to making sure the terminal is trusted, we must prevent accidental or abusive payments in trusted terminals (e.g., duplicate payments). For this reason, customers must authorize the payments by typing a PIN, which must be validated by the trustlet before authorizing the payment. Since the I/O path between the mobile device’s UI and the trustlet can be intercepted by a possibly compromised OS, the PIN must be typed in the VT. The VT hashes the PIN along with nonce nd and payment amount, and sends the result to the trustlet as authorization

proof. Sending this hash value (i) prevents the PIN from being sent as clear text, and (ii) binds the PIN to that particular transaction, thereby preventing replay attacks. The trustlet validates the authorization proof by recreating the hash and comparing them. To recreate the hash, the trustlet finds the PIN enclosed in the sealed envelope sent by the bank. The PIN is chosen by the customer and conveyed to the banking services before the Setup protocol takes place. To modify the PIN, a new sealed envelope must be generated and sent to the device, an operation that could be done on the bank’s website.

To implement these protocols, the mobile payment trustlet implements three meth- ods: SetupCCInfo, InitPayment, and Pay. The first takes the sealed envelope (i.e., the contents of message 1 of the Setup protocol), unseals it, and keeps the resulting objects

8.4 Use Cases

Application Model Trustlet Interface

public IHealthTrustlet : IEntrypoint { bool SetupRecords(SealedRecords recs); Nonce InitQuery();

Recs QueryRecs(RecQuery query); }

Protocols

Deploy: 1. HA→Device: seal([[R0, . . . , Rn], ACPol, KT, certHA(KT )], Tlet , Dev )

Query: 1. Device→HP: nd

2. HP→Device: [RIDk ], nh, {nd}KH, certHA(KH )

3. Device→HP: ["Ri. . .Rj#K, {K, nh}KT, certHA(KT )] | fail Table 8.4: Use Case 4: E-health application.

in memory. The second method just returns nonce nd. The third method takes the

validation arguments contained in message 2 of the Pay protocol, and either returns the transaction record or aborts if validation fails.