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$, an abstract addition operation $\oplus$ on the elements, and the value $q$ is a large prime number slightly bigger than $2^{252}$. By Lagrange theorem this group 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$, … such that the list loops back onto itself once P is added to itself $q$ times. Define $O = 0P$, and $nP$ as $P$ added to itself $n$ times. Now, we can 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, hardened with Scrypt, 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.

Scrypt

As mentioned above, the hash-to-curve function is hardened by Scrypt, which raises the cost of a brute force attack. The input to it is formed from the concatenation of the PIN, note’s lookup ID, and a timestamp nonce. The timestamp helps prevent replay attacks because the sender’s device checks that the retrieval request is fresh.

In and integrated setting, such as with the Crosspass Slack plugin, a salt known to both sender and recipient is added to the Scrypt input.

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.

Using the same PIN on many lookup IDs

An attacker can attempt to access 100,000 random notes with the same PIN. This attack scenario can occur if the attacker gains full control of the Crosspass server, or if he can bypass throttling mechanisms by using a botnet.

Since there are only 10,000 possible PINs, there is a statistical chance that some notes will have that exact PIN. This attack is partially mitigated by requiring the recipient to use a Scrypt hash function with inputs including a timestamp nonce, lookup ID, and the PIN. This increases the computational cost of the attack by preventing replay attacks.

To further prevent this attack, the recipient must pass a second factor authentication (2FA) challenge described in the next section. However, it’s up to the sender, to decide if his note warrants the extra work required for the 2FA step. When creating a new share, the sender can opt in to 2FA.

In the case of Crosspass Slack integration, the sender and recipient share a direct message (DM) channel, and the explicit 2FA step is not needed: a random salt is added to the Retrieve button inside Slack by posting to the DM channel directly from the sender via Slack’s response_url mechanism. This salt is known only to Slack — but not the Crosspass server — and is included in the OPAQUE input.

Anonymous 2FA

Normally, second-factor authentication (2FA) comes in the form of a short OTP code users receive via email or SMS. But for Crosspass, the 4-digit PIN serves as the first factor. Also, emailing or texting recipients as part of the authentication flow would deanonymize them. Thus, Crosspass uses a different approach that preserves anonymity.

For the second factor authentication, the recipient answers a question about himself that is easy for the true recipient but difficult for an attacker to guess—such as the recipient’s phone number or email address. The sender will know something about the recipient from the means by which he is communicating with him (e.g., WhatsApp, Telegram, email). Thus, while creating a new share, the sender is asked:

What do you know about the recipient? Pick one:

• His email address
• His phone number
• His username on:
  • Telegram
  • Signal
  • Twitter/X
  • Other

Note: This will not be exposed to servers and will not deanonymize the recipient.

When the time comes for the recipient to answer the chosen question, he is shown a hint—after all, he might have two phone numbers and several active email addresses. The hints take the following form:

• email m...g@gmail.com
• phone number 3xx-7xx-5xxx
• Telegram nickname @b...z

The question, so as not to be spoiled by the hint, must have at least as much entropy as a 4-digit PIN to avoid weakening the security of the system. For this reason, the hint should also omit the length of the nickname or email prefix. (Note that three letters already provide more entropy.)

The question hint is transferred to the recipient in the challenge leg (see flow chart above), and the answer must be returned as part of the challenge answer leg. This way, the hint is never exposed to the Crosspass server. (Otherwise, an attacker could retroactively deanonymize the recipient if he later gains access to the sender’s contact lists.)

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.

Exploits in Files

The Crosspass mobile app allows transferring JPEG images and (soon) PDFs. Both formats can harbor exploits and are carefully handled.

When one normally emails images and PDFs, they are validated by the webmail service (e.g., Gmail). The downside, of course, is that the file attachments are exposed to a third party. In contrast, in an E2EE setting, the safety check must be performed by the recipient’s device.

Crosspass takes the approach of simply stripping anything that could contain exploits before the files are exposed to the recipient.

JPEG

All images are converted to JPEG before they are sent and are reduced in size—sufficient to remain suitable for printing photographs of ID documents. On the receiving side, it is considered an error if the format is not a valid JPEG or if the data is too large. Second, the image is safely checked for a decompression bomb. Finally, all EXIF metadata is removed by redrawing the image on a clean canvas and returning only the rendered result.

PDF

For PDFs, all active scripting elements are removed. On iOS, the PDF is completely flattened using the “print-to-PDF” functionality that iOS provides. On Android, this cannot be done, so all scripting elements, launch actions, and most annotations (including embedded files) are removed.

Denial of Service (DoS)

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. The remaining discussion concerns the case when different lookup IDs are being requested.

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

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.

Both CAPTCHA and device attestation methods can be circumvented through inexpensive manual labor, rooted mobile devices, or language model generators. The Money Hold mechanism, however, raises the cost of attempting to brute-force PINs. Here’s how it works: the in-app purchase system on both iOS and Android is used to charge a set amount to the recipient—let’s say \$10 for this example. The Crosspass server will only forward the Push Notification once it verifies a proof of purchase by checking with the relevant store server-to-server (either the App Store or Play Store). If the sender releases the secret message, the Crosspass server observes this event (but not the encrypted content) and then refunds the \$10 to the recipient. However, if there are four incorrect PIN attempts, the recipient forfeits the \$10.

The money hold is activated only if it is detected that the server is under a heavy attack. 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 money hold is activated. The actual amount held must grow in proportion with the attempted abuse of the Crosspass server.

In summary, this layered approach allows the app to remain simple to use and to mitigate DoS attacks with certainty. Please note that CAPTCHA and Money Hold are not yet implemented.

DoS when the Crosspass server is compromised

Above approaches do not prevent abuse of the sending devices if the Crosspass server itself is compromised. However, the Money Hold concept can be enhanced so that the sender requires the Crosspass server to place funds in escrow when initiating a Push Notification. This can be achieved using a cryptocurrency that supports smart contracts or equivalent features. With this setup, upon successful PIN entry, the escrowed amount is returned to the Crosspass server. If the attempt fails, however, the funds remain on hold for an extended period.

The senders’ devices query the Smart Contract to determine the total funds the Crosspass server currently has on hold. Based on this information, the devices set new minimum amounts that the Crosspass server must escrow for subsequent transactions. These required hold amounts increase exponentially relative to the current total held in escrow. Consequently, a brute-force attack would compel the Crosspass server to continually lock up growing amounts of funds, making such attacks increasingly costly.

Longer Lookup IDs

The lookup ID is designed to be 4 letters for convenience: it’s easy to type it while looking at it on another device or window, without complex copy-paste flows which increase the attack surface. However, when integrating Crosspass with other communication apps (Slack, Microsoft Teams, and Gmail), it can be arranged that the lookup ID never needs to be typed manually. In this case, the lookup ID can be longer and more cryptic. But to keep the longer lookup IDs working with the mobile app as well, they are designed as follows:

ABCD
ABCI-DEFG
ABCI-DEFI-GHJK

The generation rules are:

• all codes use only uppercase letters
• 4-letter IDs do not use the letter I
• 8-letter IDs have the letter I in the 4th position
• 12-letter IDs have the letter I in the 4th and 8th positions

The Crosspass mobile app UX will expand to ask for more letters when the user types I in the last input square.

With such 8-letter lookup IDs, there are 7 random letters, because the letter I is fixed. (Note that the letter O is also not used.) This gives 24^7 possibilities, no less than 4.5 billion variants. A 12-letter lookup ID gives more than 63 trillion possibilities.

The policy on using longer lookup IDs can take the approach to further limit the danger of Denial-of-Service attacks. For instance, if a user creates many notes in quick sequence (perhaps he is experimenting or testing some integration), the server allocates them with longer IDs.

One possible policy is to always create longer IDs for notes from new app installations. This prevents someone from creating an attack consisting of many fresh installations. The time when an app gets to register a short note is randomly chosen to avoid all new installations unlocking together and using up short IDs in sync.