tillitis / tkey-ssh-agent

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

TKey SSH Agent

tkey-ssh-agent is an OpenSSH-compatible agent for use with the Tillitis TKey USB security token.

Warning: Please use tagged releases for any real use. Development on main might mean we change which version of the the signer device app we use which would cause the SSH key pair to change!

See Release notes.

Installing

tkey-ssh-agent might be available in your operating system's package system.

If not, see Tillitis' application page for the agent as well as instructions.

If there's no official package for your system the easiest way to install is probably to:

$ go install github.com/tillitis/tkey-ssh-agent/cmd/tkey-ssh-agent@latest

After this the tkey-ssh-agent command should be available in your $GOBIN directory.

Note that installing with go install doesn't set the version like building with other methods does. See building the agent below.

You will also have to install these manually if you use go install:

• Manual page system/tkey-ssh-agent.1.
• udev rules, see system/60-tkey.rules (Linux).
• systemd service unit, see system/tkey-ssh-agent.service.tmpl and change ##BINDIR## to where you installed tkey-ssh-agent (some Linux dists).

If you're building from source (see below) there is a make install target that installs the agent and the udev rules. Please see Makefile to see that everything ends up where you want to. Typically you will have to do:

$ sudo make install
$ sudo make reload-rules

Using tkey-ssh-agent

tkey-ssh-agent tries to auto-detect the TKey. If more than one is found, or if you're running on QEMU, then you'll need to use the --port flag:

$ ./tkey-ssh-agent -a ./agent.sock --port /dev/pts/1

This will start the SSH agent and tell it to listen on the specified socket ./agent.sock.

Nota bene: If the signer app binary, the USS, or the UDS in the physical USB stick change your key pair will change.

If you copy-paste the public key into your ~/.ssh/authorized_keys you can try to log onto your local computer (if sshd is running there). The socket path set/output above is also needed by SSH in SSH_AUTH_SOCK:

$ SSH_AUTH_SOCK=/path/to/agent.sock ssh -F /dev/null localhost

-F /dev/null is used to ignore your ~/.ssh/config which could interfere with this test.

The tkey-ssh-agent also supports the --uss and --uss-file flags to enter a User Supplied Secret.

You can use --show-pubkey (short flag: -p) to only output the pubkey. The pubkey is printed to stdout for easy redirection, but some messages are still present on stderr.

Building the agent

If you have Go and make installed, a simple:

$ make

or, for a Windows executable,

$ make tkey-ssh-agent.exe

should build the agent. A pre-compiled signer device app binary is included in the repo and will be automatically embedded.

Cross compiling the usual Go way with GOOS and GOARCH environment variables works for most targets but currently doesn't work for GOOS=darwin since the go.bug.st/serial package relies on macOS shared libraries for port enumeration.

Building agent with tkey-builder

If you want to use our tkey-builder image and you have make you can run:

$ podman pull ghcr.io/tillitis/tkey-builder:4
$ make podman

or run it directly with Podman:

$ podman run --rm --mount type=bind,source=$(CURDIR),target=/src --mount type=bind,source=$(CURDIR)/../tkey-libs,target=/tkey-libs -w /src -it ghcr.io/tillitis/tkey-builder:4 make -j

Note that building with Podman like this by default creates a Linux binary. Set GOOS and GOARCH with -e in the call to podman run to desired target. Again, this won't work with a macOS target.

Building with another signer

For convenience, and to be able to support go install, a precompiled signer device app binary is included under cmd/tkey-ssh-agent.

If you want to replace the signer used by the agent you have to:

1. Compile your own signer and place it in the cmd/tkey-ssh-agent directory.
2. Change the path to the embedded signer in cmd/tkey-ssh-agent/signer.go. Look for go:embed....
3. Change the appName directly under the go:embed to whatever your signer is called so the agent reports this correctly with --version.
4. Compute a new SHA-512 hash digest for your binary, typically by something like sha512sum cmd/tkey-ssh-agent/signer.bin-v0.0.7 and put the resulting output in the file signer.bin.sha512 at the top level.
5. make in the top level.

Disabling touch requirement

The signer device app normally requires the TKey to be physically touched to make a signature. For special purposes it can be compiled without this requirement by setting the environment variable TKEY_SIGNER_APP_NO_TOUCH to some value when building. Example: make TKEY_SIGNER_APP_NO_TOUCH=yesplease.

Note well: You have to do this when building both the signer and the client apps. tkey-ssh-agent will also stop displaying notifications about touch if the variable is set.

Warning: Of course changing the code also changes the signer binary and as a consequence the SSH key pair will also change.

Building the signer

1. See the Devoloper Handbook for setup of development tools. We recommend you use tkey-builder.
2. See the instructions in the tkey-device-signer repo.
3. Copy its signer/app.bin to cmd/tkey-sign/signer.bin-${signer_version} and run make.

To help prevent unpleasant surprises we keep a digest of the signer in cmd/tkey-ssh-agent/signer.bin.sha512. The compilation will fail if this is not the expected binary. If you really intended to build with another signer, see Building with another signer above.

Windows support

tkey-ssh-agent can be built for Windows. The Makefile has a windows target that produces tkey-ssh-agent.exe and tkey-ssh-agent-tray.exe. The former is a regular command-line application, suitable for use in environments like PowerShell. The latter is a small application built for the windowsgui subsystem, meaning it operates without a console. Its primary function is to create a tray icon and initiate tkey-ssh-agent.exe with the identical arguments it received. They are assumed to be located in the same directory. For automatically starting the SSH agent when logging onto the computer, a shortcut to tkey-ssh-agent-tray.exe, with the required arguments, can be added in your user's Startup folder.

When using the --uss option the Windows build by default uses the pinentry program from Gpg4win for requesting the User-Supplied Secret. This package can be installed using: winget install GnuPG.Gpg4win.

The SSH Agent supports being used by the native OpenSSH client ssh.exe (part of Windows Optional Features and installable using winget). The environment variable SSH_AUTH_SOCK should be set to the complete path of the Named Pipe that tkey-ssh-agent listens on.

For example, if it is started using ./tkey-ssh-agent.exe -a tkey-ssh-agent the environment variable could be set for the current PowerShell like this:

$env:SSH_AUTH_SOCK = '\\.\pipe\tkey-ssh-agent'

Setting this environment variable persistently, for future PowerShell terminals, Visual Studio Code, and other programs can be done through the System Control Panel. Or using PowerShell:

[Environment]::SetEnvironmentVariable('SSH_AUTH_SOCK', '\\.\pipe\tkey-ssh-agent', 'User')

You can learn more about environment variables on Windows in Microsoft's article.

The SSH Agent can also be used with the Git-for-Windows client (winget install Git.Git). By default, it uses its own bundled ssh-client. Run the following PowerShell commands to make git.exe use the system's native ssh.exe:

$sshpath = (get-command ssh.exe).path -replace '\\','/'
git config --global core.sshCommand $sshpath
git config --global --get core.sshCommand

The last command should output something like C:/Windows/System32/OpenSSH/ssh.exe.

For details on how we package and build an MSI installer, see system/windows/README.md.

Licenses and SPDX tags

Unless otherwise noted, the project sources are licensed under the terms and conditions of the "GNU General Public License v2.0 only":

Copyright Tillitis AB.

These programs are free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2 only.

These programs are distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see:

https://www.gnu.org/licenses

See LICENSE for the full GPLv2-only license text.

External source code we have imported are isolated in their own directories. They may be released under other licenses. This is noted with a similar LICENSE file in every directory containing imported sources.

The project uses single-line references to Unique License Identifiers as defined by the Linux Foundation's SPDX project on its own source files, but not necessarily imported files. The line in each individual source file identifies the license applicable to that file.

The current set of valid, predefined SPDX identifiers can be found on the SPDX License List at:

https://spdx.org/licenses/

All contributors must adhere to the Developer Certificate of Origin.

tkey-ssh-agent's Issues

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

Linux: Document pinentry and Desktop Notifications

We need to document the assumptions behind running tkey-ssh-agent, and especially pinentry, on Linux systems better. The assumptions are:

• A working graphical pinentry
• A working Desktop Notification system

A working graphical pinentry typically means something like pinentry-gnome3 or pinentry-qt on most systems.

People who use GNOME or KDE or another full desktop are probably all set. People who use more lightweight systems with a minimal wm or a minimal Wayland compositor need to set things up themselves.

pinentry-gnome3 and Desktop Notifications typically also have dependencies on a working dbus session. If pinentry-gnome3 can't connect to the dbus session you get the dreaded:

No Gcr System Prompter available, falling back to curses

It wants to speak to gcr-prompter, which listens on the dbus.

When running, for instance, Sway or River this means you have to do something like

exec dbus-update-activation-environment --systemd WAYLAND_DISPLAY

in your config to get both pinentry-gnome3 and screen sharing working.

Note well: The agent tries to look in the user's gpg-agent.conf for what they want to use as a pinentry and tries to use that. This can be really confusing if they have something there that's old and isn't even installed on their system. Perhaps remove that functionality altogether? If they really want control they can set it with the --pinentry flag.

To check if you have a working graphical pinentry, first install something like pinentry-gnome3, then:

mcbacon4:~ % pinentry-gnome3 
OK Pleased to meet you
GETPIN

You should get a graphical window asking for something. I typed in "foo" and hit return.

D foo
OK

Theoretically something other than pinentry-gnome3 or pinentry-qt should work fine, but I haven't tested for instance pinentry-gtk2. Sadly, the minimalist pinentry-bemenu doesn't work. However, pinentry-emacs does! See the different implementations here:

git://git.gnupg.org/pinentry.git

Note well: If you just want to run the agent in the foreground and want it to ask for the USS in the same terminal, just call it with pinentry-curses:

% tkey-ssh-agent -p --uss --pinentry pinentry-curses

Use Goreleaser to build releases

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

The packages should be the same level as the debian-pkg we are shipping has today.
The goal is to have the same level for rpm, archlinux and alpine too.

Verify reproducible builds

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

CI

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

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.

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

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 ssh-agent

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

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

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.

[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.

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.

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.

Add Windows support to tkey-ssh-agent

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

#73

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! 🙏

Convert man page to scdoc

Instead of writing in complex mdoc, rewrite the man page as scdoc like we do with tkey-sign.

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 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.

Break out Go packages

Break out our two Go packages to their own repos:

• tk1
• tk1sign

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.

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.

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)

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

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.

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

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).

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

Handle if the socket exists when a service tries to start tkey-ssh-agent

Today tkey-ssh-agent creates a unix socket which is used to communicate with the ssh client.

If the tkey-ssh-agent is run in a service, and is not exited gracefully - the socket might not be removed properly. This prevents the service from starting again, since tkey-ssh-agent automatically fails if a socket already exists with the same path. This forces the user to manually remove the existing socket, before the service will start again.

Building MSI package in CI fails

Tried to get the MSI package to build in CI, but stops due to an error:
This works on a local Ubuntu 22.10 using our OCI image msi-builder, but not in GH Actions..

Branch build_msi

Run mkdir ~/.wine
  mkdir ~/.wine
  ./build-msi.sh 0.0.6 tkey-ssh-agent.wxs
  shell: sh -e {0}
Going to build: 0.0.6.0
002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0048:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0050:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0048:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0048:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
0048:err:systray:initialize_systray Could not create tray window
0048:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002
0048:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
0048:err:ole:apartment_get_local_server_stream Failed: 0x80004002
002c:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
002c:err:winediag:nodrv_CreateWindow L"Make sure that your X server is running and that $DISPLAY is set correctly."
0050:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0050:err:winediag:nodrv_CreateWindow L"Make sure that your X server is running and that $DISPLAY is set correctly."
0050:err:ole:apartment_createwindowifneeded CreateWindow failed with error 3
0050:err:ole:apartment_createwindowifneeded CreateWindow failed with error 0
0050:err:ole:apartment_createwindowifneeded CreateWindow failed with error 14007
0050:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x800736b7
0050:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x800736b7
0050:err:ole:apartment_get_local_server_stream Failed: 0x800736b7
0050:err:ole:start_rpcss Failed to open RpcSs service
0040:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0040:err:winediag:nodrv_CreateWindow L"Make sure that your X server is running and that $DISPLAY is set correctly."
008c:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
008c:err:winediag:nodrv_CreateWindow L"Make sure that your X server is running and that $DISPLAY is set correctly."
0094:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0094:err:winediag:nodrv_CreateWindow L"Make sure that your X server is running and that $DISPLAY is set correctly."
00f0:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
wine: configuration in L"/github/home/.wine" has been updated.
00f0:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
00f0:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
00f0:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0024:fixme:mscoree:parse_startup useLegacyV2RuntimeActivationPolicy=L"true" not implemented
0024:fixme:mscoree:parse_startup useLegacyV2RuntimeActivationPolicy=L"true" not implemented
0024:err:mscoree:CLRRuntimeInfo_GetRuntimeHost Wine Mono is not installed
Error: Process completed with exit code 255.

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.

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

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

[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).

runsign.sh: add --help flag

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

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.

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.

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.

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

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

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?

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?