Wired News

Planet Jabber

Monal IM: iOS 4.2 Final beta

2 days 4 hours ago

What I hope is the final beta for iOS 4.2 is out. This is a massive update that touches every part of the code and should be a huge improvement for everyone using Monal. Still no progress on adding to the french app store sadly. It will have to wait for at least 4.3 in 2020. I will be adding all of these changes to the macOS app next.

This is a large update with a lot of changes fixing or improving:

  • OMEMO key exchange
  • roster versioning
  • push support (tested Tigase too)
  • contact list accuracy
  • chat synch and catchup (MAM)
  • issues joining, rendering and leaving group chats (MUC)
  • discovery of HTTP upload on some servers
  • Ipad translucency issues
  • numerous UI glitches, dark mode quirks
  • many bugs that impacted stability

Anu

Paul Schaub: Pitfalls for OMEMO Implementations – Part 1: Inactive Devices

2 days 8 hours ago

Smack’s OMEMO implementation received a security audit a while ago (huge thanks to the Guardian Project for providing the funding!). Radically Open Security, a non-profit pentesting group from the Netherlands focused on free software and ethical hacking went through the code in great detail to check its correctness and to search for any vulnerabilities. In the end they made some findings, although I wouldn’t consider them catastrophically bad (full disclosure – its my code, so I might be biased :D). In this post I want to go over two of the finding and discuss, what went wrong and how the issue was fixed.

Finding 001: Inactive Devices break Forward Secrecy

Inactive devices which no longer come online retain old chaining keys, which, if compromised, break
confidentiality of all messages from that key onwards.

Penetration Test Report – Radically Open Security
  • Vulnerability Type: Loss of Forward Secrecy.
  • Threat Level: High
Finding 003: Read-Only Devices Compromise Forward Secrecy

Read-only devices never update their keys and thus forfeit forward security.

Penetration Test Report – Radically Open Security
  • Vulnerability Type: Loss of Forward Secrecy.
  • Threat Level: Elevated

These vulnerabilities have the same cause and can be fixed by the same patch. They can happen, if a contact has a device which doesn’t come online (Finding 001), or just doesn’t respond to messages (Finding 003) for an extended period of time. To understand the issue, we have to look deeper into how the cryptography behind the double ratchet works.

Background

In OMEMO, your device has a separate session with every device it sends messages to. In case of one-to-one chat, your phone may have a session with your computer (you can read messages you sent from your phone on your computer too), with your contacts phone, your contacts computer and so on.

In each session, the cryptography happens in a kind of a ping pong way. Lets say you send two messages, then your contact responds with 4 messages, then its your turn again to send some messages and so on and so forth.

To better illustrate whats happening behind the scenes in the OMEMO protocol, lets compare an OMEMO chat with a discussion which is moderated using a “talking stick” (or “speachers staff”). Every time you want to send a message, you acquire the talking stick. Now you can send as many messages as you want. If another person wants to send you a message, you’ve got to hand them the stick first.

Now, cryptographically OMEMO is based on the double ratchet. As the name suggests, the double ratchet consists of two ratchets; the Diffie-Hellman-Ratchet and the Symmetric-Key-Ratchet.

The Symmetric-Key-Ratchet is responsible to encrypt every message you send with a new key. Roughly speaking, this is done by deriving a fresh encryption key from the key which was used to encrypt the previous message you sent. This procedure is called Key Derivation Function Chain (KDF-Chain). The benefit of this technique is, that if an attacker manages to break the key of a message, they cannot use that key to decrypt any previous messages (this is called “forward secrecy“). They can however use that key to derive the message keys of following messages, which is bad.

Functional Principle of a Key Derivation Function Chain

This is where the Diffie-Hellman-Ratchet comes into play. It replaces the symmetric ratchet key every time the “talking stick” gets handed over. Whenever you pass it to your contact (by them sending a message to you), your device executes a Diffie-Hellman key exchange with your contact and the result is used to generate a new key for the symmetric ratchet. The consequence is, that whenever the talking stick gets handed over, the attacker can no longer decrypt any following messages. This is why the protocol is described as “self healing”. The cryptographic term is called “future secrecy“.

Functional Principle of the Diffie-Hellman Ratchet Algorithm Vulnerability

So, what’s wrong with this technique?

Well, lets say you have a device that you used only once or twice with OMEMO and which is now laying in the drawer, collecting dust. That device might still have active sessions with other devices. The problem is, that it will never acquire the talking stick (it will never send a message). Therefore the Diffie-Hellman-Ratchet will never be forwarded, which will lead to the base key of the Symmetric-Key-Ratchet never being replaced. The consequence is, that once an attacker manages to break one key of the chain, they can use that key to derive all following keys, which will get them access to all messages that device receives in that session. The property of “forward secrecy” is lost.

Smack-omemo already kind of dealt with that issue by removing inactive devices from the device list after a certain amount of time (two weeks). This does however only include own devices, not inactive devices of a contact. In the past I tried to fix this by ignoring inactive devices of a contact, by refusing to encrypt message for them. However, this lead to deadlocks, where two devices were mutually ignoring each other, resulting in a situation where no device could send a message to the other one to recover. As a consequence, Smack omitted deactivating stale contacts devices, which resulted in the vulnerability.

The Patch

This problem could not really be solved without changing the XEP (I’d argue). In my opinion the XEP must specify an explicit way of dealing with inactive devices. Therefore I proposed to use message counters, which gets rid of the deadlock problem. A device is considered as read-only, if the other party sent n messages without getting a reply. That way we can guarantee, that in a worst case scenario, an attacker can get access to n messages. That magical number n would need to be determined though.
I opened a pull request against XEP-0384 which introduces these changes.

Mitigation for the issue has been merged into Smack’s source code already

As another prevention against this vulnerability, clients could send empty ping messages to forward the Diffie-Hellman-Ratchet. This does however require devices to take action and does not work with clients that are permanently offline though. Both changes would however go hand in hand to improve the OMEMO user experience and security. Smack-omemo already offers the client developer a method to send ping messages

I hope I could help any fellow developers to avoid this pitfall and spark some discussion around how to address this issue in the XEP.

Happy (ethical) Hacking!

vanitasvitae

ProcessOne: SwiftNIO Workshop in Paris at dotSwift Conference

3 days 9 hours ago

I have partnered with the good folks at dotConferences to put together some contents for a SwiftNIO workshop. The workshop will take place in Paris on February the 4th, the day after the dotSwift conference.

If you are coming to Paris for the dotSwift conference, you can make the best of your trip by also attending my SwiftNIO workshop. If you are interested by Swift Server-side or Swift cross platform development, this a good opportunity to get you started.

What you’ll learn

SwiftNIO involves many advanced concepts, that may not always be obvious for Swift developer. The concept have been refined during the 10+ years of Netty development, so despite SwiftNIO being still quite young, it comes with a steep learning curve.

The workshop will guide you through the concepts behind SwiftNIO and the architecture of the project. From there it will show how to build you client library framework as a Swift Package and how to test it on Linux. Finally, it will show how to write a mini server-side framework. The example will be illustrated with a simple but real protocol for Messaging: STOMP (Simple Text Oriented Messaging Protocol).

The workshop will covers the following topics:

  • Concepts & principles of Swift NIO
  • Designing networking application: The role of threading & async / await
  • Understanding Futures & Promises
  • Going deeper into async code: Mastering the functional operators
  • Leveraging SwiftNIO provided components for HTTP
  • Building a simple client library (illustrated by STOMP protocol)
  • Building a simple server-side framework (illustrated by STOMP protocol)

You can learn more and book your workshop here: https://www.dotswift.io/training-swiftnio

Mickaël Rémond

Meme: viral internet stuff