0

We have IoT gateways that run Linux 5.4.31 kernel. These gateways need to manage thousands of devices which are mobile and each has a unique encryption key. The idea is to fetch the key of a device from a server (via secure channel) when the device enters the range, use it for decryption as long as the device is in the range and delete the key from memory when it leaves. Decryption must be done on the gateway since we have to do specific actions depending on the received data.

We want to store the keys on RAM unencrypted because we don't want the overhead of decrypting the keys for each time we access them. We have following assumptions:

  1. Physical access to the gateways are not possible.
  2. The service is running under a non-root user.
  3. An attacker might gain access to the gateway as a non-root user (that is different from the service user if that matters).
  4. An attacker might pull off a buffer overflow attack.

What are the options of an attacker to access the encryption keys on the RAM under these assumptions if

  1. We store the keys on a statically allocated memory (via static keyword in C, not in stack)
  2. We store the keys on dynamically allocated memory (it would probably be one-time allocation since we have limited resources).

Also what restrictions should we put on a non-root user, e.g. they can't access swap memory, core dumps, install packages, use gdb, etc. to prevent access to the process RAM?

Note: If the attacker has root access then they can access to all the keys using the private key that is used to access the server anyway, so we do not consider this case for this question.

Improve this question
1
  • I am going to suggest that if you want someone to tell you what the attack vectors are for your "linux", you are going to probably want to be more specific. Telling us only the kernel version is not super helpful. And you have no details about what else is running? At a minimum, what distro are you using and what changes have you made? Commented Sep 14, 2021 at 17:40

1 Answer 1

Reset to default
2

You’ll probably get better answers on Information Security SE.

You should ensure that the keys aren’t written to swap, by locking the relevant memory ranges (see mlock); this is easier to do if you allocate a pool of memory for the keys.

Also what restrictions should we put on a non-root user, e.g. they can't access swap memory, core dumps, install packages, use gdb, etc. to prevent access to the process RAM?

Non-root users can’t access swap anyway, and by locking the keys in memory you avoid that issue entirely. Non-root users also can’t access core dumps other than those generated by their own processes, and they can’t ptrace other users’ processes either (which means they can’t run gdb etc. to view other processes’ memory).

If your CPU provides the required features, you could look into using pkeys for additional protection. Another possibility is to delegate key handling to the kernel entirely; see the keyrings man page for details.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.