Conversation

Replying to

@DanielMicay

and

Quote Tweet

Replying to @DanielMicay @whitequark and @bmastenbrook

The purpose of systemd-logind (previously consolekit) is largely to deal with tracking remote vs. physical sessions and the active session to grant/revoke these kinds of privileges. And yet... I need to deal with it myself by opening some file as root in vim to use USB in 2020.

Replying to

and

Look at `getfacl /dev/snd/controlC0` and you can see it in action. For that example, uaccess grants users with active physical sessions access (if you switch users, you lose it while in the background) and the audio group means you always have access to it.

Replying to

and

That's generally how this works. The part that really annoys me is that they don't set uaccess on stuff like a serial device, fastboot / adb, hardware wallet, etc. The rules cover common cases but packages have to ship their own rules dealing with every USB device case-by-case.

Replying to

and

There are people involved in this kind of decision making with no actual threat model or rational thinking about security paired with an anti-user attitude. If I can smash the device with a hammer or plug it into something else, just let me use it. It's not just USB either.

Replying to

and

I at least claim to not be afflicted by either. permission dialogs are a barrier for our users! I want our devices to be usable! but I'm concerned about the "how could this possibly go wrong" approach as applied to a class of devices with historically less than zero security...

Replying to

and

... I'm concerned about a kernel side interface that's not been treated with enough care, and I'm concerned that use cases where the physically logged in user does not own the machine are getting lost maybe all of these are worth smashing? if so, let's call that out as a goal

Replying to

and

but the fact that the WebUSB folks immediately yolo'd themselves into breaking the FIDO security model does not speak well of the amount of prior planning that's been put into changing the longstanding assumptions about what can access USB devices ref:

yubico.com

WebUSB in Google Chrome and Responsible Disclosure

In 2018, Yubico worked with Google to help address security vulnerability issues for WebUSB in Google Chrome that affected FIDO U2F authenticators

Replying to

and

It's already broken for a compromised device. When I use FIDO login with my Trezor Model T, it shows me the site identity on the touchscreen and I have to allow it there. The security key design is already broken if it relies on the OS / browser not being compromised.

Replying to

and

historically users are really really bad at comparing things on two different screens IMO the FIDO model is broken in all sorts of ways, so this might just be an artifact of that

Replying to

and

In general, I don't think an HSM without secure input and output can actually provide as much as people expect from them. For example, a hardware wallet for Bitcoin with no display lets an attacker send a million dollars to themselves when you confirm buying a pizza with it.

Replying to

and

So, a proper hardware wallet has a screen and secure input. Ideally, it has a touchscreen or physical keyboard rather than just a few buttons. HSM design in the Bitcoin world is so much more advanced in terms of the workflow and threat model of a traditional HSM. Find it weird.

5:06 AM · Jan 25, 2021Twitter Web App

Replying to

and

Like being able to back up your seed on paper or with something like cryptosteel.com/product/crypto via it being displayed on the screen once when initializing it. If my Trezor Model T dies, I can initialize a new one with the seed and set the counter to UTC time and I can still login.

cryptosteel.com

Cryptosteel Cassette Solo

The classic design of Cryptosteel Cassette established the offline metal backup market with a lightweight and portable solution.

Replying to

and

- we should do BIP39 recovery keys for ArmorLock so people can save them via the Cryptosteel Cassette (see above)

Show replies

Replying to

and

nothing like a concrete financial incentive? there are other aspects of b*tc**n hardware wallets that I find... underdesigned though, e.g. the trezor folks yolo'd their side channel mitigations instead of just using a Montgomery ladder for mysterious reasons

Replying to

and

Trezor doesn't have good physical security in general because they won't sign and NDA and use closed source firmware for a secure element. They're working on their own open source secure element: tropicsquare.com.

Show replies