DE102010004786A1 - Computer-aided method for providing development environment to implement secure application in motor car, involves invoking secure applications over interfaces, where secure applications are more configurable during implementation - Google Patents

Abstract

The method involves providing multiple security modules (SM1-SM3) that comprise multiple secure applications. The secure applications are invoked over multiple interfaces (IF1-IF6) by external applications (A1-A3) and more configurable during implementation. The secure applications are distributed on internal entities in a car and/or external entities outside the car. The entities are identified and authenticated by an entity authentication module. The secure applications are monitored by a security monitoring module. Cryptographic services are provided by a cryptography module. Independent claims are also included for the following: (1) a computer program product comprising a set of instructions for executing a computer-aided method for providing a development environment to implement a secure application in a motor car (2) a motor car comprising multiple control devices.

Description

The invention relates to a method for the computer-aided provision of a development environment for implementing security applications in a vehicle architecture, in particular in a motor vehicle architecture. Furthermore, the invention relates to a method for providing a runtime environment for performing security applications in a vehicle architecture, in particular in a motor vehicle architecture.

Today, in the control of components (eg of control units) of a vehicle or the communication of vehicle components with external components (eg back-end servers), software-based applications are usually used which have corresponding functionalities in conjunction with suitable hardware implement. The protection of such applications against unauthorized access and unauthorized changes by persons or malicious code (eg viruses, Trojans) plays an increasingly important role. In particular, the data processed by appropriate software must be secured against unauthorized use or modification.

At present, security solutions based on proprietary security mechanisms or proprietary security applications are used in the automotive environment. These solutions are often rigid and inflexible and can not be adapted to newer vehicle safety architecture requirements. Due to the large number of individual security solutions, there are often overlaps of the solutions in terms of functionality and in terms of their implementation, eg. B. by a multi-redundant implementation of cryptographic primitives. This increases the complexity and risk of implementation errors, and thus also the potential risk of vulnerabilities that an attacker can exploit for tampering. Conversely, insufficient protection is often provided for new applications with extended protection needs.

The object of the invention is therefore to provide the necessary in a vehicle architecture protection and security mechanisms simple and flexible, thereby enabling a reliable and cost-effective implementation of security functions for a variety of vehicle configurations.

This object is achieved by the method according to independent claim 1. Further developments of the invention are defined in the dependent claims.

The method according to the invention provides a development environment for implementing security applications in a vehicle architecture, the term "vehicle architecture" being widely understood and the realization of security applications both in the vehicle itself and in external, ie. H. may be associated with the vehicle but located outside of the vehicle components and between internal control devices and external components. An external component may be, for example, a backend server for wireless communication with a corresponding communication module of the vehicle or else an external device (eg a mobile terminal). Internal control devices can be any IT components within the vehicle, which are realized purely by software or a combination of hardware and software. In the following, the term entity is also used for the designation of corresponding control devices or independent components in or outside the vehicle, wherein an entity may optionally also be assigned to a user or may correspond to a user (eg in the context of authentication). , According to the invention, the term "development environment" refers to a corresponding software-implemented tool with a set of security modules with which a programmer / software developer can easily implement and integrate security functions based on security applications in his code when developing a software. The implemented security applications are then reliably available in the vehicle architecture at runtime.

In the method according to the invention, a plurality of security modules is provided, each security module comprising a number of security applications implementing security functions, wherein one or more of the security applications of a respective security module can be invoked via one or more interfaces by external applications, and wherein one or more of the security applications of the respective security module are configurable in implementation. One or more of the security applications may e.g. B. be configurable only during implementation. Optionally, one or more of the security applications may be configurable and / or updatable at run time both during implementation and (at least limited) at run time. Under an external application is an application to understand, which is not directly part of the security modules, but which newly developed an application developer to implement certain safety-critical functionalities for a vehicle. In a preferred variant of the In accordance with the invention, the security modules and the interfaces within the development environment are provided by means of a software library which the external applications can easily access.

The inventive method is characterized by the fact that various security mechanisms can be flexibly integrated into a vehicle architecture in the manner of a modular modular system. That is, the modular safety building kit provides a technical solution to easily integrate a safety mechanism in a safety overall system. The individual security mechanisms are based on security modules whose security applications can be reconfigured in particular both for implementation in a preconfigurable manner and also limitedly at runtime. These security functions and security mechanisms provided by the security applications can thus be flexibly adapted to the respective security requirements of the using application and the system environment.

By configuring the safety module security applications, which is ensured via a suitable configuration interface, a security mechanism can be suitably adapted according to the specification of an external security application by the application developer. In this case, a static pre-configuration for the security modules or for their security applications is usually given, which can be changed in a suitable manner. The static preconfiguration relates in particular to the configuration of communication endpoints of a security application or a security module to other security applications or security modules, which are used by the security application under consideration or the security module under consideration or which needs the considered security application or security module. The configuration may further involve static rules, such as: As filter rules, authorization rules and the like, or even static credentials (English: credentials), such as secret keys, public keys, certificates and the like.

In a preferred embodiment of the invention, the implemented security modules at least partially also enable dynamic reconfiguration during runtime. In this way, dynamic rules, such. For example, the update of intrusion detection rules. Likewise, dynamic credentials such. Updated pseudonym identities and keys.

The method of the invention also provides a starting point to easily implement new security applications in a vehicle architecture. This can be achieved in a simple way by additional, new or extended use of the security modules based on corresponding security applications or by adding new security modules. Thus, new security requirements can be integrated, which are required by new security applications.

Another advantage of the invention is that an application developer based on the corresponding interface can easily integrate a security application into the external application he has developed, without having detailed knowledge of the corresponding security module and its underlying security mechanisms and security functions.

The inventive method, the development effort in the development of new security solutions due to the use of security modules is kept very low, since the security applications of the security modules form a flexibly configurable and reusable security kit. The individual security modules or their security applications can be suitably configured and assembled according to the security requirements of the corresponding applications. Since different use cases often have similar security requirements, similar security mechanisms are often needed. By appropriate configuration of the security applications or security modules such similar security mechanisms can be realized in a simple manner. In this way, high efficiency in terms of cost and system resources is achieved. It also reduces the cost of testing newly developed software and avoids the redundant, parallel development of security solutions that often occur with proprietary solutions. Likewise, security mechanisms can be omitted in a simple manner by the modular design of the safety kit, which are not required for the corresponding applications. In this way, the security solutions can be efficiently implemented in line with the model and application.

In a preferred variant of the method according to the invention, at least some of the security modules comprise one or more internal interfaces which are not used by external applications but via which the security modules can call each other exclusively. This can be a distributed call be achieved by the security modules with each other.

In a further embodiment of the method according to the invention, the security applications of the plurality of security modules are distributed to a plurality of different internal entities in the vehicle and / or external entities outside the vehicle. In this way, remote access to security applications of various internal or external entities via corresponding interfaces to external applications or internal interfaces between security applications is achieved.

In a further embodiment of the method according to the invention, at least some of the security applications of the plurality of security modules are implemented by so-called plug-ins. Plugins are well known in the art and allow for easy customization and replacement of the respective implementations of the security applications by the adaptation or replacement of the corresponding plug-in.

• – die Erteilung von Erlaubnissen zur Durchführung von durch eine Entität angefragten Operationen, insbesondere von Operationen auf einer bestimmten Entität;
• – den Widerruf von erteilten Erlaubnissen zur Durchführung von Operationen, insbesondere von Operationen auf einer bestimmten Entität;
• – das Nachschlagen, ob eine Entität momentan die Erlaubnis zur Durchführung einer Operation hat, insbesondere einer Operation auf einer bestimmten Entität;
• – das Setzen von Sicherheitsregeln zur lokalen Durchsetzung innerhalb des Sicherheitsmoduls.

In a further, preferred embodiment of the method according to the invention, the security applications of one or more security modules and in particular of each security module provide inter alia one or more and in particular all of the following operations:

• - the granting of permits to carry out operations requested by an entity, in particular operations on a particular entity;
• - the revocation of granted permissions to perform operations, in particular operations on a particular entity;
• - looking up whether an entity currently has permission to perform an operation, in particular an operation on a particular entity;
• - setting security rules for local enforcement within the security module.

As a result, enforcement of security rules for the respective security module is achieved in addition to the actual functions of the corresponding security module.

• – ein Kommunikations-Steuer-Modul zur Kommunikation zwischen internen Entitäten im Fahrzeug und/oder externen Entitäten außerhalb des Fahrzeugs;
• – ein Entitäts-Authentifizierungs-Modul zur Identifikation und Authentifizierung von Entitäten;
• – ein Sicherheitsregel-Entscheidungs-Modul zur Abfrage und Verwaltung von vorgegebenen Sicherheitsregeln;
• – ein Sicherheits-Überwachungs-Modul zur Überwachung der Ausführung von Sicherheitsmodulen;
• – ein sicheres Speicher-Modul zum kryptographisch gesicherten Speichern von Daten;
• – ein Plattform-Integritäts-Modul zur Erkennung von Manipulationen an den Sicherheitsmodulen und Sicherheitsanwendungen;
• – ein Kryptographie-Modul zur Bereitstellung von kryptographischen Diensten.

In a particularly preferred embodiment of the method according to the invention, the modular safety building set, ie the plurality of safety modules, comprises one or more of the following safety modules:

• A communication control module for communication between internal entities in the vehicle and / or external entities outside the vehicle;
• An entity authentication module for identifying and authenticating entities;
• A security rule decision module for querying and managing given security rules;
• - a security monitoring module for monitoring the execution of security modules;
• A secure memory module for cryptographically secured storage of data;
• - a platform integrity module to detect security module and security application tampering;
• A cryptography module for providing cryptographic services.

The just mentioned security modules and their functionalities as well as the generic concept of the invention are explained in detail also in documents [1] and [2]. The entire disclosure content of these documents is incorporated by reference into the content of the present application. In particular, the operations set out below, which may include the above-mentioned modules, are again explained in detail in the cited documents.

• – die Bereitstellung von verschiedenen gesicherten Kommunikationskanälen;
• – den Aufbau eines kryptographisch gesicherten Kommunikationskanals zwischen Entitäten:
• – das Senden und Empfangen von Daten über einen kryptographisch gesicherten Kommunikationskanal;
• – das Beenden eines kryptographisch gesicherten Kommunikationskanals;
• – das Setzen von Kommunikationsfiltern auf einem kryptographisch gesicherten Kommunikationskanal;
• – das Protokollieren von Ereignissen betreffend Sicherheitsanwendungen des Kommunikations-Steuer-Moduls.

In a preferred variant of the invention, the security applications of the communication control module provide one of the following operations:

• - the provision of various secure communication channels;
• The structure of a cryptographically secured communication channel between entities:
• The sending and receiving of data via a cryptographically secured communication channel;
• The termination of a cryptographically secured communication channel;
• The setting of communication filters on a cryptographically secured communication channel;
• The logging of events relating to security applications of the communication control module.

It is preferable that all of the above-mentioned operations of the communication control module except for the operation of logging events via corresponding interfaces to external applications.

• – die Verifikation der Authentizität und die Evaluierung der Vertrauenswürdigkeit einer Entität;
• – das Einloggen (d. h. die Authentifizierung) von Entitäten mit Authentisierungsdaten;
• – das Ausloggen von Entitäten;
• – das Erzeugen von Authentisierungsdaten, insbesondere von Authentisierungstickets;
• – die Verifikation von Authentisierungsdaten, insbesondere von Authentisierungstickets;
• – das Protokollieren von Ereignissen betreffend Sicherheitsanwendungen des Entitäts-Authentifizierungs-Moduls.

In a further preferred embodiment of the inventive method, the security functions of the entity authentication module provide one or more of the following operations:

• - the verification of authenticity and the evaluation of the trustworthiness of an entity;
• The login (ie the authentication) of entities with authentication data;
• - the logout of entities;
• The generation of authentication data, in particular of authentication tickets;
• The verification of authentication data, in particular of authentication tickets;
• The logging of events concerning entity authentication module security applications.

Preferably, all of the entity authentication module operations mentioned above, except for logging events, have interfaces to external applications.

• – eine Abfrage und Überprüfung, ob eine Entität berechtigt ist, bestimmte Operationen basierend auf Sicherheitsregeln und/oder basierend auf Authentisierungsdaten durchzuführen;
• – das Setzen von Sicherheitsregeln;
• – die Überprüfung von durch das Sicherheitsregel-Entscheidungs-Moduls getroffenen Entscheidungen;
• – das Protokollieren von Ereignissen betreffend der Sicherheitsanwendungen des Sicherheitsregel-Entscheidungs-Moduls;
• – die Delegation von Entscheidungen an andere Sicherheitsregel-Entscheidungs-Module;
• – die Transformation von einer oder mehreren Sicherheitsregel-Sprachen in die Sprache des Sicherheitsregel-Entscheidungs-Moduls.
• – die Integration von Entscheidungs-Plugins zur Entscheidungsfindung basierend auf einer oder mehreren Sicherheitsregel-Sprachen, insbesondere basierend auf Sicherheitsregel-Sprachen, die nicht in die Sprache des Sicherheitsregel-Entscheidungs-Moduls transformiert werden (können).

In a further preferred embodiment of the method according to the invention, the security applications of the security rule arbitration module provide one or more of the following operations:

• A query and check whether an entity is authorized to perform certain operations based on security rules and / or based on authentication data;
• - the setting of security rules;
• - the review of decisions made by the security rule-decision module;
• The logging of events relating to the security applications of the security rule decision module;
• - the delegation of decisions to other safety rule decision modules;
• - the transformation of one or more security rule languages into the language of the security rule decision module.
• The integration of decision plug-ins for decision-making based on one or more security rule languages, in particular based on security rule languages that can not be transformed into the language of the security rule arbitration module.

It is preferable that all of the above operations of the security rule arbitration module have an interface to external applications except for logging events.

• – die Aktivierung und Deaktivierung der Überwachung von Ressourcen oder Diensten;
• – die passive Überwachung von Ereignissen;
• – das Setzen von Erkennungsmustern zur Erkennung von Angriffen Unbefugter;
• – das Setzen von Antwortregeln in Antwort auf die Erkennung eines Angriffs eines Unbefugten;
• – das Ausführen von Gegenmaßnamen nach der Erkennung eines Angriffs eines Unbefugten;
• – das Auslösen eines Alarms nach der Erkennung eines Angriffs eines Unbefugten;
• – die Verarbeitung der Protokollierungsereignisse von anderen Sicherheitsmodulen.

In a further preferred embodiment of the method according to the invention, the security applications of the security monitoring module provide one or more of the following operations:

• - the activation and deactivation of the monitoring of resources or services;
• - the passive monitoring of events;
• - the setting of recognition patterns to detect attacks by unauthorized persons;
• - the setting of response rules in response to the detection of an attack by an unauthorized person;
• - the execution of countermeasures after the detection of an attack by an unauthorized person;
• The triggering of an alarm after the detection of an attack by an unauthorized person;
• - the processing of logging events from other security modules.

In this case, preferably all said operations of the security monitoring module have an interface to external applications.

• – die Bereitstellung verschiedener gesicherter Speichersysteme (z. B. block-basierter und/oder datei-basierter Speichersysteme), insbesondere über Plugins;
• – das Öffnen und/oder Einbinden (Englisch: Mounten) von Datenobjekten gemäß vorgegebener Sicherheitsparameter;
• – das Lesen von zuvor geöffneten Datenobjekten gemäß vorgegebener Sicherheitsparameter;
• – das Schreiben in zuvor geöffnete Datenobjekte gemäß vorgegebener Sicherheitsparameter;
• – das Löschen von Datenobjekten;
• – das Protokollieren von Ereignissen betreffend Sicherheitsanwendungen des sicheren Speicher-Moduls.

In another embodiment of the inventive method, the secure storage module security applications provide one or more of the following operations:

• The provision of various secure storage systems (eg block-based and / or file-based storage systems), in particular via plugins;
• - Opening and / or incorporating (English: Mounten) of data objects according to predetermined security parameters;
• The reading of previously opened data objects according to predetermined safety parameters;
• The writing into previously opened data objects according to predetermined safety parameters;
• - the deletion of data objects;
• - logging events relating to security applications of the secure storage module.

Preferably, all of the above-mentioned operations of the secure memory module except for the operation of logging events via an interface to external applications.

• – die Erweiterung von initialen Plattform-Integritäts-Messwerten um einen oder mehrere Messwerte, wobei die Plattform-Integritäts-Messwerte angeben, inwieweit eine Manipulation der entsprechenden Software- bzw. Hardware-Plattform durch Unbefugte vorliegt;
• – die sichere (zertifizierte) Abfrage von Plattform-Integritäts-Messwerten;
• – das Verschlüsseln von Daten und deren Abbildung auf einem Plattform-Integritäts-Messzustand;
• – das Protokollieren von Ereignissen betreffend Sicherheitsanwendungen des Plattform-Integritäts-Moduls;
• – das sichere Starten einer Plattform;
• – die Attestierung der Vertrauenswürdigkeit einer Plattform gegenüber anderen Entitäten;
• – das kryptographische Binden von Daten an eine bestimme Konfiguration einer Plattform und/oder an eine eindeutige Plattformkennung.

In another embodiment of the method according to the invention, the security functions of the platform integrity module provide one or more of the following operations:

• The extension of initial platform integrity metrics by one or more metrics, the platform health metrics specifying the extent to which there is unauthorized manipulation of the corresponding software or hardware platform;
• - the secure (certified) query of platform integrity metrics;
• - encrypting data and mapping it on a platform integrity measurement state;
• - logging events relating to platform integrity module security applications;
• - safely starting a platform;
• - attesting the trustworthiness of a platform to other entities;
• The cryptographic binding of data to a specific configuration of a platform and / or to a unique platform identifier.

Preferably, all of the above-mentioned operations of the platform integrity module have an interface to external applications except for the logging of events. The operations of the platform integrity module are preferably at least partially implemented or supported by hardware (eg, cryptographically protected memory).

• – die Erzeugung von Hashwerten;
• – die Erzeugung von Nachrichten-Authentisierungs-Codes;
• – die Erzeugung von Zufallszahlen;
• – die Verifikation von Hashwerten;
• – die Verifikation von Nachrichten-Authentisierungs-Codes;
• – die Verifikation von Signaturen;
• – die Verschlüsselung von Daten;
• – die Entschlüsselung von Daten.

In a further preferred embodiment of the method according to the invention, the security applications of the cryptography module provide one or more of the following operations:

• The generation of hash values;
• The generation of message authentication codes;
• - the generation of random numbers;
• - the verification of hash values;
• The verification of message authentication codes;
• - the verification of signatures;
• - the encryption of data;
• - the decryption of data.

In this case, preferably all of the said operations of the cryptography module have an interface to external applications. The operations of the cryptographic services module may be at least partially implemented or supported by hardware (eg, cryptographically protected memory).

In addition to the method described above, the invention further relates to a computer program product with a program code stored on a machine-readable carrier for carrying out the method according to the invention when the program is run on a computer.

Moreover, the invention relates to a method for providing a runtime environment for performing security applications in a vehicle architecture, wherein the security applications are implemented by means of a development environment provided according to the inventive method described above. At least some external applications call one or more security applications from one or more security modules via corresponding interfaces. Thus, in addition to the implementation of the security applications, the invention also relates to the execution of the implemented security applications in a corresponding vehicle architecture.

The invention furthermore encompasses a vehicle, in particular a motor vehicle, which has one or more control units on which security applications run based on the above-mentioned method for providing a runtime environment during operation of the control unit (s).

The advantages of the method according to the invention according to the embodiments described above can be summarized as follows:
Developers of external applications, especially external security applications, are provided with a coordinated selection of security functions or security mechanisms oriented to the respective application. Easy creation, use and reuse, as well as a simple test of security functionalities are achieved because complex internal security schemes are hidden behind the corresponding interface. The process is very efficient in terms of cost and system resources, avoiding redundancy in the development of security applications and isolated security solutions. System engineers and vehicle or equipment manufacturers can ensure that their application developers do not have to deal with security issues that require specialized security expertise. Rather, developers can use appropriately configurable security applications from deployed security modules. By using abstract interfaces, various implementations of security applications as well as updates of corresponding implementations or substitutions of implementations in the corresponding vehicle architecture can be implemented. In this way, the method can be used to implement security mechanisms for different architectures of different vehicles, in particular also in a series-specific and application-specific manner. The abstract interfaces enable automated, systematic and reliable testing of the implemented security mechanisms. It also ensures easy configuration of the appropriate security applications through a suitable configuration interface. Furthermore, new security features can be achieved by adding appropriate security modules and their security applications.

Embodiments of the invention are described below in detail with reference to the accompanying drawings.

Show it:

1 a schematic representation of the use of the modular safety modules according to an embodiment of the invention;

2 and 3 UML diagrams illustrating the execution of security mechanisms using the example of two authentication operations.

1 shows a schematic representation of the inventive use of security modules in the implementation of security applications in a vehicle architecture. In 1 For example, the software applications developed by a software developer are exemplified by A1, A2 and A3. In order to integrate security functions into these applications, the developer can access a modular system consisting of a large number of security modules, which are integrated in 1 are denoted by the reference symbols SM1, SM2 and SM3 by way of example. These modules with implementations contained therein in the form of security applications are provided to the software developer in the form of a library. In the following, the term "application" or "security application" is also used in some places as a synonym for the term "application" or "security application". In order to access the security applications, corresponding interfaces are defined, which in 1 exemplified by IF1 to IF6. The security modules can cooperate with each other or access one another via these interfaces, and furthermore the software applications A1 to A3 can access respective subsets of these interfaces. These subsets represent user programming interfaces (also known as APIs API = Application Programming Interface) and are in 1 denoted by AI1 to AI3. They combine one or more of the interfaces IF1 to IF6. The individual security modules can be distributed to different entities in or outside the vehicle, so that the interfaces IF1 to IF6 and AI1 to AI3 can also be accessed remotely by different entities. For example, safety functions can be implemented on a control device in the vehicle via corresponding safety modules and their safety applications, wherein these safety functions can also be used by other control devices through remote access. This can z. For example, you can perform computationally-intensive operations on a high-performance entity and relieve entities of lower performance. The interfaces AI1 to AI3 are implemented by calling functions based on security applications of the available security modules. In this way, a security function in the software applications A1 to A3 can be mapped directly to a function of a security module or it can be implemented by successively calling several functions from different security modules. Thus, internal dependencies of the modules and their interactions are encapsulated before the developer of the software application A1 to A3.

The interfaces IF1 to IF6 of the security modules are implemented by individual implementations, which in turn can use security functionalities of other security modules by calling their interfaces. In this case even an individual implementation can be exchanged equivalently, without adaptations having to be made in other security modules or other software applications, since all implemented functionalities are encapsulated behind the corresponding interface of the security module.

According to 1 Thus, a two-level standardized security abstraction layer is created which keeps the actual implementations from the software developer. In this way, the software development effort can be reduced by the reuse of appropriate security modules, and a modular, flexibly configurable and reusable security kit is created. With the help of this modular design kit security applications in a vehicle in corresponding control components or in external components such. Backend servers, can be individually assembled and implemented as appropriate. In contrast to proprietary or isolated security solutions, high efficiency in terms of cost and system resources is achieved based on this modular kit. Furthermore, based on the security kit, such security modules and security mechanisms may be omitted which are actually not needed. With the in Furthermore, not only interfaces are specified, but also processes (English: state machines), which control the integration of individual implementations into the overall system and also regulate the communication between security modules.

• – Autorisierungsregeln, welches spezifizieren, in welchem Maße eine bestimmte Entität berechtigt ist, unter bestimmten Bedingungen eine bestimmte Ressource zu nutzen bzw. auf eine bestimmte Ressource zuzugreifen, z. B. für folgende Zwecke: – Zugriff auf Dateien, ein Netzwerk oder eine Eingabe- bzw. Ausgabevorrichtung; – interne oder externe Kommunikation innerhalb einer Entität bzw. zwischen Entitäten, d. h. es werden Filterregeln festgelegt, welche beispielsweise definieren, welche Inhalte, Quellen, Protokolle oder Dienste zwischen verschiedenen Kommunikationsendpunkten kommunizieren können; – die Verwendung von an eine Entität angeschlossenen Peripheriegeräten; – das Display einer Mensch-Maschine-Schnittstelle; – Softwareinstallationen und die Ausführung von Software;
• – private Regeln, welche definieren, bis zu welchem Grad Daten und Informationen gegenüber Dritten geheim gehalten werden sollen oder wenigstens für einen bestimmten Grad an Privatheit zu anonymisieren sind;
• – Authentisierungsregeln, welche definieren, welche Art von Authentisierung/Authentifizierung (z. B. ein Passwort, eine Smartcard und dergleichen) für eine entsprechende Authentisierung/Authentifizierung von vorgegebenen Rollen erforderlich ist;
• – Intrusions-Detektions-Regeln, welche vorbestimmte Angriffsszenarien und Angriffsheuristiken festlegen;
• – Intrusions-Antwort-Regeln, welche definieren, welche Art von Gegenmaßnahmen gegen bestimmten Arten von detektieren Angriffen durchzuführen sind.

In order to create a very flexible and adaptable implementation of security functionalities in a vehicle architecture, the security modules or their security applications can be configured via configuration interfaces. The configuration can be achieved statically and even dynamically by accepting and enforcing individual security rules, which can be configured as follows, for example:

• Authorization rules specifying to what extent a given entity is entitled to use or access a particular resource under certain conditions, e.g. For the following purposes: - accessing files, a network or an input / output device; Internal or external communication within an entity or between entities, ie filter rules are defined which, for example, define which contents, sources, protocols or services can communicate between different communication endpoints; The use of peripheral devices attached to an entity; The display of a human-machine interface; - Software installations and the execution of software;
• - private rules that define the extent to which data and information should be kept secret from third parties or at least be anonymous for a certain degree of privacy;
• Authentication rules which define what type of authentication / authentication (eg a password, a smartcard and the like) is required for a corresponding authentication / authentication of predefined roles;
• Intrusion detection rules defining predetermined attack scenarios and attack heuristics;
• - Intrusion response rules that define what kind of countermeasures to take against certain types of detected attacks.

• – ein Kommunikations-Steuer-Modul, welches auch als CCM (CCM = Communication Control Module) bezeichnet wird;
• – ein Entitäts-Authentifizierungs-Modul, welches auch als EAM (EAM = Entity Authentication Module) bezeichnet wird;
• – ein Sicherheitsregel-Entscheidungs-Modul, welches auch als PDM (PDM = Policy Decision Module) bezeichnet wird;
• – ein Sicherheits-Überwachungs-Modul, welches auch als SWD (SWD = Security Watchdog) bezeichnet wird;
• – ein sicheres Speicher-Modul, welches auch als SSM (SSM = Secure Storage Module) bezeichnet wird;
• – ein Plattform-Integritäts-Modul, welches auch als PIM (PIM = Platform Integrity Module) bezeichnet wird;
• – ein Kryptographie-Modul, welches auch als CRS (CRS = Cryptographic Service) bezeichnet wird.

As stated above, the security modules preferably include the following modules:

• A communication control module, which is also referred to as CCM (CCM = Communication Control Module);
• An entity authentication module, which is also referred to as EAM (Entity Authentication Module);
• A security rule arbitration module, also referred to as PDM (Policy Decision Module);
• A security monitoring module, which is also referred to as SWD (SWD = Security Watchdog);
• A secure storage module, also referred to as SSM (SSM = Secure Storage Module);
• A platform integrity module, also referred to as PIM (PIM = Platform Integrity Module);
• A cryptography module, also referred to as CRS (Cryptographic Service).

The tasks of the individual modules and the operations preferably to be implemented by these modules have already been described above. It is within the scope of expert action to implement the corresponding operations of the modules by means of suitable software implementations. Based on the modules, a distributed safety functionality in various control devices of a vehicle as well as in relation to external devices, such. As a backend server allows. Through the use of security modules in particular an implementation of security functionality in different vehicle series can be achieved with changing IT infrastructures in the vehicle. All that needs to be done is to make sure that the security implementations within the security modules can be safely executed at different locations inside and even outside the vehicle. In this way, the appropriate interfaces of the safety modules can be safely accessed via various control units within the vehicle and even partially outside the vehicle. The actual location where a security implementation of a security module is deployed is transparent to the corresponding applications that use the security implementations of the modules. Likewise, the actual location of a security implementation of one security module is transparent to other security modules and should not depend on specific characteristics of the underlying architecture or interconnect mechanisms.

To illustrate the invention, an implementation of corresponding operations of the module will be described below using the example of the above-mentioned entity authentication module EAM.

• – Die Identifikation und Authentifizierung entsprechender Entitäten, wobei eine Entität insbesondere eine Applikation, ein Prozess, eine Rolle oder ein Gerät sein kann bzw. einem Benutzer entsprechen kann;
• – die Verwaltung von Authentisierungsprozessen für Entitäten, z. B. die Verarbeitung von Authentisierungs-Statusanfragen, die Erzeugung und die Verarbeitung von Authentisierungstickets, die Aktualisierung von Authentisierungs-Berechtigungsnachweisen, die Verarbeitung von Timeouts und Widerrufen von Authentisierungen;
• – eine Single-Sign-On-Realisierung, welche einen speziellen Teil der Verwaltung der Authentisierungsdaten darstellt, wobei eine Single-Sign-On-Realisierung an sich aus dem Stand der Technik bekannt ist;
• – Mechanismen zur Aufrechterhaltung der Privatsphäre, z. B. Pseudonymisierung von Identitäten gemäß spezieller Privatsphäre-Regeln.

The main tasks of the entity authentication module are the following:

• The identification and authentication of corresponding entities, wherein an entity may in particular be an application, a process, a role or a device or may correspond to a user;
• The administration of authentication processes for entities, e.g. For example, the processing of authentication status requests, the generation and processing of authentication tickets, the updating of authentication credentials, the processing of timeouts and revoking of authentications;
• A single sign-on implementation, which represents a special part of the management of the authentication data, whereby a single-sign-on Realization is known per se from the prior art;
• - Privacy mechanisms, eg. B. Pseudonymization of identities according to special privacy rules.

As mentioned above, entities may be in particular users, roles or devices. A user can be understood in particular as the passenger or occupant of a vehicle. A role may be, for example, a party involved in the execution of operations of the module, such as: B. the vehicle manufacturer, his. A device can be any technical unit within the vehicle or a unit communicating with components of the vehicle, for example a diagnostic analyzer, an electronic control unit or a communication terminal of a user.

In order to identify and authenticate the abovementioned entities in a very flexible manner, the entity authentication module can be implemented, for example, with the Extensible Authentication Protocol (EAP). This protocol is defined in RFC 3748 (RFC = Request For Comments). A significant advantage of EAP is that the actual authentication scheme is not specified, but is negotiated during the authentication process. EAP is currently used in most WLAN networks and also in many LAN networks and comprises about 30 different EAP methods for authentication in order to support various authentication schemes. Optionally, the entity authentication module may also be based on other protocols, such as the RADIUS protocol.

The following explains the abstract interfaces provided in the embodiment of an Entity Authentication Module described herein. The interfaces are specified by the functions described below, the corresponding input or output parameters of the functions being given in parentheses after the thickly printed function names. The parameters are printed in italics and before each parameter is specified whether it is an input parameter (characterized by the expression "in") or whether it is an output parameter (characterized by the expression "out"). Further, before the thick-printed function name and after a corresponding expression "out", it is indicated which output variable type is the function, the variable type being printed in italics. In the interfaces described below, the functions are always of the variable type "bool" in the form of true or false. Furthermore, the underlined term public or private indicates below whether external applications that are not contained in the security modules can access the corresponding interfaces or not. This means that "public" specifies that external applications can access the interface, and the expression "private" indicates that the interface can only be accessed within the modules.

• – public out bool EAM_login_entity (in entity_id, in/out auth_credential) Gemäß dieser Schnittstelle wird die Entität, welche durch eine gegebene Entitäts-Identifikation entity_id referenziert wird, zunächst für geeignete Authentisierungs-Schemata klassifiziert, gegebenenfalls über das PDM-Modul. Anschließend wird der Authentisierungs-Berechtigungsnachweis auth_credential gemäß dem verwendeten Authentisierungs-Schema unter Verwendung des Moduls CRS verifiziert. Dabei kann der Berechtigungsnachweis auth_credential einen sog. „multistep credential” (z. B. ein Challenge-Response-Protokoll) darstellen, welches intermediäre Eingabe- bzw. Ausgabedaten aufweisen kann. Ebenso kann der Berechtigungsnachweis auth_credential ein Authentisierungsticket von einem externen Authentisierungs-Dienst, beispielsweise von einer Backend-Authentisierung, umfassen. Schließlich wird basierend auf der Funktion EAM_update_entity_authenticated() die durch die gegebenen Entitäts-Identifikation entity_id referenzierte Entität zu einer Liste von erfolgreich authentisierten Entitäten hinzugefügt und der Wert true zurückgegeben. War die Authentisierung der Entität nicht erfolgreich, wird lediglich der Wert false zurückgegeben.
• – public out bool EAM_logoff_entity (in entity_id) Gemäß dieser Operation wird zunächst beim Sicherheitsregel-Entscheidungs-Modul basierend auf der Funktion PDM_authorize() nach einer geeigneten Logoff-Autorisierung des Aufrufers der Operation gesucht. Anschließend wird mit dem Befehl EAM_lookup_entity() nach der Entität gesucht, welche durch die gegebene Entitäts-Identifikation entity_id in der lokalen Liste der erfolgreich authentisierten Entitäten referenziert ist. Die Entitäts-Identifikation entity_id wird dann von der Liste entfernt und der Wert true zurückgegeben. Ansonsten wird der Wert false zurückgegeben.
• – public out bool EAM_create_authentication_ticket (in entity_id, in ticket_rules, out auth_ticket) Gemäß dieser Operation wird zunächst mit der Funktion EAM_lookup_entity() nach der Entität gesucht, welche durch die gegebene Entitäts-Identifikation entity_id in der lokalen Liste der erfolgreich authentisierten Entitäten referenziert wird. Anschließend wird ein Authentisierungsticket für diese Entität erzeugt, welches die erforderliche Metainformation gemäß den individuellen Ticket-Erzeugungs-Regeln, gegeben durch ticket_rules, enthält (z. B. das Authentisierungs-Schema, die Authentisierungs-Zeit und dergleichen). Schließlich wird die Metainformation in die Variable auth_ticket geschrieben und der Wert true zurückgegeben. Ansonsten wird der Wert false zurückgegeben. Im Falle, dass der Aufrufer der Operation nur die Information benötigt, ob eine bestimmte Entität überhaupt eingeloggt ist, kann die Ausgabe auth_ticket ignoriert werden und der Aufrufer muss nur den zurückgegebenen boolschen Wert interpretieren. Im Falle, dass der Aufrufer ein Pseudonym benötigt, umfasst die Variable ticket_rules auch die entsprechende Regel zur Generierung eines Pseudonyms.
• – public out bool EAM_verify_authentication_ticket (in entity_id, in auth_ticket) Gemäß dieser Operation wird ein gegebenes Authentisierungsticket auth_ticket für eine Entität, welche durch die Entitäts-Identifikation entity_id gegeben ist, unter Verwendung des Moduls CRS verifiziert. Dabei wird der Wert true zusammen mit diesem Authentisierungsticket zurückgegeben, falls die Entität erfolgreich authentisiert werden kann. Ansonsten wird der Wert false zurückgegeben. Im Unterschied zur obigen Operation EAM_login_entity() impliziert diese Funktion nicht automatisch einen lokalen Login. Somit wird diese Funktion nur zur Entitäts-Authentisierung genutzt.
• – private out bool EAM_log_authentication_event (in authentication_event) Für alle sicherheitsrelevanten Authentisierungs-Ereignisse (z. B. erfolgreiche Logins, fehlgeschlagene Logins) ruft das Modul EAM intern diese Funktion auf, um interne Antworten des EAM-Moduls (z. B. die Verlängerung von Verzögerungen zwischen erfolglosen Logins) zu ermöglichen und um dem Sicherheits-Überwachungs-Modul zu berichten, so dass potentiell unberechtigte Intrusionen detektiert werden können.

In the following, the interfaces are first mentioned and their functionality explained below:

• Public out bool EAM_login_entity (in entity_id, in / out auth_credential) According to this interface, the entity referenced by a given entity identifier entity_id is first classified for appropriate authentication schemes, optionally via the PDM module. Subsequently, the authentication credential auth_credential is verified according to the authentication scheme used using the module CRS. In this case, the authorization statement auth_credential can represent a so-called "multistep credential" (eg a challenge-response protocol), which can have intermediate input or output data. Similarly, the credential auth_credential may include an authentication ticket from an external authentication service, for example, from a backend authentication. Finally, based on the function EAM_update_entity_authenticated (), the entity referenced by the given entity identifier entity_id is added to a list of successfully authenticated entities and the value true is returned. If the authentication of the entity was unsuccessful, only the value false is returned.
• - public out bool EAM_logoff_entity (in entity_id) According to this operation, the security rule arbitration module first looks for a suitable logoff authorization of the invoker of the operation based on the PDM_authorize () function. Then, the EAM_lookup_entity () command is used to search for the entity referenced by the given entity identifier entity_id in the local list of successfully authenticated entities. The Entity Identifier entity_id is then removed from the list and returned true. Otherwise, the value false is returned.
• - public out bool EAM_create_authentication_ticket (in entity_id, in ticket_rules, out auth_ticket) According to this operation, the entity EAM_lookup_entity () is first used to look for the entity referenced by the given entity identifier entity_id in the local list of successfully authenticated entities becomes. Subsequently, an authentication ticket is generated for this entity, which contains the required meta information according to the individual ticket generation rules given by ticket_rules (eg the authentication scheme, the authentication time and the like). Finally, the metainformation is written to the auth_ticket variable and returned true. Otherwise, the value false is returned. In case the caller of the operation only needs the information as to whether a particular entity is ever logged in, the output auth_ticket can be ignored and the caller need only interpret the returned boolean value. In the case that the caller needs a pseudonym, the variable ticket_rules also includes the corresponding rule for generating a pseudonym.
• Public out bool EAM_verify_authentication_ticket (in entity_id, in auth_ticket) According to this operation, a given authentication ticket auth_ticket for an entity given by the entity identification entity_id is verified using the module CRS. The value true is returned together with this authentication ticket if the entity can be successfully authenticated. Otherwise, the value false is returned. In contrast to the above operation EAM_login_entity (), this function does not automatically imply a local login. Thus, this feature is used only for entity authentication.
• - private out bool EAM_log_authentication_event (in authentication_event) For all security-relevant authentication events (eg successful logins, failed logins), the EAM module internally calls this function to retrieve internal responses from the EAM module (eg extension of Delays between unsuccessful logins) and to report to the security monitoring module so that potentially unauthorized intrusions can be detected.

The Entity Authentication Module uses the variables EAM_entity_authenticated as attributes (that is, as internal data). This variable corresponds to a list of all currently successfully authenticated entities together with meta information about the corresponding authentication scheme (eg authentication via password, authentication via a corresponding ticket) as well as the login time and the like. Another attribute of the entity authentication module is the EAM_authentication_artifacts. This is a set of local authentication artifacts, eg. Password hashes, public keys, certificates and the like. These artifacts are used to process authentication requests.

The EAM module in the embodiment described herein depends on other modules, i. H. the EAM module uses operations of other modules. In particular, the PDM module is used to decide which entity authentication method to use (unless this decision is pre-configured in the EAM module). The CRS module is used to implement the cryptographic authentication schemes and mechanisms. The CCM module is used for secure calling and inter-module communication. The SSM module is used for secure non-volatile storage of authentication artifacts. The PIM module serves to prove the trustworthiness of the platform configuration.

In the following, for clarity by means of UML diagrams, the 2 and 3 the execution of the functions EAM_login_entity and EAM_verify_authentication_ticket described above is explained. The functions mentioned in the following diagrams are corresponding implementations in the form of so-called plugins. Certain plugins return so-called EAMPlugin return codes from a plurality of return codes. The return codes for EAM_verify_authentication_ticket include the following return codes with the following meaning content:

"AuthenticationAccepted":

The process of authentication has been successfully completed.

"AuthenticationFailed":

The process failed and all information related to the entity is discarded.

"AuthenticationPending":

The process needs more steps to complete. The process is called again with new data in authentication_ticket.

"FunctionNotSupported":

A protocol that is not supported was selected when authentication was performed. All data will be deleted.

"Unknown Ticket Type":

The data in the authentication_ticket variable is corrupted. All data will be deleted.

When performing the EAM_login_entity operation according to 2 First, the corresponding authentication ticket and the corresponding entity are transferred to the function EAM_verify_authentication_ticket. This is illustrated by the variables AuthenticationTicket and Entity. After performing the verification according to the method EAM_verify_authentication_ticket, which is described below in relation to 3 is described, the corresponding authentication ticket and the generated EAMPluginReturnCodes is issued. It is then determined whether an EAMPluginReturnCode is set to "AuthenticationAccepted". If so, the entity status is set to login. In all other cases, no entity status is stored. In the case of the return code "AuthenticationFailed", a message is sent to the security monitoring module to inform this module that the authentication did not work. According to 2 Furthermore, the authentication ticket and the EAMPluginReturnCodes are given to the function EAM_log_authentication_event for logging the authentication event. Finally, the authentication ticket and the EAMPluginReturnCodes are returned.

3 shows the execution of the EAM_verify_authentication_ticket method. As already out 2 can be seen, this function receives the authentication ticket and the entity which is in 3 analogous to 2 labeled AuthenticationTicket and Entity. Subsequently, the selection of a plug-in for verification of the authentication ticket is based on the entity and the authentication ticket. The authentication ticket and the entity are then processed in a further step such that an authentication artifact for entity and plug-in is searched for. Authentication artifacts are internal security credentials that are stored directly in the module, such as security credentials. As a password or a private or public key. The plugin does not have to worry about the secure storage of this data. This data is centrally managed and can be used by any plugin. The entire security context, ie the data currently being processed by a plugin, is also managed by the EAM module and not by the plugins themselves. This further reduces the complexity of the plugins. Unlike the authentication artifacts, an authentication ticket is an input from an application that uses the EAM module. This ticket will be handed over to the corresponding plugin. It contains processing information for the specific EAM plugin, such as: As an encrypted password, which must then be decrypted in the plugin for the first time and then adjusted with the stored artifact in the EAM module.

Is according to 3 a verification authentication plugin is found, the verification is performed according to this plugin based on the method verify_authentication_ticket. Finally, the authentication ticket and the EAMPluginReturnCodes are returned. If no plugin is found, the return code UnknownTicketType is returned.

The embodiments of the inventive method described above represent a modular system for implementing safety applications in a vehicle or external units communicating with the vehicle. This modular system is preferably used in the implementation of appropriate software applications in the form of a library, to which the Software Developer has access and their interfaces, he can use to implement security applications. An interface is also provided, with which appropriate security implementations can be configured by the developer. Optionally, it is also possible to perform a reconfiguration of security mechanisms during the runtime of an application. In this way, based on the safety building kit, various safety mechanisms can be flexibly integrated into a given vehicle safety system. In particular, each security mechanism can also be used for many different software applications within a system environment. The individual safety functions are provided by the respective modules and their external interfaces in a simple way the application developer.

bibliography

• [1] EMVY: The Embedded Vehicular IT Security Construction Kit, Basic Concept from December 17, 2009, BMW Group Research and Technology
• [2] Design Specification - BMW Group Research and Technology, December 17, 2009

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited non-patent literature

• RFC 3748 [0052]

Claims (18)

Method for the computer-assisted provision of a development environment for implementing security applications in a vehicle architecture, in particular in a motor vehicle architecture, characterized in that a plurality of security modules (SM1, SM2, SM3) is provided, each security module (SM1, SM2, SM3 ) comprises a number of security applications, wherein one or more of the security applications of a respective security module (SM1, SM2, SM3) are called via one or more interfaces (IF1, IF2, ..., IF6) by external applications (A1, A2, A3) and wherein one or more of the security applications of a respective security module (SM1, SM2, SM3) are configurable in implementation. A method according to claim 1, characterized in that one or more of the security applications are configurable only in the implementation and / or that one or more of the security applications are configurable and / or updatable both at implementation and at runtime. A method according to claim 1 or 2, characterized in that the security applications of the security modules comprise operations from or between one or more control devices in the vehicle and / or external units arranged outside the vehicle. Method according to one of the preceding claims, characterized in that at least part of the security modules (SM1, SM2, SM3) comprises one or more internal interfaces, via which security applications of the security modules (SM1, SM2, SM3) can call each other. Method according to one of the preceding claims, characterized in that the security applications of the plurality of security modules (SM1, SM2, SM3) are distributed to a plurality of different internal entities in the vehicle and / or external entities outside the vehicle. Method according to one of the preceding claims, characterized in that at least a part of the security applications of the plurality of security modules (SM1, SM2, SM3) are implemented via plugins. Method according to one of the preceding claims, characterized in that the security applications of one or more security modules (SM1, SM2, SM3) and in particular each security module (SM1, SM2, SM3) provide one or more and in particular all of the following operations: - the granting of permits to carry out operations requested by an entity; - the revocation of granted licenses to carry out operations; - looking up whether an entity currently has permission to perform an operation; - setting security rules for local enforcement within the security module. Method according to one of the preceding claims, characterized in that the plurality of security modules (SM1, SM2, SM3) comprises one or more of the following security modules (SM1, SM2, SM3): A communication control module for communication between internal entities in the vehicle and / or external entities outside the vehicle; Relate to an entity authentication module for identifying and authenticating entities; A security rule decision module for managing given security rules; - a security monitoring module to monitor the execution of security applications; A secure memory module for cryptographically secured storage of data; - a platform integrity module to detect security module and security application tampering; A cryptography module for providing cryptographic services. A method according to claim 8, characterized in that the security applications of the communication control module provide one or more of the following operations: - the provision of various secure communication channels; - the construction of a cryptographically secured communication channel; The sending and receiving of data via a cryptographically secured communication channel; The termination of a cryptographically secured communication channel; The setting of communication filters on a cryptographically secured communication channel; The logging of events relating to security applications of the communication control module. A method according to claim 8 or 9, characterized in that the security applications of the entity authentication module provide one or more of the following operations: - the verification of authenticity and the evaluation of the trustworthiness of an entity; The authentication of entities with authentication data; - the logout of entities; The generation of authentication data, in particular of authentication tickets; The verification of authentication data, in particular of authentication tickets; - logging events relating to security applications of the Entity Authentication Module; Method according to one of claims 8 to 10, characterized in that the security applications of the security rule decision module provide one or more of the following operations: A query and check whether an entity is authorized to perform certain operations based on security rules and / or based on authentication data; - the setting of security rules; - the review of decisions made by the security rule-decision module; - logging events relating to security applications of the security rule arbitration module; - the delegation of decisions to other safety rule decision modules; - the transformation of one or more security rule languages into the language of the security rule decision module - the integration of decision-making plug-ins for decision-making based on one or more security rule languages. Method according to one of the claims 8 to 11, characterized in that the security applications of the security monitoring module provide one or more of the following operations: - the activation and deactivation of the monitoring of resources or services; - the passive monitoring of events; - the setting of recognition patterns to detect attacks by unauthorized persons; - setting response rules in response to detection of an attack; - the execution of countermeasures after the detection of an attack by an unauthorized person; The triggering of an alarm after the detection of an attack by an unauthorized person; - the processing of logging events from other security modules. Method according to one of claims 8 to 12, characterized in that the security applications of the secure storage module provide one or more of the following operations: - the provision of various secure storage systems, in particular via plugins; The opening and / or integration of data objects in accordance with predetermined security parameters; The reading of previously opened data objects according to predetermined safety parameters; The writing into previously opened data objects according to predetermined safety parameters; - the deletion of data objects; - logging events relating to security applications of the secure storage module. Method according to one of claims 8 to 13, characterized in that the security applications of the platform integrity module provide one or more of the following operations: The extension of initial platform integrity measurements by one or more measurements; - secure query of platform integrity metrics; - encrypting data and mapping it to a platform integrity measurement state; - logging events relating to platform integrity module security applications; - safely starting a platform; - attesting the trustworthiness of a platform to other entities; The cryptographic binding of data to a specific configuration of a platform and / or to a unique platform identifier. Method according to one of claims 8 to 14, characterized in that the security applications of the cryptographic module provide one or more of the following operations: The generation of hash values; The generation of message authentication codes; - the generation of random numbers; - the verification of hash values; The verification of message authentication codes; - the verification of signatures; - the encryption of data; - the decryption of data. Computer program product with a program code stored on a machine-readable carrier for carrying out a method according to one of the preceding claims, when the program runs on a computer. Method for providing a runtime environment for implementing security applications in a vehicle architecture, in particular in a motor vehicle architecture, wherein the security applications are implemented by means of a development environment provided according to a method according to one of claims 1 to 15, characterized in that external applications ( AP1, AP2, AP3) at least partially Call one or more security applications from one or more security modules (SM1, SM2, SM3) via corresponding interfaces. Vehicle, in particular a motor vehicle, comprising one or more control devices on which security applications run during operation based on the method according to claim 17.

Images