United States Patent

The Crosspass protocol is protected by the United States patent US11658823.

Overview

There are two widely used methods to transfer confidential data. The first method constitutes sending URLs containing lookup identifiers that reference data stored in the cloud. When a recipient accesses one of such URLs, the data are retrieved from the cloud and the URL expires. But are the data getting deleted from the cloud afterwards? There is no way to verify this and users must trust the service operator. By either malice or mistake confidential data may remain in the cloud. At some future time the data may be stolen by an attacker.

A variant of this scheme is to store merely encrypted blobs in the cloud and to include the decryption keys in the URLs. Recipients download blobs from the cloud and then decrypt them. However, because these URLs must be sent by some medium (email or IM), there is no guarantee that the decryption keys themselves would not linger in the cloud. Again, the attacker could obtain confidential data, this time by harvesting both the encryption keys and the blobs.

The second method involves asymmetric cryptography and is used by Instant Messengers. They offer end-to-end encryption by storing public keys of users in the cloud and brokering an exchange of these keys. This requires that users trust server APIs to give out correct public keys. A compromised server may send an attacker’s public key, thus positioning him as a Man in the Middle (MITM) who can eavesdrop on the communication and impersonate users.

In order to verify that the public keys are correct, users must use a secondary communication channel to verify the fingerprints of the public keys. However, the fingerprints are as long as four credit card numbers and are bewildering. As a result, public key verification is not enforced by IM apps and users often do not know that they must do it for the end-to-end encryption guarantee.

Crosspass takes a third approach by requiring that users exchange short verification codes (PINs). These codes facilitate negotiating a symmetric encryption key and authenticating the communicating parties. This does not inconvenient users because they are already accustomed to short verification codes when they sign into websites.

The Crosspass server, unlike servers supporting Instant Messengers, does not broker public keys. Consequently, user’s devices need to be online at the time of the transfer in order to communicate peer to peer. Because mobile phones are almost always online either through WiFi or Cellular Data, Crosspass is designed as a mobile app.

Security Model

Crosspass assumes that,

• The mobile device of the sender and the recipient have not been compromised.
• If the PIN is intercepted by a third party, the intended recipient will use the PIN earlier than the third party.

Protocol

The protocol requires two legs of communication between the sender and recipient and takes on average under 5 seconds.

sequenceDiagram
    actor Alice
    participant Server
    actor Bob
    Note left of Alice: (a) store payload on device <br> (b) generate random PIN
    Alice->>Server: Register device
    Note left of Server: reserve new lookup ID
    Server->>Alice: lookup ID
    Alice-->>Bob: communicate lookup ID and PIN out-of-band
    Bob->>Server: retrieve by lookup ID
    activate Bob
    Note right of Bob: wait for response
    Server->>Alice: relay by<br>Push Notification 
    Alice->>Server: challenge 
    activate Alice
    Note left of Alice: wait for response
    Server->>Bob: relay
    deactivate Bob
    Note right of Bob: derive shared secret
    Bob->>Server: challenge answer
    activate Bob
    Note right of Bob: wait for response
    Server->>Alice: relay
    deactivate Alice
    Note left of Alice: derive shared secret
    Alice->>Server: encrypted payload 
    Server->>Bob: relay
    deactivate Bob
    Note left of Server: free lookup ID
    Note right of Bob: decrypt payload

Password Authenticated Key Exchange (PAKE)

Crosspass uses the oblivious pseudorandom function (OPRF) described in the OPAQUE protocol to authenticate the two mobile phones peer to peer.

Crosspass uses a cryptographic blinding technique to hide the PIN from the relaying servers and to establish a symmetric key securely. To do this, Crosspass uses the Curve25519 Elliptic Curve group for cryptographic operations. This group has $8q$ elements, an identity element $O$ and an abstract addition operation $\oplus$ on the elements. The value $q$ is a large prime number slightly bigger than $2^{252}$. By Lagrange theorem it has a subgroup $G$ with $q$ elements. Because $q$ is prime, this subgroup is cyclic and each of its elements $P$ is a generator. We can list the elements of $G$ as $O, P, P \oplus P, P\oplus P \oplus P$, … This list loops back onto itself once P is added to itself $q$ times. Define $O = 0P$ and rewrite the same list as, $$0P, 1P, 2P, …, (q-1)P$$ The integer multipliers $0,1,2,…,(q-1)$ of $P$ are called scalars. Because these scalars cycle between 0 and $(q-1)$, they are integers modulo $q$. If $r^{-1}$ is an inverse of $r$ modulo $q$, then for any $P$ in $G$: $$r^{-1}(rP) = P$$

Let $h$ be a hash-to-curve function that maps arbitrary strings to the elements of $G$. Designate a PIN by $x$ and let $P_x = h(x)$ be an element of $G$, represented as a 32-byte value.

1. The recipient’s device selects an ephemeral 32 bytes long random scalar $r$ and “mixes” the PIN using scalar multiplication, $$ P_α = rP_x $$ Using the TweetNacl library this would be computed with scalarMult($ r, P_x $). An eavesdropper who captures $P_a$ would not be able to recover $x$ because he is “blinded” by an ephemeral value $r$ which is unknown to him.

2. When the sender’s Crosspass app receives $P_α$, it uses another random scalar $k$ (also 32 bytes long) to compute the following two values which it sends to Bob’s mobile device,
   $$ P_β=kP_α $$ $$ V=kP_0 $$
   Here $P_0$ is the generator of $G$, also known as the base point. Using the TweetNacl library, $V$ would be computed as scalarMultBase(k).

After these values have been exchanged, both Alice and Bob can derive the same symmetric cryptographic key.

Let $r^{-1}$ be the inverse of $r$ in group $ Z_q^{*} $ (which can be computed in polynomial time) and consider the scalar product of this value with $P_\beta$:

$$ r^{-1} P_β = r^{-1} (kP_α) = r^{-1} (k (rP_x)) $$

We can reorder the scalars as $r^{-1} r k$ to observe that the $r$ blinder “cancels out” and that we get the equation,

$$ r^{-1} P_β = k P_x $$

The left side of this equation can be computed by Bob and the right side can be computed by Alice. Therefore, Alice derives the encryption key by, $$ H(x, V, kP_x) $$ where $H$ be the SHA-256 hash function. Whereas, Bob derives the encryption key by, $$ H(x, V, r^{-1} P_β) $$

Now both Alice and Bob have the same 32 bytes long symmetric key and further encryption proceeds by conventional means. In addition to deriving the same key, the protocol ensures that each side had derived the same key before the encrypted payload is released. This allows to (a) mark the exchange as completed if the two sides have authenticated, and (b) to detect a brute force attack on the PIN and to deny requests after 3 failures.

Symmetric Cryptography

The symmetric cryptography is based on the American Encryption Standard (AES) with 256-bit keys and Galois Counter Mode (GCM) blocks.

Push Notifications

The protocol requires Alice’s mobile device to have an Internet connection (WiFi or Cellular Data) when Bob initiates the first leg of communication. However, her mobile app does not need to be running at that time because it will be activated by a Push Notification. (On iOS this functionality is implemented using a Notification Service Extension.)

Pseudo Anonymity

Crosspass does not require users to login and it does not ask for phone numbers or email addresses. Simply opening the app allows one to use it.

However, Crosspass relies on Push Notification delivery via the Apple Push Notification Service (APNS) for iOS and via the Firebase Cloud Messaging (FCM) for Android. On iOS this exposes Alice’s device ID which Apple Inc. could use to link Alice to a Lookup ID of the note.

Also, Crosspass verifies in-app purchase receipt of the sender’s side. If Alice uses iOS, then Apple Inc. can use this information to link Alice to a Lookup ID of the note. Similarly, if Alice uses Android, then Google LLC can use this information to link Alice to a Lookup ID of the note.

Brute Force Attacks

• If Alice’s device observes a wrong PIN three times, the note is locked and cannot be retrieved by Bob even if he provides the correct PIN. Alice must manually unlock the note before Bob can retry. This prevents a brute force attack on Alice’s device.

• If Bob gets an error message that he entered a wrong PIN five times in a row, then the Crosspass app causes him to wait a day before retrying. This prevents a brute force attack on Bob by a MITM impersonating Alice.

Timing Attacks

By the way of constant time computation, Curve25519 shields the encryption from CPU side-channel timing attacks. However, timing data can associated the sender and recipient at the network level, nullifying the anonymity of the exchange. For maximum anonymity the recipient should avoid using an IP address that could be connected to him. The recipient can dissaciate himself from the IP address by using a public Wi-Fi network. (Note that when a mobile device connects to a Wi-Fi network, it already spoofs the MAC address (iOS: Settings, Wi-Fi, Settings, Private Wi-Fi Address). This way the operator of Wi-Fi router, will not be able to learn the recipient’s identity.)

What’s more, the real-time timing data may also set off a phishing attack against one or both parties. For example, when the recipient starts a Crosspass retrieval, the attacker can make the retrieval fail (for example, due to a forced network outage) and then send the recipient an email asking him to reveal the PIN. By staying anonymous to the attacker, the likelihood of such attacks is reduced. For Push Notifications, the sender divulges his mobile device ID to the Crosspass server, therefore this isn’t entirely feasible in his situation. An adversary who is able to connect this data to the sender’s identity and initiate a Phishing campaign via a secondary channel (email, SMS, etc.). The sender needs to be security aware in order to defend against this attack: he needs to be able to spot a phishing attempt and keep his PIN private. Except from the Crosspass mobile app, Crosspass will never request that you input your PIN.

On-Device Storage

Data on the device is deleted after two weeks at the latest. When the shared item (note or password) is transfered to recipient, it is deleted on the sender’s mobile device immediately. A received item remains on recipient’s mobile device for a day and then gets deleted.

Crosspass stores a cryptographic key on the mobile device. The key is not backed up to the cloud and is only accessible to the Crosspass app. Confidential data is encrypted with this key and is stored in a ciphertext form in a local database on the device.

Crosspass blanks the screens when the app is placed into background by the operating system. This avoids confidential data leaking via screenshots which the operating systems takes for performance reasons.

Denial of Service (DoS)

Crosspass verifies device authenticity and throttles accesses by IP address.

The Crosspass API checks Alice’s device authenticity when her device wants to share a new item. For iOS, it relies on the Device Check and App Attest APIs. For Android, it relies on the Play Integrity API.

Verifications are necessary to prevent a sender’s Denial of Service attack on the availability of lookup IDs. (The lookup ID consists of four case-insensitive letters, therefore the maximum number of reserved lookup IDs are less than half a million.) Verifications are also necessary to avoid a recipient’s attack causing too many Push Notifications to senders’ devices.

In future versions of Crosspass, whenever device verification is insufficient to prevent DoS attacks on lookup ID reservation, a CAPTCHA would be shown. This would be limited only to users who have a public IP from which unusually many requests originate.