From client security point of view, whenever making a TLS connection through an untrusted network, it is very important to authenticate the server (the device) reliably. Otherwise, a man-in-the-middle (MITM) type of attacker could hijack the connection and intercept any information passed between the client and the server, including the client’s authentication credentials.
The web server of DMU801 uses self-signed TLS certificates, and currently, there is no way to manage those certificates. However, the self-signed certificate is unique for each device and if known by the client, it can be used for cryptographically secure server authentication.
All API client implementations should have a two-phase authentication model as follows:
- Learning phase: Connections to new devices are only allowed by manual authorization. When allowed to perform an initial connection, the client implementation records and stores the public certificate of the server to a server certificate database. It is recommended to perform the initial connection through a trusted network if possible.
- Assertion phase: Whenever connecting to a known device, the client implementation asserts the pre-learned server certificate of that device for server authentication, that is, requires the TLS stack to only accept the specific server certificate. This way, if there is a MITM adversary on the connection path, the connection will be refused by the TLS stack.
Because DMU801 server certificates have no hostname information that could be used for typical hostname verification, the client implementations must disable TLS hostname verification. However, contrary to a typical Certificate Authority -based server certificate verification, when the above device-specific server certificate verification model is used, disabling the hostname verification does not pose a security risk. This is because each device is authenticated explicitly by its server certificate.