Controlling application access

Privacy Management enables the Example Account Service under the instruction of the End User to control which applications may access which DeviceData or Cameras. It provides fine grain control over the window of access and which data items may be accessed.

Data that is produced by cameras and further enhanced by Example services is sensitive and requires management of who or may not access the data.

• Control over who may or may not access data is provided through the encryption of data and access is controlled through the distribution of keys to different entities accessing the data.
• Further control over the keys is applied by attaching usage rules to the keys that control how the data may be accessed, how it may be processed, and how the result of the processing may be distributed.
• These rules include a window of time during which data may be accessed, types of processing that may be applied to data, ability to forward the results of analysis of the data etc.

Each of the logical blocks may be implemented in either in the cloud, the camera, or on a mobile device.

The Privacy Management Service may define standard policies for how DeviceData is managed and encrypted. It may also define standard policies for how different Example service providers may access and process DeviceData.

▲ Top

Privacy Management Service

The Privacy Management Service manages the distribution of keys used to either decrypt or encrypt DeviceData. It is also responsible for defining the rules that are applied to access the DeviceData. This service may be cloud based or for simple systems may be implemented in an appliance or in an individual camera.

Keys are distributed by the Privacy Management Service through Rights Objects which include the following fields:

1. Identity of the receiving device or service.
2. Encrypted keys for encrypting or decrypting DeviceData.
3. Usage rules for keys.
4. Authentication field.

The cryptography used to secure the rights object is described in the rights object section.

• The privacy management system distributes the Rights Object to devices that are authorized to access DeviceData.

Each device, application or service shall have a public and private key pair and an X.509 certificate provided either by the Example licensing authority (cameras) or the Example Account Service (Apps, Example services).

• Any device provisioned with a certificate shall comply with the compliance criteria for either the Example licensing authority (cameras) or Nice Account Service (Apps, Example services).
• These compliance criteria describe how keys are to be secured and how the processing of rights objects is to be enforced.

Camera

The camera acts as a source of data. The Privacy Management Service provides a Rights Object to the Camera which enables the Camera to export data that it is capturing and the key that should be used to encrypt the data.

Sensor

The sensor may directly encrypt data before it leaves the sensor module. There are two methods that may be used to manage the keys used to encrypt the DeviceData leaving the sensor module:

1. Clear Key Exchange: A key is passed over the interface to the sensor which stores the key in non-volatile memory. The key should not be readable by any device outside of the sensor. The key should be configured once when a sensor is paired to a host device. This method reduces complexity in the sensor but has the weakness that when the key is written to the sensor an eavesdropper may access the key and breach the system.

   
   Clear Key Exchange.

2. Rights Object: The sensor has a private key and ID embedded. The Sensor provides its certificate to the Privacy Management Service. The Privacy Management Service provides a rights object to the sensor including the content encryption key to be used. The sensor uses the Content Encryption Key to encrypt any data that the camera outputs.

   
   Rights Object.

Example Service Provider

The Example Service Provider is issued a Private Public Key pair and X.509 certificate by the Example Account Service. The Privacy Management Service utilizes this public key to encrypt Rights Objects to enable the Example Service Provider to access DeviceData.

3rd Party Application

The 3rd Party Application is issued a Private and Public Key pair and X.509 certificate by the Example Account Service. The Privacy Management Service utilizes this public key to encrypt Rights Objects to enable the Example Service Provider to access DeviceData. Each instance of application has its own public private key pair.

Data Encryption

The camera acts as a source for DeviceData and DeviceMarks. When generating the DeviceData or DeviceMarks there is the option of encrypting the data or mark.

Each camera may have one or more sensors.

• Each sensor will have an unique ID.
• The Device Data or Mark Encryption Object configures whether the DeviceData generated by a specific sensor and DeviceMark generator for the device is encrypted or not.

If the data is encrypted, then a key delivered in the Device Data or Mark Encryption Object is used to encrypt the data.

• The Key ID for the Key is a system wide unique ID for a particular key value.
• The Key ID is used to link back to the Rights Object to enable the decryption of the content.

Encryption Object

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "title": "Device Data or Mark Encryption Object",
  "additionalProperties": false,
  "properties": {
    "Camera ID": {
      "type": "string",
      "description": "Camera ID issued by Example LA to camera"
    },
    "Encryption Object ID": {
      "type": "string",
      "description": "Unique ID for this object"
    },
    "Valid Start Date & Time": {
      "type": "string",
      "description": "Date and time from when the object is valid"
    },
    "Valid End Date & Time": {
      "type": "string",
      "description": "Date and time before which the object is valid"
    },
    "Sensor List": {
      "type": "array",
      "items": [
        {
          "type": "object",
          "properties": {
            "Sensor ID": {
              "type": "string"
            },
            "Encryption Enabled": {
              "type": "boolean",
              "description": "If TRUE then output of sensor shall be encrypted with attached key."
            },
            "Key ID": {
              "type": "string",
              "description": "Unique System Wide Key ID to be used to encrypt data - referenced in Rights Object used to access content."
            },
            "Encrypted Key": {
              "type": "string"
            }
          }
        }
      ]
    },
    "DeviceData Source ID": {
      "type": "object",
      "properties": {
        "Encryption Enabled": {
          "type": "boolean",
          "description": "If TRUE then output of sensor shall be encrypted with attached key."
        },
        "Key ID": {
          "type": "string"
        },
        "Encrypted Key": {
          "type": "string"
        }
      }
    }
  }
}

JSON Data Encryption

Device Data in JSON format is encrypted by using the JWE RFC 7516 JSON Web Encryption, using the A128CBC-HS256 algorithm defined in Section 5.1 of RFC 7518 JSON Web Algorithms .

• The Content Encryption Keys are distributed by the Privacy Management System as part of the Privacy Rights Object.
• Each JWE encrypted object shall have a unique identifier for the key that enables the Privacy Rights Agent in the Device/Service/App to reference a Privacy Rights Object addressed to the Device/Service/App that enables the decryption of the DeviceData.

Video/Audio Encryption

There are two types of delivery mechanisms that are used for video delivery – MPEG DASH or RTSP.

MPEG DASH : MPEG DASH is preferred for storage and applications that can utilize a delayed version of the video (typically greater than 10 seconds).

• Where MPEG DASH is utilized the encryption defined in MPEG DASH shall be used.
• The content encryption key carried in the privacy rights shall be used to encrypt and decrypt the video.
• The MPEG DASH format is compatible with the DRM and video playback in most mobile, PC and TVs.
• The DRM used in these devices can be used to control the playback of encrypted video.
• For this to occur the DRM servers which can address these devices shall be provided the content encryption key to be included into the DRM rights objects supported by these systems (these include Apple FairPlay, Widevine DRM and Playready DRM).
• MPEG DASH encryption is an authentication described in the MPEG document "Information technology – Dynamic adaptive streaming over HTTP (DASH) – Part 4: Segment encryption and authentication" .
• The DASH Interoperability Forum has defined how content packagers that implement the MPEG DASH encryption can exchange keys and other DRM information.
• The Privacy Management System can use these interfaces to request a compliant DRM implementation to generate Rights Objects that can be consumed by standard implementations of DRM in these devices.

This is described in the document: "DASH-IF Implementation Guidelines: Content Protection Information Exchange Format (CPIX)" .

RSTP : For applications that require real time streaming RTSP and RTP shall be used.

• SRTP shall be used to encrypt the video being streamed.
• The content encryption key used within SRTP is carried within the Privacy Rights Object.
• SRTP is described in RFC 3711 "The Secure Real Time Streaming Protocol" .

Privacy Objects

A Privacy Rights Object is a JSON object that contains the following information:

1. Content Encryption Key: This key is used to either decrypt or encrypt the DeviceData that is generated.
2. Processing rules regarding what may or may not be done with the DeviceData that has been encrypted.
3. A Key ID that matches the Key ID (MPEG DASH) or Master Key Identifier (SRTSP) that is used to encrypt the content.
4. A signature that is generated using the Private Key of the Account Service Provider.
   • Note: The privacy object shall be rejected if this signature check fails in any way.
5. The key objects are encrypted using the public key of the device, application or service that is consuming the Privacy Rights Object.

The following code block is the JSON schema for the Privacy Rights Management object.

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "title": "Rights Object Schema",
  "additionalProperties": false,
  "properties": {
    "Client ID": {
      "type": "number",
      "description": "Identity of client that is being enabled to access the data"
    },
    "Rights Object ID": {
      "type": "number",
      "description": "Unique ID of rights object issued by privacy management system"
    },
    "Start Date & Time ": {
      "type": "string",
      "description": "Date and Time from when object may be processed."
    },
    "End Date and Time": {
      "type": "string",
      "description": "Time from which the object is no longer valid and may longer be processed."
    },
    "Analysis Rule": {
      "type": "object",
      "properties": {
        "Analysis Allowed": {
        "type": "boolean",
        "description": "If TRUE then device data may be analysed."
      },
      "Export": {
        "type": "object",
        "description": "If ",
        "properties": {
          "Export Allowed": {
            "type": "boolean",
            "description": "If TRUE then result of analysis may be exported"
          },
          "Encryption Required": {
            "type": "boolean",
            "description": "If TRUE encryption must be encrypted with key within JSON object"
          },
          "Encryption Key ID": {
            "type": "number",
            "description": "Identifier for the Encryption Key"
          },
          "Encryption Key": {
            "type": "string",
            "description": "Key used to encrypt device data that is generated for export"
          }
        }
      }
    }
  },
  "Storage Rule": {
    "type": "object",
    "properties": {
      "Storage Allowed": {
        "type": "boolean",
        "description": "If TRUE the DeviceData may be stored."
      },
      "Encryption Required": {
        "type": "boolean",
        "description": "Encryption Required to Store the Device Data"
      },
      "Encryption Key ID": {
        "type": "number",
        "description": "ID of key used to encrypt stored Device Data"
      },
      "Encryption Key": {
        "type": "string",
        "description": "Encryption key used to encrypt any stored Device Data"
      }
    }
  },
  "Export Rule": {
    "type": "object",
    "description": "Rules concerning forwarding of Device Data",
    "properties": {
      "Export Allowed": {
      "type": "boolean",
      "description": "If TRUE device data may be exported"
      },
      "Encryption Required": {
        "type": "boolean",
        "description": "If TRUE then DeviceData must be encrypted using supplied key."
      },
      "Key ID": {
       "type": "number",
       "description": "ID of key to be used to encrypt exported DeviceData."
      },
      "Encryption Key": {
        "type": "string",
        "description": "Key to be used to encrypt exported DeviceData."
      }
    }
  },
  "View Rule": {
    "type": "object",
    "properties": {
      "Viewing Allowed": {
      "type": "boolean"
      }
    }
  },
  "Capture Rule": {
      "type": "object",
      "properties": {
        "Exclude": {
          "type": "array",
          "items": [
            {
              "required": [
                "Face",
                "Text",
                "License Plate"
              ]
            }
          ]
        },
        "Include": {
          "type": "array",
          "items": [
            {
              "required": [
                "Include All",
                "Face",
                "Text",
                "License Plate"
              ]
            }
          ]
        },
        "Key ID": {
          "type": "number"
        },
        "Encrypted Key": {
          "type": "string"
        }
      }
    },
    "Access Rule": {
      "type": "object",
      "properties": {
        "Access Conditions": {
          "type": "array",
          "description": "Conditions under which data may be accessed.",
          "items": [
            {
              "description": "Restrictions on Accessing Data",
              "required": [
                "Unrestricted",
                "Emergency Only"
              ]
            }
          ]
        }
      }
    }
  }
}

▲ Top

Description

The creation of a DeviceMark entails the capture of DeviceData, the capture of Metadata regarding the DeviceData capture, and then augmenting the Metadata by performing an analysis of the DeviceData and already generated Metadata to create new Metadata.

• A DeviceMark may be constructed over time by different systems.
• The DeviceMark may be appended to years after the original DeviceData was captured.
• For example if a particular Device has high importance and a new algorithm becomes available it may make sense to append the output of the new algorithm to the existing DeviceMark for that device.

It may also be important to be able to track which systems have added which data to the DeviceMark and to ensure that no system has altered the DeviceMark.

• For example the camera capturing the DeviceData may sign the DeviceData to prove that no subsequent system has altered the original DeviceData.
• The camera may have a motion detection capability. On detection of motion, the camera creates a DeviceMark which contains the time and a reference to the video file containing what triggered the motion detection.
• This video itself may be signed and the DeviceMark generated by the camera is signed with the camera’s private key.
• A different system may then process the video and DeviceMark to recognize a face in the video. This system may append the identity of the face to the DeviceMark and sign the combined DeviceMark.

A party wishing to verify the origin of the data on the DeviceMark and video is then able to verify that the camera generated the video and the first part of the DeviceMark which indicated motion and that the second system appended the actual identity of a face to the DeviceMark.

Chaining of Signatures

RFC 7515 defines a signing of a JSON data structure.

• Using this method a sequence of signatures can be created which enable first party to sign a JSON structure.
• A second party can then include the signature generated by the first party into a JSON structure that incorporates additional DeviceData to the first set of DeviceData in the DeviceMark.
• The signature shall be a hash of the cleartext of the DeviceMark before encryption is applied.

▲ Top