Sopher has been part of the UpdateDeutschland 48h Sprint Hackathon initiative which took place from 19th to 21st of March 2021. It was clear quickly that there was one particular challenge posed by the City of Freiburg that had the potential for a match.

Wie können wir kollaboratives Arbeiten in Zeiten von Home Office und Home Schooling für städtische Mitarbeiter:innen, Schüler:innen und andere Akteuren:innen ermöglichen, ohne gegen den Datenschutz zu verstoßen?

How can we enable collaborative work in times of home office and home schooling for urban employees, students and other stakeholders without violating data protection?

During the Hackathon we met in video conferences organized by the UpdateDeutschland team and learned that the City of Freiburg had the concrete goal of implementing a collaborative whiteboard for their employees and possibly for other employees of the public sector.

As a result we produced a short video that showcases our activity during the three days:

At the same time during the night from Saturday to Sunday we integrated an existing open source SaSS whiteboard into Sopher.

Integrating Excalidraw into Sopher.

The open source collaborative whiteboard Excalidraw supports end-to-end encryption (E2EE), see E2EE in Excalidraw. Combining the communication features of Sopher with the collaborative features of Excalidraw seemed a perfect match for the challenge of the Hackathon. We integrated the SaSS deployment of Excalidraw into Sopher using simple key derivation in each channel. Here we derive a symmetric key from the channel's identity key like so

k_group = hkdf(tbp(identity), 'whiteboard')
k_contact = hkdf(ecdh(id_1, id_2), 'whiteboard')

In a group the key depends on the group identity key via its thumbprint and in the case of a one-to-one whiteboard we derive a ECDH shared secret first and then derive the whiteboard secret from that.

Further steps

In order to be useful we need to take into account that employees use Single-Sign-On mechanisms and already have accounts at their respective organization. To not overuse the resources of the Excalidraw team we plan to host our own instance of Excalidraw infrastructure and link to that in Sopher.

A collaborative whiteboard — integrating Excalidraw into Sopher was originally published in Becoming sopher on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sopher.io provides end-to-end encrypted communication for teams. We offer end-to-end encryption for each and every communication that happens between your and your team member’s devices. In this post we want to answer the question how we got there and what are the special properties of our implementation compared to the Signal protocol as specified by Open Whisper Systems (OWS).

When we started our implementation in December 2016 OWS had just released descriptions of their algorithms for the handshake protocol X3DH and for the Double-Ratchet-Algorithm to the public domain. That was great since we would not have to dig around in their source code. An earlier attempt to implement the Signal protocol by the encrypted messenger Wire conjured up legal problems due to similarities with the source code of OWS's implementation. The description of multi-device support Sesame was added a bit later and so we came up with our own which is pretty similar. But first things first, what are the properties we expect from a message protocol that suits our needs?

Properties of an ideal protocol

One key aspect of the technical side of Sopher is the fact that we do not operate an application server. Everything happens in the client and if we really need to store information online we upload it to standard cloud storage such as Dropbox, Google Drive, S3 or the like. This poses a few challenges to the implementation of the messaging protocol. In particular we faced the following tasks:

• Only use cryptographic primitives provided by the WebCrypto API
• Symmetric asynchronous handshake
• Message acknowledgement
• Multi-device support

A browser implementation of the Signal protocol using Typescript

For the browser implementation of the Sopher client we use Typescript. This enables us to leverage the power of asynchronous programming using the keywords async and await. Not to mention the beauty of working with an editor (mostly Visual Studio Code) that really understands the structure and dependencies of the project. If you are not familiar with Typescript check out their Documentation, its worth it.

In the next sections we will walk you through the differences to vanilla Signal as described in the OWS specs.

WebCrypto primitives

At the current stage of development we support browsers that implement the WebCrypto API sufficiently well (Chrome, Firefox). This has several advantages security-wise and implementation-wise. It is more secure since we can leverage the power of non-exportable keys. A CryptoKey can be flagged non-extractable when generated by the API:

let key = await crypto.subtle.generateKey(
  {
    name: 'ECDH',
    namedCurve: 'P-384'
  },
  false, // make the key non-extractable
  ['deriveKey', 'deriveBits']
);

This makes it extra hard for an attacker to steal the keys. Nevertheless those keys can be stored in IndexedDB for subsequent usage.

Obviously sticking to WebCrypto greatly simplifies the implementation as we do not have to create fallback strategies for browsers without WebCrypto. This would add a great amount of overhead since one would have to use WebWorkers for encryption to avoid locking the browser context.

The X3DH protocol recommends using the X25519 or X448 elliptic curves for the use in Diffi-Hellmann key agreements. However those curves are not part of WebCrypto implementations neither in Chrome nor Firefox, let alone Safari. Safari however added ECDH support to its Technology Preview in May 2017. We therefore decided to use the standard NIST curve P-384 to perform Diffie-Hellmann key agreements and DSA signatures.

All other cryptographic primitives recommended by OWS are available in WebCrypto implementations. We use AES-CBC for content encryption and HMAC with SHA-512 for payload signatures as described in the JWA specification. One could consider using direct encryption as described in the spec to save a little space here. On the other hand we need per-recipient encryption for group messaging anyway. One way to implement this is via the multiple encryption of a content encryption key.

Symmetric asynchronous handshake

We basically follow the specification of X3DH when establishing a session between devices. The one major difference is in the way we determine in advance who is Alice and who is Bob to avoid the hassle of maintaining more than one session as described in the Sesame algorithm.

In Sopher a shared file in a cloud storage acts the role of the server. A client publishes his public (pre-)keys for other clients to pick up and start a session. In particular we store the following information in a JWS structure signed with the device key:

{
  DID: "c6e4b0b5b8ffcfeb4e0...",
  name: "Chrome",
  timestamp: 1535538368530,
  key: {crv: "P-384", kty: "EC", ...},
  pipeKey: {crv: "P-384", kty: "EC", ...},
  signedPrekey: {crv: "P-384", kty: "EC", ...},
  onetimePrekeys: [
    {crv: "P-384", kty: "EC", ...},
    {crv: "P-384", kty: "EC", ...},
    {crv: "P-384", kty: "EC", ...},
    ...
  ],
  invitations: [
    {
      salt: "jJTjeLvmeeYyT8...",
      url: "eyJhbGciOiJBMjU2S1ciLCJlbmMiOiJBMjU2Q0JDLUhTNTEyIn0..."
    },
    ...
  ],
  ,
  ...
}"

We establish a transport encryption by using Diffie-Hellmann key agreement with the corresponding pipeKeys and invitation salts of the devices. The resulting symmetric key is used to encrypt both the url of the message pipe (the file that contains all encrypted messages) given in the invitation attribute and the contents of this file. If Alice wants to start sending messages to Bob she uses the corresponding device keys as IKa and IKb, the signedPrekey of Bob as SPKb and one of the public keys contained in the onetimePrekeys array as OPKb. In addition to that she generates her own ephemeral key pair EKa. Refer to the X3DH protocol for the details on how to arrive at a shared secret using all of these keys.

In the initial messages that are included in the first and second chain of the Double Ratchet Algorithm we include the following information:

export interface InitialMessageData {
  IK: JsonWebKey;
  EK: JsonWebKey;
  SPK_THUMB: string;
  OPK_THUMB: string;
  AD: string;
}

We identify the selected signedPrekey and onetimePrekey by their respective thumbprints as defined by JWK thumbprint. AD takes the value literally as defined in the X3DH spec. The public keys are serialized using the JWK specification.

The X3DH protocol is asymmetric by nature: a device starts sending messages by downloading a set of (pre-)keys from the server and calculating a shared secret from it. In the next step the recipient receives one of the first messages that includes all necessary information to complete the session handshake.

In our setting the situation is symmetric: Any device can start sending messages as soon as it learns about the public device profile of a contact’s device. Once the other device receives these messages it should either pick up the remote session or adapt its own session it created before. To achieve this we fix the roles of Alice and Bob as described in the OWS spec in advance by using a natural order of public EC identity keys by comparing x coordinates. The device with the smaller key is Alice, the one with the greater acts the role of Bob.

When a device starts sending messages the situation is perfectly symmetric. Each device downloads a set of keys, performs X3DH as specified and starts sending. Only until a device receives the first message, then the state either has to be switched to a new shared secret (in the case of Bob) by performing the corresponding X3DH step. Or, in the case of Alice, just the receiving chain has to be initialized with the shared secret defined by the other device's initial messages:

By doing so we avoid keeping track of more than one session per pair of devices.

Message acknowledgement

We need acknowledgement for messages in order to decide which messages we have to store online (We write a file for all pending messages to cloud storage if the device is offline) for later retrieval at the device of the recipient.

In order to accomplish message acknowledgement we include in each message header the missing messages that are stored in MKSKIPPED as described in the spec. The corresponding header attribute mm is an array that contains chain identifiers (the thumbprint of the corresponding public chain key) followed by the message indices within that chain. Such a JWE header may look this this:

{
  alg: "A256KW",
  enc: "A256CBC-HS512",
  aad: {
    v: 1,
    dh: {
      crv: "P-384",
      kty: "EC",
      x: "mmEa7QxSNTCJMD80hynUq6GJV1Aq8l...",
      y: "wjgt1XqQeGx3XxLJTHjk3zLAYH3Ncr..."
    },
    n: 0,
    pn: 1,
    mm: [
      "gcNwdlmBw4EZIPbrc4V-uN6t7cesDwSeja-SgdeZxKs",
      0,
      1,
      "rKlsCL-DMQOUY_jmlXlOqeOmVZbilOO9Z_3CxiwMrOI",
      0
    ],
    dm: []
  }
}

Note that we include all additional header information that is not part of the JOSE specs in the aad (Additional Authenticated Data) attribute. This includes the protocol version v, the JWK chain key dh, the index of the message in the current chain n, and the length of the previous chain pn. If this would be one of the initial messages then we would include an extra init field in the aad structure.

This acknowledgement procedure can however only capture what the other side knows it is missing. Thus we must retain all messages of the current and the previous chain in addition to the messages mentioned in the header since the other side might be missing messages at the end of the previous chain or in the current chain.

We implement a method called retainStoredMessages that deletes all stored messages but those mentioned in the mm header. We invoke it before DHRatchet so it effectively leaves the stored messages of the previous and current chain alone, see line 7 of this Gist:

Message discarding

If a device A is inactive for more than a month device B would stop encrypting and sending messages for it. Additionally, device B would discard all messages that have been stored so far to avoid bloating the contents of the corresponding pipes connecting A and B. When device B becomes active again we signal the indices of discarded messages in the dm header field of each of the following messages from B to A until those indices are removed from the mm header of A as a reaction to the dm header contents. See also line 9 of Algorithm 2.

Multi-device support

There is not much to say about multi-device support. As we have only one Double Ratchet session per pair of devices there is not much maintenance going on when sending messages between contacts. We have two kinds of messages at the moment: system messages directly address separate devices, and chat messages that address all devices of a contact or group of contacts. If a message is sent to all devices of a contact it gets encrypted separately for each of the sessions.

Future work

Direct JWE encryption to save space

Currently we use A256KW encryption algorithm to encrypt all messages feeding the Signal message key as input for the AES-KW operation. We believe that this extra step doesn't add security to the encryption over using the message key directly to encrypt generate the MAC of the JWK.

Acknowledgements

We like to thank the team of Open Whisper Systems.

Implementing the Signal E2EE protocol for sopher.io was originally published in Becoming sopher on Medium, where people are continuing the conversation by highlighting and responding to this story.

At sopher.io, we want sopher identities to be as useful as possible. So we decided to implement the OpenID Connect authorization flow, ultimately offering the “Login with sopher.io” button to third-party web sites.

OpenID Connect defines three types of flows that can be used by a Relying Party (RP) to perform user authentication at an OpenID Connect Provider (OP):

Code Flow

The Code Flow authenticates the user at his identity provider, e.g., Google, and redirects back with an authorization code. In a second step this code is used to obtain identity and access tokens. The second step takes place via server-to-server communication with the token end-point at the identity provider.

Implicit Flow

The Implicit Flow works without server-to-server communication. The identity provider directly redirects with identity and access tokens included in the fragment of the redirect URI. No backend is needed on the client side. At sopher.io we use this flow to connect to cloud storage providers.

Hybrid Flow

The third flow is a mixture of the Code Flow and the Implicit Flow called the Hybrid Flow.

At sopher.io profiles are hosted by the users themselves. We do not operate any servers to host user data and cannot provide a token end point on our side. This renders the code flow infeasible for us. Additionally we cannot verify users’ identities since we simply do not store anything about them.

The solution to these problems is actually part of the OpenID Connect specification: The Self-Issued Identity Provider. In combination with the Implicit Flow we can offer a fully compliant OpenID Connect implementation for sopher.io accounts.

Self-Issued Identity Provider

A Self-Issued Identity Provider is an entity that cryptographically asserts its identity. It does so by signing the fingerprint of its public key using a signed OpenID Connect id token including the fingerprint and the public key. At first login the RP stores the fingerprint of the public key as the id of the entity. At subsequent logins the RP validates the identity token using the public key included in the id token. How does sopher.io come into play?

The registration attribute of the OpenID Connect Self-Issued Identity Provider request is meant to provide information about the RP such as name, logo, or policy links. We use this field to transmit the client id token that a sopher app obtains upon registration. A sopher.io account can verify the identity of the RP as well as inferring name, logo, and origin information.

Implementing OpenID Connect for sopher.io was originally published in Becoming sopher on Medium, where people are continuing the conversation by highlighting and responding to this story.