CMCDragonkai
commented
5 years ago @ll-aashwin-ll We had a discussion about this yesterday. Does that mean this is already done?
Note that I believe this only works at the chunk-level. So a user would be allowed to modify one of the uncorrupted chunks before they meet the wrong chunk. I feel like this could be problematic. Maybe we could instead maintain a total hash calculated over all chunks.
Please see if we can make use of https://en.wikipedia.org/wiki/Merkle_tree to verify a full file without having to hash every chunk up of a large file?
robert-cronin
There is no restriction for only using a single key for encryption with EFS. It is possible with each new instantiation of EFS a different key. It would be beneficial to ensure that when an encrypted file is opened, that the key loaded in the EFS is the same as the key that the file was encrypted with.
This helps preserves the integrity of the file by not performing any operation unless the key is verified to be the same. It can be argued that using AES GCM already provides integrity, but there is a difference albiet subtle.
This key validation measure is designed to prevent the user from destroying the integrity of the file. For example there is nothing stopping the using from writing a block anywhere in an existing file using a separate key than the one it was written with, even when using AES GCM. Key validation on open() can prevent this. The most common use case here would not involve a malicious attacker but rather user error
The integrity provided by GCM is designed to alert the user if data modification can occurred. This would have occurred outside the EFS universe, and generally implies that the file has been maliciously tampered or corrupt, so the data is not be trusted.
One way to perform the key validation is to hash the key, and put it the metadata header of a file when it is open(*, w )'d. On any open(*, !w) of a file, the key the EFS is loaded with will be hashed and compared to the one in the header of the file.