Anti tamper real time clock (RTC) - make your embedded system secure

Prevent Malicious Code from Changing Register Settings:
A hacker may introduce unauthorized firmware into the system so as to take control or change register settings. One of the common software tamper is to move back the time in order to allow, for example, music protected by Digital Rights Management to be played again and again by moving back the time.

RTC should have the capability to lock the time so that it cannot be moved back unless the system is reset. Critical register access should be secured by a write protection mechanism such that any write from a malicious or runaway code cannot change the register settings unless it goes through a pre-specified sequence.

Figure 4 shows the recommended write protection on the RTC registers. The registers are locked by default and to program them a specific sequence needs to written which would be known to the valid/secure program only.


Figure 4: Write Protection Sequence
(Click on image to enlarge)
Additional advantage of having this write sequence is to protect the registers against an ESD or external noise that can trigger changes in register settings. Since any write to the register has to go through a fixed sequence, it is highly unlikely that an ESD/noise can corrupt the registers.

It is also essential to separate critical registers from the user registers by providing different access permissions to the critical registers. For example, RTC registers can be divided into Secure and non-Secure registers and time & date registers can be kept in the secure portion which can only be accessed by the secure code. This provides additional layer of protection to the RTC registers.

Protecting against a Power Glitch on external lines:
For the systems that boot from external memory, a unique way of tampering a secure system is to introduce noise on the memory interface or a glitch on the power lines of the SoC. This random noise can cause changes to registers settings. In some of the systems that boot securely, this can cause to bypass entire security process thereby making the SoC vulnerable to hacks and tampers.

RTC can prevent this from happening by maintain a hard-coded security code that needs to be programmed in its registers during boot. RTC, on a code mismatch can generate a security alarm indicating that external boot sequence has been manipulated by random noise or otherwise generated by the hacker to unsecure the system. This code once programmed is monitored at all times. Hence noise generated at any point in time which alters the programmed code will be detected.


Figure 5: Power Glitch Detection
(Click on image to enlarge)
Protection against Battery Removal:
One of the common ways of tampering a system is to remove the battery when the main supply is not available. This allows hacker to manipulate the system and then connect the battery back as if nothing has happened. In a secure system, the RTC should be independent in all ways, including its power source. Removal of this independent power source i.e. the battery can have detrimental effect on the system and can make it vulnerable to attacks. Hence a secure system must ensure battery is not easily removable and if removed must be detectable.

It is important to note that RTC should have a separate "Power on Reset (POR)" than the SoC POR. RTC should reset (RTC POR asserted) only for the case where both main as well as battery supply is removed or battery is connected for the first time. RTC should have the capability to detect removal of battery and thus generate an internal tamper interrupt to the CPU. During initial calibration, this tamper can be ignored as system would in diagnostic mode.

Time Stamping a Tamper Event:
RTC should be able to record the time of a tamper event. This can let the system know when an attack has happened and the number of times it occurred since installation. Good example to understand this is a digital electricity meter. A hacker can reverse the neutral and the live wire so as to make the current flow in opposite direction thus counting the energy backwards. If the RTC has the capability to detect this and store the time when the event has occurred, energy distribution company can know when this happened and can bill/fine the user accordingly.

Invalidating the Time:
It is a good idea to invalidate the time when a tamper occurs and this action is completely application dependent. For example, in a Point of Sale terminal, it would be good to invalidate a time so as to indicate that device has been tampered while for an electricity meter, it should just record the time stamp without invalidating the time as all the billing calculation may be time dependent. Energy companies also want to know subsequent tamper events after the first tamper and would like to keep running the clock all the time, no matter what. They can later bill user differently based on time and number of tampers.