[9fans] Solo factotum (was: Enterable namespaces: /proc/pid/$ns/srv)

[9fans] Solo factotum (was: Enterable namespaces: /proc/pid/$ns/srv)

[David Arroyo]

On Sun, Dec 14, 2025, at 07:43, sirjofri wrote:
> More ideally, but also offtopic, I's like to have a factotum usb drive, 
> where the secrets never leave the usb device. It would talk 9p directly
> over the serial bus.

I think this is a great idea; an HSM-like device with an interface that
doesn't suck. After some discussion about this idea on IRC, I want to
try and implement it.  I purchased the "security" variant of this family
of microcontrollers:

https://tomu.im/

It's an STM32L432KC (Arm v7) in the form factor of a yubikey nano,
so it's nearly flush with a USB Type-A port. It has a capacitive button
which would work nice with the `confirm` attribute of factotum to require
human presence before using a key.

It is still in the mail, so I am exploring the firmware it ships with,
and trying to prove things out with qemu.  If our tc compiler can produce
code for this microcontroller, I will probably replace their firmware,
otherwise I will adapt their firmware to run factotum.  It could be nice
to retain the webauthn abilities of their firmware.

I'm trying to figure out how to serve 9P over USB, which I know very
little about.  My initial plan is to make the device a USB serial
device that expects 9P, then try to mount the /dev/eiaUN device.
However, nusb(4) states that the nusb/serial driver only works for two
chips, so I'd have to add support for this one.  That's not a problem,
but am I going in the right direction?  There are a number of USB
device classes, maybe a different one is more suitable to carrying 9P?
If this works out it would be great if I could also mount it under
Linux, with v9fs or 9pfuse, but that's not a priority.

David

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T969c381dcd9c760d-M076fe1fcc6f57d1f2db9913f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Solo factotum (was: Enterable namespaces: /proc/pid/$ns/srv)

[sirjofri via 9fans]

29.12.2025 14:03:55 David Arroyo <droyo@aqwari.net>:
> On Sun, Dec 14, 2025, at 07:43, sirjofri wrote:
>> More ideally, but also offtopic, I's like to have a factotum usb drive,
>> where the secrets never leave the usb device. It would talk 9p directly
>> over the serial bus.
>
> I think this is a great idea; an HSM-like device with an interface that
> doesn't suck. After some discussion about this idea on IRC, I want to
> try and implement it.

That sounds cool and I can't wait for the results.

> It has a capacitive button
> which would work nice with the `confirm` attribute of factotum to require
> human presence before using a key.

Somehow funny that factotum has this feature that's described in the fido standard years later.

> I'm trying to figure out how to serve 9P over USB, which I know very
> little about.  My initial plan is to make the device a USB serial
> device that expects 9P, then try to mount the /dev/eiaUN device.
> However, nusb(4) states that the nusb/serial driver only works for two
> chips, so I'd have to add support for this one.  That's not a problem,
> but am I going in the right direction?

I don't know much about USB, though maybe the nusb/serial restriction only applies for real rxtx serial converters or something? I mean, USB is serial by its nature so any communication is serial, I guess... But I also don't know. However, being able to mount 9p from a USB serial line would be interesting for many use cases.

For the factotum key, another complex issue could be that factotum needs access to the network interface for auth stuff. I was thinking about this, and plan 9 makes it possible to solve this. One could for example put the /net of the host into a /srv of the factotum key, or something like that. In any case, this is a challenge to find a good and clean solution.

sirjofri.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T969c381dcd9c760d-M0d2ff5a543c1c0839177815f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Solo factotum (was: Enterable namespaces: /proc/pid/$ns/srv)

[David Arroyo]

On Mon, Dec 29, 2025, at 09:40, sirjofri via 9fans wrote:
> I don't know much about USB, though maybe the nusb/serial restriction
> only applies for real rxtx serial converters or something? I mean, USB
> is serial by its nature so any communication is serial, I guess...

My limited understanding is that the device & interface class is a hint
to the host as to how it should be interacted with.

https://www.usb.org/defined-class-codes

On 9front, it tells nusbrc which user-level driver to execute. On Linux,
it would tell the kernel whether to expose the device as a block device,
or a serial device, or a file system, etc. The device class 0x0A,
CDC-Data, seems like the closest thing to a pipe. I could always, of
course, define a new device class if there is a mismatch of expectations.

> However, being able to mount 9p from a USB serial line would be
> interesting for many use cases.

Yes. Imagine a "driverless" USB network adapter, which serves an ether(3)
file system using 9P over USB. Or an audio card, or mouse, or ...

> For the factotum key, another complex issue could be that factotum
> needs access to the network interface for auth stuff. I was thinking
> about this, and plan 9 makes it possible to solve this. One could for
> example put the /net of the host into a /srv of the factotum key,
> or something like that. In any case, this is a challenge to find a
> good and clean solution.

I had not thought about that. I will probably start with the protocols
which can be completed offline, such as ssh. For protocols which need
the auth server to validate the peer's key, I'm not sure. Perhaps the
needkey interface can be used to supply information that could be used
to validate the peer's credentials.

David

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T969c381dcd9c760d-Mf5a07dc97f991a22f2cf9bd0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Solo factotum

[Dworkin Muller]

On Tue, 30 Dec 2025 01:28:51 -0500, "David Arroyo" <david@arroyo.cc> wrote:
david> On Mon, Dec 29, 2025, at 09:40, sirjofri via 9fans wrote:
david> > For the factotum key, another complex issue could be that factotum
david> > needs access to the network interface for auth stuff. I was thinking
david> 
david> I had not thought about that. I will probably start with the protocols
david> which can be completed offline, such as ssh. For protocols which need
david> the auth server to validate the peer's key, I'm not sure. Perhaps the

Alternatively, just set it up as a secret store, like is done with
terminals.  Not quite as elegant/cool, but perhaps more practical.

Dworkin

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Ta60752663ff08448-M37f48b8734998f5a42ba5afc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Solo factotum

[sirjofri via 9fans]

30.12.2025 19:22:13 Dworkin Muller <dworkin@weaselfish.com>:
> Alternatively, just set it up as a secret store, like is done with
> terminals.  Not quite as elegant/cool, but perhaps more practical.

In general, you're right. However the big difference (and why I think there's a solid use case for a factotum key) is that the machine that runs factotum has to be secure. If you have a terminal with its own factotum program, that's fine. The program is on a trusted machine. However, if your terminal boots off a fs, you have to trust the factotum program on that fs to not steal your keys when executed. If you run factotum in a remote session, you have to trust the server. If you have a single enclosed factotum key and no way for the host to download the secrets directly, then you can use it even on an untrusted machine.

Sure, you still need a way to edit the keys. Maybe a specific mount access using an additional secret for editing or something similar could be invented.

In any case, I think for a fully trusted environment you probably don't need a factotum key. I think the whole factotum and secstore stuff is built around this level of trust (you trust the grid). If you consider a public grid with multiple users and people who sign in as guests, I'd prefer to not have my secrets uploaded into the memory of a machine that I can't control myself, if possible. And people do set up grids like that. That's why I welcome experiments into that direction. Not to replace the current status quo, but to extend it in a compatible way for different use cases.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Ta60752663ff08448-Mce4dd48da0c413713a2dbd66
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Solo factotum

[ori]

y'all are reinventing a TPM.

Quoth sirjofri via 9fans <9fans@9fans.net>:
> 30.12.2025 19:22:13 Dworkin Muller <dworkin@weaselfish.com>:
> > Alternatively, just set it up as a secret store, like is done with
> > terminals.  Not quite as elegant/cool, but perhaps more practical.
> 
> In general, you're right. However the big difference (and why I think there's a solid use case for a factotum key) is that the machine that runs factotum has to be secure. If you have a terminal with its own factotum program, that's fine. The program is on a trusted machine. However, if your terminal boots off a fs, you have to trust the factotum program on that fs to not steal your keys when executed. If you run factotum in a remote session, you have to trust the server. If you have a single enclosed factotum key and no way for the host to download the secrets directly, then you can use it even on an untrusted machine.
> 
> Sure, you still need a way to edit the keys. Maybe a specific mount access using an additional secret for editing or something similar could be invented.
> 
> In any case, I think for a fully trusted environment you probably don't need a factotum key. I think the whole factotum and secstore stuff is built around this level of trust (you trust the grid). If you consider a public grid with multiple users and people who sign in as guests, I'd prefer to not have my secrets uploaded into the memory of a machine that I can't control myself, if possible. And people do set up grids like that. That's why I welcome experiments into that direction. Not to replace the current status quo, but to extend it in a compatible way for different use cases.
> 
> sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Ta60752663ff08448-Mfe30e767d437cfac9dbc3483
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Solo factotum

[Steve Simon]

when i used plan9 full time i kept a usb stick containing my encrypted secrets (in factotum format) plugged into my terminal.
i added a clause to my profile to prompt for the password to decrypt it and push the text (via read -m) into /mnt/factotum/ctl.

(all from memory, so it may be inexact)

how would the proposed device improve on this? - honest question.

-Steve

> On 31 Dec 2025, at 1:14 pm, ori@eigenstate.org wrote:
> 
> y'all are reinventing a TPM.
> 
> Quoth sirjofri via 9fans <9fans@9fans.net>:
>> 30.12.2025 19:22:13 Dworkin Muller <dworkin@weaselfish.com>:
>>> Alternatively, just set it up as a secret store, like is done with
>>> terminals.  Not quite as elegant/cool, but perhaps more practical.
>> 
>> In general, you're right. However the big difference (and why I think there's a solid use case for a factotum key) is that the machine that runs factotum has to be secure. If you have a terminal with its own factotum program, that's fine. The program is on a trusted machine. However, if your terminal boots off a fs, you have to trust the factotum program on that fs to not steal your keys when executed. If you run factotum in a remote session, you have to trust the server. If you have a single enclosed factotum key and no way for the host to download the secrets directly, then you can use it even on an untrusted machine.
>> 
>> Sure, you still need a way to edit the keys. Maybe a specific mount access using an additional secret for editing or something similar could be invented.
>> 
>> In any case, I think for a fully trusted environment you probably don't need a factotum key. I think the whole factotum and secstore stuff is built around this level of trust (you trust the grid). If you consider a public grid with multiple users and people who sign in as guests, I'd prefer to not have my secrets uploaded into the memory of a machine that I can't control myself, if possible. And people do set up grids like that. That's why I welcome experiments into that direction. Not to replace the current status quo, but to extend it in a compatible way for different use cases.
>> 
>> sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Ta60752663ff08448-M4c3d06203988eafa4f6a9030
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Solo factotum

[David Arroyo]

On Tue, Dec 30, 2025, at 23:24, Steve Simon wrote:
> when i used plan9 full time i kept a usb stick containing my encrypted 
> secrets (in factotum format) plugged into my terminal.
> i added a clause to my profile to prompt for the password to decrypt it 
> and push the text (via read -m) into /mnt/factotum/ctl.
>
> (all from memory, so it may be inexact)
>
> how would the proposed device improve on this? - honest question.

For protocols like dp9ik or ssh, your secrets would never leave the
device. Even if an attacker gained the ability to dump all the memory
on your system, they wouldn't be able to recover your keys. They would
need physical access to your hardware factotum, and then they would
need to overcome whatever read/write protections the hardware device
allegedly has.

Honestly, my own motivations are not security related. I just think it's
cool. I like the idea of attaching a little computer to my computer to
extend it with almost zero configuration. One could imagine a class of USB
devices that only speak 9P, which operating systems would automatically
mount when they're plugged in. In the same vein, I'm interested in
adding 9p over virtio-vsock support to 9front, as a zero-config way for
a hypervisor to expose a factotum, or a /dev/draw, to a 9front guest.

Factotum is just one of the (famous last words) easier functions to
offload; its API surface is small, its messages are small, and its
performance requirements are modest.

David

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Ta60752663ff08448-M720e7a7a8f75b109572ba59b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Solo factotum

[ori]

Quoth David Arroyo <david@arroyo.cc>:
> 
> Honestly, my own motivations are not security related. I just think it's
> cool. I like the idea of attaching a little computer to my computer to
> extend it with almost zero configuration. One could imagine a class of USB
> devices that only speak 9P, which operating systems would automatically
> mount when they're plugged in. In the same vein, I'm interested in
> adding 9p over virtio-vsock support to 9front, as a zero-config way for
> a hypervisor to expose a factotum, or a /dev/draw, to a 9front guest.

fwiw, I've done this before -- for a startup, I wrote firmware that talked
9p over a bulk usb pipe. It wasn't really worth doing the USB serial bits,
a dumb bulk endpoint was enough.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Ta60752663ff08448-M9f86b044e1a386b9feab58d1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Solo factotum

[Steve Simon]

thanks for all the replies, the bit i missed was running factotum on the key, rather than just storing keys on a dumb thumb drive.

i get it.

-Steve


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Ta60752663ff08448-M36bba9595b5536ca868807ef
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Solo factotum

[sirjofri via 9fans]

31.12.2025 05:31:21 Steve Simon <steve@quintile.net>:
> when i used plan9 full time i kept a usb stick containing my encrypted secrets (in factotum format) plugged into my terminal.
> i added a clause to my profile to prompt for the password to decrypt it and push the text (via read -m) into /mnt/factotum/ctl.
>
> (all from memory, so it may be inexact)
>
> how would the proposed device improve on this? - honest question.

That depends on your terminal and grid. Yes, the factotum process runs on your terminal, so the memory is on your machine. However, if that terminal boots off an untrusted grid and the factotum program is corrupted to send your secrets to some server, or to have debugging enabled by default, that's an attack vector. It's like using ipso in an unprotected ramfs.

If factotum runs standalone on a separate machine like that USB device, the secrets can't leave that device and thus never even reach the terminal.

Again, that attack vector is very unlikely in a standard environment where you control the grid, and most users will run trusted factotums in public grids, too, by using a trusted system to rcpu into that untrusted one. Other than that, security is a very personal thing. Some people can live with higher risks than others.

And yes ori, it's basically reinventing TPM, just Plan 9-flavored.

Have a good new year everyone

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Ta60752663ff08448-Mfe84efc9c20c371ba0d199ab
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Solo factotum

[ori]

Quoth Steve Simon <steve@quintile.net>:
> how would the proposed device improve on this? - honest question.

By design, keys never leave factotum; A kernel exploit could
break that guarantee. Separate hardware means the factotum
wouldn't share a kernel with possibly compromised or hostile
software.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Ta60752663ff08448-M12171259dee7a4cefdaad81f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Solo factotum

[Skip Tavakkolian]

To Ori's point, for such a factotum-on-a-stick to be as secure as
possible (the main point), you would need hardware support like
encrypted storage, trusted execution env, hardware root of trust
attestations all the way to the manufacturer, etc.

This level of security is crucial for trustworthy IoT (e.g. trusting
over-the-air updates), which is why some SoC's like Nordicsemi NRF52,
53, 54 and STMicroelectronics STM32L5, H5 have these capabilities.
Arm's Platform Security Architecture framework is a good resource for
considering all the ways that secrets can be compromised and how the
processor architecture can help mitigate them.

If doing embedded development isn't a showstopper, I think working out
how to embed factotum in a suitable device and figuring out the
mechanics of integrating it into the user environment would be a
useful experiment. There are inexpensive dev kits for NRF and STM soc.

On Tue, Dec 30, 2025 at 4:14 PM <ori@eigenstate.org> wrote:
>
> y'all are reinventing a TPM.
>
> Quoth sirjofri via 9fans <9fans@9fans.net>:
> > 30.12.2025 19:22:13 Dworkin Muller <dworkin@weaselfish.com>:
> > > Alternatively, just set it up as a secret store, like is done with
> > > terminals.  Not quite as elegant/cool, but perhaps more practical.
> >
> > In general, you're right. However the big difference (and why I think there's a solid use case for a factotum key) is that the machine that runs factotum has to be secure. If you have a terminal with its own factotum program, that's fine. The program is on a trusted machine. However, if your terminal boots off a fs, you have to trust the factotum program on that fs to not steal your keys when executed. If you run factotum in a remote session, you have to trust the server. If you have a single enclosed factotum key and no way for the host to download the secrets directly, then you can use it even on an untrusted machine.
> >
> > Sure, you still need a way to edit the keys. Maybe a specific mount access using an additional secret for editing or something similar could be invented.
> >
> > In any case, I think for a fully trusted environment you probably don't need a factotum key. I think the whole factotum and secstore stuff is built around this level of trust (you trust the grid). If you consider a public grid with multiple users and people who sign in as guests, I'd prefer to not have my secrets uploaded into the memory of a machine that I can't control myself, if possible. And people do set up grids like that. That's why I welcome experiments into that direction. Not to replace the current status quo, but to extend it in a compatible way for different use cases.
> >
> > sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Ta60752663ff08448-M49d8a21810679e15bff7ef46
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Solo factotum (was: Enterable namespaces: /proc/pid/$ns/srv)

[Shawn Rutledge]

> On Dec 29, 2025, at 11:57, David Arroyo <droyo@aqwari.net> wrote:
> 
> On Sun, Dec 14, 2025, at 07:43, sirjofri wrote:
>> More ideally, but also offtopic, I's like to have a factotum usb drive, 
>> where the secrets never leave the usb device. It would talk 9p directly
>> over the serial bus.
> 
> I think this is a great idea; an HSM-like device with an interface that
> doesn't suck. After some discussion about this idea on IRC, I want to
> try and implement it.  I purchased the "security" variant of this family
> of microcontrollers:

This sounds like a great idea.  But personally I would like to have a portable solution: something that works on all OSes.  I currently use a yubikey to store an ED25519 private key that I can use for ssh (thus also git) and gpg (thus also “pass”, which uses gpg to store passwords) on every OS except 9.  And it does the FIDO stuff too.  So I wish yubikeys could be supported with factotum somehow too.  I’m not quite sure what that would entail in practice; but it is a device that stores secrets that they promise can't be extracted from it.

Bitcoin wallet devices can be used this way too, but they tend to be bulkier and less robust.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T969c381dcd9c760d-Mc83861eb161a4e98c3fbb515
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription