While the integrity of single files is protected by storing GCM authentication tags in the metadata file, I couldn't find any measures to protect integrity and authenticity of the metadata file itself in the e2ee whitepaper.
In case of an active attacker (who controls the server and can read and write files including the metadata file), this might have some undesired consequences. Three problems that came to my mind:
Replacement of the metadataKeys
As the metadataKeys aren't authenticated, an active attacker could simply generate some metadataKeys himself, encrypt them with the public keys of the users who have access to the folder, and replace the old metadataKeys with his own ones.
If the folder isn't empty, old files can't be decrypted anymore and the attacker should therefore delete them. As he knows the name of the folder, he might place some new unsuspicious files in there to increase the chances of remaining undetected.
Possible scenario: Alice creates a new folder, sets it to encrypted but doesn't immediately upload files. When she uploads files on the next day, the attacker has already replaced the metadataKey by his own key and can now decrypt the uploaded files.
Mitigation: Sign the metadataKeys with Alice's private key.
Reusage of old metadataKeys
An attacker who knows an old metadataKey can write files to the encrypted folder and therefore violate integrity and authenticity of the files.
Possible scenario: The option to use a recovery key was once enabled and later disabled. The attacker therefore knows all metadataKeys which were created before the recovery key was disabled. He can still use this metadataKeys to write files.
Mitigation: Compute a HMAC over the "files" array of the metadata file using the latest metadataKey.
Replay of old files
An attacker could replay older versions of the files and the corresponding metadata file.
Mitigation: Include a timestamp indicating when the metadata file was last changed or alternatively increment a version number. Add this timestamp to the scope of the HMAC mentioned before. On client-side, store the timestamp and update it whenever the folder is synced.
Summary
To sum up, the integrity of the metadata file should also be protected, especially to prevent an attacker from changing the metadataKeys. Therefore, a signature of the metadataKeys and a HMAC over the "files" array, a timestamp and ideally also the "sharing" array should be added to the metadata file.
While the integrity of single files is protected by storing GCM authentication tags in the metadata file, I couldn't find any measures to protect integrity and authenticity of the metadata file itself in the e2ee whitepaper.
In case of an active attacker (who controls the server and can read and write files including the metadata file), this might have some undesired consequences. Three problems that came to my mind:
Replacement of the metadataKeys
As the metadataKeys aren't authenticated, an active attacker could simply generate some metadataKeys himself, encrypt them with the public keys of the users who have access to the folder, and replace the old metadataKeys with his own ones. If the folder isn't empty, old files can't be decrypted anymore and the attacker should therefore delete them. As he knows the name of the folder, he might place some new unsuspicious files in there to increase the chances of remaining undetected.
Possible scenario: Alice creates a new folder, sets it to encrypted but doesn't immediately upload files. When she uploads files on the next day, the attacker has already replaced the metadataKey by his own key and can now decrypt the uploaded files.
Mitigation: Sign the metadataKeys with Alice's private key.
Reusage of old metadataKeys
An attacker who knows an old metadataKey can write files to the encrypted folder and therefore violate integrity and authenticity of the files.
Possible scenario: The option to use a recovery key was once enabled and later disabled. The attacker therefore knows all metadataKeys which were created before the recovery key was disabled. He can still use this metadataKeys to write files.
Mitigation: Compute a HMAC over the "files" array of the metadata file using the latest metadataKey.
Replay of old files
An attacker could replay older versions of the files and the corresponding metadata file.
Mitigation: Include a timestamp indicating when the metadata file was last changed or alternatively increment a version number. Add this timestamp to the scope of the HMAC mentioned before. On client-side, store the timestamp and update it whenever the folder is synced.
Summary
To sum up, the integrity of the metadata file should also be protected, especially to prevent an attacker from changing the metadataKeys. Therefore, a signature of the metadataKeys and a HMAC over the "files" array, a timestamp and ideally also the "sharing" array should be added to the metadata file.