Secure way to transfer data over NFC?

Question

I am currently writing a payment system to accept payment details from an NFC enabled smartphone (BlackBerry 9900) to a Windows client (C#.NET)

I am currently having two issues relating to security:

1. What is a good way to secure the data for transmission over NFC? I'm thinking public key encryption so that it can be encrypted on the phone using the public key and then decrypted by the .NET on the other side using the private key.

2. How to secure the data so that the data can't be cloned by another reader i.e. another reader pretends the be the windows client and reads the secure data. This could then be played back to the windows client by the attacker at a later data to make a payment. I'm thinking that when the phone taps the client reader the client will send a token that must be present in the data returned from the phone that includes the sensitive data. I think that maybe the public and private keys should be created per each transaction request. The public key sent to the phone to encrypt the data. Maybe that would suffice as the token also as if it can't be decrypted by the client then it's an invalid request.

Please note that I have no experience in cryptography at all. I'm aiming to implement a solution that has libraries readily available in .NET 3.0 and BlackBerry SDK 7.0.

Answer 1

There is not much special about near field communication here - it is just like any insecure transport medium, which can be evesdropped on (with external antennas up to several meters in distance).

Because of the low distance limit, there is no way for a man-in-the-middle attack if you (the human operator) are sure that your device is communicating with the right reader, but there is the relaying attack (your blackberry communicates to a reader, which forwards the data to another device which communicates to the real reader), which also might including the replay problem.

I would recommend not to build a new protocol (especially if you are new to cryptography), but to reuse existing, generally known, protocols. In this case, the usual TLS (Transport Layer Security) protocol seems like a good fit, if you can provide your "server" with a private key which is kept secret, and whose corresponding public key could be certified by some certificate agency whose key (or root key of some chain) would be known to the "client".

In the usual way of SSL/TLS operating, client and server negotiate a shared secret, from which the session keys are then derived.

(I suppose it would be easier to let the Blackberry be the client and your windows machine the server, but it would work the other way around, too.)

I don't know anything about Blackberry programming (nor .NET), but I suppose that there are SSL/TLS libraries available for both.

Note that while this avoids replay attacks (the keys are individually creating depending for each session, and won't work later), this doesn't really help against the relaying attack - so make sure to only transmit your payment details to sellers you trust.