| Abstract [eng] |
One-way data transfers are used in cases where it is imperative to protect computer systems against certain threats. Depending on use case, data can either only be sent from the system or only be sent to the system, but not both ways. Such one-way data transfers are called unidirectional transfers. Malware analysis is often performed on isolated system or systems, to prevent malware from infecting external machines. But inbound data transfers to isolated system or systems are sometimes required. Controlling the isolated systems from the outside is also sometimes useful. So it would be useful to have a way to transfer data and commands to the infected systems in a unidirectional manner, to prevent malware from spreading. The goal of this work was to create a software implemented method to send data via an effectively unidirectional link. The chosen solution was to create a unidirectional control and file transfer protocol, UCFTP. The protocol allows sending files and executing commands on the receiver system. This is a network protocol, so it could be used in untrusted networks. For this reason, protocol uses encryption. Asymmetric cryptography is used to create symmetric session keys. Sender and receiver programs are identified by their public keys and the sender cryptographically authenticates to the receiver for every data transfer session. The protocol provides confidentiality, integrity, authenticity and replay attack protection. The protocol is resilient to packet loss. RaptorQ forward error correction (FEC) is used to compensate lost packets. Some constraints have to placed on the environment for the protocol to be usable: the attacker does not flood the link leading to the receiver, the link to the receiver is up and has known speed and packet loss characteristics. Protocol implementation uses UDP because it is connectionless. This allows the implementation to be uses on any systems that support UDP. Data throughput from the sender using the protocol is similar to throughput of HTTP/3. The receiver implementation is unable to keep up with such speeds. The space overhead of the protocol is similar to SSH and HTTP/3. The protocol is suitable for the malware analysis use case in certain environments, but the implementation is not optimized and may crash. The supported commands are also basic and might be inconvenient to use due to their limitations. |
