Interoperable Private Identity Discovery for E2EE Messaging

Interoperable Private Identity Discovery for E2EE Messaging Google

gih@google.com

Google

fgolu@google.com

ART More Instant Messaging Interoperability (mimi) interoperable E2EE messaging private user discovery This document specifies how users can find each other privately when using end-to-end encrypted messaging services. Users can retrieve the key materials and message delivery endpoints of other users without revealing their social graphs to the key material service hosts. Users can search for phone numbers or user IDs, either individually or in batches, using private information retrieval (PIR). Our specification is based on a state-of-the-art lattice-based homomorphic PIR scheme, which provides a reasonable tradeoff between privacy and cost in a keyword-based sparse PIR setting. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the mimi Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Glossary of terms:

Authoritative Name Server: Final holder of the IP addresses for a specific domain or set of domains.
Client: A software application running on a user's device or computer.
Database: A collection of records all of equal sizes (i.e., padded as appropriate).
Dense PIR: A type of PIR scheme that is used to retrieve information from a database using the index or position of each record as key. This is equivalent to the standard PIR schemes from the literature.
DNS: See Domain Name Service.
Domain Name Service: A system that accepts domain names and returns their IP addresses.
FHE: See Fully Homomorphic Encryption.
Fully Homomorphic Encryption: A type of encryption that allows arithmetic operations to be performed on encrypted data without decrypting it first.
KDS Resolver: A service that helps clients find and download the public keys of other users.
KDS: See Key Distribution Server.
Key Distribution Server: A server holding the public key material that enables a user to securely communicate with other users.
Name Server: Stores DNS records that map a domain name to an IP address.
Partition: A smaller division of a shard that is used to facilitate recursion with PIR.
PIR: See Private Information Retrieval
Preferred Service: A messaging service that a user has chosen as the default.
Private Information Retrieval: A cryptographic technique that allows a client to query a database server without the server being able to learn anything about the query or the record retrieved.
Public Key Bundle: Cryptographic key and other metadata that are used to encrypt and decrypt messages.
Public Key PIR: A type of PIR scheme that uses a small amount of client storage to gain communication and computation efficiencies over multiple queries.
Resolver: A service that helps clients find the IP address for a domain through recursive queries over Name Servers hierarchy.
Shard: A subset of a large database that is divided into smaller, more manageable pieces.
Sparse PIR: A type of PIR scheme that is used to retrieve information from a database of key-value pairs. This is the same as Keyword PIR in the literature.
Transform: A process of converting the partitions in a shard into a format that is suitable for homomorphic encryption computations.

Introduction Outline of design for message delivery bridge and key distribution server discovery mechanisms for interoperable E2EE messaging clients. A DNS-like resolver service stores UserID <-> service pairs that map to key distribution and message delivery endpoints (e.g. Platform1 Bridges). Each service is responsible for an "authoritative name server" that covers its own users and this can be replicated/cached by other providers and retrieved by sender clients using a privacy preserving protocol to prevent social graph leakage.

Functional Requirements For a given messaging service identity handle (Phone number or alphanumeric UserID):

P0 Return receiver service ID to send message payload: can be mapped to endpoints for message delivery and key distribution using standard mechanism -> e.g. Platform1.org/send/, Platform1.org/kds
P0 Return optional default receiver service ID user preference for a given PN/UserID (e.g. default:Platform1.org)

Privacy Requirements

P0 Resolver service should not learn the PN/UserID a client is querying for (i.e. who is sending a message to who)
P0 Resolver service should not learn the public identity of the querying client.
P0 Resolver service should not learn the exact timing of when a message is sent

Privacy Non-requirement Hiding service reachability. All major E2EE messaging services already publish unACL'd reachability information without opt-out i.e. +16501234567, reachable on Messages, Whatsapp, Telegram (not including name or any other info). Therefore this should not be a goal (and would not be feasible to implement).

Proposed solution

Key distribution │ │ │ │ │ │ │ │ │ │ │ Replicate P2 │ │ │ │ │ │ Name Records │ │ │ │ │ │ <──────────────────────── │ │ │ │ │ │ │ │ │ PIR Query │ │ │ │ │ │ PN/UserID │ │ │ │ │ │───────────────────> │ │ │ │ │ │ │ │ │ │ │ │ PIR Query │ │ │ │ │ │ PN/UserID │ │ │ │ │ │ ─────────────────────> │ │ │ │ │ │ │ │ │ │ ╔═════╧══════════════════════╧═══════╗ │ │ │ │ ║Supported service IDs ░║ │ │ │ │ ║ + default service ║ │ │ │ │ ╚═════╤══════════════════════╤═══════╝ │ │ │ │ │ Service IDs │ │ │ │ │ │ & default service │ │ │ │ │ │ <───────────────────── │ │ │ │ │ │ │ │ │ │ │ │ Query │ │ │ │ │ │ PN/UserID │ │ │ │ │ ─────────────────────────────────────────────────────────────────────> │ │ │ │ │ │ │ │ │ │ Return Public │ │ │ │ │ │ Key Bundle │ │ │ │ │ <───────────────────────────────────────────────────────────────────── │ │ │ │ │ │ │ │ Return Public │ │ │ │ │ │ Key Bundle │ │ │ │ │ │<─────────────────── │ │ │ │ │ │ │ │ │ │ ────┐ │ │ │ │ │ Encrypt Message │ │ │ │ <───┘ │ │ │ │ │ │ │ │ │ │ │ │ Send Encrypted Message via messaging providers │ │ │───────────────────────────────────────────────────────────────────────────────────────────────────────────> ┌───┴───┐ ┌────┴─────┐ ┌─────┴──────┐ ┌───────┴────────┐ ┌─┴──┐ ┌──┴───┐ │P1 │ │P1 │ │P1 │ │Authoritative P2│ │P2 │ │P2 │ │ Client│ │ Front End│ │ Name Server│ │Name Server │ │ KDS│ │Client│ └───────┘ └──────────┘ └────────────┘ └────────────────┘ └────┘ └──────┘ ]]> Taking Platform1 client sending to a Platform2 user as an example:

Platform1 name server replicates authoritative Platform2 NS records. There will need to be a shared list of participating services and name server endpoints.
Platform1 client sends key bundle request to Platform1 front end (PIR encrypted PN/UserID)
Platform1 FE gets supported key distribution service IDs, version number + default service=Platform2 via PIR protocol from its own name server.
Platform1 FE queries Platform2 KDS to retrieve public keys.

4.1 Platform1 Client first sends (query and session key) encrypted with Platform2 public key to Platform1 FE.
4.2 Platform1 FE sends encrypted query to Platform2 KDS
4.3 Platform2 KDS decrypts query and session key, encrypts response with session key
4.4 Platform2 KDS sends encrypted response to Platform1 FE
4.5 Platform1 FE forwards to Platform1 client

Platform 1 Client and Platform 2 Client exchange messages through their respective messaging providers.

This provides E2EE interop while only disclosing to gateway service which services a phone number is registered to. In all other respects, gateway services learn no more information than in the non-interop case.

Resolver registration Each service is responsible for registering user enrollments with the resolver.

Preferred service integrity While the preferred service is public, the user should control its value/integrity. As well as ensuring user control, it also prevents spoofing attacks where an attacker A could create an account on a new service that B does not have an account on, and then set it to B's preferred service (see cross-service identity spoofing below). Therefore to prevent anyone but the user modifying the default service value, records must be signed with the user's private key and verified by the sender against their public key. For multiple key pairs across different services, the last key pair to sign the default service bit must be used to change the default. │ │ │ │ Query PN/UserID │ │ ─────────────────────────────────────────────────────────────────────────────────> │ │ │ │ Return supported service IDs + default service preference + signature │ │ <───────────────────────────────────────────────────────────────────────────────── │ │ │ │────┐ │ │ │ Verify default service pref signature │ │<───┘ │ ┌──┴───┐ ┌────┴─────┐ ┌───┴────┐ │Client│ │Service UI│ │Resolver│ └──────┘ └──────────┘ └────────┘ ]]>

Cross-service identity spoofing Today, a messaging service may support one or more ways of identifying a user including email address, phone number, or service specific user name. Messaging interoperability introduces a new problem that traditionally has been resolvable at the service level: cross-service identity spoofing, where a user on a given E2EE may or may not be addressable at the same ID on another service due to a lack of global uniqueness constraints across providers. As a result, a user may be registered at multiple services with the same handles, e.g. if Bob's email is bob@example.com and his phone number is 555-111-2222 and he is registered with Signal and iMessage, he would be addressable at bob@example.com:iMessage, 555-111-2222:iMessage, and 555-111-2222:Signal. In this case, the same userId on iMessage and Signal is acceptable as the phone number can map to only one individual who proves their identity by validating ownership of the SIM card. On services where a user can log in with a username alone, however e.g. Threema and FooService, the challenge becomes:

Alice messages Bob at Bob's preferred service (bob@Threema)
Eve messages Alice impersonating Bob using bob@FooService
Alice needs some indicator or UI to know that bob@Threema isn't bob@FooSercice and that when bob@FooService messages, it should not be assumed that bob@FooService is bob@Threema.

Options for solving this are: 1. Storing the supported services for a contact in Contacts and if a receipt receives a message from an unknown sender, to treat it as spam or otherwise untrusted from the start. 2. Requiring the fully qualified username for services that rely on usernames only - e.g. bob@threema.com vs bob.

Privacy of resolver lookup queries Resolver lookup queries leak the user's social graph - i.e. who is communicating with whom, since the IP address of the querying client can be tied to user identity, especially when operating over a mobile data network. Therefore we propose to use Private Information Retrieval (PIR) to perform the resolver queries. We have evaluated multiple alternative schemes. The proposed solution is based on the Public Key PIR framework by Patel et al with sharded databases. This framework is applicable with any standard PIR scheme such as the open source implementation here. Cost estimates suggest this is feasible even for very large resolver databases (10 billion records).

Proposed protocols A private information retrieval protocol enables a client holding an index (or keyword) to retrieve the database record corresponding to that index from a remote server. PIR schemes have communication complexities sublinear in the database size and they provide access privacy for clients which precludes the server from being able to learn any information about either the query index or the record retrieved. A standard single-server PIR scheme provides clients with algorithms to generate a query and decrypt a response from the server. It also provides an algorithm for the server to compute a response. The Public Key PIR framework can be wrapped around any standard lattice-based PIR scheme. This framework consists of server database setup, client key initialization, client query generation, server response computation, and client response decryption sub-protocols. All operations are over a set of integers with a plaintext modulus.

Server database setup

Sharding: If the database is over 2²⁰ records, sub-divide it into shards of ~1 million unique records each, which is a good balance for privacy and costs. Performing PIR over the databases gives stronger privacy but is more costly. Similarly, running PIR queries over the shards is less costly but gives weaker privacy.
- Sample a hash key K_s for sharding.
- Using K_s, shard the large database of r records into ⌈r/2²⁰⌉ shards based on the hash prefix of the record's unique identifier.
- N.B. The hash key will be provided to clients to determine the shard to query.
Set partitioning boundaries for each shard D: Given a n key-value pairs shard D = {(k₁,v₁),...,(k_n,v_n)}, then
- Compute the number of database partitions as b = n/d₁. Where d₁ is the desired size for each partition. A value of 128 for d₁ works well.
- Sample a partitioning boundary hash key K₁ to generate a target partition for each shard key.
- Compute the hash F₁(K₁,k_i) for each record identifier k_i.
- Sort the hash values alphanumerically and then divide the list into b partitions P₁,...,P_b.
- Store the b partition boundaries beginning hash values B₀, ..., B_b. Note that B₀ = 0, and B_b = |U|-1 where U is the rage for F₁(K₁,k_i).
- N.B. The partition boundaries will be provided to clients and can be stored efficiently (e.g., ~11KB for n = 2²⁰, d₁ = 128, |U| = 2⁶⁴).
Transform each shard: Sample two hash keys K₂ and K_r where K₂ will be used to generate a row vector within each partition, and K_r is used to generate a representation for the transformed database as F(K_r,k_i)||v.
N.B. F(K,k) is the output value from hashing k with key K and || is a concatenation.
For each partition P_i
- Construct a |P_i| x d₁ Platform1 M_i by appending a random row vector from the bit vector derived from (F₂(K₂,k||1),...,F₂(K₂,k||d₁)).
- Construct a |P_i| vector y_i by appending F_r(K_r,k)||v for each (k,v) in P_i.
- Solve for e_i that satisfies M_ie_i = y_i.
Construct the transformed d₁ x b Platform1 as E = [e₁ ... e_b].
The Platform1 E is the transformed Platform1 for shard D.
The clients must download parameters (K₁,K₂,K_r) to query each shard, plus K_s to inform the server of the target shard for a query.

This protocol is completed by the server without any client participation and before answering any client query. Note that a shard must be re-transformed after an update. Shard transform only takes a few minutes.

Client key initialization

The client generates a per-key unique identifier (UID), private key and public key using a fully homomorphic encryption (FHE) scheme relying on hardness assumptions similar to Ring Learning with Errors problem.
The client persists the UID and private key into its local key store, and uploads query-independent parameters UID and public key to the server. These later parameters will enable the server to perform cryptographic operations (i.e., FHE) efficiently.
The server needs to maintain an up-to-date mapping of UID to public key for all clients.
Each client completes this offline initialization protocol before running any query. It also needs to perform it periodically (e.g., weekly or monthly) to prevent server linkability of private queries to the user over an extended period.
The client downloads query parameters from the server:
- Sharding hash key K_s to inform the server of the target shard for a query.
Sets of parameters (K₁,K₂,K_r,B₀, ..., B_b) for each shard.

Client query generation

The client creates a query to retrieve the value corresponding to a database key k as follows:
Select a standard PIR algorithm with server-supported implementation as the underlying PIR scheme.
Compute d = F_s(K_s,k) to identify the shard to query.
Compute j = F₁(K₁,k) to learn which partition contains the desired entry from the downloaded partition boundaries for the shard.
Generate z vector v of length d₁ , ... , d_z . Compute a d₁-length random bit vector v₁ from (F₂(K₂,k||1),...,F₂(K₂,k||d₁)). Compute v₂ as a zero bit vector of d₂ length with only the bit set at ⌊j/⌈n/d₁d₂⌉⌋. Similarly compute v₃ , ... , v_z.
Finally use the underlying PIR scheme and the private key to encrypt the z vector v.
Send v, d and the UID to the server.
N.B. The dimension d_z is typically small; a size of 2 or 4 works well.

Server response computation

The server retrieves the public key for the client's UID, and computes the ciphertext of the value corresponding to the key of interest for the shard d, as follows.
Take the transformed shard E as a d₁x ⌈n/d₁⌉ Platform1 E₁, use the underlying PIR response answering algorithm to compute v₁.E₁, and rearrange the resulting ⌈n/d₁⌉ vector as a d₂x ⌈n/d₁d₂⌉ Platform1 E₂.
Next, compute v₂.E₂, and rearrange the resulting ⌈n/d₁d₂⌉ vector as a d₃x ⌈n/d₁d₂d₃⌉ Platform1 E₃.
The server similarly repeats the computation for the remaining dimensions v₃ ,... , v_z.
The end result is a ciphertext r of the database value corresponding to k. The server sends r back to the client.

Client response decryption

The client uses the underlying PIR response decryption algorithm and private key to decrypt the response r as k_r||v. If F_r(K_r,k) == k_r then returns v otherwise returns null (key not found).

FHE key requirements

At least 128-bit of security
- ElGamal, NIST P-224r1 curve and a 4 bytes plaintext size for fast decryption.
- Gentry-Ramzan, used a 2048-bit modulus
- Damgaerd-Jurik, used 1160-bit primes

Cost estimates In these estimates, we propose using shards of size ~1 million of identifiers. For 1.28 TB (10 billion records), breaking this down into 10,000 shards each of size 1 million records gives a cost estimate for each query as below:

Parameter	Cost estimate
PIR Public Key Size Per Device, including metadata (storage required)	14 MB
Upload Bandwidth Per Query	14 KB
Download Bandwidth Per Query	21 KB
Client Time Per Query	0.1s
Server Time Per Query (Single Thread)	0.8-1s

Note on some assumptions for feasibility:

Resolver queries will be cached (vs requiring a roundtrip for every message) and asynchronous with message sending, therefore 1s latency is acceptable.
It is acceptable for key changes to be communicated reactively on decrypt failure.
Group messaging E2EE is bootstrapped using individual users' public keys and for V1, group state will be stored by the initiating user's service provider. Therefore no additional discovery mechanism is required.

Notes

IANA Considerations This document has no IANA actions.

Normative References Don't be Dense: Efficient Keyword PIR for Sparse Databases n.d. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments The technical description of the private information retrieval framework is based on Sarvar Patel, Joon Young Seo and Kevin Yeo's USENIX Security '23 paper titled "Don't be Dense: Efficient Keyword PIR for Sparse Databases ".