thudson

If you want to play mental poker with an arbitrary number of friends/enemies, I built a prototype with a really basic UI that extends the SRA81 protocol to support more than two players and that also removes the need to reveal the hands at the end of the game. https://secret.cards/

Similar higher-than-rated-bandwidth can be achieved on the TRS-80 Model 100, which uses an array of 10 HD44102 controllers. With an FPGA it is possible to draw full motion video on the LCD: https://twitter.com/qrs/status/1092410264316653568

The WEH001602A is pin compatible to the HD44780, with OLED output instead of LCD. In 8-bit parallel mode with an FPGA you can exceed the recommended clock rate to drive quite a bit of data into the displays: https://twitter.com/qrs/status/1088240598971310081

A few years ago I built an adapter to allow classic Mac CRT's to be used with BeagleBone or Raspberry Pi systems ( https://trmm.net/Mac-SE_video). X11 has supported 1-bit mono displays since forever, so it mostly worked out of the box with well written programs.

Watching youtube videos in 1-bit is an amazing aesthetic. Unfortunately all of my videos of it were on vine, so this Muybridge-esque cat video seems to be the only one that I cross-posted to twitter: https://twitter.com/qrs/status/1045272076750401536

12-eights for "microns turnabouts Como migraines": 9a7e6f41875b444851cb19f018cea83e6565762d88888888888813ac47d39ce7

Although I'm also a fan of "Georgetown surfboarded rips nodding", which hashes to the very pleasant 01234567894a7924a0a568c01ae2f48f93921fc9b4437d7866db3be132411b08

If you want to more easily configure UEFI Secure Boot on your Linux system, while also registering your own signing keys to eliminate the Microsoft and OEM ones: https://safeboot.dev/

The CD-ROM is now on archive.org: https://archive.org/details/hugo_nebula_1993

Brad Templeton wrote about it: "I believe this CD is now a piece of history, as the world's first major eBook project using current fiction. At the time it was the largest anthology of current fiction ever published in one volume, and it may retain that title even today. Prior ventures were small or featured either unpublished writers or public domain works. This anthology featured novels that in most cases had not yet come out in paperback."

In practice it is a bit of a pain during the initial setup and package installation -- I was probably rebooting to recovery mode once a day or more to install some command line tool that I had forgotten about. Once the machine is configured then it is a more rare occurrence, although your usage might vary.

Something that I'm not happy about is that the snaps all live on the writable /var since they want to do automatic updates all the time. This is problematic for a locked-down configuration and might recommend against a snap based distribution.

Separating out the bootable bits from the rest of the packages might help, as would running more things in sandboxes. Another option that we're exploring is some lvm magic to create a snapshot, upgrade the snapshot, sign it, and then on the next reboot use it as the real root. This is also useful for fleet management -- the new root filesystem, kernel, initrd, etc can arrive "behind the scenes" and on the next reboot is the one that is used. Since the PCRs can be predicated as well, the PCR policy can be signed and sent along with the upgrade to make it seamless.

If you want LUKS encryption with signed policies to prevent brittle PCRs, rollback prevention with monotonic counters, and user pin to prevent dictionary attacks, plus TPM sealed TOTP to attest to the state of the firmware: https://safeboot.dev/

The TPM is not a DRM enforcement mechanism if you set it up for your own use. It is a very useful tool for taking control of machine that you own - it provides a way to prove* to yourself that the system booting with the firmware that you've approved, in the configuration that you setup, and running the kernel and initrd that you've signed. https://safeboot.dev/attestation/#i-thought-remote-attestati...

*: Depending on your threat model and risks, some of which are discussed here https://safeboot.dev/threats/

Some forms of TPM tampering are explicitly addressed in the threat model:

> The PCR values in the TPM are not "secret", so an adversary with physical access could directly wire to the TPM and provide it with the correct measurements to extend the PCRs to match the signed values. The user PIN is still necessary to unseal the secret and the TPM dictionary attack protections both rate-limit and retry-limit the attacker.

Decaping chips to recover secrets is outside of the threat model, however.

A separate bootloader and key on USB does not protect against many physical attacks, nor ones that involve changing the firmware or nvram configuration through software attacks. Without some sort of sealed keys or attestation of the platform configuration, your external bootloader has no guarantees that the device itself has not been backdoored. mjg59's tpm-totp talk[1] discussed the difficulty of trusting the firmware that loaded the bootloader that loaded the kernel that is now asking for your password (although even with that it is necessary to add integrity protections on the encrypted disk, otherwise there are a variety of attacks against the systems).

Secure Boot is trustable, if you remove the vendor keys and reprogram the platform key with one under your own control. Likewise, the TPM is useful for protecting your secrets, not just enforcing DRM, if you take ownership of it and make use of the sealed key policies. See the safeboot.dev threat model[2] for how these protections are applied and how they detect or prevent many sorts of attacks.

1: https://mjg59.dreamwidth.org/35742.html 2: https://safeboot.dev/threats/

This NSA report is a wonderfully thorough guide to configuring UEFI Secure Boot, although it is another example of how unusable security tools can be. This conplexity was my motivation for writing the safeboot[1] scripts, which wrap all of the signing key management, TPM key sealing, and attestation into a hopefully easier to use package.

1: https://safeboot.dev/

That was exactly my motivation: there are tons of guides for setting up UEFI SecureBoot platform keys, yubikey tokens, TPM disk encryption, dmverity, etc, but all of them seemed to involve "type hundreds of commands with no mistakes and hope that your system still boots afterwards". It felt to me that each program represented a low-level library function that needed to be linked into a high-level tool to handle the common cases for most users.

Regarding /boot being in the clear -- the initramfs and kernel shouldn't contain any secrets, so having them unencrypted isn't a big drawback. Signed is much more important so that an adversary with write access to the disk can't swap out the kernel.

One advantage to using the TPM for unsealing the disk encryption key is that it helps protect against attacks that re-write the firmware. If an adversary can reflash the platform key (via either a local SPI flash programmer or some code execution that gives them write access to the NVRAM region of the flash), then you can't tell that the PK has been changed and that the kernel to which you are inputting the password is no longer trustworthy. Since the secret is sealed with (among other things) the hash of the UEFI SecureBoot configuration, the TPM will not unseal it if the PK, KEK or db are changed.

If you want to take it to another level, TPM TOTP can be used to validate that the password dialog is even valid before you type in the password. I think we can integrate that fairly easily into the initramfs for the next version of safeboot.

It's pretty typical boot time for most UEFI server platforms with network cards and RAID controllers. The Dell R630 takes about six minutes, the HP DL3x0 is about eight and the Lenovo x3550 takes over ten. Of the ones I've tested only the Intel s2600wf is under two minutes in a stock configuration, but with LinuxBoot it is less than twenty seconds to a Unix shell despite the PEI and DXE serial debugging messages: https://www.youtube.com/watch?v=0HISDFXZvSI

The threat model that LinuxBoot is addressing is different form SecureBoot and it can use the well known, normal Linux tools rather than the unconventional UEFI ones.

The Heads runtime can do things like use TPMTOTP to attest to the user that the firmware is unaltered and includes gnupg to verify the kernel and root filesystem signatures with the user's own key.

For cloud systems a LinuxBoot runtime can use the TPM or other trusted hardware to remotely attest to the client's own provisioning server that the configuration is unchanged, and since it is reproducibly built, that the firmware is what the user expects. This is significantly more trustworthy than the binary blobs and non-reproducible UEFI firmware on most servers.

The LinuxBoot kernel establishes a hardware root of trust with the TPM and measures the ROM before bringing up any IO devices, so when it connects to the network it is able to perform a remote attestation as to its state. This way the hosting provider or customer can decide to not provision a node that has somehow been modified by a prior tenant.

For a network booting scenario the LinuxBoot server can use GPG to validate the signature on the kernel that it receives over the network. Additionally, secrets can be sealed in the TPM and only unlocked if the received kernel matches the expected one (and if the local firmware is unmodified).

With LinuxBoot you can use any filesystem that Linux supports, not just FAT.

You can update boot entries by editing shell scripts, rather than manipulating opaque NVRAM variables.

You can run Linux applications straight from the ROM if you want to do that.

You can avoid legacy partitions entirely and use LVM for flexible volume management.

And...

You can build it yourself and verify that the reproducible build matches what others have built to ensure that the firmware is clean.

You can have the firmware attest to you via TOTP that it hasn't been changed.

You can have a fully encrypted disk, with secrets sealed in the TPM and only unsealed if the firmware is unmodified.

You can include device drivers for things that UEFI doesn't support.

You can use external hardware tokens like a Yubikey to sign the OS install and have the firmware validate the GPG signature.

Or what ever else you might want to do...

Helen Sharman was Britain's first astronaut -- she spent seven days on the Mir space station in 1991. Peake is the seventh British astronaut[0].

0: https://en.wikipedia.org/wiki/British_space_programme#Britis...

Cool URLs still work in OmniWeb on a NeXT with a decades old bookmarks file: https://www.flickr.com/photos/osr/17082625625/lightbox

The Mondo 2000 interview bookmarks, not so much.

tl;dr: Xeno Kovah, Corey Kallenberg and I ported several previously disclosed vulnerabilities from Windows UEFI systems to Apple's EFI firmware. Using the 2014 Darth Venamis ("Dark Jedi") vulnerability we were able to unlock the motherboard boot flash, write our proof of concept to it, then scan the bus for PCIe Option ROMs and copy the worm to them as well. This allowed it to spread to other systems via shared Thunderbolt devices, possibly across air-gap security perimeters or via evil-maid attacks.

Like the original Thunderstrike vulnerability presented at CCC last year[0], firmware passwords and FileVault encryption don't prevent infection, reinstalling OSX won't remove it and it changes the RSA keys in the ROM so that Apple's firmware update routines can't remove it either. The only way to remove it is with a hardware in-system programming device connected to the SPI flash chip.

This is a transcript of our hour long presentation at DefCon 23 / Blackhat 2015 last week, which is why it is too long to read... Here is a shorter overview[1] and a demo video[2].

0: https://trmm.net/Thunderstrike_31c3

1: https://trmm.net/Thunderstrike_2

2: https://trmm.net/Thunderstrike2_demo

Firmware passwords can be bypassed by a local user with a Thunderbolt Option ROM. The 10.10.2 fix for Thunderstrike left that hole open during normal boots: https://trmm.net/Thunderstrike_FAQ#Is_Thunderstrike_fixed_in...

Fun! I've been working on a similar free software project to unfold generic STL files for laser cutting: https://github.com/osresearch/papercraft

The problem is that most models on thingiverse produce designs that are very, very difficult to fold up. Even low-poly things (like the Stanford Bunny) are almost impossible.

Most of the disk packs have had the help files deleted to reclaim 100 blocks so HELP results in a "?KMON-F-File not found SY:HELP.SAV". If the files are there, it looks sort of like this: https://www.flickr.com/photos/osr/14008886427/

I hear that the WC doors on Swiss trains have a slide-to-unlock feature as well.

The T221 is a great monitor for coding -- check out the size of the "fixed" font on the wikipedia image. But with most configurations it only does 12, 24 or 48 Hz depending on how many DVI channels you can use. Also, since it is being driven as four separate 1920x1280 displays with xinerama there tends to be tearing across the boundaries with movies or video since the refresh from the cards is not synchronized.

Other than that, I love mine and am considering a second one for dual head using eight DVI channels.