Going to the freelance side

From now on, I am an independent geek! After nearly 2 years at Login People, I am jumping out in the sea to work for myself.

I will do mainly web development (Rails, Node.JS) and software security (penetration testing, code reviews, protocol audit). Feel free to contact me for missions, I will be happy to work with you!

Software security is like medicine

People don't get software security. Between the legends around hackers, the scaremongering by salesmen and the technical level needed to practice it, you won't even try to understand. It is hard to get a high level view of how it works, and how you can protect yourself. But there's a nice little metaphore to understand security: it's like medicine!

Medicine is about taking care of your body, fighting off illness, healing injuries. The body is a big machine that can fail in a lot of ways, depending on a lot of parameters. It is the same for software security: you want to prevent and repair any disruption that could fail at any time. Security, like medicine, is a very technical domain, and takes a lot of time to learn. Even after learning, you still don't know everything, and you must keep up to date with recent research.

But basic body maintenance is easy. And protecting your software against basic attacks is easy too. You don't need to study for 11 years to prevent basic SQL injections. Most of the time, the diseases and bugs that will affect you are common, and you don't need Dr House to prevent them.

Bodies and software are problematic because they both decay through time, and are very sensitive to their environment. Change the environment, and you could catch something new. The world is full of germs and criminals. Is that a good reason to always stay at home? Obviously not. You must accept that you can get sick at any time. So, take steps to protect yourself. Wash your hands and sanitize your inputs. And beware of snake oil.

Feel free to extend on the metaphore in the comments, and use it to explain software security around you!

By the way, if you need someone to auscultate your applications, you can contact me at geoffroycouprie.com

Hiring gurus

I see a lot of posts on job boards asking for "gurus", ninjas" or whatever. That is ridiculous at best, dangerous at worst.

Ridiculous, because you won't find gurus on job boards. The real stars will not look for a job on these websites. They stay in companies that know their value and pay them well. Or they are directly contacted with offers tailored to them. They don't need job boards.

That is also dangerous, because you will gather good or average developers with a very high idea of themselves. They think of themselves as awesome developers, so why would they learn anything? For your teams, you need team players, humble people, able to recognize their errors, and able to learn. You don't need a lonesome cowboy.

Even worse, you will refuse future gurus because they're not good enough right now. Some developers have a lot of potential, and can bloom in the right environment. Think of it: a developer cheaper than others who will deliver more than others in a year! You will also refuse useful people: an bad developer with a knack for debugging, a bad developer with a lot of knowledge about low level problems, a bad developer who will boost your team's productivity, just because he's good with people...

These job posts reinforce the cargo cult of the awesome geek wrangling tons of awesome code without sleep and with a lot of coffee. Enough with that! We geeks are not produced in chain, with A, B, or C quality level. We are real people, with unique qualities or defects, and you will miss out on awesome people while you wait for your prince charming.

Your data is precious

Following LinkedIn's large password leak, I have seen a dangerous thought spread to friends and colleagues:
"so what if my LinkedIn password has leaked? What can they do? Look for a job for me?"

That is based on wrong assumptions about what an attacker wants and can do. And it is mistaking the low value you get from a service with the value of your data. Your data is PRECIOUS. Maybe not to you. But everything can be sold, and you'll always find someone interested to buy it. Let's see a few creative uses of your Linkedin account:

Analyze your data

You might think that what you share is of no use to anyone except potential recruiters, but by mixing your resume, shared links, private messages, all the data you put on the website, I could build a nice profile and sell it to advertisers. Did you put your address and phone number somewhere in your profile? Awesome! I have a lot of targeted advertisements for you!

Obtain access to your other accounts(email, Facebook, Twitter, Viadeo...)

With your email address and your password, I could probably guess the password for other services. Almost nobody has strong and different passwords for every service. Would you like to see your Facebook or Twitter account compromised? I don't think so.

Oh, remember to use a strong password, or even two factor authenticatiob for email. A lot of password recovery systems sues emails, so if your mailbox is compromised, your accounts will be compromised.

Spam/SEO

Nothing ca be done with your account? oh, you have contacts. And maybe, a well referenced profile. I'd be able to send spam links to all your contacts with the user feed, and put them in your profile, to improve the ranking of my websites. Sure, there's no harm to you, if you don't care about losing credibility or annoying your contacts.

Using the contact list

Oh, yes, I could sell your contact list, that's easy money!

While I'm at it, I could have fun with your friends and colleagues:

  • ask them for money, nude pictures, confidential information, etc.
  • tell them that your email account has been compromised, and that they must address their emails to another address controlled by me
  • obtain access to their accounts with social engineering
You may be insignificant, but that's not necessary true of your contacts. In social networks, your network has a value, and you must protect it. It is your responsibility to make sure your friends and colleagues don't get compromised through your account.
It reminds me of the 90s, when I often had this dialogue:
Me-You should put an antivirus and firewall on your computer.
You-Why should I? There's nothing interesting on my computer, why would anyone want to infect it?
Me-I receive from you 10 emails a day, and all of them contain a virus."

Worst Case Messaging Protocol

We already have lots of tools to communicate safely, and in some cases, anonymously. These tools work well for their purpose, but spying and law enforcement tools have also improved.

People are forced to decrypt their hard drives in airports. Rootkits are developed by police forces. DPI systems are installed on a country level. Using the graph of who communicates with whom, it is possible to map the whole hierarchy of an organisation, even if all communications are encrypted. How can we defend against that?

I believe that the analysis of organisations is one of the biggest threats right now. The ability to recognize an organization is the ability to destroy it by seizing a few members. That may be useful against terrorists, but these tools are too powerful, and they may be used by the wrong hands. Terrorists already know how to defend against such systems, but what of common people? Any company, association or union could be broken anytime.

I think we need tools to mount resilient organizations. A compromised node shouldn't bring down the whole system. Intercepted messages shouldn't give too much information on the different parties. People can still find ways to send their messages safely (PGP, dead drops, giving USB keys hand to hand), but we need a framework to build decentralized human systems.

Here is the solution I propose: a messaging protocol designed to protect identities and route around interception. This protocol is designed to work in the worst case (hence its name), when any communication could be intercepted, and even when we can only use offline communication.

Every message is encrypted, signed and nearly anonymized (if you already know the emitter or receiver, you can recognize their presence, but this can be mitigated). To introduce redundant routes in the network, a simple broadcast is used (the protocol is not designed for IP networks, but for human networks, with limited P2P communication). Any node can be used to transmit all the messages. The fundamental idea is that if you're compromised, the whole organization can still work safely without you.

Prerequisites

Assumptions

  • Every communication can be intercepted
  • if a node is compromised, every message it can read or write is compromised
  • People can still create a P2P (IRL) network to communicate (aka giving an USB key to someone else)

Goals

  • Confidentiality
  • Anonymity
  • Authentication
  • Deniability? (I am just a messenger)
  • Untraceability
  • Can work offline (worst case)

For this protocol, we need a RNG, a HMAC function, a symmetric cipher and an asymmetric cipher. I have not yet decided what algorithms must be used. They could be specified in the message format, to permit future changes in algorithms.

Message format

  • nonce1
  • HMAC( sender's public key, nonce1 )
  • expiration date
  • symcrypt( symmetric key, message )
  • nonce2
  • For each receiver:
    • asymcrypt( receiver1's public key, symmetric key )
    • HMAC( receiver1's public key, nonce2 )
    • asymcrypt( receiver2's public key, symmetric key )
    • HMAC( receiver2's public key, nonce2 )
  • asymsign( sender's private key, whole message )

Here is how it works:
An identity is represented by one or more public keys (you can have a different public key for each of your contacts, it makes messages difficult to link to one person). They are not publicly linked to a name or email address, but the software layer could handle the complexity with a good enough UI. I do not cover key exchange: users must design their own way to meet or establish communications.

Every user is a hub: all messages are broadcasted by all users. To prevent data explosion, expiration dates are used. Users recognize the message they receive and the identity of the emitter, using the HMAC of the public keys. All communication are encrypted, but I use the convergent encryption ideas to have multirecipient messages.

Handling the messages

Parsing

  • verify if one of my public keys is in the receivers by calculating the HMAC with nonce2
  • validate the signature (if I already know the emitter's public key)
  • decrypt the symmetric key that was encrypted with my public key
  • decrypt the message

Creating messages

  • write the message
  • choose the emitter's identity and public key
  • choose the receivers and the public keys used
  • choose an expiration date
  • generate two random nonces
  • generate a symmetric key
  • insert nonce 1 and the HMAC of nonce 1 and my key
  • insert the expiration date
  • encrypt the message with the symmetric key and insert it
  • insert nonce 2
  • for each receiver:
    • encrypt the symmetric key with the receiver's public key and insert the result
    • insert the HMAC of nonce 2 and the receiver's public key
  • sign the whole message with my private key and append the signature

Sending messages

  • Take all the messages you received
  • filter them according to some rules:
    • remove expired messages
    • remove messages too large?
    • etc
  • add your messages to the list
  • give the message list to the next node in the network

This protocol is voluntarily simple and extensible. New techniques can be devised based on this protocol, like dummy receivers in a message or dummy messages to complicate analysis. It is independent of the type of data transmitted, so any type of client could use this protocol (it is at the same level as IP). Most of the logic will be in the client and the contact manager, to present an interface easy to use.

I truly hope we will never need this to communicate, but recent events have convinced me that I need to release it, just in case.

I am open to any critique or suggestion about this protocol. I will soon open a repository to host some code implementing it, and it will of course be open to contributions :)