In this final chapter, we will use the BeagleBone Black (BBB) to protect the last bastion of your online life: real-time chats. With your e-mail protected by GPG and your browsing protected by Tor, we'll use the software called Off-the-Record (OTR) to protect instant messaging chats. OTR addresses a weakness in the PGP threat model and we will give an overview of the OTR design objectives before building the project. We'll also consolidate all of your chat networks to be managed over an Internet Relay Chat interface, which will run on your BBB. While this project doesn't require any additional hardware other than the BBB, the cryptographic concepts and networking interactions are slightly more challenging than the previous chapters. At the end of this chapter and the book, you will have had exposure to and become familiar with the three most effective tools to protect your privacy online.
In this chapter, you will do the following:
- Learn the difference between the cryptographic design between PGP and OTR
- Run an IRC to chat gateway with BitlBee
- Incorporate your IRC networks with the IRC bouncer ZNC
- Set up and use OTR chat on BitlBee and ZNC
Before we investigate OTR, let's consider how we could encrypt our chat sessions. We could use GPG for chat. We'd have to know the public key of our correspondent, and each time we'd enter a message, it would encrypt and/or sign the message and send it along. Some chat networks don't have an equivalent e-mail address, so it could be awkward finding and verifying public keys. However, you can certainly imagine a chat system that worked this way; it's a slightly more synchronous version of GPG with e-mail.
Even if those technical problems are addressed there is a bigger issue lurking in PGP's design. Let's return to our friends Alice and Bob. Alice and Bob have been communicating with GPG for quite some time now. They use GPG flawlessly and religiously practice the best security hygiene. Until one day, when somebody gets a hold of Bob's private key. Now, there are several ways this could happen. Despite Bob's willpower, perhaps he just couldn't resist clicking on the Watch cuTe kittys [sic] link and malware infected his computer. Perhaps somebody stole his custom made GPG key hardware token and guessed his GPG passphrase. Regardless of how his private key was leaked, what matters is that now somebody else has it.
Bob, vigilant GPG user that he is, immediately revokes his key, which informs the world that the key is compromised. This warns others not to use that particular key and for future conversations, they should use a new key. But let's not forget about Alice and the many communiqués she exchanged with Bob. What's to make of Alice? This attacker, who has Bob's private key, can decrypt the entire past communication between Alice and Bob. All of it. All of a sudden, their conversation doesn't seem so private as Ian Goldberg, the designer of OTR, remarks about privacy in GPG communications.
While GPG has its place, if you are concerned about losing control of your private key, then maybe you should consider other tools. One tool, which was designed with this threat in mind, is called Off-the-Record (OTR) which was originally published in the paper Off-the-Record Communication, or, Why Not To Use PGP (Borisov 2004). OTR includes some cryptographic features and design goals that differ from PGP. For example, OTR was designed to incorporate perfect forward secrecy, which ensures that session keys, the keys that are encrypting the communication traffic, can't be re-derived if the longer term identity key is compromised. Also OTR only uses digital signatures for the initial authentication step; individual messages are not signed.
The session keys are derived independently by both parties through a Diffie-Hellman Key-Exchange protocol. The Diffie-Hellman protocol helps to solve a key distribution problem. Alice and Bob want to secure their communications with a symmetric cipher, but they both need the same key. Using Diffie-Hellman, they can both derive the shared key value over an insecure channel, without exposing the value of the key to a third party. OTR uses asymmetric cryptography in a Diffie-Hellman key-exchange, so that both parties can derive a shared AES key in counter-mode. AES in counter-mode (AES-CTR) uses AES as a stream cipher, the significance of which is discussed later in this section.
Note
A simplified, two-minute description of the Diffie-Hellman Key Exchange is available at Khan Academy website https://www.khanacademy.org/computing/computer-science/cryptography/modern-crypt/v/diffie-hellman-key-exchange--part-2.
Another feature of OTR that is different than PGP is that OTR was designed with repudiability for messages, which is the ability to deny authorship or validity. PGP was designed for non-repudiability, which provides a proof, via your digital signature, that you indeed created that message. However, with OTR, neither Alice nor Bob can prove the other, or themselves, created a particular message. The details of this feature are a bit technical, but we'll provide a high-level summary since it is a clever use of Message Authentication Codes (MACs).
A MAC is a small tag that accompanies a block of data. The tag is computed by the sender and is sent to the receiver, who recomputes the value to check that the data was not corrupted in transit, which attests the integrity of the data. Furthermore, MACs involve a shared-key between parties. So, Alice has the same MAC key as Bob. Therefore, when Bob verifies the MAC on a message, he is assured that the sender has the same MAC key as himself. In OTR, because Alice and Bob have the same MAC key that is applied to individual messages, either one of them can create messages to imitate the other. Therefore, neither of them can prove that they, nor their communicating partner, definitively produced a message. This provides the repudiation feature in OTR.
The OTR designers incorporate one additional unorthodox feature for a cryptographic system: forgeability. OTR is designed so that it is easy to change the ciphertext en route to produce a meaningful output when the message is decrypted. This can be performed because the designers chose a malleable encryption scheme using a stream cipher; in OTR's case, it uses AES-CTR with a 128-bit key length. In stream ciphers, the meat of the cipher is generating a key stream, but the actual encryption is typically performed by applying the exclusive-OR operation to the plaintext. Decryption is performed with the same exclusive-OR function applied to the same keystream. An attacker, who can guess the plaintext of the message, can modify the ciphertext to produce a different plaintext message of the same length. Therefore, the messages can be forged.
Note
Exclusive-OR, or XOR, can be used for both encryption and decryption due to its logical definition: the XOR of A and B is true if and only if either A or B is true. Digital messages are represented as binary streams. The plaintext of a message is XORed with a key stream to produce a ciphertext, and when that ciphertext is XORed with the same key stream, the plaintext is returned. For example, if the plaintext bit is 1 and the key stream bit is 1, the ciphertext will return 0. When the ciphertext bit, 0, is applied to the keystream 1, the plaintext bit 1 is recovered. The Khan Academy has an interactive and visual series on XOR in cryptography: https://www.khanacademy.org/computing/computer-science/cryptography/ciphers/a/xor-bitwise-operation.
Alice and Bob are still protected from a third party, who doesn't know the MAC key, being able to tamper with their immediate conversation. However, OTR includes yet another twist. It publishes the MAC keys of the previous conversation once it has re-keyed to new MAC keys. Publishing the MAC keys means that anyone who has passively monitored the conversation can change the ciphertext, and thus, manipulate the plaintext of past messages. This adds another layer of deniability to the conversation, as any recorded conversation could be easily manipulated and might seem legitimate. Alice and Bob only publish old MAC keys, the key currently in use is kept secret until the protocol requires them to re-key.
Designing cryptosystems is not enough to ensure their adoption; they also need to be robust and usable. OTR was not only published as an academic paper, but a library was provided as well. OTR was designed to work over any existing Instant Message (IM) protocol with any client that could incorporate the library, or plugin. Your favorite IRC client probably has a plugin or library that can easily incorporate OTR. In this chapter, we will be using OTR plugins that are built in the two IRC applications we will examine.
The design of OTR, specifically the perfect forward secrecy and deniability features, have inspired derivates for other protocols besides real-time chatting. For example, Open WhisperSystems' TextSecure app for mobile devices uses an OTR-like protocol over SMS and other asynchronous IM channels.
Also, OTR, like Tor and GPG, is recommended by the Freedom of the Press Foundation, a U.S. Non-profit organization that supports and defends public interest journalism. This organization provides education and tutorials on how to use these tools. While presented in the contexts of journalists protecting their sources, as Glenn Greenwald and Laura Poitras used (Greenwald 2014), the information is applicable to any user of privacy enhancing technology.
In this chapter, we'll be using the BBB to run OTR on various IRC gateways. The BBB is well suited to act as your personal IRC gateway. It can easily handle the IRC connections and act as an always-on server without dramatically increasing your electric bill. While IRC may seem archaic, it provides an interface that is client independent and modular. We'll eventually build a complete IRC solution, one that manages all of your IRC networks. First we will look at the software BitlBee, which merges your chat networks like Google Talk and Jabber into IRC.