Howdy! Here we are, back with some news for you, and also an explanation about how we approach security in Caliopen. Ready? Let’s go!
The News
- Unfortunately in March other projects than Caliopen left our lead developers little time left : little progress were thus made on this regard. In order to allow new persons to easily join the project and contribute, we plan to completely reorganize our code: this is being taken care of, and it will soon be done.
- Our work on the gamification process of security setup continues: we met with the Manzalab crew in order to discuss our ideas. A public pad, where everyone can bring his contribution, has been open.
- We also met with project PEPS: our project have quite different goals, but we’d both like for our project to converge on some points. We have thus started considering the integration of the Privacy Index into other messaging services.
- Caliopen crossed the border! The BGLUG hosted the first conference about Caliopen outside France: we thank them for their invitation!
- Next on our list is a conference on April 24th in Brest. Do you want us to give a talk about Caliopen? Becasue we’d surely love to! Please get in touch with us!
The Keys Caos
Since the beginning of Caliopen, we’ve been asked over and over what encryption we will use in order to guarantee users’ privacy.
If we don’t have a straight forward reply, that’s because we have to lay down the premises first:
– We can’t talk about the encryption system of Caliopen, by design, the user will be able to choose not to encrypt anything, to encrypt the messages he sends, or to encrypt the messages saved in Caliopen… These choices might prove to be more or less constraining for the users on a daily basis: their adoption will of course influence the Privacy Index score, but users won’t be forced into them. Caliopen will surely offer encryption systems, it’s in its DNA, but the user won’t be forced to adopt them.
– Also, we don’t think that anybody can guarantee privacy. Even in the most protected environment one can always be trapped by a microphone, a USB key plugged while away, a targeted attack, or just a plain dumb mistake. Caliopen’s goal is to make mass surveillance harder, making it too expensive to be used. The goal is not to protect the privacy of some individuals (even though, of course, that’s what we will strive to do), rather, we aim to improve the privacy protection of all of the users.
These are key points in order to understand Caliopen. We might be used to think in a binary mode: my communications are encrypted, and thus I am protected VS my communications are not encrypted, thus the NSA knows everything about me. But with Caliopen we are building a multi-step system: me and my contacts have now a better protection, but we still can do more.
Nonetheless, this explanation wouldn’t suffice without presenting our technical choices about encryption. And especially about encryption keys.
Since the beginning we decided that Caliopen won’t lock users into its own ecosystem: our choices are conservatives and compatibles with the whole of the messaging systems existing today, according to the good old Postel principle ( “Be liberal in what you accept, and conservative in what you send”). The same is true about encryption: in order to remain compatible with existing solutions, PGP will be available to those willing to sign or encrypt their messages.
PGP has a huge advantage: it is completely decentralized. Contrary to S/MIME, it doesn’t use any central authority to distribute public keys.
On the other hand, PGP has a huge disadvantage: being completely decentralized, it might be hard to find the public key that will allow you to encrypt the message you are writing to a new contact, and it is also hard to make your own public key available to those willing to write you encrypted messages. A key server? The SKS protocol has been a great advance, no doubt about that, but it remains rather unstable to be reliable on a daily basis. And, by centralizing key management, it represents a vulnerability that weakens PGP. This is why we thought it was necessary to offer another solution to Caliopen users willing to use their own encryption keys.
[expand title=”«The Keys Chaos» Post by Werner Koch translated from German.” swaptitle=”The Keys CHaos (The article is in German since it is a reply to an article published n the German magazine C’T)”]
The Keys Chaos
(The article was written in German, because it is a reply to an article published in the German newspaper C’T)
In C’T issue 6/2015, February 21st, Jürgen Schmidt sings an ed piece asking to “let PGP die”.
According to his words, PGP (as well as the OpenPGP standard) is outdated and “a limping dynosaur”. In order to prove it, he compare it to Apple’s on line services, and to the instant messaging tool Textsecure (Signal on iOS).
Let’s not mention that, being US-based, these two companies mith be forced to put backdoors into their software, but that’s like to compare trains to submarines. They are both made of steel and they both carry things, but that’s all they have in common.
Still, in his article “The Keys Chaos”, page 160, that’s how he approaches the issues.
Though, to compare online protocols (such as TextSecure) with offline protocols (such as OpenPGP or S/MIME) isn’t really a fair choice. A meeting, in a meeting room or through an online conference, won’t have the same constraints as a mail exchange. Many problems are easier to solve in a simultaneous exchange than in an asynchronous discussion.
Nonetheless, mails, e-mails and summaries are still far from useless; it is only through these offline communication tools that informations can be kept confidentials and remain available in order to be used later.
And we need offline protocols, that work even when we don’t have network anymore. The «Sneakernet» network, by the way, is often cheaper (more bandwith, cf. Backups) and more sure than an online connection. Those who saw Citizenfour can remeber how Snowden distinguish his online laptop and his offline one (airgapped). Now, e-mail is by its own nature and offline tool.
OpenPGP, contrary to S/MIME (the other offline encryption protocol), is decentralized, which brings great advantages: one can use it anywhere, it doesn’t need a Certification Authority, just like a meeting doesn’t need to be confirmed by a registration office (that’s what a certification authority would be in real life). To whish that keyservers require a confirmation e-mail before one is allowed to submit his key it means to forgo the decentralized architecture of OpenPGP, since this would create a centralized system.
Of course, in a centralized system one can check the identity of the key owner. But that’s impossible in the context of services replicated and decentralized, which were built on purpose without a central control.
Regarding the problems Jürgen Schmidt complains about, some undecryptable emails, they would be easily solved by publishing his contact informations along with the legal informations on the magazine’s website. It would be enough to just add to his email address at least his key ID, its fingerprint, or even a direct link.
He doesn’t mention as well the same problems that arise using S/MIME, even though it is (looks like) the other most widespread encryption protocol for email. This is all the more surprising since C’T has been promoting, for several years already, S/MIME as the easy-to-use encryption solution.
But how to find a key if it hasn’t been sent with a first e-mail? Alleged trust warranties of certification authority are a joke. With their help, any spying organisation – pubic or private – can get any certificate for any address. Those are not as clearly fake keys as those you see on key servers, but they sure make life easier for the NSA, GCHQ and BND.
To use the web interface of a key server to prove that one can submit “fake” keys is a pointless method, since the key server can (or want) not ake cryptographic controlos. This should be well-known by the author of the article, notably since he asked me this question a few days before that. Using OpenPGP software would highlight right away that these are “fake” keys, since no one of those would be imported or listed in the keychain.
It’s true: you can submit any key. The usual example is “president@whitehouse.gov”, with around 27 keys. This is clearly nothing new, and even something you learn in every cryptoparty. This is also the reason why some magazines or some business cards mention also a fingerprint. Most experienced users have even their key signed during “Keysigning Parties” (even though it is more a kind of a party game than a solution useful for everyone).
Rather than to tear down all at once the key servers and OpenPGP, it would be more useful to ask ISPs to act: e-mail addresses are uniquely managed thourgh DNS, thus one could – and should – use also DNS to obtain the keys.
Of course one can always forge the DNS, since it isn’t really secure, but thre would be at least a key for every e-mail address. RFCs about this subject exist since several years and GnuPG implemented this system since 2006 (see http://www.guug.de/veranstaltungen/ffg2006/abstracts.html#4_2_2 ). On this matter, in 2012, with my colleague Marcus Brinkmann, I started a roject named STEED (see http://g10code.com/steed.html ), and C’T published an article more or less exact about it, “Trust at first sight” (see http://www.heise.de/artikel-archiv/ct/2012/20/190_Vertrauen-auf-den-ersten-Blick ).
Unfortunately, SIP don’t want to participate and prefere to distract us by preaching security through dumb solutions like the “made in Germany” e-mail or by praising as a reference the backdoored service De-Mail.
(see http://www.ccc.de/en/updates/2013/stellungnahmedemail)
[/expand]
This kind of problems have been recently discussed by Werner Koch (we’ve translated his article answering a critic against PGP) and we chose to use DNS, and this for several reasons.
– Every Caliopen user has (at least) an ID (user@domain) that can be used as an e-mail address, DNS allows to easily find his public key. It will suffice to query the domain name server (for example ‘dig @ns.brainstorm.fr -t cert laurent.brainstorm.fr’ will provide the PGP key for “laurent@brainstorm.fr”). No need for a working SKS server, no need to rely on a third party to act as an intermediary.
– On this regard, DNS is a decentralized system: apart from the zone admins, especially if DNSSEC is used, it is extremely hard for a third party to edit it in order to insert fake keys.
– Managed like this, keys are easy to revoke (which is one of the main problems with PGP).
There are still more reasons, but while translating Werner Koch‘s post, we discovered that those are described in detail in a document of the STEED project (a project featuring, once again, Werner Koch): http://g10code.com/docs/steed-usable-e2ee.pdf .
Once again, Caliopen users won’t be forced: those preferring to manage public keys in a different way will be most certainly allowed to do so. Caliopen’s algorithms will calculate the Privacy Index according to the management technique chosen: more points will be earned with a safer management choice, but all of them will be handled, of course.
We look forward to keep on explaining our encryption choices (key generation, private key management, multiple devices use) in our future posts, and are eager to have your feedback!
Contact
While waiting for our next blog post, you may want to reach us: good idea! And, even better, it’s so easy!
- Through IRC, on irc.freenode.org, channel #caliopen or, to take part in the development, on #caliopdev. And please, don’t be intimidated if, when you come in, we are talkin in French: let us know that you’d rather converse in English and we’ll immediately switch language!
- On Twitter, we are @caliopen_org
- Drop us a good old-fashioned e-mail! contact@caliopen.org
- Github: everything’s clear, no need to ask questions? Great! We are waiting for your PR! Caliopen is on Github