search

huitema / pairing

Description of the simple pairing protocol
0 stars 1 forks source link

Users might press OK without actually looking at the SAS #1

Open huitema opened 6 years ago

huitema commented 6 years ago

I have been reviewing the DNS-SD privacy issues in light of Stuart's draft (draft-cheshire-dnssd-privacy-considerations-01) and his presentation at IETF 100 (https://datatracker.ietf.org/meeting/100/materials/slides-100-dnssd-04-stuart-privacy/). Draft and presentation reflect uneasiness with several of the design choices that we made in draft-ietf-dnssd-privacy-03, draft-ietf-dnssd-pairing-03, and draft-ietf-dnssd-pairing-info-00. One of these issues is the type of pairing agreement.

The pairing agreement proposed in draft-ietf-dnssd-pairing-03 relies on a final authentication step, in which a "short authentication string" is verified. The problem there is not the correctness of the protocol, but the weakness of the human user. Pairing processes can be long and convoluted. After the user has finally mastered the UI on two devices and gone through all the process, it is very tempting to press the "OK" button without looking too closely to the strings on the displays. Designs that require to enter a PIN or a password before proceeding with the pairing do not have that weakness, and technology exist that make them secure.

huitema commented 6 years ago

The proposed alternative is to require that the client enters a server-provided PIN before performing the pairing protocol, and to let the protocol machine make all the decisions after that. This kind of user interaction would be a good match for the "QR code" variant: read the PIN and the server name from the QR code displayed by the server, and execute the pairing protocol.

Note that this UI variant was rejected in the "info" draft for two reasons:

1- Experience shows that some servers don't care about security all that much, and take shortcuts such as static pins with value "0001".

2- Experience also shows that users do not like to read and copy numbers.

The QR code variation would be a mitigation of issue #2.

huitema commented 6 years ago

PIN based protocols require robust PIN exchange algorithm. Simple challenge/response algorithms don't work, because MITM can quickly enumerate and try all PIN values. The protocol needs to incorporate a "Password-authenticated key agreement" (PAKE) algorithm.

kaiserd commented 6 years ago

TL;DR

Longer Version:

The SAS pairing method we describe in our draft is subdivided into three phases:

Only the manual authentication phase influences the UI; it is independent of the other two phases. The manual authentication again can be subdivided into SAS representation --- e.g. representing the SAS as alphanumeric string, as a QR code, or as something more exotic --- and the SAS verification method. In our draft, we describe the compare & confirm verification method on a alphanumeric SAS representation. The compare & confirm method is indeed "cheatable" by the users of the pairing devices but has proven to be the most comfortable one. We can, however, use a copy & enter verification method, which demands the users to read the SAS representation from one device and enter it into the second device. This would result in the same UI that a J-PAKE based protocol would use.

Comparison

Both methods, ours and J-PAKE, offer secure device pairing. Both do not depend on a short PIN that is instrumental in the key generation.

Among the advantages over the respective other protocol family are (I might add more later...):

Manual SAS Authentication Methods

PAKE Methods

Discussion

From a UI point of view, both methods can offer the copy & enter method. We do not need to switch to PAKE for offering this. However, only the SAS method offers the more convenient methods, among them QR codes (unless the App manages the PAKE passwords).

Further, as a pairing method in the DNS-SD/mDNS area, manual SAS authentication methods are better suited because they are not dependent on a pre-existing password. Using J-PAKE for the pairing of two smart phones, the users of these two devices need a pre-existing password. This poses a new question: How do these users agree on a password. The sociallist millionaires protocol could be used to this end, but it is less convenient for users than verifying an SAS.

While PAKE achieves authenticity using a pre-existing password, Manual Authentication achieves authenticity by a "personal meeting". For the DNS-SD/mDNS area, where devices are assumed be be relatively close to each other, the "personal meeting" poses way less overhad than the need for pre-existing passwords.

Additional: Fixed PIN

Devices that do not feature a display and come with a fixed PIN allow only for a lower level of privacy because each device pairing with that device uses the same PIN. We should treat the case of a fixed PIN separately.

Regarding (fixed) PIN based protocols, it is important that the PIN is not instrumental in the key generation and just serves authentication purposes. PAKE protocols fulfill that, but they do not offer an authenticated PIN exchange; the PIN (password) is expected to already be known to the pairing parties.

Questions