The Example system enables the camera to have a Firewall within the camera itself. The implementation of the Firewall may be:

1. Within a trusted execution environment.
   • This provides the highest level of security.
   • This provides a defense even when the application processor on the camera has been compromised and simplifies the management of updates by enabling a single code image for security to be used on multiple camera models.
   • The details of the Trusted Execution Environment are out of scope of this specification. (Options that may be implemented are Global Platform or within the Android specification (Trustee)).
2. Within the application processor.

Note: The implementation of the Firewall is determined by the camera manufacturer.

The Example system provides a standard mechanism to configure the following within the firewall:

• Whitelist, Blacklist mode
• Domain Name Filters
• Port Filters
• Protocol Filters
• Specific patterns

These settings are delivered by the Network Security system using a Network Security Configuration Object. The Example system provides a standard format for setting these configurations as well as a trust model for the management of these configurations.

The Example system enables signatures for malware or viruses to be uploaded to the Network Security Module using the YARA syntax to describe the signatures to be checked. The Network Security Module runs a YARA application that implements the checks that are defined by the YARA rules file.

• This structure should be delivered as a signed JSON object using JSON Object Signing described in IETF RFC 7515 .
• The object maybe optionally encrypted using JSON Web Encryption described in IETF RFC 7516 .

The device shall always use HTTPS mutual authentication:

• Where both the client and the camera validate each other's certificates.
• In addition a whitelist may be enforced where the camera will only accept specific certificates if they appear in the whitelist.

Each security object shall have a time window parameter within the object outside of which the object shall not be processed by the receiving device.

• Each device shall have a real time clock.
• The synchronization of the clock is described in the Device Secure Time Section.

One of the challenges of the any security system is to enable the secure synchronization of time across the system. Having verifiable time is important for the following reasons:

1. For applications that require a trusted timestamping of SceneData.
   1. These may include applications such as surveillance where the footage may be used in legal proceedings or to prevent replaying of older versions of surveillance footage.
2. In the protocol security to prevent replay attacks.

The Network Time Protocol shall be used to enable cameras to securely determine time.

The following protocol shall be used to enable time synchronization between devices and a server:

• Network Time Protocol Version 4: Protocol and Algorithms Specification (https://tools.ietf.org/html/rfc5905)

This protocol is secured using:

• RFC 5906 Network Time Protocol Version 4: Autokey Specification (https://tools.ietf.org/html/rfc5906#appendix-D)

The messages shall be authenticated using the authentication defined within this specification.

• The Autokey Specification defines a Key exchange based on X.509 certificates.
  • The Example LA Root Certificate shall be used as the certificate for the time server.
  • The Device Certificate shall be used for the device to authenticate with the time server.