├── LICENSE └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | Copyright 2018 WebPKI.org 2 | 3 | Licensed under the Apache License, Version 2.0 (the "License"); 4 | you may not use this file except in compliance with the License. 5 | You may obtain a copy of the License at 6 | 7 | http://www.apache.org/licenses/LICENSE-2.0 8 | 9 | Unless required by applicable law or agreed to in writing, software 10 | distributed under the License is distributed on an "AS IS" BASIS, 11 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | See the License for the specific language governing permissions and 13 | limitations under the License. 14 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # “A Better QR” 2 | ![betterqr](https://cloud.githubusercontent.com/assets/8044211/26782217/c320c982-49f2-11e7-90ac-348677374ba3.png) 3 | 4 | ## Background 5 | Using QR codes on the Web together with mobile phones acting as _Identity Tokens_ or _Wallets_ has been a huge success. 6 | 7 | There is essentially only one but rather obvious snag; you need to start a specific QR- or QR-enabled application in order to use such a system. 8 | 9 | However, if you scratch a bit under the surface of these systems you will find that they suffer from a fairly ugly security flaw as well: _There is no secure binding between the page showing the QR-code and the QR-code itself_. This fact has been successfully exploited by criminals who with simple phishing scams have lured people logging in to their bank for "Important Information" giving the phisher access to the account rather than the user. There is currently no publicly documented workaround for this vulnerability. 10 | 11 | Some systems only use a short identifier rather than a QR-code making them susceptible to "Social Engineering" scams over the phone as well. 12 | 13 | Note: even the most advanced systems out there using _Security Elements_ and _Asymmetric Key Cryptography_ exhibit these problems. 14 | 15 | This is how most QR based schemes work today: 16 | 17 | 1. The user wants to login or have reached a Web page asking for a payment. Note: using a **_PC_** 18 | 2. The service offers a (preferably one-time) QR code in a Web page 19 | 3. The user starts a QR enabled application. Note: using a **_Phone_** 20 | 4. The application scans the QR code aided by the user doing the focusing 21 | 5. The QR enabled application performs the authentication or transaction using OOB (Out Of Band) communication based on the read QR data 22 | 23 | ## Proposal 24 | This repository contains a proposal for a _Dedicated_, _Write-only_ Web-invoked NFC system intended as a replacement for inconvenient and security-broken QR schemes. The primary applications are authentication and payments. 25 | 26 | ## NFC in PCs 27 | It is correct that _integrated NFC support_ in PCs is quite uncommon. OTOH, why would vendors maintain support for NFC if it doesn't have any important task to perform? Unfortunately NFC has in spite of nice characteristics, gotten serious competition from QR even for payments in physical shops. 28 | 29 | ## Possible "Side Effects" 30 | Although uniting payment protocols is not a part of this proposal, 31 | it is related since the idea is that somewhere down the line, it should be 32 | possible using the same payment protocols in physical shops as on-line. 33 | NFC would in such a use case only be used to setup the 34 | communication channel while the actual payment protocol would use HTTP or WebSocket. 35 | 36 | ![united](https://user-images.githubusercontent.com/8044211/42658603-1bf6c870-8626-11e8-95b5-a6d7cc444f4c.png) 37 | In such a setup there is _no need for a traditional payment terminal since the entire client side of the 38 | UI and security is catered for by the mobile device_. 39 | 40 | The [Saturn](https://cyberphone.github.io/doc/saturn/) payment authorization scheme is designed to take advantage of such a possibility. 41 | 42 | ## Architectural Overview 43 | https://cyberphone.github.io/doc/research/nfc-based-qr-replacement2.pdf 44 | 45 | Note: this proposal outlines a pure _Security Protocol_ which means that it presumes that the software running in Servers, PCs and Phones is operating correctly. 46 | 47 | ## Attack Vectors and their Mitigation 48 | The following analysis may indeed be incorrect. This is why I have requested a security review 😀. 49 | 50 | Note: https to a (by the browser) trusted site is a prerequisite for enabling the NFC API. 51 | 52 | ### Intercepting NFC 53 | Intercepting NFC over quite long distances has been reported as feasible. 54 | However, the only thing it buys you is stealing the user's login attempt, not the login itself. 55 | 56 | ### Phishing 57 | The user clicks on a Web link received in an email or chat, or is encountered on a Web site. 58 | The link opens a malicious Web site like `https://yourbank.business.f6s4f.com` typically masquerading as a bank or similar. 59 | The user is encouraged logging in. Before responding to the user with an NFC-using Web page, 60 | the malicious site calls the target site in order to start a session of its own. 61 | Then the malicious site returns a Web page for the user calling NFC with the received data. 62 | Unfortunately (for the attacker) the NFC driver will not produce any output since the Web page displayed to the 63 | user has another host than the target site. See step \#4 in the [architectural overview](#architectural-overview). 64 | 65 | If a malicious site rather tries to _reuse_ an authentic login to itself at another site, the check performed at \#10.1 66 | in the [architectural overview](#architectural-overview) should thwart such efforts even if the session information is correct. 67 | 68 | ### Social Engineering Scams 69 | There is (AFAICT) no way a person calling you on the phone, asking you to login somewhere, 70 | could take or reuse that login. 71 | 72 | ### Unresolved: Dynamic NFC Data R/W 73 | The most sophisticated attack I have come up with so far requires the attacker to: 74 | 1. Create a session with the target site 75 | 2. Intercept and rewrite NFC RF data (see step \#7 in the [architectural overview](#architectural-overview)), 76 | on the fly by replacing the user's URL with the attacker's URL 77 | 78 | There doesn't seem to be any real mitigation to this attack. OTOH, it seems quite 79 | complex to succeed with, requiring special radio equipment 80 | presumably mounted on the PC itself. If we are talking public computers, hacking the browser would 81 | be a much more workable solution since it defeats pretty much all security solutions! 82 | 83 | ## Security Considerations 84 | This proposal depends on an updated browser API which means that possible 85 | side-effects with respect to security and privacy must be considered. 86 | AFAICT, the system does not introduce issues beyond what QR already do, 87 | but _it might be useful disabling the NFC API on hidden pages_. 88 | 89 | One could imagine having a special HTML object but I believe this would 90 | be overkill; it should suffice that the NFC-using page features an 91 | icon. 92 | 93 | A component that does require specific security measures is the mobile device. 94 | However, these are application specific. For an authentication scheme like 95 | shown in the [architectural overview](#architectural-overview), an alert message `"this is your first login to 'xyz.com', do you want to continue"` 96 | seems appropriate. 97 | --------------------------------------------------------------------------------