ES2844248T3 - Método y dispositivo para procesamiento de datos y sistema de comunicación que comprende tal dispositivo - Google Patents

Método y dispositivo para procesamiento de datos y sistema de comunicación que comprende tal dispositivo Download PDF

Info

Publication number
ES2844248T3
ES2844248T3 ES19179349T ES19179349T ES2844248T3 ES 2844248 T3 ES2844248 T3 ES 2844248T3 ES 19179349 T ES19179349 T ES 19179349T ES 19179349 T ES19179349 T ES 19179349T ES 2844248 T3 ES2844248 T3 ES 2844248T3
Authority
ES
Spain
Prior art keywords
trust
local
instance
trusted
manager
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES19179349T
Other languages
English (en)
Inventor
Jörg Abendroth
Michael Marhöfer
Manfred Schäfer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks Oy
Original Assignee
Nokia Solutions and Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Solutions and Networks Oy filed Critical Nokia Solutions and Networks Oy
Application granted granted Critical
Publication of ES2844248T3 publication Critical patent/ES2844248T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Un método para procesamiento de datos que comprende una primera instancia que comprende al menos una unidad confiable local y un gestor de confianza local, comprendiendo el método - la unidad confiable local recibe una petición de un nivel de confianza desde una segunda instancia, - el gestor de confianza local determina un nivel de confianza, - el gestor de confianza local proporciona el nivel de confianza a la unidad confiable local, y - la unidad confiable local transmite el nivel de confianza a la segunda instancia.

Description

DESCRIPCIÓN
Método y dispositivo para procesamiento de datos y sistema de comunicación que comprende tal dispositivo La invención se refiere a un método y a un dispositivo para el procesamiento de datos y a un sistema de comunicación que comprende un dispositivo de este tipo.
Un usuario o cliente que quiere explotar un servicio particular que puede ser independiente de su red actual se enfrenta a numerosos procesos que se requieren para un control de acceso al servicio (por ejemplo, registro, afinidad de red, identificación, autorización, pago, privacidad, negociación de políticas).
Esto se aplica repetidamente si el usuario se conecta a diferentes servicios, cada uno de los cuales requiere que cumplan prerrequisitos de acceso al servicio individuales. Tales servicios pueden tener todos sus propias expectativas sobres los valores de confianza del usuario y su respectivo entorno antes de aceptar a un usuario ajeno.
Por otra parte, el propio usuario puede tener sus propios requisitos en cuanto a cómo los servicios deberían tratar su privacidad y datos de confianza. Expectativas con respecto a tales problemas de privacidad están creciendo en ambos lados, en el proveedor de un servicios así como en el usuario. Esto es, en particular, pertinente cuando se refiere a servicios de alto valor que incluyen o están relacionados con flujo de dinero (significativo) o intercambio de testigos valiosos que soportan una gran necesidad de entornos multiservicio comprobados y confiables.
Todo esto se complica aún más si las partes implicadas no se conocen de antemano y, en particular, no saben quién (¿fiable o no?), con qué intención (¿maliciosa o no? y con qué clase de equipo (¿capaz de ver contenido seguro, última versión de software?) se está conectando un participante de comunicación.
En algunos entornos, dos partes necesitan establecer un cierto nivel de seguridad y pueden no ser capaces de, por ejemplo, referirse a una tercera parte para propósitos de aseguramiento de confianza, verificación de integridad y/o atestación. La solicitud de patente internacional WO01/11845 es técnica anterior adicional.
El problema a resolver es superar las desventajas indicadas anteriormente y proporcionar un enfoque para habilitar la interacción segura de al menos dos partes en particular incluso sin una conexión obligatoria a una tercera parte. Este problema se resuelve de acuerdo con las características de las reivindicaciones independientes. Realizaciones adicionales resultan a partir de las reivindicaciones dependientes.
Para superar este problema, se proporciona un método para el procesamiento de datos que comprende una primera instancia que comprende al menos una unidad confiable local (LTU) y un gestor de confianza local (LTM), comprendiendo el método la siguiente etapa:
- el gestor de confianza local proporciona una información relacionada con la política a la al menos una unidad confiable local y/o a una segunda instancia.
Por lo tanto, preferentemente dentro de la primera instancia, el gestor de confianza local proporciona, por ejemplo tras la petición desde otra instancia o desde al menos una unidad confiable local, una información relacionada con la política a la al menos una unidad confiable local.
La información relacionada con la política puede ser una información pertinente a la seguridad y puede, por ejemplo, comprender o establecer un nivel de confianza.
Este enfoque permite que la primera instancia proporcione un nivel de confianza a una segunda instancia sin una necesidad de que la primera instancia o la segunda instancia se conecten a una parte confiable, por ejemplo, una tercera instancia que actúa como un centro de confianza o empresa de confianza independiente. En su lugar, las entidades pertinentes a la seguridad de la primera instancia habilitan que la primera instancia (la al menos una unidad confiable local y el gestor de confianza local) proporcione un cierto nivel de seguridad que puede considerarse suficiente para que numerosas transacciones o negociaciones finalicen.
Sin embargo, es una ventaja particular que basándose en tal "confianza" simplificada entre partes, siempre puede ser una opción latente para cada instancia conectarse a dicha tercera parte (confiable) para confirmar un nivel de confianza como se ha expuesto hasta ahora sin una parte confiable implicada. Como tal opción puede considerarse omnipresente, la aceptación de un usuario de este enfoque que ejecuta una autenticación entre pares únicamente puede aumentar.
También es posible aumentar el nivel de confianza conectándose a la tercera parte (confiable) en comparación con un nivel de confianza ya proporcionado en, por ejemplo, la primera instancia.
En una realización, el gestor de confianza local proporciona la información relacionada con la política basándose en un mensaje enviado por la segunda instancia.
Este puede ser el caso si la segunda instancia solicita, por ejemplo, una política de la primera instancia y espera como una respuesta una información particular relacionada con la política que se refiere a la política. Por lo tanto, la información relacionada con la política puede enviarse por la primera instancia, después de que la política se ha recibido y procesado por al menos una unidad confiable local.
En otra realización, el mensaje enviado por la segunda instancia comprende una política.
Tal política puede contener información sobre cómo tiene que compilarse una respuesta, es decir una información relacionada con la política, y enviarse de vuelta a la segunda instancia.
En una realización adicional, la información relacionada con la política comprende un nivel de confianza.
Puede haber varios de tales niveles de confianza, que podrían depender de un escenario, una empresa o negociación a finalizar, una persona o usuario, un equipo (conocido, improbable que se manipule o ejecute software malicioso), etc. Opcional, un usuario o un dispositivo puede decidir en qué nivel de confianza confía y, por lo tanto, procede con la transacción. Como se ha indicado anteriormente, también es una opción requerir un nivel de confianza más fuerte solicitando una confirmación adicional de al menos una tercera parte.
Se ha de observar que la tercera parte puede ser una entidad conocida generalmente y confiable y/o una instancia que puede solo aumentar el nivel de confianza (es decir, la entidad confiable puede actuar como un verificador o emisor de, por ejemplo, certificados, software o similar). Esta última puede ser otro par (o varias instancias), cada uno de los cuales no tiene necesariamente que ser una entidad confiable común.
Como una alternativa, la tercera parte confiable también puede disminuir un nivel de confianza, por ejemplo, en caso de hacer cumplir una revocación.
En una siguiente realización, la información relacionada con la política comprende al menos uno de los siguientes: a) Un testigo: el testigo puede usarse para reenviarse directamente, por ejemplo, desde la primera instancia a la segunda instancia y/o desde el gestor de confianza local a la al menos una unidad confiable local. Basándose en la política que se envía o reenvía, el testigo puede compilarse de acuerdo con demandas de, por ejemplo, la segunda instancia. Las reglas sobre cómo tiene que compilarse dicho testigo pueden negociarse por adelantado o durante tal comunicación. Ventajosamente, la al menos una unidad confiable local no necesita conocer nada acerca del testigo o sobre cómo tiene que compilarse por el gestor de confianza local, simplemente reenvía el mismo tras la recepción a la segunda instancia.
b) Un atributo: en principio, cada clase de datos puede usarse para el propósito descrito, es decir, reenviar información pertinente a la política a la segunda instancia.
c) Un certificado: puede reenviarse un certificado para probar, por ejemplo, una identidad de la primera instancia a la segunda instancia.
d) Puede usarse un conjunto de reivindicaciones para confirmar la identidad de la primera instancia.
e) Puede usarse un momento y/o una indicación de tiempo para confirmar la identidad y/o para confirmar un periodo de validez.
f) Un programa a ejecutarse en la primera instancia: la información proporcionada por el gestor de confianza local puede ser un programa y/o un subprograma que se instala o ejecuta en la plataforma de la primera instancia. El programa instalado y/o ejecutándose en la primera instancia puede usarse para comunicarse directamente con la segunda instancia de acuerdo con la política expuesta.
g) Parámetros de un programa a ejecutarse en la primera instancia: también puede ser una solución proporcionar únicamente parámetros a la primera instancia, dichos parámetros se usan por un programa, subprograma de función ejecutable en la primera instancia. Transferir un conjunto predeterminado de al menos un parámetro puede resultar en la ejecución de una función particular en la primera instancia.
Se ha de observar que pueden usarse combinaciones de los mismos o con piezas de información adicionales para cumplir con el nivel de confianza requerido por, por ejemplo, la segunda instancia.
Es también una realización que la al menos una unidad confiable local transmite la información relacionada con la política a la segunda instancia o a (otra) tercera instancia.
Conforme a otra realización, el gestor de confianza local actúa como un proveedor de confianza virtual.
De acuerdo con una realización, el gestor de confianza local proporciona información relacionada con la política a una instancia solicitante, por ejemplo, a la segunda instancia.
Esto puede permitir que la primera instancia y la segunda instancia finalicen un negocio y/o negociación sin incluir ninguna tercera parte como entidad confiable.
De acuerdo con otra realización, el gestor de confianza local deriva al menos un certificado (de confianza). Tal certificado puede derivarse a partir de sí mismo y suministrarse a la al menos una unidad confiable local. Ventajosamente, el certificado se basa en propiedades proporcionadas por la unidad confiable local.
En otra realización más, el gestor de confianza local asigna al menos un certificado de confianza a la al menos una unidad confiable local.
De acuerdo con una siguiente realización, el gestor de confianza local notifica un nivel de confianza de al menos una unidad confiable local a una instancia solicitante, por ejemplo, a la segunda instancia.
Conforme a una realización más, el gestor de confianza local traduce un parámetro de la al menos una unidad confiable local a un nivel de confianza y/o a un testigo, en donde dicho nivel de confianza y/o testigo se transmite preferentemente a una instancia solicitante, por ejemplo, a la segunda instancia.
En una realización, el gestor de confianza local se comunica en línea y/o fuera de línea con una instancia externa que proporciona al gestor de confianza local información relacionada con al menos una de las unidades confiables locales.
Tal comunicación puede aplicarse con una instancia adicional, en particular con una tercera parte confiable, por ejemplo, un centro de confianza común.
Es otra realización que el gestor de confianza local se habilita para gestionar un contexto de sesión de la al menos una unidad confiable local.
Además, es una realización que el gestor de confianza local comprende (y realiza) una funcionalidad de vigilancia para supervisar la al menos una unidad confiable local.
De acuerdo con otra realización más, el gestor de confianza local aplica emisiones de control externas a la al menos una unidad confiable local.
Es una siguiente realización que el gestor de confianza local comprende y/o realiza una funcionalidad de cobro. Como una realización adicional, la al menos una unidad confiable local está protegida contra manipulación por, por ejemplo, ciertos medios de hardware. En particular, el gestor de confianza local puede estar mejor protegido que la al menos una unidad confiable local.
Además, la al menos una unidad confiable local puede construir una relación de seguridad y/o confianza basándose en un proceso y/o en una credencial que se controla y/o proporciona por el gestor de confianza local.
El problema indicado anteriormente se resuelve también por una unidad de procesador que se dispone y/o equipa de tal forma que el método según se describe puede ser ejecutable en tal unidad de procesador.
También, el problema indicado anteriormente se resuelve por un dispositivo, en particular por una primera instancia, que comprende:
- una unidad confiable local; y
- un gestor de confianza local;
- en donde el gestor de confianza local está equipado para proporcionar una información relacionada con la política al gestor de confianza local y/o a una segunda instancia.
De acuerdo con una realización, el dispositivo es un dispositivo de comunicación, en particular un dispositivo del siguiente tipo:
- una tarjeta inteligente;
- una tarjeta con chip;
- un equipo de usuario;
- un terminal de usuario;
- un teléfono móvil;
- un establecimiento de máquina y dejado en una ubicación por un usuario;
- un ordenador móvil;
- un asistente digital personal;
- un ordenador conectado a una red por cable o inalámbrica;
- un teléfono IP.
La tarjeta inteligente y/o la tarjeta con chip pueden obtener en particular la energía requerida para su operación a través de comunicación de campo cercano (NFC). Tales tarjetas pueden usarse para emisión de billetes, aplicaciones de contabilidad, puntos de venta o similares.
Se ha de observar que la red inalámbrica puede comprender comunicación de campo cercano (NFC).
El problema indicado anteriormente también se resuelve mediante un sistema de comunicación que comprende el dispositivo como se describe en este documento.
Se proporcionan un método, un aparato y un sistema de acuerdo con las siguientes cláusulas 1-23:
1. Un método para procesamiento de datos que comprende una primera instancia que comprende al menos una unidad confiable local y un gestor de confianza local, comprendiendo el método la siguiente etapa:
- el gestor de confianza local proporciona una información relacionada con la política a la al menos una unidad confiable local y/o a una segunda instancia.
2. El método de acuerdo con la cláusula 1, en donde el gestor de confianza local proporciona la información relacionada con la política basándose en un mensaje enviado por la segunda instancia.
3. El método de acuerdo con la cláusula 2, en donde el mensaje enviado por la segunda instancia comprende una política.
4. El método de acuerdo con cualquiera de las cláusulas anteriores 1-3, en donde la información relacionada con la política comprende un nivel de confianza.
5. El método de acuerdo con cualquiera de las cláusulas anteriores 1-4, en donde la información relacionada con la política comprende al menos uno de los siguientes:
- un testigo;
- un atributo;
- un certificado;
- un conjunto de reivindicaciones;
- un momento, en particular una indicación de tiempo;
- un programa a ejecutar en la primera instancia;
- parámetros de un programa a ejecutar en la primera instancia.
6. El método de acuerdo con cualquiera de las cláusulas anteriores 1-5, en donde la al menos una unidad confiable local transmite la información relacionada con la política a la segunda instancia o a una tercera instancia.
7. El método de acuerdo con cualquiera de las cláusulas anteriores 1-6, en donde el gestor de confianza local actúa como un proveedor de confianza virtual (VTP).
8. El método de acuerdo con cualquiera de las cláusulas anteriores 1-7, en donde el gestor de confianza local proporciona información relacionada con la política a una instancia solicitante.
9. El método de acuerdo con cualquiera de las cláusulas anteriores 1-8, en donde el gestor de confianza local deriva al menos un certificado de confianza.
10. El método de acuerdo con la cláusula 9, en donde el gestor de confianza local asigna al menos un certificado de confianza a la al menos una unidad confiable local.
11. El método de acuerdo con cualquiera de las cláusulas anteriores 1-10, en donde el gestor de confianza local notifica un nivel de confianza de al menos una unidad confiable local a una instancia solicitante.
12. El método de acuerdo con cualquiera de las cláusulas anteriores 1-11, en donde el gestor de confianza local traduce un parámetro de la al menos una unidad confiable local a un nivel de confianza y/o un testigo a transmitir a una instancia solicitante.
13. El método de acuerdo con cualquiera de las cláusulas anteriores 1-12, en donde el gestor de confianza local se comunica en línea y/o fuera de línea con una instancia externa que proporciona al gestor de confianza local información relacionada con al menos una de las unidades confiables locales.
14. El método de acuerdo con cualquiera de las cláusulas anteriores 1-13, en donde el gestor de confianza local se habilita para gestionar un contexto de sesión de la al menos una unidad confiable local.
15. El método de acuerdo con cualquiera de las cláusulas anteriores 1-14, en donde el gestor de confianza local realiza una funcionalidad de vigilancia para supervisar la al menos una unidad confiable local.
16. El método de acuerdo con cualquiera de las cláusulas anteriores 1-15, en donde el gestor de confianza local aplica emisiones de control externas a la al menos una unidad confiable local.
17. El método de acuerdo con cualquiera de las cláusulas anteriores 1-16, en donde el gestor de confianza local realiza una funcionalidad de cobro.
18. El método de acuerdo con cualquiera de las cláusulas anteriores 1-17, en donde la al menos una unidad confiable local está protegida contra manipulación.
19. El método de acuerdo con cualquiera de las cláusulas anteriores 1-8, en donde la al menos una unidad confiable local construye una relación de seguridad y/o confianza basándose en un proceso y/o una credencial que se controla por el gestor de confianza local.
20. Un dispositivo que comprende una unidad de procesador que se dispone de tal forma que el método de acuerdo con cualquiera de las cláusulas anteriores 1-19 es ejecutable en dicho procesador.
21. Un dispositivo, en particular una primera instancia, que comprende
- una unidad confiable local; y
- un gestor de confianza local;
- en donde el gestor de confianza local está equipado para proporcionar una información relacionada con la política al gestor de confianza local y/o a una segunda instancia.
22. El dispositivo de acuerdo con cualquiera de las cláusulas 20 o 21, en donde dicho dispositivo es un dispositivo de comunicación, en particular un dispositivo del siguiente tipo:
- una tarjeta inteligente;
- una tarjeta con chip;
- un equipo de usuario;
- un terminal de usuario;
- un teléfono móvil;
- un establecimiento de máquina y dejado en una ubicación por un usuario;
- un ordenador móvil;
- un asistente digital personal;
- un ordenador conectado a una red por cable o inalámbrica;
- un teléfono IP.
23. Sistema de comunicación que comprende el dispositivo de acuerdo con cualquiera de las cláusulas 20 a 22. Realizaciones de la invención se muestran e ilustran en las siguientes figuras:
La Figura 1 muestra un diagrama de mensajes de un escenario que comprende un dispositivo A y un dispositivo B que solicitan e intercambian certificados - opcionalmente incluyendo una instancia confiable;
La Figura 2 muestra un escenario de gestión de confianza local que comprende responsabilidades de las unidades participantes;
La Figura 3 muestra un escenario de aplicación que comprende una red P2P con relación de seguridad y confianza construida en la gestión de confianza local;
La Figura 4 muestra una aplicación de mecanismos de control parental a través del gestor de confianza local y unidad confiable local;
La Figura 5 muestra un diagrama de bloques que comprende dos instancias que pueden usarse para la comunicación de datos;
La Figura 6 muestra un diagrama de bloques basándose en la Figura 5, en donde una tercera instancia adicional actúa como una parte confiable;
La Figura 7 muestra un diagrama que comprende un esquema de provisión de confianza con flujo de información entre un servicio, un cliente y un proveedor de confianza virtual;
La Figura 8 muestra un diagrama que comprende entidades de soporte de confianza;
La Figura 9 muestra un diagrama basándose en la Figura 7 que comprende un servicio adicional que conduce como un ejemplo de una federación de confianza;
La Figura 10 muestra un diagrama de mensajes que comprende dos servicios, un cliente y un proveedor de confianza virtual construyendo una federación de confianza, en donde se envían mensajes para autenticar el usuario sobre el segundo servicio con la ayuda del primer servicio.
El enfoque según se presenta comprende en particular una gestión de confianza descentralizada que aprovecha la facilidad de uso y en muchos casos (por ejemplo, considerando comunicación de campo cercano (NFC), o transacciones de par a par (P2P) es también aplicable en ausencia de una conectividad de red de gestión.
En el establecimiento de una atestación dentro del campo de computación confiable, una entidad prueba la confianza de otra entidad mediante, por ejemplo, el uso de valores de integridad. Estos valores, como tal, pueden ser complejos y también pueden cambiar a menudo. Por lo tanto, pueden usarse autoridades centrales para traducir un valor de integridad en una declaración.
Sin embargo, usar autoridades centralizadas (tales como, por ejemplo, (terceras) partes comunes confiables) es conveniente cuando se construyen y confirman relaciones de seguridad y confianza entre entidades que inicialmente no se conocen y desconocen la confianza del otro.
Con respecto a muchas aplicaciones como P2P, NFC o situaciones sin ninguna conexión fiable a una autoridad de red (es decir, parte confiable), algunas funcionalidades de autoridad pueden tener que desplazarse a los propios clientes.
Por lo tanto, el enfoque proporcionado en este documento presenta una solución que no requiere una conexión directa a una autoridad central. En su lugar, ninguna o solamente alguna interacción ocasional con tal autoridad central puede ser suficiente.
Tal interacción ocasional con una autoridad central o tercera parte confiable (por ejemplo, un centro de confianza) puede utilizarse en línea o incluso fuera de línea o basándose en una infraestructura de red opcional a usar únicamente en circunstancias especiales.
Además, este enfoque proporciona un alto grado de flexibilidad ya que puede adaptarse de forma autónoma a un amplio campo de aplicaciones y entornos de seguridad/confianza. También resuelve el problema de traducir "valores de integridad" a "declaraciones de confianza" que pueden realizarse mediante únicamente una sola instancia.
En un escenario particular, dos instancias A y B (también denominadas dispositivos) quieren comunicarse entre sí, en particular estas instancias pueden querer cambiar información secreta y/o finalizar un acuerdo, firmar un contrato o acordar los términos de unas negociaciones.
El dispositivo B (segunda instancia) quiere conocer un nivel de confianza del dispositivo A (primera instancia). De acuerdo con la Figura 1, el dispositivo A comprende un gestor de confianza local LTM y una unidad confiable local LTU. La unidad confiable local LTU es la aplicación que quiere comunicarse con el dispositivo B.
Se ha de observar que antes de emitir un certificado, puede proporcionarse una atestación.
El dispositivo B necesita verificar una integridad del gestor de confianza local LTM en el dispositivo A, que se expresa mediante un registro de configuración de plataforma (PCR) conocido y/o un valor de troceo. Cambios de este valor pueden no producirse muy a menudo. También, la distribución de estos valores puede proporcionarse fuera de banda. Por lo tanto, el dispositivo B envía una petición (que comprende una política o un nivel de confianza requerido) a la unidad confiable local LTU.
El gestor de confianza local LTM tiene su propia base de datos de parámetros de confianza de unidad confiable local LTU conocidos localmente, que el gestor de confianza local LTM puede comparar con atestaciones internas de la unidad confiable local LTU.
Posteriormente, el gestor de confianza local LTM puede entregar un certificado a la unidad confiable local LTU conteniendo su nivel de confianza (también denominado como información relacionada con la política). El dispositivo A envía este certificado (que incluye una referencia al certificado del gestor de confianza local LTM) al dispositivo B. El certificado preferentemente no indica un valor de troceo nativo, ya que entonces el dispositivo B necesitaría conocer todas las potenciales configuraciones de dispositivo del dispositivo A o incluso de cualquier dispositivo al que pueda conectarse. En su lugar, el certificado comprende un nivel de confianza en una escala bien conocida o una semántica comparable.
Por lo tanto, no se requiere una autoridad de red remota, porque el gestor de confianza local LTM actúa en una función de un "Proveedor de Confianza/Empresa de Confianza" con competencias locales y sin conexión a una autoridad de confianza en el lado de red.
Sin embargo, puede ser ventajosa al menos una fase inicial de "establecimiento del gestor de confianza local LTM" y distribución de sus valores de troceo, por ejemplo, durante un proceso de fabricación o de despliegue del dispositivo. Como se muestra adicionalmente en la Figura 1, una instancia externa (centro de confianza común) puede estar presente si es necesaria, es decir, en particular si se requiere o solicita por una parte (dispositivo y/o usuario del dispositivo B). Ese puede ser el caso si el nivel de confianza/política solicitada por el dispositivo B es más fuerte que un certificado que puede proporcionarse por el dispositivo A únicamente (sin que un centro de confianza esté implicado). Por lo tanto, como se indica por las líneas discontinuas, el nivel de confianza puede solicitarse por el gestor de confianza local LTM desde el centro de confianza, el centro de confianza proporciona un certificado apropiado. Tal certificado emitido por el centro de confianza preferentemente es de un mayor nivel de confianza y, por lo tanto, puede reenviarse al dispositivo B para cumplir con la petición de un alto nivel de este tipo de confianza y/o seguridad.
La Figura 2 introduce algunos principios en más detalle. Describe un cliente confiable (en este punto: el dispositivo A) que se implementa con características de seguridad predefinidas para evitar satisfactoriamente ataques locales en datos pertinentes a la confianza (al menos hasta cierto extremo). Tales mecanismos pueden variar (a prueba de manipulaciones, basado en TCG, basado en entorno de pruebas/Java, basado en UICC, soluciones de SW puras, etc.) dependiendo de respectivos requisitos y/o condiciones ambientales o escenarios para el que tiene que aplicarse un cliente de este tipo así como dependiendo de un nivel de confianza que tiene que cumplirse.
Ya que los ataques locales no pueden excluirse categóricamente de ser (hasta cierto punto) exitosos, puede ser ventajoso proporcionar un control externo, que puede restringirse para interacciones (por ejemplo, en caso de una emergencia) ocasionales y/o solicitadas o para operaciones administrativas (tal como, por ejemplo, gestionar una lista negra).
El cliente confiable mostrado en la Figura 2 comprende dos entidades particulares, el gestor de confianza local (LTM) y al menos una unidad confiable local (LTU).
Estas entidades pueden implementarse preferentemente de tal forma que el gestor de confianza local LTM puede afectar a la al menos una unidad confiable local LTU, pero no a la inversa. Esto puede conseguirse, por ejemplo, dividiendo de forma apropiada el hardware y el software del dispositivo A, mediante mecanismos de espacio de núcleo/espacio de usuario, o en particular por módulos de seguridad incorporados o fijados adecuados.
Gestor de confianza local LTM
El gestor de confianza local LTM puede asumir algunas tareas de un proveedor de confianza virtual. Sin embargo, su gobernanza y responsabilidad puede restringirse a la al menos una unidad confiable local LTU del cliente confiable (en este punto: el dispositivo A).
Las siguientes tareas pueden asignarse al gestor de confianza local LTM:
■ Atestación de gestor de confianza local LTM:
El gestor de confianza local LTM puede notificar su integridad a un contendiente externo (a una instancia y/o dispositivo externos) que desea conocer la identidad y parámetros de confianza del gestor de confianza local LTM. Estos parámetros de confianza pueden ser bien conocidos externamente y también pueden almacenarse en una autoridad confiable pública, tal como una CA privada. Por lo tanto, el gestor de confianza local LTM puede verificarse por el contendiente, si se requiere. En particular, la atestación de gestor de confianza local LTM puede realizarse entre diferentes gestores de confianza locales así como entre el gestor de confianza local LTM y su al menos una unidad confiable local LTU, si se necesitara.
■ Emisor y verificador de certificado de confianza:
El gestor de confianza local LTM puede derivar un certificado de confianza que contiene una referencia a su propio certificado de confianza y que se asigna a al menos una unidad confiable local LTU. Un certificado de este tipo puede incluir parámetros de confianza (nativos o de una forma traducida) de al menos una unidad confiable local LTU.
El gestor de confianza local LTM puede verificar estos certificados de la al menos una unidad confiable local LTU, si se solicita (explícitamente) por otra parte (por ejemplo, en un entorno P2P).
Una vez que un gestor de confianza local LTM se conoce externamente, cualquier certificado y/o testigo emitido por este gestor de confianza local LTM (a por al menos una unidad confiable local LTU) también puede verificarse y certificarse.
■ El gestor de confianza local LTM se utiliza para determinar de forma segura y notificar el "nivel de confianza" (o incluso información más detallada) de su al menos una unidad confiable local LTU asignada. En particular, el gestor de confianza local LTM es capaz de traducir parámetros de confianza nativos de al menos una unidad confiable local LTU (tal como mediciones de seguridad de integridad troceados) a niveles y/o testigos de confianza especificados que tienen un significado semántico de tal forma que pueden entenderse, por ejemplo, por entidades externas.
Ejemplo: "Se permite y habilita que esta unidad confiable local LTU particular participe en transacciones hasta una cantidad de 5 euros" o "Esta unidad confiable local LTU particular tiene un nivel de parche de 'PL-1234'". Por lo tanto, el gestor de confianza local LTM puede comunicarse (en línea y/o fuera de línea) con una autoridad externa (por ejemplo, una tercera parte confiable) que proporciona al gestor de confianza local LTM información relacionada con la al menos una unidad confiable local LTU (por ejemplo, valores de medición de integridad específicos, asignaciones de capacidad u otros parámetros de confianza).
■ El gestor de confianza local LTM también puede operar en negociaciones de políticas y proporcionar restricciones de establecimiento de conformidad con política local para al menos una unidad confiable local LTU asignada.
Ejemplo: el gestor de confianza local LTM puede derivar y emitir un nuevo certificado a al menos una unidad confiable local LTU sin ninguna interacción externa. También, el gestor de confianza local LTM puede ordenar a la al menos una unidad confiable local LTU que entre en un estado seguro particular o el gestor de confianza local LTM puede configurar la al menos una unidad confiable local LTU según se requiera por una política. Sin embargo, para propósitos de gestión de software, el propio gestor de confianza local LTM puede solicitar ayuda de autoridades de gestión externas.
■ El gestor de confianza local LTM se habilita para gestionar el contexto de sesión de su al menos una unidad confiable local LTU asignada.
Esto es particularmente útil para asegurar que una única unidad confiable local LTU no puede cambiar su "estado de seguridad" específico al que se ha asignado durante una sesión confiable abierta sin que se note. Por lo tanto, se habilita que el gestor de confianza local LTM realice funciones de vigilancia para supervisar al menos una unidad confiable local LTU. Por ejemplo, el gestor de confianza local LTM supervisa un apuntador de instrucciones (IP) de al menos una unidad confiable local LTU que está en una sesión confiable. Si el apuntador de instrucciones de la LTU debido a un ataque de desbordamiento de memoria intermedia lanzado externamente se establece en una región de memoria de pila, puede enviar una notificación a entidades externas, invalidando de este modo esta sesión confiable particular.
■ El gestor de confianza local LTM también puede traducir y hacer cumplir emisiones de control externas a la al menos una unidad confiable local LTU.
Ejemplo: puede habilitarse que el gestor de confianza local LTM invalide un certificado de al menos una unidad confiable local LTU o puede cambiar la configuración y/o el establecimiento de software de al menos una unidad confiable local LTU por petición de una entidad autorizada (externa).
■ El gestor de confianza local LTM también puede asumir responsabilidad de emisiones de cobro (por ejemplo, supervisando transacciones de al menos una unidad confiable local LTU, el gestor de confianza local LTM puede crear y recopilar registros de datos de cobro y notificarlos bajo petición).
■ Para resumir tareas internas hacia al menos una unidad confiable local LTU, el gestor de confianza local LTM puede ser preferentemente responsable de atestación local, gestión de unidad local (con respecto a software y configuración, supervisión y control) así como para gestión de confianza (por ejemplo, credenciales, secretos, testigo, "personalización" de ID, pseudónimos, activación y desactivación, registro, control de sesión, etc.).
Unidad confiable local LTU
La al menos una unidad confiable local LTU es una unidad que se conecta o bien a otra al menos una unidad confiable local LTU o bien a servicios para transacciones comerciales.
Se confía en la al menos una unidad confiable local LTU en un sentido que está protegida contra manipulación hasta un cierto nivel que depende de una implementación técnica.
Además, cualquiera al menos una unidad confiable local LTU
■ es capaz de construir relaciones de seguridad y confianza y niveles de confianza basándose en procesos y credenciales controlados por el gestor de confianza local LTM asignado (véase "tareas internas" como se ha descrito anteriormente);
■ comunica con otros socios para consumir o incluso para ofrecer servicios de una forma que es conveniente para un dispositivo confiable;
■ se habilita para gestión de confianza remota como se ha descrito anteriormente (esto incluye en particular descarga y configuración de software remotas seguras).
Implementaciones y ventajas:
■ Este enfoque en particular permite y/o sugiere el uso de módulos de conformidad con un grupo de cálculo confiable (TCG), por ejemplo, usando un módulo de plataforma confiable (TPM) para el gestor de confianza local LTM y un módulo confiable móvil (MTM) para la al menos una unidad confiable local LTU (módulos confiables móviles permiten una gestión de software remota basada en certificados y soportan virtualización).
■ El gestor de confianza local LTM depende de credenciales a largo plazo y/o parámetros de confianza, mientras que las credenciales y parámetros de confianza de al menos una unidad confiable local LTU preferentemente serán temporales.
■ El uso del gestor de confianza local LTM también permite la utilización de pseudónimos locales y declaraciones de confianza que se hacen anónimas.
■ La Figura 3 muestra un escenario de aplicación típico. El cliente puede operar en una red P2P, se construyen relaciones de seguridad y confianza sobre la gestión de confianza local. Usando el enfoque presentado en este documento, un "plano de gestión" puede separarse de un "plano de transacción" como se muestra en la Figura 3. Los gestores de confianza locales LTM pueden gestionar la red P2P autoorganizando el establecimiento de seguridad/confianza para sus clientes pares (es decir, la respectiva al menos una unidad confiable local LTU) que puede intercambiar algún contenido P2P entre sí.
El gestor de confianza local LTM puede asegurar una funcionalidad de conmutación de la red P2P, asegurando por lo tanto una "accesibilidad" de pares que no pueden accederse por los propios pares de unidad confiable local LTU.
■ Si se notifica que el gestor de confianza local LTM o cualquiera de su al menos una unidad confiable local LTU es malicioso, puede informarse a autoridades externas (por ejemplo, un verificador de acuerdo con la Figura 3). Esto puede ayudar con respecto a la verificación de parámetros de confianza y credenciales gestor de confianza local LTM, pero también para propósitos de regeneración.
También es posible que se usen entidades externas para controlar la red P2P a través de gestores de confianza locales LTM.
La al menos una unidad confiable local LTU - que es parte de una transacción comercial - puede permanecer completamente anónima usando declaraciones de confianza y credenciales gestionadas por los gestores de confianza locales LTM asociados.
■ Una aplicación adicional es una funcionalidad de control parental de acuerdo con la Figura 4.
Un padre puede controlar la al menos una unidad confiable local LTU de un hijo a través del gestor de confianza local LTM. El gestor de confianza local LTM puede asignar pseudónimos, parámetros de confianza que se hacen anónimos y límites de crédito (determinados por sus padres) a al menos una unidad confiable local LTU (que actúa como un hijo) para su uso en transacciones comerciales restringidas.
El gobierno sobre el gestor de confianza local LTM y la al menos una unidad confiable local LTU se hace a través de mecanismos de propiedad apropiados.
■ Un gestor de confianza local LTM puede usarse para implementar funciones de medición de seguridad, supervisión, clasificación y carga de lado de dispositivo (por una infraestructura de operador de red móvil (MNO)) junto con cumplimiento y control local.
Ejemplo: cada vez más, la clasificación (por ejemplo, de un vendedor) será de interés particular usando tiendas de Internet. Esta clasificación es una clase de "mecanismo de autorización" controlado por humanos (basándose predominantemente en recomendaciones de otros compradores) que se usa de forma creciente en el campo de transacciones comerciales electrónicas.
Pueden soportarse dos clases de funciones de clasificación. Por ejemplo, el gestor de confianza local LTM puede vincular de forma segura las clasificaciones del propietario a todas las unidades confiables locales LTU y/o certificados que está usando el gestor de confianza local LTM en una transacción comercial:
- Clasificación P2P confirmada por la comunidad: por ejemplo, compradores de libros usados están clasificando vendedores;
- Clasificación confirmada por la autoridad: empresas, instituciones, servicios, etc. votan por la confianza de los usuarios.
■ En Máquina a Máquina (M2M) y/o comunicación de campo cercano (NFC), gestores de confianza locales LTM pueden asegurar la confianza local incluso en ausencia de una conectividad de red (central).
En particular es posible que este enfoque se aplique a un entorno con conectividad esporádica a tal red central a través de la cual puede accederse a una parte confiable.
Un ejemplo para una conectividad esporádica o arbitraria es un equipo de servicios que está pasando con un verificador o unidad de control externa.
■ La funcionalidad del gestor de confianza local LTM también puede realizar protección de mal uso, por ejemplo, en caso de un dispositivo robado.
El gestor de confianza local LTM puede invalidad de forma autónoma las credenciales de la al menos una unidad confiable local LTU localmente, si no se reautoriza de nuevo o acciona por petición.
Para una reautorización puede requerirse una presencia de un usuario y/o propietario. Como alternativa, el usuario y/o propietario puede controlar tal reautorización a través de una notificación enviada al verificador dentro de una red o dentro de una red P2P. La próxima vez que un gestor de confianza local LTM se conecta, se solicita la autorización de un propietario. Si falla tal autorización, se desactivará la al menos una unidad confiable local LTU.
■ Operadores de red pueden implicarse actuando como autoridad de control de nivel superior y final (verificador, VTP, etc.). También, los operadores de red (o proveedores) pueden soportar el cobro de consumidor a empresa de una manera fiable.
Por otra parte, los operadores y/o proveedores también pueden beneficiarse de capacidades de gestión local ya que este reduce carga de red y pueden dirigir una porción de la gestión de red requerida hacia el gestor de confianza local LTM que puede ser capaz en particular de procesar tal tarea en caso de una conectividad perdida.
El enfoque presentado en este documento también puede combinarse con un escenario de comunicación que incluye una segunda instancia y/o una tercera instancia. En particular, la segunda instancia puede solicitar a la primera instancia que proporcione un nivel de seguridad y/o confianza que necesita conseguir la tercera instancia implicada.
Lo siguiente describe, en particular, un escenario que comprende una primera instancia que puede estar equipada como se ha indicado anteriormente, es decir, con un gestor de confianza local y al menos una unidad confiable local. El enfoque descrito en este documento en particular se refiere a control de acceso al servicio basado en políticas de confianza (TPSAC) en un entorno de servicio (por ejemplo, Internet basado en IP) abierto.
Por consiguiente, en este documento se describen métodos que habilitan la gestión, negociación y uso de federación de confianza basada en políticas para servicios. Esto puede percibirse como un complemento a métodos de federación de identidades, habilitando de este modo una "confianza" medible (a entidades implicadas) y negociación basada en políticas y mecanismos de control de acceso.
El término "confianza" en este contexto comprende en particular relaciones de seguridad entre diferentes entidades que se basan en "dispositivos confiables", en particular relacionados con el contexto de la organización de normalización de grupo de cálculo confiable (TCG).
También, se proporcionan principios en relación con conexión de red confiable (TCG-TNC). Sin embargo, el enfoque presentado en este documento se refiere en particular a una vista céntrica de servicio y un entorno federado, controlado por usuario y abierto.
También, este enfoque se refiere en particular a "relaciones comerciales confiables" entre socios empresariales que se aseguran mediante mecanismos de confianza tales como marcos y contratos organizacionales, en particular mediante medios técnicos. Se conocen tecnologías que permiten negociar mecanismos de seguridad (por ejemplo, política de WS en conjunto con otras tecnologías de servicios web, políticas de privacidad según se proporcionan por, por ejemplo, plataforma para preferencias de privacidad P3P). Sin embargo, tales enfoques carecen de cualquier problema de "confianza" medido y gestionado.
El enfoque presentado en este documento en particular se ocupa del problema de un punto único (virtual) de gestión de confianza. Preferentemente, se usa un punto único de confianza (SPOT) para conseguir una solución de todo mediado por uno. Tal punto único de confianza se denomina como "virtual", porque ventajosamente varias instancias pueden necesitar cooperar.
Sin embargo, problemas de seguridad y privacidad pueden tener que respetarse de una manera fiable. El SPOT virtual necesita ser confiable para sí mismo, debido a su responsabilidad central en la mediación de confianza general, provisión y proceso de gestión. Esto puede basarse en contratos o medios técnicos y con precisión puede resolverse mediante arquitecturas de seguridad acompañantes.
Problemas de relaciones bilaterales (o multilaterales) podrían resolverse si ambas partes expresaron sus deseos en términos de políticas y negocian las condiciones antes de conceder/aceptar acceso al servicio. El enfoque proporcionado en este documento ventajosamente presenta una solución unificada e integral al mismo.
Problemas de confianza básicos se refieren a credenciales pueden asignarse a un usuario y/o al dispositivo de un usuario. Puede necesitarse que se soporten diferentes soluciones, en particular para usuarios que proceder de redes heterogéneas y/o usuarios que operan con un equipo diferente.
El equipo de usuario tiene que comprobarse de forma fiable y, si no se cumplen requisitos para acceder al servicio (por ejemplo, debido a un equipo no aceptado, o violación de políticas), pueden requerirse procesos de gestión de confianza.
Como un ejemplo, tal proceso de gestión de confianza puede comprobar las capacidades de dispositivo o un comando puede transmitirse al dispositivo para propósitos de configuración (por ejemplo, "habilitar Java Script") o pueden comprobarse valores de confianza del dispositivo ("atestación", políticas negociadas). En un escenario más complejo, un proceso de gestión de confianza puede incluir gestión de dispositivo remota extendida (por ejemplo, para preparar y vincular de forma segura credenciales necesarias a un estado del sistema o para habilitar descarga de software segura). También desactivación, revocación y control de riesgo (por ejemplo, para evitar el mal uso de dispositivos robados) es un problema de gestión de confianza del que puede hacerse cargo.
Este enfoque permite un servicio (mediante el uso de SPOT y federación de confianza) para utilizar, por ejemplo, grupo de computación confiable TCG (u otro mecanismo de confianza), sin basarse en una tecnología de acceso específica.
En entornos cerrados (por ejemplo, en una red móvil) el operador de red móvil se ocupa del cobro y la facturación. Sin embargo, esto está principalmente restringido a servicios de red y está soportando únicamente abonados propios (o de itinerancia) del respectivo operador de red móvil (conectando a través de, por ejemplo, dispositivos móviles xSIM/3GPP).
Este enfoque también proporciona una federación de datos de confianza (es decir, integrando mecanismos de computación confiable en principios de federación) así como gestión de confianza.
Adicionalmente, este enfoque puede extender algunos componentes de TCG, en particular puede usar los mismos en el contexto de un mecanismo de control de acceso de servicio unificado.
También, este enfoque permite incorporar (pero no está restringido a) declaraciones de autorización general (GA). La Figura 5 muestra un diagrama de bloques que comprende dos instancias que pueden usarse para comunicación de datos.
Una primera instancia 110 envía una petición 101 a una segunda instancia 120. La segunda instancia 120 envía un mensaje 102 (como una respuesta) que comprende una política. Esta política indica, por ejemplo, qué clase de información, datos, nivel de confianza se requiere de la primera instancia 110 para cumplir con la petición 101. La primera instancia 110 a continuación envía una información relacionada con la política 105 a la segunda instancia 120 y por lo tanto cumple con la política expuesta por la segunda instancia 120 en su mensaje 102.
Como un ejemplo, cumpliendo con la política de la segunda instancia 120 enviando la información relacionada con la política 105, la primera instancia 110 se autentica a sí misma a la segunda instancia 120. Posteriormente, la segunda instancia 120 puede cumplir con la petición 101 de la primera instancia 110 proporcionando la información 150. Esta información 150 puede referirse adicionalmente a comunicación de datos que se intercambia bilateralmente.
La Figura 6 muestra la primera instancia 110 y la segunda instancia 120 de acuerdo con la Figura 5 además de una tercera instancia 130.
Antes de enviar la información relacionada con la política 105 a la segunda instancia 120, la primera instancia 110 envía una petición 103 que se refiere a la política requerida por la segunda instancia 120 (enviada a través del mensaje 102) a la tercera instancia 130.
Esto puede convertirse, en particular, necesario si la segunda instancia 120 indica a través de su mensaje 102 que se requiere un nivel de confianza que no puede cumplirse por la primera instancia 110 sola (por ejemplo, la segunda instancia 120 no va a confiar en la primera instancia 110 únicamente porque la primera instancia 110 le dirá la segunda instancia 120 que haga eso). Por lo tanto, se requiere una parte confiable (en este punto: la tercera instancia 130) tanto para la primera instancia 110 como la segunda instancia 120.
Por consiguiente, la tercera instancia 130 produce una información relacionada con la política 104 tras la recepción de la petición 103 y envía la misma a la primera instancia 110. La primera instancia 110 reenvía la información relacionada con la política a la segunda instancia 120 a través del mensaje 105.
La información relacionada con la política 104 generada por la tercera instancia 130 puede basarse en información 107 proporcionada por al menos un servidor de gestión de dispositivos 140 a la tercera instancia 130. Tal información 107 puede referirse al dispositivo particular de la primera instancia 110, por ejemplo, un tipo de un teléfono celular proporcionado por un cierto fabricante, y/o al menos una aplicación que se ejecuta en la primera instancia 110.
Adicionalmente, la segunda instancia 120 puede proporcionar información adicional 106 que se requiere para generar la información relacionada con la política 104 en línea o fuera de línea. Tal información también puede almacenarse en bases de datos separadas.
La información relacionada con la política puede proporcionar un testigo, un atributo, un certificado, un conjunto de reivindicaciones, un programa a ejecutar en la primera instancia 110, parámetros de un programa a ejecutar en la primera instancia 110, información proporcionada por el servidor de gestión de dispositivos 140 y/o información proporcionada por la segunda instancia 120.
Como una realización particular, la primera instancia 110 puede ser un terminal, en particular un teléfono móvil, la segunda instancia 120 puede ser un proveedor de servicios, en donde la primera instancia 110 y la segunda instancia se conectan a través de una red fija o a través de una red inalámbrica. La tercera instancia 130 puede ser una empresa de confianza que puede conectarse a la primera instancia 110 y/o a la segunda instancia 120 a través de una red fija o a través de una red inalámbrica.
Se ha de observar que una aplicación de red puede comprender una red de expansión limitada como en la comunicación de campo cercano (NFC). Un escenario de este tipo puede comprender un número limitado de, por ejemplo, dos a tres instancias.
La Figura 7 muestra un esquema de control de acceso de acuerdo con una realización presentada con este enfoque. La Figura 7 muestra cómo se realiza un punto único de confianza (SPOT) y que en una etapa 6 el cliente recibe un testigo que federa la confianza de diferentes entidades de soporte de confianza (véase la Figura 8 como se describe a continuación). A continuación se explican los conceptos.
Suposiciones
Se asume que un servicio o un proveedor posee cada al menos un certificado (con una clave pública y una clave privada). Esto se usa para la gestión segura desde el cliente al servidor y para establecer canales seguros (por ejemplo, a través de TLS) así como para autenticación mutua.
Conexión
Un usuario en un cliente U desea conectarse a un servicio A que requiere acceso (1) para usar ese servicio A. El servicio A puede basarse en IP y está abierto a cualquier cliente que se acepte. Sin embargo, para ser aceptado, tienen que cumplirse varias condiciones.
Política de confianza
Estas condiciones se expresan en términos de una así denominada política de confianza proporcionada por el servicio A después de que el cliente U se conecta (2).
La política de confianza está relacionada con seguridad y debería protegerse preferentemente de una manera adecuada, por ejemplo, mediante un mecanismo de firma. La política incluye los siguientes aspectos (pero no está restringida a estos) que debe negociarse entre el cliente U y el servicio A.
Como una alternativa, el cliente U puede ofrecer una política existente con la que está de conformidad y el servicio A puede decidir si aceptar la misma o iniciar el proceso de negociación como se expone.
■ Software de cliente requerido para conexión
El servicio A requiere que un software esté disponible y se ejecute en el cliente U.
Esto puede ser un problema relacionado con la seguridad (por ejemplo, prescribiendo un cierto entorno de tiempo de ejecución como un navegador confiable y/o un software convencional confiable). También puede ser un problema específico del servicio, ya que el propio servicio A (o una tercera parte (preferentemente confiable) afiliada) puede proporcionar una pieza de software (confiable) (por ejemplo, un módulo de ordenación, comunicación o pago confiable) para cumplimiento con política a ejecutar en el cliente U.
El servicio A también puede aceptar preferencias de usuario así como alternativas a las mismas (por ejemplo, un navegador favorito en el cliente U) si esto está conforme con la política.
■ Nivel de confianza (TL)
El servicio A proporciona información del nivel de confianza asociada con un nivel de confianza que se espera del cliente U.
Esto puede incluir configuración del cliente, estado de cliente activo durante la comunicación de servicio, capacidades de seguridad, nivel de parche del software de cliente, presencia de herramientas de detección/prevención de intrusión (IDS/IDP) local ejecutándose en el cliente, u otras capacidades de cliente que no necesitan ser directamente pertinentes a la confianza en sí mismas (por ejemplo, protocolos habilitados, velocidad de CPU, parámetros de QoS). Sin embargo tales capacidades son preferentemente revisables y deberían notificarse de una manera confiable.
El nivel de confianza puede ser un valor predefinido (por ejemplo, conocido por el proveedor de confianza o cualquier otra entidad externa confiable). También puede describirse por una especificación de nivel de confianza.
■ Especificación de nivel de confianza (TL)
Puede proporcionarse una especificación de nivel de confianza de una manera formalizada y/o intercambiable, por ejemplo, usando un lenguaje de marcas extensible (XML).
Usando mecanismos de computación confiable puede comprender valores de condiciones previas (certificados de medición de integridad remota (RIM-Cert) que describen software esperado a descargarse en un dispositivo) y condiciones posteriores (por ejemplo, valores de medición de integridad (IMV)) que pueden notificarse de forma segura por el cliente U cuando se comprueba para la prestación del servicio A.
■ Sincronización de tiempo, indicaciones de tiempo
La política de confianza puede requerir especificaciones con respecto a confianza o sincronización de la hora local que se ejecuta en el cliente U durante su conexión con el servicio A.
También, pueden expresarse requisitos de comportamiento, por ejemplo, un requisito para usar indicaciones de tiempo cuando se intercambian mensajes con el servicio A.
■ Modo de aceptación
Tras la conexión, el cliente U puede aceptarse directamente por el servicio A. Este caso es de relevancia cuando se usan mecanismos de computación confiable. De acuerdo con el modo de aceptación, el servicio A puede especificar los mecanismos a usar cuando se conectan, por ejemplo, atestación, testigo REL, reverificación, certificados, periodos de validez, credenciales selladas, testigo, secreto compartido, etc.
En principio, existen varias alternativas:
a) El cliente U está preparado y ya comprobado por otra instancia, por ejemplo, un proveedor de confianza virtual VTP, equipando de este modo al cliente U con testigos adecuados, certificados o credenciales que tienen que reenviarse al servicio A cuando se conecta.
El servicio A confía en las credenciales o información generada por el proveedor de confianza virtual VTP, pero también puede pedir al proveedor de confianza virtual VTP un detalle adicional o verificación adicional.
b) El propio servicio A comprueba el cliente U tras la conexión. Tal inspección puede prepararse ventajosamente por el proveedor de confianza virtual VTP (por ejemplo, a través de gestión de dispositivo remota).
Además, el proveedor de confianza virtual VTP puede soportar verificación (por ejemplo, proporcionando los valores de verificación esperados) para aprovechar los mecanismos basados en TCG.
■ Tipo de ID
El servicio A puede establecer tipo o tipos de ID que el cliente U tiene que proporcionar durante autenticación y/o atestación (ejemplos: ID de dispositivo, Id de usuario, uso de anonimato y de pseudónimos, AIK).
■ Modo de autenticación
El servicio A puede especificar cómo tiene que autenticarse el cliente en el proveedor de confianza virtual VTP para preparación de acceso al servicio (red 3GPP/xSIM, uso de arquitectura de autenticación genérica GAA, uso de atestación de TCG, RIM GA/AIK, Web, certificado, contraseña, etc.)
■ Modo de cobro y pago
El servicio A especifica cómo debería considerarse el cobro y pago. Esto permite el establecimiento de un respectivo esquema de pago para el cliente U que usa el servicio A.
■ Privacidad
También pueden cubrirse problemas relacionados con plataforma para preferencias de privacidad P3P.
■ Autorización
Si el servicio A necesita autorizaciones (por ejemplo, derechos específicos para acceder al cliente U y/o garantías de pago del cliente U, puede especificarse qué clase de información usar y cómo implementar el mecanismo de autorización (por ejemplo, usando testigo REL, usando mecanismos específicos de servicios, usando tecnología de XACML, etc.). También los contratos o términos de negociación pueden estar sujetos a una política.
Política de cliente local
El cliente U puede tener sus propias políticas (locales) (pueden ser diferentes, por ejemplo, dependiendo de un estado de sistema) que pueden coincidir con los problemas relacionados con políticas de servidor y extensiones que son específicas de usuario o cliente.
En particular, tales extensiones pueden cubrir capacidades de dispositivo (seguridad, confianza, protocolos, etc.), privacidad de usuario (uso de anonimato) y atributos de federación (qué atributos se habilitan para federación, y cuáles no).
Negociación y resolución de política
Los mecanismos de control de acceso a aplicar pueden negociarse entre los socios comerciales implicados usando "políticas de confianza y privacidad" expresando sus respectivas expectativas que pueden medirse y gestionarse por entidades especialidades a través del proveedor de confianza virtual VTP.
Después de enviar la política al cliente U, el cliente U se conecta al proveedor de confianza virtual VTP (el cliente U puede elegir una selección del proveedor de confianza virtual VTP) para negociaciones de política y preparaciones (3).
En el proveedor de confianza virtual VTP, se conoce el cliente U, una relación comercial entre el proveedor de confianza virtual VTP y el cliente U se ha establecido preferentemente antes de tal conexión. Una relación comercial de este tipo puede basarse en, por ejemplo, un contrato y una suscripción inicial que permite que el proveedor de confianza virtual VTP autentique al cliente U.
Como se ha descrito anteriormente, el cliente U puede tener su propia política local para expresar su propio nivel de confianza requerido (por ejemplo, una privacidad de usuario del cliente U). Tal política local del cliente U también puede comprender capacidades de habilitación y/o compatibilidades y/o cumplimientos. La política local del cliente U puede enviarse al proveedor de confianza virtual VTP junto con la política del servicio A.
A continuación, el proveedor de confianza virtual VTP comprueba si las diferentes políticas (del servicio A así como del cliente U) pueden emparejarse y/o combinarse (4). El proveedor de confianza virtual VTP también decide qué hacer si no hay coincidencia. Una solución para resolver tal falta de coincidencia es una actualización del cliente U a través de gestión remota. Como alternativa, o además el proveedor de confianza virtual VTP puede comunicarse con el servicio A para encontrar una solución apropiada de dicha falta de coincidencia.
Como una alternativa adicional, el servicio A puede actualizarse para cumplir con la política negociada.
Si es necesario, el proveedor de confianza virtual VTP puede iniciar y operar procedimientos de gestión de dispositivo remotos (5) para hacer el dispositivo conforme con la política. Esta etapa puede basarse preferentemente en mecanismos de computación confiable. También, tales mecanismos de seguridad negociados para el servicio A pueden establecerse en esta etapa (5), es decir, pueden determinarse testigo, certificados, mecanismos de vinculación y sellado, prerrequisitos de seguridad, etc.
El proveedor de confianza virtual VTP suministra al cliente U un conjunto de declaraciones, testigos o similar que cumple con la política como se expone por y/o negociada (a negociar) con el servicio A.
Autenticación, comprobación de cliente y establecimiento
En la siguiente etapa (6) que puede retrasarse o procesarse de forma repetida, el cliente U se conecta al proveedor de confianza virtual VTP en condiciones (usando la política resultante) que se han negociado para el acceso al servicio (mediante el servicio A de acuerdo con el ejemplo mostrado en la Figura 7; sin embargo, cualquier otra política de confianza de servicio podría estar sujeta a esta fase).
El cliente U obtiene una declaración como una prueba para identificación satisfactoria, autenticación y/o atestación (y otras comprobaciones de seguridad que pueden considerarse necesarias para autorización).
Como una alternativa, dependiendo de un modelo del proveedor de confianza virtual VTP y dependiendo de una relación (comercial) entre el proveedor de confianza virtual VTP y el cliente U, el proveedor de confianza virtual VTP puede equipar al cliente U con autorizaciones que pueden transportarse a través de un testigo REL o implícitamente a través de mecanismos de artefactos/declaraciones. Si es necesario, el servicio A puede (directamente) contactar con el proveedor de confianza virtual VTP.
Acceso al servicio
Una vez equipado con todos los mecanismos y credenciales y declaraciones/artefactos, el cliente U puede conectar con el servicio A en una etapa (7) de acuerdo con la política de confianza expuesta por el servicio A y/o el cliente U. El servicio A puede aceptar al cliente U posterior a una etapa (8). Tal aceptación, sin embargo, puede estar sujeta a comprobaciones adicionales. Si el cliente U proporciona una identidad (pseudónimo) generado por el proveedor de confianza virtual VTP (en el que el cliente U tiene una cuenta registrada) depende del servicio A usar esta identidad directamente o generar su propia gestión de identidad (IDM) basándose en ID y/o datos generador y proporcionados por el proveedor de confianza virtual VTP (por ejemplo, si existe una necesidad de asociar una dirección de entrega para productos comprados o si el servicio quiere almacenar el "comportamiento de pago" de esa identidad).
Otro problema para la información intercambiada entre el servicio A y el proveedor de confianza virtual VTP puede resumirse como se indica a continuación: Si un usuario "hostil" con un pseudónimo solicita otro pseudónimo para el mismo servicio A, porque se ha bloqueado su antigua cuenta, el proveedor de confianza virtual VTP debería informar al servicio A comprendiendo un mensaje como: "User_1123 es ahora USER_XYV".
Si el cliente U está federado a otros servicios depende de la política del cliente decidir si usar los mismos o diferentes ID para cada uno de estos servicios.
También es posible que el acceso al servicio sea completamente anónimo. En este caso, el servicio A está confiando en la "declaración" sola (que es, por ejemplo, particularmente útil para transacciones de una sola vez como, por ejemplo, "Este usuario anónimo ha ganado una competición - por favor, entréguenle bienes por valor de 20 EUR - Garantizaré el pago". - expresados por un testigo REL enviado dentro de una declaración por el servicio A).
Depende del servicio A aceptar adicionalmente este cliente U únicamente después de que una comprobación de proveedor de confianza virtual VTP anterior o para ejecutar un procedimiento de inicio de sesión propio con ese cliente U usando sus ID conocidos y valores de confianza.
Ejemplo: en casos en los que posterior a un registro basado en xSIM inicial a través del proveedor de confianza virtual VTP únicamente se requieren ID y PW, esta clase de inicio de sesión simplificado es viable. Si el proveedor de confianza virtual VTP se necesita para una gestión de dispositivo remota, por ejemplo, para propósitos de sincronización de tiempo o para credenciales de corto plazo, el inicio de sesión simplificado como se ha indicado anteriormente no es viable.
Conjuntos de datos de confianza, incluyendo declaraciones para acceso al servicio
El proveedor de confianza virtual VTP (después de comprobar el cliente U) proporciona declaración, datos de confianza y credenciales necesarios para acceder al servicio A por dicho cliente U. La información proporcionada por el proveedor de confianza virtual VTP se refiere en particular a valores y puede comprender al menos uno de los siguientes:
■ Testigo de sesión:
valor firmado por el proveedor de confianza virtual VTP, que comprende en particular un periodo de validez; el testigo de sesión puede existir siempre. Confirma que el proveedor de confianza virtual VTP firmante comprobó este cliente U para acceso al servicio y que existe un conjunto de datos de confianza conformes con la política. El testigo de sesión puede asociarse en particular con un uso inherente por hora y fecha.
■ Tratamiento de confianza:
secreto compartido, haciendo referencia a un conjunto de datos posterior en el proveedor de confianza virtual VTP y en el cliente U; el tratamiento de confianza puede existir siempre. Es un secreto compartido entre el cliente U y el proveedor de confianza virtual VTP, usado para identificar inequívocamente el conjunto de datos.
■ (pseudónimo) ID de usuario;
■ (pseudónimo) ID de dispositivo;
■ Declaraciones o tratamientos de declaraciones:
transportar o referenciar la "afirmación de confianza" confirmada por el proveedor de confianza virtual VTP; ■ Credenciales/secretos (incluyendo testigos de valor);
■ Política negociada;
■ Otros datos
tales como información de sincronización de tiempo o indicaciones de tiempo, límites de crédito, pistas desde el proveedor de confianza virtual VTP con respecto al servicio específico (también el proveedor de confianza virtual VTP podría enviar referencias a servicios conformes con la política);
Intercambio de información entre el servicio A y el proveedor de confianza virtual VTP
El servicio A es libre de contactar con el proveedor de confianza virtual VTP para conseguir información adicional con respecto a, por ejemplo, negociación de política, declaración o cualquier otro intercambio de información adicional entre el proveedor de confianza virtual VTP y el servicio A (9). Esto incluye información de confianza (tal como valores de medición de integridad (IMV) si la política de confianza requería reatestación en el momento de conexión, valores de sincronización de tiempo, credenciales y secretos compartidos, datos de federación o información de pago/cobro).
Además, información con respecto a posibles brechas de seguridad, clientes en listas negras, revocaciones, etc. puede solicitarse del proveedor de confianza virtual VTP. Los protocolos subyacentes necesitan garantizar que el propio proveedor de confianza virtual VTP no es consciente de los secretos que se comparten entre el cliente U y el servicio A únicamente.
Cobro y pago
Antes, durante (prepago) o después (pospago) de que el cliente U usa servicio A, este servicio A puede hacer uso del proveedor de confianza virtual VTP para soporte de pago/cobro (9).
En este sentido, el servicio A puede enviar registros de cobro al proveedor de confianza virtual VTP que puede reenviar los mismos al proveedor de red móvil o a cualquier proveedor de pago de la elección del usuario.
Las modalidades de pago también pueden depender de la autorización del cliente U obtenida durante la fase de "autenticación, comprobación de cliente y establecimiento". Por ejemplo, un testigo REL podría transportar una información de contabilidad confirmada, indicando "este cliente U puede consumir servicios por una cantidad de 5 EUR". Tal información de contabilidad también puede ser parte de una declaración intercambiada entre el proveedor de confianza virtual VTP y el servicio A.
Entidades de soporte de confianza y bases de datos
El proveedor de confianza virtual VTP se referencia como "virtual", en particular porque técnicamente actúa como un punto único de gestión de confianza (véase anteriormente) tanto para el servicio A así como el cliente U.
El proveedor de confianza virtual VTP puede comprender y/o interactuar con varias entidades que están implicadas en la provisión de confianza basada en política, negociación de privacidad, procesos de cobro y pago.
Entidades particularmente pertinentes en este sentido son
■ Operadores de red (móviles) (para soportar una autenticación inicial derivada a partir de un acceso de red satisfactorio, por ejemplo, a través de xSIM, GAA, SSC o IMS o a través de una red fija);
■ Autoridades de certificación para soporte de certificado/PKI (por ejemplo, certificados de autorización RIM y certificados RIM);
■ Entidades de soporte de TCG (proporcionando mecanismos de conformidad con TCG e información para integrar mecanismos de computación confiable, software con capacidad RIM);
■ Plataforma para preferencias de privacidad (P3P) para soporte de política de privacidad;
■ Certificados (CERT) para soporte de vulnerabilidad de dispositivo y software, proveedores de cobro y pago; ■ Otros proveedores de confianza virtuales (VTP) (asociados) (por ejemplo, en escenarios de itinerancia o dominio cruzado).
Se hace referencia a la Figura 8 para propósitos de ilustración adicionales en este sentido.
Federación de confianza
El esquema de control de acceso al servicio basado en política mostrado en la Figura 7 puede extenderse mediante mecanismos de federación de confianza como se indica. Existen diferentes formas de lograr un resultado ya que los principios a aplicar preferentemente dependen de preferencias de usuario y políticas negociadas con servicios federados.
En la Figura 9 y en la Figura 10 se muestra un esquema de federación de confianza.
Después de ser aceptado por el servicio A, el cliente U se vincula a un servicio B. En este ejemplo, el cliente U no quiere que su VTP-ID se comparta con el servicio B y por lo tanto cliente U únicamente muestra al servicio B su referencia al servicio A (privacidad: testigo firmado opcional desde el servicio A), la política de confianza TP resultante, el testigo de sesión ST, así como el tratamiento de confianza TH troceado. Esto se visualiza en la etapa (10) de la Figura 9.
En inicio de sesión en el servicio B puede hacerse como se describe por la siguiente secuencia de mensajes:
EncpUbK-B (ST, h(TH,r), Ref-ServiceA, TP,
LoginCredentials)
Posteriormente, el servicio B conoce que el cliente U está confirmado por el servicio A, tiene una política de confianza aceptada (que el servicio B puede comprobar de nuevo) y que todas las condiciones dadas en la política de confianza ya se han comprobado por el proveedor de confianza virtual VTP. "Ref-ServiceA" puede contener cualquier dato del servicio A (por ejemplo, una recomendación, puntos de valor, límites de crédito diarios, etc.), pero pueden ser en particular datos que son comprensibles para el cliente U (por ejemplo, para comprobaciones de política de privacidad).
El servicio B confía en este procedimiento de inicio de sesión simplificada, pero puede pedir opcionalmente directamente al proveedor de confianza virtual VTP información adicional (siempre y cuando esto esté permitido por la política de privacidad). Como se ha descrito anteriormente, el cliente U puede conseguir una identidad/pseudónimo que es específico para el servicio B. Esto también se envía al proveedor de confianza virtual VTP para evitar un posible mal uso de ID multiplicados (que pueden usarse para eludir listas negras).
Ejemplo: pago anónimo a través de "banca domestica invocada por el servicio"
Un servicio que acepta un usuario (bajo un pseudónimo o de forma anónima) tiene un contrato con el banco de este usuario. Sin embargo, el servicio no conoce la identidad real del usuario, por ejemplo, su nombre.
Para propósitos de pago, el usuario federa su ID de servicio y sus datos de confianza directamente a su banco y obtiene un formulario prerrellenado que está vinculado a la cuenta bancaria del usuario (el efecto es similar a la banca doméstica desencadenada directamente por una función de pago de servicios). El propio pago se hace a través de una cuenta anónima mantenida por el banco con una referencia al pseudónimo del usuario (el proveedor de confianza virtual VTP ayuda a la resolución de ID) junto con una confirmación de que la cuenta del usuario real se ha cargado ahora.
El servicio no puede descubrir la identidad del usuario. Además, el banco no conoce qué ha comprado este usuario (que se conoce ahí). Los datos de confianza ayudan a asegurar esta clase de transacción.
El enfoque proporcionado en este documento combina varios métodos e infraestructuras en un enfoque unificado. Esto permite una integración controlada por servicio/usuario de control de acceso agnóstico a la red, mecanismos de computación confiable, principios de federación y privacidad, negociación de política unificada, gestión de dispositivo remota y federación de confianza, basándose en ID de usuario y de dispositivo.
Las siguientes ventajas son evidentes en particular:
■ Los mecanismos y funciones descritos (por ejemplo, proveedor de confianza virtual VTP, entidades de soporte de confianza) habilitan modelos de negocio innovadores para las así denominadas empresas de confianza (TrustCos).
■ Se soporta una integración de valores de confianza y/o testigos en un proceso (comercial) y/o negociación entre partes (instancias), permitiendo de este modo integrar cobro y pago.
■ Mediante la gestión de confianza se soporta una integración de operadores de red (móviles) y proveedores de servicios (por ejemplo, integrando pago/cobro). También, se mejora la gestión de riesgo, por ejemplo en caso de dispositivos robados o abusados.
■ Este enfoque aprovecha, generaliza y mejora el control de acceso al servicio, haciendo el mismo independiente de mecanismos dependientes de red subyacentes (agnóstico de red).
■ Un "conjunto de datos de confianza" introducido extiende y complementa "declaraciones" que contienen únicamente información de autorización y autenticación en una vista más generalizada con respecto a "confianza". Por lo tanto, problemas relacionados con computación confiable y dispositivo (integridad de dispositivo, ID de dispositivo) pueden combinarse con un contexto de federación.
■ El mecanismo introducido depende del intercambio de mensajes o de testigos y puede implementarse con bastante independencia de protocolos específicos (por ejemplo, HTTP).
■ Mediante negociación de política de confianza este enfoque permite una conformidad enfatizada de servicio de condiciones de control de acceso y al mismo tiempo respeta las preferencias de usuario, privacidad y capacidades de dispositivo.
■ Este enfoque proporciona adicionalmente mecanismos de SSO para servicios con reconocimiento de confianza.
■ Adicionalmente, se soporta la composición de servicio, ya que un servicio conectado puede federarse y puede usar una SSO confiable con la misma política de confianza.
■ Uso unificado de políticas es un problema que también se resuelve por los mecanismos de acceso introducidos en este documento.

Claims (15)

REIVINDICACIONES
1. Un método para procesamiento de datos que comprende una primera instancia que comprende al menos una unidad confiable local y un gestor de confianza local, comprendiendo el método
- la unidad confiable local recibe una petición de un nivel de confianza desde una segunda instancia,
- el gestor de confianza local determina un nivel de confianza,
- el gestor de confianza local proporciona el nivel de confianza a la unidad confiable local, y
- la unidad confiable local transmite el nivel de confianza a la segunda instancia.
2. El método de acuerdo con la reivindicación 1, en donde el gestor de confianza local está configurado para realizar una atestación local.
3. El método de la reivindicación 1, en donde la unidad confiable local es una aplicación que quiere comunicarse con la segunda instancia.
4. El método de la reivindicación 1, en donde el nivel de confianza se incluye en un certificado.
5. El método de la reivindicación 1, en donde el gestor de confianza local proporciona el nivel de confianza basándose en un mensaje enviado por la segunda instancia.
6. Un dispositivo, en particular una primera instancia, que comprende una unidad confiable local y un gestor de confianza local; en donde
- la unidad confiable local está configurada para recibir una petición de un nivel de confianza desde una segunda instancia,
- el gestor de confianza local está configurado para determinar un nivel de confianza,
- el gestor de confianza local está configurado para proporcionar el nivel de confianza a la unidad confiable local, y
- la unidad confiable local está configurada para transmitir el nivel de confianza a la segunda instancia.
7. El dispositivo de la reivindicación 6, en donde el gestor de confianza local está configurado para realizar una atestación local.
8. El dispositivo de la reivindicación 6, en donde la unidad confiable local es una aplicación que quiere comunicarse con la segunda instancia.
9. El dispositivo de la reivindicación 6, en donde el gestor de confianza local notifica un nivel de confianza de al menos una unidad confiable local a la segunda instancia.
10. El dispositivo de la reivindicación 6, en donde el gestor de confianza local proporciona el nivel de confianza basándose en un mensaje enviado por la segunda instancia.
11. El dispositivo de la reivindicación 6, en donde el nivel de confianza se incluye en un certificado.
12. El dispositivo de la reivindicación 6, en donde el dispositivo y/o la segunda instancia están configurados para conectarse a una tercera parte confiable para confirmar el nivel de confianza.
13. El dispositivo de la reivindicación 12, en donde el gestor de confianza local está configurado para comunicarse en línea con la tercera parte confiable.
14. El dispositivo de cualquier reivindicación anterior 6 a 13, en donde el dispositivo es un dispositivo de comunicación, en particular un equipo de usuario, un terminal de usuario, un teléfono móvil, un ordenador móvil; o asistente digital personal.
15. El dispositivo de cualquier reivindicación anterior 6 a 14, en donde la segunda instancia es un proveedor de servicios y la primera instancia y la segunda instancia se conectan a través de una red inalámbrica.
ES19179349T 2007-05-09 2008-04-29 Método y dispositivo para procesamiento de datos y sistema de comunicación que comprende tal dispositivo Active ES2844248T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP07009309A EP1990750A1 (en) 2007-05-09 2007-05-09 Method and device for data processing and communication system comprising such device

Publications (1)

Publication Number Publication Date
ES2844248T3 true ES2844248T3 (es) 2021-07-21

Family

ID=38596372

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19179349T Active ES2844248T3 (es) 2007-05-09 2008-04-29 Método y dispositivo para procesamiento de datos y sistema de comunicación que comprende tal dispositivo

Country Status (6)

Country Link
US (1) US8966568B2 (es)
EP (3) EP1990750A1 (es)
ES (1) ES2844248T3 (es)
PL (1) PL3557456T3 (es)
UA (1) UA96991C2 (es)
WO (1) WO2008138747A2 (es)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7657871B2 (en) 2005-07-22 2010-02-02 Sbc Knowledge Ventures, L.P. Method and system of managing configuration profiles of a plurality of deployed network elements
US20100250949A1 (en) * 2009-03-31 2010-09-30 Torino Maria E Generation, requesting, and/or reception, at least in part, of token
CN102460453B (zh) * 2009-04-13 2014-12-24 黑莓有限公司 用于确定sip消息的可信度的***和方法
US9760885B1 (en) 2010-03-23 2017-09-12 Amazon Technologies, Inc. Hierarchical device relationships for geolocation-based transactions
US20110238476A1 (en) * 2010-03-23 2011-09-29 Michael Carr Location-based Coupons and Mobile Devices
US9665864B2 (en) * 2010-05-21 2017-05-30 Intel Corporation Method and device for conducting trusted remote payment transactions
US8959218B2 (en) * 2010-06-21 2015-02-17 Cox Communications, Inc. Secure dynamic quality of service using packetcable multimedia
US9208318B2 (en) 2010-08-20 2015-12-08 Fujitsu Limited Method and system for device integrity authentication
WO2012023050A2 (en) 2010-08-20 2012-02-23 Overtis Group Limited Secure cloud computing system and method
US9111079B2 (en) 2010-09-30 2015-08-18 Microsoft Technology Licensing, Llc Trustworthy device claims as a service
US9965768B1 (en) 2011-05-19 2018-05-08 Amazon Technologies, Inc. Location-based mobile advertising
US9894040B2 (en) 2012-09-11 2018-02-13 Microsoft Technology Licensing, Llc Trust services for securing data in the cloud
US8959351B2 (en) * 2012-09-13 2015-02-17 Microsoft Corporation Securely filtering trust services records
CN114331453A (zh) * 2015-03-02 2022-04-12 创新先进技术有限公司 数据传输的方法及***
US10803175B2 (en) * 2015-03-06 2020-10-13 Microsoft Technology Licensing, Llc Device attestation through security hardened management agent
CN106686599B (zh) 2015-11-05 2020-10-20 创新先进技术有限公司 一种用于应用信息的风险管理的方法与设备
US10318723B1 (en) * 2016-11-29 2019-06-11 Sprint Communications Company L.P. Hardware-trusted network-on-chip (NOC) and system-on-chip (SOC) network function virtualization (NFV) data communications
US10482034B2 (en) * 2016-11-29 2019-11-19 Microsoft Technology Licensing, Llc Remote attestation model for secure memory applications
RU2693330C2 (ru) 2017-12-27 2019-07-02 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для авторизации пользователя для выполнения действия в электронном сервисе
US11132681B2 (en) 2018-07-06 2021-09-28 At&T Intellectual Property I, L.P. Services for entity trust conveyances
US10802872B2 (en) 2018-09-12 2020-10-13 At&T Intellectual Property I, L.P. Task delegation and cooperation for automated assistants
US11481186B2 (en) 2018-10-25 2022-10-25 At&T Intellectual Property I, L.P. Automated assistant context and protocol
US10965551B2 (en) * 2018-11-21 2021-03-30 Microsoft Technology Licensing, Llc Secure count in cloud computing networks
US11451396B2 (en) * 2019-11-05 2022-09-20 Microsoft Technology Licensing, Llc False positive reduction in electronic token forgery detection
US11687919B2 (en) 2020-06-08 2023-06-27 VBN Holdings, LLC System for dynamic network authentication protocols
US11569995B2 (en) 2021-03-15 2023-01-31 Seagate Technology Llc Provisional authentication of a new device added to an existing trust group
US11695772B1 (en) * 2022-05-03 2023-07-04 Capital One Services, Llc System and method for enabling multiple auxiliary use of an access token of a user by another entity to facilitate an action of the user

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6691232B1 (en) * 1999-08-05 2004-02-10 Sun Microsystems, Inc. Security architecture with environment sensitive credential sufficiency evaluation
US20030061506A1 (en) * 2001-04-05 2003-03-27 Geoffrey Cooper System and method for security policy
GB0027280D0 (en) * 2000-11-08 2000-12-27 Malcolm Peter An information management system
GB2372594B (en) * 2001-02-23 2004-10-06 Hewlett Packard Co Trusted computing environment
US20050097342A1 (en) * 2001-05-21 2005-05-05 Cyberscan Technology, Inc. Trusted watchdog method and apparatus for securing program execution
GB2382419B (en) * 2001-11-22 2005-12-14 Hewlett Packard Co Apparatus and method for creating a trusted environment
JP4039277B2 (ja) * 2003-03-06 2008-01-30 ソニー株式会社 無線通信システム、端末、その端末における処理方法並びにその方法を端末に実行させるためのプログラム
US7631346B2 (en) * 2005-04-01 2009-12-08 International Business Machines Corporation Method and system for a runtime user account creation operation within a single-sign-on process in a federated computing environment
US7447908B2 (en) * 2005-05-09 2008-11-04 Silverbrook Research Pty Ltd Method of authenticating a print medium offline

Also Published As

Publication number Publication date
EP3557456B1 (en) 2020-10-21
US8966568B2 (en) 2015-02-24
WO2008138747A3 (en) 2009-02-05
EP2158558B1 (en) 2019-06-12
EP1990750A1 (en) 2008-11-12
EP2158558A2 (en) 2010-03-03
EP3557456A1 (en) 2019-10-23
US20110131627A1 (en) 2011-06-02
PL3557456T3 (pl) 2021-04-19
UA96991C2 (ru) 2011-12-26
WO2008138747A2 (en) 2008-11-20

Similar Documents

Publication Publication Date Title
ES2844248T3 (es) Método y dispositivo para procesamiento de datos y sistema de comunicación que comprende tal dispositivo
US9621355B1 (en) Securely authorizing client applications on devices to hosted services
Carretero et al. Federated identity architecture of the European eID system
ES2773739T3 (es) Servicio de delegación de usuario a usuario en un entorno de gestión de identidad federada
Sicari et al. A policy enforcement framework for Internet of Things applications in the smart health
Suomalainen et al. Secure information sharing between heterogeneous embedded devices
CN109587100A (zh) 一种云计算平台用户认证处理方法及***
RU2459248C2 (ru) Способ установления защищенной электронной связи между различными электронными устройствами, в особенности между электронными устройствами поставщиков электронных услуг и электронными устройствами потребителей электронной услуги
Bhattacharjya et al. Present scenarios of IoT projects with security aspects focused
Borselius Multi-agent system security for mobile communication
Indushree et al. A novel Blockchain-based authentication scheme for telecare medical information system
US20140282925A1 (en) Personal Authentication Device and System for Securing Transactions on a Mobile Device
Lenz et al. Towards cross-domain eID by using agile mobile authentication
Kerttula A novel federated strong mobile signature service—the finnish case
Ruiz-Martínez et al. A mobile network operator-independent mobile signature service
Suoranta et al. Strong authentication with mobile phone
María de Fuentes et al. Security protocols for networks and internet: a global vision
Gonçalves et al. Oidc-tci: Oidc with trust context information
Zhang et al. Achieving fine‐grained access control in virtual organizations
Agbede Strong Electronic Identification: Survey & Scenario Planning
EP1990969A1 (en) Method for data communication and device as well as communication system comprising such device
Kome Identity and consent in the internet of persons, things and services
Boi et al. Decentralized Authentication in Microservice Architectures with SSI and DID in Blockchain
Kim et al. General authentication scheme in user-centric idm
Brooks et al. Securing wireless grids: architecture designs for secure wiglet-to-wiglet interfaces