tillitis / tkey-verification Goto Github PK

In 0.0.2 we decided to remove the automatic detection of TKey serial port device path on Macos. The implementation (https://github.com/bugst/go-serial/blob/master/enumerator/usb_darwin.go) was not in pure Go and required the use of Golang's Cgo -- that is, calls to C code. To compile it, Macos/Darwin libraries/headers/source code needs to be available (and C compiler is used). Because of this, it became complicated to reproducibly build release binaries (and also to build them all on one platform). We decided to prioritize reproducible builds of these binaries, which are used by customers to verify that their TKey is genuine.

The consequence of removing automatic TKey detection on Macos is that after plugging in the TKey, user has to first list the available serial ports using something like ls -l /dev/cu*, and then run the verification using the relevant serial port like: tkey-verification verify --port /dev/cu.usbmodemN). There will typically only be 1 /dev/cu.usbmodem present, unless the user has some other similar serial-port based devices plugged in. Other platforms does not (usually) require the use of the --port option.

One idea to work around this was to just have the program look for any /dev/cu.usbmodem* devices and if exactly 1 is found, then use it. This runs into the risk of talking to a serial port which does not belong to a TKey. However unlikely, this does not seem like a nice thing to do. The point of using the enumeration of the go-serial library is that it can list serial ports that belong to a USB device with a specific, known VendorID:ProductID (1207:8887 being Tillitis').

The path forward to enable auto-detection on Macos is probably to think through and implement a way to conveniently build reproducible Macos releases (of both architectures) when using CGO (ideally getting the two other platforms built at the same time). Or, could there be a pure-Go way to find out about the origins of a device-node on Macos?

The readme contains a section with some sort of info about the different values:

H = hash(udi,pubkey)
S = signature(H)
T = tag of the signer-app binary that was used

H and S are explained, but not T.

Goal: Let a user verify that the TKey is a genuine Tillitis.

We need new provisioning and verification software, mostly (only?) on the
host side, possibly the same program with different arguments.

Provisioning:

• Get UDI from TKey.
• Run an app, probably signerapp from a tagged version.
• Get signerapp's public key.
• hash(udi,pubkey)
• Sign hash with our own secret key.
• Store signed hash somewhere (print a QR code? publish behind a web form?), possibly publish the signed hash in Sigsum.

Verification by user:

• Somehow get hold of our public key. Perhaps in the software repo and/or our web site.
• Get the published signed hash. Perhaps a web page? Perhaps a QR code? (But see below about Sigsum.)
• Get UDI from TKey.
• Run the same TKey app we did (signerapp?)
• Get signerapp's public key.
• hash(udi, pubkey)
• Get the published signed hash. Perhaps a web page? Perhaps a QR code? Perhaps in Sigsum?
• Verify signature on the signed hash.
• Compare published hash with computed hash. If it's the same, the we ran the same software on the same stick in provisioning.

Software needs:

• One provisioning host program that extracts UDI, runs the signerapp, gets the stick's pub key, and outputs a signed hash(udi, pubkey). Possibly storing in Sigsum or somewhere else.

• One user host program (same as provisioning?) that extracts UDI, runs the signerapp, extracts the
  pub key, does hash(udi, pubkey) and checks against a provided hash.

Verisigner is dependent on tillitis-key1-apps repo, but the dependencies has been move to tkey-libs.

Use Goreleaser to make the release process less error prone.
Our other repos are already using it, use as a template.