However, this is only the beginning

Messages on the way to another host¶For the way to another host via a transport channel the message must be packed. To do this, it is first converted into a byte array via a stream. But this is only the beginning. For certain messages, it is worthwhile to use compression, which further reduces the size of the byte array. In addition, additional encryption is sometimes desired in case certain hosts along the way are not trusted.

Here we have implemented the concept of the Package Builder Sequence. Each method of transforming the packet is marked with a letter.

Currently there are

– M = stream message (mandatory) – Z = compress packet with the ZIP algorithm – A = encrypt with AES.

The packet will have the applied sequence in the header, e.G.B. "MZA" for all three builder types. When unpacking, the builders are called in reverse order.

However, this is only the beginning

Which Package Builder Sequence is used can be set in many ways:

A sequence can be set in the envelope of a message. It has the highest priority.

If the sequence is missing in the envelope, the own link frequency is used. It is only valid for a certain distance between 2 hosts, which does not have to be adjacent. In the data pool it is under:

Plugin/network/hosts/HID/MyPacketBuilderSequence

Where HID is the adversary Host-ID.

If the route sequence is missing, the sequence is applied to the entire host. It is entered in the configuration as follows:

The PacketBuilderSequence is the sequence of packing messages, before they will be sent to another host. 'M' means 'Message' and is mandatory. Z' means 'Zip': ZIP compression is used if the compressed packet is smaller then the uncompressed packet. 'A' means 'AES': AES encryption is used after compression. The default PacketBuilderSequence is 'MZA'. MZA

If also this entry is missing, "M" is assumed, as neither compression nor encryption is used.

However, this is only the beginning

Symmetric AES encryption is not to be confused with the use of SSL/TLS for a link between two neighboring hosts. It rather applies to the internal encryption of a message between sender and receiver host, i.E. Z.B. Between "A" and "D" in the diagram above.

How does the sender host find out how the receiver host would like it to be?? And how is encryption done, if not using the TLS layer??

Now, before the first message from z.B. A is sent to D, A has to ask host D for its preferences. This takes place (of course!) by a message (GetHostRecord). (If this was not done with the first message to be sent, the current message is put back for a moment and the GetHostRecord is sent first.) A public key of an RSA key of A is provided, which is then used by D to encrypt a symmetric session key. In addition, various other data are provided, such as name, vendor, package builder sequence (!), license key etc. This now tells A everything he needs to communicate with D. The other way round (D>A) it works the same way. So two different session keys (back and forth) are agreed between each pair of hosts. This only happens at the beginning of a session (and again after a certain time has elapsed), and is so fast that you don't notice it.

There is one catch: If one of the involved hosts is shut down and then up again, the session keys become invalid. Since the opposing host does not necessarily notice that one host was down for a short time, host D receives a message from host A that is still encrypted with the old SessionKey. This message is lost. At least the circumstance is used and Host A is asked to request a new HostRecord.

Like this post? Please share to your friends:
Leave a Reply

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: