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 are generally met. Still, there is the possibility of copying and re-transmitting a valid data transmission. Today, different methods are used to prevent this. However, none of these are perfect.
This article 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. The following paragraphs 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 by taking advantage of the ever-increasing number of peripherals a modern microcontroller has onboard, designing a remote-controlled system with 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 these, and only if found valid does it start normal operation. Typically, such devices include printer cartridges, toothbrush heads, mobile phone batteries or even electronic modules.
Algorithms to secure your message. These devices normally use hash algorithms such as Secure Hash Algorithm-2 (SHA-2) cryptographic hash functions. These functions calculate a key from a longer message. For example, MD5 checksum is used when downloading large files from the Internet. 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 kinds of applications, authentication is for securing business rather than providing privacy.
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 adds to 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 is required, the bigger is the additional cost.
As mentioned earlier, some implementations use a hardware encryption module, while others use software implementations. But essentially, both implementations 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 to 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 these.
Brute force attack. The brute force attack is a very basic cryptanalytic attack that involves using all possible combinations until the correct one is reached. Of course, this is more a theoretical approach rather than a real implementation, and depending on the number of possible combinations, it can take a long time to complete. With modern encryption techniques, such an attack would take many years to complete.
Capture and replay. This attack is one in which valid data is fraudulently captured and re-transmitted. There are several countermeasures to avoid such attacks. One such measure is using session tokens. These tokens are used as a part of the encryption system. Each token is valid only for a particular session; the token (and the transmissions derived from that token) cannot be used in another session. One-time passwords are very similar to session tokens except that these are used to authenticate individual transactions in a session. However, these are difficult to be implemented in one-way systems.
Check the integrity of your data. The message authentication code is a short piece of information added to a data transaction and used to authenticate a message to provide data integrity. Data integrity assures the detection of accidental and intentional message changes, while authenticity assures the message’s origin. This does not provide the privacy aspect but more the authentication.
Note the time. Time-stamping is another way of preventing a capture-and-replay attack. It involves sending periodic time-stamped messages. At the receiver end, the time-stamp is compared to a local estimated one within a reasonable tolerance level. This poses some special design challenges.
A time-keeping source
To overcome some of today’s major security threats, we propose a system that features the concept of limited time valid data packet. In other words, every data packet that the transmitter/encoder is sending over the air has time-limited validity. Even though, in essence, the data packet itself is perfectly valid in terms of proper encryption and data contained, it is valid only for a very limited time period. A capture-and-reply attack would have very little success in attacking such a system. This is because such an attack involves capturing a data packet and then re-transmitting it at a later time; but the data packet is only valid for the time frame for which it was transmitted.
To implement this, each data packet needs to include a time-stamp. Thus, the transmitter needs to have a time-keeping source. The easiest way to achieve this is by using a crystal oscillator. (A 32.768kHz crystal is a good choice.) Today’s microcontrollers feature crystal-driven time-keeping peripherals that can work even in low-power states. Thus, the processor can keep track of time even in sleep mode. Any other time-keeping method can be used as well, provided that it features good stability over time and temperature.
At the other end. On the decoder side, a similar time-keeping mechanism is used (if not the same). The first time an encoder is paired with a decoder, the latter stores information such as the serial number and its timer value. It then stores a delta time value that represents the time difference between the encoder and the decoder onboard timers. At this time, the encoder is synchronised with the decoder. At a later time, when a transmission from the encoder is being received, the decoder evaluates the time value that it expects (based on the decoder’s timer and from the encoder’s last-saved time-stamp) with the time-stamp from the encoder. If the two values match, the decoder takes appropriate action (that is, opens a door).
However, the receiver/decoder side needs to support not just one but many more such encoders. So it needs to have different time values for all encoders paired with the decoder. Obviously, the decoder cannot implement many such timers.
The solution is to use a single timer on the decoder side and use time delta values for each encoder. These time delta values for each encoder need to be saved in non-volatile memory. When a data packet arrives from the encoder, the decoder would read the saved time delta value for that particular encoder and use its current timer value to estimate the timer value sent by the encoder. The decoder would, again, compare the two time values and if these match (or there are acceptable small differences), it would take appropriate action.
Synchronisation
The whole synchronisation mechanism is built around free-running timers, both on the encoder and the decoder sides. Ideally, these timers run synchronously and are in constant synchronisation. However, all time-keeping devices have limited stability and precision. Devices that feature high stability and precision can be very expensive. So choosing the right time-keeping mechanism is more a design trade-off. A typical implementation will use the same time-keeping circuit on both encoder and decoder sides. A cost-effective solution can be using a crystal oscillator. However, even if the same crystal is used at both ends, there will be some frequency differences.
Discrepancies in frequency. First, there is the initial crystal precision. This is specified by the crystal manufacturer and it is typically in the range of 5ppm to 40ppm (parts per million). The initial crystal precision is due to the manufacturing process. The crystal frequency cannot exactly be the specified value, but a very close one. This is specific and constant over time for every crystal.
Second, crystals are sensitive to temperature. The oscillating frequency is specified at 25°C. Between -20°C and 50°C, frequency can vary up to an additional 20ppm.
Third, we must also take into consideration crystal aging. This is less important, since it happens over a very large period of time. Taking into account all the above tolerances will mean that timers on both the encoder and the decoder will never be in perfect synchronisation, except at first pairing. The decoder will not be able to calculate an exact match of the encoder’s real-time value. It will only be able to calculate an approximate value.
The decoder can still be synchronised with all encoders by using an acceptance window. For example, once synchronised, timer error between the encoder and the decoder will be at minimum. As time passes, time drift between the encoder and the decoder will increase. It is then up to the decoder to decide the maximum time difference for a packet to be accepted as a valid packet.
Re-synchronisation
Since the system relies on the fact that the timers on both ends are in constant synchronisation, it is very important that the timer’s operation is not interrupted. There are cases when synchronisation can be lost due to power failure (like a mains grid incident or battery replacement).
On the encoder side, this will typically happen when the battery gets exhausted and needs replacement. This can be easily resolved by manually re-synchronising the encoder. On the decoder side, a loss of power is more serious, especially since the decoder needs to keep track of multiple encoders.
Re-learning all encoders is feasible only when there is a relatively-low number of encoders. If the system has more than a few encoders, manually synchronising all encoders is not a good option. In such cases, it is recommended that the decoder has a time-keeping back-up circuit such as a real-time clock circuit with a battery backup.
Conclusion
Proper implementation can offer a very high security level. System attacks like capture-and-reply and radio frequency jamming become basically useless.
Another important advantage is that such an encoder can be used with multiple decoders. This is because the decoder only verifies time synchronisation and the authenticity of the encoder. Overall, this is a high-security and cost-effective security solution.
From the user standpoint, the solution introduces no difference and allows for ease of use. This technology can easily be used in conjunction with an authentication scheme so it can also provide a good level of OEM protection.
The technique described in this paper is patented by Microchip Technology Inc.
Cristian Toma is senior applications engineer, MCU08 Division, Microchip Technology Inc.
