UK’s GCQH is at it again. Now with a bold proposal to request Apple and other companies to build backdoors into their real-time chat apps, as this article reveals. And the weird things is, Apple and the bunch may be forced to comply since they are hosting those chats. But PassLok will fare quite a bit better, as the post explains.
This is because the real-time chat built into PassLok and other apps of mine is not hosted by PassLok. Or anyone, for that matter. It uses the industry-standard (except for Apple) Web-RTC protocol, which connects client devices directly to one another rather than through a hub like most chat apps. This is a breakdown of how PassLok chat works:
- Alice wants to initiate a secure chat with Bob, plus maybe Carol and a few others. She already has those people Locks (public keys, in PassLok). So she makes a special chat invitation, including a short message (as for telling everyone the start time), the type of chat (text, audio, or video, plus files), a “room” label, and a random password, all of it encrypted so only those persons can decrypt them, plus herself. She sends the invitation, which looks like a piece of gibberish text, to all of them by email, text, or whatever.
- Bob gets the invitation and decrypts it in PassLok, which displays the short message and offers to open the chat window. If he clicks OK, the browser downloads the chat app code from PassLok.com in the Netherlands (it may be cached, if he ran it before) and starts it in a frame within PassLok that nevertheless is isolated from the rest of the code. The page asks for a name to be used within the session and, if Bob is the first to open the invitation, displays a button to Start the chat. If Bob is not the first, the button says “Join” instead.
- By this time, the app has contacted Firebase.io and sent it the room label, which is made of a pair of words chosen randomly, so it can collect the participants’ IP addresses and relay them to one another. Once Bob clicks “Start”, the room is officially started and Firebase.io looks up Bob’s IP number (Bob cannot do so automatically, especially if connected to a local network) and stores it so other joining the chatroom can get it.
- Let’s say Alice decrypts the invitation now and is presented with the same chat page, which has a “Join” button (because the app has asked Firebase.io whether or not that chatroom already exists). After she supplies an alias and clicks the button, the following happens: her app connects with Firebase.io and gets Bob’s IP number, along with those of other correspondents who may have joined already; then her app sends a message to Bob directly, asking to begin a WebRTC-protocol chat; there’s a few back and forth exchanges similar to those involved in a TLS connection (as in https: web pages); before the connection is completed, Alice sends in the random password that was encrypted into the chat invitation, and which Bob also knows (but not Firebase; they only got the chatroom name); if the password is the same that Bob knows the connection is completed, starting from Bob’s side, otherwise it fails; Alice’s machine gets notified and the chat starts on his side as well. This process is repeated between Alice and every other correspondent whose IP address was stored at Firebase when Alice clicked “Join” so that all connections are between pairs of machines, not through a hub.
- The chat itself is encrypted end-to-end as in the TLS protocol, between each pair of participants. There is an ephemeral session key for each pair, so that an eavesdropper cannot retrieve the chat data without it.
The GCQH would have a tough time with this:
- If they force Firebase to turn in what they have, they’ll get a chatroom name and a bunch of IP numbers, and nothing else. They could try to locate the participants by their IP numbers, assuming they are not using a VPN or similar. Or they could try and inject an IP number they control, so that participants connect to their machine as well as to the original participants.
- In this case, they could collect the chat password from those joining afterwards, as they try to connect to them, and then use it to complete their connection to the rest. But they won’t be able to join the chat incognito, since that would require changing the chat app in the other participants’ machines. The others are going to know that someone else has joined and they are going to try to authenticate each other. PassLok chat includes a (manual) protocol to do this based on electronic signatures, which takes a mere few seconds por each participant. The GCQH would have to have the private Key of the participant they are impersonating in order to pull this off. But of course if they had that key they wouldn’t have to be doing all this.
- They may also try to hack the chat app at its source, but they have no jurisdiction over the server, located in the Netherlands. In any case, participants can see the code before it executes and compare it with clean code they obtained beforehand. This is because the code does not execute on the server as in most chat apps, but exclusively on the client machines.
Far fetched? Possibly but by no means something they wouldn’t do. But compare this with what they have to do to eavesdrop into your common chat app: just serve a subpoena to the server administrator and copy everything that is going through their server. If it’s running Signal or one of its derivatives (such as WhatsApp), they’ll have to contend with the end-to-end forward-secret encryption built into the protocol, but things would be much easier for them since they control the server and any software sent out from it, which users cannot see or check. But this would impossible with PassLok Chat, since the only thing passlok.com does is serve the chat code, which users can check before it runs, and the only thing Firebase does is collect and reveal IP numbers. Neither of them ever sees actual chat data.
So, if you are living in the UK or otherwise have a problem with GCQH reading your chats, you may want to take PassLok’s family for a spin. The chat capability is built into PassLok Privacy, PassLok for Email, SeeOnce, and URSA. Enjoy!