-
Die
Erfindung betrifft ein Verfahren zum Prüfen einer auf einer
ersten Einrichtung auszuführenden oder zu installierenden
Version eines Softwareproduktes.
-
Asymmetrische
kryptographische Verschlüsselungsverfahren werden herkömmlicherweise
zur digitalen Signatur von Codes, Software oder Software-Produkten
eingesetzt. Mittels der digitalen Signatur werden die Quelle und
die Authentizität der Software – im Weiteren unter
dem Begriff "Integrität" zusammengefasst – überprüft.
Dabei werden die digitalen Signaturen dazu eingesetzt, die Software
vor ihrer Installation zu überprüfen. Nach der
Installation werden die digitalen Signaturen auch dazu eingesetzt
sicherzustellen, dass die Software nicht verändert wurde.
Solche Verfahren zum Signieren von Software sind beispielsweise
unter http://www.microsoft.com/whdc/winlogo/drvsign/best_practices.mspx und http://www.java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/rsa_signing.html veröffentlicht.
-
Für
die digitale Signatur werden herkömmlicherweise sogenannte
Zertifikate verwendet. Diese Zertifikate werden von zertifizierten
Einrichtungen, sogenannten Certification Authorities, bereitgestellt. Solche
Zertifikate haben herkömmlicherweise eine Gültigkeitsdauer
von ein bis drei Jahren. Allerdings sind auch Zertifikate für
den einmaligen Einsatz bekannt. Die Verwendung eines Zertifikates
ist beispielsweise aus http://www.verisign.com/stellent/groups/public/documents/data_sheet/003201.pdf oder
aus http://www.verisign.com/support/tic/per/whitepaper.htm bekannt.
-
Allerdings
wird die Software oftmals für eine Lebensdauer entwickelt,
welche länger als die Gültigkeitszeitdauer eines
Zertifikates ist. Aus diesem Grund bieten Zeitstempeldienste Zeitstempel
an, um den Zeitpunkt der Signierung zu beurkunden. Die Signatur
wird dann herkömmlicherweise als gültig angenommen,
wenn das Zertifikat zum Zeitpunkt, welcher durch den Zeitstempel
beurkundet wird, gültig war.
-
Die
digitalen Signaturen können beispielsweise stets dann überprüft
werden, wenn die entsprechende Software geöffnet oder ausgeführt
wird. Des Weiteren ist bekannt, ein Update von Software mittels
einer Online-Anfrage beim Vertreiber der Software durchzuführen,
wenn die entsprechende Software auf dem PC des Anwenders oder Nutzers
gestartet wird. Wenn eine neue Version der Software auf dem Server
des Vertreibers gefunden wird, kann diese auf dem PC des Anwenders
installiert werden. Wenn allerdings keine Online-Verbindung verfügbar ist,
muss die installierte Version der Software weiter verwendet werden.
Auch für einige solcher Software-Produkte oder Software
ist eine digitale Signatur notwendig, um die vom Server des Vertreibers
heruntergeladene Software korrekt installieren zu können. Dies
ist beispielsweise auch unter http://www.microsoft.com/whdc/winlogo/drvsign/best_practices.mspx beschrieben.
-
Eine
Aufgabe der vorliegenden Erfindung besteht demnach darin, eine einfache
und insbesondere kostengünstige Möglichkeit bereitzustellen,
die Integrität und die Aktualität eines auf einer
Einrichtung eines Anwenders, beispielsweise auf einem PC, auszuführenden
oder zu installierenden Softwareproduktes zu prüfen.
-
Eine
weitere Aufgabe der vorliegenden Erfindung ist es, eine einfache
und insbesondere kostengünstige Möglichkeit bereitzustellen,
die Integrität und die Aktualität eines auf der
Einrichtung des Anwenders auszuführenden oder zu installie renden Softwareproduktes
ohne eine aktuell bestehende Online-Verbindung zu prüfen.
-
Erfindungsgemäß wird
zumindest eine dieser gestellten Aufgaben durch ein Verfahren zum Prüfen
einer auf einer ersten Einrichtung auszuführenden oder
zu installierenden Version eines Softwareproduktes gelöst.
-
Demgemäß wird
ein Verfahren zum Prüfen einer auf einer ersten Einrichtung
auszuführenden oder zu installierenden Version eines Softwareproduktes
vorgeschlagen, welches folgende Schritte aufweist:
- a) Empfangen der Version des Softwareproduktes und einer zu
der Version des Softwareproduktes zugehörigen, mittels
eines privaten Schlüssels erzeugten digitalen Signatur;
- b) Empfangen eines Zertifikats, welches zumindest den zu dem
privaten Schlüssel zugehörigen öffentlichen
Schlüssel und eine Angabe des Gültigkeitszeitrahmens
des öffentlichen Schlüssels aufweist;
- c) Überprüfen einer Gültigkeit des öffentlichen Schlüssels
in Abhängigkeit der Angabe des Gültigkeitszeitrahmens
zur Bereitstellung eines Aktualitäts-Prüfungsergebnisses;
- d) Überprüfen einer Gültigkeit der
empfangenen digitalen Signatur zur Bereitstellung eines Integritäts-Prüfungsergebnisses;
- e) Bestimmen einer Aktualität der empfangenen Version
des Softwareproduktes in Abhängigkeit des bereitgestellten
Aktualitäts-Prüfungsergebnisses; und
- f) Bestimmen einer Integrität der empfangenen Version
des Softwareproduktes in Abhängigkeit des bereitgestellten
Integritäts-Prüfungsergebnisses.
-
Ein
Vorteil der Erfindung liegt darin, dass die Aktualität
einer auszuführenden oder zu installierenden Version eines
Softwareproduktes auf der ersten Einrichtung des Anwenders, z. B.
einem PC des Anwenders, überprüfbar ist. Vorteilhafterweise
sind dabei keine zusätzlichen Mittel, wie beispielswei se
eine Online-Abfrage beim Vertreiber des Softwareproduktes, notwendig.
Erfindungsgemäß wird das für die Integritätsprüfung
mit der digitalen Signatur inhärent vorhandene Zertifikat,
dabei insbesondere die Angabe des Gültigkeitszeitrahmens
des öffentlichen Schlüssels, genutzt. Somit ist
das erfindungsgemäße Verfahren unabhängig
von einer bestehenden oder unterbrochenen Online-Verbindung des
PCs des Anwenders. Weiter ist das erfindungsgemäße
Verfahren durch die Ausnutzung eines inhärent vorhandenen Mittels
kostengünstig und einfach durchführbar.
-
Weiter
wird durch die Überprüfung der Aktualität
der Version des Softwareproduktes auf der ersten Einrichtung ein
sogenanntes Roll-Back der Versionen des Softwareproduktes verhindert,
da bei abgelaufenen Versionen das Aktualitätsprüfungsergebnis als
ein negatives Aktualitätsprüfungsergebnis interpretiert
wird.
-
Ein
weiterer Vorteil liegt darin, dass beim Einsatz des erfindungsgemäßen
Verfahrens zwar für jede Version des Softwareproduktes
bzw. für jeden Software-Release ein separater Schlüssel
und ein separates Zertifikat eingesetzt wird, es aber ermöglicht
ist, dass ein jedes Software-Release für verschiedene Plattformen
oder in verschiedenen Konfigurationen gleichzeitig eingesetzt wird.
Dies wird erfindungsgemäß dadurch möglich,
dass ein Schlüssel für mehr als einen Signaturprozess
verwendet werden kann.
-
Vorteilhafte
Ausgestaltungen und Weiterbildungen der Erfindung ergeben sich aus
den Unteransprüchen sowie der Beschreibung und der Bezugnahme
auf die Zeichnungen.
-
Gemäß einer
bevorzugten Ausgestaltung der Erfindung beinhaltet der Gültigkeitszeitrahmen des öffentlichen
Schlüssels einen Gültigkeitszeitrahmen des privaten
Schlüssels und/oder einen Update-Zeitrahmen für
eine Angabe eines notwendigen Updates der Version des Softwareproduktes,
wobei der Gültigkeitszeitrahmen des öffentlichen
Schlüssels und der Gültig keitszeitrahmen des privaten Schlüssels
zeitgleich beginnen und der Gültigkeitszeitrahmen des öffentlichen
Schlüssels und der Update-Zeitrahmen zeitgleich enden.
-
Gemäß einer
weiteren bevorzugten Ausgestaltung enthält das Zertifikat
den öffentlichen Schlüssel, die Angabe der Gültigkeitsdauer
des öffentlichen Schlüssels, einen Namen des Softwareproduktes,
eine Versionsangabe des Softwareproduktes, eine Angabe des Gültigkeitszeitrahmens
des privaten Schlüssels und/oder eine Angabe des Gültigkeitszeitrahmens
des Update-Zeitrahmen.
-
Gemäß einer
bevorzugten Weiterbildung der Erfindung beinhaltet der Verfahrensschritt
c) ein Überprüfen der Gültigkeit des öffentlichen
Schlüssels zur Bereitstellung des Aktualitäts-Prüfungsergebnisses
zur Angabe der Aktualität der Version des Softwareproduktes
in Abhängigkeit der Angabe des Gültigkeitszeitrahmens
des öffentlichen Schlüssels oder in Abhängigkeit
des Gültigkeitszeitrahmens des öffentlichen Schlüssels
und eines von einer dritten Einrichtung bereitgestellten Rückrufstatus
des jeweiligen Zertifikats für die Version des Softwareproduktes.
-
Wenn
beispielsweise die erste Einrichtung den PC eines Anwenders und
die zweite Einrichtung einen Server eines Vertreibers der Softwareprodukte darstellt,
so kann die dritte Einrichtung eine Zertifizierungsautorität
sein. Vorteilhafterweise kann insbesondere durch die zweite Möglichkeit
der obig erläuterten Ausgestaltungen der Erfindung sichergestellt werden,
dass der Anwender eine Anzeige erhält, dass das von ihm
ausgeführte oder installierte Softwareprogrammprodukt nicht
mehr aktuell ist, wenn die Zertifizierungsautorität einen
Rückrufstatus für das jeweilige eingesetzte Zertifikat
veröffentlicht. Der Rückruf kann auch von dem
Vertreiber initiiert werden, welcher dann der Zertifizierungsautorität
den Rückruf bekannt gibt, welche im Folgenden den Rückrufstatus
für dieses Zertifikat veröffentlicht. Durch den
Einsatz des Rückrufstatus für das Aktualitäts-Prüfungsergebnis
kann somit ermög licht werden, dass der Anwender über
neue Updates oder neue Versionen des Softwareproduktes benachrichtigt
wird, auch wenn die Gültigkeitsdauer des öffentlichen
Schlüssels noch nicht abgelaufen ist.
-
Gemäß einer
weiteren bevorzugten Weiterbildung beinhaltet der Verfahrensschritt
d) ein Durchführen einer Verifikation der empfangenen,
mittels der digitalen Signatur signierten Version des Softwareproduktes
zur Bereitstellung des Integritäts-Prüfungsergebnisses.
-
Gemäß einer
weiteren bevorzugten Ausgestaltung wird das Aktualitäts-Prüfungsergebnis
als ein negatives Aktualitäts-Prüfungsergebnis
interpretiert, wenn der Zeitpunkt des Startens oder Installierens
der Version des Softwareproduktes auf der ersten Einrichtung später
als ein Ende des Gültigkeitszeitrahmens des öffentlichen
Schlüssels ist.
-
Gemäß einer
weiteren bevorzugten Ausgestaltung wird das Aktualitäts-Prüfungsergebnis
als ein negatives Aktualitäts-Prüfungsergebnis
interpretiert, wenn der bereitgestellte Rückrufstatus angibt, dass
das jeweilige Zertifikat für die entsprechende Version
des Softwareproduktes zurückgerufen ist, oder der Zeitpunkt
des Startens oder Installierens der Version des Softwareproduktes
auf der ersten Einrichtung später als ein Ende des Gültigkeitszeitrahmens
des öffentlichen Schlüssels liegt.
-
Gemäß einer
weiteren bevorzugten Ausgestaltung wird bei einem positiven Aktualitäts-Prüfungsergebnis
und wenn der Zeitpunkt des Startens oder Installierens der Version
des Softwareproduktes auf der ersten Einrichtung später
als ein Beginn des Update-Zeitrahmens ist, zumindest ein Teil einer
aktuellen Version des Softwareproduktes und eine zugehörige
aktuelle digitale Signatur der aktuellen Version des Softwareproduktes
oder ausschließlich eine aktuelle digitale Signatur der
aktuellen Version des Softwareproduktes als Aktualitäts- Bestätigung
von der zweiten Einrichtung mittels eines Netzwerks bereitgestellt.
-
Aktualisiert
der Vertreiber des Softwareproduktes einen Teil oder das ganze Softwareprodukt, so
kann der Anwender den aktualisierten Teil oder die gesamte aktuelle
Version des Softwareproduktes mit einer zugehörigen aktuellen
digitalen Signatur der aktuellen Version des Softwareproduktes von
dem Server des Vertreibers herunterladen. Dem Vertreiber des Softwareproduktes
ist es allerdings auch ermöglicht, ein nicht mehr als aktuell
bezeichnetes Softwareprodukt erneut zur Installation und zum Start freizugeben.
Hierzu kann der Vertreiber des Softwareproduktes ausschließlich
eine aktuelle digitale Signatur bereitstellen, welche der Anwender
dann von dem Server des Vertreibers herunterladen kann.
-
Gemäß einer
weiteren bevorzugten Weiterbildung sind nach den Schritten a) bis
f) folgende Schritte vorgesehen:
- – bei
einem positiven Integritäts-Prüfungsergebnis und
einem positiven Aktualitäts-Prüfungsergebnis wird
die Version des Softwareproduktes auf der ersten Einrichtung gestartet
oder installiert;
- – bei einem negativen Integritäts-Prüfungsergebnis
wird die Version des Softwareproduktes auf der ersten Einrichtung
nicht gestartet und nicht installiert; und/oder
- – bei einem positiven Integritäts-Prüfungsergebnis
und einem negativen Aktualitäts-Prüfungsergebnis
wird zumindest ein Teil einer von der zweiten Einrichtung mittels
eines Netzwerks bereitgestellten aktuellen Version des Softwareproduktes und
eine zugehörige aktuelle digitale Signatur oder ausschließlich
eine von der zweiten Einrichtung mittels des Netzwerks bereitgestellte,
aktuelle digitale Signatur der aktuellen Version des Softwareproduktes
als Aktualitäts-Bestätigung der auf der ersten
Einrichtung vorhanden Version des Softwareprodukts von der ersten
Einrichtung geladen.
-
Gemäß einer
weiteren bevorzugten Weiterbildung ist nach den Schritten a) bis
f) folgender Schritt vorgesehen:
- – bei
einem positiven Integritäts-Prüfungsergebnis,
einem positiven Aktualitäts-Prüfungsergebnis und
wenn der Zeitpunkt des Startens oder Installierens der Version des
Softwareproduktes auf der ersten Einrichtung später als
ein Beginn des Update-Zeitrahmens ist, wird die Version des Softwareproduktes
auf der ersten Einrichtung gestartet oder installiert und/oder es
wird zumindest ein Teil einer von der zweiten Einrichtung mittels
eines Netzwerks bereitgestellten aktuellen Version des Softwareproduktes
und eine zugehörige aktuelle digitale Signatur oder ausschließlich
eine von der zweiten Einrichtung mittels des Netzwerks bereitgestellte,
aktuelle digitale Signatur der aktuellen Version des Softwareproduktes
als Aktualitäts-Bestätigung der auf der ersten
Einrichtung vorhanden Version des Softwareprodukts von der ersten
Einrichtung geladen.
-
Gemäß einer
weiteren bevorzugten Ausgestaltung werden für jede bereitgestellte
Version des Softwareproduktes der Gültigkeitszeitrahmen
des öffentlichen Schlüssels, der Gültigkeitszeitrahmen
des privaten Schlüssels und/oder der Update-Zeitrahmen festgelegt.
-
Durch
diese Ausgestaltung der Erfindung ist es dem Vertreiber des Softwareproduktes
ermöglicht, einen Zeitplan oder einen Schedule für
die Aktualisierungen der Versionen seines Softwareproduktes zu bilden.
Diesen Zeitplan kann der Vertreiber auch unter Verwendung des Zertifikats
vertrauenswürdig an die Anwender weiterverteilen.
-
Gemäß einer
weiteren bevorzugten Ausgestaltung werden die verschiedenen digitalen
Signaturen und die zu den jeweiligen digitalen Signaturen zugehörigen
Zertifikate der verschiedenen Versionen des Softwareproduktes zur
Bereitstellung eines Log-Files der Versionen des Softwareproduktes durch
die erste Einrichtung und/oder die zweite Einrichtung gespeichert.
-
Durch
die Bereitstellung des Log-Files ist ein Dokument mit einer vertrauenswürdigen
Versions-Historie bereitgestellt.
-
Gemäß einer
weiteren bevorzugten Ausgestaltung werden bei einem positiven Integritäts-Prüfungsergebnis
und einem negativen Aktualitäts-Prüfungsergebnis
oder bei einem positiven Integritäts-Prüfungsergebnis,
einem positiven Aktualitäts-Prüfungsergebnis und
wenn der Zeitpunkt des Startens oder Installierens der Version des
Softwareproduktes auf der ersten Einrichtung später als
ein Beginn des Update-Zeitrahmens ist, der zumindest eine Teil der
von der zweiten Einrichtung mittels des Netzwerkes bereitgestellten
aktuellen Version des Softwareproduktes und die zugehörige
aktuelle digitale Signatur oder ausschließlich die aktuelle
digitale Signatur als Aktualitäts-Bestätigung
in Abhängigkeit einer Eingabe des Nutzers der ersten Einrichtung
geladen.
-
Durch
diese Ausgestaltung ist sichergestellt, dass der Nutzer oder Anwender
der Entscheidungsträger bleibt, welche Software oder Softwareprodukte auf
seiner ersten Einrichtung, beispielsweise seinem PC, ausgeführt
oder installiert werden.
-
Gemäß einer
weiteren bevorzugten Ausgestaltung wird bei einem positiven Integritäts-Prüfungsergebnis
und einem negativen Aktualitäts-Prüfungsergebnis
bei einem Ausbleiben einer Eingabe des Nutzers innerhalb eines vorbestimmten
Zeitfensters oder einer Eingabe des Nutzers, welche angibt, dass
kein Update der Version des Softwareproduktes erfolgen soll, die
Version des Softwareproduktes der ersten Einrichtung nicht installiert
oder in einem vorbestimmten eingeschränkten Funktionsumfang
ausgeführt.
-
Gemäß einer
weiteren bevorzugten Ausgestaltung werden für jede Version
des Softwareproduktes ein eigener privater Schlüssel mit
festgelegtem Gültigkeitszeitrahmen und ein eigenes Zertifikat bereitgestellt
und verwendet.
-
Gemäß einer
weiteren bevorzugten Weiterbildung beinhaltet der Verfahrensschritt
d) ein Überprüfen, ob ein Zeitpunkt der Erstellung
der jeweiligen digitalen Signatur, welcher mittels eines in der
digitalen Signatur beinhalteten Zeitstempels repräsentiert wird,
innerhalb des Gültigkeitszeitrahmens des privaten Schlüssels
liegt.
-
Das
Zertifikat kann weiter einen Hash-Algorithmus und/oder einen Signatur-Algorithmus
umfassen.
-
Vorzugsweise
umfasst die digitale Signatur zumindest einen mit dem privaten Schlüssel
eines Schlüsselpaares verschlüsselten Hash-Wert
des Softwareproduktes.
-
Der
Verfahrensschritt a) beinhaltet insbesondere folgende Schritte:
- – Bereitstellen der Version des Softwareproduktes durch
eine einem Hersteller des Softwareproduktes zugeordneten zweiten
Einrichtung;
- – Bereitstellen des Zertifikates für die Version
des Softwareproduktes durch eine einer Zertifizierungsautorität
zugeordneten dritten Einrichtung;
- – Signieren der bereitgestellten Version des Softwareproduktes
mittels zumindest des in dem Zertifikat enthaltenen Hash-Algorithmus;
- – Übertragen der mittels der digitalen Signatur
signierten Version des Softwareproduktes von der zweiten Einrichtung
an die erste Einrichtung; und
- – Übertragen des Zertifikats von der zweiten
Einrichtung oder der dritten Einrichtung an die erste Einrichtung.
-
Das
Signieren der bereitgestellten Version des Softwareproduktes umfasst
vorzugsweise:
- – Berechnen zumindest
eines Hash-Wertes der Version des Softwareproduktes in Abhängigkeit des
in dem Zertifikat enthaltenen Hash-Algorithmus; und
- – Verschlüsseln des zumindest einen berechneten
Hash-Wertes mittels des privaten Schlüssels des Schlüsselpaares.
-
Das Übertragen
der signierten Version des Softwareproduktes von der zweiten Einrichtung
an die erste Einrichtung beinhal tet insbesondere das Übertragen
der bereitgestellten Version des Softwareproduktes und des zumindest
einen verschlüsselten Hash-Wertes.
-
Ferner
wird ein Computerprogrammprodukt vorgeschlagen, welches auf einer
programmgesteuerten Einrichtung die Durchführung eines
wie oben erläuterten Verfahrens zum Prüfen einer
auf einer ersten Einrichtung auszuführenden oder zu installierenden
Version eines Softwareproduktes veranlasst.
-
Denkbar
ist z. B. die Lieferung des Computerprogrammproduktes als Speichermedium,
wie Speicherkarte, USB-Stick, Floppy, CD-ROM, DVD oder auch in Form
einer herunterladbaren Datei von einem Server in einem Netzwerk.
Dies kann z. B. in einem drahtlosen Kommunikationsnetzwerk durch die Übertragung
einer entsprechenden Datei mit dem Computerprogrammprodukt auf die
erste Einrichtung erfolgen.
-
Die
Erfindung wird nachfolgend anhand den in den schematischen Figuren
angegeben Ausführungsbeispielen näher erläutert.
Es zeigen:
-
1 ein
schematisches Ablaufdiagramm eines ersten Ausführungsbeispiels
des erfindungsgemäßen Verfahrens;
-
2 eine
schematische Darstellung des Gültigkeitszeitraumes des öffentlichen
Schlüssels, des Gültigkeitszeitrahmens des privaten
Schlüssels und des Updatezeitrahmens;
-
3 ein
schematisches Blockdiagramm eines Zertifikates;
-
4 ein
schematisches Ablaufdiagramm eines zweiten Ausführungsbeispiels
des erfindungsgemäßen Verfahrens; und
-
5 ein
schematischer zeitlicher Ablauf eines Beispiels für eine
Anwendung des erfindungsgemäßen Verfahrens auf
einem PC eines Nutzers.
-
In
allen Figuren sind gleiche bzw. funktionsgleiche Elemente und Einrichtungen – sofern
nichts anderes angegeben ist – mit denselben Bezugszeichen
versehen.
-
1 zeigt
ein schematisches Ablaufdiagramm eines ersten Ausführungsbeispiels
des erfindungsgemäßen Verfahrens zum Prüfen
einer auf einer ersten Einrichtung auszuführenden oder
zu installierenden Version eines Softwareproduktes. Nachfolgend
wird das erste Ausführungsbeispiel des erfindungsgemäßen
Verfahrens anhand des Blockschaltbildes in 1 mit Bezug
auf 2 erläutert. Das erste Ausführungsbeispiel
des erfindungsgemäßen Verfahrens gemäß 1 weist
die folgenden Verfahrensschritte S1–S6 auf:
-
Verfahrensschritt S1:
-
Eine
Version des Softwareproduktes und eine zu der Version des Softwareproduktes
zugehörige, mittels eines privaten Schlüssels
erzeugte digitale Signatur wird von der ersten Einrichtung empfangen.
Die erste Einrichtung ist insbesondere als ein Personalcomputer
oder eine Recheneinheit eines Anwenders oder Nutzers ausgebildet.
Die erste Einrichtung empfängt die Version des Softwareproduktes
und die zugehörige digitale Signatur insbesondere von einer
zweiten Einrichtung, welche dem Vertreiber des Softwareproduktes
zugeordnet ist, insbesondere mittels eines Netzwerkes.
-
Verfahrensschritt S2:
-
Ein
Zertifikat Z, welches zumindest den zu dem privaten Schlüssel
zugehörigen öffentlichen Schlüssel K1
und eine Angabe AV des Gültigkeitszeitrahmens V des öffentlichen
Schlüssels K1 aufweist, wird empfangen. Die erste Einrichtung
kann dabei das Zertifikat Z von der zweiten Einrichtung, welche
dem Vertreiber zugeordnet ist, oder von einer dritten Ein richtung,
welche insbesondere eine Zertifizierungs-Autorität ist,
empfangen.
-
Verfahrensschritt S3:
-
Die
Gültigkeit des öffentlichen Schlüssels
K1 wird in Abhängigkeit der Angabe AV des Gültigkeitszeitrahmens
V des öffentlichen Schlüssels K1 zur Bereitstellung
eines Aktualitäts-Prüfungsergebnisses überprüft.
Dabei kann die Überprüfung der Gültigkeit des öffentlichen
Schlüssels K1 zur Bereitstellung des Aktualitäts-Prüfungsergebnisses
zur Angabe der Aktualität der Version des Softwareproduktes
auf der ersten Einrichtung in Abhängigkeit der Angabe AV des
Gültigkeitszeitrahmens V des öffentlichen Schlüssels
K1 oder in Abhängigkeit der Angabe AV des Gültigkeitszeitrahmens
V des öffentlichen Schlüssels K1 und eines von
der dritten Einrichtung bereitgestellten Rückrufstatus
R des jeweiligen Zertifikates Z für die Version des Softwareproduktes durchgeführt
werden.
-
Verfahrensschritt S4:
-
Die
Gültigkeit der empfangenen digitalen Signatur wird von
der ersten Einrichtung zur Bereitstellung eines Integritäts-Prüfungsergebnisses
geprüft. Dabei kann eine Verifikation der empfangenen,
mittels der digitalen Signatur signierten Version des Softwareproduktes
zur Bereitstellung des Integritäts-Prüfungsergebnisses
durchgeführt werden. Ferner kann überprüft
werden, ob ein Zeitpunkt der Erstellung der jeweiligen digitalen
Signatur, welcher mittels eines in der digitalen Signatur beinhalteten Zeitstempels
repräsentiert wird, innerhalb des Gültigkeitszeitrahmens
S des privaten Schlüssels liegt.
-
Verfahrensschritt S5:
-
Die
Aktualität der empfangenen Version des Softwareproduktes
wird in Abhängigkeit des bereitgestellten Aktualitäts-Prüfungsergebnisses
bestimmt. Dabei wird das Aktualitäts-Prüfungsergebnis vorzugsweise
als ein negatives Aktualitäts-Prüfungsergebnis
interpretiert, wenn der Zeitpunkt des Star tens oder Installierens
der Version des Softwareproduktes auf der ersten Einrichtung später
als ein Ende des Gültigkeitszeitrahmens V des öffentlichen Schlüssels
K1 ist.
-
Ferner
kann das Aktualitäts-Prüfungsergebnis als ein
negatives Aktualitäts-Prüfungsergebnis interpretiert
werden, wenn der bereitgestellte Rückrufstatus R, welcher
insbesondere von der dritten Einrichtung bereitgestellt wird, angibt,
dass das jeweilige Zertifikat Z für die entsprechende Version
des Softwareproduktes zurückgerufen ist, oder wenn der Zeitpunkt
des Startens oder Installierens der Version des Softwareproduktes
auf der ersten Einrichtung später als ein Ende des Gültigkeitszeitrahmens
V des öffentlichen Schlüssels K1 liegt.
-
Verfahrensschritt S6:
-
Die
Integrität der empfangenen Version des Softwareproduktes
wird in Abhängigkeit des bereitgestellten Integritäts-Prüfungsergebnisses
bestimmt.
-
In 2 ist
eine schematische Darstellung des Gültigkeitszeitrahmens
V des öffentlichen Schlüssels K1, des Gültigkeitszeitrahmens
S des privaten Schlüssels und des Update-Zeitrahmens U
abgebildet. Das Bezugszeichen t bezeichnet jeweils die Zeit. Dabei
beinhaltet der Gültigkeitszeitrahmen V des öffentlichen
Schlüssels K1 den Gültigkeitszeitrahmen S des
privaten Schlüssels und den Update-Zeitrahmen U für
eine Angabe eines notwendigen Updates der Version des Software-Produktes
auf der ersten Einrichtung. Vorzugsweise beginnen der Gültigkeitszeitrahmen
V des öffentlichen Schlüssels K1 und der Gültigkeitszeitrahmen
U des privaten Schlüssels zeitgleich. Ferner enden die
Gültigkeitszeitrahmen V des öffentlichen Schlüssels
K1 und der Update-Zeitrahmen U zeitgleich. Sowohl der Gültigkeitszeitrahmen
S des privaten Schlüssels als auch der Update-Zeitrahmen
U sind jeweils eine Teilmenge des Gültigkeitszeitrahmens
V des öffentlichen Schlüssels K1.
-
3 zeigt
ein schematisches Blockdiagramm eines Zertifikates Z. Vorzugsweise
enthält das Zertifikat Z zumindest den öffentlichen
Schlüssel K1, die Angabe AV der Gültigkeitsdauer
V des öffentlichen Schlüssels K1, einen Namen
N des Softwareproduktes, eine Versionsangabe VA des Softwareproduktes,
eine Angabe AS des Gültigkeitszeitrahmens S des privaten
Schlüssels und/oder eine Angabe AU des Update-Zeitrahmens
U sowie den Namen NZ der ausstellenden Zertifizierungsautorität
und die digitale Unterschrift DZ der Zertifizierungsautorität unter
diese Daten. Vorzugsweise werden für jede vom Vertreiber
mittels der zweiten Einrichtung bereitgestellte Version des Softwareproduktes,
welche der Nutzer mittels seiner ersten Einrichtung über
ein Netzwerk herunterladen kann, der Gültigkeitszeitrahmen
V des öffentlichen Schlüssels K1, der Gültigkeitszeitrahmen
S des privaten Schlüssels und der Update-Zeitrahmen U festgelegt
oder neu bestimmt. Somit kann überprüft werden,
ob ein Zeitpunkt der Erstellung der jeweiligen digitalen Signatur,
welcher mittels eines in der digitalen Signatur beinhalteten Zeitstempels
repräsentiert wird, innerhalb des Gültigkeitszeitrahmens
S des privaten Schlüssels liegt.
-
4 zeigt
ein schematisches Ablaufdiagramm eines zweiten Ausführungsbeispiels
des erfindungsgemäßen Verfahrens. Das zweite Ausführungsbeispiel
gemäß 4 beinhaltet die Verfahrensschritte
S1–S6 gemäß 1 sowie
die weiteren Verfahrensschritte S7–S9. Aus diesem Grund
werden im Folgenden nur die gegenüber dem ersten Ausführungsbeispiel
gemäß 1 zusätzlichen Verfahrensschritte
S7–S9 erläutert. Die im Weiteren beschriebenen
Verfahrensschritte S7–S9 folgen auf die Verfahrensschritte
S1–S6 gemäß 1:
Die
Verfahrensschritte S7–S9 werden in Abhängigkeit
des Integritäts-Prüfungsergebnisses und des Aktualitäts-Prüfungsergebnisses
ausgeführt.
-
Verfahrensschritt S7:
-
Bei
einem positiven Integritäts-Prüfungsergebnis und
einem positiven Aktualitäts-Prüfungsergebnisses
wird die Version des Softwareproduktes auf der ersten Einrichtung
gestartet oder installiert.
-
Verfahrensschritt S8:
-
Bei
einem negativen Integritäts-Prüfungsergebnis wird
die Version des Softwareproduktes auf der ersten Einrichtung nicht
gestartet und nicht installiert.
-
Verfahrensschritt S9:
-
Bei
einem positiven Integritäts-Prüfungsergebnis und
einem negativen Aktualitäts-Prüfungsergebnis wird
zumindest ein Teil einer von der zweiten Einrichtung mittels eines
Netzwerks bereitgestellten aktuellen Version des Softwareproduktes
und eine zugehörige aktuelle digitale Signatur von der
ersten Einrichtung geladen. Alternativ kann, falls die Version des
Softwareproduktes vom Vertreiber nicht, sondern nur die zugehörige
digitale Signatur aktualisiert wurde, die von der zweiten Einrichtung
des Vertreibers mittels des Netzwerks bereitgestellte, aktuelle
digitale Signatur der aktuellen Version des Softwareproduktes als
Aktualitäts-Bestätigung der auf der ersten Einrichtung
vorhandenen Version des Softwareproduktes von der ersten Einrichtung
geladen werden.
-
Alternativ
kann bei einem positiven Integritäts-Prüfungsergebnis,
einem positiven Aktualitäts-Prüfungsergebnis und
wenn der Zeitpunkt des Startens oder Installierens der Version des
Softwareproduktes auf der ersten Einrichtung später als
ein Beginn des Update-Zeitrahmens ist, die Version des Softwareproduktes
auf der ersten Einrichtung gestartet oder installiert werden. Des
Weiteren kann in einem solchen Falle zumindest ein Teil oder eine
Vollversion der von der zweiten Einrichtung mittels des Netzwerkes
bereitgestellten aktuellen Version des Softwareproduktes und die
zugehörige aktuelle digitale Signatur oder ausschließlich
die von der zweiten Einrichtung mittels des Netzwerkes bereitgestellte, aktuelle
digitale Signatur der aktuellen Version des Softwareproduktes als
Aktualitäts-Bestätigung der auf der ersten Einrichtung
vorhandenen Version des Softwareproduktes von der ersten Einrichtung
geladen werden.
-
Nachdem
der Nutzer oder Anwender über die Zeit eine Vielzahl aufeinanderfolgender
Versionen des Softwareproduktes herunterladen kann, werden vorzugweise
die verschiedenen digitalen Signaturen und die zu den jeweiligen
digitalen Signaturen zugehörigen Zertifikate Z der verschiedenen
Versionen des Softwareproduktes zur Bereitstellung eines Log-Files
der Versionen des Softwareproduktes durch die erste Einrichtung
gespeichert. Alternativ kann diese Speicherung auch von der zweiten
Einrichtung des Vertreibers des Softwareproduktes erfolgen.
-
Vorzugsweise
werden das Laden aktueller Versionen des Softwareproduktes und/oder
das Laden einer aktuellen digitalen Signatur von einer Eingabe des
Nutzers der ersten Einrichtung getriggert. Vorzugsweise kann bei
einer Aufforderung der ersten Einrichtung an den Nutzer für
eine solche Eingabe und bei einem folgenden Ausbleiben der Eingabe
des Nutzers innerhalb eines vorbestimmten Zeitfensters oder bei
einer Eingabe des Nutzers, welche angibt, dass kein Update der Version
des Softwareproduktes erfolgen soll, die Version des Softwareproduktes
auf der ersten Einrichtung nicht installiert werden oder nur in
einem vorbestimmten eingeschränkten Funktionsumfang ausgeführt
werden.
-
5 zeigt
einen schematischen Ablauf eines Beispiels für eine Anwendung
des erfindungsgemäßen Verfahrens auf einer ersten
Einrichtung, beispielsweise einem PC eines Nutzers. Die oberen fünf Zeilen
der 5 zeigen verschiedene Versionen oder Releases
R1–R3 eines von einer zweiten Einrichtung eines Vertreibers
bereitgestellten Softwareproduktes und ihre zeitlichen Geltungsbereiche
in Abhängigkeit von V, S und U. Die letzte Zeile der 5 zeigt
fünf Zeitpunkte t1–t5, zu denen der Nutzer bzw.
die erste Einrichtung des Nutzers hinsichtlich einer Aktualisierung
der Version des Softwarepro duktes auf der ersten Einrichtung oder
einer ausschließlichen Aktualisierung der digitalen Signatur
tätig wird.
-
Zum
Zeitpunkt t1 lädt und installiert der Nutzer bzw. die erste
Einrichtung des Nutzers den Release R1 des Softwareproduktes.
-
Der
Zeitpunkt t2 liegt innerhalb des Update-Zeitrahmens U von R1. Zu
diesem Zeitpunkt t2 hat der Vertreiber des Softwareproduktes bzw.
die zweite Einrichtung des Vertreibers den zweiten Release R2 des
Softwareproduktes bereitgestellt. Somit lädt der Nutzer
die zweite Version R2 zum Zeitpunkt t2.
-
Zum
Zeitpunkt t3 war bereits ein Rückrufstatus R von einer
dritten Einrichtung, beispielsweise einer Zertifizierungs-Autorität,
veröffentlicht, welche angibt, dass der Vertreiber den
zweiten Release R2 zurückgerufen hat. Zum Zeitpunkt t3
empfängt der Nutzer den Rückrufstatus R und lädt
die aktuelle Version R2.1.
-
Der
Zeitpunkt t4 liegt innerhalb des Update-Zeitrahmens U des zweiten
Release R2, insbesondere des Releases R2.1. Ein dritter Release
R3 ist zum Zeitpunkt t4 noch nicht vorhanden bzw. von der zweiten
Einrichtung herunterladbar, sodass der Nutzer zum Zeitpunkt t4 ausschließlich
eine aktuelle digitale Signatur für das zweite Release
R2.1 lädt.
-
Der
Zeitpunkt t5 liegt am Beginn des Update-Zeitrahmens U des Releases
2.1. Folglich sucht die erste Einrichtung des Nutzers zum Zeitpunkt
t5 nach neuen Updates des Softwareproduktes. Zum Zeitpunkt t5 hat
der Vertreiber bereits das Release R3 bereitgestellt, sodass der
Nutzer bzw. die erste Einrichtung des Nutzers das dritte Release
R3 mittels des Netzwerkes von der zweiten Einrichtung des Vertreibers
herunterladen kann.
-
Obwohl
die vorliegenden Erfindung vorstehend anhand der bevorzugten Ausführungsbeispiele beschrieben
wurde, ist sie darauf nicht beschränkt, sondern auf vielfältige
Art und Weise modifizierbar.
-
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
-
- - http://www.microsoft.com/whdc/winlogo/drvsign/best_practices.mspx [0002]
- - http://www.java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/rsa_signing.html [0002]
- - http://www.verisign.com/stellent/groups/public/documents/data_sheet/003201.pdf [0003]
- - http://www.verisign.com/support/tic/per/whitepaper.htm [0003]
- - http://www.microsoft.com/whdc/winlogo/drvsign/best_practices.mspx [0005]