I'm developing a TCP Streaming API for "IoT" devices in LabView.

The TCP Server will be listening to a certain port, and our devices will try to connect to it. In order to know that the connecting client is from our company, all our servers and clients will share a private key and a password. When the client connects successfully to the socket, it will send the secret password cyphered in AES256 with the private key.

But what prevents an attacker from sniffing a client's credentials message and resend as it is to the server to gain access? Cyphering doesn't protect that.

  • 2
    You use TLS to prevent sniffing...
    – schroeder
    Jun 15 '20 at 9:14
  • Sorry, I cant integrate TLS into labview easily.
    – Héctor
    Jun 15 '20 at 10:58
  • 1
    The "s" in "IoT" stands for security ... Jun 15 '20 at 12:29

You could use a challenge-response mechanism. The server sends a random string, the client signs that using the private key. Since the server sends a new challenge every time, a replay attack won't work.

Or just use TLS to properly encrypt the connection. You could even use client certificates to replace your AES-encrypted secret password. TLS can provide both encryption and authentication, which seems to be what you are looking for. And another advantage is that you have to do a minimum amount of cryptography yourself, reducing the chance of implementation mistakes.

  • I can't integrate TLS in Labview easily so I think I will go for the challange-response mechanism. It is a solid way at least for a first version? Thank you so much. It could seam a silly question but is valuable and concise information for a beginner.
    – Héctor
    Jun 15 '20 at 10:57

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.