Stronger authentication support in Windows

[tmclean-feith]

When working with Windows environments the connector endpoint can be secured with TLS, however this provides little in the way of useful authentication, authorization, or auditing. The only authentication supported is the authentication key provided via the shell application or via the Windows registry (in cleartext) when using the KSP.

It looks like one can specify client certificate authentication for Linux environments when using the pkcs11 module. It would be useful to have a similar form of strong authentication in Windows environments, such as Client Certificate (mTLS) or Kerberos authentication. Ideally this would work in both the shell application as well as the KSP.

[qpernil]

Mutual authentication with HTTPS only occurs if the server requires client certificates. yubihsm-connector itself has no support for requiring client certificates, so if this is desired then one must use some kind of reverse proxy, such as nginx, in front of the connector. If that is the case the curl-based http(s) client used in the client library used by yubihsm-shell and yubihsm-pkcs11 supports specifying client certificates to use if requested by the server. Again, note that the mutual authentication is triggered by the server (the reverse proxy in this case), not by providing these settings on the client. The windows client library uses WinHttp, the built-in http client library of Windows itself. As such it may support using client certificates configured in Windows, but no direct support is provided by the yubihsm client libraries on Windows.

It should also be noted that authentication by a proxy is not end-to-end, as it terminates in the proxy. The proxy is however not part of the trusted environment as the HSM uses a cryptographic protocol end-to-end between the client library and the HSM itself. Unlike TLS this protocol always performs mutual authentication. This protocol requires each party to have a pair of symmetric keys, which are then used to generate unique session keys for each session that is established. In the current release the client keys are derived from the password provided to the libraries, but future releases may support other means of providing the keys, such as using CryptoApi on Windows etc.

[qpernil]

All of the the above being said, it is not unreasonable to implement https with client certificates support in the WinHttp backend, something that at first glance looks doable. Im putting that in as a feature request. Thx.