Interoperable Private Identity Discovery for E2EE Messaging

2.1. Functional Requirements

For a given messaging service identity handle (phone number or alphanumeric UserID):¶

1. Endpoint discovery: discover receiver service IDs to retrieve public key material and send message payload e.g. Platform1.org/send/, Platform1.org/kds¶

2. Default service discovery: Discover optional default receiver service ID user preference for a given PN/UserID (e.g. default:Platform1.org)¶

3. Global uniqueness: Fully-qualified service identifiers should be globally unique¶

4. Key verification (P1): Provide an independently trusted party to assert and verify the association between a public key and a UserID¶

2.2. Privacy Requirements

1. Social graph: Resolver or discovery services should not learn the PN/UserID a client is querying for (i.e. who is sending a message to who)¶

2. Querying user identity: A resolver service should not default to sharing the querying user identity with other resolver services when it requires their help for discovery¶

3. Metadata: Resolver service should not learn the exact timing of when a message is sent¶

2.3. Other Non-functional Requirements

1. No single entity should be financially responsible for resolving all identity queries (e.g. even within a geographical region)¶

2. Costs for each participating entity of storing and querying key records should be proportional to their number of participating users¶

3. Performance should support each client querying each of their contacts at least once every 24 hours¶

2.4. Non-requirements

1. Hiding service reachability: This is the link between a UserID and a service. 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).¶

2. Hiding the value of UserIDs or public keys: e.g. the existence of the PN, +16501234567¶

3. Hiding the association between a public key and a UserID: e.g. PN +16501234567 has pubkey x¶

4. Contact lookup by name (or anything except username)¶

3.1. Key distribution

Taking Platform1 client sending to a Platform2 user as an example:¶

1. Platform1 name server replicates authoritative Platform2 NS records. There will need to be a shared list of participating services and name server endpoints.¶

2. Platform1 client sends key bundle request to Platform1 front end (PIR encrypted PN/UserID)¶

3. Platform1 FE gets supported key distribution service IDs, version number + default service=Platform2 via PIR protocol from its own name server.¶

4. 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¶

5. 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.¶

3.2. Resolver registration

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

3.3. 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.¶

3.4. 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.¶

4.1. 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 [PIRFramework] 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. The appendix provides the protocol messages in protocol buffer format.¶

4.2. 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¶

  • Damgård-Jurik, used 1160-bit primes¶

4.3. 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:¶

Note on some assumptions for feasibility:¶

1. Resolver queries will be cached (vs requiring a roundtrip for every message) and asynchronous with message sending, therefore 1s latency is acceptable.¶

2. It is acceptable for key changes to be communicated reactively on decrypt failure.¶

3. 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.¶

4.4. Notes

5.1. Appendix

The protocol messages are specified in protobuffer format in this appendix.¶

syntax = "proto3";

package mimi.discovery.pir;

// PirParameterRequest represents a request from a client to a server to
// fetch database and cryptographic parameters for querying a database.

message PirParameterRequest {
  // The protocol version for PIR.
  uint32 protocol_version = 1;

  // Used to prevent replays; request fingerprint.
  string nonce = 2;

  // The unique identifier of the client.
  string uid = 3;

  // The PIR scheme that the client wants to use.
  PirScheme pir_scheme = 4;

  // The public key of the client.
  repeated bytes public_key = 5;
}

// PirParameterResponse represents a server's response to PirParameterRequest
// and it contains database and cryptographic paramaters to use for quering the
// database using PIR.

message PirParameterResponse {
  // The protocol version for PIR.
  uint32 protocol_version = 1;

  // Used to prevent replays; request fingerprint.
  string nonce = 2;

  // The unique identifier of the client.
  string uid = 3;

  // Status of the request.
  PirStatus response_status = 4;

  // The PIR scheme negotiated from the client request.
  optional PirScheme pir_scheme = 5;

  // A map of server-supported PIR schemes to their paramaeters.
  map<PirScheme, PirParams> pir_schemes = 6;

  // The shard hash key to identify subdatabase cointaining a keyword.
  HashKey shard_key = 7;

  // parameters for sub databases
  repeated PirSubDbParameter sub_db_param = 8;
}

// PirSubDbParameter represents a subdatabase partitioning parameters

message PirSubDbParameter {
  // The hash key of the partition boundary.
  HashKey partion_boundary_hash_key = 1;

  // The hash key of the row vector.
  HashKey row_vector_hash_key = 2;

  // The hash key of the record representation.
  HashKey record_representation_hash_key = 3;

  // The beginning hash values for the partition
  // boundaries for a single shard.
  repeated PatitionBundaries partition_boundaries = 4;

  // The size of the database.
  uint32 database_size = 5;

  // The size of the largest record.
  uint32 record_size = 6;
}

// PirRequest represents a sparse PIR request to a server for retrieving a
// database record.

message PirRequest {
  // The protocol version for PIR.
  uint32 protocol_version = 1;

  // Used to prevent replays; request fingerprint.
  string nonce = 2;

  // The unique identifier of the client.
  string uid = 3;

  // The PIR scheme that the client wants to use.
  optional PirScheme pir_scheme = 4;

  // The shard ID of the record to be retrieved.
  uint32 shard = 5;

  // The encrypted vector of the query.
  repeated bytes encrypted_vector = 6;
}

// PirResponse represents a PIR server's response to a PirRequest.

message PirResponse {
  // The protocol version for PIR.
  uint32 protocol_version = 1;

  // Used to prevent replays; request fingerprint.
  string nonce = 2;

  // The unique identifier of the client.
  string uid = 3;

  // Status of the request.
  PirStatus response_status = 4;

  // The encrypted response.
  repeated bytes encrypted_response = 5;
}

// PatitionBundaries represents the beginning hash values for the partition
// boundaries for a single shard.

message PatitionBundaries {
  // The hash values of the partition boundaries.
  repeated string boundary = 1;
}

// HashKey represents a cryptographic hash key.

message HashKey {
  // The hash key.
  repeated bytes hash_key = 1;
}

// PirParams represents the paramaters of a PIR scheme instance.

message PirParams {
  // The number of levels of recursion used in the PIR scheme.
  optional int32 levels_of_recursion = 1;

  // The modulus used in the PIR scheme.
  repeated bytes modulus = 2;

  // The plaintext modulus used in the PIR scheme.
  repeated bytes plaintext_modulus = 3;

  // Other parameters used in the specific PIR scheme.
  repeated bytes other_params = 4;

  // Reserved values.
  reserved 5, 6, 7;
}

// PirScheme represents an indexed-based PIR scheme .

enum PirScheme {
    // Scheme not specified
    PIR_SCHEME_UNSPECIFIED = 0;

    // XPIR scheme based on the Ring Learning with Errors (Ring-LWE) problem.
    PIR_SCHEME_RLWE_XPIR = 1;

    // Add more PIR schemes that we might want to support.
}

// PirStatus represents the PIR server response codes.

enum PirStatus {
  // The PIR scheme selected by the client is supported.
  PIR_SCHEME_MATCHED = 0;

  // The PIR scheme selected by the client is not supported, but the server
  // suggests a list of supported schemes.
  PIR_SCHEME_SUGGESTED = 1;

  // There are problems with the request.
  PIR_REQUEST_FAILURE = 2;

  // The response was successfully computed from the request.
  PIR_RESPONSE_SUCCESS = 3;

  // The response computation failed.
  PIR_RESPONSE_FAILURE = 4;
}