QR verfication

[testbird]

This is about the experimental "labs" qr code option available through the advanced settings.

• The QR code seems to be static.
  With a picture of it everyone could get auto-verfied? Maybe add a timestamp plus a random check word to the qr, to be re-shown on the reading client and valid for handshaking messages during the next 24h? (greylisting). So the reading user sees the same checkword displayed after scanning? Maybe even allow the qr-showing user to edit extend the random checkword with an own and/or reader supplied string, before generating and showing the qr? With this, the users could verify that the correct qr is read and used?

• There is hidden communication (not visible to the user) going on in the background.
  This has shown to create security problems when bugs are discovered. It could be another reason to show a check word and require the user of the qr-showing client to actively, one-time-accept the reception of these background message from this sender address. (Allows to see if the correct, same, temporary check word that was shown (possibly even user edited) and included within the qr shows up again in the received background message.)

[r10s]

well, this all is subject to change. meanwhile, NEXTLEAP has released the underlaying protocol, see http://countermitm.readthedocs.io/en/latest/ for details (was also on the Delta Chat mailing list; cave: it's a longer reading) and https://github.com/nextleap-project/countermitm/ for discussion.

in fact, in the first version, the QR code expired, however, for the first tests, it appears more practical for testing to create it static. also the advantages should not be ignored: it is eg. possible to print it on a business card this way.

btw. there is already random data (the INVITENUMBER) in the QR code, so it is not possible to guess it.

wrt. the hidden communication: yes, automated processing of administrative messages arises a new attack vector, this is also discussed in the protocol.

[testbird]

Thanks for responding and providing the links. It's good to discuss subjects to change as it is a way to improve things. :)

the advantages should not be ignored: it is eg. possible to print it on a business card

Good that you already implemented expiring codes. Disabling for testing is no problem, but I think that contact data sharing and contact verification should never be mixed up. It's a basic requirement to maintain credibility of the verification process. Passing on a business card is by no means a contact/key verification, but currently like having a master key to (re)verify all your contacts? May the system notification message in the background be suppressed just as easily?

Simply have both:

1. A static "QR contact id" code for printing and sharing is great, maybe only those should get generated with the Delta Chat or Email-chat label overlay.
2. Use expiring ones with (optionally manually extendable) checkwords to only allow solicit background messages into the system, and thus allow for a reasonable degree of minimal reliance on the contact verification.

[r10s]

Passing on a business card is by no means a contact/key verification

well, you have met someone in person and also giving the person sth. out-of-band. this can to be a good start of a key verification.

[testbird]

Right, meeting someone in person is kind of a requisite for human verification. Contact details can be exchanged and and keys can be verified.

But let's rather be carefull, the spec may just need some more refinement, to not make shifted claims or suggestions.

I mean IIUC, "passing on (a copy) of a business card" does not require that you are meeting those passing it on (again), not to speak of intercepting the plain-text INVITENUMBER. Once that qr number goes around, everybody can get "verified" (in a meaningless way). Thus, it's better to use one-time, temporary "verification QRs", and separate static "contact setup QRs".
Things get questionable when words do not explain correctly or do not match what is done.

Ok, here comes a small, quite terse but with constructive intent, overview of potential subjects to change. I know it contains some exaggerations, but let them serve to avoid unnecessary risks:

Setup Contact protocol Contact Setup protocol?
It's a semi-public fingerprint presentation tag (but with the side effect of currently assigning a misnamed "verified" state to every possessor of the semi-public credentials).
=> Change the wording to setup/configured contacts, or enhance the oobc (see below).

Verified Group protocol verified/setup-by-third-parties protocol?
Complete credibility release of trust to other parties (to the same misnamed "verified" state from above, not even scoped as "verified-by").
=> Use a more precise language and visualisation. (gossip, peer-setup, introduced, met-by, setup-by x others?).

History verification protocol metadata readout protocol
Decentral telecom data retention, with a data extraction mechanism (for the misnamed "verified" from above) with a use-case of history confirmation.
Edit: meta-data collection at central claimchains not considered
=> Enhance the oobc (see below) and default to pin (verified) keys and only store basic massage counts and key-change events etc. localy instead.

Now, here's an idea for a simple-to-use solution that might tackle many of the raised problems and better fulfill the verification ambitions:

Let the qr code scanner use the front (selfie) cam, and have the devices run though a sequence to exchange fingerprints AND public keys in both ways using QR codes (longer data can be transfered using the QRStream app).
With this, both peers could start the same "QR scanning mode" (instead of having to coordinate a "displaying" and a "scanning" party), acknowledge the displayed generated or extended default check word (optionally let the peer supply or enter an additional made-up string) hold the devices together front-to-front to beam things over, and when the chat initiation message arrives, confirm the verification if recognizing the right check words.

[Hocuri]

Well, the advantage of the current process is that it is quite fast (probably faster than the process you described). And if I know the other person personally and sometimes meet him/her, it is secure enough.

[testbird]

I see, the one-way-OOB address+fingerprint scanning ("QR contact setup") may have been quicker to implement than two-way-OOB address+key exchange.

But, I see no drawback for two-way-OOB scanning, other than maybe having to implement repetitive scanning, if it is not possible to cram the whole public key into a larger QR. But maybe even two-way OOB scanning of just the address+fingerprint is enough.

IMHO one-way-OOB address+fingerprint scanning is inferior, because it

• fosters telecom data collection and export (As keys are never actually OOB compared directly/absoutely, the confirmation only relies on relative changes over time, that need to be tracked and compared (with data provided by the same "misnamed-verified" arbitrary otherside key setup).)
• is technically, probably not significantly faster than two-way address+key exchange (scanning is quick and parallel).
• is in practical exchanges probably much slower (confusion who scanns/displays, and side-changing requirements when scanning in group meetings) than a two-way-OOB scanning.
• is not easier to use than two-way-OOB scanning (even if just accepting optional default checkwords) but with no possibilty to do some actual verification (better?: "observeable key transmision"?).
• calls a contact setup scheme "verification", and talks about "verfied contacts" despite that this label is by no means restricted (nor required) to be a person that did the OOB scan.

With printed or scanned business cards featuring QR codes, or especially for the MITM or network level mentioned in above documents, all readers will get a verified status for arbitrary addresses, regardless if you know that person or sometimes meet him/her.

And the idea of recursive trusting third-party "verifications" for further "verifications" makes all this even worse.
But at the root of all this is just the mix-up of a "contacts setup protocol" with "verification".

So, the simple distinction between something like an "introduced-by", and an actual two-way OOB "verified" status may solve the problem way more adequately. And may also actually be well-understandable: "John Newby" (has no verified icon, but show) "introduced-by r10s (who may be verified, and show that icon), Hocceruser, and testbird."

[testbird]

There seems to exist another key promotion or referral (not verifying) scheme:

As far as I understand that, this provider is signing autocrypt headers: https://posteo.de/blog/neu-vereinfachte-e-mail-verschl%C3%BCsselung-mit-autocrypt-und-openpgp-header

May this be used in dubious ways?
Are you considering dc-core to check those, and generate metadata?
Do you see a merit in keeping the "no further servers contacted" default?
Also not collecting at and requesting from peers?

[testbird]

Guys, please be more cautious when touting the lab feature.

How would you rank another project with things looking like semi-concepts and deceptive use of labels like "OOB - verfied" when in fact it is just "has seen QR of X"?
Doesn't this likely create loopholes that can be rippled off?

For example, the one-way instead of two-way OOB scanning leaves one leg sticking out for capture:
The problem is that (grabbing) it grants unconditional privileges (possibly even an escalation path) without making use of the second channel for a full comparison of key data.

So, with a copy of your one-way QR everyone can contact you and get that "verfied" label, and...

Looks like having the QR code of two users even allows to make them think they setup 
their communication "verfied", while they are actually both talking to a mitm that 
blocks direct connections, and instead, fakes vc-requests in the name of the other side 
to both of them, and then proxies between them.

"In for a penny, in for a pound." (Aka, one must finish what one starts before leaving the lab, be careful with unsure claims, and scrap insecure things and wrong claims.)

Symmetric two-way-OOB QR scanning may allow to provide levels of true verification, fix the privilege flaws, and actually be easier to use than the one-way arbitrary contact verificationlabel passing scheme.

[testbird]

This frontend seems to have two-way-OOB working, besides Bluetooth or Wi-Fi message transport:
https://briarproject.org/manual/#adding-contacts
https://code.briarproject.org/akwizgran/briar/tree/master

[r10s]

This frontend seems to have two-way-OOB working, besides Bluetooth or Wi-Fi message transport:

Yes, Bluetooth and Wi-Fi transport are an interesting addition that would make things faster and more reliable (esp. for Wi-Fi, Bluetooth seems to have its own issues).

Two-way is no feature imho.
The countermitm paper discusses how to do this one-way in a safe way.

And do not mix things here: This has nothing to do with the scanned code being static or not.

Guys, please be more cautious when touting the lab feature.

Why? It's a labs feature that should be tested. Not more and not less.

However, in general, this should be discussed in the issue you created here nextleap-project/countermitm#58 - maybe we should close this issue here to be more focused :)

[haeckser]

hmm, imho, checking the fingerprint of the public key of a chat member will validate its correctness. This could be done by the fingerprint, spelled to the chat member by phone or direct contact or even by a generated QR code that I can scan and which is compared with the fingerprint of the selected chat partner.
The ability of using a phone call for validation is in my eyes very important, because I use DC to sent information to partners somewhere in the world and will rarely have the chance of a direct contact.
QR or WIFI transfer options are in my eyes just another (and more comfortable) way in case of face to face meetings

What in my eyes is important is away to detect changed pub keys (by manipulating the mails) and mange the trust level.
A simple traffic light (someone has posted that idea in another issue) maybe in the list of contacts and a notification whenever a state changes will give users a good chance to catch manipulations without making the protocols more complicated.

Especially the manual (voice transferred) check of the fingerprint is a must.
If there are ways to make validations and transfers of public keys more simple, they are welcome as long as they will not block the manual check or make the code less robust.
I would put the traffic light visualization on more higher priority than a more complex automatic transfer in face to face situations

[testbird]

Two-way is no feature imho

Have a little look, comparing to the draft below.

The countermitm paper discusses how to do this one-way in a safe way.

Actually, it explicitly mentions to introduce additional attack surfaces in several steps (not safe). And it could leave the unfortunate impression to disguise a new and different method behind well-established terms and processes, rather than finding more precisely descriptive terms to explain any differences and present all the new aspects.

There is no response in the nextleap issue, and since any flaws are irrelevant as long as they're not part of deltachat, I more constructively contribute an improvement idea instead:

---

2-way OOB Autocrypt Verificaton Protocol Spec V0.0 "out of the cloud draft"

---

A single button to verify contacts for the user. When pressed, it starts QR scanning on the front-camera, and shows QR codes on the display, together with the instruction to pair with another device (front-to-front) until they beeped.

Process description: The devices start to

1. Display some "autocrypt verfication intent" QR code in the upper part of the display. If this is not seen on the other side, any contact data containing QR code is just used to set up an unverified contact.

2. Display the own ID and key in the lower part of the display, say arranged in the vcard format.

   • If the display resolution is not high enough, the information is shown in a repeating sequence of QR codes or a higher bandwidth flicker code (if such exists).
     See flicker-code example and QR Stream implementations
     https://f-droid.org/en/packages/com.github.xloem.qrstream/
     https://github.com/xloem/qrstream
     https://github.com/christiansiegel/video-qr-code-scanner

3. After sucessfully receiving the vcard information from the peer, the device calculates the signature for the received public key (using the own secret key) and presents it as QR code(s) in the upper part of the display.

4. After successfully receiving a signature from the peer, present a small additional "autocrypt verification done" indication QR in the display (top most should be easiest to scan for camera).

5. After verification is done and receiving the done indication from the peer, stop the process and emit an audio and optical signal, to indicate success.

This process "only" verifies that the peer device has access to the secret key belonging to the presented public key.

If (once) email connectivity is available, the devices may send regular encrypted messages to each other, and confirm the correct association to the email address.

Advantages of this 2-way pairing

• off-line capable, no metadata leaks into email/network channel required
• presents only public key data and poses challenges to be encrypted, without introducing any secrets that would grant privileges in other contexts (making it interesting to intercept)
• does not impel to introduce any back office code for hidden email message handling

Optionally 1), to get some verification that the person holding the device actually belongs to the key, before the process starts, the device may show a screen with a checkword to be told to the person, and input fields to enter the checkwords from the peer. (Best proceedings, like self-entered checkwords, would have to be investigated.)

Optionally 2), the basic pairing process could be optionally further extended into a "custom mode", in which the process stops after receiving the vcard, to present the received vcard, and allow the user to select all those data fields of the peer that he knows or could verify, and only afterward the process proceeds to transmit the signatures for all the selected fields to the peer.]

Verified-by (signed key gossip?)

The devices keep track of the email addresses that a key is used with.

The user is warned if the key of a contact changes, by inserting a notification about the event into the corresponding messages, and changing the corresponding user icon (badge, overlay) in the chat list and all other places changes accordingly.

Further, the contact profiles store (only) the change events in a list for investigation (instead of the whole messaging history). The contact profiles also list any other contacts that may be using the same key.

A user may indicate to another user that a third party was verified and has been using the key with a specific email address, by sending the key of the third party and its address(es), signed using the devices own secret key.

Such "verfied-by" indications can be sent automatically by the device, when adding a new contact to a group.

The minimal trust level for "secure groups" could default to such "verified-by self-verfied contacts".

[Hocuri]

One problem with 2-way OOB Autocrypt Verificaton: How do users know how far they need to hold their smartphones apart?
With 1-way this was no problem: The camera image was shown on the screen and the user just had to move the smartphones until the QR code was fully on the screen.

[testbird]

Good point, I later played around with two phones, but forgot to write yesterday:

Approaching a QR with the back-camera, successful qr scanning range was beginning at about 40cm.

The minimal distance to capture each others whole display was to at about 30cm, here, and the harder to get part is the lower display.

But this also showed another problem, most of the times the auto focus is on the background, not on the other phone. A lower resolution QR might work anyway.

So,

1. if possible, manually set the focus to 30cm?

2. Only the upper display part to show just one QR, and automatically loop through the QRs, showing the next every X milliseconds. (Should also be much easier (possible) to implement with existing qr scanning libs.): own details with challenge, response (empty at first), ....

3. An idea to provide some guidance and feedback could be to turn on the flashlights as long as some display corner marks or simply a qr code is detected. (Beep should only accur after the full sequence was scanned successfully.)

[testbird]

Because the exchange does not contain any tokens (only challenges) the protocol may also be ok to be used over wireless near field (radio) communication "NFC".

[testbird]

4. Another way to provide feedback could be to let the devices make another (lower volume) noise or vibration when detecting a new QR in the 250ms paced sequence shown by the peer. Could be a cool "beaming" gimmick even 🥇 :-)

[r10s]

closing this, discussion is taken place here https://github.com/nextleap-project/countermitm/issues

[testbird]

Well, unfortunately no one replied to the issue I opened there. No one could explain what I may not be seeing just right.

Fortunately, there are now others that have started to pick on exactly the same theoretical basics that I brought up.

In the end, the solution for a practical messenger will have to

• remove all "secrecy" assumptions from the QR exchange
• not rely on references across channels
• do freshness checks only for convenience (avoid annoyance), not security

The basics are:

=> Easy verification management UX for a local web-of-trust

• contact addition
• true contact credentials verification (instead of hoping to catch mitm by chaining in a secret sent through another one-way channel)
  • 2-way OOB public (encryption) key exchange with decryption challenges and signed responses
  • optional personal word-of-mouth "checkword"
• signed "verified-by" announcements and denouncements (gossip "I verified contact X" by sending a separate signature for the self-verfied key of X to other peers within encrypted messages).
• visualisation of state (icons)
• listing of verfication paths (self-verfied, verified-by X, Y, Z)

=> claim chains only as another optional, alternative, advanced, distributed storage backend for the UX

[testbird]

BTW: The 2-way OOB sequence could start with showing a plain, static vcard compatible QR (that may be printed on a business contact card), and only start to present a challenge in between after detecting another vcard QR in the video stream.

If the detected QR is only from a static business card, the process can end if only the same qr (and no challenge) is read repeatedly for say 1550ms.

[r10s]

Fortunately, there are now others that have started to pick on exactly the same theoretical basics that I brought up.

so, you made the discussion starting :)

[testbird]

Proper 2-way OOB key comparison also eliminates the need for having system messages running in behind the back of the user (a large minus).

[testbird]

If simultanious scanning and displaying is too advanced for a starter, just placing a button on the display to switch between scan/show the ID, (public) encryption key data (and an decryption challenge) would be enough to allow propper 2-way OOB checks, without implementing known security flaws (cross channel, backgroud channel, ...)

(allow manual subsequent scanning in both directions)