Let's say I'm designing a communications protocol that will be used by many pairs of devices to communicate amongst each other (between the pairs only).

Assuming the devices in the pair can communicate with each other in a cryptographically secure way using, for example, digital signatures, and at least one is occasionally connected to the internet, how would you:

  • issue new keys (either between the devices, or from a centralized source)?
  • reliably fall back and maintain communication if something happens during the key issue process?

The main requirements are:

  1. In a pair of devices A, B, only A and B can communicate with each other; an adversary must not be able to know how to talk to B or A by observing the communications between them.
  2. Such a protocol should be able to be open sourced with no loss in security.
  3. At least one of the systems must be able to be operated by a human, even if the underlying code that runs these systems is opaque to the operator.

Here's the problems I see:

  1. Having centralized control of key management adds a single point of failure; access this service and the whole thing collapses
  2. These systems must be operated by people, so access to the keys could be feasible
  3. If for some reason a cryptographic problem is detected, the systems are unusable, and must (somehow?) be securely updated with new keys, but lack a basis of trust.
  4. Physical security of the system operated by the human is paramount.

How would you manage the keys in this situation?

  • $\begingroup$ Why doesn't a standard solution such as TLS address your problem? $\endgroup$
    – poncho
    Commented Dec 15, 2021 at 15:19
  • $\begingroup$ Ah, that's a great point! A and B are not connected by a network, they're connected by a serial cable (SPI/CAN/RS232 etc) $\endgroup$ Commented Dec 15, 2021 at 15:29
  • 2
    $\begingroup$ TLS can operate over a serial cable - you need to have some reliable transport (to serve the place of TCP), but that's not difficult. Alternatively, you can use DTLS (which doesn't need reliability - however implementations aren't quite as well-vetted) $\endgroup$
    – poncho
    Commented Dec 15, 2021 at 16:01
  • 1
    $\begingroup$ If you use something like Point-to-Point Protocol (PPP) to connect nodes you could run TLS and TCP/IP over PPP. $\endgroup$ Commented Dec 15, 2021 at 16:25
  • $\begingroup$ Does TLS handle key/cert rotation and management automatically? $\endgroup$ Commented Dec 15, 2021 at 16:41

1 Answer 1


As I can think you have to look at key consolidation protocols to get more info that may help you to build your protocol.

Modern key consolidation protocols contain additional amounts of information, which help to counteract the active attacks of the adversary.

Some of these quantities are:

-Timestamp. The time stamp consists of the date, time, minutes, seconds and in some cases tens or centimeters of a second and expresses the time when a protocol action is performed, which can be some (cryptographic) operation or transmission of information. The time stamp in practice requires a trusted time stamp server, which serves time stamp requests.

-Nonce. The unique number often replaces the time stamp and is a random number that does not appear in a future execution of the protocol and gives uniqueness to the messages that are exchanged. It is important that this number is not predictable by the opponent. The unique number is included in the cryptographic operations and thus binds cryptographically to the corresponding messages, resulting in reduced degrees of freedom of action of the opponent.

Some reasons for consolidating session keys are:

  1. Limiting the amount of encrypted material that can be used for cryptanalysis.
  2. Restriction of the consequences of disclosure or unauthorised access to cryptographic keys.
  3. The need to store many cryptographic keys for a long time.
  4. Independence between communication sessions and between web applications / services.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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