WO2014079563A1 - Installation einer applikation auf dem sicherheitselement eines portable datenträgers - Google Patents

Installation einer applikation auf dem sicherheitselement eines portable datenträgers Download PDF

Info

Publication number
WO2014079563A1
WO2014079563A1 PCT/EP2013/003500 EP2013003500W WO2014079563A1 WO 2014079563 A1 WO2014079563 A1 WO 2014079563A1 EP 2013003500 W EP2013003500 W EP 2013003500W WO 2014079563 A1 WO2014079563 A1 WO 2014079563A1
Authority
WO
WIPO (PCT)
Prior art keywords
security element
application
installation device
installation
security
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
PCT/EP2013/003500
Other languages
English (en)
French (fr)
Inventor
Dieter Weiss
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 GmbH
Original Assignee
Giesecke+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+Devrient GmbH filed Critical Giesecke+Devrient GmbH
Publication of WO2014079563A1 publication Critical patent/WO2014079563A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING 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/306—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using TV related infrastructures
    • 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/308—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using the Internet of Things
    • 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/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
    • 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/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of 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/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/356—Aspects of software for card payments
    • G06Q20/3563—Software being resident on card

Definitions

  • the present invention relates to a method for installing an application in a security element of a portable terminal by means of an installation device and a corresponding installation device.
  • portable terminals such as for example mobile terminals, smartphones, tablets and the like
  • applications can be expanded in a known manner by the installation of software functionalities, so-called applications or "apps.”
  • the applications which also include security-relevant data and / or can usually be installed in a security element of the terminal, the installation of the application on the security element can also be done after the issue of the security element to the user, ie when the security element is already in operation.
  • Security elements that can be integrated into security devices that can be integrated into a terminal come into question as security elements.
  • security elements that are permanently embedded in the terminal are also known and usable, for example embedded SIM / UICC mobile cards, TPMs ("Trusted Platform Modules") or NFC modules
  • secure execution environments within a specific hardware architecture of the terminal, within an ARM TrustZone architecture, for example, as security serve as a "Trusted Execution Environment” according to the "Global Platform” specification.
  • the applications are provided in the form of a program code that can be executed platform-independently by an interpreter, for example a virtual machine.
  • an interpretable code is Java or JavaCard bytecode, which can be executed by a Java or JavaCard virtual machine on the security element.
  • Java or JavaCard bytecode which can be executed by a Java or JavaCard virtual machine on the security element.
  • the disadvantage of this is that the program code that can be interpreted in comparison to the program code which can be directly executed on a processor of the security element, i. processor code adapted to the processor, running much slower. This is particularly problematic if the corresponding application implements a functionality that must meet hard time constraints.
  • An example of such a functionality is a payment functionality via NFC ("Near Field Communication"), in which case the communication protocol used already makes tight time specifications, for example with regard to the required response times of the security element.
  • the object of the present invention is to propose a method for installing an application on a security element of a portable data carrier, which improves the runtime of the installed application. on possible. Furthermore, the installation method should not require an increase in the complexity of the security element.
  • An inventive method for installing an application in a security element of a portable terminal comprises the following
  • OTA air interface
  • An installation device is an external device which is different from the security element and the portable terminal and is set up to carry out the method according to the invention.
  • the installation device comprises in particular means for establishing a data communication connection with the security element, directly or via the portable terminal. This can be done, for example, via a so-called installation interface of the installation direction.
  • the data communication is conducted, for example, via a suitable communication network, such as the Internet.
  • the installation device comprises an interface for accepting an application to be installed on the security element, for example by an application provider or developer.
  • the installation device further comprises tools for generating or providing an executable program code assigned to the application, in particular suitable compiler and linker functionalities.
  • the installation means comprises means for transmitting generated program code to the security element.
  • the installation device is preferably operated, for example, by a manufacturer or a publisher of the security element.
  • an independent entity can also operate an installation device according to the invention of the type described.
  • the method according to the invention thus makes it possible to generate program code individually tailored to the security element, in particular its processor, in the form of machine code and to install it on the security element. This allows execution of the application with the best possible use of the resources of the security element. The execution of the application can be done much faster than in known methods, in which the application is provided only as a uniform, interpretable program code.
  • the security element can remain unchanged.
  • the configuration of the security element can even be simplified.
  • One to run Interpreter required by interpretable program code is then dispensable. In this way not only computing time, in the direct execution of the program code associated with an application on a processor of the security element, but also storage space in a non-volatile memory of the security element can be saved to a not inconsiderable extent.
  • Both are in data carriers or modules of the type described, which are resource constrained by design, of immense importance and can simplify the production of such security elements and can be done more economically.
  • the installation device is designed as a trustworthy entity, in particular as a so-called “Trusted Service Manager”, hereinafter referred to as TSM for short.
  • TSM Trusted Service Manager
  • cryptographic keys are exchanged between the trusted entity and an owner of the security element, which can then cryptographically secure the installation process.
  • the installation device comprises a so-called client interface.
  • requests or orders concerning the installation of an application can be accepted on a security element and / or forwarded to a wide, similar installation device.
  • Such a request may relate to an application that already exists in the installation device.
  • An installation order can alternatively together with the application to be installed are placed at the installation device, ie the client delivers with the order also the application to be installed.
  • the client interface can be designed technically in various ways, for example in the form of a web service.
  • a manufacturer and / or publisher of the security element, but also authorized third parties can administer the security element via the client interface, for example a user of the terminal in which the security element is integrated.
  • the client interface can also be used to receive applications that can be installed on a security element from an application provider or developer without an installation order being bound thereto. In this way, any developers can provide the applications they design for installation on a security element via the installer. The mere acceptance of installable applications, however, can also be done by other means.
  • a TSM may include a client interface.
  • An application that can be installed or installed on a security element is usually made available to the installation device in the form of an interpretable intermediate code, preferably a byte code, for example as a Java or JavaCard bytecode. But it is also possible that the application is provided in the form of a source code in a higher-level programming language. For an inventive installation of an application in the security element, it is not necessary that a same effect application, for example in the form of interpretable program codes or as source code, already in the security element exists.
  • the step of querying the configuration of the security element may include various substeps.
  • the installation device first queries whether the security element permits installation of program code which can be executed directly by a processor of the security element. If this is not the case, the installation device provides such program code associated with the application, which can be executed by an interpreter of the security element, in particular by a virtual machine. In the other case, where the security element supports installation of machine code, further queries are made to enable generation and provision of the program code executable directly on the processor of the security element.
  • the step of querying the configuration of the security element then typically further includes the substeps of interrogating a hardware configuration of the security element and querying a software configuration of the security element.
  • the software component of the security element will also be examined with regard to all significant factors, in particular with regard to the security element of provided data, libraries, software functionalities and programming interfaces.
  • call addresses of functions provided by the security element can be queried. This applies both to call addresses of functions of an API ("application programming interface") and functions of other applications already installed on the security element, for example.
  • API application programming interface
  • an object code assigned to the application is generated. This is done by means of a suitable, the hardware configuration associated compiler. Alternatively, an object code can also be generated in advance for all compilers present to the installation device. In the providing step, the pre-created object code is then selected which is compatible with the requested hardware and software configuration.
  • the generated or selected object code is subsequently linked with respect to the abovementioned queried invocation addresses by functions used by the security element provided by the application.
  • This approach allows the installer to easily generate program code tailored to the security element and executable directly on the processor of the security element.
  • the appropriate compiler is selected depending on the requested hardware configuration. Since the call addresses to be resolved in the link are explicitly queried in the object code in each case-this step preferably takes place after the object code has been generated in order to query only the call addresses referenced there-various specifics, for example concerning an operating system of security, can be used - Selements or the like, are disregarded in the creation of the executable program code. This is particularly relevant in the variant of the method in which object code is generated in advance for different hardware platforms, since the number of different object codes to be produced can be limited - because of the lack of dependency on the same of the specifics mentioned.
  • the installation device is supported by various tools, in particular by compiler and / or linker functionalities adapted to the respective security element. These are preferably provided by a manufacturer of the security element and / or a production of the portable terminal. As a result, all functionalities of the security element can be optimally supported and all resources optimally utilized. This is true since, in particular, the manufacturer of the security element, who prescribes the hardware equipment and at least initially also the software equipment of the security element, can optimally match a compiler to it, in particular also with regard to the security element of existing resources, such as data, libraries or the like.
  • the installation device can check the application, preferably before the step of providing a program code assigned to the application and executable on the security element. By means of such a checking step it can be ensured that no defective, inoperable and / or damage-causing program code is installed or that unauthorized third parties introduce program code into the security element.
  • An audit may involve different aspects, such as compliance with technical specifications and whether the application includes malicious code.
  • Other security aspects for example the susceptibility of the application to known attacks on security elements, for example so-called side channel attacks, can be tested alternatively or additionally.
  • an examination regarding the integrity and / or authenticity of the application can take place in order to prevent the installation of foreign or modified program codes.
  • known methods can be used, for example checksums, so-called “message authentication codes” or certificates, for example based on an asymmetric key architecture.
  • test can also be done in the same way by an external
  • Auditing instance for example, a software certification authority, a publisher of the security element, an application provider or similar instances done. A developer can do the application before doing this through the installer, submit to the auditor or CA. This point checks the application according to specified test criteria and provides the application, after successful testing, with a corresponding certificate.
  • the step of checking by the installation device can consist only in verifying the certificate.
  • the installation device can alternatively or additionally make their own checks if the certificate is available.
  • An installation device 30, which supports an installation method described below, is described by way of example as a so-called "Trusted Service Manager.”
  • TSM Trusted Service Manager
  • Such a “Trusted Service Manager” (TSM) is a trustworthy entity, which is an installation of an application in a security element 42 of a portable terminal 40 in a cryptographically secured manner.
  • the TSM manages corresponding cryptographic keys, which have previously been exchanged with an owner of the security element 42.
  • TSM-specific features ie the cryptographic securing of the installation by means of the key provided for this purpose, are not affected.
  • the aim of the method described with reference to FIG. 1 is to provide for each different security element 42, in particular for security element 42 of different manufacturers 20, applications in a form directly executable on the respective processor 44 of the security element 42, i. as machine code adapted to the respective processor 44.
  • the TSM provides corresponding compiler and linker functionalities from various manufacturers 20 of different security elements 42. Also, manufacturers of portable terminals 40 having security elements 42 integrated therein can provide compiler and linker functionalities.
  • the installation device 30 can assemble the various received compilers and linkers into, for example, a compiler and linker database, each linked to the information for which security element 42, ie for which hardware platform, the corresponding compiler and linker is respectively usable.
  • an application developer 10 provides the application device 30 with an application 50.
  • This step can be repeated by the same developer 10 and / or other developers with different applications, so that the installation device 30 can have various applications that can be installed in a security element 42.
  • applications are provided in an interpreter executable code, such as Java or JavaCard bytecode. It is likewise possible for the application to be provided in the form of a source code of a high-level programming language, for example in "C" or Java 3.
  • the installation device 30 compiles all applications present there by means of all the compilers present in the compiler database.
  • the corresponding applications are now in the form of object code which is adapted to the corresponding hardware platforms, but can not yet be executed there, since, for example, functionalities present in the security element, which are referenced by the object code corresponding to the application, first still have to be linked correctly.
  • the installation device 30 receives a request regarding the installation of a specific application 50 in a specific security element 42.
  • the request is initiated in the present example by the portable terminal 40, in which the security element 42 is integrated.
  • the installation device 30 comprises a client interface 32 (see FIG. Via this interface, orders relating to the installation of an application can be accepted on a security element and forwarded to another, similar installation device 30 ', as indicated in FIG. 2 and described in more detail below.
  • Orders for installation of an application on a security element 42 can reach the installation device 30 from various points, for example from the manufacturer 20 or issuer 20 'of the security element. However, authorized third parties can also issue corresponding orders, such as in the present example the owner of the terminal and a service provider with whom the owner of the security element is related, for example an application provider, a credit card provider or the like. Each such order usually includes information with which the security element on which the designated application is to be installed to identify exactly, for example, a unique serial number, or the like, as well as an indication of the application to be installed.
  • a request regarding the installation of an application may relate to an application already present at the installation device 30.
  • the application to be installed can be supplied together with such an order.
  • the above-mentioned information concerning the application to be installed can either designate it clearly or include it directly.
  • the installation device 30 first in step S5 queries the hardware configuration of the security element 42. For this purpose, a data communication connection between the installation device 30 and the security element 42 is built. The data communication connection is established via an installation interface 34 (see Fig. 2) of the installation device 30.
  • the installation device 30 may select the appropriate object security for the specific security element 42. Select code. This has already been generated in advance, as described, in step S3 by compiling the application 50 provided in step S2, using a compiler suitable for the queried hardware configuration.
  • the installation device 30 ensures that the selected object code is compatible with the security element 42.
  • the software configuration pertains to all aspects of the software component of the security element that are to be considered in the selection of the object code, for example, the correct version of a corresponding API or the like.
  • step S7 the installation device therefore asks the corresponding call addresses of these functions at the security element in order to be able to resolve the remaining in the object code references in the subsequent step S8 of the link.
  • step S7 allows the installation device 30 to ignore further specifics of the security element 42, for example an operating system installed thereon. Furthermore, this query can not only relate to API functions, but also those functions that are provided by other, already present on the security element 42 applications.
  • the security element can already determine the memory address at which the executable program code corresponding to the application will subsequently be stored during the installation in step S10. In the following step S8, this not only enables a link of the object code, but also a relocation.
  • step S8 the object code selected in step S6 is linked knowing the call addresses retrieved in step S7.
  • step S9 the installation device 30 transmits the executable program code associated with the application 50, as described above, to the security element 42.
  • the program code is finally installed.
  • the security element 42 can for this purpose include a corresponding loading or installation functionality.
  • an application 50 provided to the installation device 30 not to be ready for receipt for one or more hardware platforms is compiled.
  • the compilation step S3 can only take place in response to a corresponding order for installing the application 50 in a specific security element 42.
  • the installation device 30 queries the hardware and software configuration of the relevant security element 42 described with reference to step S5 and only then generates the corresponding object code for the security element 42.
  • the installation device 30 it is possible, for example, for the installation device 30 to be the first time then request a corresponding compiler functionality from a manufacturer 20 of the security element 42.
  • the installation device 30 may first inquire in step S5 from the security element 42 as to whether this in principle allows installation of program code which can be directly executed on the processor 44 of the security element 42. If this is not the case, steps S6 to S8 can be omitted. Instead of a machine code tailored to the processor 44 of the security element 42, the installation device then transmits in step S9 only such code assigned to the application 50, which code can be interpreted by an interpreter of the security element 42, for example a virtual machine. In the event that the application 50 of the installation device 30 has already been provided in a corresponding form (in step S2), nothing has to be done in step S3. However, if the application is present only as a source code, at least the interpretable code is to be generated in step S3.
  • the installation device 30 can proceed if it recognizes that it has no compiler which can be assigned to the hardware configuration queried by the security element 42 in step S5 and can not be obtained.
  • the Installation device 30 further has the option of forwarding the installation job to such an installation device 30 '(see Fig. 2), which has a compiler functionality adapted to the hardware configuration of security element 42.
  • Cryptographic keys which may be necessary for securing the installation could be present in the case described by way of example in that the further installation device 30 'is operated by a manufacturer 20 of the security element 42 in the case of the further installation device 30' already on the basis of the manufacturer's reference. That is, the security element 42 is already equipped in the production with appropriate, specifically assigned to the manufacturer cryptographic keys.
  • These cryptographic keys differ from those cryptographic keys that a later owner of the security element 42 agreed with the installation device 30, but are also used to secure an application installation, if this is performed by a further installation device 30 'assigned to the manufacturer.
  • Common further security measures which can secure data communication between two parties over an unsecured communication network, such as encrypted data transmission, the use of signatures and mutual authentication of the communication partners, can of course be as described above. However, they are not described in detail here.
  • the installation device 30 can check an application 50 received from an application provider or developer 10 and a further client 20, 20 'with respect to various aspects before this application 50 is prepared for installation on a security element 42.
  • the test may estimate the likelihood that the application includes malicious code, for example, by standard bytecode verification or the like.
  • the application can be examined for integrity and / or authenticity.
  • it is possible that the application, before it is provided to the installation device is checked by an external body according to predetermined test criteria. Such a check can be documented by means of a certificate, which is attached to the application 50. A check of the installation device 30 can then be limited to a check of the certificate.

Landscapes

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

Abstract

Ein Verfahren zur Installation einer Applikation (50) in einem Sicherheitselement (42) eines portablen Endgeräts (40) umfasst die folgenden Schritte: Die externe Installationseinrichtung (30) fragt eine Konfiguration des Sicherheitselements (42) ab (S5, S7). Diese Konfiguration kann sowohl die Hardware- als auch die Softwareausstattung des Sicherheitselements (42) betreffen. Auf Basis der abgefragten Konfiguration stellt die Installationseinrichtung (30) einen der Applikation (50) zugeordneten, auf dem Sicherheitselement (42) ausführbaren Programmcode bereit (S3, S6, S8). Bevorzugt handelt es sich bei dem Programmcode um unmittelbar durch einen Prozessor (44) des Sicherheitselements (42) ausführbaren Maschinencode. Der ausführbare Programmcode wird anschließend von der Installationseinrichtung (30) an das Sicherheitselement (42) übertragen (S9) und dort installiert (S10).

Description

INSTALLATION EINER APPLIKATION AUF DEM SICHERHEITSELEMENT EINES
PORTABLE DATENTRÄGERS
Die vorliegende Erfindung betrifft ein Verfahren zur Installation einer Applikation in einem Sicherheitselement eines portablen Endgeräts mittels einer Installationseinrichtung sowie eine entsprechende Installationseinrichtung.
Die Funktionalität portabler Endgeräte, wie beispielsweise von Mobilfun- kendgeräten, Smartphones, Tablets und dergleichen, kann durch die Installation von Softwarefunktionalitäten, so genannten Applikationen oder„ Apps", in bekannter Weise erweitert werden. Die Applikationen, welche auch sicherheitsrelevanten Daten umfassen und/ oder verarbeiten können, werden in der Regel in einem Sicherheitselement des Endgeräts installiert, wobei die Installation der Applikation auf dem Sicherheitselement auch noch nach der Ausgabe des Sicherheitselements an den Nutzer erfolgen kann, d.h. wenn das Sicherheitselement bereits in Betrieb ist.
Als Sicherheitselemente kommen entfernbar in ein Endgerät integrierbare Sicherheitsmodule, beispielsweise SIM/UICC-Mobilf unkkarten, sichere Multimediakarten oder dergleichen in Frage. Aber auch fest in das Endgerät eingebaute Sicherheitselemente sind bekannt und verwendbar, beispielsweise embedded-SIM/ UICC-Mobilf unkkarten, TPMs („Trusted Platform Moduls") oder NFC-Module. Schließlich können auch sichere Ausführungsum- gebungen innerhalb einer spezifischen Hardwarearchitektur des Endgeräts, beispielsweise innerhalb einer ARM TrustZone- Architektur, als Sicherheit- selemente dienen, wie beispielsweise ein„Trusted Execution Environment" gemäß der„Global Platform" -Spezifikation.
Die Applikationen werden dabei in der Regel in Form eines durch einen In- terpreter, beispielsweise eine Virtuelle Maschine, plattformunabhängig ausführbaren Programmcodes bereitgestellt. Ein bekanntes Beispiel eines solches interpretierbaren Codes ist Java- oder JavaCard-Bytecode, welcher von einer Java oder JavaCard Virtuellen Maschine auf dem Sicherheitselement ausgeführt werden kann. Auf diese Weise kann eine solche Applikation auf verschiedensten Hardwareplattformen und unter verschiedenen Betriebssystemen ausgeführt werden, ohne dass eine Anpassung der Applikation an die entsprechende Hardwareplattform und/ oder Softwareausstattung erfolgen muss. Nachteilig daran ist, dass interpretierbarer Programmcode im Vergleich zu auf einem Prozessor des Sicherheitselements direkt ausführbarem Programmcode, d.h. auf den Prozessor angepassten Maschinencode, deutlich langsamer ausgeführt wird. Dies ist insbesondere dann problematisch, wenn die entsprechende Applikation eine Funktionalität implementiert, welche harten Zeitbeschränkungen genügen muss. Ein Beispiel einer solchen Funktionalität ist eine Bezahlfunktionalität über NFC („Near Field Communicati- on"), wobei bereits das verwendete Kommunikationsprotokoll enge zeitliche Vorgaben macht, beispielsweise hinsichtlich erforderlicher Antwortzeiten des Sicherheitselements.
Aufgabe der vorliegenden Erfindung ist es, ein Verfahren zum Installieren einer Applikation auf einem Sicherheitselement eines portablen Datenträgers vorzuschlagen, welches eine verbesserte Laufzeit der installierten Applikati- on ermöglich. Weiterhin soll das Installationsverfahren keine Steigerung der Komplexität des Sicherheitselements erforderlich machen.
Diese Aufgabe wird durch ein Verfahren und eine Installationseinrichtung mit den Merkmalen der unabhängigen Ansprüche gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen sind in den abhängigen Ansprüchen angegeben.
Ein erfindungsgemäßes Verfahren zur Installation einer Applikation in ei- nem Sicherheitselement eines portablen Endgeräts umfasst die folgenden
Schritte: Die Installationseinrichtung fragt eine Konfiguration des Sicherheitselements ab. Diese Konfiguration kann sowohl die Hardware- als auch die Softwareausstattung des Sicherheitselements betreffen. Abhängig von der abgefragten Konfiguration stellt die Installationseinrichtung einen der Ap- plikation zugeordneten, auf dem Sicherheitselement ausführbaren Programmcode bereit. Bevorzugt, wie nachfolgend ausgeführt, handelt es sich bei dem Programmcode um unmittelbar durch einen Prozessor des Sicherheitselements ausführbaren Maschinencode. Der ausführbare Programmcode wird anschließend von der Installationseinrichtung an das Sicherheit- selement übertragen, vorzugsweise über eine Luftschnittstelle (OTA,„over the air"), und dort schließlich installiert.
Eine erfindungsgemäße Installationseinrichtung ist eine von dem Sicherheitselement und dem portablen Endgerät verschiedene, externe Einrichtung, welche eingerichtet ist, das erfindungsgemäße Verfahren durchzuführen. Insofern umfasst die Installationseinrichtung insbesondere Mittel, um mit dem Sicherheitselement, direkt oder über das portable Endgerät, eine Datenkommunikationsverbindung aufzubauen. Dies kann beispielsweise über eine dazu eingerichtete, so genannte Installationsschnittstelle der Installationsein- richtung erfolgen. Die Datenkommunikation wird dabei beispielsweise über ein geeignetes Kommunikationsnetzwerk, wie das Internet, geleitet. Weiter umf asst die Installationseinrichtung eine Schnittstelle, um eine auf dem Sicherheitselement zu installierende Applikation entgegenzunehmen, bei- spielsweise von einem Applikationsanbieter oder -entwickler. Die Installationseinrichtung umfasst ferner Werkzeuge, um einen der Applikation zugeordneten ausführbaren Programmcode zu erzeugen bzw. bereitzustellen, insbesondere geeignete Compiler- und Linker-Funktionalitäten. Schließlich umfasst die Installationseinrichtung Mittel, um erzeugten Programmcode an das Sicherheitselement zu übertragen.
Bevorzugt wird die Installationseinrichtung beispielsweise von einem Hersteller oder einem Herausgeber des Sicherheitselements betrieben. Aber auch eine unabhängige Instanz kann eine erfindungsgemäße Installationseinrich- tung der beschriebenen Art betreiben.
Das erfindungsgemäße Verfahren ermöglicht es somit, individuell auf das Sicherheitselement, insbesondere dessen Prozessor, zugeschnittenen Programmcode in Form von Maschinencode zu erzeugen und auf dem Sicher- heitselement zu installieren. Dies erlaubt eine Ausführung der Applikation unter bestmöglicher Ausnutzung der Ressourcen des Sicherheitselements. Die Ausführung der Applikation kann deutlich schneller erfolgen als in bekannten Verfahren, bei welchen die Applikation lediglich als einheitlicher, interpretierbarer Programmcode bereitgestellt wird.
Weiterhin kann das Sicherheitselement unverändert verbleiben. In dem Fall, dass sämtliche in dem Sicherheitselement installierten Applikationen mit dem erfindungsgemäßen Verfahren installiert werden, kann die Konfiguration des Sicherheitselements sogar vereinfacht werden. Ein zum Ausführen von interpretierbarem Programmcode erforderlicher Interpreter ist dann verzichtbar. Auf diese Weise kann nicht nur Rechenzeit, beim direkten Ausführen des einer Applikation zugeordneten Programmcodes auf einem Prozessor des Sicherheitselements, sondern auch noch Speicherplatz in einem nicht flüchtigen Speicher des Sicherheitselements in nicht unbeträchtlichem Maße eingespart werden. Beides ist bei Datenträgern oder Modulen der beschriebenen Art, die bauartbedingt ressourcenbeschränkt sind, von immenser Bedeutung und kann die Herstellung solcher Sicherheitselemente vereinfachen und wirtschaftlicher erfolgen lassen.
Gemäß einer ersten bevorzugten Ausführungsform ist die Installationseinrichtung als vertrauenswürdige Instanz ausgebildet, insbesondere als so genannter„Trusted Service Manager", im Folgenden kurz mit TSM bezeichnet. Eine solche Instanz ist eingerichtet, als Dienstleister die zu installierende Applikation von einem Auftraggeber entgegenzunehmen und den Installati- onsprozess in kryptographisch gesicherter Weise durchzuführen. Vor dem Schritt des Installierens der Applikation in dem Sicherheitselement werden dazu kryptographische Schlüssel zwischen der vertrauenswürdigen Instanz und einem Besitzer des Sicherheitselements ausgetauscht. Mittels dieser Schlüssel kann der Installationsprozess dann kryptographisch gesichert werden.
Gemäß einer zweiten bevorzugten Ausführungsform umfasst die Installationseinrichtung eine so genannte Auftraggeber-Schnittstelle. Über diese Schnittstelle können Anfragen bzw. Aufträge betreffend die Installation einer Applikation auf einem Sicherheitselement entgegengenommen und/ oder an eine weitete, gleichartige Installationseinrichtung weitergeleitet werden. Eine solche Anfrage kann sich dabei auf eine Applikation beziehen, die bereits bei der Installationseinrichtung vorliegt. Ein Installationsauftrag kann alternativ zusammen mit der zu installierenden Applikation an die Installationseinrichtung gestellt werden, d.h. der Auftraggeber liefert mit dem Auftrag auch die zu installierende Applikation. Die Auftraggeber-Schnittstelle kann technisch auf verschiedene Arten ausgebildet sein, beispielsweise in Form eines Webs- ervices. Über die Auftraggeber-Schnittstelle können insbesondere ein Hersteller und/ oder Herausgeber des Sicherheitselements, aber auch berechtigte Dritte, das Sicherheitselement verwalten, beispielsweise ein Nutzer des Endgeräts, in welches das Sicherheitselement integriert ist. Die Auftraggeber-Schnittstelle kann weiterhin dazu dienen, auf einem Sicherheitselement installierbare Applikationen von einem Applikationsanbieter oder -entwickler entgegenzunehmen, ohne dass ein Installationsauftrag daran gebunden ist. Auf diese Weise können beliebige Entwickler die von ihnen entworfenen Applikationen zur Installation auf einem Sicherheitsele- ment über die Installationseinrichtung bereitstellen. Die bloße Entgegennahme von installierbaren Applikationen kann allerdings auch auf anderem Weg erfolgen.
Die beiden genannten Ausführungsformen können vorteilhaft kombiniert werden, d.h. ein TSM kann eine Auftraggeber-Schnittstelle umfassen.
Eine auf einem Sicherheitselement installierbare oder zu installierende Applikation wird der Installationseinrichtung in der Regel in Form eines interpretierbaren Zwischencodes, vorzugsweise eines Byte-Codes, beispielsweise als Java- oder JavaCard-Bytecode bereitgestellt. Es ist aber auch möglich, dass die Applikation in Form eines Quell-Codes in einer höheren Programmiersprache bereitgestellt wird. Für eine erfindungsgemäße Installation einer Applikation in dem Sicherheitselement ist es nicht erforderlich, dass eine gleichwirkende Applikation, beispielsweise in Form interpretierbaren Programmcodes oder als Quell-Code, bereits in dem Sicherheitselement vorliegt.
Der Schritt des Abfragens der Konfiguration des Sicherheitselements kann verschiedene Teilschritte umfassen. Vorzugsweise wird seitens der Installationseinrichtung zuerst abgefragt, ob das Sicherheitselement eine Installation von direkt durch einen Prozessor des Sicherheitselements ausführbaren Programmcodes überhaupt erlaubt. Falls diese nicht der Fall ist, stellt die Installationseinrichtung solchen der Applikation zugeordneten Programmcode bereit, welcher durch einen Interpreter des Sicherheitselements, insbesondere durch eine Virtuelle Maschine, ausgeführt werden kann. Im anderen Fall, in dem das Sicherheitselement ein Installieren von Maschinencode unterstützt, werden weitere Abfragen getätigt, um die Erzeugung und Bereitstellung des direkt auf dem Prozessor des Sicherheitselements ausführbaren Programm- codes zu ermöglichen.
Der Schritt des Abfragens der Konfiguration des Sicherheitselements umfasst dann in der Regel weiter die Teilschritte des Abfragens einer Hardware- Konfiguration des Sicherheitselements sowie des Abfragen einer Software- Konfiguration des Sicherheitselements.
Hinsichtlich der Hardware-Konfiguration werden dabei sämtliche Parameter betrachtet, welche die Ausführbarkeit des zu erzeugenden Programmcodes auf einem Prozessor des Sicherheitselements beeinflussen können. Dies sind neben dem Prozessor selbst beispielsweise auch vorhandene Coprozessoren, Sensoren oder dergleichen.
Die Softwareausstattung des Sicherheitselements wird ebenfalls hinsichtlich aller erheblichen Faktoren untersucht, insbesondere hinsichtlich auf dem Si- cherheitselement bereitgestellter Daten, Bibliotheken, Software- Funktionalitäten und Programmierschnittstellen.
Schließlich können Auf ruf adressen von durch das Sicherheitselement bereit- gestellten Funktionen abgefragt werden. Dies betrifft sowohl beispielsweise Aufrufadressen von Funktionen einer API („Application Programming Interface") als auch Funktionen anderer, bereits auf dem Sicherheitselement installierter Applikationen. Der Schritt des Bereitstellens eines der Applikation zugeordneten, auf dem Sicherheitselement ausführbaren Programmcodes kann folgende Teilschritte umfassen.
Auf Basis der abgefragten Hardware- und Software-Konfiguration des Si- cherheitselements wird ein der Applikation zugeordneter Objekt-Code erzeugt. Dies geschieht mittels eines geeigneten, der Hardware-Konfiguration zugeordneten Compilers. Alternativ kann ein Objekt-Code auch bereits vorab, für alle der Installationseinrichtung vorliegenden Compiler, erzeugt werden. Im Schritt des Bereitstellens wird dann derjenige vorab erzeugte Objekt- Code ausgewählt, welcher zu der abgefragten Hard- und Software- Konfiguration kompatibel ist.
Zum Erstellen des für das Sicherheitselement spezifischen, auf dem Prozessor des Sicherheitselements direkt ausführbaren Programmcodes wird an- schließend der erzeugte oder ausgewählte Objekt-Code mit Bezug auf die genannten, abgefragten Aufrufadressen von durch die Applikation verwendeten, durch das Sicherheitselement bereitgestellten Funktionen gelinkt. Diese Vorgehensweise ermöglicht es der Installationseinrichtung, auf das Sicherheitselement zugeschnittenen, auf dem Prozessor des Sicherheitselements direkt ausführbaren Programmcode auf einfache Weise zu erzeugen. Der passende Compiler wird abhängig von der erfragten Hardware- Konfiguration ausgewählt. Da die beim Linken aufzulösenden Aufrufadressen im Objekt-Code jeweils explizit abgefragt worden sind - dieser Schritt erfolgt vorzugsweise erst nach dem Erzeugen des Objekt-Codes, um nur die dort referenzierten Aufrufadressen abfragen zu müssen -, können verschiedene Spezifika, beispielsweise betreffend ein Betriebssystem des Sicherheit- selements oder dergleichen, bei der Erstellung des ausführbaren Programmcodes außer Acht gelassen werden. Dies ist insbesondere in der Variante des Verfahrens relevant, in der Objekt-Code für verschiedene Hardware- Plattformen vorab erzeugt wird, da die Anzahl der herzustellenden, verschiedenen Objekt-Codes beschränkt werden kann - wegen der fehlenden Abhängigkeit derselben von den genannten Spezifika.
Wie erwähnt, wird die Installationseinrichtung im Schritt des Bereitstellens bzw. Erzeugens eines der Applikation zugeordneten, auf dem Sicherheitselement ausführbaren Programmcodes durch verschiedene Werkzeuge un- terstützt, insbesondere durch an das jeweilige Sicherheitselement angepasste Compiler- und/ oder Linker-Funktionalitäten. Diese werden bevorzugt von einem Hersteller des Sicherheitselements und/ oder einem Herstellen des portablen Endgeräts bereitgestellt. Dadurch können sämtliche Funktionalitäten des Sicherheitselements optimal unterstützt und sämtliche Ressourcen optimal ausgenutzt werden. Dies gilt, da insbesondere der Hersteller des Sicherheitselements, der die Hardwareausstattung und zumindest anfangs auch die Softwareausstattung des Sicherheitselements vorgibt, einen Compiler optimal darauf abstimmen kann, insbesondere auch hinsichtlich bereits in dem Sicherheitselement vorliegender Ressourcen, wie z.B. Daten, Bibliotheken oder dergleichen.
Die Installationseinrichtung kann die Applikation prüfen, vorzugsweise vor dem Schritt des Bereitstellens eines der Applikation zugeordneten, auf dem Sicherheitselement ausführbaren Programmcodes. Mittels eines solchen Prüfschrittes kann sichergestellt werden, dass kein schadhafter, funktionsunfähiger und/ oder schadenverursachender Programmcode installiert wird oder dass unbefugte Dritte Programmcode in das Sicherheitselement einschleusen.
Eine Prüfung kann jeweils verschiedene Aspekte betreffen, beispielsweise die Einhaltung technischer Spezifikationen sowie die Frage, ob die Applikation Schadcode umfasst. Andere Sicherheitsaspekte, beispielsweise die Anfälligkeit der Applikation gegenüber bekannten Angriffen auf Sicherheitselemente, beispielsweise so genannten Seitenkanalangriffen, können alternativ oder zusätzlich geprüft werden.
Weiter kann eine Prüfung hinsichtlich Integrität und/ oder Authentizität der Applikation stattfinden, um das Installieren fremden oder veränderten Programmcodes zu verhindern. Dazu können bekannte Methoden verwendet werden, beispielsweise Prüf summen, so genannte„Message Authentication Codes" bzw. Zertifikate, beispielsweise basierend auf einer asymmetrischen Schlüsselarchitektur.
Die Prüfung kann aber in gleicher Weise auch durch eine externe
Prüfinstanz, beispielsweise eine Softwarezertifizierungsstelle, einen Herausgeber des Sicherheitselements, einen Applikationsanbieter oder ähnliche Instanzen erfolgen. Ein Entwickler kann dazu die Applikation, bevor er diese über die Installationseinrichtung bereitstellt, der Prüfinstanz oder Zertifizierungsstelle vorlegen. Diese Stelle prüft die Applikation nach vorgegebenen Prüfkriterien und versieht die Applikation, nach erfolgreicher Prüfung, mit einem entsprechenden Zertifikat.
Im dem Fall, dass die Applikation, wenn sie von der Installationseinrichtung empfangen wird, bereits ein solches Zertifikat einer Zertifizierungsstelle um- fasst, kann der Schritt des Prüfens durch die Installationseinrichtung lediglich im Verifizieren des Zertifikats bestehen. Die Installationseinrichtung kann aber auch bei Vorliegen des Zertifikats alternativ oder zusätzlich eigene Prüfungen vornehmen.
Als portable Endgeräte eignen im Zusammenhang mit der vorliegenden Erfindung insbesondere Mobilfunkendgeräte, Smartphones, Tablet-Computer, Netbooks, Notebooks, intelligente Multimediageräte (Smart TV, Set-Top-Box, etc.), Smart Meter oder dergleichen, welche eingerichtet sind, ein Sicherheitselement der beschriebenen Art aufzunehmen, oder in die ein derartiges Sicherheitselement bereits fest eingebaut oder implementiert ist. Die vorliegende Erfindung wird nachfolgend mit Bezug auf die beiliegenden Zeichnungen beispielhaft beschrieben. Darin zeigen:
Figur 1 Schritte einer bevorzugten Ausführungsform eines Verfahrens zur Installation einer Applikation in einem Sicherheitselement eines portablen Endgeräts und
Figur 2 an dem Verfahren beteiligte Instanzen sowie deren wesentliche
Komponenten. Eine Installationseinrichtung 30, welche ein im Folgenden beschriebenes Installationsverfahren unterstützt, wird beispielhaft als sogenannter„Trusted Service Manager" beschrieben. Ein solcher„Trusted Service Manager" (TSM) ist eine vertrauenswürdige Instanz, welche eine Installation einer Applikati- on in einem Sicherheitselement 42 eines portablen Endgeräts 40 in krypto- graphisch gesicherter Weise durchführen kann. Dazu verwaltet der TSM entsprechende kryptographische Schlüssel, welche zuvor mit einem Besitzer des Sicherheitselements 42 ausgetauscht worden sind. In Rahmen des nachfolgend beschriebenen Verfahrens ist gleichfalls eine Installationseinrichtung 30 verwendbar, welche nicht als TSM ausgebildet ist, solange nicht die TSM- spezifischen Merkmale, d.h. das kryptographische Sichern der Installation mittels dazu vorgesehener Schlüssel, betroffen ist.
Ziel des mit Bezug auf Fig. 1 beschriebenen Verfahrens ist es, für jeweils ver- schiedene Sicherheitselemente 42, insbesondere für Sicherheitselemente 42 verschiedener Hersteller 20, Applikationen in einer auf dem jeweiligen Prozessor 44 des Sicherheitselements 42 direkt ausführbaren Form bereitzustellen, d.h. als an den jeweiligen Prozessor 44 angepassten Maschinencode. Dazu ist es erforderlich, dass der TSM 30 die entsprechenden Werkzeuge zum Herstellen dieses ausführbaren Programmcodes besitzt.
Wie mit Bezug auf Schritt Sl angedeutet, werden dem TSM entsprechende Compiler- und Linker-Funktionalitäten von verschiedenen Herstellern 20 verschiedener Sicherheitselemente 42 zur Verfügung gestellt. Auch Herstel- 1er von portablen Endgeräten 40 mit darin integrierten Sicherheitselementen 42 können Compiler- und Linkerfunktionalitäten bereitstellen. Die Installationseinrichtung 30 kann die verschiedenen, empfangenen Compiler und Linker beispielsweise in einer Compiler- und Linker-Datenbank zusammenstellen, jeweils verknüpft mit der Information, für welches Sicherheitselement 42, d.h. für welche Hardware-Plattform, der entsprechende Compiler und Linker jeweils verwendbar ist.
In einem unabhängigen zweiten Schritt S2 stellt ein Applikationsentwickler 10 der Installationseinrichtung 30 eine Applikation 50 bereit. Dieser Schritt kann von demselben Entwickler 10 und/ oder anderen Entwicklern mit verschiedenen Applikationen wiederholt werden, so dass bei der Installationseinrichtung 30 verschiedene, in einem Sicherheitselement 42 installierbare Applikationen vorliegen können. In der Regel werden solche Applikationen in einem durch einen Interpreter ausführbaren Code, beispielsweise als Javaoder JavaCard-Bytecode, bereitgestellt. Es ist gleichfalls möglich, dass die Applikation in Form eines Quellcodes einer höheren Programmiersprache, beispielsweise in„C" oder Java, bereitgestellt wird. In einem dritten Schritt S3 compiliert die Installationseinrichtung 30 sämtliche dort vorliegenden Applikationen jeweils mittels sämtlicher in der Compiler Datenbank vorliegender Compiler. Die entsprechenden Applikationen liegen nun in Form von Objekt-Code vor, welcher auf die entsprechenden Hardwareplattformen angepasst ist, dort aber noch nicht ausgeführt werden kann, da beispielsweise in dem Sicherheitselement vorliegende Funktionalitäten, die von dem der Applikation entsprechenden Objekt-Code referenziert werden, erst noch korrekt verlinkt werden müssen.
In einem vierten Schritt S4 empfängt die Installationseinrichtung 30 eine An- frage hinsichtlich der Installation einer konkreten Applikation 50 in einem konkreten Sicherheitselement 42. Die Anfrage wird in dem vorliegenden Beispiel von dem portablen Endgerät 40 initiiert, in welches das Sicherheitselement 42 integriert ist. Zur Entgegennahme dieses Auftrags umfasst die Installationseinrichtung 30 eine Auftraggeber-Schnittstelle 32 (vgl. Fig.2). Über diese Schnittstelle können Aufträge betreffend die Installation einer Applikation auf einem Sicherheitselement entgegengenommen sowie an eine weitere, gleichartige Installa- tionseinrichtung 30' weitergegeben werden, wie dies in Fig.2 angedeutet und nachfolgend noch detailliert beschrieben wird.
Aufträge für eine Installation einer Applikation auf einem Sicherheitselement 42 können die Installationseinrichtung 30 von verschiedenen Stellen errei- chen, beispielsweise von dem Hersteller 20 oder Herausgeber 20' des Sicherheitselements. Aber auch berechtigte Dritte können entsprechende Aufträge erteilen, wie im vorliegenden Beispiel der Besitzer des Endgeräts sowie ein Dienstleister, mit welchem der Besitzer des Sicherheitselements in Beziehung steht, beispielsweise ein Applikationsanbieter, ein Kreditkartenanbieter oder dergleichen. Jeder solche Auftrag beinhaltet in der Regel eine Information, mit welcher das Sicherheitselement, auf welchem die bezeichnete Applikation installiert werden soll, genau zu identifizieren ist, beispielsweise eine eindeutige Seriennummer, oder dergleichen, sowie eine Angabe betreffend die zu installierende Applikation.
Wie im vorliegenden Beispiel gezeigt, kann sich eine Anfrage hinsichtlich der Installation einer Applikation auf eine bereits bei der Installationseinrichtung 30 vorliegende Applikation beziehen. Alternativ kann zusammen mit einem solchen Auftrag die zu installierende Applikation mitgeliefert werden. Mit anderen Worten kann die vorstehend genannte Angabe betreffend die zu installierende Applikation diese entweder eindeutig bezeichnen oder aber unmittelbar umfassen. Um den Installationsauftrag ausführen zu können, fragt die Installationseinrichtung 30 in Schritt S5 zuerst die Hardwarekonfiguration des Sicherheitselements 42 ab. Dazu wird eine Datenkommunikationsverbindung zwischen der Installationseinrichtung 30 und dem Sicherheitselement 42 auf ge- baut. Die Datenkommunikationsverbindung wird über eine Installationsschnittstelle 34 (vgl. Fig. 2) der Installationseinrichtung 30 aufgebaut.
Abhängig von den durch das Sicherheitselement 42 zurückgelieferten Konfigurationsdaten, welche beispielsweise den Prozessor 44 des Sicherheitsele- ments 42 sowie eventuell vorhandene weitere Leistungsmerkmale, wie beispielsweise verschiedene Coprozessoren, Sensoren, oder dergleichen betreffen, kann die Installationseinrichtung 30 den für das spezifische Sicherheitselement 42 passenden Objekt-Code auswählen. Dieser ist bereits vorab, wie beschrieben, in Schritt S3 durch Compilieren der in Schritt S2 bereitgestellten Applikation 50 erzeugt worden, wobei ein für die abgefragte Hardwarekonfiguration passender Compiler verwendet worden ist.
Mittels einer ebenfalls in Schritt S5 abgefragten Softwarekonfiguration des Sicherheitselements 42 stellt die Installationseinrichtung 30 sicher, dass der ausgewählte Objekt-Code kompatibel mit dem Sicherheitselement 42 ist. Die Softwarekonfiguration betrifft sämtliche Aspekte der Softwareausstattung des Sicherheitselements, welche bei der Auswahl des Objekt-Codes zu berücksichtigen sind, beispielsweise die korrekte Version einer entsprechenden API oder dergleichen.
Mit dem in Schritt S6 ausgewählten Objekt-Code stehen nun sämtliche für das Linken erforderlichen Funktionen fest. In Schritt S7 fragt die Installationseinrichtung daher die entsprechenden Aufrufadressen dieser Funktionen bei dem Sicherheitselement ab, um im nachfolgenden Schritt S8 des Linkens die in dem Objekt-Code verbleibenden Referenzen auflösen zu können.
Die Abfrage in Schritt S7 erlaubt es der Installationseinrichtung 30, weitere Spezifika des Sicherheitselements 42, beispielsweise ein darauf installiertes Betriebssystem, zu ignorieren. Weiterhin kann diese Abfrage nicht lediglich API-Funktionen betreffen, sondern auch solche Funktionen, die durch andere, bereits auf dem Sicherheitselement 42 vorliegende Applikationen bereitgestellt werden.
Optional kann das Sicherheitselement in diesem Schritt bereits die Speicheradresse ermitteln, an welcher der der Applikation entsprechende ausführbare Programmcode nachfolgend, bei der Installation in Schritt S10, abgelegt werden wird. Dies ermöglicht im nachfolgenden Schritt S8 nicht lediglich ein Linken des Objekt-Codes, sondern auch eine Relokation.
Wie erwähnt, wird in Schritt S8 der in Schritt S6 ausgewählte Objekt-Code in Kenntnis der in Schritt S7 abgefragten Aufruf adressen gelinkt. In Schritt S9 überträgt die Installationseinrichtung 30 den wie vorstehend beschrieben erzeugten, der Applikation 50 zugeordneten ausführbaren Programmcode an das Sicherheitselement 42. In dem Sicherheitselement 42 wird der Programmcode schließlich installiert. Das Sicherheitselement 42 kann dazu eine entsprechende Lade- oder Installationsfunktionalität umfassen.
Es versteht sich, dass einzelne Schritte des beschriebenen Verfahrens in unterschiedlicher Reihenfolge ausgeführt werden können. Es ist beispielsweise möglich, dass eine der Installationseinrichtung 30 bereitgestellte Applikation 50 nicht direkt nach Empfang für eine oder mehrere Hardwareplattformen compiliert wird. Der Schritt S3 des Compilierens kann beispielsweise erst in Reaktion auf einen entsprechenden Auftrag zur Installation der Applikation 50 in einem konkreten Sicherheitselement 42 erfolgen. Das heißt, die Installationseinrichtung 30 fragt die mit Bezug auf Schritt S5 beschriebene Hard- wäre- und Softwarekonfiguration des betreffenden Sicherheitselements 42 ab und erzeugt erst daraufhin den entsprechenden Objekt-Code für das Sicherheitselement 42. Weiterhin ist es beispielsweise möglich, dass die Installationseinrichtung 30 erst dann eine entsprechende Compilerfunktionalität bei einem Hersteller 20 des Sicherheitselements 42 anfordert.
Gemäß einer Variante des vorstehend beschriebenen Verfahrens, kann die Installationseinrichtung 30 in Schritt S5 zuerst von dem Sicherheitselement 42 erfragen, ob dieses prinzipiell eine Installation von auf dem Prozessor 44 des Sicherheitselements 42 direkt ausführbaren Programmcodes erlaubt. Ist dies nicht der Fall, so können die Schritte S6 bis S8 unterbleiben. Anstelle eines auf den Prozessor 44 des Sicherheitselements 42 zugeschnittenen Maschinencodes überträgt die Installationseinrichtung in Schritt S9 dann lediglich solchen der Applikation 50 zugeordneten Code, welcher von einem Interpreter des Sicherheitselements 42 interpretierbar ist, beispielsweise einer virtuellen Maschine. In dem Fall, dass die Applikation 50 der Installationseinrichtung 30 bereits in entsprechender Form (in Schritt S2) bereitgestellt worden ist, ist in Schritt S3 nichts zu tun. Falls die Applikation allerdings lediglich als Quell-Code vorliegt, so ist in Schritt S3 zumindest der interpretierbare Code zu erzeugen.
In gleicher Weise kann die Installationseinrichtung 30 vorgehen, wenn sie erkennt, dass ihr kein Compiler vorliegt, welcher der in Schritt S5 von dem Sicherheitselement 42 abgefragten Hardwarekonfiguration zuzuordnen ist, und ein solcher auch nicht zu beschaffen ist. In einem solchen Fall steht der Installationseinrichtung 30 weiterhin der Weg offen, den Installationsauftrag an eine solche Installationseinrichtung 30' (vgl. Fig. 2) weiterzuleiten, welche eine der Hardwarekonfiguration des Sicherheitselements 42 angepasste Compilerfunktionalität besitzt. Dies könnte beispielsweise ein entsprechen- der TSM sein, welcher dem Hersteller 20 des betreffenden Sicherheitselements 42 zugeordnet ist.
Diese weitere Installationseinrichtung 30' könnte dann - anstelle der zuerst aufgerufenen Installationseinrichtung 30 - den Installationsauftrag überneh- men und in der vorstehend beschriebenen Weise ausführen. Dazu eventuell notwendige kryptographische Schlüssel, mittels welcher die Installation gesichert werden kann, könnten in dem exemplarisch beschriebenen Fall, dass die weitere Installationseinrichtung 30' von einem Hersteller 20 des Sicherheitselements 42 betrieben wird, bei der weiteren Installationseinrichtung 30' bereits aufgrund des Herstellerbezugs vorliegen. Das heißt, das Sicherheitselement 42 wird bereits bei der Herstellung mit entsprechenden, eigens dem Hersteller zugeordneten kryptographischen Schlüsseln ausgestattet. Diese kryptographischen Schlüssel unterscheiden von denjenigen kryptographischen Schlüsseln, welche ein späterer Besitzer des Sicherheitselements 42 mit der Installationseinrichtung 30 vereinbart, sind aber gleichfalls zur Sicherung einer Applikationsinstallation verwendbar, wenn diese von einer dem Hersteller zugeordneten, weiteren Installationseinrichtung 30'durchgeführt wird. Gängige weitere Sicherheitsmaßnahmen, welche eine Datenkommunikation zwischen zwei Parteien über ein ungesichertes Kommunikationsnetzwerk sichern können, wie beispielsweise eine verschlüsselte Datenübertragung, die Verwendung von Signaturen sowie eine gegenseitige Authentisierung der Kommunikationspartner, können selbstverständlich die vorstehend be- schriebenen Verfahren weiter schützen, werden jedoch hier nicht im Detail beschrieben.
Als zusätzliche Sicherheitsmaßnahme kann die Installationseinrichtung 30 eine von einem Applikationsanbieter oder -entwickler 10 sowie einem weiteren Auftraggeber 20, 20' empfangene Applikation 50 hinsichtlich verschiedener Aspekte prüfen, bevor diese Applikation 50 für eine Installation auf einem Sicherheitselement 42 aufbereitet wird. Die Prüfung kann beispielsweise die Wahrscheinlichkeit abschätzen, ob die Applikation Schadcode umfasst, beispielsweise mittels einer standardmäßigen Bytecode- Verifikation oder dergleichen. Weiter kann die Applikation hinsichtlich Integrität und/ oder Authentizität untersucht werden. Alternativ ist es möglich, dass die Applikation, bevor sie der Installationseinrichtung bereitgestellt wird, von einer externen Stelle nach vorgegebenen Prüfkriterien geprüft wird. Eine solche Prüfung kann mittels eines Zertifikats, welches der Applikation 50 beigefügt wird, dokumentiert werden. Eine Prüfung der Installationseinrichtung 30 kann sich dann auf eine Prüfung des Zertifikats beschränken.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zur Installation einer Applikation (50) in einem Sicher heit- selement (42) eines portablen Endgeräts (40), umfassend die Schritte:
Abfragen (S5, S7) einer Konfiguration des Sicherheitselements (42) durch eine Installationseinrichtung (30);
Bereitstellen (S3, S6, S8) eines der Applikation (50) zugeordneten, auf dem Sicherheitselement (42) ausführbaren Programmcodes in Abhän- gigkeit der abgefragten Konfiguration durch die Installationseinrichtung (30);
Übertragen (S9) des ausführbaren Programmcodes an das Sicherheitselement (42) durch die Installationseinrichtung (30);
Installieren (S10) des ausführbaren Programmcodes in dem Sicherheits- element (30).
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Installationseinrichtung (30) als vertrauenswürdige Instanz vorgesehen ist, welche kryptographische Schlüssel umfasst, wobei die Installation der Applikation (50) in dem Sicherheitselement (42) mittels der kryptographischen Schlüssel gesichert wird.
3. Verfahren nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass die Installationseinrichtung (30) eine Auftraggeber- Schnittstelle umfasst und einen Auftrag betreffend die Installation der Applikation (50) in dem Sicherheitselement (42) über die Auftraggeber- Schnittstelle entgegennimmt.
4. Verfahren nach einem der Ansprüche 1 bis 3, gekennzeichnet durch den Schritt des Bereitstellens (S2) der Applikation für die Installationseinrichtung (30) durch einen Applikationsanbieter (10).
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Applikation (50) in Form eines Quell-Codes in einer höheren Programmiersprache oder in Form eines interpretierbaren Zwischencodes, vorzugsweise eines Byte-Codes, bereitgestellt wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass der Schritt des Abfragens der Konfiguration des Sicherheitselements (42) zumindest einen der folgenden Teilschritte umfasst:
Abfragen, ob das Sicherheitselement (42) eine Installation von direkt durch einen Prozessor (44) des Sicherheitselements (42) ausführbaren Programmcodes erlaubt;
Abfragen (S5) einer Hardware-Konfiguration des Sicherheitselements (42);
Abfragen (S5) einer Software-Konfiguration des Sicherheitselements (42);
Abfragen (S7) von Aufrufadressen von durch das Sicherheitselement (42) bereitgestellten Funktionen.
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass der Schritt des Bereitstellens eines der Applikation zugeordneten, auf dem Si- cherheitselement (42) ausführbaren Programmcodes zumindest einen der folgenden Teilschritte umfasst:
Erstellen (S3) eines der Applikation zugeordneten Objekt-Codes in Abhängigkeit von der abgefragten Hardware-Konfiguration des Sicherheitselements (42); Linken (S8) des Objekt-Codes mit Bezug auf abgefragte Aufrufadressen von durch die Applikation (50) verwendeten, durch das Sicherheitselement (42) bereitgestellten Funktionen zum Erstellen eines für das Sicherheitselement (42) spezifischen, auf einem Prozessor (44) des Si- cherheitselements (42) ausführbaren Programmcodes.
8. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass im Schritt des Bereitstellens eines der Applikation (50) zugeordneten, auf dem Sicherheitselement (42) ausführbaren Programmcodes in dem Fall, dass das Si- cherheitselement (42) eine Installation von direkt auf einem Prozessor (44) des Sicherheitselements (42) ausführbaren Programmcodes nicht erlaubt, solcher der Applikation (50) zugeordneter Programmcode bereitgestellt wird, welcher durch einen Interpreter des Sicherheitselements (42) ausgeführt werden kann.
9. Verfahren nach einem Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Installationseinrichtung (30) in dem Schritt des Bereitstellens eines der Applikation (50) zugeordneten, auf dem Sicherheitselement (42) ausführbaren Programmcodes durch Werkzeuge unterstützt wird, welche ihr von einem Hersteller (20) des Sicherheitselements (42) und/ oder einem Hersteller des portablen Endgeräts (40) bereitgestellt worden sind, insbesondere an das Sicherheitselement (42) angepasste Compiler- und/ oder Linker- Funktionalitäten.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass das Übertragen des der Applikation (50) zugeordneten Programmcodes an das Sicherheitselement (42) über eine Luftschnittstelle erfolgt.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass die Installationseinrichtung (30) einen Auftrag zur Installation der Applikation (50) auf dem Sicherheitselement (42) an eine weitere Installationseinrichtung weiterleitet, wobei die weitere Installationseinrichtung einge- richtet ist, ein Verfahren nach einem der Ansprüche 1 bis 10 zu unterstützen.
12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass die Installationseinrichtung (30) die Applikation (50) prüft, vorzugsweise vor dem Schritt des Bereitstellens eines der Applikation (50) zu- geordneten, auf dem Sicherheitselement (42) ausführbaren Programmcodes, insbesondere hinsichtlich Integrität und Authentizität, einzuhaltender technischer Spezifikationen und/ oder Sicherheitsaspekten.
13. Installationseinrichtung (30), welche eingerichtet ist, ein Verfahren zur Installation einer Applikation (50) in einem Sicherheitselement (42) eines portablen Endgeräts (40) nach einem der Ansprüche 1 bis 12 durchzuführen.
14. Installationseinrichtung (30) nach Anspruch 13, dadurch gekennzeichnet, dass die Installationseinrichtung (30) als vertrauenswürdige In- stanz, insbesondere als„Trusted Service Manager", ausgebildet ist, welche eingerichtet ist, kryptographische Schlüssel zu verwalten, mittels derer eine Installation einer Applikation (50) in einem Sicherheitselement (42) krypto- graphisch gesichert werden kann.
15. Installationseinrichtung (30) nach einem der Ansprüche 13 oder 14, gekennzeichnet durch eine Auftraggeber-Schnittstelle, über welche Aufträge betreffend die Installation einer Applikation (50) auf einem Sicherheitselement (42) entgegengenommen und/ oder an eine weitere Installationseinrichtung weitergeleitet werden können.
PCT/EP2013/003500 2012-11-22 2013-11-20 Installation einer applikation auf dem sicherheitselement eines portable datenträgers Ceased WO2014079563A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102012022874.0A DE102012022874A1 (de) 2012-11-22 2012-11-22 Applikationsinstallation
DE102012022874.0 2012-11-22

Publications (1)

Publication Number Publication Date
WO2014079563A1 true WO2014079563A1 (de) 2014-05-30

Family

ID=49713049

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/003500 Ceased WO2014079563A1 (de) 2012-11-22 2013-11-20 Installation einer applikation auf dem sicherheitselement eines portable datenträgers

Country Status (2)

Country Link
DE (1) DE102012022874A1 (de)
WO (1) WO2014079563A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015004319B4 (de) * 2015-04-01 2024-07-11 Giesecke+Devrient Mobile Security Germany Gmbh Verfahren zum Unterstützen einer Installation einer Applikation
WO2018219490A1 (en) * 2017-06-02 2018-12-06 Giesecke+Devrient Mobile Security Gmbh Method for preparing instructions to be executed by a subscriber identity module, subscriber identity module and service providing system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1703382A1 (de) * 2005-03-16 2006-09-20 Sun Microsystems, Inc. Verfahren zum Laden von Anwendungen in ein mobiles Gerät
DE102011015710A1 (de) * 2011-03-31 2012-10-04 Giesecke & Devrient Gmbh Verfahren zum Aktualisieren eines Datenträgers

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8645934B2 (en) * 2010-05-06 2014-02-04 International Business Machines Corporation Simultaneous compiler binary optimizations
US8239918B1 (en) * 2011-10-11 2012-08-07 Google Inc. Application marketplace administrative controls

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1703382A1 (de) * 2005-03-16 2006-09-20 Sun Microsystems, Inc. Verfahren zum Laden von Anwendungen in ein mobiles Gerät
DE102011015710A1 (de) * 2011-03-31 2012-10-04 Giesecke & Devrient Gmbh Verfahren zum Aktualisieren eines Datenträgers

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
RAJA NAEEM AKRAM ET AL: "Application Management Framework in User Centric Smart Card Ownership Model", 25 August 2009, INFORMATION SECURITY APPLICATIONS, SPRINGER BERLIN HEIDELBERG, BERLIN, HEIDELBERG, PAGE(S) 20 - 35, ISBN: 978-3-642-10837-2, XP019136006 *

Also Published As

Publication number Publication date
DE102012022874A1 (de) 2014-05-22

Similar Documents

Publication Publication Date Title
DE102015209116A1 (de) Verfahren und Aktualisierungsgateway zum Aktualisieren eines eingebetteten Steuergerätes
EP2692157B1 (de) Verfahren und vorrichtung zur aktualisierung einer datenträgerapplikation
DE102014102168A1 (de) Verfahren und System zum Erstellen und zur Gültigkeitsprüfung von Gerätezertifikaten
DE102013108020A1 (de) Authentifizierungsschema zum Aktivieren eines Spezial-Privileg-Modus in einem gesicherten elektronischen Steuergerät
DE102015209108A1 (de) Verfahren und Entscheidungsgateway zum Autorisieren einer Funktion eines eingebetteten Steuergerätes
DE102013108022A1 (de) Verfahren zum Aktivieren des Entwicklungsmodus eines gesicherten elektronischen Steuergeräts
WO2012130460A1 (de) Verfahren zum aktualisieren eines datenträgers
DE102012015573A1 (de) Verfahren zum Aktivieren eines Betriebssystems in einem Sicherheitsmodul
EP2885907B1 (de) Verfahren zur installation von sicherheitsrelevanten anwendungen in einem sicherheitselement eines endgerät
EP2673731B1 (de) Verfahren zur programmierung eines mobilendgeräte-chips
DE102021125851A1 (de) Problemmanagement in einem benutzersystem
DE102012022874A1 (de) Applikationsinstallation
EP2987078B1 (de) Verfahren zum bereitstellen einer applikation auf einem sicherheitsmodul sowie ein solches sicherheitsmodul
DE102010004786A1 (de) Verfahren zum rechnergestützten Bereitstellen einer Entwicklungsumgebung zur Implementierung von Sicherheitsanwendungen in einer Fahrzeug-Architektur
DE102018129354A1 (de) Verfahren zum Bearbeiten von Anwendungsprogrammen auf einem verteilten Automatisierungssystem
EP3329415B1 (de) Chipkarte mit hauptapplikation und persistenzapplikation erlaubt hauptapplikationupdate ohne die benutzerdaten im persistenzapplikation zu ändern
CN111209002B (zh) 程序包的开发部署方法、服务器及计算机可读存储介质
EP2569726B1 (de) Verfahren zum überprüfen, ob programmanweisungen von einem tragbaren endgerät ausgeführt wurden
Erdogan et al. Risk-driven Security Testing versus Test-driven Security Risk Analysis.
DE102012022875A1 (de) Verfahren und System zur Applikationsinstallation
CN106385318B (zh) 基于椭圆方程的sdk验证方法
EP3186740A1 (de) Verfahren zur installation einer zusätzlichen applikation in einem nicht-flüchtigen speicher einer chipkarte
EP3488375A1 (de) Chipset mit gesicherter firmware
DE102015207004A1 (de) Verfahren zum geschützten Zugriff auf Sicherheitsfunktionen eines Sicherheitsmoduls eines Hostsystems
DE102013016619A1 (de) Verfahren zum Erzeugen eines computerausführbaren Programms und Verfahren zur gesicherten Kommunikation zwischen zwei Computern

Legal Events

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

Ref document number: 13799483

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13799483

Country of ref document: EP

Kind code of ref document: A1