Let’s chat about how you chat.

In the modern day, there are a plethora of instant-messaging applications at disposal to allow you to communicate, send photos and videos, and share your location with family and friends. The same is true about the Government housing all this data. So, I thought I’d add some context as to what you can do to improve security when using instant messaging applications.

The best thing about factual topics on the internet are, you can quote and use them to literally reiterate the same fact on your own post, and it’s for a good cause; keeping things factual.


Why do I need an encrypted chat program?

You do not necessarily need an encrypted chat program, however it is important to those whom wish to have privacy with those they speak to. Any message (ASCII), photo, video or voice recording transmitted via Facebook, Snapchat, Instagram or even conventional SMS can (and most likely) is stored in some centralised database, building a profile of you.

Do you remember people complaining Facebook knows what they look at on their phones?  As an example, this post goes into detail about data you are sharing with Facebook, even though you are not directly opting to do so (read the terms of service next time):

  • Videos you’ve watched
  • Comments you’ve liked
  • Websites you’ve visited
  • Articles and websites you’ve commented on
  • Surveys you’ve filled out
  • Companies you like
  • People you’ve been tagged with
  • People you frequently hang out with
  • Friends you’ve requested
  • Friends you denied
  • Friends you’ve un-friended
  • How often you are online
  • Apps you Admin/created
  • Pages you admin/created
  • Your current mood
  • Device you’ve accessed the Internet from
  • Exact Geo-location (longitude, altitude, latitude, time/date stamp)
  • TV, Film, Concert you are currently watching
  • Book or publication you are currently reading
  • Audio you are currently listening too
  • Drink you are currently drinking
  • Food you are currently eating
  • Activities you participate in
  • Advertising you interact with
  • Profiles you interact with most
  • Locations you access Facebook
  • Locations you access web properties connected to Facebook
  • Level of online engagement
  • When you changed jobs
  • How long you stayed in a job
  • Credit card details
  • IP Address
  • Apps you’ve downloaded
  • Games you’ve played
  • Pages/Businesses you’ve un-liked (when)

The main reasoning behind the highlighted items are that in unison, anyone with access to this data can isolate your location, recent visits and what devices you have on you. Not only does this potentially make you vulnerable to tracking from people, but opens you up for someone to steal your identity (yes, these are very dramatic repercussions but still valid).

  • Device you’ve accessed the Internet from

Services (this is not limited to Facebook) should not have the ability to catalogue the devices tied to an account.

With this ability, they are able to (stemming to the next point) always have a geo-locked location of the device (and assumed person) at their disposal.

  • Exact Geo-location (longitude, altitude, latitude, time/date stamp)

Exact. What the actual Foxtrot Unicorn Charlie Kite?  Services knowing where I am, at whatever time is a clear abuse of power.

Using this information, patterns of travel and location can allow you to be tracked. Using services such as Facebook to allow geo-location tracking is absurd in my opinion.

  • IP Address

If you know my public IP via a NAT you can easily sniff and track web usage of certain people; again, what the actual Foxtrot Unicorn Charlie Kite?

  • Websites you’ve visited

Because Internet Censorship is what everyone wants, right?  Having ISP logging Metadata and services knowing website you visit is a sheer breach of personal privacy.

  • Book or publication you are currently reading

Personally, I read a lot of politically incorrect publications (not that I am some crazy person) and I’d like to keep that private; Facebook knowing I am “Googling” terrorist attacks and researching them should not be recorded without my implicit confirmation.

Now of course, it is impossible not to use services that record all this data (Personally Google knows everything about me) but there are valid techniques to mitigate the collection and aggregation of this information.

What are the things I should look for in set program?

This is a broad and rather opinion-based topic point. Discussion relating open sourced, closed, cross-platform and protocols are open for debate.

Personally (and I am not a security expert), there need to be 3 options available in an application to make it secure:

  • Open source, peer reviewed;
  • De-facto encryption standards and;
  • Non identifying sign-up requirements.

Open source, peer reviewed

This topic has a lot of scrutiny about it. One point being vulnerabilities are shared with anyone reading the code, but at the same time, greater set of eyes allow this to be patched faster.

My opinion is summarised by this statement:

Do I choose Safe Number One that’s advertised to have half-inch steel walls, an inch-thick door, six locking bolts, and is tested by an independent agency to confirm that the contents will survive for two hours in a fire? Or, do I choose for Safe Number Two, a safe the vendor simple says to trust, because the design details of the safe are a trade secret? It could be Safe Number Two is made of plywood and thin sheet metal. Or, it could be that it is stronger than Safe Number One, but the point is I have no idea.

Of course, the battle enraged the internet  and everyone has their own opinions I personally believe that if the code is peer-reviewed, back doors and holes to the software are far less likely than those of a propriety company that will share your data for the right payment.

De-facto encryption standards

When you use a program designed to keep security in mind, you do not want to rely on some newly-created protocol that takes a thousand builds to be stable. Implementing either old (usually broken) or unstable protocols is a flaw in itself when trying to enact secure messaging.

As with all my posts, the technical content will be highly referenced as I am (as I’ve said) not a security expert.

When looking at encryption and cryptography, there are a number of standards you can enact.

Extensible Messaging and Presence Protocol (XMPP)

is a communications protocol for message-oriented middleware based on XML (Extensible Markup Language).[1] It enables the near-real-time exchange of structured yet extensible data between any two or more network entities.[2] Originally named Jabber,[3] the protocol was developed by the Jabber open-source community in 1999 for near real-timeinstant messaging (IM), presence information, and contact list maintenance. Designed to be extensible, the protocol has been used also for publish-subscribe systems, signalling for VoIP, video, file transfergaming, the Internet of Things (IoT) applications such as the smart grid, and social networking services.

Think of XMPP as the back-end transportation method and not necessarily the encryption methodology.  XMPP is good as it has a open-standard, and is scalable across platforms.

According to XMPP:

Secure — any XMPP server may be isolated from the public network (e.g., on a company intranet) and robust security using SASL and TLS has been built into the core XMPP specifications. In addition, the XMPP developer community is actively working on end-to-end encryption to raise the security bar even further.

An XMPP Server is considered secure when the following (minimum) items are present:

  • The server is running with a server certificate
  • The server is configured to not allow any cleartext communications – S2S and C2S
  • The server supports XEP-198

Note that unless you have clear access to the code running on the server to validate the above, you assume the XMPP portion of the application is unsecure.

Off-the-Record Messaging (OTR)

is a cryptographic protocol that provides encryption for instant messaging conversations. OTR uses a combination of AESsymmetric-key algorithm with 128 bits key length, the Diffie–Hellman key exchange with 1536 bits group size, and the SHA-1 hash function. In addition to authentication and encryption, OTR provides forward secrecyand malleable encryption.

OTR is a rather complex protocol. Before commencing an encrypted data exchange, both parties must do an unauthenticated Diffie-Hellman (D-H) key exchange to set up an encrypted channel, and then do mutual authentication inside that channel.

Let’s use Bob and Alice as the example here. Bob must initiate the AKE (Authenticated Key Exchange) as follows:

Bob:

  1. Picks a random value r (128 bits)
  2. Picks a random value x (at least 320 bits)
  3. Sends Alice AESr(gx), HASH(gx)

Alice:

  1. Picks a random value y (at least 320 bits)
  2. Sends Bob gy

Bob:

  1. Verifies that Alice’s gy is a legal value (2 <= gy <= modulus-2)
  2. Computes s = (gy)x
  3. Computes two AES keys c, c’ and four MAC keys m1, m1′, m2, m2′ by hashing s in various ways
  4. Picks keyidB, a serial number for his D-H key gx
  5. Computes MB = MACm1(gx, gy, pubB, keyidB)
  6. Computes XB = pubB, keyidB, sigB(MB)
  7. Sends Alice r, AESc(XB), MACm2(AESc(XB))

Alice:

  1. Uses r to decrypt the value of gx sent earlier
  2. Verifies that HASH(gx) matches the value sent earlier
  3. Verifies that Bob’s gx is a legal value (2 <= gx <= modulus-2)
  4. Computes s = (gx)y (note that this will be the same as the value of s Bob calculated)
  5. Computes two AES keys c, c’ and four MAC keys m1, m1′, m2, m2′ by hashing s in various ways (the same as Bob)
  6. Uses m2 to verify MACm2(AESc(XB))
  7. Uses c to decrypt AESc(XB) to obtain XB = pubB, keyidB, sigB(MB)
  8. Computes MB = MACm1(gx, gy, pubB, keyidB)
  9. Uses pubB to verify sigB(MB)
  10. Picks keyidA, a serial number for her D-H key gy
  11. Computes MA = MACm1′(gy, gx, pubA, keyidA)
  12. Computes XA = pubA, keyidA, sigA(MA)
  13. Sends Bob AESc’(XA), MACm2′(AESc’(XA))

Bob:

  1. Uses m2′ to verify MACm2′(AESc’(XA))
  2. Uses c’ to decrypt AESc’(XA) to obtain XA = pubA, keyidA, sigA(MA)
  3. Computes MA = MACm1′(gy, gx, pubA, keyidA)
  4. Uses pubA to verify sigA(MA)

If all of the verifications succeeded, Alice and Bob now know each other’s Diffie-Hellman public keys, and share the value s. Alice is assured that s is known by someone with access to the private key corresponding to pubB, and similarly for Bob.

Once this has been configured, you can go about Exchanging data.

Suppose Alice has a message (msg) to send to Bob:

Alice:

  • Picks the most recent of her own D-H encryption keys that Bob has acknowledged receiving (by using it in a Data Message, or failing that, in the AKE). Let keyA by that key, and let keyidA be its serial number.
  • If the above key is Alice’s most recent key, she generates a new D-H key (next_dh), to get the serial number keyidA+1.
  • Picks the most recent of Bob’s D-H encryption keys that she has received from him (either in a Data Message or in the AKE). Let keyB by that key, and let keyidB be its serial number.
  • Uses Diffie-Hellman to compute a shared secret from the two keys keyA and keyB, and generates the sending AES key, ek, and the sending MAC key, mk, as detailed below.
  • Collects any old MAC keys that were used in previous messages, but will never again be used (because their associated D-H keys are no longer the most recent ones) into a list, oldmackeys.
  • Picks a value of the counter, ctr, so that the triple (keyA, keyB, ctr) is never the same for more than one Data Message Alice sends to Bob.
  • Computes TA = (keyidA, keyidB, next_dh, ctr, AES-CTRek,ctr(msg))
  • Sends Bob TA, MACmk(TA), oldmackeys

Bob:

  • Uses Diffie-Hellman to compute a shared secret from the two keys labelled by keyidA and keyidB, and generates the receiving AES key, ek, and the receiving MAC key, mk, as detailed below. (These will be the same as the keys Alice generated, above.)
  • Uses mk to verify MACmk(TA).
  • Uses ek and ctr to decrypt AES-CTRek,ctr(msg).

Do you like advanced mathematics?

So if it’s just a pre-defined function, surely it can be impersonated?

Socialist Millionaires’ Protocol (SMP)

is one in which two millionaires want to determine if their wealth is equal without disclosing any information about their riches to each other. It is a variant of the Millionaire’s Problem[2][3] whereby two millionaires wish to compare their riches to determine who has the most wealth without disclosing any information about their riches to each other.

Basically, let’s check to see who you are without disclosing information. Another fun example of maths. Assuming that Alice begins the exchange:

Alice:

  1. Picks random exponents a2 and a3
  2. Sends Bob g2a = g1a2 and g3a = g1a3

Bob:

  1. Picks random exponents b2 and b3
  2. Computes g2b = g1b2 and g3b = g1b3
  3. Computes g2 = g2ab2 and g3 = g3ab3
  4. Picks random exponent r
  5. Computes Pb = g3r and Qb = g1r g2y
  6. Sends Alice g2b, g3b, Pb and Qb

Alice:

  1. Computes g2 = g2ba2 and g3 = g3ba3
  2. Picks random exponent s
  3. Computes Pa = g3s and Qa = g1s g2x
  4. Computes Ra = (Qa / Qba3
  5. Sends Bob Pa, Qa and Ra

Bob:

  1. Computes Rb = (Qa / Qbb3
  2. Computes Rab = Rab3
  3. Checks whether Rab == (Pa / Pb)
  4. Sends Alice Rb

Alice:

  1. Computes Rab = Rba3
  2. Checks whether Rab == (Pa / Pb)
  • If everything is done correctly, then Rab should hold the value of (Pa / Pb) times (g2a3b3)(x – y), which means that the test at the end of the protocol will only succeed if x == y. Further, since g2a3b3 is a random number not known to any party, if x is not equal to y, no other information is revealed.

Pretty neat documentation on OTR. Props to them.

Diffie–Hellman key exchange (D–H) – Elaborated for OTR Implementation.

 is a method of securely exchanging cryptographic keys over a public channel

Or as I prefer to explain it:

Diffie helman is a mathematical algorithm to exchange a shared secret between two parties. This shared secret can be used to encrypt messages between these two parties.

This “methodology” (its a protocol) is used to “salt” a passphrase (or key). The following implantation on how it works:

The simplest and the original implementation of the protocol uses the multiplicative group of integers modulo p, where p is prime, and g is a primitive root modulo p. These two values are chosen in this way to ensure that the resulting shared secret can take on any value from 1 to p–1. Here is an example of the protocol, with non-secret values in blue, and secret values in red.

  1. Alice and Bob agree to use a modulus p = 23 and base g = 5 (which is a primitive root modulo 23).
  2. Alice chooses a secret integer a = 6, then sends Bob A = ga mod p
    • A = 56 mod 23 = 8
  3. Bob chooses a secret integer b = 15, then sends Alice B = gb mod p
    • B = 515 mod 23 = 19
  4. Alice computes s = Ba mod p
    • s = 196 mod 23 = 2
  5. Bob computes s = Ab mod p
    • s = 815 mod 23 = 2
  6. Alice and Bob now share a secret (the number 2).

Both Alice and Bob have arrived at the same value s, because, under mod p,

{\displaystyle A^{b}{\bmod {\,}}p=g^{ab}{\bmod {\,}}p=g^{ba}{\bmod {\,}}p=B^{a}{\bmod {\,}}p}

More specifically,

{\displaystyle (g^{a}{\bmod {\,}}p)^{b}{\bmod {\,}}p=(g^{b}{\bmod {\,}}p)^{a}{\bmod {\,}}p}

The following values are then stated:

  • g = public (prime) base, known to Alice, Bob, and Eve. g = 5
  • p = public (prime) modulus, known to Alice, Bob, and Eve. p = 23
  • a = Alice’s private key, known only to Alice. a = 6
  • b = Bob’s private key known only to Bob. b = 15
  • A = Alice’s public key, known to Alice, Bob, and Eve. A = ga mod p = 8
  • B = Bob’s public key, known to Alice, Bob, and Eve. B = gb mod p = 19

hm.PNG

This is literally all available on Wikipedia by the way.

It is imperative to understand that Diffie-Hellman is just a function to compute a shared key, not a full protocol. To actually use it, you need to design a protocol on top of it; OTR actually signs the DH key with its “long term key”.

Perfect Forward Secrecy (PFS)

Again, this is bundled in the OTR implementation. In the simplest form:

PFS is a property of secure communication protocols in which compromise of long-term keys does not compromise past session keys. Forward secrecy protects past sessions against future compromises of secret keys or passwords. If forward secrecy is used, encrypted communications and sessions recorded in the past cannot be retrieved and decrypted should long-term secret keys or passwords be compromised in the future, even if the adversary actively interfered.

To get a better understanding of this, it can be stated that:

A public-key system has the property of forward secrecy if it generates one random secret key per session to complete a key agreement, without using a deterministic algorithm. This means that the compromise of one message cannot compromise others as well, and there is no one secret value whose acquisition would compromise multiple messages.

There are many iterations of this, the current notable method being Double Ratchet.


Basic Understanding = Done.

Now that you’ve got a basic understanding of why it is important to want to encrypt your data, and an example of how this is accomplished, let’s look at your options.

Again this post is about picking an app to secure messaging. It is not intended to go into depth on how encryption works etc.

So, how do we know what to use, and what not to use? Well you could use CryptoCat or an application listed here.

The answer is: whatever application meets your suited requirements. There is no 100% answer to this question.

Personally I use Signal for a few reasons:

  1. It’s easy to tell people to install;
  2. Implements OTR Ratchet;
  3. Curve25519 improvement to D-H and;
  4. It’s just really easy to use.

Thanks!

Make sure you check out my blog post about Fighting For Internet Freedom.

Come visit me on Stack Exchange:


Profile for Michael Nancarrow on Stack Exchange

 

Errors? Typos? More facts needed?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s