DE102020105529A1

DE102020105529A1 - Verfahren zur selektiven Bereitstellung von Daten

Info

Publication number: DE102020105529A1
Application number: DE102020105529.3A
Authority: DE
Inventors: Markus Jostock
Original assignee: Arxum GmbH
Current assignee: Arxum GmbH
Priority date: 2020-03-02
Filing date: 2020-03-02
Publication date: 2021-09-02
Also published as: WO2021175805A1

Abstract

Verfahren zur selektiven Bereitstellung von Daten (4) aus einem vertraulichen Datenspeicher (2) eines Datenbereitstellers (1) mit einem Datenbereitstellungsmodul (3) aufweisend die folgenden Schritte:
a) Empfangen einer Anfrage (8) von einem Datenanfrager (7) bezüglich der Bereitstellung von Teildaten (9) aus dem vertraulichen Datenspeicher (2), wobei die Anfrage mindestens einen Datenidentifzierparameter (12) zur Identifizierung der Teildaten (9) beinhaltet;
b) Prüfen anhand einer Blockchain (5), ob die Anfrage (8) mit einem von dem Datenbereitsteller (1) in der Blockchain (5) hinterlegten Regelwerks (13) geprüft und als berechtigt eingestuft wurde;
c) Sofern die Anfrage (8) als berechtigt eingestufte wurde, Bereitstellung der zur Bereitstellung angefragten Teildaten (9) an den Datenanfrager (7).

Description

Hier beschrieben wird ein Verfahren zur selektiven Bereitstellung von Daten. Die selektive Bereitstellung von Daten erfolgt beispielsweise sehr regelmäßig zwischen verschiedenen Unternehmen in einer Lieferkette. Ein typischer Anwendungsfall ist, dass ein Unternehmen Informationen über Einzelteile eines Zulieferers anfordern will, welche es in seinen Produkten verbaut hat. Ein solcher Fall kommt häufig vor, wenn beispielsweise Probleme mit den Einzelteilen des Zulieferers auftreten oder sich zumindest andeuten und dass die Einzelteile verarbeitende Unternehmen die beim Hersteller verfügbaren Informationen über die Einzelteile erhalten möchte. In diesem Fall ist das Unternehmen, welches die Einzelteile hergestellt hat, das Daten bereitstellende Unternehmen bzw. der Datenbereitsteller und das Unternehmen, welches die Zulieferteile verarbeitet hat, das Daten anfragende Unternehmen bzw. der Datenanfrager.
In dieser Beziehung hat der Datenanfrager ein Interesse daran, die von ihm benötigen Daten schnell und zuverlässig (am besten automatisiert) und ohne lästige Wartezeiten erhalten zu können. Der Datenbereitsteller hat ein Interesse daran, nur die Daten bereitzustellen, die der Datenanfrager tatsächlich berechtigt ist zu erhalten. Der Datenbereitsteller hat ebenfalls ein Interesse daran, die Detailtiefe der angefragten Daten genau zu kennen und gegebenenfalls auch nur Daten in der Detailtiefe herauszugeben, die der Datenanfrager tatsächlich berechtigt ist zu erhalten.
Es sind sehr viele unterschiedliche Situationen denkbar, in denen vergleichbare Interessen des Datenbereitstellers und des Datenanfragers einander gegenüber stehen und in welchen ein Verfahren zur selektiven Bereitstellung von Daten hilfreich ist, mit welchem diese Interessen berücksichtigt werden können.
Hiervon ausgehend ist es Aufgabe der vorliegenden Erfindung ein Verfahren zur selektiven Bereitstellung von Daten zu beschaffen, welches die sich aus der Beziehung von Datenbereitsteller und Datenanfrager ergebenden Herausforderungen in innovativer Weise löst.
Hier beschrieben werden soll ein Verfahren zur selektiven Bereitstellung von Daten aus einem vertraulichen Datenspeicher eines Datenbereitstellers mit einem Datenbereitstellungsmodul aufweisend die folgenden Schritte:

a) Empfangen einer Anfrage von einem Datenanfrager bezüglich der Bereitstellung von Teildaten aus dem vertraulichen Datenspeicher, wobei die Anfrage mindestens einen Datenidentifizierparameter zur Identifizierung der Teildaten beinhaltet;
b) Prüfen anhand einer Blockchain, ob die Anfrage mit einem von dem Datenbereitsteller in der Blockchain hinterlegten Regelwerks geprüft und als berechtigt eingestuft wurde;
c) Sofern die Anfrage als berechtigt eingestufte wurde, Bereitstellung der zur Bereitstellung angefragten Teildaten an den Datenanfrager.

Das Verfahren ist beispielsweise für die weiter oben beschriebenen Beziehungen zwischen Herstellern von Einzelteilen als Datenbereitsteller und Verarbeitern dieser Einzelteile als Zuliefererteile in höheren Produktionsstufen als Datenanfrager anwendbar. Das Verfahren ist auch in vielen anderen Konstellationen anwendbar. Insbesondere ist das Verfahren in Lieferketten der Automobilindustrie oder vergleichbarer Industrien anwendbar. In solchen Lieferketten besteht häufig der Bedarf, Produktionsdaten bezüglich eingekaufter Einzelteile von einem Zulieferer anzufragen, um in Abhängigkeit derartiger Daten beispielsweise auch Verarbeitungsprozesse der Einzelteile zu steuern. In diesen Anwendungsfällen hat der Datenbereitsteller und Zulieferer allerdings kein Interesse daran, dass ein Käufer bzw.
Datenanfrager von Einzelteilen Produktionsdaten über Einzelteile erhalten kann, die an einen anderen Käufer geliefert wurden. In dieser Konstellation ist das hier beschriebene Verfahren äußerst hilfreich. Beide Parteien haben ein hohes Interesse an einem Datenaustausch, um z.B. die Lieferung zugesicherter Qualität nachzuweisen und Gewährleistungsansprüche gegeneinander abzugrenzen.
Das beschriebene Verfahren wird mit einem Datenbereitstellungsmodul ausgeführt, welches in bzw. an einer vertraulichen Sphäre des Datenbereitstellers angeordnet ist bzw. welches eine Zugangsmöglichkeit zu dem vertraulichen Datenspeicher bereitstellt. Das Datenbereitstellungsmodul hat allerdings Kommunikationsschnittstellen nach außen, über die Anfragen bezüglich bestimmter Daten empfangen werden können und über die auch die Bereitstellung von Daten erfolgen kann. Die Kommunikationsschnittstellen des Datenbereitstellungsmoduls können beispielsweise an das Internet angeschlossen sein. Das Datenbereitstellungsmodul kann besonders bevorzugt hinter einer Art Firewall oder einer vergleichbaren Hardware-Komponente des Datenbereitstellers implementiert sein oder unmittelbar an eine solche Komponente angeschlossen sein, wobei dann bevorzugt die Kommunikationsschnittstellen des Datenbereitstellungsmoduls derart eingerichtet sind, dass diese über die Firewall bzw. die vergleichbare Hardwarekomponente mit der Umgebung kommunizieren.
Der vertrauliche Datenspeicher ist in üblichen Ausführungsvarianten des beschriebenen Verfahrens ein Datenspeicher, der unter der (alleinigen) Verantwortung und (alleinigen) Kontrolle des Datenbereitstellers steht. Es kann sich beispielsweise um einen Datenspeicher in einem Server in einem Werksgelände des Datenbereitstellers handeln, der von außen nicht zugänglich ist. Ein solcher Server kann aber auch in einem Rechenzentrum angeordnet sein und über übliche Sicherheitsmaßnahmen gegen unberechtigte Zugriffe geschützt sein.
In Schritt a) wird eine Anfrage von dem Datenanfrager bezüglich der Bereitstellung von Teildaten empfangen. Die Anfrage kann direkt von dem Datenanfrager empfangen werden, beispielsweise über die beschriebenen Kommunikationsschnittstellen, wobei dann bevorzugt ist, dass der Datenbereitsteller an diesem Kommunikationsschnittstellen permanent horcht, ob Daten bereitgestellt werden. Die Anfrage kann auch indirekt von dem Datenanfrager empfangen werden. Ein indirekter Empfang kann beispielsweise dadurch erreicht werden, dass der Datenanfrager permanent an einem bestimmten Ort prüft bzw. horcht, ob Anfragen des Datenanfragers dort abgelegt werden, die an den jeweiligen Datenbereitsteller bzw. an das jeweilige Datenbereitstellungsmodul gerichtet sind.
Ein solcher Ort kann beispielsweise eine Blockchain sein, in welcher Datenanfragen des Datenanfragers eingetragen werden.
Bei dieser Blockchain handelt es sich bevorzugt aber nicht notwendigerweise um eine privat betriebene Blockchain, die in bevorzugten Ausführungsvarianten öffentlich verfügbar ist und deren Regelwerk für den Datenanfrager einsehbar und auswertbar ist. Diese Blockchain wird bevorzugt auf einer Hardware betrieben, die komplett unabhängig von dem Datenbereitstellungsmodul ist und insbesondere auch unabhängig ist von einer Hardware, auf der das Datenbereitstellungsmodul betrieben wird. Die Blockchain kann so ausgeführt sein, dass jeder Teilnehmer (Datenanfrager und/oder Datenbereitsteller) sich Kopien der Blockchain erstellen kann, um anhand dieser Kopien, Prüfungen von Anfragen und/oder sonstige Validierungen vornehmen zu können.
Die Anfrage in Schritt a) kann beispielsweise als eine Transaktion in die Blockchain geschrieben werden. Zu den sich hierdurch ergebenden Möglichkeiten folgen weiter unten noch detaillierte Erläuterungen.
In Schritt a) erfolgt die Anfrage mit mindestens einem Datenidentifizierparameter zur Identifikation der Teildaten. Ein solcher Datenidentifizierparameter ist bevorzugt eine ID über die die gewünschten Teildaten identifizierbar sind. Ein solcher Datenidentifizierparameter kann beispielsweise eine Teilenummer und/oder eine Seriennummer eines Zuliefererteils umfassen. Die Teildaten können beispielsweise bestimmte Daten (Parameter aus der Herstellung, Prüfdaten, oder Ähnliches) für dieses Zuliefererteil umfassen.
Die Prüfung anhand der Blockchain, ob die Anfrage mit einem von dem Datenbereitsteller in der Blockchain hinterlegten Regelwerk als berechtigt eingestuft wurde in Schritt b) erfolgt bevorzugt implizit. Die Prüfung kann beispielsweise schon dadurch realisiert werden, dass festgestellt wurde, dass die jeweilige Datenanfrage aus Schritt a) erfolgreich in die Blockchain eingetragen wurde. Wenn die Datenanfrage unmittelbar aus der Blockchain empfangen wurde, bspw. in dem die Blockchain von dem Datenbereitstellungsmodul permanent überwacht wird, kann die Prüfung implizit bereits schon dadurch erfolgen, dass die Anfrage erfolgreich aus der Blockchain empfangen wurde. Diese Art der impliziten Prüfung einer Anfrage anhand eines in der Blockchain hinterlegten Regelwerks erfolgt beispielsweise dadurch, dass davon ausgegangen wird, dass eine in die Blockchain eingetragene Anfrage nur dann in die Blockchain eingetragen wurde, wenn diese Anfrage auch mit dem Regelwerk als berechtigt eingestuft wurde. Es erfolgt also zunächst eine Vorprüfung der Anfrage in der Blockchain anhand des hinterlegten Regelwerks und die Prüfung in Schritt b) umfasst das Validieren dieser Vorprüfung. Dabei kann die Validierung dieser Vorprüfung auch dadurch erfolgen, dass auf das Wissen darüber zurückgegriffen wird, dass an dem Ablageort (Blockchain) hinterlegte Datenanfragen grundsätzlich als anhand des Regelwerks als berechtigt eingestuft werden mussten.
Das in der Blockchain hinterlegte Regelwerk ist bevorzugt in Form eines Smart-Contracts in der Blockchain hinterlegt. Bevorzugt ist das Regelwerk von dem Datenbereitsteller erstellt und (in Form des Smart-Contracts) in die Blockchain geschrieben worden. Als in die Blockchain geschriebener Smart-Contract ist das Regelwerk nicht abänderbar und insbesondere für den Datenanfrager nicht abänderbar. Das Regelwerk ist allenfalls durch ein Regelwerkupdate, welches vom Datenbereitsteller in Form eines neuen Smart-Contracts in die Blockchain geschrieben wird, abänderbar. Ausschließlich der Datenbereitsteller hat die notwendigen Berechtigungen für ein Regelwerkupdate auf der Blockchain.
Die Bereitstellung der angefragten Teildaten in Schritt c) erfolgt nur sofern die Anfrage als berechtigt eingestuft wurde. Im Folgenden werden weitere Details dazu ausgeführt wie die Bereitstellung der Daten in vorteilhafter Weise erfolgen kann.
Die hier beschriebene Art der Bereitstellung von Daten hat weitreichende Vorteile: Die Überprüfung der Daten wird anhand der Blockchain möglich bzw. durch die Blockchain selbst durchgeführt. Vorgelagert zu den beschriebenen Verfahrensschritten a) bis c), die mit dem Datenbereitstellungsmodul ausgeführt werden, wird die gesendete Anfrage bzw. Anfragetransaktion anhand des im Smart- Contract hinterlegten Regelwerks (Berechtigungsüberprüfung) als valide verifiziert und nur in diesem Fall in die Blockchain geschrieben bzw. in einen Block aufgenommen. Mit dem Eintrag der Anfrage in die Blockchain bzw. in einen Block der Blockchain wird die Anfrage unwiderruflich persistiert. In dem Fall, dass die Anfrage nicht als valide verifiziert werden konnte, weil sie gegen das Regelwerk in dem Smart-Contract verstößt, wird die Anfrage verworfen. Dieser dem hier beschriebenen Verfahren vorgelagerte Verarbeitungsschritt wird bevorzugt komplett außerhalb des Datenverarbeitungsmoduls und unabhängig von dem Datenverarbeitungsmodul ausgeführt. Wie schon weiter oben beschrieben verlässt sich die Prüfung in Schritt b) bevorzugt auf diese Vorprüfung.
Wenn die Prüfung in Schritt b) sich vollständig auf die Vorgänge in der Blockchain (Vorprüfung bzw. erfolgreiche Eintragung der Anfrage in einen Block der Blockchain verlässt), kann erreicht werden, dass keinerlei Überprüfung der Berechtigung einer Anfrage in dem Datenbereitstellungsmodul mehr erforderlich ist. Nur wenn die Anfrage als valide geprüft wurde, wird sie als Anfragetransaktion in die Blockchain geschrieben.
Dies eröffnet die Möglichkeit weitreichender Vereinfachungen und, wenn dies gewünscht ist, auch gesteigerter Transparenz bei der Bereitstellung von Daten.
Besonders bevorzugt ist das Verfahren, wenn Schritt c) die folgenden Unterschritte umfasst, wenn eine Bereitstellung von angefragten Teildaten erfolgt:

c1) Einlesen der angefragten Teildaten aus dem vertraulichen Datenspeicher mit Hilfe des mindestens einen Datenidentifizierparameters;
c2) Verschlüssen der eingelesenen Teildaten, so dass verschlüsselte Teildaten entstehen und Bereitstellung der verschlüsselten Teildaten auf einer Datentransferplattform.

Mit Schritt c1) wird insbesondere eine automatisierte Sammlung der angefragten Teildaten im Unternehmen möglich. Aufgrund der vorgelagerten Prüfung in Schritt b) anhand der Blockchain kann sich das Datenbereitstellungsmodul auf die mit Schritt a) empfangene Anfrage zu 100 Prozent verlassen. Aus diesem Grund werden neue Möglichkeiten zur Automatisierung des Einlesens der gewünschten Teildaten ermöglicht. Das Einlesen von Teildaten kann insbesondere ohne manuelle und von einem (menschlichen) Operator kontrollierte Verarbeitungsschritte erfolgen. Darin liegt ein großes ökonomisches Einsparpotential.
Der Schritt c2) beinhaltet zwei Unterschritte, nämlich das Verschlüsseln und die Bereitstellung der verschlüsselten (Teil)-Daten. Das Verschlüsseln stellt sicher, dass keine dritte Partei die bereitgestellten Daten lesen kann. Der zweite Schritt führt im Sinne eines Daten „PUSH“ Verfahrens aus dem gesicherten Firmenbereich hinaus an die Datentransferplattform, die bevorzugt einen öffentlichen Speicher für die Daten bereitstellt. Dadurch, dass die Daten auf der Datentransferplattform bereit gestellt werden, muss niemals externen Partnern (Datenanfragern) Zugang zu den internen Daten im vertraulichen Datenspeicher oder einem anderen, ggf. temporären, nicht vertraulichen internen Datenspeicher gewährt werden. Hierdurch kann eine beachtliche Erhöhung der Datensicherheit der Daten im vertraulichen Speicher erreicht werden.
Besonders bevorzugt, ist, wenn in Schritt c2) zunächst ein symmetrischer Schlüssel generiert wird, und die angefragten Teildaten mit dem symmetrischen Schlüssel vor der Bereitstellung auf der Datentransferplattform verschlüsselt werden und der symmetrische Schlüssel dem Datenanfrager über einen sicheren Kanal bereit gestellt wird.
Mit diesem Verfahren werden dem Datenanfrager nicht die Daten direkt zur Verfügung gestellt, sondern hier wird der (geheime) Ort übermittelt, an dem die Daten auf der öffentlichen Datentransferplattform abgelegt wurden. Durch die Verwendung eines symmetrischen Schlüssels zur Verschlüsselung der eigentlichen Daten (Teildaten) kann die (gegebenenfalls umfangreiche) Menge an Daten effizient verschlüsselt werden. Symmetrische Verschlüsselungsverfahren sind häufig effizienter als asymmetrische Verschlüsselungsverfahren.
Weiterhin vorteilhaft ist, wenn der symmetrische Schlüssel mit einem öffentlichen Schlüssel eines Schlüsselpaars des Datenanfragers verschlüsselt und in der Blockchain bereitgestellt wird. Der öffentliche Schlüssel des Schlüsselpaars des Datenanfragers kann von dem Datenanfrager für den Datenbereitsteller abrufbar bereitgestellt werden. Durch eine elektronische Signatur oder ähnliche Maßnahmen kann auch sichergestellt werden, dass der öffentliche Schlüssel des Datenanfragers eindeutig dem Datenanfrager zuordenbar ist und hier keine Identitätsfälschung (bzw. kein man-in-the-middle-Angriff) erfolgen kann.
Bevorzugt wird der symmetrische Schlüssel als Paket bestehend aus dem symmetrischen Schlüssel und einer Prüfsumme mit dem öffentlichen Schlüssel des Datenanfragers verschlüsselt und über die Blockchain bereitgestellt. Gegebenenfalls ist Bestandteil dieses Pakets auch eine Information über den Speicherort der verschlüsselten Teildaten. Der Datenanfrager erhält den verschlüsselten symmetrischen Schlüssel bzw. dieses Paket über die Blockchain, in dem der Datenanfrager an der Blockchain horcht bzw. die Blockchain überwacht und reagiert, wenn der Schlüssel bzw. das Paket hier mit Referenz zu dessen zuvor platzierten Anfrage auftaucht. Mit dem Inhalt dieses Pakets kann nun der Datenanfrager die angefragten Teildaten finden, entschlüsseln und gegebenenfalls anhand der Prüfsumme auch die Echtheit dieser Daten überprüfen.
Weiterhin vorteilhaft ist das Verfahren, wenn das Regelwerk mindestens eine erste Berechtigungsdefinition enthält, die Teildaten definiert, für deren Zugriff der Datenanfrager berechtigt ist und wobei die Einstufung einer Anfrage als berechtigt nur dann erfolgt, wenn die mindestens eine erste Berechtigungsdefinition erfüllt ist.
Als Teil des Regelwerks liegen solche Berechtigungsdefinitionen auch in der Blockchain. Eine solche Berechtigungsdefinition, die Teildaten definiert, kann beispielsweise anhand des Datenidentifizierparameters erkennen, ob eine Anfrage berechtigt ist. Beispielsweise kann der Datenidentifizierparameter bestimmte Nummernkreise ansprechen, wobei einzelne Teildatenpakete Datenidentifizierparametern innerhalb dieser Nummernkreises zugeordnet sind. Die Nummernkreise können beispielsweise jeweils einzelnen Kunden des Datenbereitstellers zugeordnet sein. Beispielsweise können Zulieferteile mit einer Teilenummer beginnend mit 1 einem ersten Kunden zugeordnet sein, Zulieferteile für einen zweiten Kunden mit einer Nummer mit 2 und so weiter. Die Teilenummer kann als Datenidentifizierparameter für die Kunden dienen.
Wenn der erste Kunde als Datenanfrager auftritt, kann die erste Berechtigungsdefinition vorgeben, dass dieser Kunde nur Teildaten zu Zulieferteilen mit Kundennummern beginnend mit 1 erhält. Für den zweiten Kunden als Datenanfrager kann es sich um Kundennummern beginnend mit 2 handeln und so weiter.
Die Überprüfung mit der ersten Berechtigungsdefinition stellt also in diesem Fall sicher, dass der Datenanfrager nur Teildaten von Produkten anfragen kann, die auch an ihn geliefert wurden. Der Datenanfrager kann keine Teildaten von Produkten erfragen die z.B. an Mittbewerber geliefert wurden (und welche gegebenenfalls eine andere Qualität oder sonstige unterschiedliche Eigenschaften) haben.
Außerdem vorteilhaft ist das Verfahren, wenn das Regelwerk mindestens eine zweite Berechtigungsdefinition enthält, die eine maximale Anzahl von Anfragen und/oder eine maximale Datenmenge enthält, die ein Datenanfrager in einem vorgegebenen Zeitintervall anfragen darf und wobei einer Einstufung einer Anfrage als berechtigt nur dann erfolgt, wenn die mindestens eine zweite Berechtigungsdefinition erfüllt ist.
Mit dieser Definition kann beispielsweise eine maximale Anzahl von Datenanfragen oder eine maximale Datenmenge pro Tag, Woche oder Monat festgelegt sein. Es können auch mehrere derartige Limits existieren, die gestuft zueinander abgefragt werden, wobei weder das eine oder das andere Limit für das jeweilige Zeitintervall überschritten werden darf. Durch eine solche zweite Berechtigungsdefinition kann insbesondere der systematische Zugriff auf große Datenmengen verhindert werden.
Durch eine solche zweite Berechtigungsdefinition wird manueller Aufwand stark reduziert, aber auch eine manuelle Kontrolle umgangen. Da der Datenbereitsteller aber Interesse daran hat, dem Datenanfrager Teildaten seiner Produkte automatisiert zu übermitteln, kann der Datenbereitsteller die Anzahl der automatisierten Übermittlungen begrenzen. Die Begrenzung kann z.B. auf einen Prozentsatz der gelieferten Produkte beschränkt sein oder auf eine Anzahl, die im üblichen statistischen Maß eine Anfrage von Daten rechtfertigt. In der zweiten Berechtigungsdefinition hinterlegte Begrenzungen können gegebenenfalls auf explizite Anfrage hin auch angehoben oder sogar aufgehoben werden, wenn der Datenbereitsteller hiermit einverstanden ist. Die Anfrage zur Anhebung sowie eine mögliche Einverständniserklärung oder Ablehnung dieser Anfrage durch den Datenanfrager kann ggf. auch über die Blockchain erfolgen.
Außerdem besonders voreilhaft ist das Verfahren, wenn das Regelwerk mindestens eine dritte Berechtigungsdefinition enthält, die eine Detailtiefe der Teildaten definiert, die ein Datenanfrager abrufbaren darf und wobei eine Einstufung einer Anfrage als berechtigt nur dann erfolgt, wenn die mindestens eine dritte Berechtigungsdefinition erfüllt ist.
Solche dritte Berechtigungsdefinitionen ermöglichen eine erweiterte Berechtigungsfunktion könnte z.B. eine weitere Detailstufe von Daten mit einem höheren Datenvolumen, höherer Auflösung, tieferer Datenhierarchie o.a. sein, die ggf. einer anderen maximalen Datenmenge unterliegen als im Verfahren nach 6. oder auch andere, hier nicht näher aufgeführte, Berechtigungsfunktionen.
Da die Berechtigungsdefinitionen auf der Blockchain liegen, kann der Datenanfrager alleine (ohne Einverständnis des Datenbereitstellers) die Berechtigungsdefinitionen nicht beeinflussen.
Die Tatsache, dass die verschiedenen Berechtigungsdefinitionen für einen automatisierten Datenaustausch auf einer ggf. öffentlichen Blockchain abgelegt werden, führt nicht zu einer Veröffentlichung von Informationen, die der Datenbereitsteller geheim halten möchte. Der Datenbereitsteller möchte i.A. Informationen als vertraulich behandeln, die z.B. betreffen:

- die Qualität seiner Produkte;
- Effizienz der Produktion (Produktivität, Qualitätsrate, Verfügbarkeit);
- Anzahl produzierter Einheiten;
- Anzahl gelieferter Produkte für bestimmte Kunden;
- Marktanteile;
- oder andere.

Die Berechtigungsdefinitionen liegen ggf. auf einer öffentlichen Blockchain, das bedeutet aber nicht, dass sie interpretierbar sind. Wird z.B. die Berechtigungsfunktion so implementiert, dass sie bestimmte Seriennummern überprüft, für die ein Datenanfrager berechtigt ist Daten anzufragen (erste Berechtigungsdefinitionen), dann ist eine mögliche Implementierung, die berechtigten Seriennummern in einer Liste auf der Blockchain abzulegen. Dies bedeutet implizit, wenn der Empfänger bekannt ist, wäre öffentlich bekannt, welche Produkte mit welchen Seriennummern an diesen Empfänger geliefert wurden. Auf einer Blockchain kann aber auch ein anderes Verfahren als eine (offene) Liste verwendet werden: Die Seriennummern können auch in einem sog. kryptographischen Akkumulator abgelegt werden, der die Antwort einer „Mitgliedschaft“ für eine bestimmte Nummer / ID in einer Gruppe liefert, ohne die Liste der Mitglieder der Gruppe offenzulegen.
In besonders bevorzugten Ausführungsvarianten des Verfahrens erfolgt eine Prüfung der Berechtigung in Schritt b) anhand der Blockchain dadurch, dass geprüft wird, ob die Anfrage von der Blockchain validiert und in die Blockchain aufgenommen wurde.
Dieses Verfahren hat einen enormen wirtschaftlichen Nutzen: Einerseits kann die Übertragung von geschützt liegenden Daten aus einer Umgebung des Datenbereitstellers völlig automatisiert werden, wodurch ein hohes Kosteneinsparpotential realisiert werden kann. Andererseits hat der Datenbereitsteller durch dieses Verfahren die volle Kontrolle über die Regeln der automatisierten Datenübermittlung. Obwohl Daten ohne manuelle Prüfung automatisiert übertragen werden, kann kein Datenanfrager unkontrolliert Daten beziehen.
Die Prüfung der Datenanfragen des Datenanfragers erfolgt in der Blockchain tatsächlich durch sogenannte Block-Ersteller (häufig auch Block Producer), die jede Datenanfrage (als Transaktion) oder auch jede andere Information (als Transaktion), die in die Blockchain geschrieben werden soll, überprüfen. Nur wenn die Datenanfrage sämtlichen Anforderungen erfüllt und insbesondere auch den für die jeweilige Anfrage vorgesehenen Regelwerke, wird diese Anfrage in die Blockchain geschrieben.
Besonders vorteilhaft ist das Verfahren, wenn außer der Prüfung der Berechtigung in Schritt b) anhand der Blockchain keine weitere Prüfung der Berechtigung erfolgt.
Durch die Verwendung der Blockchain kann auf jede weitere Prüfung der Berechtigung verzichtet werden. Dies macht das beschriebene Verfahren besonders effizient. Es ist allerdings nicht ausgeschlossen, das zusätzliche Überprüfungen möglich sind.
Besonders bevorzugt ist das Verfahren, wenn Anfragen in der Blockchain in verschlüsselter Form und/oder mit einem Hash-Wert hinterlegt werden.
Auf diese Art- und Weise kann insbesondere verhindert werden, dass Informationen, die über die Blockchain zwischen einem bestimmten Datenanfrager und einem bestimmten Datenbereitsteller oder umgekehrt, übertragen werden, an Dritte abfließen.
Hier auch beschrieben werden soll ein Datenbereitstellungsmodul eingerichtet zum Austausch von Daten mit einer öffentlichen Blockchain und eingerichtet zur Durchführung des beschriebenen Verfahrens.
Die weiter oben beschriebenen besonderen Vorteile und Ausgestaltungsmerkmale des Verfahrens sind auf das beschriebene Datenbereitstellungsmodul anwendbar und übertragbar. Details zum Aufbau des Datenbereitstellungsmoduls sind im Folgenden im Zusammenhang mit den Figuren offenbart.
Hier auch beschrieben werden soll ein Computerprogrammprodukt umfassend ein derartiges Datenbereitstellungsmodul oder ein Datenbereitstellungsmodul eingerichtet zur Durchführung des beschriebenen Verfahrens.
Außerdem beschrieben wird ein Speichermedium, auf dem ein derartiges Computerprogrammprodukt gespeichert ist.
Die Erfindung und das technische Umfeld wird im Folgenden anhand der Figuren näher erläutert. Es ist darauf hinzuweisen, dass die Figuren nur schematisch sind und die Prinzipien der hier behandelten Erfindung erläutern sollen. Einzelne beschriebene Merkmale oder Funktionen des Ausführungsbeispiels können auch in anderer als der dargestellten Weise sinnvoll im Rahmen der Erfindung miteinander kombiniert werden. Es zeigen

1: ein erstes schematisches Ablaufdiagramm eines beschriebenen Verfahrens mit den beteiligten Verfahrensakteuren; und
2: ein zweites schematisches Ablaufdiagramm eines beschriebenen Verfahrens mit den beteiligten Verfahrensakteuren.

Im dem Ablaufdiagramm des Verfahrens gemäß 1 ist oben zunächst der Datenbereitsteller 1 dargestellt, der hier neben dem vertraulichen Datenspeicher 2 angeordnet ist. Der vertrauliche Datenspeicher 2 ist beispielsweise auf einem Server oder in einer Fabrik angeordnet. In dem vertraulichen Datenspeicher 2 befinden sich Daten 4, die beispielsweise eine Vielzahl von Teildaten 9 umfassen können, wobei Teildaten 9 der Daten 4 jeweils mit einem Datenidentifizierparameter 12 identifizierbar sind. Der Datenbereitsteller ist der Inhaber der Daten 4 und damit auch der Teildaten 9, aus denen die Daten 4 bestehen. Der Datenbereitsteller 1 schreibt eine Berechtigungsdefinition 6 in eine Blockchain 5. Die Blockchain 5 besteht aus einer Vielzahl von aufeinanderfolgenden Blöcken 10 in welche eine Vielzahl von Daten in Form von Transaktionen hinterlegt sein kann. Transaktionen in den Blöcken 10 können insbesondere die beschriebenen Regelwerke 13, validierte Anfragen 14 oder auch weitere Daten wie öffentliche Schlüssel 15 und symmetrische Schlüssel 17 zur Verschlüsselung von Daten sein. Die Berechtigungsdefinition 6 kann Teil eines Regelwerks 13 sein, gemäß welchem Daten aus dem vertraulichen Datenspeicher 2 zur Verfügung gestellt werden können und welches beispielsweise erste Berechtigungsdefinitionen 18, zweite Berechtigungsdefinitionen 19 oder dritte Berechtigungsdefinitionen 20 umfassen kann.
Ein Datenanfrager 7 ist unterhalb der Blockchain dargestellt. Der Datenanfrager 7 kann eine Anfrage 8 zur Bereitstellung bestimmter Teildaten 9 an die Blockchain 5 übermitteln, wobei eine solche Anfrage auch einen Datenidentifizierparameter 12 beinhaltet, mit welchem die jeweiligen Teildaten identifizierbar sind.
Diese Anfrage 8 wird als validierte Anfrage 14 in die Blockchain 5 geschrieben, sofern die Anfrage mit dem Regelwerk 13 übereinstimmt. Die Anfrage 8 mit dem Datenidentifizierparameter 12 gelangt über die Blockchain 5 an ein Datenbereitstellungsmodul, welches an dem vertraulichen Datenspeicher 2 angeordnet ist. Es erfolgt eine Berechtigungsprüfung 21, die auch implizit dadurch erfolgen kann, dass die Anfrage 8 nur dann über die Blockchain 5 zu dem Datenbereitstellungsmodul 3 gelangt, wenn diese als validierte Anfrage in die Blockchain 5 geschrieben wurde. Der Empfang der Anfrage durch das Datenbereitstellungsmodul 3 entspricht Schritt a) des beschriebenen Verfahrens. Die Prüfung, ob die Anfrage dem Regelwerk entspricht (ob explizit oder implizit), entspricht im wesentlichen Schritt b) des beschriebenen Verfahrens.
Verschlüsselte Teildaten 22 werden an eine Datentransferplattform 11 geschickt wo sie zum Abruf durch den Datenanfrager 7 zur Verfügung stehen. Ein symmetrischer Schlüssel 17, mit welchem die Teildaten 9 verschlüsselt worden sind, kann über die Blockchain 5 ebenfalls an den Datenanfrager 7 übermittelt werden, damit dieser die verschlüsselten Teildaten 22 entschlüsseln kann. Der symmetrische Schlüssel 17 kann dazu mit einem ebenfalls über die Blockchain bereitgestellten öffentlichen Schlüssel 15 des Datenanfragers 7 verschlüsselt werden. Mit dem privaten (geheimen) Schlüssel 16 des Datenanfragers kann dieser dann zunächst den symmetrischen Schlüssel 17 und den geheimen Ablageort 11 entschlüsseln, um anschließend die verschlüsselten Teildaten 22 zu entschlüsseln. Die hier beschriebene Bereitstellung von Daten entspricht Schritt c) des beschriebenen Verfahrens mit den einzelnen Unterschritten c1) und c2).
In der 2 ist das beschriebene Verfahren noch in einer etwas anderen Darstellung aufgeführt, nämlich in Form eines Flussdiagramms. Der Datenanfrager 7 stellt zunächst die Anfrage 8, die dann an die Blockchain 5 übergeben wird in welcher eine Anfrageprüfung 24 erfolgt. Die Anfrageprüfung 24 kann entweder in einen akzeptierten Pfad 26 oder in einen abgelehnten Pfad 27 münden, wobei der abgelehnte Pfad mit der Beendigung 28 des Verfahrens endet. Wenn die Anfrage 8 akzeptiert wird, wird der akzeptierte Pfad 26 beschritten und es erfolgte eine Anfragespeicherung 25 der Anfrage. Anschließend wird die Anfrage durch den Datenbereitsteller 1 bzw. dessen Datenbereitstellungsmodul 3 empfangen. Dies erfolgt mit dem Block „Anfrage lesen 29“. Eine zusätzliche explizite Validierung der Anfrage wird nicht durchgeführt. Aufgrund der Tatsache, dass die Anfrage aus der Blockhain 5 stammt, wird der Anfrage vertraut. Dann erfolgt das Teildaten zusammenstellen 30 mit einer Verschlüsselung der Teildaten. Die Schlüsselpaket-Speicherung 32 erfolgt in der Blockchain 5. Das sichere Ablegen der Teildaten 31 wird von dem Datenbereitstellungsmodul 3 auf einer hier nicht dargestellten Datentransferplattform 11 durchgeführt. Die abgelegten Teildaten 31 und das gespeicherte Schlüsselpaket 32 können nun von dem Datenanfrager 7 verarbeitet werden. Es erfolgt ein Schlüsselpaketeinlesen 33 und ein Laden und Entschlüsseln der Daten 34.
Bezugszeichenliste

1: Datenbereitsteller
2: vertraulicher Datenspeicher
3: Datenbereitstellungsmodul
4: Daten
5: Blockchain
6: Berechtigungsdefinition
7: Datenanfrager
8: Anfrage
9: Teildaten
10: Block
11: Datentransferplattform
12: Datenidentifizierparameter
13: Regelwerk
14: validierte Anfrage
15: öffentlicher Schlüssel
16: privater Schlüssel
17: symmetrischer Schlüssel
18: erste Berechtigungsdefinition
19: zweite Berechtigungsdefinition
20: dritte Berechtigungsdefinition
21: Berechtigungsprüfung
22: verschlüsselte Teildaten
23: Verschlüsselungsmodul
24: Anfrageprüfung
25: Anfragespeicherung
26: akzeptierter Pfad
27: abgelehnter Pfad
28: Beendigung
29: Anfrage lesen
30: Teildaten zusammenstellen
31: Teildaten sicher ablegen
32: Schlüsselpaket speichern
33: Schlüsselpaket lesen
34: Daten laden und entschlüsseln

Claims

Verfahren zur selektiven Bereitstellung von Daten (4) aus einem vertraulichen Datenspeicher (2) eines Datenbereitstellers (1) mit einem Datenbereitstellungsmodul (3) aufweisend die folgenden Schritte: a) Empfangen einer Anfrage (8) von einem Datenanfrager (7) bezüglich der Bereitstellung von Teildaten (9) aus dem vertraulichen Datenspeicher (2), wobei die Anfrage mindestens einen Datenidentifizierparameter (12) zur Identifizierung der Teildaten (9) beinhaltet; b) Prüfen anhand einer Blockchain (5), ob die Anfrage (8) mit einem von dem Datenbereitsteller (1) in der Blockchain (5) hinterlegten Regelwerks (13) geprüft und als berechtigt eingestuft wurde; c) Sofern die Anfrage (8) als berechtigt eingestufte wurde, Bereitstellung der zur Bereitstellung angefragten Teildaten (9) an den Datenanfrager (7).
Verfahren nach Anspruch 1, wobei Schritt c) die folgenden Unterschritte umfasst, wenn eine Bereitstellung von angefragten Teildaten (9) erfolgt: c1) Einlesen der angefragten Teildaten (9) aus dem vertraulichen Datenspeicher mit Hilfe des mindestens einen Datenidentifizierparameters (12); c2) Verschlüssen der eingelesenen Teildaten (9), so dass verschlüsselte Teildaten (22) entstehen und Bereitstellung der verschlüsselten Teildaten (22) auf einer Datentransferplattform (11).
Verfahren nach Anspruch 2, wobei in Schritt c2) zunächst ein symmetrischer Schlüssel (17) generiert wird, und die angefragten Teildaten mit dem symmetrischen Schlüssel (17) vor der Bereitstellung auf der Datentransferplattform (11) verschlüsselt werden und der symmetrische Schlüssel (17) dem Datenanfrager (7) über einen sicheren Kanal bereit gestellt wird.
Verfahren nach Anspruch 3, wobei der symmetrische Schlüssel (17) mit einem öffentlichen Schlüssel (15) eines Schlüsselpaars des Datenanfragers (7) verschlüsselt und in der Blockchain (5) bereitgestellt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Regelwerk (13) mindestens eine erste Berechtigungsdefinition (18) enthält, die Teildaten (9) definiert für deren Zugriff der Datenanfrager (7) berechtigt ist und wobei die Einstufung einer Anfrage (8) als berechtigt nur dann erfolgt, wenn die mindestens eine erste Berechtigungsdefinition (18) erfüllt ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Regelwerk (13) mindestens eine zweite Berechtigungsdefinition (19) enthält, die eine maximale Anzahl von Anfragen (8) und/oder eine maximale Datenmenge enthält, die ein Datenanfrager (7) in einem vorgegebenen Zeitintervall anfragen darf und wobei einer Einstufung einer Anfrage (8) als berechtigt nur dann erfolgt, wenn die mindestens eine zweite Berechtigungsdefinition (19) erfüllt ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Regelwerk (13) mindestens eine dritte Berechtigungsdefinition (20) enthält, die eine Detailtiefe der Teildaten (9) definiert, die ein Datenanfrager (7) abrufen darf und wobei eine Einstufung einer Anfrage (8) als berechtigt nur dann erfolgt, wenn die mindestens eine dritte Berechtigungsdefinition (20) erfüllt ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei eine Prüfung der Berechtigung in Schritt b) anhand der Blockchain (5) dadurch erfolgt, dass geprüft wird, ob die Anfrage (8) von der Blockchain (5) validiert und in die Blockchain (5) aufgenommen wurde.
Verfahren nach einem der vorhergehenden Ansprüche, wobei außer der Prüfung der Berechtigung in Schritt b) anhand der Blockchain (5) keine weitere Prüfung der Berechtigung erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei Anfragen (8) in der Blockchain (5) in verschlüsselter Form und/oder mit einem Hash-Wert hinterlegt werden.
Datenbereitstellungsmodul (3) eingerichtet zum Austausch von Daten mit einer öffentlichen Blockchain (5) und eingerichtet zur Durchführung eines Verfahrens gemäß einem der Ansprüche 1 bis 10.
Computerprogrammprodukt umfassend ein Datenbereitstellungsmodul (3) nach Anspruch 11 oder eingerichtet zur Durchführung eines Verfahrens gemäß einem der Ansprüche 1 bis 10.
Speichermedium, auf dem ein Computerprogrammprodukt nach Anspruch 11 gespeichert ist.