DE112012000770T5

DE112012000770T5 - System zum Ermöglichen des Überprüfens von digitalen Signaturen

Info

Publication number: DE112012000770T5
Application number: DE112012000770T
Authority: DE
Inventors: Michael Osborne; Tamas Visegrady
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2011-03-16
Filing date: 2012-02-22
Publication date: 2013-11-07
Anticipated expiration: 2032-02-23
Also published as: US20120239935A1; CN103416021B; DE112012000770B4; US8892892B2; GB2501645A; CN103416021A; US8914637B2; JP2014511169A; US20120324230A1; GB2501645B; JP5928741B2; WO2012123833A1; GB201313687D0

Abstract

Die Erfindung gilt hauptsächlich Verfahren und Systemen zum Ermöglichen des Überprüfens von digitalen Signaturen (S41). Die Verfahren sind in einem computergestützten System (1) umgesetzt, das einen Server (10) aufweist, der mit Anwendungen (A, B, C) Daten austauscht, und weisen die folgenden Schritte an dem Server auf: – Empfangen (S13) einer oder mehrerer von einer oder mehreren der Anwendungen ausgegebenen Signaturanforderungen (ai, bi, ci); – Weiterleiten (S14) von ersten Daten, die den empfangenen Signaturanforderungen entsprechen, an eine oder mehrere Signiereinheiten (Sig1-4) zum anschließenden Signieren der ersten Daten; – Speichern (S16) eines aktualisierten Systemzustands (sn+1), der unter Verwendung einer Funktion aus Folgendem berechnet (S15) wurde: – einem Bezugssystemzustand (sn); und – zweiten Daten (ai, bi, ci, Ai, Bi, Ci), die den empfangenen Signaturanforderungen entsprechen, wobei der Bezugssystemzustand und der aktualisierte Systemzustand die Signaturanforderungen bestätigen; und – Wiederholen der obigen Schritte (S12 bis S16) unter Verwendung des aktualisierten Systemzustands (sn+1) als neuen Bezugssystemzustand.

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft allgemein computergestützte Verfahren und Systeme zum Ermöglichen des Überprüfens von digitalen Signaturen und insbesondere computergestützte Systeme, die einen Server aufweisen, der mit mehreren gleichzeitig laufenden Anwendungen Daten austauscht und Zeitstempel für anwendungsrelevante Ereignisse anfordert.
HINTERGRUND DER ERFINDUNG
Einen sicheren Verschlüsselungsprozessor kennt man als einen zweckbestimmten Chip oder Mikroprozessor, der Verschlüsselungsarbeitsschritte ausführt, meistens in einer Konfektionierung mit verschiedenen physischen Sicherheitsmaßnahmen integriert ist und einen Grad von Manipulationssicherheit bereitstellt. Smartcards sind zum Beispiel allgemein bekannte Formen sicherer Verschlüsselungsprozessoren, obgleich in empfindlichen Systemen wie Bankautomaten weithin komplexere Verschlüsselungsalgorithmen eingesetzt werden, siehe z. B. Wikipedia-Beitragsschreiber. „Sicherer Verschlüsselungsprozessor”. Wikipedia, Die freie Enzyklopädie. Wikipedia, Die freie Enzyklopädie, 29. Nov. 2010. Web. 23. Feb. 2011.
Es sind auch Hardware-Sicherheitsmodule (HSM) bekannt, d. h. ein Typ von sicherem Verschlüsselungsprozessor zum Verwalten von digitalen Schlüsseln, zum Beschleunigen von Verschlüsselungsprozessen hinsichtlich digitaler Signierungen und zum Bereitstellen einer starken Authentifizierung zum Zugreifen auf kritische Schlüssel für Server-Anwendungen. Bei derartigen Modulen handelt es sich um physische Einheiten, üblicherweise in Form von Einschubkarten oder externen TCP/IP-Sicherheitseinheiten, die direkt an einem Computer (Server oder Universalcomputer) angebracht werden können, siehe z. B. Wikipedia-Beitragsschreiber. ”Hardware-Sicherheitsmodul”. Wikipedia, Die freie Enzyklopädie. Wikipedia, Die freie Enzyklopädie, 8. Feb. 2011. Web. 23. Feb. 2011.
HSMs können besonders dafür verwendet werden, digital signierte Daten wie zum Beispiel Zeitstempel bereitzustellen. Eine digitale Signatur bedeutet allgemein Daten, die zu einer Dateneinheit hinzugefügt werden, oder eine verschlüsselte Umwandlung dieser, wodurch es einem Empfänger der Dateneinheit ermöglicht wird, die Quelle und die Unversehrtheit der Dateneinheit nachzuweisen und vor Fälschungen z. B. durch den Empfänger zu schützen, siehe z. B. [CEN03].
Es sind ferner Spezifikationen für Verschlüsselungsmodule für Signierungsarbeitsschritte von Zertifizierungsdiensteanbietern bekannt. Derartige Verschlüsselungsmodule stellen einen Kennungsidentitätsnachweis, eine Zugriffssteuerung und eine Prüfung der Benutzer von deren Diensten bereit [CEN03].
Ebenso ist das System „Logocrypt” bekannt, das Zusicherungen bezüglich starker Verschlüsselung bereitstellt, dass durch eine Protokollierungseinrichtung vor einer Systembeeinträchtigung gespeicherte Daten nach der Beeinträchtigung nicht unerkannt geändert werden können [Hol06]. Es gibt andere Umsetzungen, die auf den nicht veränderbaren (nonmalleable) Eigenschaften von Hash-Ketten beruhen.
Die folgenden Bezugnahmen sind Teil des Stands der Technik für die vorliegende Erfindung:
[CEN03] CEN Standardisierungssystem für die Informationsgesellschaft. CWA 14167-4: Cryptographic Module for CSP Signing Operations Protection Profile, Oktober 2003. Version: 0.28. CEN/ISSS Electronic Signature (E-SIGN) Workshop.
[GR01] Rosario Gennaro und Pankaj Rohatgi. How to sign digital streams. Information and Computation, 165(1): 100–116, 2001.
[Gur10] Emil Gurevitch. Providing a tamper-evident layer for logs using secure hardware. Academic dissertation. IMM-B.Eng.-2010-34, 2010, Technische Universität Dänemark (DTU).
[Ho106] Jason E. Holt. Logcrypt: forward security and public verification for secure audit logs. In ACSW Frontiers '06: Proceedings of the 2006 Australasian workshops an Grid computing and e-research, Seiten 203–211. Australian Computer Society, Inc., 2006.
KURZDARSTELLUNG DER ERFINDUNG
Gemäß einem ersten Aspekt ist die vorliegende Erfindung als Verfahren zum Ermöglichen des Prüfens von digitalen Signaturen umgesetzt, das in einem computergestützten System umgesetzt wird, das einen Server aufweist, der mit Anwendungen Daten austauscht, und das die folgenden Schritte an dem Server aufweist:

– Empfangen einer oder mehrerer von einer oder mehreren der Anwendungen ausgegebenen Signaturanforderungen;
– Weiterleiten von ersten Daten, die den empfangenen Signaturanforderungen entsprechen, an eine oder mehrere Signiereinheiten zum anschließenden Signieren der ersten Daten;
– Speichern eines aktualisierten Systemzustands, der unter Verwendung einer Funktion aus Folgendem berechnet wurde:
– einem Bezugssystemzustand; und
– zweiten Daten, die den empfangenen Signaturanforderungen entsprechen, wobei der Bezugssystemzustand und der aktualisierte Systemzustand die Signaturanforderungen bestätigen; und
– Wiederholen der obigen Schritte unter Verwendung des aktualisierten Systemzustands als neuen Bezugssystemzustand.

In anderen Ausführungsformen kann das Verfahren eine oder mehrere der folgenden Eigenschaften aufweisen:

– das Verfahren umfasst ferner an dem Server: das Empfangen von Antworten von den Signiereinheiten als Reaktion auf das Weiterleiten der ersten Daten, und die zweiten Daten umfassen dritte Daten, die Daten in den empfangenen Antworten entsprechen;
– die ersten weitergeleiteten Daten behalten höchstens eine Signaturanforderung pro anfordernder Anwendung bei;
– der aktualisierte Systemzustand wird unter Verwendung einer Funktion aus einem vorhergehenden Systemzustand und zweiten Daten, die von mindestens zwei einzelnen Anwendungen empfangenen Signaturanforderungen entsprechen, berechnet;
– das Speichern weist das Speichern eines Satzes von zusammengefassten Daten auf, die man durch das Zusammenfassen der zweiten Daten in eine Folge von den Bezugssystemzustand und den aktualisierten Systemzustand aufweisenden Systemzuständen erhält, und das Zusammenfassen weist vorzugsweise das Verschachteln der zweiten Daten in die Folge von Systemzuständen auf;
– das Weiterleiten weist das Zuteilen eines Satzes von ersten Datenteilmengen zu entsprechenden Signiereinheiten zum anschließenden Signieren der ersten Datenteilmengen auf, wobei jede der ersten Datenteilmengen entsprechenden an dem Server empfangenen Signaturanforderungen entspricht;
– der Zeitpunkt des Zuteilens wird beruhend auf zeitlichen Zwangsbedingungen an dem Server entschieden, wobei vorzugsweise quantisierte Zeitspannen verwendet werden;
– das Verfahren weist ferner auf: das Verzögern der einen oder mehreren empfangenen Signaturanforderungen vor dem Weiterleiten der entsprechenden ersten Daten, während vorher weitergeleitete erste Daten an der einen oder den mehreren Signiereinheiten signiert werden;
– das Speichern weist das Speichern eines Satzes von zusammengefassten Daten auf, die man durch das Zusammenfassen der zweiten Daten in eine Folge von den Bezugssystemzustand und den aktualisierten Systemzustand aufweisenden Systemzuständen erhält, wobei das Verfahren ferner Folgendes an dem Server aufweist: Empfangen einer Anfrage von einer der Anwendungen; und Antworten auf die eine der Anwendungen beruhend auf dem Satz von zusammengefassten Daten;
– das Verfahren umfasst ferner an dem Server: das Empfangen von Antworten von den Signiereinheiten als Reaktion auf das Weiterleiten der ersten Daten, wobei die Antworten vertrauenswürdige Zeitdaten aufweisen;
– bei den Signiereinheiten handelt es sich um Hardware-Sicherheitsmodule;
– das Verfahren weist ferner auf: Prüfen der Signaturanforderungen oder verwandten Daten beruhend auf dem Bezugssystemzustand und dem aktualisierten Systemzustand; und
– bei der Funktion handelt es sich um eine nicht umkehrbare Funktion;

Gemäß einem anderen Aspekt ist die vorliegende Erfindung als computergestütztes System ausgeführt, das einen Server aufweist, der so eingerichtet ist, dass er mit Anwendungen und Signiereinheiten Daten austauscht, wobei der Server so konfiguriert ist, dass er die Schritte der Verfahren gemäß den obigen Ausführungsformen umsetzt.
Gemäß einem letzten Aspekt ist die vorliegende Erfindung als ein sich auf dem durch einen Computer lesbaren Medium befindliches Computerprogramm ausgeführt, das Anweisungen aufweist, die ein computergestütztes System dazu veranlassen, die Schritte der Verfahren gemäß den obigen Ausführungsformen umzusetzen.
Die vorliegende Erfindung verkörpernde Systeme, Verfahren und Computerprogrammfunktionen werden nun mit Hilfe von nicht einschränkenden Beispielen und unter Bezugnahme auf die beigefügten Zeichnungen beschrieben.
KURZBESCHREIBUNG VERSCHIEDENER ANSICHTEN DER ZEICHNUNGEN
1 zeigt eine Systemebenenansicht von ausgegebenen digitalen Ereignissen wie zum Beispiel Zeitstempeln, die von Signiereinheiten zurückgesendet und in eine Folge von Zuständen auf Systemebene zusammengefasst wurden, gemäß Ausführungsformen;
2 veranschaulicht anwendungsspezifische Zustandsketten innerhalb der Zustandsfolge aus 1 gemäß Ausführungsformen;
3 zeigt verschiedene Komponenten eines computergestützten Systems zum Ermöglichen des Prüfens von digitalen Signaturen gemäß Ausführungsformen;
4 zeigt eine typische Anwendungssicht einer Zeitstempelfolge, die man in Ausführungsformen erhält;
5 veranschaulicht Zeittoleranzfenster, die von einem Signaturen zuteilenden/empfangenden Server gemäß Ausführungsformen verwendet werden;
6 ist ein Ablaufplan typischer Schritte, die durch Signiereinheiten, Server und Anwendungen in Ausführungsformen durchgeführt werden; und
7 zeigt schematisch ein Beispiel einer computergestützten Einheit (z. B. einen Server-Computer, eine Signiereinheit oder unterstützende ausgeführte Anwendungen), die zum Umsetzen der Schritte von Verfahren gemäß Ausführungsformen der Erfindung geeignet sind.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Zunächst werden allgemeine Aspekte der Verfahren gemäß Ausführungsformen der Erfindung zusammen mit allgemeinen Varianten davon erörtert (Abschnitt 1). Als nächstes werden in Abschnitt 2 spezifischere Ausführungsformen beschrieben.
1. Allgemeine Aspekte der Erfindung
In Bezug auf die 1 bis 6 werden vorliegende Verfahren üblicherweise in einem computergestützten System 1 umgesetzt, das einen Server 10 aufweist, der mit einem Satz 30 von Anwendungen A, B, C, ..., Daten austauscht, d. h. Anforderungen an den Server sendet und Aktualisierungen von diesem erhält. Der Server 10 dient ferner als Schnittstelle zwischen den Anwendungen und einem Satz 20 von Signiereinheiten Sig_m, üblicherweise HSMs, die digitale Signaturen wie zum Beispiel Zeitstempel bereitstellen, wie per se bekannt ist. Somit enthält das System 1 hauptsächlich den Server 10, z. B. einen Zeitstempel-Server. Das System 1 kann auch so angesehen werden, dass es die Anwendungen und/oder die Signiereinheiten sowie andere Einheiten/Komponenten wie zum Beispiel einen Zertifikatsaussteller 40, die Signiererzertifikate 50, die Systemzustandskette 15 usw. „aufweist”, die hierin beschrieben sind.
1.1. Allgemeine Ausführungsform des Verfahrens
Die folgenden Schritte werden wie aus Sicht des Servers beschrieben umgesetzt (der Schwerpunkt liegt auf dem Ablaufplan aus 6):

– Schritt S13: die anwendungsbezogenen Daten a_i, b_i, c_i, ... wie zum Beispiel Anwendungszustände oder anwendungsrelevante Ereignisse, die von den entsprechenden Anwendungen A, B, C ausgegeben werden (Schritt S31), werden an dem Server empfangen. Derartige Daten a_i, b_i, c_i, ... geben allgemein Aktivitäten oder Ereignisse der Anwendungen an, für welche die Signatur angefordert wird; sie werden von dem Server als Signaturanforderungen ausgelegt. Wie derartige Anforderungen im Einzelnen an dem Server gehandhabt werden können, wird später beschrieben.
– Schritt S14: der Server leitet erste Daten (genannt D_1,n), die den empfangenen Signaturanforderungen entsprechen, an den Satz 20 der Signiereinheiten Sig_m (bzw. kurz „Signierer” genannt) für eine anschließende Signierung (Schritt S21) weiter. Wie der Server die Signaturanforderungen im Einzelnen den Signierern zuteilen kann, wird später untersucht.
– Dann wird in Schritt S15 ein aktualisierter Systemzustand s_n+1 unter Verwendung einer Funktion f berechnet, die üblicherweise nicht umkehrbar ist, d. h., s_n+1 = f(s_n, D_2,n), und anschließend angewiesen wird, durch den Server an einer geeigneten Stelle gespeichert zu werden, Schritt S16. Die Funktion f verwendet als Argumente:
– einen Bezugssystemzustand s_n, bei dem es sich üblicherweise um den vorher berechneten Zustand handelt, der als Bezugszustand für einen aktuellen Zyklus n dient, siehe Schritt S12, und
– zweite Daten (allgemein durch D_2,n angegeben), die den Signaturanforderungen entsprechen, die während desselben Zyklus empfangen und an Signierer weitergeleitet wurden.

Obwohl es sich bei D_1,n und D_2,n jeweils um Daten handelt, die den empfangenen Anforderungen entsprechen (d. h., sowohl D_1,n als auch D_2,n sind logisch verwandt mit den Anforderungen), muss es sich nicht um dieselben Daten handeln. Wie ersichtlich werden wird, kann D_2,n Folgendem entsprechen oder diese sogar aufweisen:

– die während des aktuellen Zyklus n an dem Server empfangenen anwendungsrelevanten Daten a_i, b_i, c_i, ...; und/oder
– die Daten A_i, B_i, C_i, ..., die a_i, b_i, c_i, ... entsprechen, wobei A_i, B_i, C_i, ... insbesondere Zeitstempel aufweisen, die von den Signiereinheiten innerhalb des Zyklus n zurückgesendet wurden (Schritt S22). Interessanterweise kann das Aktualisieren der Systemzustände parallel mit dem Signieren stattfinden, wenn A_i, B_i, C_i, ... nicht enthalten sind. Trotzdem stellt das Einschließen von A_i, B_i, C_i, ... durch Zusammenfassen der ausgegebenen Signaturen ein höheres Zusicherungsniveau bereit, was als wertvoller als die signierten Daten betrachtet werden kann.
– Schließlich werden die oben erwähnten Schritte (S12 bis S16) wiederholt, wobei der aktualisierte Systemzustand s_n+1 als neuer Bezugszustand für das Berechnen von nachfolgenden Aktualisierungen der Systemzustände verwendet wird.

Man erhält entsprechend eine Folge {..., s_n, ...} von Systemzuständen, welche die Signaturanforderungen bestätigt. Insbesondere wird D_2,n durch zwei fortlaufende (oder zumindest aufeinander folgende) Zustände bestätigt, d. h., s_n und s_n+1 = f(s_n, D_2,n). Die gesamte Folge verfolgt den Verlauf der Signaturanforderungen. Ein derartiger Systemstatus-Aktualisierungsprozess zeichnet eine Systemebenenfolge (siehe z. B., s_1-4 in 1), die eine Unversehrtheitsgarantie bietet, was später während eines Prüfprozesses geprüft wird, Schritt S41.
1.2. Allgemeine Varianten
Vorzugsweise würde der Server, wie oben dargestellt, zum Aktualisieren des Systemzustands Daten verwenden, die von den Signierern (Schritt S22) als Reaktion auf D_1,n zurückgesendet wurden. Die zurückgesendeten Daten umfassen die dritten Daten D_3,n = A_i, B_i, C_i, ... wie zum Beispiel Zeitstempel (und möglicherweise die zusätzlichen vertrauenswürdigen Zeitdaten t_i), die logisch mit D_1,n verwandt sind.
In der Praxis handelt es sich bei den zurückgesendeten Antworten um die Zeitstempel. Letztere sind vorzugsweise in dem Aktualisierungsprozess enthalten, z. B. für Umgebungen mit hoher Zusicherung. Die zurückgesendeten Zeitstempel können einen Bezug auf die verursachende Anforderung oder auf die in der Anforderung enthaltenen oder darauf verwiesenen Ereignisse a_i, b_i, c_i, ..., usw. beibehalten. Folglich könnten die Anforderungen als solche verworfen werden.
Trotzdem kann es einfacher sein, jede relevante Information zu erfassen (Anforderungen oder anwendungsbezogene Ereignisse + Zeitstempel).
Es können entsprechend mehrere Fälle unterschieden werden:

(i) s_n+1 = f(s_n, a_i, b_i, c_i, ...), d. h., Systemzustände werden nur beruhend auf einem vorhergehenden Zustand s_n und den Signaturanforderungen (oder verwandten Daten) aktualisiert, was einen gewissen Grad an Parallelisierung ermöglicht;
(ii) s_n+1 = f(s_n, a_i, b_i, c_i, ..., A_i, B_i, C_i, ...), d. h., der Aktualisierungsprozess berücksichtigt ferner von den Signierern zurückgesendete Antworten; oder
(iii) s_n+1 = f(s_n, A_i(a_i), B_i(b_i), C_i(c_i), ...), die von den Signierern zurückgesendeten Antworten behalten gleichermaßen einen Bezug auf die Anforderungen bei, so dass anwendungsrelevante Ereignisse (die ursprünglich an dem Server empfangen wurden) in dem Aktualisierungsprozess nicht beibehalten werden müssen;
(iv) s_n+1 = f(s_n A_i, B_i, C_i, ...), hier werden die an dem Server empfangenen Anforderungen aus dem Aktualisierungsprozess gestrichen, aber es wird angenommen, dass A_i, B_i, C_i, ... anderweitig auf a_i, b_i, c_i, ... abgebildet werden können;
(v) usw.

Aus in Abschnitt 2 angeführten Gründen werden die obigen Fälle (iii) oder (iv) bevorzugt.
Als nächstes würde ein eindeutiger Zuteilungsprozess vorzugsweise höchstens eine Signaturanforderung a_i, b_i, c_i pro anfordernder Anwendung A, B, C innerhalb desselben Aktualisierungszyklus s_n–s_n+1 beibehalten. Dies wird später ausgearbeitet.
Wie in 1 veranschaulicht, codiert der Systemzustand-Aktualisierungsprozess des Weiteren vorzugsweise Daten, die gleichzeitig laufenden Anwendungen gehören. Man erhält nämlich beruhend auf zweiten Daten D_2,n, die wahrscheinlich Anforderungen von zwei oder mehr einzelnen Anwendungen entsprechen, einen Zustand s_n+1. Wie zum Beispiel in 1 veranschaulicht, erhält man s₂ aus S₁ unter Verwendung insbesondere von A₁ und B₂, d. h., den Anwendungsdaten a₁, b₂, d. h., den Anwendungen A und B entsprechenden Daten. Gleichermaßen erhält man s₃ aus s₂ unter Verwendung von A₂ und C₁ usw. Die Bedeutung der durchgestrichenen Kästchen wird später erläutert.
Man kann auch zusätzliche Varianten in Betracht ziehen, wobei die Systemaktualisierungen als Vektoren strukturiert sind, d. h., s_n+1 = {s_A,n+1, S_B,n+1, s_C,n+1, ...}, deren Komponenten den entsprechenden Anwendungen A, B, C, ... entsprechen (was sowieso der Fall ist, wenn nur eine Anwendung mit dem Server Daten austauscht). Derartige Varianten können für Systeme mit einer konstanten oder einer eingeschränkten Anzahl von Anwendungen geeignet sein. Sie werden jedoch nicht bevorzugt, wenn der Server mit veränderbaren Client-Anwendungen Daten austauscht, insbesondere, wenn der Server bösartigen Anwendungen R ausgesetzt ist, da die Entwicklung des Systemzustands s_R,n+1 = f(s_R,n, ...) besser oder vielleicht zu leicht vorhersagbar werden würde. Derartige Varianten können zum Beispiel geschrieben werden:

(vi) S_n+1 = {s_A,n+1, s_B,n+1, s_C,n+1, ...} = {f(S_A,n, a_i, ...), f(s_B,n, b_i, ...), f(s_C,n, c_i, ...), ...
(vii) s_n+1 = {s_A,n+1, s_B,n+1, s_C,n+1, ...} = {f(s_A,n, A_i, ...), f(s_B,n, B_i, ...), f(s_C,n, C_i, ...), ...}
(viii) usw.

Gleichermaßen können die Systemaktualisierungen als Vektoren s_n+1 = {..., s_m,n+1, s_m+1,n+1, s_m+2,n+1, ...} strukturiert sein, wobei jede Komponente einem bestimmten Signierer m entspricht.
Übrigens können noch andere Varianten in Betracht gezogen werden, wobei die Funktion f zusätzlich zu D_2,n, z. B., s_n+1 = f(s_n-1, D_2,n), einen beliebigen vorher berechneten Zustand s_n-p oder eine Kombination daraus {s_n-p, s_n-q} als Argumente verwendet. Somit handelt es sich bei dem Bezugszustand nicht unbedingt um den gerade vorher berechneten Systemzustand. In allen Fällen wird ein Schema erreicht, das es ermöglicht, den Verlauf von Anwendungsanforderungen zu verfolgen.
Als nächstes kann das Speichern der aktualisierten Zustände mit dem Zusammenfassen der zweiten Daten D_2,n (Schritt S16) in eine Folge 15 von Systemzuständen {s_,n, s_n+1} einhergehen. Eine typische sich daraus ergebende Struktur würde die aus 1 widerspiegeln. Ein einfaches Zusammenfassungsschema besteht zum Beispiel aus dem Verschachteln der zweiten Daten in die Folge von Zuständen, was abhängig von dem beibehaltenen Berechnungsschema als {s_n, {a_i, b_i, ..}, s_n+1}, oder {s_n, {a_i, b_i, ..}, {A_i, B_i, ..}, s_n+1}, usw. geschrieben werden kann. Die Folge wird entsprechend gespeichert, z. B. verschlüsselt, und kann später für eine Prüfeinheit 40 verfügbar gemacht werden. Falls benötigt, kann der Server auf Anforderung einen Zugriff auf die Folge bereitstellen, Schritt S18. In Varianten hat die Prüfeinheit 40 Zugriff auf die gespeicherte Folge 15.
Gegenwärtig werden Anforderungszuweisungen an Signierer ausführlicher erörtert. Vorzugsweise weist das Weiterleiten der ersten Daten (Schritt S14) das Zuteilen von Datenteilmengen, die den entsprechenden in Schritt S13 empfangenen Signaturanforderungen a_i, b_i, ... entsprechen, zu entsprechenden Signierern zum anschließenden Signieren auf. Ein Beispiel ist das folgende, das 1 widerspiegelt:

– Zunächst wird ein Bezugssystemzustand s₁ identifiziert (siehe auch 6, Schritt S12),
– es werden die Signaturanforderungen {a₁, b₂} empfangen (siehe auch 6, Schritt S13);
– entsprechende Daten werden zum Signieren geschickt, Schritt S14, S21. Genauer werden den Signierern Sig₁ bzw. Sig₂ erste und zweite Datenteilmengen, die den Signaturanforderungen a₁ bzw. b₁ entsprechen, zum anschließenden Signieren zugewiesen. Die Signierer Sig₁ und Sig₂ senden entsprechende Zeitstempeldaten {A₁, B₁} zurück, Schritt S22, die selbst (zusätzlich zu/anstelle von a₁, b₁) zum Vorrücken des Systemzustands auf s₂ verwendet werden können, usw.

Entsprechend geben die Verweise s₁ bis s₅ in 1 aufeinander folgende Systemzustände an. Eine waagrechte Linie entspricht einem bestimmten Signierer. Signierer arbeiten parallel. Folglich:

– gibt A₁ einen ersten von dem Signierer Sig₁ zurückgesendeten Zeitstempel an und entspricht einem ersten Anwendungszustand/-ereignis a₁ von Anwendung A;
– entspricht B₁ gleichermaßen einem ersten Zeitstempel für die ersten Anwendungsdaten b₁ der Anwendung B, außer, diese b₁ entsprechenden Daten wurden dem Signierer Sig₂ zugeteilt;
– entspricht A₂ einem zweiten Zeitstempel, der von Sig₁ für die Anwendung A zurückgesendet wurde. Dieser Sig₁ scheint zufällig speziell Anwendung A zugewiesen zu sein, obgleich im Prinzip Ausführungsformen in Betracht gezogen werden können, in denen Signierer speziell dafür vorgesehenen Anwendungen zugewiesen sind;
– entspricht C₁ einem ersten Zeitstempel, der von dem zweiten Signierer Sig2 für die Anwendung C zurückgesendet wurde.
– usw.

Der Zeitpunkt des Zuteilens z. B. beruhend auf zeitlichen Zwangsbedingungen wie zum Beispiel auf quantisierten Zeitspannen wird an dem Server entschieden. Der Server puffert zum Beispiel die empfangenen Signaturanforderungen a_i, b_i, c_i, während vorher weitergeleitete Anforderungen an den Signierern Sig_1-4 signiert werden. Dies wird später in Bezug auf 5 erneut erörtert. Es können andere Varianten in Betracht gezogen werden. Wenn zum Beispiel eine vorher festgelegte Anzahl von empfangenen Anforderungen erreicht ist, leitet der Server die Anforderungen an die Signierer weiter.
2 veranschaulicht Zustandskettenpfade entsprechend 1, jedoch aus Sicht der Anwendungen. Wie in 3 abgebildet, können Anwendungen ihre eigene Zustandskette 35 pflegen. In dieser Hinsicht ermöglichen es Ausführungsformen Anwendungen, ihre eigenen Zustände abzufragen/zu prüfen. Üblicherweise kann eine Anwendung, wenn gewünscht, eine Anfrage an den Server stellen, z. B. bezüglich eines bestimmten Bezugsanwendungszustands, Zeitstempels oder sogar eines Systemzustands. Als Reaktion darauf kann der Server irgendeine relevante Antwort bereitstellen, indem er einfach die zusammengefassten Daten 15 untersucht. Der Server kann zum Beispiel einen aktualisierten Systemzustand berechnen und an die Anwendung zurücksenden, der unter Verwendung eines gleichartigen Schemas wie oben erörtert erhalten wurde, d. h. die Schritte S13 bis 15, S17 aus 6 widerspiegelnd. Interessanterweise muss das System keine Anwendungsdaten über die Daten hinaus, die in der Systemzustandskette 15 benötigt werden, dauerhaft speichern. Letzterer kann ein vereinfachtes Format mit Präfix unter Verwendung von auf andernorts gespeicherte anwendungsrelevante Daten verweisenden Kennungen zugewiesen werden, wodurch man Skalierbarkeit erhält.
Zusätzliche Einzelheiten werden nun in Bezug auf spezifischere Ausführungsformen bereitgestellt.
2. Spezifische Ausführungsformen
Nachfolgend werden spezifische Ausführungsformen der Verfahren und Systeme zum Ermöglichen des Prüfens von digitalen Signaturen in Bezug auf die 1 bis 4 beschrieben. Insbesondere wird ein Signierdienst wie ein Zeitstempeldienst beschrieben, der Elemente von zentralen und verteilten Systemen kombiniert und digitale Signaturen wie zum Beispiel Zeitstempel erzeugen kann, die Anwendungsdaten wie z. B. anwendungsrelevante Ereignisse bestätigen.
Zusätzlich zu unabhängigen digitalen Signaturen (darunter Zeitstempel) kann ein derartiges System eine große Anzahl von Anwendungen unterstützen und es jeder ermöglichen, eine in einer Richtung verlaufende Folge von entstehenden Systemzuständen derart zu verfolgen, dass eine spätere Abänderung der gesamten Ereignisfolge (darunter die globalen und einzelnen Anwendungssystemzustände) verhindert wird. Derartige Folgen können als hochzuverlässige, verschlüsselte, sichere Prüfungsprotokolle verwendet werden, um die Unversehrtheit und Echtheit von gesamten Folgen von Ereignissen und nicht nur von einzelnen Zeitstempeln nachzuweisen.
Ein derartiges System stellt auch eine Folge von zusammengefassten Zuständen auf Systemebene bereit, wodurch systemweite Prüfungen unter denselben Unversehrtheitsgarantien möglich sind. Die kombinierten Protokolle ermöglichen es diesem System, starke Nachweise für den Verlauf von verbundenen Client-Anwendungen zu geben. Das System kann die Anzahl von ausgebenden (backend) Signiereinheiten transparent ändern, wodurch ein beliebig großer Signierdurchsatz bereitgestellt wird.
2.1. Systemkomponenten
Wie vorher erörtert, weist das System den Server 10 auf, der als zentraler Zuteiler dient, der Anforderungswarteschlangen koordiniert, einen Satz Anwendungen/Aufträge mit niedrigeren Berechtigungen bedient und mit den folgenden Komponenten ausgestattet ist (siehe z. B. 3):

1. Einer Folge von Systemzuständen („Zustandskette”, s₁ bis s₅ in 1), die durch Einwegfunktionen unumkehrbar vorgerückt werden, wobei relevante Daten stark verschlüsselt zusammengefasst werden. Derartige Funktionen sind per se bekannt. Wie vorher erklärt, wird der Zustand s_n+1 beruhend auf einem vorhergehenden Zustand s_p (p ≤ n) berechnet, Daten, die den empfangenen Anforderungen entsprechen (wie zum Beispiel Daten, die Antworten von den Signierern entsprechen). Typische Umsetzungen verwenden „Hash-Ketten” oder ähnliche Einwegfolgen, die nicht gefälscht werden können (Einfügen oder Entfernen von Elementen).
2. Ein Zuteiler, der Zeitstempelanforderungen aus seiner Eingangswarteschlange (auf eindeutige Weise) anordnet, teilt diese einer willkürlichen Anzahl von Signierern Sig_n zu und leitet entsprechende Antworten zurück an die anfordernden Anwendungen. Der Zuteiler quantisiert auch die Zeit, wodurch er „Zeitstempel (ausgebende) Zyklen” (5) erstellt und Anforderungen (siehe A₁...C₂ in 1) verzögert, die während des Signierens von vorher zugeteilten Anforderungen ankommen. Zeitstempelzyklen quantisieren die Zeit herunter auf die Auflösung einer gegebenen, z. B. ungünstigsten, Signierlatenzzeit. Es wird angenommen, dass die Signierlatenzzeit ausreichend gering ist, dass sie den Zuteiler nicht beeinflusst. Dies setzt eine ausreichende Signierfähigkeit der Signiereinheiten voraus.
3. Der Zuteiler (der Server) pflegt einen Satz 20 von geeigneten Signierern Sig_1-n wie zum Beispiel Hardware-Sicherheitsmodule (HSMs) oder gleichwertige hochzuverlässige Signiereinheiten, siehe z. B. [CEN03]. Ein neu eingefügter ausgebender Signierer s₅ kann zum Beispiel aktiviert werden (S11, 6), wenn s₄ in 1 erreicht wird. In Varianten pflegen Signierer auch ihre inneren Takte und fügen vertrauenswürdige Zeitwerte in Zeitstempelstrukturen ein, wobei kein Vertrauen in den Takt des Host-Computers selbst benötigt wird. Der Zuteiler kann Dienstqualitätsgarantien (quality-of-service guarantees), Prioritätsstufen oder andere bekannte Verwaltungsfunktionen für Warteschlangen bereitstellen. Derartige Einzelheiten werden hier nicht weiter erörtert, da der Einfachheit halber angenommen wird, dass eine zentrale Warteschlange verwendet wird.
4. Einen Satz 30 von einer oder mehreren Anwendungen A, B, C, ..., die jeweils ihre eigenen Zustände a_i, b_i, c_i, ... auf Anwendungsebene pflegen und eine logische Kette von Ereignissen 35 bilden. Anwendungen pflegen ihren eigenen Zustand und bilden eine logische Kette beruhend auf Aktualisierungen des Zustands (wie zum Beispiel durch A₁ bis A₄ oder B₁ bis B₃ in 1 oder 2. Da Anwendungen Anforderungen eindeutig anordnen, schicken sie vorzugsweise nicht mehrere Ereignisse aus demselben Anwendungszustand ab (was mehrdeutig wäre, die Kette verzweigen würde und somit ungültig wäre). Trotzdem können von der Umsetzung abhängige Antworten für derartige ungültige Folgen von Aufrufen in Betracht gezogen werden. Eine angemessene Antwort ist zum Beispiel das Verarbeiten einer ersten derartigen Anforderung und das Ignorieren nachfolgender Ereignisse von derselben Anwendung. Anders ausgedrückt, innerhalb eines aktuellen Zyklus wird für das Berechnen eines neuen Systemzustands höchstens eine Signaturanforderung pro anfordernder Anwendung beibehalten. Entsprechend geben die Daten a_i, b_i, c_i, ... auf Anwendungsebene sowohl Anwendungszustände als auch jedes Ereignis auf Anwendungsebene an. Es können andere systemspezifische Reaktionen festgelegt werden.
5. Es können zusätzliche Anwendungen bereitgestellt werden, die mit dem Server Daten austauschen und Zeitstempel benötigen, aber keine logische Folge von Zuständen pflegen. Bei derartigen Anwendungen handelt es sich um herkömmliche Zeitstempelbenutzer, die digital signierte Zeitstempel als Besitznachweis pflegen, aber keinen Nachweis über die relative Reihenfolge erbringen. Man beachte, dass Echtzeit-Taktunterschiede selbst beim Vorhandensein von Zeitstempeln eine ungenaue Reihenfolge mit sich bringen können, wenn es mehrere Signierer gibt. In den jetzt erörterten spezifischen Ausführungsformen verwaltet das System als Nebeneffekt herkömmliche Zeitstempelbenutzer: für den vorliegenden Zweck handelt es sich dabei um Anwendungen, die ihre eigene Zustandskette ignorieren, aber eigentlich in der systemweiten enthalten sind. In diesem Hinblick entsprechen durchgestrichene Signaturen in 1 unabhängigen Zeitstempeln; ihre gestrichelten Verbindungen mit Zuständen zeigen Systemstatusaktualisierungen, welche die verursachenden Anwendungen ignorieren.
6. Eine eindeutige durch den Server umgesetzte Sortier/Zuweisungs-Strategie, die Anforderungen Signieren zuweist (d. h. weiterleitet, Schritt S14) und die Zuweisung (d. h., a_i, b_i, c_i oder entsprechende Daten) in die Aktualisierung s_n+1 des Systemzustands s_n codiert (Schritt S16). Wie oben erörtert, kann die Statusaktualisierung je nach Systemanforderungen die signierten Zeitstempel A_i, B_i, C_i enthalten. Wenn keine Zeitstempel enthalten sind, kann die Statusaktualisierung parallel mit dem Signieren stattfinden, wodurch die Effizienz des Prozesses verbessert wird.
7. Eine öffentliche Schnittstelle, die ein Ereignis wie zum Beispiel einen Hash-Wert (zum Beispiel das Ereignis e_b,1, das mit dem Anwendungszustand b₁ {b₀₀, b₀₁} der Anwendung B verwandt ist, siehe 4), und optional den Zustand auf Anwendungsebene selbst (b₁ ≡ {b₀₀, b₀₁}) in eine signierte Zeitstempelstruktur B₁ umwandelt und, falls vorhanden, den Anwendungszustand (zu b₂ = {b₀₀, b₀₂}) und in allen Fällen den Systemzustand (von s₁ zu s₂) vorrückt. Bei anwendungsbezogenen Ereignissen kann es sich um verschlüsselte Hash-Werte wie die von Dokumenten oder Systemänderungen handeln, deren Protokollierung von einer Anwendung als angemessen angesehen wird. Somit wird derselbe Server zum Vorrücken sowohl des System- als auch des Anwendungszustands verwendet, z. B. unter Verwendung gleichartiger Einwegfunktionen, woraus sich die Zusammenfassung von b01/b02/s1/s2, usw. ergibt. Wenn die aufrufende Anwendung es wünscht, wird ihr der Systemzustand vor (s₁) und nach (s₂) dem Ausgeben des Zeitstempels B₁ bereitgestellt. In 4 werden s₁ und s₂ an die Anwendung B zurückgesendet, nachdem auf s₂ vorgerückt wurde (siehe auch Schritt S17 in 6). Gleichermaßen werden in diesem Beispiel s₃ und s₄ zurückgesendet, nachdem auf s₄ vorgerückt wurde. Die vertrauenswürdigen Werte t₁, t₂ können auch zurückgesendet werden. Man beachte, dass die Folge der Systemzustände aus Sicht der Anwendung, die sie auf ihrer eigenen Zustandskette sieht, möglicherweise nicht fortlaufend ist. In 1 unterscheidet sich zum Beispiel der Systemzustand nach dem Ausgeben von B₁ (Zustand s₂) von dem ursprünglichen Systemzustand s₃ vor dem Ausgeben von B₂ (d. h., dem logischen Nachfolger von B₁ aus Sicht der Anwendung).

2.2 Vorteile
Das aus den obigen Komponenten konstruierte System weist zahlreiche Vorteile auf, die jetzt zu erörtern sind.
2.2.1 Anwendungseinmaligkeit
Ein systemweiter Kettenzustand 15 mit fester Größe wird gespeichert. Konkreter bedeutet „feste Größe” einen verschlüsselten Hash-Wert, der unabhängig davon, wie viele Daten zusammengefasst wurden, durch eine feste Anzahl von Bits dargestellt wird. Der Kettenzustand 15 kann üblicherweise als {..., s_n, {A_i, B_i, ...}, s_n+1, ...} dargestellt werden, was die Systemebenenkette aus 1 widerspiegelt. Entsprechend kann das System auf eine große Anzahl von Anwendungen skalieren, da der Anwendungszustand dem Anwendungsspeicher zugehört. Dies ermöglicht es, dass das System Anwendungsfluktuationen mit anwendungsspezifischen Ressourcenlecks problemlos tolerieren kann.
2.2.2 Unbegrenztes Skalieren für mehrere Anwendungen
Da lediglich ein systemweiter Kettenzustand mit fester Größe gespeichert wird, kann das System auf eine große Anzahl von Anwendungen skalieren, da das Verfolgen des Anwendungszustands verteilt ist. Während Kettenwerte auf Anwendungsebene getrennt gepflegt werden können, werden Zustandsketten auf Anwendungsebene in eine einzelne Folge 15 von Zuständen auf Systemebene zusammengefasst. Diese Bindung ermöglicht einen Nichtverstoß sämtlicher einzelner Anwendungsketten, wenn eine Prüfung auf Systemebene durchgeführt wird.
Da Anwendungen außerdem mit jedem Zeitstempel einen aktuellen Systemzustand abfragen können, erhalten sie die entsprechende Fähigkeit, ihren eigenen Zustand nachzuweisen, indem sie zurück auf Zustände auf Systemebene verweisen. Eine derartige Bindung zwischen Anwendungen und dem System ist besonders vorteilhaft, wenn mehrere (sich gegenseitig nicht vertrauende) Anwendungen interagieren müssen und Rechtzeitigkeit/Besitz nachweisen müssen. Sie können sich somit vorteilhafterweise auf das vorliegende Schema verlassen.
2.2.3 Ununterbrochenes Verwalten von Signierern
Das Hinzufügen oder Entfernen von Signierern ist für Anwendungen transparent, da sie nicht direkt am Weiterleiten der Anforderung teilnehmen. Man kann zum Beispiel annehmen, dass eine unabhängige (offline) Verwaltungseinheit einen Signierer einrichtet (z. B. Schritt S11 in 6), der zu Beginn eines vollständigen Zyklus eingefügt wird (z. B. nach dem Erfassen von Zustand s₄ in 1). Man kann auch annehmen, dass das System ein „durch einen Signierer eingeführtes” Ereignis als erste Aktion signiert, wodurch das Einführen von neuen sich auf dem Signierer befindlichen Schlüsseln an die Prüfungskette gebunden wird.
2.2.4 Zentrales Zuweisen von ursprünglichen Anwendungszuständen
Zum Schutz des Systems vor versehentlichen Zustandskollisionen kann der Anwendungszustand in einen aktualisierten und einen festen Zustand aufgeteilt werden, und der Anwendungszustand-Aktualisierungsprozess aktualisiert nur den veränderlichen Teil: siehe z. B., b_1-3 = {b₀₀, b_01-03} in 4, wobei b₀₀ (der feste Zustand) nicht aktualisiert wird, angenommen, er wurde zentral zugewiesen. Trotzdem können Anwendungspräfixe ohne eine zentrale Registrierdatenbank zugewiesen werden. Der zentrale Zuteiler kann zum Beispiel genug über Host-Anwendungen wissen, um von diesen eine praktisch einmalige Kennung abzuleiten.
Praktische Systeme würden wahrscheinlich Zustandsableitungsfunktionen mit einer vernachlässigbaren Wahrscheinlichkeit einer Kollision verwenden; deshalb ist ein ausdrücklicher Kollisionsschutz für Systeme von Interesse, in denen auch ein Schutz vor unbekannten Bedrohungen erwünscht ist.
2.2.5 Komplexität des Zuteilers
Neben dem Aufwand für das Verwalten der Warteschlange kann das System ein zentrales Verwalten von Anwendungsanforderungen und deren eindeutige Zuteilung zu dem Satz von aktiven Signierern erfordern. Die meisten dieser Arbeitsschritte skalieren mit der Anzahl von Signiereinheiten, sobald Warteschlangenalgorithmen die Anforderungen mit der höchsten Priorität gewählt haben. Da die Anzahl von Signiereinheiten allgemein viel geringer ist als die Anzahl von anfordernden Anwendungen, insbesondere in hochzuverlässigen zentralisierten Umgebungen, führen Arbeitsschritte des Zuteilers nicht zu einem nennenswerten Verwaltungsaufwand.
2.3 Erweiterungen
Es werden nun mehrere Erweiterungen erörtert.
2.3.1 Mehrere Instanzen
Mehrere Kopien des vorliegenden Systems können zusammenarbeiten, wenn sie in verbundenen Systemen wie zum Beispiel Mainframe-Sysplexen eingesetzt werden. Die öffentlichen Signiererschlüssel derartiger Gruppen können zum Beispiel unter administrativer Steuerung synchronisiert werden, und es können administrative Zeitstempelzyklen periodisch eingefügt werden. Kreuzsignierungs-Zeitstempel zwischen mehreren Instanzen ermöglichen es mehreren Instanzen, gegenseitig den Taktversatz zu überwachen und das System zu alarmieren, wenn Instanzen abweichen.
2.3.2 Geschlüsselte Zustandsumwandlung
Wenn eine geschlüsselte Umwandlung wie zum Beispiel HMAC zum Vorrücken von Zuständen verwendet wird, erhält das System Immunität von durch Anwendungen hervorgerufenen Hash-Kollisionen, unabhängig von der Wahl der Hash-Funktion. Wenn man annimmt, dass Anwendungen den Zeitstempelzuteiler nicht beeinträchtigen, so ist ein durch den Zuteiler gespeicherter Zustandsumwandlungsschlüssel (STK, state-transformation key) ausreichend sicher für eine derartige Erweiterung.
Das Vorrücken des Systemzustands durch eine geschlüsselte Umwandlung fügt einen moderaten Verwaltungsaufwand hinzu, aber verhindert, dass Anwendungen den nächsten Systemzustand vorhersagen oder das System in bekannte Zustände bringen können. Theoretisch können in einem leicht belasteten System oder, wenn bösartige Anwendungen andere möglicherweise am Anfordern von Zeitstempeldiensten hindern können, sämtliche Daten, die zum Vorrücken des Systemzustands verknüpft werden, modelliert und vorhergesagt werden (da das System wahrscheinlich lediglich beruhend auf öffentlichen Datenstrukturen und Algorithmen aufbaut). Angenommen, bösartige Algorithmen können ihre Ereignisse adaptiv wählen, Zeitstempel mit hoher Genauigkeit erraten und andere Zustände durch Abfragen in Erfahrung bringen. Zustandsänderungen können hingegen durch Anwendungen lediglich beobachtet und beeinflusst, jedoch nicht vorhergesagt, werden, wenn eine geschlüsselte Umwandlung mit einem durch den Zuteiler verwalteten Schlüssel verwendet wird.
Man beachte, dass nicht synchronisierte Anwendungen A, B, C, ... in einer typischen Server- oder gemeinsam genutzten Umgebung wahrscheinlich die Ströme der Anforderungen ausreichend stören können, so dass derartige zustandssteuernde Angriffe nicht praktikabel sind. In anderen Systemen ist es vernünftig, eine geschlüsselte Umwandlung zum Vorrücken des Zustands anzuordnen.
Die Sicherheit von ausgegebenen Zeitstempeln ist unabhängig von der Vertraulichkeit des STK, da erstere durch sich im HSM befindliche Signierer erzeugt werden. Deshalb kann sich der STK innerhalb eines Host-Computers befinden und benötigt keinen Schutz innerhalb sicherer Hardware. Wenn eine Anwendung den Zuteiler möglicherweise beeinträchtigt, kann sie das System auf Infrastrukturebene auch anderweitig stören – nicht verschlüsselungstechnisch, aber durch Dienstverweigerung (denial-of-service) – folglich schützen vorliegende Ausführungsformen nicht speziell vor dem Verlust des STK.
2.4 Zusätzliche Überlegungen
Nachfolgend werden zusätzliche Einzelheiten der Umsetzung erörtert.
2.4.1 Trennung von Signierschlüsseln und Zustandsspeicher
Das System speichert Zustandsdaten über die relative Reihenfolge von Ereignissen außerhalb sicherer Signiereinheiten, aber speichert hochzuverlässige Signierschlüssel innerhalb sicherer Hardware. Als Folge müssen einige Ausführungsformen mindestens auf kooperierenden Host-Code vertrauen, um Ereignisse richtig anzuordnen, bevor sie an Signierer gesendet werden. Trotzdem verlässt sich sichere Hardware auf die Zusammenarbeit von Host-Computern für die Trennung/Verfolgung von Host-Einheiten (Prozesse, Aufträge, Threads) und ähnliche Konzepte, die für E/A-Einheiten nicht sichtbar sind. Somit weiten vorliegende Ausführungsformen diese Abhängigkeit auf eine Folge von Ereignissen aus, nicht nur auf einzelne Anforderungen. Da Signaturen gesamte Folgen verschlüsselt verbinden, wird eine sich falsch benehmende Host-Bibliothek während Systemprüfungen aufgedeckt. Trotzdem kann bösartiger Host-Code noch immer keine Signaturen und somit die authentifizierte Folge von deren Zeitstempeln fälschen, selbst wenn er Anforderungen lokal neu anordnen oder abändern kann.
2.4.2 Zeitsynchronisierung
Es wird angenommen, dass die Taktabweichung zwischen ausgebenden Signierern ausreichend gering ist, dass das System ohne inkonsistente Signierer-interne Zeiten laufen kann. Eine Taktabweichung in Signierern muss möglicherweise ausreichend gering bleiben, so dass die Zeitstempel im ungünstigsten Fall zwischen verschiedenen Signieren nicht widersprüchlich sind. Da das System Anforderungen synchronisiert, gibt es gut definierte Fenster, die selbst ungünstigste Ereignisse enthalten müssen. Mit Bezug auf 5 werden deshalb die Toleranz-(Zeit-)Fenster 210, 220 auf jeder Seite eines nominalen Zeitstempelfensters 230 bereitgestellt, wobei die Nebeneinanderstellung der Fensterkomponenten 210, 230 und 220 den vollständigen Zyklus 240 ergeben. In dem Beispiel aus 5 dient das Fenster 210 für „schnelle Signierer”, während das Fenster 220 für „langsame” Signierer dient.

1. Schnelle Signierer (Takte, die leicht vor der richtigen Zeit liegen), müssen Zeitstempel nach der Mitte der vorherigen Zuteilung erzeugen; und
2. Zeitstempel von langsamen Signierern müssen vor der Mitte der nächsten Zuteilung liegen.

Idealerweise würde man die Takte der Signierer synchronisieren, so dass sämtliche Zeitstempel Zeitwerte von innerhalb des nominalen Zeitfensters enthalten, d. h., nachdem Signaturen angefordert wurden, aber bevor sie durch den Zuteiler empfangen wurden. Das Gestatten einer Abweichung bis zur Mitte lockert die Anforderungen etwas und ist möglicherweise in hochzuverlässigen Umgebungen oder dort, wo eine derartige gelockerte Behandlung nicht notwendig ist, nicht gestattet.
Selbst mit gelockerten Garantien für den ungünstigsten Fall sind in verschiedenen Zyklen ausgegebene Zeitstempel garantiert monoton. Eine genaue Synchronisierung ist ein Preis, den man zum Garantieren einer relativen Reihenfolge zwischen von verschiedenen Signierern in demselben Zyklus ausgegebenen Zeitstempeln bezahlen muss. Da die Anforderungen sämtlicher Anwendungen einzeln serialisiert sind (mehrere Zeitstempel werden nicht für dieselbe Anwendung in demselben Zyklus ausgegeben), sind die Zeiten innerhalb sämtlicher Anwendungsketten durch die Bauart konsistent, da Anwendungen neue Zeitstempel nur anfordern, nachdem vorhergehende verarbeitet wurden.
Da ausgegebene Zeitstempel ununterbrochen überwacht werden können, können ein ,störender' Signierer (d. h. einer mit einer erheblichen Taktabweichung) deaktiviert und der Zeitstempelzyklus wiederholt werden, wobei sämtliche Anforderungen aus dem fehlgeschlagenen Zyklus erneut ausgegeben werden. Nach der Deaktivierung kann der Takt des abweichenden Signierers korrigiert werden.
Allgemeiner ausgedrückt empfängt der Server 10 Signaturanforderungen (6, Schritt S13) und speichert diese. Der Server entscheidet dann über den Zeitpunkt des Zuteilens der Anforderung zu den Signierern, vorzugsweise beruhend auf zeitlichen Zwangsbedingungen unter Verwendung z. B. von quantisierten Zeitspannen, wie oben erörtert wurde. Andere Schemata können ausgearbeitet werden. In nicht bevorzugten Varianten wartet der Server vor dem Zuteilen der Signatur zum Beispiel so lange, bis eine bestimmte Anzahl von Anforderungen erreicht wird. Noch andere Schemata können ausgearbeitet werden, die zeitliche Zwangsbedingungen nicht zwingend vorschreiben.
2.4.3 Kombinierte Zeitstempel und Hash-Ketten
Ausführungsformen, die sich sowohl auf Zeitwerte als auch auf Ketteninformationen gemeinsam mit Zeitstempeln verlassen, stellen sowohl die Wanduhrzeit als auch relative Reihenfolgenfunktionen bereit. Anwendungen können dann auswählen, welchen Nachweis sie bevorzugen. Trotzdem stellt nur die relative Anordnung durch eine Zustandskette einen Nichtverstoßnachweis bereit (und ist daher für einige Ausführungsformen ausreichend).
In Systemen, in denen sämtliche Signaturen nachgewiesen werden müssen, wie zum Beispiel Identitätsdokumente ausgebende Anwendungen, wären eine relative Anordnung und ein Verschlüsselungsschutz vor dem Entfernen/Einfügen von Zeitstempeln (beides wird von der vorliegenden Prüfungskette bereitgestellt) wertvoller als absolute Zeitwerte.
2.4.4 Auslastung der Signierer
Die Auslastung der Signierer kann maximiert werden, wenn die Signierlatenzzeit über die Signierer hinweg nahezu einheitlich ist, da eine Zeitstempelzykluszeit nahe dem ungünstigsten Wert gewählt werden kann.
Wenn der Host-Computer (Treiber) auch die Auslastung der Signierer überwacht, kann die Quantisierung ein vorhersagbares Auslastungsmuster erstellen, welches das System übernehmen kann, um die Verarbeitungslast zu optimieren.
2.4.5 Keine Signiererschlüsselsynchronisierung
Man kann annehmen, dass eine endliche Auswahl von Signierschlüsseln in einer Zertifikathierarchie dargestellt werden kann, und dass Anwendungen Schlüssel überprüfen können, die durch einen beliebigen zulässigen Schlüssel erstellt wurden. Wenn diese Annahme für die gesamte Zeitstempelinfrastruktur zutrifft, kann das System betrieben werden, ohne jemals Schlüssel über mehrere HSMs hinweg zu synchronisieren. In einer derartigen Umgebung kann man „beibehaltene Schlüssel” verwenden, Signierschlüssel, die das HSM, in dem sie erzeugt wurden, niemals verlassen.
In Systemen, in denen ein einzelner ausgebender Schlüssel sämtliche Zeitstempel ausgibt, werden normalerweise Schlüsselklonverfahren benötigt. Diese werden hier nicht weiter erörtert; man beachte, dass eine ausdrückliche Zeitquantisierung problemlos Punkte bietet, um Ausgabestellen hinzuzufügen/zu entfernen, also kann das System mühelos in jede beliebige Lösung zur Schlüsselsynchronisierung integriert werden.
2.4.6 Zustandsbasierte Prüfpunkte
Da ein System gemäß Ausführungsformen durch einen einzelnen, verschlüsselt verbundenen Satz von Zuständen entsteht, befinden sich in dem Zustand immer vorhergehende Aktionen. Deshalb kann eine Prüfung einen bestimmten Zustand als „als gut bekannt” ermitteln, was es ermöglicht, den Prüfungsverlauf zu kürzen. Wenn das System durch periodische Prüfungen verbessert wird und bekannte gute Zustände dokumentiert werden, können Archivprotokolle größentechnisch eingegrenzt werden (Anzahl von Zeitstempeln).
2.5 Vergleich mit bestehenden Systemen, Leistungsfähigkeiten
Nachfolgend wird ein Vergleich mit anderen sicheren Protokollierungssystemen angestellt.
2.5.1 Mehrere Signierer im Vergleich zwischen ohne/mit Schlüsselsynchronisierung
Eine typische Lösung für Skalierbarkeitsprobleme, insbesondere für Privatschlüssel-Arbeitsschritte ist die ausdrückliche Schlüsselsynchronisierung zwischen Gruppen von Signierschlüsseln, die dann untereinander austauschbar werden. Das Migrieren von Schlüsseln zwischen mehreren Signierern auf eine sichere Weise ist ein herausforderndes Problem. Vorliegende Ausführungsformen umgehen die gesamte Klasse von replizierungstechnischen Problemen durch Verbinden von verschiedenen Signierern über deren gemeinsamen Systemzustand. In einer praktischen Konfiguration werden Signiererzertifikate möglicherweise durch denselben steuernden Zertifikatsaussteller 40 zugewiesen, siehe 3, wodurch es erforderlich ist, dass Anwendungen zunächst den Signierschlüssel finden. Da jedoch beim Ersetzen von Signiererschlüsseln ein ähnliches Problem auftritt (wenn ein neuer Zeitstempel-Server hinzugefügt wird), wird er hier lediglich dafür benötigt, überprüfende Anwendungen auf die gelöste Instanz zu verweisen.
Im Wesentlichen stellen Ausführungsformen durch das Verwenden von mehreren unabhängigen Schlüsseln an Stelle von mehreren Instanzen mit synchronisierten Schlüsseln Skalierungsfunktionen bereit. Der einzige an Prüfungen überprüfende Anwendungen übertragene Verwaltungsaufwand liegt in der zusätzlichen Zertifikatsanalyse/-überprüfung, wenn man auf einen vorher unbekannten Signiererschlüssel trifft. In einer hochzuverlässigen Umgebung dient dieser zusätzliche Schritt (der auch zwischenspeicherbar ist) vorzugsweise zum Synchronisieren von Schlüsseln zwischen Signierern. In der Tat verbieten viele hochzuverlässige Signiererumgebungen das Exportieren von langlebigen Schlüsseln; trotzdem stellen Ausführungsformen eine skalierbare Lösung unter diesen Regeln bereit.
2.5.2 Signierschlüsselerneuerung
Die Verschlüsselungsforschung bezüglich sicherer Zeitstempel bevorzugt tendenziell eine stark verschlüsselte Entwicklung (Ersetzen) von Signierschlüsseln, da dies das Anfälligkeitsfenster von einzelnen Schlüsseln auf ein Mindestmaß beschränkt [Gur10]. Auf Grund der unvermeidbaren Serialisierung beschränkt eine häufige Schlüsselentwicklung jedoch auch die Skalierbarkeit auf mehrere Anwendungen. Dies ist kein Problem, wenn man nur eine einzelne Prüfungskette berücksichtigt. Dies würde jedoch in gemeinsam genutzten Systemen wie zum Beispiel Unternehmensservern ernsthafte Leistungsengpässe verursachen.
Vorliegende Ausführungsformen verwenden Privatschlüsselsignaturen, die es ermöglichen, das Schlüsselerneuerungsproblem in eine Zertifikat-Lebenszyklus-Verwaltung umzuwandeln, d. h., in ein Offline-Problem.
2.5.3 Leistungsfähigkeit
Die Verwendung von Privatschlüsselsignaturen ist allgemein weniger wirksam als auf Symmetrie beruhende Verfahren, was für einen gegebenen Signierer einen geringeren Durchsatz bedeutet. In der Praxis können hier mehrere Signierer einbezogen werden, um einen vergleichbaren Zieldurchsatz zu erhalten.
2.5.4 Native Integration mehrerer Anwendungsketten
Aktuell verwendete Prüfmechanismen konzentrieren sich tendenziell auf ein systemweites Protokoll oder behandeln Anwendungsereignisketten als unabhängige Einheiten ohne zusammengefasste Protokolle. Wenn die Fähigkeit zum Handhaben mehrerer Protokolle erwähnt wird, betrifft diese Fähigkeit allgemein das logische Verknüpfen von einzelnen Ereignisprotokollen, nicht aber eine systemweite Zusammenfassung des gesamten vergangenen Systemverlaufs [Hol06, Abschnitt 9].
In dem vorliegenden Fall sind Ausführungsformen der Erfindung so ausgelegt, dass sie eine unbegrenzte Anzahl von Protokollen auf Anwendungsebene integrieren.
2.5.5 Öffentliche Prüfprotokolle
Ausführungsformen des Systems wurden für uneingeschränkte Prüfungen entwickelt und zum Speichern nahezu all seiner Daten und sämtlicher erzeugter Protokolle außerhalb sicherer Hardware (3). Obwohl der Host-Computer mit einem Datenbankverwaltungsproblem belastet wird, ermöglicht es ein derartiger Ansatz, den in der Signierer-Hardware gepflegten Zustand auf ein Mindestmaß zu beschränken. Da es nicht erforderlich ist, sich auf in HSMs befindliche Protokolle zu verlassen, können Systeme gemäß den vorliegenden Ausführungsformen (im Prinzip) unbegrenzt skalieren, da Host-Ressourcen im Vergleich zu denen von sicheren Signiereinheiten im Wesentlichen unbegrenzt sind. Man beachte, dass das Anordnen von internen Protokollen einen belanglosen Dienstverweigerungsangriff gegen Signiereinheiten darstellt [CEN03, 5.1.1.3].
Im Fall von öffentlich überprüfbaren Prüfketten können keine auf MAC beruhenden Schemata verwendet werden, was folglich im Vergleich zu auf Symmetrie beruhender Protokollauthentifizierung zu einer Leistungseinbuße führt. Da jedoch mehrere Signierer einbezogen werden können, kann die Signiererleistung bei Bedarf skaliert werden. Wenn Prüfketten durch asymmetrische Techniken signiert werden, können durch das System bereitgestellte Prüfprotokolle im Gegensatz zu auf MAC beruhenden Verfahren mit Nichtverstoßgarantien ewig bestehen [GR01].
Als wichtige Folge des Speicherns weniger Signierer-interner Zustände können vorliegende Signierer auch andere Anwendungen für andere Rechner bereitstellen (angenommen, es gibt eine ausreichende Trennung zwischen Signierschlüsseln verschiedener Benutzer), und deshalb kann das vorliegende System in Ausführungsformen mit anderen Benutzern eines sicheren Coprozessors gemeinsam existieren. Vom Blickwinkel des Host-Computers aus können Coprozessoren mit mäßig ungenutzter Fähigkeit die vorliegenden Signierer für andere Rechner bereitstellen. Dies ermöglicht es, dass das System zu vielen bestehenden Systemen als inkrementelles Merkmal hinzugefügt werden kann.
2.6 Einzelheiten der technischen Umsetzung
Schließlich veranschaulicht 7 eine beispielhafte Ausführungsform einer computergestützten Einheit, die zum Umsetzen von Aspekten der vorliegenden Erfindung geeignet ist. Man wird verstehen, dass die hierin beschriebenen Verfahren weitgehend nicht dialogfähig sind und automatisiert laufen. In beispielhaften Ausführungsformen können die hierin beschriebenen Verfahren entweder in einem dialogfähigen, einem teilweise dialogfähigen oder nicht dialogfähigen System umgesetzt werden. Die hierin beschriebenen Verfahren können in Software (z. B. Firmware), Hardware oder einer Kombination daraus realisiert werden. In beispielhaften Ausführungsformen werden die hierin beschriebenen Verfahren in Software als ausführbares Programm realisiert und von einem digitalen Spezial- oder Universal-Computer wie zum Beispiel einem Personal Computer, einer Workstation, einem Minicomputer oder einem Mainframe-Computer ausgeführt. Das System 100 beinhaltet deshalb den Universalcomputer 101.
In beispielhaften Ausführungsformen beinhaltet der Computer 101 im Hinblick auf die Hardware-Architektur, wie in 7 gezeigt, einen Prozessor 105, den mit einer Speichersteuereinheit 115 verbundenen Speicher 110 und eine oder mehrere Eingabe- und/oder Ausgabe-(E/A-)Einheiten 140, 145 (oder Peripheriegeräte), die für den Datenaustausch über eine lokale Eingabe/Ausgabe-Steuereinheit 135 verbunden sind. Bei der Eingabe/Ausgabe-Steuereinheit 135 kann es sich um einen oder mehrere Busse oder andere drahtgebundene oder drahtlose Verbindungen, die nach dem Stand der Technik bekannt sind, handeln, wobei sie nicht darauf beschränkt ist. Die Eingabe/Ausgabe-Steuereinheit 135 kann zusätzliche Elemente aufweisen, die der Einfachheit halber weggelassen werden, wie zum Beispiel Steuereinheiten, Puffer (Cachespeicher), Treiber, Wiederholelemente und Empfänger zum Ermöglichen der Datenübertragung. Des Weiteren kann die lokale Schnittstelle Adress-, Steuer- und/oder Datenverbindungen beinhalten, um einen entsprechenden Datenaustausch zwischen den vorher genannten Komponenten zu ermöglichen. Wie hierin beschrieben, kann es sich bei den E/A-Einheiten 140, 145 um jede beliebige nach dem Stand der Technik bekannte allgemeine Verschlüsselungskarte oder Smartcard handeln.
Bei dem Prozessor 105 handelt es sich um eine Hardware-Einheit zum Ausführen von Software, insbesondere der in dem Speicher 110 gespeicherten. Bei dem Prozessor 105 kann es sich um jeden beliebigen kundenspezifischen oder im Handel erhältlichen Prozessor, eine Zentraleinheit (CPU), einen Hilfsprozessor unter mehreren dem Computer 101 zugehörigen Prozessoren, einen auf Halbleitern beruhenden Mikroprozessor (in Form eines Mikrochips oder Chipsatzes), einen Makroprozessor oder allgemein jede beliebige Einheit zum Ausführen von Software handeln.
Der Speicher 110 kann jeden beliebigen oder eine Kombination aus flüchtigen Speicherelementen (z. B. Direktzugriffsspeicher (RAM wie zum Beispiel DRAM, SRAM, SDRAM usw.)) und nichtflüchtigen Speicherelementen (z. B. ROM, einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM), einen elektronisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM), einen programmierbaren Nur-Lese-Speicher (PROM), Band, einen Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine Platte, eine Diskette, eine Kassette oder dergleichen usw.) beinhalten. Außerdem kann der Speicher 110 elektronische, magnetische, optische und/oder andere Typen von Speichermedien umfassen. Man beachte, dass der Speicher 110 eine verteilte Architektur aufweisen kann, wobei sich verschiedene Komponenten entfernt voneinander befinden, der Prozessor 105 aber darauf zugreifen kann.
Die Software in dem Speicher 110 kann ein oder mehrere separate Programme beinhalten, die jeweils eine geordnete Auflistung von ausführbaren Anweisungen zum Umsetzen von logischen Funktionen aufweisen. In dem Beispiel aus 7 beinhaltet die Software in dem Speicher 110 hierin beschriebene Verfahren gemäß beispielhaften Ausführungsformen und ein geeignetes Betriebssystem (OS) 111. Das OS 111 steuert im Wesentlichen das Ausführen anderer Computerprogramme wie zum Beispiel der hierin beschriebenen Verfahren und stellt eine Zeitplanung, eine Eingabe/Ausgabe-Steuerung, eine Datei- und Datenverwaltung, eine Speicherverwaltung und eine Datenübertragungssteuerung und verwandte Dienste bereit.
Die hierin beschriebenen Verfahren können in Form eines Quellprogramms, eines ausführbaren Programms (Objektcode), eines Skripts oder einer beliebigen anderen Einheit vorliegen, die einen Satz von durchzuführenden Anweisungen aufweist. Wenn das Programm in Form eines Quellprogramms vorliegt, muss es durch einen Compiler, einen Assembler oder einen Interpreter oder dergleichen übersetzt werden, der in dem Speicher 110 beinhaltet sein kann, damit er ordnungsgemäß in Verbindung mit dem OS 111 funktioniert. Des Weiteren können die Verfahren in einer objektorientierten Programmiersprache, die Datenklassen und Verfahren aufweist, oder einer prozeduralen Programmiersprache, die Routinen, Unterroutinen und/oder Funktionen aufweist, geschrieben werden.
In beispielhaften Ausführungsformen können eine herkömmliche Tastatur 150 und Maus 155 mit der Eingabe/Ausgabe-Steuereinheit 135 verbunden sein. Zu anderen Ausgabeeinheiten wie zum Beispiel den E/A-Einheiten 140, 145 können Eingabeeinheiten wie zum Beispiel ein Drucker, ein Scanner, ein Mikrofon und dergleichen zählen, aber nicht darauf beschränkt. Schließlich können zu den E/A-Einheiten 140, 145 ferner Einheiten gehören, die sowohl Eingaben als auch Ausgaben zum Beispiel an eine Netzwerkschnittstellenkarte (NIC) oder einen Modulator/Demodulator (zum Zugreifen auf andere Dateien, Einheiten, Systeme oder ein Netzwerk), einen Hochfrequenz-(HF-) oder anderen Transceiver, eine Telefonschnittstelle, eine Brücke, einen Router und dergleichen übertragen, aber nicht darauf beschränkt. Wie hierin beschrieben, kann es sich bei den E/A-Einheiten 140, 145 um jede beliebige nach dem Stand der Technik bekannte allgemeine Verschlüsselungskarte oder Smartcard handeln. Das System 100 kann ferner eine mit einer Anzeige 130 verbundene Anzeigesteuereinheit 125 beinhalten. In beispielhaften Ausführungsformen kann das System 100 ferner eine Netzwerkschnittstelle 160 zum Verbinden mit einem Netzwerk 165 beinhalten. Bei dem Netzwerk 165 kann es sich um ein IP-basierendes Netzwerk für den Austausch von Daten zwischen dem Computer 101 und jedem beliebigen externen Server, Client-Computer und dergleichen über eine Breitbandverbindung handeln. Das Netzwerk 165 sendet und empfängt Daten zwischen dem Computer 101 und externen Systemen. In beispielhaften Ausführungsformen kann es sich bei dem Netzwerk 165 um ein verwaltetes IP-Netzwerk, das von einem Diensteanbieter verwaltet wird, handeln. Das Netzwerk 165 kann drahtlos umgesetzt sein, z. B. unter Verwendung von Drahtlosprotokollen und -technologien wie zum Beispiel WiFi, WiMax usw. Bei dem Netzwerk 165 kann es sich auch um ein paketvermitteltes Netzwerk handeln, wie zum Beispiel ein lokales Netzwerk, ein Weitverkehrsnetz, das Internet oder einen anderen Typ von Netzwerkumgebung handeln. Bei dem Netzwerk 165 kann es sich um ein festes Drahtlosnetzwerk, ein drahtloses lokales Netzwerk (LAN), ein drahtloses Weitverkehrsnetz (WAN), ein persönliches Netzwerk (PAN), ein virtuelles Privatnetz (VPN), ein Intranet oder ein anderes geeignetes Netzwerksystem handeln und es beinhaltet eine Ausrüstung zum Empfangen und Senden von Signalen.
Wenn es sich bei dem Computer 101 um einen PC, eine Workstation, eine intelligente Einheit oder dergleichen handelt, kann die Software in dem Speicher 110 ferner ein Basic Input/Output System (BIOS) beinhalten (der Einfachheit halber weggelassen). Das BIOS ist im ROM gespeichert, so dass das BIOS ausgeführt werden kann, wenn der Computer 101 aktiviert wird.
Wenn sich der Computer 101 in Betrieb befindet, ist der Prozessor 105 so konfiguriert, dass er innerhalb des Speichers 110 gespeicherte Software ausführt, Daten zu und von dem Speicher 110 überträgt und allgemein Operationen des Computers 101 gemäß der Software steuert. Die hierin beschriebenen Verfahren und das OS 111 werden vollständig oder teilweise von dem Prozessor 105 gelesen, möglicherweise in dem Prozessor 105 gepuffert und dann ausgeführt.
Wenn die hierin beschriebenen Systeme und Verfahren wie in 7 gezeigt in Software realisiert sind, können die Verfahren auf einem beliebigen durch einen Computer lesbaren Medium wie zum Beispiel dem Speicher 120 zur Verwendung durch oder in Verbindung mit einem beliebigen computerverwandten System oder Verfahren gespeichert sein.
Der Fachmann wird verstehen, dass Aspekte der vorliegenden Erfindung als System, Verfahren oder Computerprogrammprodukt ausgeführt werden können. Entsprechend können Aspekte der vorliegenden Erfindung die Form einer vollständigen Hardware-Ausführungsform, einer vollständigen Software-Ausführungsform (darunter Firmware, im Speicher befindliche Software, Mikrocode, usw.) oder einer Software- und Hardware-Aspekte kombinierenden Ausführungsform annehmen, die hierin alle allgemein als „Schaltkreis”, „Modul” oder „System” bezeichnet sein können. Des Weiteren können Aspekte der vorliegenden Erfindung die Form eines auf einem oder mehreren durch einen Computer lesbaren Medien enthaltenen Computerprogrammprodukts annehmen, die durch einen Computer lesbaren Programmcode enthalten.
Es kann jede Kombination aus einem oder mehreren durch einen Computer lesbaren Medien verwendet werden. Bei dem durch einen Computer lesbaren Medium kann es sich um ein durch einen Computer lesbares Signalmedium oder ein durch einen Computer lesbares Speichermedium handeln. Bei einem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, eine derartige Vorrichtung oder Einheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu konkreteren Beispielen (eine nicht erschöpfende Liste) des durch einen Computer lesbaren Speichermediums gehören die folgenden: eine elektrische Verbindung mit einer oder mehreren Leitungen, eine mobile Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein Lichtwellenleiter, ein mobiler Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine optische Speichereinheit, eine magnetische Speichereinheit oder jede geeignete Kombination daraus. In dem Kontext dieses Dokuments kann es sich bei einem durch einen Computer lesbaren Speichermedium um jedes beliebige physische Medium handeln, das ein Programm enthalten bzw. speichern kann, das von oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Ausführung von Anweisungen verwendet wird.
Ein durch einen Computer lesbares Signalmedium kann ein weitergeleitetes Datensignal mit darin enthaltenem durch einen Computer lesbarem Programmcode beinhalten, zum Beispiel im Basisband oder als Teil einer Trägerwelle. Ein derartiges weitergeleitetes Signal kann eine beliebige Form aus einer Vielfalt an Formen annehmen, darunter elektromagnetische, optische bzw. jede geeignete Kombination daraus, jedoch nicht darauf beschränkt. Bei einem durch einen Computer lesbaren Signalmedium kann es sich um ein beliebiges durch einen Computer lesbares Medium handeln, das kein durch einen Computer lesbares Speichermedium ist und das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder Einheit zum Ausführen von Anweisungen übertragen, weiterleiten bzw. transportieren kann.
Auf einem durch einen Computer lesbaren Medium enthaltener Programmcode kann unter Verwendung eines beliebigen geeigneten Mediums übertragen werden, darunter drahtlos, drahtgebunden, Lichtwellenleiter-Kabel, HF usw. oder jede geeignete Kombination daraus, jedoch nicht auf diese beschränkt.
Computerprogrammcode für das Ausführen von Arbeitsschritten für Aspekte der vorliegenden Erfindung kann in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Java, Smalltalk, C++ o. ä. sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C” oder ähnliche Programmiersprachen. Der Programmcode kann vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters).
Aspekte der vorliegenden Erfindung werden oben unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Funktionsschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder durch Computerprogrammanweisungen ausgeführt werden kann. Diese Computerprogrammanweisungen können dem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte erzeugen.
Die Computerprogrammanweisungen können auch auf einen Computer oder eine andere programmierbare Datenverarbeitungsvorrichtung bzw. andere Einheiten geladen werden, um das Ausführen einer Folge von Prozessschritten auf dem Computer, der anderen programmierbaren Vorrichtung bzw. den anderen Einheiten zu veranlassen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer oder einer anderen programmierbaren Vorrichtung ausgeführten Anweisungen Verfahren zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder angegebenen Funktionen/Schritte erzeugen.
Die Ablaufpläne und die Blockschaltbilder bzw. Schaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaltbildern bzw. Schaubildern ein Modul, ein Segment oder einen Teil eines Codes darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) aufweisen. Es sei auch angemerkt, dass in einigen alternativen Ausführungen die in den Blöcken angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden können. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaltbilder bzw. Schaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaltbildern bzw. Schaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder durch Kombinationen aus Spezial-Hardware und Computeranweisungen.
Obwohl die vorliegende Erfindung unter Bezugnahme auf bestimmte Ausführungsformen beschrieben wurde, werden Fachleute verstehen, dass diverse Änderungen durchgeführt und Elemente durch gleichwertige ersetzt werden können, ohne von dem Umfang der vorliegenden Erfindung abzuweichen. Außerdem können viele Abwandlungen vorgenommen werden, um eine bestimmte Situation den Lehren der vorliegenden Erfindung anzupassen, ohne von dem Umfang dieser abzuweichen.
Deshalb ist es beabsichtigt, dass die vorliegende Erfindung nicht auf die bestimmte beschriebene Ausführungsform beschränkt ist, sondern dass die vorliegende Erfindung sämtliche Ausführungsformen beinhaltet, die in den Umfang der beigefügten Ansprüche fallen. Man könnte sich zum Beispiel auf verschiedene Zuteilungsschemata verlassen, die auf zeitlichen Zwangsbedingungen oder einer kritischen Anzahl von empfangenen Anforderungen beruhen. Es können auch verschiedene Strukturen für einen aktualisierten Systemzustand, Skalare, Vektoren oder Matrizen usw., in Betracht gezogen werden. Obwohl auf eine Funktion „f” Bezug genommen wurde, was das Berechnen eines aktualisierten Zustands angeht, ist es außerdem klar, dass Algorithmen verwendet werden können, um einen aktualisierten Systemzustand zu erreichen, die sich nicht ausdrücklich auf eine bestimmte Funktion verlassen, sondern z. B. auf eine Folge von Schritten usw.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

CEN Standardisierungssystem für die Informationsgesellschaft. CWA 14167-4: Cryptographic Module for CSP Signing Operations Protection Profile, Oktober 2003. Version: 0.28. CEN/ISSS Electronic Signature (E-SIGN) Workshop [0007]
Rosario Gennaro und Pankaj Rohatgi. How to sign digital streams. Information and Computation, 165(1): 100–116, 2001 [0007]
Emil Gurevitch. Providing a tamper-evident layer for logs using secure hardware. Academic dissertation. IMM-B.Eng.-2010-34, 2010, Technische Universität Dänemark (DTU) [0007]
Jason E. Holt. Logcrypt: forward security and public verification for secure audit logs. In ACSW Frontiers '06: Proceedings of the 2006 Australasian workshops an Grid computing and e-research, Seiten 203–211. Australian Computer Society, Inc., 2006 [0007]

Claims

Verfahren zum Ermöglichen des Prüfens von digitalen Signaturen, das in einem computergestützten System (1) umgesetzt wird, das einen Server (10) aufweist, der mit Anwendungen (A, B, C) Daten austauscht, und das die folgenden Schritte an dem Server aufweist: – Empfangen (S13) einer oder mehrerer von einer oder mehreren der Anwendungen ausgegebenen Signaturanforderungen (a_i, b_i, c_i); – Weiterleiten (S14) von ersten Daten, die den empfangenen Signaturanforderungen entsprechen, an eine oder mehrere Signiereinheiten (Sig_1-4) zum anschließenden Signieren der ersten Daten; – Speichern (S16) eines aktualisierten Systemzustands (s_n+1), der unter Verwendung einer Funktion aus Folgendem berechnet (S15) wurde: – einem Bezugssystemzustand (s_n); und – zweiten Daten (a_i, b_i, c_i, A_i, B_i, C_i), die den empfangenen Signaturanforderungen entsprechen, wobei der Bezugssystemzustand und der aktualisierte Systemzustand die Signaturanforderungen bestätigen; und – Wiederholen der obigen Schritte (S12 bis S16) unter Verwendung des aktualisierten Systemzustands (s_n+1) als neuen Bezugssystemzustand.
Verfahren nach Anspruch 1, wobei das Verfahren ferner an dem Server aufweist: – Empfangen (S22) von Antworten von den Signiereinheiten als Reaktion auf das Weiterleiten der ersten Daten, und wobei die zweiten Daten dritte Daten (A₁, B_i, C_i) aufweisen, die Daten in den empfangenen Antworten entsprechen.
Verfahren nach Anspruch 2, wobei die ersten weitergeleiteten Daten höchstens eine Signaturanforderung (a_i, b_i, c_i) pro anfordernder Anwendung (A, B, C) beibehalten.
Verfahren nach Anspruch 1, 2 oder 3, wobei der aktualisierte Systemzustand (s_n+1) unter Verwendung einer Funktion aus einem vorhergehenden Systemzustand und zweiten Daten (a_i, b_i, c_i, A_i, B_i, C_i), die von mindestens zwei einzelnen Anwendungen empfangenen Signaturanforderungen entsprechen, berechnet (S15) wird.
Verfahren nach Anspruch 4, wobei: – das Speichern das Speichern eines Satzes von zusammengefassten Daten aufweist, die man durch das Zusammenfassen (S16) der zweiten Daten in eine Folge (15) von den Bezugssystemzustand und den aktualisierten Systemzustand aufweisenden Systemzuständen erhält, und – das Zusammenfassen vorzugsweise das Verschachteln (S16) der zweiten Daten in die Folge von Systemzuständen aufweist.
Verfahren nach einem der Ansprüche 1 bis 5, wobei das Weiterleiten das Zuteilen (S14) eines Satzes von ersten Datenteilmengen zu entsprechenden Signiereinheiten (30, Sig_n) zum anschließenden Signieren der ersten Datenteilmengen aufweist, wobei jede der ersten Datenteilmengen entsprechenden an dem Server empfangenen Signaturanforderungen entspricht.
Verfahren nach Anspruch 6, wobei der Zeitpunkt des Zuteilens beruhend auf zeitlichen Zwangsbedingungen an dem Server entschieden wird, wobei vorzugsweise quantisierte Zeitspannen verwendet werden.
Verfahren nach Anspruch 7, ferner aufweisend – Verzögern (S13) der einen oder mehreren empfangenen Signaturanforderungen (a_i, b_i, c_i), vor dem Weiterleiten (S14) der entsprechenden ersten Daten, während vorher weitergeleitete erste Daten an der einen oder den mehreren Signiereinheiten (Sig_1-4) signiert werden.
Verfahren nach einem der Ansprüche 1 bis 8, wobei: – das Speichern das Speichern eines Satzes von zusammengefassten Daten aufweist, die man durch das Zusammenfassen (S16) der zweiten Daten in eine Folge (15) von den Bezugssystemzustand und den aktualisierten Systemzustand aufweisenden Systemzuständen erhält, wobei das Verfahren ferner an dem Server aufweist: – Empfangen einer Abfrage von einer (A) der Anwendungen; – Antworten auf die eine der Anwendungen beruhend auf dem Satz von zusammengefassten Daten.
Verfahren nach einem der Ansprüche 1 bis 9, ferner aufweisend an dem Server: – Empfangen (S22) von Antworten von den Signiereinheiten als Reaktion auf das Weiterleiten der ersten Daten, wobei die Antworten vertrauenswürdige Zeitdaten (t_i) aufweisen.
Verfahren nach einem der Ansprüche 1 bis 10, wobei es sich bei den Signiereinheiten um Hardware-Sicherheitsmodule handelt.
Verfahren nach einem der Ansprüche 1 bis 11, ferner aufweisend: – Prüfen (S41) der Signaturanforderungen oder verwandten Daten beruhend auf dem Bezugssystemzustand und dem aktualisierten Systemzustand.
Verfahren nach einem der Ansprüche 1 bis 12, wobei es sich bei der Funktion um eine nicht umkehrbare Funktion handelt.
Computergestütztes System (1), das einen Server (10) aufweist, der so eingerichtet ist, dass er mit Anwendungen (A, B, C) und Signiereinheiten (30) Daten austauscht, wobei der Server so konfiguriert ist, dass er die Schritte des Verfahrens gemäß einem der Ansprüche 1 bis 10 umsetzt.
Sich auf einem durch einen Computer lesbaren Medium befindliches Computerprogramm, das Anweisungen zum Veranlassen eines computergestützten Systems (1) zum Umsetzen der Schritte aus einem der Ansprüche 1 bis 10 aufweist.