SignerOS – Minimal Air-Gapped OS for Bitcoin Wallet Creation and Signing

[belenviranli]

Hi everyone,

I've been working on SignerOS, an open-source operating system designed specifically for offline Bitcoin wallet creation and transaction signing.

The idea is simple: turn an ordinary personal computer into a Bitcoin signing device.

You don't need to buy dedicated hardware. You can boot SignerOS from a USB drive and use an existing computer as an air-gapped Bitcoin wallet.

SignerOS is not a general-purpose operating system. It is a small, purpose-built, embedded-like OS that tries to do as little as possible.

Current features:

• Bitcoin-only
• No Wi-Fi or Ethernet drivers
• No network stack
• No hard-disk access
• Stateless
• Minimal Linux kernel
• Buildroot based
• Single Qt application
• Wallet creation
• XPUB generation
• PSBT import, signing and export
• Live USB boot

Why use a PC instead of a hardware wallet?

I don't see SignerOS as a replacement for hardware wallets.

It can also be used together with a hardware wallet as part of a multisig setup.

For example, you could have:

 2-of-3 Multisig

    PC with SignerOS
          +
    PC with TailOS
          +
    Hardware Wallet

This also gives you another independent signing device without requiring another dedicated hardware wallet.

Not every wallet needs to be long-term cold storage. Another use case I'm interested in is short-term wallets.

For example, you may want to create a wallet for:

• giving someone Bitcoin as a gift
• temporarily holding some BTC
• a specific project or event
• a small amount that you don't want to keep in your everyday hot wallet

For these situations, buying a hardware wallet may not make much sense but if you don't want to use a hot wallet, you could boot SignerOS on a computer you already own, create a wallet offline, and use it without ever connecting the machine to the Internet.

The goal is not to claim that this is automatically safer than every hardware wallet. The idea is simply to provide a middle ground between an online hot wallet and a dedicated hardware wallet.

Why not just use a normal Linux distribution?

You certainly can.

But I wanted to try a different approach:

If a computer is only going to sign Bitcoin transactions, why should it have networking support at all?

SignerOS starts from a minimal Linux system and adds only what is needed for its purpose.

The project is still WIP. There is a lot of work remaining around security review, entropy, usability, hardware compatibility and reproducible builds.

I'm publishing it because I'd like to get feedback from people who are interested in Bitcoin security, air-gapped systems and self-custody.

Website:
https://signeros.org

GitHub:
https://github.com/SignerOS

I'd especially appreciate criticism of the security model and ideas about things I may have overlooked.

Thanks!

[Cinexa]

Hello, interesting work.

I did a little bit of research, Secure Boot is an optional feature and hasn't been proven. If you don't have a signed UKI and enrol a key on your computer, Evil Maid has complete control over the stick. So treat unsigned builds as experimental.

Also, for PSBT policy, while it's good that forged change and unknown fees are blocked (that's great), there are still warning messages for things like weird sighashes, high fees, and unverifiable change that users can click past. Make all of these warning messages into hard refusal messages by default.

And finally, for Entropy, do not allow RDRAND to be the only method of unlocking wallet creation until the kernel pool has been seeded; these two sources of randomness are not independent against faulty hardware.

[dkbit98]

I am not a fan of using USB sticks for this purpose, maybe because in past I had several sticks that got corrupted for me.
Than we should also think about firmware used in different USB manufacturers and some have proprietary space.
I also remember malicious USB were circulating, and some even used them to destroy host device. 

[iloveDigit]

This is a similar overall concept to the Nintendo 64 wallet generator I've posted about in this forum, although our Nintendo 64 thing doesn't have signing functionality yet. There's also a Linux version.

https://bitcointalk.org/index.php?topic=5591806.0

If we add keyboard support to the Nintendo 64 version (feasible because the N64 did originally have a keyboard attachment), it could pair with an OS that's just a Nintendo 64 emulator to achieve something similar to your concept

[belenviranli]

Hello, interesting work.

I did a little bit of research, Secure Boot is an optional feature and hasn't been proven. If you don't have a signed UKI and enrol a key on your computer, Evil Maid has complete control over the stick. So treat unsigned builds as experimental.

Also, for PSBT policy, while it's good that forged change and unknown fees are blocked (that's great), there are still warning messages for things like weird sighashes, high fees, and unverifiable change that users can click past. Make all of these warning messages into hard refusal messages by default.

And finally, for Entropy, do not allow RDRAND to be the only method of unlocking wallet creation until the kernel pool has been seeded; these two sources of randomness are not independent against faulty hardware.

Thanks for taking the time to look into it.

The Secure Boot part is definitely something that needs to be improved. For now, I leave this to the user and recommend signing the image with their own key and enrolling that key in the UEFI DB on their own computer.

For the PSBT policy, I will look into the weird sighash cases. Thanks for pointing that out. I'm not sure about making high fees a hard refusal, though. If the fee is clearly shown to the user, I'm not sure blocking the signing completely is the right approach.

Finally, for entropy, RDRAND is currently considered sufficient before the kernel pool is seeded. There is also timing jitter and user interaction, but I agree that these are not very strong sources by themselves. I think it would be better not to rely on RDRAND alone, so I opened a GitHub issue to tighten the entropy requirements.

[Cinexa]

Thanks for taking the time to look into it.

The Secure Boot part is definitely something that needs to be improved. For now, I leave this to the user and recommend signing the image with their own key and enrolling that key in the UEFI DB on their own computer.

For the PSBT policy, I will look into the weird sighash cases. Thanks for pointing that out. I'm not sure about making high fees a hard refusal, though. If the fee is clearly shown to the user, I'm not sure blocking the signing completely is the right approach.

Finally, for entropy, RDRAND is currently considered sufficient before the kernel pool is seeded. There is also timing jitter and user interaction, but I agree that these are not very strong sources by themselves. I think it would be better not to rely on RDRAND alone, so I opened a GitHub issue to tighten the entropy requirements.

Thanks and good that you opened the entropy issue.

Yes, self key signing is the correct model, but again image is not signed and docs tell users to disable it which is where the majority path will be where touching the stick by anyone at that point then allows them to claim ownership of all subsequent seeds.. At least refuse wallet creation unless UKI is demonstrably under SB.

Highlighting the amount paid isn't the same as people noticing.. Just refuse by default is good (above your current threshold); maybe if they want to override it make them type it in sats. Anyone attempting Non-SIGHASH_ALL & unverifiable changes should also be hard refusals; that is not a high fee, that is 'i cannot know what i am signing.'.

RDRAND is not a second random number. It is mixed into the kernel pool and any issue with the generator will impact both pools. Ensure the kernel pool has been seeded before allowing RDRAND alone to access anything on the wallet...