tillitis-{gateware,firmware,qemu}: init at 23.03.1

[ghost]

• 2023-Apr-21: the emulator works! 🎉

What is this?

Tillitis is an owner-controlled (Edit: apparently I have been hoodwinked) cryptographic token, created by Mullvad.

Description of changes

• All of it builds using our clang, qemu, sdcc, and FPGA circuit synthesis tools (yosys/nextpnr) instead of the dockerified toolchain that Tillitis provides.
• The emulator works
• Try the gateware on real hardware (mine cleared customs this week, arrived yesterday)

I'm probably abusing pkgsCross here. But I can't get a full riscv32-none-elf-targeted clang to compile, even after spending a lot of time fighting with llvmPackages.libstdcxx (needed for a full stdenv bootstrap even though Tillitis doesn't use C++).

Things done

• Built on platform(s)
  • x86_64-linux
  • powerpc64le-linux
  • aarch64-linux
• Fits CONTRIBUTING.md.

[ghost]

The emulator works!

$ nix build -f . -L on_kgpe.tillitis-qemu.passthru.run && ./result
char device redirected to /dev/pts/19 (label chrid)
Hello, I'm firmware with tk1_name0:0x746b3120 tk1_name1:0x6d6b6466 tk1_version:0x00000001

PR submitted upstream to rebase their qemu fork to v8.0.0:

• hw/riscv/tk1.c: update to new HTIF API tillitis/qemu#16

[Artturin]

not nativeBuildInputs?

[Artturin]

diff --git a/pkgs/misc/tillitis/default.nix b/pkgs/misc/tillitis/default.nix
new file mode 100644
index 00000000000..a6c8c994263
--- /dev/null
+++ b/pkgs/misc/tillitis/default.nix
@@ -0,0 +1,15 @@
+{ makeScopeWithSplicing
+, generateSplicesForMkScope
+}:
+
+makeScopeWithSplicing (generateSplicesForMkScope "tillitis") (_: { }) (_: { }) (self:
+let
+  inherit (self) callPackage;
+in
+{
+  firmware-softcpu = callPackage ./firmware-softcpu.nix { };
+  firmware-usb2serial = callPackage ./firmware-usb2serial.nix { };
+  gateware = callPackage ./gateware.nix { };
+  qemu = callPackage ./qemu.nix { };
+
+})
diff --git a/pkgs/misc/tillitis/qemu.nix b/pkgs/misc/tillitis/qemu.nix
index dddc5e16d32..d752566ba34 100644
--- a/pkgs/misc/tillitis/qemu.nix
+++ b/pkgs/misc/tillitis/qemu.nix
@@ -2,16 +2,15 @@
 , stdenv
 , fetchFromGitHub
 , fetchpatch
-, qemu
+, pkgs
 , git
 , buildPackages
 , writeScript
-, tillitis-qemu               # for passthru
-, tillitis-firmware-softcpu   # for passthru
+, firmware-softcpu               # for passthru
 }:
 
-(qemu.override { enableDocs = false; })
-  .overrideAttrs(previousAttrs: {
+(pkgs.qemu.override { enableDocs = false; })
+  .overrideAttrs(finalAttrs: previousAttrs: {
   version = "8.0.0";
 
   # This is just `git rebase` of the tillitis fork forward to
@@ -53,10 +52,10 @@
   passthru = {
     run = writeScript "tillitis-qemu-run" ''
       exec \
-        ${tillitis-qemu}/bin/qemu-system-riscv32 \
+        ${finalAttrs.finalPackage}/bin/qemu-system-riscv32 \
         -nographic \
         -M tk1,fifo=chrid \
-        -bios ${tillitis-firmware-softcpu}/firmware.elf \
+        -bios ${firmware-softcpu}/firmware.elf \
         -chardev pty,id=chrid \
         "$@"
     '';
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index a1c8ded4c9d..eaba9f73d42 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -39750,10 +39750,7 @@ with pkgs;
     });
   };
 
-  tillitis-firmware-softcpu = callPackage ../misc/tillitis/firmware-softcpu.nix { };
-  tillitis-firmware-usb2serial = callPackage ../misc/tillitis/firmware-usb2serial.nix { };
-  tillitis-gateware = callPackage ../misc/tillitis/gateware.nix { };
-  tillitis-qemu = callPackage ../misc/tillitis/qemu.nix { };
+  tillitis = import ../misc/tillitis/default.nix { inherit makeScopeWithSplicing generateSplicesForMkScope; };
 
   duti = callPackage ../os-specific/darwin/duti {
     inherit (darwin.apple_sdk.frameworks) ApplicationServices;

conversion to a scope, LMK if you want me to commit it

[mchack-work]

You won't be able to try the FPGA bitstream (what you call gateware) on an ordinary TKey bought from the Tillitis shop. It has already been provisioned with a bitstream inside the FPGA's own configuration memory and locked down.

Please ping me at mc at tillitis.se and I'll see what I can do.

[ghost]

and locked down.

I assume this means you've blown some kind of "no more programming" eFuse, rather than letting the user do so themselves.

Is this mentioned anywhere in the documentation?

I feel somewhat bait-and-switched here. How is the user supposed to know what bitstream is on the FPGA if they can't load it themselves? If they can't generate their own UDS how can they be sure you didn't keep a copy of it?

Since the FPGA programming pins aren't accessible via USB (or at least shouldn't be) and these ICE FPGAs are not tamper-proof devices (i.e. they are not secure against physical attack) I'm not sure what threat model this is intended to protect against.

Edit: wow, looks like there was a rug pull three weeks ago. This is pretty disorienting for people who've been following your project for many months. You should be more up-front about this.

[mchack-work]

I'm sorry you feel bait-and-switched.

Currently only the locked-down end-user version is available in the
shop.

We will update the documentation and the shop to state very clearly that
this is a locked-down version.

The plan is to sell at least two products: A locked-down end-user TKey
and a Dev Kit with an empty TKey and a programmer board. The latter
was what we gave out during the Open Source Firmware Conference in
September but we're having some delays in getting it to the shop with
the latest revision of the PCB.

You can verify the TKey you have with the tkey-verification program.
This won't verify the bitstream but it will verify that the computed
CDI is the same as when we provisioned it (thus proving that it's the
same UDS, part of the bitstream) and the firmware is unchanged. The
firmware is reproducible and you can check the hash after source audit
and compiling, if you like.

You have no way of knowing if we kept the UDS (we don't) but you are
encouraged to use a User Supplied Secret (USS) when using the TKey.
The USS is used together with the UDS and a hash of the loaded device
app to produce the CDI that is used for key derivation.

[RaitoBezarius]

I convinced 2 friends to buy 2 of them (and myself 2 of them) because of this feature… :C.

[JulienMalka]

I convinced 2 friends to buy 2 of them (and myself 2 of them) because of this feature… :C.

That's a bit of a shame, me too...

[ghost]

Wow, Tillitis came through; they're selling unlocked TKeys through their storefront. I must be getting jaded; I had long ago stopped expecting that level of integrity from hardware vendors. Very impressed.

It may be a while before I get back to pushing this PR forward, but I am hacking on this material locally again.

[bbigras]

is anyone working on packaging the SSH Agent for TKey? I'm stuck at trying to link monocypher with tkey-device-signer