CN110476432B - Protection of surveillance media - Google Patents

Abstract

The media device receives a domain key from a service provider. The media device further encrypts the media using a media key and the domain key to form an encrypted media token: the protected media key is encapsulated in the encrypted media token. The service provider may then receive the encrypted media token and one or more recipient entity identifiers associated with the recipient entity and determine whether the recipient entity has access to the media from the media device. If the receiving entity has access to media from the media device, the service provider decrypts an encrypted media token using the domain key to obtain the media key and provides the media key to the receiving entity. In this way, the authenticated receiving entity can obtain the media key necessary to decrypt the media. Furthermore, there is no need for any intermediate entity to have similar access, and therefore the encryption provided by the media key is in place throughout the transmission of the media from the media device to the receiving entity.

Description

Protection of surveillance media

technical field

The present disclosure relates to the protection of media generated by media devices, such as monitoring devices. Specifically, but not exclusively, the present disclosure relates to ensuring the confidentiality of media generated by surveillance cameras.

Background technique

Many video surveillance systems protect the generated surveillance media content during transmission between the elements of the system. For example, where a camera generates a media stream for viewing at a remote device, it is mandatory in the transmission of the media stream between elements of the system such as the camera, the remote device, and any intermediary devices through which the media stream is transmitted Confidentiality of the media.

As a result, outside of the secure communication phase between system elements, there is often no protection enforcement and media content is effectively unprotected, vulnerable and can be disclosed. Access control with proper policy management is not always or weakly implemented on one or more elements of the system, which means that in elements without effective access control or monitoring, unauthorized access can be made without authorization. Protected media content; media content is unprotected and vulnerable when access control or monitoring at any element is hacked or otherwise bypassed.

Description of drawings

1 is a schematic diagram of a system for implementing the preferred embodiment;

Fig. 2 is the schematic diagram of Fig. 1, wherein additional information represents processing steps at each entity;

FIG. 3 is a flowchart illustrating the process of the preferred embodiment; and

Figure 4 shows the hardware infrastructure used to implement the preferred embodiment.

Detailed ways

In summary, methods according to the present disclosure include protecting media generated by a media device with a media key, and protecting the media key with a domain key to form an encrypted media token. When a receiving entity wishes to access the media, the trusted service provider can authenticate the receiving entity and decrypt the encrypted media token to obtain the media key for use by the receiving entity to decrypt the media. In this way, the media can be protected by the media device that generated it without subsequent decryption until the media appears at an authorized receiving entity. The intermediate entity does not need to have access to the decrypted media. The present disclosure also provides a computer-readable medium and system configured to perform the method.

In some aspects of the present disclosure, a method for protecting media content in a network is provided, comprising the steps of: a media device receiving a domain key from a service provider. The media device also encrypts the media with the media key and encrypts the media key with the domain key to form an encrypted media token: encapsulates the protected media key in the encrypted media in the token. The service provider may then receive the encrypted media token and one or more recipient entity identifiers associated with the recipient entity and determine whether the recipient entity has access to the media from the media device. If the receiving entity has access to the media from the media device, the service provider decrypts an encrypted media token using the domain key to obtain the media key and provides the media key to the receiving entity. In this way, an authenticated recipient entity can obtain the media key necessary to decrypt the media. Furthermore, no intermediate entities are required to have similar access, so the encryption provided by the media key is in place throughout the transmission of the media from the media device to the receiving entity.

In some implementations, the media key is generated at the media device. Alternatively, the media device may receive the media key from an external source (eg, the service provider). The media key may be, for example, randomly generated.

Optionally, the domain key is associated with a domain that defines one or more media devices within the network. Thus, the domain key may be public to more than one media device. A given media device may be added to or removed from a domain over time, allowing access to media from that media device to be controlled through a process of authenticating the receiving entity. The receiving entity may be authenticated prior to the step of determining whether the receiving entity has access to media from media devices within the domain associated with the domain key.

The media device may receive the domain key from the service provider in encrypted form using one or more media device identifiers. In this way, the service provider can ensure the security of the transmission of the domain key to the media device.

The encrypted media token may include metadata associated with the domain key. In this case, the protected media key is encapsulated in an encrypted media token with metadata. For example, the metadata may identify the domain with which the domain key is associated, or may allow identification of the domain key in some other manner. This can help the service provider locate the domain key to be used to decrypt encrypted media tokens.

In some implementations, the media device sends an encrypted media token to the receiving entity, and the service provider receives the encrypted media token from the receiving entity. For example, an encrypted media token may be sent to the receiving entity along with the media itself. In other examples, the encrypted media token may be sent to the receiving entity in an out-of-band communication (eg, separate from the media). The encrypted media token may be sent directly from the media device to the receiving entity, or may be sent via one or more intermediary entities.

The service provider may receive the encrypted media token in encrypted form using one or more receiving device identifiers. Alternatively or additionally, the service provider may provide the media key to the receiving entity in encrypted form using one or more receiving device identifiers. The method can help secure communications between the receiving entity and the service provider.

One or both of the media key and the domain key may change periodically. In this way, security can be improved. Changing the media key or the domain key may result in regeneration of encrypted media tokens. For example, the media stream may include data packets, and each data packet may be encrypted using the media key prior to transmission from the media device. If the media key is changed, eg, after a predetermined length of time or after a predetermined number of packets, subsequent packets of the same media stream are encrypted using the updated media key.

The media may include audio and/or visual content. The visual content may include video or one or more still images. The media may also include metadata. Such metadata may include, for example, alert indications designed to alert the user. The media may be streaming media. The media may be generated by the media device in real time. The media device may include a camera. For example, the media device may be a surveillance camera such as a mobile surveillance camera. For example, the media device may be a drone, a robot, or a wearable camera. The media device may be, but is not limited to, any other device capable of processing or generating media.

In some aspects of the present disclosure, there is provided a computer-readable medium comprising computer-executable instructions for performing the method of the above-described aspects. Furthermore, other aspects of the present disclosure provide a system configured to perform the methods.

In some aspects of the present disclosure, a system for protecting media content in a network including media devices and service providers is provided. The media device is configured to: receive a domain key from the service provider; and encrypt media with the media key, and encrypt the media key with the domain key to form an encrypted media token Card. the service provider is configured to: receive an encrypted media token and one or more recipient entity identifiers associated with the recipient entity; determine whether the recipient entity has access to media from the media device; and, if The receiving entity has access to the media from the media device, decrypts the encrypted media token using the domain key to obtain the media key and provides the media key to the receiving entity. Optional features of the method can also be applied to the system. The system may also include the receiving entity. The receiving entity may be configured to decrypt the media using the media key received from the service provider.

Some specific embodiments will now be described by way of illustration with reference to the accompanying drawings.

Referring to Figure 1, a system comprising a camera device 11, one or more intermediary devices 20 and a receiving entity 30 is shown. The camera device is a media device that can generate media to be received by the receiving entity 30 . The media generated by the camera 11 may be sent to the receiving entity 30 via one or more intermediate entities 20 .

The camera device 11 may be part of any fixed or mobile surveillance system such as a drone, robot or wearable device. In general, it can be any device capable of processing or generating media content. The intermediate entity 20 may be any network element capable of passing network traffic, while the receiving entity 30 may be any suitable device for playback or processing of media. The receiving entity 30 may be located in a surveillance control room or any other desired location, and may be fixed or portable. The receiving entity 30 may be, for example, a network-enabled end-user device such as a laptop computer, personal computer, tablet computer, smartphone, or the like.

Also shown as part of the system of FIG. 1 is a license provisioning service 40 . This acts as a service provider and can communicate with the policy manager 50 . Also shown is a secret provisioning service 60, which may optionally be provided to communicate with the camera device 11 and the receiving entity 30.

The license provision service 40, the policy manager 50 and the secret provision service 60 may act cooperatively as a service provider. Each of them can be implemented as a cloud-based service, or can be implemented on a defined physical device such as a server.

Generally, each element shown in FIG. 1 may be implemented on one or more computing devices, further details of which are set forth below with reference to FIG. 4 .

The operation of the system of FIG. 1 can be understood with reference to FIGS. 2 and 3 . Figure 2 illustrates the system of Figure 1 with additional reference numerals identifying communications within or between system elements associated with the processing steps described below. The numbers in Figure 2 are associated with paragraph numbers "1" to "10" below. Figure 3 is a flow chart providing further explanation of certain process steps and illustrating the steps in one possible order.

1 - At step s31, the camera 11 is configured with a device unique secret. There are one or more identifiers associated with the camera 11 . These secrets can be software or hardware based. These secrets can be pre-provisioned at the time of manufacture or over-the-air, as shown in option 1d of the secret provisioning service 60 in Figure 2 .

2- A camera is associated with a domain. This field connects or associates the camera with the area it covers. At step s32, a domain key may be generated by the license providing service 40 for the domain. At step s34, which may occur during the installation of the camera 11, the unique domain key is provided from the license providing service 40 in an over-the-air manner. The domain key is securely protected when transmitted to the camera 11 using the available device unique secret. When a camera is installed in a new area or an existing area is divided into a new domain, a new unique domain key is provided to the camera.

3- At step s35, the camera 11 may generate a media key which is used to encrypt the media generated by the camera at step s36. At step s37, the media key is protected with a unique domain key and an encrypted media token is generated. Encrypted media tokens include protected media keys and additional metadata. Any relevant information may be recorded in the metadata, such as information identifying the domain associated with the camera 11 . Since the media is encrypted within the camera 11, it is protected when it leaves the camera 11 to be sent elsewhere. For example, at step s38, the media encrypted by the media key is sent to the receiving entity 30. As shown in FIG. 2 , the sending may take place via one or more intermediary entities 20 . The encrypted media token is also sent to the receiving entity 30 at step s29. Depending on the streaming format, the encrypted media token can be embedded in the protected camera media content or sent using an out-of-band channel.

4- At step s33, the receiving entity 30 may be configured with an entity unique secret. These entity-unique secrets serve as one or more identifiers associated with the receiving entity. Secrets can be software or hardware based. These secrets can be pre-provisioned at the time of manufacture or over-the-air, as shown in option 1d of the secret provisioning service 60 in Figure 1 .

5- After step s39 above, the receiving entity has received the encrypted media token from the camera 11. The receiving entity may extract the token from the media stream if desired. In some alternatives, the receiving entity will obtain the token from an out-of-band channel. Then, at step s40, the receiving entity 30 provides the encrypted media token to the license providing service 40. The encrypted media token is provided in the form of a cryptographic challenge protected with the entity's unique secret. This cryptographic challenge is used to authenticate the receiving entity 30 .

6 - The license offering service 40 verifies the cryptographic challenge that authenticated the receiving entity 30 in the previous step 5 and extracts the encrypted media token. The license provisioning service 40 identifies the domain from the metadata encapsulated in the encrypted media token. The license providing service 40 can then confirm whether the receiving entity is authorized to access the media from the camera 11 . If the receiving entity 30 is authorized to access the domain by the policy manager 50, then at step s41, the license providing service 40 extracts the media key from the encrypted media token using the domain key. The license provisioning service 40 then generates an encrypted physical token that encapsulates the media key with the relevant usage rules. The encrypted entity token is protected using an entity unique secret known to the receiving entity 30 rather than a domain key unknown to the receiving entity 30, and the encrypted entity token is provided back to the receiving entity 30 at step s42.

7- The receiving entity 30 then verifies the encrypted entity token received from the license providing service 40. Then, at step s43, the receiving entity 30 can extract the media key and thus can decrypt the protected camera media content according to the relevant usage rules. The resulting unprotected camera media content may be accessed and/or processed by the receiving entity.

8- As an option, and to improve the protection of the camera's media content, the media key can be changed periodically. For example, the media stream may include data packets, and each data packet is encrypted using a media key before being sent from the camera 11 . If the media key is changed, eg, after a predetermined length of time or after a predetermined number of packets, subsequent packets of the same media stream are encrypted using the updated media key. In this case, the encrypted media token must be regenerated for each media key change and sent to the receiving entity 30 again. The method can help ensure communications between the receiving entity and the service provider by requiring the receiving entity to be re-authenticated using the regenerated encrypted media token, even if the receiving entity was originally authorized to decrypt the media stream.

9- Similarly, domain keys can be changed periodically for the same reason. In this case, a new media key and a new encrypted media token must be generated for each domain key change and sent to the receiving entity 30 again.

10- Since the proposed camera media content protection scheme preserves the properties of the content format, any intermediate entity not authorized to access unprotected camera media content can still record protected camera media content without privacy concerns . The recorded camera media content can be reproduced anywhere without privacy concerns; the camera media content remains protected and access to the camera media content requires authentication of the entity that needs to access or process the camera media content and as in 5, 6 and 7 The described verification by the license providing service 40.

This process can uniquely protect content from cameras 11 or other media devices and provide protection of the media regardless of the number of devices such as intermediaries 20 involved in the processing chain.

4 illustrates a block diagram of one embodiment of a computing device 300 in which a set of instructions may be executable to cause the computing device to perform any one or more of the methods discussed herein. Computing device 300 may be used with elements of the systems shown in FIGS. 1 and 2 . In alternative implementations, the computing device may be connected (eg, networked) to other machines in a local area network (LAN), intranet, extranet, or the Internet. A computing device may operate in the capacity of a server or client machine in a client-server network environment, or as a peer-to-peer machine in a peer-to-peer (or distributed) network environment. The computing device may be a personal computer (PC), tablet computer, set-top box (STB), personal digital assistant (PDA), cellular phone, network device, server, network router, switch or bridge, or capable of performing the actions specified for the machine to take. Action's instruction set (sequential or otherwise) for any machine. Furthermore, although only a single computing device is shown, the term "computing device" should also be understood to include executing a set of instructions (or sets of instructions), individually or jointly, to perform any one or more of the methods discussed herein any collection of machines (eg, computers).

Exemplary computing device 300 includes processing device 302, main memory 304 (eg, read only memory (ROM), flash memory, dynamic random access memory such as Synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.) in communication with each other via a bus 330. fetch memory (DRAM), etc.), static memory 306 (eg, flash memory, static random access memory (SRAM), etc.), and secondary memory (eg, data storage device 318).

Processing device 302 represents one or more general-purpose processors, such as microprocessors, central processing units, or the like. More specifically, the processing device 302 may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing other instruction sets, or A processor that implements combination of instruction sets. Processing device 302 may also be one or more special purpose processing devices, such as application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, and the like. Processing device 302 is configured to perform processing logic operations (instructions 322) for performing the operations and steps discussed herein.

Computing device 300 may also include a network interface device 308 . Computing device 300 may also include a video display unit 310 (eg, liquid crystal display (LCD) or cathode ray tube (CRT)), alphanumeric input device 312 (eg, keyboard or touch screen), cursor control device 314 (eg, mouse or touch screen) ) and audio equipment 316 (eg, speakers).

Data storage device 318 may include one or more machine-readable storage media (or more specifically, one or more non-transitory computer-readable storage media) 328 on which One or more sets of instructions 322 are stored that embody any one or more of the methods or functions described herein. During execution of instructions 322 by computing device 300, instructions 322 may also reside entirely or at least partially within main memory 304 and/or within processing device 302, which also constitute computer-readable storage media.

The various methods described above can be implemented by computer programs. The computer program may comprise computer code arranged to instruct a computer to perform the functions of one or more of the various methods described above. Computer programs and/or code for performing the methods may be provided to an apparatus such as a computer on one or more computer-readable media, or more generally, a computer program product. Computer readable media may be transitory or non-transitory. The one or more computer-readable media may be, for example, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, or a propagation medium for data transmission, such as for downloading code over the Internet. Alternatively, the one or more upper computer readable media may take the form of one or more physical computer readable media, such as semiconductor or solid state memory, magnetic tape, removable computer disk, random access memory (RAM), read only memory (ROM), rigid disks and optical disks such as CD-ROM, CD-R/W or DVD.

In one embodiment, the modules, components, and other features described herein (eg, with respect to control unit 310 of FIG. 4 ) may be implemented as discrete components or integrated in hardware components (eg, ASICS, FPGA, DSP, or similar devices) ) as part of the Personalization Server.

A "hardware component" is a tangible (eg, non-transitory) physical component (eg, a collection of one or more processors) capable of performing particular operations, and may be configured or arranged in a particular physical manner. Hardware components may include special purpose circuits or logic devices that are permanently configured to perform particular operations. The hardware components may be or include special purpose processors, such as field programmable gate arrays (FPGAs) or ASICs. Hardware components may also include programmable logic devices or circuits that are temporarily configured by software to perform certain operations.

Accordingly, the phrase "hardware component" should be understood to include a tangible entity that may be physically constructed, permanently configured (eg, hardwired) or temporarily configured (eg, programmed) to operate in a particular manner or Perform specific actions described in this article.

Additionally, modules and components may be implemented as firmware or functional circuits within a hardware device. Furthermore, modules and components may be implemented in any combination of hardware devices and software components, or only in software (eg, code stored or otherwise embodied in a machine-readable medium or transmission medium).

Unless expressly stated otherwise from this disclosure, as will be clear from the following discussion, it should be understood that throughout Terms such as "replacement", "replacement" and the like refer to the actions and processes of a computer system or similar electronic computing device that manipulates and converts data represented as physical (electronic) quantities within the registers and memory of the computer system into the computer system A memory or register or other such information stores, transmits or displays other data similarly represented as physical quantities within the device.

It should be understood that the above description is intended to be illustrative, and not restrictive. Many other implementations will be apparent to those skilled in the art upon reading and understanding the above description. Although the present disclosure has been described with reference to specific exemplary implementations, it will be recognized that the present disclosure is not limited to the described implementations, but can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. Therefore, the scope of the disclosure should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims (15)

1. A method for protecting media content in a network, the method comprising: At the media device: receive a domain key from a service provider; and encrypting media generated by the media device with a media key and encrypting the media key with the domain key to form an encrypted media token; The method also includes, at the service provider: receiving the encrypted media token and one or more recipient entity identifiers associated with the recipient entity; determining whether the receiving entity has access to media from the media device; and If the receiving entity has access to the media from the media device, decrypt the encrypted media token using the domain key to obtain the media key and provide the media key to the the receiving entity; and If the receiving entity does not have access to the media from the media device, then the encrypted media token is not decrypted using the domain key to obtain the media key; wherein, The media includes data packets, each data packet encrypted using the media key prior to transmission from the media device, and if the media key is changed, after a predetermined number of data packets, the changed media key is used Encrypt subsequent data packets of the same media stream. 2. The method of claim 1, further comprising generating the media key at the media device. 3. The method of claim 1 or 2, wherein the domain key is associated with a domain defining one or more media devices within the network. 4. The method of claim 3, wherein authenticating the receiving entity comprises establishing that the receiving entity is authorized to access media from media devices within the domain associated with the domain key. 5. The method of claim 1, wherein the media device receives the domain key in encrypted form using one or more media device identifiers. 6. The method of claim 1, wherein the encrypted media token includes metadata associated with the domain key. 7. The method of claim 1, wherein the media device sends the encrypted media token to the receiving entity, and wherein the service provider receives the encrypted media from the receiving entity token. 8. The method of claim 1, wherein the service provider receives the encrypted media token in encrypted form using one or more receiving device identifiers. 9. The method of claim 1, wherein the service provider provides the media key to the receiving entity in encrypted form using one or more receiving device identifiers. 10. The method of claim 1, wherein the media key is changed periodically. 11. The method of claim 1, wherein the domain key is changed periodically. 12. The method of claim 1, wherein the media comprises audio and/or visual content. 13. The method of claim 1, wherein the media device comprises a camera. 14. A computer-readable medium comprising computer-executable instructions for performing the method of any of claims 1-13. 15. A system for protecting media content in a network comprising media devices and service providers, wherein: The media device is configured to: receiving a domain key from the service provider; and encrypting media generated by the media device with a media key and encrypting the media key with the domain key to form an encrypted media token; and wherein the service provider is configured to: receiving the encrypted media token and one or more recipient entity identifiers associated with the recipient entity; determining whether the receiving entity has access to media from the media device; and If the receiving entity has access to the media from the media device, decrypt the encrypted media token using the domain key to obtain the media key and provide the media key to the the receiving entity; and If the receiving entity does not have access to the media from the media device, then the encrypted media token is not decrypted using the domain key to obtain the media key; wherein, The media includes data packets, each data packet encrypted using the media key prior to transmission from the media device, and if the media key is changed, after a predetermined number of data packets, the changed media key is used Encrypt subsequent data packets of the same media stream.

Images