The Latest in IT Security

I recently tried an amazing browser extension named Datarmine whose goal is to secure social network posts. It works for Facebook, Twitter etc. The idea is that your posts get encrypted, and only people with your secret key can decrypt it. Others see a fake replacement post (that you can choose).

This is a post encrypted by Datarmine. The end-user chooses the text which is displayed to people who are not authorized to decrypt it. (Text in French basically says “I am trying Datarmine”).

This is the real post, decrypted from the message above.

I guess nobody recalls my post in 2010 on encrypting Facebook posts, but this is very much the same idea :). The Datarmine browser extension makes it far more friendly to use. No need to use GPG, get mixed with public and private keys or understand cryptography at all. Datarmine works with one secret key. You choose to whom you distribute it, that’s all. Check out Datarmine’s web site for plenty of tutorial videos.

“Hey? Facebook is already capable of restrcting access to my posts to whoever I choose, don’t you know?”

Sure, I know, and I like the feature. But that’s a Facebook guarantee. What happens if Facebook servers are compromised? Think of server side vulnerabilities, bugs, or worms such as the infamous Koobface. Is your data safe in those circumstances? No. And don’t tell me this can’t happen: it happens all the time, it has already happened (and not only to Facebook.). What if Facebook sells your data to 3rd companies you don’t trust? Not to mention the recent privacy issues around the NSA and PRISM.

That’s what Datarmine is for. It secures your post, even if it is stored ‘in the cloud’. With Datarmine, Facebook (Twitter and any other social network) is like unknown people: they can’t read your post.

However, let’s not take security for granted. I am a reverse engineer after all 😉 We’ll check it out for ourselves.

The figure below basically illustrates Datarmine’s HTTP protocol.

Datarmine’s HTTP protocol

Datarmine introduces a new concept that they call ‘incentives’. An incentive is a ‘fake post’. Text that people without my secret key will see instead of my real post. Fortunately, Datarmine end-users have some control over which incentive is used to replace their post: it can be selected (and customized) from a catalog of incentives (e.g sports, news, caritative.).

The first two requests (getIncentive and find_by_user_id) deal with incentives to use for my post. The first one retrieves the default incentive, and the second one retrieves the particular incentive sources I have selected in my Datarmine account.

Then, when the datarmined post is ready, it is sent via an HTTP POST to Datarmine servers (publishNew request – see capture below). The packet contains my user id, people who are authorized to read the post (Robin Wood), the encrypted post (with its cryptographic parameters) and the incentive to use.

HTTP packet capture when creating a new datarmined post

The Datarmine server answers back with the incentive to use (inside a JSON object). There is a link at the end of the incentive, e.g http://wate.at/2209. This link actually leads to a Datarmine information page, but the trailing identifier is particularly important (2209) because it references each post. Each post gets a new identifier. This identifier is mandatory for the Datarmine extension to decrypt and display the right post.

Finally, whenever an authorized user views a datarmined post, a HTTP POST request is sent from the user’s browser to Datarmine servers with the identifier of the post (tids). Datarmine fetches the correct encrypted post on their server and sends it back to the user’s browser. The post is decrypted locally (on the user’s host). There are several cryptographic parameters:

• IV: Input Vector
• ks: Key Size – 128 bits
• ts: I don’t know what this is.
• mode: CCM, i.e Counter with CBC-MAC. This is a block cipher mode.
• adata: additional authenticated data. This is a parameter for CCM. It contains authenticated but not encrypted data. None in our case.
• cipher: AES. Well known block cipher.
• iter: probably iteration (1000), though I don’t know what this is for. It is not the CCM counter.
• salt: I am not sure, but I guess the salt is combined with the secret key to create the AES block cipher key.
• ct: cipher text.
• author: user name of the person who posted this entry

What do we learn from this reverse engineering?

1. Datarmined posts are indeed encrypted locally. Only ciphered text are sent over Internet. Cool 🙂 AES-128 in CCM mode is used. We are happy to note that Datarmine developers were careful to use a different IV (Input Vector) for each post, as this is a condition to CCM mode’s security. Apart from a changing IV, I haven’t checked yet the message is correctly encrypted, nor where and how the secret key is secured. I will be doing so as soon as possible.

2. Spies sniffing on the network can see who is posting: the user id is sent along several packets and the author name is included in the response to the read packet. They can also see to whom we post as the list of authorized end-users is sent in clear text in the publishNew packet. For privacy reasons, I think this should be fixed.

3. If Datarmine servers are down, you won’t be able to decrypt posts. That’s because the encrypted post is sent back as a response to the HTTP request “read”. Guillaume Lovet (technical editor of the blog) would certainly prefer Datarmine to hide the encrypted message within the incentive. That way, Datarmine servers wouldn’t need to be contacted to read a post. Additionally, it would be less obvious to external viewers (who can easily spot the http://wate.at link) that you have encrypted a post. Interesting suggestion!

4. To my understanding, restricting who can read a given datarmined post is done at two levels. First, cryptography: people must have your secret key. Second, access level: people must be authorized to read your post. The various authorized users are specified in the auth field of the publishNew POST request. If you try to read a post entry you are not entitled to, the server responds with an HTTP 500 error.

   $ wget -post-data=’user_id=7777&tids=%5B2209%5D’
   .
   HTTP request sent, awaiting response. 500 Internal Server Error

However, note that the security provided by the access level is far weaker than the security provided by cryptography. If you have the secret key and you manage to get the cipher text by some way (for example, sniffing packets to an authorized user on your network), you can actually read the post. I wouldn’t count too much on this access level security. When you post, keep in mind for now that whoever has your secret key can probably read your post.

The Datarmine extension is currently only available for Chrome, but Datarmine developers are working on extensions for other browsers.

– Crypto Girl