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/
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
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
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/
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."
“These directories contain the "raw" form of the anthology, which is to say RTF, GIF and JPEG files, along with a few ASCII files. They are found in the online version, and in a special directory on the CD for people without MS-Windows or a Macintosh.” [read.me]
The format description for the .txt annotations is at: "hugo-nebula anthology 1993/hugo/novel/vinge/exnotes.txt"
To take a first quick look at the notes:
unzip hugo.zip
cd 'hugo-nebula anthology 1993/hugo/novel/vinge/'
rg '^\^ ' # or grep -rn '^\^ ' .
Hmm. Perhaps someone needs to transform those RTFs to HTML, with appropriate management for the footnotes. Then we can finally have the HTML version of the annotated novel that was promised 27 years ago. :)
It's pretty hacky, but you end up with a single HTML file with Vinge's notes in a side margin, with numbers and everything. There's probably ways that the title bits could be improved, but I'm too lazy to fix it now that I have the actual HTML file.
Good luck! Let me know if you have questions, I may be able to help.
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...
No it is not, but I am fairly sure that is one of the main use cases. And you have a uniquely identifiable machine which creates new security problems.
We also know from smartphones that manufacturers can indeed be motivated to lock bootloaders. I think the main reason we don't have that on PC is that there are still multiple manufacturers and legacy considerations.
I cannot read the minds of Microsoft, but I have my assumptions that I believe are quite safe.
https://trustedcomputinggroup.org/ has rebranded themselves because they got a bad name. Justified in my opinion. People have identified the motivation on day one.
But again, yes, it can have some security advantages against the numerous disadvantages. I think it is bad for open computing overall. There are certainly mechanisms to secure your OS that don't rely on TPM. It may benefit you, but I would actually like to see it removed from my machine with all the consequences (which would be not being able to play DRM protected media).
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.
I think there are some misunderstandings in this thread about what Secure Boot is and how it works. Secure Boot doesn't protect your disk encryption key.
The purpose of Secure Boot is to validate that the bootloader is trusted so that you can have some assurance that you're not giving your disk encryption password to a fake bootloader which phishes you.
Secure Boot doesn't give any agency more control over your machine than if you were not running Secure Boot. Using Secure Boot is strictly more secure than not using it, even if you don't trust the parties who made the implementation.
You could say "Your computer is trustable, if you have verified the silicon of your CPU, motherboard, etc." and it would be equally true. Secure Boot isn't perfect, but it's a lot better than no Secure Boot.
The only argument against it is that it provides a false sense of security, which is only a problem if you decrease security in other areas as a result of using Secure Boot.
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.
(additional plug) portions of which are used to enable github.com/google/go-attestation, which aims to make it practical for verification of system boot state in a heterogeneous environment and is now being actively used inside Google.
I've been following safeboot for a while and it looks really, really cool!
One concern I've been having regarding a read-only root file system – an idea that I really like! – was how cumbersome software updates (say, through apt) and quick config changes (in /etc) must be. AFAIU I'd have to manually sign a new rootfs image every single time[0] which looks rather painful to me. I wish Linux distributions provided a clear separation between user-facing software & configs and system-internal stuff that one hardly ever has to touch: IMHO software & configs should by default get installed on a per-user basis and not require root. (And applications should also be sandboxed by default but I'm digressing…)
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.
> 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 sounds very nice and similar to Android's A/B partitions!
> Since the PCRs can be predicated as well
This may be a stupid question but… what are PCRs? Google yields "polymerase chain reaction" – a method used, among others, for detecting the coronavirus but I'm sure that's not it. :)
It's amazing that you disregard the most basic attack in your threat model (https://safeboot.dev/threats/): going after the TPM itself. TPMs are usually FIPS 140-2 L2: not something that's meant to be hardened against even basic hardware attacks.
IMHO the TPM should be a required piece but not the only piece of the puzzle. If I loose my laptop, I don't want the goods to be protected exclusively by a key that's trivial to recover from it (stored in something that's not a secure-element).
tl;dr; Use the TPM (and potentially other technologies like SGX) as part of your KDF to strengthen PIN/passphrase that the user provides. This breaks the asymmetry of offline attacks (attacker will always be bound by TPM/SGX-speed). Do NOT give it the only key required to decrypt your data.
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.
What I'm argueing in my talk is that it shouldn't be. Odds are your phone does it better :)
Decaping a chip from a lost laptop is far from science fiction and can be performed at a fixed cost. Mitigation is super-cheap... There's just no good reason to store the "final" key on the TPM.
Here I interleave rounds of argon2id (configured with parameters that fit my system: use up all the RAM and all the cores since there's nothing else to do in the initrd) with HMAC rounds from TPM and/or SGX (configured with the right policies so that they rate-limit and only unlock if the PCRs check out).
Surely TPM is only useful for getting to a trusted point/input for the key that encrypts the drive?
If an attacker can get hold of the hw long enough to get into the TPM they could just copy the encrypted drive, and replace the laptop entirely - the only thing needed would be to ship the typed pass-phrase home on next login?
I suppose ideally there'd be some kind of challenge-response to verify the TPM (very naive version - type in a wrong pin/pw first - if it's accepted you know the system is compromised..).
But, assuming the attacker can replace the whole system - I'm not sure I see how it could be trusted fully, assuming it's not under 24/7 watch (and even then, it could of course be compromised, but shifting the attack toward eg bribery, betrayal, neglect etc).
It is very much news to me that key-recovery from the TPM is not supposed to be that hard.
If that is the case, how does it strengthen a PIN? Any attacker wanting to find a decryption key could simply extract the key, and then brute-force the PIN outside of the TPM constraints, can't they?
It definitely does when there is no attempt made at protecting against it. L2 means "tamper evidence", you need L3 for things to start to be designed to prevent it from being "basic".
SGX is L3, you'll be hard pressed to find a TPM that does better than L2.
Phrasing it another way: Even if you don't have the skills/equipment to do it. How much do you think it costs to get someone to do it for you? How reproducible is that process? Why are we assuming it's hard?
I'm pretty sure their benchmark for hard is needing to take the device apart and do surgery on it. To me, that is what I would qualify as hard despite knowing how to do it, it's hard by way of being annoying.
However, regarding cryptography, the NSA's cryptographic expertise and resources are secret, so it's very hard to include them in a threat model.
They could know more than civilian cryptographers, have new direct attacks that we don't know yet, e.g. algebraic attacks and specialized hardware to solve gigantic systems of equations. Or, they could have a working quantum computer with many qbits. We don't know, do we?
My threat models for my clients use a state sponsored APT, and generic SIGINT and HUMINT agencies all the time. The idea being that SIG agency does passive interception and traffic analysis, where the HUM agency does targeted collection, and the APT is opportunistic zero day.
It's not just the NSA, it's literally everyone else as a class of threat they might need to consider. Also, I use opposition researchers as threats for politically exposed people, and who cross over into foreign spy level stuff.
The controls it prescribes are straightforward, and realistically, it's a risk you just understand, do your best to mitigate it, and accept.If you are going to not do business because you are afraid of state level consequences, you've got a legal/regulatory problem, and not a technical one.
That leak says something about the resources, not the expertise. For example both the NSA and almost every NATO equivalent of it tends to design cryptographic primitives with openly documented “weird” interfaces (key checksums, self-synchronizing remarkably slow stream ciphers...) and probably nobody outside of these agencies really knows why.
The way I see it, safeboot is a bunch of scripts helping to set up solutions already available.
I didn't look at it in details, but in one of the screenshots the system asks for a pin to unlock the disk.
I agree that storing a full decryption key in the TPM may be risky. Even if the thread model should be considered (it may not be interesting for an attacker to go around doing this to Joe Random's laptop) it is something that users should be aware of.
I don't like TPM. I generally don't like any hardware-based security features. The security must relies on sufficiently long passphrase in my brain remains secret.
Perhaps, I can use Shamir's Secret Sharing to share a key with other people I trust, including the lawyer I paid which must keep client's secret and exempt from police raid by law.
