p≡p I-Ds (IETF Internet-Drafts)

105 KiB

Raw Blame History

coding
utf-8

title: "pretty Easy privacy (pEp): Key Synchronization Protocol" abbrev: pretty Easy privacy (pEp) KeySync docname: draft-hoeneisen-pep-keysync-01 category: std

stand_alone: yes pi: [toc, sortrefs, symrefs, comments]

author: {::include ../shared/author_tags/bernie_hoeneisen.mkd} {::include ../shared/author_tags/hernani_marques.mkd}

{::include ../shared/author_tags/claudio_luck.mkd}

normative: RFC4949:

RFC5322:

RFC7435: I-D.birk-pep:

informative:

RFC4880:

RFC5321:

RFC7258:

RFC7942:

I-D.marques-pep-email:

I-D.birk-pep-trustwords:

I-D.marques-pep-rating:

I-D.marques-pep-handshake:

I-D.luck-lamps-pep-header-protection:

I-D.hoeneisen-pep-keysync:

{::include ../shared/references/isoc-btn.mkd}

{::include ../shared/references/implementation-status.mkd}

--- 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.

--- middle

Introduction

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

This part of the pretty Easy privacy (pEp) protocols {{I-D.birk-pep}} presents a way to synchronize private key material in a decentralized manner that is easy to implement. This network protocol is designed as a finite-state machine (FSM) along with the exchange of specific KeySync messages.

For pEp implementations, pEp KeySync for key synchronization is a critical part of the broader pEp Sync protocol, which is designed to be extensible to allow for the synchronization of additional user data, such as configuration settings and peer trust status information across a user's devices.

This document will provide a general description of pEp KeySync, including idealized use cases, diagrams, and examples of messages that may be generated during the KeySync process.

Problem Statement

Modern users of messaging systems usually have multiple devices, and often desire to send and receive encrypted messages on some or all of them.

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. These messages were likely encrypted with a key that was generated on another device belonging to the same user. For example, the sender encrypts with a key that was generated on the home laptop of the recipient. The recipient then attempts to decrypt the message on their mobile phone, where the corresponding private key is not available. As a result, the recipient either must return to their laptop to decrypt the message, or attempt to copy the correct private key to their mobile device, which may expose the user's private key to potential leaks or theft.

Approach

The basic approach to solving the multiple-device decryption problem is to synchronize private keys among the devices of a user in a secure manner. pEp aims to do this by using Trustword confirmation (cf. {{I-D.birk-pep-trustwords}}) between any two devices at a time for pairing purposes. Simply put, a user needs to manually compare and confirm Trustwords before the automatic and security-sensitive transfer of private key information can occur.

Main Challenge

The main challenge, that pEp KeySync is designed to overcome, is to perform the synchronization in a secure manner so that private keys are not leaked or exposed to theft.

Note: The case of an adversary getting access to the device itself is beyond the scope of this document.

{::include ../shared/text-blocks/key-words-rfc2119.mkd}

{::include ../shared/text-blocks/terms-intro.mkd}

{::include ../shared/text-blocks/handshake.mkd}

Note: In pEp KeySync, the handshake is used to authenticate own devices (the user normally compares the Trustwords directly by looking at the screens of the devices involved).

{::include ../shared/text-blocks/trustwords.mkd} {::include ../shared/text-blocks/tofu.mkd} {::include ../shared/text-blocks/mitm.mkd} {::include ../shared/text-blocks/identity.mkd}

Device Group: All devices that are grouped to share data like cryptographic keys, trust information, calendar, configuration and other data. The data is synchronized through a common channel for a given identity, e.g., an identity can be an email address and the common channel a mailbox in email.
Group Key: A key pair primarily used by a Device Group for a certain identity. A Device Group has a Group Key for each of a user's identities.
Sole Device: A device which is not part of a Device Group.
Grouped Device: A device which is already part of a Device Group.
Beacon (message): A technical text message that is broadcast by Sole Devices and transmitted through a message sent to the channel of an identity. Other Sole Devices, or a Grouped Device of the same unique identity and using that identity's channel, can interpret this Beacon in order to initiate negotiation for the formation of a Device Group.

General Description

This section describes an ideal-condition use case for pEp KeySync. It focuses on the main procedures and on the scenarios where everything works. Unexpected user behavior, error handling, race conditions and the like are mostly omitted from this section in order to facilitate a better understanding of the general concepts of pEp KeySync. Additional use cases will be discussed in further detail throughout {{reference-implementation}}.

Use Cases for pEp KeySync

Form Device Group

Our user, Alice, has two devices that are configured with pEp-implementing messaging clients and share the same identity for her preferred communication channel (in our example: a communication channel with an email address). Let us call these devices Alice_R and Alice_O. Each device already has its own key pair, which was automatically generated by the pEp protocol. Neither device knows anything about the other.

Alice wants full communication capability from both of her devices, but currently cannot do so, as the devices do not know about each other. Alice will use pEp Keysync to form a Device Group and add her devices to it. This allows for the exchange of private key data among its devices, allowing Alice to have full communication capability on both of her devices.

Add New Device to Existing Device Group

Sometime after devices Alice_R and Alice_O have formed a Device Group (cf. {{form-device-group}}), Alice buys another device, Alice_J, which is also configured with pEp-implementing messaging clients and shares the same identity for her preferred communication channel (the aforementioned email address). Alice_J also has a key pair, which was automatically generated by the pEp protocol, just as the Grouped Devices Alice_R and Alice_O have. But while the Grouped Devices know each other and have exchanged private keys, Alice_J and the Grouped Devices don't know anything each other. Thus, Alice does not have full communication capability across the three devices.

As before with devices Alice_R and Alice_O, Alice will use pEp Keysync to add device Alice_J to the existing Device Group, allowing all three devices to exchange private key information, and Alice to have access to her messages from any of them.

Exchange Private Keys

All devices from Alice are part of a Device Group (cf. {{form-device-group}} and {{add-new-device-to-existing-device-group}}). However, as keys may expire or get reset, occasionally new key pairs are generated. For Alice to be able to read all encrypted messages on all devices, any new private key needs to be shared with the other devices in the device group. All devices in Alice's Device Group will share the latest private keys as they are generated, keeping all of her devices up to date and functioning as desired.

Leave Device Group

Alice may decide that one of her devices (e.g., her mobile phone) should no longer have access to all private keys of the Device Group. Alice can manually tell that device to leave the Device Group. The Device Group will ensure that further communication among the remaining Grouped Devices is private.

Remove other Device from Device Group

One of Alice's devices may be stolen or become otherwise compromised. She needs to ensure that the affected device no longer receives updates to private keys from the other devices in her Device Group. Alice can initiate actions to mitigate the damage, including the revocation of her private keys, as well as forcibly removing the compromised device from her Device Group.

Interaction Diagrams

The following interaction diagrams depict what happens during Alice's KeySync scenarios in a simplified manner. For each scenario, we first present a successful case, then an unsuccessful case and, finally, a case that has been interrupted, or discontinued. Some details are skipped here for the sake of readability. Descriptions of the interactions are included after each diagram.

Form Device Group

Successful Case

{::include ../shared/fence-line.mkd} {::include ../shared/ascii-arts/sync/form-device-group.atxt} {::include ../shared/fence-line.mkd}

As depicted above, a user intends to form a Device Group in order to securely share key material among its members. The group is formed by an 'Offerer' device and a 'Requester' device. The names 'Offerer' and 'Requester' are derived from the FSM (cf. {{simplified-finite-state-machine}}), in which the device roles are defined during the start sequence, which is necessary for the FSM to work as intended.

During initialization of pEp KeySync, each device generates a UUID version 4, variant 1 number, which is called a Transaction-ID (TID). These TIDs are sent as a challenge in a Beacon over the mutual channel, and the device roles of 'Offerer' and 'Requester' are determined by the numeric value of each device's unique TID.

Note: All messages are 'broadcast'. The TIDs added to each message allow the identification of received messages which pertain to the ongoing transaction and its sender.

Every device sends a Beacon message containing a challenge TID. Upon receipt of a Beacon message from another device, the received challenge TID is compared with the device's own challenge TID. The device which has a TID with a lower numerical value is assigned as the 'Requester', and the other device is automatically assigned as the 'Offerer'.

Note: The 'Offerer' device MUST NOT start a Negotiation. Thus, it re-sends its own Beacon (for robustness in case earlier Beacon message got lost) and waits. Message 1(r) depicts the Beacon message sent by the 'Requester' device and is not required for the process to continue.
After determination of the role, the 'Requester' device sends a NegotiationRequest message.
The 'Requester' device displays the Trustwords to the user.
Upon receipt of the NegotiationRequest message, the 'Offerer' device sends a NegotiationOpen message.
The 'Offerer' device displays the Trustwords to the user.
The user compares the Trustwords of both devices. As the Trustwords are the same on both devices, the user presses the 'Accept' button on the 'Requester' device.

Note 1: The user may also press the 'Accept' button on the 'Offerer' device first. The end result is not affected by which 'Accept' button is pressed first. However, the order of the messages slightly changes.

Note 2: The user may also choose to press the 'Cancel' button or the 'Reject' button (see below).
On receipt of the user's 'Accept', the 'Requester' device sends a CommitAcceptRequester message.

The 'Offerer' device receives this message and waits for the user to press the local 'Accept' button.
The user compares the Trustwords of both devices and presses the 'Accept' button on the 'Offerer' device.

Note: The user may also choose to press the 'Cancel' button or the 'Reject' button (see below).
On receipt of the user's 'Accept', the 'Offerer' device sends a CommitAcceptRequester message.
The 'Offerer' device then sends an OwnKeysOfferer message along with the user's local key pairs (private and public keys) to
to be synchronized.
Upon receipt of the OwnKeysOfferer message, the 'Requester' device is Grouped and sends an OwnKeysRequester message along with the user's local key pairs (private and public keys) to be synchronized.

Upon receipt of the OwnKeysRequester message, also the 'Offerer' device is grouped. The formation of the Device Group has been successful.

Unsuccessful Case

{::include ../shared/fence-line.mkd} {::include ../shared/ascii-arts/sync/form-device-group_reject.atxt} {::include ../shared/fence-line.mkd}

For unsuccessful KeySync attempts, messages 1-5 are the same as in a successful attempt (see above), but once the Trustwords are shown, events are as follows:

{::include ../shared/fence-line.mkd}

R6. The user compares the Trustwords of both devices. As the Trustwords do not match, the user presses the 'Reject' button on the 'Requester' device.

 Note: The user may also press the 'Reject' button on the
 'Offerer' device first. The end result is not affected by which
 'Reject' button is pressed first. However, the order of the
 messages slightly changes.

{::include ../shared/fence-line.mkd}

R7. On receipt of the user's 'Reject', the 'Requester' device sends a CommitReject message.

{::include ../shared/fence-line.mkd}

Once the CommitReject message is sent or received, respectively, the devices cannot form a Device Group, and pEp KeySync is disabled on both devices. As a result, there are no further attempts to form a Device Group involving either of these two devices.

Discontinuation Case

{::include ../shared/fence-line.mkd} {::include ../shared/ascii-arts/sync/form-device-group_cancel.atxt} {::include ../shared/fence-line.mkd}

For discontinued (canceled) KeySync attempts, messages 1-5 are the same as in a successful attempt (see above), but once the Trustwords are shown, events are as follows:

{::include ../shared/fence-line.mkd}

C6. The user decides to discontinue the process and presses the 'Cancel' button on the 'Requester' device.

 Note: The user may also press the 'Cancel' button on the
 'Offerer' device first. The end result is not affected by which
 'Cancel' button is pressed first. However, the order of the
 messages slightly changes.

{::include ../shared/fence-line.mkd}

C7. On receipt of the user's 'Cancel', the 'Requester' device sends a rollback message.

{::include ../shared/fence-line.mkd}

The devices do not form a Device Group. KeySync remains enabled and forming a Device Group can start again.

Add New Device to Existing Device Group

Successful Case

{::include ../shared/fence-line.mkd} {::include ../shared/ascii-arts/sync/join-device-group.atxt} {::include ../shared/fence-line.mkd}

As depicted above, a user intends to add a new device to an existing Device Group.

Note: All messages are 'broadcast'. The TIDs added to each message allow the identification of received messages which pertain to the ongoing transaction and its sender.

During initialization of pEp KeySync, the new device sends a Beacon message.

Note: In the diagram, all messages marked "1. Beacon" are a single message, but drawn separately in order to convey that the message is sent to all devices in the Device Group.
Upon receipt of a Beacon message from a device not part of a Device Group, all Grouped Devices are send a NegotiationRequest message.

Note: Messages 2(a) and 2(p) are different instances of the NegotiationRequest message type.
All Grouped Devices display the Trustwords to the user.
Upon receipt of every NegotiationRequest message, the New Device sends a NegotiationOpen message.

Note: Messages 4(a) and 4(p) are different instances of the NegotiationOpen message type.
The new device displays the Trustwords to the user.
The user compares the Trustwords of both devices and presses the 'Accept' button on one of the Grouped Devices.

Note 1: The Grouped Device that the user presses the 'Accept' button on now assumes the role of the active device in Group, while the other Grouped Devices get the role of passive devices in the group.

Note 2: The user may also press the 'Accept' button on the new device first. The end result is not affected by which 'Accept' button is pressed first. However, the order and number of the messages change.

Note 3: The user may also choose to press the 'Cancel' button or the 'Reject' button (see below).
On receipt of the user's 'Accept', the active Grouped Device sends a TrustThisKey message, which is consumed by the passive Grouped Devices.
Then, the Active Grouped Device also sends a CommitAcceptForGroup message.

The new device receives this message and waits for the user to press the local 'Accept' button.
The user compares the Trustwords of both devices and presses the 'Accept' button on the new device.

Note: The user may also choose to press the 'Cancel' button or the 'Reject' button. However, these cases are explained later.
On receipt of the user's 'Accept', the new device sends a CommitAccept message.
The new device then sends a GroupKeys message along with its own private keys.
Upon receipt of the GroupKeys message, the Active Grouped Device is Grouped and sends a GroupKeys message along with its own private keys. The new device has successfully joined the Device Group.

Note: In the diagram, all messages marked "12. GroupKeys + keys" are a single message, but drawn separately in order to convey that the message is sent to all devices in the Device Group.

Unsuccessful Case

{::include ../shared/fence-line.mkd} {::include ../shared/ascii-arts/sync/join-device-group_reject.atxt} {::include ../shared/fence-line.mkd}

For unsuccessful KeySync attempts, messages 1-5 are the same as in a successful attempt (see above), but once the Trustwords are shown, events are as follows:

{::include ../shared/fence-line.mkd}

R6. The user compares the Trustwords of both devices. As the Trustwords do not match, the user presses the 'Reject' button on one of the Grouped Devices.

 Note: The user may also press the 'Reject' button on the New
 Device first. The end result is not affected by which 'Reject'
 button is pressed first. However, the order and number of the
 messages slightly changes.

{::include ../shared/fence-line.mkd}

R7. On receipt of the user's 'Reject', the 'Requester' device sends a 'CommitReject' message.

Note: In the diagram, all messages marked "R7. CommitReject"
are a single message, but drawn separately in order to convey
that the message is sent to all devices in the Device Group.

{::include ../shared/fence-line.mkd}

The new device does not join the group and pEp KeySync is disabled on it. As a consequence, there are no further attempts to join the Device Group.

Once the CommitReject message is sent or received, respectively, the new device cannot join the Device Group, and pEp KeySync is disabled on the new device. As a result, there are no further attempts to join a Device Group by the new device.

Discontinuation Case

{::include ../shared/fence-line.mkd} {::include ../shared/ascii-arts/sync/join-device-group_cancel.atxt} {::include ../shared/fence-line.mkd}

For discontinued (canceled) KeySync attempts, messages 1-5 are the same as in a successful attempt (see above), but once the Trustwords are shown, events are as follows:

{::include ../shared/fence-line.mkd}

C6. The user decides to discontinue the process and presses the 'Cancel' button on one of the Grouped Devices.

 Note: The user may also press the 'Cancel' button on the New
 Device first. The end result is not affected by which 'Cancel'
 button is pressed first. However, the order and number of the
 messages slightly changes.

{::include ../shared/fence-line.mkd}

C7. On receipt of the user's 'Cancel', the 'Requester' device sends a rollback message.

Note: In the diagram, all messages marked "C7. Rollback"
are a single message, but drawn separately in order to convey
that the message is sent to all devices in the Device Group.

{::include ../shared/fence-line.mkd}

The new device does not join the Device Group. KeySync remains enabled and joining a Device Group can start again.

105 KiB Raw Blame History

{::include ../shared/author_tags/claudio_luck.mkd}

RFC5322:

RFC4880:

RFC5321:

RFC7258:

RFC7942:

I-D.marques-pep-email:

I-D.marques-pep-rating:

I-D.luck-lamps-pep-header-protection:

I-D.hoeneisen-pep-keysync:

{::include ../shared/references/implementation-status.mkd}

Introduction

Problem Statement

Approach

Main Challenge

General Description

Use Cases for pEp KeySync

Form Device Group

Add New Device to Existing Device Group

Exchange Private Keys

Leave Device Group

Remove other Device from Device Group

Interaction Diagrams

Form Device Group

Successful Case

Unsuccessful Case

Discontinuation Case

Add New Device to Existing Device Group

Successful Case

Unsuccessful Case

Discontinuation Case

Exchange Private Keys

Leave Device Group

Remove other Device from Device Group

Simplified Finite-State Machine

Reference Implementation

Full Finite-State Machine

States

InitState

Sole

HandshakingOfferer

HandshakingRequester

HandshakingPhase1Offerer

HandshakingPhase1Requester

HandshakingPhase2Offerer

HandshakingPhase2Requester

FormingGroupOfferer

FormingGroupRequester

Grouped

HandshakingToJoin

HandshakingToJoinPhase1

HandshakingToJoinPhase2

JoiningGroup

HandshakingGrouped

HandshakingGroupedPhase1

HandshakingGroupedPhase2

Actions

deviceGrouped (conditional)

disable

hideHandshakeDialog

openNegotiation

ownKeysAreDefaultKeys

newChallengeAndNegotiationBase

partnerIsGrouped (conditional)

prepareOwnKeys

receivedKeysAreDefaultKeys

sameChallenge (conditional)

sameNegotiation (conditional)

sameNegotiationAndPartner (conditional)

saveGroupKeys

showBeingInGroup

showBeingSole

showDeviceAdded

showGroupCreated

showGroupedHandshake

showJoinGroupHandshake

showSoleHandshake

storeNegotiation

tellWeAreGrouped

105 KiB

Raw Blame History