rugk
commented
11 months ago Well… if we ask for security we first would have to ask for a threat model… What's yours?
I propose one here…
treat model
Anyone intercepting/MITM the connection? I guess? The situation could be scanning a password from your desktop with your phone.
Threats are many:
- compromised devices/apps etc. (note your app on your phone to scan it etc.)
- interception in between
- etc.
We focus on the interception part.
current solution
IMHO the current solution is already quite robust, as “intercepting” currently would require:
- physical presence (as long as your devices are not compromised, but we did not want to consider this), where someone could scan the code (as the data is not sent anywhere)
- exact timing as you probably would close that QR code soon (however, a photo of it taken at the wrong moment would be enough) or the lightning etc. changes, so the code cannot be scanned anymore by the attacker
- possibly be noticable as you may see when someone it behind you
All in all, practically, I only see should surfing as a practical attack. While photos may be possible to expand the time for an attack, it's likely also easy enough to scan the QR code instantly instead.
Note if you are being shoulder-surfed, possibly much more data is already compromised, as you are likely being watched for longer and people may see entering your password etc.
Proposed solution
Some asymmetric(?) encryption.
However:
- Note: Simply passing private and public keys is quite useless. If our shoulder surfer can intercept the private key, they can also easily decode the. And it is likely that they can intercept both…
- Thus a diffie hellman exchange or something similar would need to be implemented.
Effects
- It would make a passive shoulder surfing attack an active MITM attack. Yes. Like, you need to intercept the QR code somehow and possibly prevent a forged QR code to MITM e.g. a diffie hellman exchange. The reason is DH is vulnerable to MITM attacks. However, I see that this is likely hard for QR codes, as in our treat model you likely can only scan your "real" QR code due to the physical distance involved.
Thus, this could indeed be effective.
Implementation effort
Here comes the catch: Huuuge. Especially to do properly. E.g. one big challenge is a diffie hellman exchange would require your phone communicating back to your laptop. Bidirectional communication is, however, not really a feature of QR codes. :wink: (Also said DH key exchange has big key lengths, but this could be solved by using elliptic curves aka ECDH instead.)
However, the worst thing may be a practical one: Both clients need to support it. If this add-on supports it, that is not enough. The app (in our example) also needs to do so.
Summary
All in all, this is less benefit with much work. And without a proper way to do it (cryptography always goes wrong and without being a cryptographer you ought not even to try to implement low-level stuff.), it will likely fail. Thus, I don't see that as a feature soon or in the near future.
Alternatives
- maybe saving asymmetric keys for longer on both clients: impractical, needs key management (yet more work), what happens on compromise?
- symmetric encryption: way easier to implement, but still suffers from the "both clients support" problem. Also you can use plenty of tools for that already and just then paste your encrypted data into the QR code generator.
oneofthehorses
Hi!
It would be awesome feature to create something like "encrypted channel where devices first say hello to each other (wich means exchange of public keys) and then you can send\recive information by secure channel throught QR-code's
Thanks for your works!!!