Oxen  mandated Quarkslab to perform an audit of their instant messaging solution Session . This application, forked from Signal, aims to improve users privacy by using an onion routing mechanism . This mechanism differs from Tor's one by requiring a deposit in their own cryptocurrency to operate a Service Node (Snode  ), 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.
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.
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:
the Android application;
commit b5ecb8fd991c424c071ccd20f726a4c674d50b7b (tag audit)
commit 1becaa7e7051b941c3935e3203194afa948ffe87 (tag audit)
the iOS application;
commit 2c18c3694d725f353cbe65c927fc37780c3c6260 (tag audit)
commit df787d84bb8adb23c10df669296dee8d7988e410 (tag audit)
commit f818a61c04eeb78662dc4626014575bff9eb879b (tag audit)
the Desktop application.
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.
We provide in the Chapter 2 of the full report  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  a more censorship-resistant network than Tor or I2P. Documentation regarding how this network is designed and used is available online .
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  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, 2) https://docs.oxen.io/about-the-oxen-blockchain/oxen-service-nodes|
|||Full report of the assessment|