EP1364512A2 - Verfahren und kommunikationssystem zum bereitstellen eines programm-elements - Google Patents

Verfahren und kommunikationssystem zum bereitstellen eines programm-elements

Info

Publication number
EP1364512A2
EP1364512A2 EP02708167A EP02708167A EP1364512A2 EP 1364512 A2 EP1364512 A2 EP 1364512A2 EP 02708167 A EP02708167 A EP 02708167A EP 02708167 A EP02708167 A EP 02708167A EP 1364512 A2 EP1364512 A2 EP 1364512A2
Authority
EP
European Patent Office
Prior art keywords
computer
program element
identification information
approval message
installation approval
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP02708167A
Other languages
English (en)
French (fr)
Inventor
Rainer Falk
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
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 AG filed Critical Siemens AG
Publication of EP1364512A2 publication Critical patent/EP1364512A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/101—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity

Definitions

  • the invention relates to a method and a communication system for providing a program element.
  • a common cellular phone is made using
  • the software is usually loaded by the cell phone, installed and executed there to ensure different functionalities in the cell phone.
  • the cell phone is controlled by software in its radio properties (for example the frequency bands to be used, the transmission power to be used or the modulation method to be used) or other properties such as the type of
  • a mobile telephone generally a communication terminal or a mobile terminal
  • the functionality of a mobile telephone can thus be specifically changed or expanded by loading appropriate software.
  • software can be transmitted to the mobile phone via any unsecured channels, in particular via a radio channel.
  • a method for reliably providing software should advantageously not be dependent on specific assumptions about the type of software distribution.
  • a digital signature uses the principle of asymmetric cryptography, in which a private key and a corresponding public key, which together form an asymmetrical key pair, are used.
  • a certificate of the respective public cryptographic key is used to securely certify a link between the public cryptographic key and the name of the person or organization to which the public key belongs. This ensures that the key pair used, consisting of the respective private cryptographic key and public cryptographic key, is reliable.
  • asymmetric cryptography has the particular disadvantage that, for example, a high computing power is required when creating a digital signature, which often even leads to the fact that special cryptographic co-processors are used in the respective computers producing the digital signature.
  • the verification of the digital signature is a very computationally complex task due to the asymmetrical cryptographic operations to be carried out, which often considerably overwhelms the computing power resources available in a mobile telecommunications terminal.
  • sequence of certificates used to secure the public keys used must be validated for what purpose an evaluation of the data contained in the certificates, such as checking the validity of the certificates used or taking into account predefinable restrictions in the use of the respective certificates.
  • the additional security information that is, for example, the digital signature and the associated information
  • the invention is therefore based on the problem of specifying a method and a communication system for providing a program element by means of which a lower computing requirement is achieved and in which the amount of data required to transmit the security information is reduced.
  • the program element is transmitted from the first computer to the second computer. Furthermore, an installation approval message is transmitted to the second computer, wherein the installation approval message contains at least first identification information, second identification information and a cryptographic value that relates to at least the first identification information and the second identification -Information was formed contains.
  • the first identification information the program element provided is identified, preferably uniquely.
  • the second identification information it is possible to identify the second computer, also preferably uniquely.
  • the cryptographic value is formed using a symmetrical secret key, the symmetrical secret key being available, that is to say stored, both in the second computer and in an authentication unit. Using the symmetrical secret key, the cryptographic value is verified in the second computer and in the event that the verification is successful and the installation approval message contains the information that the program element may be installed and / or may be executed, the program element is installed or executed in the second computer.
  • Identification information in each case explicitly and / or implicitly.
  • An example of the information being available implicitly can be seen in the use of a cryptographic key used in each case, which permits a corresponding conclusion to be drawn about the particular instance using the key.
  • the first identification information can be a hash value that is formed via the respective program element.
  • a communication system for providing a program element has
  • the installation approval message contains at least the following information: first identification information with which the provided program element is identified, second identification information with which the second computer is identified, a cryptographic value about at least the first identification information and the second identification information,
  • a symmetrical secret key being stored in the second computer and in the authentication unit
  • the authentication unit has a unit for forming the cryptographic value using the symmetrical secret key
  • the second computer has a verification unit for verifying the cryptographic value using the symmetrical secret key
  • the invention can clearly be seen in the fact that a ticket is used in addition to the program element, which contains unambiguous, reliable security information for identifying the program element provided and the second computer, i.e. the computer on which the program element is installed or is to be carried out.
  • the reliability of the identification information is achieved by the cryptographic value that is formed via the identification information using the symmetrical secret key.
  • a program element is any type of computer program or part of one
  • executing a computer program also means interpreting a computer program, for example interpreting a computer program in Java (Java bytecode) using a virtual machine.
  • the cryptographic value can be a cryptographic hash value, which is preferably formed according to one of the following methods:
  • CBC-MAC using a known block cipher (e.g. DES, 3DES, AES, IDEA),
  • a known block cipher e.g. DES, 3DES, AES, IDEA
  • HMAC-MD5 eg MD5, SHA-1, RIPEMD, RIPEMD160
  • HMAC-SHA1 HMAC-SHA1
  • HMAC-RIPEMD HMAC-RIPEMD160
  • HMAC-RIPEMD160 • HMAC using a known hash function with shortened output (eg HMAC- MD5-80, HMAC-SHA1-80, HMAC-RIPEMD-80, HMAC-RIPEMD160-80 with output shortened to 80 bits)
  • the cryptographic hash value is also referred to as the message authentication code (MAC).
  • the functions used to determine a message authentication code are also referred to as a “keyed hash function *.
  • Additional information can be added to the ticket, i.e. the installation approval message, for example:
  • Installation approval message is reliable, that is, is valid
  • the authentication unit can be contained in the first computer, in which case both the program element and the installation approval message are stored in the first computer.
  • a further computer with a database which clearly functions as a program archive (download archive), can be provided, which transfers the desired program element to the first computer.
  • the installation approval messages which are specific to a tuple of the following units, can also be found in the download archive:
  • • second computer, and • program element can be stored in a communication network on the basis of the unique assignment of the symmetrical secret keys to the second computer and the respective authentication unit.
  • the authentication unit is not contained in the first computer, it can alternatively be provided that the authentication unit has access to the download archive and loads installation authorization messages previously stored there, if necessary.
  • the authentication unit itself can also form the cryptographic value using the symmetric secret key accessible to it.
  • the entire installation approval message itself can also be secured using a cryptographic method, for example encrypted or signed using asymmetrical or symmetrical cryptography.
  • a request message is sent from the second computer to the authentication unit with the first identification information contained in the request message and a second one
  • the authentication unit it is determined whether the program element belonging to the respective first identification information and the second computer corresponding to the second identification information, whether the program element may be installed or executed at all. If this is the case, an installation approval message is generated and sent to the second computer.
  • Both the installation approval message and the request message can contain different one-time values or the same one-time value, in which case the degree of security is further increased as part of the method.
  • the one-time value used can be, for example, a random number or a predeterminable counter value.
  • the same one-time value is used in the installation approval message and in the request message, a binding is achieved between the request message and the installation approval message, the level of cryptographic security being further increased if the cryptographic value additionally exceeds the One-time value is formed.
  • the second computer is a telecommunications terminal, for example a mobile telecommunications terminal, preferably a mobile radio communication terminal, that is to say a mobile radio telephone.
  • FIG. 1 shows a block diagram in which a communication system is shown, which is designed according to the GSM standard
  • Figure 2 is a block diagram of a communication system according to a first embodiment of the invention.
  • Figures 3a and 3b is a block diagram of a
  • Figures 4a to 4c a block diagram of a
  • FIGS. 5a and 5b message flow diagrams in the event that a
  • FIG.5a Installation approval message is transmitted, which allows an installation or execution of the program element (Fig.5a) or with an installation approval message, which does not allow the installation or execution of the program element (cf. 5 b);
  • Figure 6 is a flow chart in which the individual
  • FIG. 7 shows a flow chart in which the individual method steps that are carried out in the authentication unit according to an exemplary embodiment of the invention are shown.
  • Fig.l shows a communication system 100 with a.
  • a large number of mobile communication terminals 101 each of which is connected via an air interface 102, that is to say a radio link, to a base transceiving station (BTS) 103, also referred to below as a base station, each of which is a base station system 104 (Base Station System, BSS) are assigned, wherein a base control station (Base Station Controller, BSC) 105 is provided for each base station system 104 for controlling the base station (s) 103 contained in the base station system 104.
  • BSS Base Station System
  • BSC Base Station Controller
  • At least some of the base station systems 104 of the communication system 100 are in accordance with the GSM / GPRS / EDGE standard with a mobile switching center 106 (Mobile Switching Center, MSC) for the transmission of line-bound voice or data and with an SGSN 107 (Serving GPRS Support Node) for the transmission packet data to a gateway (Gateway GPRS Support Node, GGSN) 108 connected to a packet data network 112.
  • MSC Mobile Switching Center
  • SGSN 107 Serving GPRS Support Node
  • GGSN Gateway
  • the mobile switching center 106 is connected to a conventional telephone network 109.
  • the central exchange 106 or the SGSN 107 performs functions required for the exchange of communication connections for the operation of the mobile communication terminals 101 in the respective groups of Base station systems 104, for which a mobile switching center 106 or the SGSN 107 is "responsible".
  • the functions provided by the mobile switching center 106 or SGSN 107 include
  • Procedures that are used to interact with other communication networks for example a fixed network such as PSTN, ISDN,
  • Each base station 103 is connected via the packet data network 112 to an authentication unit 110, which is explained in more detail below.
  • the communication system 100 has at least one
  • Program element provisioning computer 111 which is also coupled to the mobile communication terminals 101 via the packet data network 112.
  • FIG. 2 shows a simplified illustration of the communication system 200 according to a first exemplary embodiment of the invention.
  • a program element 202 is stored in a program element provisioning computer 201 and is transmitted via a
  • Communication connection 203 transmitted from the program element provisioning computer 201 to a mobile communication terminal, in accordance with this exemplary embodiment a mobile telephone 101, and stored there.
  • the mobile communication terminal 101 receives the program element 202 from a source not trusted by the mobile communication terminal 101.
  • the mobile communication terminal 101 Before the actual installation or execution of the program element 202, the mobile communication terminal 101 checks whether the program element is trustworthy and whether it may be installed or executed at all.
  • the mobile communication terminal 101 requests an installation approval message from an authentication unit 204, which is explained in more detail below.
  • the authentication unit 204 Based on the request message 205, it is determined in the authentication unit 204 whether the respective program element 202 may be installed or executed on the mobile communication terminal 101 or not.
  • the result of the check is transmitted to the mobile communication terminal 101 with an installation approval message 207 from the authentication unit 204 to the mobile communication terminal 101 via the communication link 206.
  • FIG. 3a and 3b show alternative architectures of a communication system 300, 310 according to further exemplary embodiments of the invention.
  • the program element 302 is stored in the program element provisioning computer 301 (cf. FIG. 3a).
  • the program element 302 is accessed by the program element provisioning computer 301 via a first communication link 303, according to this
  • Embodiment at least partially transmit a radio link to the mobile communication terminal 101.
  • program element 302 is a second
  • the installation approval message 306 is transmitted to the mobile communication terminal 101 via a third communication connection 307, likewise a radio connection according to this exemplary embodiment.
  • the mobile communication terminal 101 it is checked on the basis of the installation approval message 306, as will be explained in more detail below, whether the received program element 302 may be installed or executed.
  • 3b shows an alternative architecture, in which the authentication unit 305 only with the program element provisioning computer 301 via the second
  • Communication connection 304 is connected and not directly to the mobile communication terminal 101. After receiving the program element 302 or alternatively after receiving an inquiry message (not shown), the installation approval message 306 is also formed. In a further step, the installation approval message 306 is transmitted via the second communication connection 304 to the program element provisioning computer 301 and from there to the mobile communication terminal 101.
  • 4 a to 4 b show further alternatives of a communication system 400, 420, 430 according to further exemplary embodiments of the invention.
  • an archive computer 401 is provided in which a multiplicity of program elements 402, 403,... 404 are stored.
  • the archive computer 401 has a first one
  • the program element provisioning computer 409 is connected to the mobile communication terminal 101 via a second communication connection 410.
  • a program element 402, 403, 404 optionally requested by the program element provisioning computer 409 is transmitted from the archive computer 401 to the program element provisioning computer 409, temporarily stored there or stored permanently and via the third communication connection 412 to the mobile communication terminal 101 transmitted.
  • 4b shows an alternative architecture in which a large number of installation approval messages 405, 406,... 407 are stored in the archive computer 401.
  • the exemplary embodiment according to FIG. 4b differs from the exemplary embodiment according to FIG. 4a in particular in that, as in the exemplary embodiment according to FIG. 3b, the authentication unit 411 with the program element provision computer 409 via a third
  • Communication link 412 is connected. After receipt of the program element 402 or alternatively after receipt of a request message (not shown), the installation approval message 405, 406, 407 is formed.
  • the installation approval message 405 is transmitted via the third communication connection 412 to the program element provisioning computer 301 and from there via the second communication connection 410 to the mobile communication terminal 101.
  • the exemplary embodiment shown in FIG. C differs from the exemplary embodiment according to FIG. B in particular in that, as in the exemplary embodiment according to FIG. 3a, the authentication unit 411 is connected directly to the mobile communication terminal 101 via a fourth communication connection 413. According to this exemplary embodiment, the installation approval message 405 is thus transmitted directly to the mobile communication terminal 101 via the fourth communication connection 413.
  • the procedure described below, in particular the structure of the request message and the installation approval message, is identical for all the exemplary embodiments described above in which the respective messages are used.
  • the procedure for providing a program element becomes the structure of the communication system 200 according to the first to simplify the illustration of the invention
  • the program element 202 becomes the program element 202 via the first communication link 203 to the mobile
  • the request message 205 is formed by the mobile communication terminal 101.
  • the request message 205 has the following information:
  • the random number N serves to create a logical link between the request message 205 and a first type of installation authorization message 501 described below.
  • the first type of installation approval message 501 which is transmitted by the authentication unit 204 to the mobile communication terminal 101 (cf. FIG. 5 a) in the event that the program element 202 is trustworthy and on the mobile communication Terminal 101 may be installed or executed contains
  • the following information can additionally be contained in the installation approval message 501:
  • the authentication unit 204 forms an installation approval message 502 in which an error 503 is given is contained and sends this to the mobile communication terminal 101 (see FIG. 5b).
  • the request message 205 and / or the installation approval message 501 are cryptographically secured using a symmetrical cryptographic method.
  • the cryptographically strong hash value H which was formed via the program element 202, is determined according to this exemplary embodiment in accordance with the MD5 method or the SHA-1 method as a cryptographic checksum.
  • the checksum is determined using the data contained in the installation approval message of the first type 501 using a secret symmetrical key that is only known and stored in the mobile communication terminal and the authentication unit 204 , formed, for example using a method for forming a message
  • the installation approval message 501 and the information contained therein is generated in a simple and thus very efficient manner by the security information, which is formed below using the symmetrical secret key, at least via the first identification information and the second identification information, hereinafter referred to as the cryptographic value Information protected,
  • Authentication unit 204 unique secret symmetric key can in principle be used in the context of the invention any method for generating a symmetrical key and for distributing such in the two communicating units.
  • FIG. 6 shows in a flowchart 600 the individual method steps which are carried out in the mobile communication terminal 101 according to the first exemplary embodiment of the invention.
  • the program element 202 is received in the mobile communication terminal 101 in a further step (step 602) as described above.
  • the first identification information that is to say the information for identifying the program element 202, is received and stored in the mobile communication terminal 101.
  • a random number N is formed and using the random number N, the.
  • the request message 205 is formed and the identification information and the second identification information are sent to the authentication unit 204.
  • the mobile communication terminal 101 After the request message 205 has been sent in its entirety, the mobile communication terminal 101 goes into a waiting state and waits for the receipt of an installation approval message 501, 502 which is to be sent by the authentication unit 204.
  • FIG. 7 shows in a flowchart 700 the individual method steps which are carried out in the authentication unit 204 in accordance with this exemplary embodiment of the invention.
  • a transition is made to a waiting state, in which the authentication unit 204 waits for the receipt of a request message that was sent from a mobile communication terminal 101.
  • a request message 205 is received in a further step (step 702), then in a first test step (step 703) it is checked using the second identification information whether the authentication unit 204 is for the mobile communication terminal 101, which is identified by the second identification information is responsible, in other words, whether the authentication unit 204 supports the mobile communication terminal 101.
  • the installation approval message of the second type 502 is formed with a corresponding error information 503 and transmitted to the mobile communication terminal 101 (step 704).
  • the authentication unit 204 supports the mobile communication terminal 101 identified by the second identification information, it is checked in a second test step (step 705) using the first identification information whether the program element designated by the first identification information may be accepted by the respective mobile communication terminal 101.
  • an installation approval message 502 with the corresponding error message 503 is again formed in step 704 and transmitted to the mobile communication terminal 101.
  • the authentication unit 204 in a further step (step 706) uses the cryptographic hash value H using the MD5 method or of the SHA-1 method is determined or a stored cryptographic hash value that was previously determined specifically for the program element 202 is read out or ascertained.
  • a message authentication code is determined using the symmetrical secret key, which is known to both the authentication unit 204 and the mobile communication terminal 101.
  • step 708 the installation approval message of the first type 501 is formed and sent to the mobile communication terminal 101.
  • step 704 or 708 After sending the installation approval message first type 501 or second type 502 (steps 704 or 708) the method in the authentication unit 204 is ended (step 709).
  • step 605 If the mobile communication terminal 101 receives the installation approval message 501, 503 (step 605), it is then checked in a third test step (step 606) whether the installation approval message is an installation approval message 502 or whether the checksum, i.e. the message authentication code is invalid or whether a format error is determined.
  • the loaded program element 202 is not accepted, that is to say not installed and also not executed (symbolized in FIG. 6 by block 607).
  • a fourth check step (step 608) checks whether the first identification Information, the second identification information and the random number contained in the installation approval message of the first type 501, match the respective first identification information, second identification information and
  • Random number that was sent from the mobile communication terminal 101 in the request message 205 to the authentication unit 204 is a value that was sent from the mobile communication terminal 101 in the request message 205 to the authentication unit 204.
  • the loaded program element 202 is not accepted (block 607).
  • step 609 it is checked in a fifth test step (step 609) whether the hash value H contained in the installation approval message 501 and the hash value likewise determined by the mobile communication terminal 101 match via the program element 202.
  • the same algorithm is used in the mobile communication terminal to form the hash value as in the authentication unit 204.
  • the loaded program element is again not accepted (block 607).
  • the loaded program element 202 is accepted (step 610), that is to say the program element 202 is installed or executed.
  • step 611 After the program element 202 is accepted or not accepted (steps 610, 607), the method in the mobile communication terminal 101 is ended (step 611).
  • the order of the information, both in the request message 206 and in the installation approval message 501, can be changed flexibly.
  • the hash value H can already be contained in the request message 206.
  • the installation type approval message 501 only confirms that the hash value H contained in the request message 206 is correct. In this case, the hash value H is thus checked in the authentication unit 204 and not in the mobile communication terminal 101. It should also be pointed out that the use of a random number is optional and that the random numbers used can be different in the request message or in the first type of installation approval message 501.
  • Identification information for identifying the user of the mobile communication terminal 101 and / or for identifying the authentication unit 204 may additionally be contained in the request message 206 and / or in the installation approval message.
  • a plurality of inquiries or installation approval messages can be contained in a bundled inquiry message or bundled installation approval message and transmitted together.
  • the mobile communication terminal 101 can again check the program element by means of a further request message, optionally with another authentication unit. This procedure allows the reliability to be further increased, in particular when transmission errors occur or when an authentication unit fails.
  • a predeterminable counter value can be used.
  • An authentication unit can be provided which creates installation approval messages for any number of providers of program Elements. There can also be several
  • Authentication units can be included in the communication system, each of which creates installation approval messages for one or more providers of program elements and transmits them to the respective mobile communication terminal.
  • the authentication unit can be contained in a computer together with the program element provisioning computer or the program element provisioning computer can directly request an installation approval message from the authentication unit for the mobile communication terminal 101 and that generated installation approval message together with the program element to the mobile communication terminal.
  • the creation of an installation approval message of the first type can be made dependent on the authentication unit depending on whether a license for the respective program element is available and is known to the authentication unit.
  • a legal financial claim is justified on the basis of an installation approval message of the first type 501, for example a claim for remuneration for the use of the loaded program element.
  • the additional information described above can be divided into several installation approval messages transmitted one after the other.
  • the different installation approval messages are different Authentication instances are requested, created and transmitted to the mobile communication terminal.
  • the authentication instance is clearly provided as a ticket server, which only issues installation tickets, that is to say the installation approval messages, for program elements which are valid from the point of view of the authentication unit. These installation tickets are used to ensure that a mobile communication terminal only accepts valid software, ie only valid program elements.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Es wird ein Programm-Element zu dem zweiten Rechner übertragen sowie eine Installations-Genehmigungs-Nachricht, die eine erste Identifizierungs-Information, eine zweite Identifizierungs-Information sowie einen kryptographischen Wert über zumindest diese Identifizierungs-Informationen aufweist. Die erste Identifizierungs-Information identifiziert das bereitgestellte Programm-Element und die zweite Identifizierungs-Information den zweiten Rechner. Der kryptographische Wert wird unter Verwendung des symmetrischen geheimen Schlüssels gebildet, der in dem zweiten Rechner und in einer Authentifizierungseinheit verfügbar ist. Unter Verwendung des symmetrischen geheimen Schlüssels wird der kryptographische Wert in dem zweiten Rechner verifiziert.

Description

Beschreibung
Verfahren und Kommunikationssystem zum Bereitstellen eines Programm-Elements
Die Erfindung betrifft ein Verfahren und ein KoirtmunikationsSystem zum Bereitstellen eines Programm- Elements.
Ein übliches Mobilfunk-Telefon wird unter Verwendung von
Software gesteuert. Die Software wird üblicherweise durch das Mobilfunk-Telefon geladen, dort installiert und ausgeführt, um unterschiedliche Funktionalitäten in dem Mobilfunk-Telefon zu gewährleisten.
So wird das Mobilfunk-Telefon beispielsweise mittels Software in seinen Funkeigenschaften (beispielsweise die zu verwendenden Frequenzbänder, die zu verwendende Sendeleistung oder auch zu verwendende Modulationsverfahren) oder sonstigen Eigenschaften gesteuert wie zum Beispiel die Art der
Signalisierung, unterschiedliche Strategien zur Frequenzwahl oder unterschiedliche angebotene, das heißt bereitgestellte Dienste.
Um die Software zu aktualisieren oder auch um Software erstmals auf das Mobilfunk-Telefon zu laden, dort zu installieren und auszuführen ist es erforderlich, die Software von einem Server-Computer zu dem Mobilfunk-Telefon zu übertragen.
Somit kann durch Laden von entsprechender Software die Funktionalität eines Mobilfunk-Telefons, allgemein eines Kommunikationsendgeräts oder eines Mobilfunk-Terminals, gezielt verändert oder erweitert werden.
Um eine Manipulation des Mobilfunk-Telefons durch unberechtigte Dritte zu verhindern, ist zu gewährleisten, dass das Mobilfunk-Telefon lediglich Software akzeptiert und somit installiert und ausführt, die von einem autorisierten und damit verlässlichen Anbieter stammt und für die gewährleistet ist, dass die Software nicht modifiziert wurde.
In diesem Zusammenhang ist zu berücksichtigen, dass Software über beliebige ungesicherte Kanäle, insbesondere über einen Funkkanal, zu dem Mobilfunk-Telefon übertragen werden kann. So kann beispielsweise Software von einem Personal Computer, einem allgemein zugänglichen Rechner, der beispielsweise an einem Flughafen oder einem Bahnhof installiert ist, oder einem anderen Mobilfunk-Telefon, allgemein einem anderen Mobilfunk-Terminal, allgemein über eine Luftschnittstelle, das heißt über eine Funkverbindung, oder leitungsgebunden über ein Anschlusskabel bezogen werden.
Ein Verfahren zum verlässlichen Bereitstellen von Software sollte vorteilhafterweise nicht von speziellen Annahmen über die Art der Verteilung von Software abhängig sein.
Zum Gewährleisten der Integrität und des sicheren Nachweises der Herkunft von Software ist es bekannt, Software unter Verwendung des Prinzips der asymmetrischen Verschlüsselung digital mit dem geheimen Schlüssel des Software-Anbieters zu signieren.
In diesem Zusammenhang ist es bekannt, digital signierte JAR- Dateien bei JAVA zu verwenden, die auch im Rahmen von MExE (Mobile Station Application Execution Environment) , einer Ausführungsumgebung für Anwendungen auf einem Mobilfunk- Telefon, verwendet werden, oder die auch im Internet verwendeten Techniken wie dem sogenannten Microsoft Authenticode™ und dem Netscape Object Signing™ einzusetzen.
Bei diesen bekannten Verfahren wird der Software eine digitale Signatur und eventuell weitere Daten, die zur Überprüfung der digitalen Signatur verwendet werden, hinzugefügt. Eine digitale Signatur verwendet das Prinzip der asymmetrischen Kryptographie, bei der ein privater Schlüssel und ein korrespondierender öffentlicher Schlüssel, welche gemeinsam ein asymmetrisches Schlüsselpaar bilden, verwendet werden.
Nur der Inhaber eines privaten kryptographischen Schlüssels kann auch eine gültige digitale Signatur erzeugen, jedoch kann jeder, der zu dem jeweiligen privaten kryptographischen Schlüssel passenden öffentlichen kryptographischen Schlüssel kennt, die Signatur überprüfen.
Ein Zertifikat des jeweiligen öffentlichen kryptographischen Schlüssels wird verwendet, um eine Bindung zwischen dem öffentlichen kryptographischen Schlüssel und dem Namen der Person oder Organisation, zu der der öffentliche Schlüssel gehört, sicher zu bescheinigen. Auf diese Weise wird gewährleistet, dass das verwendete Schlüsselpaar aus jeweiligem privaten kryptographischen Schlüssel und öffentlichem kryptographischen Schlüssel verlässlich ist.
Der Einsatz der asymmetrischen Kryptographie weist insbesondere den Nachteil auf, dass beispielsweise bei der Erstellung einer digitalen Signatur eine hohe Rechenleistung erforderlich ist, was häufig sogar dazu führt, dass spezielle kryptographische Co-Prozessoren in den jeweiligen die digitale Signatur erstellenden Rechnern verwendet werden.
Insbesondere auch die Überprüfung der digitalen Signatur ist aufgrund der durchzuführenden asymmetrischen kryptographischen Operationen eine sehr rechenaufwendige Aufgabe, die häufig die bei einem mobilen Telekommunikations- Endgerät zur Verfügung stehenden Rechenleistungs-Ressourcen erheblich überfordert.
Außerdem muss die verwendete Folge von Zertifikaten zur Sicherung der verwendeten öffentlichen Schlüssel validiert werden, wozu eine Auswertung der in den Zertifikaten enthaltenen Daten, wie beispielsweise die Überprüfung der Gültigkeit der verwendeten Zertifikate oder die Berücksichtigung vorgebbarer Einschränkungen in der Benutzung der jeweiligen Zertifikate.
Zur Überprüfung der Gültigkeit der verwendeten Zertifikate ist beispielsweise neben weiteren Signaturprüfungen das Laden einer Zertifikats-Widerrufsliste (Certificate Revocation List, CRL) oder eine Online-Überprüfung des Zustands des jeweiligen Zertifikats beispielsweise gemäß dem Online Certificate Status Protocol erforderlich.
Ferner führt die zusätzliche Sicherungsinformation, das heißt beispielsweise die digitale Signatur und die zugehörigen
Zertifikate zu den öffentlichen Schlüsseln zu einer erhöhten zu übertragenden Datenmenge (Datenvolumen) .
Insbesondere bei einer Übertragung über einen Kanal mit einer nur geringen zur Verfügung stehenden Bandbreite, wie beispielsweise bei der Übertragung über eine Funkverbindung, besteht somit das Bedürfnis, die zu übertragende Datenmenge, insbesondere beim Übertragen eines Programms, das heißt bei der Übertragung von Software, möglichst gering zu halten.
Somit liegt der Erfindung das Problem zugrunde, ein Verfahren und ein Kommunikationssystem zum Bereitstellen eines Programm-Elements anzugeben, durch welches ein geringerer Rechenbedarf erreicht wird und bei dem die benötigte Datenmenge zur Übertragung der Sicherungsinformation reduziert ist.
Das Problem wird durch das Verfahren und das
Kommunikationssystem mit den Merkmalen gemäß den unabhängigen Patentansprüchen gelöst. Bei einem Verfahren zum Bereitstellen eines Programm-Elements von einem ersten Rechner für einen zweiten Rechner wird von dem ersten Rechner das Programm-Element zu dem zweiten Rechner übertragen. Ferner wird eine Installations- Genehmigungs-Nachricht zu dem zweiten Rechner übertragen, wobei die Installations-Genehmigungs-Nachricht zumindest eine erste Identifizierungs-Information, eine zweite Identifizierungs-Information sowie einen kryptographischen Wert, der über zumindest die erste Identifizierungs- Information und die zweite Identifizierungs-Information gebildet wurde, enthält. Mit der ersten Identifizierungs- Information wird das bereitgestellte Programm-Element, vorzugsweise eindeutig, identifiziert. Mittels der zweiten Identifizierungs-Information ist es möglich, den zweiten Rechner, ebenfalls vorzugsweise eindeutig, zu identifizieren. Der kryptographische Wert wird unter Verwendung eines symmetrischen geheimen Schlüssels gebildet, wobei der symmetrische geheime Schlüssel sowohl in dem zweiten Rechner als auch in einer Authentifizierungs-Einheit verfügbar, das heißt gespeichert, ist. Unter Verwendung des symmetrischen geheimen Schlüssels wird der kryptographische Wert in dem zweiten Rechner verifiziert und für den Fall, dass die Verifikation erfolgreich ist, und in der Installations- Genehmigungs-Nachricht die Information enthalten ist, dass das Programm-Element installiert werden darf und/oder ausgeführt werden darf, so wird das Programm-Element in dem zweiten Rechner installiert bzw. ausgeführt.
Es ist in diesem Zusammenhang anzumerken, dass die Information, insbesondere die jeweilige
Identifizierungsinformation, jeweils explizit und/oder implizit vorliegen kann. Ein Beispiel dafür, dass die Information implizit vorliegt kann in der Verwendung eines jeweils verwendeten kryptographischen Schlüssels, der einen entsprechenden Rückschluss auf die jeweilige den Schlüssel verwendende Instanz zulässt, gesehen werden. Die erste Identifizierungsinformation kann ein Hash-Wert sein, der über das jeweilige Programm-Element gebildet wird.
Ein Kommunikationssystem zum Bereitstellen eines Programm- Elements, weist auf
• einen ersten Rechner, in dem das Programm-Element gespeichert ist, wobei der erste Rechner eine Sendeeinheit enthält zum Senden des Programm-Elements zu einem zweiten Rechner, • den zweiten Rechner, wobei der zweite Rechner eine
Empfangseinheit zum Empfangen des Programm-Elements und einer Installations-Genehmigungs-Nachricht enthält,
• wobei die Installations-Genehmigungs-Nachricht zumindest folgende Informationen enthält: - eine erste Identifizierungsinformation, mit der das bereitgestellte Programm-Element identifiziert wird, eine zweite Identifizierungsinformation, mit der der zweite Rechner identifiziert wird, - einen kryptographischen Wert über zumindest die erste Identifizierungsinformation und die zweite Identifizierungsinformation,
• eine Authentifizierungseinheit,
• wobei ein symmetrischer geheimer Schlüssel in dem zweiten Rechner und in der Authentifizierungseinheit gespeichert ist,
• wobei die Authentifizierungseinheit eine Einheit zum Bilden des kryptographischen Werts unter Verwendung des symmetrischen geheimen Schlüssels aufweist, • wobei der zweite Rechner eine Verifikationseinheit zum Verifizieren des kryptographischen Werts unter Verwendung des symmetrischen geheimen Schlüssels aufweist, und
• wobei der zweite Rechner eine Entscheidungseinheit aufweist, die derart eingerichtet ist, dass unter
Verwendung der Installations-Genehmigungs-Nachricht und des verifizierten kryptographischen Werts ermittelt wird, ob das Programm-Element in dem zweiten Rechner installiert oder ausgeführt werden darf.
Anschaulich kann die Erfindung darin gesehen werden, dass ein Ticket zusätzlich zu dem Programm-Element verwendet wird, das eine eindeutige verlässliche Sicherungsinformation zur Identifizierung des bereitgestellten Programm-Elements und des zweiten Rechners, das heißt desjenigen Rechners, auf dem das Programm-Element installiert bzw. ausgeführt werden soll, enthalten ist. Die Verlässlichkeit der Identifizierungs- Informationen wird erreicht durch den kryptographischen Wert, der über die Identifizierungs-Informationen unter Verwendung des symmetrischen geheimen Schlüssels gebildet wird.
Aufgrund des Einsatzes eines symmetrischen kryptographischen Verfahrens zur Bildung des kryptographischen Werts ist sowohl die Bildung des kryptographischen Werts als auch dessen Verifikation erheblich einfacher und somit mit erheblich geringerem Rechenzeitbedarf durchführbar. Außerdem wird für die Installations-Genehmigungs-Nachricht eine gegenüber der digitalen Signatur üblicherweise erforderlichen Datenmenge erheblich reduzierter Datenmenge erreicht.
Unter einem Programm-Element ist in diesem Zusammenhang jede Art von Computerprogramm oder eines Teils eines
Computerprogramms zu verstehen, welches von einem Prozessor ausgeführt werden kann. Unter dem Ausführen eines Computerprogramms ist in diesem Zusammenhang auch das Interpretieren eines Computerprogramms, beispielsweise das Interpretieren eines Computerprogramms in Java (Java- Bytecode) mittels einer virtuellen Maschine, zu verstehen.
Bevorzugte Weiterbildungen der Erfindung ergeben sich aus den abhängigen Ansprüchen. Der kryptographische Wert kann ein kryptographischer Hash- Wert sein, der vorzugsweise gemäß einem der folgenden Verfahren gebildet wird:
• CBC-MAC unter Verwendung einer bekannten Blockchiffre (z.B. DES, 3DES, AES, IDEA) ,
• HMAC unter Verwendung einer bekannten Hash-Funktion
(z.B. MD5, SHA-1, RIPEMD, RIPEMD160), die auch als HMAC- MD5, HMAC-SHA1, HMAC-RIPEMD, HMAC-RIPEMD160 bezeichnet werden, • HMAC unter Verwendung einer bekannten Hash-Funktion mit gekürzter Ausgabe (z.B. HMAC-MD5-80, HMAC-SHA1-80, HMAC- RIPEMD-80, HMAC-RIPEMD160-80 bei auf 80 Bit gekürzter Ausgabe) ,
• MAA, • RIPE-MAC,
• MD5-MAC.
Eine Übersicht über weiterhin ebenfalls verwendbare Verfahren zum Bilden des kryptographischen Hash-Werts ist in (Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone , Handbook of Applied Cryptography, CRC Press Series on Discrete Mathe atics and Its Applications, Series Editor: Kenneth H. Rosen, Oktober 1996, CRC Press (Boca Raton, New York, London, Tokyo), ISBN 0849385237, S. 340 - 365) und in dem Request for Com ents Nr. 2104 der IETF (RFC 2104) zu finden.
Der kryptographische Hash-Wert wird auch als Nachrichtenauthentifizierungscode (Message Authentication Code, MAC) bezeichnet. Die zum Ermitteln eines Nachrichtenauthentifizierungscodes verwendeten Funktionen werden auch als „Keyed Hash Function* bezeichnet.
Aufgrund des Einsatzes standardisierter und üblicherweise außer in Software auch in Hardware implementierbarer Kryptoverfahren zur Bildung eines Hash-Wertes wird einerseits gewährleistet, dass der gebildete kryptographische Hash-Wert aus kryptographischer Sicht sehr stark ist und somit eine große Verlässlichkeit aufweist und zum anderen sehr schnell gebildet werden kann, wodurch eine zeitliche Verzögerung bei der Bildung des kryptographischen Werts gering gehalten wird.
Dem Ticket, das heißt der Installations-Genehmigungs- Nachricht, können zusätzliche Informationen hinzugefügt werden, beispielsweise:
• Der Zeitpunkt des Ausstellens, das heißt des Erzeugens der Installations-Genehmigungs-Nachricht, • eine Angabe über einen Zeitraum, während dessen die
Installations-Genehmigungs-Nachricht verlässlich, das heißt gültig ist,
• eine Angabe des Anbieters bzw. der Vertriebsinstanz des jeweiligen Programm-Elements, • eine Angabe der Sicherheitsdomäne, der das geladene, das heißt bereitgestellte Programm-Element zugeordnet werden soll,
• eine Angabe von Berechtigungen, die dem Programm-Element bei dessen Ausführung durch den zweiten Rechner gewährt werden sollen, insbesondere Zugriffsrechte auf andere, weitete Programm-Elemente,
• Angaben über den Bedarf von Ressourcen, die das bereitgestellte Programm-Element bei dessen Ausführung oder auch zur Speicherung benötigt, • eine Angabe, dass das Programm-Element auf einem vorgegebenen Typ (Modell) eines Rechners funktionsfähig ist,
• eine Angabe, dass das Programm-Element kompatibel ist mit einem auf einem zweiten Rechner gespeicherten und funktionsfähigen weiteren Programm-Element.
Durch Verwendung einer solchen Zusatzinformation wird die Flexibilität des Verfahrens und somit die Nutzbarkeit der Installations-Genehmigungs-Nachricht im Rahmen der Bereitstellung eines Programm-Elements erheblich erhöht. Die Authentifizierungseinheit kann in dem ersten Rechner enthalten sein, in welchem Fall sowohl das Programm-Element als auch die Installations-Genehmigungs-Nachricht in dem ersten Rechner gespeichert ist.
Ferner kann ein weiterer Rechner mit einer Datenbank, welche anschaulich als Programm-Archiv (Download-Archiv) fungiert, vorgesehen sein, welche das gewünschte Programm-Element zu dem ersten Rechner überträgt. In dem Download-Archiv können ebenso die Installations-Genehmigungs-Nachrichten, die jeweils spezifisch sind für ein Tupel der folgenden Einheiten:
• Authentifizierungseinheit,
• zweiter Rechner, und • Programm-Element in einem Kommunikationsnetz aufgrund der eindeutigen Zuordnung der symmetrischen geheimen Schlüssel zu dem zweiten Rechner und der , jeweiligen Authentifizierungseinheit, gespeichert sein.
Ist die Authentifizierungseinheit nicht in dem ersten Rechner enthalten, so kann alternativ vorgesehen sein, dass die Authentifizierungseinheit Zugriff auf das Download-Archiv hat und von dort zuvor gespeicherte Installations-Genehmigungs- Nachrichten bei Bedarf lädt.
Die Authentifizierungseinheit kann jedoch den kryptographischen Wert unter Verwendung des ihr zugänglichen symmetrischen geheimen Schlüssels auch selbst bilden.
Die gesamte Installations-Genehmigungs-Nachricht selbst kann ebenfalls mittels eines kryptographischen Verfahrens gesichert sein, beispielsweise mittels asymmetrischer oder symmetrischer Kryptographie verschlüsselt werden oder signiert werden. Gemäß einer Ausgestaltung der Erfindung ist es vorgesehen, dass eine Anforderungsnachricht von dem zweiten Rechner an die Authentifizierungseinheit gesendet wird, mit der zu einer in der Anforderungsnachricht enthaltenen ersten Identifizierungsangabe und einer zweiten
Identifizierungsangabe eine Installations-Genehmigungs- Nachricht beantragt wird.
In der Authentifizierungseinheit wird zu dem der jeweiligen ersten Identifizierungsangabe gehörenden Programm-Element und dem zu der zweiten Identifizierungsangabe korrespondierenden zweiten Rechner ermittelt, ob das Programm-Element überhaupt installiert bzw. ausgeführt werden darf. Ist dies der Fall, wird eine Installations-Genehmigungs-Nachricht gebildet, und an den zweiten Rechner gesendet.
Sowohl in der Installations-Genehmigungs-Nachricht als auch in der Anfragenachricht können unterschiedliche Einmalwerte oder der gleiche Einmalwert enthalten sein, in welchem Fall der Grad der Sicherheit im Rahmen des Verfahrens weiter erhöht wird.
Der verwendete Einmalwert kann beispielsweise eine Zufallszahl oder ein vorgebbarer Zählerwert sein.
Wird in der Installations-Genehmigungs-Nachricht und in der Anfragenachricht der gleiche Einmalwert verwendet, so wird eine Bindung zwischen der Anfragenachricht und der Installations-Genehmigungs-Nachricht erreicht, wobei der Grad der kryptographischen Sicherheit weiter erhöht wird, wenn der kryptographische Wert zusätzlich über den Einmalwert gebildet wird.
Weiterhin kann über das Programm-Element selbst ein kryptographischer Hash-Wert gebildet werden und der Installations-Genehmigungs-Nachricht beigefügt sein. Gemäß einer weiteren Ausgestaltung der Erfindung ist der zweite Rechner ein Telekommunikations-Endgerät, beispielsweise ein mobiles Telekommunikations-Endgerät, vorzugsweise ein Mobilfunk-Kommunikations-Endgerät, das heißt ein Mobilfunk-Telefon.
Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Weiteren näher erläutert. Identische Elemente sind in den Figuren mit identischen Bezugszeichen versehen.
Es zeigen
Figur 1 ein Blockdiagramm, in dem ein Kommunikationssystem dargestellt ist, welches gemäß dem GSM-Standard ausgestaltet ist;
Figur 2 ein Blockdiagramm eines Kommunikationssystems gemäß einem ersten Ausführungsbeispiel der Erfindung;
Figuren 3a und 3b ein Blockdiagramm eines
Kommunikationssystems gemäß alternativen Ausführungsbeispielen der Erfindung;
Figuren 4a bis 4c ein Blockdiagramm eines
Kommunikationssystems gemäß weiteren Ausführungsbeispielen der Erfindung;
Figuren 5a und 5b Nachrichten-Flussdiagramme für den Fall, dass aufgrund einer Anfragenachricht eine
Installations-Geneh igungs-Nachricht übertragen wird, die eine Installation oder ein Ausführen des Programm-Elements gestattet (Fig.5a) bzw. mit einer Installations-Genehmigungs-Nachricht, die die Installation oder das Ausführen des Programm-Elements nicht gestattet (vgl. Fig.5b); Figur 6 ein Ablaufdiagramm, in dem die einzelnen
Verfahrensschritte, die in dem Mobil-Terminal gemäß einem Ausführungsbeispiel der Erfindung durchgeführt werden, dargestellt sind;
Figur 7 ein Ablaufdiagramm, in dem die einzelnen Verfahrensschritte, die in der Authentifizierungseinheit gemäß einem Ausführungsbeispiel der Erfindung ausgeführt werden, dargestellt sind.
Fig.l zeigt ein Kommunikationssystem 100 mit einer. Vielzahl von mobilen Kommunikations-Endgeräten 101, die jeweils über eine Luftschnittstelle 102, das heißt eine Funkverbindung, mit einer Basis-Empfangsstation (Base Transceiving Station (BTS) ) 103, im Weiteren auch als Basisstation bezeichnet, verbunden sind, welche jeweils einem Basisstationssystem 104 (Base Station System, BSS) zugeordnet sind, wobei jeweils eine Basiskontrollstation (Base Station Controller, BSC) 105 für jedes Basisstationssystem 104 vorgesehen ist zur Steuerung der in dem Basisstationssystem 104 enthaltenen Basisstation (en) 103.
Zumindest ein Teil der Basisstationssysteme 104 des KommunikationsSystems 100 sind gemäß dem GSM / GPRS / EDGE- Standard mit einem mobilen Vermittlungszentrum 106 (Mobile Switching Center, MSC) zur Vermittlung leitungsgebundener Sprache oder Daten sowie mit einem SGSN 107 (Serving GPRS Support Node) zur Übermittlung von Paketdaten an ein Gateway (Gateway GPRS Support Node, GGSN) 108 in ein Paketdatennetz 112 verbunden. Das mobile VermittlungsZentrum 106 ist mit einem üblichen Telefonnetz 109 verbunden.
Die zentrale Vermittlungsstelle 106 bzw. der SGSN 107 führt für die Vermittlung von Kommunikationsverbindungen erforderliche Funktionen für den Betrieb der mobilen Kommunikations-Endgeräte 101 in den jeweiligen Gruppen von Basisstationssystemen 104, für die jeweils ein mobiles VermittlungsZentrum 106 bzw. der SGSN 107 "zuständig" ist, durch.
Die Funktionen, die das mobile VermittlungsZentrum 106 bzw. der SGSN 107 bereitstellt, enthalten u.a.
• das Routing und die Steuerung von Anrufen, das heißt Kommunikationsverbindungen,
• Verfahren, die für das Zusammenwirken mit anderen Kommunikations-Netzwerken, beispielsweise einem Festnetz wie PSTN, ISDN,
• Verfahren zum Aktualisieren der Einträge der Kommunikations-Endgeräte, während sie von einer Mobilfunk-Zelle in eine andere übergehen, etc.
Jede Basisstation 103 ist über das Paketdatennetz 112 mit einer im Weiteren im Detail erläuterten Authentifizierungseinheit 110 verbunden.
Ferner weist das Kommunikationssystem 100 mindestens einen
Programm-Element-Bereitstellungsrechner 111 auf, der mit den mobilen Kommunikations-Endgeräten 101 ebenfalls über das Paketdatennetz 112 gekoppelt ist.
Fig.2 zeigt eine vereinfachte Darstellung des Kommunikationssystems 200 gemäß einem ersten Ausführungsbeispiel der Erfindung.
In einem Programm-Element-Bereitstellungsrechner 201 ist ein Programm-Element 202 gespeichert und wird über eine
Kommunikationsverbindung 203 von dem Programm-Element- Bereitstellungsrechner 201 zu einem mobilen Kommunikations- Endgerät, gemäß diesem Ausführungsbeispiel einem Mobilfunk- Telefon 101 übertragen und dort gespeichert.
Wie im Weiteren näher erläutert wird, erhält das mobile Kommunikations-Endgerät 101 das Programm-Element 202 von einer für das mobile Kommunikations-Endgerät 101 nicht vertrauenswürdigen Quelle.
Vor der eigentlichen Installation bzw. der Ausführung des Programm-Elements 202 überprüft das mobile Kommunikations- Endgerät 101, ob das Programm-Element vertrauenswürdig ist und ob es überhaupt installiert werden darf bzw. ausgeführt werden darf.
Um zu überprüfen, ob das Programm-Element installiert werden darf bzw. ob es unverändert und damit vertrauenswürdig ist, fordert das mobile Kommunikations-Endgerät 101 von einer Authentifizierungseinheit 204 eine Installations- Genehmigungs-Nachricht, welche im Weiteren näher erläutert wird, an.
Dies erfolgt durch Übertragen einer Anfragenachricht 205 von dem mobilen Kommunikations-Endgerät 101 zu der Authentifizierungseinheit 204 über eine zweite Kommunikationsverbindung 206.
Aufgrund der Anfragenachricht 205 wird in der Authentifizierungseinheit 204 ermittelt, ob das jeweilige Programm-Element 202 auf dem mobilen Kommunikations-Endgerät 101 installiert bzw. ausgeführt werden darf oder nicht.
Das Ergebnis der Überprüfung wird dem mobilen Kommunikations- Endgerät 101 mit einer Installations-Genehmigungs-Nachricht 207 von der Authentifizierungseinheit 204 zu dem mobilen Kommunikations-Endgerät 101 über die Kommunikationsverbindung 206 übertragen.
Fig.3a und Fig.3b zeigen alternative Architekturen eines Kommunikationssystems 300, 310 gemäß weiteren Ausführungsbeispielen der Erfindung. In dem Programm-Element-Bereitstellungsrechner 301 ist das Programm-Element 302 gespeichert (vgl. Fig.3a) .
Das Programm-Element 302 wird von dem Programm-Element- Bereitstellungsrechner 301 über eine erste Kommunikations erbindung 303, gemäß diesem
Ausführungsbeispiel zumindest teilweise einer Funkverbindung zu dem mobilen Kommunikations-Endgerät 101 übertragen.
Ferner wird das Programm-Element 302 über eine zweite
Kommunikationsverbindung 304 zu der Authentifizierungseinheit 305 übertragen, woraufhin von der Authentifizierungseinheit 305 nach Empfang des Programm-Elements 302 oder alternativ nach Empfang einer Anfragenachricht (nicht gezeigt) eine Installations-Genehmigungs-Nachricht 306 gebildet wird.
Die Installations-Genehmigungs-Nachricht 306 wird in einem weiteren Schritt über eine dritte Kommunikationsverbindung 307, gemäß diesem Ausführungsbeispiel ebenfalls eine Funkverbindung, zu dem mobilen Kommunikations-Endgerät 101 übertragen.
In dem mobilen Kommunikations-Endgerät 101 wird aufgrund der Installations-Genehmigungs-Nachricht 306, wie im Weiteren näher erläutert wird, überprüft, ob das empfangene Programm- Element 302 installiert bzw. ausgeführt werden darf.
Fig.3b zeigt eine alternative Architektur, bei der die Authentifizierungseinheit 305 nur mit dem Programm-Element- Bereitstellungsrechner 301 über die zweite
Kommunikationsverbindung 304 verbunden ist und nicht direkt mit dem mobilen Kommunikations-Endgerät 101. Nach Empfang des Programm-Elements 302 oder alternativ nach Empfang einer Anfragenachricht (nicht gezeigt) wird ebenfalls die Installations-Genehmigungs-Nachricht 306 gebildet. Die Installations-Genehmigungs-Nachricht 306 wird in einem weiteren Schritt über die zweite KommunikationsVerbindung 304, zu dem Programm-Element-Bereitstellungsrechner 301 übertragen und von dort weiter zu dem mobilen Kommunikations- Endgerät 101.
Fig.4a bis Fig.4b zeigen weitere Alternativen eines Kommunikationssystems 400, 420, 430 gemäß weiteren Ausführungsbeispielen der Erfindung.
Gemäß dem in Fig.4a dargestellten Ausführungsbeispiel der Erfindung ist ein Archiv-Rechner 401 vorgesehen, in dem eine Vielzahl von Programm-Elementen 402, 403, ... 404 gespeichert sind.
Ferner sind in dem Archiv-Rechner 401 eine Vielzahl von Installations-Genehmigungs-Nachrichten 405, 406, ... 407 gespeichert .
Der Archiv-Rechner 401 ist über eine erste
KommunikationsVerbindung 408 mit dem Programm-Element- Bereitstellungsrechner 409 verbunden.
Über eine zweite Kommunikationsverbindung 410 ist der Programm-Element-Bereitstellungsrechner 409 mit dem mobilen Kommunikations-Endgerät 101 verbunden.
Ein optional von dem Programm-Element-Bereitstellungsrechner 409 angefordertes Programm-Element 402, 403, 404 wird von dem Archiv-Rechner 401 zu dem Programm-Element- Bereitstellungsrechner 409 übertragen, dort temporär zwischengespeichert oder dauerhaft gespeichert und über die dritte Kommunikationsverbindung 412 zu dem mobilen Kommunikations-Endgerät 101 übertragen.
Ferner wird die zu dem Programm-Element 402 , 403 , 404 j eweils zugehörige Installations-Genehmigungs-Nachricht 405 , 406, 407 über die erste KommunikationsVerbindung 408 an den Programm- Element-Bereitstellungsrechner 409 übertragen, dort ebenfalls temporär oder dauerhaft gespeichert und über die zweite Kommunikationsverbindung 410 weiter zu dem mobilen Kommunikations-Endgerät 101 übertragen.
Fig.4b zeigt eine alternative Architektur, bei der in dem Archiv-Rechner 401 eine Vielzahl von Installations- Genehmigungs-Nachrichten 405, 406, ... 407 gespeichert sind.
Das Ausführungsbeispiel gemäß Fig.4b unterscheidet sich von dem Ausführungsbeispiel gemäß Fig.4a insbesondere dadurch, dass wie gemäß dem Ausführungsbeispiel gemäß Fig.3b die Authentifizierungseinheit 411 mit dem Programm-Element- Bereitstellungsrechner 409 über eine dritte
Kommunikationsverbindung 412 verbunden ist. Nach Empfang des Programm-Elements 402 oder alternativ nach Empfang einer Anfragenachricht (nicht gezeigt) wird die Installations- Genehmigungs-Nachricht 405, 406, 407 gebildet.
Die Installations-Genehmigungs-Nachricht 405 wird in einem weiteren Schritt über die dritte Kommunikationsverbindung 412 zu dem Programm-Element-Bereitstellungsrechner 301 übertragen und von dort über die zweite Kommunikationsverbindung 410 weiter zu dem mobilen Kommunikations-Endgerät 101.
Das in Fig. c dargestellte Ausführungsbeispiel unterscheidet sich von dem Ausführungsbeispiel gemäß Fig. b insbesondere dadurch, dass wie gemäß dem Ausführungsbeispiel gemäß Fig.3a die Authentifizierungseinheit 411 direkt mit dem mobilen Kommunikations-Endgerät 101 über eine vierte Kommunikationsverbindung 413 verbunden ist. Die Installations-Genehmigungs-Nachricht 405 wird gemäß diesem Ausführungsbeispiel somit direkt über die vierte Kommunikationsverbindung 413 zu dem mobilen Kommunikations- Endgerät 101 übertragen. Die im Weiteren beschriebene Vorgehensweise, insbesondere der Aufbau der Anfragenachricht und der Installations- Genehmigungs-Nachricht ist für alle oben beschriebenen Ausführungsbeispiele, in denen die jeweiligen Nachrichten verwendet werden, identisch.
Aus diesem Grund wird zur einfacheren Darstellung der Erfindung im Weiteren die Vorgehensweise zur Bereitstellung eines Programm-Elements die Struktur des Kommunikationssystems 200 gemäß dem ersten
Ausführungsbeispiel zur Erläuterung verwendet.
Wie in Fig.2 dargestellt ist, wird von dem Programm-Element- Bereitstellungsrechner 201 das Programm-Element 202 über die erste Kommunikationsverbindung 203 zu dem mobilen
Kommunikations-Endgerät 101 übertragen und dort gespeichert.
Nach Empfang des Programm-Elements 202 wird von dem mobilen Kommunikations-Endgerät 101 die Anfragenachricht 205 gebildet.
Wie in Fig.5a und Fig.5b dargestellt ist, weist die Anfragenachricht 205 folgende Informationen auf:
• Eine erste Identifizierungs-Information, mit der das bereitgestellte Programm-Element identifiziert wird, in Fig.5a bezeichnet mit Id-SW,
• eine zweite Identifizierungs-Information, mit der das mobile Kommunikations-Endgerät 101 eindeutig identifiziert wird, in Fig.5a bezeichnet mit Id-MT, und • einen Einmalwert, gemäß diesem Ausführungsbeispiel eine Zufallszahl N.
Die Zufallszahl N dient gemäß diesem Ausführungsbeispiel dazu, eine logische Verknüpfung zu schaffen zwischen der Anfragenachricht 205 und einer im Weiteren beschriebenen ersten Art von Installations-Geneh igungs-Nachricht 501. Die erste Art von Installations-Genehmigungs-Nachricht 501, die von der Authentifizierungseinheit 204 an das mobile Kommunikations-Endgerät 101 übermittelt wird (vgl. Fig.5a) für den Fall, dass das Programm-Element 202 vertrauenswürdig ist und auf dem mobilen Kommunikations-Endgerät 101 installiert bzw. ausgeführt werden darf, enthält
• ebenfalls die erste Identifizierungs-Information, mit der das bereitgestellte Programm-Element 202 eindeutig identifiziert wird, in Fig.5a bezeichnet mit Id-SW, • die zweite Identifizierungs-Information, mit der das mobile Kommunikations-Endgerät 101 eindeutig identifiziert wird, in Fig.5a bezeichnet mit Id-MT,
• einen kryptographisch starken Hash-Wert H, der über das Programm-Element 202 gebildet wurde, • die Zufallszahl N,
• eine Prüfsumme über die zuvor beschriebenen Daten in der Installations-Geneh igungs-Nachricht 501.
Optional können in der Installations-Genehmigungs-Nachricht 501 folgende Informationen zusätzlich enthalten sein:
• Der Zeitpunkt des Ausstellens, das heißt des Erzeugens der Installations-Genehmigungs-Nachricht,
• eine Angabe über einen Zeitraum, während dessen die Installations-Genehmigungs-Nachricht verlässlich, das heißt gültig ist,
• eine Angabe des Anbieters bzw. der Vertriebsinstanz des jeweiligen Programm-Elements,
• eine Angabe der Sicherheitsdomäne, der das geladene, das heißt bereitgestellte Programm-Element zugeordnet werden soll,
• eine Angabe von Berechtigungen, die dem Programm-Element bei dessen Ausführung durch den zweiten Rechner gewährt werden sollen, insbesondere Zugriffsrechte auf andere, weitete Programm-Elemente, • Angaben über den Bedarf von Ressourcen, die das bereitgestellte Programm-Element bei dessen Ausführung oder auch zur Speicherung benötigt, • eine Angabe, dass das Programm-Element auf einem vorgegebenen Typ (Modell) eines Rechners funktionsfähig ist,
• eine Angabe, dass das Programm-Element kompatibel ist mit einem auf einem zweiten Rechner gespeicherten und funktionsfähigen weiteren Programm-Element.
Für den Fall, dass das Programm-Element 202 nicht vertrauenswürdig ist, das heißt auf dem mobilen Kommunikations-Endgerät 101 nicht installiert bzw. ausgeführt werden darf, bildet die Authentifizierungseinheit 204 eine Installations-Genehmigungs-Nachricht zweiter Art 502, in der eine Fehlerangabe 503 enthalten ist und sendet diese an das mobile Kommunikations-Endgerät 101 (vgl. Fig.5b) .
Die Anfragenachricht 205 und/oder die Installations- Genehmigungs-Nachricht 501 sind kryptographisch gesichert unter Verwendung eines symmetrischen kryptographischen Verfahrens .
Der kryptographisch starke Hash-Wert H, der über das Programm-Element 202 gebildet worden ist, wird gemäß diesem Ausführungsbeispiel gemäß dem MD5-Verfahren oder dem SHA-1- Verfahren als kryptographische Prüfsumme ermittelt.
Mit dieser Information kann die Unverändertheit des Programm- Elements 202 überprüft werden.
Die Prüfsumme, in Fig.5a mit MAC bezeichnet, wird über die in der Installations-Genehmigungs-Nachricht erster Art 501 enthaltenen Daten wird unter Verwendung eines geheimen symmetrischen Schlüssels, der lediglich in dem mobilen Kommunikations-Endgerät und der Authentifizierungseinheit 204 bekannt und gespeichert sind, gebildet, beispielsweise unter Anwendung eines Verfahrens zur Bildung eines Messages
Authentication Codes oder Nachrichtenauthentifizierungscodes . Durch die unter Verwendung des symmetrischen geheimen Schlüssels zumindest über die erste Identifizierungs- Information und die zweite Identifizierungs-Information gebildete Sicherungsinformation, im Weiteren als kryptographischer Wert bezeichnet, wird auf einfache und somit sehr effiziente Weise die Installations-Genehmigungs- Nachricht 501 und die darin enthaltene Information geschützt,
Auf diese Weise ist gewährleistet, dass kein unbefugter Dritter eine Installations-Genehmigungs-Nachricht erster Art 501 erzeugen kann, welche von dem mobilen Kommunikations- Endgerät 101 fehlerhafterweise akzeptiert wird.
Zum Erstellen und Verteilen des jeweiligen für ein Paar von mobilen Kommunikations-Endgerät 101 und
Authentifizierungseinheit 204 eindeutigen geheimen symmetrischen Schlüssel kann grundsätzlich im Rahmen der Erfindung jedes beliebige Verfahren zum Erzeugen eines symmetrischen Schlüssels und zum Verteilen eines solchen in den beiden miteinander kommunizierenden Einheiten verwendet werden.
Fig.6 zeigt in einem Ablaufdiagramm 600 die einzelnen Verfahrensschritte, die in dem mobilen Kommunikations- Endgerät 101 gemäß dem ersten Ausführungsbeispiel der Erfindung ausgeführt werden.
Nachdem in einem ersten Schritt 601 das Programm gestartet wird, wird in einem weiteren Schritt (Schritt 602) wie oben beschrieben wurde, das Programm-Element 202 in dem mobilen Kommunikations-Endgerät 101 empfangen. Zusätzlich wird die erste Identifizierungsangabe, das heißt die Information zum Identifizieren des Programm-Elements 202, empfangen und in dem mobilen Kommunikations-Endgerät 101 gespeichert.
In einem weiteren Schritt (Schritt 603) wird eine Zufallszahl N gebildet und unter Verwendung der Zufallszahl N, der. ersten Identifizierungs-Information und der zweiten Identifizierungs-Information wird in einem weiteren Schritt (Schritt 604) die Anfragenachricht 205 gebildet und an die Authentifizierungseinheit 204 gesendet.
Nach vollständigem Senden der Anfragenachricht 205 geht das mobile Kommunikations-Endgerät 101 in einen Wartezustand über und wartet auf den Empfang einer Installations-Genehmigungs- Nachricht 501, 502, die von der Authentifizierungseinheit 204 gesendet werden soll.
Fig.7 zeigt in einem Ablaufdiagramm 700 die einzelnen Verfahrensschritte, die gemäß diesem Ausführungsbeispiel der Erfindung in der Authentifizierungseinheit 204 durchgeführt werden.
Nach Starten des Verfahrens in einem ersten Schritt (Schritt 701) wird in einen Wartezustand übergegangen, in dem die Authentifizierungseinheit 204 auf den Empfang einer Anfragenachricht, die von einem mobilen Kommunikations- Endgerät 101 gesendet wurde, wartet.
Wird eine Anfragenachricht 205 in einem weiteren Schritt (Schritt 702) empfangen, so wird in einem ersten Prüfschritt (Schritt 703) unter Verwendung der zweiten Identifizierungsangabe überprüft, ob die Authentifizierungseinheit 204 überhaupt für das mobile Kommunikations-Endgerät 101, welches durch die zweite Identifizierungsangabe bezeichnet wird, zuständig ist, das heißt anders ausgedrückt, ob die Authentifizierungseinheit 204 das mobile Kommunikations-Endgerät 101 unterstützt.
Ist dies nicht der Fall, so wird die Installations- Genehmigungs-Nachricht zweiter Art 502 gebildet mit einer entsprechenden Fehlerinformation 503 und an das mobile Kommunikations-Endgerät 101 übertragen (Schritt 704) . Unterstützt die Authentifizierungseinheit 204 jedoch das durch die zweite Identifizierungs-Information identifizierte mobile Kommunikations-Endgerät 101, so wird in einem zweiten Prüfschritt (Schritt 705) unter Verwendung der ersten Identifizierungs-Information überprüft, ob das durch die erste Identifizierungs-Information bezeichnete Programm- Element von dem jeweiligen mobilen Kommunikations-Endgerät 101 akzeptiert werden darf.
Ist dies nicht der Fall, so wird wiederum eine Installations- Genehmigungs-Nachricht zweiter Art 502 mit der entsprechenden Fehlermeldung 503 in dem Schritt 704 gebildet und an das mobile Kommunikations-Endgerät 101 übertragen.
Darf jedoch das Programm-Element 202 von dem Kommunikations- Endgerät 101 akzeptiert, das heißt installiert bzw. ausgeführt werden, so wird von der Authentifizierungseinheit 204 in einem weiteren Schritt (Schritt 706) der kryptographische Hash-Wert H unter Verwendung des MD5- Verfahrens oder des SHA-1-Verfahrens bestimmt oder es wird ein gespeicherter, zuvor für das Programm-Element 202 spezifisch bestimmter kryptographische Hash-Wert ausgelesen bzw. ermittelt.
In einem weiteren Schritt (Schritt 707) wird ein Message Authentication Code unter Verwendung des symmetrischen geheimen Schlüssels, der sowohl der Authentifizierungseinheit 204 als auch der mobilen Kommunikations-Endgerät 101 bekannt ist, bestimmt.
In einem weiteren Schritt (Schritt 708) wird die Installations-Genehmigungs-Nachricht erster Art 501 gebildet und an das mobile Kommunikations-Endgerät 101 gesendet.
Nach dem Senden der Installations-Genehmigungs-Nachricht erster Art 501 oder zweiter Art 502 (Schritte 704 bzw. 708) wird das Verfahren in der Authentifizierungseinheit 204 beendet (Schritt 709) .
Empfängt das mobile Kommunikations-Endgerät 101 die Installations-Genehmigungs-Nachricht 501, 503 (Schritt 605) , so wird anschließend in einem dritten Prüfschritt (Schritt 606) überprüft, ob die Installations-Genehmigungs-Nachricht eine Installations-Genehmigungs-Nachricht zweiter Art 502 ist oder ob die Prüfsumme, das heißt der Message Authentication Code ungültig ist oder ob ein Formatfehler ermittelt wird.
Ist dies der Fall, so wird das geladene Programm-Element 202 nicht akzeptiert, das heißt nicht installiert und auch nicht ausgeführt (in Fig.6 symbolisiert durch Block 607).
Ist die empfangene Installations-Genehmigungs-Nachricht eine Installations-Genehmigungs-Nachricht erster Art 501 und ist sowohl der Message Authentication Code MAC gültig und ist auch kein Formatfehler ermittelt worden, so wird in einem vierten Prüfschritt (Schritt 608) überprüft, ob die erste Identifizierungs-Information, die zweite Identifizierungs- Information sowie die Zufallszahl, die in der Installations- Genehmigungs-Nachricht erster Art 501 enthalten ist, übereinstimmt mit der jeweiligen ersten Identifizierungs- Information, zweiten Identifizierungs-Information und
Zufallszahl, die von dem mobilen Kommunikations-Endgerät 101 in der Anfragenachricht 205 an die Authentifizierungseinheit 204 gesendet wurde.
Stimmen die erste Identifizierungs-Information und/oder die zweite Identifizierungs-Information und/oder die Zufallszahl in der Installations-Genehmigungs-Nachricht 501 und der Anfragenachricht 206 nicht überein, so wird das geladene Programm-Element 202 nicht akzeptiert (Block 607) .
Stimmen die Informationen in der Anfragenachricht 206 und in der Installations-Genehmigungs-Nachricht 501 jedoch überein, so wird in einem fünften Prüfschritt (Schritt 609) überprüft, ob der in der Installations-Genehmigungs-Nachricht 501 enthaltene Hash-Wert H und der von der mobilen Kommunikations-Endgerät 101 ebenfalls ermittelte Hash-Wert über das Programm-Element 202 übereinstimmen. In diesem Zusammenhang ist anzumerken, dass in dem mobilen Kommunikations-Endgerät zur Bildung des Hash-Wertes der gleiche Algorithmus verwendet wird wie in der Authentifizierungseinheit 204.
Sind die Hash-Werte nicht gleich, so wird wiederum das geladene Programm-Element nicht akzeptiert (Block 607) .
Sind jedoch die Hash-Werte gleich, so wird das geladene Programm-Element 202 akzeptiert (Schritt 610) , das heißt das Programm-Element 202 wird installiert bzw. ausgeführt.
Nachdem das Programm-Element 202 akzeptiert oder nicht akzeptiert worden ist (Schritte 610, 607) wird das Verfahren in dem mobilen Kommunikations-Endgerät 101 beendet (Schritt 611) .
Im Weiteren werden einige Alternativen zu dem oben beschriebenen Ausführungsbeispiel dargelegt.
Die Reihenfolge der Information, sowohl in der Anfragenachricht 206 als auch in der Installations- Genehmigungs-Nachricht 501 können flexibel verändert werden.
Ferner kann der Hash-Wert H bereits in der Anfragenachricht 206 enthalten sein. In diesem Fall wird in der Installations- Genehmigungs-Nachricht erster Art 501 lediglich bestätigt, dass der in der Anfragenachricht 206 enthaltene Hash-Wert H korrekt ist. In diesem Fall erfolgt somit die Überprüfung des Hash-Wertes H in der Authentifizierungseinheit 204 und nicht in dem mobilen Kommunikations-Endgerät 101. Es ist ferner darauf hinzuweisen, dass die Verwendung einer Zufallszahl optional ist und dass in der Anfragenachricht bzw. in der Installations-Genehmigungs-Nachricht erster Art 501 die verwendeten Zufallszahlen unterschiedlich sein können.
In der Anfragenachricht 206 und/oder in der Installations- Genehmigungs-Nachricht können zusätzlich Identifizierungs- Informationen zum Identifizieren des Benutzers des mobilen Kommunikations-Endgeräts 101 und/oder zur Identifizierung der Authentifizierungseinheit 204 enthalten sein.
Ferner können mehrere Anfragen bzw. Installations- Genehmigungs-Nachricht in einer gebündelten Anfragenachricht bzw. gebündelten Installations-Genehmigungs-Nachricht enthalten sein und gemeinsam übertragen werden.
Falls das mobile Kommunikations-Endgerät keine Installations- Genehmigungs-Nachricht erster Art 501 erhalten hat, das heißt anders ausgedrückt, wenn innerhalb einer vorgegebenen Zeitdauer, das heißt nach Ablauf eines Timers, keine Installations-Genehmigungs-Nachricht erster Art 501 oder ein Installations-Genehmigungs-Nachricht zweiter Art 502 empfangen wurde, so kann von dem mobilen Kommunikations- Endgerät 101 erneut eine Überprüfung des Programm-Elements mittels einer weiteren Anfragenachricht erfolgen, optional bei einer anderen Authentifizierungseinheit. Durch diese Vorgehensweise kann die Zuverlässigkeit insbesondere bei Auftreten von Übertragungsfehlern oder bei Ausfall einer Authentifizierungseinheit weiter erhöht werden.
Alternativ zu der Zufallszahl kann ein vorgebbarer Zählerwert verwendet werden.
Es kann eine Authentifizierungseinheit vorgesehen werden, die Installations-Genehmigungs-Nachrichten erstellt für eine grundsätzlich beliebige Anzahl von Anbietern von Programm- Elementen. Es können ferner mehrere
Authentifizierungseinheiten in dem Kommunikationssystem enthalten sein, die jeweils für einen oder mehrere Anbieter von Programm-Elementen Installations-Genehmigungs-Nachrichten erstellen und zu dem jeweiligen mobilen Kommunikations- Endgerät übertragen.
Wie oben erläutert wurde, kann die Authentifizierungseinheit in einem Rechner gemeinsam mit dem Programm-Element- Bereitstellungsrechner enthalten sein oder der Programm- Element-Bereitstellungsrechner kann unmittelbar von der Authentifizierungseinheit für das mobile Kommunikations- Endgerät 101 stellvertretend eine Installations-Genehmigungs- Nachricht anfordern und die erstellte Installations- Genehmigungs-Nachricht gemeinsam mit dem Programm-Element an das mobile Kommunikations-Endgerät übertragen.
Das Erstellen einer Installations-Genehmigungs-Nachricht erster Art kann seitens der Authentifizierungseinheit davon abhängig gemacht werden, ob eine Lizenz für das jeweilige Programm-Element vorhanden ist und der Authentifizierungseinheit bekannt ist.
Ferner kann vorgesehen sein, dass aufgrund einer erstellten Installations-Genehmigungs-Nachricht erster Art 501 ein rechtlicher finanzieller Anspruch begründet wird, beispielsweise ein Vergütungsanspruch für die Nutzung des geladenen Programm-Elements.
Die oben beschriebene Zusatzinformation kann auf mehrere, nacheinander übertragene Installations-Geneh igungs- Nachrichten aufgeteilt sein.
Bei einer solchen alternativen Ausführungsform kann es vorgesehen sein, dass die unterschiedlichen Installations- Genehmigungs-Nachrichten von unterschiedlichen Authentifizierungsinstanzen angefordert, erstellt und übertragen werden zu dem mobilen Kommunikations-Endgerät.
Anschaulich kann die Erfindung darin gesehen werden, dass ein sicheres Laden von Programm-Elementen, das heißt von
Software, selbst für ein mobiles Kommunikations-Endgerät mit einer beschränkten Leistungsfähigkeit, das heißt mit beschränkten Ressourcen an Rechenleistung ermöglicht wird. Hierzu wird die Authentifizierungsinstanz anschaulich als Ticket-Server vorgesehen, die nur für aus Sicht der Authentifizierungseinheit gültige Programm-Elemente Installations-Tickets, das heißt die Installations- Genehmigungs-Nachrichten ausstellt. Diese Installations- Tickets werden verwendet, um sicherzustellen, dass ein mobiles Kommunikations-Endgerät nur gültige Software, das heißt nur gültige Programm-Elemente akzeptiert.

Claims

Patentansprüche
1. Verfahren zum Bereitstellen eines Programmelements von einem ersten Rechner für einen zweiten Rechner, • bei dem von dem ersten Rechner das Programmelement zu dem zweiten Rechner übertragen wird,
• bei dem eine Installations-Genehmigungs-Nachricht zu dem zweiten Rechner übertragen wird,
• wobei die Installations-Genehmigungs-Nachricht zumindest folgende Informationen enthält: eine erste Identifizierungsinformation, mit der das bereitgestellte Programmelement identifiziert wird, eine zweite Identifizierungsinformation, mit der der zweite Rechner identifiziert wird, - einen kryptographischen Wert über zumindest die erste Identifizierungsinformation und die zweite IdentifizierungsInformation,
• wobei der kryptographische Wert unter Verwendung eines symmetrischen geheimen Schlüssels gebildet wird, welcher symmetrische geheime Schlüssel in dem zweiten Rechner und in einer Authentifizierungs-Einheit verfügbar ist,
• bei dem unter Verwendung des symmetrischen geheimen Schlüssels der kryptographische Wert in dem zweiten Rechner verifiziert wird, und • bei dem in dem zweiten Rechner unter Verwendung der Installations-Genehmigungs-Nachricht und des verifizierten kryptographischen Werts ermittelt wird, ob das Programmelement in dem zweiten Rechner installiert oder ausgeführt werden darf.
2. Verfahren nach Anspruch 1, bei dem der kryptographische Wert ein Nachrichtenauthenti izierungscode ist .
3. Verfahren nach Anspruch 1 oder 2, bei dem der kryptographische Wert gemäß einem der folgenden Verfahren ermittelt wird: CBC-MAC unter Verwendung einer bekannten Blockchiffre, beispielsweise DES, 3DES, AES, IDEA,
HMAC unter Verwendung einer bekannten Hash-Funktion, beispielsweise MD5, SHA-1, RIPEMD, RIPEMD160, die auch als HMAC-MD5, HMAC-SHA1, HMAC-RIPEMD, HMAC-RIPEMD160 bezeichnet werden,
HMAC unter Verwendung einer bekannten Hash-Funktion mit gekürzter Ausgabe, beispielsweise HMAC-MD5-80, HMAC-
SHA1-80, HMAC-RIPEMD-80, HMAC-RIPEMD160-80 bei auf 80
Bit gekürzter Ausgabe,
MAA,
RIPE-MAC,
MD5-MAC.
4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem in der Installations-Genehmigungs-Nachricht zumindest eine der folgenden Informationen enthalten ist:
Der Zeitpunkt, zu dem die Installations-Genehmigungs- Nachricht generiert worden ist, • eine Zeitangabe, mit der angegeben wird, wie lange die Installations-Genehmigungs-Nachricht gültig ist, eine dritte Identifizierungsangabe zum Identifizieren des Anbieters des Programm-Elements, eine Angabe einer Sicherheitsdomäne, der das bereitgestellte Programm-Element zugeordnet werden soll, Berechtigungsangaben, die dem Programm-Element zugeordnet sind, und die dem Programm-Element bei dessen Durchführung in dem zweiten Rechner gewährt werden sollen, • eine Angabe über den Bedarf von Ressourcen, die das bereitgestellte Programm-Element hat, • eine Angabe, dass das Programm-Element auf einem vorgegebenen Typ (Modell) eines Rechners funktionsfähig ist, • eine Angabe, dass das Programm-Element kompatibel ist mit einem auf einem zweiten Rechner gespeicherten und funktionsfähigen weiteren Programm-Element.
5. Verfahren nach einem der Ansprüche 1 bis 4,
• bei dem von dem zweiten Rechner an die Authentifizierungs-Einheit eine Anfragenachricht übertragen wird, mit der eine Installations-
Genehmigungs-Nachricht für das in dem zweiten Rechner bereitgestellte Programm-Element angefordert wird,
• wobei in der Anfragenachricht zumindest die erste Identifizierungs-Information und die zweite Identifizierungs-Information enthalten sind.
6. Verfahren nach einem der Ansprüche 1 bis 5, bei dem in der Installations-Genehmigungs-Nachricht ein erster Einmalwert enthalten ist.
7. Verfahren nach Anspruch 5, bei dem in der Anforderungsnachricht ein zweiter Einmalwert enthalten ist.
8. Verfahren nach Anspruch 6 und 7, bei dem der erste Einmalwert gleich dem zweiten Einmalwert ist .
9. Verfahren nach einem der Ansprüche 6 bis 8, bei dem als Einmalwert eine Zufallszahl oder ein Zählerwert verwendet wird.
10. Verfahren nach einem der Ansprüche 1 bis 9, bei dem die Authentifizierungseinheit in dem ersten Rechner enthalten ist.
11. Verfahren nach einem der Ansprüche 1 bis 10, bei dem der zweite Rechner ein Telekommunikations-Endgerät ist.
12. Verfahren nach Anspruch 11, bei dem der zweite Rechner ein mobiles Telekommunikations- Endgerät ist.
13. Verfahren nach Anspruch 11 oder 12, bei dem der zweite Rechner ein Mobilfunk-Kommunikations- Endgerät ist.
14. Kommunikationssystem zum Bereitstellen eines Programm- Elements,
- mit einem ersten Rechner, in dem das Programm-Element gespeichert ist, wobei der erste Rechner eine Sendeeinheit enthält zum Senden des Programm-Elements zu einem zweiten Rechner - mit dem zweiten Rechner, wobei der zweite Rechner eine Empfangseinheit zum Empfangen des Programm-Elements und einer Installations-Genehmigungs-Nachricht enthält,
- wobei die Installations-Genehmigungs-Nachricht zumindest folgende Informationen enthält: eine erste Identifizierungsinformation, mit der das bereitgestellte Programm-Element identifiziert wird, eine zweite Identifizierungsinformation, mit der der zweite Rechner identifiziert wird, einen kryptographischen Wert über zumindest die erste Identifizierungsinformation und die zweite IdentifizierungsInformation, mit einer Authentifizierungseinheit,
- wobei ein symmetrischer geheimer Schlüssel in dem zweiten Rechner und in der Authentifizierungseinheit gespeichert ist,
- bei dem die Authentifizierungseinheit eine Einheit zum Bilden des kryptographischen Werts unter Verwendung des symmetrischen geheimen Schlüssels aufweist,
- bei dem der zweite Rechner eine Verifikationseinheit zum Verifizieren des kryptographischen Werts unter Verwendung des symmetrischen geheimen Schlüssels aufweist, und - bei dem der zweite Rechner eine Entscheidungseinheit aufweist, die derart eingerichtet ist, dass unter Verwendung der Installations-Genehmigungs-Nachricht und des verifizierten kryptographischen Werts ermittelt wird, ob das Programm-Element in dem zweiten Rechner installiert oder durchgeführt werden darf.
EP02708167A 2001-02-28 2002-01-25 Verfahren und kommunikationssystem zum bereitstellen eines programm-elements Withdrawn EP1364512A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10109546 2001-02-28
DE10109546A DE10109546A1 (de) 2001-02-28 2001-02-28 Verfahren und Kommunikationssystem zum Bereitstellen eines Programm-Elements
PCT/DE2002/000267 WO2002069598A2 (de) 2001-02-28 2002-01-25 Verfahren und kommunikationssystem zum bereitstellen eines programm-elements

Publications (1)

Publication Number Publication Date
EP1364512A2 true EP1364512A2 (de) 2003-11-26

Family

ID=7675748

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02708167A Withdrawn EP1364512A2 (de) 2001-02-28 2002-01-25 Verfahren und kommunikationssystem zum bereitstellen eines programm-elements

Country Status (4)

Country Link
US (1) US20040117612A1 (de)
EP (1) EP1364512A2 (de)
DE (1) DE10109546A1 (de)
WO (1) WO2002069598A2 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10215747B4 (de) * 2002-04-10 2004-11-18 Siemens Ag Verfahren, Computerprogramm mit Programmcode-Mitteln und Computerprogramm-Produkt zu einem geschützten Herunterladen eines elektronischen Objekts in ein Personal Area Network (PAN) sowie Personal Area Network (PAN)
US8832466B1 (en) * 2006-01-27 2014-09-09 Trustwave Holdings, Inc. Methods for augmentation and interpretation of data objects
KR101590188B1 (ko) * 2009-05-08 2016-01-29 삼성전자주식회사 휴대단말기에서 소프트웨어 패키지의 무결성을 검증하는 방법

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5343529A (en) * 1993-09-28 1994-08-30 Milton Goldfine Transaction authentication using a centrally generated transaction identifier
TW313642B (en) * 1996-06-11 1997-08-21 Ibm A uniform mechanism for using signed content
US5892904A (en) * 1996-12-06 1999-04-06 Microsoft Corporation Code certification for network transmission
US6282294B1 (en) * 1998-01-07 2001-08-28 Microsoft Corporation System for broadcasting to, and programming, a motor device in a protocol, device, and network independent fashion

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO02069598A2 *

Also Published As

Publication number Publication date
DE10109546A1 (de) 2002-09-12
US20040117612A1 (en) 2004-06-17
WO2002069598A2 (de) 2002-09-06
WO2002069598A3 (de) 2002-11-07

Similar Documents

Publication Publication Date Title
DE60200093T2 (de) Sichere Benutzerauthenifizierung über ein Kommunikationsnetzwerk
DE60315914T2 (de) Ad hoc Sicherheitszugriff auf Dokumente und Dienste
DE60200081T2 (de) Sichere Benutzer- und Datenauthenifizierung über ein Kommunikationsnetzwerk
DE60310968T2 (de) Sicherheits- und Privatsphärenverbesserungen für Sicherheitseinrichtungen
DE69433771T2 (de) Verfahren und Vorrichtung zur Geheimhaltung und Authentifizierung in einem mobilen drahtlosen Netz
DE60119857T2 (de) Verfahren und Vorrichtung zur Ausführung von gesicherten Transaktionen
EP0872076B1 (de) Verfahren zum rechnergestützten austausch kryptographischer schlüssel zwischen einer ersten computereinheit und einer zweiten computereinheit
EP1080557B1 (de) Verfahren und anordnung zum rechnergestützten austausch kryptographischer schlüssel zwischen einer ersten computereinheit und einer zweiten computereinheit
DE102017223898A1 (de) Sicheres Ablegen und Zugreifen von Dateien mit einer Webanwendung
EP2338255A2 (de) Verfahren, computerprogrammprodukt und system zur authentifizierung eines benutzers eines telekommunikationsnetzwerkes
DE102012208834A1 (de) Authentisierung eines Produktes gegenüber einem Authentisierer
DE10393847B4 (de) Verfahren und Vorrichtung zum Auffinden einer gemeinsam genutzten vertraulichen Information ohne Beeinträchtigung nicht-gemeinsam genutzter vertraulicher Informationen
WO1997047108A1 (de) Verfahren zum gruppenbasierten kryptographischen schlüsselmanagement zwischen einer ersten computereinheit und gruppencomputereinheiten
EP3595237B1 (de) Nachladen kryptographischer programminstruktionen
DE102018102608A1 (de) Verfahren zur Benutzerverwaltung eines Feldgeräts
DE60115672T2 (de) Sicherheitsarchitektur der internet-protokoll telefonie
EP1364512A2 (de) Verfahren und kommunikationssystem zum bereitstellen eines programm-elements
WO2003063409A2 (de) Verfahren zur datenverkehrssicherung in einer mobilen netzumgebung
WO2004098218A1 (de) Verfahren zur installation oder deinstallation eines programmcodes in einer teilnehmerstation eines funkkommunikationssystems sowie teilnehmerstation
EP3881486B1 (de) Verfahren zur bereitstellung eines herkunftsortnachweises für ein digitales schlüsselpaar
EP4115584B1 (de) Gesicherter und dokumentierter schlüsselzugriff durch eine anwendung
DE102022000857B3 (de) Verfahren zur sicheren Identifizierung einer Person durch eine Verifikationsinstanz
EP1048141A2 (de) Verfahren zur generierung asymmetrischer kryptoschlüssel beim anwender
DE102009053230A1 (de) Verfahren zur Autorisierung eines externen Systems auf einem Steuergerät eines Fahrzeugs, insbesondere eines Kraftfahrzeugs
DE60226245T2 (de) Verfahren und Vorrichtung zur Handlung eines vertrauenswürdigen Uhrwertes

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030813

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: FALK, RAINER

17Q First examination report despatched

Effective date: 20070807

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20071218