The Case for System Command Encryption

In several popular standards (e.g. ISO 7816, ISO 14443 or ISO 11898) and IoT applications, a node (transponder, terminal) sends commands and data to another node (transponder, card) to accomplish an applicative task (e.g. a payment or a measurement). Most standards encrypt and authenticate the data. However, as an application of Kerckhoffs' principle, system designers usually consider that commands are part of the system specifications and must hence be transmitted in clear while the data that these commands process is encrypted and signed. While this assumption holds in systems representable by relatively simple state machines, leaking command information is undesirable when the addressed nodes offer the caller a large "toolbox" of commands that the addressing node can activate in many different orders to accomplish different applicative goals. This work proposes protections allowing encrypting and protecting not only the data but also the commands associated to them. The practical implementation of this idea raises a number of difficulties. The first is that of defining a clear adversarial model, a question that we will not address in this paper. The difficulty comes from the application-specific nature of the harm that may possibly stem from leaking the command sequence as well as from the modeling of the observations that the attacker has on the target node's behavior (is a transaction accepted? is a door opened? is a packet routed etc). This paper proposes a collection of empirical protection techniques allowing the sender to hide the sequence of commands sent. We discuss the advantages and the shortcomings of each proposed method. Besides the evident use of nonces (or other internal system states) to render the encryption of identical commands different in time, we also discuss the introduction of random delays between commands (to avoid inferring the next command based on the time elapsed since the previous command), the splitting of a command followed by n data bytes into a collection of encrypted sub-commands conveying the n bytes in chunks of random sizes and the appending of a random number of useless bytes to each packet. Independent commands can be permuted in time or sent ahead of time and buffered. Another practically useful countermeasure consists in masking the number of commands by adding useless "null" command packets. In its best implementation, the flow of commands is sent in packets in which, at times, the sending node addresses several data and command chunks belonging to different successive commands in the sequence.