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.
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 counter-measures 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 they 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 and to provide data integrity. The data integrity assures the detection of accidental and intentional message changes, while the 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 are proposing a system that features a 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, the data packet 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; butthe data packet is only valid for the time frame for which it was transmitted at.
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.768 kHz 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 a good stability over time and temperature.
At the other end: On the decoder side, a similar time-keeping mechanism is being used (if not the same). The first time an encoder is paired with a decoder, the decoder stores information such as serial number and its timer value. It then stores a delta time value that represents the time difference between the encoder and the decoder on-board 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 will take the appropriate action (i.e., open 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 will 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 will, again, compare the two time values and if they match (or there are acceptable small differences), it will appropriate action.
Synchronisation
The whole synchronisation mechanism is built around free-running timers, both on the encoder side and the decoder side. Ideally, these timers will run synchronously and will be 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 of all, there is the initial crystal precision. This is specified by the crystal manufacturer and it’s typical in the range of 5-40 parts per million (ppm). The initial crystal precision is due to the manufacturing process. The crystal frequency cannot be exactly the specified value, but a very close value. This is specific and constant over time for every crystal.
Second, crystals are sensitive to temperature. The oscillating frequency is specified at 25 degrees Celsius. Between -20 degrees and 50 degrees, the frequency can vary up to an additional 20ppm.
Third, we must also take into consideration the 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 the timers on both the encoder and 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 able to calculate an approximate value. The decoder can still be synchronised with all the encoders by using an acceptance window. For example, once synchronised, the timer error between the encoder and the decoder will be at minimum. As time passes, the time drift between the encoder and 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 the 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 becomes empty 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 having a relatively low number of encoders. If the system has more than just a few encoders, manually synchronising all the 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 back-up.
Conclusions
Such an implementation can offer a very high security level. System attacks like capture-and-reply and radio frequency (RF) jamming are 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 differences and allows for ease of use. This technology can be easily used in conjunction with an authentication scheme so it can also provide a good level of OEM protection. The described technology is implemented by the new MCS3142 high security encoder from Microchip Technology.
The technique described in this paper is patented by Microchip Technology Inc.
