European Union And OS level Backdoors

marmarek · October 12, 2020, 1:31pm

I don’t think it is technically possible to force a backdoor on Qubes OS users. At the very least, it is an open source project, that anyone can download sources, apply modifications and build themselves.
Anyway, we’ll fight back any request to backdoor Qubes with any means available to us. In case of all the options exhausted, we’d rather stop maintaining the project, than to ship backdoored product.

qufo · October 12, 2020, 2:38pm

johny:

I think what he/she wanted to know (I do at leat) is if you would
implement the backdoor at all or if you would refuse and perhaps
relocate somewhere outside the EU.

I don’t think it is technically possible to force a backdoor on Qubes
OS users. At the very least, it is an open source project, that
anyone can download sources, apply modifications and build
themselves.
Anyway, we’ll fight back any request to backdoor Qubes with any means
available to us. In case of all the options exhausted, we’d rather
stop maintaining the project, than to ship backdoored product.

That’s the spirit…

qufo · October 12, 2020, 2:40pm

no one said it is a conspiracy theory. i just wondered why there
should be a backdoor in the device itself its simpler to have a
(law
forced) backdoor in programs.

anyway thanks for the information and as fsflover said, Amd,
Intel,Arm all of them have backdoors.

So to my knowledge only Intel’s ME has a remote management feature.
AMD’s PSP can be manipulated and exploited through arbitrary code,
but
not remotely; only if the attacker got you to load malicious code or
has physical access to your laptop/computer. If you have other
information please share it.

36C3 - Uncover, Understand, Own - Regaining Control Over Your AMD
CPU:
https://www.youtube.com/watch?v=bKH5nGLgi08

CCC’s collection of AMD processor analyses presentations:
https://www.youtube.com/c/mediacccde/search?query=AMD

So, yes I feal a better while using AMD processors.

I forgot the links to the code for those who want to check for
themselves:

unman · October 12, 2020, 2:45pm

I don’t want to worry you but since AMD provides DASH tools which are
“for secure out-of-band and remote management”, and which operate
“independent of the power state of the machine or the state of the OS”,
I’m not sure you should feel any better.

There’s a huge amount of nonsense talked about these features, and what
the motivation for them is. The primary market for processors/machines
remains business, and a huge push in IT management in business is for
remote out-of-band control. That’s it.
Not to say that i want those features on my machines, but there’s no
need to look for conspiracy when hard cash provides an answer.

qufo · October 12, 2020, 3:05pm

I don’t want to worry you but since AMD provides DASH tools which are
“for secure out-of-band and remote management”, and which operate
“independent of the power state of the machine or the state of the
OS”,
I’m not sure you should feel any better.

I heart about DASH, but to my knowledge there has to be client software
installed on the target machine. But I’m not so familiar with DASH, do
you have more info about it?

There’s a huge amount of nonsense talked about these features, and
what
the motivation for them is. The primary market for
processors/machines
remains business, and a huge push in IT management in business is for
remote out-of-band control. That’s it.

True enough, yes I know.

Not to say that i want those features on my machines, but there’s
no
need to look for conspiracy when hard cash provides an answer.

I know but that’s usually what one gets told when pointing such things
out…

dispuser5132 · October 12, 2020, 3:15pm

Thank you

dispuser5132 · October 12, 2020, 3:17pm

Yes but chances to meet people that think hardware backdoors are conspiracy in a Qubes OS forum is very rare. i guess

dispuser5132 · October 12, 2020, 3:18pm

Thank you and the Qubes OS Team for the hard work

adw · October 13, 2020, 3:13am

Thanks for replying here, Marek! I’m with you 100%.

Scumbag · October 17, 2020, 6:55am

Maybe the shared Qubes master key idea should be implemented:

It may not help against a judicially forced backdoor but it can help at other attempts to undermine Qubes OS.

fsflover · October 22, 2020, 12:40pm

Yes but chances to meet people that think hardware backdoors are conspiracy in a Qubes OS forum is very rare. i guess

whoami · October 22, 2020, 3:55pm

Would it help to set the development team to a charity to get a better law protection. Needless to say, that charity regulations and laws are country dependent?

I don’t know how centric the actual team is but decreasing the risk by distributing the dev. team around the globe and verify new lines of code only with consensus before release it?

adw · October 24, 2020, 11:18am

I think that’s part of the idea behind the proposed new multisig scheme:

github.com/QubesOS/qubes-issues

Consider generating new shared Qubes Master Signing Key

opened 01:12PM - 19 May 17 UTC

rootkovska

T: enhancement C: other P: major cryptography security project management

I think it's a nobrainer to state that it would be beneficial for everybody, i.e…. the project, its users, and even myself, if we could get a new Qubes Master Signing Key (QMSK), such that could be **shared** between N parties, of which M would be required to meet in order to use the key to sign other keys (i.e. the specific Release Signing Keys). For this effort to make sense, there are a few additional requirements though: 1. There should be just one key, usable the same way as standard GPG keys are used to sign/verify software. The solution that N people have just N keys and all of them sign the other keys, is simply not acceptable from the user point of view. 2. None of the N holders should be able to walk away with the full QMSK after any of the signing ceremony. 3. The owner of the laptop on which the creation and/or any of the further ceremonies take place, should also not be able to steal the QMSK. The recent discussion on qubes-devel [1] has encouraged me to think again about this problem and I've come up with the following idea which I'd like that we further discuss: 1. Assuming we have a laptop that _approximates_ the idea of a stateless laptop [2] reasonably well (of course, I'm realistic enough to know we won't have any True Stateless Laptop anytime soon). Let's call this laptop: **Laptop**. Also, we shall defer the discussion about how well should this approximation be, until some later time. Meanwhile I'm more interested in discussing other aspects of this proposal. 2. The Laptop runs **Tails** and uses encrypted persistent partition (likely LUKS-based, like the standard Persistence mode in Tails does), which is called **Persistent Partition**. The Persistent Partition is unlockable with a keyfile, which we shall call: the **Keyfile**. 3. During the **Initial Ceremony**, we generate: 1) the new QMSK, and 2) the Keyfile which will be used for the Persistent Partition encryption. The Keyfile is then used to mount the Persistent Partition and the new QMSK is moved onto this partition. 4. Still at the Initial Ceremony, the keyfile is split among N parties, creating N **Shared Keys**. This likely could be achieved using the `ssss` program (don't remember if it's part of the standard Tails distro, if not, we should use something that is, or convince Tails people to include it :) 5. The original Keyfile is then destroyed (here's where one of the benefits of using Tails for this exercise become clear, another benefit: we can use nearly arbitrary old machine as the Laptop) 6. Subsequently, whenever there is a need to use the QMSK, e.g. to sign the new Qubes Release Key, at least M out of N parties needs to meet, boot the Laptop using Tails, plug at least M USB sticks, combine the M Shared Keys, recreate the Keyfile, then mount the Persistent Partition. 7. Once the Persistent Partition gets mounted, we can create new keys (e.g. Release Signing Key), and sign them with the Master Key. Also, in case we needed to sign some other keys (e.g. other people's key), we the the trick suggested by @petertodd might be used: a one-time-use Binding Keys could be created, and signed by the QMSK. Note: I'm not really convinced about the idea of bi-directional signing (i.e. to have the binding key also sign the QMSK) -- this seems like some superficial trick, not really needed by us. 8. Once the keys are ready for export, we can copy them to some ephemeral fs, unmount the Persistent Partition (plus some make sure the memory with secrets also got wiped...), and subsequently export the keys, even using something like a USB stick... Open issues: 1. What's the best way to import the Shared Keys? Plugging USB sticks obviously endangers the laptop to some attacks... Using HSMs does not change much hear, as these are... also USB devices. One option is to keep them on some read-only mediums (DVD), of course encrypted with some user-only-known passphrase. 2. It seems to me that the Persistent Partition could be also burnt to such a DVD, for even if we are going to be generating new keys there, these would be exported and no problem if we discard them from the Persistent Partition. 3. The choice of M and N. Right now I'm thinking M = 2, N = 3 (me, Marek, plus somebody only we know who). Other options might be possible though. 4. Will we ever have a need to sign any keys non-generated on the Laptop? Likely not: only Release Keys, and these should then sign individual developer's keys. Does this make most of the discussion in [1] futile, or am I missing something? /cc @marmarek @andrewdavidwong @woju @petertodd [1] https://groups.google.com/d/msg/qubes-devel/XreFo6RM47Q/U_jmqK5SBgAJ [2] https://blog.invisiblethings.org/papers/2015/state_harmful.pdf

Narvey · October 15, 2021, 12:17am

@adw Where did any of this go? Specifically:

Were the proposed E.U. regs scrapped?
Has Qubes given up (or delayed) the multisig idea?

adw · October 15, 2021, 5:52am

Nowhere yet, AFAIK.

Sorry, I have no idea.

Not any moreso than before. Our to-do list is years and years long. We’re understaffed, and urgent stuff often cuts in line, bumping less urgent stuff down. It’s not unusual for something like this to sit as a to-do item for a very long time. That doesn’t necessarily mean we have or haven’t decided to do it, delay it, or abandon it.