0

Update: original problem description

I am developing a client-server system for configuration updates. The system handles update tasks. An update task is initiated on a server; multiple clients then need to connect to the server to negotiate their updates within this task. A task can be initiated either manually of programmatically, and can be done either via CLI or via REST interface.

The requirements:

  • It should be absolutely easy for the end user to do those tasks;
  • Connections between clients and server should be secure, in the sense of that the whole communication should be authenticated, encrypted, protected against violations of message integrity or any other attacks, such as replays.

I will appreciate any suggestions to solve this task simply and efficiently.

The solution I have in mind currently is to generate a PSK on a server, and use then this PSK on the clients for connections. For that I have developed a symmetric key protocol that will mutually authenticate and establish a new short-living session key between two parties that have a pre-shared key. Unfortunately, I have not found any existing protocol that would fit my purposes, so I quickly devised my own. Would greatly appreciate your feedback on the protocol, or otherwise any advice to find something that already exists.

Notation:

C         = Client
S         = Server
K         = pre-shared key between C and S
ENC(K, m) = message m encrypted with key K; encryption function is AES-256-CBC
MAC(K, m) = a message-authentication code of message m, computed using key K
rnd       = random value
c1        = client challenge (randomly generated by the client)
c2        = server challenge (randomly generated by the server)
K'        = short-living session key

The protocol:

C -> S : em = ENC(K, (rnd, c1)), MAC(K, em)
S -> C : em = ENC(K, (c2,  c1)), MAC(K, em)
C -> S : em = ENC(K, (c1,  c2)), MAC(K, em)

Further session messages are encrypted with session key K' = c1 + K + c2:

* -> * : em = ENC(K', m), MAC(K', em)

Thanks a lot for your help!

Update: Rationale for using PSK instead of private/public keys. Simplicity of usage. A tool is run on a server, and generates a unique PSK automatically, which the user then needs to manually or programmatically transfer to the clients he wants to connect. For the user this is much easier than using public-key cryptography.

Update: Rationale for having session keys in addition to PSK. In the system I am working on, A PSK establishes a limited-time trust between a server and multiple clients. The underlying protocol is for configuration management, and there should be a protection against replay attacks. IF I were just to use the same PSK to encrypt different sessions, THEN it could be possible, as far as I see, just to record and then replay a session to achieve another (unauthorized) configuration update, which would be bad. Usage of session keys precludes this scenario.

  • 1
    Can you explain your rationale, why you want to have session keys, when you already have a pre-shared key? What do you believe would be the added value? – Euphrasius von der Hummelwiese Feb 22 at 13:10
  • 3
    Doesn't TLS with PSK authentication provide what you need? – Steffen Ullrich Feb 22 at 13:19
  • 1
    @SteffenUllrich: How do you know the rationale Tim had in mind? I agree, that this might be an attempt to achieve PFS. However, as the proposed algorithm obviously does not provide PFS, I was wondering if he had something different in mind when considering this scheme. Therefore further explanation of his goal is probably required. – Euphrasius von der Hummelwiese Feb 22 at 13:28
  • 1
    @EuphrasiusvonderHummelwiese: I'm not sure this is the rationale Tim had but this is the usual rationale to have such a setup. I did not understand your comment specific to Tim but more general on why to create a shared key if one already has one. – Steffen Ullrich Feb 22 at 13:47
  • 1
    Thanks for the update. To defend against replay-attacks your scheme might work. However, none of us is a cryptographer, therefore I'd support the proposal of @SteffenUllrich to use some standard as TLS PSK. – Euphrasius von der Hummelwiese Feb 22 at 14:12
2

This might be better suited to Cryptography.stackexchange; you're violating a major rule of crypto here (don't roll your own! It applies to authentication and key exchange schemes just as much as to everything else) and that's where I'd go if I wanted amateur advice on cryptographic scheme design.

With that said, while I don't personally see any vulnerabilities in your scheme, I suspect you're reinventing the wheel a bit. I think you ought to do a lot more looking around for alternatives.

For example, Steffen Ullrich already mentioned TLS-PSK, which in addition to handling authentication and key exchange, also takes care of message integrity and authentication, session resumption, and all that good stuff. One of the dangers in designing your own cryptographic algorithm or protocol is that even if you get the "hard" part of it right, you end up needing to write other stuff (such as the actual message-handling) yourself as well, and that's a lot of opportunities to mess up the implementation or miss an important protection.

Another protocol that does what you want is SRP (Secure Remote Password), which is designed to prove to two endpoints (client and server, in your scenario) that both know the same password/key over an insecure network without ever exposing the key, and which produces a value usable as a temporary session key if the exchange succeeds. This protocol could be used by itself, but it would probably make more sense to use TLS-SRP, which uses SRP for mutual authentication and key exchange.

  • Thanks a lot for the elaborate answer! I will definitely look at the variants of TLS you and Steffen Ullrich pointed out. I will also re-ask the question at Cryptography.stackexchange -- just curious about the protocol... – Tim Feb 25 at 8:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.