I have completed my audit of GrapheneOS.

Verdict:

Two leaks in the VPN implementation was found. One DNS leak, and one MDNS/multicast leak. I reported these issues to GrapheneOS developers about one and a half month ago. GrapheneOS developers have confirmed both issues, and attempted to fix the first one, but had to revert the fix because it interfered with some VPN apps. A new fix will be developed. No work has been started yet at fixing the MDNS/multicast leak, but the issue is confirmed.

https://github.com/GrapheneOS/os-issue-tracker/issues/3442
https://github.com/GrapheneOS/os-issue-tracker/issues/3443

I have looked for information leaks over both Wifi and 4G while using various apps. Only expected data traffic was observed, no leaks. Revoking Network permission works as expected, it blocks the app from sending or receiving network traffic.

I have analyzed what files are stored in what storage classes. I was unable to confirm things are actually encrypted, but I think the Cellebrite leak recently kind of proved that it is, so I didn't bother to dig deeper. Storage classes and what data is stored how is given below. I have already pointed out that some sensitive data is stored in a way not requiring your credentials to read. The developers are already very aware of this limitation, and have been clear it is too low priority to fix for now, and that Device Encryption still provides some protection. So this is for your information only. But, one issue I uncovered seem far more serious. Log files with very precise information about what you do on your device, including the exact files you open with full unencrypted file names, and timestamps, and what user profile did it, is stored as Device Encrypted, ie without being protected with your login credentials such as PIN or password at all. This defeats the purpose of file name encryption, and may also leak other sensitive user specific app data. I reported this issue today.

https://github.com/GrapheneOS/os-issue-tracker/issues/3583

I also by chance discovered a flaw in the app permission UI, where not all file based permissions show up, possibly misleading the user to believe an app do not have access to files and media at all, when it fact it has full read/write access to the whole file system. I reported this issue today too.

https://github.com/GrapheneOS/os-issue-tracker/issues/3584

That is it! I promised to post this once I completed the audit, and now I have!

Device Encrypted:

Things stored in this storage class are protected and encrypted by the Secure Element hardware, bootloader firmware and GrapheneOS firmware. An attacker needs to find an exploit against any of them to read out this data, but will not need your PIN code, password or any other user credential.

List of installed app is Device Encrypted, including the APKs themselves. List of user profiles and their profile pictures are Device Encrypted. Various non-sensitive system information and non-sensitive system related cache files are Device Encrypted. Device uptime and usage statistics is Device Encrypted. Log files are Device Encrypted. Per user app permissions are Device Encrypted. Bluetooth and cell tower configuration seem to be Device Encrypted, presumably including associated Bluetooth devices. File sizes or number of files for each user is Device Encrypted, even when the filenames and file data themselves are Credential Encrypted. Log files is from all user profiles, and may leak information about what files exists in the user profile, and what actions the user has done with exact timestamps. File sizes and file counts alone can also reveal what files it is, if they have been downloaded from the web, or uploaded to the web. I found nothing else that is Device Encrypted.

Credential Encrypted:

Things stored in this storage class is protected and encrypted by the Secure Element hardware, bootloader firmware, GrapheneOS firmware and your PIN code or password. An attacker does not only need to break the Device Encrypted storage class, but then also need to break your PIN code or password using brute-force after that. A 6 digit PIN code would be trivial to break once Device Encrypted storage class is broken, but a long password of 7 or more diceware words should protect your files and data that is Credential Encrypted for many years, even if the hardware and software is completely broken by an attacker.

All app cache and user data are Credential Encrypted per user. All files visible in Files app are Credential Encrypted per user, including all thumbnails. File names of all app cache, user data and all files are Credential Encrypted per user. When you log out a user, the files for that user becomes unavailable again, as before the user was logged in. You cannot log out the Owner user, so don't store sensitive files there, unless you want to turn of your phone completely. I am uncertain, but stored Wifi networks and their passwords are possibly also Credential Encrypted, but I didn't confirm this with certainty because usually that information is not sensitive anyway.

Per Boot Encrypted:

I would guess this is encrypted with a key that is regenerated at every boot. Only swap storage seem to be of this storage class, nothing else. This would be as expected, and secure, assuming key is wiped at poweroff or reboot.

Unencrypted:

GrapheneOS itself is unencrypted. Data related to the SIM card is unencrypted, including the name of your carrier. Modem related user data is unencrypted. This information is available to any attacker who disassembles your phone, that is all they need to do, but none of this information seem sensitive, so that is likely no issue.