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.
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.