ES3068014T3 - Procedimiento y dispositivo de protección de un flujo entrante comprendiendo un flujo elemental constituido por paquetes de vídeo - Google Patents

Abstract

Este método de protección de un flujo entrante (10), que comprende al menos un flujo elemental de vídeo entrante (11), y que comprende una sucesión de paquetes de vídeo entrantes (12), se caracteriza por: el desensamblaje (32) del flujo entrante para separar un paquete actual; el cifrado del paquete actual con una clave de sesión (TEK); la construcción (35) de un paquete de metadatos de confidencialidad que comprende un campo de marca de tiempo correspondiente a una marca de tiempo del paquete actual y un campo de confidencialidad que contiene la clave de sesión; el cifrado del paquete de datos de confidencialidad con una clave de cifrado (KEK); el ensamblaje (36) de un flujo saliente (20) que comprende un flujo elemental saliente que agrupa los paquetes actuales cifrados (22) y un flujo elemental de metadatos de privacidad que comprende los paquetes de metadatos de privacidad cifrados (26). (Traducción automática con Google Translate, sin valor legal)

Description

[0001] DESCRIPCIÓN

[0002] Procedimiento y dispositivo de protección de un flujo entrante comprendiendo un flujo elemental constituido por paquetes de vídeo

[0003] La invención tiene como campo el de la protección de los flujos de datos, en particular de los flujos de datos de vídeo.

[0004] En el presente documento, el nivel de confidencialidad atribuido a un dato asocia una sensibilidad del propio dato ("secreto", "confidencial", "acceso restringido", etc.) a un derecho a conocer este dato atribuido a tal o cual consumidor o usuario de este dato.

[0005] La protección de un dato se entiende entonces como la atribución de un nivel de confidencialidad adaptado a ese dato.

[0006] En el estado de la técnica, la protección de un dato se realiza a nivel de red. Se trata de segregar diferentes perímetros dentro de una red y de asignar un nivel de confidencialidad particular a cada perímetro. Por lo tanto, cada perímetro es homogéneo en términos de sensibilidad de los datos que circulan en él y del derecho de acceso de los usuarios (un usuario con derecho de acceso a un perímetro tiene derecho a conocer todos los datos que circulan en ese perímetro). Por lo tanto, este modelo de protección se centra en la red y no en los datos en sí.

[0007] Sin embargo, los paradigmas "data centric security" ("seguridad centrada en los datos") o "zero trust" ("confianza cero") tienen como objeto general volver a centrar las medidas de protección en los datos para permitir una mayor flexibilidad en la gestión de los datos, y esto a lo largo de todo el ciclo de vida de cada dato.

[0008] El ciclo de vida de un dato se entiende desde la producción de este dato por un emisor o productor, su transmisión a un destinatario o consumidor, y el uso de este último (el uso puede ser el simple almacenamiento de los datos).

[0009] En el marco del paradigma "data centric security", nos gustaría poder proteger los datos de un flujo de datos de vídeo (o flujo de vídeo).

[0010] En el caso, por ejemplo, de un flujo de vídeo generado por una cámara de vigilancia, se desearía, por ejemplo, que las imágenes entregadas por esta cámara pudieran ser vistas por todos los usuarios cuando estén en baja resolución, y que, cuando esta cámara esté controlada para proporcionar imágenes de alta resolución, estas imágenes solo puedan ser vistas por usuarios autorizados.

[0011] Una solución podría ser codificar las imágenes cuando estén reservadas para un usuario autorizado y permitir su decodificación solo cuando el usuario haya sido identificado correctamente. Sin embargo, esta técnica de protección es binaria ya que una imagen solo puede estar en dos estados, codificada o no codificada.

[0012] El documento US 2018/331824 A1 describe la protección de un flujo de paquetes de datos. Un primer motor encripta la carga útil de un paquete con una clave simétrica y asocia a esta carga útil encriptada un encabezado comprendiendo una etiqueta temporal y un índice. Al mismo tiempo, cada clave simétrica está protegida por medio de una clave pública compartida entre los usuarios por un segundo motor. Cada clave simétrica encriptada está asociada a un índice para establecer una correspondencia con la carga útil encriptada de un paquete del flujo.

[0013] Nos gustaría tener más flexibilidad al disponer de un medio que permita proteger los datos de un flujo de vídeo en el nivel más adecuado, especialmente teniendo en cuenta a los productores y consumidores de este dato.

[0014] La presente invención tiene como objeto resolver este problema proponiendo un procedimiento y un dispositivo de protección multinivel de un flujo de vídeo.

[0015] Por ello, la invención tiene por objeto un procedimiento, un dispositivo de protección y un programa informático, tal y como se describe en las reivindicaciones adjuntas.

[0016] La invención y sus ventajas se comprenderán mejor tras leer la descripción detallada que sigue de dos ejemplos de realización particulares, que se ofrecen únicamente a título ilustrativo y no limitativo, y que se realiza haciendo referencia a los dibujos adjuntos, donde:

[0017] - [Fig. 1] la Figura 1 es una representación esquemática, en forma de módulos funcionales, de un dispositivo de protección según una primera realización de la invención;

[0018] - [Fig.2] la Figura 2 es una representación en forma de bloques del procedimiento de protección llevado a cabo por el dispositivo de la figura 1; y,

[0019] - [Fig. 3] la Figura 3 es una representación esquemática, en forma de módulos funcionales, de un dispositivo de protección según una segunda realización de la invención.

[0020] De manera general, la invención se refiere a un dispositivo de protección, software o hardware, dispuesto en corte sobre una vía de transmisión de un flujo de datos de vídeo, entre un emisor y un destinatario de este flujo.

[0021] El flujo de vídeo se corta o paquetiza, es decir, se compone de una sucesión de paquetes. La parte de carga útil de un paquete respeta un CÓDEC de vídeo.

[0022] El dispositivo de protección está adaptado para aplicar una política de privacidad que permita asignar un nivel de protección N adaptado a cada paquete del flujo de vídeo.

[0023] Este dispositivo de protección es adecuado para volver a emitir un flujo compuesto comprendiendo además de un flujo de vídeo saliente derivado del flujo de vídeo entrante, un flujo de metadatos de privacidad. El flujo de datos de salida respeta el formador MPEG-TS. Este flujo de metadatos también es un flujo paquetizado, ya que cada paquete de metadatos de privacidad está estrechamente asociado con uno o varios paquetes del flujo de vídeo.

[0024] A continuación, se describe una primera realización de la invención con referencia a las figuras 1 y 2.

[0025] Esta primera realización es adecuada para el tratamiento de un flujo entrante que contiene solo un flujo elemental de vídeo. El flujo elemental de vídeo es un flujo subdividido en paquetes de vídeo.

[0026] Se trata, por ejemplo, de un flujo bruto, a la salida de un dispositivo de adquisición, como una cámara de vigilancia.

[0027] Como se representa en la figura 1, el flujo entrante 10 (o contenedor) comprende un flujo elemental de vídeo 11. El flujo elemental de vídeo 11 está constituido por una sucesión de paquetes de vídeo 12.

[0028] En esta primera realización, el dispositivo de protección es una pasarela 30 situada en corte entre dos redes (no representadas en esta figura), la red de la fuente del flujo entrante 10 y la red del destinatario del flujo saliente 20, reemitida por el dispositivo de protección 30.

[0029] Una pasarela es un dispositivo comprendiendo medios de cálculo, como un procesador, y medios de almacenamiento, como una memoria. La memoria almacena las instrucciones de diferentes programas, cuya ejecución por el procesador permite dotar a la pasarela 30 de diferentes funcionalidades. En particular, la memoria de la pasarela 30 comprende las instrucciones de un programa de protección multinivel del flujo entrante.

[0030] La pasarela 30 aplica una política de protección a cada uno de los paquetes de vídeo 12 del flujo entrante. La pasarela 30 está configurada para aplicar esta política, que por lo tanto está preestablecida. La política de protección determina el nivel de confidencialidad N que debe asociarse al paquete de vídeo actual, según uno o varios indicadores, Id.

[0031] Más precisamente, la pasarela 30 comprende una interfaz de entrada 31, que es adecuada para la recepción del flujo entrante 10.

[0032] A continuación de la interfaz de entrada 31, la pasarela 30 comprende un módulo 32 de descomposición del flujo entrante 10. Este módulo tiene la función de aislar los diferentes paquetes de vídeo 12 del flujo elemental de vídeo 11 del flujo entrante 10.

[0033] Cada paquete de vídeo se aplica como entrada a un módulo 33 de filtrado. El módulo 33 tiene la función de determinar el valor del o de cada uno de los indicadores Id de la política de protección en el paquete de vídeo actual.

[0034] Un indicador puede ser un indicador de contexto, es decir, un parámetro externo al flujo entrante 10 y a la pasarela 30. A continuación, un tercero comunica dicho indicador a la pasarela 30. Es, por ejemplo, una fecha o un contexto operativo de implementación de la cámara, fuente del flujo de vídeo que debe protegerse.

[0035] Pero, preferentemente, un indicador es un elemento derivado del paquete de vídeo actual. Por ejemplo, el módulo 33 está adaptado para implementar un algoritmo de reconocimiento de imágenes que permita identificar en la o las imágenes del paquete de vídeo actual la presencia de un objetivo (en el caso, por ejemplo, de imágenes procedentes de una cámara de vigilancia). Si se detecta efectivamente un objetivo, un indicador de "presencia de objetivo" cambia del valor cero al valor unidad.

[0036] [0031]La pasarela 30 comprende, aguas abajo del módulo 33, un módulo 34 de decisión. El módulo 34, a partir de uno o varios de los indicadores Id determinados por el módulo 33 para el paquete de vídeo actual, decide el valor del nivel de confidencialidad N que debe asignarse a este paquete de vídeo actual.

[0037] La pasarela 30 comprende, aguas abajo del módulo 34, un módulo 35 de generación de paquetes de metadatos de confidencialidad. El módulo 35 comprende un submódulo 43 de concatenación de los diferentes campos que constituyen un paquete de metadatos de privacidad. Un paquete de metadatos de privacidad comprende un campo de etiquetado temporal que permite asociar un paquete de metadatos de privacidad a un paquete de vídeo asignándoles una misma fecha.

[0038] Un paquete de metadatos también comprende un campo de nivel de privacidad que indica el valor N calculado por el módulo 34 para el paquete de vídeo actual.

[0039] Por último, el paquete de metadatos también comprende un campo criptográfico.

[0040] El módulo 35 comprende un submódulo 42 de cifrado de un paquete de metadatos de privacidad. Según el valor de N que indica que el paquete de vídeo actual está reservado a destinatarios autenticados, el submódulo 42 selecciona una clave de seguridad adecuada para estos destinatarios y encripta el paquete de metadatos asociado al paquete de vídeo actual. El submódulo 42 usa una clave de seguridad, como una clave de encriptado de claves KEY ("key encryption key").

[0041] La clave de seguridad KEK se comparte entre la pasarela 30 y los destinatarios del flujo de vídeo que tienen derecho a conocer el contenido de este flujo. La forma de intercambiar las claves KEK entre pasarela y destinatario) es conocida como tal y no forma parte de la presente invención.

[0042] La pasarela 30 comprende un módulo 36 de asociación de flujos elementales, a la vez un flujo elemental de vídeo saliente 21 correspondiente al flujo elemental de vídeo entrante 11 y el flujo elemental de metadatos de privacidad 25 procedente del módulo 35 y compuesto por paquetes de metadatos de privacidad encriptados.

[0043] La pasarela 30 comprende un módulo criptográfico 40.

[0044] El módulo criptográfico 40 toma como entrada el paquete de vídeo actual emitido a la salida del módulo 32 de descomposición.

[0045] El módulo criptográfico 40 comprende un submódulo 41 adecuado para encriptar el paquete de vídeo actual por medio de una clave de sesión, por ejemplo, una clave de encriptado de tráfico - TEK ("traffic encryption key"). El submódulo 41 es capaz de generar una clave de sesión TEK por paquete de vídeo a proteger. El paquete de vídeo encriptado se transmite al módulo 36 de asociación. Los diferentes paquetes de vídeo encriptados 22 constituyen el flujo elemental de vídeo 21 del flujo de vídeo saliente 20.

[0046] El submódulo 41 transmite la clave de sesión TEK al submódulo 43.

[0047] Es esta clave TEK la que se coloca en el campo de encriptado del paquete de metadatos de privacidad asociado al paquete de vídeo actual.

[0048] Por último, la pasarela 30 comprende una interfaz de salida 37 que permite retransmitir el flujo saliente 20 construido por el módulo 36 en la red con destino al destinatario.

[0049] Por lo tanto, el flujo saliente 20 está constituido por un flujo elemental de vídeo 21 y un flujo elemental de metadatos de confidencialidad 25. El flujo elemental de vídeo está constituido por una sucesión de paquetes de vídeo 22. El flujo elemental de metadatos de privacidad 25 está constituido por una sucesión de paquetes de metadatos de privacidad 26.

[0050] El flujo saliente 20 respeta el protocolo MPEG-TS ("Moving Picture Experts Group-Transport Stream" o "Grupo de expertos en imágenes en movimiento - Flujo de transporte"), en particular en su última versión de fecha IEC 13818-1 de 2022 de septiembre de 2022.

[0051] La Figura 2 representa una realización del procedimiento de protección según la invención resultante de la implementación de la pasarela 30 de la figura 1.

[0052] El procedimiento 50 comienza con una etapa 51 de adquisición del flujo entrante. La etapa 51 corresponde al uso de la interfaz de entrada 31.

[0053] [0048]A continuación, el procedimiento 50 continúa con la descomposición del flujo entrante 10 para encontrar el flujo elemental de vídeo 11 y la división del flujo elemental de vídeo 11 en diferentes paquetes de vídeo 12. Esta etapa 52 corresponde a la ejecución del módulo 32 de descomposición del flujo entrante. La etapa 53 corresponde al filtrado del paquete de vídeo actual para evaluar uno o varios indicadores Id definidos por la política de privacidad implementada por la pasarela 30. La etapa 53 corresponde a la ejecución del módulo 33 de filtrado del paquete de vídeo actual.

[0054] Los diferentes identificadores Id se transmiten al módulo de decisión 34, que, en la etapa 54, determina el nivel de privacidad N adecuado para el paquete de vídeo actual.

[0055] El nivel de confidencialidad así determinado se transmite al módulo 35.

[0056] La etapa 60 corresponde a la ejecución del módulo 40 en el paquete de vídeo actual.

[0057] En la etapa 61, el paquete de vídeo actual se encripta mediante la clave de sesión TEK para obtener un paquete de vídeo actual encriptado. Este último se transmite al módulo 36 de asociación de flujos elementales.

[0058] La clave de sesión TEK se transmite al módulo 35.

[0059] En la etapa 55, correspondiente a la ejecución del módulo 35, se construye primero un paquete de metadatos de privacidad. Comprende diferentes campos, principalmente:

[0060] - un campo de etiquetado temporal que retoma la etiqueta temporal del paquete de vídeo actual para asociar un paquete de metadatos particular a un paquete de vídeo particular.

[0061] - Un campo para el nivel de confidencialidad N determinado al final de la etapa 54.

[0062] - Un campo de cifrado que permite transmitir la clave de sesión TEK usada al final de la etapa 60 para cifrar el paquete de vídeo actual.

[0063] El paquete de metadatos de privacidad se cifra usando la clave KEK adaptada al nivel de privacidad N (en particular, adaptada a los derechos de los usuarios autorizados a conocer el contenido del flujo).

[0064] El paquete de metadatos de privacidad cifrados se transmite al módulo 36.

[0065] En la etapa 56, correspondiente a la ejecución del módulo 36, el flujo saliente 20 se asocia a partir de los flujos elementales de vídeo (construido a partir de la sucesión de los paquetes de vídeo encriptados a la salida de la etapa 61) y del flujo elemental de metadatos (construido a partir de la sucesión de los paquetes de metadatos encriptados a la salida de la etapa 55).

[0066] Por último, en la etapa 57, el flujo saliente 20 se retransmite al destinatario.

[0067] Debe observarse que, en la figura 1, los flujos elementales del flujo saliente se representan por separado el uno del otro, pero los paquetes de estos dos flujos elementales en realidad se multiplexan en el flujo saliente, formando un contenedor.

[0068] La realización preferida comprende el cifrado sistemático de los paquetes de vídeo con una clave TEK y siempre comprende el cifrado del paquete de metadatos de privacidad (donde se encuentra la clave TEK) con la clave KEK.

[0069] Por lo tanto, la capacidad de un destinatario para acceder, sí o no, a los paquetes de un flujo depende de si tiene o no la clave KEK. Por lo tanto, se refiere al procedimiento de distribución de la clave KEK para ponerla a disposición solo de los destinatarios que tienen derecho a conocer los paquetes de metadatos de privacidad y, después de extraer la clave TEK, los paquetes de vídeo correspondientes.

[0070] Ventajosamente, una misma clave TEK puede usarse para encriptar cada uno de los paquetes de una secuencia de varios paquetes de vídeo sucesivos. A continuación, se genera un paquete de metadatos no para cada paquete de vídeo, sino para esta secuencia de paquetes de vídeo. A continuación, se asocia un solo paquete de metadatos de privacidad a la secuencia de paquetes de vídeo encriptados. Eventualmente, pudiendo una secuencia ser larga, el paquete de metadatos de privacidad se repite a una frecuencia fija en el flujo saliente. El paquete de metadatos de privacidad se cifra por medio de la misma KEK en cada repetición.

[0071] Debe enfatizarse que colocar una clave de sesión TEK en el paquete de metadatos de privacidad asociado con un paquete de vídeo encriptado permite la asociación entre estos paquetes no solo por el campo de etiquetado de tiempo, sino especialmente por el campo criptográfico que contiene la clave de sesión TEK para descifrar el paquete de vídeo correspondiente. Esto permite al destinatario descifrar el paquete de vídeo encriptado asociado a esta clave de sesión TEK y solo este. Mientras que la asociación por un campo temporal es débil, la asociación por una clave de encriptado es una asociación fuerte, que permite hacer que esta solución sea robusta.

[0072] [0064]El cifrado de la clave TEK con la clave KEK permite aumentar la seguridad evitando cualquier alteración del flujo por parte de terceros. De hecho, si el metadato de TEK no estuviera cifrado, un tercero podría extraerlo y usarlo para descifrar los paquetes de vídeo o para construir nuevos paquetes de vídeo, encriptarlos con la clave TEK e insertarlos en el flujo.

[0073] Si los paquetes de vídeo están encriptados por la clave TEK, pero solo la clave TEK está cifrada por la clave KEK y ninguno de los otros metadatos, estos otros metadatos de privacidad pueden ser conocidos y posiblemente alterados por un atacante.

[0074] En un ejemplo de uso de esta primera realización, todos los datos se identifican como pertenecientes al mismo nivel por la política de seguridad parametrizada. A continuación, se requiere un solo paquete de metadatos de privacidad para etiquetar todos los datos del flujo. Los datos se cifran con una clave TEK para vincularlos al paquete de metadatos de privacidad, y el paquete de metadatos de privacidad y él mismo cifrado con una clave KEK para garantizar la integridad y autenticidad del conjunto. El paquete de metadatos de privacidad se repite a intervalos regulares para permitir que un nuevo entrante en el flujo pueda descifrarlo. Su clave KEK puede seguir siendo la misma.

[0075] La figura 3 ilustra una segunda realización del dispositivo según la invención.

[0076] Un elemento de la segunda realización de la figura 3 que es similar a un elemento de la realización de la figura 1 es referenciado por una cifra de referencia correspondiente a la cifra de referencia usada en la figura 1 para identificar este elemento similar, aumentado en un centenar.

[0077] En esta segunda realización, la pasarela 130 está adaptada para aplicar una política de privacidad a un flujo entrante 110, siendo este último ahora un flujo compuesto. El flujo entrante 110 contiene un primer flujo elemental 110, que es un flujo de paquetes de vídeo, y un segundo flujo elemental 115.

[0078] El segundo flujo elemental puede no estar correlacionado con el primer flujo elemental. Por ejemplo, podría tratarse de otro flujo elemental de vídeo completamente diferente e independiente del primer flujo elemental de vídeo.

[0079] Preferentemente, el segundo flujo elemental se correlaciona con el primer flujo elemental. Por ejemplo, podría tratarse de un flujo elemental de audio asociado al flujo elemental de vídeo, asociándose cada paquete del segundo flujo elemental a uno o varios paquetes del primer flujo elemental.

[0080] En lo sucesivo, el segundo flujo elemental es un flujo elemental de metadatos de contexto que se correlaciona con el flujo elemental de vídeo.

[0081] Los paquetes de metadatos de contexto 116 del segundo flujo elemental 115 llevan una etiqueta temporal que permite asociar un paquete de metadatos 116 a un paquete de vídeo 112.

[0082] Debe observarse que, en la figura 3, los flujos elementales del flujo entrante se representan por separado el uno del otro, pero los paquetes de estos dos flujos elementales en realidad se multiplexan juntos en el flujo entrante.

[0083] El flujo entrante 110 respeta preferentemente el protocolo MPEG-TS.

[0084] Para aplicar una política de privacidad al flujo 110, la pasarela 130 comprende una interfaz de entrada 131 para la adquisición del flujo entrante 110.

[0085] A continuación de la interfaz de entrada 131, la pasarela 130 comprende un módulo 132 de descomposición del flujo entrante. El módulo 132 es capaz de separar (especialmente demultiplexar) los diferentes flujos elementales que componen el flujo compuesto entrante y, para cada flujo elemental, de dividirlo en paquetes. Así, en una primera salida, el módulo 130 entrega un primer paquete de vídeo corriente y en una segunda salida, el módulo 130 entrega un segundo paquete de metadatos de contexto corriente.

[0086] La pasarela 130 comprende varios módulos de filtrado, estando cada módulo de filtrado adaptado al tratamiento de los paquetes de un flujo elemental particular.

[0087] Así, un primer módulo de filtrado 133.1 permite filtrar el paquete de vídeo actual para obtener uno o varios primeros indicadores Id.1, mientras que un segundo módulo de filtrado 133.2 permite filtrar el paquete de metadatos de contexto actual, para obtener uno o varios segundos indicadores Id.2.

[0088] En la realización de la figura 3, estos dos conjuntos de indicadores se transmiten a un módulo de toma de decisiones en cuanto al nivel de confidencialidad que debe aplicarse a los paquetes actuales. En la realización de la figura 3, este módulo 134 es común a los dos flujos elementales. El módulo 134 proporciona un nivel de privacidad N para el paquete de vídeo actual y el paquete de metadatos de contexto actual.

[0089] La pasarela 130 comprende, después del módulo 134, un módulo 140.1 de encriptado del paquete de vídeo actual y un módulo 140.2 de encriptado del paquete de metadatos de privacidad. Como en la primera realización de la figura 1, un primer módulo 141.1 del módulo 140.1 toma como entrada el paquete de vídeo actual emitido por el módulo 132 y lo encripta usando una clave de sesión TEK1. El paquete de vídeo encriptado se transmite a un módulo 136 de asociación de flujos elementales.

[0090] Al mismo tiempo, un segundo módulo 141.2 del módulo 140.2 toma como entrada el paquete de metadatos de contexto actual emitido por el módulo 132 y lo encripta con una clave de sesión TEK2. El paquete así encriptado se transmite al módulo 136.

[0091] El submódulo 143 del módulo 135 construye un paquete de metadatos de privacidad que integra: - un campo de etiquetado temporal, que permite asociar un paquete de metadatos de privacidad a un paquete de vídeo y el paquete de metadatos de contexto compartiendo una etiqueta temporal común ("time stamp");

[0092] - un campo de nivel de confidencialidad que indica el valor N calculado para los paquetes actuales por el módulo 134; y,

[0093] - un primer campo criptográfico, que contiene la clave de sesión TEK1,

[0094] - un segundo campo criptográfico, que contiene la clave de sesión TEK2.

[0095] Un submódulo 142 del módulo 135, según el valor N del nivel de privacidad asignado a los paquetes actuales por el módulo 134, cifra el paquete de metadatos de privacidad usando una clave de seguridad KEK. El submódulo 142 transmite el paquete cifrado al módulo 136.

[0096] El módulo 136 permite asociar (especialmente multiplexar) los flujos elementales, a la vez el flujo elemental de vídeo, el flujo elemental de metadatos de contexto y el flujo elemental de metadatos de privacidad.

[0097] La pasarela 130 comprende una interfaz de salida 137 adaptada para retransmitir el flujo saliente 120, construido por el módulo 136, en la red hacia el destinatario o los destinatarios del flujo.

[0098] Por lo tanto, el flujo saliente 120 está constituido por un flujo elemental de vídeo 121 y un flujo elemental de metadatos 125. El flujo elemental de vídeo está constituido por una sucesión de paquetes de vídeo encriptados 122. El flujo elemental de metadatos 125 está constituido por una sucesión de paquetes de metadatos que integran a la vez paquetes de metadatos de contexto encriptados 116 (correspondientes al paquete contenido en el segundo flujo elemental del flujo entrante) y paquetes de metadatos de privacidad 126 resultantes de la aplicación de la política implementada por la pasarela 130.

[0099] El flujo saliente 120 cumple con el protocolo MPEG-TS.

[0100] Las diferentes etapas del procedimiento resultantes de la implementación del dispositivo 130 no se describen aquí en detalle, pero se deducen de lo que se ha presentado anteriormente. En particular, cada módulo funcional de la figura 3 podría verse como una etapa de implementación del procedimiento correspondiente.

[0101] En un caso de uso de esta segunda realización, un flujo entrante compuesto multiplexado, con un vídeo y metadatos contextuales pertenecientes al mismo programa. La política de seguridad se ajusta de modo que los metadatos contextuales estén marcados con "Descripción Restringida" _ DR y los datos de vídeo estén marcados con "Confidencial", a menos que la posición de la cámara de adquisición (por ejemplo, dada por un sistema GPS que equipa la cámara), que se puede extraer de los metadatos contextuales, corresponda a un área fijada previamente. Los datos de vídeo se marcan entonces como "Secreto". Por lo tanto, se puede usar el mismo paquete de metadatos de privacidad para etiquetar varios paquetes de metadatos contextuales. La clave TEK2 usada para cifrar los paquetes de metadatos contextuales está incrustada en el paquete de metadatos de privacidad, que además lleva la información del MISP que anuncia los paquetes de vídeo asociados como DR, y este se cifra con una clave KEK asociada al nivel DR. En este ejemplo, puede ocurrir que dos paquetes de vídeo consecutivos no tengan el mismo nivel de privacidad. A continuación, se cifran con claves diferentes y cada uno tiene su paquete de metadatos de privacidad asociado. Se usa una clave KEK de nivel CD para uno y una clave KEK de nivel S para el otro.

[0102] Como variante de esta segunda realización, una vez separados los diferentes flujos elementales por el módulo 132, se podrían tener cadenas de tratamiento totalmente independientes que permitan aplicar una política de confidencialidad específica a cada flujo elemental del flujo entrante. Estas cadenas podrían usar claves de sesión TEK idénticas o diferentes y/o claves de cifrado KEK idénticas o diferentes.

[0103] El flujo saliente podría entonces estar compuesto, por una parte, de un primer flujo elemental correspondiente al primer flujo elemental y de un primer flujo elemental de metadatos de confidencialidad asociado al primer flujo elemental, y, por otra parte, de un segundo flujo elemental correspondiente al segundo flujo elemental y de un segundo flujo elemental de metadatos de confidencialidad asociado a este segundo flujo elemental.

[0104] Si en las realizaciones anteriores el dispositivo de aplicación de una política de privacidad es un dispositivo de hardware independiente (por ejemplo, una pasarela entre una red local y una red pública), como alternativa, el dispositivo de aplicación de una política de privacidad es esencialmente software, como por ejemplo un controlador a la salida de una cámara de adquisición de imágenes.

[0105] La política de privacidad implementada por el dispositivo puede ser redefinida a intervalos. Esto puede requerir reprogramar el módulo de filtrado para determinar el valor de diferentes indicadores en los paquetes entrantes.

[0106] A este respecto, el módulo de filtrado está adaptado para asociar uno o varios indicadores a un paquete corriente. Este indicador se puede determinar solo a partir del paquete actual, pero también podría depender de un procesamiento en una sucesión de paquetes, comprendiendo el paquete actual y una serie de paquetes anteriores. El indicador podría ser, por ejemplo, un valor medio en esta sucesión de paquetes o el resultado de una comparación entre el paquete actual y uno o varios paquetes anteriores.

[0107] Como variante, el dispositivo de protección no comprende un módulo de filtrado y la política de privacidad se reduce a encriptar los paquetes de un flujo y cifrar la clave de sesión TEK con una clave de cifrado KEK adaptada al destinatario.

[0108] Ventajosamente, cuando los datos de privacidad son idénticos de un paquete de vídeo a otro para una secuencia de paquetes de vídeo, solo se emite un paquete de metadatos de privacidad para el primero de estos paquetes de vídeo. El destinatario del flujo sabe entonces que debe asociar un paquete de vídeo con los datos de confidencialidad del último paquete de metadatos recibido.

[0109] Debe observarse que el estándar "Motion Imagery Standard Profile" MISP ST 0102.12 STANAG 4609 (o "perfil estándar de imágenes del movimiento" en español) estandariza la introducción de metadatos de contexto en los flujos de vídeo. Algunos campos de estos metadatos indican el nivel de confidencialidad de los paquetes de vídeo asociados.

[0110] El paquete de metadatos de privacidad desarrollado por el módulo 35 (o el módulo 135) podría incluir todos o parte de los campos definidos por el estándar MISP, especialmente para ser compatible con este estándar. Por lo tanto, se pueden considerar campos complementarios. Además, el ETSI ha especificado los medios de protección de los flujos de vídeo en la norma ETSI TS101197-DVB "SIMULCRYPT".

[0111] En un mismo flujo multiplexado, la solución SIMULCRYPT permite transmitir "programas" cifrados y otros en claro, siendo un "programa" una colección de paquetes de diferentes tipos (audio, vídeo, ...) que constituyen un flujo coherente (una emisión o una película, por ejemplo). Por lo tanto, un programa puede transmitirse sin encriptar o encriptado. De este modo, se trata de un encriptado binario (todo o nada), que no permite la granularidad de protección propuesta por la presente invención.

[0112] Además, a diferencia de la presente invención, SIMULCRYPT no permite encriptar un tramo de audio con una clave diferente de la usada para encriptar el tramo de vídeo asociado.

[0113] Lo más importante, SIMULCRYPT cifra un flujo para protegerlo de forma confidencial. En cambio, la presente invención es ante todo una solución que permite vincular fuertemente los metadatos de confidencialidad a los datos, y proteger los datos en confidencialidad. Por lo tanto, la presente invención permite separar, en un flujo, los datos por nivel de confidencialidad y aplicar a cada dato una protección adaptada al nivel de confidencialidad requerido. La separación de los datos según su nivel de confidencialidad se refiere a datos de flujos elementales diferentes, pero sobre todo a datos de paquetes diferentes de un mismo flujo elemental. Podríamos hablar de una separación "temporal" entre datos (dentro de un mismo flujo de datos, asignar diferentes niveles de privacidad de un paquete a otro) o de una separación "espacial" (el nivel de privacidad de los datos de diferentes flujos elementales se puede tratar de forma independiente).

[0114] El uso de una clave de sesión para encriptar un paquete de datos de vídeo y colocar esta clave de sesión en el paquete de metadatos de privacidad asociado permite vincular fuertemente los paquetes de los flujos elementales de vídeo y de metadatos.

[0115] Además, al cifrar el paquete de metadatos de confidencialidad, la presente invención permite garantizar la integridad y la autenticidad de este metadato. La solución especificada por la OTAN no permite garantizar la integridad y la autenticidad del metadato, ni ligarlo al flujo de vídeo mediante una firma criptográfica.

[0116] Según la invención, para garantizar la integridad y la autenticidad de los metadatos de confidencialidad, estos últimos se engloban en el cifrado mediante la clave KEK.

[0117] [0106]La solución especificada por el ETSI no permite gestionar políticas de seguridad complejas basadas en atributos y niveles de sensibilidad heterogéneos en un mismo flujo.

[0118] La presente invención ofrece una capacidad binaria: o bien se descifra la clave de encriptado del flujo de vídeo (para poder descifrar a continuación el flujo de vídeo; o bien no se puede descifrar la clave de encriptado. La presente invención permite cifrar ciertos paquetes o tramos de paquetes de un flujo con una clave, y otros tramos de ese mismo flujo con otra clave.

[0119] El uso de una clave de sesión para encriptar un paquete de datos de vídeo y colocar esta clave de sesión en el paquete de metadatos de privacidad asociado permite vincular fuertemente los paquetes de los flujos elementales de vídeo y de metadatos.

[0120] Además, al cifrar el paquete de metadatos de confidencialidad, la presente invención permite garantizar la integridad y la autenticidad de este metadato. La solución especificada por la OTAN no permite garantizar la integridad y la autenticidad del metadato, ni ligarlo al flujo de vídeo mediante una firma criptográfica.

[0121] Según la invención, para garantizar la integridad y la autenticidad de los metadatos de confidencialidad, estos últimos se engloban en el cifrado mediante la clave KEK.

[0122] La solución especificada por el ETSI no permite gestionar políticas de seguridad complejas basadas en atributos y niveles de sensibilidad heterogéneos en un mismo flujo.

[0123] La presente invención ofrece una capacidad binaria: o bien se descifra la clave de encriptado del flujo de vídeo (para poder descifrar a continuación el flujo de vídeo; o bien no se puede descifrar la clave de encriptado. La presente invención permite cifrar ciertos paquetes o tramos de paquetes de un flujo con una clave, y otros tramos de ese mismo flujo con otra clave.

Claims (11)

1. REIVINDICACIONES

1. Procedimiento de protección de un flujo entrante (10, 110), comprendiendo el flujo entrante al menos un flujo elemental de vídeo entrante (11, 111), comprendiendo el flujo elemental de vídeo entrante una sucesión de paquetes de vídeo entrantes (12, 112),caracterizándoseel procedimientoporquecomprende las etapas de:

- descomposición (52) del flujo entrante para separar un paquete corriente (12, 112, 116);

- encriptado del paquete actual con una clave de sesión (TEK, TEK1, TEK2);

- construcción (55) de un paquete de metadatos de confidencialidad comprendiendo un campo de etiqueta temporal correspondiente a una etiqueta temporal del paquete actual y un campo de confidencialidad que contiene la clave de sesión;

- cifrado del paquete de datos de privacidad con una clave de cifrado (KEK);

- asociación (56) de un flujo saliente (20, 120) comprendiendo un flujo elemental saliente que reagrupa los paquetes corrientes encriptados (22, 122, 116) y de un flujo elemental de metadatos de confidencialidad comprendiendo los paquetes de metadatos de confidencialidad cifrados (26, 126).

2. Procedimiento según la reivindicación 1, comprendiendo además:

- adquisición de al menos un indicador (Id); y,

- determinación (54) de un nivel de confidencialidad (N) para el paquete actual a partir de o de cada indicador, comprendiendo la etapa de construcción (55) de un paquete de metadatos de confidencialidad, además, un campo de nivel de confidencialidad que retoma el nivel de confidencialidad determinado para el paquete actual.

3. Procedimiento según la reivindicación 2, donde la clave de cifrado (KEK) se selecciona según el nivel de confidencialidad (N) determinado para el paquete actual.

4. Procedimiento según cualquiera de las reivindicaciones anteriores, donde la etapa de adquisición consiste en filtrar (53) el paquete entrante para evaluar al menos un indicador (Id).

5. Procedimiento según cualquiera de las reivindicaciones anteriores, donde el flujo entrante comprende, además del flujo elemental de vídeo, un flujo elemental de metadatos de contexto, permitiendo la etapa de descomposición separar un paquete de metadatos de contexto actual.

6. Procedimiento según la reivindicación 5, donde el paquete de vídeo actual se encripta con una primera clave de sesión (TEK1), y el paquete de metadatos de contexto se encripta con una segunda clave de sesión (TEK2).

7. Procedimiento según la reivindicación 6, donde el paquete de metadatos de confidencialidad comprende un primer campo de confidencialidad que recoge la primera clave de sesión y un segundo campo de confidencialidad que recoge la segunda clave de sesión.

8. Procedimiento según cualquiera de las reivindicaciones anteriores, donde el flujo saliente respeta el protocolo "grupo de expertos en imágenes en movimiento - Flujo de transporte" - MPEG-TS.

9. Procedimiento según cualquiera de las reivindicaciones anteriores, donde el paquete de metadatos de privacidad comprende campos adicionales para ser compatible con el estándar de "perfil estándar de imágenes de movimiento" - MISP.

10. Dispositivo de protección (30) adaptado para implementar un procedimiento de protección según cualquiera de las reivindicaciones 1 a 9 sobre un flujo entrante, comprendiendo el flujo entrante al menos un flujo elemental de vídeo entrante.

11. Programa informático comprendiendo instrucciones de software que, cuando son ejecutadas por un ordenador, implementan un procedimiento de protección según cualquiera de las reivindicaciones 1 a 9 sobre un flujo entrante, comprendiendo el flujo entrante un flujo elemental de vídeo entrante, comprendiendo el flujo elemental de vídeo entrante una sucesión de paquetes de vídeo entrante.