First off, I've been writing software for 30 years. While I've studied a lot about security methods and encryption, I would never consider myself an expert. I would consider myself "suitably skilled in the art."
It makes more sense to me to use a NFC connection to have the two devices identify each other. The user verifies on their device where they are (Joe's Coffee Shack on W. 3rd St). Your device then contacts the payment servers over the data network (or text message in a pinch) as does their device. Both devices have created a shared secret that they have each encrypted with their own key. Payment server verifies with each public key that it has that the secret agrees as does the charge amount. User's device is contacted again and once the user verifies the transaction it goes through and the merchant's system is notified.
Protecting the payment system from the app path is ludicrous. If it is run in the same system as the OS and the app environment, it is not safe and cannot be made so. Instead make it harder by doing essentially the same thing as the baseband modem (but don't even think of running it there or as a uJava app on the SIM because they are insecure as hell). Instead you place a 3rd independent ASIC that is the payment processor. It would only communicate over specific and protected channels with the OS and the baseband modem. That again would be impossible to make 100% secure, but it would definitely raise the difficulty level significantly.
The other point that is insane is to trust their Bluetooth or WiFi as the second channel. Can we please move to making banking more secure, not less?
And as for obvious. The above scenario is me thinking about how I would design a secure payment system for roughly 2 minutes after only reading the first two paragraphs in the article and not looking at the patent. Please don't nit-pick it because I know I've probably missed things here and there. So with that in mind back to the article.
SIM card?!? Are you ****ing kidding me. Secure? Not hardly. That was pretty well dispelled at DefCon 21.
Now to the patent. Ah, sure. I knew no one would specify Bluetooth or WiFi in a patent. You don't fence off things with specificity anymore. You fence off the whole continent as in "a second air interface different from the first air interface includes identifying an air interface having properties more desirable than the first air interface for communication of data to a user over a time period longer than the time used to establish the first secure link."
Shared secret, check. Not sure that I agree with the shared secret being the encryption key. Maybe if each device signed the message first with their own key before encrypting with the shared secret. That sounds like they really mean Diffie-Hellman and that means you end up with a key weaker than the keys used to create it. Again, we don't know the real implementation. This is modern patent law so be as broad and cryptic as you can.
I'm sure within 5 years we'll hear about this patent being granted. Pretty well shouldn't as it is overly broad and obvious. They really haven't added anything new to the game.
As for my idea. I would never implement it myself. I'd definitely want a team of experts in security to go over it and improve it. As well as have the code and any hardware peer reviewed. That would never happen. Once the big players get involved everything gets watered down and made easier and you get the least common denominator solution. Fraud is considered just a cost of business to the banks, they charge it back to the customers however they can.
I never get tired watching DefCon or C3 presentations where developers or engineers have decided to role their own security or encryption solution. They're hysterical.
Biting the hand that feeds IT
