Audit of Session Secure Messaging Application
2021-04-29 07:00:00 Author: blog.quarkslab.com(查看原文) 阅读量:138 收藏

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 32 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.

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].


文章来源: http://blog.quarkslab.com/audit-of-session-secure-messaging-application.html
如有侵权请联系:admin#unsafe.sh