EP4511783A1 - Verfahren und system zur personalisierung eines sicheren elements - Google Patents

Verfahren und system zur personalisierung eines sicheren elements

Info

Publication number
EP4511783A1
EP4511783A1 EP23722815.0A EP23722815A EP4511783A1 EP 4511783 A1 EP4511783 A1 EP 4511783A1 EP 23722815 A EP23722815 A EP 23722815A EP 4511783 A1 EP4511783 A1 EP 4511783A1
Authority
EP
European Patent Office
Prior art keywords
personalization
secure element
data
personalized
configuration command
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.)
Pending
Application number
EP23722815.0A
Other languages
English (en)
French (fr)
Inventor
Monika Eckardt
Claus Jarnik
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+Devrient Mobile Security Germany GmbH
Original Assignee
Giesecke+Devrient Mobile Security Germany 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
Priority claimed from DE102023110087.4A external-priority patent/DE102023110087A1/de
Application filed by Giesecke+Devrient Mobile Security Germany GmbH filed Critical Giesecke+Devrient Mobile Security Germany GmbH
Publication of EP4511783A1 publication Critical patent/EP4511783A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3226—Use of secure elements separate from M-devices
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/343—Cards including a counter
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q20/3558—Preliminary personalisation for transfer to user
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/077—Constructional details, e.g. mounting of circuits in the carrier
    • G06K19/07716—Constructional details, e.g. mounting of circuits in the carrier the record carrier comprising means for customization, e.g. being arranged for personalization in batch
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element

Definitions

  • the invention relates to a method and a system for the computer-aided personalization of a secure element onto which a memory image is loaded, in which an operating system of the secure element is integrated.
  • UICC Universal Integrated Chip Card
  • eUICC embedded UICC
  • iUICC Integrated eUICC
  • SIM Secure Element
  • a memory image is loaded onto the secure element. This process is carried out, for example, by the manufacturer of the secure element. Data that is individually intended for the secure element is then written into a special data area on the secure element. This step can also be carried out, for example, by the manufacturer of the secure element. This is followed by the personalization explained below.
  • the data unique to the secure element may include sensitive data such as keys, trusted root certificates, PINs, and the like. Such data is therefore non-public and only accessible to a limited group of people. Furthermore, the individual data can also be non-confidential (ie public) data, such as a Identification of the secure element, public certificates and the like. Sensitive data can be personalized separately from non-confidential data, for example during the initial startup of a secure element after the sensitive data has been loaded onto the secure element. This personalization can take place, for example, at the manufacturer of the secure element or at the manufacturer of the end device into which the secure element is to be integrated. Sensitive individual data is usually personalized as part of a secure handshake procedure. This process is usually carried out by the manufacturer of the device.
  • EP 1 622 098 A1 describes a concept of distributed personalization of a security element.
  • a first command puts the security element into a state in which only a second command is accepted, which enables secure personalization.
  • the personalization itself is done using a third command.
  • EP 2289225 B1 discloses a method for personalizing a security element of a mobile terminal, which also uses distributed personalization. A method is described in which the production of the security element and the introduction of the operating system are carried out in one location and the personalization of the security element in another, secure location. What is suggested here is the final personalization of the security element when a user uses the device for the first time.
  • the method according to the invention for the computer-aided personalization of a secure element onto which a memory image into which an operating system of the secure element is integrated is loaded, one or more individual elements are stored in a special memory area of the secure element Records intended for the secure element are written.
  • the individual data sets contain card-specific data with which the secure element is personalized under the control of the operating system.
  • the method according to the invention is therefore based on a secure element that is pre-personalized in a manner known per se and onto which a memory image with an operating system for operating the secure element is loaded.
  • the loading or writing of one or more data sets intended individually for the secure element can also be done in a manner known per se.
  • the term a data record that is intended individually for the secure element is to be understood as meaning information that is clearly intended only for a single secure element, such as keys, certificates and the like.
  • the card-specific data is expediently provided in the form of a data block or a data record chain.
  • the data record chain can also contain data that is, for example, jointly unique for a specific series of secure elements, such as so-called batch global data.
  • a configuration command is used to personalize the secure element to determine an order in which the data records to be written are personalized.
  • Such a configuration command makes it possible to interrupt the step of introducing personalization data in a controlled manner and to continue it at a later point in time.
  • This can be used, for example, to divide production times between different locations. For example, general production can be carried out at one location while further personalization is carried out at an end customer. This reduces production times in a factory, for example at the manufacturer of the secure element.
  • the personalization can be divided into logical sequences, for example according to a required logic. For example, the introduction of essential information can be separated from the personalization of a boat profile.
  • Another possibility opened up by using a configuration command is to divide the sections of a personalization into different locations according to their confidentiality and security requirements.
  • a further advantage of the procedure according to the invention is that it makes it possible to carry out only partial personalization in order to be able to carry out updates before further personalization.
  • different components outside the secure element e.g. servers, may also be involved.
  • Such components are also referred to as offcard components.
  • These may optionally be provided in different environments, which may have certified access, uncertified access or HSM access.
  • different security mechanisms can be implemented.
  • the configuration command determines which data in one or more of the data sets should be personalized in a first step. After personalizing this data in the first step, further personalization is then interrupted. For example, it can be determined which data is personalized in the factory of the user of the secure element should. Further personalization can then be carried out at a later date.
  • the configuration command sets one or more breakpoints up to which the data record or data sets are personalized. This makes it possible to define the time of an interruption in the personalization process. In other words, it is determined up to which data record the personalization should be carried out and when the interruption should take place.
  • a further expedient embodiment provides that the continuation of the personalization is configured at a later point in time using the configuration command. According to one embodiment, this can be done by configuring a predetermined event using the configuration command, upon whose occurrence the personalization is continued. Such an event can be, for example, a restart (reset) or the achievement of a predetermined number of restarts of the secure element. When this event occurs, further personalization will then continue.
  • a predetermined event can be, for example, a restart (reset) or the achievement of a predetermined number of restarts of the secure element.
  • the configuration command is sent to the secure element at least one more time, whereby the personalization is continued at a later point in time.
  • This personalization approach also makes it possible to add additional parts of the data set in distributed steps.
  • the further, distributed steps can be carried out by receiving a further explicit configuration command depending on the occurrence of a predefined event.
  • the personalization of the data sets can be carried out at different times and at different locations, depending on the urgency.
  • important personalizations can be carried out immediately. Further personalization can be carried out later, e.g. by the customer of the device. This distributes the total time of personalization and thereby the production time for the manufacturer of the secure element.
  • the configuration command is sent to the secure element at least one more time, whereby the personalization is continued (after an interruption at a later time).
  • the configuration command can therefore be sent to the secure element once or multiple times.
  • the configuration command can be transmitted to the secure element in encrypted or unencrypted form.
  • the encryption and/or transmission can take place according to the procedures known from the prior art.
  • Events for continuing personalization can be configured using the configuration command. For example, a configuration is possible in which personalization continues with predefined data sets, e.g. data sets #2 to #3, after a restart of the secure element is carried out. Afterwards, with the next restart, the remaining data will be personalized.
  • predefined data sets e.g. data sets #2 to #3
  • the configuration command is sent to the secure element at least one more time.
  • a trigger command which is used in the prior art to initialize and start personalization, is, as before, only required once. This continues to support backward compatibility with existing systems; no further adjustments are required.
  • a further expedient embodiment provides that in the first step a firmware update key is personalized in one of the data sets. In a second step, a firmware update is then carried out. This provides the opportunity to perform a firmware update before fully personalizing the secure element.
  • the card-specific or confidential data can include the firmware update key, which is absolutely necessary for a later firmware update.
  • the proposed approach can eliminate these disadvantages.
  • By personalizing only the firmware update keys in the first step this allows the operating system to be updated immediately afterwards, including the code for further personalization. This allows new features to be added or personalized that were not yet known at the time of original development. In addition, errors that may occur during personalization can be resolved.
  • the invention relates to a system for computer-aided personalization of a secure element, onto which a memory image is loaded, into which an operating system of the secure element is integrated, the system for carrying out the personalization method according to the invention according to one or more preferred embodiments of this personalization method is set up.
  • the invention makes it possible to implement different levels of trust through controlled personalization.
  • the trust level of a unit involved in the personalization process outside of the secure element can be adjusted accordingly.
  • Different components such as production machines, integrated servers, can be involved. It is therefore possible, for example, to carry out part of the personalization of the firmware update keys at the manufacturer of the secure element and to store the next sensitive data in the Production facilities of a terminal device manufacturer in whose terminal devices the secure element is to be incorporated. It is also possible that the data records to be personalized are secured differently. Each production facility can then only decode its predetermined area.
  • the personalization process can be divided into several parts in order to distribute production times and production locations and/or to change and/or expand the personalization process.
  • 1 is a flowchart illustrating the configuration of distributed personalization of a secure element
  • FIG. 2 shows a flowchart in which a personalization that has already started is continued using an explicitly received configuration command
  • FIG. 3 shows a flowchart in which a continuation of a personalization that has already started takes place when a preconfigured event occurs
  • 4 is a flowchart illustrating distributed personalization of a secure element
  • 5 shows a data record chain with several data records to be personalized, which are secured with a uniform key
  • Fig. 6 shows a data record chain with several data records to be personalized, which are secured differently according to different personalization steps to be carried out.
  • the invention is described below using a secure element that is to be integrated into an end device, such as a mobile phone.
  • eUICC embedded Universal Integrated Chip Card
  • the starting point of the method is a secure element, not shown in the figures, to which an operating system is applied. This is typically done by the chip manufacturer of the secure element.
  • the operating system is integrated into a memory image ("image"), which also contains a so-called
  • card-specific data is written into a special memory area of the secure element.
  • This card-specific data can consist of confidential data (such as keys, trusted root certificates, Pins and the like) and non-confidential data (e.g. card IDs, public certificates).
  • the card-specific data is available as data sets DS (see Figures 5 and 6).
  • the card-specific data is expediently provided in the form of a data block or a data record chain, as indicated in Figures 5 and 6.
  • the data record chain can also contain data that is specific to a certain series of secure elements, for example.
  • the data block or the card-specific data can also be introduced, for example, by the chip manufacturer.
  • the card-specific data is subsequently personalized under the control of the operating system, triggered by a configuration command, i.e. they are made accessible to the operating system. For example, a key required for a function of the operating system, such as executing a firmware update, is written to a location in the memory area where the operating system expects and needs it.
  • the card-specific data can have different levels of confidentiality.
  • non-confidential data can be personalized separately from confidential data, for example after the secure element is first powered and as soon as data has been loaded. This is typically carried out by the manufacturer of the secure element or sometimes by a device manufacturer in whose terminal the secure element is incorporated.
  • the personalization of confidential data is typically carried out as part of a secure handshake procedure that uses authentication and key exchange. The personalization can take place at a later point in time, for example at the device manufacturer.
  • objects are created in the secure element according to the card-specific data.
  • creating the objects can take production time, although the objects are personalized with the corresponding card-specific data after they have been created.
  • the personalization can therefore be carried out at three different locations: a) at the manufacturer of the operating system of the secure element, where the memory image is inserted into the secure element, b) at the chip card manufacturer, where card-specific data is loaded, with optional personalization of non-confidential data can be done, and c) by the device manufacturer, where, if this has not already been done, non-confidential data will be personalized and finally confidential data will be personalized.
  • an order in which the data records DS are personalized can be determined by using a configuration command in the personalization of the secure element.
  • the configuration command does not contain any personalization data but only sets up the execution of the personalization, ie the provision of the data contained in the DS data sets. held individual data for the operating system under the control of the operating system. In particular, it determines how many data records DS are to be personalized or for which data record DS personalization should be interrupted.
  • the configuration command enables a controlled interruption and later continuation of the personalization.
  • card-specific data that is used as part of the personalization is divided into different data sets DS, as illustrated in Figures 5 and 6. All card-specific data for a secure element are expediently provided together in a data record chain together with any existing series-specific data.
  • the fifth data record DS includes, for example, an FWU key, the second data record DS a certificate A, the third data record DS an associated key A, the fourth data record a certificate B, the fifth data record DS an associated key B, the sixth data record DS a certificate C and the seventh data record DS has an associated key C.
  • A, B and C represent a production facility or a second manufacturer A, B or C.
  • the 6 shows the same seven data records DS of the data record chain, although these are secured with different keys K1 to K4.
  • the key Kl is used to secure the firmware update key.
  • the key K2 becomes security of the second and third data sets used.
  • the fourth and fifth data records are secured with the key K3 and the sixth and seventh data records are secured with the key K4.
  • the keys K2-K4 are each assigned to one of the production sites A, B, C. Each of these production sites can personalize a specific portion of data, but not beyond that. With this division it is possible to divide the personalization into different units and thus meet different security requirements.
  • the data sets DS are usually personalized in a defined order.
  • the configuration command used according to the invention makes it possible to determine which data sets DS should be personalized in a respective step. For example, it can be specified that in a first personalization step from the data record chain shown in FIG. 5, only the first data record that contains a key for a firmware update is personalized and further personalization is then interrupted. For example, it can be determined which data should be personalized at the device manufacturer's production site. Further personalization can then be carried out at a later date.
  • FIG. 1 shows a flowchart in which a configuration of the distributed personalization of the secure element, not shown, using the configuration command according to the invention is described. The flowchart shows how the initial configuration is carried out and how the personalization is then processed accordingly.
  • a command CSP is sent to the secure element.
  • the CSP command represents the configuration command.
  • a TSP command is sent to the secure element.
  • the TSP command represents a trigger signal known from the prior art that starts the personalization.
  • step S103 it is checked whether a configuration is set. If this is not the case (path “No”), complete personalization is carried out in step S104, as is known from the prior art, and the personalization then ends.
  • step S103 If a configuration is set in step S103 (path “Yes”), it is checked in step S105 whether another configuration is available. If this is not the case (path “No”), personalization ends. If a further configuration is present in step S105 (path “Yes”), it is checked in step S106 whether an implicit configuration should be carried out. This will be explained further below with reference to FIG. 3. Should an implicit configuration be carried out (path “Yes” ), an event for the further continuation of the personalization is configured in step S107. The procedure then ends. If no implicit configuration is to be carried out (path “No” in step S106), then in step S108 the personalization of the first data record DS of the data record chain that is still to be executed takes place and the method returns to step
  • Fig. 2 shows a flowchart in which a continuation of the configuration using explicit completion is shown.
  • the CSP command i.e. the configuration command
  • the TSP trigger command is not sent again when the configuration is continued.
  • step S202 it is checked whether a configuration is set or exists. If this is not the case (path “No”), further personalization is carried out in step S203. If a configuration is set in step S202 (path “Yes”), the further procedure corresponds to the procedure described in FIG. 1.
  • the completion or completion of the personalization can also be done implicitly.
  • a special event can be configured to continue personalization. For example, a restart of the secure element or the determination of a predetermined number of restarts can be defined. When this event occurs, personalization continues. With this variant it is also possible to configure several implicit personalization steps. For example, for each event only a part of the data record DS can be personalized and then an interruption can occur. When the next (preconfigured) event occurs, personalization will continue.
  • Fig. 3 shows a flowchart of the continuation of personalization as a result of an implicitly occurring event. In step S301 it is determined whether an implicit configuration exists. If this is not the case (path “No”), the method continues with step S307, in which the personalization follows a process known from the prior art. The personalization and the method then end.
  • step S301 If an implicit configuration is configured in step S301 (path "Yes"), then in step S302 it is checked whether a predefined event has been fulfilled. If this is not the case (path “No"), the method jumps again to step S307. If a preconfigured event is fulfilled in step S302 (path “Yes”), then in step S303 a check is made as to whether a data record DS is present. If this is not the case (path “No”), the method continues again with step S307 . If a data record DS is available (path "Yes”), the personalization of the data record DS takes place in step S304. In step S305 it is checked whether an implicit configuration is present.
  • Step S303 returns and it is checked again whether a data record is available. If the check in step S305 shows that an implicit configuration is present ("yes" path), an event is configured for further continuation. The method then continues to step S307.
  • the method described makes it possible to check, without further configuration commands, whether an implicit personalization has been configured and is pending during operation of a secure element, for example after a restart of the secure element. If the configured event is met, personalization continues.
  • Both the implicit completion and the explicit completion of personalization allow the personalization of the data sets to be carried out at different times and at different locations, depending on the urgency. Personalizations important for production can be carried out immediately. Further personalization can be carried out later with a customer. This distributes the overall personalization time and allows production time to be saved.
  • the procedure described above can be repeated by sending the CSP configuration command several times (once or multiple times). Depending on the application and security information, the CSP command can be transmitted unsecured or secured.
  • An interruption time can be defined using the CSP configuration command. It is defined up to which data record DS personalization should be carried out and when the interruption should take place. It is possible to configure additional implicit events to continue personalization. For example, it can be configured that personalization continues with data sets #2 to #3 after a restart. The remaining data can then be personalized with another restart. In this way, the order in which the data records DS of a data record chain are personalized is determined using the configuration command CSP. As shown in Fig. 4, it is possible to perform a firmware update before complete personalization. 4, in step S401, the configuration command CSP is transmitted to the secure element, the configuration being defined to personalize only the firmware update (FWU) key.
  • firmware update firmware update
  • step S402 the trigger command TSP, which is known from the prior art, is transmitted to the secure element.
  • the personalization of the firmware update keys is then carried out and the personalization process is then interrupted.
  • a firmware update can then be carried out immediately (step S403).
  • a firmware update can, for example, contain a bug fix and/or expansion.
  • the feature extension makes it possible to personalize loaded data sets that were not yet known at the time the secure element was originally developed.
  • the configuration command CSP is sent again to the secure element to initiate the remaining personalization (step S404).
  • the invention makes it possible to specifically enable firmware updates at an early stage, i.e. bug fixes or feature expansions can be carried out immediately after the firmware update keys have been personalized. The remaining personalization can then be carried out.
  • the personalization can be distributed across different production sites. Saving production times is possible.
  • the application or configuration of personalization can be divided based on different security requirements.
  • the Corresponding data sets must be provided with corresponding keys (see keys K1-K4 in Fig. 6).
  • Personalization of sensitive data can be divided according to security levels or use cases.
  • the continuation of a personalization that has begun can be controlled explicitly via another configuration command or implicitly through the previous configuration of certain events, e.g. after a certain number of restarts.

Landscapes

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

Abstract

Die Erfindung betrifft ein Verfahren zur rechnergestützten Personalisierung eines sicheren Elements, auf das ein Speicherabbild geladen ist, in das ein Betriebssystem des sicheren Elements integriert ist. Bei dem erfindungsgemäßen Verfahren werden in einen speziellen Speicherbereich des sicheren Elements ein oder mehrere, individuell für das sichere Element vorgesehene Datensätze (DS), geschrieben. Mit einem Konfigurationskommando (CSP) wird in der Personalisierung des sicheren Elements eine Reihenfolge festgelegt, in der die zu schreibenden Datensätze (DS) personalisiert werden.

Description

V e r f a hr e n u n d S y s t e m z u r P e r s o n a l i s i e r u n g e i n e s s i c h e r e n E l e m e nt s
Die Erfindung betrifft ein Verfahren und ein System zur rechner gestützten Personalisierung eines sicheren Elements, auf das ein Speicherabbild geladen ist, in dem ein Betriebssystem des sicheren Elements integriert ist.
Bei dem sicheren Element handelt es sich z.B. um ein Teilnehmeridentitäts- modul in Form einer Universal Integrated Chip Card (= UICC) zum Verwalten von Authentisierungsdaten für die Nutzung von Diensten eines Kommunikationsnetzes. In anderen Ausführungsformen ist das sichere Element eine embedded UICC (= eUICC), eine „Chipkarte", eine Integrated eUICC („iUICC"), ein Integrated Secure Element, ein embedded Secure Element, ein Secure Element, ein „SIM" oder eine Chipkarte. hn Rahmen der Produktion von sicheren Elementen, also etwa einer eUICC, werden diese mit individuellen Daten personalisiert. Dabei wird zunächst ein Speicherabbild (englisch: "image") auf das sichere Element geladen. Dieser Prozess wird z.B. beim Hersteller des sicheren Elements durchgeführt. Anschließend werden Daten, die individuell für das sichere Element vorgesehen sind, in einen speziellen Datenbereich auf dem sicheren Element geschrieben. Auch dieser Schritt kann beispielsweise beim Hersteller des sicheren Elements durchgeführt werden. Hieran schließt sich die weiter unten erläuterte Personalisierung an.
Die individuell für das sichere Element vorgesehenen Daten können vertrauliche Daten, wie z.B. Schlüssel, vertrauenswürdige Root-Zertifikate, PINs und dergleichen, umfassen. Solche Daten sind somit nicht-öffentlich und nur für einen eingeschränkten Personenkreis zugänglich. Ferner können die individuellen Daten auch nicht vertrauliche (d.h. öffentliche) Daten, wie z.B. eine Identifikation des sicheren Elements, öffentliche Zertifikate und dergleichen, umfassen. Vertrauliche Daten können getrennt von nicht vertraulichen Daten personalisiert werden, z.B. beim initialen Hochfahren eines sicheren Elements, nachdem die vertraulichen Daten auf das sichere Element geladen wurden. Diese Personalisierung kann z.B. beim Hersteller des sicheren Elements oder auch beim Hersteller des Endgeräts erfolgen, in welches das sichere Element zu integrieren ist. Vertrauliche individuelle Daten werden üblicherweise im Rahmen eines sicheren Handshake-Verfahrens personalisiert. Dieser Prozess wird in der Regel beim Hersteller des Endgeräts durchgeführt.
Bei der Personalisierung von sowohl vertraulichen als auch nicht vertraulichen Daten werden im sicheren Element Objekte allokiert bzw. angelegt, die dann später mit den individuellen Daten beschrieben werden. Nach Beschreiben mit den Daten ist die Personalisierung abgeschlossen.
Die EP 1 622 098 Al beschreibt ein Konzept einer verteilten Personalisierung eines Sicherheitselements. Dabei wird das Sicherheitselement durch ein erstes Kommando in einen Zustand versetzt, in dem nur noch ein zweites Kommando akzeptiert wird, durch das das sichere Personalisieren ermöglicht wird. Die Personalisierung selbst erfolgt mittels eines dritten Kommandos.
Die EP 2289225 Bl offenbart ein Verfahren zum Personalisieren eines Sicherheitselements eines mobilen Endgeräts, bei dem ebenfalls eine verteilte Personalisierung zur Anwendung kommt. Dabei wird ein Verfahren beschrieben, bei dem die Herstellung des Sicherheitselements und die Einbringung des Betriebssystems an einem Ort sowie die Personalisierung des Sicherheitselements an einem anderen, sicheren Ort, vorgenommen werden. Vorgeschlagen wird hierzu, die Endpersonalisierung des Sicherheitselements bei der erstmaligen Verwendung des Endgeräts durch einen Nutzer vorzunehmen.
Aus der DE 19939280 Al ist ein Verfahren zum Initialisieren und Personalisieren einer Chipkarte bekannt. Im Datenspeicher der Chipkarte werden Datenstrukturen angelegt, die eine eindeutige Zuordnung von Personalisierungsdaten zu einzelnen Chipkartenanwendungen ermöglichen. In einem vorbereitenden Initialisierungsschritt werden Anwendungsbeschreibungen und zugeordnete Personalisierungsbeschreibungen in einem Speicherblock eines zu personalisierenden Speicherbereichs angelegt. Bei der nachfolgenden Personalisierung werden zu den Anwendungen Personalisierungsdaten an die Chipkarte übertragen und mit Hilfe der Personalisierungsbeschreibungen den Anwendungen zugeordnet. Abgesehen von den Personalisierungsdaten müssen keine weiteren Zusatzdaten übertragen werden.
Es ist Aufgabe der Erfindung, die Flexibilität bei der Personalisierung eines sicheren Elements weiter zu verbessern.
Diese Aufgabe wird durch ein Verfahren zur rechnergestützten Personalisierung eines sicheren Elements gemäß den Merkmalen des Anspruchs 1 sowie ein System zur rechnergestützten Personalisierung eines sicheren Elements gemäß den Merkmalen des Patentanspruchs 11 gelöst. Vorteilhafte Ausgestaltungen ergeben sich aus den abhängigen Ansprüchen.
Bei dem erfindungsgemäßen Verfahren zur rechnergestützten Personalisierung eines sicheren Elements, auf das ein Speicherabbild in das ein Betriebssystem des sicheren Elements integriert ist, geladen ist, werden in einem speziellen Speicherbereich des sicheren Elements ein oder mehrere, individuelle für das sichere Element vorgesehene Datensätze geschrieben. Die individuellen Datensätze enthalten kartenindividuelle Daten, mit denen unter Steuerung des Betriebssystems die Personalisierung des sicheren Elementes erfolgt. Das erfindungsgemäße Verfahren geht somit von einem in an sich bekannter Weise vorpersonalisierten sicheren Element aus, auf das ein Speicherabbild mit einem Betriebssystem zum Betrieb des sicheren Elements geladen ist. Das Laden bzw. Schreiben eines oder mehrerer, individuell für das sichere Element vorgesehener Datensätze kann ebenfalls in an sich bekannter Weise erfolgen. Unter dem Begriff eines Datensatzes, der individuell für das sichere Element vorgesehen ist, ist eine Information zu verstehen, die eindeutig nur für ein einzelnes sicheres Element vorgesehen ist, wie z.B. Schlüssel, Zertifikate und dergleichen. Zweckmäßig werden die kartenindividuellen Daten in Form eines Datenblockes oder einer Datensatzkette bereitgestellt. Die Datensatzkette kann neben kartenindividuellen Daten auch Daten enthalten, die zum Beispiel für eine bestimmte Serie von sicheren Elementen gemeinsam eindeutig sind, etwa sogenannte Batch-globale Daten.
Im Rahmen des erfindungsgemäßen Verfahrens wird mit einem Konfigurationskommando in der Personalisierung des sicheren Elements eine Reihenfolge festgelegt, in der die zu schreibenden Datensätze personalisiert werden.
Die Nutzung eines solchen Konfigurationskommandos ermöglicht es, den Schritt des Einbringens von Personalisierungsdaten kontrolliert zu unterbrechen und zu einem späteren Zeitpunkt fortzusetzen. Dies kann beispielsweise dazu genutzt werden, um Produktionszeiten auf verschiedene Standorte aufzuteilen. Beispielsweise kann eine generelle Produktion an einem Standort durchgeführt werden, während weitere Personalisierungen bei einem Endkunden realisiert werden. Dies reduziert Produktionszeiten in einer Fabrik, z.B. beim Hersteller des sicheren Elements. Ebenso kann die Personalisierung in logische Sequenzen, z.B. entsprechend einer erforderlichen Logik, aufgeteilt werden. So kann z.B. das Einbringen von essentiellen Informationen getrennt werden von der Personalisierung eines Bootprofils.
Eine weitere durch die Nutzung eines Konfigurationskommandos eröffnete Möglichkeit ist, die Abschnitte einer Personalisierung entsprechend ihrer Vertraulichkeit und Sicherheitsanforderungen auf unterschiedliche Standorte aufzuteilen.
Ein weiterer Vorteil des erfindungsgemäßen Vorgehens besteht darin, dass es ermöglicht wird, nur eine Teilpersonalisierung durchzuführen, um vor der weiteren Personalisierung Aktualisierungen durchführen zu können. Auch können je nach Personalisierungsschritt unterschiedliche Komponenten außerhalb des sicheren Elements, z.B. Server, beteiligt sein. Solche Komponenten werden auch als Offcard-Komponenten bezeichnet. Diese können gegebenenfalls in unterschiedlichen Umgebungen, die einen zertifizierten Zugriff, einen nicht zertifizierten Zugriff oder einen HSM-Zugriff aufweisen können, vorgesehen sein. Je nach beteiligten Komponenten außerhalb des sicheren Elements können unterschiedliche Sicherheitsmechanismen realisiert sein.
Gemäß einer zweckmäßigen Ausgestaltung des Verfahrens wird durch das Konfigurationskommando festgelegt, welche Daten in einem oder mehreren der Datensätze in einem ersten Schritt personalisiert werden sollen. Nach der Personalisierung dieser Daten in dem ersten Schritt wird dann die weitere Personalisierung unterbrochen. So kann z.B. festgelegt werden, welche Daten in der Fabrik des Verwenders des sicheren Elements personalisiert werden sollen. Im Anschluss kann zu einem späteren Zeitpunkt die weitere Personalisierung durchgeführt werden.
Gemäß einer weiteren zweckmäßigen Ausgestaltung ist vorgesehen, dass durch das Konfigurationskommando ein oder mehrere Unterbrechungspunkte, bis zu denen der oder die Datensätze personalisiert werden, gesetzt werden. Hierdurch ist es möglich, den Zeitpunkt einer Unterbrechung im Personalisierungsprozess zu definieren. Es wird mit anderen Worten festgelegt, bis zu welchem Datensatz die Personalisierung durchgeführt werden soll und wann die Unterbrechung stattfinden soll.
Eine weitere zweckmäßige Ausgestaltung sieht vor, dass mittels des Konfigurationskommandos die Fortsetzung der Personalisierung zu einem späteren Zeitpunkt konfiguriert wird. Dies kann gemäß einer Ausgestaltung dadurch erfolgen, dass durch das Konfigurationskommando ein vorgegebenes Ereignis konfiguriert wird, bei dessen Eintreten die Personalisierung fortgesetzt wird. Ein solches Ereignis kann beispielsweise ein Neustart (Reset) oder das Erreichen einer vorgegebenen Anzahl an Neustarts des sicheren Elements sein. Beim Eintreten dieses Ereignisses wird dann die weitere Personalisierung fortgesetzt. In diesem Zusammenhang ist es möglich, mehrere, implizite Personalisierungsschritte zu konfigurieren. Zum Beispiel wird zu jedem Ereignis nur ein Teil des Datensatzes personalisiert und danach unterbrochen. Beim Eintreten des nächsten Ereignisses wird dann die Personalisierung weiter durchgeführt.
In einer anderen Ausgestaltung ist vorgesehen, dass das Konfigurationskommando zumindest ein weiteres Mal an das sichere Element gesendet wird, wodurch die Personalisierung zu einem späteren Zeitpunkt fortgesetzt wird. Dieses Vorgehen der Personalisierung ermöglicht es ebenfalls, weitere Teile des Datensatzes in verteilten Schritten zu personalisieren. Die weiteren, verteilten Schritte können durch den Empfang eines weiteren expliziten Konfigurationskommandos in Abhängigkeit des Eintretens eines vordefinierten Ereignisses durchgeführt werden.
Auf diesem Wege kann die Personalisierung der Datensätze, je nach Dringlichkeit, zu verschiedenen Zeitpunkten und an verschiedenen Standorten durchgeführt werden. Für die Produktion von die sicheren Elemente nutzenden Endgeräten können wichtige Personalisierungen sofort durchgeführt werden. Weitere Personalisierungen können später, z.B. beim Kunden des Endgeräts, durchgeführt werden. Dies verteilt die Gesamtzeit der Personalisierung und dadurch die Produktionszeit für den Hersteller des sicheren Elements.
Gemäß einer weiteren zweckmäßigen Ausgestaltung wird das Konfigurationskommando zumindest ein weiteres Mal an das sichere Element gesendet, wodurch die Personalisierung (nach einer Unterbrechung zu einem späteren Zeitpunkt) fortgesetzt wird. Das Konfigurationskommando kann demgemäß einmal oder mehrfach an das sichere Element gesendet werden. Je nach Anwendungsfall und Sicherheitsanforderungen kann das Konfigurationskommando verschlüsselt oder unverschlüsselt an das sichere Element übertragen werden. Die Verschlüsselung und/ oder Übertragung kann gemäß den aus dem Stand der Technik bekannten Vorgehensweisen erfolgen.
Mit dem Konfigurationskommando können somit Ereignisse zum Fortsetzen der Personalisierung konfiguriert werden. Es ist beispielsweise eine Konfiguration möglich, bei der die Personalisierung nach einem Neustart des sicheren Elements mit vorgegebenen Datensätzen, z.B. Datensatz #2 bis #3, weiter durchgeführt wird. Im Anschluss, mit dem nächsten Neustart, werden dann die restlichen Daten personalisiert.
Für den Fall, dass die Personalisierung durch den expliziten Empfang eines weiteren Konfigurationskommandos fortgesetzt werden soll, wird das Konfigurationskommando zumindest ein weiteres Mal an das sichere Element gesendet. Dennoch wird ein Trigger-Kommando, das im Stand der Technik zur Initialisierung und zum Start der Personalisierung verwendet wird, wie bisher nur ein einziges Mal benötigt. Dadurch wird eine Rückwärtskompatibilität zu bestehenden Systemen weiterhin unterstützt, darüberhinausgehende Anpassungen sind nicht erforderlich.
Eine weitere zweckmäßige Ausgestaltung sieht vor, dass in dem ersten Schritt in einem der Datensätze ein Firmware- Aktualisierungsschlüssel personalisiert wird. In einem zweiten Schritt wird dann eine Firmware- Aktualisierung durchgeführt. Dies bietet die Möglichkeit, ein Firmware-Update vor der vollständigen Personalisierung des sicheren Elements durchführen zu können. Die kartenindividuellen bzw. vertraulichen Daten können den Firmware-Aktualisierungsschlüssel beinhalten, die für eine spätere Firmware- Aktualisierung zwingend notwendig sind.
Da ohne Firmware-Aktualisierungsschlüssel keine Firmware- Aktualisierung möglich ist, kann in herkömmlicher Weise eine Aktualisierung erst nach Abschluss der Personalisierung durchgeführt werden. Dies bedeutet, Code, der im Rahmen der Personalisierung ausgeführt wird, kann nicht geändert werden und dieser Code muss zum Zeitpunkt der Erstellung die zukünftige Struktur des später geladenen Datensatzes fehlerfrei kennen. Dies limitiert im Stand der Technik den Einsatz eines sicheren Elements, da die Datensätze später eventuell nicht erweitert werden können. Ebenso kann ein Fehler im Rahmen der Personalisierung nicht behoben werden.
Durch das vorgeschlagene Vorgehen können diese Nachteile behoben werden. Indem im ersten Schritt nur die Firmware- Aktualisierungsschlüssel personalisiert werden, ermöglicht dies im direkten Anschluss eine Aktualisierung des Betriebssystems einschließlich des Codes für die weitere Personalisierung. Dadurch können neue Merkmale hinzugefügt oder personalisiert werden, die zum ursprünglichen Entwicklungszeitpunkt noch nicht bekannt waren. Darüber hinaus können Fehler, die im Rahmen der Personalisierung auftreten können, behoben werden.
Neben dem oben beschriebenen Personalisierungsverfahren betrifft die Erfindung ein System zur rechnergestützten Personalisierung eines sicheren Elements, auf das ein Speicherabbild geladen ist, in das ein Betriebssystem des sicheren Elements integriert ist, wobei das System zur Durchführung des erfindungsgemäßen Personalisierungsverfahrens gemäß einer oder mehrerer bevorzugter Ausgestaltungsformen dieses Personalisierungsverfahrens eingerichtet ist.
Die Erfindung ermöglicht durch die kontrollierte Personalisierung unterschiedliche Vertrauensniveaus (engl.: „Level of Trust") zu implementieren. Ebenso kann das Vertrauensniveau einer am Personalisierungsprozess beteiligten Einheit außerhalb des sicheren Elements (Offcard-Komponente) entsprechend angepasst werden. Dies bedeutet, je nach Anwendungsfall können unterschiedliche Komponenten, wie z.B. Produktionsmaschinen, eingebundene Server, involviert sein. Es ist damit z.B. möglich, einen Teil der Personalisierung der Firmware- Aktualisierungsschlüssel beim Hersteller des sicheren Elements durchzuführen und die nächsten sensitiven Daten in den Produktionsstätten eines Endgeräteherstellers, in dessen Endgeräte das sichere Element eingebracht werden soll. Ebenfalls ist es möglich, dass die zu personalisierenden Datensätze unterschiedlich gesichert sind. Jede Produktionsstätte kann dann nur den für sich vorbestimmten Bereich entschlüsseln.
Hierdurch ergibt sich eine starke Flexibilisierung und Erweiterbarkeit des Prozesses der Personalisierung. Der Personalisierungsprozess kann in mehrere Teile aufgeteilt werden, um Produktionszeiten und Produktionsstandorte zu verteilen und/ oder den Personalisierungsprozess zu ändern und/ oder zu erweitern.
Die Erfindung wird nachfolgend anhand von Ausführungsbeispielen in den beigefügten Figuren detailliert beschrieben.
Es zeigen:
Fig. 1 ein Flussdiagramm, in dem die Konfiguration einer verteilten Personalisierung eines sicheren Elements verdeutlich ist;
Fig. 2 ein Flussdiagramm, in dem eine Fortsetzung einer bereits gestarteten Personalisierung mit Hilfe eines explizit empfangenen Konfigurationskommandos erfolgt;
Fig. 3 ein Flussdiagramm, bei dem eine Fortsetzung einer bereits gestarteten Personalisierung beim Auftreten eines vorab konfigurierten Ereignisses erfolgt;
Fig. 4 ein Flussdiagramm, das eine verteilte Personalisierung eines sicheren Elements illustriert; Fig. 5 eine Datensatzkette mit mehreren zu personalisierenden Datensätzen, die mit einem einheitlichen Schlüssel gesichert sind; und
Fig. 6 eine Datensatzkette mit mehreren zu personalisierenden Datensätzen, die entsprechend verschieden durchzuführender Personalisierungsschritte unterschiedlich gesichert sind.
Im Folgenden wird die Erfindung anhand eines sicheren Elements beschrieben, das in ein End gerät, wie z.B. ein Mobiltelefon, zu integrieren ist. Vorzugsweise handelt es sich bei dem sicheren Element um ein fest in das Endgerät eingebautes Teilnehmeridentitätsmodul in Form einer embedded Universal Integrated Chip Card (= eUICC) zum Verwalten von Authentisie- rungsdaten für die Nutzung eines Mobilfunknetzes. In anderen Ausführungsformen kann das sichere Element auch eine UICC (= Universal Integrated Chip Card), eine Integrated eUICC („iUICC"), eine SIM (= Subscriber Identity Module) oder eine Chipkarte sein.
Ausgangspunkt des Verfahrens ist ein in den Figuren nicht dargestelltes sicheres Element, auf das ein Betriebssystem aufgebracht ist. Dies erfolgt typischerweise durch den Chiphersteller des sicheren Elements. Das Betriebssystem ist in ein Speicherabbild („Image") integriert, das zusätzlich ein sog.
Root-Profil beinhaltet.
Nachdem das Speicherabbild auf das sichere Element aufgebracht ist, werden kartenindividuelle Daten in einen speziellen Speicherbereich des sicheren Elements geschrieben. Diese kartenindividuellen Daten können aus vertraulichen Daten (wie z.B. Schlüssel, vertrauenswürdigen Root-Zertifikate, Pins und dergleichen) und nichtvertraulichen Daten (z.B. Karten IDs, öffentliche Zertifikate) bestehen. Die kartenindividuellen Daten liegen als Datensätze DS (siehe Figuren 5 und 6) vor. Zweckmäßig werden die kartenindividuellen Daten in Form eines Datenblockes oder einer Datensatzkette bereitgestellt, wie in Figuren 5 und 6 angedeutet. Die Datensatzkette kann neben kartenindividuellen Daten auch Daten enthalten, die zum Beispiel für eine bestimmte Serie von sicheren Elementen gemeinsam spezifisch sind. Das Einbringen des Datenblocks bzw. der kartenindividuellen Daten kann ebenfalls zum Beispiel beim Chiphersteller erfolgen.
Die kartenindividuellen Daten werden nachfolgend, angestoßen jeweils durch ein Konfigurationskommando, unter Steuerung des Betriebssystems personalisiert, d.h. sie werden dem Betriebssystem zugänglich gemacht. Beispielsweise wird ein für eine Funktion des Betriebssystems, etwa die Ausführung eines Firmware Updates, benötigter Schlüssel an eine Stelle im Speicherbereich geschrieben, an der das Betriebssystem ihn erwartet und benötigt.
Die kartenindividuellen Daten können unterschiedliche Vertraulichkeitsstufen besitzen. Grundsätzlich können nichtvertrauliche Daten getrennt von den vertraulichen Daten personalisiert werden, z.B. nach dem ersten Bestromen des sicheren Elements und sobald Daten geladen wurden. Dies wird typischerweise beim Hersteller des sicheren Elements oder teilweise bei einem Gerätehersteller, in dessen Endgerät das sichere Element eingebracht ist, durchgeführt. Die Personalisierung von vertraulichen Daten erfolgt typischerweise im Rahmen eines sicheren Handshake-Verfahrens, das eine Authentisierung und einen Schlüsselaustausch nutzt. Die Personalisierung kann zu einem späteren Zeitpunkt geschehen, z.B. beim Gerätehersteller.
Zum Zeitpunkt der Personalisierung werden entsprechend den kartenindividuellen Daten Objekte im sicheren Element angelegt. Das Anlegen der Objekte kann je nach Objektgröße Produktionszeit beanspruchen, wobei die Objekte nach dem Anlegen mit den entsprechenden kartenindividuellen Daten personalisiert werden.
Die Personalisierung kann somit an drei verschiedenen Standorten durchgeführt werden: a) beim Hersteller des Betriebssystems des sicheren Elements, bei dem das Speicherabbild in das sichere Element eingebracht wird, b) beim Chipkartenhersteller, bei dem kartenindividuelle Daten geladen werden, wobei ein optionales Personalisieren von nichtvertraulichen Daten erfolgen kann, sowie c) beim Gerätehersteller, bei dem, sofern noch nicht geschehen, nichtvertrauliche Daten personalisiert werden und schließlich vertrauliche Daten personalisiert werden.
Mit Hilfe des nachfolgend beschriebenen erfindungsgemäßen Verfahrens kann durch die Verwendung eines Konfigurationskommandos in der Personalisierung des sicheren Elements eine Reihenfolge festgelegt werden, in der die Datensätze DS personalisiert werden. Das Konfigurationskommando enthält keine Personalisierungsdaten sondern richtet nur die Ausführung der Personalisierung ein, d.h. die Bereitstellung der in den Datensätzen DS ent- haltenen individuellen Daten für das Betriebssystem unter Steuerung des Betriebssystems. Es legt insbesondere fest, wieviele Datensätze DS personalisiert werden bzw. bei welchem Datensatz DS eine Personalisierung unterbrochen werden soll. Das Konfigurationskommando ermöglicht eine kontrollierte Unterbrechung und spätere Fortführung der Personalisierung.
Dazu werden die kartenindividuellen Daten, die im Rahmen der Personalisierung benutzt werden, in verschiedene Datensätze DS aufgeteilt, wie dies die Figuren 5 und 6 illustrieren. Alle kartenindividuellen Daten für ein sichere Element werden zweckmäßig zusammen mit gegebenenfalls vorhandenen serienspezifischen Daten in einer Datensatzkette gemeinsam bereitgestellt.
In Fig. 5 ist eine Datensatzkette dargestellt, die beispielhaft sieben Datensätze DS umfasst. Diese sind alle mit einem gemeinsamen bzw. identischen Schlüssel Kl gesichert. Den Schlüssel Kl erhält das sichere Element über ein Handshake-Verfahren von der Personalisierungseinrichtung. Der erste Datensatz umfasst z.B. einen FWU-Schlüssel, der zweite Datensatz DS ein Zertifikat A, der dritte Datensatz DS einen dazugehörigen Schlüssel A, der vierte Datensatz ein Zertifikat B, der fünfte Datensatz DS einen dazugehörigen Schlüssel B, der sechste Datensatz DS ein Zertifikat C und der siebte Datensatz DS einen dazugehörigen Schlüssel C. A, B und C stehen dabei stellvertretend für eine Produktionsstätte oder einen zweiten Hersteller A, B oder C.
In Fig. 6 sind die gleichen sieben Datensätze DS der Datensatzkette dargestellt, wobei diese jedoch mit unterschiedlichen Schlüsseln Kl bis K4 gesichert sind. Beispielsweise ist der Schlüssel Kl zur Absicherung des Firmware-Update-Schlüssels verwendet. Der Schlüssel K2 wird zur Absicherung des zweiten und dritten Datensatzes genutzt. Der vierte und fünfte Datensatz ist mit dem Schlüssel K3 und der sechste und siebte Datensatz ist mit dem Schlüssel K4 abgesichert. Die Schlüssel K2-K4 sind jeweils einer der Produktionsstätten A, B, C zugewiesen. Jede dieser Produktionsstätten kann einen speziellen Datenanteil personalisieren, aber nicht darüber hinaus. Mit dieser Aufteilung ist es möglich, die Personalisierung auf unterschiedliche Einheiten aufzuteilen und somit unterschiedlichen Sicherheitsanforderungen gerecht zu werden.
Die Datensätze DS werden üblicherweise in einer definierten Reihenfolge personalisiert. Das erfindungsgemäß genutzte Konfigurationskommando ermöglicht dabei die Festlegung, welche Datensätze DS in einem jeweiligen Schritt personalisiert werden sollen. Beispielsweise kann festgelegt sein, dass in einem ersten Personalisierungsschritt aus der in Fig. 5 gezeigten Datensatzkette nur der erste Datensatz, der einen Schlüssel für einen Firmware Update enthält, personalisiert wird und die weitere Personalisierung anschließend unterbrochen wird. So kann z.B. festgelegt werden, welche Daten in dem Produktionsstandort des Geräteherstellers personalisiert werden sollen. Im Anschluss kann zu einem späteren Zeitpunkt die weitere Personalisierung durchgeführt werden.
Indem in einem ersten Personalisierungsschritt nur ein Schlüssel für ein Firmware Update personalisiert wird, wird beispielsweise ermöglicht, dass zunächst ein Fehlerbehebungselement in das Betriebssystem eingespielt wird, mit dem es anschließend in nachfolgenden Personalisierungsschritten dann möglich ist, die weiteren Datensätze DS zu personalisieren. Grundsätzlich wird es auf diese Weise auch möglich, eine gänzlich neue Datensatzkette mit neuen Datensätzen DS auf das sichere Element zu schreiben und nachfolgend diese zu personalisieren. Fig. 1 zeigt ein Flussdiagramm, in dem eine Konfiguration der verteilten Personalisierung des nicht dargestellten sicheren Elements mithilfe des erfindungsgemäßen Konfigurationskommandos beschrieben ist. Das Flussdiagramm zeigt, wie die erste Konfiguration durchgeführt wird und anschließend die Personalisierung entsprechend abgearbeitet wird.
In einem ersten Schritt S101 wird ein Kommando CSP an das sichere Element gesendet. Das Kommando CSP stellt das Konfigurationskommando dar. In einem Schritt S102 wird ein Kommando TSP an das sichere Element gesendet. Das Kommando TSP stellt ein aus dem Stand der Technik bekanntes Trigger-Signal dar, das die Personalisierung startet. Im Schritt S103 wird überprüft, ob eine Konfiguration gesetzt ist. Ist dies nicht der Fall (Pfad „Nein"), erfolgt im Schritt S104 die Durchführung einer vollständigen Personalisierung, wie diese aus dem Stand der Technik bekannt ist, und die Personalisierung endet anschließend.
Ist in Schritt S103 eine Konfiguration gesetzt (Pfad „Ja"), wird in Schritt S105 geprüft, ob eine weitere Konfiguration vorhanden ist. Ist das nicht der Fall (Pfad „Nein"), endet die Personalisierung. Ist eine weitere Konfiguration im Schritt S105 vorhanden (Pfad „Ja"), wird in Schritt S106 überprüft, ob eine implizite Konfiguration erfolgen soll. Dies wird weiter unten anhand von Fig. 3 erläutert. Soll eine implizite Konfiguration durchgeführt werden (Pfad „Ja"), so wird in Schritt S107 ein Ereignis für die weitere Fortsetzung der Personalisierung konfiguriert. Anschließend endet das Verfahren. Soll keine implizite Konfiguration durchgeführt werden (Pfad „Nein" des Schritts S106), so erfolgt im Schritt S108 die Personalisierung des ersten noch auszuführenden Datensatzes DS der Datensatzkette und das Verfahren kehrt zum Schritt
S105 zurück. Nach einer Unterbrechung der Personalisierung kann die weitere Personalisierung über das Konfigurationskommando CSP, welches an das sichere Element gesendet wird, fortgesetzt werden. Diese Personalisierung wird als explizites Komplettieren bezeichnet.
Fig. 2 zeigt ein Flussdiagramm, in dem eine Fortsetzung der Konfiguration mittels expliziter Komplettierung dargestellt ist. Zum Anstoßen der weiteren Personalisierung wird im Schritt S201 das Kommando CSP, d.h. das Konfigurationskommando, an das sichere Element gesendet. Ein erneutes Senden des Trigger-Kommandos TSP erfolgt bei der Fortsetzung der Konfiguration nicht. In Schritt S202 wird überprüft, ob eine Konfiguration gesetzt ist bzw. vorliegt. Ist dies nicht der Fall (Pfad „Nein"), erfolgt im Schritt S203 die Durchführung der weiteren Personalisierung. Ist eine Konfiguration in Schritt S202 gesetzt (Pfad „Ja"), so entspricht das weitere Vorgehen dem in Fig. 1 beschriebenen Vorgehen.
Die Vervollständigung oder Komplettierung der Personalisierung kann auch implizit erfolgen. Hierzu kann ein spezielles Ereignis konfiguriert werden, um die Personalisierung fortzusetzen. Beispielsweise kann hierzu ein Neustart des sicheren Elements oder die Feststellung einer vorgegebenen Anzahl an Neustarts definiert werden. Bei Eintreten dieses Ereignisses wird die Personalisierung fortgesetzt. Bei dieser Variante ist es auch möglich, mehrere implizite Personalisierungsschritte zu konfigurieren. Zum Beispiel kann zu jedem Ereignis nur ein Teil des Datensatzes DS personalisiert werden und danach eine Unterbrechung erfolgen. Beim Eintreten des nächsten (vorab konfigurierten) Ereignisses wird die Personalisierung dann weiter durchgeführt. Fig. 3 zeigt ein Flussdiagramm der Fortsetzung der Personalisierung infolge eines implizit auftretenden Ereignisses. Im Schritt S301 wird festgestellt, ob eine implizite Konfiguration vorliegt. Ist dies nicht der Fall (Pfad „Nein"), geht das Verfahren mit Schritt S307 weiter, in dem die Personalisierung einem aus dem Stand der Technik bekannten Ablauf folgt. Anschließend enden die Personalisierung und das Verfahren.
Ist eine implizite Konfiguration in Schritt S301 konfiguriert (Pfad „Ja"), so wird in Schritt S302 überprüft, ob ein vordefiniertes Ereignis erfüllt ist. Ist das nicht der Fall (Pfad „Nein"), springt das Verfahren wiederum zum Schritt S307. Ist ein vorkonfiguriertes Ereignis in Schritt S302 erfüllt (Pfad „Ja"), so erfolgt in Schritt S303 die Überprüfung, ob ein Datensatz DS vorhanden ist. Ist dies nicht der Fall (Pfad „Nein"), wird das Verfahren wiederum mit Schritt S307 fortgesetzt. Liegt ein Datensatz DS vor (Pfad „Ja"), erfolgt in Schritt S304 die Personalisierung des Datensatzes DS. In Schritt S305 wird überprüft, ob eine implizite Konfiguration vorliegt. Ist das nicht der Fall (Pfad „Nein"), geht das Verfahren zum Schritt S303 zurück und es wird erneut überprüft, ob ein Datensatz vorhanden ist. Ergibt die Überprüfung in Schritt S305, dass eine implizite Konfiguration vorliegt (Pfad „Ja"), so wird ein Ereignis für die weitere Fortsetzung konfiguriert. Anschließend geht das Verfahren zum Schritt S307 weiter.
Das beschriebene Verfahren ermöglicht es im Betrieb eines sicheren Elements, z.B. nach einem Neustart des sicheren Elements, ohne weiteres Konfigurationskommando zu überprüfen, ob eine implizite Personalisierung konfiguriert wurde und aussteht. Sofern das konfigurierte Ereignis erfüllt ist, wird die Personalisierung fortgesetzt. Es wird hier der konfigurierte Daten- satz personalisiert. Eine weitere implizite Konfiguration für weitere Datensätze ist möglich, sofern diese durch das vorherige Konfigurationskommando CSP konfiguriert wurde.
Sowohl das implizite Vervollständigen als auch das explizite Vervollständigen der Personalisierung erlauben die Personalisierung der Datensätze, je nach Dringlichkeit, zu verschiedenen Zeitpunkten und an verschiedenen Standorten durchführen zu können. Für die Produktion wichtige Personalisierungen können sofort durchgeführt werden. Weitere Personalisierungen können später bei einem Kunden durchgeführt werden. Dies verteilt die Gesamtzeit der Personalisierung und ermöglicht eine Einsparung von Produktionszeit.
Das oben beschriebene Vorgehen kann über das mehrmalige Senden des Konfigurationskommandos CSP (einmal oder mehrfach) wiederholt werden. Je nach Anwendungsfall und Sicherheitsinformationen kann die Übertragung des Kommandos CSP ungesichert oder gesichert erfolgen.
Mittels des Konfigurationskommandos CSP kann somit ein Unterbrechungszeitpunkt definiert werden. Es wird definiert, bis zu welchem Datensatz DS eine Personalisierung durchgeführt werden soll und wann die Unterbrechung stattfinden soll. Es besteht die Möglichkeit der Konfiguration zusätzlicher impliziter Ereignisse zum Fortsetzen der Personalisierung. Es kann z.B. konfiguriert werden, dass die Personalisierung nach einem Neustart mit dem Datensatz # 2 bis #3 weiter durchgeführt wird. Mit einem erneuten Neustart können dann die restlichen Daten personalisiert werden. Mittels des Konfigurationskommandos CSP wird auf diese Weise die Reihenfolge festgelegt, in der die Datensätze DS einer Datensatzkette personalisiert werden. Wie in Fig. 4 gezeigt besteht die Möglichkeit, ein Firmware-Update vor der kompletten Personalisierung durchzuführen. Gemäß Fig. 4 wird in Schritt S401 das Konfigurationskommando CSP an das sichere Element übertragen, wobei die Konfiguration derart definiert ist, nur den Firmware-Update (FWU)-Schlüssel zu personalisieren. In Schritt S402 wird das Trigger-Kommando TSP, das aus dem Stand der Technik bekannt ist, an das sichere Element übertragen. Daraufhin wird die Personalisierung der Firmware-Up- date-Schlüssel durchgeführt und anschließend der Personalisierungsprozess unterbrochen. Im Anschluss kann sofort ein Firmware-Update durchgeführt werden (Schritt S403). Ein Firmware-Update kann zum Beispiel eine Fehlerbehebung und/ oder Erweiterung enthalten. Mit der Feature-Erweiterung ist es möglich, geladene Datensätze zu personalisieren, die zum ursprünglichen Entwicklungszeitpunkt des sicheren Elements noch nicht bekannt waren. Nach dem Firmware-Update wird erneut das Konfigurationskommando CSP an das sichere Element gesendet, um die verbleibende Personalisierung zu initiieren (Schritt S404).
Die Erfindung ermöglicht es, Firmware-Updates gezielt frühzeitig zu ermöglichen, d.h. direkt nach der Personalisierung der Firmware-Update-Schlüssel können Fehlerbehebungen oder Feature-Erweiterungen durchgeführt werden. Im Anschluss kann eine restliche Personalisierung durchgeführt werden.
Die Personalisierung kann auf unterschiedliche Produktionsstätten verteilt werden. Eine Einsparung von Produktionszeiten ist möglich.
Die Anwendung bzw. Konfiguration der Personalisierung kann aufgrund unterschiedlicher Sicherheitserfordernisse aufgeteilt werden. Bei Nutzung mehrerer Produktionsstätten und jeweiligen Sicherheitsstufen können die entsprechenden Datensätze mit entsprechenden Schlüsseln (siehe die Schüssel K1-K4 in Fig. 6) versehen werden. Die Personalisierung sensibler Daten kann entsprechend der Sicherheitsstufen oder Anwendungsfälle aufgeteilt werden.
Die Fortsetzung einer angefangenen Personalisierung kann explizit über ein weiteres Konfigurationskommando oder implizit durch die vorherige Konfiguration bestimmter Ereignisse, z.B. nach einer bestimmten Anzahl an Neustarts, gesteuert werden.

Claims

P a t e n t a n s p r ü c h e Verfahren zur rechnergestützten Personalisierung eines sicheren Elements, auf das ein Speicherabbild geladen ist, in welchem ein Betriebssystem des sicheren Elements integriert ist, bei dem in einen speziellen Speicherbereich des sicheren Elements ein oder mehrere, individuell für das sichere Element vorgesehene Datensätze (DS) geschrieben werden, welche kartenindividuelle Daten enthalten, mit denen unter Steuerung des Betriebssystems die Personalisierung des sicheren Elementes erfolgt, wobei mit einem Konfigurationskommando (CSP) in der Personalisierung des sicheren Elements eine Reihenfolge festgelegt wird, in der die Datensätze (DS) personalisiert werden. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass durch das Konfigurationskommando (CSP) festgelegt wird, welche Daten in einem oder mehreren der Datensätze (DS) in einem ersten Schritt personalisiert werden sollen. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass durch das Konfigurationskommando (CSP) ein oder mehrere Unterbrechungspunkte, bis zu denen der oder die Datensätze (DS) personalisiert werden, gesetzt werden. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mittels des Konfigurationskommandos (CSP) die Fortsetzung der Personalisierung zu einem späteren Zeitpunkt konfiguriert wird. 5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass durch das Konfigurationskommando (CSP) ein vorgegebenes Ereignis konfiguriert wird, bei dessen Eintreten die Personalisierung fortsetzt wird.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass das Ereignis ein Neustart oder das Erreichen einer vorgegebenen Anzahl an Neustarts des sicheren Elements ist.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Konfigurationskommando (CSP) zumindest ein weiteres Mal an das sichere Element gesendet wird, wodurch die Personalisierung zu einem späteren Zeitpunkt fortgesetzt wird.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Konfigurationskommando (CSP) verschlüsselt oder unverschlüsselt an das sichere Element übertragen wird.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in dem ersten Schritt in einem der Datensätze (DS) ein Firmware- Aktualisierungsschlüssel personalisiert wird.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass in einem zweiten Schritt eine Firm ware- Aktualisierung durchgeführt wird.
11. System zur rechnergestützten Personalisierung eines sicheren Elements, auf das ein Speicherabbild geladen ist, in dem ein Betriebssystem des sicheren Elements integriert ist, wobei das System derart ausgestaltet ist, dass bei seinem Betrieb in einen speziellen Speicherbereich des sicheren Elements ein oder mehrere, individuell für das sichere Element vorgesehene Datensätze (DS) geschrieben werden, welche kartenindividuelle Daten enthalten, mit denen unter Steuerung des Betriebssystems die Personalisierung des sicheren Elementes erfolgt, und mit einem Konfigurationskommando (CSP) in der Personalisierung des sicheren Elements eine Reihenfolge festgelegt wird, in der die zu schreibenden Datensätze (DS) personalisiert werden. 12. System nach Anspruch 11, dadurch gekennzeichnet, dass das System zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 10 eingerichtet ist.
EP23722815.0A 2022-04-22 2023-04-21 Verfahren und system zur personalisierung eines sicheren elements Pending EP4511783A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE102022001390 2022-04-22
DE102023110087.4A DE102023110087A1 (de) 2022-04-22 2023-04-20 Verfahren und System zur Personalisierung eines sicheren Elements
PCT/EP2023/025187 WO2023202801A1 (de) 2022-04-22 2023-04-21 Verfahren und system zur personalisierung eines sicheren elements

Publications (1)

Publication Number Publication Date
EP4511783A1 true EP4511783A1 (de) 2025-02-26

Family

ID=86330966

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23722815.0A Pending EP4511783A1 (de) 2022-04-22 2023-04-21 Verfahren und system zur personalisierung eines sicheren elements

Country Status (4)

Country Link
US (1) US20250245314A1 (de)
EP (1) EP4511783A1 (de)
CN (1) CN119053980A (de)
WO (1) WO2023202801A1 (de)

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19939280A1 (de) 1999-08-19 2001-02-22 Ibm Sicheres Personalisieren von Chipkarten
EP1622098A1 (de) 2004-07-30 2006-02-01 ST Incard S.r.l. Verfahren zur gesicherten Personalisierung einer IC-Karte
DE102008027043B4 (de) 2008-06-06 2012-03-08 Giesecke & Devrient Gmbh Verfahren zum Personalisieren eines Sicherheitselements eines mobilen Endgeräts
US20140031024A1 (en) * 2012-02-05 2014-01-30 Rfcyber Corporation Method and system for providing controllable trusted service manager
US10936719B2 (en) * 2016-09-23 2021-03-02 Apple Inc. Preserving trust data during operating system updates of a secure element of an electronic device
FR3072853B1 (fr) * 2017-10-20 2021-11-12 Oberthur Technologies Procedes de chargement d'un profil dans un element securise, gestionnaire et element securise personnalisable
IT201800009905A1 (it) * 2018-10-30 2020-04-30 St Microelectronics Srl Procedimento per la generazione di dati personalizzati di profile package in carte a circuito integrato, corrispondente sistema e prodotto informatico
IT201900017561A1 (it) * 2019-09-30 2021-03-30 St Microelectronics Srl "Procedimento per introdurre dati di personalizzazione in memorie non volatile di una pluralità di circuiti integrati, in particolare in carte a circuito integrato, corrispondente sistema e prodotto informatico"
GB202014682D0 (en) * 2020-09-17 2020-11-04 Nordic Semiconductor Asa Bootloaders
US11979940B2 (en) * 2020-10-14 2024-05-07 Flo Live Israel LTD. System and method for provisioning enhanced SIM profiles as standard eUICC profiles
IT202200011084A1 (it) * 2022-05-26 2023-11-26 St Microelectronics Srl Procedimento per introdurre dati di personalizzazione in memorie non volatile di una pluralità di circuiti integrati, in particolare in carte a circuito integrato, corrispondente sistema e prodotto informatico

Also Published As

Publication number Publication date
CN119053980A (zh) 2024-11-29
US20250245314A1 (en) 2025-07-31
WO2023202801A1 (de) 2023-10-26

Similar Documents

Publication Publication Date Title
EP2289225B1 (de) Verfahren zum personalisieren eines sicherheitselements eines mobilen endgeräts
EP1639603A2 (de) Verfahren zur durchführung eines software-updates eines elektronischen steuergerätes durch eine flash-programmierung über eine serielle schnittstelle und ein entsprechender zustandsautomat
DE19839680B4 (de) Verfahren und Vorrichtung zur Veränderung des Speicherinhalts von Steuergeräten
EP3080950B1 (de) Verfahren und system zur deterministischen autokonfiguration eines gerätes
DE102022113922A1 (de) Ota-master, system, verfahren, nicht-transitorisches speichermedium und fahrzeug
DE102023110087A1 (de) Verfahren und System zur Personalisierung eines sicheren Elements
EP3811261A1 (de) Kryptografiemodul und betriebsverfahren hierfür
EP1227616A1 (de) Verfahren, Programm und Anordnung zur Synchronisierung von einem Network Manager mit einem Network Agenten
WO2005022382A2 (de) Verfahren zur installation einer programmkomponente
EP4511783A1 (de) Verfahren und system zur personalisierung eines sicheren elements
EP2561460B1 (de) Verfahren zum konfigurieren einer applikation für ein endgerät
DE102005009639A1 (de) Verfahren und Vorrichtung zum Sichern individueller Einstellungsdaten
EP1634252B1 (de) Verfahren zum laden von tragbaren datenträgern mit daten
WO2011033030A1 (de) Verfahren zum installieren und konfigurieren von applikationen auf einem portablen datenträger
EP2524333A1 (de) Verfahren zum bereitstellen eines sicheren zählers auf einem endgerät
DE102024108995B3 (de) Verfahren zum einrichten eines benutzergerätes sowie selbiges nebst computerprogramm, computerlesbarem datenträger und einrichtungsanordnung dafür
EP1529257B1 (de) Übernehmen eines datensatzes in eine recheneinheit
DE102019005545A1 (de) Verfahren zum Betreiben eines Maschinendatenkommunikationsnetzwerks, sowie Maschinendatenkommunikationsnetzwerk
EP4361800B1 (de) Verfahren zur verbesserung der betriebssicherheit eines steuergeräts sowie steuergerät
WO2009103728A1 (de) Verfahren und vorrichtung zum speichern von informationsdaten
DE102020216071A1 (de) Verfahren zum Betreiben einer Vorrichtung, ein Steuergerät eines Kraftfahrzeugs, und Vorrichtung
DE102021005325A1 (de) Verfahren zur rechnergestützten Erzeugung eines Speicherabbilds für ein sicheres Element
WO2021115629A1 (de) Personalisierung eines sicheren identifikationselements
EP4679305A1 (de) Einbindungsverfahren zum einbinden einer clientvorrichtung in eine einsatzumgebung, prüfinstanzvorrichtung, versionsprüfeinrichtung, einsatzumgebung, clientvorrichtung, computerprogramm und elektronisch lesbarer datenträger
EP2348453B1 (de) Verfahren zum zuordnen eines tragbaren datenträgers, insbesondere einer chipkarte, zu einem terminal

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

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

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20241122

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 ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)