Audit of Session Secure Messaging Application

Oxen [1] mandated Quarkslab to perform an audit of their instant messaging solution Session [2]. This application, forked from Signal, aims to improve users privacy by using an onion routing mechanism [3]. This mechanism differs from Tor's one by requiring a deposit in their own cryptocurrency to operate a Service Node (Snode [4] ), the Oxen equivalent of a Tor Entry, Relay or Exit Node. While reviewing the architecture of this solution, we found some issues and provided recommendations to improve parts of the implementations.

Introduction

In March 2020, Oxen ordered a security review of Session for all the implemented platforms (Android, Desktop, iOS).

The Quarkslab assessment was spread over a year for a total of 42 days with two engineers. The full report of the assessment can be found here.

All important findings have been patched by Oxen throughout the audit process.

During the first two audits (of the Android and iOS versions), the protocol used was the one implemented from the forked Signal application. It is worth mentioning the fact that Oxen performed a complete redesign of the cryptographic protocol used for encryption and signature of messages. This refactoring took place right before the third and last audit of the desktop version. As a result, the original 32-day deadline has been extended by an additional 10 days.

Neither Quarkslab nor the report's author has funds invested in Oxen or in $OXEN crypto-currency.

Scope

Through this audit we reviewed three components that are part of Session, each evaluation was performed by one evaluator in 10 days.

Those audits were carried out sequentially in the following order:

As the audit had quite a short time limit, we engaged the target in different ways in order to cover the most important aspects that could impact the security of the application. Overall, we tried to consider various attacks based on the degree of power of the attacker:

  • Stolen device attacker;

  • Fully remote client-side attacker;

  • Network omniscient attacker;

  • Compromised server attacker (or server owner);

  • Side applications in the same device.

Results

We provide in the Chapter 2 of the full report [5] a list of findings and recommendations for each application.

We would like to highlight the fact that we only disagree on the security/usability tradeoff regarding private key generation process.

We paid specific attention to the privacy aspect of the different implementations of Session, this is why some issues are related to sensitive information leaks.

We have not studied the crypto-economic aspects that would make Lokinet [6] a more censorship-resistant network than Tor or I2P. Documentation regarding how this network is designed and used is available online [7].

Conclusion

Oxen's Session really improves Signal privacy and resilience by adding an overlay network to the existent end-to-end encryption instant messaging solution. The onion-routing mechanisms make use of Oxen’s Snodes [4] to store and exchange messages, however, there are some other centralized standard web services that are still used through the overlay network (for the push service and to deliver attachment files).

The overall security level of this application is good and makes it usable for privacy-concerned people.

The full report of the assessment can be found here.

We would like to thank the Oxen team for making this assessment possible.

[1]https://oxen.io/
[2]https://getsession.org/
[3]https://arxiv.org/pdf/2002.04609.pdf
[4](1, 2) https://docs.oxen.io/about-the-oxen-blockchain/oxen-service-nodes
[5]Full report of the assessment
[6]https://lokinet.org/
[7]https://docs.loki.network/

If you would like to learn more about our security audits and explore how we can help you, get in touch with us!