Delivering updates securely, maintaining the identity of the communication endpoints, ensuring message authentication, together with integration with hardware security solutions are critical factors in a secure software update. This section gives a brief overview of how Mender ensures a secure end-to-end update process.
A Device, running the Mender client, communicates with the Mender server in order to authorize, get updates, update inventory data, and deliver status information.
Communication between the client and server happens via a REST API over a TLS-encrypted channel. The Mender client relies on the operating system’s root Certificate Authorities (CAs) to verify the server identity by default. You can also configure the client to use a specific certificate for chain validation, e.g. when using self-signed certificates.
This ensures that the Mender client will only connect to a verified server, and no man-in-the-middle attack is possible.
The client initiates all communication by connecting to the server, so no open ports are required on the device in order to use Mender. As long as the Mender client can connect to the server over HTTPS, you can schedule updates.
Each Device has a unique public and private RSA, ECDSA or ED25519 key. You can generate this offline and provision it with the Device storage, otherwise the Mender client will automatically generate an RSA key pair with a default length of 3072 bits when it launches for the first time. Once generated, private key cannot be changed or retrieved by means of API calls. If you decide to re-generate the keys on the Device, it will require going through the authorization process again. The client passes the public key in authorization requests to the server and you can see the public key of a Device in the Mender UI.
You can find more information in the Device authentication and Preauthorizing devices sections.
The Mender client has the ability to verify that the update comes from a trusted source. This is an additional layer of security, independent of the communication channel. If Artifact signature verification is enabled, the client needs to have access to the public part of the keypair used for signing the Artifacts. To enable Artifact signature verification, configure the path of the public key file using the ArtifactVerifyKey configuration option of the Mender client.
You can find more information in the Sign & Verify section.
As a user, you interact with your Devices either via API calls issued to the Mender server, or via the web UI. In both cases, the connection is HTTPS encrypted with TLS. To authenticate with the Mender server, a user must log in by presenting a valid email address and password, as well as a Two Factor authentication code (if available in the plan and enabled). The client (e.g. web UI) used to log in then receives a JWT token with a default expiration time of one week.
As an additional layer of security, Mender Enterprise supports Role Based Access Control to limit authorization of users.
The Mender client can utilize private keys stored in Hardware Security Modules (HSM) or in Trusted Platform Modules (TPM). This is an additional layer of security which eliminates storage of private keys (secrets) as plain text files on the device, making it harder for an attacker to gain access to keys to impersonate devices.
Starting with the Mender Client 2.4.0, the client uses OpenSSL for cryptographic operations, which enables usage of
OpenSSL Engine's as abstractions for HSM.
For the Mender client to be able to utilize an HSM, OpenSSL must first be configured appropriately, and this is normally vendor specific. Please see the following tutorial for vendor specific instructions:
The Mender client supports PKCS#11, or any other HSM access methods that are supported by
OpenSSL Engine's. See Mender client configuration sections for additional details.
Currently, Mender supports hardware security engines for SSL handshake, mTLS, and authentication request signing.
The Mender Enterprise server supports configurable API rate limits. When a device or a user is
crossing the rate limit threshold, it will receive the HTTP status code 429 Too Many Requests.
You can configure the server to enforce these limits based on the client IP and the identity of the API caller, either device or user. Rate limits can apply to all the API calls, or you can customize them for specific API end-points.
© 2024 Northern.tech AS