Request Encryption Audit completed by Cure53
Alexandru Stoicescu
Jan 15, 2022
2 min.
The full report can be downloaded here
We present below the encryption audit report written by Cure53 and our action plan.
Encryption is what allows users to keep ownership of their data. Before reading the audit report, it is relevant to remind how this works very briefly. Our network allows end-to-end encrypted invoice sharing, between multiple parties: the invoice issuer, the payer, a CPA, an auditor, etc. When sending an invoice to the network, all the data is encrypted with a key, which is then encrypted with the public keys of the payer and issuer. They can later grant permissions to third-parties.
The scope of collaboration with Cure53 included the audit and answers to a few questions.
The report revealed 3 identified vulnerabilities with severity from Low to Medium. Below you can find a summary of these findings, as well as the actions which were taken to answer each of them.
We want to thank Dr.-Ing. M. Heiderich and Dr. N. Kobeissi for their precious advice, for their seriousness and for their interest in our project. We can only provide end-to-end encryption to our users with good serenity thanks to them.
These findings were all implemented and released in June: https://github.com/RequestNetwork/requestNetwork/commits/master
RN-01-001 WP1: Insecure PRNG for cryptographic material (Low)
Description: Use of a not cryptographically secure pseudorandom number generator to generate the salt of the payment reference
Severity: This salt is used only to generate the payment reference. It can not lead to fraud.
Action: Change the call Math.random() by crypto.randomBytes()
Status: fixed – Commit
RN-01-006 WP1: Encryption scheme reveals plain-text oracle (Medium)
Description: The encrypted content is highly predictable (following a standard and normalized JSON structure). This could allow an attacker to use the hash to guess the content by brute-force.
Severity: Although the JSON structure is fixed, all the transactions of the protocol include a signature. This signature adds non-predictable 60+ bytes that make the brute-force attack infeasible. Users should also consider that there are not enough requests existing at the moment of the audit to make any kind of brute-force attack.
Action: Use the authenticated encryption algorithm aes-256-gcm instead of aes-256-cbc and remove the hash.
RN-01-007 WP1: No integrity from symmetric encryption (Medium)
Description: The encryption algorithm aes-256-cbc does not provide cryptographic integrity.
Severity: Ranked Medium by Cure53. What is the actual impact on users? aes-256-cbc is used to encrypt the request content (symmetric encryption). If a malicious node wanted to alter the integrity of the encryption result, the encrypted request could not be read by anyone. This request would appear as an error right after creation, and users would stop using this dapp or node. There is no way for the nodes to alter the clear content. The impact is irrelevant for our use case.
Action: Use the authenticated encryption algorithm aes-256-gcm instead of aes-256-cbc.
Status: fixed – Commit
