In remote-control operated systems, security is always a concern. The system must be designed to prevent unauthorised access. Special software and encryption are used to prevent eavesdropping. This is why such systems are using encrypted communication. In a perfect scenario, only the authorised receiving party is able to decode and process the information. With an adequate level of encryption, such criteria is generally met. Still, there is the possibility copying and re-transmitting a valid data transmission. Today, different methods are used to prevent this. However, none of them are perfect.
This paper describes the implementation of a highly-secure remote control system that makes the capture and reply attack useless. The data packet sent over the air contains time-synchronisation information, which is valid only for a very narrow time frame. Any further capture and reply attack is simply useless. Even though a captured-and-replied message, in essence, contains (almost) correct information, the message is discarded since it has lost its valid time frame. We will describe the proposed solution and the technical challenges faced while designing such a system.
The end application rules: General remote-control designs come in various implementations and security levels. Of course, in general, the price also increases along with the security level. However, with smart firmware and taking advantage of the ever-increasing number of peripherals a modern microcontroller has on-board, designing a remote-controlled system with a very strong security is more cost effective today. In general, the remote-control level of security is tied directly with the end application. For example, controlling a light source or a fan does not really require encryption. But, when the system is designed to allow (or not) access to a valuable property, then there is the need to add a certain security level. However, this does not come for free.
Authentication versus privacy
There is a wide range of encryption algorithms that can be used. The choice is more system-specific. In general, there is a split between authentication and security. Authentication is used more when the encrypted data does not carry any specific information by itself, such as commands and messages. It is used more to authenticate a device. A good example is a manufacturer choosing to authenticate replacement parts, upon installation. The system first authenticates them, and only if found valid does it start normal operation. Typically, such devices include printer cartridges, toothbrush heads, cellphone batteries or even electronic modules.
Algorithms to secure your message: These devices normally use hash algorithms such as the Secure Hash Algorithm-2 (SHA-2) cryptographic hash functions. These are functions that calculate a key from a longer message. For example, the MD5 checksum is used when downloading large files from the Internet. The MD5 message digest algorithm will read the entire file and then generate a key. This computed hash value is later used to verify the integrity (or authenticity) of the downloaded file, without providing any means to recover the original data. In other words, simply having the key does not mean you can backwards generate the original data from which the key was generated.
In general, in these kind of applications, authentication is for securing business rather than providing privacy.
On the other hand, a system that uses privacy will use encryption algorithms like Extended Tiny Encryption Algorithm (XTEA) or Advanced Encryption Standard (AES). These are industry-standard encryption algorithms that are being used in a wide variety of electronic devices and are being considered secure enough for a large number of applications. These algorithms can be implemented either in hardware or in software. There are different opinions (even among specialists) regarding which implementation, whether hardware or software, is the more secure one.
Adding Higher Encryption is Adding More Cost
In general, a stronger security level will result in an increase in the overall cost of the system. Both hardware and software implementation will have an impact. Even a complete software implementation will add additional cost; this is because the firmware also needs to occupy more memory. The more memory required, the bigger is the additional cost.
As mentioned, some implementations use a hardware encryption module, while others use software implementations. But essentially, both implementations do add additional cost. Software implementations have bigger requirements on both program and data memory. On the other hand, hardware implementation has bigger requirements in terms of the size of the silicon die. There are pros and cons on both sides. The choice is up to the system designer.
But even if the designer is using a very high level of security, this does not lock out attacks like capture-and-replay or jamming and selectively replaying information.
Typical Security Threats
This section introduces you to some of the modern threats to securing your system, and methods to secure them.