4

As explained in the TCP/IP Guide, it is possible to configure TCP/IP to operate in simplex mode and this mode is utilized, among other things, in communication from satellites.

One consideration with TCP/IP is however that, in itself, it "lacks even the most basic mechanisms for security, such as authentication or encryption", as explained in this article.

According to this other question, IPSec can be used to provide encryption for IP, but as can be read at Wikipedia, IPSec is used to establish mutual authentication and exchange of encryption keys.

Neither mutual authentication nor an exchange of keys should be possible in fully simplex mode (or maybe it is but I am missing something?).

Anyway, the question I wanted to ask is: if TCP/IP is actually ever operated in simplex mode, what are the options for encrypting the data?

Community
  • 1
coderworks
  • 519
  • 1
  • 4
  • 13
  • 1
    "TCP/IP"? Raw IP can work in simplex mode (as can UDP), but TCP cannot since you must send _and_ receive packets to perform a handshake. – user1686 Aug 26 '15 at 16:43
  • @grawity, a handshake is only needed when negotiating encryption. Neither TCP nor IP include mechanisms for encryption within themselves. They can be run in simplex mode (just like it's explained in The TCP/IP Guide) but any encryption cannot depend on a handshake. – coderworks Aug 26 '15 at 20:02
  • No, just because a "TCP/IP guide" describes general modes like simplex or duplex, doesn't automatically mean all of them apply to TCP or IP specifically. A handshake _is_ also needed when negotiating the TCP connection, and [a TCP connection](https://tools.ietf.org/html/rfc793#section-2.7) is [full-duplex](https://tools.ietf.org/html/rfc1122#page-82). /// ("Encryption cannot depend on handshake"? Well, handshake cannot depend on encryption either! There are _many other parameters_ that can be 'negotiated', not just keys.) – user1686 Aug 26 '15 at 20:13

2 Answers2

4

With one-directional communication the sender must have least some knowledge of the recipient so that the data can be encrypted. This knowledge might be a common pre-shared secret which is used in symmetric communication or it might be the public key like used in PGP and S/MIME. This public key then can be used to encrypt a message which can be decrypted only by private key (which should only be accessible to the recipient). In practice this public key is usually used for performance reasons to encrypt only a short random secret and this random secret is used as symmetric key to encrypt the larger data.

The established standards PGP and S/MIME are actually good examples how to encrypt a message without doing any kind of handshakes inside the communication channel. The sender only needs the public key of the recipient to create such an encrypted message.

Of course if the common pre-shared key or the private key of the sender are compromised all communication done using this key can be decrypted, which includes all old communication. This risk can be mitigated if you use a different key all the time in the hope that not all of the keys gets compromised. But this would mean that you need some kind of back communication from time to time to exchange or negotiate the new keys.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • In simple terms - without a key, sending encrypted data is pointless. –  Aug 26 '15 at 11:08
  • 1
    @Ian: the key is needed for the encryption not for the sending. You can still send pre-encrypted data without having access to the key. – Steffen Ullrich Aug 26 '15 at 11:34
  • Apologies - I meant to say encrypting without notifying the receiver of any key is pointless. –  Aug 26 '15 at 12:19
  • After re reading your comment though, you seem to argue against even what I've just added to my initial comment. –  Aug 26 '15 at 12:20
  • 1
    @Ian: I must say that I don't really understand what you arguing about. A key must be there before encrypting something. Thus you either have the key (common pre-shared key) or create it (random key) and transmit it protected (encrypted with the public key of the recipient). – Steffen Ullrich Aug 26 '15 at 13:20
  • I'm not really arguing, I've actually up voted your post. I am trying to better understand what you've said. It implied to me that you've stated there is no use in encrypting simplex without first sharing a key. This question is specifically about encrypting simplex properly and methods to accomplish this. Can you clarify how your answer relates to these specifically? –  Aug 26 '15 at 18:38
  • Sharing the key with the recipient, of course. –  Aug 26 '15 at 18:40
  • @Ian: I understand the question is asking how to do encryption without doing **in-band** key exchange like done within TLS and IPSec (when used with certificates). And the answer is to either use a key which was shared out-of-band or to generate a key and transmit it protected by encrypting it with the public key of the intended recipient, like PGP and S/MIME do. – Steffen Ullrich Aug 26 '15 at 18:49
  • I see, thank you. So there isn't much purpose behind simplex encryption to a receiver without giving them a key using a covert channel first? –  Aug 26 '15 at 19:07
  • @Ian: you don't need a covert channel for the public key. This can be openly published like the case is with PGP. Only the private key must kept secret by the recipient (the sender does not know the private key). – Steffen Ullrich Aug 26 '15 at 19:46
  • That wasn't really the point of my question. –  Aug 27 '15 at 20:18
  • @Ian: sorry, but I have really problems extracting the point from your questions and I'm only guessing what you might mean. Maybe you could explain yourself in more detail. – Steffen Ullrich Aug 28 '15 at 04:26
  • Is there a reason to encrypt simplex without sharing the key? –  Aug 28 '15 at 23:04
1

OTP and variations thereof can be utilized and would be the best option given a strong enough key, of course traditional symmetric & asymmetric ciphers can also be used.

The problem however would be forward-secrecy for previous communications, once the data is encrypted and sent it is a matter of time before the key can be factored leading to a compromise of the data.

This problem is compounded in simplex mode because you cannot perform any further key exchanges between parties because it is usually embedded in the firmware.

jas-
  • 931
  • 5
  • 9