Archive for the 'Crypto' Category

Cables Communication: An anonymous, secure, message exchange

Nov 17 2013 Published by under Crypto,privacy,Tor

Last night at Interlock Rochester, someone did a lightning talk on Liberte Linux — one of those anonymity Linux distros similar to TAILS and the like. Everything seemed pretty standard for an anonymity machine, all traffic was tunneled over Tor using iptables, only certain software was able to be installed, full disk encryption, memory wiping — But one thing stuck out, this service called “Cables.”

Cables Communication:

Cables (or Cable I really don’t know) is designed by a person that goes by the name, Maxim Kammerer. He is also the creator of Liberte Linux. Its purpose is to let user A communicate with user B, in an E-mail-like way, but with anonymity and security in mind. Before this, Tor users would use services like TorMail, until that was taken down. I don’t know if that was the inspiration for this new service, but it seems like it’s an attempt to fill that hole. 

liberte-logo-600px[1]

Overview:

Here’s a very simplified functional overview:

  1. User generates a Cables certificate which is a 8192 bit RSA X.509 certficate
  2. The fingerprint for that certificate is now that user’s username (like “antitree” is the username of “[email protected]”)
  3. A Tor hidden service is created and that is the domain of the address you’re sending (e.g xevdbqqblahblahlt.onion)
  4. This “Cables Address” is given to the trusted party you’d like to anonymously communicate with
  5. You setup a mail client like Claws, to handle communications to send these messages to the addresses
  6. Your email is saved into the Cables “queue” and is ready to be sent
  7. Cables then looks for the receipient’s Cables service, and lets it know it has a new message
  8. Once a handshake is complete, the message is sent to the user

So that’s a userland understand of it, but I’m glossing over a lot of important stuff like how Cables talks to another Cables service, what kind of encryption is being used, key exchange things… You know, the important stuff.

Cables messages are CMS

There are two important parts to understand about cables. The encrypted message format, and the way that it communicates information. Cables uses an implementation of the Cryptographic Message Syntax (CMS), which is an IETF standard for secure message communications. You can read more about how CMS is supposed to work here. In short, Cables messages are the CMS format implemented with X.509-based key management. My take-away from this is “Good – it’s not designing a new crypto.”

Communication Protocol

Although email is the most common example, Cables is not stuck in one way in which you communicate these messages – it’s transport independant. From what I see, it could be used securely share file to another user, as an instant message service, or exchanging information over some new communication protocol. This is why it fits nicely using Tor (and I2P) and a transport.

All communications are done via HTTP GET requests. This is a big part of understanding how this works. Cables comes with wrappers to help it feel more like a mail protocol, but all transmissions communicate over HTTP. For example, if you you look at the “cable-send” command in the /home/anon/bin path, you’ll notice it’s just a bash script wrapper for the “send” command. But that’s ALSO a bash script to interpret the mail message format and save it into a file path.

HTTP Server

This HTTP service is facilitated by the appropriately named “daemon” process which is the service shared via your .onion address. This service runs on local port 9080, and is served up on port 80 of the hidden service. So if you visit your hidden service address on that port, you receive a 200 ok response. But if you give it a URL like the one below, you can actually access files on the file system. There is a 1 to 1 translation between the files saved in the path /

certs

 

This web service responds to every request, but only certain requests deliver content. Here are the standard ones:

  • /{Username}/
    • certs/ca.pem
    • certs/verify.pem
    • queue/{message_id}
    • rqueue/{message_id}.key
    • request/

Most of these just serve up files sitting on the file system. /request/ initiates the service requests and starts the transfer.

Daemon push?

If you didn’t think so already, this is where it starts to get odd. This daemon regularly looks inside the queue folder (using inotify) for new messages to send. This is done on a random basis so that new messages are not sent out at the exact same time, each time. This is an attempt to prevent traffic fingerprinting  — an attack where someone is able to sniff your traffic and based on the traffic schedule, predict that you’re using Cables. In other words, when you go to send a secure message, what you’re doing is taking a message, encrypting it into the designated CMS specification, and plopping in a special place on your hard drive. Then the daemon service looks in that path and decides if you’re trying to send something.

Ok Crypto

I don’t yet have a grasp on the crypto besides understanding that it generates a certificate authority on first run which helps generate the rest of the keys used to sign, verify, and encrypt messages. It uses an implementation of Diffie-Helman for ephemeral keys and then there’s some magic in between the rest. 🙂 My first take on this is that its weakest points are not the cryptography, but the communication protocol.

Impressions So Far

If I’m scoping this project for potential attack vectors, I’d predict that there’s going to be something exploitable in the HTTP service implementation. That’s me being a mean, security guy, but I feel that’s going to have the lowest hanging fruit. This is mitigated by the fact that Tor hidden services are not something you can discovery, so even if there was an attack, the attacker would need to know your hidden service, and probably your username.

Although I keep mentioning that it’s aimed at being an email replacement, there’s one major difference which is that instead of having a dedicated SMTP server, messages are sent directly to the recipient which means that that user must have his box up and running. The default timeout for messages to fail is 7 days.

I think so far that CMS is a good way to go, but using GET PUSH style HTTP for transmission, might prove to be its eventual downfall. I’m not poo-pooing the project, but there are some challenging hurdles that it’s aiming to leap.

Onion Porn: HashedControlPassword

Oct 27 2012 Published by under Crypto,Python,Tor

I love excessively documented things. Design documents, protocols specs…whatever and Tor is one of those projects that I’ve always loved to randomly poke around into. I got sucked into Tor’s source code today and was entertained by the results. Beware, crypto time suck ahead.

ControlPort

Tor is controllable by making socket connections to it’s aptly named “ControlPort” usually on port 9051. The control port is not enabled by default if you’ve just installed Tor on Ubuntu or something, but it is enabled on the Windows packages that use front-ends like Vidalia. Anyways, this gives various third parties the ability to control all aspects of Tor on-the-fly.

There was a 2600 article years ago, about using the control port and it gives a really cool summary of some of the stuff you can do. Create custom circuits, create super long circuits, generate new circuits on demand. If you’ve used Vidalia, this is what it interfaces with.

But what I got sucked into today is the fact that there’s two ways to authenticate with the control port: Cookie, and HashedPassword. (Or none if you don’t care.) . This is what your standard TORRC looks like:

## The port on which Tor will listen for local connections from Tor
## controller applications, as documented in control-spec.txt.
ControlPort 9051
## If you enable the controlport, be sure to enable one of these
## authentication methods, to prevent attackers from accessing it.
#HashedControlPassword 16:872860B76453A77D60CA2BB8C1A7042072093276A3D701AD684053EC4C

Crypto

Normally you can generate a hashed password for saving in your TORRC file by using the “–hash-password” switch to Tor. But today I wanted to waste my time and see how it’s generated. Thankfully, even though the documentation is a bit outdated, the control spec still goes into some pretty good detail.

https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt

Section 5.1 covers authentication and the HashedControlPassword function which looks like this:

I’m all double rainbow on this at first which made me spend more time on it. Se we see the RFC for OpenPGP and how it documents the generation of this hash. And it starts to make sense. I’ll try to explain how I understand it:

OpenPGP’s RFC explains that the S2K (string to key) algorithm takes in a secret value, a specifier (I’ll come back to), an 8 byte salt, a “count” value, and generates  a hash. The count value is an encoded hex value that affects how many times the secret is hashed. The salt is just a random 8 byte value. But the specifier dictates the type of S2K and the hashing function to use. It consists of 2 bytes, the first specifies the type of hashing function that will be performed. These options are:

0x00 Simple: A key comes in, a hash goes out

0x01 Salted: A key is salted and then hashed

0x03 Iterated and Salted: A key, and a salt, all hashing the crap out of eachother over and over. This is what Tor uses.

The second byte specifies the hashing algorithm. In the case of Tor, they use SHA1 so this specifier should be 0x02. So putting that together for Tor, we would expect to see the hex encoded version of 32. But you’ll notice in the control-spec, there is no 32 at all but there is a “16:”.

I spent far too long trying to rationalize how 16 fits into the hash but it turns out that Tor does not use the specifier in their implementation  of S2K. That makes sense after I think about it since Tor doesn’t need to worry about different hashing algorithms or varied number of hashing iterations. They implement a static password hashing function that uses SHA1 and iterates based on a counter value of 60 which is also static. This is why you’ll always a 60 in the middle of the HashedControlPassword value in the TORRC file.

I really needed to find out why 16. There had to be a reason. The most amount of beers that Roger Dingledine consumed in one sitting? The number of times Nick Mathewson was arrested for dealing meth? Someone from the Tor-talk mailing list finally pointed out what I was missing:

16 appears to be describing whether or not it’s base16 as opposed to base64. There’s nothing in the documentation about this and attempts to use a base64 encoded password didn’t work out for me. I’ll have to just leave this alone until someone can tell me more.

Code

Nothing useful really came out of this besides making myself happy diving into some code but I still wanted an actual output of some kind so I rolled my own version of the hashing algorithm in Python.

This will generate a hash for the password “foo”. Place the hash in the TORRC file and restart Tor and then you can test like this:

[me@me]# nc localhost 9051
authenticate "foo"
250 OK

External Links