To ensure the security of Example data of any sensitive nature, there are several aspects relating to security that need to be handled by the Example specification. The major security assets in the system are the user's account, the cameras, data (DeviceMarks and DeviceData) and Applications. See the following tabular data table.

Major security assets and threats with counter measures in the Example system

Asset	Attack	Attacker Motivation	Counter Measure
Account	Hijack of Account Full access to cameras and data	Ransom Invasion of Privacy Disable Physical Security Fraud	Managed Credentials Revocable OAuth Tokens with limited access and time of access.
Camera	Access Data Disable/Reconfigure Rogue Computing Denial of service, Bitcoin Mining	Ransom Invasion of Privacy Disable Physical Security Fraud Denial of Service attacks Bitcoin Mining	Managed Credentials Managed Keys with mutual TLS White & Black Lists Firmware Signing IP Address White & Black Lists File Inspection Secure configuration of ports Implementation Requirements
Data	Access Data Publish Data, use data to commit crimes Modify Data	Ransom Invasion of Privacy Fraud Social Engineering	Data Encryption Privacy Rights Management Limited access to data Defines how data may be used Implementation Requirements
App	Fake App Steal User Credentials Reverse Engineering of App Steal App Credentials	Implement attacks listed above	Manage Unique App Key Managed Credentials Privacy Rights Management Implementation Requirements

The following functionality is used to protect these assets:

1. Device:
   1. Device Credential Management
   2. Device Management:
      1. Network Security
      2. Secure Time
      3. Code Signing
2. User Account:
   1. Access Control
3. Data:
   1. Privacy Management System
4. Application:
   1. Application Key
   2. Credential Management
   3. Privacy Management System

▲ Top

Key to any security system are the roles of parties in the system and how trust is managed. This section describes the hierarchy of entities that manage trust, and how end users and devices fit into the trust model. Access Control, Privacy Management and Network Security all conform to this trust model.

The highest authority in the Example ecosystem is the Example Licensing Authority (NLA). This authority issues certificates to participants in the Example Ecosystem. The hierarchy of the Example Ecosystem is shown in the following figure. The certificates used to create this hierarchy conform to the X.509 standard.

Note: Depending on the stage of the device's life cycle the Camera Manufacturer or the Example Camera Seller may be able to manage the Firmware Update. For this reason the certificate for the Firmware update service may be changed by the Example LA to allow the Example Camera Seller to take control of the update from the Camera Manufacturer.

The following roles are defined in the Example ecosystem:

• Example Licensing Authority
• Example Account Service
  • Account Management Service
  • Access Control Service
  • Privacy Management Service
  • Network Security Service
• Example Camera Manufacturer
• Example Camera Seller
• 3rd Party Apps

Example Licensing Authority

The Example Licensing Authority provides root certificates for the participants in the Example ecosystem. It effectively brokers trust between the camera manufacturers and the providers of Example Account Services.

• Each camera in the Example Ecosystem is issued a Certificate and Private Key by the Example Licensing authority.
• Each Account Service in the Example Ecosystem is provided a Certificate by the Example Licensing Authority.

Example Account Service

Each Example Account Service is issued a Certificate and Private Key by the Example Licensing Authority. The Example Account Service creates its own trusted ecosystem of Service Providers and 3rd party Apps. The Example Account Service operates the Account Management Service, Privacy Management Service, Device Data Service, Network Security and Access Control Services.

The end consumer or enterprise selects a Example Account Service, creates a user account and then links their cameras to their account. The camera validates that the Example Account Service is a valid service based on the certificate provided by the Example Licensing Authority. The Example Account Service validates that the camera is a valid Example camera based on the certificate issued to the camera by the Example Licensing Authority.

Account Management Service

The end consumer or enterprise selects a Example Account Service, creates a user account, and then links their cameras to their account.

• The Camera validates that the Example Account Service is a valid service based on the certificate provided by the Example Licensing Authority.
• The Example Account Service validates that the camera is a valid Example camera based on the certificate issued to the camera by the Example Licensing Authority.

The linkage of the Example camera to the Example Account Service is performed when the end user configures the camera.

• A Example camera may only be linked to one Example Account Service at a time.
• It is possible for a user to decouple a camera from a Example Account Service and couple it to a different Example Account Service.
• A user may grant ownership of a camera to another user. In doing so the original user deactivates the camera from their User Account. The Example Account Service must notify the Example LA, so that the Example LA can set the camera back to being available to be assigned to another User Account. The second user can then couple the camera to their User Account.

The mechanism that is used to enable the user of the camera to extract the Camera ID and Password is determined by the camera manufacturer. These may include a local login to the camera, NFC communication with a mobile device, etc. The user uses the Camera ID and Password to enable the Example LA to assign the camera to the user's account.

Access Control Service

The Example Account Service is also responsible for managing access control of the end user account credentials.

• The Example Account Service shall provide a high priority notification to the end user if and when the control of the camera is transferred.
• The Example Account Service should also consider the usage of multi-factor authentication to enable recovery in case of the loss of account ID and password.
• These may include messaging using mobile telephone number, email or may involve the use of other security tokens and forms of identification to validate the transfer of the camera.

Privacy Management Service

This service is provided by the Example Account Service.

• It manages the security of data generated by any party in the system.
• A camera that creates Device Data uses keys provided to it by the Privacy Management Service to encrypt the Device Data that it generates.
• The Privacy Management Service manages who can access the Device Data and what the entity may do with the Device Data by issuing Privacy Objects which contain the Keys that enable the entity to decrypt the data and rules that determine what the entity may do with the decrypted Device Data.
• The Privacy Objects may also determine whether the Entity may export data and if so the keys that should be used to encrypt the exported data.

The Privacy Management Service controls which entities may access this extended Device Data by using Privacy Objects to control access to it.

• The Privacy Management Service is a component of the Example Account Service.
• The recipient of a Rights Object shall conform to the implementation guidelines of the Example LA.
• These guidelines include the requirement for the receiver of the Rights Object to obey the conditions specified in the rights object and what is needed to ensure that this is not bypassed in any way.

Network Security Service

This service is provided by the Example Account Service.

• It controls the configuration of the Network Security Function embedded in the camera.
• This includes the encryption keys used for any VPN connection with the camera, whitelists and blacklists and deep packet inspection.

Example Camera Manufacturer

The Camera Manufacturer provides a camera that is compliant to the Example APIs and to the Example security requirements.

• The Camera Manufacturer performs conformance testing of the product to ensure that the product is functionally conformant to the specifications provided by the Example LA.
• It also performs an audit on its implementation to ensure that it conforms to the Security Implementation Requirements defined by the Example LA.

The camera has a unique ID and private key embedded by the Camera Manufacturer.

• These are provided by the Example LA.
• These are used to set up secure communications with camera and to enable the camera to validate itself when interacting with either the Example Account Service or one of the systems within the Example Account Service's ecosystem.

Example Camera Seller

The Example Camera Seller is the entity that brands and markets the device.

• The Example Camera Seller notifies the Example LA of the cameras that it is selling into the market.
• If this information is not provided the Example LA will not enable activation of the device onto a Example Account Service.
• The Example Camera Seller is also responsible for issuing updates to the Device firmware signed under the firmware signing key.

3rd Party Apps

The Example Account Service controls the access that 3rd party apps have to data and cameras associated with the user's account.

• The configuration of Device and Capture modes is controlled through the OAuth protocol, while the access to Device Data is controlled through the privacy management system.
• Where the app is a client to the Privacy Management System, it is issued a certificate and private key by the Example Account Service.

▲ Top

The following objects are related to security in the Example Ecosystem:

• The Device Security Object is issued by the Example LA to the device manufacture to enable the manufacturer to embed credentials into the device during manufacture.
• The Example Licensing Authority Credential Object is issued by the Example License Authority and binds a device to a Example Account Service.
• The Example Account Service Credential Object configures the device to be managed by the Example Account Service, and the security settings of the device with respect to the security of the device on the network.
• The Access Token Object contains Access Tokens as defined by the OAuth2 protocol which enable an App or Service to access another Service or Device.
• The Privacy Rights Object is provided to a device, app or service to enable the device, app or service to either generate devicedata or process devicedata.
• The Network Security Object defines the security settings of the device with respect to the security of the device on the network.
• The Device Firmware Update Object enables the validation of a firmware update.
• The App Developer Security Package enables the app developer to access Example API's and process Example data.
• The Application Instance Security Object enables a specific instance of an App to access Example API's and process Example data.
• The Device Seller Object feeds back to the Example LA which devices the seller will be selling to consumers. This object is not encrypted or authenticated as it is used for administrative purposes only.

The Example Licensing Authority Credential Object is issued by the Example License Authority, and binds a device to a Example Account Service.

These objects are always encrypted using the Public Key of the device to which they are addressed.

The authentication of the objects depends on the object:

• The Example LA Credential Object is always signed by the Example Licensing Authority.
• The other objects are always signed by the Example Account Service.

▲ Top