- iPhone (let's assume 6 and newer for the sake of this question).
- Raspberry Pi 2.
The Raspberry runs a REST web service which the iPhone queries. The web service uses JSON Web Tokens for authentication and authorization. I am trying to find an as-secure-as-possible way for the iPhone to obtain a JWT from the Raspberry without too much hassle for the user -- but security is of greater importance than ease of use.
The two devices will operate in close proximity of each other, so token exchange over a physically constrained channel seems like a good solution as an attacker must be physically present prior to (e.g. leaving behind a device that can sniff and relay the information using a different channel) or during token exchange.
As the iPhone does not offer developers access to the NFC chip, this is not an option (I've also read elsewhere that it is vulnerable to MITM attacks at a range of up to 10 meters).
Bluetooth Numeric Comparison seems like a possible option as it has been proven secure (at least for v2.1).
Q1: Is this still valid? Can Bluetooth Numeric Comparison be considered secure in Bluetooth 4.x?
Having to pair devices is not ideal though as an iPhone will only interact with the Raspberry for a few days and then be replaced by a new iPhone interacting with the same Raspberry Pi. I would like to avoid having to clean up the Raspberry's list of paired devices daily.
I have been thinking of a custom solution in which I would generate a (secure) random value which would be displayed on a display connected to the Raspberry Pi. This would serve as a shortlived token that the iPhone user would manually input, and the application would send an auth request to the web service using this value. The web service would keep a timer to make sure that the shortlived token could only be exchanged for an actual JWT within a short timeframe (say 5-10 minutes) to prevent brute force attacks. We can assume that a PKI can be used to setup an SSL connection between the Raspberry Pi and the iPhone such that exchanging the short-lived token for a long-lived JWT will be performed in a secure way.
Q2: I know that designing custom security solutions is a horrible idea and should be left to security experts. However, the proposed strategy seems very simple, yet it must be flawed, and I would like to know why it is flawed.