• Upon activation, each card is uniquely locked to the particular hardware unit, and cannot be used in other hardware.
• Transmission of firmware updates via the internet is encrypted.
• Encryption utilizes the industry-standard AES.
• The CUBE has no concept of onboard accounts or inbound access, and no default access credentials for use with any local or remote access that reflects on security:
• No non-secure ports are open.
• There is no user-accessible interface on board the CUBE (outside of the basic configuration discussed above), and no default user passwords.
• There are no non-secure ports facilitating any inbound access.
• The CUBE only makes outgoing network requests. This includes DNS lookups, and outgoing HTTP and HTTPS requests.
• In all respects the CUBE is reminiscent of a user on the network periodically accessing the internet in order to check whether a web page has been updated.
• The CUBE requests its control instructions from the cubemc.net infrastructure.
• The control instructions include information about which media must be held on board and how it must be scheduled.
• Required media not yet on board is fetched via HTTP or HTTPS requests from the appropriate content servers.
• The CUBE may periodically send status reports via HTTP / HTTPS POST messages. These status reports include playback history logs, synchronization status, storage usage and so forth.
• The CUBE is not subject to virus infection as it does not execute any content, javascript or any other executable format retrieved via HTTP / HTTPS, with the exception of firmware updates (which must be properly encrypted or otherwise will be rejected by the CUBE).
• Ie, outbound TCP access is directed to destination ports 80 and 443.
• All HTTP verbs (GET, POST etc) should be permitted by the security device.
• Access to all subdomains of cubemc.net (*.*.cubemc.net) should be allowed.
• The CUBE can perform its outgoing requests via a proxy server, and proxy authentication can be used. The proxy should support the CONNECT extension method for correct SSL/HTTPS operation.
• The CUBE will default to using NTP for time synchronization. If NTP is not permitted in the network, the CUBE will instead utilize HTP for time sync (which derives the time sync info via HTTP).
• In standard operational modes, when content programming is updated, CUBE will only bring on board files that are not yet present.
• In other words, during periods where no content changes are being deployed, and the system is in “steady state” with respect to delta transfers, CUBE will incur minimal traffic usage.
• Network traffic during such periods primarily pertains to live playback reporting and system diagnostic capabilities.
• For a typical music and messaging application in steady state, over the course of one hour, approximately 17,100 bytes would be transmitted and approximately 1,860 bytes received.
• This is spread as 40 - 90 requests with a mean payload of 190 - 390 bytes apiece.