102 lines
5.6 KiB
Markdown
102 lines
5.6 KiB
Markdown
|
# stack zero
|
||
|
|
||
|
i will share first the components of my stack and what each is for, and then
|
||
|
some things i would like to improve in the not-so-distant future. this is a
|
||
|
bootstrapping stack; it is not perfect, but it does seem to be more supportive
|
||
|
of end user control and security than most technology stacks.
|
||
|
|
||
|
## components and rationales
|
||
|
|
||
|
1) a "hardware random number generator" (hrng). optional. i just happened to
|
||
|
have one lying around, so i decided to use it. good for generating a lot of
|
||
|
high-quality entropy very quickly. makes creating new keys much faster.
|
||
|
|
||
|
2) a ledger hardware wallet. this cryptocurrency wallet plays the role of a pgp
|
||
|
smartcard, allowing me to sign things without revealing my private keys to my
|
||
|
online computer. i like that this is a self-contained device with a screen, and
|
||
|
that it has a "plausible deniability" function. it seems to strike a good
|
||
|
balance between security and convenience.
|
||
|
|
||
|
3) a safe means of transferring data to and from an airgapped computer, such as
|
||
|
a good usb stick. if one uses a usb stick, one should be careful to choose one
|
||
|
with signed or locked firmware, to protect against unknowingly ferrying an
|
||
|
attacker's code between one's "online" computer and one's airgapped computer.
|
||
|
one might also consider turning off hotplugging, to keep the device from
|
||
|
emulating other devices in the event it _does_ harbor malicious code in its
|
||
|
firmware.
|
||
|
|
||
|
if no such stick can be obtained one might use a
|
||
|
[tinfoil chat](http://git.fuwafuwaqtlkkxwc.onion/yafox/tfc-mirror)-like data
|
||
|
diode system instead.
|
||
|
(original clearnet repository: https://github.com/maqp/tfc )
|
||
|
|
||
|
in a pinch, if one's online and airgapped computers have headphone and
|
||
|
microphone jacks, one could also just use an audio cable and
|
||
|
[minimodem](http://git.fuwafuwaqtlkkxwc.onion/yafox/minimodem-mirror).
|
||
|
(original clearnet repository: https://github.com/kamalmostafa/minimodem )
|
||
|
|
||
|
4) an old luks-encrypted thinkpad with libreboot, to be kept airgapped after the
|
||
|
initial setup. used for provisioning everything and for interacting with
|
||
|
sensitive material (such as encrypted backups of private keys). libreboot might
|
||
|
have been unnecessary, but as this is the most foundational element in the
|
||
|
stack, i thought it would be better to be safe. for extra security, i set up
|
||
|
libreboot so that it only boots kernels signed with my pgp private key.
|
||
|
|
||
|
this laptop should at least be loaded with gpg, pcscd, and the tools necessary
|
||
|
to flash the firmware on one's "online" computer. it should also have whatever
|
||
|
software one needs to use one's hrng, if applicable.
|
||
|
|
||
|
5) an openpower pc from raptor computing systems. this serves as an "online"
|
||
|
computer. all its firmware (except the onboard broadcom nic; there is a
|
||
|
whiteroom re-implementation effort on for that) is open source, so every chip
|
||
|
requiring firmware can be flashed with custom firmware. the system can also
|
||
|
require that all firmware be signed by one's own private keys, and the firmware
|
||
|
can in turn require a signed kernel and initramfs to boot, and the kernel can
|
||
|
_then_, in theory, require that all executable binaries be signed as well.
|
||
|
|
||
|
so it is possible to lock down this hardware with one's own keys such that
|
||
|
_nothing_ which is not explicitly signed off on by oneself can run on it.
|
||
|
|
||
|
of course, since this only applies to binaries, any script at all can be run
|
||
|
without having been signed first. there is always a way around whatever
|
||
|
security measures one puts in place. the goal is simply to make it difficult
|
||
|
enough to get around one's defenses that the attacker moves on to another
|
||
|
target, and to escape (as much as possible) mass surveillance.
|
||
|
|
||
|
regardless, assuming there are no fatal bugs in the implementation, an attacker
|
||
|
would have to gain physical access to one's computer to load their own firmware.
|
||
|
being able to reasonably trust one's own hardware is invaluable.
|
||
|
|
||
|
6) a simple linux distribution. whatever one understands intimately is fine.
|
||
|
i am building my own and have finally got it to the point where it's not too
|
||
|
embarassing to share. the goal is simply to have a system on which there is
|
||
|
nothing running or installed which one has not consciously chosen, and which can
|
||
|
readily support things like experimenting with different kernel configurations.
|
||
|
|
||
|
## caveats
|
||
|
|
||
|
the first caveat here: i am trusting IBM to be truthful about the properties of
|
||
|
their openpower chips, and i am trusting raptor computing systems to be truthful
|
||
|
about the properties of the mainboard they sold me. i am also trusting everyone
|
||
|
involved in the production of these chips and boards. (attacks in manufacturing
|
||
|
[do happen](https://www.bbcnewsv2vjtpsuy.onion/news/technology-47800000).)
|
||
|
|
||
|
second, this stack is hardly innocuous! the hrng, ledger, and openpower system
|
||
|
are all rather unusual pieces of equipment.
|
||
|
|
||
|
i have made some compromises along the way in the name of expedience. i would
|
||
|
rather not have to trust IBM, but the alternative is trusting that libreboot has
|
||
|
managed to dig all the backdoors out of the old thinkpads. it comes down to a
|
||
|
bet, though i am not wagering everything on that one bet. if my online machine
|
||
|
fails me, my digital person is at least safe for a time because my keys are not
|
||
|
on my online machine. detecting that failure then becomes paramount.
|
||
|
|
||
|
this is not a bet i would like to have to make if my life were in danger. i
|
||
|
share all this not because i am confident that it is the best that anyone can
|
||
|
come up with, but because i think it may be a good starting point for some.
|
||
|
experimenting, thinking through things, and customising one's own stack is
|
||
|
encouraged. for example, the ledger might be swapped out with some sort of
|
||
|
|
||
|
at the very least, i hope this starting point provides a strong enough
|
||
|
foundation for the work ahead.
|