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)

Each shared note in Crosspass is uniquely identified by just four letters, allowing for a maximum of 450,000 active shares at any given time. A share locks up if someone tries to retrieve it three times with the same random four-letter code and random PIN. Therefore, a large-scale denial-of-service attack can attempt to lock as many shares as possible by doing this for as many random 4-letter codes as possible. Since DoS attacks are rare, mitigation support should not cause the app to be hard to use when a DoS attack is not occurring. For this reason, Crosspass takes a multistage approach,

1. Device Attestation
2. CAPTCHA
3. Recipient 2FA

First, Crosspass relies on device attestation services of Apple on iOS and Google Services on Android. Crosspass interfaces to their APIs in order to verify that the user is using a physical device and not a simulator.

Second, some cellular network operators place mobile customers behind a single public IP address. A CAPTCHA is displayed if an excessive number of API calls are coming from the same IP address. (This feature will be included in a later app release; it is not yet ready.)

Unfortunately both CAPTCHA and device attestation can be bypassed by cheap manual labour, rooted mobile devices and LLM generators. Therefore, the ultimate mitigation requires a protocol solution.

Note that the sender’s device notifies the Crosspass server when the PIN is wrong. The server, in turn, tracks the total count of wrong PINs for active shares. If the number of active shares is $N$ and the number of wrong PINs is $M$, then the ratio $R = M/N$ can be used to detect a DoS attack early. If $R$ is greater than a certain threshold (e.g. $0.1$), then the server requires recipients to send a 2FA OTP to the senders by another channel. (A recipient may use the same communication channel from which he received the lookup ID and PIN). A sender then must enter the received OTP into his Crosspass app in order to whitelist a recipient. Until R drops below threshold, retrieval requests from non-whitelisted recipients are dropped and do not reach the senders’ devices. (Note that this feature will be included in a later app release; it is not yet ready.)

In addition to these mitigations, the number of API requests to retrieve a particular share are throttled irrespective of the originating IP or device. This limits the total number of Push Notifications to a particular device, thereby mitigating a targeted attack against that device.

In summary, this layered approach allows the app to remain simple to use and to mitigate DoS attacks with certainty.