add soft blog entries 004 through 006.
This commit is contained in:
parent
fbc52a5e9b
commit
3d54a6b82f
|
@ -0,0 +1,22 @@
|
||||||
|
# a preface
|
||||||
|
|
||||||
|
before entering into the details of building a secure foundation for one's
|
||||||
|
digital self, a caveat and a suggestion:
|
||||||
|
|
||||||
|
1) security is not a "set it and forget it" affair. it is active and constantly
|
||||||
|
changing. assumptions turn out to be wrong. people make mistakes, even if
|
||||||
|
they have good training. expect to make mistakes. have plans in place for
|
||||||
|
when (not if) that happens. at the very least, make sure you have tools in
|
||||||
|
place to notify you when your perimeter, whatever it may be, is breached. my
|
||||||
|
focus in the next few entries will be on strengthening the perimeter around
|
||||||
|
one's keys, but know that no perimeter is unbreachable. the goal is always
|
||||||
|
to make breaching the perimeter so expensive or difficult that it doesn't
|
||||||
|
justify the payoff.
|
||||||
|
|
||||||
|
2) one might consider taking up an art form as a way to believably produce
|
||||||
|
original cover messages. (being a meme lord _does_ count. the "seriousness"
|
||||||
|
of one's art form is irrelevant, for our purposes.) art can always be as
|
||||||
|
"noisy" as one likes, and an artist may always have their own reasons for
|
||||||
|
creating an artwork one way or another. having a hobbyist's level of
|
||||||
|
knowledge of electronics may also be very beneficial, as bespoke electronics
|
||||||
|
are unlikely to have well-known noise signatures.
|
|
@ -0,0 +1,16 @@
|
||||||
|
-----BEGIN PGP SIGNATURE-----
|
||||||
|
|
||||||
|
iQIzBAABCAAdFiEE0ZVR9dPnC9rIvgC+tQHDCzf0gGwFAl++vEQACgkQtQHDCzf0
|
||||||
|
gGyvhg//YMt4F0RVzFgelnLc3d2+ePXx6wD5+jA9Y1jUf3blcnk4SYHPmbQ8PVrY
|
||||||
|
YsSjQ/NhyxlTiNXEboGiMhgNTEwk7LK5jA+ASsIlYUwju/33v+pvNl8cLMrcj8+b
|
||||||
|
LGZGMte4f1ZK9SD6A/pmQU4F9QFaJ0j/ijQi5CPF2IRGnXEzu7bz0LmKR0X1nl4G
|
||||||
|
Gyrk2uixv8tQ91LxaPzQRWdbWvQ7eaZmHtX4ENHDamnn6SmSCEYtlxPish/IdirI
|
||||||
|
htCQ5+e+DUWqVn2SWoIhXFnbXFM5BrLAXCkVEk0IKhzBs35qeGYZQ6ReKx0UYs2O
|
||||||
|
WSrBG+0Ua4Wmio00WSOMkd9WyhbopcgsFf2V3Py+iii+MnZN8FK5UbCScRdo4IW0
|
||||||
|
BYt/4W4CIrAQnLj5mKIEXKjt49qmZIwnlJhqgrs8G8WfFZGLCOoVorLZJPwl+9FQ
|
||||||
|
Smhl12fKlSs8aGgeQHHSe5GYVVF+G5zJ2oqYopdtZDZWxuDKnWT+rxXT9AF0+2cl
|
||||||
|
WUxzXTeM07eYZpLk4zDhmRlqmUSKMxMJGP981BMev6QyUIh1HMkE6o3A9Xj5SRF/
|
||||||
|
heeGn1ArKxQFNt+iviuF6po1U2xBwHpVzonRWyNDBGAsDpGynp2dn5dtLKp5UqjU
|
||||||
|
o/mgagW2VvoXK0dmFYoDGnVja8ouAC14NQNlvukg5/7GyLtJTqQ=
|
||||||
|
=EID+
|
||||||
|
-----END PGP SIGNATURE-----
|
|
@ -0,0 +1,101 @@
|
||||||
|
# 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.
|
|
@ -0,0 +1,16 @@
|
||||||
|
-----BEGIN PGP SIGNATURE-----
|
||||||
|
|
||||||
|
iQIzBAABCAAdFiEE0ZVR9dPnC9rIvgC+tQHDCzf0gGwFAl++0LUACgkQtQHDCzf0
|
||||||
|
gGxO7Q/+PL14+Sy2agS+nAcSihZrMJRcZo0DHuf0gCv5vE+4R7fXvO6URV1RZgTo
|
||||||
|
iQpiE/JEKB0/vL+mc5yaQuPJPJbmW9qP0BjGEbHnnMMLnPi4YDbuokdHEvPFYm06
|
||||||
|
/aYhR9sjp38FyphZoKDtQKuArRdbNlAfZIIf5bGRo7sK3vQGFhsxOzDzYrgVEXPZ
|
||||||
|
rEtvzQ1r3WqztBKFnQuIl8/ZMRVYmqE0dOr3BGWqYRZXO+sd8s5Ib8UTT5Uhyp7g
|
||||||
|
4fDNP/8ezC66nt7+fgwVVJm+6RRCRPIfUG6OUje8cU2aKNkFwiee6V70SBaWYBL6
|
||||||
|
sOVhbSFw07Ca0Pcisz8y4atLCZOn4rBN8WCdy37LpIv5u40Zc7b6bWu9Nhq8WHm6
|
||||||
|
ZsotWMtd9UuRsXlxmDfW0+J4nctK/1rvfZ0S202GqLFvsBGEn1Z3DMe01Nba37GZ
|
||||||
|
5/Nl5b7H0S6jkYvYZqzbYmWvUDnf1d3tuN1scCGlBhwDRvPT5oK/fd+6H4qoBzal
|
||||||
|
4DjhEsdzbM8WmIuUo9DAHPOhEF7Khhu/8UXBcuXUtfwt2Abnvi/me7NGoO1/g3iV
|
||||||
|
yjufAqjhAwWizxIrVd8hb7hAI1mMV6C2Xzga4/q6Q3yx22V5nSLe/eF+RgjK3otZ
|
||||||
|
xsRtWF18Qe3kVJ/M+Hasm+ezVnjazwuEfx6gfYdNyrgd+E4Lg/I=
|
||||||
|
=2FZp
|
||||||
|
-----END PGP SIGNATURE-----
|
|
@ -0,0 +1,74 @@
|
||||||
|
# lix os
|
||||||
|
|
||||||
|
in order to have a system which both minimised trust dependencies and allowed me
|
||||||
|
to explore my ideas around securing my system unimpeded, i decided to design and
|
||||||
|
compile my own linux from source code.
|
||||||
|
|
||||||
|
i had done this before, years ago, by following the "linux from scratch" guide.
|
||||||
|
my goal now was to build a system i could use to birth my more-than-reasonably
|
||||||
|
secure digital identity. the goal was a statically linked linux based on musl
|
||||||
|
and suckless tools. i wanted an inflexible system that would do nothing without
|
||||||
|
my explicit, cryptographic permission, along with a tiny codebase that would be
|
||||||
|
easy to examine and modify.
|
||||||
|
|
||||||
|
my first attempt i named "mu linux," unaware that the name was already in use.
|
||||||
|
it was essentially a scripting of the linux from scratch approach, with a strict
|
||||||
|
"filesystem-as-database" approach. every discrete field was a file, so nothing
|
||||||
|
more than "cat" was needed to read package details. it had no ability to set
|
||||||
|
redundant urls for fetching source code, though, and no sandboxing at all. the
|
||||||
|
whole thing was also written as one, tightly coupled piece.
|
||||||
|
|
||||||
|
having proven that it was possible to build a static suckless userland with musl
|
||||||
|
on my openpower computer, i decided to start using some fancier linux features
|
||||||
|
to create some separation of state and concerns. i took note of what seemed to
|
||||||
|
me the discrete "units" of mu linux and began writing standalone utilities that
|
||||||
|
did only one thing each and which i hoped might prove useful to others tackling
|
||||||
|
the same problems. i built a package manager that used overlayfs and chroots to
|
||||||
|
keep filesystem changes from the build process and from the installation process
|
||||||
|
in their own directories, facilitating insight into each step of package
|
||||||
|
development.
|
||||||
|
|
||||||
|
as i went, i started having to make compromises. gnu tools were the first.
|
||||||
|
getting a c compiler toolset set up with musl proved difficult. only two
|
||||||
|
compilers seemed to have support for the powerpc64le platform: gcc and clang.
|
||||||
|
clang took an age to compile and gave me some trouble early on. musl-cross-make
|
||||||
|
provided a canonical set of patches for enabling muslc support, as well as some
|
||||||
|
other nice features. autotools, gnu-sed, and gnu-grep followed soon after.
|
||||||
|
|
||||||
|
then dynamic linking began creeping in. the first dynamically linked packages
|
||||||
|
were gpg and pcscd. i needed smartcard support, and gpg uses dlopen to load
|
||||||
|
smartcard drivers dynamically. rewriting portions of gpg would have resolved
|
||||||
|
the problem, but it seemed simpler to just allow this one package to use dynamic
|
||||||
|
linking. i also ended up making exceptions for perl and python, as they needed
|
||||||
|
dynamic linking to be able to load certain modules. i absolved myself by making
|
||||||
|
sure statically linked versions of those packages were the default. those
|
||||||
|
compromises got me a console userland with tmux, tor, lynx, and the ability to
|
||||||
|
display images to the framebuffer.
|
||||||
|
|
||||||
|
then i tried to start building an identity on tor and quickly discovered i had
|
||||||
|
no way to solve captchas! i tried building a copy of netsurf targeting the
|
||||||
|
framebuffer and learned i had to choose either wayland or sdl2 as middleware.
|
||||||
|
i chose wayland, thinking i could just use michael forney's wld and swc, both of
|
||||||
|
which were built with static linking in mind, and get a desktop environment out
|
||||||
|
of the deal. after quite some time wrestling with these packages, i ultimately
|
||||||
|
gave up: netsurf would launch, but then shortly thereafter lock up the whole
|
||||||
|
system, and i could not figure out why. i was losing patience with the whole
|
||||||
|
endeavor, so i decided to just use more common components for my desktop and
|
||||||
|
revisit the problem later.
|
||||||
|
|
||||||
|
so i made another compromise and built an almost entirely dynamically-linked
|
||||||
|
desktop system: sway as the window manager, foot as the terminal emulator,
|
||||||
|
netsurf with gtk3 as the web browser, and webkit2gtk as an alternate web browser
|
||||||
|
for when netsurf wasn't cutting it.
|
||||||
|
|
||||||
|
along the way i tried to bootstrap rust using mrustc in order to get firefox
|
||||||
|
built and then the tor browser, but no luck there. yet another problem to
|
||||||
|
revisit. in the meantime i've come up with new ideas for a third linux
|
||||||
|
distribution better able to manage runtime dependencies, but lix os works and
|
||||||
|
has been working for me now for a couple months.
|
||||||
|
|
||||||
|
today i've released my work so far. i have not yet purged the false starts and
|
||||||
|
half-working packages from their respective repositories, but at present it is
|
||||||
|
possible to set up the desktop system i have described here. my work is spread
|
||||||
|
out across several repositories, but the entry point for lix os is
|
||||||
|
[here](http://git.fuwafuwaqtlkkxwc.onion/yafox/lix-os).
|
|
@ -0,0 +1,16 @@
|
||||||
|
-----BEGIN PGP SIGNATURE-----
|
||||||
|
|
||||||
|
iQIzBAABCAAdFiEE0ZVR9dPnC9rIvgC+tQHDCzf0gGwFAl++0L4ACgkQtQHDCzf0
|
||||||
|
gGw78g/+I8Cet09ZuTjIyIaI5prB9XI6gAbIA4BSeKgJQ8gG1X1kHEUuSEDIhNcd
|
||||||
|
nR2RwAtfQHmCzDkJ254K+9qEua9qi6jWusX9joYLYxPtAiKfgt+zPf/czzEXKHC3
|
||||||
|
pvyBxogG9ANo7Oe3rFWucHCUjyu9Lp9wIo0XIIjPkgGfS5z9fcAJNgjecCUrDLzx
|
||||||
|
1LBeAYqA4c1rn0lGuqFcD0GIim+GFlEcozvb0iCXK9xPam9d6+04z3lELH+LNCXH
|
||||||
|
c5QLlzEDapXgI3FNc6tvhRnmUmSNj9grJHhTzU9pIZ5CXoBrYtgau+4ayFMK0+89
|
||||||
|
hg8xlUnnc5S/I2a9rZxunsIi+RDN/i6VS6IIpRg9bHoIfpudimWwlM9ZfkVNpxdT
|
||||||
|
QRCE21DTyTiDn0reRaLZTQBLxGENcAMkGlGqkJ1hoyrLwcWzCmNH9NzlEDTE07aZ
|
||||||
|
ozWB0edG5zmdOkILZn5OEvIkY4CnIym7mVU0AnaKAyDJzR5VySdvIdlmrrKhuPzu
|
||||||
|
EuBo/fNyD+rR3LmLCfyIxMRO49IrugNrQRYqAfZvmSFuvFGf8U4mS0FQQiLKpCLs
|
||||||
|
F5ZxkcRWa4lhIq2KftS/7cp/uYd3fPuejCOJa0td0KNGUTdTeEEdDl5j48GMWkt4
|
||||||
|
oJGDONyHbOC4UZaBg09XWFrj7nu2MrYU+QlkQGF9DwHtAA2teDM=
|
||||||
|
=CmJ5
|
||||||
|
-----END PGP SIGNATURE-----
|
Loading…
Reference in New Issue