DE102023116901A1

DE102023116901A1 - Zertifikatlose Authentifizierung von ausführbaren Programmen

Info

Publication number: DE102023116901A1
Application number: DE102023116901.7A
Authority: DE
Inventors: Bhalchandra Phad; Harshad B Chandak; Ashwani Mattoo; Christopher S. York; Randall L. Wolf
Original assignee: Cummins Inc
Current assignee: Cummins Inc
Priority date: 2022-06-30
Filing date: 2023-06-27
Publication date: 2024-01-04
Also published as: US20240004986A1; CN117335991A

Abstract

Ein Prozess stellt zertifikatlose sichere Authentifizierung eines ausführbaren Programms bereit. Der Prozess beinhaltet Starten eines ausführbaren Programms, wobei das ausführbare Programm eine sichere Programmkomponente beinhaltet, als Reaktion auf einen Post-Launch-Authentifizierungsauslöser, Berechnen, unter Verwendung der sicheren Komponente, eines kryptografischen Hash-Funktions(CHF-)Digests von zumindest einem Teil des ausführbaren Programms, Zugreifen, unter Verwendung der sicheren Komponente, auf einen zuvor berechneten CHF-Digest von zumindest dem Teil des ausführbaren Programms, der in einer White-Box-Datenstruktur des ausführbaren Programms enthalten ist, Vergleichen, unter Verwendung der sicheren Komponente, des CHF-Digest und des zuvor berechneten CHF-Digest, und als Reaktion auf das Vergleichen, das Gleichheit des CHF-Digest und des zuvor berechneten CHF-Digest angibt, Autorisieren eines Vorgangs des ausführbaren Programms.

Description

TECHNISCHES GEBIET
Die vorliegende Anmeldung betrifft im Allgemeinen die Kryptografie und Computersicherheit und insbesondere, aber nicht ausschließlich, die zertifikatlose Authentifizierung von ausführbaren Programmen.
ALLGEMEINER STAND DER TECHNIK
Es besteht ein erheblicher und zunehmender Bedarf an der Authentifizierung von ausführbaren Programmen in einer Vielfalt an Rechenkontexten. Für eine solche Authentifizierung ist eine Reihe von Vorschlägen gemacht worden; allerdings weist der Stand der Technik zahlreiche Nachteile, Unzulänglichkeiten und ungelöste Probleme auf. Einige Vorschläge basieren auf zertifikatbasierter Authentifizierung, bei der ein digitales Zertifikat verwendet wird, um eine Vorrichtung, ein Programm oder einen Code zu authentifizieren. Digitale Zertifikate, auch Public-Key-Zertifikate genannt, sind elektronische Dokumente, die Informationen über einen öffentlichen Schlüssel eines öffentlichen/privaten Schlüsselpaars, Informationen über die Identität des Zertifikatsinhabers und eine digitale Signatur (erzeugt unter Verwendung des privaten Schlüssels des öffentlichen/privaten Schlüsselpaars und eines Signaturalgorithmus) eines Zertifikatsausstellers, welcher der Zertifikatsinhaber oder eine separate Zertifizierungsstelle sein kann, enthalten.
Es ist eine Reihe von zertifikatbasierten Ansätzen vorgeschlagen worden. Obwohl zertifikatbasierte Ansätze nützlich sind, werfen sie eine Reihe von Problemen auf. Zum Beispiel kann von einem Zertifikatsinhaber verlangt werden, die Kontrolle über seine Zertifikate und ihre Verwendung zur Authentifizierung gegenüber einer Zertifizierungsstelle einer Drittpartei zu teilen oder aufzugeben. Während der Inhaber die alleinige Kontrolle über seine Zertifikate und ihre Verwendung behalten könnte, bliebe der Zertifizierungsstelle der Drittpartei dann dieser Vorteil verwehrt. Ein weiteres Problem ist, dass eine Zertifizierungsstelle kompromittiert werden kann, was die Ausstellung von bösartigen Zertifikaten ermöglicht, die gültig erscheinen, aber verwendet werden können, um die Authentizität von Software zu fälschen, die so modifiziert worden ist, dass sie Malware beinhaltet. Ablauf- und Versionsverfolgung von digitalen Zertifikaten bringt auch Verwaltungsaufwand und potentielle Sicherheitsprobleme mit sich. Es besteht nach wie vor ein erheblicher, ungedeckter und weit verbreiteter Bedarf an den einzigartigen Vorrichtungen, Prozessen und Systemen, die durch die vorliegende Offenbarung bereitgestellt werden.
OFFENBARUNG VON BEISPIELHAFTEN AUSFÜHRUNGSFORMEN
Um beispielhafte Ausführungsformen der vorliegenden Offenbarung, die Art und Weise und den Prozess ihrer Herstellung und Verwendung klar, prägnant und genau zu beschreiben und die Praxis, Herstellung und Verwendung derselben zu ermöglichen, wird nun auf bestimmte beispielhafte Ausführungsformen Bezug genommen, beinhaltend diejenigen, die in den Figuren veranschaulicht sind, und spezifische Sprache wird verwendet, um diese zu beschreiben. Es versteht sich dennoch, dass dadurch keine Einschränkung des Umfangs der Erfindung erzeugt wird und dass die Erfindung solche Änderungen, Modifikationen und weitere Anwendungen der beispielhaften Ausführungsformen beinhaltet und schützt, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
KURZDARSTELLUNG DER OFFENBARUNG
Beispielhafte Ausführungsformen beinhalten einzigartige Einrichtungen, Verfahren und Systeme zum Kalibrieren einer elektronischen Steuereinheit. Weitere Ausführungsformen, Formen, Gegenstände, Merkmale, Vorteile, Aspekte und Nutzen ergeben sich aus der folgenden Beschreibung und den Zeichnungen.
KURZE BESCHREIBUNG DER FIGUREN

1 ist ein Flussdiagramm, das bestimmte Aspekte eines Beispielprozesses zum Durchführen einer zertifikatlosen sicheren Authentifizierung von ausführbaren Programmen veranschaulicht.
2 ist ein schematisches Diagramm, das bestimmte Aspekte eines Beispielsystems zum Durchführen einer zertifikatlosen sicheren Authentifizierung von ausführbaren Programmen veranschaulicht.
3 ist ein Flussdiagramm, das bestimmte Aspekte eines Beispielprozesses zum Erzeugen eines ausführbaren Programms, das zertifikatlose sichere Authentifizierung von ausführbaren Programmen ermöglicht, veranschaulicht.
4 ist ein schematisches Diagramm, das bestimmte Aspekte eines Beispielsystems zum Erzeugen eines ausführbaren Programms, das zertifikatlose sichere Authentifizierung von ausführbaren Programmen ermöglicht, veranschaulicht.

DETAILLIERTE BESCHREIBUNG VON BEISPIELHAFTEN AUSFÜHRUNGSFORMEN
Unter Bezugnahme auf 1 ist dort ein Flussdiagramm veranschaulicht, das bestimmte Aspekte eines Beispielprozesses 100 zum Durchführen einer zertifikatlosen Authentifizierung von ausführbaren Programmen veranschaulicht. Es versteht sich, dass sich zertifikatlose Authentifizierung auf computerbasierte kryptografische Authentifizierung bezieht, die ohne Verwendung eines digitalen Zertifikats erfolgreich durchgeführt werden kann. Ferner noch bezieht sich ein zertifikatloses authentifizierbares Paket (CLA-Paket) auf und beinhaltet Softwarepakete, die aus einem ausführbaren Programm bestehen, im Wesentlichen daraus bestehen oder ein solches umfassen, dessen Eigenschaften oder Verbindungen mit anderen Paketkomponenten ermöglichen, dass es unter Verwendung von zertifikatloser Authentifizierung authentifiziert wird. Zertifikatlose Authentifizierung und CLA-Pakete können auch in Kombination mit zertifikatbasierter Authentifizierung durchgeführt oder verwendet werden, vorausgesetzt, dass zumindest eine Instanziierung der Authentifizierung einer solchen Kombination kein digitales Zertifikat oder dessen Verwendung erfordert.
Es versteht sich, dass die zum Beschreiben von zertifikatloser Authentifizierung und CLA-Paketen verwendeten Begriffe für Fachleute auf diesem Gebiet eine technische Bedeutung haben. Zum Beispiel bezieht sich ein digitales Zertifikat oder Zertifikat auf eine Datei, ein Objekt oder eine Codeeinheit, die den öffentlichen Schlüssel eines öffentlichen/privaten Schlüsselpaars sowie Daten enthält, die den Zertifikatsinhaber identifizieren, der über den entsprechenden privaten Schlüssel verfügt und daher verwendet werden kann, um ein Objekt (z. B. eine Datei, Nachricht oder ein anderes Objekt) zu identifizieren, dessen kryptografischer Hash-Funktions(CHF)-Digest unter Verwendung des privaten Schlüssels verschlüsselt worden ist, indem ein Digest, der durch Berechnen eines kryptografischen Hashs des Objekts produziert wird, mit einem Digest, der durch Entschlüsseln des verschlüsselten CHF-Digests des Objekts produziert wird, verglichen wird.
Ein ausführbares Programm bezieht sich im Allgemeinen auf ein Programm, das als oder in einer oder mehreren Dateien, Objekten oder anderen Codeeinheiten bereitgestellt ist, das durch einen Computer gestartet und ausgeführt werden kann, beinhaltend zum Beispiel eine App, eine Anwendung, ein Skript oder eine andere ausführbare Datei für einen Desktop-Computer, einen eingebetteten Computer oder eine Steuerung, einen Laptop-Computer, eine mobile Vorrichtung, ein Smartphone, ein Tablet oder andere Arten von Computern und Rechenvorrichtungen. Ein ausführbares Programmpaket bezieht sich auf einen Satz von Software, beinhaltend zumindest ein ausführbares Programm und potentiell zugehörige Softwarekomponenten, zum Beispiel Archive und Komponenten davon, Komprimierungs-/Dekomprimierungskomponenten, Ordner und Komponenten davon, Bibliothekskomponenten, Installationskomponenten, Verknüpfungskomponenten, Ressourcen, Dienste und andere Softwarekomponenten, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Der Prozess 100 kann durch den Startvorgang 102 initiiert werden, zum Beispiel, indem ein Benutzer den Start eines ausführbaren Programms auswählt oder befiehlt, oder indem eine andere Softwarekomponente einen solchen Start auswählt oder befiehlt. Das ausführbare Programm kann eine beliebige Anzahl an Arten von ausführbaren Programmen umfassen, beinhaltend zum Beispiel Anwendungen oder Apps für mobile Vorrichtungen, Laptops, Desktops, Server oder andere Arten von Computern sowie andere Arten von ausführbaren Programmen, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Von dem Vorgang 102 geht der Prozess 100 zu dem Vorgang 104 über, der ein ausführbares Programm startet. Das ausführbare Programm beinhaltet bevorzugt eine sichere Programmkomponente. In einigen Formen kann die sichere Programmkomponente einige oder alle der Attribute, Eigenschaften und/oder Strukturen der sicheren Komponente 230 sein oder aufweisen, die in Verbindung mit 2 veranschaulicht und beschrieben ist, oder der anderen sicheren Komponenten, die hierin offenbart sind. In einigen Formen kann die sichere Programmkomponente einige oder alle der Attribute, Eigenschaften und/oder Strukturen von anderen sicheren Programmkomponenten sein oder aufweisen, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Von dem Vorgang 104 geht der Prozess 100 zu dem Vorgang 106 über, der einen Authentifizierungsablauf unter Verwendung der sicheren Programmkomponente initiiert oder auslöst. Der Vorgang 106 kann auf eine Anzahl an Arten gemäß einer Anzahl an Formen arbeiten. In einigen Formen kann der Vorgang 106 den Authentifizierungsablauf als den ersten Vorgang eines ausführbaren Programms beim Start sofort initiieren oder auslösen. In einigen Formen kann der Vorgang 106 den Authentifizierungsablauf sofort und ausschließlich als den ersten Vorgang eines ausführbaren Programms beim Start initiieren oder auslösen, sodass kein anderer Ablauf oder Prozess des ausführbaren Programms mit dem Authentifizierungsablauf initiiert werden kann. In einigen Formen kann der Vorgang 106 den Authentifizierungsablauf sofort und ausschließlich als den ersten Vorgang eines ausführbaren Programms beim Start initiieren oder auslösen, sodass kein anderer Ablauf oder Prozess des ausführbaren Programms bis zum Abschluss des Authentifizierungsablaufs durchgeführt werden kann. In einigen Formen kann der Vorgang 106 den Authentifizierungsablauf initiieren oder auslösen, nachdem das ausführbare Programm gestartet ist und einige andere Startabläufe oder andere Programmabläufe initiiert und/oder abgeschlossen worden sind, sodass der Vorgang 106 nicht sofort oder nicht ausschließlich der erste Vorgang eines ausführbaren Programms beim Start ist. In einigen Formen kann der Vorgang 106 den Authentifizierungsvorgang initiieren oder auslösen, nachdem das ausführbare Programm gestartet ist und eine aufrufende Komponente des ausführbaren Programms versucht, auf eine eingeschränkte oder sichere Ressource zuzugreifen oder den Zugriff darauf anzufordern. Es versteht sich, dass das Vorstehende Beispiele für den Vorgang 106 sind, der als Reaktion auf das Starten eines ausführbaren Programms durchgeführt wird. Es versteht sich ebenfalls, dass die Durchführung von Vorgängen im Anschluss an den Vorgang 106 auch als Reaktion auf das Starten eines ausführbaren Programms als durchgeführt angesehen werden kann. Es versteht sich ferner, dass in den vorstehenden und anderen Beispielen der Vorgang 106 als Post-Launch-Authentifizierungsauslöser oder Authentifizierungsinitiator fungieren oder arbeiten kann.
Von dem Vorgang 106 geht der Prozess 100 zu dem Vorgang 108 über, bei dem die sichere Programmkomponente einen kryptografischen Hash-Funktions-Digest des ausführbaren Programms berechnet. Es versteht sich, dass sich der Begriff Digest auf Datenausgabe als Reaktion auf Eingabe bezieht, die einer kryptografischen Hash-Funktion (CHF) bereitgestellt wird, die eine Eingabe von beliebiger Größe einer Ausgabe fester Größe (d. h. den Digest, manchmal auch als Hash oder Hashwert bezeichnet) auf eine deterministische Weise zuordnet. Bevorzugt weist eine CHF auch bestimmte Undurchführbarkeitsmerkmale auf, was bedeutet, dass es nicht praktikabel oder prohibitiv im Hinblick auf Rechenzeit und -leistung ist (selbst wenn theoretisch möglich), bestimmte Vorgänge relativ zu einer CHF durchzuführen. Zum Beispiel ist es bevorzugt unmöglich, eine Nachricht mit einer CHF zu erzeugen, die einen gegebenen Hash-Wert liefert (d. h. den Prozess umzukehren, der den gegebenen Hash-Wert erzeugt hat). Es ist auch bevorzugt unmöglich, zwei verschiedene Eingaben zu finden, welche den gleichen Digest produzieren, wenn sie mit einer CHF verarbeitet werden. Es ist auch vorzuziehen, dass eine kleine Änderung der Eingabe in eine CHF den resultierenden Digest so stark verändert, dass ein neuer Digest scheinbar nicht mit dem vorherigen Digest korreliert.
Von dem Vorgang 108 geht der Prozess 100 zu dem Vorgang 110 über, bei dem die sichere Programmkomponente auf einen zuvor berechneten Hash-Funktions-Digest des ausführbaren Programms zugreift, der in einer White-Box-Datenstruktur enthalten ist. Es versteht sich, dass sich eine White-Box-Datenstruktur auf eine Anzahl an Datenstrukturen (z. B. Datenspeicher) bezieht und diese beinhaltet, die unter Verwendung von White-Box-Kryptografie(WBC-)Techniken geschützt sind und daher auch als White-Box-geschützte Datenstruktur bezeichnet werden können. Im Allgemeinen kombinieren WBC-Techniken Verschlüsselung und Verschleierung, um geschützte Objekte (z. B. einen Digest, einen geheimen Schlüssel oder ein anderes Objekt) sicher in den Code eines ausführbaren Programms oder Programmpakets einzubetten oder diesem zuzuordnen. WBC-Techniken kombinieren Code und geschützte Objekte auf eine solche Weise, dass ein Angreifer nicht zwischen den beiden unterscheiden kann und das WBC-geschützte ausführbare Programm oder Programmpaket in einer unsicheren Umgebung sicher ausgeführt werden kann. Ein ausführbares Programm oder Paket kann als White-Box-geschützt bezeichnet werden, wenn es ein oder mehrere Objekte beinhaltet, die gemäß einer WBC-Technik geschützt sind.
Eine beispielhafte WBC-Implementierung kann sowohl ein geschütztes Objekt als auch zufällige Daten in eine Zusammensetzung einbetten, aus der es schwierig ist, das ursprüngliche geschützte Objekt abzuleiten, zum Beispiel durch Hartcodieren eines geschützten Objekts in eine Reihe von schlüsselabhängigen Nachschlagetabellen, die durch eine Randomisierungstechnik geschützt sind. Bestimmte solche Implementierungen können Substitution-Permutation-Network(SPN-)Blockchiffren verwenden, die (a) eine Chiffre neu organisieren, sodass Substitutionsboxvorgänge benachbart zu Vorgängen sind, die das geschützte Objekt beinhalten, (b) den geheimen Schlüssel in der Substitutionsbox hartcodieren, (c) vernichtende affine Transformationsvorgänge in eine affine Blockchiffreschicht injizieren, (d) alle affinen Vorgänge in eine Reihe von Nachschlagetabellen zerlegen und (e) zufällige vernichtende Codierungen in die Folge von Nachschlagetabellen injizieren. Es versteht sich, dass eine Vielfalt an anderen WBC-Techniken auch in Betracht gezogen wird.
Von dem Vorgang 110 geht der Prozess 100 zu dem Vorgang 112 über, bei dem die sichere Programmkomponente den Hash-Funktions-Digest und den zuvor berechneten Hash-Funktions-Digest vergleicht, um die Gleichheit des Hash-Funktions-Digests und der zuvor berechneten Hash-Funktion zu bewerten. Der Vergleich kann eine Anzahl an Vorgängen beinhalten. In einigen Formen kann der Vergleich einen Gleich- oder Gleichheitsoperator verwenden, um den Hash-Funktions-Digest mit dem zuvor berechneten Hash-Funktions-Digest zu vergleichen. In einigen Formen kann der Vergleich den Hash-Funktions-Digest von dem zuvor berechneten Hash-Funktions-Digest subtrahieren (oder umgekehrt) und den Rest mit Null (0) vergleichen. In einigen Formen kann der Vergleich andere Arten von Vorgängen durchführen, beinhaltend zum Beispiel Dividieren des Hash-Funktions-Digests durch den zuvor berechneten Hash-Funktions-Digest (oder umgekehrt) und Vergleichen des Quotienten mit eins (1) oder durch Durchführen von anderen mathematischen Vergleichsvorgängen, die wirksam sind, um eine Bewertung der Gleichheit oder Identität des Hash-Funktions-Digests anhand des zuvor berechneten Hash-Funktions-Digests zu ermöglichen, wie es einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommt.
Von dem Vorgang 112 geht der Prozess 100 zu der Bedingung 114 über, die bewertet, ob ein Vergleich des Vorgangs 112 angibt, dass der Hash-Funktions-Digest gleich oder identisch mit dem zuvor berechneten Hash-Funktions-Digest ist. In einigen Formen kann die Funktionalität des Vorgangs 112 und der Bedingung 114 kombiniert oder durch einen einzelnen Operator oder eine einzelne Bedingung durchgeführt werden.
Wenn die Bedingung 114 positiv ausgewertet wird, geht der Prozess 100 zu dem Vorgang 116 über, der den Status des ausführbaren Programms auf authentifiziert setzt. Von dem Vorgang 116 geht der Prozess 100 zu dem Vorgang 118 über, der als Reaktion auf den authentifizierten Status des ausführbaren Programms eine oder mehrere ausführbare Programmvorgänge autorisiert. Von dem Vorgang 118 geht der Prozess 100 zu dem Vorgang 120 über, bei dem der Prozess 100 enden oder wiederholt werden kann.
Wenn die Bedingung 114 negativ ausgewertet wird, geht der Prozess 100 zu dem Vorgang 115 über, der den Status des ausführbaren Programms auf nicht authentifiziert setzt. Von dem Vorgang 115 geht der Prozess 100 zu dem Vorgang 117 über, der als Reaktion auf den nicht authentifizierten Status des ausführbaren Programms eine oder mehrere ausführbare Programmvorgänge verbietet. Von dem Vorgang 118 geht der Prozess 100 zu dem Vorgang 120 über, bei dem der Prozess 100 enden oder wiederholt werden kann.
Eine Anzahl an Arten von ausführbaren Programmvorgängen kann in Verbindung mit dem Vorgang 118 autorisiert oder in Verbindung mit dem Vorgang 117 verboten werden. In einigen Formen können der eine oder die mehreren ausführbaren Programmvorgänge den Betrieb (oder fortgesetzten Betrieb) des ausführbaren Programms selbst umfassen, der entweder erlaubt (wodurch das ausführbare Programm weiter normal arbeiten kann) oder verboten sein kann (was dazu führt, dass das ausführbare Programm ausgesetzt oder beendet wird). In einigen Formen können der eine oder die mehreren ausführbaren Programmvorgänge umfassen, dass das ausführbare Programm auf eine oder mehrere Softwarekomponenten zugreift, zum Beispiel ein oder mehrere Softwarearchive, Bibliotheken oder Paketkomponenten oder Kombinationen davon sowie andere Arten von Softwarekomponenten. In einigen Formen können der eine oder die mehreren ausführbaren Programmvorgänge andere ausführbare Programmvorgänge umfassen, wie einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommt.
Unter Bezugnahme auf 2 ist ein schematisches Diagramm veranschaulicht, das bestimmte Aspekte eines beispielhaften ausführbaren Programmpakets 200 (hierin auch als Paket 200 bezeichnet) darstellt, das für zertifikatlose Authentifizierung konfiguriert und dazu in der Lage ist und daher ein Beispiel eines CLA-Pakets gemäß der vorliegenden Offenbarung bereitstellt. Das Paket 200 beinhaltet den ausführbaren Programmspeicher 210, der wiederum von dem System zugängliche oder von dem System ausführbare Komponenten 220 (hierin auch als Komponenten 220 bezeichnet), eine sichere Programmkomponente 230 (hierin auch als Komponente 230 bezeichnet) und eine White-Box-Datenstruktur 240 beinhaltet. Wie durch die gestrichelten Kästchen 240a, 240b und 240c angegeben, kann die White-Box-Datenstruktur 240 eine beliebige von einer Anzahl an Beziehungen zu den veranschaulichten Komponenten des Pakets 200 aufweisen, wie hierin ferner beschrieben. Es versteht sich, dass solche Beziehungen Beispiele für eine White-Box-Datenstruktur eines ausführbaren Programms sind und auch als White-Box-Datenstruktur eines Programmpakets gemäß der vorliegenden Offenbarung angesehen werden können.
Die Komponenten 220 können Kernkomponenten eines ausführbaren Programms beinhalten, auf die durch einen Benutzer oder ein System, auf dem das Paket 200 bereitgestellt ist, direkt zugegriffen, aufgerufen, gelesen und/oder angesehen werden kann. In der veranschaulichten Ausführungsform beinhalten die Komponenten 220 einen Authentifizierungsauslöser 222 und eine aufrufende Komponente 224 und können auch andere Komponenten 226 beinhalten, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Der Authentifizierungsauslöser 222 ist konfiguriert, um einen Authentifizierungsvorgang unter Verwendung der sicheren Programmkomponenten 230 zu initiieren. Der Authentifizierungsauslöser 222 kann konfiguriert sein, um einen Authentifizierungsvorgang auf eine Anzahl an Weisen zu initiieren, beinhaltend zum Beispiel gemäß einer beliebigen der Beispielvorgänge oder -techniken, die oben in Verbindung mit dem Vorgang 106 beschrieben sind, sowie auf andere Arten, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Die aufrufende Komponente 224 ist konfiguriert, um auf eine oder mehrere eingeschränkte oder sichere Ressourcen zuzugreifen oder Zugriff darauf anzufordern, wie auf die eingeschränkten Ressourcen 238 der sicheren Komponente 230. Zugriff auf solche Ressourcen kann von dem Authentifizierungsablauf abhängig gemacht werden, der zumindest teilweise in der sicheren Komponente 230 instanziiert und durch diese durchgeführt wird. Falls und wenn ein solcher Zugriff gewährt wird, können Ressourcen, wie die eingeschränkten Ressourcen 238, durch die aufrufende Komponente 224 und/oder durch andere Komponenten 226 genutzt werden.
Die sichere Komponente 230 enthält einen Digest-Rechner 232, einen Schlüssel 234, einen Digest-Komparator 236 und eingeschränkte Ressourcen 238 und kann in einigen Formen andere sichere Komponenten beinhalten. Die sichere Komponente 230 kann unter Verwendung einer Anzahl an Techniken gesichert oder geschützt werden, beinhaltend zum Beispiel Speicherung in verschlüsseltem Speicher, der auf einer Hardware-Ebene, einer Firmware-Ebene, einer Software-Ebene oder Kombinationen davon verschlüsselt sein kann, sowie andere Formen von kryptografischer schlüsselbasierter Speicherung, passwortgeschützter Speicherung, anmeldeinformationsgeschützter Speicherung oder anderer Arten von geschützter oder sicherer Speicherung, wie sie einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen. Solche Sicherheits- und Schutzattribute und -merkmale stellen Schutz und Sicherheit für die Bestandteilkomponenten der sicheren Komponente 230 bereit, beinhaltend den Digest-Rechner 232, den Schlüssel 234, den Digest-Komparator 236 und die eingeschränkten Ressourcen 238. Es versteht sich, dass, während die Schutz- und/oder Sicherheitsmerkmale und -techniken, die auf die sichere Komponente 230 angewendet werden, nicht auf die Komponenten 220 angewendet werden, die Komponenten 220 optional auf verschiedene Weise separat gesichert oder geschützt werden können.
Der Digest-Rechner 232 ist konfiguriert, um einen CHF-Digest des Pakets 200 oder einer Komponente oder eines Teils davon zu berechnen, der derselben Komponente, demselben Teil oder der gleichen Gesamtheit des Pakets 200 entspricht, aus welcher der vorberechnete Digest 242 der White-Box-Datenstruktur 240 berechnet wurde und unter Verwendung der gleichen CHF-Berechnung, die verwendet wurde, um den vorberechneten Digest 242 zu berechnen. In einigen Ausführungsformen kann der Digest-Rechner 232 konfiguriert sein, um das Vorhandensein von Digest-Informationen in einer Komponente, einem Teil oder der Gesamtheit des Pakets 200 zu berücksichtigen, das andernfalls die zertifikatlose Authentifizierung verhindern würden.
Wenn das Paket 200 zum Beispiel als CLA-Paket erstellt oder konfiguriert ist, wie in Verbindung mit 3 und 4 beschrieben, wird zunächst eine CHF-Berechnung an dem Paket 200 oder einem Teil davon durchgeführt, der keine Daten oder Informationen der White-Box-Datenstruktur 240 beinhaltet. Wenn es jedoch erstellt oder konfiguriert ist, um CLA bereitzustellen, beinhaltet das Paket 200 oder ein Teil davon die Daten und Informationen der White-Box-Datenstruktur 240. Daher produziert eine nachfolgende CHF-Berechnung, die für die CLA-Form des Pakets 200 oder eine CLA-Form eines Teils davon durchgeführt wird, einen anderen Digest als den Digest, der ursprünglich in dem CLA-Erstellungs- oder Konfigurationsprozess berechnet wurde. Entsprechend kann der Digest-Rechner 232 konfiguriert sein, um einen Teil des Pakets 200 zu ignorieren oder wegzulassen, um das Berechnen eines Digests zu vermeiden, der für Authentifizierungszwecke ungeeignet wäre. Wenn also zum Beispiel die White-Box-Datenstruktur 240 in einer Form wie durch die gestrichelten Kästchen 240b oder 240c angegeben bereitgestellt ist (wie nachstehend hierin ferner beschrieben), kann der Digest-Rechner 232 konfiguriert sein, um einen CHF-Digest der Komponenten 220 zu berechnen. In anderen Formen, in denen die White-Box-Datenstruktur 240 ganz oder teilweise in einer Form wie durch das gestrichelte Kästchen 240a angegeben bereitgestellt ist (wie nachstehend hierin ferner beschrieben), kann der Digest-Rechner 232 konfiguriert sein, um eine CHF zu berechnen, indem nur einen Teil der Komponenten 220 verwendet wird, der als die White-Box-Datenstruktur 240 ausschließend definiert ist oder bekannt ist.
Der Schlüssel 234 ist ein kryptografischer Schlüssel, der durch die sichere Komponente 230 konfiguriert und verwendbar ist, um auf die White-Box-Datenstruktur 240 zuzugreifen, indem er die Daten, mit denen er kombiniert, eingebettet, integriert und/oder anderweitig gemäß einer oder mehreren WBC-Techniken wie den WBC-Techniken, die hierin beschrieben sind, oder anderen WBC-Techniken, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen, kryptografisch assoziiert wurde, entschlüsselt und nicht von ihnen verschleiert wird.
Der Digest-Komparator 236 ist konfiguriert und durch die sichere Komponente 230 verwendbar, um einen CHF-Digest, der durch den Digest-Rechner 232 berechnet wird, mit der White-Box-Datenstruktur 240 des vorberechneten Digests 242 zu vergleichen, zum Beispiel unter Verwendung von Techniken wie denjenigen, die in Verbindung mit dem Vorgang 112 beschrieben sind oder anderen Vergleichstechniken, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Die Ressourcen 238 können beliebige von einer Anzahl an Arten von eingeschränkten Ressourcen beinhalten, zum Beispiel Anmeldeinformationen, Schlüssel, Bibliotheken oder Bibliothekskomponenten (z. B. Dynamic Link Libraries (DLL), andere Arten von dynamischen Bibliotheken und statischen Bibliotheken), gemeinsam genutzte Objekte oder im Prinzip ein beliebiger Code, eine beliebige Datei oder eine beliebige Ressource, für die Sicherheit oder Schutz gewünscht wird.
Die White-Box-Datenstruktur 240 enthält einen vorberechneten Digest 242 und kann optional und in einigen Formen auch andere Komponenten 244 beinhalten. Der vorberechnete Digest 242 ist ein CHF-Digest, der berechnet wird, wenn das Paket 200 als CLA-Paket erstellt oder konfiguriert wird, zum Beispiel wie in Verbindung mit 3 und 4 beschrieben. Die White-Box-Datenstruktur 240 ist ein Beispiel für eine White-Box-geschützte Datenstruktur, die gemäß WBC-Techniken wie denjenigen, die hierin offenbart sind, geschützt und gesichert werden kann. WBC-Techniken können Verschlüsselung und Verschleierung kombinieren, um den vorberechneten Digest 242 in oder mit anderem Code des Pakets 200 sicher zu kombinieren, einzubetten, zu integrieren und/oder anderweitig kryptografisch zu verknüpfen.
Die White-Box-Datenstruktur 240 kann sich auf die veranschaulichten Komponenten des Pakets 200 beziehen und kann in oder mit solchen Komponenten auf eine Anzahl an Weisen kombiniert, eingebettet, integriert und/oder anderweitig kryptografisch verknüpft sein, wie im Allgemeinen durch die gestrichelten Kästchen 240a, 240b und 240c angegeben. Zum Beispiel kann die White-Box-Datenstruktur 240 kombiniert, eingebettet, integriert oder anderweitig kryptografisch verknüpft sein mit: Systemkomponenten 220 oder ausführbarem Programmspeicher 210 (wie durch das gestrichelte Kästchen 240a angegeben), anderen Komponenten oder Orten von ausführbarem Programmspeicher 210 (wie durch das gestrichelte Kästchen 240b angegeben), oder anderen Paketkomponenten 250, die sich ganz oder teilweise außerhalb oder separat von ausführbarem Programmspeicher 210 befinden können (wie durch das gestrichelte Kästchen 240c angegeben). Zusätzlich kann die White-Box-Datenstruktur 240 mit Kombinationen der vorstehenden Beispiele kombiniert, eingebettet, integriert oder anderweitig kryptografisch verknüpft sein, zum Beispiel mit zwei oder mehr der Komponenten und/oder Orte, die durch die gestrichelten Kästchen 240a, 240b, 240c angegeben sind, oder mit allen solchen Komponenten und/oder Orten. Ferner noch kann die White-Box-Datenstruktur 240 mit einer oder mehreren Komponenten und/oder Orten unter Verwendung einer Vielfalt an Techniken kombiniert, eingebettet, integriert oder anderweitig kryptografisch verknüpft werden, beinhaltend beliebige der WBC-Techniken, die hierin offenbart sind, sowie andere Techniken, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Unter Bezugnahme auf 3 ist ein Flussdiagramm veranschaulicht, das bestimmte Aspekte eines Beispielprozesses 300 zum Erzeugen eines ausführbaren Programms, das zertifikatlose sichere Authentifizierung von ausführbaren Programmen ermöglicht, veranschaulicht. Der Prozess 300 kann in Verbindung mit einer Anzahl an Netzwerken und Systemen durchgeführt werden, beinhaltend zum Beispiel das System 400, das in Verbindung mit 4 beschrieben ist, sowie andere Netzwerke und Systeme, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Der Prozess 300 kann durch den Startvorgang 302 initiiert werden, zum Beispiel durch einen Entwickler, der eine Nicht-CLA-Form eines Softwarepakets für eine sichere Entwicklungsplattform (SDP) bereitstellt, wie die SDP 410, die unten in Verbindung mit 4 beschrieben ist, oder andere geeignete Entwicklungscomputer, Maschinen, Systeme und/oder andere Arten von Plattformen, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Von dem Vorgang 302 geht der Prozess 300 zu dem Vorgang 304 über, bei dem die Nicht-CLA-Form des Softwarepakets an der SDP empfangen wird. Von dem Vorgang 304 kann der Prozess 300 zu dem Vorgang 306 übergehen, der das Softwarepaket bei einer Registrierungsstelle registriert (z. B. einer Zertifizierungsstelle einer Drittpartei, Herausgeber oder Vertreiber einer CLA-Form des Softwarepakets). Bei einer solchen Registrierung kann ein Token oder ein Token-Anspruch durch die Registrierungsstelle erzeugt und von dieser empfangen werden und kann nach Erhalt in einer Authentifizierungsbibliothek gespeichert werden, die auf der oder durch die SDP verwaltet wird. Es versteht sich, dass eine Vielfalt an Registrierungs- und Tokenisierungstechniken und -vorgängen genutzt werden kann, wie einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommt.
Von dem Vorgang 306 geht der Prozess 300 zu dem Vorgang 308 über, der eine CHF verwendet, um den Digest der Nicht-CLA-Form des Softwarepakets zu berechnen. Der Vorgang 308 kann eine Vielfalt an CHF-Komponenten, -Vorgängen und -Techniken nutzen, wie die Beispiele, die hierin offenbart sind, oder andere Beispiele, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Von dem Vorgang 308 geht der Prozess 300 zu dem Vorgang 310 über, der den Digest und eine oder mehrere Komponenten oder die Gesamtheit der Nicht-CLA-Form des Softwarepakets an eine White-Box-Kryptografieplattform überträgt. Von dem Vorgang 310 geht der Prozess 300 zu dem Vorgang 312 über, bei dem der Digest und die Nicht-CLA-Form des Softwarepakets durch die White-Box-Kryptografieplattform empfangen werden. Der Digest und die eine oder mehreren Komponenten oder die Gesamtheit der Nicht-CLA-Form des Softwarepakets können zusammen oder separat und in einer einzelnen Nachricht oder mehreren Nachrichten übertragen und empfangen werden, die weiter paketiert und/oder verschlüsselt werden können und die über ein sicheres Netzwerk wie ein virtuelles privates Netzwerk (VPN) übertragen werden können.
Von dem Vorgang 312 geht der Prozess 300 zu dem Vorgang 314 über, der eine oder mehrere WBC-geschützte Softwarepaketkomponenten (auch als WBC-Paketkomponenten bezeichnet) erzeugt. Der Vorgang 314 kann die eine oder mehreren WBC-Paketkomponenten unter Verwendung von WBC-Schutztechniken wie denjenigen, die hierin offenbart sind, erzeugen. Die Erzeugung von einer oder mehreren WBC-geschützten Paketkomponenten kann Kombinieren, Einbetten, Integrieren und/oder anderweitiges kryptografisches Zuordnen des Digests zu einer oder mehreren Komponenten oder der Gesamtheit der Nicht-CLA-Form des Softwarepakets beinhalten, die wirksam sind, um die eine oder mehreren WBC-Paketkomponenten zu erzeugen.
Von dem Vorgang 314 geht der Prozess 300 zu dem Vorgang 316 über, der die eine oder mehreren WBC-Paketkomponenten an die SDP überträgt. Von dem Vorgang 316 geht der Prozess 300 zu dem Vorgang 318 über, bei dem die eine oder mehreren WBC-Paketkomponenten an der SDP empfangen werden. Die eine oder mehreren WBC-Paketkomponenten können zusammen oder separat und in einer einzelnen Nachricht oder mehreren Nachrichten übertragen und empfangen werden, die weiter paketiert und/oder verschlüsselt werden können und die über ein sicheres Netzwerk wie ein virtuelles privates Netzwerk (VPN) übertragen werden können.
Von dem Vorgang 318 geht der Prozess 300 zu dem Vorgang 320 über, der eine CLA-Form des Softwarepakets erzeugt, beinhaltend die eine oder mehreren WBC-Paketkomponenten. Der Vorgang 320 kann eine Anzahl an Techniken verwenden, um die CLA-Form des Softwarepakets zu erzeugen. In einigen Formen können die eine oder mehreren WBC-Paketkomponenten alle oder im Wesentlichen alle der Komponenten der CLA-Form des Softwarepakets beinhalten, wobei in diesem Fall keine wesentlichen Änderungen an der CLA-Form des Softwarepakets vorgenommen werden müssen und der Vorgang 320 auf das Speichern, Indizieren und/oder Registrieren der CLA-Form des Softwarepakets beschränkt sein kann. In einigen Formen kann die eine oder können die mehreren WBC-Paketkomponenten nur einige der Komponenten der CLA-Form des Softwarepakets beinhalten, wobei in diesem Fall der Vorgang 320 die WBC-Paketkomponenten archivieren, kombinieren, integrieren, in einem gemeinsamen Ordner oder Verzeichnis platzieren oder anderweitig zuordnen oder mit anderen Softwarepaketkomponenten verknüpfen kann, um die CLA-Form des Softwarepakets zu erstellen oder bereitzustellen. Von dem Vorgang 320 geht der Prozess 300 zu dem Vorgang 322 über, der die CLA-Form des Softwarepakets an ein Ziel außerhalb der SDP überträgt oder anderweitig bereitstellt.
Unter Bezugnahme auf 4 ist ein schematisches Diagramm veranschaulicht, das bestimmte Aspekte eines Beispielsystems 400 zum Erzeugen eines ausführbaren Programms, das zertifikatlose sichere Authentifizierung von ausführbaren Programmen ermöglicht, veranschaulicht. Das System 400 kann konfiguriert sein, um eine Anzahl an Prozessen auszuführen, um eine CLA-Form eines Softwarepakets (z. B. CLA-Paket 499) aus einer Nicht-CLA-Form eines Softwarepakets (z. B. Nicht-CLA-Paket 401) zu erstellen oder zu konfigurieren, beinhaltend zum Beispiel den Prozess 300, der in Verbindung mit 3 beschrieben ist, sowie andere Prozesse, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen. In der veranschaulichten Ausführungsform ist das System 400 in der Form eines Netzwerks bereitgestellt, das mehrere Systeme und Komponenten beinhaltet, wie weiter unten beschrieben. In anderen Formen könnte das System 400 als einheitliches System bereitgestellt sein, zum Beispiel als Datenzentrum, Server oder anderes einheitliches Rechensystem.
Das System 400 beinhaltet eine sichere Entwicklungsplattform (SDP) 410 und eine White-Box-Kryptografie-Plattform (WBC) 430, die bevorzugt als sichere Plattformen konfiguriert und bereitgestellt sind, die von externen Netzwerken und Systemen durch ein oder mehrere Sicherheitsmerkmale getrennt sind, die allgemein durch den gestrichelten Pfeil 402 angegeben sind. In einigen Formen können die SDP 410 und die WBC-Plattform 430 durch ein oder mehrere Sicherheitsmerkmale, die allgemein durch den gestrichelten Pfeil 403 angegeben sind, weiter voneinander getrennt sein. Die Sicherheitsmerkmale, die durch die gestrichelten Pfeile 402 und 403 angegeben sind, können zum Beispiel bedingte Zugriffssysteme, DMZs, Firewalls, Gateways (eingehend und/oder ausgehend), Honeypots, Honeynets, Paketfilter oder andere Netzwerksicherheitssysteme beinhalten, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Die SDP 410 beinhaltet den CLA-Paketgenerator 412, der konfiguriert ist, um eine Eingabe zu empfangen, beinhaltend das Nicht-CLA-Paket 401 und um eine Ausgabe bereitzustellen, beinhaltend das CLA-Paket 499. CLA-Paketgenerator 412. Der CLA-Paketgenerator 412 beinhaltet einen kryptografischen Hash-Funktions(CHF-)Rechner 422 und einen Paketprozessor 424 und kann in einigen Formen andere Komponenten beinhalten, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Der CHF-Rechner 422ist konfiguriert, um eine kryptografische Hash-Funktion (CHF) zu nutzen, um einen Digest 413 des Nicht-CLA-Pakets 401 oder einer Komponente oder eines Teils davon zu berechnen. Der CHF-Rechner 422 kann eine solche Berechnung unter Verwendung einer Anzahl an CHF-Techniken wie denjenigen, die hierin beschrieben sind, oder anderer Techniken durchführen, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Der Paketprozessor 424 ist konfiguriert, um Eingabe/Ausgabe und andere Kommunikationsaspekte und -vorgänge zwischen dem CLA-Paketgenerator 412 und anderen Systemen oder Komponenten handzuhaben, beinhaltend die WBC-Plattform 430 sowie Systemen und Komponenten der SPD 410. Zum Beispielkann der Paketprozessor 424 konfiguriert sein, um Kommunikationen handzuhaben, um ein Softwarepaket bei einer Registrierungsstelle 440 (z. B. einer Zertifizierungsstelle einer Drittpartei, einem Herausgeber oder einem Vertreiber einer CLA-Form des Softwarepakets) zu registrieren und um einen Token oder Token-Anspruch, der durch die Registrierungsstelle 440 erzeugt wird, in einer Authentifizierungsbibliothek der SDP zu empfangen und zu speichern oder zu halten. In einigen Formen kann der Paketprozessor 424 auch konfiguriert sein, um verschiedene Pre-WBC- und Post-WBC-Verarbeitungsvorgänge an oder im Zusammenhang mit Softwarepaketkomponenten wie denjenigen, die hierin beschrieben sind, oder anderen Vorgängen durchzuführen, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Der Paketprozessor 424 ist ferner konfiguriert, um die Kommunikation des Digest 413 (der durch den CHF-Rechner 422 berechnet wird) und der Nicht-WBC-Paketkomponenten 414 (die eine oder mehrere Komponenten oder das gesamte Nicht-CLA-Paket 401 beinhalten) von dem CLA-Paketgenerator 412 und der SDP 410 zu der WBC-Plattform 430 zu erleichtern oder daran teilzunehmen. In der veranschaulichten Ausführungsform beinhaltet eine solche Kommunikation eine Übertragung über ein virtuelles privates Netzwerk (VPN) 470. In einigen Formen kann eine solche Kommunikation eine Übertragung über andere Arten von sicheren Netzwerken beinhalten. In einigen Formen kann eine solche Kommunikation eine netzwerkinterne Übertragung beinhalten, zum Beispiel, wenn die SDP 410 und die WBC-Plattform 430 in einem gemeinsamen Netzwerk oder innerhalb eines gemeinsamen Rechensystems, wie einem gemeinsamen Datenzentrum (physisch oder virtuell) oder einem Satz von einem oder mehreren Servern oder anderen Computern bereitgestellt sind.
Die WBC-Plattform 430 beinhaltet den WBC-Generator 436, den Komponentenprozessor 438 und kann in einigen Formen andere Komponenten beinhalten, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen. Der WBC-Generator 436 ist konfiguriert, um WBC-Paketkomponenten durch Kombinieren, Einbetten, Integrieren oder anderweitiges kryptografisches Zuordnen von dem Digest 413 und den Nicht-WBC-Komponenten 414 zu erzeugen. Der WBC-Generator 436 kann WBC-Paketkomponenten 434 gemäß einer oder mehreren WBC-Techniken erzeugen, wie den WBC-Techniken, die hierin beschrieben sind, oder anderen WBC-Techniken, die einem Fachmann mit dem Vorteil und Einblick in die vorliegende Offenbarung in den Sinn kommen.
Der Komponentenprozessor 438 ist konfiguriert, um Eingabe/Ausgabe und andere Kommunikationsaspekte und -vorgänge zwischen der WBC-Plattform 430 und anderen Systemen oder Komponenten der SPD 410 und Komponenten davon handzuhaben. Zum Beispiel ist der Komponentenprozessor 438 konfiguriert, um die Kommunikation der WBC-Paketkomponenten 434 von der WBC-Plattform 430 zu dem CLA-Paketgenerator 412 der SDP 410zu erleichtern oder daran teilzunehmen. In der veranschaulichten Ausführungsform beinhaltet eine solche Kommunikation eine Übertragung über das virtuelle private Netzwerk (VPN) 470. In einigen Formen kann eine solche Kommunikation eine Übertragung über andere Arten von sicheren Netzwerken beinhalten. In einigen Formen kann eine solche Kommunikation eine netzwerkinterne Übertragung beinhalten, zum Beispiel, wenn die SDP 410 und die WBC-Plattform 430 in einem gemeinsamen Netzwerk oder innerhalb eines gemeinsamen Rechensystems, wie einem gemeinsamen Datenzentrum (physisch oder virtuell) oder einem Satz von einem oder mehreren Servern oder anderen Computern bereitgestellt sind.
Sobald der CLA-Paketgenerator 412 ferner konfiguriert ist, um das CLA-Paket 499 (das eine CLA-Form des Nicht-CLA-Pakets 401 ist) als Reaktion auf WBC-Paketkomponenten 434 zu erzeugen, die von der WBC-Plattform 430 empfangen werden. Eine Anzahl an Techniken kann genutzt werden, um das CLA-Paket 499 zu erzeugen. In einigen Formen können die WBC-Paketkomponenten 434 alle oder im Wesentlichen alle der Komponenten des CLA-Pakets 499 beinhalten, wobei in diesem Fall keine wesentlichen Änderungen oder weitere Verarbeitung erforderlich ist, obwohl verschiedene Vorgänge wie Speichern, Indizieren und/oder Registrieren des CLA-Pakets 499 durchgeführt werden können. In einigen Formen können die WBC-Paketkomponenten 434 nur einige der Komponenten des CLA-Pakets 499 beinhalten, wobei in diesem Fall die WBC-Paketkomponenten 434 archiviert, kombiniert, integriert, in einem gemeinsamen Ordner oder Verzeichnis platziert oder anderweitig zugeordnet oder mit anderen Paketkomponenten verknüpft werden können, um das CLA-Paket 499 zu erstellen oder bereitzustellen.
Während beispielhafte Ausführungsformen der Offenbarung in den Zeichnungen und der vorstehenden Beschreibung detailliert veranschaulicht und beschrieben worden sind, ist dies als veranschaulichend und nicht als einschränkend zu betrachten, wobei zu verstehen ist, dass nur bestimmte beispielhafte Ausführungsformen gezeigt und beschrieben worden sind und dass alle Änderungen und Modifikationen, die im Rahmen der beanspruchten Erfindungen liegen, geschützt werden sollen. Es versteht sich, dass die Verwendung von Wörtern wie bevorzugt, vorzugsweise oder bevorzugter, die in der obigen Beschreibung verwendet werden, zwar angeben, dass das so beschriebene Merkmal möglicherweise wünschenswerter ist, es jedoch möglicherweise nicht notwendig ist und Ausführungsformen, denen dies fehlt, als innerhalb des Umfangs der Erfindung angesehen werden können, wobei der Umfang durch die folgenden Ansprüche definiert ist. Bei der Lektüre der Ansprüche ist darauf hinzuweisen, dass bei der Verwendung von Wörtern wie „ein“, „eine“, „zumindest ein“ oder „zumindest ein Teil“ nicht die Absicht besteht, den Anspruch auf nur einen Gegenstand zu beschränken, es sei denn, in dem Anspruch ist ausdrücklich etwas Gegenteiliges angegeben. Wenn die Formulierung „zumindest ein Teil“ und/oder „ein Teil“ verwendet wird, kann der Gegenstand einen Teil und/oder den gesamten Gegenstand beinhalten, sofern nicht ausdrücklich etwas Gegenteiliges angegeben ist.

Claims

Prozess zum zertifikatlosen sicheren Authentifizieren eines ausführbaren Programms, wobei der Prozess Folgendes umfasst: Starten eines ausführbaren Programms, wobei das ausführbare Programm eine sichere Programmkomponente beinhaltet; als Reaktion auf einen Post-Launch-Authentifizierungsauslöser, Berechnen, unter Verwendung der sicheren Komponente, eines kryptografischen Hash-Funktions-(CHF)-Digests von zumindest einem Teil des ausführbaren Programms; Zugreifen, unter Verwendung der sicheren Komponente, auf einen zuvor berechneten CHF-Digest von zumindest dem Teil des ausführbaren Programms, der in einer White-Box-Datenstruktur des ausführbaren Programms enthalten ist; Vergleichen, unter Verwendung der sicheren Komponente, des CHF-Digest und des zuvor berechneten CHF-Digest; und als Reaktion auf das Vergleichen, das Gleichheit des CHF-Digest und des zuvor berechneten CHF-Digest angibt, Autorisieren eines Vorgangs des ausführbaren Programms.
Prozess nach Anspruch 1, wobei der Post-Launch-Authentifizierungsauslöser einen Authentifizierungsablauf initiiert, der das Berechnen als einen von einem sofortigen Post-Launch-Vorgang und einem sofortigen und exklusiven Post-Launch-Vorgang beinhaltet.
Prozess nach Anspruch 1, wobei das Berechnen Berechnen des CHF-Digest des gesamten ausführbaren Programms beinhaltet.
Prozess nach Anspruch 1, wobei das Zugreifen Verwenden eines Schlüssels beinhalten, um auf den zuvor berechneten CHF-Digest zuzugreifen, der in der White-Box-Datenstruktur enthalten ist.
Prozess nach Anspruch 1, wobei das Autorisieren zumindest eines von Folgendem umfasst: Erlauben von fortgesetzter Ausführung des ausführbaren Programms und Erlauben von einem von Zugriff und Nutzung einer sicheren Ressource für das ausführbare Programm.
Einrichtung, die ein nichtflüchtiges Speichermedium umfasst, das konfiguriert ist, um ein Programm zu speichern, das durch einen oder mehrere Prozessoren zu Folgendem ausführbar ist: Berechnen, unter Verwendung einer sicheren Komponente, eines kryptografischen Hash-Funktions-(CHF)-Digest von zumindest einem Teil des Programms; Zugreifen, unter Verwendung der sicheren Komponente, auf einen zuvor berechneten CHF-Digest von zumindest dem Teil des Programms, der in einer White-Box-Datenstruktur des Programms enthalten ist; Vergleichen, unter Verwendung der sicheren Komponente, des CHF-Digest und des zuvor berechneten CHF-Digest; und wenn der CHF-Digest und der zuvor berechnete CHF-Digest gleich sind, Autorisieren eines Vorgangs des ausführbaren Programms.
Einrichtung nach Anspruch 6, wobei das Programm durch einen oder mehrere Prozessoren ausführbar ist, um den CHF-Digest als Reaktion darauf zu berechnen, dass das Programm gestartet wird.
Einrichtung nach Anspruch 6, wobei das Programm durch einen oder mehrere Prozessoren ausführbar ist, um den CHF-Digest des gesamten Programms zu berechnen.
Einrichtung nach Anspruch 8, wobei das Programm durch einen oder mehrere Prozessoren ausführbar ist, um unter Verwendung eines Schlüssels, der in der sicheren Komponente enthalten ist, auf den zuvor berechneten CHF-Digest zuzugreifen.
Einrichtung nach Anspruch 9, wobei, dass das Programm zum Autorisieren durch einen oder mehrere Prozessoren ausführbar ist, zumindest eines von Folgendem umfasst: das Programm ist durch einen oder mehrere Prozessoren ausführbar, um fortgesetzte Ausführung des ausführbaren Programms zu ermöglichen, und das Programm ist durch einen oder mehrere Prozessoren ausführbar, um zu ermöglichen, dass das ausführbare Programm auf eine sichere Ressource zugreift oder diese nutzt.
Prozess zum Erstellen eines ausführbaren Programmpakets, das zu zertifikatloser Authentifizierung in der Lage ist (CLA-Paket), wobei der Prozess Folgendes umfasst: Berechnen eines kryptografischen Hash-Funktions(CHF-)Digest von zumindest einem Teil des CLA-Pakets; Erstellen einer White-Box-Datenstruktur, beinhaltend den CHF-Digest, der mit dem zumindest einen Teil des CLA-Pakets über eine White-Box-Kryptografietechnik kryptografisch verknüpft ist; und Bereitstellen des CLA-Pakets, beinhaltend den CHF-Digest, der mit dem zumindest einen Teil des CLA-Pakets kryptografisch verknüpft ist.
Prozess nach Anspruch 11, wobei der zumindest eine Teil des CLA-Pakets das gesamte CLA-Paket beinhaltet.
Prozess nach Anspruch 11, wobei das Berechnen auf einer sicheren Entwicklungsplattform durchgeführt wird und das Erstellen der White-Box-Datenstruktur auf einer White-Box-Kryptografieplattform in Wirkkommunikation mit der sicheren Entwicklungsplattform durchgeführt wird.
System zum Erstellen eines ausführbaren Programmpakets, das zu zertifikatloser Authentifizierung in der Lage ist (CLA-Paket), wobei das System Folgendes umfasst: einen kryptografischen Hash-Funktions(CHF-)Rechner, der konfiguriert ist, um einen CHF-Digest von zumindest einem Teil des CLA-Pakets zu berechnen; einen White-Box-Komponenten(WBC-)Generator, der konfiguriert ist, um eine White-Box-Datenstruktur beinhaltend den CHF-Digest zu erstellen, der mit dem zumindest einen Teil des CLA-Pakets unter Verwendung einer White-Box-Kryptografietechnik kryptografisch verknüpft ist; und einen CLA-Paketgenerator, der konfiguriert ist, um das CLA-Paket beinhaltend den CHF-Digest bereitzustellen, der mit dem zumindest einen Teil des CLA-Pakets kryptografisch verknüpft ist.
System nach Anspruch 14, wobei der zumindest eine Teil des CLA-Pakets das gesamte CLA-Paket beinhaltet.
System nach Anspruch 14, wobei der kryptografische Hash-Funktions(CHF-)Rechner als Komponente des CLA-Paketgenerators bereitgestellt ist.
System nach Anspruch 14, wobei der CLA-Paketgenerator auf einer sicheren Entwicklungsplattform bereitgestellt ist und der WBC-Generator auf einer White-Box-Kryptografieplattform in Wirkkommunikation mit der sicheren Entwicklungsplattform bereitgestellt ist.