Security Best Practices

This how-to-guide describes security best practices for deploying EVerest in a production environment. It provides checklists with items to consider for securing the system.

EVerest-related security aspects

• ☐ Do not expose the main MQTT broker on any interface (e.g. PLC, Ethernet, …). We recommend using a unix domain socket between EVerest and Mosquitto.

In Mosquitto, config file add the line:

listener 0 /tmp/mosquitto.socket

In the EVerest config file, add the following to the settings section:

settings:
 mqtt_broker_socket_path: /tmp/mosquitto.socket

• ☐ If a part of an MQTT API should be exposed, e.g. to a mobile app on the same wireless LAN, use mutually authenticated TLS for the MQTT connection and run a separate Mosquitto instance. Bridge only those API topics strictly needed (and nothing from the “everest” topic) between the two Mosquitto instances. Shutdown the public Mosquitto whenever it is not needed.

• ☐ Use OCPP security level 3 for the CSMS connection.

• ☐ Use a hardware security module, e.g. TPM2 for generating and securing private keys.

• ☐ Don’t use the admin-panel on the product and ensure EVerest does not listen on port 8849. In the Yocto recipes, this is disabled by default. Take special care if you use another build system. Set “EVEREST_ENABLE_ADMIN_PANEL_BACKEND=OFF” in cmake.

• ☐ Do not run EVerest modules as root user. Create a low privilege user, that has access only to what is needed (via filesystem permissions, group memberships, …). In Yocto, you can do this in your image file similar to this:

inherit useradd
USERADD_PACKAGES = "${PN}"
USERADD_PARAM:${PN} = "-u 1500 -d /home/everest -g everest -G systemd-journal,dialout,tty,gpio,tss,mosquitto -r -s /bin/false everest"
GROUPADD_PARAM:${PN} = "-g 1500 everest; -g 1501 gpio; -r systemd-journal; -r tss"
GROUPMEMS_PARAM:${PN} = ""

Note

Make sure to use the correct groups and settings for your system.

Specify this user in the EVerest config file in the settings section:

settings:
 run_as_user: everest

Some modules need elevated privileges, e.g. SLAC module. Those modules should be given individual Linux capabilities like this:

slac:
  config_implementation:
    main:
      device: seth0
      link_status_detection: true
  module: EvseSlac
  capabilities:
    - CAP_NET_RAW

Here is a list of capabilities required by the EVerest modules:

EvseSlac / EvSlac	CAP_NET_RAW
Setup	CAP_NET_ADMIN, CAP_NET_RAW, CAP_DAC_OVERRIDE
PacketSniffer	CAP_NET_RAW

The systemd service should start the manager process as root. It will then change the user for the child processes it forks (the modules) and set the capabilities as needed.

General (non-EVerest-related) security aspects

Reaching complete system-level security is a complex topic, that should be handled by experts. This manual cannot give real advice here.

Following, we created an unordered and incomplete list of things that you should consider during the development process:

• ☐ Use secure boot and make sure that you do a full lock-down on production units that prevents any unsigned code to boot.

• ☐ Disable bootloader console on production units.

• ☐ Disable any UART console login.

• ☐ Disable or lock down all programmer interfaces such as SWD or JTAG in production units.

• ☐ Don’t expose USB ports unless you really know what you are doing. A quite common attack vector for charging stations is to plug in a USB dongle and reconfigure / update the firmware - or attach a keyboard …

• ☐ Evaluate if the rootfs or special partitions need encryption.

• ☐ Use a secure vault for all private keys on the device (e.g. TPM2.0).

• ☐ Make sure your PKI for secure boot and OTA is properly maintained. If you loose the private root key, the hardware in the field is lost.

• ☐ Use signed updates. Evaluate if encryption is needed.

• ☐ Use signed updates also for all other components, such as the safety MCU.

• ☐ Be able to OTA-update all components in the charger through the normal OTA package - also third party components if they have a firmware update feature.

• ☐ Network interfaces: Verify that only services being absolutely necessary are accessible on a network interface.

• ☐ Use mTLS with TPM if you have a custom cloud connection.

• ☐ Lock down all maintenance / service / repair ports.

• ☐ Maintain the complete Linux system and provide regular updates.

• ☐ Don’t use default passwords for anything - or better: Don’t use passwords at all.

• ☐ Use software and hardware watchdogs.

---

Authors: Cornelius Claussen