tillitis/tkey-ssh-agent

SSH Agent for TKey, the flexible open hardware/software USB security key 🔑

tkey-ssh-agent's Issues

Test apps for EMC testing and serial speed

A modified signer app with no touch requirements and a host software that loads and then just signs messages forever. For EMC test and serial speed test.

Signatures need to be validated by the host part to see if something goes wrong.

LGPL licenses on libraries

Current licenses are GPLv2 only, even on C libraries and Go packages. This means source code which is linked with these libraries or packages automatically also gets a GPL v2 license. This is probably not what we want, since it means no proprietary software can be written using our libraries and packages.

Do we reconsider?

If so, perhaps we should relicense the C libraries and the Go packages under LGPL? Here's one version:

https://www.gnu.org/licenses/lgpl-3.0.en.html

[windows] tk-sign app hangs during long term stress testing

Using the test-loop.sh script from the communication test branch, the test-loop.sh eventually hangs after some number of signatures, for example:

loop count: 77286, seconds passed: 50256
Connecting to device on serial port COM8 ...
Public Key from device (UID 00010:20:3:04050607): ebb95cac6cb6fb662a231363cfeb6d5a132866ed2fee55dc8efc7bc8c7726ffe
Sending a 128 bytes message for signing.
Signature over message by device: 1a0f93609b37952e7a4018930ecd5aeb97883dac32e6115e10ecefc07b93db4ae3b83f4bc3a923e6237e3b1dbdfd612634392b8fcc1b6c1f8379aface3a0fe0d
Signature verified.

Inspecting the process monitor, it does appear that tk-sign is the part that has hung:

$ ps -e |grep tk-sign
    59211   63534   63534       6240  pty4      197609 08:18:50 /c/Users/matt/Other-Repos/tillitis-key1-apps/tk-sign
     3629   63545   63545      19564  pty2      197609 20:48:03 /c/Users/matt/Other-Repos/tillitis-key1-apps/tk-sign
    57328   63531   63531      16824  pty0      197609 19:14:59 /c/Users/matt/Other-Repos/tillitis-key1-apps/tk-sign
    37230   63573   63573      19276  pty3      197609 10:55:21 /c/Users/matt/Other-Repos/tillitis-key1-apps/tk-sign

This testing was performed on a desktop computer running Windows 10, and go version "go1.19.3 windows/amd64" installed from the official package. The golang apps were compiled in a mingw shell, using (I believe):

go build ./cmd/runapp
go build ./cmd/tk-sign

The riscv signerapp app.bin firmware was compiled in an Ubuntu docker container, and copied into the ./apps/signerapp directory. Similarly, the application fpga gateware was compiled on the same Ubuntu docker container, using the version in the communication_test_automation branch (which should be unchanged from the current main branch). This gateware was then flashed onto 4 mta1-usb-v1 boards (two prototypes, and two from the OSFC production batch, but all with similar components), and the usb sticks were plugged into USB ports on the desktop motherboard. Then, a test loop script was started for each device, targeting the specific serial ports like this:

USB_DEVICE=COM99 ./test-loop.sh

The devices were left to run overnight. Two hung early, one at 4928 loops, and one at 13498 loops, and a third hung much later at 77286 loops. The fourth is still running, and is up to 93500 signatures:

In windows, so far all of the hangs have been after the 'Signature verified.' message displays. This test was also repeated on Linux with a different failure mode, which will be posted as a second issue.

macos: the serial pkg's enumeration can't be built with CGO_ENABLED=0

From: https://pkg.go.dev/go.bug.st/serial

This library tries to avoid the use of the "C" package (and consequently the need of cgo) to simplify cross compiling. Unfortunately the USB enumeration package for darwin (MacOSX) requires cgo to access the IOKit framework. This means that if you need USB enumeration on darwin you're forced to use cgo.

pkg.go.dev doesn't show our Go modules doc

https://pkg.go.dev/github.com/tillitis/tillitis-key1-apps/tk1 should show the documentation of the tk1 Go module but doesn't. Instead it says: "Documentation not displayed due to license restrictions". This is probably because it doesn't automatically detect our license, see

https://pkg.go.dev/license-policy

An example loader app

The CDI computation is dependent on the app digest by design. This means we can't change a device app at all without producing a new CDI. This means we can't upgrade a device app, do any bug fixes or anything it all with a device app without changing CDI.

If we want to allow people to upgrade their apps we have to have another way: a small loader app (that doesn't change with an upgrade) with a security policy.

The loader app works like the firmware in loading a new app into memory and then jumping to it. It just excludes the CDI computation and instead hands the already computed CDI over to the new app.

To not just reveal the CDI to any app it also includes a security policy requiring all apps it loads to be signed with a private key. The corresponding public key for verificiation is part of the loader app.

Break out device libraries

Break out the device libraries to their own repo (or repos?).

We can then use these libraries for both firmware and apps more easily and keep tags separately from apps.

Will also probably need LGPL licenses to be a little more useful to people.

U2F/FIDO support for Linux

Investigate the possibility to get U2F/FIDO support in TKey.

One possible solution, at least for Linux systems, is to use the uhid system to create a virtual HID device as a user process.

An existing solution using uhid is:

https://github.com/psanford/tpm-fido

Looking at the code it seems the memory/memory.go shows us what we need to fulfill to be able to use a TKey instead.

Let's keep this issue for Linux and create other issues for other platforms.

The random app should not return TRNG entropy

The get_random function returns entropy from the TRNG core. It should instead use a secure Digital Random Bit Generator (DRBG) such as a Hash_DRBG or CTR_DRBG.

https://github.com/tillitis/tillitis-key1-apps/blob/dfb113101be19d7acdd544a4759b85aa8129e2d5/apps/random/main.c#L26

tkey-ssh-agent: make less assumptions on systemd availability

make install want to install a systemd service file with no opt-in/out.

tkey-ssh-agent(1) make some assumptions on systemd availability. (edit by quite: it no longer does)

Verify reproducible builds

Verify and go through best practices for reproducible builds, primarily for TKey apps and secondary for host apps.

detect os when building to support darwin

The makefile enforces to check the signer hash, this is done using sha512sum which goes under a different name on darwin, shasum -a 512.

To support building on darwin without manual modifications to the makefile, consider either adding a flag for the user to specify OS, or unamefor autodetection.

Server use-case with no touch

Consider having your TKey attached to a server box running, say, Ansible Tower or something and using the tkey-ssh-agent to provide ID for Ansible's ssh sessions. No one is there to touch the TKey touch sensor when needed.

We have support in both tkey-ssh-agent and tkey-device-signer to compile it with TKEY_SIGNER_APP_NO_TOUCH but no packaging for this use case. Maybe supply packages and more documentation on how to use?

I/O and debug function confusion

The debug functions putchar(), puts() et cetera currently only work on the QEMU debug port we added. This is confusing.

I suggest we change the names of these function to debug_*() or qemu_*() or something and also include real puts() et cetera that uses the UART.

Avoid using udev for monitoring TKey presence, notifying tkey-ssh-agent

Instead we should detect and (re)connect to TKey when we the agent service gets an actual command. We have time to do this. sshd does have a LoginGraceTime setting which could time out signing takes too long time, but the default is 120 seconds. In the code, the duration seems to span all sorts of authentication including keyboard interactive. Also currently user must already touch the TKey to confirm signing/authentication for log-in within this time.

Getting rid the use of udev for this purpose will simplify porting to other OSes. Though we still need (at least on Linux) a udev rule to make TKey's serial port readable by logged in user.

Break out device apps

Break out the device apps to their own repos:

• blink
• nx
• random
• rng_stream
• signer
• timer

Take special care of signer and include the hash in -apps and the checks there so we don't change the resulting binary unnecessarily.

Embed tagged signer in tkey-ssh-agent

Like in tkey-sign-cli we want to embed the pre-compiled signer app directly in the repo. We keep all the build scripts to rebuild stuff, obviously, and still use that in the CI.

We keep a digest to be sure nothing changed, always checked with CI.

Embedding the binary in the repo enables go install.

Break out client apps

Break out client apps into their own repos. We have our own issue for the ssh agent.

• tkey-runapp
• tkey-sign

Did 0.0.6 release get re-tagged?

👋 While building [email protected] formula and dependencies, we found that tkey-ssh-agent 0.0.6 source tarball has checksum mismatch, raise this issue to confirm if there was a git re-tagging happened. Thanks! 🙏

[linux] tk-sign app hangs during long term stress testing

Using the test-loop.sh script from the communication test branch, the test-loop.sh eventually hangs after some number of signatures, for example:

loop count: 645, seconds passed: 362
Auto-detected serial port /dev/ttyACM1
Connecting to device on serial port /dev/ttyACM1 ...
Public Key from device (UID 00010:20:3:04050607): ebb95cac6cb6fb662a231363cfeb6d5a132866ed2fee55dc8efc7bc8c7726ffe
Sending a 128 bytes message for signing.

or:

loop count: 235, seconds passed: 132
Auto-detected serial port /dev/ttyACM2
Connecting to device on serial port /dev/ttyACM2 ...
Public Key from device (UID 00010:20:3:04050607): ebb95cac6cb6fb662a231363cfeb6d5a132866ed2fee55dc8efc7bc8c7726ffe
Sending a 128 bytes message for signing.
Signature over message by device: 70dc2638de2cd1d3e09040d511f36ece9ebc40a7205a9c458216ccf8bd4fa3a635a8a018e77e563bab3f2ff687377b6d13d404326905df27f0b70ccdb15c6b01
Signature verified.
loop count: 236, seconds passed: 133
Auto-detected serial port /dev/ttyACM2
Connecting to device on serial port /dev/ttyACM2 ...

This testing was performed on a laptop running Debian, with the signing apps running from Ubuntu docker containers. Four mta1-usb-v1 devices were prepared in the same way as described in #19. Three devices were connected to the laptop using a USB 3 hub, and the fourth directly to a USB a port (previous testing did not uncover any correlation between which port the device was connected to, and the eventual failure). The docker container was built from the communication test branch of the tillitis-key1 repository:

cd contrib
make build

Then, a test-loop script was run for each of the four connected keys, using make to start the scripts:

USB_DEVICE=/dev/ttyACM0 make test-loop

All four scripts stopped after a short number of iterations, hanging in tk-sign after displaying one of two messages, either 'Sending a 128 bytes message for signing.', or 'Connecting to device on serial port /dev/ttyACM2 ...':

This likely has the same cause as #19 , however the point where it hangs happened to be different in linux, so I reported it as a separate issue. There is also a chance this is related to running the script in a container, so it might be good to try this again without containers (I can do that if it's helpful).

Update go-serial to build for darwin

Due to stricter enforcement of rules in Go 1.21, go-serial version < 1.6.0 does not build on darwin.
So for our applications to be supported on darwin for Go 1.21, go-serial needs to be updated to at > 1.6.0, see release notes here.

# go.bug.st/serial/enumerator
../../../go/pkg/mod/go.bug.st/[email protected]/enumerator/usb_darwin.go:142:11: cannot define new methods on non-local type C.CFStringRef
../../../go/pkg/mod/go.bug.st/[email protected]/enumerator/usb_darwin.go:148:11: cannot define new methods on non-local type C.CFTypeRef
../../../go/pkg/mod/go.bug.st/[email protected]/enumerator/usb_darwin.go:154:11: cannot define new methods on non-local type *C.io_registry_entry_t
../../../go/pkg/mod/go.bug.st/[email protected]/enumerator/usb_darwin.go:165:11: cannot define new methods on non-local type *C.io_registry_entry_t
../../../go/pkg/mod/go.bug.st/[email protected]/enumerator/usb_darwin.go:175:11: cannot define new methods on non-local type *C.io_registry_entry_t
../../../go/pkg/mod/go.bug.st/[email protected]/enumerator/usb_darwin.go:194:11: cannot define new methods on non-local type *C.io_registry_entry_t
../../../go/pkg/mod/go.bug.st/[email protected]/enumerator/usb_darwin.go:214:11: cannot define new methods on non-local type *C.io_iterator_t
../../../go/pkg/mod/go.bug.st/[email protected]/enumerator/usb_darwin.go:218:11: cannot define new methods on non-local type *C.io_iterator_t
../../../go/pkg/mod/go.bug.st/[email protected]/enumerator/usb_darwin.go:222:11: cannot define new methods on non-local type *C.io_iterator_t
../../../go/pkg/mod/go.bug.st/[email protected]/enumerator/usb_darwin.go:229:11: cannot define new methods on non-local type *C.io_object_t
../../../go/pkg/mod/go.bug.st/[email protected]/enumerator/usb_darwin.go:233:11: cannot define new methods on non-local type *C.io_object_t

Clean out everything when make clean

Running make clean after make does not remove the all build artifacts.
I suggest removing the follwing files when doing make clean:

    runapp
    tk-sign
    tk-ssh-agent

Attempt to queue multiple LoadAppData cmds fails

I've tried rewriting the LoadApp function to queue -- keep in flight -- multiple LoadAppData cmds, while reading the responses only when they come in. This should be possible since we have an RX FIFO of 512 bytes in hardware.

The idea is to keep the app continuously fed with data to process, instead of waiting for its responses (acks) for every frame of data. The goal being faster loading of the app.

There are two branches. loadappdata-queue is a first attempt, which I think is flawed because (when the queue is full) it waits for and reads a response after each sending of cmd.

The second attempt loadappdata-queue-take-2 always makes an attempt to read a response, but times out after some milliseconds if there is none. But both attempts fails in the same way. After a few cmds/responses, we get a response which has the wrong cmd code. Running towards QEMU works though. And setting the queueLen to 1 works for running towards hw.

Output from running loadappdata-queue-take-2:

~/t/tillitis-key1-apps ./tk-ssh-agent -k
Auto-detected serial port /dev/ttyACM0
Connecting to device on serial port /dev/ttyACM0 ...
GetAppNameVersion tx (frame len: 1+1):
00000000  58 09                                             |X.|
GetAppNameVersion: ReadFrame: Read timeout
GetNameVersion tx (frame len: 1+1):
00000000  50 01                                             |P.|
Device is in firmware mode.
Loading app...
LoadUSS tx len:129 contents omitted
app size: 27656, 0x6c08, 0b110110000001000
SetAppSize tx (frame len: 1+32):
00000000  52 03 08 6c 00 00 00 00  00 00 00 00 00 00 00 00  |R..l............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00                                                |.|
LoadAppData tx (frame len: 1+128):
00000000  13 05 81 40 01 41 81 41  01 42 81 42 01 43 81 43  |[email protected]|
00000010  01 44 81 44 01 45 81 45  01 46 81 46 01 47 81 47  |.D.D.E.E.F.F.G.G|
00000020  01 48 81 48 01 49 81 49  01 4a 81 4a 01 4b 81 4b  |.H.H.I.I.J.J.K.K|
00000030  01 4c 81 4c 01 4d 81 4d  01 4e 81 4e 01 4f 81 4f  |.L.L.M.M.N.N.O.O|
00000040  37 71 00 40 41 11 17 75  00 00 13 05 45 bc 97 75  |[email protected]|
00000050  00 00 93 85 c5 bb 63 57  b5 00 23 20 05 00 11 05  |......cW..# ....|
00000060  e3 4d b5 fe 97 00 00 00  e7 80 e0 00 00 00 00 00  |.M..............|
00000070  00 00 13 01 01 81 23 26  11 7e 23 24 81 7e 23 22  |......#&.~#$.~#"|
00000080  91                                                |.|
QUEUE after send ID:0: [0] (nsent:127 offset:0 binlen:27656)
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0]
LoadAppData tx (frame len: 1+128):
00000000  33 05 7e 23 20 21 7f 23  2e 31 7d 23 2c 41 7d 23  |3.~# !.#.1}#,A}#|
00000010  2a 51 7d 23 28 61 7d 23  26 71 7d 23 24 81 7d 23  |*Q}#(a}#&q}#$.}#|
00000020  22 91 7d 23 20 a1 7d 23  2e b1 7b 05 65 13 05 05  |".}# .}#..{.e...|
00000030  cb 33 01 a1 40 37 05 00  ff 83 25 05 08 ae d8 83  |.3..@7....%.....|
00000040  25 45 08 ae da 83 25 85  08 ae dc 83 25 c5 08 ae  |%E....%.....%...|
00000050  de 83 25 05 09 2e c1 83  25 45 09 2e c3 83 25 85  |..%.....%E....%.|
00000060  09 2e c5 03 25 c5 09 2a  c7 37 e5 09 6a 13 05 75  |....%..*.7..j..u|
00000070  66 aa cb 37 d5 bc f3 13  05 85 90 aa c9 37 b5 67  |f..7.........7.g|
00000080  bb                                                |.|
QUEUE after send ID:1: [0 1] (nsent:127 offset:127 binlen:27656)
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0 1]
LoadAppData tx (frame len: 1+128):
00000000  53 05 13 05 55 e8 aa cf  37 a5 ca 84 13 05 b5 73  |S...U...7......s|
00000010  aa cd 37 f5 6e 3c 13 05  25 37 aa d3 37 05 95 fe  |..7.n<..%7..7...|
00000020  13 05 b5 82 aa d1 37 f5  4f a5 13 05 a5 53 aa d7  |......7.O....S..|
00000030  37 35 1d 5f 13 05 15 6f  aa d5 37 55 0e 51 13 05  |75._...o..7U.Q..|
00000040  f5 27 aa db 37 85 e6 ad  13 05 15 2d aa d9 37 75  |.'..7......-..7u|
00000050  05 9b 13 05 c5 88 aa df  37 75 3e 2b 13 05 f5 c1  |........7u>+....|
00000060  aa dd 37 e5 83 1f 13 05  b5 9a 23 22 a1 10 37 c5  |..7.......#"..7.|
00000070  41 fb 13 05 b5 d6 23 20  a1 10 37 d5 e0 5b 13 05  |A.....# ..7..[..|
00000080  95                                                |.|
QUEUE after send ID:2: [0 1 2] (nsent:127 offset:254 binlen:27656)
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0 1 2]
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0 1 2]
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0 1 2]
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0 1 2]
LoadAppData rx (expectedID:0) (frame len: 1+4):
00000000  11 06 00 00 00                                    |.....|
QUEUE after recv: [1 2]
LoadAppData tx (frame len: 1+128):
00000000  73 05 08 6d f2 fd 15 e5  fd 13 45 15 00 e5 b7 13  |s..m......E.....|
00000010  fc 34 00 13 15 2c 00 4e  95 00 41 05 65 13 05 05  |.4...,.N..A.e...|
00000020  15 0a 95 13 06 00 08 81  45 97 60 00 00 e7 80 a0  |........E.`.....|
00000030  d5 01 45 83 a5 0d 08 f5  dd 83 a5 4d 08 33 06 ad  |..E........M.3..|
00000040  00 05 05 23 00 b6 00 e3  16 85 fe 93 f5 84 01 01  |...#............|
00000050  45 e3 92 75 fb 13 d5 54  00 93 7c 35 00 05 65 13  |E..u...T..|5..e.|
00000060  05 05 0d 0a 95 13 06 00  08 81 45 97 60 00 00 e7  |..........E.`...|
00000070  80 80 d1 05 65 13 05 05  15 0a 95 03 45 05 00 7d  |....e.......E..}|
00000080  15                                                |.|
QUEUE after send ID:3: [1 2 3] (nsent:127 offset:889 binlen:27656)
LoadAppData rx (expectedID:1): no data
no frame to read yet
QUEUE: [1 2 3]
LoadAppData rx (expectedID:1): no data
no frame to read yet
QUEUE: [1 2 3]
LoadAppData rx (expectedID:1): no data
no frame to read yet
QUEUE: [1 2 3]
LoadAppData rx (expectedID:1): no data
no frame to read yet
QUEUE: [1 2 3]
LoadAppData rx (expectedID:1) (frame len: 1+4):
00000000  31 06 00 00 00                                    |1....|
QUEUE after recv: [2 3]
LoadAppData tx (frame len: 1+128):
00000000  13 05 86 00 d5 8d c2 05  4d 8d 85 65 93 85 45 0d  |........M..e..E.|
00000010  8a 95 88 c1 05 65 13 05  15 1d 0a 95 03 45 05 00  |.....e.......E..|
00000020  85 65 93 85 05 1d 8a 95  83 c5 05 00 05 66 13 06  |.e...........f..|
00000030  36 1d 0a 96 03 46 06 00  85 66 93 86 26 1d 8a 96  |6....F...f..&...|
00000040  83 c6 06 00 22 05 4d 8d  93 15 86 00 d5 8d c2 05  |....".M.........|
00000050  4d 8d 85 65 93 85 05 0d  8a 95 88 c1 13 95 5c 00  |M..e..........\.|
00000060  83 a5 0d 10 f5 dd 13 65  b5 01 93 85 4d 10 88 c1  |.......e....M...|
00000070  93 06 f0 07 03 a5 0d 10  75 dd 01 45 89 45 23 a2  |........u..E.E#.|
00000080  bd                                                |.|
QUEUE after send ID:0: [2 3 0] (nsent:127 offset:1524 binlen:27656)
LoadAppData rx (expectedID:2): no data
no frame to read yet
QUEUE: [2 3 0]
LoadAppData rx (expectedID:2): no data
no frame to read yet
QUEUE: [2 3 0]
LoadAppData rx (expectedID:2): no data
no frame to read yet
QUEUE: [2 3 0]
LoadAppData rx (expectedID:2) (frame len: 1+4):
00000000  51 06 00 00 00                                    |Q....|
QUEUE after recv: [3 0]
LoadAppData tx (frame len: 1+128):
00000000  33 05 0d 10 75 dd 81 45  01 45 31 46 23 a2 cd 10  |3...u..E.E1F#...|
00000010  03 a6 0d 10 75 de 93 f5  f5 0f 05 05 23 a2 bd 10  |....u.......#...|
00000020  63 07 25 01 b3 85 aa 00  83 c5 05 00 d5 b7 81 4c  |c.%............L|
00000030  2d be 13 95 5c 00 83 a5  0d 10 f5 dd 13 65 85 01  |-...\........e..|
00000040  93 85 4d 10 88 c1 03 a5  0d 10 75 dd 81 4c 13 05  |..M.......u..L..|
00000050  f0 0f 23 a2 ad 10 11 be  09 45 63 1e ac 18 05 65  |..#......Ec....e|
00000060  13 05 25 15 0a 95 03 45  05 00 85 65 93 85 15 15  |..%....E...e....|
00000070  8a 95 83 c5 05 00 05 66  13 06 36 15 0a 96 03 46  |.......f..6....F|
00000080  06                                                |.|
QUEUE after send ID:1: [3 0 1] (nsent:127 offset:2032 binlen:27656)
LoadAppData rx (expectedID:3): no data
no frame to read yet
QUEUE: [3 0 1]
LoadAppData rx (expectedID:3): no data
no frame to read yet
QUEUE: [3 0 1]
LoadAppData rx (expectedID:3): no data
no frame to read yet
QUEUE: [3 0 1]
LoadAppData rx (expectedID:3) (frame len: 1+4):
00000000  71 06 00 00 00                                    |q....|
QUEUE after recv: [0 1]
LoadAppData tx (frame len: 1+128):
00000000  53 05 8a 95 23 80 a5 00  13 95 5c 00 83 a5 0d 10  |S...#.....\.....|
00000010  f5 dd 93 65 95 01 13 85  4d 10 0c c1 83 a5 0d 10  |...e....M.......|
00000020  f5 dd 91 45 0c c1 03 a5  0d 10 75 dd 05 45 23 a2  |...E......u..E#.|
00000030  ad 10 05 65 13 05 15 0d  0a 95 03 45 05 00 83 a5  |...e.......E....|
00000040  0d 10 f5 dd 23 a2 ad 10  05 65 13 05 25 0d 0a 95  |....#....e..%...|
00000050  03 45 05 00 83 a5 0d 10  f5 dd 81 4c 23 a2 ad 10  |.E.........L#...|
00000060  39 b2 13 05 f0 07 46 44  22 8c 63 64 a4 00 13 0c  |9.....FD".cd....|
00000070  f0 07 88 09 d6 45 2e 95  85 65 93 85 15 15 8a 95  |.....E...e......|
00000080  62                                                |b|
QUEUE after send ID:2: [0 1 2] (nsent:127 offset:2540 binlen:27656)
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0 1 2]
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0 1 2]
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0 1 2]
LoadAppData rx (expectedID:0): no data
no frame to read yet
QUEUE: [0 1 2]
LoadAppData rx (expectedID:0) (frame len: 1+4):
00000000  11 11 00 00 00                                    |.....|
LoadApp: receiveRspLoadAppData: ReadFrame: Expected cmd code 0x6 (rspLoadAppData), got 0x11

Break out Go packages

Break out our two Go packages to their own repos:

• tk1
• tk1sign

Add Windows support to tkey-ssh-agent

Add Windows suport to the SSH agent for use with Microsoft's port of OpenSSH.

#73

A generic encryption TKey app

Write a generic encryption TKey app. It should be able to receive a message (or series of messages) and encrypt it with the CDI,

Such a TKey app can be used for many things, for instance the TOTP tillitis/tillitis#33

tkey-ssh-agent: documentation and flags

All flags should be documented in the man page, not just the help output.

Make sure flags don't overlap with other ssh-agent implementations, like OpenSSH:

-k      Kill the current agent (given by the SSH_AGENT_PID environment variable).

Signer app hangs if TK1 stops communicating

During ESD stress testing, if the device gets shocked while tkey-sign is running, there is some chance that it hangs at:

Sending a 128 bytes message for signing.
WARNING! This tkey-sign and signer app is built with the touch requirement removed

My guess is that the tkey fails to send 1 or more bytes as a response, and there could be a timeout on the serial read (or write) to catch this.

Move runsign.sh to sign-related subdir

Cloning a clean repo, the root contains the 'runsign' shell script, but no other app specific scripts. When building the root gets populated with several programs (inclding scripts). If order to keep the repo "app agnostic" I suggest moving the runsign script to s subdir related to the signer app. During build it can be copied back.

Break out ssh-agent

Make tkey-ssh-agent standalone in its own repo.

Probably rename -apps to tkey-ssh-agent to keep the stars for Homebrew.

Use with gpg-agent / scdaemon

Hi, is there currently a way to use any of the apps with gpg-agent or scdaemon, or would that need a new app written?

runsign.sh: add --help flag

Print Usage: information also when --help flag (or even -h) is used.

Statically link host apps for broader compatibility

The apps require a newer version of go than is available in more conservative distros, such as Debian Bullseye. If I specify 'CGO_ENABLED=0' while building the host applications using the Docker environment, I'm able to build statically linked versions of the apps that will then run natively in Debian.

I don't know if there are any major implications for doing this (besides slightly larger file sizes, of course), but it might help with distribution.

Question: Why use `RM=/bin/rm` in certain places and not others?

Distros that don't follow the FHS like NixOS or Guix have issues running make clean as it currently is.
If there's no real reason to for using RM=/bin/rm, it would be nice to avoid referring to /bin.
Also confusing is that there are a few scripts that don't follow the same convention.

Makefiles seem to use RM=/bin/rm:
https://github.com/tillitis/tillitis-key1-apps/blob/2261f0c9a156e43246dff29c033ece5e6d3ec161/Makefile#L1
https://github.com/tillitis/tillitis-key1-apps/blob/2261f0c9a156e43246dff29c033ece5e6d3ec161/apps/Makefile#L27

Shell scripts seem to use rm:
https://github.com/tillitis/tillitis-key1-apps/blob/2261f0c9a156e43246dff29c033ece5e6d3ec161/debian/build-pkg.sh#L23
https://github.com/tillitis/tillitis-key1-apps/blob/2261f0c9a156e43246dff29c033ece5e6d3ec161/test/attic/test-loop.sh#L41
https://github.com/tillitis/tillitis-key1-apps/blob/2261f0c9a156e43246dff29c033ece5e6d3ec161/test/run#L23

Update build instructions with new dependency on Go

The build instructions in the README talks about C, clang, llvm, as dependencies needed to build. And the actual build instruction is to run 'make'. Running make on a Ubuntu machine with clang-14:

´´´
go build ./cmd/runapp
go: cannot find GOROOT directory: /libexec
make: *** [Makefile:11: runapp] Error 2
´´´

There now seems to be a dependency on Go. The instructions should be updated to inform about this.

tk-ssh-agent usability

There is a lot consider and to do for usability.

• how can it handle TK1 being unplugged at any time. Would the agent pinging the TK1 continuously be of any help?
  • if we manage to handle unplugging gracefully (whatever that means exactly), then there is also reconnection, or what? in the case of trying reconnection, should tk-ssh-agent perhaps be locked to the TK1 UDI that it originally was started for...
  • maybe the agent should not remain connected to serial port, but connect when it needs to do something! (and on startup prob). have to think how this would interact with auto-detect of port and attempts to start other agents. also, should it possibly only accept to use the USB device with serial X and UDI Y which it found on startup? (and how would that work with QEMU..?)
    • this would indeed avoid the device getting exclusively locked...
    • remember that for example an ssh login does first List() and then Sign() through that api; perhaps opening and closing the serial port on both those operations takes time...
• so when tk-ssh-agent has opened the serial port path, nobody else can. Probably good in some sense, but at some point we might find out that we could use some IPC to talk to a running tk-ssh-agent, to retrieve something from the TK1. Maybe not, just dropping the idea here.
• autodetecting the serial port /dev-path. should be possible, since vendor and product IDs (or so) are known. There is a gousb package which uses libusb under the hood (cgo), and it is said to work at least also on Macos. Had quick look, but I did not understand if the actual serial port path could really be discovered by gousb (it its current shape)
  • another way could be to make installation of tk-ssh-agent set up udev-rules to make the /dev-port predefined, like /dev/tillitiskeyX. Could be possible? Maybe even harder to accomplish on things other than Linux though.
  • another option could be to probe the devices listed by GetPortsList() of our go.bug.st/serial pkg. Not so nice perhaps, and what it outputs on non-Linux is unknown to me. There is also a detailed list, which can filter on vedor/prod ID! https://pkg.go.dev/go.bug.st/serial#section-documentation
• Generally related: the (ssh) agent.ExtentendedAgent go interface that is implemented has Add/Remove/RemoveAll/Lock/Unlock/Signers which just returns ErrNotImplemented. Most of that makes sense, but would it make sense to do something on RemoveAll, like hm stop the agent? Also I don't know what Signers() actually is for.

windows: getting "access denied" notification if named pipe already exists

A moderator of the winget community pkgs helpfully gave this comment about running tkey-ssh-agent. They wrote In a VM without the USB key, it gives this message: and posted a screenshot of a notification from tkey-ssh-agent that reads tkey-ssh-agent | Could not create listener: ListenPipe: open \\.\pipe\tkey-ssh-agent: Access is denied. (microsoft/winget-pkgs#103026 (comment))

The TKey USB not being plugged in really should not matter, we don't even try to connect to it until tkey-ssh-agent is asked for some action. We did not run into this ourselves during our testing on Windows 11 running in QEMU, and on Windows 10 on hardware.

Could there be some setup where user running the agent does not have permission to create a named pipe? And does that have any relation to our SecurityDescriptor setup in listen_windows.go?

One thing though, this is the exact message one gets when trying to run a second tkey-ssh-agent that tries to create the same Named Pipe as the first. Could you have happaned to do that @stephengillie

CI

At least do a complete build and yell if anything fails.