Unified Encrypted Payload Elements for XMPP

Requirements on encryption change from time to time. New technologies pop up and crypto protocols get replaced by new ones. There are also different use-cases that require different encryption techniques.

For that reason there is a number of encryption protocols specified for XMPP, amongst them OMEMO and OpenPGP for XMPP.

Most crypto protocols share in common, that they all aim at encrypting certain parts of the message that is being sent, so that only the recipient(s) can read the encrypted content.

OMEMO is currently only capable to encrypt the messages body. For that reason the body of the message is being encrypted and stored in a <payload/> element, which is added to the message. This is inconvenient, as it makes OMEMO quite inflexible. The protocol cannot be used to secure arbitrary extension elements, which might contain sensitive content as well.

<message to='juliet@capulet.lit' from='romeo@montague.lit' id='send1'>
  <encrypted xmlns='eu.siacs.conversations.axolotl'>
    <header>...</header>
    <!-- the payload contains the encrypted content of the body -->
    <payload>BASE64ENCODED</payload>
  </encrypted>
</message>

The modern OpenPGP for XMPP XEP also uses <payload/> elements, but to transport arbitrary extension elements. The difference is, that in OpenPGP, the payload elements contain the actual payload as plaintext. Those <payload/> elements are embedded in either a <crypt/> or <signcrypt/> element, depending on whether or not the message will be signed and then passed through OpenPGP encryption. The resulting ciphertext is then appended to the message element in form of a <openpgp/> element.

<signcrypt xmlns='urn:xmpp:openpgp:0'>
  <to jid='juliet@example.org'/>
  <time stamp='...'/>
  <rpad>...</rpad>
  <payload>
    <body xmlns='jabber:client'>
      This is a secret message.
    </body>
  </payload>
</signcrypt>

<!-- The above element is passed to OpenPGP and the resulting ciphertext is included in the actual message as an <openpgp/> element -->

<message to='juliet@example.org'>
  <openpgp xmlns='urn:xmpp:openpgp:0'>
    BASE64_OPENPGP_MESSAGE
  </openpgp>
</message>

Upon receiving a message containing an <openpgp/> element, the receiver decrypts the content of it, does some verity checks and then replaces the <openpgp/> element of the message with the extension elements contained in the <payload/> element. That way the original, unencrypted message is constructed.

The benefit of this technique is that the <payload/> element can in fact contain any number of arbitrary extension elements. This makes OpenPGP for XMPPs take on encrypting message content way more flexible.

A logical next step would be to take OpenPGP for XMPPs <payload/> elements and move them to a new XEP, which specifies their use in a unified way. This can then be used by OMEMO and any other encryption protocol as well.

The motivation behind this is, that it would broaden the scope of encryption to cover more parts of the message, like read markers and other metadata.

It could also become easier to implement end-to-end encryption in other scenarios such as Jingle file transfer. Even though there is Jingle Encrypted Transports, this protocol only protects the stream itself and leaves the metadata such as filename, size etc. in the clear. A unified <encrypted/> element would make it easier to encrypt such metadata and could be the better approach to the problem.

QR-Code Generator for OMEMO

OMEMO is, like any other encryption protocol based on trust. The user has to make sure, that the keys they are trusting belong to the right users. Otherwise a so called Man-in-the-Middle attack is possible. An attacker might pretend to be your contact and secretly steal all the messages you thought were encrypted. They are, just to the wrong recipient.

To counteract such attacks, OMEMO encourages the user to verify their contacts fingerprints. A fingerprint can be considered the name of a contacts key. The user has to make sure, that the key A he is presented with really belongs to contact C by checking, if the fingerprints match. As those fingerprints are usually long, random series of characters, this is a tedious task. Luckily there are techniques like QR codes, which make our lifes easier. Instead of comparing two long strings character by character, you just scan a code and are done.

The QR-Code contains the Jabber-ID of the owner, as well as all of their fingerprints. So by scanning your code, a friend might automatically add you to their contact list and mark your devices as trusted. You can also put the QR-Code on your personal website, so people who want to reach out to you can easily establish a secure connection to you.

I spent the last few days looking into JavaFX (I have no real UI designing experience in Java, apart from Android), designing a small tool that can generate OMEMO fingerprint QR-Codes. This is what I came up with:

QR-Code generator with selectable fingerprints

The tool logs into your XMPP account and fetches all your published keys. Then it presents you with a list in which you can select, which fingerprints you want to include in the QR-Code.

There are still a lot of features missing and I consider the tool in no means as completed. My plans are to add the possibility to export QR-Codes to file, as well as to copy the text content of the code to clipboard. You see, there is a lot of work left to do, however I wanted to share my thoughts with you, so maybe client developers can adopt my idea.

Starting to use the Fellowship Card

I recently became a fellow of the FSFE and so I received a nice letter containing the FSFE fellowship OpenPGP smartcard.

After a quick visual examination I approved the card to be *damn cool*, even though the portrait format of the print of it still confuses me when I look at it. I especially like, how optimistically many digits the membership number field has (we can do it!!!). What I don’t like, is the non-https link on the bottom of the backside.

But how to use it now?

It took me some time to figure out, what that card exactly is. The FSFE overview page about the fellowship card misses the information, that this is a OpenPGP V2 card, which might be handy when choosing key sizes later on. I still don’t know, whether the card is version 2.0 or 2.1, but for my usecase it doesn’t really matter. So, what exactly is a smart-card and what CAN I actually do with it?

Well, OpenPGP is a system that allows to encrypt and sign emails, files and other information. That is and was nothing new to me, but what actually was new to me is the fact, that the encryption keys can be stored elsewhere than on the computer or phone. That intrigued me. So why not jump right into it and get some keys on there? – But where to plug it in?

My laptop has no smart-card slot, but there is that big ugly slit at one side, that never really came to value for me, simply because most peripherals that I wanted to connect to my computer, I connected via loved USB. It’s an ExpressCard slot. I knew that there are extension cards that can be fit in there, so they aren’t in the way (like eg. a USB dongle would be). There must be smart-card readers for ExpressCards, right? Right. And since I want to read mails when I’m on a train or bus, I’d find it convenient, when the card reader vanishes inside my laptop.

So I went online and searched for ExpressCard smart-card readers. I ended up buying a Lenovo Gemplus smart-card reader for about 25€. Then I waited. After half an hour I asked myself, if that particular device would work well with GNU/Linux (I use Debian testing on my ThinkPad), so I did some research and reassured me, that there are free drivers. Nice!

While I waited for my card to arrive, I received another letter with my admin pin for the card. Just for the record 😉

Some days later the smart-card reader arrived and I happily shoved it into the ExpressCard slot. I inserted the card and checked via

gpg –card-status

what’s on the card, but I got an error message (unfortunately I don’t remember what exactly it was) about that there was no card available. So I did some more research and it turns out I had to install the package

pcscd

to make it work. After the installation, my smart-card was detected, so I could follow the FSFEs tutorial on how to use the card. So I booted into a live Ubuntu that I had laying around, shut off the internet connection, realized that I needed to install pcscd here as well, reactivated the internet, installed pcscd and disconnected again. At that point in time I wondered, what exact kind of OpenPGP card I had. Somewhere else (forgot where) I read, that the fellowship card is a version 2.0 card, so I could go full 4096 bit RSA. I generated some new keys, which took forever! While I did so, I wrote some nonsense stories into a text editor to generate enough entropy. It still took about 15 minutes for each key to generate (and a lot of nonsense!). What confused me, was the process of removing secret keys and adding them back later (see the tutorial.)

But I did it and now I’m proud owner of a fully functional OpenPGP smart-card + reader. I had some smaller issues with an older GPG key, that I simply revoked (it was about time anyway) and now everything works as intended. I’m a little bit sad, because nearly none of my contacts uses GPG/PGP, so I had to write mails to myself in oder to test the card, but that feel when that little window opens, asking me to insert my card and/or enter my pin pays up for everything 🙂

My main usecase for the card became signing git commits though. Via

git commit -S -m “message”

git commits can be signed with the card (works with normal gpg keys without a card as well)! You just have to add your keys fingerprint to the .gitconfig. Man, that really adds to the experience. Now every time I sign a commit, I feel as if my work is extremely important or I’m a top secret agent or something. I can only recommend that to everyone!

Of course, I know that I might sound a little silly in the last paragraph, but nevertheless, I hope I could at least entertain somebody with my first experiences with the FSFE fellowship card. What I would add to the wish list for a next version of the card is a little field to note the last digits of the fingerprint of the key thats stored on the card. That could be handy for remembering the fingerprint when there is no card reader available. Also it would be quite nice, if the card was usable in combination with smart-phones, even though I don’t know, how exactly that could be accomplished (maybe a usb connector on the card?)

Anyways that’s the end of my first blog post. I hope you enjoyed it. Btw: My GPG key has the ID 0xa027db2f3e1e118a 🙂

Edit: This is a repost from october. In the mean time, I lost my admin pin, because I generated it with KeePassX and did not click on “accept” afterwards. That’s a real issue that should be addressed by the developers, but thats another story. I can still use the card, but I can’t change the key on it, so some day I’ll have to order a new card.