Building a safer FIDO2 key with privilege separation and WebAssembly | Hacker News Reader

Building a safer FIDO2 key with privilege separation and WebAssembly

benkettle.xyz

94 pointsbkettle16 comments

Interesting approach! The writeup is really detailed, and I think it is a very solid concept. The only downside is the slowdown due to the entire c->wasm->c translation and the need to essentially virtualize every single memory access. And it doesn't really protect against bugs in the translation layer, of course.

I noticed that the reference manual[0] of the MCU used also mentions a "firewall", which can be used to essentially create a "user mode" and "kernel mode" separation in both code and memory, with a well-defined "syscall" entry point. It would be neat to compare the impact of software vs hardware privilege separation.

[0]: https://www.st.com/resource/en/reference_manual/rm0394-stm32...

Agreed. One benefit of the SFI-based approach over typical approaches that leverage hardware like MPUs or this firewall is that we can have arbitrarily many privilege domains. For the security key we only have three (Trusted, USB, and FIDO2 lib) but there is nothing stopping us from adding more to get finer-grained privilege separation with each module having a smaller set of permissions. It’s possible to build multiple domains on top of these hardware mechanisms, but adds reconfiguration complexity at every context switch that we are able to avoid (at the cost of general runtime overhead). It would definitely be interesting to compare the two approaches.

Another approach adds hardware specifically for this kind of sandboxing: a paper from earlier this year [1] implements an extension to x86 that adds hardware support for Wasm-style SFI. It could be interesting to see how this can apply to the embedded context where resources are more limited.

One nice thing about embedded stuff like this, though, is that we are dealing with human time scales and fairly simple operations—-there was a lot of room for slowdown without becoming unreasonable.

1: https://dl.acm.org/doi/pdf/10.1145/3582016.3582023

Hi all,

I recently finished up my Master’s thesis and thought the topic might be of interest to some HN readers. Happy to answer any questions!

Was this specifically around privilege separation, or was there also effort into preventing side-channel attacks via things like timing and power draw measurements?

Did you put thought into e.g. firmware updates of these, or even the ability to put additional sandboxed applications on a key with isolated views of state/storage?

This was specifically focusing on privilege separation---we don't provide any protection against timing or other side channels, though this work could be combined with existing work around constant-time crypto, etc to get some assurance about side channels.

No specific thought about firmware updates. In the brainstorming phase we were thinking about a multi-application model indeed---something like the Ledger Nano but using Wasm for isolation between applications instead of their OS. For this project we decided to try out the privilege separation angle, but I think the multi-application idea would be interesting to explore too.

The USB driver itself can not access arbitrary memory. But it may be able to program the DMA controller of the USB peripheral to access arbitrary memory. So the WebAssembly sandboxing of a driver alone is not enough. You still need some hardware mechanism like an SMMU. Or a trusted module that abstracts the DMA controller.

Indeed we thought this would be a challenge and I didn’t explain this aspect in the blog post. But on this chip, DMA is its own peripheral and the DMA peripheral is not used by the USB driver. Instead, the USB peripheral and the main CPU share a small memory region. The USB peripheral is then programmed in terms of offsets into this shared memory region, rather than physical memory addresses—-the USB peripheral does not have access to all of physical memory. This is discussed at the bottom of page 48 of the thesis itself [1].

This saved a lot of trouble, but in intro work on this I was using another chip (nRF52840) that worked the way you describe. To safely handle DMA in that case, without an IOMMU, we had to add somewhat complex reasoning that looked at each memory read and write to see if it was modifying a DMA control register and reject the write if it could lead to unsafe behavior. More info is on pages 52-55 of the thesis PDF.

This was pretty messy, so it was fortunate that the chip we used had a different plan. Let me know if I’m misunderstanding you!

[1]: https://pdos.csail.mit.edu/papers/bkettle-meng.pdf#page48

Are there NX pages/flags?

NX bit: https://en.wikipedia.org/wiki/NX_bit

Tagged architecture / Memory tagging: https://en.wikipedia.org/wiki/Tagged_architecture & type unions

Harvard architecture > memory details > Contrast with modified Harvard architecture: https://en.wikipedia.org/wiki/Harvard_architecture#Contrast_...

IIUC Ideally there should be an NX bit on pages, registers, names, and/or variables; and the programming language supports it.

(IIRC, with CPython the NX bit doesn't work when any imported C extension has nested functions / trampolines?)

What's the real threat model here?

> But an attacker who compromises a host PC still gets significant power to interact with a connected authenticator by sending arbitrary messages over USB

The attacker can already extract all sensitive user data from the browser and even run a keylogger and take screenshots. The attacker can wait until the user logs into the desire website or service.

At this point everything of value is lost.

> At this point everything of value is lost.

With FIDO2 this is not the case—since FIDO2 uses public key signatures with a secret key stored on the authenticator, a keylogger would not lead to the long-term account compromise that it would with just password-based authentication. An attacker with control of a user’s PC may be able to learn a session cookie, but once that cookie expires the attacker will no longer be able to log in.

In many cases, a typical cookie / session expiration time is enough time to heavily compromise an account / product / org.

Maybe once we replace passwords with FIDO2 more widely and people no longer have to remember and enter their password every time they manually authenticate, we can shorten up session timeouts. Or, as GitHub does, we can require explicit authentication for sensitive actions. But yes, agreed—there’s not much FIDO2 can do to help when authentication isn’t required.

Agreed. </3 passwords.

Excellent work by the way. This stuff is super intriguing.

I wonder what account recovery is going to look like with FIDO2. "I lost my hardware passkey" buttons that email/text a magic link to enroll a new device? How many sites will allow adding a second device? How many will allow adding a second device without validating control of the original one?

Usually you have to upgrade all the links in the chain to get noticeably stronger security.

Authentication by secure hardware-backed cryptography is great, but you need to make sure the user agent and execution environment don't allow for exfiltration of sessions. You might want to use time-of-flight calculations on geopositioned IP address information to make sure they aren't exfiltrated as well, but...

You have to make sure you don't focus on exfiltration too much, since the attacker could use code injection to misuse resources local to the user. That will obviously break a lot of your anomaly detection.

So you probably want to work on securing the user agent to prevent code injection, such as requiring a particular browser and configuring it to only allow a list of vetted web extensions, using CSP and sub resource integrity for web pages, having a policy of installing OS and browser updates nearly immediately, and so on.

...but again, you probably don't want to spend that much time strengthening all the walls without planning what to do when attackers manage to figure out a way in, such as using an unknown zero-day. Reducing the damage an attacker can do is possibly a better investment, but that touches on the entire business process.

To your question, requiring the highest levels of strong authentication is an inefficient focus if the recovery process is an email into a third-party system. You can register multiple authenticators to reduce the need to go through recovery, (but then you have to worry about attackers registering new ones during a compromise, or the end-user having processes to keep them all safe). For recovery, you may use an equivalently strong mechanism like strong in-person identity verification (e.g. you have to walk to the IT desk and prove who you are to register a new security key fob onto your account).

Reply on news.ycombinator.com