Tamper detection methods

This post is related to

We have Non Balena devices in production using Zymbits Zymkey and encrypted filesystem to prevent misuse of devices stolen from their mounting location.

My current impression is that going this way makes our setup unnecessarily complex and costly and prevents us from choosing hardware that does not support this.

So I am looking for other ways to reduce mainly the risk of s.o. misusing the credentials they might find on the unencrypted device.

  1. Make sure the device has limited access to out backend systems.
  2. Implement a kind of tamper detection (not prevention) that informs us about unusual device metrics that indicate a risk that the device has been compromised.

My interest here is to sort out the second point: Which metrics or information available on the device could I use as triggers for a ‚I have been tampered with‘ message to the backend, knowing and accepting that some of them could be faked with some effort?

Our devices are stationary, so one thing I could check is if the location (gsm cell) has changed.

Any more ideas much welcome.
Bruno

Our devices are stationary, so one thing I could check is if the location (gsm cell) has changed. Any more ideas much welcome.

Related to the location / GSM cell idea, something else that could be checked is the MAC address of the “default gateway” (e.g. a WiFi router providing internet access), like “4c:38:d8:00:22:18” in the example below:

root@5d3ffbf:~# balena-engine run -it --privileged --network host --rm alpine
/ # ip route show | grep default
default via 192.168.0.1 dev wlan0  metric 600
/ # arp -an
? (192.168.0.1) at 4c:38:d8:00:22:18 [ether]  on wlan0
...

Also, if your board has a spare GPIO pin, perhaps fitting a simple on/off switch to the case, that detects if the case is physically opened – at least while the board is powered up…

Good suggestions, thank you! We are looking for off-the-shelf hardware, so I am looking mainly for software based solutions.

Hi Bruno, just want to let you know that we’ve also asked one of our security experts if he has more suggestions for tamper detection, if so we will get back to you again :slight_smile:

Great Alida,

the idea we think about is accepting the device itself is insecure, but minimizing the potential misuse and impact on the backend.

Bruno

Bruno,

I have personally been investigating the options around encryption at rest and what we could build into the OS to allow support for this. I have access to a Zymbit and I have been looking into how it integrates and what support is needed on the OS/HW level.

I don’t have anything concrete to put forward yet, but I thought it would useful to you to know that this is a conversation that is happening internally and these kinds of feedback help us focus our discussions. So thank you :grin:

Regarding tamper detection mechanism, if the risk is that the device could be moved/stolen, then you could periodically write the device’ uptime to a file and then check that the uptime is always greater than that value - and keep updating it. If the device reboots then you would be able to detect it, but how you handle that would be up to you :+1:

Ok. Zymbit will still be an option but we will focus on tamper detection. Tnx for the suggestions.