EP2531983A1 - Komplettierung portabler datenträger - Google Patents

Komplettierung portabler datenträger

Info

Publication number
EP2531983A1
EP2531983A1 EP11703594A EP11703594A EP2531983A1 EP 2531983 A1 EP2531983 A1 EP 2531983A1 EP 11703594 A EP11703594 A EP 11703594A EP 11703594 A EP11703594 A EP 11703594A EP 2531983 A1 EP2531983 A1 EP 2531983A1
Authority
EP
European Patent Office
Prior art keywords
completion
data
record
authorization
security module
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.)
Ceased
Application number
EP11703594A
Other languages
English (en)
French (fr)
Inventor
Ludger Holtmann
Jörn TREGER
Matthias Jauernig
Sara Stamer
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.)
Giesecke and Devrient Mobile Security GmbH
Original Assignee
Giesecke and Devrient GmbH
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 Giesecke and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Publication of EP2531983A1 publication Critical patent/EP2531983A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0806—Details of the card
    • G07F7/0813—Specific details related to card security
    • G07F7/0826—Embedded security module

Definitions

  • the present invention relates to a method for completing portable data carriers and to a security module and a system for carrying out such a method.
  • an operating system mask is inserted in a non-rewritable, non-volatile memory of the data carrier, for example a ROM memory, in a first production step.
  • the completion step the introduced operating system mask is completed. This fixes any errors in the operating system mask and loads operating system extensions. Furthermore, the possibly corrected and extended operating system is configured appropriately.
  • Corresponding completion data are thereby loaded into a non-volatile, rewritable memory of the data carrier, for example an EEPROM memory.
  • the data carrier is connected to a suitable completion device on which the completion data is provided.
  • EP 1 722 336 A2 describes a method for generating initialization data for a security data carrier.
  • a security module for example a USB token, is provided, on which secret data for generating the initialization data are stored.
  • the security module can be further configured to receive input data and to generate the initialization data by means of own routines using the secret data.
  • EP 1 722336 A2 neither describes how initialization data that can be generated or generated in a secure manner can be introduced into corresponding security data carriers nor how the free use of the generated initialization data can be restricted as intended.
  • Object of the present invention is to allow the completion of small amounts of portable data carriers in particular simple, effective and at the same time completely controllable.
  • the present invention relates inter alia to a method for completing at least one portable data carrier connected to a completion device.
  • a completion data record present on the completion device is introduced into the data carrier.
  • a security module is connected to the completion device for this purpose.
  • Various authorization records are provided on the security module.
  • the security module includes a management application for managing the various authorization records.
  • Each of the authorization records specifies exactly one complete set.
  • each of the authorization data records is assigned to exactly one completion data record.
  • the management application on the security module monitors completion of the at least one volume according to the specification in an authorization record selected from the various authorization records.
  • the administration of the authorization data records to the security module by the administration application comprises, in particular, the introduction of new authorization data records, the blocking or deletion of existing authorization data records, which are provided, for example, by new authorization data records. replaced, as well as various status queries regarding currently available authorization records.
  • the method according to the invention thus does not exclude that at least temporarily only one authorization data record is present on the security module, which is suitable for specifying a completion.
  • the security module usually includes a plurality of different authorization records for specifying various completions by means of a security module.
  • a specification of a completion here includes, in particular, information about a corresponding completion data record, a data carrier to be completed and / or a security module to be monitored for this purpose.
  • the number of permissible completions as well as the configuration of a completion can also be specified by the authorization data record.
  • the specification may include further specifications concerning the completion.
  • An authorization data record thus essentially determines the completion to be carried out, by at least specifying who is allowed to complete which data carriers, which data carriers, which data carriers, and which data.
  • An authorization data set can thus also be regarded in some way as a form of control or control data, since not only are those who are authorized to complete the code given, but also preferably how those authorized persons have to act, which actions are excluded and the like.
  • the administration application on the security module supervises the completion by the fact that the data required for the completion only by the management application on the basis of the selected Authorization record provided.
  • data may be, for example, secret data for authentication against the data carrier to be completed or test data for checking a configuration of a completed data carrier.
  • the management application thus represents a kind of control or control application, but rather a passive, indirect form of control is present.
  • a completion of portable data carriers can be delegated.
  • the completion does not necessarily have to be done directly at the manufacturer of the data carrier, but for example at an external test department, a customer of the manufacturer or the like.
  • the introduction of completion data into the data carrier can be carried out there under monitoring of the security module.
  • the completion of small test series thus does not further obstruct the completion process of the large-volume series production with already extensively tested completion data at the data carrier manufacturer. This ensures a simple and effective completion process both for large series in the disk manufacturer as well as for small test series at the external site.
  • the security module can manage various authorization data records which in turn are assigned to different completion data records, a flexible completion of various portable data carriers with different completion data and using only one security module is possible.
  • a security module according to the invention for monitoring the completion process according to the invention is set up to be connected to a completion device.
  • the security module includes an administrative application executable thereon.
  • the security module is set up to include various authorization records. Each of these authorization records specifies exactly one completion and is assigned to exactly one completion record on the completion device.
  • the management application is set up to manage the various authorization records on the security module.
  • an inventive system for completing at least one portable data carrier comprises a completion device.
  • An auxiliary application is provided on the completion device.
  • the system furthermore comprises an inventive security module with administration application connected to the completion device and at least one portable data carrier also to be completed, which is also connected to the completion device.
  • part of the system are various authorization data records as well as various completion scripts, which each comprise a completion data record and complete commands for introducing the completion data record into a data carrier.
  • Each authorization record is assigned to exactly one completion script and specifies exactly one complete set.
  • the auxiliary application on the completion device is set up to bring the various authorization data sets into the security module.
  • the auxiliary application is set up to insert the completion data set encompassed by the completion script into the at least one data carrier.
  • the management application is set up to monitor the completion according to the specification in the selected authorization record.
  • the completion device only has to include corresponding interfaces in order to be able to be connected to the security module and a data carrier to be completed.
  • smart cards of various form factors and embodiments come into consideration as portable data carriers to be completed.
  • the cards are based on Java Card technology.
  • a corresponding reader is needed, which may be part of the completion device or in turn is suitably connected to the completion device.
  • Other designs and configurations of the portable data carrier are also possible, for example as a memory card or the like.
  • the security module can likewise be present in any design, for example as a chip card or as a USB token.
  • the security module is designed as a chip card with a Java-based operating system and is configured to execute so-called Java Card Applets.
  • the security module thus includes at least one non-volatile, rewritable memory, for example a FLASH or EEPROM memory, and a processor for executing applications stored in the memory.
  • the completion device must have a further interface for connecting to the security module or be connectable to a corresponding reader.
  • the management application is preferably an application stored in a memory of the security module and executable on a processor of the security module.
  • the management application is designed as a Java Card Applet, which can be executed on a security module in the form of a Java Card.
  • the management application is typically personalized and supports various security mechanisms.
  • Both the authorization data script and the completion script serve to automate the completion process.
  • the scripts can be created using any suitable scripting language, such as Groovy or the like.
  • APDUs application protocol data units
  • Security modules Commands in the form of APDUs
  • the administration application on the security module as well as the data carriers to be completed recognize and support the respective commands. dardkomrnandos as well as proprietary APDUs specially developed for the use according to the invention.
  • the helper application on the completion device is intended to execute the authorization data script and the completion script. That the intelligence and flexibility of the procedure lies in the scripts, but not in the helper application.
  • This can be regarded as the interface between an operator of the completion device, the administration application on the security module and the data carrier to be completed.
  • the auxiliary application can thus be universally used to complete a wide variety of data carriers by means of various completion scripts, without being adapted for each. Nevertheless, the auxiliary application or a similar mechanism is of central importance for the completion process, since it can establish a connection between the administration application on the security module and the portable data carrier to be completed, and the complete script can only be executed by the auxiliary application.
  • the helper application is also based on Java, but may also be programmed in any other suitable language.
  • a selected authorization data record uniquely specifies a completion data record to be introduced during the completion into a data carrier to be completed, for example by unambiguously assigning a completion script to the authorization data record.
  • the completion script which is typically provided on the completion apparatus, includes the corresponding completion record and completion commands for inserting the completion record into the volume.
  • the completion script associated with the authorization record gives particular especially the completion record to be introduced.
  • the specification of the completion data set or the completion script comprising the completion data record preferably takes place via a naming convention, ie the authorization data record and the completion script associated therewith have unambiguously identical name components from which the assignment to one another can be read off.
  • the authorization data set may include a check value which has been derived from the associated completion data record or the associated completion script, for example a hash value.
  • the completion script can then be uniquely identified by this check value. The provision of such a check value further makes it possible to detect whether the completion record or the completion script has been altered without permission.
  • the completion data are then preferably introduced into the data carrier in the context of the method according to the invention in that the completion script associated with the selected authorization data record is executed by the auxiliary application on the completion device. This means in particular that the auxiliary application only has interface character and does not have to provide its own commands for introducing the completion data record.
  • Each completion is specified in full by one of the various authorization records that are managed on the security module.
  • Such a specification includes a number of specifications which must be complied with during the corresponding completion in order to be approved by the administration application on the security module.
  • various parameters relating to completion can be determined by means of the corresponding Specify this completion specifying authorization record exactly.
  • the security module is personalized before it is issued or provided, for example by means of a unique identification number.
  • Each location that receives a security module for the delegated completion of portable data carriers can thus be identified or addressed via the identification number in the security module.
  • the management application on the security module is personalized with the identification of the security module and bound in this way to the security module. This ensures that the administration application is used only in conjunction with the security module provided for it and only by the location to which the corresponding security module has been provided. Further, it can be ensured that a completion script intended to be used under the supervision of a particular first security module for completing portable data carriers can not serve to support completion of data volumes under the control of another, second security module.
  • an authorization data record from the set of the various authorization data records on the security module, which has been selected to be a concrete completion of a portable data carrier according to the to monitor storage according to the invention.
  • a selected authorization data record specifies, as already indicated, the specific security module which can monitor a completion in accordance with the authorization data record and subsequently release the corresponding completion on the completed data carrier. This is preferably done by virtue of the authorization data record comprising information that uniquely identifies the security module, for example an identification number of the security module.
  • the authorization data record is provided on the security module only in a suitable manner, for example, stored in the appropriate place on the security module if the security module matches the corresponding specification in the authorization data record. In this way, it is ensured that a specific authorization data record can be used only on exactly the security modules or at exactly the locations to which corresponding security modules have been provided, which are specified in the authorization module as permitted security modules. Use of the authorization data set on other security modules not specified in the specification of the authorization data record is thus effectively prevented. Furthermore, a selected authorization data record specifies a portable data carrier which may be completed according to the specification in the authorization data record.
  • a corresponding completion of the data carrier ie an introduction of completion data as well as a configuration of the completion, takes place only if the data carrier complies with the specification in the authorization data record.
  • a data carrier can be designated, for example, via a hardware identification assigned thereto. As a rule, this hardware identification is the same for all volumes of a batch which comprise an identical operating system mask in their ROM.
  • a Be indirectly specified media that are contained in the authorization record the data carrier relating to secret data.
  • secret data can be, for example, secret keys or the like, which are required in the course of the completion process, for example for authentication to the data carrier or for establishing secure data communication with the data carrier.
  • a selected authorization record further specifies how many portable volumes may be completed by the specified completion record.
  • a period within which a completion must be made can be specified in the authorization record. Only when a corresponding maximum number of completions has not yet been reached, or when the predetermined period still lasts, can a completion be carried out. In this way it can be ensured that only an envisaged number of volumes, as specified by the authorization record, can be completed.
  • the management application can, for example, manage a corresponding counter on the security module, which is decremented after each completing according to the specification. By means of the expiration date, it can be ensured that only current and not accidentally obsolete completion scripts are used.
  • an authorization data script is created.
  • This comprises an authorization data record which, as described in detail above, substantially completely specifies the completion to be carried out.
  • the authorization data script comprises at least one command. By means of this command, as explained below, the authorization data record can be introduced into the security module.
  • a completion script is created which includes the completion record and the completion commands already explained above.
  • the authorization data script and the completion script are uniquely associated with each other.
  • the authorization data script and the completion script are then transmitted to the completion apparatus. This transmission can for example be done by e-mail, but any other type of transmission is possible. These Steps are performed by the instance that has control over the entire completion process, typically the manufacturer of the volumes.
  • the authorization record is then transmitted from the completion device to the security module by the auxiliary application executing the authorization data script on the completion device.
  • the auxiliary application acts merely executing, ie does not provide its own command, but merely executes the command or the commands of the authorization data script in order to effect the transmission of the authorization data record to the security module.
  • the auxiliary application executes the completion script in order to introduce the completion data record into the portable data carrier.
  • both transmission steps are preceded by a series of further steps which ensure the safety of the entire completion system and which are described in detail below.
  • the authorization record and the completion script are encrypted prior to transmission to the completion device. This prevents spying or even changing of this security-relevant data during transmission.
  • the entitlement data script as such may remain unencrypted because it includes the encrypted entitlement record
  • the completion script is usually fully encrypted, ie the completion record along with the completion commands. Thus, no information about the completion commands can reach unauthorized possession.
  • the completion script after being received by the helper application on the completion device, is decrypted by the helper application itself.
  • the helper application is the sole instance having the key to decrypt the completion script.
  • the encrypted authorization record is decrypted only after being transmitted to the security module by the management application on the security module.
  • the auxiliary application can nevertheless effect the transmission of the encrypted authorization data record to the security module since it can easily execute the inherently unencrypted authorization data script.
  • the administration of the various authorization records is completely performed by the management application and only on the security module.
  • the administration of the various completion scripts is performed by the auxiliary application on the completion device, which decodes and subsequently manages the scripts during reception, for example first stores them at a predetermined location in a memory of the completion device. Only when a concrete data carrier is to be completed is an authorization data record selected, which specifies the completion and thereby monitors it. The associated completion script is then determined for this authorization data record, which is subsequently executed by the auxiliary application.
  • security-relevant data is to be completed between the security module and the one to be completed Data carrier via the auxiliary application on the completion device, with which both the security module and the disk are connected transmitted.
  • the helper application authenticate to the security module at the beginning of the procedure.
  • Authentication of the auxiliary application with respect to the data medium to be completed can also be provided.
  • the data communication between the auxiliary application and the security module is secured, for example encrypted, during most of the completion process.
  • a secure communication channel between the management application on the security module and the auxiliary application on the completion device is set up preparatory.
  • a secure communication channel is established between the helper application on the completion device and the portable medium to be completed.
  • the data transmission can also be performed securely between the completion device and the data carrier.
  • Authentication of the auxiliary application with respect to the security module can be done by means of a password.
  • This password receives the body to which the completion is delegated when the security module is deployed.
  • the password is only valid for the one security module which has been personalized by the identification number for the corresponding job.
  • Security module can then be derived from the password secret key. These keys are never known to the entity performing the completion. The derivation and secure management of these keys is the responsibility of the auxiliary application. These keys are outside the auxiliary application not accessible. In this respect, secure data communication with the security module, which is required for various steps of the completion process, can be carried out exclusively via the auxiliary application. Also in this way it is ensured that a completion process without an inventive interaction of the various components, here the security module and the auxiliary application on the completion device, is not feasible.
  • Secret data which is required to authenticate the auxiliary application on the completion device relative to the data carrier, are provided to the auxiliary application by the administration application on the security module. This can be done in a secure way, since, as mentioned, a secure data communication between the security module and the auxiliary application is already guaranteed.
  • the authentication application on the security module is provided with an authentication value by the administration application on request, which is determined by the administration application by means of data stored in the authorization data record.
  • Secret keys for establishing a secure communication channel between the helper application on the completion device and the volume are also provided by the management application on the security module.
  • the authorization data record comprises a special basic key of the data carrier, from which the secret key required for the production of the secure channel can be derived.
  • a completion of a data carrier is further specified by the selected authorization data record in that the configuration of the data carrier is also specified precisely. It is possible to use two data carriers devices which comprise an identical operating system mask, for example in the ROM memory, as well as an identical completion record, for example in the EEPROM memory, can be configured in various ways. As such, a specification of the intended configuration is an integral part of the specification in the authorization record. Only if the completed configuration of the data carrier has occurred after the introduction of the completion data set in the manner specified by the authorization data set, the configuration is released - only then the disk is ready for further use. Such a release can be done by a release command, which receives the disk from the auxiliary application. This command may include configuration check data that completely defines the intended configuration of the volume, for example in the form of a check value. A corresponding check value is calculated by the data carrier via the current configuration. Only if both test values agree will the completion including configuration be released.
  • this data carrier is individualized. This step is usually done through commands of the completion script. This first checks whether the data carrier is already individualized or not. It should be noted that a batch of identically constructed data carriers is usually not individualized before the completion, so each data carrier of the batch carries the same batch number. The batch number is used to calculate the authentication value for authentication against the data medium. In order, for example, to prevent a complete completion process of a data carrier from being "recorded" in an abusive manner and subsequently in the same way for any number of identically constructed data carriers of the same batch with the same output.
  • the actual completion process ie the introduction of the completion record in the disk, an individualization step is prefixed.
  • the introduction of the completion data requires, as mentioned, an authentication to the data carrier.
  • a data carrier-specific authentication is required for a completion of a data carrier according to the invention.
  • the batch number of the data carrier is replaced by its serial number.
  • the serial number of the data carrier is data carrier-specific. Consequently, the authentication value for authentication with respect to the data carrier, which is calculated by means of the batch number now replaced by the serial number, is also data carrier-specific from this point in time.
  • This change of the batch number can be regarded as an upstream completion and, as such, also requires an authentication with respect to the data carrier to be individualized. However, this can be done with an only batch-specific authentication value for an entire batch, which can thus be part of the completion script. Such an individualization can be omitted if a corresponding data carrier is already individualized because it has already been completed, for example, in an earlier production cycle, but this earlier completion is now to be replaced by a new completion.
  • FIG. 1 shows components of a preferred embodiment of a system according to the invention
  • a completion system 1000 includes a completion device 200, for example in the form of a personal computer (PC), a security module 100, various authorization data scripts 400, 400 ', 400 ", various completion scripts 300, 300', 300", and to be completed Data carrier 10, 11, 12, 13.
  • a completion device 200 for example in the form of a personal computer (PC)
  • a security module 100 for example in the form of a personal computer (PC)
  • various authorization data scripts 400, 400 ', 400 " various completion scripts 300, 300', 300"
  • various completion scripts 300, 300', 300 and to be completed Data carrier 10, 11, 12, 13.
  • the completion device 200 comprises suitable interfaces 220, 230 in order to be connected to the security module 100 and to a data carrier 10 to be completed.
  • the interfaces 220, 230 may be designed, for example, as chip card readers if the security module 100 and the data carriers 10, 11, 12, 13 to be completed are designed as chip cards.
  • an auxiliary application 210 is installed, which plays the role of an interface between a user of the completion device 200, the security module 100 and a data carrier 10 to be completed in the completion method described in detail below.
  • the auxiliary application 210 is set up to execute the authorization data scripts 400, 400 ', 400 "and the completion scripts 300, 300', 300", which are described below.
  • the completion device 200 is further connected to a network, for example the Internet.
  • the completion device 200 may receive data, such as the completion scripts 300, 300 ', 300 "and the authorization data scripts 400, 400', 400".
  • the security module 100 is designed as a portable data carrier, for example as a chip card, in particular as a GlobalPlatform Java Card. Alternatively, however, the security module 100 can also be embodied, for example, as a USB token or the like.
  • a management application 110 is installed executable. By means of this management application 110, various authorization data records 310, 310 ', 310 "to be described are managed in the security module 100. Furthermore, the administration application 110 is set up to monitor the completion procedure described below.
  • a portable data carrier 10 to be completed for example likewise in the form of a Java Card, comprises a ROM memory (not shown) in which an operating system mask has already been inserted, as well as a rewritable, non-volatile memory (not shown), for example a FLASH Memory or an EEPROM memory in which completion data 310 is written during the completion process described below.
  • a rewritable, non-volatile memory for example a FLASH Memory or an EEPROM memory
  • completion data 310 By means of this completion data 310, any errors in the ROM mask are remedied.
  • the operating system of the data carrier 10 is suitably supplemented during the completion by the completion data 310 and configured and booted for the first time.
  • a completion script 300, 300 ', 300 "includes a completion record 310, 310', 310" as well as completion commands 320, 320 ', 320 ".
  • the completion record 310, 310 ', 310 "during the completion process into a data carrier 10, 11, 12, 13 to be completed.
  • the execution script 300, 310 ', 310 is executed by the auxiliary application 210 on the completion device 200, as described below.
  • An authorization data script 400, 400 ', 400 "finally includes an authorization data record 410, 410', 410" as well as at least one command 420, 420 ', 420 "for introducing the authorization data record 410, 410', 410” the security module 100 the command 420, 420 ', 420 "is also executed by the auxiliary application 210 on the completion device 200.
  • An authorization data record 410, 410', 410" is in each case unambiguously assigned to a completion data record 310, 310 ', 310 "and specifies one each Completion, ie in the authorization data record 410, 410 ', 410 ", all essential parameters of a completion process are predetermined, as will be described in detail below with reference to FIGS.
  • the completion method described here has been developed in order to be able to delegate a completion process to an external site other than the manufacturer of the data carriers 10, 11, 12, 13 to be completed.
  • an external body may be, for example, an external department of the manufacturer or a close customer. In this way, the production process at the actual manufacturer is not affected by the completion of small test quantities of data carriers.
  • step S1 the security module 100 is prepared.
  • the management application 110 is loaded into the security module 100 in sub-step TS11 in order to be executable there.
  • the security module 100 is personalized in TS12 by providing it with a unique identity number ID. By means of this identity number, any external point which receives such a security module 100 for external completion can be uniquely addressed.
  • the management application 110 is also personalized on the security module 100 in sub-step TS13: on the one hand with the identity number ID of the security module 100, on the other hand with a cryptographic key keyBD.
  • the management application 110 is bound to the security module 100, thus can only be used in conjunction with the uniquely identified module 100, which carries the same ID, but not with a similar other security module.
  • the key keyBD serves, as described below, for decrypting authorization records 410, 410 ', 410 "received in encrypted form by the management application 110.
  • a security module 100 prepared in this way is provided to the external site in step S2.
  • step S3 the auxiliary site 210 is further provided to the external site. This is to be installed on the completion device 200. As described below, the completion process without the helper application 210 can not be performed, nor without the security module 100.
  • step S4 the external entity receives a number of volumes to be completed 10, 11, 12, 13. These are usually data carriers a structurally identical batch, which has not yet been completed. However, it is also possible that individual or all of the data carriers 10, 11, 12, 13 provided have already been completed in a previous production phase and are now to be completed again for test purposes, for example for improving or correcting the operating system.
  • completion data and authorization data are generated and transmitted to the external site. These steps are performed by the manufacturer of the volumes to be completed whenever a new completion version, e.g. a completion record 310 for supplementing an operating system of a data carrier 10 is present.
  • a new completion version e.g. a completion record 310 for supplementing an operating system of a data carrier 10 is present.
  • step S5 a new completion record 310 for completing a portable volume 10, 11, 12, 13 is generated.
  • This completion record 310 may be a further development of a previous version of completion data or a new or first development.
  • the completion data record 310 includes exactly the data that is to be introduced into a memory of a data carrier 10, 11, 12, 13 to be completed. For this purpose, commands are generally required by means of which the completion device 200 with the data carrier 10, 11, 12, 13 communicates to transmit the completion data 310 to the data carriers 10, 11, 12, 13.
  • Corresponding completion commands 320 are thus also generated and processed together with the completion record 310 in step S6 to a completion script 300.
  • This completion script 300 thus comprises both completion data 310 to be introduced into the data carrier 10, 11, 12, 13 and commands 320 required therefor, specifically in the arrangement and sequence in which the commands 320 are merely specified by the auxiliary application 210 as specified by the script 300 the completion device 200 must be performed.
  • the completion script 300 may be generated in any suitable scripting language, such as Groovy. If the data carriers 10, 11, 12, 13 and the security module 100 are designed as chip cards according to ISO 7816, the completion commands 320 are provided for communication with these two elements in the form of APDUs ("application protocol data unit") In step S7, the generated completion script 300 is encrypted with a transfer key key S. In this way, it is checked against spying or altering during the subsequent transfer to the completion device (see step Sil). which can then be accessed via an unsecured network, for example via e-mail via the Internet.
  • APDUs application protocol data unit
  • an authorization record 410 is generated. This includes a substantially complete specification of a completion.
  • This authorization record 410 is clearly the completion record 310, which has been generated in step S5, assigned.
  • An assignment of the completion script 300 to the authorization data record 410 may further be effected by the authorization data record 410 comprising a check digit specifying the completion script 300, for example a hash value over the complete completion script 300.
  • the management application 110 may be located on the security module 100 not only recognize the completion script 300 associated with the authorization data record 410 as such, but also check for any undesired changes.
  • Authorization record 410 may include, among other things, the following data:
  • a hardware ID of a data carrier 10, 11, 12, 13 which can be completed by means of the completion data record 310 is generally the same for identically constructed data carriers 10, 11, 12, 13 of a batch.
  • This hardware ID uses the management application 110 on the security module 100 during the later course of the completion process to check whether a present data carrier 10, 11, 12, 13 may be completed with an existing completion record 310, ie the authorization record 410 not only sets the permissible Komplett istsrtzsatz 310, but also the type of disk 10, 11, 12, 13, which may be completed with it.
  • this key specifies the authorization record 410 - indirectly - a to be completed disk 10, 11, 12, 13, because if these keys does not fit to be completed to a data carrier 10, 11, 12, 13, an intended completion before gang already fail because an authentication against the disk 10, 11, 12, 13 will not be successful.
  • An identification number ID of a security module 100 which may be used to complete a data carrier 10, 11, 12, 13 to be completed.
  • the authorization data record 410 thus also specifies, in addition to the completion record 310 and the data carrier 10, 11, 12, 13 to be completed, who may perform this completion: Only the location that is in possession of a security module 100 clearly identified with the ID.
  • a completion number that specifies how often a completion specified by the remaining parameters may be performed. After each successful completion according to the authorization data record 410, the completion number, which can be provided as a counter, is correspondingly reduced. If this counter reaches zero, the authorization record 410 is likewise blocked by the administration application 110. A check digit about the completion script 300, already described above.
  • a test value which clearly specifies an admissible configuration of a data carrier 10, 11, 12, 13 to be completed. Only if the data carrier 10, 11, 12, 13 has been configured according to this configuration specification after the completion record 310 has been inserted is the completion successful.
  • This check value can also be designed as a hash value.
  • Information about authorization records to be blocked In this way, it becomes possible, for example, to indicate to the administration application 110 on the security module 100 that the existing authorization data record 410 replaces an earlier authorization data record already present on the security module 100.
  • the former authorization record which for example specified a completion according to a previous version of a current completion script 300, is then locked by the management application 110 as part of the management of the various authorization records 410, 410 ', 410 "on the security module 100.
  • step S9 the authorization record 410 is encrypted by means of another key keyBD and thus against spying and changing secured in the subsequent transfer (see step Sil) to the completion device 200.
  • the authorization data record 410 is decrypted only on the security module 100 by the administration application 110. For the purpose of personalization (see TS13), this was equipped with the corresponding key.
  • an authorization data script 400 is generated in step S10. This comprises, in addition to the encrypted authorization data record 410, at least one command 420 which, when executed by the auxiliary application 210 on the completion apparatus 200, directly leads to the encrypted authorization data record 410 being transmitted to the security module 100. Separate encryption of the authorization data script 400 itself is generally not necessary since the at least one command 420 does not represent a security-relevant date. In contrast, the commands 320 of the completion script 300 are considered security-relevant and, together with the completion data 310 that is also to be secured, are encrypted (cf. S7).
  • the encrypted completion script 300 and the authorization data script 400 with the encrypted authorization data record 410 are subsequently transmitted to the completion apparatus 200 in step S, for example via the Internet. There can then start the actual completion process, which will be described with reference to Figures 4 to 8 below. Each time a new or updated completion record 310 is present, steps S5 through Sil may be repeated in the manner described. If a data carrier 10, 11, 12, 13 to be completed is connected to the plating device 200 via the interface 220 and the security module 110 via the interface 230, the actual completion process is initiated, as described with reference to FIG. 4 ,
  • step S12 In order to be able to cryptographically secure the subsequent completion process, during which security-relevant data is transmitted, certain security measures are necessary.
  • the completion process is continued in step S12 in that the auxiliary application 210 is authenticated to the administration application 110 on the security module 100. This is done by means of a password, which is known to the user of the completion device 200.
  • a secure channel is established between the auxiliary application 210 and the administration application 110 in step S13.
  • the necessary secret keys are derived from the auxiliary application 210 in substep TS131 from the password, without the user of the completion device 200 comes into the possession of these keys - which at the same time ensures that the security module 100 and the running administration application 110 always only in conjunction with the auxiliary application 210, but not separately.
  • the secured communication connection to the security module 100 is established in sub-step TS132 by means of the secret keys.
  • a transfer of the authorization data record 410 to the security module 100 can take place in step S14.
  • the auxiliary application 210 executes the authorization data script 400 on the completion device 200.
  • the authorization data record 410 is decrypted by the management application 110 by means of the key ke eD in step S15. Subsequently, it is checked in step S16 whether the security module ID specified in the authorization data record 410 matches the ID of the security module 100. Only if this is the case, the authorization record 410 is stored in the security module 100 in step S18. Otherwise, the completion process is aborted in step S17. In step S19, the auxiliary application 210 then decrypts the receiving completion script 300 on the completion device 200.
  • the execution of the completion script 300 by the auxiliary application 210 is initiated by a user of the completion device 200 selecting the authorization data record 410 assigned to the completion script 300, which is stored on the security module 100 alongside any other authorization data records 410 ', 410 "already stored therein That is, only if the security module 100 stores an authorization data set 410, 10 ', 410 "which is unambiguously assigned to a completion script 300, 300', 300" present on the completion device 200, can the corresponding completion script 300, 300 ', 300 "are executed by the auxiliary application 210. It is also clear at this point that the entire completion method is feasible only in the interaction of the described components.
  • step S21 the data carrier 10, 11, 12, 13 to be completed in one of the actual completion of the data carrier 10, 11, 12, 13 is individualized, if not already done.
  • This step is necessary to prevent identical volumes 10, 11, 12, 13 of a batch from being completed identically by means of a correct "recorded" completion process performed for a volume 10 of the batch note that data carriers of the same batch have an identical batch number
  • the batch number of a data carrier is used to calculate an authentication value AV required for the authentication against the data medium Accordingly, for the data carriers of a batch - as long as they have the same batch number - This makes it possible to repeatedly use a recorded completion process, including authentication, but this is to be prevented in the case of delegated completion
  • the completion script 300 checks whether a respective data carrier is being checked 10, 11, 12, 13 has already been individualized, for example, because this data carrier 10, 11, 12, 13 has already been personalized once in an earlier production phase. If not, the data carrier 10, 11, 12, 13 is individualized in that the batch number stored in the data carrier 10, 11, 12, 13
  • step S22 the auxiliary application 210 authenticates itself with respect to the data carriers 10, 11, 12, 13.
  • the data volume-specific authentication value AV required for this purpose requests them from the administration application 110 on the security module 100 in sub-step TS 221.
  • the management application 110 determines the AV and provides it to the auxiliary application 210 in sub-step TS222 before the auxiliary application 210 finally authenticates in sub-step TS223 by means of the acquired AV at the data carrier 10, 11, 12, 13.
  • the auxiliary application 210 requests in sub-step TS231 the information required for this, from one on the security module 100 as part of the authorization data record 410 stored media key derived from the management application 110. This determines the corresponding keys using the authorization data record 410 and provides them to the auxiliary application 210 in sub-step TS232.
  • the secure communication connection to the data carrier 10, 11, 12, 13 represents the auxiliary application 210 using these derived keys in substep TS233.
  • Step S23 is optional, especially since the completion records transmitted in the following step S24 can already be encrypted independently of an encryption of the transmission channel.
  • step S24 the completion record 310 is transferred by means of a command of the completion script 300 to the data carrier 10, 11, 12, 13 and stored there, for example in the EEPROM memory. If necessary, this memory is previously completely deleted as a precautionary measure.
  • the disk after step S24 preferably by means of a reset signal restarted (warm reset) and analogous to step S22 authentication is performed, but now compared to the completed (J AVA card) operating system of the disk he follows. Subsequently, the operating system of the data carrier 10, 11, 12, 13 updated and completed by means of the completion data 310 is configured in step S25.
  • step S26 this configuration is checked on the basis of the specifications in the authorization data record 410.
  • the auxiliary application 210 requests a corresponding configuration check value in sub-step TS261 from the administration application 110 on the security module 100.
  • the management application 110 creates this check value after the specification in the authorization data record 410 and provides the auxiliary application 210 with the appropriate value in sub-step TS262.
  • data carrier-specific data parts can be entered.
  • the auxiliary application 210 transmits the configuration check value obtained in sub-step TS263 to the data carrier 10, 11, 12, 13. There, the received configuration test value compared to a test value internally calculated via the current configuration in the substeps TS264, TS265.
  • the data carrier 10, 11, 12, 13 has thus been configured according to the specifications in the authorization data record 410, the corresponding configuration in the data carrier 10, 11, 12, 13 is released in substep TS267 and the counter relating to the allowable completion number in the permission record 410 is decremented by the management application 110 by one. Otherwise the completion process will be canceled unsuccessfully.
  • the release of the completion means that the completed data carrier 10, 11, 12, 13 is ready for further production steps, for example an initialization or a subsequent personalization to a future user.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Storage Device Security (AREA)

Abstract

Gemäß einem Verfahren zur Komplettierung zumindest eines mit einer Komplettierungsvorrichtung (200) verbundenen portablen Datenträgers (10; 11; 12; 13) wird ein auf der Komplettierungsvorrichtung (200) vorliegender Komplettierungsdatensatz (310; 310', 310") in den Datenträger (10; 11; 12; 13) eingebracht. Dazu wird ein Sicherheitsmodul (100) mit der Komplettierungsvorrichtung (200) verbunden. Auf dem Sicherheitsmodul (100) werden verschiedene Berechtigungsdatensätze (410; 410'; 410") bereitgestellt. Daneben umfasst das Sicherheitsmodul (100) eine Verwaltungsapplikation (110) zum Verwalten der verschiedenen Berechtigungsdatensätze (410; 410'; 410"). Jeder der Berechtigungsdatensätze (410; 410'; 410") spezifiziert genau eine Komplettierung. Weiterhin ist jeder der Berechtigungsdatensätze (410; 410'; 410") genau einem Komplettierungsdatensatz (310; 310'; 310") zugeordnet. Die Verwaltungsapplikation (110) auf dem Sicherheitsmodul (100) überwacht die Komplettierung des zumindest einen Datenträgers (10; 11; 12; 13) gemäß der Spezifizierung in einem aus den verschiedenen Berechtigungsdatensätzen (410; 410'; 410") ausgewählten Berechtigungsdatensatz (410).

Description

K o m le t t i e r u n g p o r t a b l e r D a t e n t r ä g e r Die vorliegende Erfindung betrifft ein Verfahren zur Komplettierung portabler Datenträger sowie ein Sicherheitsmodul und ein System zur Durchführung eines solchen Verfahrens.
Bei der Herstellung portabler Datenträger wird in einem ersten Herstel- lungsschritt eine Betriebssystemmaske in einen nicht wiederbeschreibbaren, nicht volatilen Speicher des Datenträgers, beispielsweise einen ROM- Speicher, eingebracht. In einem weiteren Schritt, dem Komplettierungsschritt, wird die eingebrachte Betriebssystemmaske komplettiert. Dabei werden eventuelle Fehler der Betriebssystemmaske korrigiert sowie Erweiterun- gen des Betriebssystems geladen. Weiterhin wird das eventuell korrigierte und erweiterte Betriebssystem geeignet konfiguriert. Entsprechende Komplettierungsdaten werden dabei in einen nicht volatilen, wiederbeschreibbaren Speicher des Datenträgers, beispielsweise einen EEPROM-Speicher, geladen. Dazu wird der Datenträger mit einer geeigneten Komplettierungsvor- richrung verbunden, auf welcher die Komplettierungsdaten bereitgestellt werden.
Bevor Datenträger mit Betriebssystemmaske und zugehöriger Komplettierung in die Serienproduktion gehen, werden kleinere Testmengen dieser Da- tenträger umfangreich getestet. Dies geschieht oft abseits der eigentlichen Datenträgerproduktion in dafür speziell eingerichteten, eventuell externen Testabteilungen. Beim Testen aufgefundene Fehler oder Mängel werden dann mittels angepasster Komplettierungsdaten behoben, worauf erneute Tests mit solchen Datenträgern durchgeführt werden, welche mit den ange- passten Komplettierungsdaten komplettiert worden sind.
Da die zu testenden Datenträger in der Regel lediglich in sehr kleinen Men- gen hergestellt, d.h. insbesondere komplettiert, werden, behindert deren eventuell mehrfache Komplettierung den Ablauf der übrigen Serienproduktion, d.h. der Komplettierung von Datenträgern mit vollständig getesteten Betriebssystemkomponenten, erheblich. Die Serienproduktion ist auf die Herstellung großer Serien ausgelegt und optimiert. Eine Auslagerung der Komplettierung kleiner Testserien, beispielsweise an die entsprechenden externen Testabteilungen, birgt das Risiko, dass noch geheime Komplettierungsdaten missbräuchlich verwendet werden. Ebenso ist möglich, dass anstelle von begrenzten Testserien größere Mengen von Datenträgern mit den Komplettierungsdaten komplettiert oder dass komplettierte Datenträger nicht bestimmungsgemäß konfiguriert werden.
Die EP 1 722336 A2 beschreibt ein Verfahren zur Erzeugung von Initialisierungsdaten für einen Sicherheitsdatenträger. Dabei wird ein Sicherheitsmodul, beispielsweise ein USB-Token, bereitgestellt, auf welchem Geheimdaten zur Erzeugung der Initialisierungsdaten gespeichert sind. Das Sicherheitsmodul kann weiter eingerichtet sein, Eingangsdaten zu empfangen und mittels eigener Routinen unter Verwendung der Geheimdaten die Initialisierungsdaten zu erzeugen. Allerdings ist in der EP 1 722336 A2 weder beschrieben, auf welche Weise derart erzeugbare oder erzeugte Initialisie- rungsdaten auf gesicherte Weise in entsprechende Sicherheitsdatenträger eingebracht werden können noch, wie die freie Verwendung der erzeugten Initialisierungsdaten bestimmungsgemäß eingeschränkt werden kann. Aufgabe der vorliegenden Erfindung ist es, die Komplettierung insbesondere kleiner Mengen portabler Datenträger einfach, effektiv und gleichzeitig vollständig kontrollierbar zu ermöglichen. Diese Aufgabe wird durch ein Verfahren, ein Sicherheitsmodul sowie ein System mit den Merkmalen der nebengeordneten Ansprüche gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen sind in den abhängigen Ansprüchen angegeben. Die vorliegende Erfindung betrifft unter anderem ein Verfahren zur Komplettierung zumindest eines mit einer Komplettierungsvorrichtung verbundenen portablen Datenträgers. Dabei wird ein auf der Komplettierungsvorrichtung vorliegender Komplettierungsdatensatz in den Datenträger eingebracht. Erfindungsgemäß wird dazu ein Sicherheitsmodul mit der Komplet- tierungsvorrichtung verbunden. Auf dem Sicherheitsmodul werden verschiedene Berechtigungsdatensätze bereitgestellt. Daneben umfasst das Sicherheitsmodul eine Verwaltungsapplikation zum Verwalten der verschiedenen Berechtigungsdatensätze. Jeder der Berechtigungsdatensätze spezifiziert genau eine Komplettierung. Weiterhin ist jeder der Berechtigungsda- tensätze genau einem Komplettierungsdatensatz zugeordnet. Die Verwaltungsapplikation auf dem Sicherheitsmodul überwacht die Komplettierung des zumindest einen Datenträgers gemäß der Spezifizierung in einem aus den verschiedenen Berechtigungsdatensätzen ausgewählten Berechtigungsdatensatz.
Das Verwalten der Berechtigungsdatensätze auf den Sicherheitsmodul durch die Verwaltungsapplikation umfasst insbesondere das Einbringen neuer Berechtigungsdatensätze, das Sperren oder Löschen bereits vorhandener Berechtigungsdatensätze, welche beispielsweise durch neue Berechtigungsda- tensätze ersetzt werden, sowie diverse Statusabfragen bezüglich aktuell vorliegender Berechtigungsdatensätze. Das erfindungsgemäße Verfahren schließt somit nicht aus, dass zumindest temporär lediglich ein Berechtigungsdatensatz auf dem Sicherheitsmodul vorliegt, welcher geeignet ist, eine Komplettierung zu spezifizieren. Für gewöhnlich umfasst das Sicherheitsmodul allerdings, wie beschrieben, eine Mehrzahl verschiedener Berechtigungsdatensätze zum Spezifizieren verschiedener Komplettierungen mittels eines Sicherheitsmoduls. Eine Spezifizierung einer Komplettierung umfasst dabei insbesondere Angaben über einen entsprechenden Komplettierungsdatensatz, einen zu komplettierenden Datenträger und/ oder ein dies überwachendes, zu verwendendes Sicherheitsmodul. Auch die Anzahl zulässiger Komplettierungen sowie die Konfiguration einer Komplettierung können durch den Berechti- gungsdatensatz vorgegeben werden. Die Spezifizierung kann weitere, die Komplettierung betreffende Vorgaben umfassen. Ein Berechtigungsdatensatz bestimmt somit die durchzuführende Komplettierung im Wesentlichen vollständig, indem vorzugsweise zumindest spezifiziert wird, wer mit welchen Hilfsmitteln welche Datenträger wie oft mit welchen Daten auf welche Weise zu welcher Zeit komplettieren darf. Ein Berechtigungsdatensatz kann somit in gewisser Weise auch als eine Form von Kontroll- oder Steuerdaten angesehen werden, da nicht lediglich die zur Komplettierung Berechtigten vorgegeben werden, sondern vorzugsweise auch festgelegt wird, wie diese Berechtigten vorzugehen haben, welche Aktionen ausgeschlossen sind und ähnliches mehr.
Die Verwaltungsapplikation auf dem Sicherheitsmodul überwacht die Komplettierung dadurch, dass für die Komplettierung notwendige Daten lediglich durch die Verwaltungsapplikation unter Rückgriff auf den ausgewählten Berechtigungsdatensatz bereitgestellt werden. Solche Daten können beispielsweise Geheimdaten zur Authentisierung gegenüber dem zu komplettierenden Datenträger oder Prüfdaten zum Überprüfen einer Konfiguration eines komplettierten Datenträgers sein. Insofern ist eine Komplettierung des Datenträgers ohne die Verwaltungsapplikation auf dem Sicherheitsmodul und abweichend von der Spezifizierung durch den ausgewählten Berechtigungsdatensatz nicht möglich. Die Verwaltungsapplikation stellt somit eine Art Steuer- oder Kontrollapplikation dar, wobei jedoch eher eine passive, indirekte Form der Steuerung vorliegt.
Gemäß dem erfindungsgemäßen Verfahren kann eine Komplettierung von portablen Datenträgern delegiert werden. Die Komplettierung muss also nicht mehr notwendigerweise direkt beim Hersteller der Datenträger erfolgen, sondern beispielsweise bei einer externen Testabteilung, einem Kunden des Herstellers oder dergleichen. Das Einbringen von Komplettierungsdaten in den Datenträger kann dort unter Überwachung des Sicherheitsmoduls durchgeführt werden. Die Komplettierung kleiner Testserien blockiert somit nicht weiter den Komplettierungsablauf der großvolumigen Serienproduktion mit bereits ausführlich getesteten Komplettierungsdaten beim Datenträ- gerhersteller. Dadurch wird ein einfacher und effektiver Komplettierungsablauf sowohl für Großserien beim Datenträgerhersteller als auch für kleine Testserien bei der externen Stelle sichergestellt.
Auf der anderen Seite ist gewährleistet, dass von der externen Stelle lediglich solche Komplettierungen vorgenommen werden können, die durch entsprechende Berechtigungsdatensätze spezifiziert werden. Es kann dadurch beispielsweise verhindert werden, dass geheime Komplettierungsdaten ausgespäht werden, dass eine nicht zugelassene Anzahl von Datenträgern mit bestimmten Komplettierungsdaten vervollständigt wird, dass die Komplettie- rungsdaten über einen vorgegebenen Gültigkeitszeitraum hinaus verwendet werden und ähnliches mehr. Dadurch, dass das Sicherheitsmodul verschiedene Berechtigungsdatensätze verwalten kann, welche ihrerseits jeweils verschiedenen Komplettierungsdatensätzen zugeordnet sind, ist eine flexible Komplettierung verschiedener portabler Datenträger mit verschiedenen Komplettierungsdaten und unter Verwendung lediglich eines Sicherheitsmoduls möglich. Dabei ist es derjenigen Stelle, welche das Sicherheitsmodul mit der Verwaltungsapplikation sowie die Berechtigungsdatensätze bereitstellt, in der Regel also dem ursprünglichen Hersteller der Datenträger, vor- behalten, sämtliche Parameter, welche eine delegierte Komplettierung portabler Datenträger spezifizieren, detailliert vorzugeben und insofern die entsprechende Komplettierung lückenlos zu überwachen und gegebenenfalls einzuschränken oder zu verhindern. Ein erfindungsgemäßes Sicherheitsmodul zum Überwachen des erfindungsgemäßen Komplettierungsverfahrens ist eingerichtet, mit einer Komplettierungsvorrichtung verbunden zu werden. Das Sicherheitsmodul umfasst eine darauf ausführbare Verwaltungsapplikation. Weiterhin ist das Sicherheitsmodul eingerichtet, verschiedene Berechtigungsdatensätze aufzunehmen. Dabei spezifiziert jeder dieser Berechtigungsdatensätze genau eine Komplettierung und ist genau einem Komplettierungsdatensatz auf der Komplettierungsvorrichtung zugeordnet. Die Verwaltungsapplikation ist eingerichtet, die verschiedenen Berechtigungsdatensätze auf dem Sicherheitsmodul zu verwalten. Weiterhin ist die Verwaltungsapplikation eingerichtet, die Kom- plertierung des zumindest einen portablen Datenträgers gemäß der Spezifizierung in einem aus den verschiedenen Berechtigungsdatensätzen ausgewählten Berechtigungsdatensatz zu überwachen. Ein erfindungsgemäßes System zur Komplettierung zumindest eines portablen Datenträgers umfasst eine Komplettierungsvorrichtung. Auf der Komplettierungsvorrichtung wird eine Hilfsapplikation bereitgestellt. Das System umfasst weiterhin ein mit der Komplettierungsvorrichtung verbundenes, erfindungsgemäßes Sicherheitsmodul mit Verwaltungsapplikation sowie zumindest einen ebenfalls mit der Komplettierungsvorrichtung verbundenen, zu komplettierenden portablen Datenträger. Weiterhin Teil des Systems sind verschiedene Berechtigungsdatensätze sowie verschiedene Komplettierungsskripte, welche jeweils einen Komplettierungsdatensatz sowie Kom- plettierungskommandos zum Einbringen des Komplettierungsdatensatzes in einen Datenträger umfassen. Jeder Berechtigungsdatensatz ist genau einem Komplettierungsskript zugeordnet und spezifiziert genau eine Komplettierung. Die Hilfsapplikation auf der Komplettierungsvorrichtung ist eingerichtet, die verschiedenen Berechtigungsdatensätze in das Sicherheitsmodul ein- zubringen. Weiterhin ist die Hilfsapplikation eingerichtet, durch Ausführen eines solchen Komplettierungsskripts, welches einem aus den verschiedenen Berechtigungsdatensätzen ausgewählten Berechtigungsdatensatz zugeordneten ist, den durch das Komplettierungsskript umfassten Komplettierungsdatensatz in den zumindest einen Datenträger einzubringen. Die Verwaltungs- applikation ist dabei eingerichtet, die Komplettierung gemäß der Spezifizierung in dem ausgewählten Berechtigungsdatensatz zu überwachen.
Nachfolgend werden vorteilhafte Ausgestaltungen und Weiterbildungen des zuvor verdeutlichten erfindungsgemäßen Grundprinzips beschrieben, wel- ches in den unabhängigen Ansprüchen definiert ist. Dabei ist es bei der vorliegenden Erfindung trotz etwaiger Zusammenfassung mehrerer Merkmale in einzelnen abhängigen Ansprüchen technisch sinnvoll, das erfindungsgemäßen Grundprinzip durch jedes einzelne der nachfolgend erwähnten Merkmale separat zu konkretisieren, obwohl das betreffende Merkmal mög- licherweise nur im Zusammenhang mit weiteren Merkmalen beansprucht ist. Die offenbarten vorteilhaften Ausgestaltungen gehen insofern über die beanspruchten Ausführungsformen hinaus. Als Komplettierungsvorrichtung kann im Rahmen der delegierten Komplettierung beispielsweise ein einfacher Personal Computer oder dergleichen dienen. Aber auch der Einsatz von industriellen Komplettierungsmaschinen oder vergleichbaren Vorrichtungen ist möglich. Die zu komplettierenden Mengen von Datenträgern sind in der Regel sehr klein, weshalb ein hoher Datendurchsatz und eine hohe Komplettierungsgeschwindigkeit nachrangig sind. Die Komplettierungsvorrichtung muss lediglich entsprechende Schnittstellen umfassen, um mit dem Sicherheitsmodul und einem zu komplettierenden Datenträger verbunden werden zu können. Als zu komplettierende portable Datenträger kommen vor allem Chipkarten verschiedener Formfaktoren und Ausführungsformen in Frage. Vorzugsweise basieren die Karten auf der Java Card Technologie. Zum Verbinden solcher Chipkarten mit der Komplettierungsvorrichtung wird ein entsprechendes Lesegerät benötigt, welches Teil der Komplettierungsvorrichtung sein kann oder seinerseits geeignet mit der Komplettierungsvorrichtung zu verbinden ist. Andere Bauformen und Ausgestaltungen des portablen Datenträgers sind ebenfalls möglich, beispielsweise als Speicherkarte oder dergleichen. Das Sicherheitsmodul kann ebenfalls in beliebiger Bauform vorliegen, also beispielsweise als Chipkarte oder aber als USB-Token. Gemäß einer bevorzugten Ausführungsform der Erfindung wird das Sicherheitsmodul als Chipkarte mit einem auf Java basierenden Betriebssystem ausgebildet und ist eingerichtet, so genannte Java Card Applets auszuführen. Insbesondere um- fasst das Sicherheitsmodul also zumindest einen nicht volatilen, wiederbe- schreibbaren Speicher, beispielsweise einen FLASH- oder EEPROM-Speicher, sowie einen Prozessor zum Ausführen von in dem Speicher gespeicherten Applikationen. Abhängig von der Bauform des Sicherheitsmoduls muss die Komplettierungsvorrichtung eine weitere Schnittstelle zum Verbinden mit dem Sicherheitsmodul aufweisen oder mit einem entsprechenden Lesegerät verbindbar sein.
Die Verwaltungsapplikation ist vorzugsweise eine in einem Speicher des Si- cherheitsmoduls gespeicherte, auf einem Prozessor des Sicherheitsmoduls ausführbare Applikation. Vorzugsweise ist die Verwaltungsapplikation als Java Card Applet ausgebildet, welches auf einem Sicherheitsmodul in Form einer Java Card ausführbar ist. Wie nachfolgend detailliert beschrieben, ist die Verwaltungsapplikation in der Regel personalisiert und unterstützt di- verse Sicherheitsmechanismen.
Sowohl das Berechtigungsdatenskript also auch das Komplettierungsskript dienen der Automatisierung des Komplettierungsverfahrens. Die Skripte können mittels jeder geeigneten Skriptsprachen erstellt werden, beispiels- weise mittels„Groovy" oder dergleichen.
Sind der zu komplettierende Datenträger und das Sicherheitsmodul als Chipkarten gemäß ISO 7816 ausgebildet, so kann die Kommunikation dieser Elemente mit den entsprechenden Lesegeräten über so genannte APDUs („application protocol data units") erfolgen. Demnach umfassen die Skripte in Zusammenhang mit solchen Datenträgern bzw. Sicherheitsmodulen Kommandos in Form von APDUs. Die Verwaltungsapplikation auf dem Sicherheitsmodul sowie die zu komplettierenden Datenträger erkennen und unterstützen die jeweiligen Kommandos. Dabei kommen sowohl bekannte Stan- dardkomrnandos als auch proprietäre, speziell für den erfindungsgemäßen Gebrauch entwickelte APDUs zum Einsatz.
Die Hilfsapplikation auf der Komplettierungsvorrichtung ist dazu vorgese- hen, das Berechtigungsdatenskript und das Komplettierungsskript auszuführen. D.h. die Intelligenz und Flexibilität des Verfahrens liegt in den Skripten, nicht aber in der Hilfsapplikation. Diese kann als Schnittstelle zwischen einem Bediener der Komplettierungsvorrichtung, der Verwaltungsapplikation auf dem Sicherheitsmodul und dem zu komplettierenden Datenträger angesehen werden. Die Hilfsapplikation kann somit universell zum Komplettieren verschiedenster Datenträger mittels verschiedenster Komplettierungsskripte verwendet werden, ohne jeweils dafür angepasst zu werden. Dennoch ist die Hilfsapplikation oder ein ähnlicher Mechanismus für das Komplettierungsverfahren von zentraler Bedeutung, da sie eine Verbindung zwischen der Verwaltungsapplikation auf dem Sicherheitsmodul und dem zu komplettierenden portablen Datenträger herstellen kann und das Kom- pletteierungsskript erst durch die Hilfsapplikation ausgeführt werden kann. Vorzugsweise basiert auch die Hilfsapplikation auf Java, kann jedoch auch in jeder geeigneten anderen Sprache programmiert sein.
Wie vorstehend angedeutet, spezifiziert ein ausgewählter Berechtigungsdatensatz einen bei der Komplettierung in einen zu komplettierenden Datenträger einzubringenden Komplettierungsdatensatz eindeutig beispielsweise dadurch, dass dem Berechtigungsdatensatz eindeutig ein Komplettierungs- skript zugeordnet ist. Das Komplettierungsskript, welches in der Regel auf der Komplettierungsvorrichtung bereitgestellt wird, umfasst den entsprechenden Komplettierungsdatensatz sowie Komplettierungskommandos zum Einbringen des Komplettierungsdatensatzes in den Datenträger. Somit gibt das dem Berechtigungsdatensatz zugeordnete Komplettierungsskript insbe- sondere den einzubringenden Komplettierungsdatensatz vor. Die Spezifizierung des Komplettierungsdatensatzes bzw. des den Komplettierungsdaten- satz umfassenden Komplettierungsskripts erfolgt vorzugsweise über eine Namenskonvention, d.h. der Berechtigungsdatensatz sowie das diesem zu- geordnete Komplettierungsskript weisen eindeutig gleiche Namensbestandteile auf, aus welchen die Zuordnung zueinander abgelesen werden kann. Alternativ oder zusätzlich kann der Berechtigungsdatensatz einen Prüfwert umfassen, welcher von dem zugeordneten Komplettierungsdatensatz oder dem zugeordneten Komplettierungsskript abgeleitet worden ist, beispiels- weise einen Hashwert. Über diesen Prüf wert kann das Komplettierungsskript dann eindeutig identifiziert werden. Das Vorsehen eines solchen Prüfwerts ermöglicht weiterhin zu erkennen, ob der Komplettierungsdatensatz bzw. das Komplettierungsskript unerlaubt verändert worden sind. Die Komplettierungsdaten werden dann im Rahmen des erfindungsgemäßen Verfahrens vorzugsweise dadurch in den Datenträger eingebracht, dass das dem ausgewählten Berechtigungsdatensatz zugeordnete Komplettierungsskript durch die Hilfsapplikation auf der Komplettierungsvorrichtung ausgeführt wird. D.h. insbesondere, dass die Hilfsapplikation lediglich Schnittstel- lencharakter besitzt und keine eigenen Kommandos zum Einbringen des Komplettierungsdatensatzes bereitstellen muss.
Eine Komplettierung wird jeweils vollständig durch einen der verschiedenen Berechtigungsdatensätze spezifiziert, welche auf dem Sicherheitsmodul ver- waltet werden. Eine solche Spezifizierung umfasst eine Reihe von Vorgaben, welche bei der entsprechenden Komplettierung eingehalten werden müssen, damit diese von der Verwaltungsapplikation auf dem Sicherheitsmodul zugelassen wird. Wie nachstehend detailliert beschrieben, können verschiedene, eine Komplettierung betreffende Parameter mittels des entsprechenden, diese Komplettierung spezifizierenden Berechtigungsdatensatzes genau vorgegeben werden.
In der Regel wird das Sicherheitsmodul personalisiert, bevor es ausgegeben bzw. bereitgestellt wird, beispielsweise mittels einer eindeutigen Identifikationsnummer. Jede Stelle, die ein Sicherheitsmodul zur delegierten Komplettierung von portablen Datenträgern erhält, kann somit über die Identifikationsnummer in dem Sicherheitsmodul identifiziert bzw. adressiert werden. In gleicher Weise wird die Verwaltungsapplikation auf dem Sicherheitsmodul mit der Identifikation des Sicherheitsmoduls personalisiert und in dieser Weise an das Sicherheitsmodul gebunden. Damit wird sichergestellt, dass die Verwaltungsapplikation lediglich in Verbindung mit dem dafür vorgesehenen Sicherheitsmodul und lediglich von der Stelle, welcher das entsprechende Sicherheitsmodul bereitgestellt worden ist, verwendet wird. Weiter kann sichergestellt werden, dass ein Komplettierungsskript, welches dazu vorgesehen ist, unter der Überwachung eines bestimmten, ersten Sicherheitsmoduls zur Komplettierung portabler Datenträger verwendet zu werden, nicht dazu dienen kann, eine Komplettierung von Datenträgern unter der Kontrolle eines anderen, zweiten Sicherheitsmoduls zu unterstützen.
Wird im Folgenden, wie bereits vorhergehend, von einem ausgewählten Berechtigungsdatensatz oder auch lediglich von einem Berechtigungsdatensatz gesprochen, so ist jeweils ein Berechtigungsdatensatz aus der Menge der verschiedenen Berechtigungsdatensätze auf dem Sicherheitsmodul gemeint, welcher ausgewählt worden ist, um eine konkrete Komplettierung eines portablen Datenträgers gemäß dem erfindungsgemäßen Verwahren zu überwachen. Ein ausgewählter Berechtigungsdatensatz spezifiziert zum einen, wie bereits angedeutet, das konkrete Sicherheitsmodul, welches eine Komplettierung gemäß dem Berechtigungsdatensatz überwachen und die entsprechende Komplettierung auf dem komplettierten Datenträger danach freigeben kann. Dies geschieht vorzugsweise dadurch, dass der Berechtigungsdatensatz eine das Sicherheitsmodul eindeutig identifizierende Information, beispielsweise eine Identifikationsnummer des Sicherheitsmoduls, umfasst. Der Berechtigungsdatensatz wird auf dem Sicherheitsmodul lediglich dann geeignet bereitgestellt, beispielsweise an entsprechender Stelle auf dem Sicherheitsmo- dul gespeichert, wenn das Sicherheitsmodul mit der entsprechenden Vorgabe in dem Berechtigungsdatensatz übereinstimmt. Auf diese Weise wird sichergestellt, dass ein spezifischer Berechtigungsdatensatz lediglich auf genau den Sicherheitsmodulen bzw. bei genau den Stellen, denen entsprechende Sicherheitsmodule bereitgestellt worden sind, verwendbar ist, welche in dem Berechtigungsmodul als zugelassene Sicherheitsmodule vorgegeben sind. Eine Verwendung des Berechtigungsdatensatzes auf anderen, in der Spezifizierung des Berechtigungsdatensatzes nicht angegebenen Sicherheitsmodulen, wird damit wirkungsvoll unterbunden. Weiterhin spezifiziert ein ausgewählter Berechtigungsdatensatz einen portablen Datenträger, welcher gemäß der Spezifizierung in dem Berechtigungsdatensatz komplettiert werden darf. Eine entsprechende Komplettierung des Datenträgers, d.h. ein Einbringen von Komplettierungsdaten sowie eine Konfiguration der Komplettierung, erfolgt lediglich dann, wenn der Da- tenträger mit der Spezifizierung in dem Berechtigungsdatensatz übereinstimmt. Ein Datenträger kann beispielsweise über eine diesem zugeordnete Hardwareidentifikation bezeichnet werden. In der Regel ist diese Hardwareidentifikation für alle Datenträger einer Charge gleich, welche eine identische Betriebssystemmaske in ihrem ROM-Speicher umfassen. Weiterhin kann ein Datenträger indirekt darüber spezifiziert werden, dass in dem Berechtigungsdatensatz den Datenträger betreffende Geheimdaten enthalten sind. Solche Geheimdaten können beispielsweise geheime Schlüssel oder dergleichen sein, welche im Laufe des Komplettierungsverfahrens benötigt werden, beispielsweise zur Authentisierung gegenüber dem Datenträger oder zum Aufbauen einer gesicherten Datenkommunikation mit dem Datenträger. Somit kann lediglich dann, wenn diese Geheimdaten in dem Berechtigungsdatensatz mit den entsprechenden Geheimdaten des zu komplettierenden Datenträgers übereinstimmen, eine Komplettierung überhaupt durchgeführt werden. Im gegenteiligen Fall scheitert diese Komplettierung bereits in den ersten Schritten, beispielsweise bei der Authentisierung der Komplettie- rungsvorrichtung bzw. der Hilfsapplikation gegenüber dem Datenträger. Dies liefert ein Beispiel dafür, dass das Überwachen der Komplettierung durch die Verwaltungsapplikation auf Basis eines ausgewählten Berechti- gungsdatensatzes zumeist keine aktive Überwachung, Steuerung oder Kontrolle des Komplettierungsverfahrens darstellt, sondern vielmehr indirekt geschieht, indem notwendige Daten lediglich berechtigten Instanzen bereitgestellt werden bzw. Instanzen sich dadurch als berechtigt herausstellen, dass sie zu von der Verwaltungsapplikation bereitgestellten verfahrensnot- wendigen Daten kompatibel oder passend sind.
Vorzugsweise spezifiziert ein ausgewählter Berechtigungsdatensatz weiterhin, wie viele portable Datenträger mittels des spezifizierten Komplettierungsdatensatzes komplettiert werden dürfen. Auch ein Zeitraum, innerhalb dessen eine Komplettierung zu erfolgen hat, kann in dem Berechtigungsdatensatz vorgegeben sein. Lediglich dann, wenn eine entsprechende Maximalanzahl von Komplettierungen noch nicht erreicht ist bzw. dann, wenn der vorgegebene Zeitraum noch andauert, kann eine Komplettierung durchgeführt werden. Auf diese Weise kann sichergestellt werden, dass lediglich eine vorgesehene Anzahl von Datenträgern, wie durch den Berechtigungsdatensatz spezifiziert, komplettiert werden kann. Die Verwaltungsapplikation kann dazu auf dem Sicherheitsmodul beispielsweise einen entsprechenden Zähler verwalten, welcher nach jeder spezifikationsgemäß durchgeführten Komplettierung dekrementiert wird. Mittels des Ablaufdatums kann sichergestellt werden, dass stets lediglich aktuelle und nicht versehentlich veraltete Komplettierungsskripte verwendet werden.
Vorzugsweise wird der externen Stelle, an welche die Komplettierung der portablen Datenträger delegiert wird, wie erwähnt, die auf der Komplettierungsvorrichtung ausführbare Hilfsapplikation, das Sicherheitsmodul mit der Verwaltungsapplikation sowie eine Anzahl noch nicht komplettierter portabler Datenträger vorab bereitgestellt. Liegt dann ein neuer Komplettierungsdatensatz vor, mit dem die Datenträger beispielsweise zu Testzwecken komplettiert werden sollen, so kann dies gemäß den folgenden Schritten ablaufen: Es wird ein Berechtigungsdatenskript erstellt. Dieses umfasst einen Berechtigungsdatensatz, welcher wie vorstehend detailliert beschrieben die durchzuführende Komplettierung im Wesentlichen vollständig vorgibt. Weiter umfasst das Berechtigungsdatenskript zumindest ein Kommando. Mittels dieses Kommandos kann, wie nachstehend erläutert, der Berechtigungsdatensatz in das Sicherheitsmodul eingebracht werden. Weiterhin wird ein Komplettierungsskript erstellt, welches den Komplettierungsdatensatz sowie die bereits vorstehend erläuterten Komplettierungskommandos umfasst. Gemäß der eindeutigen Zuordnung des Berechtigungsdatensatzes zu dem Komplettierungsdatensatz sind das Berechtigungsdatenskript und das Komplettierungsskript einander eindeutig zugeordnet. Das Berechtigungsdatenskript und das Komplettierungsskript werden dann an die Komplettierungsvorrichtung übertragen. Diese Übertragung kann beispielsweise per e-Mail erfolgen, aber auch jede andere Art der Übertragung ist möglich. Diese Schritte werden von der Instanz durchgeführt, welche die Kontrolle über den gesamten Komplettierungsvorgang besitzt, in der Regel also dem Hersteller der Datenträger. Der Berechtigungsdatensatz wird dann von der Komplettierungsvorrichtung an das Sicherheitsmodul übertragen, indem die Hilfsapplikation auf der Komplettierungsvorrichtung das Berechtigungsdatenskript ausführt. Wie schon im Zusammenhang mit dem Komplettierungsskript beschrieben, fungiert die Hilfsapplikation lediglich ausführend, stellt also kein eigenes Kommando zur Verfügung, sondern führt lediglich das oder die Kommandos des Berechtigungsdatenskripts aus, um die Übertragung des Berechtigungsdatensatzes an das Sicherheitsmodul zu bewirken. In einem weiteren Schritt führt die Hilfsapplikation - wie bereits erwähnt - das Komplettierungsskript aus, um den Komplettierungsdatensatz in den portablen Daten- träger einzubringen. Beiden Übertragungsschritten gehen in der Regel allerdings eine Reihe weiterer Schritte voraus, welche die Sicherheit des gesamten Komplettierungssystems gewährleisten und welche im Folgenden detailliert beschrieben werden. Vorzugsweise werden der Berechtigungsdatensatz sowie das Komplettierungsskript vor der Übertragung an die Komplettierungsvorrichtung verschlüsselt. Damit wird ein Ausspähen oder gar Verändern dieser sicherheitsrelevanten Daten während der Übertragung verhindert. Während das Berechtigungsdatenskript als solches unverschlüsselt verbleiben kann, da es den verschlüsselten Berechtigungsdatensatz umfasst, wird das Komplettierungsskript in der Regel vollständig verschlüsselt, d.h. der Komplettierungsdatensatz zusammen mit den Komplettierungskommandos. Damit kann auch keine Information über die Komplettierungskommandos in unberechtigten Besitz gelangen. Das Komplettierungsskript wird, nachdem es von der Hilfsapplikation auf der Komplettierungsvorrichtung empfangen worden ist, von der Hilfsapplikation selbst entschlüsselt. Vorzugsweise ist die Hilfsapplikation die einzige Instanz, welche den Schlüssel zum Entschlüsseln des Komplettierungsskripts besitzt. Damit ist eine Verwendung der Hilfsapplikation im Rahmen des Komplettierungsverfahrens unbedingt erforderlich. Erst nach dem Entschlüsseln kann das Komplettierungsskript von der Hilfsapplikation ausgeführt werden, um den Komplettierungsdatensatz in den Datenträger einzu- bringen. Ein während der Übertragung zu der Komplettierungs Vorrichtung abgefangenes Komplettierungsskript ist somit für einen Angreifer wertlos, da er es nicht entschlüsseln kann und weder an den Komplettierungsdatensatz noch an die Komplettierungskommandos gelangt. Im Gegensatz dazu wird der verschlüsselte Berechtigungsdatensatz erst nach dem Übertragen an das Sicherheitsmodul durch die Verwaltungsapplikation auf dem Sicherheitsmodul entschlüsselt. Die Hilfsapplikation kann die Übertragung des verschlüsselten Berechtigungsdatensatzes an das Sicherheitsmodul trotzdem bewirken, da sie das an sich unverschlüsselte Berechti- gungsdatenskript ohne weiteres ausführen kann. Belauscht ein Angreifer die Übertragung des Berechtigungsdatenskripts, so kann er den sicherheitsrelevanten Berechtigungsdatensatz lediglich verschlüsselt auslesen. Es ist gleichfalls möglich, das Berechtigungsdatenskript im Ganzen, d.h. bereits verschlüsselter Berechtigungsdatensatz zusammen mit Kommando(s), vor der Übertragung an die Komplettierungsvorrichtung mit demselben Schlüssel wie zuvor das Komplettierungsskript zu verschlüsseln. Dann müsste die Hilfsapplikation, vor dem Übertragen des mit einem separaten Schlüssel verschlüsselten Berechtigungsdatensatzes das Berechtigungsdatenskript erst entschlüsseln und dann ausführen. Der unter allen Umständen geheim zu haltende Berechtigungsdatensatz wird wie erwähnt mit einem separaten Schlüssel verschlüsselt, welcher lediglich der Verwaltungsapplikation auf dem Sicherheitsmodul vorliegt. Das Ausstatten der Verwaltungsapplikation mit diesem geheimen Schlüssel zur Entschlüsselung eines Berechtigungsda- tensatzes kann als weiterer - indirekter - Schritt der Personalisierung des Sicherheitsmoduls angesehen werden. Dieser Schlüssel wird dort sicher verwaltet und kann auch von der Stelle, welche die Komplettierung der Datenträger ausführt, nicht ausgelesen werden. Damit ist der Berechtigungsdatensatz zu jedem Zeitpunkt vor unberechtigtem Ausspähen oder Verändern si- eher geschützt.
Es zeigt sich an dieser Stelle, dass Berechtigungsdatensätze und diesen eindeutig zugeordnete Komplettierungsskripte unabhängig voneinander verwaltet werden. Die Verwaltung der verschiedenen Berechtigungsdatensätze, beginnend mit der Entschlüsselung durch die Verwaltungsapplikation auf dem Sicherheitsmodul, erfolgt vollständig durch die Verwaltungsapplikation und ausschließlich auf dem Sicherheitsmodul. Die Verwaltung der verschiedenen Komplettierungsskripte hingegen erfolgt durch die Hilfsapplikation auf der Komplettierungsvorrichtung, welche die Skripte beim Empfang ent- schlüsselt und nachfolgend verwaltet, beispielsweise zuerst an eine vorgegebene Stelle in einem Speicher der Komplettierungsvorrichtung speichert. Lediglich dann, wenn ein konkreter Datenträger komplettiert werden soll, wird ein Berechtigungsdatensatz ausgewählt, welcher die Komplettierung spezifiziert und dadurch überwacht. Zu diesem Berechtigungsdatensatz wird dann das zugeordnete Komplettierungsskript bestimmt, welches nachfolgend durch die Hilfsapplikation ausgeführt wird.
Während eines solchen Komplettierungsvorgangs werden sicherheitsrelevante Daten zwischen dem Sicherheitsmodul und dem zu komplettierenden Datenträger über die Hilfsapplikation auf der Komplettierungsvorrichtung, mit welcher sowohl das Sicherheitsmodul als auch der Datenträger verbunden sind, übertragen. Um die Integrität und Geheimhaltung dieser Daten zu gewährleisten, ist es notwendig, dass sich die Hilfsapplikation zu Beginn des Verfahrens gegenüber dem Sicherheitsmodul authentisiert. Auch eine Authentisierung der Hilfsapplikation gegenüber dem zu komplettierenden Datenträger kann vorgesehen sein. Weiterhin verläuft die Datenkommunikation zwischen der Hilfsapplikation und dem Sicherheitsmodul während des größten Teils des Komplettierungsverfahrens gesichert, beispielsweise ver- schlüsselt. Dazu wird vorbereitend ein sicherer Kommunikationskanal zwischen der Verwaltungsapplikation auf dem Sicherheitsmodul und der Hilfsapplikation auf der Komplettierungsvorrichtung aufgebaut. In ähnlicher Weise wird ein sicherer Kommunikationskanal zwischen der Hilfsapplikation auf der Komplettierungsvorrichtung und dem zu komplettierenden por- tablen Datenträger hergestellt. Somit kann die Datenübertragung auch zwischen der Komplettierungsvorrichtung und dem Datenträger gesichert durchgeführt werden.
Eine Authentisierung der Hilfsapplikation gegenüber dem Sicherheitsmodul kann mittels eines Passwortes erfolgen. Dieses Passwort erhält die Stelle, an welche die Komplettierung delegiert wird, bei Bereitstellung des Sicherheitsmoduls. Das Passwort ist lediglich für das eine Sicherheitsmodul gültig, welche per Identifikationsnummer für die entsprechende Stelle personalisiert worden ist. Zur Herstellung eines gesicherten Kommunikationskanals zwi- sehen der Hilfsapplikation auf der Komplettierungsvorrichtung und dem
Sicherheitsmodul können dann aus dem Passwort geheime Schlüssel abgeleitet werden. Diese Schlüssel sind der die Komplettierung durchführenden Stelle zu keinem Zeitpunkt bekannt. Die Ableitung und sichere Verwaltung dieser Schlüssel obliegt der Hilfsapplikation. Diese Schlüssel sind außerhalb der Hilfsapplikation nicht zugänglich. Insofern kann eine gesicherte Datenkommunikation mit dem Sicherheitsmodul, welche für verschiedene Schritte des Komplettierungsvorgangs erforderlich ist, ausschließlich über die Hilfsapplikation erfolgen. Auch auf diese Weise wird sichergestellt, dass ein Komplettierungsvorgang ohne ein erfindungsgemäßes Zusammenwirken der verschiedenen Komponenten, hier des Sicherheitsmoduls und der Hilfsapplikation auf der Komplettierungsvorrichtung, nicht durchführbar ist.
Geheimdaten, welche zur Authentisierung der Hilfsapplikation auf der Komplettierungsvorrichtung gegenüber dem Datenträger erforderlich sind, werden der Hilfsapplikation von der Verwaltungsapplikation auf dem Sicherheitsmodul bereitgestellt. Dies kann auf gesichertem Weg geschehen, da, wie erwähnt, eine gesicherte Datenkommunikation zwischen dem Sicherheitsmodul und der Hilfsapplikation bereits gewährleistet ist. Zur Authenti- sierung gegenüber dem Datenträger wird der Hilfsapplikation von der Verwaltungsapplikation auf dem Sicherheitsmodul auf Anfrage ein Authentisie- rungswert bereitgestellt, welcher mittels in dem Berechtigungsdatensatz gespeicherter Daten von der Verwaltungsapplikation bestimmt wird. Geheime Schlüssel zur Herstellung eines sicheren Kommunikationskanals zwischen der Hilfsapplikation auf der Komplettierungsvorrichtung und dem Datenträger werden ebenfalls von der Verwaltungsapplikation auf dem Sicherheitsmodul bereitgestellt. Dazu umfasst der Berechtigungsdatensatz einen speziellen Grundschlüssel des Datenträgers, aus welchem die zur Herstellung des sicheren Kanals benötigten geheimen Schlüssel abgeleitet werden können.
Eine Komplettierung eines Datenträgers wird durch den ausgewählten Berechtigungsdatensatz weiterhin dadurch vorgegeben, dass auch die Konfiguration des Datenträgers genau spezifiziert ist. Es ist möglich, zwei Datenträ- ger, welche eine identische Betriebsystemmaske, beispielsweise im ROM- Speicher, sowie einen identischen Komplettierungsdatensatz, beispielsweise im EEPROM-Speicher, umfassen, auf verschiedene Weisen zu konfigurieren. Insofern ist eine Vorgabe der beabsichtigten Konfiguration ein wesentlicher Teil der Spezifikation in dem Berechtigungsdatensatz. Nur wenn die erfolgte Konfiguration des Datenträgers nach dem Einbringen des Komplettierungsdatensatzes in der durch den Berechtigungsdatensatz vorgegebenen Weise erfolgt ist, wird die Konfiguration freigegeben - erst dadurch wird der Datenträger zur weiteren Verwendung betriebsbereit. Eine solche Freigabe kann durch ein Freigabekommando erfolgen, welches der Datenträger von der Hilfsapplikation empfängt. Dieses Kommando kann Konfigurationsprüfdaten umfassen, welche die beabsichtigte Konfiguration des Datenträgers vollständig festlegen, beispielsweise in Form eines Prüfwerts. Ein entsprechender Prüfwert wird von dem Datenträger über die aktuelle Konfigu- ration berechnet. Nur bei Übereinstimmung beider Prüf werte wird die Komplettierung inklusive Konfiguration freigegeben.
Vor dem Einbringen des Komplettierungsdatensatzes in den zu komplettierenden Datenträger wird dieser Datentiäger individualisiert. Dieser Schritt wird in der Regel durch Kommandos des Komplettierungsskripts durchgeführt. Dieses prüft zuerst, ob der Datenträger bereits individualisiert ist oder nicht. Dazu ist zu bemerken, dass eine Charge von baugleichen Datenträgern vor der Komplettierung in der Regel nicht individualisiert ist, mithin trägt jeder Datenträger der Charge die gleiche Chargennummer. Die Chargen- nummer wird zur Berechnung des Authentisierungswertes zur Authentisie- rung gegenüber dem Datenträger verwendet. Um beispielsweise zu verhindern, dass missbräuchlich ein gesamter Komplettierungsvorgang eines Datenträgers„aufgezeichnet" und nachfolgend in gleicher Weise für eine beliebige Anzahl baugleicher Datenträger derselben Charge mit demselben Au- thentisierungswert durchgeführt werden kann, wird dem eigentlichen Komplettierungsvorgang, d.h. dem Einbringen des Komplettierungsdatensatzes in den Datenträger, ein Individualisierungsschritt vorangestellt. Das Einbringen der Komplettierungsdaten erfordert für sich wie erwähnt eine Au- thentisierung gegenüber dem Datenträger. Somit ist für eine erfindungsgemäße Komplettierung eines Datenträgers eine datenträgerindividuelle Au- thentisierung erforderlich. Zur Individualisierung des Datenträgers, welche auch Prä-Initialisierung genannt, wird die Chargennummer des Datenträgers durch seine Seriennummer ersetzt. Die Seriennummer des Datenträgers ist datenträgerindividuell. Folglich ist ab diesem Zeitpunkt auch der Authenti- sierungswert zur Authentisierung gegenüber dem Datenträger, welcher mittels der nun durch die Seriennummer ersetzten Chargennummer berechnet wird, datenträgerindividuell. Dieses Verändern der Chargennummer kann als vorgelagerte Komplettierung angesehen werden und erfordert, als solche, ebenfalls eine Authentisierung gegenüber dem zu individualisierenden Datenträger. Diese kann für eine gesamte Charge allerdings mit einem lediglich chargenspezifischen Authentisierungswert erfolgen, welcher somit Teil des Komplettierungsskripts sein kann. Eine solche Individualisierung kann unterbleiben, falls ein entsprechender Datenträger bereits individualisiert ist, weil er beispielsweise in einem früheren Produktionszyklus bereits komplettiert worden ist, diese frühere Komplettierung nun aber durch eine neue Komplettierung ersetzt werden soll.
Im Folgenden wird die vorliegende Erfindung mit Bezug auf die beiliegenden Zeichnungen beispielhaft beschrieben. Darin zeigen:
Figur 1 Komponenten einer bevorzugten Ausführungsform eines erfindungsgemäßen Systems; Figuren 2 bis 8 Schritte einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens zum Komplettieren von portablen Datenträgern.
Mit Bezug auf Fig. 1 umfasst ein Komplettierungssystem 1000 eine Komplettierungsvorrichtung 200, beispielsweise in Form eines Personal Computers (PC), ein Sicherheitsmodul 100, verschiedene Berechtigungsdatenskripte 400, 400', 400", verschiedene Komplettierungsskripte 300, 300', 300" sowie zu komplettierende Datenträger 10, 11, 12, 13.
Die Komplettierungsvorrichtung 200 umfasst geeignete Schnittstellen 220, 230, um mit dem Sicherheitsmodul 100 sowie einem zu komplettierenden Datenträger 10 verbunden zu werden. Die Schnittstellen 220, 230 können beispielsweise als Chipkartenlesegeräte ausgebildet sein, wenn das Sicherheitsmodul 100 und die zu komplettierenden Datenträger 10, 11, 12, 13 als Chipkarten ausgebildet sind. Auf der Komplettierungsvorrichtung 200 ist eine Hilfsapplikation 210 installiert, welche bei dem nachfolgend detailliert beschriebenen Komplettierungsverfahren die Rolle einer Schnittstelle zwischen einem Nutzer der Komplettierungsvorrichtung 200, dem Sicherheitsmodul 100 und einem zu komplettierenden Datenträger 10 spielt. Die Hilfsapplikation 210 ist eingerichtet, die Berechtigungsdatenskripte 400, 400', 400" sowie die Komplettierungsskripte 300, 300', 300", welche nachfolgend be- schrieben werden, auszuführen. Die Komplettierungsvorrichtung 200 ist weiterhin an ein Netzwerk angebunden, beispielsweise das Internet. Über dieses Netzwerk kann die Komplettierungsvorrichtung 200 Daten empfangen, wie beispielsweise die Komplettierungsskripte 300, 300', 300" und die Berechtigungsdatenskripte 400, 400', 400". Das Sicherheitsmodul 100 ist als portabler Datenträger ausgebildet, beispielsweise als Chipkarte, insbesondere als GlobalPlatform Java Card. Alternativ kann das Sicherheitsmodul 100 aber z.B. auch als USB-Token oder der- gleichen ausgebildet sein. Auf dem Sicherheitsmodul 100 ist eine Verwaltungsapplikation 110 lauffähig installiert. Mittels dieser Verwaltungsapplikation 110 werden verschiedene, noch zu beschreibende Berechtigungsdatensätze 310, 310', 310" in dem Sicherheitsmodul 100 verwaltet. Weiterhin ist die Verwaltungsapplikation 110 eingerichtet, das nachstehend beschriebene Komplettierungsverfahren zu überwachen.
Ein zu komplettierender portabler Datenträger 10, beispielsweise ebenfalls in Form einer Java Card, umf asst einen ROM-Speicher (nicht gezeigt), in welchen bereits eine Betriebssystemmaske eingebracht worden ist, sowie einen wiederbeschreibbaren, nicht flüchtigen Speicher (nicht gezeigt), beispielsweise einen FLASH-Speicher oder einen EEPROM-Speicher, in welchen während des nachfolgend beschriebenen Komplettierungsverfahrens Komplettierungsdaten 310 eingeschrieben werden. Mittels dieser Komplettierungsdaten 310 werden eventuelle Fehler in der ROM-Maske behoben. Weiterhin wird das Betriebssystem des Datenträgers 10 während der Komplettierung durch die Komplettierungsdaten 310 geeignet ergänzt sowie konfiguriert und erstmalig gebootet.
Ein Komplettierungsskript 300, 300', 300" umf asst einen Komplettierungsda- tensatz 310, 310', 310" sowie Komplettierungskommandos 320, 320', 320". Mittels dieser Kommandos 320, 320', 320" wird der Komplettierungsdatensatz 310, 310', 310" während des Komplettierungsverfahrens in einen zu komplettierenden Datenträger 10, 11, 12, 13 eingebracht. Das Komplettie- rungsskript 300, 310', 310" wird dabei, wie nachfolgend beschrieben, von der Hilfsapplikation 210 auf der Komplettierungsvorrichtung 200 ausgeführt.
Ein Berechtigungsdatenskript 400, 400', 400" schließlich umfasst einen Be- rechtigungsdatensatz 410, 410', 410" sowie zumindest ein Kommando 420, 420', 420" zum Einbringen des Berechtigungsdatensatzes 410, 410', 410" das Sicherheitsmodul 100. Dazu wird das Kommando 420, 420', 420" in zu beschreibender Weise ebenfalls von der Hilfsapplikation 210 auf der Komplettierungsvorrichtung 200 ausgeführt. Ein Berechtigungsdatensatz 410, 410', 410" ist jeweils eindeutig einem Komplettierungsdatensatz 310, 310', 310" zugeordnet und spezifiziert jeweils eine Komplettierung. D.h. in dem Berechtigungsdatensatz 410, 410', 410" sind alle wesentlichen Parameter eines Komplettierungsvorgangs vorgegeben, wie dies im Folgenden mit Bezug auf die Fig. 2 bis 8 genau beschrieben wird.
Das hier beschriebene Komplettierungsverfahren ist entwickelt worden, um einen Komplettierungsvorgang an eine externe Stelle verschieden vom Hersteller der zu komplettierenden Datenträger 10, 11, 12, 13 delegieren zu können. Eine solche externe Stelle kann beispielsweise eine externe Abteilung des Herstellers oder aber ein enger Kunde sein. Auf diese Weise wird der Produktionsablauf beim eigentlichen Hersteller nicht durch die Komplettierung von kleinen Testmengen von Datenträgern beeinträchtigt. Die bereitgestellten Sicherheitsmaßnahmen, insbesondere das Sicherheitsmodul 100 mit der Verwaltungsapplikation 110 sowie die dadurch verwalteten Berechti- gungsdatensätze 410, 410', 410" erlauben es des Hersteller trotz der Delegation der Komplettierung vollständige Kontrolle über sämtliche Komplettierungsschritte und Komplettierungsergebnisse zu behalten. Schließlich sind aufgrund vorgesehener kryptographischer Absicherung des delegierten Komplettierungsverfahrens sämtliche sicherheitsrelevanten Komplettie- rungsskripte 300, 300', 300" und Berechtigungsdatensätze 410, 10', 410" stets gesichert und von unautorisierter Stelle weder einzusehen noch zu verändern. Mit Bezug auf Fig. 2 werden das Komplettierungsverfahren vorbereitende Schritte beschrieben. In Schritt Sl wird das Sicherheitsmodul 100 vorbereitet. Dazu wird im Teilschritt TS11 die Verwaltungsapplikation 110 in das Sicherheitsmodul 100 geladen, um dort ausführbar zu sein. Anschließend wird das Sicherheitsmodul 100 in TS12 personalisiert, indem es mit einer eindeutigen Identitätsnummer ID versehen wird. Mittels dieser Identitätsnummer kann jede externe Stelle, welche zum externen Komplettieren ein solches Sicherheitsmodul 100 erhält, eindeutig adressiert werden. Schließlich wird auch die Verwaltungsapplikation 110 auf dem Sicherheitsmodul 100 in Teilschritt TS13 personalisiert: Zum einen mit der Identitätsnummer ID des Sicher- heitsmoduls 100, zum anderen mit einem kryptographischen Schlüssel keyBD. Durch die Personalisierung mit der Identitätsnummer ID des Sicherheitsmoduls 100 wird die Verwaltungsapplikation 110 an das Sicherheitsmodul 100 gebunden, kann somit nur in Verbindung mit dem eindeutig kennzeichneten Modul 100, welches die gleiche ID trägt, nicht aber mit einem baugleichen anderen Sicherheitsmodul, verwendet werden. Der Schlüssel keyBD dient, wie nachfolgend beschrieben, dem Entschlüsseln von durch die Verwaltungsapplikation 110 verschlüsselt empfangenen Berechtigungsdatensätzen 410, 410', 410". Ein derart vorbereitetes Sicherheitsmodul 100 wird in Schritt S2 der externen Stelle bereitgestellt.
In Schritt S3 wird der externen Stelle weiterhin die Hilfsapplikation 210 bereitgestellt. Diese ist auf der Komplettierungsvorrichtung 200 zu installieren. Wie im Folgenden beschrieben, kann das Komplettierungsverfahren ohne die Hilfsapplikation 210 nicht durchgeführt werden, ebenso nicht ohne das Sicherheitsmodul 100. In Schritt S4 schließlich erhält die externe Stelle eine Anzahl zu komplettierender Datenträger 10, 11, 12, 13. In der Regel sind dies Datenträger einer baugleichen Charge, welche bisher nicht komplettiert worden sind. Es ist aber auch möglich, dass einzelne oder alle der bereitgestellten Datenträger 10, 11, 12, 13 bereits in einer vorhergegangenen Produktionsphase komplet- tiert worden sind und nun zu Testzwecken erneut, beispielsweise zur Verbesserung oder Fehlerkorrektur des Betriebssystems, komplettiert werden sollen.
In den mit Bezug auf Fig. 3 beschriebenen Schritten werden Komplettie- rungsdaten und Berechtigungsdaten erzeugt und an die externe Stelle übertragen. Diese Schritte werden vom Hersteller der zu komplettierenden Datenträger immer dann ausgeführt, wenn eine neue Komplettierungsversion, also z.B. ein Komplettierungsdatensatz 310 zur Ergänzung eines Betriebsystems eines Datenträgers 10, vorliegt.
In Schritt S5 wird ein neuer Komplettierungsdatensatz 310 zur Komplettierung eines portablen Datenträgers 10, 11, 12, 13 erzeugt. Dieser Komplettierungsdatensatz 310 kann eine Weiterentwicklung einer vorhergehenden Version von Komplettierungsdaten sein oder aber eine Neu- oder Erstentwick- lung. Der Komplettierungsdatensatz 310 umfasst genau die Daten, die in einen Speicher eines zu komplettierenden Datenträgers 10, 11, 12, 13 eingebracht werden sollen. Dazu sind in der Regel Kommandos notwendig, mittels welcher die Komplettierungsvorrichtung 200 mit dem Datenträger 10, 11, 12, 13 kommuniziert, um die Komplettierungsdaten 310 an den Datenträger 10, 11, 12, 13 zu übertragen.
Entsprechende Komplettierungskommandos 320 werden also ebenso erzeugt und zusammen mit dem Komplettierungsdatensatz 310 in Schritt S6 zu einem Komplettierungsskript 300 aufbereitet. Dieses Komplettierungsskript 300 umfasst somit sowohl in den Datenträger 10, 11, 12, 13 einzubringende Komplettierungsdaten 310 als auch dafür erforderliche Kommandos 320, und zwar bereits in der Anordnung und Reihenfolge, dass die Kommandos 320 lediglich wie durch das Skript 300 vorgegeben durch die Hilfsapplikation 210 der Komplettierungsvorrichtung 200 ausgeführt werden müssen. Das Komplettierungsskript 300 kann in einer beliebigen, geeigneten Skriptsprache erzeugt werden, beispielsweise mittels Groovy. Sind der Datenträger 10, 11, 12, 13 und das Sichermodul 100 als Chipkarten gemäß ISO 7816 ausgebil- det, so werden die Komplettierungskommandos 320 zur Kommunikation mit diesen beiden Elementen in Form von APDUs („application protocol data unit") bereitgestellt. Dabei können bekannte Standardkommandos, aber auch neu entwickelte, proprietäre Kommandos zum Einsatz kommen. In Schritt S7 wird das erzeugte Komplettierungsskript 300 mit einem Übertragungsschlüssel key S verschlüsselt. Auf diese Weise wird es gegen Ausspähen oder Verändern beim der nachfolgenden Übertragung an die Komplettierungsvorrichtung (siehe Schritt Sil) geschützt, welche dann über ein nicht gesichertes Netzwerk, beispielsweise per e-Mail über das Internet, er- folgen kann.
In Schritt S8 wird ein Berechtigungsdatensatz 410 erzeugt. Dieser umfasst eine im Wesentlichen vollständige Spezifikation einer Komplettierung. Dieser Berechtigungsdatensatz 410 ist eindeutig dem Komplettierungsdatensatz 310, welcher in Schritt S5 erzeugt worden ist, zugeordnet. Eine solche Zuordnung erfolgt dadurch, dass sowohl das Berechtigungsdatenskript 400 (siehe Schritt S10) als auch das Komplettierungsskript 300 identische Namensbestandteile umfassen, über welche diese Skripte 300, 400 jeweils ein- deutig identifiziert, adressiert und zugeordnet werden können. Eine Zuordnung des Komplettierungsskripts 300 zu dem Berechtigungsdatensatz 410 kann weiterhin dadurch erfolgen, dass der Berechtigungsdatensatz 410 eine das Komplettierungsskript 300 spezifizierende Prüfziffer umfasst, beispielsweise einen Hash-Wert über das vollständige Komplettierungsskript 300. Auf diese Weise kann während des Verfahrens die Verwaltungsapplikation 110 auf dem Sicherheitsmodul 100 das dem Berechtigungsdatensatz 410 zugeordnete Komplettierungsskript 300 nicht lediglich als solches erkennen, sondern auch auf etwaige - unerwünschte -Veränderungen hin prüfen.
Der Berechtigungsdatensatz 410 kann, unter anderem, folgende Daten umfassen:
Eine eindeutige Kennung des Berechtigungsdatensatzes 410 selbst. Eine eindeutige Kennung des Komplettierungsdatensatzes 310.
Eine Hardware ID eines mittels des Komplettierungsdatensatzes 310 komplettierbaren Datenträgers 10, 11, 12, 13. Eine solche Hardware ID ist für baugleiche Datenträger 10, 11, 12, 13 einer Charge in der Regel gleich. Diese Hardware ID nutzt die Verwaltungsapplikation 110 auf dem Sicherheitsmodul 100 während des späteren Verlaufs des Komplettierungsverfahrens um zu prüfen, ob ein vorliegender Datenträger 10, 11, 12, 13 mit einem vorliegenden Komplettierungsdatensatz 310 komplettiert werden darf, d.h. der Berechtigungsdatensatz 410 legt nicht nur den zulässigen Komplettierungsdatensatz 310 fest, sondern auch den Typ von Datenträger 10, 11, 12, 13, der damit komplettiert werden darf. Verschiedene kryptographische Schlüssel zur Authentisierung gegenüber und Herstellung eines sicheren Kommunikationskanals zu einem zu komplettierenden Datenträger 10, 11, 12, 3. Mittels dieser Schlüssel spezifiziert der Berechtigungsdatensatz 410 - indirekt - einen zu komplettierenden Datenträger 10, 11, 12, 13, denn falls diese Schlüssel nicht zu einem zu komplettierende Datenträger 10, 11, 12, 13 passen, wird ein beabsichtigter Komplettierungs vor gang bereits daran scheitern, dass eine Authentisierung gegenüber dem Datenträger 10, 11, 12, 13 nicht erfolgreich sein wird.
Eine Identifikationsnummer ID eines Sicherheitsmoduls 100, welches zur Komplettierung eines zu komplettierenden Datenträgers 10, 11, 12, 13 verwendet werden darf. Der Berechtigungsdatensatz 410 gibt also neben dem Komplettierungsdatensatz 310 und dem zu komplettierenden Datenträger 10, 11, 12, 13 weiterhin vor, wer diese Komplettierung durchführen darf: Lediglich die Stelle, die im Besitz eines mit der ID eindeutig gekennzeichneten Sicherheitsmoduls 100 ist.
Ein Ablaufdatum, welches angibt, wie lange der Berechtigungsdatensatz 410 gültig ist. Danach wird die Verwaltungsapplikation 110 auf dem Sicherheitsmodul 100 im Rahmen der Verwaltung der dort gespeicherten verschiedenen Berechtigungsdatensätze 410, 410', 410" den Berechtigungsdatensatz 410 sperren.
Eine Komplettierungsanzahl, welche vorgibt, wie oft eine durch die übrigen Parameter spezifizierte Komplettierung durchgeführt werden darf. Nach jeder erfolgreichen Komplettierung gemäß dem Berechtigungsdatensatz 410 wird die Komplettierungsanzahl, welche als Zähler vorgesehen sein kann, entsprechend vermindert. Erreicht dieser Zähler die Null, wird der Berechtigungsdatensatz 410 von der Verwaltungsapplikation 110 ebenfalls gesperrt. Eine - vorstehend bereits beschriebene - Prüfziffer über das Komplettierungsskript 300.
Einen Prüfwert, welcher eine zulässige Konfiguration eines zu komplettierenden Datenträgers 10, 11, 12, 13 eindeutig vorgibt. Lediglich dann, wenn der Datenträger 10, 11, 12, 13, nachdem der Komplettierungsdatensatz 310 eingebracht worden ist, gemäß dieser Konfigurationsvorgabe konfiguriert worden ist, gilt die Komplettierung als erfolgreich. Auch dieser Prüfwert kann als Hashwert ausgebildet sein. Angaben über zu sperrende Berechtigungsdatensätze. Auf dieser Wei- se wird es beispielsweise möglich, der Verwaltungsapplikation 110 auf dem Sicherheitsmodul 100 anzuzeigen, dass der vorliegende Berechtigungsdatensatz 410 einen früheren Berechtigungsdatensatz, welcher bereits auf dem Sicherheitsmodul 100 vorliegt, ersetzt. Der frühere Berechtigungsdatensatz, welcher beispielsweise eine Komplet- tierung gemäß einer Vorgängerversion eines aktuellen Komplettierungsskripts 300 spezifiziert hat, wird dann von der Verwaltungsapplikation 110 im Rahmen der Verwaltung der verschiedenen Berechtigungsdatensätze 410, 410', 410" auf dem Sicherheitsmodul 100 gesperrt.
Die vorstehende, nicht abschließende Aufzählung macht deutlich, dass mittels Vorgaben in dem Berechtigungsdatensatz 4 0 vom Hersteller der zu komplettierenden Datenträger 10, 11, 12, 13 sämtliche Aspekte einer an eine externe Stelle delegierten Komplettierung eindeutig festgelegt und bestimmt werden können. Auf diese Weise hat der Hersteller weiterhin volle Kontrolle über erfolgende Komplettierung der ausgegebenen Datenträger 10, 11, 12, 13.
In Schritt S9 wird der Berechtigungsdatensatz 410 mittels eines weiteren Schlüssels keyBD verschlüsselt und damit gegen Ausspähen und Verändern bei der anschließenden Übertragung (siehe Schritt Sil) an die Komplettierungsvorrichtung 200 gesichert. Ein Entschlüsseln des Berechtigungsdatensatzes 410 erfolgt erst direkt auf dem Sicherheitsmodul 100 durch die Verwaltungsapplikation 110. Diese wurde dazu bei der Personalisierung (vgl. TS13) mit dem entsprechenden Schlüssel ausgestattet.
Analog zu Schritt S6 mit Bezug auf die Komplettierungsdaten 310 wird in Schritt S10 ein Berechtigungsdatenskript 400 erzeugt. Dieses umfasst neben dem verschlüsselten Berechtigungsdatensatz 410 zumindest ein Kommando 420, welches, wenn durch die Hilfsapplikation 210 auf der Komplettierungsvorrichtung 200 ausgeführt, direkt dazu führt, dass der verschlüsselte Berechtigungsdatensatz 410 an das Sicherheitsmodul 100 übertragen wird. Eine separate Verschlüsselung des Berechtigungsdatenskripts 400 selbst ist in der Regel nicht notwendig, da das zumindest eine Kommando 420 kein sicher- heitsrelevantes Datum darstellt. Im Gegensatz dazu gelten die Kommandos 320 des Komplettierungsskripts 300 als sicherheitsrelevant und werden, zusammen mit den ebenfalls zu sichernden Komplettierungsdaten 310, verschlüsselt (vgl S7). Wie bereits mehrfach angedeutet, werden das verschlüsselte Komplettierungsskript 300 sowie das Berechtigungsdatenskript 400 mit dem verschlüsselten Berechtigungsdatensatz 410 anschließend in Schritt Sil an die Komplettierungsvorrichtung 200 übertragen, beispielsweise über das Internet. Dort kann dann der eigentliche Komplettierungsvorgang beginnen, welcher mit Bezug auf die Figuren 4 bis 8 im Folgenden beschrieben wird. Jeweils bei Vorliegen eines neuen oder aktualisierten Komplettierungsdatensatzes 310 können die Schritte S5 bis Sil in der beschriebenen Weise wiederholt werden. Sind ein zu komplettierender Datenträger 10, 11, 12, 13 über die Schnittstelle 220 sowie das Sicherheitsmodul 110 über die Schnittstelle 230 mit der Kom- plettierungsvorrichtung 200 verbunden, wird der eigentliche Komplettie- rungsprozess eingeleitet, wie es mit Bezug auf Fig. 4 beschrieben ist.
Um den nachfolgenden Komplettierungsvorgang, beim dem auch sicherheitsrelevante Daten übertragen werden, kryptographisch absichern zu können, sind gewisse Sicherheitsmaßnahmen notwendig. Das Komplettierungsverfahren wird in Schritt S12 dadurch fortgesetzt, dass sich die Hilfsapplika- tion 210 gegenüber der Verwaltungsapplikation 110 auf dem Sicherheitsmodul 100 authentisiert. Dies geschieht mittels eines Passwortes, welches dem Nutzer der Komplettierungsvorrichtung 200 bekannt ist.
Anschließend wird in Schritt S13 zwischen der Hilfsapplikation 210 und der Verwaltungsapplikation 110 ein sicherer Kanal aufgebaut. Die dazu notwendigen geheimen Schlüssel werden von der Hilfsapplikation 210 in Teilschritt TS131 aus dem Passwort abgeleitet, ohne dass der Nutzer der Komplettierungsvorrichtung 200 in den Besitz dieser Schlüssel gelangt - wodurch gleichzeitig sichergestellt wird, dass dieser das Sicherheitsmodul 100 und die darauf laufenden Verwaltungsapplikation 110 stets nur in Verbindung mit der Hilfsapplikation 210, nicht jedoch separat davon, verwenden kann. Mittels der geheimen Schlüssel wird schließlich in Teilschritt TS132 die gesicherte Kommunikationsverbindung zu dem Sicherheitsmodul 100 hergestellt. In der wie vorstehend beschrieben gesicherten Umgebung kann nun, wie in Fig. 5 gezeigt, in Schritt S14 eine Übertragung des Berechtigungsdatensatzes 410 an das Sicherheitsmodul 100 stattfinden. Dazu führt die Hilfsapplikation 210 auf der Komplettierungsvorrichtung 200 das Berechtigungsdatenskript 400 aus. Auf dem Sicherheitsmodul 100 wird der Berechtigungsdatensatz 410 von der Verwaltungsapplikation 110 mittels des Schlüssels ke eD in Schritt S15 entschlüsselt. Anschließend wird in Schritt S16 geprüft, ob die in dem Berechti- gungsdatensatz 410 vorgegebene Sicherheitsmodul-ID mit der ID des Sicherheitsmoduls 100 übereinstimmt. Nur wenn dies der Fall ist, wird der Berechtigungsdatensatz 410 in Schritt S18 in dem Sicherheitsmodul 100 gespeichert. Andernfalls wird der Komplettierungsprozess in Schritt S17 abgebrochen. In Schritt S19 entschlüsselt die Hilfsapplikation 210 dann auf der Komplettierungsvorrichtung 200 das empfangende Komplettierungsskript 300.
Erst wenn der Berechtigungsdatensatz 410 auf dem Sicherheitsmodul 100 gespeichert ist, kann der Komplettierungsprozess dadurch fortgesetzt wer- den, dass das - mittlerweile entschlüsselte - Komplettierungsskript 300 durch die Hilfsapplikation 210 ausgeführt wird, wie dies in Schritt S20 angedeutet ist.
Das Ausführen des Komplettierungsskripts 300 durch die Hilfsapplikation 210 wird dadurch initiiert, dass ein Nutzer der Komplettierungsvorrichtung 200 den dem Komplettierungsskript 300 zugeordneten Berechtigungsdatensatz 410, welcher auf dem Sicherheitsmodul 100, neben eventuell bereits dort gespeicherten anderen Berechtigungsdatensätzen 410', 410", gespeichert ist, auswählt. D.h. lediglich dann, wenn auf dem Sicherheitsmodul 100 ein Be- rechtigungsdatensatz 410, 10', 410" gespeichert ist, welcher einem auf der Komplettierungsvorrichtung 200 vorliegenden Komplettierungsskript 300, 300', 300" eindeutig zugeordnet ist, kann das entsprechende Komplettierungsskript 300, 300', 300" durch die Hilfsapplikation 210 ausgeführt werden. Auch an dieser Stelle wird deutlich, dass das gesamte Komplettierungs- verfahren nur im Zusammenspiel der beschriebenen Komponenten durchführbar ist.
Mit Bezug auf die Figuren 6 und 7 werden nun einzelne Schritte beschrieben, welche durch Kommandos des ausgeführten Komplettierungsskripts 300 bewirkt werden. Wenn im Folgenden eine Formulierung suggeriert, dass die Hilfsapplikation 210 von sich aus tätig wird, beispielsweise der Art„die Hilfsapplikation 210 fordert an", so bedeutet dies, dass die entsprechende Anforderung durch ein Kommando des Komplettierungsskripts 300 dadurch hervorgerufen worden ist, dass die Hilfsapplikation 210 das Komplettierungsskript 300 gestartet hat und ausführt.
In Schritt S21 wird in einer der eigentlichen Komplettierung des Datenträgers 10, 11, 12, 13 vorgelagerten Phase der zu komplettierende Datenträger 10, 11, 12, 13, falls nicht bereits geschehen, individualisiert. Dieser Schritt ist notwendig, um zu verhindern, dass identische Datenträger 10, 11, 12, 13 einer Charge mittels eines korrekten„aufgezeichneten" Komplettierungsvorgangs, der für einen Datenträger 10 der Charge durchgeführt worden ist, ebenfalls - identisch - komplettiert werden. Dazu ist zu bemerken, dass Da- tenträger derselben Charge eine identische Chargennummer aufweisen. Die Chargennummer eines Datenträgers wird verwendet, um einen zur Authentisierung gegenüber dem Datenträger erforderlichen Authentisierungswert AV zu berechnen. Demzufolge ist für die Datenträger einer Charge - so lange diese die jeweils gleiche Chargennummer besitzen - derselbe AV Wert zur Authentisierung ausreichend. Dadurch wird es möglich, einen aufgezeichneten Komplettierungsvorgang, inklusive Authentisierung, wiederholt anzuwenden. Dies soll aber im Falle der delegierten Komplettierung verhindert werden. In Teilschritt TS211 prüft das Komplettierungsskript 300, ob ein betreffender Datenträger 10, 11, 12, 13 bereits individualisiert worden ist, beispielsweise, weil dieser Datenträger 10, 11, 12, 13 bereits in einer früheren Produktionsphase einmal personalisiert worden ist. Falls nicht, so wird der Datenträger 10, 11, 12, 13 dadurch individualisiert, dass die in dem Datenträger 10, 11, 12, 13 gespeicherte Chargennummer durch eine datenträgerin- dividuelle Seriennummer ersetzt wird, wie dies in Schritt TS212 angedeutet ist.
Zur Bereitstellung einer gesicherten Umgebung zwischen der Hilfsapplikation 210 und dem Datenträger 10, 11, 12, 13 wird, wie in Fig. 7 dargestellt, in ähnlicher Weise verfahren, wie vorstehend mit Bezug auf das Sicherheitsmodul 100 beschrieben (vgl. Fig. 4). In Schritt S22 authentisiert sich die Hilfsapplikation 210 gegenüber dem Datenträger 10, 11, 12, 13. Den dazu erforderlichen, datenträgerindividuellen Authentisierungswert AV fordert sie bei der Verwaltungsapplikation 110 auf dem Sicherheitsmodul 100 in Teilschritt TS 221 an. Basierend auf Vorgaben in dem Berechtigungsdatensatz 410 bestimmt die Verwaltungsapplikation 110 den AV und stellt diesen der Hilfsapplikation 210 in Teilschritt TS222 bereit, bevor sich die Hilfsapplikation 210 schließlich in Teilschritt TS223 mittels des erlangten AV bei dem Datenträger 10, 11, 12, 13 authentisiert.
Zur Herstellung eines gesicherten Kanals zwischen der Hilfsapplikation 210 und dem Datenträger 10, 11, 12, 13, welcher in Schritt S23 hergestellt wird, fordert die Hilfsapplikation 210 in Teilschritt TS231 die dazu erforderlichen, von einem auf dem Sicherheitsmodul 100 als Teil des Berechtigungsdaten- satzes 410 gespeicherten Datenträgerschlüssels abgeleiteten Schlüssel von der Verwaltungsapplikation 110 an. Diese bestimmt die entsprechenden Schlüssel unter Rückgriff auf den Berechtigungsdatensatz 410 und stellt sie der Hilfsapplikation 210 in Teilschritt TS232 bereit. Die sichere Kommunikationsverbindung zum Datenträger 10, 11, 12, 13 stellt die Hilfsapplikation 210 mittels dieser abgeleiteten Schlüssel in Teilschritt TS233 her. Schritt S23 ist optional, insbesondere da die im folgenden Schritt S24 übertragenen Komplettierungsdatensätze bereits - unabhängig von einer Verschlüsselung des Übertragungskanals - verschlüsselt sein können.
Nun sind sämtliche Vorbereitungen getroffen, um die eigentliche Komplettierung des Datenträgers 10, 11, 12, 13 durchzuführen, wie dies mit Bezug auf Fig. 8 beschrieben wird. In Schritt S24 wird der Komplettierungsdatensatz 310 mittels eines Kommandos des Komplettierungsskripts 300 an den Datenträger 10, 11, 12, 13 übertragen und dort, beispielsweise im EEPROM- Speicher, gespeichert. Gegebenenfalls wird dieser Speicher zuvor vorsorglich komplett gelöscht. Nicht in der Figur dargestellt ist, dass der Datenträger nach Schritt S24 vorzugsweise mittels eines Resetsignals neu gestartet (Warm Reset) wird und analog zu Schritt S22 eine Authentisierung durchgeführt wird, die nun jedoch gegenüber dem komplettierten (J AVA-Card-) Betriebssystems des Datenträgers erfolgt. Anschließend wird das mittels der Komplettierungsdaten 310 aktualisierte und vervollständigte Betriebssystem des Datenträgers 10, 11, 12, 13 in Schritt S25 konfiguriert. Abschließend wird in Schritt S26 diese Konfiguration anhand der Vorgaben in dem Berechtigungsdatensatz 410 überprüft. Dazu fordert die Hilfsapplikation 210 in Teilschritt TS261 von der Verwaltungsapplikation 110 auf dem Sicherheitsmodul 100 einen entsprechenden Konfigurationsprüfwert an. Die Verwaltungsapplikation 110 erstellt diesen Prüfwert nach der Spezifizierung in dem Berechtigungsdatensatz 410 und stellt der Hilfsapplikation 210 in Teilschritt TS262 den entsprechenden Wert bereit. Bei der Berechnung des Konfigurationsprüfwerts können datenträgerindividuelle Datenbestanteile eingehen. Die Hilfsapplikation 210 überträgt den erhaltenen Konfigurationsprüfwert in Teilschritt TS263 an den Datenträger 10, 11, 12, 13. Dort wird der empfangene Konfigurationsprüfwert mit einem datenträgerintern über die aktuelle Konfiguration berechneten Prüfwert in den Teilschritten TS264, TS265 verglichen. Lediglich dann, wenn die beiden Prüfwerte übereinstimmen, der Datenträger 10, 11, 12, 13 also gemäß den Vorgaben in dem Berech- tigungsdatensatz 410 konfiguriert worden ist, wird die entsprechende Konfiguration in dem Datenträger 10, 11, 12, 13 in Teilschritt TS267 freigegeben und der die zulässige Komplettierungsanzahl betreffende Zähler im Berechtigungsdatensatz 410 wird von der Verwaltungsapplikation 110 um eins vermindert. Anderenfalls wird der Komplettierungsvorgang erfolglos ab- gebrochen. Die Freigabe der Komplettierung bedeutet, dass der komplettierte Datenträger 10, 11, 12, 13 für weitere Produktionsschritte, beispielsweise eine Initialisierung oder eine nachfolgende Personalisierung auf einen zukünftigen Nutzer, bereitsteht.

Claims

P a t e n t a n s p r ü c h e 1. Verfahren zur Komplettierung zumindest eines mit einer Komplettierungsvorrichtung verbundenen portablen Datenträgers (10; 11; 12; 13) durch Einbringen eines auf der Komplettierungsvorrichtung (200) vorliegenden Komplettierungsdatensatzes (310; 310'; 310") in den zumindest einen Datenträger (10; 11; 12; 13), dadurch gekennzeichnet, dass
auf einem mit der Komplettierungsvorrichtung (200) verbundenen Sicherheitsmodul (100) verschiedene Berechtigungsdatensätze (410; 410'; 410") sowie eine Verwaltungsapplikation (110) zum Verwalten der verschiedenen Berechtigungsdatensätze (410; 410'; 410") bereitgestellt werden,
wobei jeder der Berechtigungsdatensätze (410; 410'; 410") jeweils ge- nau eine Komplettierung spezifiziert und jeweils genau einem Komplettierungsdatensatz (310, 310', 310") zugeordnet ist und
wobei die Verwaltungsapplikation (110) die Komplettierung des zumindest einen Datenträgers (10; 11; 12; 13) gemäß der Spezifizierung in einem ausgewählten Berechtigungsdatensatz (410) überwacht.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der ausgewählte Berechtigungsdatensatz (410) den einzubringenden Komplettierungsdatensatz (310) sowie Komplettierungskommandos (320) zum Einbringen des Komplettierungsdatensatz (310) in den zumindest einen Datenträger (10; 11; 12; 13) eindeutig spezifiziert, indem dem ausgewählten Berechtigungsdatensatz (410) eindeutig ein auf der Komplettierungsvorrichtung (200) bereitgestelltes Komplettierungsskript (300) zugeordnet wird, welches den Komplettierungsdatensatz (310) sowie die Komplettierungskommandos (320) vorgibt.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der ausgewählte Berechtigungsdatensatz (410) das Sicherheitsmodul (100) spezifiziert und auf dem Sicherheitsmodul (100) nur dann bereitgestellt wird, wenn das Sicherheitsmodul (100) mit der Spezifizierung in dem Berechtigungsdatensatz (410) übereinstimmt.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der ausgewählte Berechtigungsdatensatz (410) den zumindest einen Datenträger (10; 11; 12; 13) spezifiziert und die Komplettierung nur dann durchgeführt wird, wenn der zumindest eine Datenträger (10; 11; 12; 13) mit der Spezifizierung in dem Berechtigungsdatensatz (410) übereinstimmt.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeich- net, dass der ausgewählte Berechtigungsdatensatz (410) die Maximalzahl der mit dem dem Berechtigungsdatensatz (410) zugeordneten Komplettierungsdatensatz (310) zu komplettierenden Datenträger (10; 11; 12; 13) und/oder den Zeitraum, innerhalb dessen diese Komplettierung stattfinden kann, spezifiziert, und die Komplettierung nur durchgeführt wird, wenn die spezifi- zierte Maximalzahl noch nicht erreicht ist und/ oder der spezifizierte Zeitraum gegeben ist.
6. Verfahren nach einem der Ansprüche 1 bis 5 mit Anspruch 2, gekennzeichnet durch eine auf der Komplettierungsvorrichtung (200) ausführbare Hilfsapplikation (210) sowie die Schritte:
Übertragen (Sil) eines den ausgewählten Berechtigungsdatensatz (410) umfassenden Berechtigungsdatenskripts (400) sowie des Komplettierungsskripts (300) an die Komplettierungsvorrichtung (200); Übertragen (S14) des Berechtigungsdatensatzes (410) von der Komplettierungsvorrichtung (200) an das Sicherheitsmodul (100) durch Ausführen des Berechtigungsdatenskripts (400) mittels der Hilfsapplikation (210);
- Einbringen (S24) des Komplettierungsdatensatzes (310) von der Komplettierungsvorrichtung (200) in den zumindest einen Datenträger (10; 11; 12; 13) durch Ausführen des Komplettierungsskripts (300) mittels der Hilfsapplikation (210).
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass das Komplettierungsskript (300) und der ausgewählte Berechtigungsdatensatz (410) vor dem Übertragen an die Komplettierungsvorrichtung (200) verschlüsselt (S7; S9) werden.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass das Komplettierungsskript (300) vor dem Ausführen mittels der Hilfsapplikation (200) von der Hilfsapplikation entschlüsselt (S1 ) wird.
9. Verfahren nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass der ausgewählte Berechtigungsdatensatz (410) nach dem Übertragen an das Sicherheitsmodul (100) durch die Verwaltungsapplikation (110) entschlüsselt (S15) wird.
10. Verfahren nach einem der Ansprüche 6 bis 9, dadurch gekennzeich- net, dass sich die Hilfsapplikation (210) gegenüber dem Sicherheitsmodul
(100) und dem zumindest einen Datenträger (10; 11; 12; 13) authentisiert (S12; S22) und eine Datenkommunikation von der Komplettierungsvorrichtung (200) zu dem Sicherheitsmodul (100) und/oder dem Datenträger (10; 11; 12; 13) verschlüsselt durchgeführt wird.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass die Verwaltungsapplikation (110) eine Konfiguration der Komplettierung des Datenträgers (10; 11; 12; 13) anhand von Konfigurationsvorgaben in dem ausgewählten Berechtigungsdatensatz (410) vorgibt (S26).
12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass das Sicherheitsmodul (100) vor dem Bereistellen personalisiert wird (TS12).
13. Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass der zumindest eine Datenträger (10; 11; 12; 13) vor dem Einbringen des Komplettierungsdatensatzes (310) individualisiert (S21) wird.
14. Sicherheitsmodul (100) zum Überwachen eines Verfahrens zur Komplettierung zumindest eines portablen Datenträgers (10; 11; 12; 13) durch Einbringen eines auf einer mit dem Sicherheitsmodul (100) verbindbaren Komplettierungsvorrichtung (200) vorliegenden Komplettierungsdatensatzes (310) in den zumindest einen Datenträger (10; 11; 12; 13), dadurch gekenn- zeichnet, dass
das Sicherheitsmodul (100) eingerichtet ist, verschiedene Berechtigungsdatensätze (410; 410', 410") aufzunehmen, und eine Verwaltungsapplikation (110) umfasst,
wobei jeder der Berechtigungsdatensätze (410; 410', 410") jeweils ge- nau eine Komplettierung spezifiziert und jeweils genau einem Komplettierungsdatensatz (310; 310'; 310") zugeordnet ist, und
wobei die Verwaltungsapplikation (110) eingerichtet ist, verschiedene Berechtigungsdatensätze (410; 410', 410") zu verwalten und die Komplettie- rung des zumindest einen Datenträgers (10; 11; 12; 13) gemäß der Spezifizierung in einem ausgewählten Berechtigungsdatensatz (410) zu überwachen.
15. Sicherheitsmodul (100) nach Anspruch 14, dadurch gekennzeichnet, dass die Verwaltungsapplikation (110) eingerichtet ist, die Komplettierung des zumindest einen Datenträgers (10; 11; 12; 13) gemäß einem Verfahren nach einem der Ansprüche 1 bis 13 zu überwachen.
16. System (1000) zur Komplettierung zumindest eines portablen Daten- trägers (10; 11; 12; 13), umfassend
- eine Komplettierungsvorrichtung (200) mit einer Hilfsapplikation
(210),
ein mit der Komplettierungsvorrichtung (200) verbundenes Sicherheitsmodul (100) mit einer Verwaltungsapplikation (110) nach einem der Ansprüche 14 oder 15,
zumindest einen mit der Komplettierungsvorrichtung (200) verbundenen, zu komplettierenden portablen Datenträger (10; 11; 12; 13), sowie
verschiedene Berechtigungsdatensätze (410; 410'; 410") und verschie- dene Komplettierungsskripte (300; 300', 300"), welche jeweils einen
Komplettierungsdatensatz (310; 310', 310") und Komplettierungskommandos (320; 320', 320") umfassen, wobei jeder der Berechtigungsdatensätze (410; 410'; 410") genau einem der Komplettierungsskripte (300; 300', 300") zugeordnet ist und genau eine Komplettie- rung spezifiziert,
wobei die Hilfsapplikation (210) eingerichtet ist, die verschiedenen Berechtigungsdatensätze (410; 410', 410") in das Sicherheitsmodul (100) einzubringen und durch Ausführen eines ausgewählten Komplettierungsskripts (300) den entsprechenden Komplettierungsdatensatz (410) in den Datenträger (10; 11; 12; 13) einzubringen, und
wobei die Verwaltungsapplikation (110) eingerichtet ist, die Komplettierung gemäß der Spezifizierung in dem dem Komplettierungsskript (300) zugeordneten, ausgewählten Berechtigungsdatensatz (410) zu überwachen.
EP11703594A 2010-02-05 2011-02-03 Komplettierung portabler datenträger Ceased EP2531983A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102010006987A DE102010006987A1 (de) 2010-02-05 2010-02-05 Komplettierung portabler Datenträger
PCT/EP2011/000494 WO2011095337A1 (de) 2010-02-05 2011-02-03 Komplettierung portabler datenträger

Publications (1)

Publication Number Publication Date
EP2531983A1 true EP2531983A1 (de) 2012-12-12

Family

ID=43821732

Family Applications (1)

Application Number Title Priority Date Filing Date
EP11703594A Ceased EP2531983A1 (de) 2010-02-05 2011-02-03 Komplettierung portabler datenträger

Country Status (5)

Country Link
US (1) US9076280B2 (de)
EP (1) EP2531983A1 (de)
CN (1) CN102754131B (de)
DE (1) DE102010006987A1 (de)
WO (1) WO2011095337A1 (de)

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1242094A (zh) * 1996-12-23 2000-01-19 德意志银行股份公司 芯片卡和对于运用芯片卡的过程
DE19720431A1 (de) * 1997-05-15 1998-11-19 Beta Research Ges Fuer Entwick Vorrichtung und Verfahren zur Personalisierung von Chipkarten
US6367011B1 (en) * 1997-10-14 2002-04-02 Visa International Service Association Personalization of smart cards
TW527604B (en) * 1998-10-05 2003-04-11 Toshiba Corp A memory systems
US6609199B1 (en) * 1998-10-26 2003-08-19 Microsoft Corporation Method and apparatus for authenticating an open system application to a portable IC device
US7036738B1 (en) * 1999-05-03 2006-05-02 Microsoft Corporation PCMCIA-compliant smart card secured memory assembly for porting user profiles and documents
AU2001222074A1 (en) 2000-01-19 2001-07-31 Softcard Solutions Limited Programming data carriers
CA2405477A1 (en) 2000-04-11 2001-10-18 Visa International Service Association Integrated production of smart cards
FR2810139B1 (fr) * 2000-06-08 2002-08-23 Bull Cp8 Procede de securisation de la phase de pre-initialisation d'un systeme embarque a puce electronique, notamment d'une carte a puce, et systeme embarque mettant en oeuvre le procede
DE10107527A1 (de) * 2001-02-17 2002-09-05 Deutscher Genossenschafts Verl Verfahren zur eindeutigen Zuordnung eines digitalen, extern erzeugten kartenindividuellen Datums zu einer Chipkarte
EP1798660A3 (de) * 2002-09-11 2007-09-12 Koninklijke Philips Electronics N.V. Verfahren mit Kollisionsvermeidung zum Lesen mehrerer kontaktloser Datenträger
WO2004025896A1 (en) * 2002-09-16 2004-03-25 Telefonaktiebolaget Lm Ericsson (Publ) Loading data onto an electronic device
DE10340181A1 (de) 2003-09-01 2005-03-24 Giesecke & Devrient Gmbh Verfahren zur kryptographischen Absicherung der Kommunikation mit einem tragbaren Datenträger
JP4070708B2 (ja) * 2003-11-14 2008-04-02 株式会社リコー セキュリティ確保支援プログラム及びそのプログラムを実行するサーバ装置並びにそのプログラムを記憶した記憶媒体
CN1954345B (zh) * 2004-05-28 2012-11-21 国际商业机器公司 智能卡数据事务系统以及用于提供存储和传输安全的方法
US20050269401A1 (en) * 2004-06-03 2005-12-08 Tyfone, Inc. System and method for securing financial transactions
FR2873467A1 (fr) 2004-07-26 2006-01-27 Proton World Internatinal Nv Enregistrement d'une cle dans un circuit integre
DE102005020313A1 (de) 2005-05-02 2006-11-16 Giesecke & Devrient Gmbh Vorrichtung und Verfahren zur Erzeugung von Daten für eine Initialisierung von Sicherheitsdatenträgern
US8261091B2 (en) * 2006-12-21 2012-09-04 Spansion Llc Solid-state memory-based generation and handling of security authentication tokens
US8732846B2 (en) * 2007-08-15 2014-05-20 Facebook, Inc. Platform for providing a social context to software applications
EP2063400A1 (de) * 2007-11-23 2009-05-27 Gemalto SA Virtuelles Sicherheitszugangsmodul

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2011095337A1 *

Also Published As

Publication number Publication date
DE102010006987A1 (de) 2011-08-11
CN102754131B (zh) 2015-07-08
CN102754131A (zh) 2012-10-24
US9076280B2 (en) 2015-07-07
US20120311681A1 (en) 2012-12-06
WO2011095337A1 (de) 2011-08-11

Similar Documents

Publication Publication Date Title
DE102012110499B4 (de) Sicherheitszugangsverfahren für elektronische Automobil-Steuergeräte
DE60308990T2 (de) Schutz eines gerätes gegen unerwünschte verwendung in einem sicheren umfeld
EP2289225B1 (de) Verfahren zum personalisieren eines sicherheitselements eines mobilen endgeräts
DE102010027586B4 (de) Verfahren zum kryptographischen Schutz einer Applikation
DE102007011309B4 (de) Verfahren zur authentisierten Übermittlung eines personalisierten Datensatzes oder Programms an ein Hardware-Sicherheitsmodul, insbesondere einer Frankiermaschine
DE102013013179A1 (de) Verfahren zum Betreiben eines Sicherheitselements
EP2689401B1 (de) Verfahren zum betreiben einer geldkassette mit kundenspezifischen schlüsseln
EP1073019A2 (de) Verfahren und Vorrichtung zur Übertragung von Daten auf SmartCards
EP2272199A1 (de) Verteilte datenspeicherungseinrichtung
EP1784756B1 (de) Verfahren und sicherheitssystem zur sicheren und eindeutigen kodierung eines sicherheitsmoduls
DE3705736A1 (de) Verfahren zum sichern von programmen und zur integritaetskontrolle gesicherter programme
DE10218795B4 (de) Verfahren zum Herstellen eines elektronischen Sicherheitsmoduls
EP1801724B1 (de) Verfahren und Anordnung zum Bereitstellen sicherheitsrelevanter Dienste durch ein Sicherheitsmodul einer Frankiermaschine
EP3407242A1 (de) Personalisieren eines halbleiterelements
EP2524333B1 (de) Verfahren zum bereitstellen eines sicheren zählers auf einem endgerät
DE102018005284A1 (de) Chip-Personalisierung eines eingebetteten Systems durch einen Dritten
WO2011095337A1 (de) Komplettierung portabler datenträger
WO2017108192A1 (de) Validierung und ausführung von provisionierungsdaten auf appliances
DE10218835A1 (de) Verfahren zum Herstellen eines elektronischen Sicherheitsmoduls
DE102008047639A1 (de) Verfahren und Vorrichtung zum Zugriff auf ein maschinenlesbares Dokument
EP1634252A1 (de) Verfahren zum laden von tragbaren datenträgern mit daten
DE102004058020A1 (de) Verfahren zur Personalisierung von Chipkarten
DE102014210434B4 (de) Verfahren und System zur Herstellung einer gesicherten Kommunikationsverbindung zwischen einer ersten und zweiten Vorrichtung
WO2003088053A2 (de) Programmsicherungsverfahren
EP3329415A1 (de) Chipkarte mit hauptapplikation und persistenzapplikation

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: 20120905

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20141211

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GMBH

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20181112