DryIce tamper detection for temperature, voltage and clock

[rémyobein]

Hi,

I'm using a i.MX258 in a custom board and facing problems with the DryIce tamper detection.

I program in DTCR (DryIce tamper configuration register) the DryIce tamper-detection logic: which kind of tamper generates a DryIce security alarm.

Then I print DSR (DryIce status register) and I can see if the security-violation flags is set and if set what generates the tamper.

I can easily test the tamper A and B, and the wire-mesh. Everything works.

When I enable in the DTCR register the bits TTE (temperature), CTE (clock) or VTE (voltage), then the DSR registers always reports the corresponding bit sets (bit TTD (temperature tampering) or CTD (clock tampering) or VTD (voltage tampering)).

For example, if I enable the temperature, the DryIce should only report a tamper when the temperature is below -100ºC or above 150ºC (i.MX25_security_RM_r1.pdf manual p207). My board is running at ~23ºC.

Why the DryIce always reports theses tampering sources? Is there something missing?

Best regards,

   Rémy

Remarks:

- The input voltage of the processor is 3.3V, and BAT_VDD is 1.5V

- The processor has the secure boot enabled and fusebits blown.

- Before to enable the tamper logic in DTCR, the DSR register reports no security-violation flag (SVF = 0) and DryIce in valid state (NVF = 0).

[bfac]

Dear Remy,

I was not able to contact you over email, it looks you have an issue on the server.

Just would like to update you should receive an answer soon.

Thanks!

Bruno

[Yuri]

As for recommended init procedure “Clear security violation flag. Write "1" to DSR.SVF” :

According to Table 6-11 (DryIce Status Register Field Descriptions) 

SVF “bit can only be cleared if the non-valid flag is set and by secure software writing
a logic one to this bit, provided that the security violation is no longer present.”

So the next must be provided :

NVF == 1
and
there are no security violation conditions.  

Next :

Please check If TAMPER_A or TAMPER_B is connected to NVCC_DRYICE, then external
tampering should be detected.

Also note :
Linux driver is described in Chapter 18 (DryIce Driver) of “pdk2009_12_imx25_Linux_RM.pdf”.

[Yuri]

1.

First, please use section 6.9 (Software Restrictions) of the i.MX25 Security

Reference Manual. Also, let me remind : the DRYICE_BASE_ADDR = 0x53FFC000

Next, please use the next initialization procedure (tamperA/B as example):

1.1. Clear security violation flag, DSR.SVF only and not NVF.  Write "1" to DSR.SVF.

1.2. Enable the needed tampers DTCR.ETxE, DTCR.ETGFx (x=A,B).

       Set counters, key,...

1.3. Clear all flags in DSR but not NVF. For example, write "1" to DSR.ETAD.

1.4. Enter the valid state by clearing NVF. Write "1" to DSR.NVF.

Then  testing / polling the DSR.ETxD  till a violation event occurs.

Basically it may be done even DTCR.ETxE = disable.

Finally, in order to clear the event bit(s) :  write "1" to DSR.ETxD, assuming

the external tampering is no longer detected.

DSR.ETxD bits can be cleared by writing a logic one to these bits in the non-valid state.

2.

Additionally, one may try the following values for the DACR :

HTDC = 0x1 (0x2 is also fine)

LTDC = 0x0 (0x3 is also fine)

VRC = 0x2

[bfac]

This procedure worked fine, we can mark this as correct answer.

Thanks Yuri!

[Yuri]

Please use the following (slightly modified) procedure to init security features :

1) clear security violation flag => SVF only and not NVF.

2) enable the needed tampers (temp, clock, voltage should typically generate a false alarm)

    Set counters, key,...

3) clear all flags in DSR but not NVF.

4) enter in valid state by clearing NVF.

[rémyobein]

Hi,

I was *RE*configuring the tamper while the dryice was already in valid state. So I didn't do steps 1.1 1.3 and 1.4 again.

Now, I use your initialization procedure, but:

1. When I monitor the DSR.WCF flag between each register write to know if the register was sucessfully written, the DSR.SVF stays set and the dryice reports only a clock tampering. And after ~5s it reports a clock and a voltage tamper.

2. When I monitor the DSR.WCF flag and add a small delay (~100 us) between each write, the DSR.SVF is not set. But after ~5s the dryice reports a voltage tamper.

In any case, when the Dryice reports the clock / voltage tamper, clearing the corresponding bit in DSR doesn't work which indicate that the tamper condition still exist.

I checked the dryIce voltage and it's ~1440mV that is inside the valid range.

- Do you have any idea why monitoring the DSR.WCF flag doesn't work ?

- Do you have any idea why the Dryice reports the voltage tamper after ~5s of polling ?

Best Regards,

   Rémy

Remarks:

I tested with the 4 combinations of DACR you indicated. Same behaviour

[Yuri]

Sorry for delay.

Let me look at sources (just want to check Software Restrictions in the section 6.9)