S3 security

This page describes how to create a secure connection between the CANedge and the S3 server.

Server security modes

The following describes three Server Security Modes. It is recommended to start using the Low Security Mode and migrate to the Medium Security Mode or High Security Mode before the system goes live.

Medium Security Mode and High Security Mode use HTTPS (Transport Layer Security, TLS v1.2).

Below is an overview of the security modes:

Low

Medium

High

API credentials

X

X

X

Transport security (TLS)

X

X

Server identity authentication (TLS)

X

X

Device identity authentication (TLS)

X

Warning

High Security support is pending future firmware update

Low security mode

The security provided by the Low Security Mode is illustrated below:

graph LR DEV((Device))-->API[API Credentials] subgraph Server API-->Storage(Storage) end

API credentials

The device uses the server S3 credentials (AccessKey and SecretKey) to calculate an authentication signature for each request. Upon reception, the server verifies the signature (see the S3 REST API for details). Only devices with a valid AccessKey and SecretKey pair can gain access to the S3 storage.

Warning

The AccessKey and SecretKey pair is shared amongst all nodes in the network

Warning

Data transmissions between the device and server are in plain text

Installation requirements

Devices are pre-configured with the server S3 API credentials (AccessKey and SecretKey).

Medium security mode

The security provided by the Medium Security Mode is illustrated below:

graph LR DEV((Device))== ENCRYPTED ==>API[API Credentials] subgraph Server API-->Storage(Storage) end

Warning

The device is not authenticated by the server

API credentials

Same as Low Security Mode

Transport security

HTTPS (TLS) is used to encrypt data between the device and the server. The device supports a limited set of ciphers for communicating with the remote server.

Server identity authentication

HTTPS (TLS) is used to authenticate the server certificate. This ensures that devices only allow connections to trusted servers.

Server certificate authentication sequence:

sequenceDiagram participant Device participant Server Device->>Server: Hello Server->>Device: Server certificate Device->>Device: Authenticate server certificate

Installation requirements

Same as Low Security Mode. Additionally, devices are pre-loaded with the CA certificate used to issue the server certificate - see the installation details further below.

High security mode

The security provided by the High Security Mode is illustrated below:

graph LR id1((Device))== ENCRYPTED ==>Certificate subgraph Server Certificate-->API[API Credentials] API-->Storage(Storage) end

API credentials

Same as Medium Security Mode

Transport security

Same as Medium Security Mode

Server authentication

Same as Medium Security Mode

Device identity authentication

HTTPS (TLS) Mutual Authentication is used to authenticate the device certificate. This ensures that only trusted devices are able to connect to the server.

sequenceDiagram participant Device participant Server Device->>Server: Hello Server->>Device: Server certificate Device->>Device: Verify server certificate Device->>Server: Device certificate Server->>Server: Verify device certificate

Note

Deployed devices can be denied access via a server "Certificate Revocation List"

Installation requirements

Same as Medium Security Mode. Additionally, devices are pre-loaded with a device certificate issued by the CA certificate installed on the server.

TLS/HTTPS

The CANedge uses TLS v1.2 for secure communication12, providing the following mechanisms:

  • Encryption of data transmissions

  • Server identity authentication (using certificates)

  • Device identity authentication (using certificates)

The CANedge2 supports the following ciphers for handshaking and encrypting the communication with the remote server:

Cipher

Group 1

Group 2

Group 3

TLS_RSA_WITH_AES_128_CBC_SHA

X

X

X

TLS_DHE_RSA_WITH_AES_128_CBC_SHA

X

X

X

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

X

X

X

TLS_RSA_WITH_AES_128_CBC_SHA256

X

X

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

X

X

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

X

X

TLS_RSA_WITH_AES_128_GCM_SHA256

X

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

X

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

X

These are divided into 3 groups, with each group containing a larger set of supported ciphers. Connections will initially be attempted with only group 1. In case the connection attempt fails, the CANedge will attempt with the next group, until only group 3 will be used for connections.

TLS uses a chain of certificates for establishing trust. At the top of the chain is the root certificate authority (CA). At the button is the user (application) certificate. In this specific case, the user certificate is used to identify either the server or the client (device).

graph TD root[Root Certificate] mid[Intermediate Certificate] user[User Certificate] root -->|sign| mid mid -->|sign| user user-->|reference|mid mid -->|reference|root

In order to trust the user certificate, one of the certificates above it in the trust chain must be trusted.

Warning

Be aware that certificates have an expiration date. An expired certificate is not trusted

Enabling server identity authentication

This section explains how to enable TLS/HTTPS server identity authentication on the CANedge.

When server identity authentication is used (Medium Security Mode and High Security Mode), the server must provide a trusted certificate proving its identity in order for the CANedge to accept the connection.

The server certificate is trusted if the device is configured to trust one of the certificates above it in the trust chain. Self-signed certificates are used directly, as these do not form a trust chain.

The device supports up to 10 server certificates as a bundled PKCS#7 (.p7b) file3.

Some servers have several certificates installed. The device uses the TLS extension field Server Name Indication (SNI) to indicate to the server which certificate to return (if a hostname is used as endpoint).

Below describes how to first prepare and then install trusted server certificates on the device.

Prepare certificate(s)

Trusted certificates are stored in a single file (/certs_server.p7b) on the device. The flow chart below shows how to prepare the certificate bundle depending on the number of certificates to install:

graph TD A(Acquire certificates) --> B[Number of certificates] B -->|Zero| D[Clear] B -->|One| E[Rename] B -->|Multiple| F[Bundle] G(Configure device) D --> G E --> G F --> G

Zero certificates (Clear)

Clear all loaded certificates by creating an empty/blank file called certs_server.p7b

One certificate (Rename)

Prepare a single certificate by renaming:

  1. Acquire the trusted certificate (e.g. the root certificate) in a supported format (.pem, .cer, .crt, .der)

  2. Rename the certificate to certs_server.p7b

Multiple certificates (Bundle)

Prepare multiple certificates by creating a PKCS#7 bundle containing all the certificates.

Generation of certificate bundles requires a tool, such as the free OpenSSL library 4

  1. Acquire the trusted certificates (e.g. root certificates) in a supported format

  2. Copy all the certificates into a single folder

  3. Open a console/command prompt in the folder

  4. Run openssl crl2pkcs7 -nocrl -certfile certificate_1.pem -certfile certificate_2.pem -out certs_server.p7b with the filenames of the certificates replacing certificate_1, certificate_2 etc. If more than 2 certificates are to be stored, insert additional -certfile certificate_n clauses 5

Local installation of certificate(s)

The certificate bundle can be installed on the device by placing it in the root of the SD-card.

  1. Copy the certificate file certs_server.p7b to the root folder of the device SD card

  2. Update the device Configuration File to use the https:// endpoint and the correct port

  3. Confirm that a hash of the loaded certificate is written to the device.json file on startup

  4. Verify that data is uploaded correctly via HTTPS

Warning

Make sure to update the endpoint to use https://

Remote installation of certificate(s)

The certificate bundle can be installed on the device by placing it on S3. For more information refer to Server certificates over-the-air.

Enabling device identity authentication

Warning

Device identity authentication support is pending future firmware update

If device identity authentication is used (High Security Mode), the device must provide a trusted certificate proving its identity in order for the server to accept the connection. The device certificate is trusted if the server is configured to trust one of the certificates above it in the trust chain.

1

The device is not compatible with servers that only support DSA certificates

2

512, 1024, 2048 bit key sizes are supported. 2048 bit key size is recommended

3

The device does not support multiple certificates from the same issuer (the Issuer field) as this field is used to distinguish the certificates

4

Linux: Check the package manager for the distribution, Mac OS: Homebrew, Windows: Available as a part of pre-packaged git

5

The input certificate format must be PEM/base64 encoded DER