15.8. GEISA API Security¶
GEISA provides a message based API via MQTT. Conformant implementations will provide the application a local port via the AII wherein they can connect to the MQTT broker. This is discuss in more detail in API Architecture.
15.8.1. API Authentication and Encryption¶
Several highlights of API Authentication and Encryption are repeated here:
Connections are over localhost or virtual network links between the application isolation implementations (i.e. containers, virtual machines, virtual execution enviroments, etc.) and the broker.
The broker MUST not be exposed to any external network interface. Doing so is a violation of this specification.
Encryption is NOT used for this link. While the industry has generally moved to requiring encryption everywhere, GEISA has chosen not to do this because:
The links are already completely isolated through the AII.
Doing so would introduce an internal key management or certificate management requirement.
Encryption would add unnessary overhead on a constrained embedded device.
The GEISA threat model already addresses attacks against the API via other means.
As discussed in API Architecture, platforms are responsible for issuing applications their login credentials to access the broker. The userid and password (referred to as a token), MUST be printable alphanumeric characters. The userid MUST be unique to the application instance and persist for the life the application installation. The recommended length of the application userid is eight (8) characters. The recommended length of the login token (password) is sixteen (16) random characters.