WO2009024373A2 - Verfahren zum prüfen einer auf einer ersten einrichtung auszuführenden oder zu installierenden version eines softwareproduktes - Google Patents

Verfahren zum prüfen einer auf einer ersten einrichtung auszuführenden oder zu installierenden version eines softwareproduktes Download PDF

Info

Publication number
WO2009024373A2
WO2009024373A2 PCT/EP2008/057674 EP2008057674W WO2009024373A2 WO 2009024373 A2 WO2009024373 A2 WO 2009024373A2 EP 2008057674 W EP2008057674 W EP 2008057674W WO 2009024373 A2 WO2009024373 A2 WO 2009024373A2
Authority
WO
WIPO (PCT)
Prior art keywords
software product
version
check result
public key
validity
Prior art date
Application number
PCT/EP2008/057674
Other languages
English (en)
French (fr)
Other versions
WO2009024373A3 (de
Inventor
Peter Hartmann
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to EP08774124A priority Critical patent/EP2191407A2/de
Publication of WO2009024373A2 publication Critical patent/WO2009024373A2/de
Publication of WO2009024373A3 publication Critical patent/WO2009024373A3/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2101—Auditing as a secondary aspect
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2137—Time limited access, e.g. to a computer or data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2151—Time stamp

Definitions

  • the invention relates to a method for testing a version of a software product to be executed or installed on a first device.
  • Asymmetric cryptographic encryption methods are conventionally used for the digital signature of codes, software or software products.
  • the digital signature By means of the digital signature, the source and the authenticity of the software - summarized below under the term "integrity" - are checked.
  • the digital signatures are used to check the software before it is installed. After installation, the digital signatures are also used to ensure that the software has not been altered.
  • Such methods of signing software are, for example, at http: //www.microsoft. com / whdc / winlogo / drvsign / best practices. mspx and http: // www. java .sun.com / j2se / 1.4.2 / docs / guide / plugin / developer_guide / rsa_signing.html.
  • certificates are used for the digital signature. These certificates are provided by certified institutions, so-called Certification authorities. Such certificates usually have a validity period of one to three years. However, certificates for one-time use are also known. For example, the use of a certificate is http: // www. verisign. com / spat / groups / public / documents / data _sheet / 003201.pdf or from http: // www. verisign. com / support / tlc / per / whitepaper .htm known. However, the software is often developed for a lifetime that is longer than the validity period of a certificate. For this reason, timestamping services provide timestamps to certify the time of signing. The signature is then conventionally accepted as valid if the certificate was valid at the time that is authenticated by the time stamp.
  • the digital signatures can always be checked when the corresponding software is opened or executed. Furthermore, it is known to perform an update of software by means of an online request to the distributor of the software when the corresponding software is started on the user's or user's PC. If a new version of the software is found on the server of the distributor, it can be installed on the user's PC. However, if an online connection is not available, the installed version of the software must continue to be used. Also, for some such software products or software, a digital signature is necessary to correctly install the software downloaded from the distributor's server. For example, this is also available at http: //www.microsoft. com / whdc / winlogo / drvsign / best practices. mspx described.
  • Another object of the present invention is to provide a simple and, in particular, cost-effective way of ensuring the integrity and up-to-dateness of a user's device to be executed or installed on the device. software product without checking a currently existing online connection.
  • At least one of these tasks is solved by a method for checking a version of a software product to be executed or installed on a first device.
  • a method for checking a version of a software product to be executed or installed on a first device comprising the following steps:
  • Prufungs insects e) determining an actuality of the received version of the software product as a function of the provided actuality check result; and f) determining an integrity of the received version of the
  • One advantage of the invention is that the timeliness of a version of a software product to be executed or installed can be checked on the first device of the user, for example a user's PC.
  • the certificate inherent in the integrity check with the digital signature is used.
  • the inventive method is independent of an existing or interrupted online connection of the user's PC.
  • the process according to the invention can be carried out inexpensively and simply by utilizing an inherently present agent.
  • Another advantage is that when using the method according to the invention, a separate key and a separate certificate are used for each version of the software product or for each software release, but it is possible for each software release to be used for different software releases Platforms or in different configurations simultaneously. This is possible according to the invention in that a key can be used for more than one signature process.
  • the validity time frame of the public key includes a validity time frame of the private key and / or an update time frame for an indication of a necessary update of the version of the software product, the validity time frame of the public key and the valid validity period.
  • timeframe of the private key start at the same time and the validity time frame of the public key and the update timeframe end at the same time.
  • method step c) includes checking the validity of the public key for providing the actuality check result for indicating the actuality of the version of the software product depending on the specification of the validity time frame of the public key or depending on the validity period of the public Key and a third-party facility provided recall status of the respective certificate for the version of the software product.
  • the third device may be a certification authority.
  • the certification authority publishes a recall status for the respective certificate used.
  • the recall may also be initiated by the distributor, who will then announce the recall to the certification authority, which will subsequently publish the recall status for that certificate.
  • method step d) includes performing a verification of the received version of the software product signed by the digital signature to provide the integrity check result.
  • the update check result is interpreted as a negative update check result if the time of starting or installing the version of the software product on the first device is later than an end of the validity period of the public key.
  • the update check result is interpreted as a negative update check result if the provided callback status indicates that the respective certificate has been recalled for the corresponding version of the software product or the time of starting or installing the version of the software product on the first device later than an end of the validity period of the public key.
  • the time of starting or installing the version of the software product on the first device is later than a beginning of the update time frame, then at least a part of a current version of the software product and an associated current one is at a positive update check result digital signature of the current version of the software product or only an up-to-date digital signature of the current version of the software product as actuality Confirmation provided by the second device via a network.
  • the distributor of the software product updates part or all of the software product
  • the user can download the updated part or the entire current version of the software product with an associated current digital signature of the current version of the software product from the distributor's server.
  • the distributor of the software product can release a software product that is no longer current, for installation and startup.
  • the distributor of the software product can provide only an up-to-date digital signature, which the user can then download from the server of the distributor.
  • current digital signature of the current version of the software product is loaded as an up-to-date confirmation of the version of the software product present on the first device from the first device.
  • the following step is provided after steps a) to f): if a positive integrity check result, a positive update check result and if the time of starting or installing the version of the software product on the first device is later than a start of the update time frame, the version of the software product is started on the first device or at least part of a current version of the software product provided by the second device via a network and an associated current digital signature or exclusively a current digital signature of the current version of the software product provided by the second device via the network loaded as an up-to-date confirmation of the version of the software product present on the first device from the first device.
  • the validity period of the public key, the validity period of the private key and / or the update time frame are defined for each provided version of the software product.
  • the distributor of the software product it is possible for the distributor of the software product to form a schedule or a schedule for the updates of the versions of his software product.
  • the distributor can also reliably redistribute this schedule to the users using the certificate.
  • the various digital signatures and the certificates belonging to the respective digital signatures of the different versions of the software product for providing a log file of the versions of the software product are stored by the first device and / or the second device.
  • Providing the log file provides a document with a trusted version history.
  • a positive actuality check result in the case of a positive integrity check result and a negative actuality check result or in the case of a positive integrity check result, a positive actuality check result.
  • This configuration ensures that the user or user of the decision makers remains which software or software products are executed or installed on his first device, for example his PC.
  • the version the software product of the first device in the case of a positive integrity check result and a negative actuality check result if the user does not input within a predetermined time window or an input by the user indicating that no update of the version of the software product is to take place, the version the software product of the first device is not installed or executed in a predetermined limited range of functions.
  • a separate private key with a fixed validity time frame and a separate certificate are provided and used for each version of the software product.
  • method step d) includes checking whether a time of creation of the respective digital signature, which by means of of a time stamp included in the digital signature is within the validity period of the private key.
  • the certificate may further comprise a hash algorithm and / or a signature algorithm.
  • the digital signature preferably comprises at least one hash value of the software product encrypted with the private key of a key pair.
  • the method step a) includes in particular the following steps:
  • Signing the provided version of the software product preferably includes:
  • the transfer of the signed version of the software product from the second device to the first device includes In particular, the transfer of the provided version of the software product and the at least one encrypted hash value.
  • a computer program product which causes a program-controlled device to carry out a method as described above for checking a version of a software product to be executed or installed on a first device.
  • Figure 1 is a schematic flow diagram of a first exemplary embodiment of the inventive method
  • FIG. 2 shows a schematic representation of the validity period of the public key, the validity period frame of the private key and the update time frame;
  • FIG. 3 is a schematic block diagram of a certificate
  • FIG. 4 is a schematic flow diagram of a second exemplary embodiment of the inventive method
  • FIG. 5 shows a schematic time sequence of an example of an application of the method according to the invention to a user's PC.
  • Figure 1 shows a schematic flow diagram of a first embodiment of the inventive method for
  • the first exemplary embodiment of the inventive method according to FIG. 1 has the following method steps S1-S6:
  • Method step S1 A version of the software product and a digital signature associated with the version of the software product are received by the first device.
  • the first device is designed in particular as a personal computer or a computing unit of a user or user.
  • the first device receives the version of the software product and the associated digital signature in particular from a second device which is assigned to the distributor of the software product, in particular by means of a network.
  • a certificate Z which has at least the public key Kl belonging to the private key and an indication AV of the validity time frame V of the public key Kl, is received.
  • the first device may be the certificate Z from the second device, which is assigned to the distributor, or from a third device. direction, which is in particular a certification authority.
  • Step S3 The validity of the public key K1 is checked in accordance with the indication AV of the validity time frame V of the public key K1 for providing an update check result.
  • checking the validity of the public key K1 for providing the actuality check result for indicating the actuality of the version of the software product on the first device can be dependent on the specification AV of the validity time frame V of the public key K1 or depending on the indication AV of the validity time frame V of the public key Kl and a return status R of the respective certificate Z provided by the third facility for the version of the software product.
  • the validity of the received digital signature is checked by the first means for providing an integrity check result.
  • a verification of the received version of the software product signed by means of the digital signature can be carried out to provide the integrity check result.
  • it can be checked whether a time of creation of the respective digital signature, which is represented by means of a time stamp included in the digital signature, lies within the validity time frame S of the private key.
  • the actuality of the received version of the software product will depend on the actuality provided.
  • the actuality check result is preferably interpreted as a negative actuality check result if the time of the start or installing the version of the software product on the first device later than an end of the validity period V of the public key K1.
  • the actuality check result may be interpreted as a negative update check result if the provided callback status R, which in particular is provided by the third device, indicates that the respective certificate Z has been recalled for the corresponding version of the software product, or if the time starting or installing the version of the software product on the first device is later than an end of the validity period V of the public key Kl.
  • the integrity of the received version of the software product is determined depending on the provided integrity check result.
  • FIG. 2 shows a schematic representation of the validity period V of the public key K1, of the validity period S of the private key, and of the update time frame U.
  • the reference symbol t denotes the time each.
  • the validity period of the public key Kl includes the validity period S of the private key and the update time frame U for an indication of a necessary update of the version of the software product on the first device.
  • the validity period V of the public key Kl and the validity period U of the private key start at the same time.
  • the validity periods V of the public key K1 and the update time frame U end at the same time.
  • Both the validity period S of the private key and the update time frame U are each a subset of the validity period V of the public key Kl.
  • the certificate Z contains at least the public key Kl, the indication AV of the validity period V of the public key Kl, a name N of the software product, a version specification VA of the software product, an indication AS of the Validity period S of the private key and / or an indication AU of the update time frame U and the name NZ of the issuing certification authority and the digital signature DZ of the certification authority under this data.
  • the validity period V of the public key K1 for each version of the software product provided by the distributor by means of the second device, which the user can download via a network via his first device, the validity period V of the public key K1, the validity period S of the private key and the update time frame U fixed or redetermined.
  • it can be checked whether a time of creation of the respective digital signature, which is represented by means of a time stamp included in the digital signature, lies within the validity period S of the private key.
  • FIG. 4 shows a schematic flow diagram of a second exemplary embodiment of the method according to the invention.
  • the second exemplary embodiment according to FIG. 4 includes the method steps S1-S6 according to FIG. 1 and the further method steps S7-S9. For this reason, only the method steps S7-S9 which are additional to the first exemplary embodiment according to FIG. 1 will be explained below.
  • the method steps S7-S9 described below follow the method steps S1-S6 according to FIG. 1:
  • the method steps S7-S9 are executed as a function of the integrity test result and the actuality check result.
  • Process step S7 In the case of a positive integrity check result and a positive update check result, the version of the software product is started or installed on the first device.
  • At least part of a current version of the software product provided by the second device via a network and an associated current digital signature are loaded by the first device.
  • the current digital signature of the current version of the software product provided by the second device of the distributor via the network may be updated to the one on the first device existing version of the software product are loaded from the first device.
  • the version of the software product may be on the first device started or installed. Furthermore, in such a case, at least a part or a full version of the current version of the software product provided by the second device via the network and the associated current digital signature or only the current digital signature provided by the second device via the network current version of the Software product as an up-to-date confirmation of existing on the first device version of the software product are loaded from the first device.
  • the various digital signatures and the certificates Z of the different versions of the software product associated with the respective digital signatures are preferably used to provide a log file of the versions of the software product saved by the first device.
  • this storage can also be done by the second device of the distributor of the software product.
  • the loading of current versions of the software product and / or the loading of a current digital signature from an input of the user of the first device are triggered.
  • the version of the software product are not installed on the first device or are executed only in a predetermined limited range of functions.
  • FIG. 5 shows a schematic sequence of an example of an application of the method according to the invention to a first device, for example a PC of a user.
  • the top five lines of FIG. 5 show different versions or releases R1-R3 of a software product provided by a second device of a distributor and their time ranges depending on V, S and U.
  • the last line of FIG. 5 shows five times t1-t5. to which the user or the first device of the user with regard to an update of the version of the software program act on the first device or an exclusive update of the digital signature.
  • the user or the first device of the user loads and installs the release R 1 of the software product.
  • the time t2 lies within the update time frame U of Rl.
  • the distributor of the software product or the second device of the distributor has provided the second release R2 of the software product.
  • the user loads the second version R2 at time t2.
  • a callback status R has already been published by a third entity, such as a certification authority, indicating that the distributor has recalled the second release R2.
  • a third entity such as a certification authority
  • the time t4 lies within the update time frame U of the second release R2, in particular of the release R2.1.
  • a third release R3 is not yet present at time t4 or can be downloaded from the second device, so that the user exclusively loads an up-to-date digital signature for the second release R2.1 at time t4.
  • the time t5 is at the beginning of the update time frame U of the release 2.1. Consequently, the user's first device searches for new updates of the software product at time t5.
  • the distributor has already provided the release R3, so that the user or the first device of the user can download the third release R3 by means of the network from the second device of the distributor.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Es wird ein Verfahren zum Prüfen einer auf einer ersten Einrichtung auszuführenden oder zu installierenden Version eines Softwareproduktes vorgeschlagen, welches folgende Schritte aufweist: Empfangen der Version des Softwareproduktes und einer zu der Version des Softwareproduktes zugehörigen, mittels eines privaten Schlüssels erzeugten digitalen Signatur; 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; Überprüfen einer Gültigkeit des öffentlichen Schlüssels in Abhängigkeit der Angabe des Gültigkeitszeitrahmens zur Bereitstellung eines Aktualitäts-Prüfungsergebnisses; Überprüfen einer Gültigkeit der empfangenen digitalen Signatur zur Bereitstellung eines Integritäts-Prüfungsergebnisses; Bestimmen einer Aktualität der empfangenen Version des Softwareproduktes in Abhängigkeit des bereitgestellten Aktualitäts-Prüfungsergebnisses; und Bestimmen einer Integrität der empfangenen Version des Softwareproduktes in Abhängigkeit des bereitgestellten Integritäts-Prüfungsergebnisses.

Description

Beschreibung
Verfahren zum Prüfen einer auf einer ersten Einrichtung auszuführenden oder zu installierenden Version eines Software- produktes
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" zusam- mengefasst - ü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 zerti- fizierten Einrichtungen, sogenannten Certification Authori- ties, 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/tlc/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 o- der 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 ver- wendet 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.
Erfindungsgemaß wird zumindest eine dieser gestellten Aufga- ben durch ein Verfahren zum Prüfen einer auf einer ersten Einrichtung auszuführenden oder zu installierenden Version eines Softwareproduktes gelost.
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 Gultigkeitszeitrahmens des öffentlichen Schlüssels aufweist; c) Überprüfen einer Gültigkeit des öffentlichen Schlüssels in Abhängigkeit der Angabe des Gultigkeitszeitrahmens zur Bereitstellung eines Aktualitats-Prufungsergebnisses; d) Überprüfen einer Gültigkeit der empfangenen digitalen Sig- natur zur Bereitstellung eines Integritats-
Prufungsergebnisses; 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 In- tegritats-Prufungsergebnisses .
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 zusatzlichen Mittel, wie beispielswei- se eine Online-Abfrage beim Vertreiber des Softwareproduktes, notwendig. Erfindungsgemaß wird das für die Integritatspru- fung mit der digitalen Signatur inhärent vorhandene Zertifikat, dabei insbesondere die Angabe des Gultigkeitszeitrahmens des öffentlichen Schlüssels, genutzt. Somit ist das erfin- dungsgemaße Verfahren unabhängig von einer bestehenden oder unterbrochenen Online-Verbindung des PCs des Anwenders. Weiter ist das erfindungsgemaße Verfahren durch die Ausnutzung eines inhärent vorhandenen Mittels kostengünstig und einfach durchfuhrbar.
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 verhin- dert, da bei abgelaufenen Versionen das Aktualitatsprufungs- ergebnis als ein negatives Aktualitatsprufungsergebnis interpretiert wird.
Ein weiterer Vorteil liegt darin, dass beim Einsatz des er- findungsgemaß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 erfindungsgemaß dadurch möglich, dass ein Schlüssel für mehr als einen Signa- turprozess verwendet werden kann.
Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfin- düng ergeben sich aus den Unteranspruchen sowie der Beschreibung und der Bezugnahme auf die Zeichnungen.
Gemäß einer bevorzugten Ausgestaltung der Erfindung beinhaltet der Gultigkeitszeitrahmen des öffentlichen Schlüssels ei- nen Gultigkeitszeitrahmen des privaten Schlüssels und/oder einen Update-Zeitrahmen für eine Angabe eines notwendigen Updates der Version des Softwareproduktes, wobei der Gultigkeitszeitrahmen des öffentlichen Schlüssels und der Gültig- keitszeitrahmen des privaten Schlüssels zeitgleich beginnen und der Gultigkeitszeitrahmen des öffentlichen Schlüssels und der Update-Zeitrahmen zeitgleich enden.
Gemäß einer weiteren bevorzugten Ausgestaltung enthalt 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 Gultigkeitszeitrahmens des privaten Schlüssels und/oder eine Angabe des Gultigkeitszeitrahmens 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 Aktuali- tats-Prufungsergebnisses zur Angabe der Aktualität der Version des Softwareproduktes in Abhängigkeit der Angabe des Gultigkeitszeitrahmens des öffentlichen Schlüssels oder in Abhängigkeit des Gultigkeitszeitrahmens des öffentlichen Schlüssels und eines von einer dritten Einrichtung bereitgestellten RuckrufStatus des jeweiligen Zertifikats für die Version des Softwareproduktes.
Wenn beispielsweise die erste Einrichtung den PC eines Anwen- ders und die zweite Einrichtung einen Server eines Vertreibers der Softwareprodukte darstellt, so kann die dritte Einrichtung eine Zertifizierungsautoritat sein. Vorteilhafterweise kann insbesondere durch die zweite Möglichkeit der obig erläuterten Ausgestaltungen der Erfindung sichergestellt wer- den, dass der Anwender eine Anzeige erhalt, dass das von ihm ausgeführte oder installierte Softwareprogrammprodukt nicht mehr aktuell ist, wenn die Zertifizierungsautoritat einen RuckrufStatus für das jeweilige eingesetzte Zertifikat veröffentlicht. Der Ruckruf kann auch von dem Vertreiber initiiert werden, welcher dann der Zertifizierungsautoritat den Ruckruf bekannt gibt, welche im Folgenden den RuckrufStatus für dieses Zertifikat veröffentlicht. Durch den Einsatz des Ruckruf- Status für das Aktualitats-Prufungsergebnis kann somit ermog- 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 Integri- täts-Prüfungsergebnisses .
Gemäß einer weiteren bevorzugten Ausgestaltung wird das Aktu- alitäts-Prüfungsergebnis 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 des öffentlichen Schlüssels ist.
Gemäß einer weiteren bevorzugten Ausgestaltung wird das Aktu- alitä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 Softwareproduk- tes 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 aktuel- Ie 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 Ein- richtung geladen.
Gemäß einer weiteren bevorzugten Ausgestaltung werden für jede bereitgestellte Version des Softwareproduktes der Gültigkeitszeitrahmen des öffentlichen Schlüssels, der Gültigkeits- zeitrahmen 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 Integritats-Prufungsergebnis und einem negativen Aktualitats-Prufungsergebnis oder bei einem positiven In- tegritats-Prufungsergebnis, einem positiven Aktualitats-
Prufungsergebnis und wenn der Zeitpunkt des Startens oder In- stallierens der Version des Softwareproduktes auf der ersten Einrichtung spater als ein Beginn des Update-Zeitrahmens ist, der zumindest eine Teil der von der zweiten Einrichtung mit- tels des Netzwerkes bereitgestellten aktuellen Version des
Softwareproduktes und die zugehörige aktuelle digitale Signatur oder ausschließlich die aktuelle digitale Signatur als Aktualitats-Bestatigung in Abhängigkeit einer Eingabe des Nutzers der ersten Einrichtung geladen.
Durch diese Ausgestaltung ist sichergestellt, dass der Nutzer oder Anwender der Entscheidungstrager 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 Integritats-Prufungsergebnis und einem negativen Aktualitats-Prufungsergebnis 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 Gultigkeitszeitrahmen 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 Gultigkeitszeitrahmens 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 Schlusselpaares verschlus- selten 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 Zertifizierungsautoritat 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 Softwarepro- duktes 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 Schlusselpaares.
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 Durchfuhrung 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 schemati- sehen Figuren angegeben Ausfuhrungsbeispielen naher erläutert. Es zeigen:
Figur 1 ein schematisches Ablaufdiagramm eines ersten Ausfuhrungsbeispiels des erfindungsgemaßen Verfahrens;
Figur 2 eine schematische Darstellung des Gultigkeitszeitrau- mes des öffentlichen Schlüssels, des Gultigkeitszeit- rahmens des privaten Schlüssels und des Updatezeitrahmens;
Figur 3 ein schematisches Blockdiagramm eines Zertifikates;
Figur 4 ein schematisches Ablaufdiagramm eines zweiten Ausfuhrungsbeispiels des erfindungsgemaßen Verfahrens; und Figur 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.
Figur 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 Figur 1 mit Bezug auf Figur 2 erläutert. Das erste Ausführungsbeispiel des erfindungsgemäßen Verfahrens gemäß Figur 1 weist die folgenden Verfahrensschritte S1-S6 auf:
Verfahrensschritt Sl: 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 Anwen- ders 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 Kl und eine Angabe AV des Gültigkeitszeitrahmens V des öffentlichen Schlüs- sels Kl 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-Autoritat ist, empfangen.
Verfahrensschritt S3: Die Gültigkeit des öffentlichen Schlüssels Kl wird in Abhängigkeit der Angabe AV des Gultigkeitszeitrahmens V des öffentlichen Schlüssels Kl zur Bereitstellung eines Aktuali- tats-Prufungsergebnisses überprüft. Dabei kann die Überprüfung der Gültigkeit des öffentlichen Schlüssels Kl zur Be- reitstellung des Aktualitats-Prufungsergebnisses zur Angabe der Aktualität der Version des Softwareproduktes auf der ersten Einrichtung in Abhängigkeit der Angabe AV des Gultigkeitszeitrahmens V des öffentlichen Schlüssels Kl oder in Abhängigkeit der Angabe AV des Gultigkeitszeitrahmens V des of- fentlichen Schlüssels Kl und eines von der dritten Einrichtung bereitgestellten RuckrufStatus 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 Integritats- Prufungsergebnisses geprüft. Dabei kann eine Verifikation der empfangenen, mittels der digitalen Signatur signierten Versi- on des Softwareproduktes zur Bereitstellung des Integritats- Prufungsergebnisses 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, inner- halb des Gultigkeitszeitrahmens S des privaten Schlüssels liegt .
Verfahrensschritt S5:
Die Aktualität der empfangenen Version des Softwareproduktes wird in Abhängigkeit des bereitgestellten Aktualitats-
Prufungsergebnisses bestimmt. Dabei wird das Aktualitats- Prufungsergebnis vorzugsweise als ein negatives Aktualitats- Prufungsergebnis 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 Kl 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 Kl liegt .
Verfahrensschritt S6:
Die Integrität der empfangenen Version des Softwareproduktes wird in Abhängigkeit des bereitgestellten Integritäts- Prüfungsergebnisses bestimmt.
In Figur 2 ist eine schematische Darstellung des Gültigkeitszeitrahmens V des öffentlichen Schlüssels Kl, des Gültigkeitszeitrahmens S des privaten Schlüssels und des Update- Zeitrahmens U abgebildet. Das Bezugszeichen t bezeichnet je- weils die Zeit. Dabei beinhaltet der Gültigkeitszeitrahmen V des öffentlichen Schlüssels Kl 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 Kl und der Gültigkeitszeitrahmen U des privaten Schlüssels zeitgleich. Ferner enden die Gültigkeitszeitrahmen V des öffentlichen Schlüssels Kl 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 Kl. Figur 3 zeigt ein schematisches Blockdiagramm eines Zertifikates Z. Vorzugsweise enthält das Zertifikat Z zumindest den öffentlichen Schlüssel Kl, die Angabe AV der Gültigkeitsdauer V des öffentlichen Schlüssels Kl, einen Namen N des Software- Produktes, 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 un- ter 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 Kl, der Gültig- keitszeitrahmen 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, inner- halb des Gültigkeitszeitrahmens S des privaten Schlüssels liegt .
Figur 4 zeigt ein schematisches Ablaufdiagramm eines zweiten Ausführungsbeispiels des erfindungsgemäßen Verfahrens. Das zweite Ausführungsbeispiel gemäß Figur 4 beinhaltet die Verfahrensschritte S1-S6 gemäß Figur 1 sowie die weiteren Verfahrensschritte S7-S9. Aus diesem Grund werden im Folgenden nur die gegenüber dem ersten Ausführungsbeispiel gemäß Figur 1 zusätzlichen Verfahrensschritte S7-S9 erläutert. Die im Weiteren beschriebenen Verfahrensschritte S7-S9 folgen auf die Verfahrensschritte S1-S6 gemäß Figur 1:
Die Verfahrensschritte S7-S9 werden in Abhängigkeit des In- tegritä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 Netz- werks 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 In- stallierens 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 bereitge- stellten 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 Soft- wareproduktes 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.
Figur 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 Figur 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 Figur 5 zeigt fünf Zeitpunkte tl-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 tl lädt und installiert der Nutzer bzw. die erste Einrichtung des Nutzers den Release Rl des Softwareproduktes .
Der Zeitpunkt t2 liegt innerhalb des Update-Zeitrahmens U von Rl . Zu diesem Zeitpunkt t2 hat der Vertreiber des Software- produktes 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 Nut- zers 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.

Claims

Patentansprüche
1. Verfahren zum Prüfen einer auf einer ersten Einrichtung auszuführenden oder zu installierenden Version eines Soft- wareproduktes, mit den Schritten: 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 (Z) , welches zumindest den zu dem privaten Schlüssel zugehörigen öffentlichen Schlüssel
(Kl) und eine Angabe (AV) des Gultigkeitszeitrahmens (V) des öffentlichen Schlüssels (Kl) aufweist; c) Überprüfen einer Gültigkeit des öffentlichen Schlüssels
(Kl) in Abhängigkeit der Angabe (AV) des Gultigkeitszeit- rahmens (V) des öffentlichen Schlüssels (Kl) zur Bereitstellung eines Aktualitats-Prufungsergebnisses; d) Überprüfen einer Gültigkeit der empfangenen digitalen Signatur zur Bereitstellung eines Integritats- Prufungsergebnisses; 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 In- tegritats-Prufungsergebnisses .
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Gultigkeitszeitrahmen (V) des öffentlichen Schlus- sels (Kl) einen Gultigkeitszeitrahmen (S) des privaten
Schlüssels und/oder einen Update-Zeitrahmen (U) für eine Angabe eines notwendigen Updates der Version des Softwareproduktes beinhaltet, wobei der Gultigkeitszeitrahmen (V) des öffentlichen Schlüssels (Kl) und der Gultigkeitszeitrahmen (U) des privaten Schlüssels zeitgleich beginnen und der Gultigkeitszeitrahmen (V) des öffentlichen Schlüssels (Kl) und der Update-Zeitrahmen (U) zeitgleich enden.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Zertifikat (Z) den öffentlichen Schlüssel (Kl), die Angabe (AV) der Gültigkeitsdauer (V) des öffentlichen Schlus- sels, einen Namen (N) des Softwareproduktes, eine Versionsangabe (VA) des Softwareproduktes, eine Angabe (AS) des Gultig- keitszeitrahmens (S) des privaten Schlüssels und/oder eine Angabe (AU) des Update-Zeitrahmen (U) enthalt.
4. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass der Verfahrensschritt c) ein
- Überprüfen der Gültigkeit des öffentlichen Schlüssels (Kl) zur Bereitstellung des Aktualitats-Prufungsergebnisses zur Angabe der Aktualität der Version des Softwareproduktes in Abhängigkeit der Angabe (AV) des Gultigkeitszeitrahmens (V) des öffentlichen Schlüssels (Kl) oder in Abhängigkeit der Angabe (AV) des Gultigkeitszeitrahmens (V) des öffentlichen Schlüssels (Kl) und eines von einer dritten Einrichtung be- reitgestellten RuckrufStatus (R) des jeweiligen Zertifikats (Z) für die Version des Softwareproduktes; und/oder der Verfahrensschritt d) ein
- Durchfuhren einer Verifikation der empfangenen, mittels der digitalen Signatur signierten Version des Softwareproduktes zur Bereitstellung des Integritats-Prufungsergebnisses beinhaltet.
5. Verfahren nach Anspruch 1 oder einem der Ansprüche 2-4, dadurch gekennzeichnet, dass das Aktualitats-Prufungsergebnis als ein negatives Aktu- alitats-Prufungsergebnis interpretiert wird, wenn der Zeitpunkt des Startens oder Installierens der Version des Softwareproduktes auf der ersten Einrichtung spater als ein Ende des Gultigkeitszeitrahmens (V) des öffentlichen Schlüssels (Kl) ist.
6. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass das Aktualitäts-Prüfungsergebnis als ein negatives Aktu- alitäts-Prüfungsergebnis interpretiert wird, wenn der bereitgestellte RückrufStatus (R) angibt, dass das jeweilige Zertifikat (Z) für die entsprechende Version des Softwareproduktes zurückgerufen ist, oder der Zeitpunkt des Startens oder In- stallierens der Version des Softwareproduktes auf der ersten Einrichtung später als ein Ende des Gültigkeitszeitrahmens (V) des öffentlichen Schlüssels (Kl) liegt.
7. Verfahren nach Anspruch 2 oder einem der Ansprüche 3-6, dadurch gekennzeichnet, dass 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 Ak- tualitäts-Bestätigung von der zweiten Einrichtung mittels eines Netzwerks bereitgestellt wird.
8. Verfahren nach Anspruch 1 oder einem der Ansprüche 2-7, dadurch gekennzeichnet, dass nach den Schritten a) bis f) folgende Schritte vorgesehen sind:
- 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 aus- schließ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.
9. Verfahren nach Anspruch 1 oder einem der Ansprüche 2-7, dadurch gekennzeichnet, dass nach den Schritten a) bis f) folgende Schritte vorgese- hen sind:
- 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 aktuel- Ie 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 Ein- richtung geladen.
10. Verfahren nach Anspruch 2 oder einem der Ansprüche 3-9, dadurch gekennzeichnet, dass für jede bereitgestellte Version des Softwareproduktes der Gültigkeitszeitrahmen (V) des öffentlichen Schlüssels
(Kl), der Gültigkeitszeitrahmen (S) des privaten Schlüssels und/oder der Update-Zeitrahmen (U) festgelegt werden.
11. Verfahren nach Anspruch 1 oder einem der Ansprüche 2-10, dadurch gekennzeichnet, dass die verschiedenen digitalen Signaturen und die zu den jeweiligen digitalen Signaturen zugehörigen Zertifikate (Z) der verschiedenen Versionen des Softwareproduktes zur Bereit- Stellung eines Log-Files der Versionen des Softwareproduktes durch die erste Einrichtung und/oder die zweite Einrichtung gespeichert werden.
12. Verfahren nach Anspruch 8 oder einem der Ansprüche 9-11, dadurch gekennzeichnet, dass bei einem positiven Integritats-Prufungsergebnis und einem negativen Aktualitats-Prufungsergebnis 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 Aktualitats-Bestatigung in Abhängigkeit einer Eingabe des Nutzers der ersten Einrichtung geladen werden.
13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass bei einem Ausbleiben einer Eingabe des Nutzers innerhalb eines vorbestimmten Zeitfensters oder einer Eingabe des Nut- zers, welche angibt, dass kein Update der Version des Softwareproduktes erfolgen soll, die Version des Softwareproduktes der ersten Einrichtung nicht installiert wird oder in einem vorbestimmten eingeschränkten Funktionsumfang ausgeführt wird.
14. Verfahren nach Anspruch 2 oder einem der Ansprüche 3-13, dadurch gekennzeichnet, dass für jede Version des Softwareproduktes ein eigener privater Schlüssel mit festgelegtem Gultigkeitszeitrahmen und ein eigenes Zertifikat bereitgestellt und verwendet werden.
15. Verfahren nach Anspruch 2 oder einem der Ansprüche 3-14, dadurch gekennzeichnet, dass der Verfahrensschritt d) beinhaltet: - Überprüfen, ob ein Zeitpunkt der Erstellung der jeweiligen digitalen Signatur, welcher mittels eines in der digitalen Signatur beinhalteten Zeitstempels repräsentiert wird, inner- halb des Gültigkeitszeitrahmens (S) des privaten Schlüssels liegt .
16. Computerprogrammprodukt, welches auf einer programmge- steuerten Einrichtung die Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 15 veranlasst.
PCT/EP2008/057674 2007-08-22 2008-06-18 Verfahren zum prüfen einer auf einer ersten einrichtung auszuführenden oder zu installierenden version eines softwareproduktes WO2009024373A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP08774124A EP2191407A2 (de) 2007-08-22 2008-06-18 Verfahren zum prüfen einer auf einer ersten einrichtung auszuführenden oder zu installierenden version eines softwareproduktes

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102007039602.5 2007-08-22
DE102007039602A DE102007039602A1 (de) 2007-08-22 2007-08-22 Verfahren zum Prüfen einer auf einer ersten Einrichtung auszuführenden oder zu installierenden Version eines Softwareproduktes

Publications (2)

Publication Number Publication Date
WO2009024373A2 true WO2009024373A2 (de) 2009-02-26
WO2009024373A3 WO2009024373A3 (de) 2009-07-02

Family

ID=39683452

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2008/057674 WO2009024373A2 (de) 2007-08-22 2008-06-18 Verfahren zum prüfen einer auf einer ersten einrichtung auszuführenden oder zu installierenden version eines softwareproduktes

Country Status (3)

Country Link
EP (1) EP2191407A2 (de)
DE (1) DE102007039602A1 (de)
WO (1) WO2009024373A2 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8949797B2 (en) 2010-04-16 2015-02-03 International Business Machines Corporation Optimizing performance of integrity monitoring
US9262306B2 (en) 2010-01-27 2016-02-16 Hewlett Packard Enterprise Development Lp Software application testing

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110377310B (zh) * 2014-11-12 2023-04-07 松下电器（美国）知识产权公司 更新管理方法、更新管理装置以及计算机可读取的记录介质
EP3467696B1 (de) * 2017-10-09 2020-08-26 DriveLock SE Modul und verfahren zur sicherung von computersystemen

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003019337A2 (de) * 2001-08-27 2003-03-06 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur bereitstellung von software zur verwendung durch ein steuergerät eines fahrzeugs

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7711775B2 (en) * 2001-10-24 2010-05-04 Groove Networks, Inc. Method and apparatus for managing software component downloads and updates

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003019337A2 (de) * 2001-08-27 2003-03-06 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur bereitstellung von software zur verwendung durch ein steuergerät eines fahrzeugs

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9262306B2 (en) 2010-01-27 2016-02-16 Hewlett Packard Enterprise Development Lp Software application testing
US8949797B2 (en) 2010-04-16 2015-02-03 International Business Machines Corporation Optimizing performance of integrity monitoring

Also Published As

Publication number Publication date
EP2191407A2 (de) 2010-06-02
DE102007039602A1 (de) 2009-02-26
WO2009024373A3 (de) 2009-07-02

Similar Documents

Publication Publication Date Title
DE112006001978B4 (de) Verifizierte Computerumgebung für persönliches Internetkommunikationsgerät
DE102013108020A1 (de) Authentifizierungsschema zum Aktivieren eines Spezial-Privileg-Modus in einem gesicherten elektronischen Steuergerät
DE102013108022A1 (de) Verfahren zum Aktivieren des Entwicklungsmodus eines gesicherten elektronischen Steuergeräts
DE102013108021A1 (de) Verfahren zum selektiven Software-Rollback
WO2012130461A2 (de) Aktualisierung einer datenträgerapplikation
DE102013213314A1 (de) Hinterlegen mindestens eines berechenbaren Integritätsmesswertes in einem Speicherbereich eines Speichers
WO2017008953A1 (de) Verfahren und anordnung zum sicheren austausch von konfigurationsdaten einer vorrichtung
EP2885907B1 (de) Verfahren zur installation von sicherheitsrelevanten anwendungen in einem sicherheitselement eines endgerät
EP2673731B1 (de) Verfahren zur programmierung eines mobilendgeräte-chips
WO2009024373A2 (de) Verfahren zum prüfen einer auf einer ersten einrichtung auszuführenden oder zu installierenden version eines softwareproduktes
EP3695337B1 (de) Verfahren und bestätigungsvorrichtung zur integritätsbestätigung eines systems
WO2022008201A1 (de) Verfahren zur erweiterten validierung eines containerabbilds
DE102018217431A1 (de) Sicherer Schlüsseltausch auf einem Gerät, insbesondere einem eingebetteten Gerät
WO2017194332A1 (de) Verbessern einer geräteauthentifizierung mit hilfe von geräteüberwachungsdaten
EP2038805B1 (de) Verfahren zum delegieren von privilegien an eine niedriger-privilegierte instanz durch eine höher-privilegierte instanz
DE102006049442A1 (de) Verfahren zum Freischalten einer Chipkarte
EP3752911B1 (de) Verfahren zum installieren eines programmcodepakets in ein gerät sowie gerät und kraftfahrzeug
WO2021228581A1 (de) Erstellen einer container-instanz mit an hardware gebundene lizensüberprüfung
EP3101875B1 (de) Ändern von einstellungen einer auf einem mobilen endgerät laufenden applikation
EP2923264A1 (de) Verfahren und system zur applikationsinstallation in einem sicherheitselement
DE102012022874A1 (de) Applikationsinstallation
EP3673614B1 (de) Verfahren und validierungseinrichtung zum validieren eines digitalen zertifikats
DE102021125851A1 (de) Problemmanagement in einem benutzersystem
EP4083831A1 (de) Digitales zertifikat
DE102020002055A1 (de) Datenverarbeitungsvorrichtung zur Provisionierung eines Hardware-Prozessorsystems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08774124

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2008774124

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE