[cyberax]

This is for the _ActiveDirectory_. If your machine is joined into a domain, the keys will be stored in the AD.

This does not apply to standalone devices. MS doesn't have a magic way to reach into your laptop and pluck the keys.

[riskable]

> MS doesn't have a magic way to reach into your laptop and pluck the keys.

Of course they do! They can just create a Windows Update that does it. They have full administrative access to every single PC running Windows in this way.

[g-b-r]

People really pay too little attention to this attack avenue.

It's both extremely convenient and very unlikely to be detected; especially given that most current systems are associated to an account.

I'd be surprised if it's not widely used by law enforcement, when it's not possible to hack a device in more obvious ways.

Please check theupdateframework.io if you have a say in an update system.

[g-b-r]

I actually misremembered what theupdateframework.io is, I thought it provided more protections...

[theragra]

Isn't it the same with many Linux distros?

Updates are using root to run?

[g-b-r]

It's largely the same for all automatic updating systems that don't protect against personalized updates.

I don't know the status of the updating systems of the various distributions; if some use server-delivered scripts run as root, that's potentially a further powerful attack avenue.

But I was assuming that the update process itself is safe; the problem is that you usually don't have guarantees that the updates you get are genuine.

So if you update a component run as root, yes, the update could include malicious code that can do anything.

But even an update to a very constrained application could be very damaging: for example, if it is for a E2EE messaging application, it could modify it to have it send each encryption key to a law enforcement agency.

[rstuart4133]

> the problem is that you usually don't have guarantees that the updates you get are genuine

A point of order: you do have that guarantee for most Linux distro packages. All 70,000 of them in Debian's case. And all Linux distro distribute their packages anonymously, so they can never target just one individual.

That's primarily because they aren't trying to make money out of you. Making money requires a billing relationship, and tracking which of your customers own what. Off the back of that governments can demand particular users are targeted with "special" updates. Australia in particular demands commercial providers do that with its "Assistance and Access Bill (2018)" and I'm sure most governments in the OECD have equivalents.

[smileybarry]

> so they can never target just one individual

You assume the binary can't just have a machine check in itself that activates only on the target's computer.

[dhx]

Not really, but it's quite complex for Linux because there are so many ways one can manage the configuration of a Linux environment. For something high security, I'd recommend something like Gentoo or NixOS because they have several huge advantages:

- They're easy to setup and maintain immutable and reproducible builds.

- You only install the software you need, and even within each software item, you only build/install the specific features you need. For example, if you are building a server that will sit in a datacentre, you don't need to build software with Bluetooth support, and by extension, you won't need to install Bluetooth utilities and libraries.

- Both have a monolithic Git repository for packages, which is advantageous because you gain the benefit of a giant distributed Merkle tree for verifying you have the same packages everyone else has. As observed with xz-utils, you want a supply chain attacker to be forced to infect as many people as possible so more people are likely to detect it.

- Sandboxing is used to minimise the lines of code during build/install which need to have any sort of privileges. Most packages are built and configured as "nobody" in an isolated sandbox, then a privileged process outside of the sandbox peeks inside to copy out whatever the package ended up installing. Obviously the outside process also performs checks such as preventing cool-new-free-game from overwriting /usr/bin/sudo.

- The time between a patch hitting an upstream repository and that patch being part of a package installed in these distributions is fast. This is important at the moment because there are many efforts underway to replace and rewrite old insecure software with modern secure equivalents, so you want to be using software with a modern design, not just 5 year old long-term-support software. E.g. glycin is a relatively new library used by GNOME applications for loading of untrusted images. You don't want to be waiting 3 years for a new long-support-support release of your distribution for this software.

No matter which distribution you use, you'll get some common benefits such as:

- Ability to deploy user applications using something like Flatpak which ensures they are used within a sandbox.

- Ability to deploy system applications using something like systemd which ensures they are used within a sandbox.

Microsoft have long underinvested in Windows (particularly the kernel), and have made numerous poor and failed attempts to introduce secure application packaging/sandboxing over the years. Windows is now akin to the horse and buggy when compared to the flying cars of open source Linux, iOS, Android and HarmonyOS (v5+ in particular which uses the HongMeng kernel that is even EAL6+, ASIL D and SIL 3 rated).

[theragra]

Sadly, Linux still has many small issues for desktop day-to-day usage. I encounter different small bugs almost each day, something I don't see on Windows that often. These bugs or inconvenient UI are tolerable for me, but not for everybody. Today the bug was Firefox not starting with first click on the shortcut, and mysterious case where keyboard clicks are not registering in the Firefox omnibar until Firefox restart.

[shawnz]

Furthermore it seems like it's specific to Azure AD, and I'm guessing it probably only has effect if you enable to option to back up the keys to AD in the first place, which is not mandatory

I'd be curious to see a conclusive piece of documentation about this, though

[cyberax]

Regular AD also has this feature, you can store the encryption keys in the domain controller. I don't think it's turned on by default, but you can do that with a group policy update.