U2F authentication support

[Antoine Martin]

See also smartcard API #1255.

[Antoine Martin]

Initial support added in r18801.

To use it:

• register a key for the "Xpra" service by running:

  ./xpra/server/auth/u2f_auth.py
  

It will print the public key and the key handle, both need to be preserved.
The public key is stored on the server, the key handle is used on the client to tell libu2f which key to use for authentication.

• start the server with the public key:

  xpra start --start-child="xterm" --bind-tcp=0.0.0.0:10000 -d auth \
      --tcp-auth=u2f,public_key=041438f9c6cb2b6dec3a86e3b9eb7afe77112c817a371a9b0b74988619cf5f5b06b8211a4082818940de564aca8ac7dfecf34d23187b42340a261891c637cba794 
  

• run the client with the matching key signature:

  XPRA_U2F_KEY_HANDLE=ebecec9d7665dec1e1c6261ede6ad7ba2556a07be705c4bff399b3acf37e00a6e82b26ebbb759418be22fa8bbbec6ac1c0007257d23550e63fdbf2853259499e \
      xpra attach tcp://localhost:10000 -d auth
  

And activate the U2F key when requested (ie: when it blinks).

Still TODO:

• package ​pyu2f?
• build and test on macos and win32
• support loading the public key per user so it can be used with the proxy (ie: ~/.xpra/u2f.hex?) and maybe support other key storage formats than hex?
• better way to specify the key handle on the client, per server? (also from file)

There are other libraries we can use to interface with u2f, but they're not as nice, ie: ​python-u2flib-host.

[Antoine Martin]

example of all in one registration + authentication using pyu2f

[Antoine Martin]

alternative example using u2flib_host

[Antoine Martin]

Updates:

• macos and rpm packaging: r18802, r18813
• macos bundling: r18808 (+r18839 for python2 builds)
• win32 packaging: r18807
• minor fixups: r18803 + r18804, r18805, r18806, r18817, r18818
• better debug logging: r18811, r18812
• load key signature and public key(s) from files: r18815
• utility script / GUI for registering and creating those files: r18816

Although we still support environment variables for specifying the key-handle and the public key, the preferred way is to store them as hexadecimal files in the application's user configuration directory (ie: .xpra on posix).
Running the new browser/xpra/trunk/src/xpra/client/gtk_base/u2f_tool.py will create two files there:

• u2f-keyhandle.hex containing the key handle used by the client for talking to the U2F device. This file may be renamed to u2f-keyhandle-HOSTNAME.hex (ie: u2f-keyhandle-example.com.hex which will be used when connecting to example.com server only, ie: xpra attach ssh://example.com/) - note: we only try the first valid key handle we find.
• u2f-pub.hex which contains the public key matching the key handle. This file can be renamed (ie: u2f-pub-myusername.hex) and the server will try to load every file matching u2f-pub*.hex, accepting the authentication as soon as one public key validates the signature successfully)

---

Testing locally with an $18 ​FIDO U2F Security Key:

• run the u2f_tool
• start the server:

  xpra start --start-child="xterm" --bind-tcp=0.0.0.0:10000 --tcp-auth=u2f -d auth
  

• connect with the client (activating the U2F device when requested, ie: when it blinks):

  xpra attach tcp://127.0.0.1:10000 -d auth
  

To test using a remote client machine (ie: already tested with a linux, win32 and macos as both clients and servers):

• run the u2f_tool on the new client system,
• copy the resulting u2f-pub.hex to the user configuration directory on the server (ie: ~/.xpra)
• attach (and again, activate when requested)

---

Future enhancements:

• we should verify the counter for each key (hard: need to store it on the server filesystem), see ​U2Fishing
• store / read the keys from ~/.config/Yubico/u2f_keys like ​pam-u2f does?
• support the global Central authorization mapping?
• store the key-handle with the public key? (then the server could tell the user which key-handles to try)