What technologies will help make a secure data transmission channel?

Question

Information Security

Good afternoon. I want to assemble two devices on microcontrollers and organize a secure communication channel between them. Speed ​​is of little importance. data volumes are small: something like a burglar alarm on a car and a remote control for it. The criteria are:

• The data inside the channel must be encrypted (logically)
  
• The connection is maintained only for the duration of the data transfer.
  
• Devices should be able to verify that they are communicating with each other and not with another device (something like SSL Pinning)
  
• The system must be protected from resending packets (if the 3rd party decides to resend one of the device packets, then it should not result in a re-execution of the command).
  
• The operations performed should more or less fit into the resources of microcontrollers
  

I imagine this as a kind of exchange of packets containing, in addition to the payload, a "fingerprint" of the device's unique key and a packet counter in this communication session and a session number (so that packets with the same load always differ), but most likely this was already invented before me, and I I don't know what exactly I should be looking for. Question: in what direction should I dig in order to study the available technologies in this area (what is closest to my topic)

Answer 1

TLS is used for this. This is a special protocol that solves all the issues that you want to solve. There is the possibility of encryption, mutual authentication of both the client and the server, and all that. Cons - computationally difficult. That is, on weak microcontrollers, the process of establishing a TLS session can take time, plus battery consumption. Pluses - there are already ready-made libs for many platforms / architectures that can be used so as not to reinvent the wheel and write your own.
The replay attack guarantee is achieved by the fact that in order to send a command, the parties need to authenticate, i.e. it is always a two-way exchange. Technically, the parties first exchange certificates, verify them, then, based on the Diffie-Hellman algorithm, they form a symmetric encryption key that will be used to encrypt the data stream. In general, this key will be different in each session. There are caching and state saving mechanisms to speed up the establishment of a TLS session (for example, in case the client has already connected recently - this is necessary to increase the speed of negotiating a TLS connection), but this is all optional and disabled.
You can put anything inside TLS - a custom binary protocol based on TCP / IP or REST API based on HTTP - it doesn't matter.

Answer 2

The connection is maintained only for the duration of the data transfer.

Not optimal. If the parties pass strong authentication, then it takes time and resources. It's easier to make a persistent connection supported by ping-type packets. And in order to periodically verify that the parties are still who they say they are, periodically break the connection.
This is the work of the application layer
. As for the rest - you are talking about IPSec, absolutely unequivocally :) I don't know, really, what about the resource of the microcontroller.

Answer 3

Trite:
Add a signature to the request with the time and a random set of characters.
On the device side - prohibit repeated requests for 10 years.
Bottom line: even knowing what you sent, you can’t use it in any way.
If you want to encrypt the "body" of the request itself (so that they don't read it) - encrypt it in any way (the main thing is - do not use session TOKEN for encryption! ).
Here in detail.