1

I have a simple client/server example up and running which uses client code and server code courteously provided by the OpenSSL team. I would like to add a feature to the client so that it attempts to run "privileged" commands. Some background:

  • When the tool is installed, some kind of key/token is installed on the system as well (token 1).
  • When the remote server wants to "push" data to the client, it requests a separate token (token 2), from a trusted authority (ie: separate off-site server), and sends token 2 to the client.
  • The client performs an operation on the two tokens, and if they "match" (ie: the two combined forms a valid key, one decrypts the other, or some similar mechanism), a temporary key is generated. The client needs this key to perform certain operations (ie: enter "manager mode" and do operations it wouldn't normally trigger).
  • The client may be asked by the server to re-create its security token (token #1') and re-submit its public key to the server.

The goal of the system is to give system administrators a narrow window where they can send special commands to the client by using a token which expires. Is there an existing mechanism (ie: within libssl) which could be used to accomplish what I've described above?

I think I could just implement this by doing essentially another key exchange over the already-encrypted TLS connection, but I'm not 100% sure if that's the ideal way to do this. The message I'd be sending would effectively be "MANAGER MODE AUTHORIZED" after the challenge completes. The client could be coded to exit manager mode after 5 minutes automatically. Is it really a safe test if the algorithm is effectively: "decrypt this, and if it says MANAGER MODE AUTHORIZED, proceed"?

Thank you.

jww
  • 97,681
  • 90
  • 411
  • 885
Marvin the Paranoid Android
  • 11
  • 2
  • 1
    The first part of what you describe sounds exactly like normal SSL server authentication via a certificate. I don't see the purpose of the extra session key. It doesn't add any security. – user207421 Sep 09 '16 at 02:14
  • @EJP I agree, it doesn't add any extra security in terms of the data being encrypted and kept away from unwanted viewers. I just need to have a secure means of generating a "session token" and knowing that it was authorized by a second trusted party. Ordinary users/employees can use the system, but if managers want to use it (ie: login and issue a sales return/refund, etc), they have to request a token (from a secondary server), and push it down to the client to authorize temporary access to "admin" functions. I figured something with libssl would be better than hardcoding a hash into my app. – Marvin the Paranoid Android Sep 09 '16 at 02:20
  • Just like a [Kerberos TGS session key](http://www.roguelynn.com/words/explain-like-im-5-kerberos/)? – bishop Sep 09 '16 at 19:30

0 Answers0