ES2237500T3 - Procedimiento de autorizacion con certificado. - Google Patents

Procedimiento de autorizacion con certificado.

Info

Publication number
ES2237500T3
ES2237500T3 ES01102165T ES01102165T ES2237500T3 ES 2237500 T3 ES2237500 T3 ES 2237500T3 ES 01102165 T ES01102165 T ES 01102165T ES 01102165 T ES01102165 T ES 01102165T ES 2237500 T3 ES2237500 T3 ES 2237500T3
Authority
ES
Spain
Prior art keywords
key
certificate
software
vehicle
control device
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
Application number
ES01102165T
Other languages
English (en)
Inventor
Ernst Schmidt
Burkhart Kuhls
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bayerische Motoren Werke AG
Original Assignee
Bayerische Motoren Werke AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bayerische Motoren Werke AG filed Critical Bayerische Motoren Werke AG
Application granted granted Critical
Publication of ES2237500T3 publication Critical patent/ES2237500T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • B60R25/20—Means to switch the anti-theft system on or off
    • B60R25/24—Means to switch the anti-theft system on or off using electronic identifiers containing a code not memorised by the user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2145—Inheriting rights or properties, e.g., propagation of permissions or restrictions within a hierarchy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Abstract

Procedimiento para asegurar la integridad de los datos de un software para un aparato de control de un vehículo automóvil, en el que se puede almacenar en una memoria un software que influye sobre el funcionamiento del aparato de control, en donde se han previsto los pasos si guientes: habilitación de un par de claves del aparato de control con una primera clave y una segunda clave, habilitación de un número determinado n de pares de claves de certificado, cada uno con una primera clave y una segunda clave, archivado de la primera clave del par de claves del aparato de control en o para el aparato de control del vehículo automóvil, confección de certificados correspondientes al número determinado n, comprendiendo cada certificado una informa ción del mismo, estando depositada en la información del último certificado al menos una clave para comprobar el software y - en caso de que se empleen varios certificados - estando depositada en las demás informaciones de certificado al menos una clavepara comprobar el certificado siguiente, firma de la información del primer certificado con la segunda clave del par de claves del aparato de control y - en caso de que esté presente más de un certificado - firma de los certificados restantes con la respectiva segunda clave de un par de claves de certificado, la respectiva primera clave del cual está depositada en la información del certificado precedente.

Description

Procedimiento de autorización con certificado.
La invención concierne a un procedimiento para asegurar la integridad de los datos de un software para un aparato de control de un vehículo automóvil.
Con la proporción creciente de la electrónica y las posibilidades de comunicación en el vehículo y con un vehículo crecen también las exigencias que tienen que imponerse a la seguridad,
En las más diferentes zonas del vehículo se utilizan microcontroladores para fines de control. Estos aparatos de control están unidos hoy en día frecuentemente uno con otro a través de uno o varios sistemas de bus, y existen en general posibilidades (por ejemplo, comunicación de diagnóstico) de acceder a este bus desde fuera y comunicarse con los distintos aparatos de control.
El funcionamiento de los aparatos de control viene determinado por programas de software. Hasta ahora, el software que se utiliza en un aparato de control (también controlador) está comúnmente archivado en una memoria no programable (por ejemplo, en microcontroladores programados con máscara). De este modo, no se puede realizar sin más ni más una manipulación del software. Por ejemplo, se puede reconocer el intercambio completo de un módulo de memoria por otro módulo de memoria y reaccionar a ello de manera correspondiente.
Sin embargo, debido a la futura utilización en el vehículo de aparatos de control programables, especialmente los llamados aparatos de control programables en memoria flash (memoria instantánea), se hace mayor el riesgo de que se realicen manipulaciones no autorizadas en el software y, por tanto, en el modo de trabajo de los aparatos de control. Así, el intercambio de software por parte de personas no autorizadas podría realizarse con poco coste simplemente mediante una nueva programación.
Sin embargo, por motivos de seguridad y para cumplir los requisitos legales, se tienen que adoptar medidas que impidan una variación de software original o que admitan una variación de esta clase para solamente personas autorizadas.
Por lo demás, podría manifestarse como ventajoso en el futuro el perseguir un concepto de partes idénticas, en el que se emplee un hardware idéntico para modelos diferentes. La diferencia en el modo de funcionamiento reside entonces solamente en un software diferente. En este concepto existe ciertamente la necesidad de que un determinado software sea capaz de funcionar solamente sobre un vehículo individual y no pueda ser copiado de manera sencilla.
Se conocen por el estado de la técnica una multitud de procedimientos y dispositivos de autentificación.
Así, en la patente US 5,844,986 se describe un procedimiento que se emplea para evitar una intervención no autorizada en un sistema BIOS de un PC. Un coprocesador criptográfico, que contiene una memoria BIOS, realiza una autentificación y comprobación de una variación del sistema BIOS basándose en un denominado procedimiento public key con una clave pública y una clave secreta. La verificación se efectúa en este caso mediante una comprobación de una firma digital incrustada en el software que se ha de ejecutar.
Se conoce por el documento EP 0 816 970 un dispositivo para verificar un software de firma. Este dispositivo para autentificar una memoria PROM de arranque comprende una parte de memoria y un microcódigo. Un sector de autentificación comprende un generador de hash que genera datos de hash en respuesta a la ejecución del microcódigo.
Sin embargo, con los procedimientos o dispositivos anteriores no es posible directamente la verificación de un software que ha de ejecutarse en un aparato de control de un vehículo automóvil.
En el documento EP 0 813 132 se ha descrito un procedimiento de autentificación en el que un programa está acoplado con un certificado y una lista de acceso. Según una forma de ejecución preferida, una agencia de certificados confecciona un certificado para un código y un certificado para la lista de acceso. Cuando se ha emitido una vez el certificado, ya no es posible variar el código o la lista de acceso sin que resulte lesionado el certificado. El código y la lista de acceso se almacenan juntamente con sus certificados en un servidor. Con este procedimiento un cliente que solicite el código o la lista de acceso puede verificar su autenticidad. Sin embargo, no es posible sin más medidas una aplicación de este procedimiento en el sector de los vehículos automóviles.
En general, sería ventajoso poder recurrir a varios autorizados para la confección y marcación auténtica de software solicitado. Por tanto, la marcación no tendría que ser realizada solamente por un puesto central. No obstante, debería estar preparado también un puesto de vigilancia central para la concesión de autorizaciones para autorizados seleccionados.
El cometido de la presente invención consiste en proporcionar un procedimiento para asegurar la integridad de los datos de un software para un aparato de control de un vehículo automóvil, en el que varios autorizados que son controlables por un dispositivo central puedan confeccionar un software auténtico y marcarlo de manera correspondiente.
El problema se resuelve con las características de la reivindicación 1.
Por consiguiente, un dispositivo central, denominado seguidamente centro de confianza (trust center), puede entregar a autorizados uno o más certificados con los que la persona o personas equipadas con ellos pueden firmar ellas mismas debidamente software para un aparato de control y pueden incorporarlo en un vehículo en una forma apta para su ejecución.
A este fin, por ejemplo, el centro de confianza (el propio vehículo en una forma de ejecución alternativa) proporciona un par de claves del aparato de control con una primera clave y una segunda clave. La primera clave se deposita en el propio aparato de control durante la producción de un vehículo o se archiva para el aparato de control. Por este motivo, este par de claves se denomina par de claves de aparato de control. Con la segunda clave del centro de confianza se firma un primer certificado para un autorizado, seguidamente titular del certificado.
Para una mejor claridad se supondrá en primer lugar que se necesita solamente un certificado para la lectura e ingreso ejecutables de un software nuevo en un aparato de control. Este certificado contiene en una parte de información del certificado, además de informaciones determinadas del certificado, al menos una primera clave del titular del certificado que ha generado ella misma un par de claves de certificado con una primera clave y una segunda clave. Como informaciones de certificación adicionales pueden estar fijadas, por ejemplo, el expedidor del certificado, un número de serie, un titular del certificado, determinados derechos de acceso o un período de tiempo de validez.
El autorizado o titular del certificado firma entonces con su segunda clave del par de claves del certificado el software que ha de incorporarse en el aparato de control. Tanto el certificado como el software firmado por el titular del certificado se incorporan entonces en el aparato de control de un vehículo. El aparato de control reconoce por medio de su primera clave propia del par de claves del aparato de control la legitimidad del certificado y acepta las informaciones del certificado, entre ellas la clave contenida en las mismas. Con esta clave, es decir, con la primera clave del par de claves del certificado, se realiza de nuevo la verificación de la firma del software incorporado. Cuando esta firma es reconocible también como perfecta, ésta es aceptada por el aparato de control.
Con esta forma de proceder se pueden otorgar en general derechos de variación y de firma. No todo software tiene que ser firmado él mismo por el titular del par de claves del aparato de control, por ejemplo por el centro de confianza. Con las informaciones adicionales en el certificado es posible, además, asignar al titular del certificado una gran cantidad de permisos o limitaciones. Por ejemplo, puede concederse un período de tiempo durante el cual el titular del certificado puede confeccionar e incorporar software. Pueden concederse diferentes niveles de autorización para la generación del software y la clase del software. Sin embargo, la firma del propio software es efectuada siempre por el propio titular del certificado.
Por claves se entienden en general parámetros de codificación y/o descodificación que se emplean en algoritmos criptográficos en sí conocidos. Es posible el empleo de procedimientos simétricos y asimétricos. En los procedimientos simétricos ambas claves son idénticas, de modo verdaderamente tan sólo una clave esta presente en lugares diferentes. En los procedimientos asimétricos se emplean claves diferentes. En general, se conoce como procedimiento asimétrico el procedimiento public key (clave pública) en el que se generan una clave pública y una clave secreta (privada). La clave pública deberá ser conocida para cualquier persona. Tales algoritmos criptográficos son, por ejemplo, el algoritmo de Rivest, Shamir y Adleman (algoritmo RSA), el algoritmo de encriptado de datos (algoritmo DEA) y algoritmos similares que consistan en procedimientos asimétricos. Estos algoritmos pueden emplearse tanto para el primer par de claves como también para el segundo par de claves.
En una ejecución más compleja del presente procedimiento según la invención se expiden para la comprobación de un software incorporado en un aparato de control no sólo un único certificado, sino varios certificados n. Por tanto, existen aún otras posibilidades de ejecución. Por un lado, es posible distribuir certificados diferentes entre personas diferentes, de modo que sea posible solamente en forma mancomunada una incorporación ejecutable de software nuevo en un aparato de control. Además, es posible conceder diferentes derechos de acceso en función del número diferente de certificados.
En caso de que se empleen varios certificados, la firma del primer certificado puede comprobarse con la clave archivada en el aparato de control. La firma de cualquier certificado adicional puede ser a su vez verificada por la clave contenida en un certificado anterior aceptado. Con la clave del último certificado se verifica a su vez finalmente la propia firma del software. Solamente cuando se hayan desarrollado satisfactoriamente todas las verificaciones, el software es aceptado por el aparato de control. Para que la firma de un certificado pueda ser verificada con la clave contenida en un certificado anterior, éste tiene que haber sido firmado con la segunda clave correspondiente.
Existe una gran posibilidad de variación para elegir el sitio en el que deberán depositarse cada vez la clave secreta y la clave pública. Por ejemplo, en las informaciones de un certificado están depositadas las respectivas claves públicas. En el propio aparato de control puede estar depositada también la clave pública del par de claves del aparato de control. Tiene que haberse formado entonces de manera correspondiente la firma a verificar con la clave secreta pertinente.
Naturalmente, son imaginables también otras formas de ejecución en las que la clave secreta está archivada en la información del certificado y/o en el propio aparato de control. Son enteramente imaginables también combinaciones con claves simétricas.
Preferiblemente, la clave archivada en el aparato de control está depositada en el sector de arranque. Este está protegido normalmente de una manera especial. Para aumentar la seguridad, el sector de arranque puede estar configurado también de modo que sea "bloqueado" después de la descripción y el archivado de la clave contenida en el mismo, es decir que sea bloqueado para accesos futuros, especialmente accesos de escritura.
Si todas las pruebas se desarrollan positivamente (prueba del certificado y prueba del software), el software es aceptado entonces por el aparato de control o por un dispositivo previsto expresamente para ello y puede ser aprovechado para controlar el aparato de control.
Como ya se ha descrito anteriormente, la clave pública en los llamados procedimientos de clave pública deberá ser públicamente conocida, mientras que la clave secreta es conocida solamente para un puesto autorizado.
Según una forma de ejecución especial, la clave secreta del par de claves del aparato de control es conocida solamente para el centro de confianza y la clave secreta de un par de claves de certificado es conocida solamente para el titular del certificado. Con cada clave secreta se puede generar - análogamente a la firma manual - una firma digital para un documento electrónico (certificado, software). Únicamente el propietario de la clave secreta puede confeccionar una respectiva firma válida. La autenticidad del documento (certificado, software) puede ser verificada por medio de la clave pública a través de la verificación de la firma. Un tercero no autorizado que no conozca la clave secreta no está en condiciones de confeccionar una firma válida. Si se carga en un aparato de control un certificado manipulado, vencido o no autorizante o se carga en el aparato de control un software manipulado y no correctamente firmado, esto es reconocido entonces con la respectiva clave correspondiente y el aparato de control es puesto en un estado no capacitado para funcionar.
En caso de que se emplee un procedimiento simétrico, se puede aprovechar para aumentar la etapa de seguridad una protección adicional contra disparo en forma de un hardware especial.
Para satisfacer los requisitos de una utilización de un software exclusivamente individual para el vehículo, el software previsto para un aparato de control de un vehículo determinado contiene informaciones individualizadoras del vehículo, por ejemplo el número de bastidor u otros datos individuales del vehículo. Estas informaciones están asociadas al software o integradas en éste. Únicamente después de la asociación de estos datos al software o de su integración en el mismo, éste es firmado entonces con la segunda clave del titular del último certificado. Un aparato de control acepta - como se ha descrito anteriormente - el software tan sólo cuando, por un lado, el certificado o los certificados y, además, la firma del software han sido reconocidos como perfectos. Dado que la firma depende de la información individual del vehículo contenida en el software, ésta no puede ser modificada posteriormente. Se puede alimentar solamente un software ejecutable para un aparato de control de un vehículo cuando no se ha variado la información individual del vehículo y ésta coincide realmente con la del vehículo. Es así imposible que se copie tal software individualizado sobre otro vehículo.
Para crear una etapa de seguridad adicional al incorporar software en las memorias del aparato de control, deberá ser posible además, antes de la incorporación del software, un acceso a la memoria del aparato de control solamente con una autorización correspondiente. A este fin, se ha previsto realizar antes de la sobreinscripción del software firmado una "apertura" del aparato de control en un paso de solicitud. Empleando niveles priorizados diferentes para la solicitud se podrían conceder, además, derechos de acceso configurados de maneras diferentes. En el caso de un acceso de diagnóstico, sería necesaria primeramente, por ejemplo, una solicitud, con la cual el aparato de control reconoce, a través de la información de acceso ingresada, los derechos de acceso y la etapa de autorización ligada a ellos. Según la concesión de derechos, las autorizaciones de acceso pueden clasificarse de no críticas a muy críticas. La adjudicación de derechos puede estar configurada de forma estática, de modo que, por ejemplo, se emitan códigos de acceso diferentes para etapas de autorización determinadas. Como alternativa, la adjudicación de derechos puede configurarse también en forma dinámica, de modo que se adjudiquen, por ejemplo, certificados de entrada en cuya información está contenida la etapa de autorización.
Según una alternativa, las verificaciones de las firmas se realizan en el propio aparato de control. Según otra alternativa, se puede realizar también al menos una verificación en un control de entrada o de acceso propio. Un aparato de control previsto en su caso exclusivamente para el control de acceso deberá estar dispuesto de forma no accesible en el vehículo automóvil, en comparación con los restantes aparatos de control, a causa de la función de seguridad central respecto de la adjudicación de derechos de acceso, ya que con el desmontaje físico de un aparato de control se podrían esquivar eventualmente los mecanismos de protección anteriormente descritos.
Asimismo, para excluir también el riesgo de que un aparato de control sea completamente desmontado y sustituido por otro, puede ser conveniente, además, una protección contra desmontaje del aparato de control. A este fin, se realiza esporádicamente una prueba de autenticidad del aparato de control, por ejemplo en un vehículo en el que están integrados los aparatos de control. Se dirige para ello de vez en cuando una consulta a cada aparato de control que éstos tienen que contestar con una información esperada determinada. Si la información realmente emitida por un aparato de control a verificar no coincide con la información esperada o el aparato de control no responde, se adoptan entonces medidas de seguridad adecuadas. Por ejemplo, el aparato de control es excluido del conjunto de comunicaciones o bien el aparato de control es registrado, marcado o recogido en una lista. Al realizar un diagnóstico del vehículo se puede reconocer entonces la manipulación. En la forma de ejecución anteriormente descrita los aparatos de control responden a la consulta, por ejemplo, por medio de una clave de autentificación secreta específica del aparato de control. Un aparato de control ilegalmente cambiado no dispone de esta clave y, por tanto, no es tampoco aceptado.
Se explica seguidamente la presente invención con más detalle ayudándose de ejemplos de ejecución y haciendo referencia a los dibujos adjuntos. Los dibujos muestran:
La Figura 1, una representación esquemática de una estructura de aparato de control en un vehículo,
La Figura 2, un diagrama de desarrollo para la lectura e ingreso de software en un aparato de control, y
La Figura 3, una representación esquemática del desarrollo de la adjudicación de firmas individuales para que un software pueda controlar perfectamente un aparato de control,
La Figura 4, una representación esquemática para la expedición de un certificado a través de un centro de confianza,
La Figura 5, una representación esquemática de la confección de una firma digital para un software,
La Figura 6, una representación esquemática del desarrollo de las comprobaciones en un aparato de control para la verificación de software incorporado en el mismo,
Las Figuras 7a a 7d, representaciones para el cifrado y la verificación de certificado y software empleando un código de hash, y
La Figura 8, una representación de un algoritmo para una comprobación de informaciones individuales del vehículo.
En la Figura 1 se reproduce a manera de diagrama de bloques una estructura de aparato de control con unidades conectadas en red una con otra. La red a bordo está constituida aquí por varias redes parciales (LWL-Most, sistema K-CAN, CAN del tren de potencia, etc.) que poseen en parte velocidades de transmisión diferentes y que están unidas entre sí por medio de las llamadas pasarelas (módulo de pasarela central, pasarela de controlador). Un bus de diagnóstico 16 está unido directa o indirectamente con todas las demás redes por medio de la pasarela central 14. El bus de diagnóstico 16 constituye una de las comunicaciones más importante con el medio ambiente. A través de un probador de diagnóstico, que está conectado a una caja de enchufe OBD (OBD = on board diagnose = diagnóstico a bordo) dispuesta en el extremo del bus de diagnóstico 16, y con intercalación de la pasarela central 14 se pueden activar todos los controladores, pasarelas y aparatos de control en todo el sistema.
Como alternativa, existe la posibilidad de acceder a los aparatos del vehículo a través de la red GSM 20 y un sistema telefónico 18 existente en el vehículo. Por tanto, es posible en principio un acceso remoto a la red a bordo del vehículo. El sistema telefónico 18 representa aquí también una pasarela entre la red de telefonía móvil (red GSM) y los demás abonados del bus del vehículo.
En el bus del vehículo está integrado un sistema de acceso de coche (CAS) 22 que vigila la entrada en el vehículo. Incluye como función adicional un bloqueo antihurto electrónico.
Un cambiador multimedia (MMC) constituye una interfaz entre un reproductor de CD y la red a bordo. En la pasarela 21 del controlador se convierten en mensajes las entradas que efectúa el conductor a través de los diferentes instrumentos y se retransmiten dichos mensajes a los respectivos aparatos de control activados.
Además, están representados varios aparatos de control (STG1 a STG5). El cometido de un aparato de control no sólo consiste en el control de una unidad determinada del vehículo, sino también en la comunicación entre los propios aparatos. La comunicación en el vehículo está "orientada a la radiodifusión" en el presente caso. Un generador de informaciones que ha obtenido el acceso al bus envía sus informaciones básicamente a todos los aparatos de control. El bus de datos que está unido con el controlador es escuchado para ello permanentemente. Por el contrario, en una comunicación con el entorno, por ejemplo a través del bus de diagnóstico, se activa deliberadamente cada aparato de control con una dirección unívoca.
El software que determina la funcionalidad de la unidad de control estará alojado en el futuro principalmente en una memoria flash programable. En una programación flash se pueden borrar y escribir de nuevo solamente bloques completos. El borrado de bytes individuales no es posible. Según los aparatos de control, se utilizan diferentes clases de microprocesadores. Según los requisitos, estos son procesadores de 8 bits, 16 bits o 32 bits. Todos estos aparatos de control o controladores están disponibles en variantes diferentes. Presentan, por ejemplo, una memoria flash sobre la placa o bien integrada directamente en el propio procesador.
A continuación, se entrará en más detalles sobre el cifrado empleado en el presente caso. En el procedimiento de autentificación empleado se prefiere un cifrado asíncrono. En claves simétricas cada lado tiene que estar en posesión del secreto. Tan pronto como es conocida una clave síncrona, ya no se puede asegurar un cifrado eficaz. Sin embargo, dado que una clave del par de claves tiene que estar almacenada en el aparato de control de un vehículo automóvil y, por tanto, no puede asegurarse su mantenimiento en secreto, la elección de un par de claves simétricas no es aconsejable.
En contraposición al cifrado simétrico, W. Diffie y M. Hellman desarrollaron en 1976 la llamada criptografía de clave pública. En esta clase de cifrado se genera un par de claves con una clave pública y una clave secreta. Con la clave pública se puede descifrar todo, pero no se puede cifrar. Por el contrario, para el cifrado (firmado) se necesita la clave secreta.
El procedimiento de clave pública tiene la ventaja de que una clave del par de claves deberá ser públicamente conocida. Sin embargo, dado que los procedimientos de clave pública actualmente conocidos requieren muchísimos cálculos, se emplean frecuentemente procedimientos híbridos, es decir, una combinación de procedimientos simétricos y asimétricos. En el procedimiento híbrido se intercambia una clave simétrica entre dos partes comunicantes por medio de un procedimiento de clave pública. La comunicación propiamente dicha se cifra entonces con la clave simétrica.
Debido a la separación de la clave secreta y la clave pública se pueden materializar procedimientos de autentificación y firmas digitales como se ha descrito anteriormente. Mediante la posesión de la clave secreta se puede demostrar unívocamente una identidad y se puede confeccionar una firma como en el caso de una firma manuscrita. Criptosistemas de clave pública conocidos son el procedimiento RSA. Otros criptoprocedimientos de clave pública se basan en problemas en grupos matemáticos determinados para calcular logaritmos (problema de logaritmos discretos).
Se describe seguidamente la presente invención con referencia a un ejemplo de ejecución determinado en el que un cliente desea una función adicional determinada en su vehículo automóvil. Por ejemplo, la transmisión deberá hacerse funcionar con otras curvas características de cambio. Esta función puede materializarse mediante la incorporación de nuevo software en el aparato de control de su vehículo. Para su realización, el cliente se dirige a un puesto autorizado, por ejemplo un concesionario, que pueda confeccionar tal software e incorporarlo en forma desarrollable en su vehículo.
Se explican seguidamente los desarrollos necesarios para ello.
Para no tener que hacer que todas las cantidades de software pedidas sean marcadas (firmadas) por un único puesto, se crean primero varios autorizados descentralizados - los llamados titulares de certificado - (por ejemplo, concesionarios), en los que se puede pedir un software deseado. Mediante la expedición de certificados se pone a los autorizados en condiciones de generar ellos mismos el software pedido y también firmarlo (signarlo).
Se explica primero con más detalle el desarrollo con referencia a la Figura 3. En un centro de confianza (404 en la Figura 4) se genera un primer par de claves 300 con una clave privada 304 y una clave pública 302.
Una clave es aquí un código electrónico con el que se puede cifrar y/o descifrar una información. Se emplean para ello algoritmos criptográficos conocidos, como los algoritmos RSA o DEA ya descritos anteriormente, es decir, los llamados "algoritmos de clave pública" con pares de claves asíncronas.
La clave pública 302 del centro de confianza se deposita ya durante la producción de un vehículo en el sector de arranque 308 de un aparato de control 306.
Sin embargo, con la clave privada 304 se firma (signa) ahora un certificado 318 que contiene determinadas informaciones del mismo.
El titular del certificado confecciona también un par de claves 312 (segundo par de claves) con una clave privada adicional 314 y una clave pública adicional 316. La clave pública 316 se deposita en el certificado 318 como una información del mismo. Otras informaciones del certificado pueden ser, por ejemplo, el expedidor del certificado, el número de serie, el titular del certificado, determinados derechos de acceso o el período de tiempo de validez.
Con la clave privada 314 del titular del certificado, que solamente es conocida para éste, se firma (firma 322) un software 320 de una manera que se describirá aún seguidamente. El titular del certificado incorpora entonces en el aparato de control 306 el certificado 318 existente permanentemente en su poder y también el software confeccionado y firmado 320.
El resto de esta forma de proceder se explicará ahora con ayuda de la Figura 6. El aparato de control 600 (símbolo de referencia 306 en la Figura 3) comprueba primero durante su primera aceleración hasta la velocidad de régimen después de la incorporación si el certificado 618 es perfecto. A este fin, se comprueba la firma 2 619 del certificado 618 por medio de la clave pública 602 del centro de confianza archivada en el sector de arranque 603 del aparato de control 600. Si se encuentra que el certificado 618 es válido (sí), se acepta también la información de certificado 617 almacenada en el mismo junto con la clave pública 616. Si se verifica que el certificado o su firma 619 no es irreprochable (no), se detiene (parada) el funcionamiento del aparato de control.
Con la clave pública 616 contenida en el certificado 618 se comprueba a su vez la firma 1 608 del software 606. Si se supera también esta comprobación (sí), el aparato de control puede hacerse funcionar con el software recién incorporado 610 (vale). En caso contrario (no), se detiene (parada) el funcionamiento del aparato de control 600.
En conjunto, con la forma de proceder descrita se puede conseguir una descentralización de sitios autorizados que están facultados para firmar software. Quedan abiertas aquí las más diferentes posibilidades para empaquetar en el certificado otras autorizaciones y limitaciones. Cuando está contenido un período de tiempo de validez en el certificado, un anterior titular de certificado no puede ya firmar software después de transcurrido el período de tiempo de validez o este software no es ya aceptado, dado que el certificado no es ya aceptado. Además, a través del titular del certificado se puede determinar también quién ha introducido un software en el aparato de control y, por tanto, ha realizado una modificación.
En la Figura 2 se representa otra etapa de seguridad. Cuando deba incorporarse un nuevo software en un aparato de control de un vehículo, esto tiene que solicitarse primero (paso 200 en la Figura 2). En la solicitud se efectúa una identificación del autorizado. Únicamente en caso de una identificación satisfactoria se "desbloquea" el aparato de control, con lo que en principio es posible una lectura e introducción de software nuevo y del certificado en el aparato de control (paso 202 en la Figura 2). Únicamente después de la lectura e introducción se realiza entonces la verificación anteriormente descrita del certificado y del software.
En lo que sigue se aclara con más detalle la confección del certificado. En primer lugar, tiene que existir conformidad entre el centro de confianza y un tercero para que se adjudique a este tercero como titular del certificado una cierta etapa de autorización para introducir software modificado en un aparato de control o para un aparato de control de un vehículo. Cuando se logra un acuerdo, el futuro titular del certificado (por ejemplo, un taller 400) genera su propio par de claves con una clave privada y una clave pública y envía la clave pública con una petición de certificado (paso 402 en la Figura 4) al centro de confianza 404.
El centro de confianza 404 confecciona el certificado 406, lo firma con la clave secreta (véase también el símbolo de referencia 304 en la Figura 3) y lo envía de vuelta al titular 400 del certificado, en donde se queda.
El titular 400 del certificado puede firmar software 408 (también símbolo de referencia 320 en la Figura 3) con su clave privada a partir del momento de la recepción del certificado y siempre que esto se lo permita el certificado 406. Esto se ha representado con detalle en la Figura 5. Se firma allí un software 500 en una unidad 540 con la clave secreta 520. El software firmado 560 está listo entonces para su incorporación en el aparato de control de un vehículo. Esto se ha representado también con referencia a la Figura 4. El software firmado 408 y el certificado 406 son incorporados allí por el titular del certificado en un vehículo 12.
Con referencia a las Figuras 7a a 7d se explicará con detalle la firma del software y del certificado, así como la comprobación de la respectiva firma.
Es ineficaz firmar un documento electrónico completo en su totalidad. Por el contrario, se emplea para ello en el presente caso una llamada función hash.
Expresado con más exactitud, se genera a partir del software 750, por medio de una función hash en sí conocida, un denominado código hash 751, que consiste en una información digital de longitud prefijada. Este código hash 751 es firmado entonces con la clave secreta del titular del certificado (firma 1 752). El firmado del código hash 751 es sensiblemente más eficaz que la firma de documentos de software largos. Las funciones hash conocidas tienen aquí las propiedades esenciales siguientes: Es en general difícil encontrar para un valor hash dado h un valor M de un documento (función monouso). Además, es difícil encontrar una colisión, es decir, dos valores con M y M', en los que los valores hash sean iguales (resistencia a la colisión).
Como ya se ha mencionado antes, el software solicitado 753 puede ser confeccionado y firmado por el propio titular del certificado.
De manera análoga al software se confecciona un certificado (Figura 7b). A partir de toda la información 760 del certificado, incluyendo la clave pública del titular del certificado, se genera, por medio de una función hash idéntica u otra función hash, otro código hash 761, que consiste en una información digital con una longitud prefijada diferente. Este otro código hash 761 es firmado entonces con la clave secreta del centro de confianza (firma 2 762).
Después de incorporar el nuevo software y el certificado en un aparato de control se comprueba entonces primero durante el funcionamiento siguiente, por medio de la clave pública almacenada en el aparato de control, si la firma del certificado es irreprochable (Figura 7c). Se aplica para ello la clave pública del aparato de control a la firma 2, lo que da como resultado un código hash calculado (símbolo de referencia 765). Este código hash calculado 765 se compara en un comparador 764 con el código hash 761' formado a partir del propio certificado según la función hash antes citada. En el presente caso, ambos códigos hash 765 y 761' no coinciden uno con otro. El certificado ha sido variado de manera no autorizada en el presente caso, se suprime así el funcionamiento del aparato de control (parada).
Si se hubiera verificado el certificado como irreprochable, se comprueba entonces en el paso siguiente (Figura 7b) si el software ha sido debidamente firmado. Se aplica para ello, análogamente a la firma 1 del software, la clave pública del certificado, con lo que se determina un código hash 756. Este código hash 756 en comparado en un comparador 754 con el código hash 751' determinado directamente a partir del software. En el presente caso, no existe ninguna coincidencia, por lo que se suprimiría de nuevo el funcionamiento del aparato de control. Sin embargo, si coincidieran los códigos hash 756 y 756', el aparato de control podría hacerse funcionar entonces con el nuevo software. Para impedir una comprobación en cada aceleración hasta la velocidad de régimen, se puede colocar también después de la primera verificación un bit de prueba que indica una verificación irreprochable. Naturalmente, este bit de prueba no deberá ser modificable desde fuera.
Aparte de la firma digital anteriormente escrita, se emplea frecuentemente un denominado procedimiento de interrogación-respuesta para autentificar una parte comunicante A con respecto a una parte comunicante B. En este caso, B envía primero un número aleatorio ALEATORIO a A. A firma este número aleatorio por medio de su clave secreta y envía este valor como respuesta a B. B verifica la respuesta por medio de su clave pública y comprueba la autentificación de A.
A continuación, se describe con ayuda de la Figura 8 el aseguramiento de una individualización del software para un vehículo determinado, haciéndose referencia a un procedimiento de interrogación-respuesta anteriormente mencionado.
El procedimiento anteriormente mencionado de firma de un software es ampliado en la medida en que el software del aparato de control se marca aún en forma individualizada para un vehículo determinado. Cada software se liga con una característica de identificación de un vehículo o tipo de vehículo determinado. La característica de identificación puede ser, por ejemplo, el número del bastidor.
A continuación se describe la razón de que el software así marcado pueda incorporarse después en forma apta para funcionar tan sólo en este vehículo o este tipo de vehículo.
Para la individualización del software se inscribe primero el número de bastidor FGNsw en el software 800 y a continuación se firma el software completo - junto con una clave privada IFSp 804 - como se ha descrito antes después de confeccionar el código hash (símbolo de referencia 802). El aparato de control 806 acepta tan sólo un software correctamente firmado como ya se ha descrito. Dado que el número de bastidor FGNsw está influenciado por el código hash y la firma, no es posible variar posteriormente el número del bastidor.
Cuando se acepta en principio la firma 802, se comprueba si la característica de identificación del vehículo FGNsw asociada al software 800 coincide con la característica FGN presente realmente en el vehículo. Cuando ocurre esto, se habilita el software. Por tanto, el software preparado como antes se puede emplear tan sólo en un vehículo de destino determinado. Para otro vehículo se tiene que adquirir nuevamente otro software provisto de una firma individual.
Para poder realizar esta individualización de un software, el número de bastidor deberá insertarse ya en la fabricación de manera no manipulable en los aparatos de control correspondientes. El número de bastidor FGN tiene que estar aún presente en el aparato de control incluso después de que se borre una memoria. Esto puede materializarse haciendo que el número de bastidor esté registrado, por ejemplo, en el sistema de acceso de coche (CAS) 810 ya mencionado anteriormente en una memoria no volátil.
La siguiente forma de proceder según la Figura 8 asegura entonces una consulta no manipulable. Además del número de bastidor, se necesita otro par de claves individuales del vehículo constituido por una clave secreta IFSs y la clave pública IFSp ya mencionada más arriba. La asociación del número del bastidor y las dos claves se efectúa en el puesto central. La clave secreta IFSs está almacenada en la unidad del aparato de control sistema de acceso de coche (CAS) 810, concretamente en forma no legible.
El número de bastidor FGN se encuentra ya en la zona de acceso del sistema de acceso de coche.
En el software a incorporar de nuevo está archivada, adicionalmente al número del bastidor, la clave pública IFSp (804). Seguidamente, se asegura el software completo 800 mediante la firma del mismo. Después de cargar el software en el aparato de control 806 se comprueba primero la naturaleza correcta de la firma. Seguidamente, el aparato de control 806 verifica por medio de una consulta de interrogación-respuesta anteriormente descrita si el número del bastidor del software coincide con el del vehículo. A este fin, el aparato de control envía el número del bastidor del software FGNsw y un número aleatorio ALEATORIO al sistema de acceso de coche 810 (símbolo de referencia 808). El número de bastidor FGN almacenado en el vehículo es comparado allí con el número de bastidor recibido FGNsw. A continuación, se firman los dos valores con la clave secreta IFSs y se envían nuevamente de vuelta al aparato de control 806. El aparato de control 806 puede comprobar ahora el envío firmado con la clave pública IFSp. Seguidamente, se compara (paso 814) si coinciden los diferentes valores correspondientes uno a otro. Cuando ocurre esto (VALE), el aparato de control 806 puede hacerse funcionar con el software individual del vehículo. Si la comparación da un resultado negativo, se detiene entonces el funcionamiento del aparato de control (paso 816).
Como variante de este procedimiento puede emplearse también, en lugar de un par de claves individuales IFSs e IFSp, un par de claves correspondiente no individualizado para un vehículo que esté almacenado ya en el vehículo. Se suprime de este modo la administración de esta clave. Asimismo, es posible, naturalmente, un mecanismo correspondiente con un procedimiento criptográfico simétrico. Esto tiene ventajas en la ejecución, pero trae consigo el riesgo de que la clave simétrica sea leída y extraída de los aparatos de control.
Naturalmente, en todos los procedimientos arriba citados tiene que asegurarse de forma absoluta que las claves secretas del centro de confianza se mantengan también secretas. En conjunto, la criptografía antes citada ofrece una buena posibilidad de incorporar solamente software correcto en vehículos o en vehículos determinados y prevenir así manipulaciones no autorizadas.

Claims (19)

1. Procedimiento para asegurar la integridad de los datos de un software para un aparato de control de un vehículo automóvil, en el que se puede almacenar en una memoria un software que influye sobre el funcionamiento del aparato de control, en donde se han previsto los pasos siguientes:
habilitación de un par de claves del aparato de control con una primera clave y una segunda clave,
habilitación de un número determinado n de pares de claves de certificado, cada uno con una primera clave y una segunda clave,
archivado de la primera clave del par de claves del aparato de control en o para el aparato de control del vehículo automóvil,
confección de certificados correspondientes al número determinado n, comprendiendo cada certificado una información del mismo, estando depositada en la información del último certificado al menos una clave para comprobar el software y - en caso de que se empleen varios certificados - estando depositada en las demás informaciones de certificado al menos una clave para comprobar el certificado siguiente,
firma de la información del primer certificado con la segunda clave del par de claves del aparato de control y - en caso de que esté presente más de un certificado - firma de los certificados restantes con la respectiva segunda clave de un par de claves de certificado, la respectiva primera clave del cual está depositada en la información del certificado precedente,
firma de un software a incorporar de nuevo con la segunda clave de un par de claves de certificado, la primera clave del cual está depositada en la información del último certificado,
incorporación de todos los certificados firmados en el aparato de control,
incorporación del software firmado en el aparato de control,
comprobación de la firma del primer certificado con la primera clave del par de claves del aparato de control archivada en o para el aparato de control y, en caso de que esté presente más de un certificado, comprobación de la firma de cada certificado adicional por medio de la primera clave contenida en la información del certificado precedente,
aceptación de la información de un respectivo certificado cuando la respectiva comprobación se desarrolle con resultado positivo, y
comprobación de la firma del software con la primera clave depositada en la información del último certificado y
aceptación del software incorporado cuando también esta comprobación se desarrolle con resultado positivo.
2. Procedimiento según la reivindicación 1, caracterizado porque en un certificado está contenida una clave pública en concepto de la al menos una información de certificado y porque la firma a comprobar con dicha clave se ha realizado con una clave secreta correspondiente.
3. Procedimiento según la reivindicación 1 ó 2, caracterizado porque la primera clave del par de claves del aparato de control, que está depositada en o para el aparato de control, es una clave pública y la firma del primer certificado se ha realizado con la clave secreta correspondiente.
4. Procedimiento según la reivindicación 1 ó 2, caracterizado porque el vehículo, especialmente un aparato de control montado en el vehículo, genera un par de claves asíncronas con una clave pública y una clave secreta, porque se archiva la clave secreta en el vehículo, especialmente en un aparato de control, y porque se puede leer la clave pública en el vehículo para firmar el primer certificado.
5. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque la clave archivada en el aparato de control se deposita en el sector de arranque de dicho aparato de control.
6. Procedimiento según la reivindicación 5, caracterizado porque se bloquea el sector de arranque después de la descripción y la introducción de la clave y se protege así dicho sector contra un acceso adicional, especialmente un acceso de escritura.
7. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque se reproducen el software y/o la información del certificado sobre una respectiva información con una longitud determinada y se firman entonces estas informaciones.
8. Procedimiento según la reivindicación 7, caracterizado porque como función de reproducción se elige una función hash.
9. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque se agrega al software al menos una información individual de un vehículo que contiene el aparato de control, porque se firma con el software la al menos una información individual del vehículo, porque, además de la comprobación de las firmas de los certificados y del software, se comprueba también la información individual del vehículo y porque se acepta el software en el aparato de control únicamente cuando también la información del software individual del vehículo coincide con la del vehículo.
10. Procedimiento según la reivindicación 9, caracterizado porque, para comprobar la información individual del vehículo, se genera un par de claves individuales propias, estando presentes en una unidad de seguridad del vehículo o en el aparato de control la información individual del vehículo y una clave del par de claves individuales del vehículo, estando depositada también en el software, aparte de la información individual del vehículo, la clave adicional del par de claves individuales del vehículo y comprobándose en una rutina separada si concuerdan las dos claves del par de claves individuales del vehículo para, en caso de una respuesta afirmativa, aceptar el software incorporado.
11. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque se comprueba el software al menos durante la primera aceleración hasta la velocidad de régimen del aparato de control y se le marca entonces de manera correspondiente.
12. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque, en caso de un acceso externo al aparato de control, una unidad de acceso comprueba si existe una autorización para el acceso.
13. Procedimiento según la reivindicación 12, caracterizado porque se solicita un código de un aparato de control y se comprueba la naturaleza correcta del código.
14. Procedimiento según la reivindicación 13, caracterizado porque un aparato de control emite un número aleatorio que ha de ser firmado por el que accede, y porque se comprueba la firma en el aparato de control, especialmente por medio de una clave de autentificación.
15. Procedimiento según una de las reivindicaciones 12 a 14, caracterizado porque se establece una etapa de autorización al consultar sobre la autorización de acceso y se aceptan o no se aceptan las acciones de acceso en función de la etapa de autorización.
16. Procedimiento según una de las reivindicaciones precedentes, caracterizado porque un dispositivo de seguridad montado en un vehículo realiza al menos esporádicamente una comprobación de autenticidad de un aparato de control y, en caso de un resultado negativo, registra dicho aparato de control.
17. Procedimiento según la reivindicación 16, caracterizado porque en el aparato de control está archivado un código secreto individual de dicho aparato de control.
18. Procedimiento según la reivindicación 16 ó 17, caracterizado porque el dispositivo de seguridad consulta sobre una característica específica del aparato de control y comprueba la autenticidad de ésta.
19. Procedimiento según una de las reivindicaciones 16 a 18, caracterizado porque en la comprobación de autenticidad se emplea una clave archivada en el dispositivo de seguridad y/o una clave archivada en el aparato de control.
ES01102165T 2000-02-25 2001-02-02 Procedimiento de autorizacion con certificado. Expired - Lifetime ES2237500T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10008973 2000-02-25
DE10008973A DE10008973B4 (de) 2000-02-25 2000-02-25 Autorisierungsverfahren mit Zertifikat

Publications (1)

Publication Number Publication Date
ES2237500T3 true ES2237500T3 (es) 2005-08-01

Family

ID=7632445

Family Applications (1)

Application Number Title Priority Date Filing Date
ES01102165T Expired - Lifetime ES2237500T3 (es) 2000-02-25 2001-02-02 Procedimiento de autorizacion con certificado.

Country Status (5)

Country Link
US (1) US7197637B2 (es)
EP (1) EP1127756B1 (es)
JP (1) JP2001255953A (es)
DE (2) DE10008973B4 (es)
ES (1) ES2237500T3 (es)

Families Citing this family (94)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI108389B (fi) * 1999-04-15 2002-01-15 Sonera Smarttrust Oy Tilaajaidentiteettimoduulin hallinta
DE10102979C2 (de) * 2001-01-10 2003-04-30 Torsten Valentin Verfahren zur Absicherung von Rechnern mit Anschluss an ein Netzwerk zum Zweck der Kontrolle von Netzwerkverbindungen
DE10131575A1 (de) * 2001-07-02 2003-01-16 Bosch Gmbh Robert Verfahren zum Schutz eines Mikrorechner-Systems gegen Manipulation von in einer Speicheranordnung des Mikrorechner-Systems gespeicherten Daten
DE10131578A1 (de) * 2001-07-02 2003-01-16 Bosch Gmbh Robert Verfahren zum Schutz eines Mikrorechner-Systems gegen Manipulation von in einer Speicheranordnung abgelegten Daten
DE10141737C1 (de) * 2001-08-25 2003-04-03 Daimler Chrysler Ag Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels
DE10140721A1 (de) 2001-08-27 2003-03-20 Bayerische Motoren Werke Ag Verfahren zur Bereitstellung von Software zur Verwendung durch ein Steuergerät eines Fahrzeugs
DE10213658B4 (de) * 2002-03-27 2005-10-13 Robert Bosch Gmbh Verfahren zur Datenübertragung zwischen Komponenten der Bordelektronik mobiler Systeme und solche Komponenten
DE10218050A1 (de) * 2002-04-23 2003-11-13 Zahnradfabrik Friedrichshafen Verfahren zur Überwachung und Fehlerdiagnose für Komponenten des Antriebsstrangs eines Kraftfahrzeugs
US20030217268A1 (en) * 2002-05-15 2003-11-20 Alexander Gantman System and method for using acoustic digital signature generator as oracle
US20040001593A1 (en) * 2002-06-28 2004-01-01 Jurgen Reinold Method and system for component obtainment of vehicle authentication
US7549046B2 (en) * 2002-06-28 2009-06-16 Temic Automotive Of North America, Inc. Method and system for vehicle authorization of a service technician
US7076665B2 (en) * 2002-06-28 2006-07-11 Motorola, Inc. Method and system for vehicle subassembly authentication of a component
US20040003234A1 (en) * 2002-06-28 2004-01-01 Jurgen Reinold Method and system for vehicle authentication of a subassembly
US7010682B2 (en) 2002-06-28 2006-03-07 Motorola, Inc. Method and system for vehicle authentication of a component
US20040003232A1 (en) * 2002-06-28 2004-01-01 Levenson Samuel M. Method and system for vehicle component authentication of another vehicle component
US7228420B2 (en) * 2002-06-28 2007-06-05 Temic Automotive Of North America, Inc. Method and system for technician authentication of a vehicle
US7131005B2 (en) * 2002-06-28 2006-10-31 Motorola, Inc. Method and system for component authentication of a vehicle
US7600114B2 (en) 2002-06-28 2009-10-06 Temic Automotive Of North America, Inc. Method and system for vehicle authentication of another vehicle
US7325135B2 (en) * 2002-06-28 2008-01-29 Temic Automotive Of North America, Inc. Method and system for authorizing reconfiguration of a vehicle
US20040003230A1 (en) * 2002-06-28 2004-01-01 Puhl Larry C. Method and system for vehicle authentication of a service technician
US7127611B2 (en) * 2002-06-28 2006-10-24 Motorola, Inc. Method and system for vehicle authentication of a component class
US7181615B2 (en) * 2002-06-28 2007-02-20 Motorola, Inc. Method and system for vehicle authentication of a remote access device
US7137142B2 (en) * 2002-06-28 2006-11-14 Motorola, Inc. Method and system for vehicle authentication of a component using key separation
US7137001B2 (en) * 2002-06-28 2006-11-14 Motorola, Inc. Authentication of vehicle components
DE10237698A1 (de) * 2002-08-15 2004-02-26 Volkswagen Ag Verfahren und Vorrichtung zur Übertragung von Daten
US7401352B2 (en) * 2002-08-30 2008-07-15 International Business Machines Corporation Secure system and method for enforcement of privacy policy and protection of confidentiality
US7240200B2 (en) 2002-09-26 2007-07-03 International Business Machines Corporation System and method for guaranteeing software integrity via combined hardware and software authentication
DE10245934A1 (de) * 2002-09-30 2004-04-08 Siemens Ag Automatisierungssystem sowie Verfahren zu dessen Betrieb
DE10255805A1 (de) * 2002-11-29 2004-06-09 Adam Opel Ag Verfahren zur Änderung der Programmierung eines Steuergerätes eines Kraftfahrzeuges
US6987922B2 (en) * 2002-12-05 2006-01-17 Tropic Networks Inc. Method and apparatus for controlling a variable optical attenuator in an optical network
DE10350647A1 (de) * 2003-10-29 2005-06-09 Francotyp-Postalia Ag & Co. Kg Verfahren und Anordnung zur mobilen Datenübertragung
CA2513909A1 (en) * 2003-01-22 2004-08-05 Francotyp-Postalia Ag & Co. Kg Method and device for mobile data transmission
ATE492085T1 (de) 2003-01-28 2011-01-15 Cellport Systems Inc Ein system und ein verfahren zum steuern des zugriffs von anwendungen auf geschützte mittel innerhalb eines sicheren fahrzeugtelematiksystems
DE10309507A1 (de) * 2003-03-05 2004-09-16 Volkswagen Ag Verfahren und Einrichtung zur Wartung von sicherheitsrelevanten Programmcode eines Kraftfahrzeuges
WO2004114131A1 (de) * 2003-06-24 2004-12-29 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher
DE10354107A1 (de) * 2003-07-04 2005-01-20 Bayerische Motoren Werke Ag Verfahren zur Authentifikation von insbesondere in ein Steuergerät eines Kraftfahrzeugs ladbaren Softwarekomponenten
JP2007527044A (ja) 2003-07-04 2007-09-20 バイエリッシェ　モートーレン　ウエルケ　アクチエンゲゼルシャフト 特に自動車の制御装置内にロード可能なソフトウェアコンポーネントを認証するための方法
KR101016466B1 (ko) * 2003-10-17 2011-02-24 트리나리 안라겐바우 게엠베하 오작동에 대해 보호되는 공작 기계 및 기계 제어파라미터에 의한 기계 오작동을 회피하는 방법
KR101261059B1 (ko) 2003-10-17 2013-05-06 트리나리 안라겐바우 게엠베하 나사곡면이 형성된 공작물을 제조하는 공작 기계용 중립데이터 컴퓨터 제어 시스템 및 부속 공작 기계
EP1740418B1 (de) * 2004-04-29 2012-06-13 Bayerische Motoren Werke Aktiengesellschaft Authentisierung einer fahrzeugexternen vorrichtung
US7346370B2 (en) * 2004-04-29 2008-03-18 Cellport Systems, Inc. Enabling interoperability between distributed devices using different communication link technologies
DE102004024624B4 (de) * 2004-05-18 2017-10-05 Volkswagen Ag Mit einer Verschlüsselung arbeitendes Verfahren zum Diebstahlschutz für ein Kraftfahrzeug und entsprechende Diebstahlschutzvorrichtung
JP2005336911A (ja) * 2004-05-28 2005-12-08 Mitsubishi Electric Corp 車両制御システム及びこれに用いる車載制御装置、携帯機
US20060020810A1 (en) * 2004-07-24 2006-01-26 International Business Machines Corporation System and method for software load authentication
US7660981B1 (en) * 2004-11-30 2010-02-09 Adobe Systems Incorporated Verifiable chain of transfer for digital documents
JP2006285849A (ja) * 2005-04-04 2006-10-19 Xanavi Informatics Corp ナビゲーション装置
DE102005030657B3 (de) * 2005-06-30 2006-11-16 Siemens Ag Codierverfahren und Codiereinrichtung zum Sichern eines Zählerstands eines Zählwerks vor einer nachträglichen Manipulation, sowie Prüfverfahren und Prüfeinrichtung zum Prüfen einer Authentizität eines Zählerstands eines Zählwerks
CN101243513A (zh) 2005-08-23 2008-08-13 皇家飞利浦电子股份有限公司 使用物理单向函数的信息载体鉴别
WO2007023657A1 (ja) 2005-08-26 2007-03-01 Mitsubishi Electric Corporation 情報記憶装置及び情報記憶プログラム及び検証装置及び情報記憶方法
US8145917B2 (en) * 2005-12-30 2012-03-27 Nokia Corporation Security bootstrapping for distributed architecture devices
CA2677148C (en) * 2007-02-02 2015-11-24 Telcordia Technologies, Inc. Method and system to authorize and assign digital certificates without loss of privacy
EP2137875B1 (en) * 2007-03-19 2016-03-16 Telcordia Technologies, Inc. Vehicle segment certificate management using shared certificate schemes
US20080263644A1 (en) * 2007-04-23 2008-10-23 Doron Grinstein Federated authorization for distributed computing
DE102007022100B4 (de) * 2007-05-11 2009-12-03 Agco Gmbh Kraftfahrzeugsteuergerätedatenübertragungssystem und -verfahren
US8027293B2 (en) * 2007-07-16 2011-09-27 Cellport Systems, Inc. Communication channel selection and use
US8627079B2 (en) 2007-11-01 2014-01-07 Infineon Technologies Ag Method and system for controlling a device
US8908870B2 (en) * 2007-11-01 2014-12-09 Infineon Technologies Ag Method and system for transferring information to a device
DE102007056662A1 (de) * 2007-11-24 2009-05-28 Bayerische Motoren Werke Aktiengesellschaft System zur Freischaltung der Funktionalität einer Ablaufsteuerung, die in einem Steuergerät eines Kraftfahrzeugs gespeichert ist
DE102007058975B4 (de) * 2007-12-07 2022-10-06 Bayerische Motoren Werke Aktiengesellschaft Bordnetz eines Kraftfahrzeugs mit einem Master Security Modul
JP2009194443A (ja) * 2008-02-12 2009-08-27 Ntt Data Corp 署名システム及び方法、ならびに、コンピュータプログラム
DE102008008969B4 (de) * 2008-02-13 2022-07-14 Bayerische Motoren Werke Aktiengesellschaft Bordnetz-System eines Kraftfahrzeugs mit einer Authentifizierungs-Vorrichtung
DE102008050406A1 (de) * 2008-10-04 2010-04-08 Bayerische Motoren Werke Aktiengesellschaft Datenübertragungsverfahren
US8521547B2 (en) * 2008-10-30 2013-08-27 International Business Machines Corporation Mechanic certification tracking validator
DE102008043830A1 (de) * 2008-11-18 2010-05-20 Bundesdruckerei Gmbh Kraftfahrzeug-Anzeigevorrichtung, Kraftfahrzeug-Elektroniksystem, Kraftfahrzeug, Verfahren zur Anzeige von Daten und Computerprogrammprodukt
DE102009025585B4 (de) * 2009-06-19 2012-08-16 Audi Ag Vorrichtung zur dezentralen Funktionsfreischaltung eines Steuergeräts
US10383629B2 (en) 2009-08-10 2019-08-20 Covidien Lp System and method for preventing reprocessing of a powered surgical instrument
US8397063B2 (en) * 2009-10-07 2013-03-12 Telcordia Technologies, Inc. Method for a public-key infrastructure for vehicular networks with limited number of infrastructure servers
DE102009053230A1 (de) * 2009-11-06 2011-05-12 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Autorisierung eines externen Systems auf einem Steuergerät eines Fahrzeugs, insbesondere eines Kraftfahrzeugs
CN101938520B (zh) * 2010-09-07 2015-01-28 中兴通讯股份有限公司 一种基于移动终端签名的远程支付系统及方法
CN103124654A (zh) * 2010-09-27 2013-05-29 日本电气株式会社 信息处理系统、用于检查车辆的方法和用于检查车辆的程序
JP5508216B2 (ja) * 2010-10-05 2014-05-28 日本特殊陶業株式会社 車両用電装部品の制御装置およびその制御方法
US9420458B2 (en) 2010-12-13 2016-08-16 Volkswagen Ag Method for the use of a mobile appliance using a motor vehicle
DE102011014688B3 (de) 2011-03-22 2012-03-22 Audi Ag Kraftwagen-Steuergerät mit kryptographischer Einrichtung
US20130261927A1 (en) * 2012-03-28 2013-10-03 Delphi Technologies, Inc. System and method to authenticate an automotive engine device
EP2672414A1 (en) * 2012-06-08 2013-12-11 Sodge IT GmbH Method for transferring configuration data to controller devices, a system and a computer program product
US9292463B2 (en) * 2012-09-26 2016-03-22 Intel Corporation Communication of device presence between boot routine and operating system
US9179311B2 (en) * 2013-10-04 2015-11-03 GM Global Technology Operations LLC Securing vehicle service tool data communications
DE102014017513A1 (de) * 2014-11-27 2016-06-02 Audi Ag Verfahren zum Betrieb eines Kraftfahrzeugs mit einem Diagnoseanschluss und Kraftfahrzeug
JP5879451B1 (ja) * 2015-04-20 2016-03-08 株式会社 ディー・エヌ・エー 車両を管理するシステム及び方法
US10320745B2 (en) * 2015-08-05 2019-06-11 Samsung Electronics Co., Ltd. Apparatus and method for transparent, secure element-based mediation of on-board diagnostic operations
KR101673310B1 (ko) * 2015-08-24 2016-11-07 현대자동차주식회사 인증서 기반의 차량 보안 접속 제어 방법 및 그를 위한 장치 및 시스템
DE102015220224A1 (de) 2015-10-16 2017-04-20 Volkswagen Aktiengesellschaft Verfahren zur geschützten Kommunikation eines Fahrzeugs
DE102016202527A1 (de) * 2016-02-18 2017-08-24 Robert Bosch Gmbh Recheneinheit für ein Kraftfahrzeug
US10728249B2 (en) * 2016-04-26 2020-07-28 Garrett Transporation I Inc. Approach for securing a vehicle access port
DE102016221108A1 (de) * 2016-10-26 2018-04-26 Volkswagen Aktiengesellschaft Verfahren zum Aktualisieren einer Software eines Steuergeräts eines Fahrzeugs
US10382562B2 (en) * 2016-11-04 2019-08-13 A10 Networks, Inc. Verification of server certificates using hash codes
US10530816B2 (en) * 2017-05-18 2020-01-07 Nio Usa, Inc. Method for detecting the use of unauthorized security credentials in connected vehicles
EP3679684B1 (en) 2017-09-29 2022-07-20 Huawei International Pte. Ltd. Securing outside-vehicle communication using ibc
EP3726438A1 (de) 2017-10-23 2020-10-21 Siemens Aktiengesellschaft Verfahren und steuersystem zum steuern und/oder überwachen von geräten
DE102017222879A1 (de) * 2017-12-15 2019-06-19 Volkswagen Aktiengesellschaft Vorrichtung, Verfahr, und Computerprogramm zum Freischalten von einer Fahrzeugkomponente, Fahrzeug-zu-Fahrzeug-Kommunikationsmodul
DE102018217065A1 (de) * 2018-10-05 2020-04-09 Audi Ag Steuervorrichtung zur Freischaltung zumindest einer Anwendungssoftware, Kraftfahrzeug und Verfahren zum Betreiben der Steuervorrichtung
US11546176B2 (en) * 2020-08-26 2023-01-03 Rockwell Collins, Inc. System and method for authentication and cryptographic ignition of remote devices
DE102020006075A1 (de) 2020-10-05 2022-04-07 Daimler Ag Verfahren zur Absicherung von gespeicherten Nutzdaten
US11727733B2 (en) * 2021-05-11 2023-08-15 Ford Global Technologies, Llc Enabling operator controls for machine operation

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5229648A (en) * 1989-08-10 1993-07-20 Autosafe International, Inc. Multi element security system
US5521815A (en) * 1992-01-31 1996-05-28 K.L.E. Irrevocable Trust Uniform system for verifying and tracking articles of value
JP2942837B2 (ja) * 1992-01-31 1999-08-30 株式会社セガ・エンタープライゼス セキュリティチェック方法及びゲーム装置並びにそれらに用いられる情報記憶媒体
US5689566A (en) * 1995-10-24 1997-11-18 Nguyen; Minhtam C. Network with secure communications sessions
US5883956A (en) * 1996-03-28 1999-03-16 National Semiconductor Corporation Dynamic configuration of a secure processing unit for operations in various environments
US5825877A (en) * 1996-06-11 1998-10-20 International Business Machines Corporation Support for portable trusted software
US6138236A (en) * 1996-07-01 2000-10-24 Sun Microsystems, Inc. Method and apparatus for firmware authentication
US5844986A (en) * 1996-09-30 1998-12-01 Intel Corporation Secure BIOS
US5903882A (en) * 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
DE19747827C2 (de) * 1997-02-03 2002-08-14 Mannesmann Ag Verfahren und Einrichtung zur Einbringung eines Dienstschlüssels in ein Endgerät
JP3913823B2 (ja) * 1997-02-10 2007-05-09 株式会社東海理化電機製作所 車両用始動許可装置
US5844896A (en) * 1997-02-26 1998-12-01 U S West, Inc. System and method for routing telephone calls
US6119226A (en) * 1998-01-06 2000-09-12 Macronix International Co., Ltd. Memory supporting multiple address protocols
JPH11282753A (ja) * 1998-03-06 1999-10-15 Internatl Business Mach Corp <Ibm> オブジェクトへのアクセス方法及び装置、オブジェクトへのアクセスを制御するプログラムを格納した記憶媒体
JPH11265349A (ja) * 1998-03-17 1999-09-28 Toshiba Corp コンピュータシステムならびに同システムに適用される機密保護方法、送受信ログ管理方法、相互の確認方法および公開鍵世代管理方法
DE19820605A1 (de) * 1998-05-08 1999-11-11 Giesecke & Devrient Gmbh Verfahren zur sicheren Verteilung von Software
US6138235A (en) * 1998-06-29 2000-10-24 Sun Microsystems, Inc. Controlling access to services between modular applications
US6105137A (en) * 1998-07-02 2000-08-15 Intel Corporation Method and apparatus for integrity verification, authentication, and secure linkage of software modules
US6463535B1 (en) * 1998-10-05 2002-10-08 Intel Corporation System and method for verifying the integrity and authorization of software before execution in a local platform
DE10008974B4 (de) * 2000-02-25 2005-12-29 Bayerische Motoren Werke Ag Signaturverfahren
US6490513B1 (en) * 2001-08-22 2002-12-03 Matsushita Electrical Industrial Co., Ltd. Automobile data archive system having securely authenticated instrumentation data storage
DE10141737C1 (de) * 2001-08-25 2003-04-03 Daimler Chrysler Ag Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels

Also Published As

Publication number Publication date
EP1127756B1 (de) 2005-04-27
DE10008973B4 (de) 2004-10-07
JP2001255953A (ja) 2001-09-21
DE50105995D1 (de) 2005-06-02
US7197637B2 (en) 2007-03-27
DE10008973A1 (de) 2001-09-06
EP1127756A2 (de) 2001-08-29
US20020023223A1 (en) 2002-02-21
EP1127756A3 (de) 2004-04-21

Similar Documents

Publication Publication Date Title
ES2237500T3 (es) Procedimiento de autorizacion con certificado.
ES2530229T3 (es) Procedimiento de firma
US11167723B2 (en) Method for access management of a vehicle
EP1325476B1 (en) Wireless lock system
JP4490477B2 (ja) トークン提供
US7600114B2 (en) Method and system for vehicle authentication of another vehicle
ES2835780T3 (es) Procedimiento para emitir una versión virtual de un documento
US7181615B2 (en) Method and system for vehicle authentication of a remote access device
RU2462827C2 (ru) Способ передачи данных и система тахографа
US20060255910A1 (en) Security device, vehicle authentication device, method and program
CN103338985B (zh) 用于车辆安全的方法和设备
KR102639075B1 (ko) 차량용 진단기 및 그 인증서 관리 방법
ES2301652T3 (es) Unidad de control.
US20090327760A1 (en) Tachograph
JPWO2009147734A1 (ja) 車両、メンテナンス装置、メンテナンスサービスシステム及びメンテナンスサービス方法
JP2009517939A (ja) 安全で再生保護された記憶装置
WO2004003812A2 (en) Method and system for authorizing reconfiguration of a vehicle
US7137142B2 (en) Method and system for vehicle authentication of a component using key separation
JP2006524377A (ja) 制御ユニット用のフラッシュウェアの正確性及び完全性を保証する方法
CN102301629A (zh) 鉴别通信会话和加密其数据的电路、系统、设备和方法
US7213267B2 (en) Method of protecting a microcomputer system against manipulation of data stored in a storage assembly of the microcomputer system
ES2401592T3 (es) Unidad de tacógrafo electrónico para vehículo automóvil
US20040003232A1 (en) Method and system for vehicle component authentication of another vehicle component
ES2237682T3 (es) Procedimiento y dispositivo de certificacion de una transaccion.
CN115776396A (zh) 数据处理方法、装置、电子设备及存储介质