Published: 2014-05-16 12:50:10 by Daniele Ricci

Many users have been wondering about security in Kontalk. In this post I'll consider the security concerns I faced and I'm still facing during the development of Kontalk.

Phone numbers

The biggest security implication is phone numbers. Hiding phone numbers to server administrators and to other users is very difficult since they are used as mean of identification. Kontalk uses hashes of the phone numbers in the user ID (something like, which is the SHA-1 hash of +15555245554).
Using decent hardware, by knowing just the country code, you can calculate all of the hash space and find the original value in a relatively short time. It's an easy task to carry out, but you'll have to spend time on that, meaning you have a target.
The hard part comes when the Kontalk devteam is not involved in server administration: despite we have very strong values and we do not give our data to others (of course we are tied to jurisdiction), other server administrators might. That's why we decided to create some sort of democratic network with an internal voting system, used to allow new servers and ban rogue ones. This system is not yet in place (we are still in alpha), but it will be ready at the right time. Further details will follow soon.

SMS provider

Another concern for phone numbers is using a 3rd party SMS provider to verify the numbers. In our case, Nexmo.
Of course it's a company and they have their privacy policy, but the problem is a Kontalk server must know the real phone number to send the verification SMS in the first place, meaning our Nexmo account has a record of all phone numbers that have registered or have tried to register to Kontalk. We really can't do nothing about it. Although we access Nexmo logs only when a user has a problem during registration, in fact we do have the phone numbers of all of our users.

Encryption: end-to-end without OTR

Encryption is another very important security concern. The older 2.2 versions had a weak encryption method which is being replaced by OpenPGP encryption in version 3.0. This new method will do a simple public key encryption using OpenPGP standards. More features such as perfect forward secrecy and deniable encryption will be addressed with a future version having an OTR-like approach.

Trusting server administrators

Last but not least, there is a concern about server administrators. Kontalk is designed to be a community network, meaning that volounteers can rent servers and make them available as Kontalk nodes. Those nodes will have access to all presence data and (unencrypted) messages passing through the server.
A server can prevent login attempts from users registered from another server though: it checks if the server public key is signed by the server that is authenticating the user in that moment. This is the way a server shows "trust" in one another. If anything happens, a revocation of the signature and that server is no longer trusted.
Anyway this doesn't prevent a rogue server from creating forged identities or fake accounts. There are mechanisms to protect users against that, but only when such abuses are discovered — that's because if an abuse is sporadic, it's hard to uncover it.

Still, there's no formal agreement between servers. They all count on mutual trust and spoken deals. This matter will be addressed when Kontalk will grow enough to justify the creation of a nonprofit organization, with an organized team and a more defined path to follow.

Published: 2013-10-26 18:11:16 by Daniele Ricci

Introducing asymmetric encryption has a cost. Because of the decentralized nature of asymmetric keys (i.e. no passwords database), people have to manage their own keys and take responsability for their actions with those keys. This includes losing your device, for example.

If you lose your device and the key pair is inside, the key pair is said to be compromised: anyone using your device will be able to literally impersonate you and encrypt/sign with your former keys. There are a few actions you could take (or have taken):

  • encrypt your keys and ask for a password every time you use Kontalk
  • revoke your keys

The first options is brute-force breakable, so it's not so useful really: it just delays the inevitable.
The second option requires you having a backup copy of your key pair (actually a revocation certificate) and some server to be aware of you wanting to revoke your key pair. Since Kontalk has no concept of permanent key pair storage (it's actually just a cache erasable at any time), even if the rightful owner of the compromised key pair sends a revocation certificate to the server, the server would lose it at the first cache purge, and the "other guy" — the one who found your lost device — can restore it.

To overcome this problem, Kontalk will use this implementation logic: clients can't update their own key pair to the server unless it's the same key (e.g. just a signatures update) or the client has a valid revocation certificate for the key they are about to overwrite. This way, even if there is a cache purge on the server, your new device will be able to overwrite the impostor's key pair.

Of course there is a chance that the impostor succeeds to send a few messages in the meantime: to protect against such cases, the client software will warn users about the inconsistency of the signature on the message.

Published: 2013-07-19 13:36:00 by Daniele Ricci

This extension has been deprecated.

Recently I implemented a first version of public-key driven presence subscription on both server and XMPP client1. The idea is simple: if Alice wants to see Bob's presence and write to him, Bob must sign Alice's public key first — and vice-versa. Server can verify each other's public key signatures and either allow or deny presence subscription and message delivery. This can bring some benefits:

  • server won't need to store roster list — since Kontalk is a roster-less system, this is a very good way to achieve it and store it in a user-controlled way.
  • Many will start to use Web of Trust — PGP web of trust is still confusing to some users; using a system like this can broaden adoption of a decentralized web of trust using open and standard tools.

Here is how the protocol looks like. It's an extension to the normal presence subscription flow.

Alice wants to subscribe to Bob.

<presence id='xk3h1v69'

Server checks if Alice's public key has been signed by Bob. If that's the case, subscription is accepted immediately: server will reply with presence subscribed.

If Alice's key is not signed by Bob, server forwards the presence subscription request to Bob, injecting Alice's public key:

<presence id='xk3h1v69'
    [Alice's public key]

Public key might be included using XEP-0189 with the pubkey element inside the presence stanza.

At this point, Bob can decide to either sign Alice's public key or reject the subscription.

<presence id='xk3h1v69'
    [include Alice's signed public key]

Refusal is achieved in the usual way — presence unsubscribed stanza.

Obviously to make this work, both users have to sign each other's key. Eventually servers will use those signatures to check if message delivery and presence subscription are allowed.

I recently proposed this idea to the XMPP standards list but I guess they didn't feel so happy about it — actually they didn't even reply. If anyone has opinions or comments please post them to the mailing list.

  1. androidclient genkeypair branch 

Published: 2013-06-15 16:15:46 by Daniele Ricci

I've just started to contribute to Bouncy Castle to implement RFC 6637. I'm having a few... "difficulties" I hope to solve thanks to the help of BC developers, but I really want to go through it because having elliptic curve keys is very important to Kontalk.

Because of the very small key and signature sizes compared to the actual PGP standards (RSA, DSA, ElGamal) and being much stronger, ECC will be a major part of Kontalk development. The primary benefit of using ECC in Kontalk is key size: having smaller keys means smaller signatures, less bandwidth, less storage capacity for servers (and clients too).

Asymmetric-encryption-driven privacy lists and invitation system will probably require clients to sign or encrypt the list of allowed buddies, probably signing it with each buddy's public key. This could mean a lot, thus a big bunch of data to be exchanged between servers and clients and between servers.

This part is addressed by issues 48, 54 and 55. If you have any ideas please head there and post them, we really need help :-)

Published: 2013-04-13 23:47:40 by Daniele Ricci

Kontalk is spreading at a nice pace, at an average rate of 0.2 new users per minute, excluding the 21st March peak. Donations keep coming in and development is going on. I've been having some healthy problems this 2 past weeks - apparently I'm overstressed or something like that - so I've slowed down a bit.

Currently I'm examining the possibilities and implications of encryption in Kontalk XMPP. Choosing GPG was actually a very hard choice: keys are big, server-side ops are a bit messy (gpgme), but it's a too widely adopted standard to be ignored. There is even a XEP for that so I'm not going to reinvent the wheel.

GPG has elliptic curve encryption already in beta, so hopefully we'll get that eventually and migration would be easy. So key size issue solved :-)

Server-side I'm using gpgme, which is a wrapper around the gpg executable (...), unfortunately there isn't much better than that. Eventually I will make my own implementation (anyone up for the task?).

XMPP server already has a working ad-hoc SASL mechanism for GPG challenge-based authentication. Keys for Kontalk usage have the Jabber ID in the e-mail field, a custom user-defined name field and some special comment field (e.g. Kontalk: resource name).