DE102021133816A1

DE102021133816A1 - Attestierung von operationen durch toolketten

Info

Publication number: DE102021133816A1
Application number: DE102021133816.6A
Authority: DE
Inventors: Vincent Scarlata; Alpa Trivedi; Reshma Lal; Marcela S. Melara; Michael Steiner; Anjo Vahldiek-Oberwagner
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2020-12-24
Filing date: 2021-12-20
Publication date: 2022-06-30
Also published as: US20230333824A1; CN114675828A; US11650800B2; US20220206764A1

Abstract

Es wird eine Attestierung von Operationen durch Toolketten beschrieben. Ein Beispiel eines Speicherungsmediums beinhaltet Anweisungen zum Empfangen von Quellcode zum Verarbeiten einer sicheren Arbeitslast eines Mandanten; Auswählen mindestens eines ersten Rechenknotens zum Bereitstellen einer Berechnung für die Arbeitslast; Verarbeiten des Quellcodes durch eine attestierbare Toolkette, um Maschinencode für den ersten Rechenknoten zu generieren, einschließlich Durchführen einer oder mehrerer Umwandlungen des Quellcodes durch einen oder mehrere Umwandler, um umgewandelten Code zu generieren, und Generieren einer Attestierung, die mit jeder Codeumwandlung assoziiert ist, und Empfangen von Maschinencode für den ersten Rechenknoten und Generieren einer Attestierung, die mit dem ersten Rechenknoten assoziiert ist; und Bereitstellen jeder der Attestierungen aus der ersten Phase und aus der zweiten Phase zur Verifizierung.

Description

TECHNISCHES GEBIET
Hierin beschriebene Ausführungsformen betreffen allgemein das Gebiet der elektronischen Vorrichtungen und insbesondere eine Attestierung von Operationen durch Toolketten.
STAND DER TECHNIK
Cloud-Dienstanbieter (CSPs) expandieren ihre Dienste immer mehr auf neue Kunden, einschließlich Dienste für sicherheitsbewusste Kunden, die in der Vergangenheit gezögert haben, Cloud-Dienste zu nutzen. Dies hat einen Trend angespornt, dass CSPs vertrauliche Rechendienste anbieten, die auf vertrauenswürdigen Rechentechniken aufbauen.
Gleichzeitig erweitern Cloud-Dienstanbieter ihre Rechenvorrichtungen von alleinigen CPUs (Zentralverarbeitungseinheiten) auf eine breite Vielfalt anderer Arten von Rechenknoten, einschließlich verschiedener Verarbeitungseinheiten und Hardwarebeschleuniger. Um diese heterogenen Rechenumgebungen auszunutzen, unterstützen Anbieter ferner die Einrichtung von Toolketten, die es einem Kunden ermöglichen, ihre Geschäftslogik derart zu schreiben, dass die Toolkette sie dann für einen beliebigen dieser Beschleuniger kompilieren kann.
Diese Trends arbeiten jedoch inhärent nicht gut zusammen. Vertrauliches Rechnen ermöglicht es einer Rechenvorrichtung, Logik zu attestieren, dass sie mit der Erwartung läuft, dass der Kunde sie erkennt, während eine Bereitstellung von Code über eine Toolkette dazu führt, dass der Code, den ein Rechenknoten ausführt, ein Derivat des Codes ist, der durch den Kunden bereitgestellt wird, anstatt des Codes des Kunden selbst.
Figurenliste
Hierin beschriebene Ausführungsformen sind in den Figuren der beiliegenden Zeichnungen beispielhaft, jedoch nicht einschränkend illustriert, in denen gleiche Bezugszeichen auf ähnliche Elemente verweisen.

1 ist eine Veranschaulichung einer Attestierung von Operationen, die mit Toolketten assoziiert sind, nach einigen Ausführungsformen;
2 ist eine Veranschaulichung der Anwendung einer Toolkette zum Generieren einer Kette von Attestierungszusicherungen für Code, der auf einem Endrechenknoten ausgeführt werden soll, nach einigen Ausführungsformen;
3 ist eine Veranschaulichung der Generierung von Attestierungen durch eine attestierbare Toolkette nach einigen Ausführungsformen;
4 ist eine Veranschaulichung von Messungen und Attestierungen, die mit dem Betrieb einer attestierbaren Toolkette assoziiert sind, nach einigen Ausführungsformen;
5 ist eine Veranschaulichung einer transitiven Attestierung, die eine Attestierung durch eine attestierbare Toolkette zusammenfasst, nach einigen Ausführungsformen;
6 ist ein Ablaufdiagramm zum Veranschaulichen eines Prozesses zum Attestieren einer Umwandlung oder Bewertung durch eine attestierbare Toolkette nach einigen Ausführungsformen;
7 veranschaulicht eine Ausführungsform einer beispielhaften Rechenarchitektur zur Attestierung von Operationen durch Toolketten nach einigen Ausführungsformen;
8A und 8B veranschaulichen ein Signaturschema auf Einmalhashbasis bzw. ein Signaturschema auf Mehrfachhashbasis; und
9A und 9B veranschaulichen ein Einmalsignaturschema bzw. ein Mehrfachsignaturschema.

AUSFÜHRLICHE BESCHREIBUNG
Hierin beschriebene Ausführungsformen betreffen eine Attestierung von Operationen durch Toolketten.
Um Dienste auf sicherheitsbewusste Kunden zu erweitern, können Cloud-Dienstanbieter (CSPs) vertrauliche Rechendienste anbieten, die auf vertrauenswürdigen Rechentechniken aufgebaut sind, wie etwa unter Verwendung stärkerer Isolationstechnologien zwischen Kundenarbeitslasten und der Fähigkeit, dass Rechenvorrichtungen dem Kunden attestieren, dass beispielsweise Rechenknoten in Bezug auf Patchen auf dem neuesten Stand sind, dass die relevanten Rechenknoten diese Technologien anwenden, um die Arbeitslast zu schützen, und dass die Arbeitslast, die verarbeitet wird, die Logik ist, die der Kunde einsetzen will und nicht manipuliert wurde. Der Kunde kann dann diese Attestierung verifizieren, bevor er sensible Daten an die Rechenknoten ausgibt.
Die CSP-Unterstützung wird jedoch von einem Betrieb durch CPUs (Zentralverarbeitungseinheiten) auf einen Betrieb durch eine breite Vielfalt von Rechenknoten, einschließlich mehrerer Arten von Verarbeitungsvorrichtungen (wie GPUs (Grafikverarbeitungseinheiten) und Hardwarebeschleuniger (wie FPGAs (feldprogrammierbare Gatearrays) und ASICs (anwendungsspezifische integrierte Schaltkreise)) erweitert, die eine erhöhte Leistung für bestimmte Arbeitslasten ermöglichen können. Um diese heterogenen Rechenumgebungen vollständig auszunutzen, wird die Einrichtung von Toolketten (wie etwa Intel® oneAPI-Toolkit und andere) unterstützt, um es einem Kunden zu ermöglichen, die Geschäftslogik (anfänglichen Quellcode) des Kunden derart zu schreiben, dass die attestierbare Toolkette sie dann für eine beliebige dieser Verarbeitungseinheiten und Hardwarebeschleuniger compilieren oder übersetzen kann (was allgemein als Umwandlung der Codelogik bezeichnet werden kann). Wie hierin verwendet bezeichnet „attestierbare Toolkette“ allgemein einen Satz von Programmiertools oder Dienstprogramme zum Durchführen einer Operation, und insbesondere kann eine Toolkette angewendet werden, um Quellcode in Maschinencode für mehrere unterschiedliche Typen von Rechenknoten umzuwandeln. Eine Toolkette kann den Quellcode auch mit anderem Code, wie etwa Laufzeitcode oder Bibliotheken, kombinieren. Eine attestierbare Toolkette kann in der Lage sein, Attestierungen zu erzeugen, die Informationen über die Operation beinhalten können, die die Toolkette durchgeführt hat.
Diese Toolkettenunterstützung kann ein Differenzierungspunkt für CSPs sein, da ein CSP es einem Kunden ermöglichen kann, vorrichtungsagnostischen Quellcode zu schreiben, während der CSP die beste Hardware bestimmt, die der CSP zum Ausführen dieses Codes verfügbar hat, und die anwendbare Toolkette anwendet, um die vom Kunden geschriebene Logik in Maschinencode umzuwandeln, der auf dem spezifischen Rechenknoten zur Bereitstellung laufen kann, egal, ob der Rechenknoten eine CPU, eine GPU, ein FPGA oder ein anderer dedizierter Beschleuniger ist.
Eine API-artiger Codebereitstellung führt jedoch dazu, dass der Code, den der designierte Rechenknoten ausführt, eine Ableitung des Codes ist, der vom Kunden bereitgestellt wurde, anstelle des Codes des Kunden selbst. Aus diesem Grund sollte vertrauliches Rechnen in einer heterogenen Cloud-Rechenplattform einen Attestierungsprozess bereitstellen, der einen vorrichtungsagnostischen Toolkettenbetrieb unterstützt. Vorherige Lösungen dieses Problems erfordern, dass der Mandant den Beschleunigertyp, der seine Logik ausführen wird, vorab ermittelt, für diesen einen Build erstellt und dann diesen Code an den CSP liefert. Dieses herkömmliche Modell kann für gewisse einfache Arbeitslasten ausreichend gut funktionieren, wobei die Auswahl der Recheneinheit vorab ermittelt werden kann, aber Arbeitslasten können aus mehreren unabhängigen Elementen bestehen, die zusammenarbeiten, was eine komplexeren Betrieb erfordert. Ferner wollen sich Cloud-Anbieter möglicherweise von anderen Anbietern unterscheiden, indem sie bedienerfreundliche heterogene Umgebungen anbieten, und somit einen starken Wunsch aufweisen, die Last der Ermittlung zu übernehmen, welche Rechenknoten am besten zur Ausführung von Arbeitslasten sind.
Bei manchen Ausführungsformen soll eine Einrichtung, ein System oder ein Prozess eine Attestierung einer Compilierung, Übersetzung oder Auswertung durch eine attestierbare Toolkette bereitstellen. In einigen Ausführungsformen nutzt die Einrichtung, das System oder der Prozess eine oder mehrere attestierbare Umgebungen, um Attestierungen jeder Verarbeitungsphase durch die attestierbare Toolkette zu generieren und eine Kette von Attestierungszusicherungen zu erzeugen, die von der vom Kunden erkennbaren Arbeitslast zu der Maschinenlogik nachverfolgbar sind, die auf den Endrechenknoten genutzt werden soll. Bei einem derartigen Betrieb ist ein Kunde dann in der Lage, die Kette von Attestierungen anzuwenden, um die Logik, die auf dem Endgerät läuft, durch die Toolkette zurück zur ursprünglichen Logik zu verfolgen, die durch den Kunden bereitgestellt oder erkannt wird.
1 ist eine Veranschaulichung einer Attestierung von Operationen, die mit Toolketten assoziiert sind, nach einigen Ausführungsformen. Bei manchen Ausführungsformen kann der Prozess durch ein oder mehrere Rechensysteme durchgeführt werden, wie etwa ein Rechensystem, wie in 7 veranschaulicht. Bei einigen Ausführungsformen kann eine Attestierungsoperation 100 in zwei Phasen zerlegt werden: eine Build-Phase 110 (eine erste Phase), in der Vorrichtungscodelogik erzeugt wird, und eine Laufzeitphase 120 (eine zweite Phase), in der eine vertrauliche Rechenattestierung stattfindet.
In der Build-Phase 110 wird eine attestierbare Toolkette von einer oder mehreren attestierbaren Umgebungen 125 ausgeführt. Wie hierin verwendet, bezeichnet „attestierbare Umgebung“ eine Umgebung, die in der Lage ist, eine gewisse Operation einschließlich der Generierung von Code, zu attestieren. Die attestierbare Umgebung kann unter anderem Trusted-Execution-Environment(TEE)-Technologien beinhalten, wie etwa Intel® Software Guard Extensions (Intel® SGX), Intel® Trusted Domain Extensions (Intel® TDX) oder AMD SEV. Die Toolkette kann mehrere Phasen aufweisen, die bei der Codegenerierung für ein Endgerät angewendet werden. Bei manchen Ausführungsformen erzeugt während des Verarbeitens der Arbeitslast jede Toolkettenphase eine Attestierung, die eine folgende Phase nutzen kann, wobei die Attestierung Folgendes beinhalten kann:

(a) Messen der bestimmten Toolkettenphase 112, was eine beliebige bekannte Codemesstechnologie beinhalten kann; und
(b) Messungen oder Identifikation der Eingabelogik, die durch die attestierbare Toolkette 114 umgewandelt (compiliert oder übersetzt), inspiziert oder anderweitig verarbeitet werden soll.

Bei manchen Ausführungsformen kann die Attestierung optional andere Faktoren beinhalten, wie etwa eines oder mehrere von Folgendem:

(c) Beliebige Eigenschaften, die die Toolkettenphase entweder garantiert (zum Beispiel durch Einfügen von Code oder Linken mit spezifischen Bibliotheken) oder entdeckt hat (zum Beispiel durch Inspektion der Logik) 116, oder
(d) Messungen oder Identifikation der Logik, die als Ergebnis der Phase erzeugt wurde (es sei denn, dass zum Beispiel die Toolkettenphase eine reine Prüfphase war und somit keinen neuen Code erzeugt hat) 118.

Bei manchen Ausführungsformen wird in der Laufzeitphase 120 eine Attestierung für den Kunden generiert. Bei manchen Ausführungsformen beinhaltet die Laufzeitphase 120 eine Bereitstellung von herkömmlichem vertrauenswürdigem Rechnen oder vertraulichem Rechnen. Im Allgemeinen schützt vertrauliches Rechnen verwendete Daten durch Durchführen einer Berechnung in einer hardwarebasierten vertrauenswürdigen Ausführungsumgebung. Im Betrieb durch die Toolkette wird generierter Code an einem spezifischen Rechenknoten 122 bereitgestellt. Der generierte Code kann Zugriff auf eine bestimmte Ressource erfordern, die von einer Ressourcensteuerung, wie etwa dem Mandanten 150, gehalten wird, wobei der Mandant 150 Zugriff auf sensible Daten haben kann, die von dem Rechenknoten benötigt werden, um die Vorrichtungslogik an den beabsichtigten Daten auszuführen. In einigen Ausführungsformen beinhaltet die Operation Generieren einer Vorrichtungsattestierung durch den Rechenknoten 124 und Übertragen der Attestierung an die Ressourcensteuerung 126.
Bei manchen Ausführungsformen kann die vollständige Attestierung des Betriebs der Toolkette zu einer transitiven Kette von Ereignissen zusammengesetzt werden, die als die Attestierungskette bezeichnet werden kann, die durch einen bestimmten Verifizierungsagenten (als der Verifizierer bezeichnet) zu verifizieren ist, wobei der Verifizierer zum Beispiel den Mandanten 150 oder einen designierten Verifizierungsagenten beinhalten kann, der im Auftrag des Mandanten agiert. Der Verifizierer hat Operationen bereitzustellen, einschließlich:

(a) Verifizieren jeder Attestierung in der Attestierungskette, wobei die Verifizierung unter Verwendung eines beliebigen bekannten Attestierungsprozesses durchgeführt werden kann, und
(b) Sicherstellen, dass die Kette von Ereignissen von irgendeiner erkannten Logik, wobei die erkannte Logik der ursprüngliche Arbeitslastcode ist, zu der Logik führt, die in der Vorrichtungsattestierung widergespiegelt ist.

Bei manchen Ausführungsformen kann die resultierende Attestierungskette als Nachweis verarbeitet werden, dass die Attestierungsvorrichtung Logik ausführt, die aus der ursprünglichen Geschäftslogik abgeleitet ist, optional mit den spezifizierten Sicherheitseigenschaften, und durch die angegebenen Toolkettenelemente erstellt wurde. Falls diese Elemente alle die Richtlinie des Verifizierers erfüllen, kann die Operation mit dem Bereitstellen vertraulicher Daten für die Arbeitslastberechnung fortfahren.
2 ist eine Veranschaulichung der Anwendung einer Toolkette zum Generieren einer Kette von Attestierungszusicherungen für Code, der auf einem Endrechenknoten ausgeführt werden soll, nach einigen Ausführungsformen. Wie in 2 veranschaulicht, beinhaltet ein Cloud-Dienstanbieter 200 mehrere Rechenknoten 210, um die Operation einer Arbeitslast eines Kunden, wie etwa Mandant-A 250 mit assoziierter Arbeitslast 255, zu unterstützen. Die mehreren Rechenknoten 210 können zum Beispiel einen heterogenen Satz von Vorrichtungen beinhalten, einschließlich mehrerer Arten von Verarbeitungsvorrichtungen, Hardwarebeschleuniger oder beides, veranschaulicht als eine oder mehrere CPUs 212, eine oder mehrere GPUs 214 und ein oder mehrere Hardwarebeschleuniger 216. Der Cloud-Dienstanbieter 200 (oder eine andere Drittpartei) kann arbeiten, um die Arbeitslast 255 unter Nutzung einer beliebigen Kombination der verfügbaren Rechenknoten 210 zu unterstützen. Der CSP kann eine große Anzahl von Kunden versorgen, wie etwa zusätzliche Kunden, die als Mandant-B 260 bis Mandant-n 270 gezeigt sind, wobei jeder der derartigen Kunden eine andere Arbeitslast zur Verarbeitung bereitstellen kann, wobei jede solche Arbeitslast potenziell mit einer Toolkette zur Umwandlung von Quellcode in geeigneten Maschinencode für eine oder mehrere Recheneinheiten assoziiert sein kann.
Wie veranschaulicht, kann Mandant-A 250 eine attestierbare Toolkette bereitstellen oder auswählen, die als Toolkette-A 222 veranschaulicht ist, um Arbeitslastcode (Quellcode), der als Programmlogik-A 220 gezeigt ist, in einen oder mehrere Sätze von Maschinencode für einen oder mehrere der mehreren Typen von Rechenknoten umzuwandeln. Auf diese Weise kann die Arbeitslast 255 potenziell unter Verwendung einer Vielfalt unterschiedlicher Rechenknoten verarbeitet werden, ohne dass der Kunde solche Vorrichtungen identifizieren und dieses Wissen beim Generieren der Programmlogik 220 verwenden muss, d. h., die Programmlogik kann vorrichtungsagnostisch sein. Die Programmlogik-A 220 muss in Maschinencode für jeden von einem oder mehreren der Rechenknoten umgewandelt werden, die für eine Operation an der Arbeitslast 255 ausgewählt werden, die mit dem Mandanten-A 250 assoziiert ist.
Im herkömmlichen Betrieb, damit ein Kunde, wie etwa der Mandant-A 250, die Maschinenlogik erkennt und verifiziert, die auf jedem Endgerät läuft, müsste der Kunde die Toolkette ausführen und den resultierenden Maschinencode zur Verifizierung eines solchen Codes erzeugen. Dieses Betriebsmodell kann für bestimmte Toolketten beim Compilieren ihres eigenen Codes unterstützt werden. Für Hardwarebeschleuniger, FPGA-„Compiler“ oder ähnliche Elemente würde dieser Prozess jedoch eine Kenntnis des Basisbitstroms des CSP erfordern, und GPUs würden eine Kenntnis des potenziell angepassten Kernels des CSP erfordern. Derartige Operationen sind daher in einer CSP-Umgebung im Allgemeinen nicht praktikabel.
Bei manchen Ausführungsformen soll eine Einrichtung, ein System oder ein Prozess die Toolkette für einen Kunden aus einer oder mehreren attestierbaren Umgebungen ausführen. Während die Arbeitslast verarbeitet wird, sollen die Toolkettenphasen eine Attestierung dieser Phase erzeugen, wodurch zugesichert wird, dass die Toolkette den Eingabecode in den Ausgabecode umgewandelt hat. Bei manchen Ausführungsformen können Attestierungen optional ferner beliebige Sicherheitszusicherungen beinhalten, die die Toolkette über den resultierenden Code machen kann. Dies erzeugt somit eine Kette von Attestierungszusicherungen, beginnend mit der vom Kunden erkennbaren Arbeitslast und fortfahrend bis zur Logik, die auf dem Endgerät ausgeführt wird. Während des Arbeitslasteinsatzes, wenn ein Kunde eine Attestierung von dem Endrechenknoten empfängt, wird der Kunde in der Lage sein, diese Kette von Attestierungen anzuwenden, um die Logik, die auf dem Endgerät läuft, durch die Toolkette zurück zur ursprünglichen Logik zu verfolgen, die durch den Kunden bereitgestellt oder erkannt wird.
Bei manchen Ausführungsformen kann eine Toolkette somit an einem beliebigen Ort ausgeführt werden, sei es durch den Kunden, durch einen CSP, durch ein Regulierungsgremium oder eine gegenseitig vereinbarte Drittpartei, ohne dass der Buildprozess deterministisch und wiederholbar sein muss. Stattdessen stellt die Kette von Attestierungen die benötigten Daten bereit, um die Umwandlung oder Bewertung durch die Toolkette von der anfänglichen Logik zur Logik für die Ausführung durch die Endgeräte zu attestieren.
3 ist eine Veranschaulichung der Generierung von Attestierungen durch eine attestierbare Toolkette nach einigen Ausführungsformen. Bei einigen Ausführungsformen kann eine anfängliche Geschäftslogik (Quellcode), die als Code 1 gezeigt ist, durch einen Entwickler 300 (der ein Mandant sein kann oder ein Drittentwickler sein kann) erzeugt werden. In dieser Veranschaulichung ist Code 1 der anfängliche Code zur Verarbeitung einer sicheren Arbeitslast, wobei Code 1 in Maschinencode für einen bestimmten Endrechenknoten umgewandelt werden muss, wobei die Umwandlung (d. h. Compilierung oder Übersetzung) unter Verwendung einer attestierbaren Toolkette, wie etwa Toolkette-A 222, die in 2 veranschaulicht ist, durchgeführt werden soll. Der Entwickler 300 kann ein öffentliches Dokument 302 bereitstellen, das eine Messung in Bezug auf Code 1 bereitstellt, die bei der Verifizierung der Operation der Toolkette genutzt werden kann.
Bei manchen Ausführungsformen kann das Kettentool eine oder mehrere Phasen beinhalten, wobei jede Phase (die eine Umwandlungsphase zum Umwandeln und Attestieren von Code oder eine Prüfphase zum Prüfen von Code ohne Bereitstellen einer Übersetzung sein kann) eine Attestierung des Codes generieren kann.
Wie zum Beispiel in 3 veranschaulicht, wird der Code 1 in einer Build-Phase 304 durch die Übersetzungslogik 1 (312) empfangen (wobei die Übersetzungslogik auch als eine erste Umwandlung oder ein erster Umwandler bezeichnet werden kann), um eine Umwandlung des Codes 1 durchzuführen, um Code 2 zu generieren und um eine Attestierung 1 zu generieren (316). Die Übersetzungslogik 1 kann ferner Code empfangen, wie etwa einen öffentlichen Laufzeitcode 314. In diesem Beispiel kann die generierte Attestierung 1 eine Messung der Übersetzungslogik 1 (TL1) (d. h. eine Messung, die mit der Übersetzung-1 -Phase selbst assoziiert ist), eine Messung von Code 1 (eine Messung, die mit dem empfangenen Code 1 assoziiert ist), eine öffentliche Laufzeitcodemessung (eine Messung, die mit dem empfangenen öffentlichen Laufzeitcode assoziiert ist) und eine Messung von Code 2 (eine Messung, die mit dem erzeugten Code 2 assoziiert ist) enthalten.
Die veranschaulichte Operation kann mit einem Empfangen von Code 2 durch die Übersetzungslogik 2 (322) (einen zweiten Umwandler) fortfahren, um eine Übersetzung von Code 2 durchzuführen, um Code 3 zu generieren (wobei Code 3 in diesem speziellen Beispiel der Maschinencode für einen Endrechenknoten ist) und eine Attestierung 2 zu generieren (326). Die Attestierung 2 kann eine Messung der Übersetzungslogik 2 (TL2), eine Messung von Code 2 und eine Messung von Code 3 beinhalten. Ferner kann Code 3 ferner durch Prüflogik 332 (ein erstes Prüfungselement) geprüft werden, um eine Attestierung 3 (336) zu generieren, die eine Prüflogik(IL)-Messung, eine Messung von Code 3 beinhalten kann und ferner gewisse Sicherheitszusicherungen beinhalten kann.
Bei manchen Ausführungsformen kann der Code 3 in einer Laufzeitphase 306 durch den Endrechenknoten empfangen werden, der als Vorrichtung 340 gezeigt ist. Bei manchen Ausführungsformen soll die Vorrichtung 340 eine Attestierung 4 (die Vorrichtungsattestierung) erzeugen, die Informationen bezüglich der Vorrichtung 340 und einer Messung von Code 3 beinhalten kann.
Bei einigen Ausführungsformen können die generierten Attestierungen, die von der Übersetzungslogik 1 generierte Attestierung 1, die von der Übersetzungslogik 2 generierte Attestierung 2, die von der Prüflogik 332 generierte Attestierung 3 und die von der Endrechenvorrichtung 340 generierte Attestierung 4, jeweils einem Verifizierer bereitgestellt werden, wobei der Verifizierer der Mandant oder ein Verifizierungsagent sein kann, der im Auftrag des Mandanten agiert. Die Attestierungen können zusammen eine Attestierungskette bilden, um zu attestieren, dass die Attestierungsvorrichtung (Vorrichtung 340 in diesem Beispiel) Logik (Code 3) ausführt, die aus der ursprünglichen Geschäftslogik (Code 1) abgeleitet wurde und durch die angegebenen Toolkettenelemente (Übersetzungslogik 1 und Übersetzungslogik 2) erstellt wurde. Der Verifizierer kann dann ermitteln, ob die Attestierungen alle die Richtlinie des Verifizierers erfüllen, und falls ja, kann der Mandant (oder eine andere Partei) mit dem Einsetzen von Daten zu der Arbeitslast zur Verarbeitung durch die Vorrichtung 340 fortfahren.
4 ist eine Veranschaulichung von Messungen und Attestierungen, die mit dem Betrieb einer attestierbaren Toolkette assoziiert sind, nach einigen Ausführungsformen. Bei manchen Ausführungsformen werden die Messungen und Attestierungen 400 aus Phasen einer attestierbaren Toolkette und eines Endrechenknotens abgeleitet, wie diese in 3 veranschaulicht sind.
Bei manchen Ausführungsformen beinhaltet die Attestierung 1316, wie durch die Übersetzungslogik 1 in 3 generiert, eine TL-1(Übersetzungslogik-1)-Messung, eine Messung des empfangenen Codes 1 und eine Messung von Code 2. Zur Verifizierung kann die Messung von Code 2 mit einer Eingabelogikmessung für die Attestierung 2 326 verglichen werden. Zusätzlich dazu kann der Autor oder Entwickler der Toolkette eine öffentliche Dokumentation bereitstellen, die Messungen für die Toolkette beinhaltet, die durch den Mandanten oder einen Verifizierer zum Vergleich von generierten eingesetzt werden können. Die öffentliche Dokumentation kann unter anderem die veranschaulichte Dokumentation einer TL-1-Messung 404, die Dokumentation einer TL-2(Übersetzungslogik-2)-Messung 406 und die Dokumentation einer IL-(Prüflogik)-Messung 402 beinhalten.
Die Attestierung 2 326, wie durch die Übersetzungslogik 2 in 3 generiert, beinhaltet eine TL-2(Übersetzungslogik-2)-Messung, eine Messung des empfangenen Codes 2 und eine Messung von Code 3. Die Attestierung 2 326 kann ferner eine oder mehrere Sicherheitszusicherungen beinhalten. Zur Verifizierung kann die Messung von Code 3 mit einer Eingabelogikmessung für die Vorrichtungsattestierung 346 verglichen werden.
Die Attestierung 3 336, wie durch die Prüflogik 332 in 3 generiert, beinhaltet eine IL-Messung und eine Messung des generierten Codes 3. Zur Verifizierung kann die Messung von Code 3 mit einer Eingabelogikprüfung für die Vorrichtungsattestierung 346 verglichen werden.
Die Vorrichtungsattestierung 346 (die in 3 veranschaulichte Attestierung 4) beinhaltet dann eine Vorrichtungsmessung (für die Endverarbeitungsvorrichtung) und eine Messung von Code 3.
Bei einigen Ausführungsformen, wie in Bezug auf 3 beschrieben, können die generierten Attestierungen, die durch die Übersetzungslogik 1 generierte Attestierung 1, die durch die Übersetzungslogik 2 generierte Attestierung 2, die durch die Prüflogik generierte Attestierung 3 und die durch den Endrechenknoten generierte Vorrichtungsattestierung, jeweils einem Verifizierer bereitgestellt werden. Die Attestierungen können zusammen eine Attestierungskette bilden, um zu attestieren, dass jede Attestierungsvorrichtung Logik ausführt, die aus der ursprünglichen Geschäftslogik (Code 1) abgeleitet wurde und durch die angegebenen Toolkettenelemente (Übersetzungslogik 1 und Übersetzungslogik 2) erstellt wurde.
5 ist eine Veranschaulichung einer transitiven Attestierung, die die Attestierung durch eine attestierbare Toolkette zusammenfasst, nach einigen Ausführungsformen. Die transitive Attestierung wird als eine logische Repräsentation der in 4 gezeigten Informationen bereitgestellt, wenn sie zusammen betrachtet werden. Wie in 5 gezeigt, kann eine transitive Attestierung 500 eine Vorrichtungsmessung (wobei die Vorrichtung eine Endverarbeitungsvorrichtung ist, wie etwa die in 3 veranschaulichte Vorrichtung 340); eine Messung von Code 1 (Code 1 bezieht sich auf die ursprüngliche Geschäftslogik (Maschinencode), die zur Umwandlung (Compilierung oder Übersetzung) durch die Cloud-Toolkette bereitgestellt wurde); und, falls erforderlich, eine oder mehrere Sicherheitszusicherungen beinhalten.
Bei manchen Ausführungsformen beinhaltet die transitive Attestierung Messungen von jeder Phase der Cloud-Toolkette 520 oder ist damit assoziiert, wobei die Messungen in diesem Beispiel eine TL-1(Übersetzungslogik-1)-Messung, eine TL-2(Übersetzungslogik-2)-Messung und eine IL(Prüflogik)-Messung sind.
Auf diese Weise stellen die Messungen und Sicherheitszusicherungen Daten bereit, die genutzt werden können, um zu verifizieren, ob der für eine Betriebsvorrichtung empfangene Code von der ursprünglichen Geschäftslogik abgeleitet ist und dieser Code durch die Phasen der Toolkette generiert wurde.
6 ist ein Ablaufdiagramm zum Veranschaulichen eines Prozesses zum Attestieren einer Umwandlung oder Bewertung durch eine attestierbare Toolkette nach einigen Ausführungsformen. Bei einigen Ausführungsformen beinhaltet ein Prozess 600 Empfangen, wie etwa bei einem Cloud-Dienstanbieter oder einer anderen Drittpartei, von Geschäftslogik zum Verarbeiten einer sicheren Arbeitslast durch einen ausgewählten Rechenknoten 605, wobei die sichere Arbeitslast mit einem bestimmten Mandanten assoziiert ist.
Bei einigen Ausführungsformen wird eine attestierbare Toolkette zur Umwandlung der Geschäftslogik 610 identifiziert, und ein Rechenknoten wird aus mehreren verfügbaren Rechenknoten ausgewählt, um eine Berechnung für die Arbeitslast 615 bereitzustellen. Ein Prozess kann die Auswahl mehrerer Rechenknoten beinhalten, wobei die Toolkette eine separate Umwandlung der Geschäftslogik (oder von Teilen der Geschäftslogik) für jeden der mehreren Rechenknoten bereitstellen kann.
Bei manchen Ausführungsformen soll in einer Build-Phase eines Attestierungsprozesses 620 jede einer oder mehrerer Umwandlungsphasen Code empfangen, einen Code basierend auf dem empfangenen Code generieren und eine Messung oder Identität des empfangenen Codes, eine Messung oder Identität des generierten Codes und eine Attestierung der Umwandlungsphase 625 generieren. Bei manchen Ausführungsformen kann jede der einen oder mehreren Prüfungsphasen ferner wirken, um Code zu empfangen und zu prüfen und eine Messung oder Identität des empfangenen Codes und eine Attestierung der Prüfungsphase 630 zu generieren.
Bei manchen Ausführungsformen soll eine Endrecheneinheit (d. h. die Vorrichtung zum Ausführen von empfangenem Maschinencode) in einer Laufzeitphase des Attestierungsprozesses 635 Maschinencode empfangen und eine Attestierung der Recheneinheit und des empfangenen Codes 640 generieren.
Bei manchen Ausführungsformen soll jede der Attestierungen an einen Verifizierer für den Mandanten 645 gerichtet sein, wobei der Verifizierer ein Mandant oder ein Verifizierungsagent sein kann, der im Auftrag des Mandanten agiert. Auf diese Weise empfängt der Verifizierer eine Kette von Attestierungen, die zusammen demonstrieren, dass jede Attestierungsvorrichtung Logik ausführt, die aus der ursprünglichen Geschäftslogik abgeleitet wurde, und dass der resultierende Maschinencode durch die angegebenen Toolkettenelemente (die Elemente der Umwandlungsphase) erstellt wurde. Auf diese Weise kann eine Verifizierung generiert werden, die angibt, dass der resultierende Maschinencode für den Endrechenknoten aus der ursprünglichen Maschinenlogik abgeleitet ist, ohne dass der Mandant am Betrieb der Toolkette beteiligt sein muss.
Bei manchen Ausführungsformen, falls die Attestierungen zur Verifizierung ausreichen, kann der Prozess dann mit dem Empfangen sicherer Daten von dem Mandanten 650 und dem Durchführen der Berechnung der Arbeitslast unter Nutzung der empfangenen sicheren Daten 655 fortfahren.
7 veranschaulicht eine Ausführungsform einer beispielhaften Rechenarchitektur zur Attestierung von Operationen durch attestierbare Toolketten nach einigen Ausführungsformen. In verschiedenen Ausführungsformen, wie oben beschrieben, kann eine Rechenarchitektur 700 eine elektronische Vorrichtung umfassen oder als Teil einer solchen implementiert sein. In einigen Ausführungsformen kann die Rechenarchitektur 700 beispielsweise für ein Computersystem repräsentativ sein, das eine oder mehrere Komponenten der oben beschriebenen Betriebsumgebungen implementiert. Die Rechenarchitektur 700 kann genutzt werden, um eine Attestierung von Operationen durch Toolketten bereitzustellen, wie etwa in 1-6 beschrieben.
Wie in dieser Anmeldung verwendet, sollen die Begriffe „System“ und „Komponente“ und „Modul“ auf eine mit Computern verbundene Entität verweisen, entweder Hardware, eine Kombination von Hardware und Software, Software oder Software in Ausführung, wobei Beispiele davon durch die beispielhafte Rechenarchitektur 700 bereitgestellt werden. Zum Beispiel kann eine Komponente ein Prozess, der auf einem Prozessor läuft, ein Prozessor, ein Festplattenlaufwerk oder Festkörperlaufwerk (SSD), mehrere Speicherlaufwerke (eines optischen und/oder magnetischen Speichermediums), ein Objekt, ein ausführbares Programm, ein Ausführungsthread, ein Programm und/oder ein Computer sein. Zur Veranschaulichung können sowohl eine Anwendung, die auf einem Server läuft, als auch der Server eine Komponente sein. Eine oder mehrere Komponenten können innerhalb eines Prozesses und/oder Ausführungsthreads residieren und eine Komponente kann auf einem Computer lokalisiert sein und/oder zwischen zwei oder mehr Computern verteilt sein. Ferner können Komponenten kommunikativ durch verschiedene Arten von Kommunikationsmedien aneinander gekoppelt sein, um Vorgänge zu koordinieren. Die Koordination kann den Austausch von Informationen in einer oder in beiden Richtungen involvieren. Die Komponenten können beispielsweise Informationen in Form von Signalen kommunizieren, die über die Kommunikationsmedien kommuniziert werden. Die Informationen können als Signale implementiert sein, die verschiedenen Signalleitungen zugeordnet sind. In derartigen Zuordnungen ist jede Nachricht ein Signal. Weitere Ausführungsformen können j edoch alternativ Datennachrichten einsetzen. Derartige Datennachrichten können über verschiedene Verbindungen gesandt werden. Beispielhafte Verbindungen enthalten parallele Schnittstelle, serielle Schnittstellen und Bus-Schnittstellen.
Die Rechenarchitektur 700 enthält verschiedene übliche Rechenelemente, wie einen oder mehrere Prozessoren, Mehrkernprozessoren, Coprozessoren, Speichereinheiten, Chipsätze, Steuerungen, Peripheriegeräte, Schnittstellen, Oszillatoren, Zeitgebungseinrichtungen, Videokarten, Audiokarten, Multimedia-Eingabe/Ausgabe(E/A)-Komponenten, Energieversorgungen usw. Die Ausführungsformen sind jedoch nicht auf eine Implementierung durch die Rechenarchitektur 700 beschränkt.
Wie in 7 gezeigt, enthält die Rechenarchitektur 700 einen oder mehrere Prozessoren 702 und einen oder mehrere Grafikprozessoren 708 und kann ein Einzelprozessor-Desktopsystem, ein Mehrprozessor-Arbeitsplatzrechnersystem oder ein Serversystem mit einer großen Anzahl an Prozessoren 702 oder Prozessorkernen 707 sein. In einer Ausführungsform ist das System 700 eine Verarbeitungsplattform, die in einen integrierten Ein-Chip-System-Schaltkreis (SoC- oder SOC-Schaltkreis) zur Verwendung in mobilen, tragbaren oder eingebetteten Vorrichtungen eingebunden ist.
Eine Ausführungsform des Systems 700 kann eine serverbasierte Spieleplattform, eine Spielekonsole, einschließlich einer Spiele- und Medienkonsole, eine mobile Spielekonsole, eine tragbare Spielekonsole oder eine Online-Spielekonsole enthalten oder in eine solche eingebunden sein. In einigen Ausführungsformen ist das System 700 ein Mobiltelefon, ein Smartphone, eine Tabletrechenvorrichtung oder eine mobile Internetvorrichtung. Das Datenverarbeitungssystem 700 kann auch eine tragbare Vorrichtung, wie eine tragbare Smartwatch-Vorrichtung, eine smarte optische Vorrichtung, erweiterte Realitätsvorrichtung oder virtuelle Realitätsvorrichtung, enthalten, an eine solche koppeln oder in eine solche integriert sein. In einigen Ausführungsformen ist das Datenverarbeitungssystem 700 ein Fernseher oder eine Set-Top-Box-Vorrichtung mit einem oder mehreren Prozessoren 702 und einer grafischen Schnittstelle, die von einem oder mehreren Grafikprozessoren 708 generiert wird.
In einigen Ausführungsformen enthalten der eine oder die mehreren Prozessoren 702 jeweils einen oder mehrere Prozessorkerne 707, um Anweisungen zu verarbeiten, die bei Ausführung Operationen für System- und Benutzersoftware durchführen. In einigen Ausführungsformen ist jeder des einen oder der mehreren Prozessorkerne 707 ausgelegt, einen bestimmten Anweisungssatz 709 zu verarbeiten. In einigen Ausführungsformen kann der Anweisungssatz 709 ein Rechnen mit komplexem Anweisungssatz (CISC), ein Rechnen mit reduziertem Anweisungssatz (RISC) oder ein Rechnen über ein Very Long Instruction Word (VLIW) ermöglichen. Mehrere Prozessorkerne 707 können jeweils einen anderen Anweisungssatz 709 verarbeiten, der Anweisungen enthalten kann, um die Emulation anderer Anweisungssätze zu ermöglichen. Der Prozessorkern 707 kann auch andere Verarbeitungsvorrichtungen wie einen digitalen Signalprozessor (DSP) enthalten.
In einigen Ausführungsformen enthält der Prozessor 702 einen Zwischenspeicher 704. Abhängig von der Architektur kann der Prozessor 702 einen einzelnen internen Zwischenspeicher oder mehrere Ebenen von internen Zwischenspeichern aufweisen. In einigen Ausführungsformen wird der Zwischenspeicher 704 unter verschiedenen Komponenten des Prozessors 702 gemeinsam genutzt. In einigen Ausführungsformen verwendet der Prozessor 702 auch einen externen Zwischenspeicher (z. B. einen Level-3(L3)-Zwischenspeicher oder einen Last-Level-Zwischenspeicher (LLC)) (nicht gezeigt), der von den Prozessorkernen 707 unter Verwendung bekannter Zwischenspeicherkohärenztechniken gemeinsam genutzt werden kann. Eine Registerdatei 706 ist zusätzlich im Prozessor 702 enthalten, die unterschiedliche Arten von Registern zum Speichern unterschiedlicher Datentypen enthalten kann (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister). Einige Register können Universalregister sein, während andere Register für das Design des Prozessors 702 spezifisch sein können.
In einigen Ausführungsformen ist bzw. sind ein oder mehrere Prozessor(en) 702 an einen oder mehrere Schnittstellenbusse 710 gekoppelt, um Kommunikationssignale wie Adressen, Daten oder Steuersignale zwischen dem Prozessor 702 und anderen Komponenten im System zu übertragen. Der Schnittstellenbus 710 kann in einer Ausführungsform ein Prozessorbus sein, wie etwa eine Version eines Mediendirektschnittstellen(DMI)-Busses. Prozessorbusse sind jedoch nicht auf einen DMI-Bus beschränkt und können einen oder mehrere Peripheral-Component-Interconnect-Busse (z. B. PCI, PCI Express) Speicherbusse oder andere Arten von Schnittstellenbussen beinhalten. In einer Ausführungsform enthält bzw. enthalten der Prozessor bzw. die Prozessoren 702 eine integrierte Speichersteuerung 716 und einen Plattformsteuerungshub 730. Die Speichersteuerung 716 ermöglicht eine Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 700, während der Plattformsteuerungshub (PCH) 730 Verbindungen mit E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
Die Speichervorrichtung 720 kann eine dynamische Speichervorrichtung mit wahlfreiem Zugriff (DRAM-Vorrichtung), eine statische Speichervorrichtung mit wahlfreiem Zugriff (SRAM-Vorrichtung), eine Flashspeichervorrichtung, eine Phasenwechselspeichervorrichtung oder eine andere Speichervorrichtung mit geeigneter Leistung sein, um als ProzessSpeicher zu dienen. In einer Ausführungsform kann die Speichervorrichtung 720 als SystemSpeicher für das System 700 arbeiten, um Daten 722 und Anweisungen 721 zur Verwendung speichern, wenn der eine oder die mehreren Prozessoren 702 eine Anwendung oder einen Prozess ausführen. Der Speichersteuerungshub 716 koppelt auch an einen optionalen externen Grafikprozessor 712, der mit dem einen oder den mehreren Grafikprozessoren 708 in den Prozessoren 702 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen kann eine Anzeigevorrichtung 711 an den bzw. die Prozessor(en) 702 anbinden. Die Anzeigevorrichtung 711 kann eine oder mehrere von einer internen Anzeigevorrichtung, wie zum Beispiel in einer mobilen elektronischen Vorrichtung oder einer Laptopvorrichtung, oder eine externe Anzeigevorrichtung sein, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angebunden ist. In einer Ausführungsform kann die Anzeigevorrichtung 711 eine am Kopf montierte Anzeige (HMD) wie eine stereoskopische Anzeigevorrichtung zur Verwendung in Anwendungen mit virtueller Realität (VR) oder Anwendungen mit erweiterter Realität (AR) sein.
In einigen Ausführungsformen ermöglicht der PlattformsteuerungsHub 730 den Peripheriegeräten, sich über einen Hochgeschwindigkeits-E/A-Bus mit der Speichervorrichtung 720 und dem Prozessor 702 zu verbinden. Die E/A-Peripheriegeräte beinhalten, ohne darauf beschränkt zu sein, eine Audiosteuerung 746, eine Netzwerksteuerung 734, eine Firmware-Schnittstelle 728, einen drahtlosen Transceiver 726, Berührungssensoren 725, eine Datenspeichervorrichtung 724 (z. B. Festplatte, Flash-Speicher usw.). Die Datenspeichervorrichtung 724 kann über eine Speicherschnittstelle (z. B. SATA) oder über einen peripheren Bus, wie einen Peripheral-Component-Interconnect-Bus (z. B. PCI, PCI Express) verbunden sein. Die Berührungssensoren 725 können Berührungsbildschirmsensoren, Drucksensoren oder Fingerabdrucksensoren enthalten. Der drahtlose Sende-Empfänger 726 kann ein WiFi-Sende-Empfänger, ein Bluetooth-Sende-Empfänger oder ein Sende-Empfänger für mobile Netzwerke sein, wie ein 3G-, 4G-, Long-Term-Evolution(LTE)- oder 5G-Sende-Empfänger. Die Firmwareschnittstelle 728 ermöglicht eine Kommunikation mit Systemfirmware und kann beispielsweise eine Unified Extensible Firmware Interface (UEFI) sein. Die Netzwerksteuerung 734 kann eine Netzwerkverbindung mit einem verdrahteten Netzwerk ermöglichen. In einigen Ausführungsformen koppelt eine Hochleistungsnetzwerksteuerung (nicht gezeigt) an den Schnittstellenbus 710. Die Audiosteuerung 746 ist in einer Ausführungsform eine hochauflösende Mehrkanal-Audiosteuerung. In einer Ausführungsform enthält das System 700 eine optionale Vorgänger-E/A-Steuerung 740, um Vorgänger-Vorrichtungen (z. B. Personal System 2 (PS/2) an das System zu koppeln. Der Plattformsteuerungshub 730 kann auch an eine oder mehrere Universal-Serial-Bus(USB)-Steuerungen 742 anbinden, um Eingabevorrichtungen wie Tastatur- und Mauskombinationen 743, eine Kamera 744 oder andere USB-Eingabevorrichtungen anzubinden.
8A und 8B veranschaulichen ein Signaturschema auf Einmalhashbasis bzw. ein Signaturschema auf Mehrfachhashbasis. Die in 8A und 8B veranschaulichten Operationen können nach Bedarf beim Bereitstellen von Sicherheit zur Unterstützung der Attestierung von Operationen durch Toolketten genutzt werden. Hash-basierte Kryptographie beruht auf kryptografischen Systemen, wie etwa Lamport-Signaturen, Merkle-Signaturen, einem erweiterten Merkle-Signaturschema (XMSS), einem SPHINCS-Schema, einem SPHINCS+-Schema usw. Mit der Einführung von Quantenrechnen und in Erwartung dessen Wachstums gab es Bedenken über verschiedene Herausforderungen, die das Quantenrechnen stellen könnte, und welche Maßnahmen getroffen werden könnten, um derartigen Herausforderungen unter Verwendung des Gebiets der Kryptographie entgegenzuwirken.
Ein Bereich, der untersucht wird, um Herausforderungen beim Quantenrechnen entgegenzuwirken, sind Hash-basierte Signaturen (HBS), da es diese Schemata schon seit langem gibt und diese die notwendigen Basisbestandteile aufweisen, wie etwa das Aufbauen auf symmetrischen Kryptographiebausteinen (z. B. Hash-Funktionen), um den Herausforderungen beim Quantenzählen und nach dem Quantenrechnen entgegenzuwirken. HBS-Schemata werden als schnelle Signaturalgorithmen betrachtet, die mit schnellem plattformgesichertem Booten arbeiten, was als am beständigsten gegenüber Quantenangriffen angesehen wird.
Wie zum Beispiel mit Bezug auf 8A veranschaulicht, ist ein Schema von HBS gezeigt, das Merkle-Bäume zusammen mit dem Einmalsignatur(OTS)-Schema 800 verwendet, wie etwa Verwenden eines privaten Schlüssels zum Signieren einer Nachricht und eines entsprechenden öffentlichen Schlüssels zum Verifizieren der OTS-Nachricht, wobei ein privater Schlüssel nur eine einzige Nachricht signiert.
Ähnlich, wie mit Bezug auf 8B veranschaulicht, ist ein anderes HBS-Schema gezeigt, wobei sich dieses auf ein Mehrfachsignatur(MTS)-Schema 850 bezieht, bei dem ein privater Schlüssel mehrere Nachrichten signieren kann.
9A und 9B veranschaulichen ein Einmalsignaturschema bzw. ein Mehrfachsignaturschema. Fortfahrend mit dem HBS-basierten OTS-Schema 800 von 8A und dem MTS-Schema 850 von 8B veranschaulicht 9A das Winternitz-OTS(WOTS)-Schema 900, das von Robert Winternitz vom Stanford-Mathematik-Institut vorgeschlagen wurde, während 9B das XMSS-MTS-Schema 950 veranschaulicht.
Beispielsweise stellt das WOTS-Schema 900 von 9A Hashing und Parsen von Nachrichten in M bereit, mit 67 ganzen Zahlen zwischen [0, 1, 2, ... , 15], wie etwa privater Schlüssel, sk, 905, Signatur, s, 910 und öffentlicher Schlüssel, pk, 915, wobei jedes Element 67 Komponenten mit jeweils 32 Bytes aufweist.
Nun veranschaulicht zum Beispiel 9B das XMSS-MTS-Schema 950, das eine Kombination des WOTS-Schemas 900 von 9A und des XMSS-Schemas 955 mit dem XMSS-Merkle-Baum 970 ermöglicht. Wie zuvor in Bezug auf 9A besprochen, basiert das WOTS-Schema 900 auf einem einmaligen öffentlichen Schlüssel, pk, 915, mit 67 Komponenten von jeweils 32 Bytes, der dann durch den L-Baum-Komprimierungsalgorithmus 960 gesetzt wird, um dem WOTS-komprimierten pk 967 zu ermöglichen, einen Platz im XMSS-Merkle-Baum 970 des XMSS-Schemas 955 einzunehmen. Es wird in Betracht gezogen, dass die XMSS-Signaturverifizierung ein Berechnen einer WOTS-Verifizierung und Prüfen beinhalten kann, um zu ermitteln, ob ein rekonstruierter Wurzelknoten mit dem öffentlichen XMSS-Schlüssel übereinstimmt, wie etwa Wurzelknoten = öffentlicher XMSS-Schlüssel.
Die hierin beschriebenen maschinenlesbaren Anweisungen können in einem oder mehreren eines komprimierten Formats, eines verschlüsselten Formats, eines fragmentierten Formats, eines compilierten Formats, eines ausführbaren Formats, eines paketierten Formats usw. gespeichert sein. Maschinenlesbare Anweisungen, wie sie hierin beschrieben sind, können als Daten (z. B. Abschnitte von Anweisungen, Code, Darstellungen von Code usw.) gespeichert sein, die eingesetzt werden können, um maschinenlesbare Anweisungen zu erstellen, herzustellen und/oder zu erzeugen. Die maschinenlesbaren Anweisungen können beispielsweise fragmentiert und auf einer oder mehreren Speichereinrichtungen und/oder Recheneinrichtungen (z. B. Servern) gespeichert werden. Die maschinenlesbaren Anweisungen können eines oder mehrere von Installation, Modifikation, Adaptierung, Aktualisierung, Kombinierung, Ergänzung, Konfigurierung, Entschlüsselung, Dekomprimierung, Entpackung, Verteilung, Neuzuordnung, Compilierung usw. nutzen, um sie direkt durch eine Rechenvorrichtung und/oder eine andere Maschine lesbar, interpretierbar und/oder ausführbar zu machen. Die maschinenlesbaren Anweisungen können beispielsweise in mehreren Teilen gespeichert sein, die individuell komprimiert, verschlüsselt und auf separaten Recheneinrichtungen gespeichert sind, wobei die Teile, wenn sie entschlüsselt, entkomprimiert und kombiniert werden, einen Satz von ausführbaren Anweisungen bilden, die ein Programm wie das hierin beschriebene implementieren.
In einem anderen Beispiel können die maschinenlesbaren Anweisungen in einem Zustand gespeichert sein, in dem sie von einem Computer gelesen werden können, aber eine Hinzufügung einer Bibliothek (z. B. einer Dynamic Link Library (DLL)), eines Software-Entwicklungskits (SDK), einer Anwendungsprogrammierschnittstelle (API) usw. nutzen, um die Anweisungen auf einer bestimmten Rechenvorrichtung oder anderen Vorrichtung auszuführen. In einem anderen Beispiel können die maschinenlesbaren Anweisungen konfiguriert (z. B. Einstellungen gespeichert, Daten eingegeben, Netzwerkadressen aufgezeichnet usw.) sein, bevor die maschinenlesbaren Anweisungen und/oder das bzw. die entsprechende(n) Programm(e) gänzlich oder teilweise ausgeführt werden können. Deshalb sollen die offenbarten maschinenlesbaren Anweisungen und/oder das bzw. die entsprechende(n) Programm(e) derartige maschinenlesbare Anweisungen und/oder Programme umfassen, unabhängig vom bestimmten Format oder Zustand der maschinenlesbaren Anweisungen und/oder des/der maschinenlesbaren Programms/Programme, wenn sie gespeichert sind oder sich anderweitig in Ruhe oder in Übertragung befinden.
Die hierin beschriebenen maschinenlesbaren Anweisungen können durch eine beliebige vergangene, aktuelle oder zukünftige Anweisungssprache, Skriptsprache, Programmiersprache usw. repräsentiert sein. Beispielsweise können die maschinenlesbaren Anweisungen unter Verwendung beliebiger der folgenden Sprachen repräsentiert sein: C, C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift usw.
Wie oben erwähnt, können die beispielhaften Prozesse von 9A und 9B unter Verwendung von ausführbaren Anweisungen (z. B. computer- und/oder maschinenlesbaren Anweisungen) implementiert werden, die auf einem nichtflüchtigen computer- und/oder maschinenlesbaren Medium wie einem Festplattenlaufwerk, einem Flashspeicher, einem Nur-Lese-Speicher, einer Compact Disk, einer Digital Versatile Disk, einem Zwischenspeicher, einem Direktzugriffsspeicher und/oder einer beliebigen anderen Speichervorrichtung oder Speicherplatte gespeichert sind, auf der Informationen für eine beliebige Dauer gespeichert sind (z. B. für längere Zeiträume, dauerhaft, für kurze Augenblicke, zum temporären Puffern und/oder zum Zwischenspeichern der Informationen). Wie hierin verwendet, ist der Begriff nichtflüchtiges computerlesbares Medium ausdrücklich definiert, alle Typen von computerlesbarer Speichervorrichtung und/oder Speicherplatte zu enthalten und sich ausbreitende Signale auszuschließen und Sendemedien auszuschließen.
„Enthaltend“ und „umfassend“ (und alle Formen und Zeitformen davon) werden hier als offene Begriffe verwendet. Immer wenn daher ein Anspruch irgendeine Form von „enthalten“ oder „umfassen“ (z. B. umfasst, enthält, umfassend, einschließlich, aufweisend usw.) als eine Präambel oder innerhalb einer Anspruchsangabe irgendeiner Art, versteht sich, dass zusätzliche Elemente, Ausdrücke usw. vorhanden sein können, ohne außerhalb des Geltungsbereichs des entsprechenden Anspruchs oder der entsprechenden Aufzählung zu fallen. Wenn der Begriff „mindestens“, wie hierin verwendet, als Übergangsbegriff zum Beispiel in einem Oberbegriff eines Anspruchs verwendet wird, ist er in der gleichen Weise offen, wie die Begriffe „umfassend“ und „enthaltend“ offen sind.
Der Ausdruck „und/oder“, wenn er beispielsweise in einer Form wie A, B und/oder C verwendet wird, bezeichnet eine beliebige Kombination oder Teilmenge von A, B, C, wie beispielsweise (1) nur A, (2) nur B, (3) nur C, (4) A mit B, (5) A mit C, (6) B mit C und (7) A mit B und mit C. Wie hierin im Kontext zum Beschreiben von Strukturen, Komponenten, Elementen, Objekten und/oder Dingen verwendet, soll die Phrase „mindestens eines von A und B“ auf Implementierungen verweisen, die beliebige von (1) mindestens ein A, (2) mindestens ein B und (3) mindestens ein A und mindestens ein B enthalten. Gleichermaßen, wie hierin im Kontext zum Beschreiben von Strukturen, Komponenten, Elementen, Objekten und/oder Dingen verwendet, soll die Phrase „mindestens eines von A oder B“ auf Implementierungen verweisen, die beliebige von (1) mindestens ein A, (2) mindestens ein B und (3) mindestens ein A und mindestens ein B enthalten. Wie hierin im Kontext zum Beschreiben der Durchführung oder Ausführung von Prozessen, Anweisungen, Handlungen, Aktivitäten und/oder Schritten verwendet, soll die Phrase „mindestens eines von A und B“ auf Implementierungen verweisen, die beliebige von (1) mindestens ein A, (2) mindestens ein B und (3) mindestens ein A und mindestens ein B enthalten. Gleichermaßen, wie hierin im Kontext zum Beschreiben der Durchführung oder Ausführung von Prozessen, Anweisungen, Handlungen, Aktivitäten und/oder Schritten verwendet, soll die Phrase „mindestens eines von A oder B“ auf Implementierungen verweisen, die beliebige von (1) mindestens ein A, (2) mindestens ein B und (3) mindestens ein A und mindestens ein B enthalten.
Wie hierin verwendet schließen Bezugnahmen in der Einzahl (z. B. „ein“, „eine“, „eines“, „erstes“, „zweites“ usw.) eine Vielzahl nicht aus. Der Ausdruck „ein“ oder „eine“ Entität, wie er hierin verwendet wird, bezeichnet eine oder mehrere dieser Entität. Die Ausdrücke „ein/eine“ (oder „eines“), „ein oder mehrere“ und „mindestens ein“ können hierin austauschbar verwendet werden. Obwohl sie individuell aufgeführt sind, kann ferner eine Vielzahl von Mitteln, Elementen oder Verfahrenshandlungen z. B. von einer einzigen Einheit oder einem einzigen Prozessor implementiert sein. Darüber hinaus, obwohl individuelle Merkmale in unterschiedlichen Beispielen oder Ansprüchen enthalten sein können, können diese möglicherweise kombiniert werden und die Aufnahme in verschiedene Beispiele oder Ansprüche bedeutet nicht, dass eine Kombination von Merkmalen nicht möglich und/oder vorteilhaft ist.
Deskriptoren „erstes“, „zweites“, „drittes“ usw. werden hierin beim Identifizieren mehrerer Elemente oder Komponenten verwenden, auf die separat Bezug genommen werden kann. Falls nicht anders angegeben oder auf Grundlage ihres Verwendungskontexts verstanden wird, sollen derartige Deskriptoren keine Bedeutung von Priorität, physischer Reihenfolge oder Anordnung in einer Liste oder zeitlicher Reihenfolge unterstellen, sondern werden lediglich als Bezeichnungen verwendet, um auf mehrere Elemente oder Komponenten separat zu verweisen, um die offengelegten Beispiele leichter verständlich zu machen. In einigen Beispielen kann der Deskriptor „erstes“ verwendet werden, um auf ein Element in der ausführlichen Beschreibung zu verweisen, während auf dasselbe Element in einem Anspruch mit einem unterschiedlichen Deskriptor, wie „zweites“ oder „drittes“, verwiesen wird. In derartigen Fällen sollte klar sein, dass derartige Deskriptoren nur zur einfacheren Bezugnahme auf mehrere Elemente oder Komponenten verwendet werden.
Die folgenden Beispiele betreffen weitere Ausführungsformen.
In Beispiel 1 beinhaltet ein Speicherungsmedium Anweisungen zum Empfangen von Quellcode zum Verarbeiten einer sicheren Arbeitslast eines Mandanten; Auswählen mindestens eines ersten Rechenknotens von einer Vielzahl von Rechenknoten zum Bereitstellen einer Berechnung für die Arbeitslast; Verarbeiten des Quellcodes durch eine attestierbare Toolkette, um Maschinencode für den ersten Rechenknoten zu generieren, einschließlich, in einer ersten Phase, Durchführen einer oder mehrerer Umwandlungen des Quellcodes durch einen oder mehrere Umwandler, um umgewandelten Code zu generieren, und Generieren einer Attestierung, die mit jeder Codeumwandlung assoziiert ist, und in einer zweiten Phase, Empfangen von Maschinencode für den ersten Rechenknoten und Generieren einer Attestierung, die mit dem ersten Rechenknoten assoziiert ist; und Bereitstellen jeder der Attestierungen aus der ersten Phase und aus der zweiten Phase zur Verifizierung.
In Beispiel 2 ist die erste Phase eine Build-Phase und die zweite Phase ist eine Laufzeitphase für die Verarbeitung des Quellcodes.
In Beispiel 3 repräsentieren die Attestierungen aus der ersten Phase und aus der zweiten Phase eine Kette von Attestierungen zwischen dem empfangenen Quellcode und dem generierten Maschinencode für den ersten Rechenknoten.
In Beispiel 4 beinhaltet jede Attestierung der ersten Phase wenigstens eine Messung oder Identität von empfangenem Code, eine Messung oder Identität von umgewandeltem Code und eine Attestierung eines Umwandlers, der den empfangenen Code in den umgewandelten Code umgewandelt hat.
In Beispiel 5 beinhaltet wenigstens eine erste Attestierung der ersten Phase ferner eine oder mehrere Sicherheitszusicherungen.
In Beispiel 6 beinhaltet die erste Phase ferner Durchführen einer oder mehrerer Prüfungen des Quellcodes und Generieren einer Attestierung, die mit jeder Codeprüfung assoziiert ist.
In Beispiel 7 beinhaltet die Attestierung der zweiten Phase mindestens eine Attestierung von empfangenem Maschinencode und eine Attestierung des ersten Rechenknotens.
In Beispiel 8 beinhaltet das Speicherungsmedium ferner Anweisungen zum Empfangen sicherer Daten als Reaktion auf die Attestierungen der ersten Phase und aus der zweiten Phase zur Verifizierung; und Durchführen einer Berechnung der sicheren Arbeitslast unter Nutzung der empfangenen sicheren Daten.
In Beispiel 9 beinhaltet ein System einen oder mehrere Prozessoren zum Verarbeiten von Daten; einen Speicher zum Speichern von Daten; und eine Vielzahl von Recheneinheiten zum Bereitstellen einer Berechnung für unterstützte Arbeitslasten, wobei das System Quellcode zum Verarbeiten einer sicheren Arbeitslast eines Mandanten zu empfangen hat; mindestens einen ersten Rechenknoten der Vielzahl von Rechenknoten zum Bereitstellen einer Berechnung für die Arbeitslast auszuwählen hat; den Quellcode durch eine mit dem Mandanten assoziierte attestierbare Toolkette zu verarbeiten, um Maschinencode für den ersten Rechenknoten zu generieren, einschließlich, in einer ersten Phase, eine oder mehrere Umwandlungen des Quellcodes durch einen oder mehrere Umwandler durchzuführen hat, um umgewandelten Code zu generieren, und Generieren einer Attestierung, die mit jeder Codeumwandlung assoziiert ist, und in einer zweiten Phase, Maschinencode für den ersten Rechenknoten zu empfangen und eine Attestierung zu generieren hat, die mit dem ersten Rechenknoten assoziiert ist; und jede der Attestierungen aus der ersten Phase und aus der zweiten Phase zur Verifizierung bereitzustellen hat.
In Beispiel 10 beinhaltet die Vielzahl von Rechenknoten eine oder mehrere Verarbeitungsvorrichtungen, einen oder mehrere Hardwarebeschleuniger oder beides.
In Beispiel 11 ist die erste Phase eine Build-Phase und die zweite Phase ist eine Laufzeitphase für die Verarbeitung des Quellcodes.
In Beispiel 12 repräsentieren die Attestierungen aus der ersten Phase und aus der zweiten Phase eine Kette von Attestierungen zwischen dem empfangenen Quellcode und dem generierten Maschinencode für den ersten Rechenknoten.
In Beispiel 13 beinhaltet jede Attestierung der ersten Phase wenigstens eine Messung oder Identität von empfangenem Code, eine Messung oder Identität von umgewandeltem Code und eine Attestierung eines Umwandlers, der den empfangenen Code in den umgewandelten Code umgewandelt hat.
In Beispiel 14 beinhaltet wenigstens eine erste Attestierung der ersten Phase ferner eine oder mehrere Sicherheitszusicherungen.
In Beispiel 15 beinhaltet die erste Phase ferner Durchführen einer oder mehrerer Prüfungen des Quellcodes und Generieren einer Attestierung, die mit jeder Codeprüfung assoziiert ist.
In Beispiel 16 beinhaltet die Attestierung der zweiten Phase mindestens eine Attestierung von empfangenem Maschinencode und eine Attestierung des ersten Rechenknotens.
In Beispiel 17 beinhaltet eine Einrichtung einen oder mehrere Prozessoren zum Verarbeiten von Code; und eine Speicherung zum Speichern von Computeranweisungen, wobei die Computeranweisungen Anweisungen zum Empfangen von Geschäftslogik zum Verarbeiten einer sicheren Arbeitslast eines Mandanten beinhalten, wobei die Einrichtung eine attestierbare Toolkette beinhaltet, die mit dem Mandanten assoziiert ist; Auswählen eines oder mehrerer Rechenknoten von einer Vielzahl von Rechenknoten zum Bereitstellen einer Berechnung für die Arbeitslast; Verarbeiten der Geschäftslogik durch die Toolkette, um Maschinencode für den einen oder die mehreren Rechenknoten zu generieren, einschließlich, in einer Build-Phase, Durchführen einer oder mehrerer Umwandlungen der Geschäftslogik durch einen oder mehrere Umwandler, um umgewandelten Code zu generieren, und Generieren einer Attestierung, die mit jeder Codeumwandlung assoziiert ist, und in einer Laufzeitphase, Empfangen von Maschinencode für den einen oder die mehreren Rechenknoten und Generieren einer Attestierung, die mit jedem von dem einen oder den mehreren Rechenknoten assoziiert ist; Bereitstellen jeder der Attestierungen aus der Build-Phase und aus der Laufzeitphase zur Verifizierung; und Durchführen einer Berechnung der sicheren Arbeitslast unter Nutzung des einen oder der mehreren Rechenknoten.
In Beispiel 18 repräsentieren die Attestierungen aus der Build-Phase und aus der Laufzeitphase eine Kette von Attestierungen zwischen der empfangenen Geschäftslogik und dem generierten Maschinencode für den einen oder die mehreren Rechenknoten.
In Beispiel 19 beinhaltet jede Attestierung der Build-Phase wenigstens eine Messung oder Identität von empfangenem Code, eine Messung oder Identität von umgewandeltem Code und eine Attestierung eines Umwandlers, der den empfangenen Code in den umgewandelten Code umgewandelt hat.
In Beispiel 20 beinhaltet die Attestierung der Laufzeitphase mindestens eine Attestierung von empfangenem Maschinencode und eine Attestierung eines des einen oder der mehreren Rechenknoten.
In Beispiel 21 beinhaltet eine Einrichtung Mittel zum Empfangen von Quellcode zum Verarbeiten einer sicheren Arbeitslast eines Mandanten; Mittel zum Auswählen mindestens eines ersten Rechenknotens von einer Vielzahl von Rechenknoten zum Bereitstellen einer Berechnung für die Arbeitslast; Mittel zum Verarbeiten des Quellcodes durch eine attestierbare Toolkette, um Maschinencode für den ersten Rechenknoten zu generieren, einschließlich, in einer ersten Phase, Mittel zum Durchführen einer oder mehrerer Umwandlungen des Quellcodes durch einen oder mehrere Umwandler, um umgewandelten Code zu generieren, und Mittel zum Generieren einer Attestierung, die mit jeder Codeumwandlung assoziiert ist, und in einer zweiten Phase, Mittel zum Empfangen von Maschinencode für den ersten Rechenknoten und Generieren einer Attestierung, die mit dem ersten Rechenknoten assoziiert ist; und Mittel zum Bereitstellen jeder der Attestierungen aus der ersten Phase und aus der zweiten Phase zur Verifizierung.
In Beispiel 22 ist die erste Phase eine Build-Phase und die zweite Phase ist eine Laufzeitphase für die Verarbeitung des Quellcodes.
In Beispiel 23 repräsentieren die Attestierungen aus der ersten Phase und aus der zweiten Phase eine Kette von Attestierungen zwischen dem empfangenen Quellcode und dem generierten Maschinencode für den ersten Rechenknoten.
In Beispiel 24 beinhaltet jede Attestierung der ersten Phase wenigstens eine Messung oder Identität von empfangenem Code, eine Messung oder Identität von umgewandeltem Code und eine Attestierung eines Umwandlers, der den empfangenen Code in den umgewandelten Code umgewandelt hat.
In Beispiel 25 beinhaltet wenigstens eine erste Attestierung der ersten Phase ferner eine oder mehrere Sicherheitszusicherungen.
In Beispiel 26 beinhaltet die erste Phase ferner Durchführen einer oder mehrerer Prüfungen des Quellcodes und Generieren einer Attestierung, die mit jeder Codeprüfung assoziiert ist.
In Beispiel 27 beinhaltet die Attestierung der zweiten Phase mindestens eine Attestierung von empfangenem Maschinencode und eine Attestierung des ersten Rechenknotens.
In Beispiel 28 beinhaltet die Einrichtung ferner Mittel zum Empfangen sicherer Daten als Reaktion auf die Attestierungen der ersten Phase und aus der zweiten Phase zur Verifizierung; und Mittel zum Durchführen einer Berechnung der sicheren Arbeitslast unter Nutzung der empfangenen sicheren Daten.
Einzelheiten in den Beispielen können überall in einer oder mehreren Ausführungsformen verwendet werden.
Die vorstehende Beschreibung und die vorstehenden Zeichnungen sollen in einem veranschaulichenden Sinn statt in einem einschränkenden Sinn betrachtet werden. Fachleuten ist klar, dass verschiedene Modifikationen und Änderungen an den hierin beschriebenen Ausführungsformen vorgenommen werden können, ohne vom allgemeinen Gedanken und Umfang der Merkmale abzuweichen, die in den beigefügten Ansprüchen dargelegt sind.

Claims

Nicht-transitorisches computerlesbares Speicherungsmedium oder mehrere nichttransitorische computerlesbare Speicherungsmedien mit darauf gespeicherten ausführbaren Computerprogrammanweisungen, die bewirken, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, dass der eine oder die mehreren Prozessoren Operationen durchführen, umfassend: Empfangen von Quellcode zum Verarbeiten einer sicheren Arbeitslast eines Mandanten; Auswählen mindestens eines ersten Rechenknotens von einer Vielzahl von Rechenknoten zum Bereitstellen einer Berechnung für die Arbeitslast; Verarbeiten des Quellcodes durch eine attestierbare Toolkette, um Maschinencode für den ersten Rechenknoten zu generieren, einschließlich: in einer ersten Phase, Durchführen einer oder mehrerer Umwandlungen des Quellcodes durch einen oder mehrere Umwandler, um umgewandelten Code zu generieren, und Generieren einer Attestierung, die mit jeder Codeumwandlung assoziiert ist, und in einer zweiten Phase, Empfangen von Maschinencode für den ersten Rechenknoten und Generieren einer Attestierung, die mit dem ersten Rechenknoten assoziiert ist; und Bereitstellen jeder der Attestierungen aus der ersten Phase und aus der zweiten Phase zur Verifizierung.
Speicherungsmedium oder mehrere Speicherungsmedien nach Anspruch 1, wobei die erste Phase eine Build-Phase ist und die zweite Phase eine Laufzeitphase für die Verarbeitung des Quellcodes ist.
Speicherungsmedium oder mehrere Speicherungsmedien nach Anspruch 1 oder 2, wobei die Attestierungen aus der ersten Phase und aus der zweiten Phase eine Kette von Attestierungen zwischen dem empfangenen Quellcode und dem generierten Maschinencode für den ersten Rechenknoten repräsentieren.
Speicherungsmedium oder mehrere Speicherungsmedien nach einem der Ansprüche 1 bis 3, wobei jede Attestierung der ersten Phase wenigstens eine Messung oder Identität von empfangenem Code, eine Messung oder Identität von umgewandeltem Code und eine Attestierung eines Umwandlers, der den empfangenen Code in den umgewandelten Code umgewandelt hat, beinhaltet.
Speicherungsmedium oder mehrere Speicherungsmedien nach einem der Ansprüche 1 bis 4, wobei wenigstens eine erste Attestierung der ersten Phase ferner eine oder mehrere Sicherheitszusicherungen beinhaltet.
Speicherungsmedium oder mehrere Speicherungsmedien nach Anspruch 4, wobei die erste Phase ferner Durchführen einer oder mehrerer Prüfungen des Quellcodes und Generieren einer Attestierung beinhaltet, die mit jeder Codeprüfung assoziiert ist.
Speicherungsmedium oder mehrere Speicherungsmedien nach einem der Ansprüche 1 bis 6, wobei die Attestierung der zweiten Phase mindestens eine Attestierung von empfangenem Maschinencode und eine Attestierung des ersten Rechenknotens beinhaltet.
Speicherungsmedium oder mehrere Speicherungsmedien nach einem der Ansprüche 1 bis 7, ferner umfassend ausführbare Computerprogrammanweisungen, die bewirken, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, dass der eine oder die mehreren Prozessoren Operationen durchführen, die eines von Folgendem umfassen: Empfangen sicherer Daten als Reaktion auf die Attestierungen der ersten Phase und der zweiten Phase zur Verifizierung; und Durchführen einer Berechnung der sicheren Arbeitslast unter Nutzung der empfangenen sicheren Daten.
System, umfassend: einen oder mehrere Prozessoren zum Verarbeiten von Daten; einen Speicher zum Speichern von Daten; und eine Vielzahl von Recheneinheiten zum Bereitstellen einer Berechnung für unterstützte Arbeitslasten, wobei das System ausgelegt ist: Quellcode zum Verarbeiten einer sicheren Arbeitslast eines Mandanten zu empfangen; mindestens einen ersten Rechenknoten der Vielzahl von Rechenknoten zum Bereitstellen einer Berechnung für die Arbeitslast auszuwählen; den Quellcode durch eine mit dem Mandanten assoziierte attestierbare Toolkette zu verarbeiten, um Maschinencode für den ersten Rechenknoten zu generieren, einschließlich: in einer ersten Phase, eine oder mehrere Umwandlungen des Quellcodes durch einen oder mehrere Umwandler durchzuführen, um umgewandelten Code zu generieren, und Generieren einer Attestierung, die mit jeder Codeumwandlung assoziiert ist, und in einer zweiten Phase, Maschinencode für den ersten Rechenknoten zu empfangen und eine Attestierung zu generieren, die mit dem ersten Rechenknoten assoziiert ist; und jede der Attestierungen aus der ersten Phase und aus der zweiten Phase zur Verifizierung bereitzustellen.
System nach Anspruch 9, wobei die Vielzahl von Rechenknoten eine oder mehrere Verarbeitungsvorrichtungen, einen oder mehrere Hardwarebeschleuniger oder beides beinhaltet.
System nach Anspruch 9 oder 10, wobei die erste Phase eine Build-Phase ist und die zweite Phase eine Laufzeitphase für die Verarbeitung des Quellcodes ist.
System nach einem der Ansprüche 9 bis 11, wobei die Attestierungen aus der ersten Phase und aus der zweiten Phase eine Kette von Attestierungen zwischen dem empfangenen Quellcode und dem generierten Maschinencode für den ersten Rechenknoten repräsentieren.
System nach einem der Ansprüche 9 bis 12, wobei jede Attestierung der ersten Phase wenigstens eine Messung oder Identität von empfangenem Code, eine Messung oder Identität von umgewandeltem Code und eine Attestierung eines Umwandlers, der den empfangenen Code in den umgewandelten Code umgewandelt hat, beinhaltet.
System nach Anspruch 13, wobei wenigstens eine erste Attestierung der ersten Phase ferner eine oder mehrere Sicherheitszusicherungen beinhaltet.
System nach Anspruch 13 oder 14, wobei die erste Phase ferner Durchführen einer oder mehrerer Prüfungen des Quellcodes und Generieren einer Attestierung beinhaltet, die mit jeder Codeprüfung assoziiert ist.
System nach einem der Ansprüche 9 bis 15, wobei die Attestierung der zweiten Phase mindestens eine Attestierung von empfangenem Maschinencode und eine Attestierung des ersten Rechenknotens beinhaltet.
Einrichtung, umfassend: einen oder mehrere Prozessoren zum Verarbeiten von Code; und einen Speicher zum Speichern von Computeranweisungen, wobei die Computeranweisungen Anweisungen beinhalten zum: Empfangen von Geschäftslogik zum Verarbeiten einer sicheren Arbeitslast eines Mandanten, wobei die Einrichtung eine mit dem Mandanten assoziierte attestierbare Toolkette beinhaltet; Auswählen eines oder mehrerer Rechenknoten von einer Vielzahl von Rechenknoten zum Bereitstellen einer Berechnung für die Arbeitslast; Verarbeiten der Geschäftslogik durch die Toolkette, um Maschinencode für den einen oder die mehreren Rechenknoten zu generieren, einschließlich: in einer Build-Phase, Durchführen einer oder mehrerer Umwandlungen der Geschäftslogik durch einen oder mehrere Umwandler, um umgewandelten Code zu generieren, und Generieren einer Attestierung, die mit jeder Codeumwandlung assoziiert ist, und in einer Laufzeitphase, Empfangen von Maschinencode für den einen oder die mehreren Rechenknoten und Generieren einer Attestierung, die mit jedem von dem einen oder den mehreren Rechenknoten assoziiert ist; Bereitstellen jeder der Attestierungen aus der Build-Phase und aus der Laufzeitphase zur Verifizierung; und Durchführen einer Berechnung der sicheren Arbeitslast unter Nutzung des einen oder der mehreren Rechenknoten.
Einrichtung nach Anspruch 17, wobei die Attestierungen aus der Build-Phase und aus der Laufzeitphase eine Kette von Attestierungen zwischen der empfangenen Geschäftslogik und dem generierten Maschinencode für den einen oder die mehreren Rechenknoten repräsentieren.
Einrichtung nach Anspruch 17 oder 18, wobei jede Attestierung der Build-Phase wenigstens eine Messung oder Identität von empfangenem Code, eine Messung oder Identität von umgewandeltem Code und eine Attestierung eines Umwandlers, der den empfangenen Code in den umgewandelten Code umgewandelt hat, beinhaltet.
Einrichtung nach einem der Ansprüche 17 bis 19, wobei jede Attestierung der Laufzeitphase mindestens eine Attestierung von empfangenem Maschinencode und eine Attestierung von einem des einen oder der mehreren Rechenknoten beinhaltet.