1

Because of all the problems associated with "roll-your-own cryptography", I am looking for an existing standard for standalone authentication using asymmetric keys.

Scenario/threat model

Machine-to-machine connections between services. During a connection, the client (connection initiator) should be able to enable multiple privileges/capabilities by proving possession of the corresponding key for each.

End nodes will be preconfigured to trust incoming connections from the manufacturer, but the local administrator is able to modify the configuration of his own node. As a consequence (this is not necessarily a requirement) the local administrator can remove the manufacturer's public keys and replace them with his own. The local administrator must NOT be able to read any secrets that would allow him to impersonate the manufacturer to connect to endpoints elsewhere on the WAN. That's why asymmetric encryption is chosen rather than pre-shared keys.

As an unimportant detail, the actual connections are websockets. TLS will be provided for remote connections by a proxy server; there are also LAN connections within each installation to the same endpoint and for these the overhead of TLS is not desired. Also, management is easier if capabilities can be individually unlocked in sequence instead of predefining roles at the server endpoint. As well, some non-sensitive data needs to be transferred prior to the authentication step taking place.

MitM attacks and management of the private keys at the manufacturer node (including countermeasures such as key expiration and revocation) are out of scope.

Related concepts

I've researched these but none of seems to be a perfect fit:

  • SASL and particularly LDAP public-key authentication RFC 3163 -- perfect fit but apparently abandoned due to flaws
  • SCRAM RFC 5802 -- uses challenge response to avoid transmitting the shared secret, but still requires a preshared secret aka password
  • SSH RFC 4252 -- ideal authentication and key management but integrated with tunnel encryption
  • TLS RFC 4346, 5246, 8446 -- strong authentication but overly complex key management, and integrated with tunnel encryption

Also this page describes Encrypt-then-MAC as having better proofs of security properties than Encrypt&MAC or MAC-then-Encrypt, however I think this distinction likely doesn't apply to authentication that is layered separately from encryption.

Please recommend an existing design so I am not choosing nonce, padding, and hash iteration policies myself!

Even better if an implementation is included in the .NET Framework.

Ben Voigt
  • 760
  • 1
  • 10
  • 17

1 Answers1

1

This sounds like a fantastic place to use the noise protocol.

http://noiseprotocol.org/

It's free from some of the assumptions of TLS but provides similar security. What you seem to be looking for is the KK pattern, where both participants are authenticated by their pre-shared asymmetric keys.

https://noiseexplorer.com/patterns/KK/

But there are a lot more patterns and noiseexplorer is a cool tool, so feel free to look around.

There seems to be a .NET implementation but I am not here to attest to it's correctness.

https://github.com/Metalnem/noise

foreverska
  • 1,115
  • 11
  • Thanks, quite a bit of interesting reading there. I don't think I'll use it because like TLS it seems to be oriented around establishing a session key, rather than making new attestations for an existing session that may or may not be encrypted. – Ben Voigt Mar 17 '22 at 19:27
  • @BenVoigt Glad you found it interesting and thanks for the acceptance of my answer. You may have already run across this but a non-interactive pattern for attestation could be the K pattern. It does authenticate the sender (although weak to key compromise attacks). If the sender can construct a valid K message A it can be assumed they have access to the key. It is still primarily trying to establish a key for the underlying message but it is also proof of ownership of the asymmetric private. – foreverska Mar 17 '22 at 20:37
  • I guess I'm not explaining my use case well enough. It is on-line (interactive) but rather than being part of session establishment, it is used to unlock additional access mid-session. Think of "su" or "UAC elevation". That way not all clients have to deal with it, only the ones that need to send restricted commands. – Ben Voigt Mar 17 '22 at 20:58
  • My bad, when I said non-interactive I meant from the context of noise. Mid session one could say "Server, do restricted function 5, here's noise pattern K message A as proof I know the private key." That message A could even contain parameters of function 5 that one may not want public, if so desired. But construction of message A that contains "hello world" is enough to prove knowledge of the key either way. – foreverska Mar 17 '22 at 21:05