ES2268524T3 - Dispositivo y programa de comunicacion. - Google Patents
Dispositivo y programa de comunicacion. Download PDFInfo
- Publication number
- ES2268524T3 ES2268524T3 ES04007647T ES04007647T ES2268524T3 ES 2268524 T3 ES2268524 T3 ES 2268524T3 ES 04007647 T ES04007647 T ES 04007647T ES 04007647 T ES04007647 T ES 04007647T ES 2268524 T3 ES2268524 T3 ES 2268524T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- file
- adf
- application
- jar
- 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.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- 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/12—Applying verification of the received information
-
- 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/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Stored Programmes (AREA)
- Storage Device Security (AREA)
- Stereo-Broadcasting Methods (AREA)
- Circuits Of Receivers In General (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Un dispositivo de comunicación que comprende: un medio de recepción (16F) para recibir un archivo descriptor de aplicación (ADF) desde un primer nodo (12), conteniendo el archivo descriptor de aplicación (ADF) datos para probar la autenticidad (datos de certificado) y datos (URL) que indican una ubicación de almacenamiento (12) de un archivo de aplicación (Jar), y para recibir un archivo de descripción de seguridad (SDF) desde un segundo nodo (18) que es diferente del primer nodo (12), conteniendo el archivo de descripción de seguridad (SDF) un valor de salida de una función unidireccional (valor de código de comprobación) que opera sobre datos para probar la autenticidad (datos de certificado); un medio de cálculo (16B) para calcular un valor de salida de la función unidireccional (valor de código de comprobación) que opera sobre los datos para probar la autenticidad (datos de certificado) contenidos en el archivo descriptor de aplicación (ADF); y un medio de comparación (16B) para comparar el valor de salida (valor de código de comprobación) de los datos para probar la autenticidad (datos de certificado) contenidos el archivo de descripción de seguridad (SDF) y el valor de salida (valor de código de comprobación) de los datos para probar la autenticidad (datos de certificado) calculados por el medio de cálculo; caracterizado porque el medio de recepción recibe el archivo de aplicación (Jar) desde una ubicación de almacenamiento (12) indicada por los datos que indican la ubicación de almacenamiento (12) del archivo de aplicación (Jar) contenidos en el archivo descriptor de aplicación (ADF) cuando el medio de comparación determina que los valores de salida (valores de código de comprobación) de los datos para probar la autenticidad (datos de certificado) son idénticos entre sí.
Description
Dispositivo y programa de comunicación.
La presente invención se refiere a una
tecnología para determinar la autenticidad de datos descargados.
Comúnmente, el software se descarga a
dispositivos de comunicación a través de redes de comunicación como
Internet, y se usa en esos dispositivos de comunicación. Sin
embargo, tal descarga y uso de software da lugar a un riesgo de
ataques de pirateo de datos, lo cual puede tener como resultado
accesos no autorizados a datos. Si se obtiene acceso no autorizado,
puede descargarse software malicioso al dispositivo de
comunicación.
Para contrarrestar este problema, se ha
desarrollado una diversidad de tecnologías para determinar la
autenticidad del software descargado. Por ejemplo, se ha propuesto
un procedimiento donde, antes de descargar software, un proveedor
del software facilita una tarjeta de circuito integrado (denominada
en lo sucesivo tarjeta "IC") a un usuario, conteniendo la
tarjeta IC un valor de código de comprobación, que permite al
usuario autentificar el software. (Por ejemplo, consúltese la
patente japonesa abierta a consulta por el público Nº
11-205767). Por este procedimiento, cuando un
usuario da instrucciones a un dispositivo de comunicación de
descargar software después de que la tarjeta IC ha sido cargada en
el dispositivo de comunicación, el dispositivo de comunicación
descarga el software y calcula un valor de código de comprobación
del software usando una función de creación de códigos de
comprobación. Después, el dispositivo de comunicación compara el
valor de código de comprobación calculado y el valor de código de
comprobación almacenado en la tarjeta IC para determinar si los
valores coinciden, y por lo tanto si está autorizada la descarga del
software recibido al dispositivo.
Relacionada con el procedimiento descrito
anteriormente está la popularidad de estaciones móviles que son
capaces de descargar software de aplicación Java (marca registrada)
(denominado en lo sucesivo "software Java-AP"),
y de ejecutar un programa de aplicación contenido en el software
Java-AP descargado (el programa de aplicación será
denominado en lo sucesivo "Java-APP").
Cuando se descarga software
Java-AP a tal estación móvil, primero se descarga un
archivo descriptor de aplicación (denominado en lo sucesivo un
"ADF") desde un dispositivo servidor contenido en la World Wide
Web (denominada en lo sucesivo "Web") a la estación móvil, y
después se descarga a la estación móvil un archivo Java Archive
(denominado en lo sucesivo un "archivo JAR") que contiene un
Java-APP.
Debe observarse que en esta memoria descriptiva
el término "software Java-AP" se refiere a una
combinación de un ADF y un archivo JAR. Un problema que afecta a
archivos que comprenden software Java-AP para
descarga a una estación móvil es que pueden estar sujetos a un
ataque malicioso. Por consiguiente, es necesario confirmar, de
antemano, la autenticidad del software que se va a descargar.
Un ADF es un archivo que contiene datos de
información acerca de un archivo JAR correspondiente. Tal
información incluye, por ejemplo, una fecha de cuándo fue
actualizado el archivo JAR. Por lo tanto, para mantener la paridad,
cuando el archivo JAR es actualizado también debe actualizarse el
ADF correspondiente. De esta manera, confirmando la correspondencia
apropiada del archivo JAR pertinente y el ADF, es posible confirmar
la autenticidad del software Java-AP.
Un procedimiento que ha sido propuesto pensando
en este objetivo es el siguiente. En primer lugar, se integran en un
solo archivo un ADF y un archivo JAR que tienen una correspondencia
válida. Después se calcula un valor de código de comprobación del
archivo integrado. El valor de código de comprobación se usa para
determinar si un ADF descargado y un archivo JAR tienen una
correspondencia válida. En el documento de patente anteriormente
mencionado (patente japonesa abierta a consulta por el público Nº
11-205767) se propone un procedimiento similar a
este.
Un Java-APP contenido en un
archivo JAR estará sujeto comúnmente a una diversidad de
modificaciones que son implementadas por un proveedor para corregir
fallos del programa o mejorarlo. Sin embargo, cada vez que se
modifica el Java-APP, cambiará el valor de código de
comprobación del software Java-AP. Como resultado,
se hace necesario para el proveedor del Java-APP,
concretamente un proveedor de contenidos (denominado en lo sucesivo
"CP"), distribuir tarjetas IC que contienen un nuevo valor de
código de comprobación a estaciones móviles en las que ha sido
modificado o mejorado el Java-APP. Sin embargo, la
provisión y distribución de tales tarjetas tras cada modificación y
mejora de un programa tendrían como resultado, obviamente, costes y
problemas logísticos inaceptables, y por lo tanto es poco
realista.
La solicitud de patente europea EP1289326A1
desvela un procedimiento sistemático para confirmar autenticidad de
software descargado. Un remitente transmite a un receptor el
software y el valor de código de comprobación asignado del software.
El receptor comprueba la firma en el valor de código de comprobación
descifrando el valor de código de comprobación firmado usando una
clave pública del remitente. El receptor también calcula un valor de
código de comprobación del software recibido. Por último, el
receptor verifica ese valor de código de comprobación sin firmar y
el valor de código de comprobación calculado para confirmar la
autenticidad del software.
La solicitud de patente europea EP1033652A2
también desvelaba un sistema y procedimiento para confirmar
autenticidad de software descargado. Un servidor transmite a un
terminal un software y el valor de la suma de control firmada del
software. El terminal comprueba entonces el signo en el valor del
signo de control descifrando el valor de código de comprobación
firmado usando una clave pública del servidor. El terminal también
calcula un valor de suma de control del software recibido. El
terminal verifica entonces el valor de suma de control sin firmar y
un valor de signo de control calculado para confirmar la
autenticidad del software.
En vista de esta situación, la presente
invención va dirigida a proporcionar un medio para confirmar la
autenticidad y correspondencia válida de múltiples archivos.
Para solucionar el problema descrito
anteriormente, la presente invención proporciona un dispositivo de
comunicación que comprende: un medio de recepción para recibir (a)
un primer archivo que contiene datos que indican un cierto valor que
se calcula sobre la base de datos de un cierto tipo contenidos en
otro archivo, y (b) un segundo archivo que contiene datos del cierto
tipo; un medio de cálculo para calcular un valor que se obtiene para
asignar los datos del cierto tipo contenidos en el segundo archivo a
una función unidireccional; un medio de comparación para comparar el
valor que es calculado por el medio de cálculo y el cierto valor
indicado por los datos contenidos en el primer archivo; y un medio
de determinación para determinar la validez de correspondencia del
primer archivo y el segundo archivo según un resultado de la
comparación hecha por el medio de comparación.
La presente invención proporciona además un
programa para dar instrucciones a un ordenador para ejecutar: una
etapa de recepción para recibir, (a) un primer archivo que contiene
datos que indican un cierto valor que es calculado sobre la base de
datos de un cierto tipo contenidos en otro archivo, y (b) un segundo
archivo que contiene datos del cierto tipo; una etapa de cálculo
para calcular para calcular un valor que se obtiene para asignar los
datos del cierto tipo contenidos en el segundo archivo a una función
unidireccional; una etapa de comparación para comparar el valor que
es calculado en la etapa de cálculo y el cierto valor indicado por
los datos contenidos en el primer archivo; y una etapa de
determinación para determinar la validez de correspondencia del
primer archivo y el segundo archivo según un resultado de la
comparación hecha en la etapa de comparación.
Según la presente invención, los datos de un
cierto tipo contenidos en el segundo archivo recibido por el medio
de recepción se asignan a una función unidireccional, y un valor
obtenido a partir de la función unidireccional se compara con un
valor indicado por datos contenidos en el primer archivo, que
también es recibido por el medio de recepción. Después, se determina
la autenticidad de una combinación del primer archivo y el segundo
archivo sobre la base de un resultado de la comparación. Por lo
tanto, según la presente invención, puede confirmarse la validez de
correspondencia de archivos plurales que están relacionados entre
sí, como una serie de archivos que comprenden software.
La Fig. 1 es un diagrama de bloques que ilustra
configuraciones de un sistema de descarga según una realización de
la presente invención.
La Fig. 2 es un dibujo conceptual que ilustra
una estructura de datos típica de un ADF usado en el sistema.
La Fig. 3 es un dibujo conceptual que ilustra
una estructura de datos de un SDF almacenado en un dispositivo
servidor de confianza del sistema.
La Fig. 4 es un diagrama de bloques que ilustra
configuraciones de una estación móvil contenida en el sistema.
La Fig. 5 es un dibujo conceptual que ilustra
una estructura funcional de la estación móvil.
La Fig. 6 es un gráfico secuencial que ilustra
flujos de datos en la realización de la presente invención.
La Fig. 7 es un organigrama que ilustra
procedimientos para determinar la autenticidad de archivos
descargados ejecutados en la estación móvil.
En la siguiente descripción se explicará, con
referencia a los dibujos, un sistema de descarga que se realiza
implementando una realización de la presente invención. En los
dibujos, elementos iguales están indicados por números de referencia
iguales.
Según el sistema de descarga, un usuario de una
estación móvil puede dar instrucciones (con seguridad) a la estación
móvil de que descargue software Java-AP deseado,
instale un Java-APP contenido en el software
Java-AP descargado, y ejecute el
Java-APP.
El software Java-AP se descarga
a una estación móvil en el sistema de descarga de la siguiente
manera. En primer lugar, la estación móvil visualiza una explicación
preliminar del software Java-AP para el usuario.
Cuando el usuario da instrucciones a la estación móvil de descargar
el software Java-AP, la estación móvil recibe en
primer lugar un ADF del software Java-AP. Después la
estación móvil recibe un archivo llamado un archivo de descripción
de seguridad (denominado en lo sucesivo "SDF") que corresponde
al software Java-AP. Por último, la estación móvil
recibe un archivo JAR del software Java-AP. Los
archivos SDF contienen datos que indican restricciones de
comportamiento aplicables a Java-APPs
correspondientes que existen en una estación móvil. Por lo tanto,
cuando una estación móvil ejecuta un Java-APP, la
estación móvil controla, sobre la base de condiciones indicadas en
un SDF correspondiente, el comportamiento de una aplicación
proporcionada por el Java-APP.
En esta memoria descriptiva, el término
"aplicación" significa un grupo de funciones que son
proporcionadas por una CPU cuando la CPU ejecuta un programa. En la
siguiente explicación, para describir una situación donde una CPU
ejecuta un Java-APP para proporcionar un grupo de
funciones, concretamente un Java-AP, se usará la
expresión "se realiza un Java-AP". En lo
sucesivo, una aplicación que se realiza mediante un
Java-APP se denomina un Java-AP.
Un SDF es preparado por la empresa telefónica
anteriormente mencionada a la finalización de un contrato
formalizado entre la empresa telefónica y un CP que proporciona el
software Java-AP. En el sistema de descarga en la
presente realización, algunos Java-APPs tienen SDFs
correspondientes, pero otros Java-APPs no tienen
SDFs correspondientes. El comportamiento de un
Java-AP realizado por un Java-APP
que tiene un SDF correspondiente está restringido sobre la base del
SDF. Tales Java-AP y Java-APP se
denominan "Java-AP de confianza" y
"Java-APP de confianza" en esta memoria
descriptiva, ya que la fiabilidad está garantizada por la empresa
telefónica de acuerdo a un contrato formalizado entre la empresa
telefónica y un CP que proporciona el Java-APP.
En la siguiente explicación de la presente
realización, "software Java-AP" puede
significar una combinación de un ADF, un SDF y un archivo JAR cuando
el Java-APP contenido en el archivo JAR es un
Java-APP de confianza, o puede significar una
combinación de un ADF y un archivo JAR cuando el
Java-APP contenido en el archivo JAR no es un
Java-APP de confianza. En esta memoria descriptiva,
un Java-APP que no es un Java-APP de
confianza se denomina un "Java-APP no de
confianza", y una aplicación que se realiza mediante un
Java-APP no de confianza se denomina un
"Java-AP no de confianza". De la misma manera,
en esta memoria descriptiva, el software Java-AP que
contiene un Java-APP de confianza se denomina
"software Java-AP de confianza", y un
Java-AP que contiene un Java-APP no
de confianza se denomina "software Java-AP no de
confianza".
Como se muestra en la Fig. 1, el sistema de
descarga comprende: dispositivo servidor CP 12 conectado a Internet
11; red de comunicación de paquetes móviles 15 a través de la cual
la empresa telefónica proporciona servicios de comunicación de
paquetes móviles a estaciones móviles; estación móvil 16 que
intercambia paquetes de datos con otros dispositivos de comunicación
a través de la red de comunicación de paquetes móviles 15;
dispositivo servidor de pasarela 17 que interconecta Internet 11 y
la red de comunicación de paquetes móviles 15; y dispositivo
servidor de confianza 18 que está conectado al dispositivo servidor
de pasarela 17. Aunque, en la práctica, el sistema de descarga puede
comprender estaciones móviles plurales, en la Fig. 1 sólo se muestra
una estación móvil 16 por simplicidad. Por consiguiente, en la Fig.
1 sólo se muestra un dispositivo servidor CP 12.
En la siguiente descripción, se explican
detalles de cada componente del sistema de descarga.
El dispositivo servidor CP 12 tiene componentes
de hardware y características de un dispositivo servidor Web
general. El dispositivo servidor CP 12 comprende el dispositivo de
disco duro 12A. El dispositivo servidor CP 12 puede establecer una
conexión después del protocolo de control de transmisión (denominado
en lo sucesivo "TCP"), entre el dispositivo servidor CP 12 y un
dispositivo de comunicación. Cuando el dispositivo servidor CP 12
recibe un mensaje de solicitud después de un procedimiento GET de
protocolo de transferencia de hipertexto (denominado en lo sucesivo
"HTTP") usando la conexión TCP, el dispositivo servidor CP 12
lee un archivo identificado por un localizador uniforme de recursos
(denominado en lo sucesivo un "URL") que es asignado al
procedimiento GET desde el dispositivo de disco duro 12A, transmite
un mensaje de respuesta de HTTP que contiene el archivo al
dispositivo de comunicación, y desconecta la conexión TCP.
El dispositivo de disco duro 12A almacena
archivos JAR que contienen programas escritos en lenguaje de
programación Java, y ADFs que contienen datos que indican
información sobre sus archivos JAR correspondientes.
Los ADFs almacenados en el dispositivo servidor
CP 12 están clasificados en ADFs que corresponden a
Java-APPs de confianza, y ADFs que corresponden a
Java-APPs no de confianza. Ambos tipos de ADFs
contienen datos que están contenidos en un ADF normal en la técnica
anterior, como datos que indican un nombre de software
Java-AP, un URL de almacenamiento de JAR que son
datos que indican una ubicación de almacenamiento de un archivo JAR
en la Web, datos que indican un tamaño del archivo JAR, datos que
indican una fecha de la última actualización del archivo JAR,
etcétera. Cada uno de los ADFs que corresponden a software
Java-AP de confianza contiene, como se muestra en la
Fig. 2: APID de confianza que es un identificador asignado a cada
software Java-AP de confianza; datos que indican un
dominio de servidor de confianza que especifica una ubicación de
almacenamiento de un SDF correspondiente en la Web, datos de
certificado que son proporcionados desde una autoridad certificadora
(denominada en lo sucesivo una "CA") a un CP que opera el
dispositivo servidor CP 12; y un valor de código de comprobación JAR
que indica un valor de código de comprobación de un archivo JAR
correspondiente, además de los datos anteriormente mencionados.
Un valor de código de comprobación es un valor
de una longitud fija que se obtiene como salida de una función de
creación de códigos de comprobación cuando se introducen datos
arbitrarios en la función de creación de códigos de comprobación.
Una función de creación de códigos de comprobación es un ejemplo de
una función unidireccional. Una "función unidireccional" es una
función en forma de "y = f(x)", donde y se calcula
rápidamente cuando se da x, pero donde es prácticamente imposible
calcular x cuando se da y, ya que la función no tiene función
inversa, y por lo tanto llevaría una cantidad desmesurada de tiempo
calcular x.
El dispositivo servidor CP 12 tiene una función
para generar y actualizar archivos que contienen los datos
anteriormente mencionados de acuerdo a instrucciones del CP. El
dispositivo de disco duro 12A también almacena datos de certificado,
que son emitidos por una CA, y certifica que el CP está
autentificado por la CA. El dispositivo servidor CP 12 almacena
además un programa para calcular valores de código de comprobación
de archivos JAR y datos de certificado después del algoritmo seguro
de códigos de comprobación 1 (denominado en lo sucesivo
"SHA-1").
El dispositivo servidor pasarela 17 es
administrado por la empresa telefónica anteriormente mencionada, y
tiene componentes de hardware y características de un dispositivo
servidor Web general, dispositivo que interconecta redes de
comunicación. El dispositivo servidor pasarela 17 retransmite datos
entre la red de comunicación de paquetes móviles 15 e Internet
11.
El dispositivo servidor de confianza 18 es
administrado por la empresa telefónica anteriormente mencionada, y
tiene componentes de hardware y características de un dispositivo
servidor Web general. El dispositivo servidor de confianza 18
comprende el dispositivo de disco duro 18A, y después de establecer
una conexión TCP con un dispositivo de comunicación, cuando el
dispositivo servidor de confianza 18 recibe un mensaje de solicitud
después de un procedimiento GET de HTTP usando la conexión TCP, el
dispositivo servidor de confianza 18 lee un archivo identificado por
un URL que se asigna al procedimiento GET desde el dispositivo de
disco duro 18A, transmite un mensaje de respuesta de HTTP que
contiene el archivo al dispositivo de comunicación, y desconecta la
conexión TCP.
El dispositivo de disco duro 18A almacena SDFs,
cada uno de los cuales corresponde a cada uno de los
Java-APPs de confianza.
Un SDF es un archivo realizado por la empresa
telefónica para un Java-APP de confianza. Como se
muestra en la Fig. 3, un SDF contiene: un URL de almacenamiento de
JAR que indica un URL de una ubicación de almacenamiento de un
archivo JAR que contiene el Java-AP de confianza;
una marca de datos de certificado de ADF que indica si un ADF
correspondiente contiene datos de certificado; un valor de código de
comprobación de certificado que indica un valor de código de
comprobación calculado según los datos de certificado contenidos en
el ADF; y datos de permiso que indican interfaces para programas de
aplicación (denominadas en lo sucesivo "APIs") o URLs que un
Java-AP de confianza realizado por el
Java-APP de confianza puede usar o a los que puede
acceder.
Los datos de permiso incluyen "datos de
permiso para acceder a datos personales" que indican si se
permite al Java-AP de confianza usar APIs para
acceder a datos de guía telefónica, datos de correo electrónico no
leído y datos de historial de correo electrónico saliente/entrante,
"datos de permiso para cambiar configuración" que indican si se
permite al Java-AP de confianza usar APIs para
cambiar configuraciones de una melodía o una imagen para notificar
llegadas/transmisiones de correo electrónico, y una imagen para una
pantalla no interactiva, y "datos de permiso para URLs" que
indican URLs a las que se permite acceder al
Java-AP.
Como se muestra en la Fig. 4, la estación móvil
16 comprende: un programa de sistema operativo (OS); un programa de
entorno Java-AP para establecer un entorno para
hacer que puedan funcionar Java-APs; ROM 16A para
almacenar diversas clases de programas como programas de
aplicaciones nativas; CPU 16B para ejecutar programas almacenados en
la ROM 16A; unidad de visualización 16C; memoria no volátil 16D; RAM
16E; unidad de comunicación 16F; y unidad operativa 16G. Estos
componentes de la estación móvil 16 están conectados entre sí por
medio de un bus de datos.
La unidad de visualización 16C comprende, por
ejemplo, un panel de visualización de cristal líquido y un circuito
de excitación de panel, y visualiza imágenes construidas a partir de
datos que son proporcionados por la CPU 16B.
La memoria no volátil 16D es, por ejemplo, una
memoria estática de acceso aleatorio (SRAM) o una memoria de sólo
lectura borrable y programable eléctricamente (EEPROM). El software
Java-AP que se descarga desde dispositivos
servidores contenidos en la Web se almacena en la memoria no volátil
16D. La memoria no volátil 16D también almacena un programa para
calcular valores de código de comprobación después del
SHA-1.
La unidad de comunicación 16F comprende una
antena y una unidad de comunicación inalámbrica; comunica de manera
inalámbrica paquetes de datos con la red de comunicación de paquetes
móviles 15, y retransmite paquetes de datos entre la CPU 16B y la
red de comunicación de paquetes móviles 15. La unidad de
comunicación 16F comprende un CODEC, un micrófono y un altavoz para
comunicación por voz; y permite a la estación móvil 16 mantener
comunicación por voz a través de una red de telefonía móvil (no
mostrada) que tiene un sistema de conmutación de línea.
La unidad operativa 16G comprende hardware como
un teclado para que un usuario introduzca operaciones; y proporciona
a la CPU 16B ciertas señales según las operaciones llevadas a cabo
por el usuario.
En la siguiente descripción, se explican
operaciones de ejemplo del sistema de descarga anteriormente
mencionado.
Cuando se enciende una fuente de alimentación
(no mostrada) de la estación móvil 16, la CPU 16B lee el programa de
OS almacenado en la ROM 16A y ejecuta el programa de OS usando la
RAM 16E como área de trabajo. Después de las instrucciones del
programa de OS, la CPU 16B es capaz de proporcionar varias funciones
básicas como controlar la interfaz de usuario (UI). La Fig. 5
muestra una estructura de un OS que es realizado en la estación
móvil 16 por el programa de OS. El OS especifica instrucciones
proporcionadas por el usuario sobre la base de señales recibidas
desde la unidad operativa 16G según operaciones del usuario, y lleva
a cabo ciertos procedimientos según las instrucciones.
Por ejemplo, cuando el usuario solicita descarga
de software Java-AP, un navegador Web en el OS
transfiere la solicitud a un gestor de aplicaciones Java (denominado
en lo sucesivo un "JAM").
Cuando el usuario solicita la ejecución de un
programa JAM, que es un programa de aplicaciones nativas de la
estación móvil 16, el OS inicia el programa JAM y realiza un JAM en
la estación móvil 16. El JAM visualiza una lista de
Java-APPs instalados en la estación móvil 16, y
cuando el usuario selecciona uno de los Java-APPs
que aparecen en la lista, el JAM inicia el Java-APP
seleccionado. Más concretamente, cuando la estación móvil 16 recibe
del usuario una instrucción para iniciar un cierto
Java-APP, el programa de entorno
Java-AP es iniciado por la CPU 16B, y se establece
un entorno Java-AP en la estación móvil 16. Después,
el Java-APP es iniciado por la CPU 16B usando el
entorno Java-AP, y se proporcionan funciones de un
Java-AP. Un entorno Java-Ap
contiene, por ejemplo, la máquina virtual K (KVM), que es una
máquina virtual Java ligera adaptada a una estación móvil como la
estación móvil 16, y APIs que proporcionan varias funciones para
Java-APs. Las APIs que están preparadas para
Java-APs se clasifican en APIs de confianza que sólo
se permite usar a Java-APs de confianza después de
los datos de permiso contenidos en SDFs, y APIs JAVA no de confianza
que se permite usar a todos los Java-APs.
En esta memoria descriptiva se omiten
explicaciones de operaciones para establecer y desconectar
conexiones TCP, ya que las operaciones siguen un procedimiento bien
conocido de HTTP. En la siguiente explicación, las operaciones que
son ejecutadas por la CPU 16B siguiendo instrucciones de los
programas anteriormente mencionados, como el programa de OS, un
programa navegador Web, un programa JAM, un Java-APP
y un programa de aplicación nativa, se describen como "operaciones
llevadas a cabo por la estación móvil 16" para simplificar la
descripción.
En la siguiente descripción se explican, con
referencia a la Fig. 6, operaciones para el dispositivo servidor CP
12, que es administrado por un CP, para preparar un
Java-APP de confianza.
La empresa telefónica proporciona de antemano al
CP un programa para calcular valores de código de comprobación de
archivos JAR y datos de certificado después del
SHA-1. El programa se denomina en lo sucesivo una
"herramienta". El dispositivo de disco duro 12A del dispositivo
servidor CP 12 almacena la herramienta, así como los datos de
certificado recibidos desde la CA.
El CP prepara un Java-APP para
realizar un Java-AP que sea capaz de cambiar
melodías para notificar llegadas de correo electrónico según números
de teléfono de remitentes de correos electrónicos. El
Java-APP se llama "Melody by Telno Appli". El
CP da instrucciones al dispositivo servidor CP 12 de generar un
archivo JAR que contenga un "Melody by Telno Appli", y de
almacenar el archivo JAR en una ubicación de almacenamiento
identificada por un URL de almacenamiento de
http://www.b.co.jp/melody.jar. Por otra parte, el CP
introduce datos que han de estar contenidos en un ADF, como datos
que indican el nombre del Java-APP "Melody by
Telno Appli" y el URL de almacenamiento de JAR, en el dispositivo
servidor CP 12. Después, el CP da instrucciones al dispositivo
servidor CP 12 de ejecutar la herramienta.
Después de la instrucción del CP, la CPU del
dispositivo servidor CP 12 lee la herramienta almacenada en el
dispositivo de disco duro 12A y, siguiendo las instrucciones de la
herramienta, calcula un valor de código de comprobación del archivo
JAR (denominado en lo sucesivo un "valor de código de comprobación
de JAR") y un valor de código de comprobación de los datos de
certificado (denominado en lo sucesivo un "valor de código de
comprobación de certificado"). Después, la CPU del dispositivo
servidor CP 12 genera un ADF que contiene datos que indican el valor
de código de comprobación de JAR, los datos de certificado, los
datos que indican el nombre del Java-APP "Melody
by Telno Appli", y los datos que indican el URL de almacenamiento
de JAR http://www.b.co.jp/melody.jar.
Después, el dispositivo servidor CP 12
transmite, al dispositivo servidor de confianza 18, el ADF y el
archivo JAR junto con datos que indican el valor de código de
comprobación de certificado (etapa S1).
Cuando la empresa telefónica, que administra el
dispositivo servidor de confianza 18, recibe los archivos y datos
anteriormente mencionados desde el dispositivo servidor CP 12, la
empresa telefónica determina si el CP está autorizado.
Más concretamente, la empresa telefónica
comprueba si los datos de certificado contenidos en el ADF son
emitidos por una CA en la que la empresa telefónica confía, o si los
datos de certificado son emitidos por CAs plurales con una cadena de
certificados válida y las CAs plurales son administradas por una CA
de un nivel superior en la que la empresa telefónica confía.
Después de completar la comprobación de
autenticidad, la empresa telefónica determina la autenticidad del
Java-APP proporcionado por el CP. Más concretamente,
la empresa telefónica revisa descripciones del
Java-APP contenido en el archivo JAR para comprobar
si el Java-AP realizado por el
Java-APP no destruye datos personales almacenados en
la estación móvil 16, no filtra los datos personales a un
dispositivo externo, etcétera.
Después de la inspección del programa, la
empresa telefónica determina APIs que se permite que use el
Java-AP y URLs a las que se permite acceder al
Java-AP, según un resultado de la inspección. La
empresa telefónica introduce después datos que indican las APIs y
URLs al dispositivo servidor de confianza 18.
En respuesta a la entrada, la CPU del
dispositivo servidor de confianza 18 genera un SDF que corresponde
al ADF y al archivo JAR recibidos desde el dispositivo servidor CP
12. El SDF generado por la CPU contiene datos que indican el URL de
almacenamiento de JAR http://www.b.co.jp/melody.jar contenido
en el ADF, una marca de datos de certificado de ADF "SÍ", datos
que indican el valor de código de comprobación de certificado
recibido desde el dispositivo servidor CP 12, y datos de permiso que
indican las APIs y los URLs introducidos por la empresa
telefónica.
Después de generar el ADF, la CPU del
dispositivo servidor de confianza 18 añade datos que indican un APID
de confianza "0001", que identifican el
Java-APP de confianza, y datos que indican un
dominio de servidor de confianza
http://www.a.co.jp/melody.asf, que identifica una ubicación
de almacenamiento del SDF en el dispositivo servidor de confianza
18. Después, la CPU transmite el ADF que contiene los datos
anteriormente mencionados al dispositivo servidor CP 12 (etapa
S2).
La CPU del dispositivo servidor CP 12 recibe el
ADF y almacena el ADF en el dispositivo de disco duro 12A. Después
del almacenamiento del ADF en el dispositivo servidor CP 12, el
archivo JAR que contiene el Java-APP está listo para
ser descargado a la estación móvil 16.
En la siguiente descripción se explicarán, con
referencia a la Fig. 6, operaciones que se ejecutan en el sistema de
descarga cuando el usuario da instrucciones a la estación móvil 16
de descargar software Java-AP.
En la siguiente explicación, se supone que el
ADF y el archivo JAR del software Java-AP que ha de
ser descargado no son modificados después de que el software
Java-AP está preparado, como se explica en la
sección 2-1.
El usuario da instrucciones a la estación móvil
16 de descargar el Java-APP de confianza "Melody
by Telno Appli" desde el dispositivo servidor CP 12 a la estación
móvil 16 usando la unidad operativa 16G.
Cuando la CPU 16B recibe la instrucción
realizada por el usuario para descargar el software
Java-Ap de confianza a través del navegador Web, la
CPU 16B lleva a cabo una serie de procedimientos para descargar el
Java-AP de confianza a la estación móvil 16 de la
siguiente manera.
En primer lugar, la CPU 16B recibe el ADF que
corresponde al Java-APP desde el dispositivo
servidor CP 12. Más concretamente, la CPU 16B establece una conexión
TCP con el dispositivo servidor CP 12, genera un mensaje de
solicitud para transmitir el ADF, y transmite el mensaje de
solicitud al dispositivo servidor CP 12 (etapa S3). La CPU 16B
recibe un mensaje de respuesta que contiene el ADF en respuesta al
mensaje de solicitud (etapa S4), y desconecta la conexión TCP.
Después de recibir el mensaje de respuesta, la CPU 16B almacena el
ADF contenido en el mensaje de respuesta en la memoria no volátil
16D.
Después, la CPU 16B determina si el
Java-APP que ha de ser descargado es un
Java-APP de confianza. Más concretamente, la CPU 16B
comprueba si el ADF contiene datos que indican un APID de confianza,
y cuando el ADF contiene los datos, la CPU 16B determina que el
Java-APP es un Java-APP de
confianza, ya que los datos indican que existe un SDF que
corresponde al Java-APP. Por otra parte, cuando el
ADF no contiene los datos, la CPU 16B determina que el
Java-APP es un Java-APP no de
confianza.
En un caso en que el Java-APP
que ha de ser descargado es un Java-APP no de
confianza, la estación móvil 16 descarga el archivo JAR desde una
ubicación de almacenamiento, que es identificada por los datos que
indican el URL de almacenamiento de JAR contenido en el ADF,
siguiendo los mismos procedimientos que se llevan a cabo en un
sistema de descarga normal en la técnica anterior.
En este caso de ejemplo, como el ADF contiene
datos que indican el APID de confianza "0001", la CPU 16B
determina que el Java-APP que ha de ser descargado
es un Java-APP de confianza. Por consiguiente, la
CPU 16B recibe el SDF que corresponde al Java-APP
desde una ubicación de almacenamiento identificada por los datos que
indican el dominio de servidor de confianza
http://www.a.co.jp/melody.sdf. Más concretamente, la CPU 16B
establece una conexión TCP con el dispositivo servidor de confianza
18, genera un mensaje de solicitud para transmitir el SDF, que es
identificado por el dominio de servidor de confianza
http://www.a.co.jp/melody.sdf indicado por los datos
contenidos en el ADF, y transmite el mensaje de solicitud usando la
conexión TCP (etapa S5). La CPU 16B recibe un mensaje de respuesta
que contiene el SDF en respuesta al mensaje de solicitud (etapa S6),
y desconecta la conexión TCP.
En la siguiente descripción se explicarán, con
referencia a la Fig. 7, operaciones para determinar la autenticidad
del software Java-AP de confianza después de
descargar el software Java-AP de confianza.
La CPU 16B determina si el ADF contiene datos de
certificado (etapa S101). Más concretamente, la CPU 16B comprueba si
el ADF contiene marca de datos de certificado de ADF que indique
"SÍ". Cuando la CPU 16B determina que el ADF no contiene datos
de certificado (etapa S101; No), la CPU 16B se salta los
procedimientos para revisar datos de certificado, y pasa a
procedimientos para descargar el archivo JAR (etapa S104).
En este caso de ejemplo, como el ADF contiene
los datos de marca de certificado de ADF que indican "SÍ", la
CPU 16B determina que el ADF contiene datos de certificado (etapa
S101; Sí), y calcula un valor de código de comprobación de los datos
de certificado contenidos en el ADF (etapa S102).
Después de calcular el valor de código de
comprobación, la CPU 16B compara el valor de código de comprobación
calculado y el valor de código de comprobación contenido en el SDF
para determinar si son idénticos entre sí (etapa S103). Si los
valores de código de comprobación no son idénticos entre sí (etapa
S103; N0), existe una posibilidad de que los datos de certificado
contenidos en el ADF hayan sido modificados por alguien después de
que la empresa telefónica preparara el SDF. Por lo tanto, la CPU 16B
notifica un fallo de descarga al usuario, borra el ADF, restaura
configuraciones de software en la estación móvil 16 en un estado
antes de que fuera descargado el ADF (etapa S107), y pone fin a los
procedimientos para descargar el software
Java-AP.
En este caso de ejemplo, se determina que los
valores de código de comprobación son idénticos entre sí (etapa
S103; Sí), y la CPU 16B descarga el archivo JAR a la estación móvil
16 (etapa S104). Más concretamente, la CPU 16B establece una
conexión TCP con el dispositivo servidor CP 12 usando el URL de
almacenamiento de JAR http://www.b.co.jp/melody.jar que está
contenido en el ADF, e indica una ubicación de almacenamiento en el
dispositivo servidor CP 12 donde se almacena el archivo JAR, genera
un mensaje de solicitud para transmitir el archivo JAR, y transmite
el mensaje de solicitud al dispositivo servidor CP 12 (etapa S7 en
la Fig. 6). La CPU 16B recibe un mensaje de respuesta que contiene
el archivo JAR desde el dispositivo servidor CP 12 en respuesta al
mensaje de solicitud (etapa S8 en la Fig. 6), y desconecta la
conexión TCP.
Después de recibir el mensaje de respuesta, la
CPU 16B calcula un valor de código de comprobación del archivo JAR
contenido en el mensaje de respuesta (etapa S105). La CPU 16B
compara el valor de código de comprobación calculado y el valor de
código de comprobación de JAR contenido en el ADF para determinar si
son idénticos entre sí (etapa S106). Cuando los valores de código de
comprobación no son idénticos entre sí (etapa S106; No), existe una
posibilidad de que el archivo JAR haya sido falsificado o modificado
después de que fuera preparado el archivo JAR. Por lo tanto, la CPU
16B notifica un fallo de descarga al usuario, borra el ADF y el
archivo JAR, restaura configuraciones de software en la estación
móvil 16 a un estado antes de que fuera descargado el ADF (etapa
S108), y pone fin a los procedimientos para descargar el software
Java-AP.
En este caso de ejemplo, los valores de código
de comprobación son idénticos entre sí (etapa S106; Sí). Por
consiguiente, la CPU 16B notifica al usuario que el software
Java-AP fue descargado con éxito, almacena el
archivo JAR recibido y el SDF recibido en la memoria no volátil 16D
(etapa S109), y completa el procedimiento para descargar el software
Java-AP.
Después de completar los procedimientos de
descarga para el software Java-AP de confianza, la
CPU 16B monitoriza el comportamiento de un software
Java-AP de confianza realizado por el
Java-APP de confianza contenido en el archivo JAR, y
permite o restringe el uso por parte del Java-AP de
APIs para acceder a datos personales como los datos de la guía
telefónica y para cambiar configuraciones de la estación móvil 16, y
acceso a URLs, según los datos de permiso para acceder a datos
personales, los datos de permiso para cambiar la configuración, y
los datos de permiso para URLs, respectivamente, que están
contenidos en el SDF.
Como se explicó anteriormente, según la presente
realización, es posible determinar si los datos de certificado que
están contenidos en un ADF han sido modificados después de que la
empresa telefónica ha determinado la autenticidad de los datos de
certificado, verificando que un valor de código de comprobación, que
se calcula usando los datos de certificado contenidos en el ADF, y
un valor de código de comprobación calculado de antemano usando los
datos de certificado y contenidos en un SDF correspondiente, son
idénticos entre sí. En resumen, según la presente realización, se
determina la autenticidad de una combinación de un SDF y un ADF.
Cuando los datos de certificado en el ADF se
sobrescriben con los mismos datos de certificado que los contenidos
en el SDF, los valores de código de comprobación de ambos datos de
certificado se hacen idénticos, y la combinación del SDF y el ADF se
determina como autentificada, aun cuando el ADF sea modificado
después de que fuera preparado el SDF. Por consiguiente, si el CP
tiene que modificar el ADF para modificar el archivo JAR para el
propósito, por ejemplo, de corregir fallos en el archivo JAR,
después de que la empresa telefónica determina la autenticidad de
los datos de certificado, el CP puede mantener la autenticidad de la
combinación entre el SDF y el ADF sobre la base de los mismos datos
de certificado en el ADF modificado que se usan en el ADF original.
Por lo tanto, la empresa telefónica no tiene que repetir operaciones
para determinar la autenticidad de los datos de certificado cuando
el ADF es modificado por el CP.
Por otra parte, según la presente realización,
es posible determinar si un archivo JAR que es descargado desde un
CP ha sido modificado o falsificado después de que la empresa
telefónica determina la autenticidad del archivo JAR, verificando
que un valor de código de comprobación que se calcula usando el
archivo JAR descargado y un valor de código de comprobación que fue
calculado de antemano usando el archivo JAR y estaba contenido en un
ADF correspondiente son idénticos entre sí. En resumen, según la
presente realización, se determina la autenticidad de una
combinación de un archivo JAR y un ADF. Por consiguiente, puede
prevenirse el uso de un archivo JAR falsificado en la estación móvil
16.
Por otra parte, según la presente realización,
no hay necesidad de distribuir de antemano a cada estación móvil un
medio de grabación como una tarjeta IC que contenga un valor de
código de comprobación.
Por consiguiente, en el sistema de descarga
según la presente realización, puede determinarse fácilmente la
autenticidad de combinaciones de ADFs, SDFs y archivos JAR.
Como los procedimientos para calcular un valor
de código de comprobación requieren muchos menos recursos de cálculo
que para calcular una clave pública usada en sistemas de
autentificación convencionales, la presente realización puede
adoptarse para uso con un dispositivo cuyos recursos de cálculo son
limitados, como una estación móvil.
La presente invención no está limitada a la
realización descrita anteriormente, y puede modificarse dentro del
alcance técnico de la presente invención. A continuación se dan
ejemplos de tales modificaciones.
(1) En la realización anterior, un SDF contiene
un valor de código de comprobación de datos de certificado, que está
contenido en un ADF que corresponde al SDF, y la estación móvil 16
determina la autenticidad de una combinación del SDF y el ADF
comparando un valor de código de comprobación calculado mediante el
uso de los datos de certificado contenidos en el ADF, y el valor de
código de comprobación contenido en el SDF. Un valor de código de
comprobación usado en el sistema de descarga no está limitado a un
valor de código de comprobación de datos de certificado, y para el
mismo propósito también puede usarse un valor de código de
comprobación de otro tipo de datos contenidos en un ADF, o un valor
de código de comprobación de todo el ADF.
Por otra parte, en la realización anterior, un
ADF contiene un valor de código de comprobación de un archivo JAR
correspondiente, una estación móvil 16 determina la autenticidad de
una combinación del ADF y el archivo JAR comparando un valor de
código de comprobación calculado mediante el uso del archivo JAR y
el valor de código de comprobación contenido en el ADF. Un valor de
código de comprobación usado en el sistema de descarga no está
limitado a un valor de código de comprobación de todo el archivo
JAR, y para el mismo propósito también puede usarse un valor de
código de comprobación de una parte del archivo JAR.
(2) En la realización anterior, se usan
funciones de creación de códigos de comprobación que usan
SHA-1 para calcular valores de código de
comprobación para determinar la autenticidad de combinaciones de
archivos. Sin embargo, también pueden usarse otras clases de
funciones de creación de códigos de comprobación en el sistema de
descarga. Por ejemplo, también se adoptan funciones de creación de
códigos de comprobación que usan Message Digest 5 (MD5) para el
sistema de descarga según la presente invención. Por otra parte,
pueden usarse todas las demás clases de funciones unidireccionales
en el sistema de descarga, en lugar de las funciones de creación de
códigos de comprobación.
(3) En la realización anterior, los programas
para determinar la autenticidad de archivos se almacenan en una ROM
de una estación móvil. Los programas pueden almacenarse en cualquier
otra clase de dispositivos de almacenamiento como una EEPROM de una
estación móvil. Cuando los programas se almacenan en un dispositivo
de almacenamiento regrabable como una EEPROM, los programas pueden
ser descargados a la estación móvil desde un dispositivo externo a
través de la red de comunicación móvil, y almacenados en el
dispositivo de almacenamiento regrabable. Cuando la estación móvil
tiene una interfaz para comunicarse con un dispositivo de
almacenamiento externo, los programas pueden proporcionarse a la
estación móvil conectando a la estación móvil un dispositivo de
almacenamiento externo como una tarjeta de memoria que contiene los
programas. En este caso, la estación móvil puede leer los programas
directamente del dispositivo de almacenamiento externo y
ejecutarlos.
(4) En la realización explicada anteriormente,
un ADF contiene datos que indican un dominio de servidor de
confianza, y un SDF, que corresponde a un Java-APP
de confianza que ha de ser descargado a una estación móvil, es
identificado sobre la base de los datos. Un SDF puede ser
identificado de otras maneras. Por ejemplo, la estación móvil 16
puede obtener datos que indican un URL para identificar de antemano
el dispositivo servidor de confianza 18, y cuando la estación móvil
16 genera un mensaje de solicitud para transmitir el SDF desde el
dispositivo servidor de confianza 18 a la estación móvil 16, la
estación móvil 16 puede añadir al mensaje de solicitud el URL que
identifica el dispositivo servidor de confianza 18 y datos que
indican un APID de confianza para identificar el SDF que corresponde
al software Java-AP de confianza que ha de ser
descargado.
Claims (6)
1. Un dispositivo de comunicación que
comprende:
un medio de recepción (16F) para recibir un
archivo descriptor de aplicación (ADF) desde un primer nodo (12),
conteniendo el archivo descriptor de aplicación (ADF) datos para
probar la autenticidad (datos de certificado) y datos (URL) que
indican una ubicación de almacenamiento (12) de un archivo de
aplicación (Jar), y para recibir un archivo de descripción de
seguridad (SDF) desde un segundo nodo (18) que es diferente del
primer nodo (12), conteniendo el archivo de descripción de seguridad
(SDF) un valor de salida de una función unidireccional (valor de
código de comprobación) que opera sobre datos para probar la
autenticidad (datos de certificado);
un medio de cálculo (16B) para calcular un valor
de salida de la función unidireccional (valor de código de
comprobación) que opera sobre los datos para probar la autenticidad
(datos de certificado) contenidos en el archivo descriptor de
aplicación (ADF); y
un medio de comparación (16B) para comparar el
valor de salida (valor de código de comprobación) de los datos para
probar la autenticidad (datos de certificado) contenidos el archivo
de descripción de seguridad (SDF) y el valor de salida (valor de
código de comprobación) de los datos para probar la autenticidad
(datos de certificado) calculados por el medio de cálculo;
caracterizado porque
el medio de recepción recibe el archivo de
aplicación (Jar) desde una ubicación de almacenamiento (12) indicada
por los datos que indican la ubicación de almacenamiento (12) del
archivo de aplicación (Jar) contenidos en el archivo descriptor de
aplicación (ADF) cuando el medio de comparación determina que los
valores de salida (valores de código de comprobación) de los datos
para probar la autenticidad (datos de certificado) son idénticos
entre sí.
2. El dispositivo de comunicación según la
reivindicación 1, que además comprende un medio de control (16B)
para llevar a cabo procedimientos según instrucciones descritas en
un archivo de aplicación (Jar), en el que:
el archivo descriptor de aplicación (ADF)
contiene un valor de salida de una función unidireccional (valor de
código de comprobación) que opera sobre todo o una cierta parte de
un archivo de aplicación (Jar),
el medio de cálculo calcula un valor de salida
de la función unidireccional (valor de código de comprobación) que
opera sobre todo o una cierta parte del archivo de aplicación (Jar)
recibido por el medio de recepción,
el medio de comparación compara el valor de
salida (valor de código de comprobación) del archivo de aplicación
(Jar) contenido en el archivo descriptor de aplicación (ADF) y el
valor de salida (valor de código de comprobación) del archivo de
aplicación (Jar) calculado por el medio de cálculo, y
el medio de control lleva a cabo procedimientos
según instrucciones descritas en el archivo de aplicación (Jar)
recibido por el medio de recepción cuando el medio de comparación
determina que los valores de salida (valores de código de
comprobación) del archivo de aplicación (Jar) son idénticos entre
sí.
3. El dispositivo de comunicación según la
reivindicación 1, en el que:
el archivo descriptor de aplicación (ADF)
contiene datos (URL) que indican una ubicación de almacenamiento
(18) del archivo de descripción de seguridad (SDF), y
el medio de recepción recibe el archivo de
descripción de seguridad (SDF) desde el segundo nodo (18) indicado
por los datos que indican la ubicación de almacenamiento (18) del
archivo de descripción de seguridad (SDF) contenido en el archivo
descriptor de aplicación (ADF).
4. El dispositivo de comunicación según la
reivindicación 1, en el que:
los datos para probar la autenticidad son datos
de certificado obtenidos desde un tercer nodo (CA) que es diferente
del primer y segundo nodos.
5. El dispositivo de comunicación según la
reivindicación 1, que además comprende un medio de control (16B)
para llevar a cabo procedimientos según instrucciones descritas en
un archivo de aplicación (Jar), en el que:
el archivo de descripción de seguridad (SDF)
contiene datos (datos de permiso) para indicar permisos para
procedimientos que se han de llevar a cabo según instrucciones
descritas en el archivo de aplicación (Jar) recibido por el medio de
recepción, y
el medio de control lleva a cabo procedimientos
según instrucciones los cuales se indica que son permitidos por los
datos para indicar permisos (datos de permiso).
6. Un medio de grabación que puede ser leído por
un ordenador que graba un programa para hacer que un ordenador
ejecute:
recibir un archivo descriptor de aplicación
(ADF) desde un primer nodo (12), conteniendo el archivo descriptor
de aplicación (ADF) datos para probar la autenticidad (datos de
certificado) y datos (URL) que indican una ubicación de
almacenamiento (12) de un archivo de aplicación (Jar);
recibir un archivo de descripción de seguridad
(SDF) desde un segundo nodo (18) que es diferente del primer nodo
(12), conteniendo el archivo de descripción de seguridad (SDF) un
valor de salida de una función unidireccional (valor de código de
comprobación) que opera sobre datos para probar la autenticidad
(datos de certificado);
calcular un valor de salida de la función
unidireccional (valor de código de comprobación) que opera sobre los
datos para probar la autenticidad (datos de certificado) contenidos
en el archivo descriptor de aplicación (ADF);
comparar el valor de salida (valor de código de
comprobación) de los datos para probar la autenticidad (datos de
certificado) contenidos en el archivo de descripción de seguridad
(SDF) y el valor de salida (valor de código de comprobación) de los
datos para probar la autenticidad (datos de certificado) calculado
por el medio de cálculo;
caracterizado por
recibir el archivo de aplicación (Jar) desde una
ubicación de almacenamiento (12) indicada por los datos que indican
la ubicación de almacenamiento (12) del archivo de aplicación (Jar)
contenido en el archivo descriptor de aplicación (ADF) cuando un
resultado de la comparación indica que los valores de salida
(valores de código de comprobación) de los datos para probar la
autenticidad (datos de certificado) son idénticos entre sí.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003-96088 | 2003-03-31 | ||
| JP2003096088A JP4176533B2 (ja) | 2003-03-31 | 2003-03-31 | 端末装置及びプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2268524T3 true ES2268524T3 (es) | 2007-03-16 |
Family
ID=32844639
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04007647T Expired - Lifetime ES2268524T3 (es) | 2003-03-31 | 2004-03-30 | Dispositivo y programa de comunicacion. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7558963B2 (es) |
| EP (1) | EP1465383B8 (es) |
| JP (1) | JP4176533B2 (es) |
| CN (1) | CN1272953C (es) |
| AT (1) | ATE335344T1 (es) |
| DE (1) | DE602004001704T2 (es) |
| ES (1) | ES2268524T3 (es) |
| TW (1) | TWI265708B (es) |
Families Citing this family (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003202929A (ja) * | 2002-01-08 | 2003-07-18 | Ntt Docomo Inc | 配信方法および配信システム |
| EP1491996B1 (en) * | 2002-04-03 | 2014-02-12 | NTT DoCoMo, Inc. | Distribution method, distribution system, and terminal device |
| EP1783580A4 (en) * | 2004-08-12 | 2011-03-23 | Fujitsu Ltd | JAVA APPLET, JAR FILE GENERATION PROCESS, JAR FILE GENERATION PROGRAM, AND JAR FILE GENERATION DEVICE |
| US20060107327A1 (en) * | 2004-11-16 | 2006-05-18 | Sprigg Stephen A | Methods and apparatus for enforcing application level restrictions on local and remote content |
| CN101019106B (zh) * | 2005-02-14 | 2010-04-14 | 松下电器产业株式会社 | 应用程序执行装置、管理方法和程序 |
| US8316446B1 (en) * | 2005-04-22 | 2012-11-20 | Blue Coat Systems, Inc. | Methods and apparatus for blocking unwanted software downloads |
| US7389426B2 (en) * | 2005-11-29 | 2008-06-17 | Research In Motion Limited | Mobile software terminal identifier |
| KR20090007954A (ko) * | 2007-07-16 | 2009-01-21 | 삼성전자주식회사 | Ｄｒｍ 컨텐츠 다운로드 방법 및 시스템 |
| JP4998314B2 (ja) * | 2008-02-19 | 2012-08-15 | コニカミノルタホールディングス株式会社 | 通信制御方法および通信制御プログラム |
| US9356991B2 (en) * | 2010-05-10 | 2016-05-31 | Litera Technology Llc | Systems and methods for a bidirectional multi-function communication module |
| JP2012018657A (ja) * | 2010-06-11 | 2012-01-26 | Nintendo Co Ltd | 情報処理端末、情報処理システム、情報処理プログラム |
| JP5132730B2 (ja) * | 2010-07-20 | 2013-01-30 | 株式会社エヌ・ティ・ティ・ドコモ | 配信方法および配信システム |
| JP5977018B2 (ja) * | 2011-11-14 | 2016-08-24 | ノキア テクノロジーズ オサケユイチア | 複数のコンフィギュレーションを有する装置内におけるコンフィギュレーションの使用法 |
| JP5952175B2 (ja) * | 2012-11-27 | 2016-07-13 | 日本電信電話株式会社 | 制御装置、制御システム、制御方法および制御プログラム |
| CN109040032B (zh) * | 2013-11-15 | 2021-02-23 | 华为终端有限公司 | 一种网络访问控制方法及装置 |
| KR20160006925A (ko) * | 2014-07-10 | 2016-01-20 | 한국전자통신연구원 | 앱 무결성 검증 장치 및 그 방법 |
| GB2558485A (en) * | 2016-05-13 | 2018-07-11 | Nchain Holdings Ltd | A method and system for verifying integrity of a digital asset using a distributed hash table and a peer-to-peer distributed ledger |
| US9967096B2 (en) | 2016-05-23 | 2018-05-08 | Accenture Global Solutions Limited | Rewritable blockchain |
| CN110023944B (zh) * | 2017-01-03 | 2021-12-28 | 华为技术有限公司 | 通信方法及终端设备、核心网设备 |
Family Cites Families (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6345288B1 (en) | 1989-08-31 | 2002-02-05 | Onename Corporation | Computer-based communication system and method using metadata defining a control-structure |
| JPH07230380A (ja) | 1994-02-15 | 1995-08-29 | Internatl Business Mach Corp <Ibm> | 適用業務プログラムの利用管理方法およびシステム |
| US5708709A (en) * | 1995-12-08 | 1998-01-13 | Sun Microsystems, Inc. | System and method for managing try-and-buy usage of application programs |
| US5825877A (en) | 1996-06-11 | 1998-10-20 | International Business Machines Corporation | Support for portable trusted software |
| TW313642B (en) | 1996-06-11 | 1997-08-21 | Ibm | A uniform mechanism for using signed content |
| US6167520A (en) | 1996-11-08 | 2000-12-26 | Finjan Software, Inc. | System and method for protecting a client during runtime from hostile downloadables |
| US6317742B1 (en) | 1997-01-09 | 2001-11-13 | Sun Microsystems, Inc. | Method and apparatus for controlling software access to system resources |
| JPH11205767A (ja) | 1998-01-16 | 1999-07-30 | Sony Corp | 受信装置及びデータ書換え方法 |
| WO2000042498A1 (en) | 1999-01-13 | 2000-07-20 | Hitachi, Ltd. | Method and system for executing mobile code |
| FI990461A7 (fi) * | 1999-03-03 | 2000-10-20 | Nokia Corp | Menetelmä ohjelmiston lataamiseksi palvelimelta päätelaitteeseen |
| US6976165B1 (en) | 1999-09-07 | 2005-12-13 | Emc Corporation | System and method for secure storage, transfer and retrieval of content addressable information |
| JP2001117769A (ja) | 1999-10-20 | 2001-04-27 | Matsushita Electric Ind Co Ltd | プログラム実行装置 |
| IL139327A (en) | 1999-11-22 | 2005-06-19 | Sun Microsystems Inc | Mechanism for determining restrictions to impose on an implementation of a service |
| JP3740931B2 (ja) | 2000-03-01 | 2006-02-01 | 日本電信電話株式会社 | アプリケーションプログラム管理方法及びシステム及びコンピュータ読み取り可能な記録媒体 |
| EP1132796A1 (en) | 2000-03-08 | 2001-09-12 | Universite Catholique De Louvain | Mobile code and method for resource management for mobile code |
| US6971016B1 (en) | 2000-05-31 | 2005-11-29 | International Business Machines Corporation | Authenticated access to storage area network |
| US6766353B1 (en) | 2000-07-11 | 2004-07-20 | Motorola, Inc. | Method for authenticating a JAVA archive (JAR) for portable devices |
| JP2002182983A (ja) * | 2000-12-13 | 2002-06-28 | Sharp Corp | データベースへのアクセス制御方法、データベース装置、リソースへのアクセス制御方法、情報処理装置 |
| JP2003050641A (ja) | 2001-08-07 | 2003-02-21 | Nec Corp | プログラム管理システム、そのプログラム管理方法、及び情報管理プログラム |
| EP1289326A1 (en) * | 2001-08-30 | 2003-03-05 | Motorola, Inc. | Method of verifying downloaded software and corresponding device |
| US7003672B2 (en) * | 2001-09-25 | 2006-02-21 | Hewlett-Packard Development Company, L.P. | Authentication and verification for use of software |
| JP4145118B2 (ja) * | 2001-11-26 | 2008-09-03 | 松下電器産業株式会社 | アプリケーション認証システム |
| JP2003202929A (ja) | 2002-01-08 | 2003-07-18 | Ntt Docomo Inc | 配信方法および配信システム |
| EP1491996B1 (en) | 2002-04-03 | 2014-02-12 | NTT DoCoMo, Inc. | Distribution method, distribution system, and terminal device |
-
2003
- 2003-03-31 JP JP2003096088A patent/JP4176533B2/ja not_active Expired - Fee Related
-
2004
- 2004-03-30 TW TW093108750A patent/TWI265708B/zh not_active IP Right Cessation
- 2004-03-30 EP EP04007647A patent/EP1465383B8/en not_active Expired - Lifetime
- 2004-03-30 ES ES04007647T patent/ES2268524T3/es not_active Expired - Lifetime
- 2004-03-30 DE DE602004001704T patent/DE602004001704T2/de not_active Expired - Lifetime
- 2004-03-30 AT AT04007647T patent/ATE335344T1/de not_active IP Right Cessation
- 2004-03-31 US US10/814,662 patent/US7558963B2/en not_active Expired - Fee Related
- 2004-03-31 CN CN200410030712.4A patent/CN1272953C/zh not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP1465383B1 (en) | 2006-08-02 |
| JP4176533B2 (ja) | 2008-11-05 |
| ATE335344T1 (de) | 2006-08-15 |
| US20050005099A1 (en) | 2005-01-06 |
| CN1272953C (zh) | 2006-08-30 |
| DE602004001704D1 (de) | 2006-09-14 |
| EP1465383B8 (en) | 2006-11-02 |
| US7558963B2 (en) | 2009-07-07 |
| CN1535059A (zh) | 2004-10-06 |
| TWI265708B (en) | 2006-11-01 |
| EP1465383A1 (en) | 2004-10-06 |
| JP2004302973A (ja) | 2004-10-28 |
| DE602004001704T2 (de) | 2007-10-04 |
| TW200425695A (en) | 2004-11-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2268524T3 (es) | Dispositivo y programa de comunicacion. | |
| KR100582650B1 (ko) | 컨텐츠 전송 방법 및 컨텐츠 전송 시스템 | |
| RU2595904C2 (ru) | Способы и устройство для крупномасштабного распространения электронных клиентов доступа | |
| KR101030819B1 (ko) | 애플리케이션을 장치에 로딩하는 방법, 장치 및 스마트카드 | |
| US8452970B2 (en) | System and method for code signing | |
| KR100463736B1 (ko) | 보안 환경에서의 이동 통신 장치 소프트웨어의 디버깅 및테스팅 허가 방법 | |
| US7933583B2 (en) | Method and apparatus for digital image processing of an image from an image sensor | |
| ES2362358T3 (es) | Dispositivo de comunicación, procedimiento y programa para comprobar el permiso de ejecución de software. | |
| EP2425370B1 (en) | Method and apparatus to create a secure web browsing environment with privilege signing | |
| US20040073801A1 (en) | Methods and systems for flexible delegation | |
| EP1626326A2 (en) | Software code signing system and method | |
| US20060137007A1 (en) | Revoking a permission for a program | |
| CN107332817B (zh) | 支持多个访问控制客户端的移动装置和对应的方法 | |
| CN101064604B (zh) | 远程访问方法、系统及设备 | |
| US20030059049A1 (en) | Method and apparatus for secure mobile transaction | |
| WO2008042524A2 (en) | Method and system for displaying trust level on a wireless communication device | |
| EP1561301B1 (en) | Software integrity test in a mobile telephone | |
| Jeziorski et al. | Verification of Certificate Authorities (CAs) and integration with cloud providers for enhanced security | |
| JP5132730B2 (ja) | 配信方法および配信システム | |
| Papamichail et al. | TOWARDS FAULT TOLERANT VERIFICATION OF PROXY OBJECTS IN JINI | |
| HK1068694B (en) | Content delivery method and content delivery system |