Subject: [Medup] Protocol for peer-to-peer synchronization of secret key material (new draft)

From: Hernâni Marques (p≡p foundation) <[email-masked]>
Date: Sat, 13 Jul 2019 12:09:11 +0200

Dear folks

From pEp side, we are describing a protocol for p2p sync of private key
material and provide a finite-state machine which can be implemented for
that task; see draft below.

We use Trustwords for authentication of the pairing; see also this
Thread on Twitter for other ideas on that part:

https://twitter.com/BerndPaysan/status/1149749653727928320

Feedback is very welcome.

In Montreal, we'll also be able to demonstrate how it works, in terms of
message flow and and user interaction (for example, between Android and
Outlook mail clients).

Greets

Hernani

-------- Forwarded Message --------
Subject: New Version Notification for draft-hoeneisen-pep-keysync-00.txt
Date: Sun, 07 Jul 2019 10:50:59 -0700
From: [email-masked]
To: Bernie Hoeneisen <[email-masked]>, Hernani Marques
<[email-masked]>

A new version of I-D, draft-hoeneisen-pep-keysync-00.txt
has been successfully submitted by Bernie Hoeneisen and posted to the
IETF repository.

Name:		draft-hoeneisen-pep-keysync
Revision:	00
Title:		pretty Easy privacy (pEp): Key Synchronization Protocol
Document date:	2019-07-07
Group:		Individual Submission
Pages:		74
URL:
https://www.ietf.org/internet-drafts/draft-hoeneisen-pep-keysync-00.txt
Status:
https://datatracker.ietf.org/doc/draft-hoeneisen-pep-keysync/
Htmlized:       https://tools.ietf.org/html/draft-hoeneisen-pep-keysync-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-hoeneisen-pep-keysync

Abstract:
   Modern users of messaging systems usually have multiple devices, and
   often desire to send and receive encrypted messages on some or all of
   their devices.  Using encryption on multiple devices often results in
   situations where messages cannot be decrypted on the device used to
   read the message due to a missing private key.

   This document specifies a protocol for secure peer-to-peer
   synchronization of private keys across devices belonging to the same
   user (pEp Key Synchronization Protocol).

   The pretty Easy privacy (pEp) protocols describe a set of conventions
   for the automation of operations traditionally seen as barriers to
   the use and deployment of secure end-to-end interpersonal messaging.
   These include, but are not limited to, key management, key discovery,
   and private key handling.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Bernd Paysan <[email-masked]>
Date: Sat, 13 Jul 2019 16:45:39 +0200

Am Samstag, 13. Juli 2019, 12:09:11 CEST schrieb Hernâni Marques (p≡p 
> Feedback is very welcome.

Ok, here some more details about how my seckey exchange protocol in net2o 
works:

It's not completely implemented, and fallback to a trustwords-based 
verification on computers without camera can be considered as an option.  I 
think that most people have at least one device with a camera, so if you have 
one such device, you can use that to transfer the keys, even if you have 
multiple devices without camera.  It's likely the most convenient device to 
move around, and physical proximity is a good thing for this kind of 
operation.

net2o addresses peers by pubkeys (to compute the routing), so first, you need 
a pubkey to start talking.  The pubkey is scanned as QR code; the QR code 
contains the pubkey and a random IV+secure hash to detect errors.  If your 
screen or camera is too dirty, just wipe it; if you have a bad case of spider 
app, you probably should use that device for scanning and the better screen 
for QR code presenting.  The IV+hash is used as a challenge.

So once you have the pubkey, you send a message to the node, which includes a 
proof that you have seen the challenge, and your own pubkey+a digital 
signature of the key you have seen.  I'm still thinking about the best proof 
here; I think hash(challenge, pubkey, signature) is a good approach.  That way 
a replay attack is impossible: The attacker can not replace the pubkey and the 
signature without breaking the proof.  This is part of a normal connection 
preparation within net2o, so it's by itself already not a plain-text transfer; 
but it could be.

This means you indeed did scan that particular QR code, not some other code.  
The scanned device now replaces the QR code on the screen with another QR code 
that proofs it received the scanner's pubkey (a digital signature); the 
challenge (all QR codes contain one) can be based on the proof presented.  At 
that point, both sides can be sure the communication is not intercepted, 
because the second channel (optical QR scan) allowed to verify the 
communication both ways.

This part is generic, and used for other key exchanges, too.  Only one side 
needs to present, and one side needs to scan, so it's pretty quick.

So now you can create a secure connection, and transfer the secret keys — the 
direction depends on which device has the key, so you can either select “give 
key“ or “receive key“ on the device that shows the QR code, and select the 
opposite option for the device that scans the QR code.  If the key has been 
locked with a passphrase, you will have to enter the same passphrase on both 
devices before you complete the transfer (on one device to unlock the key so 
that you can start at all, on the other, to receive it); the proof that you 
have the passphrase is send as zero-knowledge proof, too.

If an attacker scanned the QR code, too, and sent his response first, the 
scanning device would have aborted the attempt of key syncing before prompting 
to enter the passphrase.  The code-presenting device could abort an attempt of 
syncing if it receives two responses with different pubkeys for the same 
challenge.

You can work without seckey passphrase in net2o for convenience, if you like 
to (I wouldn't; Police of various police states around the world request 
people to unlock their phone, and then can search the device — having an 
additional protection is a good idea.  Police could possibly request to unlock 
net2o, either, but they can't know if the unlock is the ID they want to 
search). 

If you have a passphrase, you will need it here.  Different IDs should have 
different passphrases.

The device that received the seckey will now create a key 
revokation+replacement record so that the temporary key used for the 
connection is invalidated, and replaced by the received key, and send this 
record to the other device.  Both devices have now the same keys.

> message flow and and user interaction (for example, between Android and

I don't know if jitsi works in China, where I spend my holiday (WeChat is 
known to work, and net2o, but it still lacks a video conference mode ;-), or 
what your schedule is; as China and Montreal are 12 hours apart, there could 
be problems.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
https://net2o.de/