ES2281760T3 - Metodo y aparato para implementar un acceso vpn seguro a traves de cadenas de certificado modificadas. - Google Patents
Metodo y aparato para implementar un acceso vpn seguro a traves de cadenas de certificado modificadas. Download PDFInfo
- Publication number
- ES2281760T3 ES2281760T3 ES04253083T ES04253083T ES2281760T3 ES 2281760 T3 ES2281760 T3 ES 2281760T3 ES 04253083 T ES04253083 T ES 04253083T ES 04253083 T ES04253083 T ES 04253083T ES 2281760 T3 ES2281760 T3 ES 2281760T3
- Authority
- ES
- Spain
- Prior art keywords
- server
- user
- certificate
- ssm
- character
- 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
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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
Abstract
Método para efectuar comunicaciones seguras, que comprende: (a) conectar un dispositivo de usuario (10) a través de una red públicamente accesible (12) a un servidor (20), (b) recibir un certificado digital; (c) calcular un identificador del certificado digital recibido y convertir el identificador en una cadena de caracteres; (d) modificar la cadena de caracteres eliminando de la cadena de caracteres por lo menos un carácter seleccionado aleatoriamente; (e) visualizar, para un usuario en el dispositivo de usuario (10), la cadena de caracteres modificada; (f) recibir, en el dispositivo de usuario (10) y proveniente de un usuario al que se ha proporcionado anteriormente el identificador a través de un medio de confianza, una entrada correspondiente al por lo menos un carácter eliminado; y (g) continuar con la conexión al servidor (20) únicamente si la entrada del usuario coincide con el por lo menos un carácter eliminado.
Description
Método y aparato para implementar un acceso VPN
seguro a través de cadenas de certificado modificadas.
La presente invención se refiere al sector de
los accesos seguros a una red de comunicaciones, y más
particularmente al sector de los accesos seguros a un servidor
remoto u otro dispositivo a través de una red de comunicaciones
públicamente accesible.
Los certificados digitales son bien conocidos.
Las descripciones de los certificados digitales y su uso están
disponibles en muchas fuentes, entre las que se incluyen
<http://www.webopedia.com/TERM/d/digital_certificate.html> y
<http://wp.netscape.com/
security/techbriefs/servercerts/index.html> (incluyendo páginas
con enlaces relacionados). En resumen, un certificado digital de una
Autoridad de Certificación (CA) contiene, en un formato cifrado,
una clave de cifrado pública y alguna otra información de
identificación sobre el titular del certificado. El certificado se
adjunta a las comunicaciones del titular del certificado, y
solamente se puede descifrar (por lo menos sin esfuerzos muy
sustanciales) usando una clave pública de la Autoridad de
Certificación. Cuando se ha recibido y descifrado la clave pública
del titular del certificado (usando la clave pública de la CA), la
misma se puede usar para crear una conexión de la Capa de Conexión
Segura (SSL) con el titular del certificado para obtener una
comunicación segura. Los Certificados Digitales se pueden usar por
ejemplo, para la autenticación de individuos, de dispositivos de
usuarios específicos, de servidores, y de otros numerosos
dispositivos.
No obstante, sigue existiendo la necesidad de
sistemas y métodos escalables para obtener un acceso seguro a
intranets de empresas y otros recursos a través de Internet y otras
redes públicamente accesibles. La necesidad es especialmente
importante en el caso de dispositivos móviles tales como teléfonos
móviles, asistentes personales digitales (PDA), terminales móviles y
otros dispositivos capaces de acceder a Internet. En tales
dispositivos la facilidad de despliegue resulta con frecuencia
crítica, ya que puede haber numerosos dispositivos en uso. Por otra
parte, típicamente dichos dispositivos presentan unas capacidades
limitadas en comparación con los ordenadores personales (ordenadores
PC) o los ordenadores portátiles.
Se ha observado que cuando no se requiere
ninguna acción por parte del usuario para iniciar una SSL u otra
sesión segura, el usuario con frecuencia le concede poca importancia
al certificado digital. Por ejemplo, un usuario final debería
verificar que un certificado digital correspondiente a un servidor
es válido y/o que el titular del mismo es la entidad con la cual
desea comunicarse el usuario. Una manera común de obtener una
verificación del usuario es mostrar el nombre del titular del
certificado y pedir al usuario que acepte o no dicho certificado.
Muchos usuarios aceptan siempre sin estudiar realmente la decisión.
Por consiguiente, sigue existiendo la necesidad de métodos y
sistemas más seguros para iniciar una comunicación segura.
El documento US nº 6.141.751 describe un método
por medio del cual se puede identificar un usuario sobre una red. Se
proporciona una cadena de caracteres a un usuario el cual convierte
la cadena usando una regla de conversión y proporciona la cadena
convertida como identificación.
El documento WO 02/073377 A2 describe un método
que permite determinar una autorización de usuario creando claves
criptográficas de un solo uso y algoritmos criptográficos exclusivos
en paralelo en un centro de autorización y en un terminal remoto
usando un algoritmo común de generación de conjuntos de símbolos
gráficos conocido para el centro de autenticación y para el
usuario.
Según la invención, se proporciona un método
para efectuar comunicaciones seguras según la reivindicación 1 de
las reivindicaciones adjuntas.
Según la invención, se proporciona además un
dispositivo para comunicaciones seguras con un servidor a través de
una red públicamente accesible según la reivindicación 12 de las
reivindicaciones adjuntas.
Según la invención, se proporciona también un
soporte legible por máquina según la reivindicación 13 de las
reivindicaciones adjuntas y un método para efectuar comunicaciones
seguras según la reivindicación 14 de las reivindicaciones
adjuntas.
Durante el transcurso de la siguiente
descripción y haciendo referencia a los dibujos, se pondrán de
manifiesto otros aspectos adicionales de la presente invención.
El sumario anterior de la invención, así como la
siguiente descripción detallada de formas de realización preferidas,
se comprenderá mejor a partir de su lectura haciendo referencia a
los dibujos adjuntos, los cuales se incluyen a título de ejemplo, y
no a título limitativo en relación con la invención
reivindicada.
La Fig. 1 es un diagrama de bloques que ilustra
un entorno de red ilustrativo en el cual un dispositivo móvil puede
acceder remotamente a datos almacenados según varias formas de
realización de la presente invención.
La Fig. 2 es un diagrama de bloques que ilustra
un sistema ilustrativo según por lo menos una forma de realización
de la invención.
La Fig. 3 es un diagrama de bloques que ilustra
un dispositivo móvil ilustrativo según por lo menos una forma de
realización de la presente invención.
La Fig. 4 es un diagrama de bloques que muestra
el almacenamiento de datos en relación con un software de cliente de
Actualización Automática de Contenido según por lo menos una forma
de realización de la invención.
La Fig. 5 es un diagrama de bloques de un
servidor y otros componentes de la red según por lo menos una forma
de realización de la invención.
La Fig. 6 es un diagrama de bloques de una red
empresarial según por lo menos una forma de realización de la
invención.
La Fig. 7 es un diagrama de flujo que muestra
etapas de la gestión de mensajes ACU según por lo menos una forma de
realización de la invención.
Las Figs. 8 a 35 son ejemplos de pantallas de la
Interfaz de Usuario en un dispositivo móvil según por lo menos una
forma de realización de la invención.
En la siguiente descripción de varias formas de
realización ilustrativas, se hace referencia a los dibujos adjuntos
que forman parte de las mismas, y en los cuales se muestran a título
de ilustración varias formas de realización en las cuales se puede
llevar a la práctica la invención. Debe entenderse que se pueden
utilizar otras formas de realización y que se pueden llevar a cabo
modificaciones estructurales y funcionales sin desviarse por ello
del alcance de la presente invención.
Haciendo referencia a continuación a los
dibujos, en los que las referencias numéricas iguales indican las
mismas partes, la Fig. 1 ilustra un diagrama de bloques de varias
redes privadas virtuales (VPN) distribuidas a través de una red
troncal de datos por paquetes 14. En por lo menos una de las formas
de realización, la red de datos por paquetes 14 es Internet. Tal
como se ilustra, la VPN-A está conectada mediante
túneles (indicados mediante trazos largos) los cuales representan
comunicaciones seguras entre los dispositivos A1, A2 y A3. De forma
similar, la VPN-B está conectada mediante túneles
seguros (indicados mediante trazos cortos) entre los dispositivos
B1, B2 y B3. Las redes VPN A y B están ubicadas en una empresa u
organización que tiene múltiples ubicaciones. La arquitectura VPN
ilustrada en la Fig. 1 permite que un empleado o miembro de la
empresa u organización (u otra persona autorizada) acceda a la red
de área local (LAN) de la empresa u organización después de
conectarse a la VPN de la empresa u organización mediante túneles
seguros a través de Internet u otra red troncal de datos por
paquetes. En por lo menos una de las formas de realización, se
consigue que la conexión sea segura mediante una tecnología de
tunelización tal como la Capa de Conexiones Seguras (SSL). No
obstante, la invención no se limita a ninguna tecnología específica
para asegurar la conexión. Un dispositivo móvil 10 se puede
comunicar a través de una red móvil 12 con Internet 14 y a
continuación con y desde los diferentes dispositivos B1 a B3. Los
dispositivos B1 a B3 podrían formar parte de la misma intranet, o
podrían estar dispersar a través de múltiples intranets u otras
Redes de Área de Local (redes LAN) o Redes de Área Extensa (redes
WAN).
La Fig. 2 es un diagrama de bloques que ilustra
un sistema de cliente de red privada virtual móvil (VPN) según una
de las formas de realización de la invención. Uno de los ejemplos de
un dispositivo móvil en el cual se puede implementar un cliente del
sistema es un dispositivo móvil habilitado para el Series 60™ o el
SYMBIAN OS™ (es decir, el sistema operativo SYMBIAN OS™ disponible
en Symbian Ltd. de Londres, U.K.) con un software de cliente VPN
instalado en el mismo. Entre los ejemplos de dichos dispositivos se
incluyen los teléfonos Nokia 7650™ y 3650™ y el 9210 communicator™
(disponibles en Nokia Corp. de Espoo, Finlandia). Los dispositivos
móviles 10 se comunican a través de una red inalámbrica 12 e
Internet 14 con un cortafuegos VPN 18 y una pasarela VPN 24. Los
dispositivos móviles 10 y el ordenador 11 pueden establecer una
conexión de túnel VPN 19 en el caso de que el cortafuegos 18 permita
la conexión con la Intranet 36.
El software de cliente VPN móvil (cliente VPN)
se instala en primer lugar en el dispositivo móvil 10 para obtener
una comunicación con el servidor gestor de servicios de seguridad
(SSM) 20. El cliente VPN se muestra en la Fig. 3 como una de las
aplicaciones instaladas 72 en el dispositivo móvil 10, y el mismo se
explicará de forma más detallada posteriormente. El usuario puede
descargar el cliente VPN usando un navegador web común, a través de
una conexión por infrarrojos, BLUETOOTH, o WLAN, a través de una
difusión general o una multidifusión (por ejemplo, la
DVB-T o sus modificaciones), a través de correo
electrónico, o a través de CD-ROM u otros medios
extraíbles. El cliente VPN se entrega, por ejemplo, en forma de un
archivo SIS del sistema operativo SYMBIAN OS™ para instalarlo
fácilmente en el dispositivo móvil 10.
El servidor SSM 20, a través de un servidor Web
90 (mostrado en la Fig. 5), tiene una interfaz para filtrar
solicitudes recibidas desde fuentes remotas tales como un
dispositivo móvil 10. Se permite acceder al servidor SSM 20
únicamente a usuarios autenticados. La autenticación de los usuarios
se basa en combinaciones de nombre de usuario/contraseña que un
usuario de un dispositivo remoto introduce en un formato HTML
proporcionado por la Interfaz de Usuario (UI) externa del servidor
Web 90. Una autenticación satisfactoria provoca que el servidor SSM
20 cree una sesión para el usuario autenticado. A continuación, la
sesión se identifica entre solicitudes de páginas subsiguientes
codificando una ID de sesión en los URL correspondientes a las
páginas almacenadas en el servidor Web 90. Específicamente, cada
enlace a páginas web subsiguientes contiene un parámetro ID de
sesión que el servidor SSM 20 usa para validar las solicitudes de
página. Los Servlets y las páginas JSP en el servidor Web 90 crean
los URL en las páginas web. El usuario puede salir del servidor SSM
20 usando un enlace en una página web proporcionada por el servidor
Web 90. No obstante, como los usuarios no siempre se acuerdan de
salir de la sesión las sesiones de usuario presentan un valor de
tiempo límite corto. En una de las formas de realización, todas las
páginas del servidor Web 90 son solamente accesibles a través de
conexiones SSL. De este modo, los nombres de usuario, las
contraseñas y las ID de sesión se transfieren únicamente a través de
conexiones cifradas.
Todas las solicitudes del dispositivo móvil 10,
incluyendo solicitudes de un navegador del usuario, se envían a
través del protocolo de transferencia de hipertexto (HTTP) al
servidor SSM 20. En por lo menos una de las formas de realización,
las conexiones HTTP 19 de los dispositivos móviles 10 en Internet 14
pasan a través de la pasarela VPN 24 y/o el cortafuegos/servidor
proxy 18, y el servidor SSM 20 no está conectado directamente a
Internet 14.
El dispositivo móvil 10, el cual incluye una
pantalla de visualización, un teclado numérico y/o otros
dispositivos de entrada y salida, proporciona varias interfaces a un
usuario durante la instalación de un cliente VPN. Después de la
descarga, la pantalla indica que está presente un archivo SIS que
contiene el cliente VPN (Fig. 8). Al abrir dicho archivo, al usuario
se le invita a que instale el software seleccionando "Sí" (Fig.
9), lo cual da inicio al proceso de instalación. La selección de
"No" cancela la instalación. Al seleccionar Sí, al usuario se
le proporcionan varias selecciones en un menú de opciones:
"instalar", "ver certificado", o "detalles sobre el
producto que se está instalando" (Fig. 10). Después de
seleccionar "instalar", al usuario se le pide que cierre todas
las aplicaciones activas que se estén ejecutando en el dispositivo
(Fig. 11). Esta opción se realiza por razones de seguridad, de
manera que las otras aplicaciones no interfieran con la instalación.
Después de cerrar la totalidad del resto de aplicaciones, comienza
la instalación real. Cuando la instalación se ha completado, el
proceso de instalación le pide al usuario que apague y encienda
nuevamente el dispositivo (Fig. 12). Esta opción garantiza que todos
los componentes de bajo nivel están instalados correctamente cuando
el dispositivo se vuelve a activar. Después de la instalación, sobre
un menú de aplicación aparece un icono de Cliente VPN móvil (Fig.
13). Los usuarios pueden mover el icono de cliente a cualquier lugar
en el menú de aplicación o a cualquier carpeta.
El proceso de instalación utiliza un servicio de
Actualización Automática de Contenido (ACU). El servicio ACU incluye
un protocolo entre el dispositivo móvil 10 y el servidor SSM 20 que
permite que el dispositivo 10 mantenga sus medios locales de
almacenamiento de contenido sincronizados con el contenido del
servidor SSM 20. En una de las formas de realización, el software de
cliente de servicio ACU (cliente ACU) forma parte del cliente VPN
móvil, y se instala antes de instalar otros componentes de cliente
VPN. La fase de establecimiento del cliente ACU comprende dos
transacciones de protocolo. La primera transacción se usa para
descargar un paquete de configuración de cliente ACU en el cliente
móvil y la segunda transacción se usa para inscribir un certificado
de cliente ACU. El certificado de cliente se usa en las
comunicaciones ACU subsiguientes para firmar solicitudes ACU y para
autenticar respuestas a solicitudes.
El servidor SSM 20 incluye una base de datos 98
(Fig. 5), la cual a su vez comprende bases de datos adicionales. Una
base de datos de configuración permite que los clientes recuperen
paquetes de configuración de cliente a partir del servidor SSM 20.
Una base de datos de inscripción de certificados permite que los
clientes inscriban certificados en el servidor SSM 20. Una base de
datos de metadatos de contenido permite que los clientes recuperen
metadatos sobre el contenido almacenado en una base de datos de
contenido. La base de datos de contenido permite que los clientes
recuperen el contenido real del servidor SSM 20. Todas las bases de
datos contienen algún tipo de datos que pueden ser recuperados por
un cliente. No obstante, mientras que la base de datos de
configuración contiene solamente paquetes de configuración de
cliente, la base de datos de contenido puede contener cualquier tipo
de datos. Al contenido de las bases de datos se le asigna también
una o más propiedades; estas propiedades se incluyen en filtros de
búsqueda de solicitudes ACU para hallar los datos deseados. Por
ejemplo, la base de datos de inscripción de certificados soporta
propiedades tales como solicitudes de certificado que se preparan
usando la PKCS#10 (u otra sintaxis de solicitud de certificados) y
el nombre de la entidad; la base de datos de contenido soporta
propiedades tales como la ID de contenido y tipo.
Para acceder a las diferentes bases de datos se
requieren diferentes niveles de autorización de seguridad de los
mensajes entrantes de solicitud ACU. En por lo menos una de las
formas de realización, existen tres niveles de seguridad: Sol1 (más
bajo), Sol2 (intermedio) y Sol3 (el más alto). La base de datos de
configuración acepta todos los niveles de seguridad (Sol1, Sol2 y
Sol3), mientras que la base de datos de contenido requiere el nivel
de seguridad más alto (Sol3). La siguiente Tabla 1 resume los
requisitos de los niveles de seguridad, las propiedades de contenido
y los tipos de contenido de las base de datos del servidor SSM 20 en
una de las formas de realización. Por ejemplo, la base de datos de
inscripción de certificados almacena y devuelve certificados X.509v3
(por ejemplo, "aplicación/pkix-cert"). Tal como
es sabido en la técnica, X.509 hace referencia a la normativa
recomendada por la Unión Internacional de Telecomunicaciones para
certificados digitales. Los filtros de búsqueda en una solicitud
dirigida a la base de datos de inscripción de certificados pueden
incluir tres propiedades, un nombre de entidad, un tipo de solicitud
y una solicitud de certificado PKCS#10. La base de datos de
inscripción de certificados requiere solicitudes que tengan el nivel
de seguridad Sol2 ó Sol3.
\vskip1.000000\baselineskip
Al recibir un primer paquete de respuesta del
servidor SSM 20, el dispositivo móvil 10 establece una relación de
fiabilidad con el servidor SSM 20. En particular, el dispositivo
móvil 10 valida y almacena un certificado devuelto del servidor SSM.
El certificado almacenado del servidor SSM se usa a continuación
para validar automáticamente respuesta ACU subsiguientes del mismo
servidor.
El dispositivo móvil 10 y el servidor 20
completan la fase de establecimiento del cliente ACU y VPN antes de
dar inicio a otras operaciones (por ejemplo, la actualización del
contenido de otras aplicaciones en el dispositivo 10, el uso de una
VPN para obtener una comunicación segura por parte de otra
aplicación, etcétera). Las bases de datos objetivo usadas durante el
establecimiento del cliente pueden variar. No obstante, en la Tabla
2 y en la Fig. 7 se describen bases de datos objetivo y niveles de
seguridad de mensajes ilustrativos usados en la fase de
establecimiento del cliente ACU.
El mensaje 1 es usado por el cliente ACU para
recuperar un paquete de configuración de cliente ACU de un servidor
ACU (por ejemplo, el servidor SSM 20). Dicho servidor usa el mensaje
2 para devolver un paquete de configuración de cliente ACU al
cliente ACU. El cliente ACU usa el mensaje 3 para inscribir un
certificado de cliente ACU en el servidor ACU. Dicho servidor usa el
mensaje 4 para devolver un certificado de cliente ACU al cliente
ACU. Durante una fase de funcionamiento subsiguiente, el cliente ACU
envía un mensaje para recuperar metadatos de contenido o contenido
real de un servidor ACU, o para inscribir un certificado en un
servidor ACU (no mostrado en la Fig. 7 ó la Tabla 2). Esta opción
puede incluir la recuperación de una política VPN del servidor SSM
20. En respuesta, el servidor devuelve metadatos de contenido,
contenido real o un certificado al cliente ACU. Esta opción puede
incluir la devolución de una política VPN al cliente ACU.
Si un servidor SSM o un certificado de cliente
expira o bien se hace no válido, el dispositivo móvil 10 inicia una
nueva fase de establecimiento de cliente y ejecuta las etapas de
inicialización adecuadas. Si el dispositivo móvil 10 recibe un
estado de autenticación satisfactoria, aunque recibe también una
indicación de que el certificado de cliente móvil está a punto de
expirar, el dispositivo móvil 10 puede inscribir un certificado de
cliente nuevo usando el certificado que está a punto de expirar para
autenticar la solicitud. Una vez que se ha recibido el nuevo
certificado, este sustituye al antiguo.
Los mensajes provenientes del dispositivo móvil
10 hacia el servidor SSM 20 disponen de una parte que define la ID
de sesión (por ejemplo, un número) y la ID de mensaje (por ejemplo,
también un número), el servidor SSM 20 y
la(s) dirección(es) de cliente. La parte de la dirección del cliente también puede contener, opcionalmente, información de autenticación. Una parte de cuerpo del mensaje identifica la versión del protocolo ACU (por ejemplo "SyncML/1.0") usado en este mensaje y que se espera usar en el paquete de respuesta. La parte de cuerpo incluye además una consulta que contenga propiedades del contenido que el cliente desea recuperar del servidor. Por ejemplo, una de las consultas puede contener el URI absoluto del servidor SSM 20 (por ejemplo, "http://<nombre-servidor-acu>/acu"). En una de las formas de realización, el valor de la consulta es el mismo que el identificador uniforme de recursos (URI) de destino usado en el nivel HTTP. El mensaje del dispositivo móvil 10 incluye además un URI absoluto o un número uniforme de recurso (URN) de identidad internacional del equipo de estación móvil (IMEI) que identifica exclusivamente al dispositivo móvil 10 (por ejemplo, "http://<nombre-cliente>:<puerto>" o "IMEI:493005100592800"). La inclusión de la autenticación del cliente y la información de identidad depende del nivel de seguridad del mensaje de solicitud. El mensaje del dispositivo móvil 10 indica también si el mensaje es el último mensaje de un paquete. En por lo menos una de las formas de realización, un paquete ACU está contenido siempre en un único mensaje, y por lo tanto, en todos los mensajes ACU del dispositivo 10, estaría presente una descripción de "elemento final".
la(s) dirección(es) de cliente. La parte de la dirección del cliente también puede contener, opcionalmente, información de autenticación. Una parte de cuerpo del mensaje identifica la versión del protocolo ACU (por ejemplo "SyncML/1.0") usado en este mensaje y que se espera usar en el paquete de respuesta. La parte de cuerpo incluye además una consulta que contenga propiedades del contenido que el cliente desea recuperar del servidor. Por ejemplo, una de las consultas puede contener el URI absoluto del servidor SSM 20 (por ejemplo, "http://<nombre-servidor-acu>/acu"). En una de las formas de realización, el valor de la consulta es el mismo que el identificador uniforme de recursos (URI) de destino usado en el nivel HTTP. El mensaje del dispositivo móvil 10 incluye además un URI absoluto o un número uniforme de recurso (URN) de identidad internacional del equipo de estación móvil (IMEI) que identifica exclusivamente al dispositivo móvil 10 (por ejemplo, "http://<nombre-cliente>:<puerto>" o "IMEI:493005100592800"). La inclusión de la autenticación del cliente y la información de identidad depende del nivel de seguridad del mensaje de solicitud. El mensaje del dispositivo móvil 10 indica también si el mensaje es el último mensaje de un paquete. En por lo menos una de las formas de realización, un paquete ACU está contenido siempre en un único mensaje, y por lo tanto, en todos los mensajes ACU del dispositivo 10, estaría presente una descripción de "elemento final".
En una de las formas de realización, el cuerpo
de un mensaje de respuesta ACU del servidor SSM 20 incluye un
identificador de la versión (por ejemplo, "1.0") del XML
(lenguaje de marcado extensible) usado en, por ejemplo, el protocolo
ACU; un elemento de información de estado usado para informar a la
aplicación que envía un elemento específico sobre el resultado del
procesado de ese elemento por parte del servidor SSM 20 u otro
destinatario (por ejemplo, un código de error que indique la razón
por la cual la comunicación no resultó satisfactoria); una versión
del protocolo ACU (por ejemplo, "SyncML/1.0"); las propiedades
del contenido que el cliente desea recuperar del servidor en la
solicitud correspondiente; e información sobre pares de elementos
Estado/Resultados correspondientes a elementos de Búsqueda
adicionales (en caso de que hubiera alguno) en el paquete de
solicitud correspondiente. Los elementos de resultados están
presentes únicamente si las consultas correspondientes devuelven
algún contenido. La ID del elemento de contenido, la cual en por lo
menos una de las formas de realización es la misma que el valor del
elemento ID en los metadatos ACU correspondientes, se puede usar
como valor de la propiedad de contenido IDContenido en los filtros
de búsqueda ACU para la base de datos de contenido.
Varios programas de aplicación que funcionen
sobre el dispositivo móvil 10 pueden utilizar el cliente ACU
instalado en el dispositivo móvil. Cuando una aplicación especifica
una ID de contenido en una solicitud de actualización de contenido,
el Agente ACU 74 (Fig. 3) realiza una llamada a un gestor de
Seguridad para el Protocolo de Internet (IPSec) 60 con vistas a
obtener la identidad del servidor con el cual se va a realizar el
proceso de realización, e invita al usuario del dispositivo a que
proporcione la contraseña del cliente VPN. Cuando el agente ACU 74
dispone de la identidad del servidor (en el presente ejemplo, el
servidor SSM 20), el agente ACU 74 continúa con el proceso de
actualización realizando una consulta a la aplicación sobre una
lista de tipos de contenido deseados. El Agente ACU 74 le pide
adicionalmente a la aplicación metadatos (por ejemplo, identidades
ID, tipos e indicaciones de tiempo) sobre el contenido deseado.
Después de que se haya inicializado correctamente la comunicación
con el servidor identificado (en este caso, el servidor SSM 20), el
Agente ACU 74 genera un mensaje de solicitud ACU para el servidor
SSM 20. Dicho mensaje recupera metadatos referentes al contenido que
el servidor SSM 20 ha asociado a la aplicación de cliente que está
solicitando una actualización y/o referentes al usuario de dicha
aplicación. La solicitud ACU incluye un filtro de búsqueda que
ofrece una lista de todos los tipos de contenido que la aplicación
de cliente desea tener actualizados. A continuación, el agente ACU
74 compara los metadatos devueltos por el servidor SSM 20 con los
metadatos de la aplicación que solicita una actualización. Si
aparecen diferencias, el agente ACU 74 fija un parámetro de
configuración de actualización del contenido del servidor (por
ejemplo, "ForzarActualizaciones") en los medios de
almacenamiento de datos ACU 66 (Fig. 3). A continuación, el agente
ACU 74 recupera del servidor SSM 20 todo el contenido nuevo y
cambiado (en caso de que hubiera alguno). La Fig. 7 es una vista
ilustrativa de un diagrama de flujo que describe cómo se gestionan
los mensajes ACU según una de las formas de realización de la
invención.
Una o más políticas VPN son uno de los tipos de
contenido recuperado por el dispositivo móvil 10 a partir del
servidor SSM 20. Una política VPN contiene toda la información
requerida por un dispositivo móvil con un cliente VPN (por ejemplo,
"ClienteVPNm"), tal como un dispositivo móvil 10, para
establecer conexiones seguras con el servidor SSM 20 con vistas a,
en por lo menos una de las formas de realización, acceder al correo
electrónico 32, bases de datos 34 y otros servicios de la Intranet
empresarial (Fig. 2). En una de las formas de realización, la
política contiene datos de identidad del usuario final tales como
certificados y claves privadas. A una política VPN sin certificados,
claves privadas y otros datos específicos de usuario se le denomina
"perfil". Múltiples usuarios finales pueden obtener el mismo
perfil, y a continuación crear políticas individualizadas. En una de
las formas de realización, las políticas y los perfiles VPN se
gestionan y administran en el servidor SSM 20, el cual a su vez
incluye y/o está en comunicación con una aplicación de gestión de
políticas 26, una base de datos 98 y la autoridad de certificación
28.
Una única política VPN puede requerir múltiples
certificados de usuario. Por ejemplo, una política creada por la
aplicación de gestión de políticas 26 y transferida a la base de
datos 98 del servidor SSM 20 podría contener varias definiciones de
pasarela VPN, usando cada una de estas definiciones una
autenticación de certificado aunque basándose en una autoridad de
certificación diferente. Consecuentemente, una política individual
puede requerir múltiples procesos de inscripción de certificados
antes de estar preparada para la activación. Aunque una política
puede tener múltiples certificados de usuario asociados, en por lo
menos una de las formas de realización se dispone de un único par de
claves pública/privada de un tamaño determinado para una política.
En otras palabras, todos los certificados asociados a una política
individual y que usan el mismo tamaño de clave hacen referencia al
mismo par de claves pública/privada.
En una de las formas de realización, y tal como
se muestra en la Fig. 3, los archivos que constituyen una política
VPN están contenidos en unos medios de almacenamiento de políticas
IPSec 40 e incluyen un archivo de información de política 46 (que
contiene información general sobre la política), un archivo de
política 50 (que contiene reglas IPSec y de Intercambio de Claves de
Internet, o IKE), uno o más archivos de certificados 48 y uno o más
archivos de claves privadas 52. En por lo menos una de las formas de
realización, los medios de almacenamiento de políticas IPSec 40
almacenan pares de claves pública/privada 42, certificados 48, y
solicitudes y asociaciones de certificados 44 (que se describirán
posteriormente) para cualquier aplicación, no solamente el cliente
VPN. Los medios de almacenamiento de políticas IPSec 40 son
modificables para soportar nuevas propiedades de contenido que
puedan ser requeridas por el agente ACU 74.
Las aplicaciones 72 que funcionan sobre el
dispositivo móvil 10 acceden al cliente ACU a través del agente ACU
74. En una de las formas de realización, el cliente VPN accede al
agente ACU 74 a través del gestor IPSec 60.
En varias fases durante el proceso de
actualización del contenido y de inscripción de certificados, el
agente ACU 74 se comunica con la aplicación del cliente (por
ejemplo, el cliente VPN) que inició la actualización, la inscripción
u otro proceso.
Los medios de almacenamiento de datos ACU 66
contienen información sobre las aplicaciones del cliente que usa el
cliente ACU, tales como la información de cliente VPN 68. Los medios
de almacenamiento de datos ACU 66 contienen también información 70
sobre servidores con los cuales se comunica el agente ACU 74 en
nombre de aplicaciones de cliente, tales como el servidor SSM 20. El
contenido real y los metadatos de contenido recuperados de los
servidores son almacenados por las aplicaciones de cliente
respectivas que solicitaron la actualización u otro servicio ACU. En
el caso del cliente VPN, el contenido y los metadatos de contenido
se almacenan en los Medios de Almacenamiento de Políticas IPSec 40.
Tal como se muestra también en la Fig. 3, el dispositivo móvil 10
incluye una interfaz con la red móvil 12 tal como un transceptor 64,
una CPU 76, así como aplicaciones telefónicas y de calendario.
Aunque no se muestran, el dispositivo móvil 10 dispondría también de
uno o más dispositivos de entrada de usuario (por ejemplo, un
teclado), dispositivos de salida (por ejemplo, una pantalla) y otros
componentes conocidos.
La Fig.4 es un diagrama de bloques que muestra
el almacenamiento en unos medios de almacenamiento de datos ACU 66.
El registro ServicioACU 78 contiene información ("ID") sobre
una o más instancias del servicio ACU. El registro ApCliente 80
contiene información sobre las aplicaciones que usan una instancia
específica de un servicio ACU. Una instancia específica de un
servicio ACU puede ser usada por más de una aplicación. El registro
CuentaServidor 82 contiene información sobre las cuentas del
servidor (por ejemplo, para el servidor SSM 20) usadas por una
aplicación de cliente específica. La información del registro
CuentaServidor 82 se obtiene a partir de entradas del usuario, a
partir del servidor (por ejemplo, el servidor SSM 20) en un paquete
de configuración de cliente y/o como consecuencia de un proceso de
inicialización de un cliente. Una aplicación específica puede tener
más de un registro CuentaServidor. Los pares de claves
pública/privada se almacenan en el archivo ParClaves 84. Los
diferentes registros y archivos se pueden comunicar entre sí
dependiendo de la aplicación del cliente. El campo RefIAP en el
registro CuentaServidor 82 hace referencia a una entrada de
configuración de un Punto de Acceso a Internet (IAP) en el
dispositivo 10. Este campo especifica el punto de acceso que se debe
usar cuando se produce una comunicación con un servidor (tal como el
servidor SSM 20) especificado en el registro CuentaServidor. En
otros lugares del dispositivo se configuran otros IAP disponibles
para otros usos.
En una de las formas de realización, el agente
ACU 74 y cada aplicación que usa el cliente ACU se comunican con los
procesos de actualización de contenido y de inscripción de
certificados con el gestor IPSec 60. En una de las formas de
realización, el gestor IPSec 60 forma parte del software del sistema
operativo en el dispositivo móvil 10 (tal como el sistema operativo
SYMBIAN OS™). El gestor IPSec 60 gestiona los medios de
almacenamiento de políticas IPSec 40, incluyendo los certificados y
las claves privadas almacenadas en los mismos. El gestor IPSec 60
realiza también operaciones de cifrado y de descifrado con las
claves privadas almacenadas en los medios de almacenamiento de
políticas 42. En una de las formas de realización, las claves
privadas se instalan y almacenan en un formato cifrado, y el Gestor
IPSec 60 gestiona la importación de las políticas y las contraseñas
de los clientes VPN necesarias para descifrar y cifrar las claves
privadas. El software de cliente VPN, a través del gestor IPSec 60
y/o de otros componentes del sistema operativo, implementan diálogos
para solicitar del usuario contraseñas del cliente VPN y de
instalación de políticas.
El gestor IPSec 60 soporta además la generación
y el almacenamiento de pares de claves pública/privada, el
almacenamiento de certificados y la generación y almacenamiento de
solicitudes de certificados para el software de cliente VPN y para
otras aplicaciones. El gestor IPSec 60 asume la funcionalidad
requerida para soportar los procesos de actualización de políticas y
de inscripción de certificados. Cuando el usuario inicia un proceso
de actualización de una política con una orden para el gestor IPSec
60, el gestor IPSec 60 (a través de una interfaz de usuario)
solicita la contraseña del cliente VPN.
En una de las formas de realización, el cliente
VPN soporta dos tipos principales de autenticación VPN:
autenticación con certificados y autenticación tradicional. La
autenticación con certificados se basa en datos de la
infraestructura de clave pública (PKI) del usuario (por ejemplo, un
par de claves pública/privada y el certificado correspondiente),
mientras que la autenticación tradicional se basa en nombres de
usuario y contraseñas/códigos de acceso.
El proceso de inscripción de certificados está
disponible de dos formas: automatizada y manual. El usuario inicia
un proceso de inscripción automatizada de certificados activando una
política que requiere una inscripción de certificados. Una política
requiere una inscripción de certificados cuando la misma es una
política PKI y carece de toda la información PKI del usuario, o
cuando la información PKI del usuario es incompleta o ha expirado.
El usuario inicia un proceso de inscripción manual de certificados
seleccionando una política que requiere una inscripción de
certificados en la UI del cliente VPN y a continuación escogiendo
una orden específica de entre el menú de cliente.
En una de las formas de realización, se crean
perfiles usando una aplicación de gestión de políticas VPN 26 y los
mismos describen la estructura VPN (por ejemplo, la topología de la
red) para pasarelas y para clientes. En una de las formas de
realización, la pasarela VPN 24 realiza las comprobaciones finales
de los derechos de acceso, y una de las versiones del cliente de una
política contiene únicamente información necesaria para establecer
conexiones seguras con pasarelas correctas.
En algunas formas de realización, la aplicación
de gestión de políticas 26 incluye claves privadas de usuario y
certificados con una política. Si un perfil VPN define el uso de
certificados y claves privadas, pero no los contiene, un cliente VPN
creará un par de claves pública-privada y una
solicitud de certificado correspondiente y a continuación enviará la
solicitud a una autoridad de certificación (CA) 28 para obtener la
inscripción. Si la inscripción es satisfactoria, la CA 28 envía de
vuelta un certificado y el cliente VPN está preparado para
conexiones seguras.
Para facilitar el proceso de inscripción del
certificado, una de las formas de realización del servidor SSM 20
actúa como una pasarela de inscripción de certificados. En este
caso, los clientes VPN envían solicitudes de inscripción al servidor
SSM 20 en lugar de a la CA 28, y únicamente el servidor SSM 20 se
comunica con la CA 28. A continuación, el servidor SSM 20 realiza la
autenticación y la autorización necesarias para conseguir la
inscripción del certificado de una forma totalmente automatizada. El
servidor SSM 20 autentica usuarios con una base de datos de usuario
98 ó con un servidor de servicio de usuario de marcación con
autenticación remota (RADIUS) 30. Este último permite el uso de
testigos de contraseña tales como SECURID (disponible en RSA
Security Inc. de Bedford, Massachusetts).
En algunas formas de realización, el servidor
SSM 20 funciona como una autoridad de certificación VPN interna. En
tal caso, puede que no haya necesidad de usar una CA de una tercera
parte para firmar certificados VPN, lo cual puede dar como resultado
ahorros significativos de los costes en los despliegues de las VPN
basados en PKI.
Las políticas y los perfiles VPN pueden cambiar
después de que se hayan desplegado inicialmente. Los clientes pueden
actualizar una política del servidor SSM 20 de varias maneras. En
una de las formas de realización, el cliente VPN, usando el cliente
ACU, comprueba automáticamente las políticas actualizadas al
producirse la conexión con el servidor SSM 20. Tras hallar políticas
actualizadas, el cliente VPN (usando el cliente ACU) importa
automáticamente todos los cambios. En una de las formas de
realización, el protocolo ACU se basa en el SyncML y actúa de forma
complementaria con el software del cliente VPN basado en el SYMBIAN
OS™. La actualización automática minimiza la necesidad de
notificaciones por correo electrónico y de descargas basadas en
navegadores.
Durante el proceso de actualización de las
políticas, y con independencia de si la activación de la política ha
sido o no satisfactoria, el gestor IPSec 60 fija un parámetro que
especifica si se ha iniciado la actualización de la política. Esta
fijación se almacena en un archivo de inicialización del gestor
IPSec 60 (no mostrado en la Fig. 3). A continuación, el gestor IPSec
60 inicia el proceso de actualización de la política correspondiente
a la política activada realizando una llamada a un método
correspondiente de un agente ACU y pasándole al mismo varios
parámetros. Dichos parámetros incluyen la ID de política (como ID de
contenido) y la ID de un plug-in ACU IPSec (por
ejemplo, el UID3 del DLL Plug-in ACU IPSec). A
continuación, el agente ACU 74 carga el plug-in
especificado y usa dicho plug-in (no mostrado en la
Fig. 3) como interfaz entre el agente ACU 74 y el gestor IPSec 60
para obtener la ID del servidor (en el ejemplo, el servidor SSM 20)
con el cual se va a realizar el proceso de actualización; a
continuación el plug-in implementa la llamada del
agente ACU 74 realizando una llamada al gestor IPSec 60. Si el
plug-in no devuelve una ID de servidor al agente ACU
74, el proceso de actualización finaliza. El proceso finaliza
también si el registro de aplicación de cliente en los medios de
almacenamiento de datos ACU 66 no dispone de un registro de cuentas
de servidor asociado con la ID de servidor especificada. Si el
plug-in devuelve una ID de servidor válida al agente
ACU 74, se continúa con el proceso de actualización de la
política.
Un usuario puede iniciar el aprovisionamiento
del dispositivo móvil 10 a través de una UI (por ejemplo, moviendo
un recuadro de selección por encima de un icono y presionando una
tecla de selección, tal como se muestra en la Fig. 14). En una de
las formas de realización, no se visualizan datos si no hay
políticas instaladas en el dispositivo (Fig. 15). En dicha forma de
realización, un menú de opciones en una UI del dispositivo móvil 10
ofrece una lista de varias funciones que puede realizar un usuario,
y una orden de retorno devuelve al usuario a un menú de aplicación
principal.
Para obtener una primera política, un usuario se
conecta al servidor SSM 20. Del menú Opciones, el usuario selecciona
"Actualizar desde el servidor" (Fig. 16) para iniciar la
recepción de la política. El dispositivo móvil 10 se conecta al
servidor SSM 20 y la conexión está protegida por una contraseña de
cliente VPN. Si esta es la primera vez que se está usando el
dispositivo, puede que sea necesario que el usuario cree una
contraseña de cliente VPN. Durante la introducción de la contraseña,
cada carácter se muestra durante un instante antes de que cambie a
un asterisco (Fig. 17). Al presionar "OK" después de introducir
los caracteres se acepta la contraseña y se continúa con el proceso.
La selección de "Cancelar" devuelve al usuario a la pantalla
principal del cliente. En la siguiente etapa de aprovisionamiento,
el usuario introduce el URL o la dirección IP del servidor SSM 20
(Fig. 18). En una de las formas de realización, la dirección del
servidor se le entrega al usuario por medio de un gestor de
seguridad empresarial o de red. Después de introducir "OK", la
dirección es aceptada y el proceso continúa. Tal como en la
situación anterior, "Cancelar" devuelve al usuario a la
pantalla principal del cliente VPN. A continuación, el usuario
selecciona un Punto de Acceso a Internet (IAP) para conectarse a
Internet (o a una red específica de marcación) (Fig. 19). En una de
las formas de realización, el sistema operativo visualiza un
diálogo cuando detecta que una aplicación solicita un acceso a
Internet. "Seleccionar" acepta un punto de acceso a Internet, y
"Cancelar" devuelve al usuario a la pantalla principal del
cliente VPN. A continuación, el dispositivo móvil 10 se conecta al
servidor SSM 20. En una de las formas de realización, una "G"
en un recuadro en la esquina izquierda superior de una pantalla
informa al usuario de que el acceso GPRS está activo en una red
móvil (Fig. 20). Si se selecciona "Cancelar" el proceso
finaliza.
Si no hay presentes (o los mismos no son
válidos) ningún certificado para el servidor SSM 20 ni la
información de configuración para el cliente VPN, el proceso de
inicialización del cliente recupera del servidor SSM 20 un paquete
de configuración del cliente (Fig. 20). Sin que se disponga de un
certificado de servidor SSM en los medios de almacenamiento de datos
ACU 66, el agente ACU 74 no puede confiar automáticamente en la
respuesta y en el servidor que la envió. Para establecer una
confianza, el agente ACU 74 le pide al usuario que introduzca un
código de identidad de servidor. En una de las formas de
realización, un software en el dispositivo móvil 10 invita al
usuario a que introduzca números de entre un código de
identificación de 16 bytes o una "huella dactilar" de un
certificado entrante, y visualiza los números restantes para que el
usuario realice una verificación en relación con la huella dactilar
completa. Por ejemplo, un código de huella dactilar puede presentar
por ejemplo la siguiente forma "12qwe34rtyqwe1234". Cuando está
verificando el servidor, al usuario se le muestra un código o cadena
incompleta, por ejemplo, "12qwexxrtyqwexx34", en la que
"x" designa un carácter que falta. Para verificar el servidor,
a continuación el usuario debe introducir "34" en las primeras
dos x y "12" en las últimas dos x. El dispositivo móvil 10
calcula una huella dactilar del certificado recibido durante la
conexión y la convierte en una cadena legible; a continuación, el
dispositivo elimina ``por ejemplo, cambia a "x", "_",
etcétera) uno o más caracteres seleccionados aleatoriamente de la
cadena y visualiza la cadena modificada al usuario. La selección
aleatoria de caracteres se puede personalizar según las capacidades
de un dispositivo móvil. Por ejemplo, en un teléfono móvil con un
teclado numérico pequeño, únicamente se eliminan aleatoriamente
caracteres de dígitos. Las capacidades del dispositivo pueden ser
determinadas por, por ejemplo, el código IMEI correspondiente al
dispositivo. El número de caracteres que faltan en la cadena también
puede variar. Las posiciones de los caracteres eliminados
aleatoriamente en la huella dactilar son diferentes para intentos de
acceso diferentes. El agente ACU 74 compara los dígitos o caracteres
introducidos por el usuario con los caracteres eliminados de entre
los 16 bytes de la huella dactilar del certificado del servidor SSM
recibido. Si el código coincide con la huella dactilar, es decir,
los caracteres introducidos por el usuario coinciden con los
caracteres eliminados de la huella dactilar del servidor, el agente
ACU 74 asume que se puede confiar en el servidor SSM 20 y almacena
el certificado del servidor en el archivo de certificados 48 en los
medios de almacenamiento de políticas IPSec 40 mediante una llamada
al gestor IPSec 60. A continuación, se permite que continúe la
conexión con el servidor SSM 60.
En la Fig. 21 se muestra otro ejemplo del
procedimiento anterior. El servidor SSM 20 crea un resumen del
certificado del servidor y envía dicho resumen al dispositivo móvil
10 en forma de una huella dactilar. En el ejemplo de la Fig. 21, la
huella dactilar es el valor hexadecimal de 16 bytes
11:AF:93:B4:C8:B8:BA:CE:81:64:00:DB:9F:D5:91:59. Antes del
aprovisionamiento de la política, un administrador de la red
proporciona al usuario del dispositivo móvil 10 la huella dactilar
de una manera segura, por ejemplo, enviando por correo una tarjeta
que tenga impresa sobre ella la huella dactilar. El dispositivo
móvil 10 calcula la huella dactilar (por ejemplo, el resumen del
certificado) y visualiza la huella dactilar con cuatro caracteres
seleccionados aleatoriamente sustituidos por espacios en blanco
("_"). A continuación el usuario introduce los cuatro
caracteres que faltan. De este modo se evita que el usuario acepte
el certificado sin ni siquiera verificarlo.
Con el uso del procedimiento anterior, un
usuario verifica el certificado de un servidor para garantizar que
el usuario se está conectando a un servidor auténtico, y no a un
servidor hostil (tal como un servidor que simule ser el servidor
deseado). Esta verificación se realiza comparando la huella dactilar
del certificado previamente publicada con la huella dactilar
calculada a partir del certificado recibido del servidor.
Tal como se ha indicado, en varias formas de
realización el código de la huella dactilar para el servidor SSM 20
se le proporciona fuera de línea (antes del aprovisionamiento) al
usuario. El administrador del servidor da a conocer la huella
dactilar del certificado de alguna manera que no pueda ser cambiada
por los atacantes (por ejemplo, un boletín informativo de la
empresa, mediante entrega personal, por correo regular, etcétera).
El software de cliente del usuario calcula la huella dactilar y a
continuación visualiza la huella dactilar para el usuario con
caracteres aleatorios sustituidos por espacios en blanco (u otros
caracteres) y le pide al usuario que introduzca los caracteres que
faltan. Para poder realizar esta operación, el usuario debe
verificar la huella dactilar incompleta que se ha mostrado en
relación con la huella dactilar dada a conocer. Si el usuario puede
introducir los caracteres válidos, en ese caso también ha verificado
que la huella dactilar es la correcta (de lo contrario no habría
conocido los caracteres que faltan).
En por lo menos una de las formas de
realización, el cliente VPN solicita de forma sustancialmente
simultánea (y sin ninguna interacción por parte del usuario) un
certificado del servidor SSM 20 siempre que se conecta el
dispositivo móvil 10 a una red de empresa (tal como la intranet de
la Fig. 2). En otras palabras, el software del cliente VPN añade a
cada intento de acceso al servidor el proceso de validación de
certificados antes descrito.
Una de las formas de realización de la invención
permite que los usuarios confirmen la conexión con un dispositivo
seguro cuando obtienen un servicio de Internet de alta velocidad
desde casa, hoteles, aeropuertos, cafés, etcétera. Por ejemplo, un
usuario puede estar viajando y puede que desee conectar el
dispositivo móvil 10 a un punto de acceso a Internet de alta
velocidad desde una ubicación visitada. A todo el mundo que desee
usar el punto de acceso se le entrega a través de unos medios de
confianza una huella dactilar de un certificado correspondiente a
dicho punto de acceso. En un hotel, la huella dactilar la podría
proporcionar un recepcionista. La huella dactilar también se podría
enviar por correo al usuario. La huella dactilar se podría
visualizar de forma pública en un entorno de confianza que no se
pueda modificar fácilmente, tal como un tablón de anuncios protegido
o de difícil acceso. A continuación, de forma similar al
procedimiento expuesto anteriormente en líneas generales, el
dispositivo móvil 10, como parte de la co-
nexión al punto de acceso de alta velocidad, podría requerir que el usuario suministrase caracteres de la huella dactilar.
nexión al punto de acceso de alta velocidad, podría requerir que el usuario suministrase caracteres de la huella dactilar.
En algunas formas de realización, y tal como se
ha indicado anteriormente, la huella dactilar de un certificado se
calcula a partir del propio certificado, por ejemplo, a través de
una función resumen.
Después de que el usuario del dispositivo 10
haya verificado el certificado del servidor SSM 20, el servidor SSM
20 requiere al usuario que verifique que el mismo es quien afirma
ser, y que se ha establecido una cuenta para el o ella. Se invita al
usuario a que introduzca un nombre de usuario y una contraseña para
acceder al servidor SSM 20 (Fig. 22). En algunas formas de
realización, se podrían usar testigos o contraseñas de un solo uso.
Después de que el servidor SSM 20 y el dispositivo 10 se hayan
autenticado mutuamente, el dispositivo 10 almacena el certificado
del servidor SSM 20 y recibe información sobre el contenido
disponible (Fig. 23). El agente ACU 74 almacena una referencia a un
certificado recibido en el registro de cuentas del servidor 82 (Fig.
4) de los medios de almacenamiento de datos ACU 66 (Fig. 3) junto
con otra información de configuración de cliente recibida desde el
servidor SSM 20. El usuario obtiene una lista de contenido
disponible (Fig. 24) que (en este ejemplo) incluye una política VPN
nueva ("genérica*") de la aplicación de gestión de políticas
VPN 26, así como un certificado ACU ("certACU"). El certificado
ACU es un certificado de dispositivo para el usuario, que se usa
para autenticar el dispositivo 10 con el servidor SSM 20. El
dispositivo 10 descarga contenido (Fig. 25). Cuando se ha completado
la descarga de contenido, el dispositivo 10 muestra las políticas
VPN disponibles (Fig. 26; no se muestran certificados). A
continuación el usuario puede usar la(s)
nueva(s) política(s) conectándose a una pasarela VPN.
nueva(s) política(s) conectándose a una pasarela VPN.
Llegado este momento, el dispositivo 10 ha
recibido una política que requiere una inscripción de certificados.
En otras palabras, la política no dispone todavía de un certificado
adjunto el cual se pueda usar para la autenticación. Si el
certificado de cliente no se encuentra en su lugar o no es válido,
el proceso de inicialización del cliente continúa con la inscripción
del certificado de cliente.
En primer lugar, el cliente VPN del dispositivo
10 comprueba si la política VPN es una política de autenticación con
certificado, y si se dispone de un certificado adjunto a la
política. Si la política no contiene un certificado válido, se le
pregunta al usuario si desea inscribir un certificado (Fig. 27). Al
seleccionar "sí", al usuario se le presenta una UI que indica
generación de una solicitud de certificado (Fig. 28). Esta opción
comienza con la generación de un par de claves pública/privada para
la aplicación de cliente, a no ser que ya haya creado un par de
claves de la longitud requerida. En una de las formas de
realización, todas las cuentas del servidor que crea el agente ACU
74 para una aplicación de cliente usan el mismo conjunto de pares de
claves. El conjunto incluye un único par de claves de cada longitud
de clave diferente requerida por los servidores. Los pares de claves
son generados mediante llamadas al gestor IPSec 60. La longitud de
las claves generadas se determina por medio de un parámetro incluido
en la información de configuración de cliente recuperada del
servidor SSM 20 y almacenada en el registro CuentaServidor 82
correspondiente en los Medios de Almacenamiento de datos ACU 66.
A continuación, el agente ACU 74 puede solicitar
del usuario (no mostrado) una información de autenticación
tradicional (nombre de usuario y contraseña). La información de
autenticación tradicional se usa para autenticar la solicitud de
inscripción de certificado enviada al servidor SSM 20.
Adicionalmente, el nombre de usuario especificado se puede combinar
con información de identidad del usuario contenida en un paquete de
configuración de cliente, o una transacción de mensaje usada para
descargar un paquete de configuración de cliente ACU (por ejemplo,
el certificado de cliente ACU usado en comunicaciones ACU
subsiguientes) hacia el cliente ACU, con vistas a formar la
identidad de usuario a usar en el Certificado de cliente.
Una vez que se ha pedido el nombre de usuario,
el par de claves está preparado y el identificador del par de claves
devuelto está almacenado en el registro CuentaServidor 82 adecuado
en los Medios de Almacenamiento de Datos ACU 66, el agente ACU 74
obtiene una solicitud de certificado PKCS#10 codificado con correo
con privacidad mejorada (PEM) para el par de claves generado y la
identidad de usuario suministrada mediante una llamada al gestor
IPSec 60. En el caso de un certificado de cliente, el atributo de
contraseña de desafío en la solicitud del certificado se deja vacío.
A continuación, el gestor IPSec 60 comprueba si la solicitud de
certificado pedida ya existe (por ejemplo, está almacenada en
memoria caché) en los medios de almacenamiento de políticas IPSec
40. Si la solicitud no existe, el gestor IPSec 60 la crea usando un
módulo PKCS#10 (no mostrado en la Fig. 3).
Después de crear la solicitud del certificado,
el gestor IPSec 60 almacena (guarda en memoria caché) la solicitud
en los medios de almacenamiento de políticas IPSec 40. La memoria
caché de solicitudes se usa para evitar la regeneración de
solicitudes de certificados cuya inscripción finaliza una o más
veces con un estado pendiente. A continuación, el agente ACU 74
construye un mensaje de solicitud ACU que contiene la solicitud
PKCS#10. A continuación, el dispositivo 10 envía el mensaje al
servidor SSM 20 para la inscripción del certificado. Se invita al
usuario a que seleccione un punto de acceso a Internet (Fig. 29). A
continuación el agente ACU 74 almacena el estado de inscripción
devuelto (satisfactorio, fallo, pendiente) en el registro
CuentaServidor 82 adecuado en los medios de almacenamiento de datos
ACU 66. La Fig. 30 muestra una UI que indica recepción por el
dispositivo 10 de un certificado. Si la inscripción del certificado
es satisfactoria, el agente ACU 74 almacena el certificado de
cliente devuelto en los medios de almacenamiento de políticas IPSec
40 mediante una llamada al gestor IPSec 60. El agente ACU 74
almacena también una referencia al certificado memorizado en el
registro CuentaServidor 82 adecuado en los medios de almacenamiento
de datos ACU 66. Si el servidor SSM 20 devuelve un código de retorno
de inscripción de certificado que indica resultado satisfactorio o
fallo (es decir, no una solicitud pendiente), el agente ACU 74
elimina del gestor IPSec 60 la solicitud de certificado
correspondiente.
El proceso automatizado de inscripción de
certificados se inicia cuando un usuario activa una política a
través de la UI IPSec. La solicitud de activación de políticas fluye
desde la UI IPSec hacia la interfaz de programación de aplicaciones
(API) IPSec y adicionalmente hacia el gestor IPSec 60. Si el gestor
IPSec 60 determina que la política que se está activando requiere
una inscripción de certificado, devuelve un código de retorno
correspondiente a la API IPSec sin activar la política. Al recibir
un código de retorno que indica la necesidad de una inscripción de
certificado, la API IPSec detiene el proceso de activación de la
política y devuelve el código de retorno a la UI IPSec. Al recibir
un código de retorno que indica una necesidad de una inscripción de
certificado, en primer lugar la UI IPSec lanza un diálogo de
confirmación que permite que el usuario acepte o rechace el proceso
de inscripción venidero. Si el usuario acepta la inscripción, la UI
IPSec continúa abriendo un diálogo de avance que se mostrará siempre
que el proceso de inscripción continúe. El diálogo de avance también
permite que el usuario detenga el proceso de inscripción que está en
marcha. En una de las formas de realización, en el inicio del
proceso de activación de la política (antes de la confirmación
anterior y los diálogos de avance) se pide la contraseña de cliente
VPN y la misma no se solicita nuevamente durante el proceso de
inscripción del certificado.
El usuario puede cambiar a otras aplicaciones
mientras el proceso de inscripción del certificado continúa. El
diálogo de avance está únicamente visible en la UI IPSec, aunque por
encima de otras aplicaciones a las que esté accediendo el usuario
aparecen diálogos que requieren la interacción por parte del mismo
durante el proceso de actualización.
Después de que el usuario vuelva a aceptar la
inscripción en la UI IPSec, el proceso de inscripción continúa
mediante una llamada al agente ACU 74 para realizar una inscripción
automatizada del certificado correspondiente a la política
especificada. La llamada incluye como parámetros la ID de un
plug-in a usar en el proceso de inscripción (por
ejemplo, un Plug-in ACU IPSec, o la interfaz con el
gestor IPSec 60 para el agente ACU 74) y la ID de la política para
la cual se va a realizar la inscripción del certificado. Desde el
punto de vista del agente ACU 74 la ID de política es un parámetro
específico del cliente, por ejemplo, un usuario del dispositivo 10
puede pertenecer a muchos grupos (que se describirán
posteriormente), aunque el usuario dispone de una ID de política. A
continuación, el agente ACU 74 llama al Plug-in ACU
IPSec para que retorne una lista de servidores de inscripción para
la política. El Plug-in ACU IPSec implementa la
llamada llamando al gestor IPSec 60. Una dirección de servidor en la
lista devuelta indica el servidor (por ejemplo, el servidor SSM 20)
al que se van a enviar una o más solicitudes de certificado. No
obstante, una única
política VPN puede referirse a múltiples certificados y cada certificado se puede inscribir con un servidor diferente.
política VPN puede referirse a múltiples certificados y cada certificado se puede inscribir con un servidor diferente.
A continuación en el proceso de inscripción, el
agente ACU 74 toma las direcciones del servidor devueltas, de una en
una, y comprueba si la comunicación con el servidor respectivo se ha
inicializado correctamente. En caso negativo, el agente ACU 74 le
pide al usuario que seleccione la IAP a usar para comunicarse con el
servidor (por ejemplo, Fig. 29). A continuación, el agente ACU 74
realiza un proceso de inicialización de cliente para el servidor.
Una vez que la comunicación con el servidor se ha inicializado
correctamente, el agente ACU 74 realiza una llamada al
plug-in para que devuelva las solicitudes de
certificado correspondientes a la combinación
política-servidor especificada. En la llamada se
incluye también la identidad ACU asociada al servidor (por ejemplo,
el servidor SSM 20).
Cuando el gestor IPSec 60 recibe una solicitud
de crear y devolver solicitudes de certificado de una cierta
política, el mismo gestiona la solicitud. Cada solicitud de
certificado en la lista devuelta al agente ACU 74 por el gestor
IPSec 60 incluye una solicitud de certificado PKCS#10 codificado con
PEM y un identificador de solicitud. Los identificadores de
solicitud son definidos por aplicaciones de cliente y se trasladan
de vuelta a las aplicaciones (a través de las interfaces ACU
correspondientes) en las respuestas de inscripciones. En el caso del
cliente VPN, el identificador de solicitud es una combinación de una
información de identidad del suscriptor (subject) y de pares de
claves que el cliente VPN puede usar para hallar la política y el
sistema anfitrión con los cuales esté asociada una cierta respuesta
de inscripción. A continuación, el agente ACU 74 crea un mensaje de
solicitud ACU que comprende todas las solicitudes de certificados
destinadas a un cierto servidor y envía el mensaje de solicitud.
Cuando se recibe una respuesta de un servidor,
el agente ACU 74 analiza sintácticamente la respuesta y traslada las
respuestas devueltas de inscripción de certificados, de una en una,
al Plug-in ACU IPSec. El plug-in
traslada las respuestas adicionalmente al gestor IPSec 60.
Una respuesta de una inscripción comprende una
ID de política, una ID de solicitud de certificado y un código de
estado, y puede incluir un certificado. El certificado está presente
solamente si el código de estado indica una inscripción
satisfactoria. El certificado está ausente si el código de estado
indica un fallo o que la solicitud de inscripción está
pendiente.
Cuando el Gestor IPSec 60 recibe una respuesta
de inscripción, almacena el certificado (en el caso de que haya sido
devuelto) en los Medios de Almacenamiento de Políticas IPSec 40 y
memoriza el estado de la inscripción en el campo correspondiente de
información de inscripción en el archivo de políticas VPN 46. El
campo correspondiente de información de inscripción se halla según
el identificador de solicitud de certificado devuelto.
Si el código de estado de inscripción indica
resultado satisfactorio o fallo pero no una solicitud pendiente, el
Gestor IPSec 60 elimina de los Medios de Almacenamiento de Políticas
IPSec 40 la solicitud de certificado almacenada en memoria
caché.
Cuando el agente ACU 74 ha procesado todas las
solicitudes de certificado devueltas por el Plug-in
ACU IPSec correspondientes a una cierta política y ha trasladado los
certificados devueltos de retorno al plug-in, el
mismo devuelve un código de resultado satisfactorio/error a la API
IPSec que inició el proceso de inscripción del certificado. A
continuación, la API IPSec devuelve el código a la UI IPSec.
Si la UI IPSec recibe un código de retorno de
error como respuesta a una llamada de inscripción de certificado, la
misma muestra un diálogo informando al usuario de que la inscripción
ha fallado y de que la política no se puede activar. Si la UI IPSec
recibe un código de retorno satisfactorio, muestra un diálogo
informando al usuario de que la inscripción ha resultado
satisfactoria y de que la política se puede activar en este momento.
En este diálogo, el usuario puede dejar que la política se active o
puede cancelar la activación. Si la activación continúa, no se
solicitan nuevamente la contraseña de cliente VPN, ya que la misma
se obtuvo antes de que se iniciase el proceso de inscripción.
Después de que se haya descargado una política,
el usuario debe activarla. En por lo menos una de las formas de
realización un usuario activa una política seleccionando la política
(Fig. 31) y a continuación escogiendo "Activar" el un menú de
Opciones (Fig. 32). La activación de la política está protegida por
la contraseña del cliente VPN (Fig. 33). Para una política de
certificados, esta contraseña también desbloquea las funciones de
las claves privadas. El usuario selecciona el Punto de Acceso a
Internet (IAP) que el prefiere usar para conectarse a la red
empresarial (Fig. 34). Una vez que el usuario ha seleccionado el
IAP, el dispositivo inicia una conexión con una pasarela VPN
mostrando al usuario que la conexión GPRS está activa para una
política "genérica predefinida"; un punto de color 110 indica
que la inicialización está en camino (Fig. 35). Tras establecer
satisfactoriamente una conexión, el túnel VPN está preparado para
ser usado por cualquier aplicación, y la interfaz de usuario informa
de que la política "genérica predefinida" está activa cambiando
el color del punto 110 a, por ejemplo, verde. A continuación, el
usuario puede acceder de forma segura a sus datos en Intranet
seleccionando una aplicación adecuada. El usuario puede desactivar
la conexión del túnel VPN volviendo a la aplicación de políticas y
seleccionando "Desactivar" del menú Opciones.
En algunas formas de realización, un servidor
SSM incluye varios componentes y una estación de gestión. Estos
componentes se pueden combinar en una única plataforma o pueden
estar divididos entre múltiples plataformas. Haciendo referencia a
la Fig. 5, el servidor SSM 20 se muestra dentro del recuadro de
contorno discontinuo con una pasarela de inscripción (EGW) 22, un
servidor Web 90, una base de datos 98 y una CA interna 28 para
indicar que estos componentes, por lo menos en algunas formas de
realización, residen en un único dispositivo. En otras formas de
realización, algunos o la totalidad de estos componentes residen en
dispositivos independientes. Todavía en otras formas de realización,
otros componentes (incluyendo, por ejemplo, una pasarela de correo
electrónico 32, un servidor RADIUS 30 ó una aplicación de gestión de
políticas VPN 26) podrían residir en el mismo dispositivo con el
servidor SSM 20.
La base de datos 98 es una base de datos
relacional integrada que almacena información sobre los usuarios,
grupos de usuarios, políticas de clientes, otros archivos y sus
propiedades. El cliente ACU hace referencia a objetos de contenido
del SSM en la base de datos 98 con identificadores lógicos tales,
por ejemplo, Acu_config_db<nombre>, y realiza la inscripción
de certificados usando identificadores lógicos tales como, por
ejemplo, Acu_cert_db<nombre>, siendo reconocidos e
interpretados dichos identificadores por el servidor SSM 20. Los
usuarios finales del servidor SSM 20 se autentican ellos mismos
antes de obtener acceso a la información o funcionalidad del
servidor SSM 20. La autenticación se basa en el uso de
autenticadores (proveedores de autenticación). La identidad de un
usuario en la base de datos 98 es del tipo USERFQDN (usuario +
nombre de dominio totalmente cualificado, por ejemplo,
idusuario@dominio). Otra información de los usuarios puede incluir
el apellido, el nombre de pila, el nombre de inicio de sesión, la
contraseña, la dirección de correo electrónico, el número del
teléfono móvil o el IMEI, el servidor de autenticación, grupos de
usuarios, reglas de autoaprovisionamiento, y reglas de
concordancia.
El servidor SSM 20 determina en dónde se ha
identificado un usuario. Existen por lo menos tres tipos diferentes
de autenticadores. El primero es un autenticador SSM, en el que las
combinaciones de id/contraseña de usuario se comprueban en relación
con la base de datos 98. Únicamente puede existir a la vez una
instancia de este tipo de autenticador. El segundo tipo de
autenticador es un autenticador RADIUS, en el que las combinaciones
de id/contraseña de usuario se comprueban en relación con un
servidor RADIUS 30. Las contraseñas pueden ser bien contraseñas
normales o bien contraseñas de un solo uso generadas con tarjetas
testigo (tales como SecurID). Pueden existir al mismo tiempo varias
instancias de este tipo de autenticador.
El tercer tipo de autenticador es el
autenticador de certificados, en el que el usuario debe presentar un
certificado válido y una firma. La validez del certificado requiere
que el mismo esté firmado por una CA de confianza, y que no haya
expirado ni haya sido revocado. Si la firma se firmó con el
certificado, el usuario se considera como autenticado. La dirección
de correo electrónico en el campo de extensión de nombre alternativo
del suscriptor correspondiente al rfc822Name se usa para establecer
una correspondencia del usuario con una id de usuario SSM. En el
campo de solicitud de certificado, se inserta una identidad del
suscriptor del certificado en el campo de extensión de nombre
alternativo del suscriptor correspondiente al certificado de cliente
ACU como un rfc822Name (es decir, una dirección de correo
electrónico de la forma "parte-local@dominio").
La dirección de correo electrónico se construye a partir de un
nombre de usuario/ID solicitado del usuario y a partir del nombre de
dominio totalmente cualificado especificado en el elemento FQDN,
usándose dicho valor como la parte de dominio de una dirección de
correo electrónico almacenada en el campo de extensión de nombre
alternativo del suscriptor correspondiente al certificado de cliente
ACU. El nombre común del DN de suscriptor es el mismo que la parte
local del rfc822Name. Si hay presente un sufijo DN de suscriptor en
un certificado de usuario usado para acceder a una pasarela VPN, el
mismo anula un valor de configuración de servicio de inscripción
correspondiente. Una bandera indica si un certificado de usuario
usado para acceder a una pasarela VPN debería incluir la identidad
de usuario como rfc822Name en el campo de extensión de nombre
alternativo del suscriptor de los certificados. Los valores posibles
son 0 = no y 1 = sí. Si este valor está presente, el mismo también
anula el valor de configuración de servicio de inscripción
correspondiente. El nombre de dominio totalmente cualificado (FQDN)
a usar es el valor rfc822Name si la identidad de usuario está
incluida como un rfc822Name en el campo de extensión de nombre
alternativo del suscriptor de los certificados. Si este valor está
presente, el mismo también anula el valor de configuración de
servicio de inscripción correspondiente. También se puede
proporcionar la longitud esperada de la clave privada cuya clave
pública correspondiente está incluida en el certificado de usuario
con esta pasarela VPN. Si este valor está presente, el mismo también
anula el valor de configuración de servicio de inscripción
correspondiente.
Cada autenticador tiene un nombre y un número
variable de atributos que dependen del tipo del autenticador. En por
lo menos una de las formas de realización, todas las
implementaciones de los autenticadores soportan una interfaz Java
común, la interfaz del autenticador.
La asociación de solicitudes de autenticación
con autenticadores se basa en las credenciales suministradas (id de
usuario/contraseña o un certificado/firma), en un establecimiento de
correspondencias de autenticadores con usuarios, y en un conjunto de
reglas de autoaprovisionamiento. Si el usuario que realiza la
solicitud de autenticación tiene un registro en la base de datos
SSM, el autenticador especificado en ese registro se usa para
autenticar al usuario. Si el registro no especifica ningún
autenticador, la autenticación no resulta satisfactoria.
Si el usuario que realiza la solicitud de
autenticación no tiene un registro en la base de datos SSM, la
autenticación se realiza según un conjunto de reglas de
autoaprovisionamiento. En una de las formas de realización, una
regla de autoaprovisionamiento establece una correspondencia
conjunta de tres elementos de información: una ID de dominio, un
autenticador y un grupo de usuarios. La ID de dominio se extrae del
nombre de usuario incluido en la solicitud de autenticación y se
compara con las ID de dominio definidas para las reglas de
autoaprovisionamiento. Si no se halla ninguna regla de concordancia,
la autenticación no resulta satisfactoria.
También se deben autenticar los componentes SSM
que acceden a otros componentes sin una identidad de usuario final
(por ejemplo, un servidor PKI que solicite una CRL (lista de
revocación de certificados) del servidor SSM 20). Esta opción se
basa en un secreto compartido que fue proporcionado por el
administrador del sistema cuando el mismo instaló los
componentes.
Cuando se ha autenticado satisfactoriamente un
usuario final con una regla de autoaprovisionamiento (por ejemplo,
cuando no existe ningún registro de usuario en la base de datos 98),
en la base de datos 98 se crea automáticamente un nuevo registro de
usuario. El nuevo registro de usuario se asocia automáticamente a un
grupo de usuarios que se haya especificado como el grupo por defecto
en la regla de autoaprovisionamiento que se usó para autenticar al
usuario. Adicionalmente, el nuevo registro de usuario se asocia al
autenticador que se usó para autenticar al usuario.
Un grupo de usuarios por defecto puede presentar
un número cualquiera de entradas de contenido asociadas al mismo; de
este modo el contenido se puede asociar automáticamente a los
usuarios. A continuación, los usuarios pueden recuperar contenido
del servidor SSM 20 incluso en el caso de que el administrador no
haya creado o importado ninguna información de usuario hacia el
servidor SSM 20.
Una vez que se ha conectado al servidor SSM 20,
el usuario (bien un usuario cliente o bien el administrador) puede
usar el servidor SSM 20 según los permisos definidos en la base de
datos 98. La información de permisos se almacena también en la base
de datos 98 para usuarios que se hayan autenticado en relación con
un servidor de autenticación externo. En por lo menos una de las
formas de realización, los permisos de uso se definen en el SSM como
roles. Un rol es una definición de los objetos a los que tienen
permiso a acceder los usuarios, y de las acciones que pueden
realizar, cuando se encuentran en ese rol. En una de las formas de
realización, el servidor SSM 20 soporta cuatro tipos diferentes de
grupos de usuarios: gestores de sistema, gestores de usuarios,
gestores de contenido y usuarios cliente. Cada uno de estos tipos de
grupo tiene un rol asociado que es heredado por todos los grupos
concretos de ese tipo así como por todos los usuarios que pertenecen
a dichos grupos. Un usuario que pertenece a varios grupos de
usuarios con roles diferentes hereda el rol que presente menos
limitaciones. En una de las formas de realización, los tipos de
grupo de usuario por defecto y sus roles se definen en la
configuración del servidor SSM 20 ó la configuración ACU y no se
pueden cambiar a través de la interfaz gráfica de usuario (GUI) o de
la interfaz de línea de órdenes (CLI) del gestor del servidor SSM
20. No obstante, mediante el cambio de la configuración del servidor
SSM 20 se pueden cambiar los roles asociados a tipos de grupo por
defecto.
Los componentes que acceden a las funciones del
servidor SSM 20 a través de la red sin una identidad de usuario
tienen un rol de componente especial que se usa para definir qué
pueden hacer dichos componentes. Adicionalmente, existe un rol
interno especial que es usado internamente por el servidor SSM 20,
pudiendo acceder dicho rol a todos los objetos y pudiendo realizar
todas las operaciones. Aunque los paquetes de instalación de
software de cliente VPN y las políticas/perfiles VPN son tipos de
contenido gestionados por el SSM, el SSM no se limita a estos tipos
de
contenido.
contenido.
El contenido que distribuye el servidor SSM 20
no se crea necesariamente dentro del propio servidor SSM 20. Por el
contrario, el contenido se puede crear en sistemas externos y se
puede importar hacia el servidor SSM 20 en forma de archivos. Dentro
del servidor SSM 20, los archivos se convierten en entradas de
contenido con un cierto tipo de extensión multifunción de correo por
Internet (MIME). La operación de importación se puede iniciar a
partir de una CLI del servidor SSM 20. En algunas formas de
realización, los archivos a importar deben ser accesibles localmente
a través de operaciones normales del sistema de archivos.
El servidor SSM 20 está integrado con la
aplicación de gestión de políticas (PMA) 26 al permitir que las
políticas y los perfiles creados y mantenidos por la PMA 26 sean
exportados hacia el servidor SSM 20. Esta operación se inicia desde
dentro de la PMA 26. La PMA 26 se comunica con el servidor SSM 20 a
través de, por ejemplo, una interfaz JAVA diseñada con este fin.
Los administradores de los SSM pueden importar
información de usuarios y de grupos de usuarios hacia el servidor
SSM 20 desde sistemas externos. Además de la información de usuarios
corrientes y de grupos de usuarios, hacia el servidor SSM 20 también
se puede importar información de establecimiento de correspondencias
de usuario-a-grupo y de
grupo-a-grupo. Por ejemplo, los
administradores pueden crear usuarios y grupos de usuarios, buscar
en usuarios y en grupos de usuarios, modificar atributos de usuarios
y de grupos de usuarios, mover y eliminar usuarios y grupos de
usuarios, asociar usuarios a grupos de usuarios y entradas de
contenido, y asociar grupos de usuarios a otros grupos de usuarios
(por ejemplo, para formar una jerarquía de grupo).
La Fig. 6 muestra varios grupos de usuarios en
una empresa. Los grupos de usuarios pueden formar una jerarquía en
la que un grupo individual 112, 114, 116 ó 118 puede tener un grupo
progenitor 110. La jerarquía de grupo también forma una jerarquía de
herencia lógica. Los grupos vástagos 112, 114, 116, 118 heredan
ciertas propiedades de sus grupos progenitores 110. Por ejemplo, las
entradas de contenido asociadas a un grupo 110 están asociadas
indirectamente también a sus grupos vástagos 112, 114, 116, 118. Al
final de la jerarquía de herencia se encuentran los usuarios que
heredan propiedades de los grupos a los que pertenecen.
El grupo 110 de la Fig. 6 está asociado a una
única política y a un único usuario. No obstante, debido al
mecanismo de herencia (las ventas se heredan de la oficina de
Londres la cual se hereda de la Sede central de la empresa), el
grupo de usuarios 116 tiene políticas asociadas diferentes a las que
tienen los grupos 114 y 118. Paul Boss tiene una política asociada,
la política de la Sede central de la empresa, a través del grupo
Sede central de la empresa 110. Mary Scary se encuentra en la
oficina de Londres y tiene dos políticas asociadas, de la Sede
central de la empresa 110 y de Londres 112. Tim Tooth trabaja en la
oficina de ventas de Londres y tiene tres políticas asociadas: de la
Sede central de la empresa 110, de Londres 112 y de Ventas 116.
Cuando una entrada de contenido está asociada a
un grupo de usuarios 110, la entrada está asociada indirectamente
también a todos los usuarios y grupos que pertenecen a ese grupo o
cualquiera de sus grupos vástagos. Esta asociación indirecta se
impone en tiempo de ejecución por la lógica de la aplicación que
atraviesa la jerarquía de grupo desde abajo hacia arriba. Cuando se
elimina una entrada de contenido, también se eliminan la totalidad
de sus asociaciones con usuarios y grupos de usuarios.
Los certificados de la EGW 22 (Figs. 2, 5) para
la autenticación ACU se emiten desde la Autoridad de Certificación
(CA) interna 28 del SSM. La EGW 22 también puede emitir certificados
para la autenticación VPN desde la CA interna 28. De forma
alternativa (o adicional), la EGW 22 se puede comunicar con
autoridades CA Externas, actuando como una Autoridad de Registro
(RA) hacia CA externas y como punto de control para solicitudes de
inscripción de certificados de cliente, y puede reenviar solicitudes
de inscripción a una CA adecuada usando el SCEP (protocolo simple de
inscripción de certificados) o la CRS (sintaxis de solicitud de
certificados). En algunas formas de realización, la EGW 22
proporciona una conversión entre protocolos de inscripción.
En varias formas de realización, el servidor Web
90 actúa como una interfaz externa con el servidor SSM 20. Un
dispositivo móvil 10 envía una solicitud de inscripción de
certificados al servidor Web 90, el cual la reenvía a la EGW 22. El
dispositivo móvil 10 se conecta también con el servidor Web 90 para
actualizaciones automáticas del contenido desde la base de datos SSM
98. Una aplicación de gestión de políticas VPN 26 exporta políticas
(o perfiles) de cliente hacia el servidor Web 90, el cual las
almacena en la base de datos SSM 98. Tal como se ha indicado
anteriormente, el sistema SSM puede comprender una serie de
componentes del servidor y de cliente.
El servidor SSM 20 usa el protocolo del Servicio
de Usuario de Marcación con Autenticación Remota (RADIUS, RFC2138)
para comunicarse con servidores de autenticación externos. Este
protocolo se transporta a través del protocolo de datagrama de
usuario (UDP).
En algunas formas de realización, el Servidor
SSM 20 es el componente central del sistema SSM, y el único
componente que accede a la base de datos interna o a los servidores
de autenticación externos.
La EGW 22 proporciona servicios de la
Infraestructura de Clave Pública del SSM: la EGW de certificados
(pasarela de inscripción) 22 y certificados para la autenticación
ACU emitidos desde la autoridad de certificación interna 28 del SSM.
Los certificados para la autenticación VPN pueden provenir de la CA
interna 28 del SSM y/o de CA externas. En algunas formas de
realización, únicamente las clases del servidor SSM 20 pueden
acceder directamente a la EGW 22, y otros componentes (por ejemplo,
aplicaciones de gestión, servlets web) acceden a la EGW 22
únicamente a través de las interfaces de gestión del servidor SSM
20.
La EGW 22 usa el servidor SSM 20 para almacenar
sus datos persistentes (por ejemplo, certificados, listas CRL,
etcétera) así como para autentificar y autorizar solicitudes de
inscripción de certificados. El Servidor EGW 22 se comunica con el
servidor SSM 20.
El servidor SSM 20 dispone de una GUI y/o de una
CLI para proporcionar una interfaz de gestión y administración con
funciones de gestión del servidor SSM.
El servidor SSM 20 da a conocer dos interfaces
que se usan para importar políticas, perfiles, y otros contenidos a
distribuir. Cualquier componente de software externo puede usar una
API genérica de actualización de contenido basada en el HTTP. El
servlet HTTP importa el contenido hacia la base de datos 98. El
servidor Web 90 implementa la funcionalidad de usuario final del
SSM. El servidor Web 90 ejecuta también servlets que gestionan el
procesado XML de las solicitudes ACU, reenvían solicitudes HTTP al
Servidor EGW 22 (a través del servidor SSM 20), y proporcionan la
interfaz de importación basada en HTTP.
El servidor Web 90 es un elemento oyente
HTTP(S) para el servidor SSM 20. En por lo menos una de las
formas de realización, este es el único componente del sistema que
está atento a solicitudes provenientes de la red externa.
Los componentes del servidor SSM 20 usan varias
interfaces de red y protocolos para comunicarse entre sí o con
sistemas externos. El servidor EGW 22 y el servidor SSM 20 se pueden
comunicar usando cualquier protocolo adecuado. En una de las formas
de realización, se usa un protocolo de solicitud/respuesta sobre dos
conexiones TCP/IP (una para cada dirección). El protocolo basado en
etiqueta-longitud-valor está cifrado
y ambas partes se autentican por el hecho de que las mismas conocen
la clave secreta que se obtiene a partir del secreto compartido que
se pregunta durante la instalación.
\newpage
El servidor SSM 20 usa, por ejemplo, el
Protocolo Simple de Transferencia de Correo (SMTP) sobre TCP/IP para
enviar notificaciones de correo electrónico a usuarios finales. Para
encaminar mensajes de correo electrónico se usa una pasarela de
correo electrónico.
Tal como se ha indicado, y en por lo menos una
de las formas de realización, todas las solicitudes provenientes de
un cliente VPN de un dispositivo móvil 10, así como las provenientes
del navegador de un usuario final, llegan al servidor Web 90 sobre
HTTP. Estas solicitudes incluyen un navegador web de usuario que
envía solicitudes HTTPS al servidor Web 90, en respuesta a lo cual
el servidor Web 90 proporciona páginas HTML y/o archivos
descargados. Estas conexiones se cifran con SSL; el servidor SSM 20
se autentica basándose en su certificado y el dispositivo móvil se
autentica con un nombre de usuario/contraseña. El servidor Web 90
recibe también solicitudes de inscripción de certificados
provenientes del cliente VPN del dispositivo móvil 10 sobre el
protocolo HTTP. Las solicitudes estás cifradas y firmadas, y se
puede usar una conexión HTTP corriente. El servidor Web 90 recibe
también solicitudes de Actualización Automática de Contenidos (ACU)
provenientes del cliente VPN del dispositivo móvil 10. Estas
solicitudes están cifradas y firmadas; el servidor SSM 20 se
autentica basándose en su certificado y el dispositivo móvil 10 se
autentica con un nombre de usuario/contraseña o un certificado
emitido con este fin.
Las conexiones HTTP de los clientes de la
Internet pública 14 (por ejemplo, el dispositivo 11) pasan a través
de un cortafuegos 18 y/o un proxy/pasarela 24. Una aplicación del
dispositivo 11 puede importar y actualizar políticas del servidor
SSM 20 usando una conexión HTTP cifrado con SSL (HTTPS). El servidor
SSM 20 se autentica basándose en el certificado y el dispositivo 11
se autentica con un nombre de usuario/contraseña, y el usuario
pertenece al grupo de Gestores de Contenido, por ejemplo, cuando la
aplicación de gestión de políticas 26 traslada políticas hacia el
servidor SSM 20. Una vez que se ha conectado al servidor SSM 20, un
usuario (el usuario 11 ó el administrador) puede usar el servidor
SSM 20 según los permisos definidos en el SSM. En una de las formas
de realización, la información de permisos se almacena en la base de
datos 98, incluso para usuarios que se autentiquen en relación con
un servidor de autenticación externo.
La pasarela VPN 24 usa el HTTP para solicitar
Listas de Revocación de Certificados (listas CRL) de la EGW 22 (a
través del servidor Web 90 y el servidor SSM 20). Las CRL son
entidades firmadas que se pueden transportar a través de una
conexión HTTP corriente sin cifrado.
La EGW 22 se puede conectar con Autoridades de
Certificación externas para reenviar solicitudes de certificados a
través del HTTP.
El servidor SSM 20 no se limita a un uso como
herramienta de despliegue de políticas VPN. El servidor SSM 20
soporta el despliegue escalable de una PKI y la distribución segura
de cualquier contenido para usuarios finales autenticados y
autorizados. La generación escalable de datos PKI se puede delegar
en clientes VPN. En tal caso, un usuario recibe una política
genérica (es decir, un perfil) sin datos PKI, y el cliente PVN del
usuario genera los datos PKI antes de usar la política. En
particular, el cliente genera un par de claves pública/privada y una
solicitud correspondiente de inscripción de certificado y envía la
solicitud a una Autoridad de Certificación (CA). A continuación la
CA crea y devuelve el certificado.
Las diferentes características y ventajas de la
presente invención se ponen de manifiesto a partir de la memoria
descriptiva detallada, y por lo tanto, el objetivo de las
reivindicaciones adjuntas es abarcar todas las características y
ventajas de la invención que quedan incluidas dentro del espíritu y
el alcance de la invención. A los expertos en la materia se les
ocurrirán numerosas modificaciones y variaciones, y la invención no
se limita a la construcción y funcionamiento exactos, ilustrados y
descritos en el presente documento. Todas las modificaciones y
equivalentes adecuados a los que pueda recurrirse quedan incluidos
dentro del alcance de las reivindicaciones. La descripción anterior
está destinada a ser ilustrativa y no limitativa. Solamente a título
de ejemplo, la invención se ha descrito haciendo referencia a un
servidor SSM 20; los dispositivos, sistemas y métodos según la
invención podrían incluir (y/o incluir comunicación con) múltiples
servidores SSM 20. La invención incluye además (y/o incluye
comunicación con) servidores y dispositivos que carecen de la
totalidad de las características descritas en relación con el
servidor SSM 20, y/o que contienen características adicionales. Como
ejemplo alternativo, un certificado devuelto se puede validar
basándose en un resumen calculado sobre un mensaje ACU completo
(excepto por el elemento de firma del mensaje ACU) dando como
resultado una primera respuesta de un dispositivo remoto, firmándose
el resumen con una clave privada cuyo titular es el dispositivo
remoto, e incluyéndose el certificado correspondiente en la primera
respuesta y siendo usado por el destinatario para verificar la firma
e identificar y autenticar al emisor. Estas y otras modificaciones
quedan incluidas dentro del alcance de la invención según se define
en las reivindicaciones adjuntas.
Claims (14)
1. Método para efectuar comunicaciones
seguras, que comprende:
- (a)
- conectar un dispositivo de usuario (10) a través de una red públicamente accesible (12) a un servidor (20),
- (b)
- recibir un certificado digital;
- (c)
- calcular un identificador del certificado digital recibido y convertir el identificador en una cadena de caracteres;
- (d)
- modificar la cadena de caracteres eliminando de la cadena de caracteres por lo menos un carácter seleccionado aleatoriamente;
- (e)
- visualizar, para un usuario en el dispositivo de usuario (10), la cadena de caracteres modificada;
- (f)
- recibir, en el dispositivo de usuario (10) y proveniente de un usuario al que se ha proporcionado anteriormente el identificador a través de un medio de confianza, una entrada correspondiente al por lo menos un carácter eliminado; y
- (g)
- continuar con la conexión al servidor (20) únicamente si la entrada del usuario coincide con el por lo menos un carácter eliminado.
2. Método según la reivindicación 1, que
comprende además la selección aleatoria de múltiples caracteres para
su eliminación.
3. Método según la reivindicación 1 ó 2, en
el que el por lo menos un carácter eliminado se sustituye por un
carácter que indica la sustitución.
4. Método según la reivindicación 1 ó 2, en
el que la cadena modificada se visualiza con espacios que sustituyen
a los caracteres eliminados.
5. Método según cualquiera de las
reivindicaciones anteriores, en el que el dispositivo de usuario
(10) es un teléfono móvil y el por lo menos un carácter eliminado es
un dígito.
6. Método según cualquiera de las
reivindicaciones anteriores, en el que la recepción del certificado
digital comprende la recepción del certificado digital desde una
autoridad de certificación (28).
7. Método según cualquiera de las
reivindicaciones anteriores, en el que la posición del por lo menos
un carácter eliminado de la cadena es diferente durante un intento
de conexión subsiguiente.
8. Método según cualquiera de las
reivindicaciones anteriores, en el que el por lo menos un carácter
eliminado se elimina basándose en las capacidades del dispositivo de
usuario (10).
9. Método según cualquiera de las
reivindicaciones anteriores, en el que la recepción de la entrada
correspondiente al por lo menos un carácter eliminado comprende la
recepción de la entrada proveniente de un usuario al que se ha
proporcionado anteriormente el identificador a través de un medio de
entre correo o un boletín informativo de la empresa.
10. Método según la reivindicación 1, en el que
en la etapa (d) se eliminan solamente dígitos.
11. Método según cualquiera de las
reivindicaciones anteriores, que comprende además la repetición de
las etapas (a) a (g) en cada intento de conectar el dispositivo (10)
al servidor (20).
12. Dispositivo de usuario (10) para una
comunicación segura con un servidor (20) a través de una red
públicamente accesible (12), que comprende:
una interfaz con la red públicamente accesible;
y
un procesador configurado para realizar las
etapas que comprenden:
- recibir, a través de la interfaz, un certificado digital proveniente de un servidor ubicado remotamente,
- calcular un identificador del certificado digital recibido y convertir el identificador en una cadena de caracteres,
\newpage
- modificar la cadena de caracteres eliminando de la cadena de caracteres por lo menos un carácter seleccionado aleatoriamente,
- visualizar, para un usuario en el dispositivo de usuario (10), la cadena de caracteres modificada,
- recibir, en el dispositivo de usuario (10) y proveniente de un usuario del dispositivo al que se ha proporcionado anteriormente el identificador a través de un medio de confianza, una entrada correspondiente al por lo menos un carácter eliminado, y
- continuar con la conexión al servidor (20) únicamente si la entrada del usuario coincide con el por lo menos un carácter eliminado.
13. Soporte legible por máquina para almacenar
un programa de ordenador que tiene instrucciones ejecutables por
máquina con vistas a realizar las etapas que comprenden:
- (a)
- conectar un dispositivo de usuario (10) a través de una red públicamente accesible (12) a un servidor (20);
- (b)
- recibir un certificado digital;
- (c)
- calcular un identificador del certificado digital recibido y convertir el identificador en una cadena de caracteres;
- (d)
- modificar la cadena de caracteres eliminando de la cadena de caracteres por lo menos un carácter seleccionado aleatoriamente;
- (e)
- visualizar, para un usuario en el dispositivo de usuario (10), la cadena de caracteres modificada;
- (f)
- recibir, en el dispositivo de usuario (10) y proveniente de un usuario al que se ha proporcionado anteriormente el identificador a través de un medio de confianza, una entrada correspondiente al por lo menos un carácter eliminado; y
- (g)
- continuar con la conexión al servidor (20) únicamente si la entrada del usuario coincide con el por lo menos un carácter eliminado.
14. Método para efectuar comunicaciones
seguras, que comprende:
- (a)
- conectar un dispositivo de usuario (10) a través de una red públicamente accesible (12) a un servidor (20);
- (b)
- recibir un certificado digital;
- (c)
- recibir un identificador modificado, habiéndose calculado previamente el identificador a partir del certificado digital fuera del dispositivo de usuario y habiéndose modificado fuera del dispositivo de usuario (10) mediante la eliminación de por lo menos un carácter seleccionado aleatoriamente;
- (e)
- visualizar, para un usuario en el dispositivo de usuario (10), el identificador modificado;
- (f)
- recibir, en el dispositivo de usuario (10) y proveniente de un usuario al que se ha proporcionado anteriormente el identificador a través de un medio de confianza, una entrada correspondiente al por lo menos un carácter eliminado; y
- (g)
- continuar con la conexión al servidor (20) únicamente si la entrada del usuario coincide con el por lo menos un carácter eliminado.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US608818 | 2003-06-30 | ||
| US10/608,818 US7444508B2 (en) | 2003-06-30 | 2003-06-30 | Method of implementing secure access |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2281760T3 true ES2281760T3 (es) | 2007-10-01 |
Family
ID=33435362
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04253083T Active ES2281760T3 (es) | 2003-06-30 | 2004-05-26 | Metodo y aparato para implementar un acceso vpn seguro a traves de cadenas de certificado modificadas. |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US7444508B2 (es) |
| EP (1) | EP1494428B1 (es) |
| KR (1) | KR20050005763A (es) |
| AT (1) | ATE352163T1 (es) |
| DE (1) | DE602004004325T2 (es) |
| ES (1) | ES2281760T3 (es) |
Families Citing this family (129)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050033829A1 (en) * | 2003-08-04 | 2005-02-10 | Nokia Corporation | System and method for wireless multicast downloading |
| US20050038879A1 (en) * | 2003-08-14 | 2005-02-17 | International Business Machines Corporation | System and method for discovery of remote device driver functionality and interface |
| US10375023B2 (en) * | 2004-02-20 | 2019-08-06 | Nokia Technologies Oy | System, method and computer program product for accessing at least one virtual private network |
| US20060089121A1 (en) * | 2004-10-27 | 2006-04-27 | Hani Elgebaly | Method and apparatus for automatic connecting of virtual private network clients to a network |
| JP4654006B2 (ja) * | 2004-11-16 | 2011-03-16 | パナソニック株式会社 | サーバ装置、携帯端末、通信システム及びプログラム |
| US20060230279A1 (en) * | 2005-03-30 | 2006-10-12 | Morris Robert P | Methods, systems, and computer program products for establishing trusted access to a communication network |
| US20060230278A1 (en) * | 2005-03-30 | 2006-10-12 | Morris Robert P | Methods,systems, and computer program products for determining a trust indication associated with access to a communication network |
| US20070031009A1 (en) * | 2005-04-15 | 2007-02-08 | Julius Mwale | Method and system for string-based biometric authentication |
| US20060265737A1 (en) * | 2005-05-23 | 2006-11-23 | Morris Robert P | Methods, systems, and computer program products for providing trusted access to a communicaiton network based on location |
| US7873994B1 (en) * | 2005-06-27 | 2011-01-18 | Juniper Networks, Inc. | Management of session timeouts in an SSL VPN gateway |
| US8316226B1 (en) * | 2005-09-14 | 2012-11-20 | Juniper Networks, Inc. | Adaptive transition between layer three and layer four network tunnels |
| US8443197B2 (en) * | 2005-09-30 | 2013-05-14 | The Invention Science Fund I, Llc | Voice-capable system and method for authentication using prior entity user interaction |
| JP4829697B2 (ja) * | 2006-06-20 | 2011-12-07 | キヤノン株式会社 | 情報処理装置、情報処理方法、コンピュータプログラム及び記録媒体 |
| KR100810368B1 (ko) * | 2006-07-10 | 2008-03-07 | 주식회사 한글과 컴퓨터 | 그룹 내 문서에 대한 유출 방지 및 접근 제어 시스템 |
| KR101366277B1 (ko) * | 2006-09-07 | 2014-02-20 | 엘지전자 주식회사 | 도메인에서 ｒｏ 이동을 위한 멤버쉽 확인 방법 및 장치 |
| US8104084B2 (en) * | 2006-11-07 | 2012-01-24 | Ricoh Company, Ltd. | Authorizing a user to a device |
| EP1927930A1 (en) * | 2006-11-30 | 2008-06-04 | Sap Ag | Method and system for access control using resouce filters |
| EP1933522B1 (en) | 2006-12-11 | 2013-10-23 | Sap Ag | Method and system for authentication |
| US8412192B2 (en) * | 2007-01-08 | 2013-04-02 | Research In Motion Limited | Apparatus, and associated method, for providing an instance identifier to a network database node of a mobile network |
| WO2008099402A2 (en) * | 2007-02-16 | 2008-08-21 | Forescout Technologies | A method and system for dynamic security using authentication server |
| US8150425B1 (en) * | 2007-03-16 | 2012-04-03 | At&T Mobility Ii Llc | Systems and methods for merchandising new offers to mobile telephone users based on changes to the mobile telephone's components |
| US7974614B1 (en) | 2007-03-16 | 2011-07-05 | At&T Mobility Ii Llc | Systems and methods for merchandising content to a second mobile telephone based on the content of a first mobile telephone |
| US8239548B2 (en) * | 2007-07-17 | 2012-08-07 | Adobe Systems Incorporated | Endpoint discriminator in network transport protocol startup packets |
| US8799648B1 (en) * | 2007-08-15 | 2014-08-05 | Meru Networks | Wireless network controller certification authority |
| US7954145B2 (en) * | 2007-09-27 | 2011-05-31 | Novell, Inc. | Dynamically configuring a client for virtual private network (VPN) access |
| CA2703546A1 (en) | 2007-10-25 | 2009-04-30 | Trilliant Networks, Inc. | Gas meter having ultra-sensitive magnetic material retrofitted onto meter dial and method for performing meter retrofit |
| EP2257884A4 (en) * | 2007-11-25 | 2011-04-20 | Trilliant Networks Inc | SYSTEM AND METHOD FOR TRANSMITTING AND RECEIVING INFORMATION ABOUT A NEIGHBORHOOD ZONAL NETWORK |
| US8171364B2 (en) | 2007-11-25 | 2012-05-01 | Trilliant Networks, Inc. | System and method for power outage and restoration notification in an advanced metering infrastructure network |
| US8332055B2 (en) | 2007-11-25 | 2012-12-11 | Trilliant Networks, Inc. | Energy use control system and method |
| CA2705021A1 (en) * | 2007-11-25 | 2009-05-28 | Trilliant Networks, Inc. | Proxy use within a mesh network |
| US8359580B2 (en) | 2007-12-26 | 2013-01-22 | Visa U.S.A. Inc. | System and method for tracking testing of software modification projects |
| US20090169008A1 (en) * | 2007-12-26 | 2009-07-02 | Gonzales Jesus Orlando Ii | System and method for tracking testing of software modification projects from a wireless mobile device |
| US8171147B1 (en) | 2008-02-20 | 2012-05-01 | Adobe Systems Incorporated | System, method, and/or apparatus for establishing peer-to-peer communication |
| US20090234953A1 (en) * | 2008-03-11 | 2009-09-17 | Palm, Inc. | Apparatus and methods for integration of third party virtual private network solutions |
| US8272039B2 (en) * | 2008-05-02 | 2012-09-18 | International Business Machines Corporation | Pass-through hijack avoidance technique for cascaded authentication |
| US8312147B2 (en) * | 2008-05-13 | 2012-11-13 | Adobe Systems Incorporated | Many-to-one mapping of host identities |
| JP2009278223A (ja) * | 2008-05-13 | 2009-11-26 | Panasonic Corp | 電子証明システム及び秘匿通信システム |
| US8341401B1 (en) | 2008-05-13 | 2012-12-25 | Adobe Systems Incorporated | Interoperable cryptographic peer and server identities |
| US8793757B2 (en) * | 2008-05-27 | 2014-07-29 | Open Invention Network, Llc | User-directed privacy control in a user-centric identity management system |
| US20090307140A1 (en) | 2008-06-06 | 2009-12-10 | Upendra Mardikar | Mobile device over-the-air (ota) registration and point-of-sale (pos) payment |
| DK2144460T3 (en) * | 2008-07-10 | 2016-02-08 | Teliasonera Ab | A method, system, packet data gateway, and computer program for providing connection to the supply of data |
| KR101297519B1 (ko) * | 2008-08-08 | 2013-08-16 | 삼성전자주식회사 | Ｄｃｄ 서비스에서 사용자 콘텐트 제출 방법 및 시스템 |
| US20100064048A1 (en) * | 2008-09-05 | 2010-03-11 | Hoggan Stuart A | Firmware/software validation |
| CN102197632A (zh) * | 2008-10-29 | 2011-09-21 | 杜比实验室特许公司 | 网络互联域和密钥系统 |
| US8826006B2 (en) * | 2008-10-31 | 2014-09-02 | Motorola Solutions, Inc. | Method and device for enabling a trust relationship using an unexpired public key infrastructure (PKI) certificate |
| US8423761B2 (en) * | 2008-10-31 | 2013-04-16 | Motorola Solutions, Inc. | Method and device for enabling a trust relationship using an expired public key infrastructure (PKI) certificate |
| US20100125897A1 (en) * | 2008-11-20 | 2010-05-20 | Rahul Jain | Methods and apparatus for establishing a dynamic virtual private network connection |
| JP5270694B2 (ja) * | 2008-11-28 | 2013-08-21 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 機密ファイルを保護するためのクライアント・コンピュータ、及びそのサーバ・コンピュータ、並びにその方法及びコンピュータ・プログラム |
| US20100138907A1 (en) * | 2008-12-01 | 2010-06-03 | Garret Grajek | Method and system for generating digital certificates and certificate signing requests |
| US8880894B2 (en) * | 2008-12-30 | 2014-11-04 | Motorola Mobility Llc | Public key infrastructure-based first inserted subscriber identity module subsidy lock |
| DE102009009310A1 (de) | 2009-02-17 | 2009-10-01 | Daimler Ag | Kommunikation und Identifizierung zwischen einem Kraftfahrzeugbenutzergerät mit Head Unit und davon entfernt gelegener Vorrichtung |
| US9432356B1 (en) | 2009-05-05 | 2016-08-30 | Amazon Technologies, Inc. | Host identity bootstrapping |
| FR2946209A1 (fr) * | 2009-06-02 | 2010-12-03 | Alcatel Lucent | Procede de protection d'un reseau de telecommunication et routeur securise mettant en oeuvre un tel procede. |
| US20100325424A1 (en) * | 2009-06-19 | 2010-12-23 | Etchegoyen Craig S | System and Method for Secured Communications |
| US8495359B2 (en) * | 2009-06-22 | 2013-07-23 | NetAuthority | System and method for securing an electronic communication |
| US8510806B2 (en) * | 2009-10-22 | 2013-08-13 | Sap Ag | System and method of controlling access to information in a virtual computing environment |
| US8280966B2 (en) * | 2009-10-22 | 2012-10-02 | Sap Ag | System and method of controlling access to information in a virtual computing environment |
| EP2524471B1 (en) * | 2010-01-12 | 2015-03-11 | Visa International Service Association | Anytime validation for verification tokens |
| JP5552870B2 (ja) * | 2010-04-01 | 2014-07-16 | ソニー株式会社 | メモリ装置、ホスト装置、およびメモリシステム |
| US8473734B2 (en) | 2010-06-30 | 2013-06-25 | Juniper Networks, Inc. | Multi-service VPN network client for mobile device having dynamic failover |
| US8474035B2 (en) * | 2010-06-30 | 2013-06-25 | Juniper Networks, Inc. | VPN network client for mobile device having dynamically constructed display for native access to web mail |
| US8127350B2 (en) * | 2010-06-30 | 2012-02-28 | Juniper Networks, Inc. | Multi-service VPN network client for mobile device |
| US8458787B2 (en) * | 2010-06-30 | 2013-06-04 | Juniper Networks, Inc. | VPN network client for mobile device having dynamically translated user home page |
| US10142292B2 (en) | 2010-06-30 | 2018-11-27 | Pulse Secure Llc | Dual-mode multi-service VPN network client for mobile device |
| US8549617B2 (en) * | 2010-06-30 | 2013-10-01 | Juniper Networks, Inc. | Multi-service VPN network client for mobile device having integrated acceleration |
| US8464336B2 (en) | 2010-06-30 | 2013-06-11 | Juniper Networks, Inc. | VPN network client for mobile device having fast reconnect |
| DE102010033231B4 (de) * | 2010-08-03 | 2013-08-22 | Siemens Aktiengesellschaft | Verfahren und Vorrichtung zur manipulationssicheren Bereitstellung eines Schlüssel-Zertifikates |
| DE102010033232A1 (de) | 2010-08-03 | 2012-02-09 | Siemens Aktiengesellschaft | Verfahren und Vorrichtung zum Bereitstellen eines Einmalpasswortes |
| WO2012027634A1 (en) | 2010-08-27 | 2012-03-01 | Trilliant Networkd, Inc. | System and method for interference free operation of co-located tranceivers |
| KR101587003B1 (ko) * | 2010-09-07 | 2016-01-20 | 삼성전자주식회사 | 무선 통신 시스템에서 와이 파이 연결 확인을 위한 장치 및 방법 |
| US8832428B2 (en) | 2010-11-15 | 2014-09-09 | Trilliant Holdings Inc. | System and method for securely communicating across multiple networks using a single radio |
| US8443435B1 (en) | 2010-12-02 | 2013-05-14 | Juniper Networks, Inc. | VPN resource connectivity in large-scale enterprise networks |
| US8650620B2 (en) * | 2010-12-20 | 2014-02-11 | At&T Intellectual Property I, L.P. | Methods and apparatus to control privileges of mobile device applications |
| US9032204B2 (en) * | 2011-01-07 | 2015-05-12 | Mastercard International Incorporated | Methods and systems for providing a signed digital certificate in real time |
| US9083534B2 (en) | 2011-01-07 | 2015-07-14 | Mastercard International Incorporated | Method and system for propagating a client identity |
| WO2012097204A1 (en) | 2011-01-14 | 2012-07-19 | Trilliant Holdings, Inc. | Process, device and system for volt/var optimization |
| WO2012103072A2 (en) | 2011-01-25 | 2012-08-02 | Trilliant Holdings, Inc. | Aggregated real-time power outages/restoration reporting (rtpor) in a secure mesh network |
| EP3429163B1 (en) | 2011-02-10 | 2020-08-19 | Trilliant Holdings, Inc. | Device and method for facilitating secure communications over a cellular network |
| WO2012122310A1 (en) | 2011-03-08 | 2012-09-13 | Trilliant Networks, Inc. | System and method for managing load distribution across a power grid |
| DE102011015711A1 (de) * | 2011-03-31 | 2012-10-04 | Giesecke & Devrient Gmbh | Aktualisierung einer Datenträgerapplikation |
| US8625803B1 (en) * | 2011-05-31 | 2014-01-07 | Google Inc. | Updating shared keys |
| EP2716094A4 (en) | 2011-06-03 | 2014-12-03 | Blackberry Ltd | SYSTEM AND METHOD FOR ACCESSING PRIVATE NETWORKS |
| US8800007B1 (en) | 2011-06-24 | 2014-08-05 | Juniper Networks, Inc. | VPN session migration across clients |
| US9015469B2 (en) * | 2011-07-28 | 2015-04-21 | Cloudflare, Inc. | Supporting secure sessions in a cloud-based proxy service |
| US8898459B2 (en) | 2011-08-31 | 2014-11-25 | At&T Intellectual Property I, L.P. | Policy configuration for mobile device applications |
| US8918841B2 (en) | 2011-08-31 | 2014-12-23 | At&T Intellectual Property I, L.P. | Hardware interface access control for mobile applications |
| US8862767B2 (en) | 2011-09-02 | 2014-10-14 | Ebay Inc. | Secure elements broker (SEB) for application communication channel selector optimization |
| US9001787B1 (en) | 2011-09-20 | 2015-04-07 | Trilliant Networks Inc. | System and method for implementing handover of a hybrid communications module |
| EP2587715B1 (en) | 2011-09-20 | 2017-01-04 | BlackBerry Limited | Assisted certificate enrollment |
| US8842840B2 (en) | 2011-11-03 | 2014-09-23 | Arvind Gidwani | Demand based encryption and key generation and distribution systems and methods |
| EP2600274B1 (en) * | 2011-12-02 | 2019-04-24 | BlackBerry Limited | Method Of Sending A Self-Signed Certificate From A Communication Device |
| US8949954B2 (en) | 2011-12-08 | 2015-02-03 | Uniloc Luxembourg, S.A. | Customer notification program alerting customer-specified network address of unauthorized access attempts to customer account |
| AU2012100460B4 (en) | 2012-01-04 | 2012-11-08 | Uniloc Usa, Inc. | Method and system implementing zone-restricted behavior of a computing device |
| AU2012100462B4 (en) | 2012-02-06 | 2012-11-08 | Uniloc Usa, Inc. | Near field authentication through communication of enclosed content sound waves |
| US9083703B2 (en) * | 2012-03-29 | 2015-07-14 | Lockheed Martin Corporation | Mobile enterprise smartcard authentication |
| CA2838356A1 (en) * | 2012-12-31 | 2014-06-30 | Aastra Technologies Limited | Remote vpn provisioning of an endpoint |
| US9432336B2 (en) | 2013-02-13 | 2016-08-30 | Blackberry Limited | Secure electronic device application connection to an application server |
| AU2013100355B4 (en) | 2013-02-28 | 2013-10-31 | Netauthority, Inc | Device-specific content delivery |
| US8782774B1 (en) | 2013-03-07 | 2014-07-15 | Cloudflare, Inc. | Secure session capability using public-key cryptography without access to the private key |
| US9608962B1 (en) | 2013-07-09 | 2017-03-28 | Pulse Secure, Llc | Application-aware connection for network access client |
| WO2015018436A1 (en) * | 2013-08-06 | 2015-02-12 | Nec Europe Ltd. | Method for operating a network and a network |
| US10348721B2 (en) | 2013-10-30 | 2019-07-09 | Hewlett Packard Enterprise Development Lp | User authentication |
| US9736126B2 (en) * | 2014-12-04 | 2017-08-15 | International Business Machines Corporation | Authenticating mobile applications using policy files |
| WO2016137517A1 (en) * | 2015-02-27 | 2016-09-01 | Hewlett Packard Enterprise Development Lp | Manufacturer-signed digital certificate for identifying a client system |
| CN107079008B (zh) * | 2015-03-27 | 2020-02-21 | 华为技术有限公司 | 用户认证方法、装置及系统 |
| KR101642223B1 (ko) * | 2015-05-12 | 2016-07-22 | 주식회사 수산아이앤티 | 사설 인증서의 설치를 유도하는 방법 |
| FI20155763A (fi) * | 2015-10-26 | 2017-04-27 | Online Solutions Oy | Menetelmä ja järjestelmä sertifikaatin aitouden varmistamiseksi ssl-protokollaa käyttäen salatussa internet-yhteydessä verkkosivuun |
| US10149166B2 (en) | 2016-01-14 | 2018-12-04 | Blackberry Limited | Verifying a certificate |
| KR101729887B1 (ko) * | 2016-01-25 | 2017-04-25 | 엔에이치엔엔터테인먼트 주식회사 | 롱폴링 처리 방법 및 시스템 |
| US10079796B2 (en) | 2016-02-05 | 2018-09-18 | Vaultcast, Inc. | Method and system for secure private multi-party electronic communication |
| US10412048B2 (en) | 2016-02-08 | 2019-09-10 | Cryptzone North America, Inc. | Protecting network devices by a firewall |
| US10270603B2 (en) * | 2016-03-17 | 2019-04-23 | Blackberry Limited | Processing certificate validation warnings |
| US9990222B2 (en) | 2016-03-18 | 2018-06-05 | Airwatch Llc | Enforcing compliance rules against hypervisor and virtual machine using host management component |
| US10142323B2 (en) * | 2016-04-11 | 2018-11-27 | Huawei Technologies Co., Ltd. | Activation of mobile devices in enterprise mobile management |
| US9560015B1 (en) | 2016-04-12 | 2017-01-31 | Cryptzone North America, Inc. | Systems and methods for protecting network devices by a firewall |
| US10749857B2 (en) | 2016-09-26 | 2020-08-18 | Expanse, Inc. | Network mapping using a fingerprint |
| KR101779327B1 (ko) | 2016-11-22 | 2017-10-10 | 한국인터넷진흥원 | 룰 기반 핑거프린트 생성 방법 및 그 장치 |
| US10831838B2 (en) | 2017-03-20 | 2020-11-10 | Expanse, Inc. | Triggered scanning based on network available data change |
| US10749692B2 (en) | 2017-05-05 | 2020-08-18 | Honeywell International Inc. | Automated certificate enrollment for devices in industrial control systems or other systems |
| US10708139B2 (en) * | 2017-08-01 | 2020-07-07 | Servicenow, Inc. | Automatic grouping of similar applications and devices on a network map |
| US11556364B2 (en) * | 2018-09-20 | 2023-01-17 | Cable Television Laboratories, Inc. | Method and apparatus for enabling public key infrastructure in the generic cloud environment and the network function |
| US11139985B2 (en) * | 2018-12-04 | 2021-10-05 | Journey.ai | Receiving information through a zero-knowledge data management network |
| US11451520B2 (en) * | 2019-12-05 | 2022-09-20 | Jonathan Cobb | Private network and application provisioning system |
| US10903990B1 (en) | 2020-03-11 | 2021-01-26 | Cloudflare, Inc. | Establishing a cryptographic tunnel between a first tunnel endpoint and a second tunnel endpoint where a private key used during the tunnel establishment is remotely located from the second tunnel endpoint |
| US11546176B2 (en) * | 2020-08-26 | 2023-01-03 | Rockwell Collins, Inc. | System and method for authentication and cryptographic ignition of remote devices |
| CN114513314B (zh) * | 2022-04-20 | 2022-07-15 | 北京亿赛通科技发展有限责任公司 | 一种数字证书检测方法、装置、电子设备及存储介质 |
| US20240048382A1 (en) * | 2022-08-03 | 2024-02-08 | 1080 Network, Llc | Systems, methods, and computing platforms for executing credential-less network-based communication exchanges |
| CN115834529B (zh) * | 2022-11-23 | 2023-08-08 | 浪潮智慧科技有限公司 | 一种边缘设备远程监测方法及系统 |
| CN116996236B (zh) * | 2023-09-27 | 2023-12-12 | 北京安华金和科技有限公司 | 一种数据库操作认证处理方法和装置 |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU4785096A (en) | 1995-04-27 | 1996-11-18 | Ornella Lo Piano | Method and security system for ensuring the security of a de vice |
| JPH10307799A (ja) | 1997-02-28 | 1998-11-17 | Media Konekuto:Kk | コンピュータ通信網における身元確認方法及び身元確認装置 |
| US6233618B1 (en) | 1998-03-31 | 2001-05-15 | Content Advisor, Inc. | Access control of networked data |
| JP2001036423A (ja) | 1999-05-20 | 2001-02-09 | Yamaha Corp | 番組再生システム及び番組再生方法 |
| US6772331B1 (en) * | 1999-05-21 | 2004-08-03 | International Business Machines Corporation | Method and apparatus for exclusively pairing wireless devices |
| US6853988B1 (en) | 1999-09-20 | 2005-02-08 | Security First Corporation | Cryptographic server with provisions for interoperability between cryptographic systems |
| US6802000B1 (en) * | 1999-10-28 | 2004-10-05 | Xerox Corporation | System for authenticating access to online content referenced in hardcopy documents |
| US7506034B2 (en) * | 2000-03-03 | 2009-03-17 | Intel Corporation | Methods and apparatus for off loading content servers through direct file transfer from a storage center to an end-user |
| US6978364B1 (en) | 2000-04-12 | 2005-12-20 | Microsoft Corporation | VPN enrollment protocol gateway |
| US7028333B2 (en) | 2000-04-12 | 2006-04-11 | Corente, Inc. | Methods and systems for partners in virtual networks |
| US20020124090A1 (en) | 2000-08-18 | 2002-09-05 | Poier Skye M. | Method and apparatus for data communication between a plurality of parties |
| US7103915B2 (en) | 2000-11-13 | 2006-09-05 | Digital Doors, Inc. | Data security system and method |
| US7061874B2 (en) | 2001-01-26 | 2006-06-13 | Broadcom Corporation | Method, system and computer program product for classifying packet flows with a bit mask |
| HU0101106D0 (en) | 2001-03-14 | 2001-05-28 | Tozai Trading Corp | Id alsorithm |
| FI20010596A0 (fi) | 2001-03-22 | 2001-03-22 | Ssh Comm Security Oyj | Turvallisuusjärjestelmä tietoliikenneverkkoa varten |
| MXPA04000611A (es) | 2001-07-18 | 2005-02-17 | Wireless Generation Inc | Sistema y metodo para la evaluacion en la observacion de tiempo real. |
| US7197550B2 (en) | 2001-08-23 | 2007-03-27 | The Directv Group, Inc. | Automated configuration of a virtual private network |
| US20030126085A1 (en) | 2001-12-27 | 2003-07-03 | Slamdunk Networks, Inc. | Dynamic authentication of electronic messages using a reference to a certificate |
| US20030140257A1 (en) | 2002-01-22 | 2003-07-24 | Petr Peterka | Encryption, authentication, and key management for multimedia content pre-encryption |
| EP1475721B1 (en) * | 2002-02-13 | 2013-04-03 | Passlogy Co., Ltd. | User authentication method and user authentication system |
| US7522906B2 (en) | 2002-08-09 | 2009-04-21 | Wavelink Corporation | Mobile unit configuration management for WLANs |
-
2003
- 2003-06-30 US US10/608,818 patent/US7444508B2/en active Active
-
2004
- 2004-05-26 EP EP04253083A patent/EP1494428B1/en active Active
- 2004-05-26 AT AT04253083T patent/ATE352163T1/de not_active IP Right Cessation
- 2004-05-26 ES ES04253083T patent/ES2281760T3/es active Active
- 2004-05-26 DE DE602004004325T patent/DE602004004325T2/de active Active
- 2004-06-16 KR KR1020040044524A patent/KR20050005763A/ko not_active Application Discontinuation
Also Published As
| Publication number | Publication date |
|---|---|
| EP1494428B1 (en) | 2007-01-17 |
| EP1494428A1 (en) | 2005-01-05 |
| DE602004004325D1 (de) | 2007-03-08 |
| US7444508B2 (en) | 2008-10-28 |
| KR20050005763A (ko) | 2005-01-14 |
| DE602004004325T2 (de) | 2007-11-08 |
| ATE352163T1 (de) | 2007-02-15 |
| US20040268142A1 (en) | 2004-12-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2281760T3 (es) | Metodo y aparato para implementar un acceso vpn seguro a traves de cadenas de certificado modificadas. | |
| US7448080B2 (en) | Method for implementing secure corporate communication | |
| USRE45532E1 (en) | Mobile host using a virtual single account client and server system for network access and management | |
| CA2463286C (en) | Multi-factor authentication system | |
| US7961884B2 (en) | Method and system for changing security information in a computer network | |
| US6971005B1 (en) | Mobile host using a virtual single account client and server system for network access and management | |
| Gutzmann | Access control and session management in the HTTP environment | |
| CN109196500B (zh) | 对基于云的服务的基于统一vpn和身份的认证 | |
| US20080072301A1 (en) | System And Method For Managing User Authentication And Service Authorization To Achieve Single-Sign-On To Access Multiple Network Interfaces | |
| US20100138907A1 (en) | Method and system for generating digital certificates and certificate signing requests | |
| EP1993301B1 (en) | Method and apparatus of operating a wireless home area network | |
| MXPA04003226A (es) | Metodo y sistema para proporcionar privacidad al cliente cuando solicite contenido de un servidor publico. | |
| JP2009514072A (ja) | コンピュータ資源への安全なアクセスを提供する方法 | |
| US10523660B1 (en) | Asserting a mobile identity to users and devices in an enterprise authentication system | |
| WO2020020008A1 (zh) | 一种鉴权方法及鉴权系统 | |
| ES2305467T3 (es) | Procedimiento de auto-registro y emision automatizada de certificados digitales y arquitectura de red relacionada que implementa dicho procedimiento. | |
| Hayes | Policy-based authentication and authorization: secure access to the network infrastructure | |
| Szilagyi et al. | Radius: A remote authentication dial-in user service | |
| Halpin | Web Authentication: The next step in the evolving identity eco-system | |
| Harisha et al. | Open Standard Authorization Protocol: OAuth 2.0 Defenses and Working Using Digital Signatures | |
| Goffee | Greenpass Client Tools for Delegated Authorization in Wireless Networks | |
| Ashley et al. | Using SESAME to secure web based applications on an Intranet | |
| Kouril et al. | EXPERIENCE WITH PKI IN A LARGE-SCALE DISTRIBUTED ENVIRONMENT | |
| Nurmi | Analyzing practical communication security of Android vendor applications | |
| Lerner et al. | Interoperable and Scalable Security |