WO2018046345A1 - Steuergeräteverbund - Google Patents

Steuergeräteverbund Download PDF

Info

Publication number
WO2018046345A1
WO2018046345A1 PCT/EP2017/071615 EP2017071615W WO2018046345A1 WO 2018046345 A1 WO2018046345 A1 WO 2018046345A1 EP 2017071615 W EP2017071615 W EP 2017071615W WO 2018046345 A1 WO2018046345 A1 WO 2018046345A1
Authority
WO
WIPO (PCT)
Prior art keywords
management
access permission
permission information
rights management
rights
Prior art date
Application number
PCT/EP2017/071615
Other languages
English (en)
French (fr)
Inventor
Andre Barkowski
Gafur Zymeri
Wolfgang Fischer
Klaus Schneider
Original Assignee
Robert Bosch Gmbh
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 Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to CN201780054255.8A priority Critical patent/CN109643338A/zh
Priority to US16/330,575 priority patent/US20200226230A1/en
Publication of WO2018046345A1 publication Critical patent/WO2018046345A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G06F21/123—Restricting unauthorised execution of programs by using dedicated hardware, e.g. dongles, smart cards, cryptographic processors, global positioning systems [GPS] devices
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2153—Using hardware token as a secondary aspect
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/103—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for protecting copy right

Definitions

  • the invention relates to a control unit network.
  • a method for computer-assisted rights management for systems with at least two different data processing units in which a central rights manager is provided.
  • the latter manages rights information associated with data intended for the data processing units and releases the data intended for the data processing units in dependence on this rights information.
  • independent claim 1 has the advantage that it can be implemented with very little effort and fits well into an existing over-the-air vehicle infrastructure (Device Management, Content Management).
  • a device management as described in claim 1 can thus be made applicable in a particularly simple manner both for the rights management and for other applications.
  • a rights management also called license management or rights management
  • a backend system such as a server
  • the invention relates to a control unit network, in particular of a vehicle, with
  • access permission information is stored retrievable by the rights management, in particular on request
  • control unit functions are executable stored on other control units of the control unit network - Wherein at least one, preferably all, the further control devices is designed as a request control device and is set up as such, depending on a stored in the rights management and received by this access permission information perform these functions, or not, characterized, the control unit also includes a device management
  • the device management is set up, via a communication interface to connect to a particular vehicle external server
  • the device management is set up to provide the rights management via this interface received from the server update access permissions.
  • the request control device may in particular be configured to directly receive the access permission information from the rights management, i. e.g. in that the rights management is set up to send the access permission information to the request control device.
  • a function can be a standalone computer program, an additional feature of a computer program, or the use of a software function with a particular set of parameters. It may also be an at least partially implemented hardware function.
  • Access of the request control device to the rights management may be via an interface formed locally (e.g., by wrapper) or executed as a service-oriented communication.
  • an interface formed locally (e.g., by wrapper) or executed as a service-oriented communication.
  • protocols are used which are already established in the automotive sector, for example SOM E / IP or SOC).
  • the access permission information is advantageously deposited such that it is associated with either a unique tuple comprising a vehicle identification number and a function identification number, or a triple of vehicle identification number, user identification number, and function identification number. Examples of these are shown by way of example in FIG.
  • the request control device can be set up to request the access permission information in the rights management before receiving the access permission information.
  • Such access advantageously takes place via an API, as shown by way of example in FIG.
  • Rights management API uses by functions are advantageously synchronized synchronously against the local access rights information in the rights management. For this purpose, it may be provided to carry out a local comparison with the access permission information and advantageously immediately to deliver a synchronous response to the request control device.
  • the rights management is set up to renew the list of stored access permissions in accordance with the received update.
  • Such a renewal can take place, for example, depending on the user identification number or depending on the vehicle identification number and user identification number, as shown by way of example in FIG. 4 or FIG. 5.
  • Such a renewal advantageously takes place asynchronously.
  • These asynchronous rights management activities are advantageously hidden from the request controllers and the rights management API.
  • the device management is set up to receive via the interface information that is addressed to a device of the list, to identify this device and to provide this information to this device.
  • the rights management is registered by an (in-vehicle) registration process in the device management, and added to the list of devices.
  • the device management is thereby able to assign messages and responses, which are received by the server and addressed to the rights management, to the rights management. This allows rights management to respond to information sent to it by the server.
  • the device management is also set up to receive access permission information existing from the rights management and to transmit it to servers, for example together with the vehicle identification number.
  • the rights management transmits the access permission information for storage in a memory to a content management, wherein the content management is set up to receive data, in particular from a plurality of control devices, and store it in the memory , This is particularly efficient to implement, as other applications are demanding robust and tamper-proof storage not only from rights management but also from other applications.
  • the content management can be set up to store the data in the memory in encrypted form by means of a hardware security module, wherein only the hardware security module has access to the memory. This makes it possible to ensure the trustworthiness and the integrity of the data in a particularly efficient manner while at the same time allowing the data to be changed.
  • provision can be made in particular for the access permission information to be stored in a memory of a control unit which is not the control unit on which the rights management is set up.
  • FIG. 1 shows a control unit network of a motor vehicle
  • FIG. 2 shows a possible structuring of the access permission information
  • FIG. 3 shows a possible access via the rights management API
  • FIG. 4 shows a possible creation, deletion or modification of the access permission information via the rights management API
  • FIG. 5 shows another possible creation, deletion or modification of the access permission information via the rights management API.
  • FIG. 1 shows by way of example a vehicle 1 with a control unit network comprising a control unit 100 on which the rights management 20 and the device management 10 are stored.
  • the control unit network further comprises further control units 200, 300, 400, 500.
  • Software units 310, 410 are stored on the control units 300, 400. To execute the software functions 310, 410, they send a request to the rights management API 20, and inquire whether there is currently an access permission to execute this software function 310, 410.
  • the control units 300, 400 are registered with the device management 10 and can be addressed by it.
  • the software functions 310, 410 can be, for example, features that are already present in the vehicle 1, but which only have to be unlocked by a corresponding access permission. This may be, for example, a lane departure warning, which can be optionally purchased or unlocked by the driver of the vehicle 1.
  • the software functions 310, 410 may also be a function that can be subsequently installed for the vehicle 1. After the installation of the function 310, it can be provided that the function 310 logs on to the device management 10.
  • the rights management After requesting the API, the rights management optionally queries via an identity management 510, which is stored in the control unit 500, the vehicle identification number and the driver identification number, which transmits this to the rights management 20.
  • the rights manager 20 checks whether the access permission for executing the software function 310, 410 is present and returns the result of the software function 310, 410. For this purpose, the rights brokerage 20 accesses the memory 50 via the content management 30. Content Management 30 and memory 50 are implemented on the controller 200 that is not the controller 100 is. The software functions 310, 410 also access the memory 50 via the content management 30.
  • the access of the content management 30 to the memory 50 via the hardware security module 40 which is also installed on the control unit 200 and ensures that the information on the memory 50 is not accessed or changed by an attack unauthorized.
  • the rights management 20 is registered with the device management 10.
  • the device management 10 can connect to the off-vehicle server 600 via a connectivity interface. This connection is typically wireless, that is "over-the-air.” For example, in this system, the back-end system 600 is installed.
  • the rights management 20 can provide the device management 10 with currently stored access permission information.
  • the device management 10 transmits this currently stored access permission information to the server 600.
  • the server 600 checks whether this access permission information corresponds to the current status of the server 600 on the level of access permission information. If this is not the case, the server 600 sends the device management 10 an update of the access permission information.
  • the device management 10 receives this update, identifies that the rights management 20 is the addressee of the update and transmits the update of the rights management 20.
  • the rights management 20 performs via the content management 30 a corresponding update of the access permission information stored in the memory 50.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • General Physics & Mathematics (AREA)
  • Remote Sensing (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

Steuergeräteverbund mit -einem Steuergerät (100), auf dem eine Rechteverwaltung (20) eingerichtet ist, -wobei Zugriffserlaubnisinformationen von der Rechteverwaltung (20) abrufbar abgelegt sind, -wobei auf weiteren Steuergeräten (300, 400) des Steuergeräteverbunds Funkti- onen (310, 410) ausführbar hinterlegt sind, -wobei mindestens eines der weiteren Steuergeräte(300, 400) als ein Anfrage- steuergerät (300, 400) ausgebildet ist, und als solches eingerichtet ist, abhängig von einer in der Rechteverwaltung (20) abgelegten Zugriffserlaubnisinformatio- nen diese Funktionen auszuführen, oder nicht, dadurch gekennzeichnet, das Steuergerät (100) auch ein Device Management (10) umfasst -wobei das Device Management (10) eingerichtet ist, über eine Kommunikati- onsschnittstelle eine Verbindung mit einem Server (600) aufzunehmen - wobei das Device Management (10) eingerichtet ist, der Rechteverwaltung (20) ein über diese Schnittstelle von dem Server (600) empfangenes Update der Zu- griffserlaubnisse zur Verfügung zu stellen

Description

Beschreibung
Titel
Steuergeräteverbund
Die Erfindung betrifft einen Steuergeräteverbund. Stand der Technik
Aus der DE 10 2004 048 126 A1 ist ein Verfahren zum rechnergestützten Rechtemanagement für Systeme mit wenigstens zwei unterschiedlichen Datenverarbeitungseinheiten bekannt, bei dem ein zentraler Rechtemanager vorgesehen ist. Dieser verwaltet Rechteinformationen, die für die Datenverarbeitungseinheiten bestimmten Daten zugeordnet sind, und gibt die für die Datenverarbeitungseinheiten bestimmten Daten in Abhängigkeit dieser Rechteinformationen frei.
Vorteile der Erfindung
Das Verfahren mit den Merkmalen des unabhängigen Anspruch 1 hat demgegenüber den Vorteil, dass es mit besonders geringem Aufwand implementiert werden kann sowie sich in eine bestehende Over-The-Air Fahrzeuginfrastruktur (Device Management, Content Management) gut einfügt. Ein Device Management wie in Anspruch 1 beschrieben kann somit auf besonders einfache Weise sowohl für die Rechteverwaltung als auch für andere Anwendung anwendbar gemacht werden.
Vorteilhafte Weiterbildungen sind Gegenstand der abhängigen Ansprüche. Offenbarung der Erfindung Zum Etablieren eines gewünschten Geschäftsmodells ist es denkbar, Eigenschaften einer Software bzw. einer Funktion abhängig von entsprechenden Zugriffserlaubnissen ausführbar vorzuhalten, und hierfür Geräte- und/oder Nutzerdaten und sich daraus ergebende Zugriffserlaubnisinformationen (auch Lizenzen bzw. Entitlements genannt) in dem System, in dem die Software bzw. die Funktion ablaufen soll abrufbar zu halten.
Es ist hierbei wünschenswert, dass diese Zugriffserlaubnisinformationen sicher gespeichert werden, dass sie also nicht manipuliert werden können und dennoch aktualisierbar sind. So ist es möglich, dass der freigeschaltete Funktionsumfang während der Lebensdauer des Zielgeräts geändert werden kann.
Es ist möglich, dass eine Rechteverwaltung (auch Lizenzverwaltung oder Rechtemanagement genannt) auf einer Interaktion zwischen der Software bzw. Funktion, deren Ausführung von den Zugriffserlaubnissen abhängt und einem Backendsystem, beispielsweise einem Server, beruht, auf dem Zugriffserlaubnisinformationen vorgehalten werden.
Hierbei kann vorgesehen sein, die Schnittstellen zu der Rechteverwaltung in die Software oder Funktion statisch einzubinden. Diese muss dann zur Laufzeit eine Verbindung zur Rechteverwaltung aufnehmen können.
Insbesondere in einem Fahrzeug mit Connectivity-Ausstattung sollen neue Funktionen dynamisch eingebracht werden können. Hierfür ist es notwendig, dass das Fahrzeug mit einem entsprechenden Server Verbindung aufnimmt. Gleichzeitig ist es bei mobiler Connectivity nicht sichergestellt, dass dauerhaft eine Verbindung zu dem Server besteht.
In einem ersten Aspekt betrifft die Erfindung einen Steuergeräteverbund, insbesondere eines Fahrzeugs, mit
- einem Steuergerät, auf dem eine Rechteverwaltung eingerichtet ist,
- wobei Zugriffserlaubnisinformationen von der Rechteverwaltung insbesondere auf Anfrage abrufbar abgelegt sind,
- wobei auf weiteren Steuergeräten des Steuergeräteverbunds Funktionen ausführbar hinterlegt sind - wobei mindestens eines, vorzugsweise alle, der weiteren Steuergeräte als ein Anfragesteuergerät ausgebildet ist bzw. sind, und als solches eingerichtet ist, abhängig von einer in der Rechteverwaltung abgelegten und von dieser empfangenen Zugriffserlaubnisinformationen diese Funktionen auszuführen, oder nicht, dadurch gekennzeichnet, das Steuergerät auch ein Device Management umfasst
- wobei das Device Management eingerichtet ist, über eine Kommunikationsschnittstelle eine Verbindung mit einem insbesondere fahrzeugexternen Server aufzunehmen
- wobei das Device Management eingerichtet ist, der Rechteverwaltung ein über diese Schnittstelle von dem Server empfangenes Update der Zugriffserlaubnisse zur Verfügung zu stellen.
Hierzu kann das Anfragesteuergerät insbesondere eingerichtet sein, von der Rechteverwaltung direkt die Zugriffserlaubnisinformation zu empfangen, d.h. z.B. dass die Rechteverwaltung eingerichtet ist, die Zugriffserlaubnisinformation an das Anfragesteuergerät zu senden. Bei einer Funktion kann es sich hierbei um ein eigenständiges Computerprogramm handeln, oder um eine Zusatzfunktion eines Computerprogramms, oder um die Nutzung einer Softwarefunktion mit einem bestimmten Parametersatz handeln. Es kann sich auch um eine zumindest teilweise in Hardware implementierte Funktion handeln.
Mit einem solchen System ist es möglich, eine dynamische Lizensierung von Funktonen auch in einem„connected"- Fahrzeug anwendbar zu machen.
Hierdurch ist es möglich, die für ein Fahrzeug gültigen Zugriffsberechtigungen diesem konkreten Fahrzeug zuzuordnen (was vorteilhafterweise auf dem fahrzeugexternen Server geschieht), diese robust und sicher in das Fahrzeug einzubringen und mit dem Server synchron zu halten, die Rechteverwaltung im Fahrzeug zentral, robust und sicher zu gestalten und definierte Schnittstellen zwischen Rechteverwaltung und den Funktionen im Fahrzeug zu definieren.
Es ist dann möglich, die Zugriffserlaubnisinformationen zu einer Funktion beispielsweise abhängig von einer ermittelten Anzahl an Aufrufen dieser Funktion zu gestalten, und z. B. die Zugriffserlaubnis zu entziehen, wenn diese Anzahl eine vorgebbare Anzahl überschreitet.
Es ist auch möglich, diese Zugriffserlaubnis selektiv zu erlauben, beispielsweise um einem Kunden einer Autovermietung, der das Feature„Navigation" gebucht hat, die Nutzung eines Navigationssystems zu ermöglichen.
Der Zugriff des Anfragesteuergeräts auf die Rechteverwaltung kann über eine Schnittstelle erfolgen, die lokal (z.B. mittels Wrappers) ausgebildet ist oder als service-orientierte Kommunikation ausgeführt wird. In einem Fahrzeug werden hierbei vorzugsweise Protokolle verwendet, die im automotive- Bereich bereits etabliert sind, beispielsweise SOM E/IP oder SOC).
Die Zugriffserlaubnisinformationen sind vorteilhafterweise derartig hinterlegt, dass sie entweder einem eindeutigen Tupel umfassen eine Fahrzeugidentifikationsnummer und eine Funktionsidentifikationsnummer zugeordnet sind, oder einen Tripel aus Fahrzeugidentifikationsnummer, Nutzeridentifikationsnummer und Funktionsidentifikationsnummer. Beispiele hierfür sind exemplarisch in Figur 2 dargestellt.
In einer vorteilhaften Weiterbildung kann das Anfragesteuergerät eingerichtet sein, vor dem Empfang der Zugriffserlaubnisinformation bei der Rechteverwaltung die Zugriffserlaubnisinformationen anzufragen. Ein solcher Zugriff erfolgt vorteilhafterweise über ein API wie es exemplarisch in Figur 3 dargestellt ist. Rechteverwaltungs-API-Nutzungen durch Funktionen werden vorteilhafterweise synchron gegen die lokal in der Rechteverwaltung vorhandenen Zugriffserlaubnisinformationen abgeglichen. Hierzu kann vorgesehen sein, einen lokalen Abgleich mit den Zugriffserlaubnisinformationen durchzuführen und vorteilhafterweise sofort eine synchrone Antwort an das Anfragesteuergerät abzugeben.
In einer alternativen oder zusätzlichen Weiterbildung kann vorgesehen sein, dass die Rechteverwaltung eingerichtet ist, die Liste der abgelegten Zugriffserlaubnisse gemäß dem empfangenen Update zu erneuern. Eine solche Erneuerung kann beispielsweise abhängig von der Nutzeridentifikati- onennummer oder abhängig von Fahrzeugidentifikationsnummer und Nutzeri- dentifikationsnummer erfolgen, wie in Figur 4 bzw. Figur 5 exemplarisch gezeigt ist.
Eine solche Erneuerung erfolgt vorteilhafterweise asynchron. Diese asynchronen Aktivitäten der Rechteverwaltung sind den Anfragesteuergeräten und der API der Rechteverwaltung vorteilhafterweise verborgen.
In einer weiteren alternativen oder zusätzlichen Weiterbildung kann vorgesehen sein, dass das Device Management eingerichtet ist, eine Liste von Geräten, welche entweder in Hardware oder auch in Software oder in einer Mischform aus Hard- und Software implementiert sein können, vorzuhalten,
- wobei das Device Management eingerichtet ist, über die Schnittstelle Informationen zu empfangen, die an ein Gerät der Liste adressiert sind, dieses Gerät zu identifizieren und diesem Gerät diese Information zur Verfügung zu stellen.
Insbesondere kann vorgesehen sein, dass die Rechteverwaltung durch einen (fahrzeuginternen) Registrierungsprozess beim Device Management registriert wird, und der Liste von Geräten hinzugefügt wird.
Das Device Management ist dadurch in der Lage, Nachrichten und Antworten, die vom Server empfangen werden und an die Rechteverwaltung adressiert sind, der Rechteverwaltung zuzuordnen. Dadurch wird ermöglicht, dass die Rechteverwaltung auf Informationen reagiert, die vom Server an sie geschickt wurden.
In einer Weiterbildung kann vorgesehen sein, dass das Device Management auch eingerichtet ist, von der Rechteverwaltung bestehende Zugriffserlaubnisinformationen zu empfangen und an Server zu übermitteln, beispielsweise gemeinsam mit der Fahrzeugidentifikationsnummer.
Dies kann es dem Server ermöglichen, die Informationen auf Aktualität zu überprüfen und ggf. ein Update mit neueren Informationen zu veranlassen. Dieses Update kann dann ein Neuanlegen oder Verändern oder Löschen von Zugriffserlaubnisinformationen in der Rechteverwaltung bewirken. In einer weiteren alternativen oder zusätzlichen Weiterbildung kann vorgesehen sein, dass die Rechteverwaltung die Zugriffserlaubnisinformationen zum Abspeichern in einem Speicher an ein Content Management übermittelt, wobei das Content Management eingerichtet ist, Daten, insbesondere von einer Mehrzahl von Steuergeräten, zu empfangen und in dem Speicher abzulegen. Dies ist besonders effizient zu implementieren, da auch andere Anwendungen die Anforderungen an einen robusten und manipulationssicheren Speicher nicht nur von der Rechteverwaltung gestellt werden, sondern auch von anderen Anwendungen.
In einer Weiterbildung kann das Content Management eingerichtet sein, die Daten in dem Speicher mittels eines Hardware Security Moduls verschlüsselt abzulegen, wobei ausschließlich das Hardware Security Modul Zugriff auf den Speicher hat. Dies ermöglicht, die Vertrauenswürdigkeit und die Integrität der Daten besonders effizient sicherzustellen und gleichzeitig zu ermöglichen, dass die Daten veränderbar sind.
In einer alternativen oder zusätzlichen Weiterbildung kann insbesondere vorgesehen sein, dass die Zugriffserlaubnisinformationen in einem Speicher eines Steuergeräts abzulegen, das nicht dasjenige Steuergerät ist, auf dem die Rechteverwaltung eingerichtet ist.
Nachfolgend werden Ausführungsformen der Erfindung unter Bezugnahme auf die beiliegenden Zeichnungen näher erläutert. In den Zeichnungen zeigen:
Figur 1 einen Steuergeräteverbund eines Kraftfahrzeugs;
Figur 2 eine mögliche Strukturierung der Zugriffserlaubnisinformationen;
Figur 3 einen möglichen Zugriff über das Rechteverwaltungs-API;
Figur 4 einen mögliches Neuanlegen, Löschen oder Ändern der Zugriffserlaubnisinformationen über das Rechteverwaltungs-API; Figur 5 ein weiteres mögliches Neuanlegen, Löschen oder Ändern der Zugriffserlaubnisinformationen über das Rechteverwaltungs-API.
Figur 1 zeigt ein beispielhaft ein Fahrzeug 1 mit einem Steuergeräteverbund, der ein Steuergerät 100 umfasst, auf dem die Rechteverwaltung 20 und das Device Management 10 hinterlegt sind. Der Steuergeräteverbund umfasst ferner weitere Steuergeräte 200, 300, 400, 500. Auf den Steuergeräten 300, 400 sind Softwarefunktionen 310, 410 hinterlegt. Zur Ausführung der Softwarefunktionen 310, 410 senden diese eine Anfrage an das API der Rechteverwaltung 20, und erfragen, ob aktuell eine Zugriffserlaubnis zum Ausführen dieser Softwarefunktion 310, 410 vorliegt. Die Steuergeräte 300, 400 sind beim Device Management 10 angemeldet und von diesem adressierbar.
Bei den Softwarefunktionen 310, 410 kann es sich beispielsweise um Features handeln, die im Fahrzeug 1 bereits vorhanden sind, die jedoch erst durch eine entsprechende Zugriffserlaubnis freigeschaltet werden müssen. Hierbei kann es sich beispielsweise um einen Spurhalteassistenten handeln, der vom Fahrer des Fahrzeugs 1 optional erworben oder freigeschaltet werden kann.
Bei den Softwarefunktionen 310, 410 kann es sich auch um eine Funktion handeln, die für das Fahrzeug 1 nachinstallierbar ist. Nach erfolgter Installation der Funktion 310 kann vorgesehen sein, dass sich die Funktion 310 beim Device Management 10 anmeldet.
Nach erfolgter Anfrage an das API fragt die Rechteverwaltung optional über ein Identity Management 510, das im Steuergerät 500 hinterlegt ist, die Fahrzeugidentifikationsnummer und die Fahreridentifikationsnummer ab, die dieses an die Rechteverwaltung 20 übermittelt.
Die Rechteverwaltung 20 überprüft, ob die Zugriffserlaubnis für das Ausführen der Softwarefunktion 310, 410 vorliegt und meldet das Ergebnis der Softwarefunktion 310, 410 zurück. Hierzu greift die Rechtevermittlung 20 über das Content Management 30 auf den Speicher 50 zu. Content Management 30 und Speicher 50 sind auf dem Steuergerät 200 implementiert, das nicht das Steuergerät 100 ist. Über das Content Management 30 greifen auch die Softwarefunktionen 310, 410 auf den Speicher 50 zu.
Der Zugriff des Content Management 30 auf den Speicher 50 erfolgt über das Hardware Security Modul 40, das ebenfalls auf dem Steuergerät 200 installiert ist und dafür sorgt, dass die Informationen auf dem Speicher 50 nicht durch einen Angriff unerlaubt abgerufen oder verändert werden.
Die Rechteverwaltung 20 ist beim Device Management 10 registriert. Das Device Management 10 kann über eine Connectivity-Schnittstelle Verbindung mit dem fahrzeugexternen Server 600 aufnehmen. Diese Verbindung ist typischerweise drahtlos, also„over-the-air". In diesem ist beispielsweise das Backendsystem zur Rechteverwaltung 600 installiert.
Die Rechteverwaltung 20 kann dem Device Management 10 aktuell hinterlegte Zugriffserlaubnisinformationen zukommen lassen. Das Device Management 10 übermittelt diese aktuell hinterlegten Zugriffserlaubnisinformationen dem Server 600. Der Server 600 überprüft, ob diese Zugriffserlaubnisinformationen dem aktuell auf dem Server 600 hinterlegten Stand an Zugriffserlaubnisinformationen entsprechen. Ist dies nicht der Fall, übermittelt der Server 600 dem Device Management 10 ein Update der Zugriffserlaubnisinformationen. Das Device Management 10 empfängt dieses Update, identifiziert, dass die Rechteverwaltung 20 der Adressat des Updates ist und übermittelt das Update der Rechteverwaltung 20. Die Rechteverwaltung 20 führt über das Content Management 30 ein entsprechendes Update der im Speicher 50 hinterlegten Zugriffserlaubnisinformationen durch.
Es versteht sich für den Fachmann, dass die Erfindung in Software implementiert sein kann, oder in Hardware, oder in einer Mischform aus Hardware und Software.

Claims

Ansprüche
1. Steuergeräteverbund mit
- einem Steuergerät (100), auf dem eine Rechteverwaltung (20) eingerichtet ist,
- wobei Zugriffserlaubnisinformationen von der Rechteverwaltung (20) abrufbar abgelegt sind,
- wobei auf weiteren Steuergeräten (300, 400) des Steuergeräteverbunds Funktionen (310, 410) ausführbar hinterlegt sind,
- wobei mindestens eines der weiteren Steuergeräte (300, 400) als ein Anfragesteuergerät (300, 400) ausgebildet ist, und als solches eingerichtet ist, abhängig von einer in der Rechteverwaltung (20) abgelegten Zugriffserlaubnisinformationen diese Funktionen auszuführen, oder nicht,
dadurch gekennzeichnet, das Steuergerät (100) auch ein Device Management (10) umfasst
- wobei das Device Management (10) eingerichtet ist, über eine Kommunikationsschnittstelle eine Verbindung mit einem Server (600) aufzunehmen
- wobei das Device Management (10) eingerichtet ist, der Rechteverwaltung (20) ein über diese Schnittstelle von dem Server (600) empfangenes Update der Zugriffserlaubnisse zur Verfügung zu stellen.
2. Steuergeräteverbund nach Anspruch 1, wobei das Anfragesteuergerät (300, 400) eingerichtet ist, vor dem Empfang der Zugriffserlaubnisinformation bei der Rechteverwaltung (20) die Zugriffserlaubnisinformationen anzufragen.
3. Steuergeräteverbund nach einem der vorherigen Ansprüche, wobei die Rechteverwaltung (20) eingerichtet ist, die Liste der abgelegten Zugriffserlaubnisse gemäß dem empfangenen Update zu erneuern. Steuergeräteverbund nach einem der vorherigen Ansprüche
- wobei das Device Management (10) eingerichtet ist, eine Liste von Geräten vorzuhalten,
- wobei das Device Management (10) eingerichtet ist, über die Schnittstelle Informationen zu empfangen, die an ein Gerät (20, 300, 310, 400) der Liste adressiert sind, dieses Gerät (20, 300, 310, 400) zu identifizieren und diesem Gerät (20, 300, 310, 400) diese Information zur Verfügung zu stellen.
Steuergeräteverbund nach Anspruch 4, wobei das Device Management (10) eingerichtet ist, von der Rechteverwaltung (20) bestehende Zugriffserlaubnisinformationen zu empfangen und an Server (600) zu übermitteln.
Steuergeräteverbund nach einem der vorherigen Ansprüche, wobei die Rechteverwaltung (20) die Zugriffserlaubnisinformationen zum Abspeichern in einem Speicher (50) an ein Content Management (30) übermittelt, wobei das Content Management (30) eingerichtet ist, Daten zu empfangen und in dem Speicher (50) abzulegen.
Steuergeräteverbund nach Anspruch 6, wobei das Content Management (30) eingerichtet ist, die Daten in dem Speicher (50) mittels eines Hardware Security Moduls (40) verschlüsselt abzulegen, wobei ausschließlich das Hardware Security Modul (40) Zugriff auf den Speicher (50) hat.
Steuergeräteverbund nach einem der vorherigen Ansprüche, der eingerichtet ist, die Zugriffserlaubnisinformationen in einem Speicher (50) eines Steuergeräts (200) abzulegen, das nicht dasjenige Steuergerät (100) ist, auf dem die Rechteverwaltung (20) eingerichtet ist.
PCT/EP2017/071615 2016-09-06 2017-08-29 Steuergeräteverbund WO2018046345A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201780054255.8A CN109643338A (zh) 2016-09-06 2017-08-29 控制器复合体
US16/330,575 US20200226230A1 (en) 2016-09-06 2017-08-29 Control unit system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102016216821.5 2016-09-06
DE102016216821.5A DE102016216821A1 (de) 2016-09-06 2016-09-06 Verfahren und Vorrichtung zum Betreiben einer Brennkraftmaschine

Publications (1)

Publication Number Publication Date
WO2018046345A1 true WO2018046345A1 (de) 2018-03-15

Family

ID=59738358

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2017/071615 WO2018046345A1 (de) 2016-09-06 2017-08-29 Steuergeräteverbund

Country Status (4)

Country Link
US (1) US20200226230A1 (de)
CN (1) CN109643338A (de)
DE (1) DE102016216821A1 (de)
WO (1) WO2018046345A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021203323A1 (de) 2021-04-01 2022-10-06 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren, System und Domäne zum Bereitstellen einer Sicherheits-Ausführungsumgebung für sicherheitsrelevante Anwendungen

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10044917A1 (de) * 2000-09-12 2002-03-21 Volkswagen Ag Verfahren und Vorrichtung zur Nutzung von Funktionen und Leistungsmerkmalen in einem Kraftfahrzeug
DE102004048126A1 (de) 2004-10-02 2006-04-06 Robert Bosch Gmbh Verfahren zum rechnergesteuerten Rechtemanagement für Systeme mit wenigstens zwei unterschiedlichen Datenverarbeitungseinheiten
DE102009025585A1 (de) * 2009-06-19 2010-12-23 Audi Ag Vorrichtung zur dezentralen Funktionsfreischaltung eines Steuergeräts
WO2012126547A1 (de) * 2011-03-22 2012-09-27 Audi Ag Kraftwagen-steuergerät mit kryptographischer einrichtung

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160164881A1 (en) * 2014-12-03 2016-06-09 Ford Global Technologies, Llc Remote vehicle application permission control and monitoring

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10044917A1 (de) * 2000-09-12 2002-03-21 Volkswagen Ag Verfahren und Vorrichtung zur Nutzung von Funktionen und Leistungsmerkmalen in einem Kraftfahrzeug
DE102004048126A1 (de) 2004-10-02 2006-04-06 Robert Bosch Gmbh Verfahren zum rechnergesteuerten Rechtemanagement für Systeme mit wenigstens zwei unterschiedlichen Datenverarbeitungseinheiten
DE102009025585A1 (de) * 2009-06-19 2010-12-23 Audi Ag Vorrichtung zur dezentralen Funktionsfreischaltung eines Steuergeräts
WO2012126547A1 (de) * 2011-03-22 2012-09-27 Audi Ag Kraftwagen-steuergerät mit kryptographischer einrichtung

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021203323A1 (de) 2021-04-01 2022-10-06 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren, System und Domäne zum Bereitstellen einer Sicherheits-Ausführungsumgebung für sicherheitsrelevante Anwendungen

Also Published As

Publication number Publication date
CN109643338A (zh) 2019-04-16
DE102016216821A1 (de) 2018-03-08
US20200226230A1 (en) 2020-07-16

Similar Documents

Publication Publication Date Title
DE102020124163A1 (de) Verifizierung von fahrzeugdaten
DE112014005412B4 (de) Programmaktualisierungssystem und Programmaktualisierungsverfahren
DE102017110135A1 (de) Aktualisierungsverfahren für virtuelle DNS-Einträge zur dynamischen IP-Adressänderung eines im Fahrzeug untergebrachten Servers
DE10324189A1 (de) Verfahren zur Steuerung des Zugriffs auf eine Ressource einer Applikation in einer Datenverarbeitungseinrichtung
DE112014000623T5 (de) Zugriffbeschränkungseinrichtung, Bord-Kommunikationssystem und Verfahren zur Kommunikationsbeschränkung
DE102005000999A1 (de) Verfahren und System zum Fahrzeugkomponentenmanagement, Verfahren und System zum Aktualisieren von Fahrzeugkomponentenmanagementdaten, und Fahrzeugkomponentenmanagementcenter
DE102019135012A1 (de) Auf richtlinie und token basierender autorisierungsrahmen für konnektivität
DE102015114684A1 (de) Fahrzeug-Totalrücksetzung
DE102013202716A1 (de) Verfahren und Vorrichtung zum Freischalten mindestens einer softwarebasierten Funktion in mindestens einer elektronischen Steuereinheit eines Kraftfahrzeugs
DE102021130897A1 (de) Elektronische steuerungseinheit, softwareaktualisierungsverfahren, softwareaktualisierungsprogramm und elektronisches steuerungssystem
EP3080950B1 (de) Verfahren und system zur deterministischen autokonfiguration eines gerätes
DE102020122489A1 (de) Zugriffsautorisierung für verteiltes fahrzeugnetzwerk
EP3741094B1 (de) Steuerungssystem für ein kraftfahrzeug, verfahren zum betreiben des steuerungssystems sowie kraftfahrzeug mit einem derartigen steuerungssystem
WO2018046345A1 (de) Steuergeräteverbund
DE102014214041A1 (de) Informationsverarbeitungsgerät, Informationsverarbeitungsverfahren, Programm, Speichermedium und Informationsverarbeitungssystem
DE102011002713A1 (de) Verfahren und Vorrichtung zum Bereitstellen von kyptographischen Credentials für Steuergeräte eines Fahrzeugs
DE112016006524T5 (de) Authentifizierung einer Fahrzeugcomputeraktualisierung
DE102005034713A1 (de) System zur Bereitstellung von Funktionen für eine Fahrzeugkomponente
DE102022110251A1 (de) Ota-master, center, system, verfahren, nicht-transitorisches speichermedium und fahrzeug
EP2561460B1 (de) Verfahren zum konfigurieren einer applikation für ein endgerät
EP3225043B1 (de) Verfahren und vorrichtung zur kontrolle zumindest eines datenabrufs von einem steuergerät eines fahrzeugs sowie verfahren und vorrichtung zum abrufen von daten von einem steuergerät eines fahrzeugs
DE102020124046A1 (de) Dezentral autorisierte fahrzeugvorgänge
DE102016218988A1 (de) Kommunikationssystem
DE102020126909A1 (de) Sitzungsspezifischer zugriffstoken
DE102019112654A1 (de) Verfahren und system für distributed-ledger-technologie-kommunikationen für fahrzeuge

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17758542

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17758542

Country of ref document: EP

Kind code of ref document: A1