This is the second post in a series of posts describing a secure alternative to applications like WhatsApp. I started with the following statement:
I believe it is possible to build a system with the simplicity and functionality of WhatsApp or Viber, which provides end-to-end encryption, is built on free software and open protocols, that supports federation and is almost decentralised, and that would allow interested companies to turn a profit without compromising any of these principles.
In this post, I will outline the concepts behind the most critical component of the architecture: the directory service.
Outline
I say this is the most critical component, because here lies what makes this architecture different, but also because this is the weakest link in the whole idea. I expect criticism, specially on some security trade-offs, and I hope that people that know better than me can help me improve it.
The directory service is what allows the users to register easily, without using passwords, to be able to receive calls and messages from other users, even if they are not part of the network, and to do all this with a reasonable security model.
Let's get technical
The directory service is basically a DNSSEC-protected DNS zone serving ENUM records, along with public keys associated with each user identifier.
A TLS-enabled API will enable account creation and validation, DNS records publishing, and encrypted records querying.
Applications not supporting that API use standard ENUM querying, and the user manually uses traditional web-based methods for account and records management. This allows interoperability with any existing clients and SIP services.
The service will authenticate users by using the usual methods to probe ownership of phone numbers: sending an encrypted SMS with a secret that the client application uses then to claim the phone number.
This same method can be used to validate ownership of identifiers that are not phone numbers, like pre-existing SIP or email addresses.
Once the user is authenticated, the directory service will publish the user's public key and SIP address, both associated with the phone number.
When a user wants to place a call or send a message, it uses a DNSSEC-enabled resolver to get securely the other party's public key and SIP address. The user can also perform bulk look-ups, to discover which people on theirs address book is already in the system.
These operations disclose an important amount of private data, and I don't think this can be mitigated in an acceptable manner, and therefore the directory service needs to forget the queries as soon as possible, and not to store any logs of these.
Also, DNS queries are not encrypted, and are thus vulnerable to snooping by third parties. To mitigate this, the service needs to implement an encrypted but anonymous API to perform queries, and thus offer extra privacy to clients that support the API.
The idea is to have more than one service running on different domain names, but not many: they need to keep consistency and replicate among them, and the security and privacy implications of one service not being properly implemented or administered are too big.
Therefore, there must not be more than a handful of these, they need to be properly audited, and must not be operated by any for-profit organisation.
Security
The Web of Trust is hard. End users don't like hard. Traditional PKI is prohibitely costly, and broken. OTR is good, but is still not hassle-free.
Using one of the proposed extensions to DANE, we can solve this problem: using DNSSEC, we can have each users' public key published where everybody can retrieve it securely.
This published key can then be used for end-to-end encryption and client authentication with all the components of this architecture.
Who creates the key pair? In the simple case, the client application creates the key pair, and stores it in an appropriate container in the mobile device. It then chooses one of many cooperating directory services, and gets the public key associated with the phone number.
If the private key is lost (lost your phone?), a new pair is generated and published, after passing the same checks of number ownership, and the old keys are discarded. This opens the door for some attacks, but those can be mitigated by having the client application verify the public records periodically, and the service requiring extra checks for key replacement. For example, by also using a challenge sent by email.
What if I want to do things my way? Perfect, you create your keys, and then use the same mechanisms to register with the identity service. Also, you use the service to tell other users to connect to your own SIP server when they want to talk to your phone number.
Does this sound like ENUM? It is ENUM, but better. Just by adding DNSSEC, an unified API, and the capability of publishing key material along with the routing information, you got yourself a reasonably secure way of distributing keys and locating users.
Interaction with other components
Once the user records are published, the SIP server can use the public key to authenticate the user, and removes the need for passwords. The same principle applies to account creation: if the user has published key material under a phone number's record, the SIP server must accept account creation requests for the same phone number, provided these are authenticated with the private key.
If the user wants to switch providers, it is as simple as creating a new account in the new provider, and then updating the ENUM record.
The client application queries the service (and possibly other ENUM providers) before placing a call or sending a message. If the peer has keys published, the client can refuse to communicate if the keys don't match, or the peer is not offering call encryption.
When public keys are not found, the client can downgrade to traditional unauthenticated encryption, or unencrypted communications.
To be continued
In the next posts, I will talk about the overseeing organisation, the SIP service providers, and the client application, and how they all fit together. Stay tuned!
Conceptually, I like where you are going, but...
You say: "These operations disclose an important amount of private data, and I don't think this can be mitigated in an acceptable manner, and therefore the directory service needs to forget the queries as soon as possible, and not to store any logs of these."
I'm not following all of the details of your proposal. However by saying you will publish data via DNS, someone will be storing logs of the queries. At a small US Federal Agency we were required to store logs of all DNS queries for at least a full year - with tape backups, we functionally stored them for 3+ years. There have been discussions of how many years the major ISPs need to retain their DNS logs for. How do you reconcile your statement above with organizations retaining their DNS logs?
I am technically savy enough to run a recursive DNS server on my system - avoiding some of that logging, however some places blatantly make you use their DNS servers. Others like China are faking root DNS servers.
@Warren,
You have a good point there. I think my mitigation proposal is good enough to avoid the problem you are describing. By using the alternative query API over TLS I described, you avoid leaving traces in DNS logs.
Why keep the DNS at all then? To keep interoperability with standard applications, and to allow applications to use their own DNSSEC-enabled resolver, which still travels in the clear, but does not use proxy servers.