2

Setup:

  • 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.

  • 1
    I'm not a crypto-expert, but it seems semi reasonable to me. I'd suggest using a QR code and a reader on the iPhone - that way the temporary token could be too large to brute force and it'd be easier for the client. – crovers Sep 22 '16 at 18:37
3

Answer to Q2:

You are not really inventing something here as far as I can see. You are using a very simple One-Time-Code generator.

Generate the code locally on the Pi, keep it valid for a constrained amount of time (a few seconds maybe), require it to be entered into the phone and once used invalidate it immediately.

Use the Pi as a local Wi-Fi AP with appropriate security and it should be more than enough for the quick in and out you need. Even if someone gets onto the Wi-Fi, as long as the rest is secured with HTTPS and your OTP, it should be fine.

To save yourself a load of work and avoid the local invention problem, use a standard set of libraries on the Pi. Node.JS with ExpressJS and standard modules such as Passport, Helmet, Lusca or similar can handle the login and app security. A locally generated certificate should be enough for HTTPS.

This seems like a nice simple, standard and reasonably secure approach.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.