Hypothetically: Identification attack surface in Qubes OS (any version)

[schnurentwickler]

Remember: This is a hypothetic thought

Depending on the Qubes Security Bulletin #37 (https://www.qubes-os.org/news/2018/01/11/qsb-37/) it should be theoretically possible to get information about the system and in long term also about the user behind qubes. Because as described in QSB #37 at '## All attacks are read-only', '## Only running VMs are vulnerable', '## Only running VMs are vulnerable' and especially (!) '## Disk encryption and screenlocker passwords are at risk', it is possible to identify someone using any OS (not only linux or a qubes distribution).

It is also reboot resistent.

Each qubes user (not only) does have an individual storage encrytion password.
This individual password alone helps to remember an attacker, if this user is known and the password already stolen. Even the same screenlocker password on dom0 can identify an user, if the password is known or probably what language the user is using, if the password is fetched in cleartext.

The statement in QSB, that to make use of a stolen secret, the attacker would have to conduct physical attack on the user's computer is true but not closed.
Profiles can be set up to remember users with their not changing passwords and collect usage and connection statistics. Even whonix should be affected, if the attacker gets spectre bugs to work on the target machine.

All it needs to get this attack working, seems to depend on the surface (the template VM, used programs and the user behavior) and known bugs/exploits to get in touch with the Spectre Bug on Intel processors.

It is possible inside an AppVM do scramble information?
Like only get around (randomly choosen) 92 to 98 percent of cpu power to noise tiny cpu speed differences.
Change/Fake processor information given to any VM.
Add randomly choosen amount of datastorage not writeable. In example constantly giving 17 GB of private storage should be changed upwards (to i.e. 24GB, 19GB, 54GB) each VM start, but it is not writeable to prevent data loss.
The last point is probably not necessary because all qubes users would have the same amount of space in their disposal VM if storage settings are untouched.

About passwords:
Use/create a program which adds a salt created each reboot and is added silently to the screen password, to change memory/cpu processed passwords in their checksum or encrypted form.
It is possible to exchange a currently used decryption password (bypass?) by the running system to something randomly created?
So each Qubes OS after successful bootup would add a good password to the luks-keychain and change in realtime to this key.

These are my ideas so far.

Gedanken experiment completed.

Discussion in qubes-users, workarounds and program progress in github-issues?
Discussion link: https://groups.google.com/forum/#!topic/qubes-users/s_gYqKAz86c

[andrewdavidwong]

Discussion in qubes-users, workarounds and program progress in github-issues?

It would be better to discuss this in qubes-users before opening any issues. If there are specific, actionable issues as a result of the discussion, then feel free to open a separate issue for each one. (This includes things like documenting workarounds.)

[andrewdavidwong]

Discussion in qubes-users, workarounds and program progress in github-issues?

It would be better to discuss this in qubes-users before opening any issues. If there are specific, actionable issues as a result of the discussion, then feel free to open a separate issue for each one. (This includes things like documenting workarounds.)