Decrypting AV Device Security for Control Programmers
With a growing focus on network security, manufacturers in the AV industry are doing their part to protect clients and avoid vulnerabilities by implementing authentication and secure connections in their products’ API (Application Program Interface aka communication protocol).
In the past, AV integration with third party devices via RS-232 or an isolated Ethernet network could be as simple as sending plain text ASCII commands or matching feedback strings as runtime program functions. As AV systems have become more IT-centric, there is a growing demand for products to be accessible over enterprise networks. Consequently, more and more device APIs are implementing secure connections and often require proper authentication and authorization before access to runtime functions is permitted.
The nature of the security protocol within a device API varies and depends on how a device will be accessed. Devices accessed over a local network will likely leverage different security measures than devices accessed through a cloud server. Understanding the protocol requirements of a device and properly architecting the communication approach to seamlessly integrate security is a major part of providing effective control.
Security between an AV control system and a third-party product starts with a secure, encrypted network connection. Authenticating to a device would not be very secure if the network packets were sent in clear text, so encrypting the network connection is a necessary first step. A network connection is usually encrypted with TLS (Transport Layer Security) certificate/key exchange. (Note: TLS is a descendent of SSL – Secure Sockets Layer protocol.) This process involves a negotiation between the control system program and the device where each validates the authenticity of the other. A session key is established that is used to encrypt data between the endpoints while the connection is active. The result of the TLS negotiation is an encrypted network connection (HTTPS) between the control system program and device that ensures the integrity of the messages sent by either side. All of this happens during the initial connection to the device.
Once a secure connection is established, the control program must now authenticate with the device to gain access to API methods (functions and feedback) for device control. Very often an API requires an authentication token to be sent with each command or query. This security token is used to test that the requester (in this case the control system program) has sufficient rights to execute the API function sent with the request.
In some cases, obtaining an authentication token can be a one-time operation performed the first time a control program connects to a device. This can be referred to as “pairing” the program and the device. The pairing process involves putting the device into pairing mode and initiating a pairing request from the control program. Once the device receives the request, a pairing response is returned that includes the authentication token that the control program will store and use for future connections.
Another way device APIs can require authentication is through OAuth 2.0, a method commonly used by cloud-connected devices. This process requires independent login to an authentication server as a separate step. The successful login generates the access token used by the control program for future connections. For cloud-connected devices, a single OAuth 2.0 access token can provide access to multiple devices that are all part of the same account that is authorized.
API security is inherently complex and is becoming a common demand for interacting with many types of devices. It operates behind the scenes of control program-to-device communication but requires careful architecting and implementation to work correctly so that a programmer can interact with a connected device as intended. Whether a device API requires a username/password challenge or more complex authentication process like OAuth 2.0, proper implementation of the API security ensures that an AV control system has proper device access and authorization to the rest of the device API.
While it can be challenging to interpret the specifications of an advanced device API that requires complex string handling, parsing of verbose feedback, and/or delicate command/response timing, an added layer of secure communication can make the task of integrating a manufacturer’s product daunting for the average programmer. This is especially true given aggressive timelines, increased workloads, and tight budgets. Fortunately, there is an answer that can benefit manufacturers, programmers, and clients in an equally positive manner.
The availability of pre-developed modules/drivers/plugins for specific control system platforms eases the burden of complex device control, while maintaining secure communication, reliable performance, and streamlined ease of programming and implementation.
Control Concepts works with many AV manufacturers to develop and support custom modules/drivers/plugins that integrate their products with a variety of control platforms. These middleware solutions address the requirements of device security through any of the aforementioned methods specified by the manufacturer.
Please reach out to discuss how we can help simplify device integration while maintaining adherence to any security model. We can help architect a module/driver/plugin that will wrap the complex nature of secure communication into a simple, elegant solution.
Additionally, to learn more about secure device control and its impact on the AV industry, read our post on Understanding Secure Device Communication in AV Control.
Adam Hanson started his career in software development and has continued to hone those skills, while growing new skills in the traditional world of AV solutions and control system programming. To read his full bio, check out the Our Team page. Adam can be reach at adamh@controlconcepts.net or on LinkedIn.
