DE102016210788B4 - Komponente zur Verarbeitung eines schützenswerten Datums und Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer solchen Komponente - Google Patents

Komponente zur Verarbeitung eines schützenswerten Datums und Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer solchen Komponente Download PDF

Info

Publication number
DE102016210788B4
DE102016210788B4 DE102016210788.7A DE102016210788A DE102016210788B4 DE 102016210788 B4 DE102016210788 B4 DE 102016210788B4 DE 102016210788 A DE102016210788 A DE 102016210788A DE 102016210788 B4 DE102016210788 B4 DE 102016210788B4
Authority
DE
Germany
Prior art keywords
component
protection
data
protective measure
target class
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102016210788.7A
Other languages
English (en)
Other versions
DE102016210788A1 (de
Inventor
Alexander TSCHACHE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Volkswagen AG
Original Assignee
Volkswagen AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Volkswagen AG filed Critical Volkswagen AG
Priority to US15/434,304 priority Critical patent/US10303886B2/en
Priority to CN201710086126.9A priority patent/CN107092833B/zh
Publication of DE102016210788A1 publication Critical patent/DE102016210788A1/de
Application granted granted Critical
Publication of DE102016210788B4 publication Critical patent/DE102016210788B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • 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/60—Protecting data
    • 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/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • 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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • 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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • 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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Abstract

Komponente (10, 20) zur Verarbeitung eines schützenswerten Datums, wobei die Komponente (10, 20) eingerichtet ist, durch Ausführen der folgenden Schritte zumindest eine Sicherheitsfunktion zum Schutz des schützenswerten Datums umzusetzen, wobei die Sicherheitsfunktion zumindest eine Schutzmaßnahme aus einer Auswahl von zu einer Schutzzielklasse zugehörigen Schutzmaßnahmen umfasst:Bestimmen (30) einer zum schützenswerten Datum zugeordneten Schutzzielklasse; undAuswählen (31) zumindest einer Schutzmaßnahme aus der Auswahl von zur Schutzzielklasse zugehörigen Schutzmaßnahmen;wobei das schützenswerte Datum einer Schutzmaßnahme zugeordnet ist und die Sicherheitsfunktion zumindest die zugeordnete Schutzmaßnahme umfasst;wobei ein Datum einer ersten Schutzzielklasse vor unbefugtem Auslesen geschützt werden muss und ein Datum einer zweiten Schutzzielklasse vor unbefugter Manipulation geschützt werden muss; undwobei gemäß einer ersten Schutzmaßnahme das Datum ausschließlich in einem Hardware-Sicherheitsmodul der Komponente (10, 20) persistiert und nur von diesem verwendet wird, gemäß einer zweiten Schutzmaßnahme das Datum ausschließlich in einem internen Speicher der Komponente (10, 20) persistiert, zwischengespeichert undverwendet wird und gemäß einer dritten Schutzmaßnahme das Datum verschlüsselt und/oder signiert persistiert wird.

Description

  • Die vorliegende Erfindung betrifft eine Komponente zur Verarbeitung eines schützenswerten Datums, wobei die Komponente zumindest eine Sicherheitsfunktion zum Schutz des schützenswerten Datums umsetzt, sowie ein Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer solchen Komponente.
  • Die Druckschrift DE 10 2007 058 975 A1 offenbart ein gesichertes Bordnetz für ein Kraftfahrzeug. Verhindert werden soll die Manipulation der Software der diversen Steuergeräte. Zu diesem Zweck ist ein erstes Steuergerät mit einem Master Security Modul versehen, die weiteren Steuergeräte mit je einem Client Security Modul. Die Steuermodule tauschen signierte Nachrichten aus.
  • Die Druckschrift DE 10 2011 076 350 A1 offenbart ein Verfahren zur Manipulationserkennung an einem Fahrzeugnetzwerk. Zunächst wird ein digitaler Fingerabdruck des Fahrzeugnetzwerkes ermittelt. Dieser digitale Fingerabdruck wird mit Referenzinformationen verglichen. Abhängig vom Ergebnis des Vergleichs wird ein regulärer Steuerungsmodus aktiviert, falls keine Manipulation erkannt wurde, bzw. ein betriebssicherer Steuerungsmodus, falls eine Manipulation erkannt wurde.
  • Die Druckschrift WO 2015 / 007 673 A1 offenbart ein Verfahren zum automatisierten oder fernbedienbaren Steuern eines sicherheitsrelevanten Systems eines Fahrzeuges, ohne dass sich an Bord des Fahrzeuges ein handlungsfähiger Fahrer befinden muss. Zu diesem Zweck enthält die Kommunikation zwischen einer Anforderungseinrichtung, beispielsweise einem Funkschlüssel oder einem mobilen Kommunikationsgerät, mit einer Ausführvorrichtung im Fahrzeug Authentifizierungsinformationen.
  • Der Artikel G. Heling et al.: „Koexistenz von sicherer und nicht-sicherer Software auf einem Steuergerät“, ATZelektronik, 7. Jg. (2012), S. 62-65, beschreibt Konzepte für die effiziente Realisierung von Steuergeräten, die „Mixed-ASIL-Systeme“ darstellen, die also sowohl sicherheitsrelevante Funktionen als auch Funktionen ohne Sicherheitsbezug enthalten. Zum Schutz vor Speicherverletzungen wird der Schreibzugriff auf die Speicherbereiche der eigenen Partition begrenzt. Dazu wird eine Memory Protection Unit des Microcontrollers im Steuergerät verwendet. Die Software, die die Memory Protection Unit ansteuert und den Kontextwechsel ausführt, muss den höchsten zugewiesenen ASIL unterstützen.
  • Die Druckschrift US 2013 / 0 042 295 A1 beschreibt eine Realisierung einer sicheren Umgebung in einem mobilen Gerät für die Verarbeitung von Dokumenten und die Durchführung von sicheren Aktivitäten. Es wird eine sichere Anwendungsumgebung geschaffen, in der sichere Daten und Dokumente mittels Verschlüsselung von ungesicherten Daten getrennt werden, wodurch sich die Anwendung von Sicherheitsrichtlinien auf die sichere Anwendungsumgebung beschränken lässt.
  • Die Druckschrift US 2014 / 0 115 656 A1 beschreibt eine Einheit für Sicherheitsmanagement. Die Einheit enthält eine Tabelle mit Sicherheitsrichtlinien, die es erlaubt, Sicherheitsrichtlinien abhängig von einem angesprochenen Speicherbereich einer Speichereinheit unterschiedlich zu handhaben.
  • Die Druckschrift DE 10 2013 006 470 A1 beschreibt eine Mobilstation, die ein mobiles Endgerät und Sicherheitsressourcen umfasst. In der Mobilstation ist ein Ermittlungsmodul implementiert, mit dem die Sicherheitsressourcen der Mobilstation ermittelbar sind. Aus diesen kann ein erzielbares Sicherheitsniveau der Mobilstation abgeleitet und ausgegeben werden.
  • In heutigen Systemen mit diversen miteinander vernetzten Komponenten, beispielsweise in Kraftfahrzeugen mit einer Vielzahl von Steuergeräten, wird eine Reihe kryptografischer Funktionen unterschiedlicher Qualität verwendet. Oftmals wird dabei verlangt, dass bestimmte Daten geschützt gespeichert werden, beispielsweise kryptografisches Schlüsselmaterial. In der Regel stellen die verwendeten Funktionen entsprechende Schutzmaßnahmen zur Verfügung. Da diese Schutzmaßnahmen allerdings an unterschiedlichsten Stellen versagen können, beispielsweise durch einen falschen Ablageort der Daten, Fehler in der Software oder Fehler in den Prozessen, ist es relativ aufwändig, die Umsetzung der Forderung nach geschützter Speicherung der Daten zu gewährleisten.
  • Es ist daher eine Aufgabe der Erfindung, eine Komponente zur Verarbeitung eines schützenswerten Datums zur Verfügung zu stellen, die eine zuverlässige Umsetzung zumindest einer Sicherheitsfunktion zum Schutz des schützenswerten Datums gewährleistet.
  • Diese Aufgabe wird durch eine Komponente mit den Merkmalen des Anspruchs 1 gelöst.
  • Es ist eine weitere Aufgabe der Erfindung, ein Verfahren zur zuverlässigen Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer solchen Komponente aufzuzeigen.
  • Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des Anspruchs 4 gelöst.
  • Bevorzugte Ausgestaltungen der Erfindung sind Gegenstand der abhängigen Ansprüche.
  • Gemäß einem Aspekt der Erfindung setzt eine Komponente zur Verarbeitung eines schützenswerten Datums zumindest eine Sicherheitsfunktion zum Schutz des schützenswerten Datums um, wobei das schützenswerte Datum einer Schutzzielklasse zugeordnet ist und die Sicherheitsfunktion zumindest eine Schutzmaßnahme aus einer Auswahl von zur Schutzzielklasse zugehörigen Schutzmaßnahmen umfasst.
  • Gemäß einem weiteren Aspekt der Erfindung umfasst ein Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer Komponente zur Verarbeitung des schützenswerten Datums die Schritte:
    • - Bestimmen einer zum schützenswerten Datum zugeordneten Schutzzielklasse;
    • - Wahl zumindest einer Schutzmaßnahme aus einer Auswahl von zur Schutzzielklasse zugehörigen Schutzmaßnahmen; und
    • - Umsetzung der gewählten Schutzmaßnahme in der Komponente.
  • Durch die Definition von Schutzzielklassen und zugehörigen Schutzmaßnahmen werden die Anforderungen an die Schutzfunktionen zentral vereinheitlicht, so dass nicht jede Funktion ihre Anforderungen selbst stellen muss. Die Schutzzielklassen und Schutzmaßnahmen definieren zuverlässig, was unter dem gewünschten Umgang mit einem schützenswerten Datum zu verstehen ist. Dabei werden detaillierte Anforderungen an Hardware und Software, aber auch an Entwicklung, Prozesse und Qualitätsmaßnahmen gestellt, die sicherstellen, dass die Komponente die notwendige Sicherheit bietet. Auf diese Weise ist gewährleistet, dass die als schützenswert definierten Daten nicht ausgelesen oder manipuliert werden können. Die festgelegten Anforderungen beruhen insbesondere auf Erfahrungswerten der Entwicklung, an welchen Stellen es typischerweise durch Fehler zu Mängeln in der Sicherheit einer Komponente kommen kann. Dabei werden vorzugsweise auch Prozesse der Entwicklung betrachtet, nicht nur die Komponente isoliert.
  • Erfindungsgemäß ist das schützenswerte Datum einer Schutzmaßnahme zugeordnet. Die Sicherheitsfunktion umfasst dann zumindest die zugeordnete Schutzmaßnahme. Die allgemeingültigen Anforderungen der übergeordneten Schutzzielklasse bleiben dabei bestehen. Auf diese Weise kann bei Bedarf festgelegt werden, welche Schutzmaßnahme zwingend umzusetzen ist. Typischerweise sind für eine Schutzzielklasse mehrere Schutzmaßnahmen definiert, die alle ein Mindestmaß an Schutz bieten. Allerdings können einzelne Funktionen besondere, erhöhte Anforderungen haben. Eine Funktionsfreischaltung hat vielleicht andere Anforderungen als der Diebstahlschutz. Besondere Anforderungen können auch von extern kommen, z.B. die Verarbeitung von Zahlungsinformationen. Für solche Situationen ist es sinnvoll, die betroffenen schützenswerten Daten konkreten Schutzmaßnahmen zuzuordnen. Höherwertige Maßnahmen sind in der Regel teurer und können in ihrer Qualität über das hinausgehen, was die Schutzzielklasse als Mindestmaß festlegt. Daher sollten solche höherwertigen Maßnahmen nicht generell gefordert werden.
  • Erfindungsgemäß muss ein Datum einer ersten Schutzzielklasse vor unbefugtem Auslesen geschützt werden. Ein Datum einer zweiten Schutzzielklasse muss vor unbefugter Manipulation geschützt werden. Daten der ersten Schutzzielklasse sind „vertraulich“. Hierzu zählen z.B. geheime symmetrische Schlüssel und private Schlüssel eines asymmetrischen Schlüsselpaares. Ein Auslesen dieser Daten würde es ermöglichen, auf weitere vertrauliche Daten zuzugreifen. Daten der zweiten Schutzzielklasse sind „authentisch“. Hierzu zählen in der Regel z.B. Root-Zertifikate, globale öffentliche Schlüssel oder die Seriennummer der Komponente. Eine Manipulation solcher Daten würde es ermöglichen, die Identität einer Komponenten zu fälschen. Durch die Verwendung zumindest der beiden genannten Schutzzielklassen lassen sich die typischen Zielsetzungen der Schutzfunktionen abdecken.
  • Erfindungsgemäß wird im Rahmen einer ersten Schutzmaßnahme das Datum ausschließlich in einem Hardware-Sicherheitsmodul der Komponente persistiert und nur von diesem verwendet. Gemäß einer zweiten Schutzmaßnahme wird das Datum ausschließlich in einem internen Speicher der Komponente persistiert, zwischengespeichert und verwendet. Eine dritte Schutzmaßnahme besteht darin, dass das Datum verschlüsselt und/oder signiert persistiert wird. Die drei genannten Schutzmaßnahmen erlauben zum einen die Implementierung unterschiedlicher Schutzniveaus, zum anderen berücksichtigen sie die unterschiedlichen technischen Voraussetzungen verschiedener Komponenten. Beispielsweise ist nicht in jeder Komponente zwingend ein Hardware-Sicherheitsmodul implementiert.
  • Gemäß einem Aspekt der Erfindung ist für den Fall, dass die Komponente eine Schnittstelle aufweist, die einen lesenden oder schreibenden Zugriff auf ein schützenswertes Datum gewährt oder eine Manipulation einer Recheneinheit der Komponente erlaubt, diese Schnittstelle deaktiviert und abgesichert. Das Freischalten einer solchen Schnittstelle erfordert vorzugsweise eine komponentenindividuelle, dynamische Authentifizierung. Auf diese Weise wird berücksichtigt, dass im Rahmen der Entwicklung einer Komponente oftmals ein Entwicklerzugang erforderlich ist, der lesenden oder schreibenden Zugriff auf schützenswerte oder kryptografische Daten gewährt. Nach Abschluss der Entwicklung muss ein solcher Entwicklerzugang in den Serienkomponenten deaktiviert und abgesichert sein.
  • Vorzugsweise wird eine erfindungsgemäße Komponente in einem Fahrzeug, insbesondere einem Kraftfahrzeug, eingesetzt.
  • Weitere Merkmale der vorliegenden Erfindung werden aus der nachfolgenden Beschreibung und den angehängten Ansprüchen in Verbindung mit den Figuren ersichtlich.
    • 1 zeigt ein erstes Ausführungsbeispiel einer Komponente zur Verarbeitung eines schützenswerten Datums;
    • 2 zeigt ein zweites Ausführungsbeispiel einer Komponente zur Verarbeitung eines schützenswerten Datums;
    • 3 zeigt schematisch ein Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer Komponente zur Verarbeitung des schützenswerten Datums;
    • 4 zeigt die Erzeugung eines geschützten Bereiches in einem ungeschütztem Speicher;
    • 5 veranschaulicht die Erstellung geschützter Sicherheitskopien durch Secret-Sharing;
    • 6 zeigt eine Public-Key-Infrastruktur zur beidseitig authentifizierten Diagnose im Rahmen einer Produktion der Komponente; und
    • 7 zeigt eine Public-Key-Infrastruktur zur beidseitig authentifizierten Diagnose im Rahmen einer Diagnosetesterproduktion.
  • Zum besseren Verständnis der Prinzipien der vorliegenden Erfindung werden nachfolgend Ausführungsformen der Erfindung anhand der Figuren detaillierter erläutert. Es versteht sich, dass sich die Erfindung nicht auf diese Ausführungsformen beschränkt und dass die beschriebenen Merkmale auch kombiniert oder modifiziert werden können, ohne den Schutzbereich der Erfindung zu verlassen, wie er in den angehängten Ansprüchen definiert ist.
  • 1 zeigt eine vereinfachte schematische Darstellung einer ersten Ausführungsform einer Komponente 10 zur Verarbeitung eines schützenswerten Datums. Die Komponente 10 hat einen Eingang 11 zum Empfangen von Daten und einen Ausgang 15 zur Ausgabe von Daten. Über den Eingang 11 und den Ausgang 15 kann die Komponente 10 mit weiteren Komponenten in Verbindung stehen. Der Eingang 11 und der Ausgang 15 können als getrennte Schnittstellen oder als kombinierte bidirektionale Schnittstelle implementiert sein. Ein Sicherheitsmodul 12 setzt zumindest eine Schutzfunktion für ein schützenswertes Datum um, das einer Schutzzielklasse zugeordnet ist. Die Sicherheitsfunktion umfasst zumindest eine Schutzmaßnahme aus einer Auswahl von zur Schutzzielklasse zugehörigen Schutzmaßnahmen. Falls das schützenswerte Datum ausdrücklich einer Schutzmaßnahme zugeordnet ist, umfasst die Sicherheitsfunktion zumindest die zugeordnete Schutzmaßnahme. Erfindungsgemäß sind zumindest zwei Schutzzielklassen definiert. Daten einer ersten Schutzzielklasse müssen vor unbefugtem Auslesen geschützt werden, wohingegen Daten einer zweiten Schutzzielklasse vor unbefugter Manipulation geschützt werden müssen. Eine mögliche Schutzmaßnahme besteht z.B. darin, dass das Datum ausschließlich in einem Hardware-Sicherheitsmodul der Komponente persistiert und nur von diesem verwendet wird. Gemäß einer zweiten Schutzmaßnahme wird das Datum ausschließlich in einem internen Speicher der Komponente persistiert, zwischengespeichert und verwendet. Eine dritte Schutzmaßnahme sieht vor, dass das Datum verschlüsselt und/oder signiert persistiert wird. Die für die Umsetzung erforderlichen Funktionen, Verfahren und Protokolle werden beispielsweise von einem Funktionsmodul 14 bereitgestellt. Sie können aber auch im Sicherheitsmodul 12 selbst implementiert sein. Vom Sicherheitsmodul 12 verarbeitete Daten können über den Ausgang 15 bereitgestellt werden. Darüber hinaus können sie in einem Speicher 13 der Komponente 10 abgelegt werden. Das Sicherheitsmodul 12 und das Funktionsmodul 14 können als dezidierte Hardware realisiert sein, beispielsweise als integrierte Schaltungen. Natürlich können sie aber auch teilweise oder vollständig kombiniert oder als Software implementiert werden, die auf einem geeigneten Prozessor läuft. Für den Fall, dass die Komponente 10 eine Schnittstelle aufweist, die einen lesenden oder schreibenden Zugriff auf ein schützenswertes Datum gewährt oder eine Manipulation einer Recheneinheit der Komponente erlaubt, ist diese Schnittstelle deaktiviert und abgesichert. Das Freischalten einer solchen Schnittstelle erfordert vorzugsweise eine komponentenindividuelle, dynamische Authentifizierung.
  • 2 zeigt eine vereinfachte schematische Darstellung einer zweiten Ausführungsform einer Komponente 20 zur Verarbeitung eines schützenswerten Datums. Die Komponente 20 weist einen Prozessor 22 und einen Speicher 21 auf. Beispielsweise handelt es sich bei der Komponente 20 um einen Computer oder ein Steuergerät. Im Speicher 21 sind Instruktionen abgelegt, die die Komponente 20 bei Ausführung durch den Prozessor 22 veranlassen, eine Sicherheitsfunktion umzusetzen. Die Komponente 20 hat einen Eingang 23 zum Empfangen von Informationen. Vom Prozessor 22 generierte Daten werden über einen Ausgang 24 bereitgestellt. Darüber hinaus können sie im Speicher 21 abgelegt werden. Der Eingang 23 und der Ausgang 24 können zu einer bidirektionalen Schnittstelle zusammengefasst sein.
  • Der Prozessor 22 kann eine oder mehrere Prozessoreinheiten umfassen, beispielsweise Mikroprozessoren, digitale Signalprozessoren oder Kombinationen daraus.
  • Die Speicher 13, 21 der beschriebenen Ausführungsformen können volatile und/oder nichtvolatile Speicherbereiche aufweisen und unterschiedlichste Speichergeräte und Speichermedien umfassen, beispielsweise Festplatten, optische Speichermedien oder Halbleiterspeicher.
  • 3 zeigt schematisch ein Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer Komponente zur Verarbeitung des schützenswerten Datums. In einem ersten Schritt wird eine zum schützenswerten Datum zugeordnete Schutzzielklasse bestimmt 30. Aus einer Auswahl von Schutzmaßnahmen, die der Schutzzielklasse zugeordnet sind, wird dann zumindest eine Schutzmaßnahme ausgewählt 31. Gegebenenfalls ist das schützenswerte Datum ausdrücklich einer Schutzmaßnahme zugeordnet. In diesem Fall umfasst die Sicherheitsfunktion zumindest die zugeordnete Schutzmaßnahme. Die ausgewählten Schutzmaßnahmen werden schließlich in der Komponente umgesetzt 32. Erfindungsgemäß sind zumindest zwei Schutzzielklassen definiert. Daten einer ersten Schutzzielklasse müssen vor unbefugtem Auslesen geschützt werden, wohingegen Daten einer zweiten Schutzzielklasse vor unbefugter Manipulation geschützt werden müssen. Eine mögliche Schutzmaßnahme besteht z.B. darin, dass das Datum ausschließlich in einem Hardware-Sicherheitsmodul der Komponente persistiert und nur von diesem verwendet wird. Gemäß einer zweiten Schutzmaßnahme wird das Datum ausschließlich in einem internen Speicher der Komponente persistiert, zwischengespeichert und verwendet. Eine dritte Schutzmaßnahme sieht vor, dass das Datum verschlüsselt und/oder signiert persistiert wird. Für den Fall, dass die Komponente eine Schnittstelle aufweist, die einen lesenden oder schreibenden Zugriff auf ein schützenswertes Datum gewährt oder eine Manipulation einer Recheneinheit der Komponente erlaubt, wird diese Schnittstelle deaktiviert und abgesichert. Das Freischalten einer solchen Schnittstelle erfordert vorzugsweise eine komponentenindividuelle, dynamische Authentifizierung.
  • Nachfolgend soll eine bevorzugte Ausführungsform der Erfindung im Detail beschrieben werden. Dazu werden zunächst einige Begriffe und Abkürzungen definiert. Je nach Anwendungsbereich und erforderlicher Sicherheit können bei Bedarf auch andere kryptografischen Algorithmen und Verfahren freigegeben werden oder geänderte Parameter für diese festgelegt werden.
  • Begriffe
  • CPU (Central Processing Unit):
  • Dies wird als Einheitsbegriff für jegliche eigenständige Recheneinheit (single- oder multicore) verwendet, wie z.B. µC, FPGA, HSM, oder reguläre CPU.
  • HSM (Hardware Security Module):
  • Ein HSM ist eine dedizierte Hardware zur geschützten Persistierung von kryptografischen Daten und zur Ausführung kryptografischer Funktionen.
  • Persistieren:
  • Persisitieren bezeichnet das Speichern von Daten in nichtflüchtigem Speicher (Flash, EEPROM, Festplatte, usw.). Dies schließt das Überschreiben vorhandener Daten mit ein.
  • Individuell pro Komponente:
  • Der beschriebene Wert ist für jede produzierte Komponente verschieden. Als Komponente sind individuell produzierte, einzelne Komponenten gemeint, nicht eine Komponentenfamilie.
  • Kryptografische Algorithmen:
  • Hiermit werden mathematische Primitiven bezeichnet, welche Daten verarbeiten, z.B. Verschlüsselungsfunktionen oder Hashfunktionen.
  • Kryptografische Daten:
  • Hiermit werden geheime Daten bezeichnet, die im Rahmen der Verwendung von kryptografischen Algorithmen und Verfahren anfallen, z.B. Schlüssel, Rundenschlüssel, Zufallszahlen und Zwischenwerte.
  • Kryptografische Verfahren:
  • Hiermit werden Verfahren bezeichnet, die auf kryptografischen Algorithmen aufsetzen, z.B. Authentifizierungsverfahren oder Schlüsselableitungsverfahren.
  • Freigegebene Verfahren:
  • Hiermit werden kryptografische Algorithmen und Verfahren bezeichnet, die ausdrücklich zur Verwendung freigegeben sind.
  • Schützenswerte Daten:
  • Hiermit werden Daten bezeichnet, die mit Schutzkonzepten geschützt werden müssen.
  • Zufällig:
  • Die Wahrscheinlichkeit, dass ein bestimmter Wert aus einem Gesamtraum an Möglichkeiten ausgewählt wird, entspricht der Gleichverteilung. Anders ausgedrückt, jedes Element hat die gleiche Wahrscheinlichkeit ausgewählt zu werden. Ausgaben eines kryptografisch sicheren Zufallsgenerators, wie er weiter unten beschrieben wird, sind zufällig.
  • Bezugszeichenliste
    • AES
    Advanced Encryption Standard
    CA
    Certificate Authority
    CAN
    Controller area network
    CPU
    Central Processing Unit
    EEPROM
    Electrically Erasable Programmable Read-Only Memory
    EOL
    End of line
    FPGA
    Field-programmable gate array
    GCM
    Galois/Counter Mode
    HSM
    Hardware Security Module
    JTAG
    Joint Test Action Group
    PKI
    Public-Key-Infrastruktur
    RAM
    Random-Access Memory
    RSA
    Rivest-Shamir-Adleman
    SHE
    Secure Hardware Extension
    UART
    Universal asynchronous receiver/transmitter
    XCP/CCP
    Universal Measurement and Calibration Protocol/CAN Calibration Protocol
  • Allgemeine Anforderungen
  • Für die Entwicklung von Komponenten wird eine Auswahl von kryptografischen Algorithmen und Verfahren definiert. Ausschließlich diese kryptografischen Algorithmen und Verfahren sind zur Verwendung in Schutzkonzepten freigegeben. Alle Schutzkonzepte, die von den nachfolgenden Anforderungen berührt werden, müssen auf diesen Algorithmen und Verfahren beruhen.
  • Hardware in der Komponente
  • Kryptografische Funktionalität und sichere Software kann ohne sichere Hardware als Vertrauensanker nicht umgesetzt werden. Daher ist es notwendig, dass die Hardware der Komponente entsprechend der geforderten Schutzmaßnahmen Sicherheitseigenschaften aufweist.
  • Falls mehrere physikalisch voneinander getrennte CPUs an kryptografischen Funktionen oder Schutzkonzepten beteiligt sind, muss jede einzelne die nachfolgend beschriebenen Anforderungen erfüllen. Die Kommunikation zwischen ihnen muss entsprechend der Schutzzielklasse der übertragenen schützenswerten Daten geschützt sein.
  • Ein interner Speicher ist per Definition ein Speicher, der ausschließlich von der CPU verwendet werden kann, der er zugeordnet ist, und auf den anderweitig kein Zugriff (lesend sowie schreibend) möglich ist, ohne die CPU zu zerstören. Ein Auslesen der dort gespeicherten Daten oder eine gezielte Modifizierung ist von außen auch durch eine direkte Kontaktierung der CPU nicht möglich.
  • In diese Kategorie fallen für gewöhnlich Flash-Speicher und RAM, falls diese sich direkt auf der CPU befinden und von außerhalb der CPU auch durch direkte Kontaktierung kein Zugriff auf diese möglich ist. Der Speicher eines HSM, welches sich direkt auf der CPU befindet, fällt ebenfalls in diese Kategorie.
  • Nicht als interner Speicher zählen z.B. externe RAM außerhalb der CPU, externe EEPROM, Flash oder sonstige persistente Speicher oder Speicher auf anderen CPUs.
  • Teilweise wird für Komponenten ein authentisiertes Booten gefordert. Für eine Komponente, die mehrere CPUs enthält, wird festgelegt, welche von ihnen sicheres Booten umsetzen müssen.
  • Eine CPU, welche schützenswerte Daten verarbeitet, muss sicheres Booten auf Basis der freigegebenen Verfahren unterstützen, um die Integrität von schutzrelevanter Software sicherzustellen.
  • Es muss ein geschützter Boot-Prozess verwendet werden. Dieser muss mindestens die Software kryptografisch verifizieren, deren Integrität zur sicheren Ausführung von kryptografischen Operationen notwendig ist. Das Schutzkonzept muss das Verhalten der Komponente bei einem fehlgeschlagenen Boot-Prozess festlegen. Im Fehlerfall kann z.B. die Komponente in einen Modus versetzt werden, der nur das Flashen der Komponente zur Wiederherstellung erlaubt (Secure Boot), oder der Zugriff auf Schlüsselmaterial gesperrt werden.
  • Der geschützte Boot-Prozess muss den gesamten Boot-Pfad vom Power-up der Komponente bis inklusive der ausführenden Software und statischer Konfigurationsdaten umfassen. Der geschützte Boot-Prozess muss daher unter anderem Folgendes umfassen:
    • - sämtliche Bootloader, z.B. Startup-Loader, Bootloader, Tier-1-Bootloader, Customer-Bootloader, OEM-Bootloader;
    • - Betriebssystem;
    • - Applikationssoftware;
    • - jegliche Daten, die für die Ausführung der oben genannten Software relevant sind (Konfigurationsdateien usw.).
  • Eine effiziente Umsetzung kann z.B. durch einen Boot-Prozess in mehreren Stufen erfolgen, bei dem die jeweils vorherige Stufe die Authentizität der nächsten Stufe prüft, bevor diese gestartet wird. Die genaue Umsetzung hängt von den Fähigkeiten der CPU ab.
  • Software und Daten, die in nur einmal beschreibbarem Speicher (OTP-Speicher; OTP: one time programmable) direkt auf der CPU gespeichert sind, müssen nicht verifiziert werden.
  • Teilweise besitzen Komponenten eine hardwarebeschleunigte kryptografische Funktionalität oder ein embedded HSM.
  • Embedded HSM decken ein weites Spektrum ab, vom einfachem Schlüsselspeicher mit zugehöriger Statemachine für kryptografische Operationen, wie z.B. die Secure Hardware Extension, bis hin zu integrierten dedizierten Laufzeitumgebungen mit eigener CPU speziell für kryptografische Operationen.
  • Es ist zu beachten, dass ein externes HSM, das nicht Teil der CPU ist, wie eine externe CPU betrachtet und behandelt wird. Somit müssen Aufrufe solcher HSM durch die CPU wie oben beschrieben authentifiziert und gegebenenfalls verschlüsselt erfolgen.
  • Falls das HSM Teil der CPU ist, muss entweder die CPU authentisiertes Booten wie oben beschrieben umsetzen oder das HSM den Zustand der umliegenden CPUs verifizieren, wobei für die Maßnahmen im Fehlerfall ebenfalls die oben genannten Anforderungen gelten.
  • Schutzzielklassen für schützenswerte Daten
  • Die schützenswerten Daten werden mit verschiedenen Schutzzielklassen klassifiziert.
  • Ein Datum wird einer von zumindest zwei Schutzzielklassen zugeordnet, der Schutzzielklasse „Vertraulich“ oder der Schutzzielklasse „Authentisch“. Zusätzlich kann das Datum auch einer konkreten Schutzmaßnahme zugeordnet sein. Ist dies nicht der Fall, kann zum Schutz des Datums zwischen den zur Schutzzielklasse zugehörigen Schutzmaßnahmen frei gewählt werden.
  • Ist ein Datum auch einer Schutzmaßnahme zugeordnet, muss das Datum entsprechend genau dieser geschützt werden. Die allgemeingültigen Anforderungen der übergeordneten Schutzzielklasse bleiben dabei bestehen. Der Entwickler einer Komponente muss sicherstellen, dass die Architektur der Komponente die Umsetzung der geforderten Schutzzielklassen und Schutzmaßnahmen ermöglicht. Dabei muss zudem sichergestellt werden, dass die schützenswerten Daten auch während der Verwendung innerhalb der Komponente entsprechend ihrer Schutzzielklasse geschützt sind.
  • Schutzzielklasse „Vertraulich“
  • Schützenswerten Daten der Schutzzielklasse „Vertraulich“ sind Daten, die vor unbefugtem Auslesen geschützt werden müssen. Hierzu zählen z.B. alle geheimen symmetrischen Schlüssel und private Schlüssel eines asymmetrischen Schlüsselpaares.
  • Für die Schutzzielklasse „Vertraulich“ sind drei Schutzmaßnahmen V.1 bis V.3 definiert.
  • Schutzmaßnahme „V.1“ (HSM)
  • Die schützenswerten Daten werden ausschließlich in einem internen HSM der CPU persistiert und nur von diesem verwendet. Ein Zugriff auf die schützenswerten Daten ist nur durch das HSM möglich. Sonstige Programme, die auf der CPU laufen, haben keinen lesenden oder schreibenden Zugriff darauf.
  • Schutzmaßnahme „V.2“ (interner Speicher)
  • Die schützenswerten Daten werden ausschließlich in internem Speicher persistiert, zwischengespeichert und verwendet.
  • Schutzmaßnahme „V.3“ (verschlüsselter und authentifizierter Speicher)
  • Die schützenswerten Daten werden mit einem freigegebenen Verfahren verschlüsselt und signiert persistiert.
  • Dabei trifft mindestens eine der folgenden Aussagen zu:
    • - Die schützenswerten Daten und ihre Signatur ändern sich über die Lebenszeit der Komponente nicht.
    • - Die Signatur oder ein Hash über die schützenswerten Daten sind Daten der Schutzzielklasse „Authentisch“ und mit Schutzmaßnahme „A.1“ oder „A.2“ wie weiter unten beschrieben geschützt.
  • Bei jedem Ladevorgang der schützenswerten Daten müssen die zugehörige Signatur bzw. der Hash überprüft werden. Ist der Wert inkorrekt, dann ist das Datum verfälscht und darf nicht verwendet werden. Dieser Fall muss bei der Entwicklung berücksichtigt werden und ist Teil des Schutzkonzepts.
  • Die verschlüsselten, schützenswerten Daten exklusive der zugehörigen Signatur bzw. des Hashes können in jeder Art von Speicher persistiert werden.
  • Die entschlüsselten, schützenswerten Daten werden ausschließlich in internem Speicher zwischengespeichert und verwendet.
  • Die Schlüssel, die zur Verschlüsselung und (falls verwendet) Signierung der schützenswerten Daten in der Komponente verwendet werden, sind Daten der Schutzzielklasse „Vertraulich“ und mit Schutzmaßnahme „V.1“ oder „V.2“ geschützt.
  • Die Schlüssel, die zur Verschlüsselung und (falls verwendet) Signierung der schützenswerten Daten in der Komponente verwendet werden, sind zufällig und individuell für jede Komponente.
  • Schutzzielklasse „Authentisch“
  • Schützenswerte Daten der Schutzzielklasse „Authentisch“ sind Daten, die vor unbefugter Manipulation geschützt werden müssen. Hierzu zählen in der Regel z.B. Root-Zertifikate, globale öffentliche Schlüssel oder ein Identitätsanker der Komponente, beispielsweise deren Seriennummer.
  • Für die Schutzzielklasse „Authentisch“ sind drei Schutzmaßnahmen A.1 bis A.3 definiert.
  • Schutzmaßnahme „A.1“ (HSM)
  • Die schützenswerten Daten werden ausschließlich in einem internen HSM der CPU persistiert. Sonstige Programme, die auf der CPU laufen, haben keinen schreibenden Zugriff darauf.
  • Schutzmaßnahme „A.2“ (interner Speicher)
  • Die schützenswerten Daten werden ausschließlich in internem Speicher persistiert.
  • Schutzmaßnahme „A.3“ (authentifizierter Speicher)
  • Die schützenswerten Daten werden mit einem freigegebenen Verfahren signiert persistiert. Dabei trifft mindestens eine der folgenden Aussagen zu:
    • - Die schützenswerten Daten und ihre Signatur ändern sich über die Lebenszeit der Komponente nicht.
    • - Die Signatur oder ein Hash über die schützenswerten Daten sind Daten der Schutzzielklasse „Authentisch“ und mit Schutzmaßnahme „A.1“ oder „A.2“ geschützt.
  • Bei jedem Ladevorgang der schützenswerten Daten müssen die zugehörige Signatur bzw. der Hash überprüft werden. Ist der Wert inkorrekt, dann ist das Datum verfälscht und darf nicht verwendet werden. Dieser Fall muss bei der Entwicklung berücksichtigt werden und ist Teil des Schutzkonzepts.
  • Die schützenswerten Daten exklusive der zugehörigen Signatur bzw. des Hashes können in jeder Art von Speicher persistiert werden.
  • Falls eine Signatur verwendet wird, muss der Signierschlüssel in der Komponente nach Schutzzielklasse „Vertraulich“ mit Schutzmaßnahme „V1“ oder „V2“ geschützt werden.
  • Falls eine Signatur verwendet wird, muss der Schlüssel in der Komponente, der zur Signierung der schützenswerten Daten verwendet wird, zufällig und individuell für jede Komponente sein.
  • Nachfolgend wird anhand von 4 ein Umsetzungsbeispiel für die Erzeugung eines geschützten Bereiches in einem ungeschütztem Speicher erläutert. Dieser Ansatz ist hilfreich, falls der bereits vorhandene geschützte Speicher 41 nicht ausreicht, jedoch weiterer ungeschützter Speicher 42 vorhanden ist.
  • AES-GCM wird verwendet, um die zu schützenden Daten zu verschlüsseln und zu signieren. Der kryptografische Schlüssel hierfür hat die Schutzzielklassen „Vertraulich“ und „Authentisch“, liegt im internen Speicher 41 der CPU und ist somit entsprechend Schutzmaßnahme „V.1“ hinreichend geschützt. Die verschlüsselten Daten können im ungeschützten externen Speicher 42 abgelegt werden. Die zugehörige Signatur hat Schutzzielklasse „Authentisch“ und wird im geschützten Speicher 41 abgelegt. Dies entspricht der Schutzmaßnahme „A.1“. Es ist somit nicht möglich, die im ungeschützten externen Speicher 42 abgelegten Daten unbemerkt zu manipulieren.
  • Beim erneuten Laden der verschlüsselten Daten muss deren gespeicherte Signatur überprüft werden. Alle kryptografischen Operationen und Daten, die bei diesem Verfahren anfallen, dürfen den geschützten Speicher 41 nicht verlassen.
  • Anstelle von AES-GCM können andere Verschlüsselungs- und Signierungsverfahren verwendet werden, falls sie den zuvor definierten Anforderungen entsprechen.
  • Ein Beispiel für die Herstellung geschützter Sicherheitskopien durch Secret-Sharing ist in 5 dargestellt. Bei diesem Verfahren wird Shamir's-Secret-Sharing Methode verwendet, um einen geheimen Schlüssel in mehrere Teile zu teilen. Im Beispiel in 5 wird ein Masterschlüssel MS zur Komponentenschlüsselableitung in vier Teile geteilt, von denen mindestens zwei notwendig sind, um den Masterschlüssel wiederherzustellen. Diese Zahlen sind nur beispielhaft. Ein Geheimnis kann in beliebig viele Teile geteilt werden, von denen wiederum eine beliebige, festgelegte Anzahl benötigt wird, um das Geheimnis zu rekonstruieren.
  • Sowohl der Masterschlüssel als auch die entstehenden Teile sind Daten der Schutzzielklasse „Vertraulich“, die mit entsprechenden Verfahren geschützt werden müssen. Konkret können die Teile in verschiedenen HSMs gespeichert werden und auf einzelne Mitarbeiter personalisiert sein. Ein Vorhalten in einer geschützten Umgebung (z.B. Sicherheitsschrank) ist ebenfalls notwendig.
  • Privilegierter Zugriff und Debug-Schnittstellen
  • Der Zugriff auf alle Schnittstellen, die lesenden oder schreibenden Zugriff auf schützenswerte oder kryptografische Daten gewähren, insbesondere also auf den internen Speicher der CPU, oder die Manipulation der CPU erlauben, muss in Serienkomponenten deaktiviert und abgesichert sein.
  • Zu diesen Schnittstellen zählen: JTAG, UART, proprietäre Diagnose des Entwicklers der Komponente, Konsolen, Tier-1 Bootloader, XCP/CCP usw.
  • Das Freischalten einer solchen Schnittstelle muss eine komponentenindividuelle, dynamische Authentifizierung erfordern und auf freigegebenen Verfahren basieren.
  • Falls eine derartige Freischaltung eines Entwicklerzugangs oder ähnlicher Zugänge implementiert wird und hierfür Schlüssel durch den Auftragnehmer eingebracht werden, sind alle weiter unten im Abschnitt „Datenhandhabung außerhalb der Komponente“ beschriebenen Maßnahmen umzusetzen.
  • Ein Konzept zu einer derartigen Freischaltung muss die Kriterien für den Verfall einer solchen Freischaltung enthalten. Die Freischaltung kann z.B. zeitlich begrenzt sein, bis zu einem Neustart der Komponente erhalten bleiben, oder muss explizit wieder deaktiviert werden.
  • Ein Beispiel für ein Freischaltungskonzept über eine PKI soll nachfolgend anhand von 6 und 7 beschrieben werden. Die Figuren zeigen eine einfache PKI mit beidseitiger Authentifizierung zur Nutzung einer Entwicklerschnittstelle zur Umsetzung einer proprietären Diagnose des Entwicklers der Komponente im Rahmen einer Produktion der Komponente (6) sowie der Produktion eines Diagnosetesters (7).
  • Während der Produktion generiert (oder erhält) die Komponente ein Zertifikat, welches einen öffentlichen Schlüssel enthält und von einer Diagnose-CA signiert wird, sowie den zugehörigen privaten Schlüssel. Weiterhin wird in diese Software das CA-Zertifikat der Diagnose-CA eingebracht. Das CA-Zertifikat sowie das Zertifikat der Komponente sind Daten der Schutzzielklasse „Authentisch“. Ihre zugehörigen privaten Schlüssel sind Daten der Schutzzielklassen „Vertraulich“ und „Authentisch“.
  • Dementsprechend müssen sowohl in der Komponente als auch in der Diagnose-CA entsprechende Schutzmaßnahmen umgesetzt werden.
  • Gleichermaßen erhält ein Diagnosetester des Entwicklers ein signiertes Diagnosetesterzertifikat, welches einen öffentlichen Schlüssel enthält, den zugehörigen privaten Schlüssel sowie das Diagnose-CA-Zertifikat. Auch hier sind die öffentlichen Zertifikate Daten der Schutzzielklasse „Authentisch“ und die zugehörigen privaten Schlüssel Daten der Schutzzielklassen „Vertraulich“ und „Authentisch“.
  • Die signierten Zertifikate können dann für authentifizierte Diagnose verwendet werden. Sobald sich ein Diagnosetester des Entwicklers mit einer Komponente verbindet, können beide Seiten gegenseitig mit Hilfe ihrer Zertifikate ihre Identität und Funktion (Komponente, Tester etc.) beweisen. Die Gültigkeit der Zertifikate kann mit dem gespeicherten Diagnose CA-Zertifikat überprüft werden. Weiterhin kann mit den in den Zertifikaten enthaltenen signierten öffentlichen Schlüsseln ein authentifizierter Schlüsselaustausch durchgeführt werden. Der resultierende gemeinsame Schlüssel kann dann zur verschlüsselten und signierten Kommunikation verwendet werden.
  • Datenhandhabung in der Komponente
  • Die Software der Komponente ist Datum der Schutzzielklasse „Authentisch“.
  • Symmetrische Schlüssel und private Schlüssel eines asymmetrischen Schlüsselpaars, die in Komponenten eingebracht werden, müssen individuell und zufällig sein. Die Granularität der Schlüssel wird nach Bedarf festgelegt.
  • Kryptografische oder schützenswerte Daten oder deren flüchtige Kopien müssen, nachdem sie nicht mehr zwingend benötigt werden, mit Nullwerten überschrieben werden.
  • Symmetrische Schlüssel sind Daten der Schutzzielklassen „Vertraulich“ und „Authentisch“. Private Schlüssel asymmetrischer Schlüsselpaare sind Daten der Schutzzielklasse „Vertraulich“ und „Authentisch“. Öffentliche Schlüssel einer Komponente sind Daten der Schutzzielklasse „Authentisch“. Globale öffentliche Schlüssel (z.B. des Entwicklers) sind Daten der Schutzzielklasse „Authentisch“. Sonstige kryptografische Daten wie Zwischenwerte kryptografischer Funktionen, interne Zustände von Zufallsgeneratoren, usw. sind Daten der Schutzzielklasse ihres verwendeten Schlüssels.
  • Es darf einem Unbefugten nicht möglich sein, geschützte oder kryptografische Daten der Schutzzielklasse „Vertraulich“ durch Abhören von Leitungen auf der Platine der Komponente im Klartext abzufangen.
  • Datenhandhabung außerhalb der Komponente
  • Falls durch den Entwickler geheimes Schlüsselmaterial (z.B. private Schlüssel zur Signierung, komponentenindividuelle Schlüssel, etc.) oder schützenswerte Daten außerhalb der Komponente erzeugt, verwendet oder verwaltet wird, müssen je nach Funktion eines kryptografischen Schlüssels Einschränkungen an seine Nutzung umgesetzt werden, beispielsweise:
    • - beschränkte Nutzungsanzahl;
    • - zeitliche Beschränkung der Nutzung;
    • - Nutzung nur mit mindestens „4-Augen-Prinzip“;
    • - Personalisierung auf einzelne Mitarbeiter; verschiedene Befugnisse pro Nutzer;
    • - eingeschränkte Anzahl von Benutzern;
    • - Nutzung von IT-gebräuchlichen HSM zum Schutz der Schlüssel;
    • - manipulationssichere Protokollierung der Nutzung.
  • Kryptografische Schlüssel dürfen außerhalb eines HSM niemals im Klartext gespeichert oder übertragen werden, sondern müssen mit einem der freigegebenen Verfahren geschützt werden. Diese Anforderung gilt nicht zwingend für Entwicklungsschlüssel (siehe unten), die nicht in Produktivumgebungen verwendet werden und nicht in Produktivkomponenten eingebracht werden. Sie gilt wie folgt weiterhin nicht für die Dauer der Erstprovisionierung von Komponenten mit geheimen Schlüsseln durch den Entwickler. Falls kryptografische, geheime Schlüssel für eine Komponente während der Produktion der Komponente außerhalb der Komponente generiert werden und dort auch in die Komponente eingebracht werden, muss der Zugriff zum Schlüsselgenerator und zum Übertragungsweg auf einen möglichst kleinen Personenkreis beschränkt werden. In nur genau diesem Fall ist die Übertragung der Schlüssel in die Komponente zur Erstprovisionierung mit Schlüsselmaterial auch im Klartext gestattet.
  • Das genaue Verfahren der Schlüsselerzeugung und Übertragung, sowie die Anzahl der Personen mit Zugang zum Schlüsselgenerator und Übertragungsweg werden nach Bedarf festgelegt.
  • Falls einem Entwickler oder Dritten Zugriff auf den privaten Schlüssel eines asymmetrischen Schlüsselpaars gewährt werden soll, z.B. zu Testzwecken, müssen von jedem globalen kryptografischen Schlüssel, z.B. für authentisiertes Booten, zwei Versionen existieren:
    • - ein Entwicklungsschlüssel, der nur auf Entwicklungskomponenten während der Entwicklung verwendet wird, und der in Produktivumgebungen nicht gültig ist; dieser Schlüssel kann vom Auftraggeber herausgegeben werden;
    • - ein Serienschlüssel, der nur auf Produktionskomponenten verwendet wird; dieser Schlüssel darf vom Auftraggeber nicht herausgegeben werden.
  • Das Einbringen von Entwicklungsschlüsseln in Produktionskomponenten wird als Entwicklerschnittstelle entsprechend dem Abschnitt „Privilegierter Zugriff und Debug-Schnittstellen“ betrachtet und ist entsprechend zu schützen.
  • Softwareentwicklung
  • Software, die Daten verarbeitet, deren Ursprung außerhalb der Komponente liegt, muss durch sicherheitsorientierte Programmierstandards gehärtet werden. Mindestens sind die Standards MISRA C und MISRA C++ einzuhalten.
  • Es müssen Static-Code-Analysis-Hilfsmittel verwendet werden, um Programmierfehler zu finden, die zu Sicherheitsproblemen führen können.
  • Es muss eine Bibliothek verwendet werden, welche die nötige kryptografische Funktionalität bereitstellt. Hierzu zählt insbesondere eine dem Entwickler gegebenenfalls zur Verfügung gestellte Standardsoftware, die als erste Wahl zu verwenden ist.
  • Zur Verwendung von kryptografischen Verfahren muss immer die abstrakteste Funktion der Bibliothek verwendet werden. Falls die Bibliothek z.B. eine Funktion zur Verifikation einer Signatur anbietet, muss diese verwendet werden, anstatt dass die Schritte zur Verifikation mit Hilfe von low-level Funktionen selbst durchgeführt werden. Im Fall von RSA wäre es zum Beispiel nicht erlaubt, die notwendigen Schritte wie Exponentiation, Padding-Prüfung, usw. durchzuführen, anstatt die RSA-Verifikationsfunktion direkt aufzurufen.
  • Falls das auf der Komponente verwendete Betriebssystem ein Benutzermanagementsystem bereitstellt, muss dieses verwendet werden, so dass sichergestellt wird, dass nur privilegierte Prozesse Zugriff auf schützenswerte und kryptografische Daten erhalten können. Zudem muss der Zugriff auf schutzrelevante Hardware wie HSM, CAN-Bus I/O, usw. eingeschränkt werden.
  • Weiterhin müssen Maßnahmen umgesetzt werden, die sicherstellen, dass auf die Speicherbereiche solcher privilegierter Prozesse nicht durch andere Prozesse zugegriffen werden kann.
  • Alle Prozesse müssen auf die minimalen Rechte beschränkt werden, die sie zur Ausübung ihrer Funktionalität benötigen.

Claims (7)

  1. Komponente (10, 20) zur Verarbeitung eines schützenswerten Datums, wobei die Komponente (10, 20) eingerichtet ist, durch Ausführen der folgenden Schritte zumindest eine Sicherheitsfunktion zum Schutz des schützenswerten Datums umzusetzen, wobei die Sicherheitsfunktion zumindest eine Schutzmaßnahme aus einer Auswahl von zu einer Schutzzielklasse zugehörigen Schutzmaßnahmen umfasst: Bestimmen (30) einer zum schützenswerten Datum zugeordneten Schutzzielklasse; und Auswählen (31) zumindest einer Schutzmaßnahme aus der Auswahl von zur Schutzzielklasse zugehörigen Schutzmaßnahmen; wobei das schützenswerte Datum einer Schutzmaßnahme zugeordnet ist und die Sicherheitsfunktion zumindest die zugeordnete Schutzmaßnahme umfasst; wobei ein Datum einer ersten Schutzzielklasse vor unbefugtem Auslesen geschützt werden muss und ein Datum einer zweiten Schutzzielklasse vor unbefugter Manipulation geschützt werden muss; und wobei gemäß einer ersten Schutzmaßnahme das Datum ausschließlich in einem Hardware-Sicherheitsmodul der Komponente (10, 20) persistiert und nur von diesem verwendet wird, gemäß einer zweiten Schutzmaßnahme das Datum ausschließlich in einem internen Speicher der Komponente (10, 20) persistiert, zwischengespeichert und verwendet wird und gemäß einer dritten Schutzmaßnahme das Datum verschlüsselt und/oder signiert persistiert wird.
  2. Komponente (10, 20) gemäß Anspruch 1, wobei für den Fall, dass die Komponente (10, 20) eine Schnittstelle aufweist, die einen lesenden oder schreibenden Zugriff auf ein schützenswertes Datum gewährt oder eine Manipulation einer Recheneinheit der Komponente (10, 20) erlaubt, diese Schnittstelle deaktiviert und abgesichert ist.
  3. Komponente (10, 20) gemäß Anspruch 2, wobei das Freischalten einer solchen Schnittstelle eine komponentenindividuelle, dynamische Authentifizierung erfordert.
  4. Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer Komponente (10, 20) zur Verarbeitung des schützenswerten Datums, wobei das Verfahren umfasst: Bestimmen (30) einer zum schützenswerten Datum zugeordneten Schutzzielklasse; Auswählen (31) zumindest einer Schutzmaßnahme aus einer Auswahl von zur Schutzzielklasse zugehörigen Schutzmaßnahmen; und Umsetzen (32) der gewählten Schutzmaßnahme in der Komponente (10, 20); wobei das schützenswerte Datum einer Schutzmaßnahme zugeordnet ist und die Sicherheitsfunktion zumindest die zugeordnete Schutzmaßnahme umfasst; wobei ein Datum einer ersten Schutzzielklasse vor unbefugtem Auslesen geschützt werden muss und ein Datum einer zweiten Schutzzielklasse vor unbefugter Manipulation geschützt werden muss; und wobei gemäß einer ersten Schutzmaßnahme das Datum ausschließlich in einem Hardware-Sicherheitsmodul der Komponente (10, 20) persistiert und nur von diesem verwendet wird, gemäß einer zweiten Schutzmaßnahme das Datum ausschließlich in einem internen Speicher der Komponente (10, 20) persistiert, zwischengespeichert und verwendet wird und gemäß einer dritten Schutzmaßnahme das Datum verschlüsselt und/oder signiert persistiert wird.
  5. Verfahren gemäß Anspruch 4, wobei eine Schnittstelle der Komponente (10, 20), die einen lesenden oder schreibenden Zugriff auf ein schützenswertes Datum gewährt oder eine Manipulation einer Recheneinheit der Komponente (10, 20) erlaubt, deaktiviert und abgesichert wird.
  6. Verfahren gemäß Anspruch 5, wobei das Freischalten einer solchen Schnittstelle eine komponentenindividuelle, dynamische Authentifizierung erfordert.
  7. Fahrzeug, insbesondere Kraftfahrzeug, dadurch gekennzeichnet, dass das Fahrzeug zumindest eine Komponente gemäß einem der Ansprüche 1 bis 3 aufweist.
DE102016210788.7A 2016-02-18 2016-06-16 Komponente zur Verarbeitung eines schützenswerten Datums und Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer solchen Komponente Active DE102016210788B4 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US15/434,304 US10303886B2 (en) 2016-02-18 2017-02-16 Component for processing a protectable datum and method for implementing a security function for protecting a protective datum in such a component
CN201710086126.9A CN107092833B (zh) 2016-02-18 2017-02-17 用于处理数据的组件和用于实施安全功能的方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102016001849 2016-02-18
DE102016001849.6 2016-02-18

Publications (2)

Publication Number Publication Date
DE102016210788A1 DE102016210788A1 (de) 2017-08-24
DE102016210788B4 true DE102016210788B4 (de) 2023-06-07

Family

ID=59522338

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102016210788.7A Active DE102016210788B4 (de) 2016-02-18 2016-06-16 Komponente zur Verarbeitung eines schützenswerten Datums und Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer solchen Komponente

Country Status (3)

Country Link
US (1) US10303886B2 (de)
CN (1) CN107092833B (de)
DE (1) DE102016210788B4 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11057240B2 (en) 2018-12-20 2021-07-06 Rolls-Royce North American Technologies Inc. Method and process for securing an executable image
DE102020003072B3 (de) 2020-05-22 2021-07-15 Daimler Ag Verfahren zur sicheren Nutzung von kryptografischem Material
DE102021211591A1 (de) 2021-10-14 2023-04-20 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Verarbeiten von Daten
DE102021130402A1 (de) 2021-11-22 2023-05-25 Audi Ag Steuergerät und Steuergerätsystem für ein Kraftfahrzeug sowie Verfahren zum Betreiben eines Steuergeräts für ein Kraftfahrzeug

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007058975A1 (de) 2007-12-07 2009-06-10 Bayerische Motoren Werke Aktiengesellschaft Bordnetz eines Kraftfahrzeugs mit einem Master Security Modul
DE102011076350A1 (de) 2011-05-24 2012-11-29 Siemens Aktiengesellschaft Verfahren und Steuereinheit zur Erkennung von Manipulationen an einem Fahrzeugnetzwerk
US20130042295A1 (en) 2011-08-10 2013-02-14 Charles C. Kelly Method and apparatus for providing a secure virtual environment on a mobile device
US20140115656A1 (en) 2012-10-19 2014-04-24 Kwan Ho KIM Security management unit, host controller interface including same, method operating host controller interface, and devices including host controller interface
DE102013006470A1 (de) 2013-04-15 2014-10-16 Giesecke & Devrient Gmbh Mobilstation umfassend Sicherheitsressourcen
WO2015007673A1 (de) 2013-07-17 2015-01-22 Bayerische Motoren Werke Aktiengesellschaft Fahrzeugsystem und verfahren zur automatisierten steuerung mindestens einer safety-relevanten funktion eines fahrzeuges

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE523140C2 (sv) * 2002-07-02 2004-03-30 Telia Ab Skyddsanordning i datorsystem avsedd att skydda en fil med en säkerhetspolicy i ett system för tillämpning av säkerhetspolicy
US7681035B1 (en) * 2003-09-10 2010-03-16 Realnetworks, Inc. Digital rights management handler and related methods
ES2391786T3 (es) 2007-02-13 2012-11-29 Secunet Security Networks Aktiengesellschaft Unidad de seguridad
JP5196883B2 (ja) * 2007-06-25 2013-05-15 パナソニック株式会社 情報セキュリティ装置および情報セキュリティシステム
US8761390B2 (en) 2008-06-30 2014-06-24 Gm Global Technology Operations Production of cryptographic keys for an embedded processing device
DE102008048162A1 (de) 2008-09-19 2010-03-25 Continental Automotive Gmbh System und On-Board-Unit
DE102008042259A1 (de) 2008-09-22 2010-04-08 Bundesdruckerei Gmbh Kraftfahrzeug-Elektronikgerät, Kraftfahrzeug, Verfahren zur Anzeige von Daten auf einer Kraftfahrzeug-Anzeigevorrichtung und Computerprogrammprodukt
US10002466B2 (en) * 2010-07-21 2018-06-19 Verizon Patent And Licensing Inc. Method and system for providing autonomous car errands
DE102010042539B4 (de) 2010-10-15 2013-03-14 Infineon Technologies Ag Datensender mit einer sicheren, aber effizienten Signatur
EP2737597B1 (de) * 2011-07-26 2019-10-16 Gogoro Inc. Vorrichtung, verfahren und artikel zur physischen sicherheit von energiespeichereinrichtungen bei fahrzeugen
DE102012015940A1 (de) 2012-08-10 2014-02-13 Audi Ag Verfahren zum Betreiben eines Kraftwagens
CN105095783A (zh) * 2014-05-20 2015-11-25 中兴通讯股份有限公司 文件加密方法、装置、加密文件的读取方法、装置及终端

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007058975A1 (de) 2007-12-07 2009-06-10 Bayerische Motoren Werke Aktiengesellschaft Bordnetz eines Kraftfahrzeugs mit einem Master Security Modul
DE102011076350A1 (de) 2011-05-24 2012-11-29 Siemens Aktiengesellschaft Verfahren und Steuereinheit zur Erkennung von Manipulationen an einem Fahrzeugnetzwerk
US20130042295A1 (en) 2011-08-10 2013-02-14 Charles C. Kelly Method and apparatus for providing a secure virtual environment on a mobile device
US20140115656A1 (en) 2012-10-19 2014-04-24 Kwan Ho KIM Security management unit, host controller interface including same, method operating host controller interface, and devices including host controller interface
DE102013006470A1 (de) 2013-04-15 2014-10-16 Giesecke & Devrient Gmbh Mobilstation umfassend Sicherheitsressourcen
WO2015007673A1 (de) 2013-07-17 2015-01-22 Bayerische Motoren Werke Aktiengesellschaft Fahrzeugsystem und verfahren zur automatisierten steuerung mindestens einer safety-relevanten funktion eines fahrzeuges

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HELING, Ing Günther; REIN, Dipl-Ing FH Jochen; MARKL, Dipl-Ing FH Patrick. Koexistenz von sicherer und nicht-sicherer Software auf einem Steuergerät. ATZelektronik, 2012, 7. Jg., Nr. 7, S. 62-65.

Also Published As

Publication number Publication date
CN107092833B (zh) 2021-02-02
DE102016210788A1 (de) 2017-08-24
US20170243011A1 (en) 2017-08-24
US10303886B2 (en) 2019-05-28
CN107092833A (zh) 2017-08-25

Similar Documents

Publication Publication Date Title
DE102008006759B4 (de) Prozessor-Anordnung und Verfahren zum Betreiben der Prozessor-Anordnung ohne Verringerung der Gesamtsicherheit
DE102009013384B4 (de) System und Verfahren zur Bereitstellung einer sicheren Anwendungsfragmentierungsumgebung
EP3136285B1 (de) Verfahren und speichermodul für sicherheitsgeschützte schreibvorgänge und/oder lesevorgänge auf dem speichermodul
DE102016210788B4 (de) Komponente zur Verarbeitung eines schützenswerten Datums und Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer solchen Komponente
DE102013227087A1 (de) Gesichertes Bereitstellen eines Schlüssels
DE102015209108A1 (de) Verfahren und Entscheidungsgateway zum Autorisieren einer Funktion eines eingebetteten Steuergerätes
DE102014208838A1 (de) Verfahren zum Betreiben eines Steuergeräts
DE102014208855A1 (de) Verfahren zum Durchführen einer Kommunikation zwischen Steuergeräten
WO2019242972A1 (de) Kryptografiemodul und betriebsverfahren hierfür
DE102020117552A1 (de) Sichere hybrid-boot-systeme und sichere boot-verfahren für hybridsysteme
EP3819804A1 (de) Integritätsüberprüfung eines registerinhalts
EP3286872B1 (de) Bereitstellen eines gerätespezifischen kryptographischen schlüssels aus einem systemübergreifenden schlüssel für ein gerät
DE102020216030A1 (de) Verfahren zum abgesicherten Start einer Recheneinheit
DE102021110768B3 (de) Forensik-Modul und eingebettetes System
DE102014208840A1 (de) Verfahren zum Behandeln von Software-Funktionen in einem Steuergerät
DE102021110766B3 (de) Forensik-Modul und eingebettetes System
DE102014208853A1 (de) Verfahren zum Betreiben eines Steuergeräts
DE102021110769A1 (de) Emulationssystem und Verfahren
WO2024056443A1 (de) Verfahren zum überprüfen von daten in einer recheneinheit
EP4250634A1 (de) Rechnergestütztes industriegerät und verfahren zum betreiben eines rechnergestützten industriegeräts
EP4297334A2 (de) Verfahren zur implementierung und nutzung von kryptografischem material in wenigstens einer systemkomponente eines informationstechnischen systems
EP4307148A1 (de) Attestierung einer cloud-basierten ausführungsumgebung für eine projektierung
EP3812947A1 (de) Authentifizierung einer teilkonfiguration einer feldprogrammierbaren logikgatter-anordnung
DE102014208844A1 (de) Verfahren zum Durchführen von sicherheitskritischen Vorgängen in einem Steuergerät
WO2021229084A1 (de) Verfahren und secure-element zum nachweis einer vertrauenswürdigen elektronischen baugruppe

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final