Penetration Test Report (RadicallyOpenSecurity): 2022 Quick Security Evaluation openEngiadina v1.0

Quick Security Evaluation
openEngiadina
NGI0 Zero
V 1.0
Amsterdam, January 31st, 2022
Public
1 Introduction
As part of the NLnet projects your project openEngiadina has received a basic quick security evaluation from Radically
Open Security. The goal of the review is to provide advice and input to consider in the further development of your
project. The selected project gets 2 person days plus an extension of 1.5 person days from ROS for a quick security
evaluation.
2 Security Evaluation For openEngiadina
Tasks Performed
• Discussion with representatives of the project in the ROS chat, issue tracker and via video conferences.
• Reading of background material and public design discussions on the mailing list.
• Reading of related posts on the activitypub discussion forum and inqlab.net.
• Watching the ERIS: Encoding for Robust Immutable Storage presentation.
• Discussing the scope of the security evaluation, project requested a strong focus on the ERIS specification.
• Reviewing the ERIS specification in version 0.3.0, which from here on will be referred to as the specification.
• Interactive discussion in the issue tracker on a number of security and functionality aspects of the specification.
Please note that the OpenEngiadina repositories and code were not analyzed.
Security Considerations
• The specification contains multiple http:// link references. We recommend switching to https:// where
possible (issue #4).
• The specification makes use of the purl.org link shortener service for multiple document references. This brings
with it a number of risks, notably discontinuation of the service at some point in the future and an attacker gaining
sufficient access to manipulate the link references. According to the project representatives, these redirections are
meant to serve as dynamic web references that can be updated at some point in the future, should the URLs of
certain essential resources change. Purl.org is run by the Internet Archive non-profit organization (issue #5).
• Aspects of the specification regarding CONFIDENTIALITY vs. INTERMEDIARY PEER DENIABILITY
security goals were discussed. As a short summary, the current ERIS specification draft does not provide full
CONFIDENTIALITY in any usage mode due to the custom cryptographic construction for convergent encryption
which always generates the same ciphertext for blocks with identical plaintext content. Under some conditions,
this allows attacks that break the confidentiality of some of the encoded information (issue #6).
2
• The specification description of the ChaCha20 usage in §2.1.2. is misleading with regard to the key handling, as it
suggests that the encryption key is never reused. For a given convergence secret, all identical data blocks will re-
use the same derived ChaCha20 encryption key, well-known IV and well-known counter combination to generate
identical encrypted blocks. This construction is intentional as described in §2.3., but should be documented better
(issue #7).
• The specification requires compatibility with both the 1KiB and 32KiB ERIS block size for any inputs. However,
the inherent storage inefficiencies in using large storage blocks for short inputs (and vice versa) will likely result
in a very predictable block size choice based on input size during encoding, as recommended in the specification
itself. This presents a clear opportunity for attackers to determine if the original input data was larger than the
threshold (16KiB - 1 byte) without access to the read capability of the ERIS-encoded data. This information can
be problematic for the stated goal of INTERMEDIARY PEER DENIABILITY and CENSORSHIP RESISTANCE
since intermediary peers are well aware of the block size. As an attack, censors could enforce that all 32KiB ERIS
blocks are rejected on the peer or network level, which would prevent the exchange of most existing larger files
above the threshold without blocking the exchange of most smaller files (issue #9).
• Assuming that a peer-to-peer network is used to fetch blocks of new content, it is to be expected that attackers
run intermediary peers or perform surveillance on non-malicious peers. Over time, traffic analysis on block
accesses can reveal statistical information about block clusters as well as block to client relationships, and this
information can be recorded permanently. The practical attack details depend on the implementation, but we think
it is generally plausible that under the right conditions an observer can identify a large percentage of blocks that
belong to an ERIS encoded file and reconstruct parts of the ERIS tree structure relationship between blocks based
on access patterns. This is simplified if the structure in question is accessed repeatedly or only available from
a peer that is under observation. A leak of ERIS block plaintext to ERIS block ciphertext mappings, for example
through an ERIS URN that becomes known to an attacker later, may be used for retroactive actions against clients
which are known to have requested some of the associated blocks at some point. This scenario is not represented
in the official threat model. (issue #11).
• The ERIS design has integrity protections on node blocks and data blocks through the use of cryptographic
hashes in a tree structure (Merkle tree). Notably, the URN itself is not protected by any integrity check or
signatures and susceptible to getting replaced with a modified URN in transit. A full replacement of the URN can
lead to the various impacts, including downloading attacker-controlled files instead of the intended files. The threat
model of the specification requires PEER ENTITY AUTHENTICATION and CONFIDENTIALITY to ensure trust
in the messages that are passed between publisher and audience to address this attack potential. However, these
properties do not guarantee DATA INTEGRITY, so the official threat model of the reviewed specification version
does not rule out manipulations of the message exchange that is containing the URN. Note that the specification
authors have changed the threat model as a result of this evaluation (issue #16).
3
• Practical implications of issue #16 were discussed. Partially modifying the URN without knowing the original URN
content has different impacts depending on the affected section. We discussed the implications of an attacker with
the ability to trigger undetected bitflips in the message between publisher and audience. For example, partial data
corruption of the root reference key pair section of the URN leads to a denial of service as the ERIS data
of the root reference block cannot be found or decrypted correctly.
We have identified two attacks that involve a modification of the level of the root reference section
which can be triggered with minor message modifications:
• In the first attack scenario, the original level is decreased by the attacker, which makes the client download a
subset of the intended ERIS tree structure with reduced height and misinterpret node blocks as data blocks.
In most cases, this will fail at the decoding stage, but there is some probability that the data tail happens to
match the expected padding data structure. This results in the client incorrectly using the reference-key pair
data as the decoded plaintext file.
• In the second attack scenario, the original level is increased by the attacker, which makes the client
download and decode all of the available ERIS structure data, but the client expects there to be one or
more additional levels. Unless some specific edge cases are hit which abort the decoding, the client will
misinterpret the data blocks as node blocks and convert the correctly decrypted plaintext into a list of
reference-key pairs (64 byte per pair). Looking for additional blocks that do not exist, it then asks its block
source (likely a peer-to-peer network) for blocks that match these references, leaking half of the plain-text
data to the network peers in the process.
We consider these attacks through