[HN Gopher] Building a safer FIDO2 key with privilege separation...
___________________________________________________________________
Building a safer FIDO2 key with privilege separation and
WebAssembly
Author : bkettle
Score : 70 points
Date : 2023-07-14 16:18 UTC (6 hours ago)
(HTM) web link (benkettle.xyz)
(TXT) w3m dump (benkettle.xyz)
| sse wrote:
| 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.
| bkettle wrote:
| 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
| JuneRaffaele wrote:
| [dead]
| bkettle wrote:
| 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!
| [deleted]
| goodpoint wrote:
| 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.
| bkettle wrote:
| > 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.
| leetbulb wrote:
| In many cases, a typical cookie / session expiration time is
| enough time to heavily compromise an account / product / org.
| bkettle wrote:
| 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.
| leetbulb wrote:
| Agreed. </3 passwords.
|
| Excellent work by the way. This stuff is super
| intriguing.
| [deleted]
| crote wrote:
| 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...
| bkettle wrote:
| 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
___________________________________________________________________
(page generated 2023-07-14 23:01 UTC)