ES2530229T3 - Procedimiento de firma - Google Patents

Procedimiento de firma Download PDF

Info

Publication number
ES2530229T3
ES2530229T3 ES01101343.0T ES01101343T ES2530229T3 ES 2530229 T3 ES2530229 T3 ES 2530229T3 ES 01101343 T ES01101343 T ES 01101343T ES 2530229 T3 ES2530229 T3 ES 2530229T3
Authority
ES
Spain
Prior art keywords
software
key
vehicle
control device
control apparatus
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
ES01101343.0T
Other languages
English (en)
Inventor
Ernst Schmidt
Burkhard 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 ES2530229T3 publication Critical patent/ES2530229T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Program-control systems
    • G05B19/02—Program-control systems electric
    • G05B19/04—Program control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Program control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0426—Programming the control sequence
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/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
    • 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/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
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/23—Pc programming
    • G05B2219/23305—Transfer program into prom with passwords
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/24—Pc safety
    • G05B2219/24155—Load, enter program if device acknowledges received password, security signal
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/24—Pc safety
    • G05B2219/24159—Several levels of security, passwords
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/24—Pc safety
    • G05B2219/24167—Encryption, password, user access privileges
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/26—Pc applications
    • G05B2219/2637—Vehicle, car, auto, wheelchair
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Automation & Control Theory (AREA)
  • Storage Device Security (AREA)
  • Combined Controls Of Internal Combustion Engines (AREA)
  • Stored Programmes (AREA)

Abstract

Procedimiento para securizar 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 del aparato de control un software que influye en el funcionamiento del aparato de control, caracterizado por los pasos de habilitar un par de claves para el cifrado y descifrado de datos electrónicos, archivar una primera clave en o para un aparato de control del vehículo automóvil, firmar con la segunda clave un software que se quiere cargar, cargar el software firmado en la memoria del aparato de control, comprobar la firma del software por medio de la clave archivada en o para el aparato de control y aceptar el software cargado cuando la comprobación se desarrolle con un resultado positivo, añadir al software al menos una información individual de un vehículo que contiene el aparato de control, firmar el software juntamente con la al menos una información individual del vehículo, por que, aparte de la comprobación de la firma del software, se comprueba también la información individual del vehículo, por que se acepta el software en el aparato de control solamente cuando la información individual de vehículo del software coincide con la del vehículo, y por que la firma depende de la información individual del vehículo contenida en el software.

Description

5
10
15
20
25
30
35
40
45
50
E01101343
10-02-2015
DESCRIPCIÓN
Procedimiento de firma.
La invención concierne a un procedimiento para securizar 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 y con un vehículo crecen también los requisitos que tienen que imponerse a la seguridad.
En las muy diferentes zonas del vehículo se utilizan microcontroladores de mando. Estos aparatos de control están unidos hoy en día frecuentemente uno con otro a través de un sistema de bus y existen generalmente posibilidades (por ejemplo enlace de diagnosis) para acceder desde fuera a este bus y para 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á archivado casi siempre en una memoria no programable (por ejemplo, en microprocesadores programados con máscara). Por tanto, no se puede realizar sin ciertas dificultades una manipulación del software. Por ejemplo, se puede reconocer el cambio completo de un módulo de memoria por otro módulo de memoria y reaccionar a este cambio de una manera correspondiente.
Sin embargo, debido a la utilización futura, en el vehículo, de aparatos de control programables, especialmente los llamados aparatos de control programables flash, se hace mayor el peligro de que se realicen manipulaciones no autorizadas en el software y, por tanto, en el funcionamiento de los aparatos de control. Así, el cambio de software por parte de personas no autorizadas podría llevarse a cabo de manera sencilla mediante una nueva programación con poco coste.
Sin embargo, por motivos de seguridad y para cumplir con los requisitos legales se tienen que adoptar medidas que impidan una variación del software original o autoricen esta variación solamente a personas autorizadas.
Por lo demás, en el futuro se podría manifestar como ventajoso perseguir un concepto de piezas iguales, en el que se emplea un mismo hardware en modelos diferentes. La diferencia en el funcionamiento reside entonces solamente en el software. En este concepto existe ciertamente la necesidad de que un determinado software solamente pueda ejecutarse en un vehículo individual y no pueda ser copiado de una manera sencilla.
Se conocen por el estado de la técnica un gran número de procedimientos y dispositivos de autentificación.
Así, en el documento US 5,844,986 se describe un procedimiento que se emplea para evitar una intervención no permitida 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 BIOS basándose en un llamado procedimiento de clave pública con una clave pública y una clave secreta. La comprobación se efectúa en este caso mediante una comprobación de una firma digital incrustada en el software que se quiere cargar.
Se conoce por el documento EP 0 816 970 un dispositivo para comprobar un software de empresa. Este dispositivo para autentificar una memoria PROM de arranque comprende una parte de memoria con un microcódigo. Un sector de autentificación comprende un generador hash que genera datos hash en respuesta a la ejecución del microcódigo.
El documento EP-A-0 939 012 propone un procedimiento para verificar la coherencia de informaciones que se cargan, a través de un aparato de carga remota, en un ordenador para controlar el funcionamiento de un equipo funcional de un automóvil. En este caso, el ordenador calcula una palabra de validación en base a las informaciones y compara la palabra de validación con una palabra de validación correspondiente almacenada en el ordenador de manera inaccesible para el aparato de carga remota. Para la verificación, el ordenador comprueba si la palabra de validación calculada por el ordenador coincide con la palabra de validación almacenada en el ordenador.
Sin embargo, con los procedimientos o dispositivos anteriores no es posible realizar directamente la comprobación de un software que se quiera cargar en un aparato de control de un vehículo automóvil.
El problema de la presente invención consiste en proporcionar un procedimiento para securizar la carga de un software auténtico en un aparato de control de un vehículo automóvil.
El problema se resuelve con las características de la reivindicación 1.
Según ésta, se genera primeramente un par de claves para el cifrado y descifrado de datos electrónicos. Por claves se entienden aquí en general parámetros de codificación y/o descodificación que son conocidos por algoritmos criptográficos en sí conocidos.
10
15
20
25
30
35
40
45
50
55
E01101343
10-02-2015
En el presente caso, el software es provisto de una firma (signatura) electrónica por medio de la primera clave. Para verificar la autenticidad del software se ha archivado una segunda clave correspondiente en o para el aparato de control en el cual deberá cargarse este software. Con esta segunda clave se puede comprobar la firma electrónica del software. Si la comprobación se desarrolla positivamente, se acepta entonces el software y éste puede ser aprovechado para controlar el aparato de control.
Como cifrado puede emplearse según una primera forma de realización un llamado procedimiento simétrico en el que ambas claves son idénticas. Por tanto, se trata aquí realmente de una sola clave que se emplea en sitios diferentes. Sin embargo, dado que tiene que contarse siempre con posibilidades de que se conozca una clave archivada en un aparato de control, el nivel de seguridad de un procedimiento simétrico no es óptimo. Por tanto, este procedimiento puede utilizarse únicamente cuando no están afectados procesos demasiados críticos para la seguridad. Para aumentar el nivel de seguridad se puede emplear una protección contra disparo adicional en forma de un hardware especial.
Según otra forma de realización preferida, se elige un procedimiento de cifrado asimétrico con una clave secreta y una clave pública. En este caso, la clave pública puede estar archivada en o para el aparato de control. Con la clave secreta se firmaría entonces el software. Como alternativa, el aparato de control o el propio vehículo puede generar también el par de claves asíncrono y archivar luego la clave secreta en el aparato de control. La clave pública tendría que ser entonces legible de modo que se pueda firmar con ella un software. Naturalmente, en la última alternativa habría que asegurarse de que la clave secreta no sea legible.
Los algoritmos de cifrado con una clave secreta y una clave pública consisten en un llamado procedimiento de clave pública en el que la clave pública deberá ser públicamente conocida, mientras que la clave secreta es conocida solamente por un sitio autorizado, por ejemplo un centro de confianza. Tales algoritmos criptográficos son, por ejemplo, el algoritmo de Rivest, Shamir y Adleman (algoritmo RSA), un algoritmo de encriptado de datos (algoritmo DEA) y algoritmos similares. Con la clave secreta o la clave pública se puede generar – análogamente a la firma manuscrita – una firma digital para un documento electrónico. Solamente el propietario de la clave secreta o pública puede confeccionar una firma válida. La autenticidad del documento puede comprobarse después mediante la verificación de la firma por medio de la clave pública o secreta correspondiente. La clave secreta se denomina a veces también clave privada.
Un tercero no autorizado que no conozca la clave correcta no está en condiciones de proveer una firma válida. Si se carga entonces en un aparato de control un software manipulado y no firmado correctamente, esto es reconocido con la clave correspondiente y el aparato de control es puesto, por ejemplo, en un estado de incapacitado para funcionar.
Según otra forma de realización de la invención, se archiva la clave en el sector de arranque del aparato de control. El sector de arranque está casi siempre protegido de una manera especial y no puede sobrescribirse sin mayores dificultades. Según un perfeccionamiento, el sector de arranque puede ser “bloqueado” después de la inscripción y el ingreso de la clave, de modo que ya no sea posible un acceso adicional, especialmente una inscripción adicional. Se aseguraría así que la clave archivada en el sector de arranque estuviera protegida contra manipulación.
Para satisfacer los requisitos de una utilización de un software exclusivamente individual para un 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 del chasis 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, dicho software es firmado entonces con la clave prevista para ello. Un aparato de control acepta – como se ha descrito anteriormente – el software únicamente cuando se reconoce la firma como impecable con la otra clave asociada. Dado que la firma depende de la información individual del vehículo contenida en el software, ésta no pueda variarse posteriormente. Un software apto para ser ejecutado por un aparato de control de un vehículo puede alimentarse únicamente cuando no se haya variado la información individual del vehículo y ésta coincida realmente con la del vehículo. Por tanto, es imposible que un software individualizado de esta manera para un vehículo sea copiado en otro vehículo, ya que la información individual del vehículo no puede ser variada sin vulnerar la firma.
Para no tener que realizar una comprobación del software cada vez que se arranca un vehículo y se activan los aparatos de control, se realiza una comprobación de esta clase preferiblemente al menos durante la operación de carga. En el caso de un software impecablemente firmado, éste puede caracterizarse entonces de manera correspondiente, por ejemplo colocando en el aparato de control una bandera que no deberá ser influenciada en otras ocasiones. Después de la colocación de esta bandera el software queda aceptado también para otras activaciones. De esta manera, se pueden evitar retardos en el arranque normal del vehículo. Sin embargo, hay que asegurarse en este caso de que esta bandera no pueda ser influenciada desde fuera.
Para crear otro nivel de seguridad al cargar un software en las memorias del aparato de control, deberá ser posible según otra forma de realización de la invención, antes de la carga del software, un acceso a la memoria del aparato de control solamente con una autorización correspondiente. A este fin, antes del traspaso del software firmado está
10
15
20
25
30
35
40
45
50
E01101343
10-02-2015
prevista una “apertura” del aparato de control en un paso de solicitud. Cuando se emplean niveles de acceso diferentes en la solicitud, se podrían adjudicar, además, derechos de acceso diferentemente configurados. En el caso de un acceso de diagnóstico sería necesaria primeramente, por ejemplo, una solicitud, con lo cual el aparato de control reconoce a través de la información de acceso ingresada los derechos de acceso y el nivel de autorización ligado a ellos. Según la adjudicación de derechos, las autorizaciones de acceso pueden clasificarse desde no críticas hasta muy críticas. Según una forma de realización, se pide un código al aparato de control y se comprueba la validez de éste. A este fin, puede generarse, por ejemplo, en el aparato de control un número aleatorio que se devuelve después por el accedente en forma procesada, por ejemplo codificado o firmado de otra manera. En el aparato de control se comprueba entonces esta información, por ejemplo por medio de una clave de autentificación propia.
Es posible también configurar dinámicamente la adjudicación de derechos de acceso. Por ejemplo, se pueden proveer certificados de acceso de cuyas informaciones se desprenda el nivel de acceso. Si se acepta entonces un certificado de acceso, lo que puede ocurrir a su vez por la comprobación de una firma con una clave, se conceden entonces los derechos listados en el mismo.
Un aparato de control eventualmente previsto en exclusiva para el control de acceso no deberá estar dispuesto en forma libremente accesible en el vehículo frente a los restantes aparatos de control a causa de la función de seguridad central relativa a la adjudicación de derechos de autentificación, ya que mediante el desmontaje físico de un aparato de control se podrían esquivar los mecanismos de protección anteriormente descritos. Por tanto, es deseable una protección especial contra desmontaje, por ejemplo mecánica, de un aparato de control de seguridad de esta clase.
Además, se puede conseguir también un nivel de seguridad especial mediante la configuración de un conjunto de aparatos de control en el que están mutuamente conectados aparatos de control diferentes y éstos se condicionan unos a otros o se comprueban mutuamente.
Para excluir también el peligro de que se desmonte un aparato de control individual y se le sustituya por otro, puede ser conveniente, además, una protección propia contra desmontaje de los aparatos de control. A este fin, se realiza esporádicamente una prueba de autenticidad de los aparatos de control, por ejemplo en un vehículo en el que están integrados los aparatos de control. A este fin, se dirige una consulta a los aparatos de control, a la que éstos tienen que contestar con una información esperada determinada. Si la información realmente entregada por el aparato de control a comprobar no coincide con la información esperada o el aparato de control no contesta, se adoptan entonces unas medidas de securización adecuadas. En el caso de aparatos de control no críticos para la seguridad, el aparato de control puede ser excluido, por ejemplo, del conjunto de comunicación. Cuando el aparato de control es importante para el funcionamiento del vehículo, éste es entonces, por ejemplo, registrado, marcado o inscrito en una lista, de modo que al menos pueda comprenderse la manipulación en materia de software realizada en el respectivo aparato de control. En una forma de realización los aparatos de control tienen que contestar a la consulta por medio de una clave de autentificación secreta. Un aparato de control ilegalmente cambiado no dispone de esta clave y es entonces reconocido y tratado de manera correspondiente.
La presente invención se explica seguidamente con más detalle ayudándose de ejemplos de realización y con referencia a los dibujos adjuntos. Los dibujos muestran en:
La figura 1, una representación esquemática de una estructura de aparato de control en un vehículo,
La figura 2a y la figura 2b, una representación esquemática del desarrollo de una firma digital de un software y su comprobación,
La figura 3a y la figura 3b, una representación del desarrollo de la firma digital del software de la figura 2, pero en otro modo de representación,
La figura 4, una representación del desarrollo de la provisión de una firma por un centro de confianza,
La figura 5, una representación de un algoritmo para un procedimiento de comprobación especial de informaciones individuales de un vehículo,
Las figuras 6a y 6b, un diagrama de bloques y de desarrollo para una autentificación con respecto a un aparato de control y
La figura 7, un diagrama de desarrollo para la realización de una inscripción de un software en un aparato de control.
En la figura 1 se representa en forma de diagrama de bloques una estructura de aparato de control con unidades conectadas en red unas con otras. La red de a bordo está constituida aquí por varias redes parciales (LWL-Most, sistema K-CAN, Powertrain-CAN, etc.) que poseen en parte velocidades de transmisión diferentes y que están unidas una con otra por medio de las llamadas pasarelas (módulo de pasarela central, pasarela de controlador).
10
15
20
25
30
35
40
45
50
55
E01101343
10-02-2015
Un bus de diagnóstico 16 está conectado directa o indirectamente con todas las demás redes por medio de la pasarela central 14. El bus de diagnóstico 16 representa uno de los enlaces más importantes con el entorno. A través de un testador de diagnóstico, que está conectado a una caja de enchufe OBD 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 el sistema completo.
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 del vehículo. Es posible así en principio un acceso remoto a la red de 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 abonados restantes del bus del vehículo.
En el bus del vehículo está integrado un sistema de acceso al coche (CAS) 22 que vigila la entrada en el vehículo. Incluye como función adicional un inmovilizador electrónico.
Una pasarela de controlador 21 representa una interfaz entre un reproductor de CDs y la red de a bordo. En la pasarela de controlador 21 se convierten también en mensajes las órdenes de entrada que imparte el conductor a través de los diferentes instrumentos, y estos mensajes se retransmiten a los respectivos aparatos de control activados.
Además, se representan varios aparatos de control (STG1 a STG5). El cometido de un aparato de control no solo consiste en el control de una unidad determinada en el 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”. Un generador de informaciones, que ha obtenido el acceso al bus, envía en principio sus informaciones a todos los aparatos de control. Se escucha para ello permanentemente el bus de datos que está unido con el controlador. Por el contrario, en la 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 predominantemente en el futuro en una memoria programable, por ejemplo una memoria flash. En una programación flash solo se pueden borrar e inscribir de nuevo bloques completos. No es posible el borrado de bits individuales. Según los aparatos de control, se utilizan diferentes clases de microordenadores. Según los requisitos, éstos 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 en la placa electrónica o directamente integrada en el procesador.
El desarrollo de una securización de la integridad de los datos de un software para un aparato de control con una memoria flash se representa seguidamente con más detalle ayudándose de las figuras 2a y 2b.
En primer lugar, en un primer paso se proporciona por un único sitio autorizado, por ejemplo en un llamado centro de confianza, un par de claves constituido por una clave pública 58 y una clave secreta 52. Una clave es aquí un código electrónico con el que se puede cifrar y/o descifrar una información. Por ejemplo, se emplean en este caso unos algoritmos criptográficos conocidos, como los algoritmos RSA o DEA ya mencionados anteriormente, es decir, los llamados “algoritmos de clave pública” con pares de claves síncronos.
Se entrará primero en más detalles sobre el cifrado empleado. En el presente procedimiento de autentificación se prefiere un cifrado asíncrono. En el caso de claves simétricas, cada lado tiene que estar en posesión del “secreto”. Tan pronto como una clave síncrona, además de ser conocida por los sitios autorizados, es conocida también por terceros, no puede garantizarse una precaución de securización perfecta. Sin embargo, dado que en el presente procedimiento tiene que estar archivada en el aparato de control de un vehículo automóvil una clave del par de claves y, por tanto, no puede asegurarse el mantenerla en secreto, no es aconsejable la elección de un par de claves simétrico.
En contraste con el 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 secreta se puede realizar una firma de un documento electrónico. Esta firma es singular y en general no puede ser comprendida. Con la clave pública se puede comprobar la firma.
El procedimiento de clave pública tiene la ventaja de que una clave del par de claves puede ser públicamente conocida. Sin embargo, dado que los procedimientos de clave pública actualmente conocidos son muy intensivos en cálculo, 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 entre las partes comunicantes una clave simétrica por medio de un procedimiento de clave pública. La comunicación propiamente dicha es cifrada entonces con la clave simétrica.
Debido a la separación de las claves secreta y pública se pueden materializar procedimientos de autentificación y firmas digitales como se ha descrito anteriormente. Gracias a la posesión de la clave secreta se puede verificar unívocamente una identidad y se puede proveer una firma como en el caso de una firma manuscrita. Un
10
15
20
25
30
35
40
45
50
E01101343
10-02-2015
criptosistema de clave pública conocido es el procedimiento RSA ya mencionado anteriormente. Otros criptoprocedimientos de clave pública se basan en problemas en determinados grupos matemáticos para calcular logaritmos (problema de logaritmos discretos).
Para firmar digitalmente un documento, el único sitio autorizado cifra el documento con la clave secreta y agrega un valor de firma al documento. Para la verificación de la firma se descifra la firma con la clave pública y se compara el valor resultante con el valor del documento original. Si coinciden ambos valores del documento, la firma es entonces válida y se puede aceptar el software.
En el presente caso, una respectiva clave pública es almacenada por el sitio autorizado durante la producción de un vehículo en cada aparato de control del vehículo que deba ser modificado respecto del software (por ejemplo, el aparato de control de la caja de cambios).
Un cliente pide ahora a un distribuidor 100 (véase la figura 4) una función adicional determinada para su vehículo automóvil, por ejemplo una característica de cambio determinada para la selección de las etapas de multiplicación. Esta función puede materializarse por la carga de un nuevo software en el aparato de control de la caja de cambios del respectivo vehículo.
El distribuidor 100 proporciona seguidamente un software correspondiente 150 y lo envía, junto con el número de chasis del vehículo del cliente, al centro de confianza 104, que es el único autorizado para firmar (signar) este software. En el centro de confianza 104 se firma con la clave secreta el software juntamente con el número de chasis transmitido.
Este modo de proceder está representado también en la figura 2a (software 50, clave secreta 52), pero no se transmite aquí ningún número de chasis.
El software firmado 106 (véanse la figura 4 y el símbolo de referencia 56 en la figura 2a) se retransmite entonces al distribuidor 100, el cual lo puede cargar en el vehículo automóvil 12 del cliente.
La transmisión al centro de confianza 100, la operación de firma y la retransmisión pueden efectuarse con relativa rapidez por vía electrónica.
En el paso siguiente se carga el software firmado 56, 106, por parte del distribuidor 100, en el vehículo 12, o mejor en el aparato de control de la caja de cambios. La transmisión puede efectuarse a través del enchufe de diagnóstico y el bus de diagnóstico 16. Como alternativa, se puede efectuar también una carga controlada a distancia a través de la red GSM.
Durante la carga se efectúa primeramente una solicitud e identificación del distribuidor (véase el paso 500 en la figura 7). El distribuidor 100 envía para ello una dirección del aparato de control y un indicativo correspondiente al vehículo. En el caso de una identificación satisfactoria, se conecta el aparato de control (aquí: el aparato de control de la caja de cambios) dejándolo preparado para la inscripción del nuevo software. Es así posible la inscripción (también grabación en memoria flash) de un software nuevo en el aparato de control (véase 502 en la figura 7). Después de la carga del nuevo software en el aparato de control, el distribuidor 100 ha hecho su parte de la tarea.
En la operación siguiente el aparato de control 24 (figura 2), al ser activado, comprueba la firma del nuevo software cargado 56 por medio de la clave pública 58. Esto se explicará con detalle ayudándose de la figura 2b. Con la clave pública 58 se determina a partir de la firma en una unidad 60 del aparato de control 24 una magnitud que tiene que coincidir con el documento electrónico 62 que ha sido cifrado. Esta coincidencia se comprueba en un comparador
64. Cuando existe una coincidencia, se acepta el software cargado 50 y se hace funcionar el aparato de control 24 con este software. Si no existe coincidencia alguna, se marca el aparato de control 24 y se le archiva en una lista. En un diagnóstico se pueden recuperar después los datos de esta lista. Se proporciona entonces una nueva oportunidad para cargar un software correcto. Si no se carga un software correctamente firmado, el vehículo no puede seguir funcionando.
En las figuras 3a y 3b se han representado con algo más de precisión el cifrado y el descifrado. Durante la firma del software no se firma todo el software. Esto sería ineficiente. Por el contrario, se genera a partir del software, a través de una función hash en sí conocida, un llamado código hash 51 que consiste en una información digital de una longitud prefijada. Según las necesidades de seguridad, se puede elegir una longitud de, por ejemplo, 16 bits, 64 bits
o 128 bits. Se firma entonces únicamente este código hash 51 (firma 54) y se agrega la firma al software 50. La firma del código hash es sensiblemente más eficiente que la firma de documentos de software largos.
Las funciones hash tienen entonces las siguientes propiedades esenciales: Es difícil encontrar para un valor hash dado un valor M de un documento (función unidireccional). Además, es difícil encontrar una colisión, es decir, dos valores con M y M’ en los que sean iguales los valores hash (resistencia a las colisiones).
Durante la comprobación de la firma 50 se obtiene, aplicando la clave pública a la firma (símbolo de referencia 53 en la figura 3b), un valor hash 51’ con el que se compara el valor hash real 51 del software 50 en un comparador 66. Si
10
15
20
25
30
35
40
45
50
55
E01101343
10-02-2015
coinciden ambos valores hash, se acepta el software 50. Se trata entonces de un software auténtico y el aparato de control puede hacerse funcionar con el software cargado. Si la comparación no es positiva, el aparato de control interrumpe su funcionamiento y espera hasta que haya sido cargado un software irreprochable con una firma correcta.
Aparte del desarrollo de autentificación anteriormente descrito se emplea frecuentemente también un llamado procedimiento de desafío-respuesta para la autentificación de una parte comunicante A frente a una parte comunicante B. En este caso, B envía primero a A un número aleatorio RND. A firma este número aleatorio por medio de su clave secreta y como respuesta envía a B este valor. B verifica la respuesta por medio de su clave pública y comprueba la autentificación de A.
Una autentificación de esta clase está representada en las figuras 6a y 6b. En la figura 6a se representa el bucle de comunicación entre un testador de diagnóstico y un aparato de control. En la autentificación según el procedimiento de desafío-respuesta un usuario envía primeramente por medio del testador de diagnóstico una información con un nivel de acceso determinado LI al aparato de control y solicita al aparato de control un número aleatorio (paso 400). El aparato de control contesta con la transmisión de un número aleatorio (paso 402). En el testador de diagnóstico se firma el número aleatorio con una clave secreta y después se envía el resultado nuevamente al aparato de control (paso 404). En el aparato de control se determina nuevamente el número aleatorio a partir de la firma con ayuda de la clave pública. Si el número así calculado coincide con el número aleatorio previamente transmitido por el aparato de control, se libera el acceso para este usuario con la etapa de seguridad deseada durante el periodo de tiempo del procedimiento de diagnóstico. Por tanto, el usuario, con una clasificación de seguridad correspondiente, puede inscribir un software en la memoria de un aparato de control.
A continuación, se describe la individualización del software para un vehículo determinado. Ya al hacer referencia al proceso de firma según la figura 4 se mencionó que se transmite con el software una identificación del vehículo que corresponde únicamente a un vehículo determinado. Se firma entonces el software juntamente con la identificación del vehículo (por ejemplo, el número del chasis) y se reenvía el paquete al distribuidor. La firma entra entonces en el código hash (descrito en la forma de realización según las figuras 3a y 3b) e influye también decisivamente sobre la firma.
El aparato de control acepta solamente – como ya se ha descrito antes – un software correctamente firmado. Si la firma es correcta, se comprueba también si la identificación de vehículo asociada al software coincide realmente con la del vehículo. Si ocurriera esto, se liberaría entonces el software. Con este modo de proceder se puede emplear el software individualizado de vehículo solamente 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 una individualización de un software, el número del chasis deberá ser incorporado ya durante la fabricación en los aparatos de control correspondiente de una manera no manipulable. El número del chasis tiene que estar presente todavía en el aparato de control incluso después de un borrado de una memoria. Esto puede materializarse registrando el número del chasis en una memoria no volátil y no recambiable, por ejemplo en el sistema de acceso al coche ya mencionado más arriba y especialmente protegido.
El modo de proceder siguiente según la figura 5 asegura una consulta no manipulable. Además del número del chasis, se necesita otro par de claves individual del vehículo consistente en una clave secreta IFSs y una clave pública IFSp. La asociación del número del chasis y las dos claves se efectúa en un puesto central, es decir, en el centro de confianza. La clave secreta IFSs está almacenada en un sistema 210 de acceso al coche, concretamente en forma no legible.
El número del chasis ya se encuentra también hoy en la zona de acceso del sistema 210 de acceso al coche.
En el nuevo software que se debe cargar se archiva ahora también, además del número del chasis, la clave pública IFSp 202 individual del vehículo (paso 200 en la figura 5). Seguidamente, se securiza todo el software en el centro de confianza por medio de la firma 204. Después de la carga del software en el aparato de control se comprueba primeramente la naturaleza correcta de la firma 204.
Seguidamente, el aparato de control 206 comprueba, por medio de la consulta de desafío-respuesta anteriormente descrita, si el número de chasis incluido en el software coincide con el del vehículo. A este fin, el aparato de control 206 envía el número de chasis FGNsw contenido en el software y un número aleatorio RANDOM al sistema 210 de acceso al coche. El número de chasis almacenado FGN es comparado allí con el número de chasis recibido FGNsw. A continuación, se firman los dos valores con la clave secreta IFSs y se les reenvía nuevamente al aparato de control 206. El aparato de control 206 puede comprobar ahora con la clave pública IFSp el envío firmado y comparar los valores obtenidos con el valor de desafío que se envió al principio al sistema de acceso al coche. Si coincide los valores, se puede aceptar entonces el software (paso 216, o.k.). En caso contrario, no se acepta el software (paso 218, no).
Como variante de este procedimiento, en lugar de un par de claves individual IFSs y IFSp se puede emplear también
E01101343
10-02-2015
un par de claves correspondiente, no individualizado para el vehículo, que esté ya almacenado en el vehículo. Se suprime así la administración de esta clave. Asimismo, es posible, naturalmente, un mecanismo correspondiente con un procedimiento criptográfico simétrico. Esto tiene ciertamente ventajas de procesamiento, pero trae consigo el peligro de la extracción de la clave asimétrica de los aparatos de control.
Naturalmente, en todos los procedimientos anteriormente citados hay que asegurarse absolutamente de que las claves secretas del centro de confianza permanezcan también secretas. En conjunto, la criptografía antes citada ofrece una buena posibilidad de cargar solamente el software correcto en vehículos o en determinados vehículos y, por tanto, prevenir manipulaciones no autorizadas.

Claims (19)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    REIVINDICACIONES
    1. Procedimiento para securizar 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 del aparato de control un software que influye en el funcionamiento del aparato de control, caracterizado por los pasos de
    habilitar un par de claves para el cifrado y descifrado de datos electrónicos,
    archivar una primera clave en o para un aparato de control del vehículo automóvil,
    firmar con la segunda clave un software que se quiere cargar,
    cargar el software firmado en la memoria del aparato de control,
    comprobar la firma del software por medio de la clave archivada en o para el aparato de control y aceptar el software cargado cuando la comprobación se desarrolle con un resultado positivo,
    añadir al software al menos una información individual de un vehículo que contiene el aparato de control,
    firmar el software juntamente con la al menos una información individual del vehículo,
    por que, aparte de la comprobación de la firma del software, se comprueba también la información individual del vehículo, por que se acepta el software en el aparato de control solamente cuando la información individual de vehículo del software coincide con la del vehículo, y
    por que la firma depende de la información individual del vehículo contenida en el software.
  2. 2.
    Procedimiento según la reivindicación 1, caracterizado por que se emplea un par de claves asimétrico en el que ambas clases son iguales.
  3. 3.
    Procedimiento según la reivindicación 1, caracterizado por que se emplea un par de claves asimétrico con una clave secreta y una clave pública.
  4. 4.
    Procedimiento según la reivindicación 3, caracterizado por que la clave pública está archivada en o para el aparato de control y se firma el software con la clave secreta.
  5. 5.
    Procedimiento según la reivindicación 3, caracterizado por que el vehículo, especialmente el o un aparato de control del vehículo, genera un par de claves síncrono, por que se archiva la clave secreta en el vehículo, especialmente en un aparato de control, y por que se puede extraer del vehículo la clave pública para firmar un software.
  6. 6.
    Procedimiento según cualquiera de las reivindicaciones anteriores, caracterizado por que la clave archivada en el aparato de control se archiva en el sector de arranque de un ordenador.
  7. 7.
    Procedimiento según la reivindicación 6, caracterizado por que el sector de la rutina de arranque se bloquea después de la inscripción y el ingreso de la clave y está así protegido contra un acceso adicional, especialmente un acceso de inscripción.
  8. 8.
    Procedimiento según cualquiera de las reivindicaciones anteriores, caracterizado por que se reproduce primeramente el software sobre una información de longitud determinada y se firma luego esta información.
  9. 9.
    Procedimiento según la reivindicación 8, caracterizado por que se elige como función de reproducción una función hash.
  10. 10.
    Procedimiento según la reivindicación 1, caracterizado por que se genera un par de claves propio (par de claves individual del vehículo) para comprobar la información individual del vehículo, estando presentes en una unidad de seguridad del vehículo la información individual del vehículo y una primera clave del par de claves propio, estando archivada también en el software, junto a la información individual del vehículo, la segunda clave del par de claves propio y comprobándose en una rutina separada en el vehículo si coinciden las dos claves del par de claves propio, para aceptar, en caso afirmativo, el software cargado.
  11. 11.
    Procedimiento según cualquiera de las reivindicaciones anteriores, caracterizado por que se comprueba el software al menos durante la primera activación del aparato de control y se le marca entonces de manera correspondiente.
  12. 12.
    Procedimiento según cualquiera de las reivindicaciones anteriores, caracterizado por que, en caso de un acceso externo al aparato de control, una unidad de acceso comprueba si existe una autorización para el acceso.
    9
  13. 13.
    Procedimiento según la reivindicación 12, caracterizado por que se solicita un código a un aparato de control y se comprueba la naturaleza correcta de este código.
  14. 14.
    Procedimiento según la reivindicación 12 ó 13, caracterizado por que un aparato de control emite un número
    aleatorio que ha de ser firmado por el accedente, y por que se comprueba la firma en el aparato de control, 5 especialmente por medio de una clave de autentificación.
  15. 15.
    Procedimiento según cualquiera de las reivindicaciones 12 a 14, caracterizado por que, al consultar la autorización de acceso, se verifica un nivel de autorización y se aceptan o no se aceptan acciones de acceso en función del nivel de autorización.
  16. 16.
    Procedimiento según cualquiera de las reivindicaciones anteriores, caracterizado por que un equipo de
    10 seguridad realiza en un vehículo al menos esporádicamente una comprobación de autentificación de un aparato de control y registra el aparato de control en caso de resultado negativo.
  17. 17. Procedimiento según la reivindicación 16, caracterizado por que en el aparato de control está archivado un código secreto individual de dicho aparato de control.
  18. 18. Procedimiento según la reivindicación 16 o 17, caracterizado por que el equipo de seguridad consulta una 15 característica específica del aparato de control y comprueba la autenticidad de ésta.
  19. 19. Procedimiento según cualquiera de las reivindicaciones 16 a 18, caracterizado por que se emplea en la comprobación de autenticidad una clave archivada en el equipo de seguridad y/o una clave archivada en el aparato de control.
    10
ES01101343.0T 2000-02-25 2001-01-22 Procedimiento de firma Expired - Lifetime ES2530229T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10008974A DE10008974B4 (de) 2000-02-25 2000-02-25 Signaturverfahren
DE10008974 2000-02-25

Publications (1)

Publication Number Publication Date
ES2530229T3 true ES2530229T3 (es) 2015-02-27

Family

ID=7632446

Family Applications (1)

Application Number Title Priority Date Filing Date
ES01101343.0T Expired - Lifetime ES2530229T3 (es) 2000-02-25 2001-01-22 Procedimiento de firma

Country Status (5)

Country Link
US (1) US6816971B2 (es)
EP (1) EP1128242B1 (es)
JP (1) JP4733840B2 (es)
DE (1) DE10008974B4 (es)
ES (1) ES2530229T3 (es)

Families Citing this family (87)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10008973B4 (de) 2000-02-25 2004-10-07 Bayerische Motoren Werke Ag Autorisierungsverfahren mit Zertifikat
DE10141737C1 (de) * 2001-08-25 2003-04-03 Daimler Chrysler Ag Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels
DE10143556A1 (de) * 2001-09-06 2003-03-27 Daimler Chrysler Ag Fahrzeugmanagementsystem
US20030126453A1 (en) * 2001-12-31 2003-07-03 Glew Andrew F. Processor supporting execution of an authenticated code instruction
DE10213165B3 (de) * 2002-03-23 2004-01-29 Daimlerchrysler Ag Verfahren und Vorrichtung zum Übernehmen von Daten
DE10215626B4 (de) * 2002-04-09 2007-09-20 Robert Bosch Gmbh Verfahren zur Änderung von Verschlüsselungsalgorithmen bei geschützter Software oder geschützten Daten
US7010682B2 (en) * 2002-06-28 2006-03-07 Motorola, Inc. Method and system for vehicle authentication of a component
US20040001593A1 (en) * 2002-06-28 2004-01-01 Jurgen Reinold Method and system for component obtainment of vehicle authentication
US7325135B2 (en) * 2002-06-28 2008-01-29 Temic Automotive Of North America, Inc. Method and system for authorizing reconfiguration of a vehicle
US7137001B2 (en) * 2002-06-28 2006-11-14 Motorola, Inc. Authentication of vehicle components
US7137142B2 (en) * 2002-06-28 2006-11-14 Motorola, Inc. Method and system for vehicle authentication of a component using key separation
US20040003232A1 (en) * 2002-06-28 2004-01-01 Levenson Samuel M. Method and system for vehicle component authentication of another vehicle component
US20040003234A1 (en) * 2002-06-28 2004-01-01 Jurgen Reinold Method and system for vehicle authentication of a subassembly
US7600114B2 (en) * 2002-06-28 2009-10-06 Temic Automotive Of North America, Inc. Method and system for vehicle authentication of another vehicle
US7181615B2 (en) * 2002-06-28 2007-02-20 Motorola, Inc. Method and system for vehicle authentication of a remote access device
US7228420B2 (en) 2002-06-28 2007-06-05 Temic Automotive Of North America, Inc. Method and system for technician authentication of a vehicle
US20040003230A1 (en) * 2002-06-28 2004-01-01 Puhl Larry C. Method and system for vehicle authentication of a service technician
US7549046B2 (en) * 2002-06-28 2009-06-16 Temic Automotive Of North America, Inc. Method and system for vehicle authorization of a service technician
US7127611B2 (en) * 2002-06-28 2006-10-24 Motorola, Inc. Method and system for vehicle authentication of a component class
US7131005B2 (en) * 2002-06-28 2006-10-31 Motorola, Inc. Method and system for component authentication of a vehicle
DE10229704A1 (de) * 2002-07-02 2004-01-29 Endress + Hauser Process Solutions Ag Verfahren zum Schutz vor unerlaubtem Zugriff auf ein Feldgerät in der Prozessautomatisierungstechnik
DE10237698A1 (de) * 2002-08-15 2004-02-26 Volkswagen Ag Verfahren und Vorrichtung zur Übertragung von Daten
DE10238094B4 (de) * 2002-08-21 2007-07-19 Audi Ag Verfahren zum Schutz gegen Manipulationen in einem Steuergerät für mindestens eine Kfz-Komponente und Steuergerät
DE10249677A1 (de) * 2002-10-24 2004-05-19 Siemens Ag Programmier-und Betriebsverfahren für eine programmierbare industrielle Steuerung, insbesondere eine CNC-Steuerung
DE10255805A1 (de) * 2002-11-29 2004-06-09 Adam Opel Ag Verfahren zur Änderung der Programmierung eines Steuergerätes eines Kraftfahrzeuges
US20040177270A1 (en) * 2003-02-21 2004-09-09 Little Herbert A. System and method of multiple-level control of electronic devices
DE10309507A1 (de) * 2003-03-05 2004-09-16 Volkswagen Ag Verfahren und Einrichtung zur Wartung von sicherheitsrelevanten Programmcode eines Kraftfahrzeuges
DE10316951A1 (de) * 2003-04-12 2004-10-21 Daimlerchrysler Ag Verfahren zur Überprüfung der Datenintegrität von Software in Steuergeräten
DE10318031A1 (de) * 2003-04-19 2004-11-04 Daimlerchrysler Ag Verfahren zur Sicherstellung der Integrität und Authentizität von Flashware für Steuergeräte
JP2007507020A (ja) 2003-06-24 2007-03-22 バイエリッシェ　モートーレン　ウエルケ　アクチエンゲゼルシャフト プログラミング可能な読出し専用メモリのブートセクタ内にソフトウェアをリロードするための方法
DE10357032A1 (de) * 2003-06-24 2005-01-13 Bayerische Motoren Werke Ag Verfahren zum Nachladen einer Software in den Bootsektor eines programmierbaren Lesespeicher
JP2007527044A (ja) * 2003-07-04 2007-09-20 バイエリッシェ　モートーレン　ウエルケ　アクチエンゲゼルシャフト 特に自動車の制御装置内にロード可能なソフトウェアコンポーネントを認証するための方法
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
DE10332452B4 (de) * 2003-07-17 2018-04-12 Continental Teves Ag & Co. Ohg Steuerungs- und Regelungsgerät in einem Kraftfahrzeug sowie Verfahren zum Betreiben desselben
JP2005202503A (ja) * 2004-01-13 2005-07-28 Hitachi Ltd 車載情報装置、車載機器管理システム、車両の制御機器のプログラムのバージョンアップ情報の配信方法、車両の制御機器のプログラムのバージョンアップ方法及び車両の制御機器のプログラムのバージョンアップシステム
SE0400480L (sv) * 2004-02-26 2005-08-27 Movimento Ab Fordonsinterface
EP1723518A1 (de) * 2004-03-09 2006-11-22 Bayerische Motorenwerke Aktiengesellschaft Aktualisierung und/oder erweiterung der funktionalität der ablaufsteuerung mindestens eines steuergeräts
ES2386352T3 (es) * 2004-04-29 2012-08-17 Bayerische Motoren Werke Aktiengesellschaft Autenticación de un dispositivo externo a un vehículo
DE102004036810A1 (de) * 2004-07-29 2006-03-23 Zf Lenksysteme Gmbh Kommunikationsverfahren für wenigstens zwei Systemkomponenten eines Kraftfahrzeugs
US9489496B2 (en) 2004-11-12 2016-11-08 Apple Inc. Secure software updates
JP4534731B2 (ja) * 2004-11-19 2010-09-01 株式会社デンソー 電子制御装置及びその識別コード生成方法
JP2006285849A (ja) * 2005-04-04 2006-10-19 Xanavi Informatics Corp ナビゲーション装置
JP4492470B2 (ja) 2005-07-20 2010-06-30 株式会社デンソー 車載制御装置のデータ書き換え方法および車載制御装置
DE102005039128A1 (de) * 2005-08-18 2007-02-22 Siemens Ag Sicherheitseinrichtung für elektronische Geräte
US20070112773A1 (en) * 2005-11-14 2007-05-17 John Joyce Method for assuring flash programming integrity
DE102005060902A1 (de) * 2005-12-20 2007-06-28 Robert Bosch Gmbh Steuergerät für eine Maschine
EP1857897B1 (de) * 2006-05-15 2014-01-15 ABB PATENT GmbH Verfahren und System zur Erstellung oder Änderung sicherheitsrelevanter Daten für eine Steuerungseinrichtung
DE102006032065A1 (de) * 2006-07-11 2008-01-17 Knorr-Bremse Systeme für Nutzfahrzeuge GmbH Neuprogrammierung von elektronischen Fahrzeug-Steuereinheiten über eingebaute Peripherien für austauschbare Datenspeicher
DE102006040228A1 (de) * 2006-08-28 2008-03-06 Giesecke & Devrient Gmbh Identifikationssystem
JP2008059450A (ja) * 2006-09-01 2008-03-13 Denso Corp 車両情報書換えシステム
US20080101613A1 (en) 2006-10-27 2008-05-01 Brunts Randall T Autonomous Field Reprogramming
DE102007004646A1 (de) * 2007-01-25 2008-07-31 Siemens Ag Verfahren und Vorrichtung zum Freigeben eines Zugriffs auf eine Steuervorrichtung
DE102007004645A1 (de) * 2007-01-25 2008-07-31 Siemens Ag Tachograph
DE102007049151B4 (de) * 2007-10-12 2014-05-28 Robert Bosch Gmbh Verfahren zur Durchführung einer automotiven Anwendung
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
DE102008056745A1 (de) * 2008-11-11 2010-05-12 Continental Automotive Gmbh Vorrichtung zum Steuern einer Fahrzeugfunktion und Verfahren zum Aktualisieren eines Steuergerätes
DE102009051350A1 (de) 2009-10-30 2011-05-05 Continental Automotive Gmbh Verfahren zum Betreiben eines Tachographen und Tachograph
CN102065156B (zh) 2009-11-11 2013-08-07 中兴通讯股份有限公司 一种用于断开手持终端下载通道的装置及方法
DE102010015648A1 (de) * 2010-04-20 2011-10-20 Siemens Aktiengesellschaft Messgerät und Messverfahren
DE102010038179B4 (de) * 2010-10-14 2013-10-24 Kobil Systems Gmbh Individuelle Aktualisierung von Computerprogrammen
JP5395036B2 (ja) * 2010-11-12 2014-01-22 日立オートモティブシステムズ株式会社 車載ネットワークシステム
DE102010053488A1 (de) * 2010-12-04 2012-06-06 Audi Ag Verfahren zum reversiblen, manipulationssicheren Codieren eines Motorsteuergeräts für ein Kraftfahrzeug und Motorsteuergerät
FR2973136A1 (fr) 2011-03-25 2012-09-28 France Telecom Verification de l'integrite de donnees d'un equipement embarque dans un vehicule
DE102011109426A1 (de) * 2011-08-04 2012-12-27 Daimler Ag Verfahren zur Erkennung von Datenänderungen in einem Steuergerät
DE102011084569B4 (de) * 2011-10-14 2019-02-21 Continental Automotive Gmbh Verfahren zum Betreiben eines informationstechnischen Systems und informationstechnisches System
WO2013105916A1 (en) * 2011-12-01 2013-07-18 Intel Corporation Secure message filtering to vehicle electronic control units with secure provisioning of message filtering rules
ITVI20120034A1 (it) * 2012-02-09 2013-08-10 Bentel Security S R L Dispositivo e metodo per la gestione di installazioni elettroniche di edifici
DE102013101508B4 (de) * 2012-02-20 2024-10-02 Denso Corporation Datenkommunikationsauthentifizierungssystem für ein Fahrzeug und Netzkopplungsvorrichtung für ein Fahrzeug
JP6009290B2 (ja) * 2012-09-12 2016-10-19 株式会社ケーヒン 車両の電子制御装置
KR101438978B1 (ko) * 2012-12-31 2014-09-11 현대자동차주식회사 리프로그래밍 방법 및 시스템
US9179311B2 (en) * 2013-10-04 2015-11-03 GM Global Technology Operations LLC Securing vehicle service tool data communications
DE102014107474A1 (de) * 2014-05-27 2015-12-03 Jungheinrich Aktiengesellschaft Flurförderzeug mit einer Diagnoseschnittstelle und Verfahren zum Warten eines solchen Flurförderzeugs
JP6228093B2 (ja) * 2014-09-26 2017-11-08 Kddi株式会社 システム
CN110377310B (zh) * 2014-11-12 2023-04-07 松下电器（美国）知识产权公司 更新管理方法、更新管理装置以及计算机可读取的记录介质
DE102015201298A1 (de) * 2015-01-26 2016-07-28 Robert Bosch Gmbh Verfahren zum kryptographischen Bearbeiten von Daten
JP6183400B2 (ja) * 2015-03-31 2017-08-23 コニカミノルタ株式会社 契約書作成プログラム、契約書検証プログラム、最終暗号作成プログラム、契約書作成システム、契約書検証システム及び最終暗号作成システム
DE102015011920A1 (de) 2015-09-03 2017-03-09 Continental Automotive Gmbh Verfahren zur Überprüfung der Datenintegrität einer C2C Übertragung
KR101831134B1 (ko) * 2016-05-17 2018-02-26 현대자동차주식회사 암호화를 적용한 제어기 보안 방법 및 그 장치
DE102016221108A1 (de) * 2016-10-26 2018-04-26 Volkswagen Aktiengesellschaft Verfahren zum Aktualisieren einer Software eines Steuergeräts eines Fahrzeugs
US10031523B2 (en) 2016-11-07 2018-07-24 Nio Usa, Inc. Method and system for behavioral sharing in autonomous vehicles
DE102017129698A1 (de) * 2017-12-13 2019-06-13 Endress+Hauser Conducta Gmbh+Co. Kg Verfahren und System zum Betreiben einer Erweiterung an einem Messumformer der Prozessautomatisierungstechnik
US11022971B2 (en) 2018-01-16 2021-06-01 Nio Usa, Inc. Event data recordation to identify and resolve anomalies associated with control of driverless vehicles
US20190302766A1 (en) * 2018-03-28 2019-10-03 Micron Technology, Inc. Black Box Data Recorder with Artificial Intelligence Processor in Autonomous Driving Vehicle
US10369966B1 (en) 2018-05-23 2019-08-06 Nio Usa, Inc. Controlling access to a vehicle using wireless access devices
DE102019206302A1 (de) 2019-05-02 2020-11-05 Continental Automotive Gmbh Verfahren und Vorrichtung zum Übertragen eines Boot-Codes mit verbesserter Datensicherheit
DE102020114098A1 (de) * 2020-05-26 2021-12-02 Bayerische Motoren Werke Aktiengesellschaft Verfahren, System, Computerprogramm und Speichermedium zur Dokumentation einer Aktualisierung von Software einer Komponente eines Fahrzeugs
US11804981B2 (en) * 2021-01-14 2023-10-31 Gm Global Technology Operations, Llc Method and apparatus for providing an individually secure system to multiple distrusting parties

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4930073A (en) * 1987-06-26 1990-05-29 International Business Machines Corporation Method to prevent use of incorrect program version in a computer system
JP3550834B2 (ja) * 1995-11-13 2004-08-04 株式会社デンソー 自動車用電子制御装置のメモリ書換システム，自動車用電子制御装置及びメモリ書換装置
DE19605554C2 (de) * 1996-02-15 2000-08-17 Daimler Chrysler Ag Einrichtung zum Prüfen von Funktionselementen fahrzeugelektrischer Anlagen
JP3580333B2 (ja) * 1996-04-10 2004-10-20 日本電信電話株式会社 暗号認証機能の装備方法
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
US6754712B1 (en) * 2001-07-11 2004-06-22 Cisco Techonology, Inc. Virtual dial-up protocol for network communication
US5844986A (en) * 1996-09-30 1998-12-01 Intel Corporation Secure BIOS
JPH10161934A (ja) * 1996-11-27 1998-06-19 Nissan Motor Co Ltd 車両用制御装置のフラッシュメモリ書き換え装置
JPH10200522A (ja) * 1997-01-08 1998-07-31 Hitachi Software Eng Co Ltd Ｉｃカード利用暗号化方法およびシステムおよびｉｃカード
US5844896A (en) * 1997-02-26 1998-12-01 U S West, Inc. System and method for routing telephone calls
JP3704904B2 (ja) * 1997-08-08 2005-10-12 日産自動車株式会社 車両制御用メモリ書き換え装置
US5970147A (en) * 1997-09-30 1999-10-19 Intel Corporation System and method for configuring and registering a cryptographic device
JPH11215120A (ja) * 1998-01-27 1999-08-06 Fujitsu Ltd 通信装置
FR2775372B1 (fr) * 1998-02-26 2001-10-19 Peugeot Procede de verification de la coherence d'informations telechargees dans un calculateur
JPH11265349A (ja) * 1998-03-17 1999-09-28 Toshiba Corp コンピュータシステムならびに同システムに適用される機密保護方法、送受信ログ管理方法、相互の確認方法および公開鍵世代管理方法
JP4066499B2 (ja) * 1998-03-26 2008-03-26 株式会社デンソー 電子制御装置，電子制御システムおよび適合判断方法
US6748541B1 (en) * 1999-10-05 2004-06-08 Aladdin Knowledge Systems, Ltd. User-computer interaction method for use by a population of flexibly connectable computer systems
US6754832B1 (en) * 1999-08-12 2004-06-22 International Business Machines Corporation Security rule database searching in a network security environment

Also Published As

Publication number Publication date
DE10008974B4 (de) 2005-12-29
EP1128242A3 (de) 2006-01-18
US20020120856A1 (en) 2002-08-29
JP2001255952A (ja) 2001-09-21
EP1128242B1 (de) 2015-01-07
EP1128242A2 (de) 2001-08-29
US6816971B2 (en) 2004-11-09
JP4733840B2 (ja) 2011-07-27
DE10008974A1 (de) 2001-09-06

Similar Documents

Publication Publication Date Title
ES2530229T3 (es) Procedimiento de firma
ES2237500T3 (es) Procedimiento de autorizacion con certificado.
US11876791B2 (en) Message authentication with secure code verification
JP6454918B2 (ja) 車載コンピュータシステム、車両、管理方法、及びコンピュータプログラム
JP4067985B2 (ja) アプリケーション認証システムと装置
ES2318302T3 (es) Prueba de ejecucion que utiliza funcion aleatoria.
US7131005B2 (en) Method and system for component authentication of a vehicle
US7600114B2 (en) Method and system for vehicle authentication of another vehicle
US7181615B2 (en) Method and system for vehicle authentication of a remote access device
CN101589409B (zh) 行驶记录仪
US20050210287A1 (en) Secure mode controlled memory
US20100180130A1 (en) Cryptographic Protection of Usage Restrictions in Electronic Devices
US8028164B2 (en) Practical and secure storage encryption
EP1518350B1 (en) Method and system for vehicle authentication of a component
CN1820235A (zh) 密钥存储管理
JP6387908B2 (ja) 認証システム
ES2301652T3 (es) Unidad de control.
US20040003232A1 (en) Method and system for vehicle component authentication of another vehicle component
CN114091123A (zh) 安全集成电路芯片及其保护方法
CN109684864A (zh) 一种基于区块链的证书处理方法及系统
US20020194479A1 (en) Method of protecting a microcomputer system against manipulation of data stored in a storage assembly of the microcomputer system
CN1942347B (zh) 汽车外部装置的验证
CN116527301A (zh) 控制器的防伪造方法、装置、车辆及系统
JP4593207B2 (ja) ソフトウェア無線システム
JP2009543210A5 (es)