DE102007044905A1 - Method and device for enabling service usage and determination of subscriber identity in communication networks by means of software-based access authorization cards (vSIM) - Google Patents

Abstract

The present invention relates to an architecture for enabling service usage and discovery of subscriber identity using software-based Virtual Identity Module (vSIM) The architecture allows authorized entities access to an available communication network and the use of the Internet This architecture is hereafter referred to as "vSIM architecture." In particular, the substitutability of a conventional SIM card and its functionality are presented under equivalent properties. "In general, the vSIM architecture is trusted Operating system protected, which is based on a dedicated trust anchor and supports multiple separate and trusted execution environments, with one execution environment specific to an Inte assigned to representatives. The proposed basic architecture conforms to, but is not limited to, the TCG MPWG Reference Architecture [2] or TCG MPWG Specification [3]. It should be noted that the term trustworthiness in the context of this patent application is to be regarded as a measure which describes the state of an application and / or service. This state said that this application and / or this service statements about its integrity and correctness.

Description

1.1 scenario

The considered use case is in the 1 illustrates and considers four major entities: the device owner (DO) / local user (U), the mobile trusted platform (MTP), the network / service provider (MNO), and the point of sale (POS) Point-of-presence (POP).

In the scenario, DO / U intends a long-term relationship with the MNO (step 1 . 2 ; 1 ) in order to use a mobile communication network and the services offered therein (eg GSM, UMTS telephony, data services or special location-based services).

Instead of using a physical SIM card, the MNO populates the MTP with a software-based credential. (vSIM-Credential) (step 3 ; 1 ). The vSIM credential consists of one participant-related share and one user-related share. Each time a registered device user needs to initialize to the communication network, he first authenticates to the vSIM service using the user-related portion of the vSIM credential (step 4 ; 1 ). This service then uses, during the communication relationship, the subscriber-related portion of the vSIM network authentication credential (step 5 . 6 ; 1 ).

1.2 architecture of the vSIM platform

This section describes important components and services in the context of the vSIM architecture. In general, an MTP supports multiple protected and separate execution environments. Each environment represents an area associated with a stakeholder. 2 and 3 show the schematic structure of such a trusted vSIM platform.

The MTP implements a vSIM service (vSIM service) that is conventional smartcard-based SIM card and its functionality replaced. It should be noted that the vSIM service is (at least) three different Execution environments extends.

sufficient Prerequisites and basics for the implementation of the vSIM architecture Specifically provide the specifications [2, 3, 4, 5, 6, 7] of the Trusted Computing Group (TCG) [1].

1.2.1 stakeholders and security containers

It Four different stakeholders (sigma) are considered: the device manufacturer (DM), the network access and service provider (Mobile Network Operator, MNO), the device owner and the user (User, U).

One trusted subsystem TSS Sigma is considered a logical Entity resulting from the trusted execution environment (TE-Sigma) and the non-interchangeable security module (Trusted Module, TM) or the remote owner (RO) or stakeholders (Sigma) assigned instance of the security module (TM Sigma) exists.

• • Gerätehersteller-Subsystem (TSS-DM): Das TSS-DM ist für die Integrität, Konfiguration und Einrichtung des Geräts mit seinen eingebauten Hardwarekomponenten verantwortlich. Es stellt alle sicherheitskritischen Ressourcen eines Geräts zur Verfügung. Im Allgemeinen kontrolliert es sämtliche interne und externe Kommunikationen und sichert den Kommunikationskanal ab. Demzufolge werden alle Protokoll-Nachrichten eines TSS-Sigma's durch die Kommunikationsdienste des TSS-DM zu dessen Bestimmungsort geleitet.
• • Netzwerk- und Servicedienstleister-Subsystem (TSS-MNO): Alle subskriptions-abhängigen und teilnehmer-bezogenen Netzwerkanbieter-Dienste einer Plattform werden dem TSS-MNO zugeteilt. Dieses Subsystem ist für die Verwaltung und den Schutz des teilnehmer-bezogenen Anteils des VSIM-Credentials verantwortlich und führt die clientseitige Netzwerkauthentifikation eines Teilnehmers durch. Dafür stellt es den vSIM-Kerndienst (vSIM-CORE) zur Verfügung. Dieser kann insbesondere wesentliche Funktionalitäten (Teilnehmerauthentifikation) der konventionellen SIM substituieren, aber auch andere Authentifikationsmerkmale beherbergen. Es wird der Begriff vertrauenswürdiges Subsystem TSS-MNO als Synonym für ein vollständig ausgestattetes TSS-MNO verwendet, die den erforderlichen Dienst vSIM-CORE zur Verfügung stellt. Eine Kombination aus TSS-DM und TSS-MNO ist gegebenenfalls möglich.
• • Benutzer – Subsystem (TSS-U): Das TSS-U schützt sämtliche benutzerbezogene und private Informationen, insbesondere den zugeordneten Zugriffsberechtigungsausweis des Benutzers (benutzerbezogene Anteil des vSIM-Credentials). Es instantiiert den vSIM-Verwaltungsdienst (vSIM-MGMT). Dieser Dienst ist für die Verwaltung der Benutzerinformationen und Berechnung der Authentifizierungsantworten des lokalen Benutzers zuständig. Der Dienst vSIM-MGMT bietet dem Dienst vSIM-CORE ein internes Authentifizierungsorakel an. Damit ist es im Stande, nach Authentifizierungsanfragen (Challenges) einen Identitätsbeweis des lokalen Benutzers bereitzustellen.
• • Gerteeigentümer Subsystem (TSS-DO): Das TSS-DO instanziert den vSIM-Eigentümer-Verwaltungsdienst (vSIM-OwnMgmt). Dieser Dienst ist für die Verwaltung der Eigentümerinformationen und administrative Verwaltung, wie beispielsweise von lokalen Benutzern oder Dienstanbietern zuständig. Die Kombination aus TSS-DO und TSS-U ist in Einzelbenutzersystemen möglich.

In the following, various trustworthy subsystems of the architecture presented here are given by way of example. This includes the subsystems TSS-DM, TSS-MNO, TSS-DO and TSS-U of the stakeholders DM, MNO, DO and U:

• • Device Manufacturer Subsystem (TSS-DM): The TSS-DM is responsible for the integrity, configuration, and setup of the device with its built-in hardware components. It provides all the safety-critical resources of a device. In general, it controls all internal and external communications and secures the communication channel. Consequently, all protocol messages of a TSS sigma are routed through the communication services of the TSS-DM to its destination.
• • Network and Service Provider Subsystem (TSS-MNO): All subscription-dependent and subscriber-related network provider services of a platform are assigned to the TSS MNO. This subsystem is responsible for managing and protecting the subscriber-related portion of the VSIM credential and performs client-side network authentication of a subscriber. For this purpose it provides the vSIM core service (vSIM-CORE). This can in particular essential functionalities (Subscriber authentication) of the conventional SIM, but also accommodate other authentication features. The term trusted subsystem TSS-MNO is used as synonym for a fully equipped TSS MNO that provides the required service vSIM-CORE. A combination of TSS-DM and TSS-MNO may be possible.
• • User subsystem (TSS-U): The TSS-U protects all user-related and private information, in particular the user's assigned access authorization (user-related portion of the vSIM credential). It instantiates the vSIM Administration Service (vSIM-MGMT). This service is responsible for managing the user information and calculating the authentication responses of the local user. The vSIM-MGMT service provides the vSIM-CORE service with an internal authentication oracle. This makes it possible to provide authentication of the local user after authentication requests (challenges).
• • Device Owner Subsystem (TSS-DO): The TSS-DO instantiates the vSIM Owner Management Service (vSIM-OwnMgmt). This service is responsible for managing owner information and administrative management, such as by local users or service providers. The combination of TSS-DO and TSS-U is possible in single-user systems.

1.2.2 Basic platform assumptions

• 1. Eine mobile vertrauenswürdige Plattform (MTP) ist ein mobiles Endgerät (Mobile Station, MS) mit einem, zur Hardwareplattform, fest zugeordneten und nicht austauschbaren Sicherheitsmodul (Trusted Module, TM) (z. B. MTM [3], TPM [5]). In dem betrachteten Kontext der vSIM-Architektur ist die MTP nicht mit einem konventionellen Sicherheitstoken zur Teilnehmerauthentifikation (z. B. SIM-Karte [8]) zwingend ausgestattet.
• 2. Die MTP führt ein vertrauenswürdiges Betriebssystem aus. Die vertrauenswürdige Softwareschicht unterstützt mehrere voneinander getrennte vertrauenswürdige Subsysteme (TSS_SIGMA) mit geschützter und isolierter Ausführungs- und Speicherfunktionalität.
• 3. Jedes vertrauenswürdiges Subsystem (TSS_SIGMA) wird für kritische Sicherungsfunktionen verwendet. Es besteht aus einer vertrauenswürdigen Instanz des Sicherheitsmoduls (TM-SIGMA) und einer zugeordneten vertrauenswürdigen Ausführungsumgebung (Trusted Engine, TE_SIGMA) und vertrauenswürdigen Diensten (Trusted Service, TS_SIGMA).
• 4. Auf einer MTP existieren mindestens die drei vertrauenswürdigen Subsysteme TSS-DE, TSS-MNO, TSS-U im Auftrag der entfernten Eigentümer DE, MNO, U. Die Verfahren werden für ein Einzelbenutzer-System beschrieben. Der Geräte-Eigentümer DO und die Funktionalität des TSS-DO werden auf U bzw. TSS-U abgebildet.
• 5. Für jedes TSS-Sigma wurde ein geeignetes Verfahren zur Inbesitznahme des TSS-Sigma eines entsprechenden Interessensvertreters ausgeführt. Dadurch ist ein TSS- Sigma vollständig ausgestattet und im Sinne der vSIM-Architektur funktionsfähig.
• 6. Ein TSS-Sigma kann beliebige Daten signieren und verschlüsseln.
• 7. Ein TSS-U ist im Stande, für eine digitale Signatur geeigneten kryptographischen Schlüssel zu erzeugen, die ausschließlich für den bestimmten Plattform-Benutzer U zugänglich und benutzbar sind.
• 8. Ein TSS-MNO instanziert den Dienst vSIM-CORE. Dieser Dienst ist für die Kernfunktionalität der vSIM-Architektur verantwortlich. Insbesondere ist dieser Dienst einerseits für die sichere Speicherung und Verwendung der Teilnehmerdaten zuständig, als auch für die Teilnehmerauthentifikation gegenüber dem MNO.
• 9. Ein TSS-U instanziert den Dienst vSIM-MGMT. Dieser Dienst ist für das Benutzermanagement einer vSIM zuständig. Insbesondere ist dieser Dienst für die Verwaltung und das Management eines Geräte-Benutzers verantwortlich. Der in vSIM-Eigentümer-Verwaltungsdienst vSIM-OwnMGMT wird in vSIM-MGMT funktional abgebildet.
• 10. Der MNO bietet die erforderliche Funktionalität einer Public-Key-Infrastruktur, direkt oder indirekt an.
• 11. Der MNO besitzt ein Zertifikat Cert-MNO, daß von einer Zertifizierungsinstanz (Certification Authority, CA) ausgegeben wurde. Dieses Zertifikat verknüpft die Identität des MNO mit dem öffentlichen Schlüssel K-pub- MNO, der für die Überprüfung von digitalen Signaturen benötigt wird. Dieses Zertifikat ist für die MTP und sämtliche eingebetteten Dienstleistungen verfügbar.
• 12. Ein TSS-Sigma hat Zugriff auf einen vertrauenswürdigen Dienst RTV-Sigma. Dieser Dienst ist zuständig für die lokale Verifikation, zum Beispiel von definierten Systemzuständen, anhand von Referenzdaten.

This section considers the general platform assumptions that apply to the protocols idealized in Section 1.3 and Section 1.4:

• 1. A Mobile Trusted Platform (MTP) is a Mobile Station (MS) with a Trusted Module (TM) (e.g., MTM [3], TPM [5 ]). In the considered context of the vSIM architecture, the MTP is not necessarily equipped with a conventional security token for subscriber authentication (eg SIM card [8]).
• 2. The MTP runs a trusted operating system. The trusted software layer supports multiple, separate trusted subsystems (TSS_SIGMA) with protected and isolated execution and storage functionality.
• 3. Each trusted subsystem (TSS_SIGMA) is used for critical backup functions. It consists of a trusted instance of the security module (TM-SIGMA) and an associated trusted execution environment (Trusted Engine, TE_SIGMA) and trusted services (TS_SIGMA).
• 4. At least the three trusted subsystems TSS-DE, TSS-MNO, TSS-U on behalf of the remote owners DE, MNO, U exist on an MTP. The procedures are described for a single-user system. The device owner DO and the functionality of the TSS-DO are mapped to U or TSS-U.
• 5. For each TSS sigma, an appropriate procedure for taking possession of the TSS sigma of a relevant stakeholder has been performed. As a result, a TSS sigma is fully equipped and functional in the sense of the vSIM architecture.
• 6. A TSS sigma can sign and encrypt any data.
• 7. A TSS-U is capable of generating suitable digital signature cryptographic keys that are accessible and usable only to the particular platform user U.
• 8. A TSS MNO instantiates the service vSIM-CORE. This service is responsible for the core functionality of the vSIM architecture. In particular, this service is on the one hand responsible for the secure storage and use of the subscriber data, as well as for the subscriber authentication to the MNO.
• 9. A TSS-U instantiates the service vSIM-MGMT. This service is responsible for the user management of a vSIM. In particular, this service is responsible for the management and management of a device user. The in vSIM owner management service vSIM-OwnMGMT is functionally mapped in vSIM-MGMT.
• 10. The MNO provides the required functionality of a public-key infrastructure, directly or indirectly.
• 11. The MNO has a Cert-MNO certificate issued by a Certification Authority (CA). This certificate associates the identity of the MNO with the K-pub-MNO public key required for verification of digital signatures. This certificate is available for MTP and all embedded services.
• 12. A TSS Sigma has access to a trusted RTV Sigma service. This service is responsible for the local verification, for example of defined system states, based on reference data.

It should be noted that the further embodiment considers a single-user system. As a result, the device owner DO is equated to the user U. The procedures for subscriber authentication tion in multi-user systems with separate TSS-DO and TSS-U takes place analogously and represents no further feature of the invention.

1.2.3 Security requirements

The proposed vSIM architecture must have equivalent security properties like conventional architectures for subscriber authentication based on conventional security tokens.

• – unterwegs zum vSIM-Ausführungsumgebung, oder anderem vertrauenswürdigen Dienstleistungen sind,
• – im flüchtigen oder nicht-flüchtigen Speicher der MTP abgelegt sind,
• – innerhalb der Ausführungsumgebung ausgeführt oder benutzt werden, oder
• – zwischen verschiedenen vertrauenswürdigen Umgebungen von autorisierten Subjekten übertragen werden.

These are in particular the protected memory functionality, a tamper-resistant and isolated execution environment and authentication of a user. In addition, a vSIM platform must assure that only authorized subjects can access or manipulate proprietary data of the vSIM credential while it is being used

• - are on the way to the vSIM execution environment, or other trusted services,
• - stored in the volatile or non-volatile memory of the MTP,
• - executed or used within the execution environment, or
• - be transferred between different trusted environments by authorized subjects.

The implies that an attacker is unable to security-critical Destroy, modify or modify the access control mechanisms to get around. It must continue to be a loss and escape of safety critical Data prevent and assure that all necessary services are available and functional. Especially the vSIM architecture must ensure that only through appropriate (local or remote) owners authorized Subjects are able to access safety-critical services.

1.3 Procedure for use and the management of vSIM credentials

• • Verfahren zur Einrichtung und Inbesitznahme einer vSIM-Ausführungsumgebung durch einen entfernten Eigentümer
• • Verfahren zur Teilnehmer-Registrierung und zur Auslieferung (Roll-Out) eines vSIM-Credential, und
• • Verfahren zur Migration von vertrauenswürdigen Subsystemen.

The following section describes various procedures for using and managing vSIM credentials and related services. The purpose of the following methods is to provide the convenient use, maintenance and administrative functions to the local user or device owners, as well as from remote owners:

• • Procedure for setting up and taking possession of a vSIM execution environment by a remote owner
• • Procedure for registering participants and delivering (rollouting) a vSIM-Credential, and
• • Migration of trusted subsystems.

1.3.1 Procedures for establishment and possession a vSIM environment by a remote owner

One Device Owner (DO) of an MTP must be able to create an "empty" communication terminal, such as a mobile phone, to buy that does not pre-allocate and was initialized by a specific MNO so that the User U or the device owner DO a freely choose any MNO without restrictions can. This procedure is used to take possession of the TSS MNO by a distant owner and the setup of the vSIM execution environment to complete the MNO.

It It should be noted that the method is directly remote to any remote Owners transferable and not limited to the MNO is.

The Occupation by a distant owner (Remote Owner, RO) builds the basic and elemental trust relationship between the removed owner or representative and the MTP on. In the following section we give an example a method to perform this operation.

The main idea is to first install an original trusted subsystem TSS * -MNO. This TSS * -MNO consists of an original standard execution environment (TE * -MNO) with basic functionality and / or with a number of trusted services. If the TSS * -MNO subsystem is able to provide the MNO with evidence of its pristine configuration, construction and compliance with its security policy, this will be certified by the MNO. 4 illustrates the procedure that is outlined in sections 1.3.1.1 and 1.3.1.2.

1.3.1.1 Platform and Protocol Prerequisite

In In a preparatory phase, the platform has a certified, initial Start procedure executed and a specific trusted Software layer of the OS and its trusted units loaded. The platform checks the installed hardware and running software in a trusted state and configuration. It is capable of this condition when prompted to report and authenticate to an authorized entity.

1.3.1.2 Protocol procedure and informal description

The first phase prepares the seizure by a distant owner in front. An "empty" execution environment TE * -MNO is set up and a new instance of the security module TM-MNO activated or created.

Of Another becomes an original execution environment TE * -MNO furnished and prepared. This is in particular a Endorsement key pair EK * -TSS-MNO within TM-MNO with a corresponding endorsement certificate Cert-T55-MNO.

Thereafter, the TE * -MNO certifies its present condition. The certificate may be carried out by the local verifier RTV-DM of the TSS-DM and using reference values (RIM) and corresponding certificates of the remote owner MNO. If no matching RIM and / or RIM certificate is available for the execution environment, attestation can be made using an external (accepted) verification authority. TE MNO → MNO: ATTEST (p i )

TE * -mno generates a symmetric session key Ks and Encrypts the public part of it Endorsement key EK * -TSS-MNO, the corresponding Certificate Cert-TSS-MNO, the attestation data and information for use. Then TE * -MNO encrypts the session key Ks with the public key K-pub-MNO and sends both messages to the MNO.

It is assumed that this key is either publicly available or preinstalled by the device manufacturer.

After this the messages were received by the MNO, they are sent by private share of the asymmetric key K-pub-MNO decrypted.

in the Following this step, MNO verifies the attestation data and verifies the intended use of TSS * -MNO. If the execution environment and device attestation data are valid and the intended use is accepted, the MNO generates an individual security policy SP-MNO. The MNO signs the Cert TSS MNO and generates RIM values and RIM certificates of a "complete" TSS-MNO. These are for local verification of TSS MNO needed.

In addition, the MNO generates an initial configuration SC-TSS-MNO. Thus, the execution environment is individualized or completed in relation to the intended purpose and the given security policy. In this step MNO encrypts the messages with the public part of the key (EK-pub-TSS-MNO) and transmits this packet to the TE-MNO.

The Execution Environment TE * -MNO decrypts this received package and installs it within the TSS MNO. After all It completes its setup by configuration SC-TSS-MNO. In particular, this means that all not yet installed Services required by SC-TSS-MNO are included in TSS-MNO or installed.

1.3.2 Procedure for participant registration and for the delivery of a vSIM-Credentials (Roll-Out)

Around To use the vSIM service, the MTP must have an access authorization (vSIM-Credential) are available. This vSIM credential is either (1) generated by the MNO in advance, (2) is on attributed an initial mystery or (3) will (by the MNO and the user U) during the Acquisition generated.

• • die Anfrage eines vSIM-Credentials,
• • die Authentifizierung der beteiligten Entitäten, und
• • den Transport und die Installation des angefragten vSIM-Credentials.

The following procedure allows:

• • the request of a vSIM-Credentials,
• • the authentication of the participating entities, and
• • the transport and installation of the requested vSIM-Credentials.

There the services of the vSIM architecture as trusted Software applications are related, it means that the respective Participant's share of the vSIM credential from the MNO to the vSIM service must be transmitted safely. In conventional SIM-based Systems, the subscriber receives a security token (smartcard / SIM card), right after his registration. In contrast to the vSIM-Credential, This security token exists physically and is tagged with a, in previously used key or SIM-Credential for respective point of sale (POS).

1.3.2.1 Platform and protocol precondition

In In a preparatory phase, the platform has a certified, initial Start procedure executed and a specific trusted Software layer of the OS and its trusted units loaded. This includes the trusted execution environments with their embedded services vSIM-CORE and vSIM-MGMT. The trustworthiness the platform has been checked and the hardware installed and running software are in a trusted, acceptable and credible condition and configuration. Furthermore, it is capable of this condition when prompted by to report and authenticate an authorized entity.

1.3.2.2 Protocol procedure and informal description

The POS / POP orders any number of (pre-generated) registration tickets Ticket-i from the MNO. A registration ticket consists of the triplet: ticket i : = {IMSI i , EDGE i , AUTH i }

there IMSI-i means an International Mobile Subscriber Identity, as described in [3]. In other scenarios, this may be a random, unique identifier (ID) authorized by the authorized body is allocated.

Of the Term RAND-i denotes a random value. This value is required the identity of TSS-MNO, during the course of the protocol, to check. With AUTH-i the MTP is able to to check the integrity and authenticity of the ticket-i. It should be noted that the example chosen is the illustration serves and the purpose is not limited. Especially could also be a USIM authentication module or another Procedure to be embedded here.

Phase 1: "Participant registration and Delivery of the vSIM-Credentials "

The user registration and vSIM credential roll-out are separated into two phases. The following log sequence is in 5 Illustrates and describes the first phase. Here the user registration and registration for subscriber-related services of the MNO is detailed.

The user begins the protocol by requesting and generating a new identity card (user-related portion of the vSIM credential) for a local user at the TSS-U. For this purpose, the local user hands over a unique ID number ID-U, his personal registration data REGDATA-U and a secret authorization password CHV-U to the trusted service vSIM-MGMT (step 1 ; 5 ). U → vSIM MGMT : ID U , CHV U REGDATA U .

Subsequently, vSIM-MGMT generates an asymmetric signature key pair KU and generates a corresponding certificate containing all relevant information of the user (REGDATA-U, the public part of KU) (step 2 ; 5 ). The service vSIM-MGMT then transmits the certificate CERT-U to the service vSIM-CORE (step 3 ; 5 ).

Within this step, the vSIM-MGMT service initiates a registration process and attests its current state and configuration to the local verifier (RTV-MNO) of the vSIM-CORE service. The TSS MNO checks the given data with reference data ("Reference Integrity Metrics" (RIM)). Then TSS-MNO checks if the state of the current execution environment is in a valid and acceptable state (step 4 ; 5 ). As soon as the vSIM-CORE is convinced of the reliability of the device, it generates a unique identifier PID and sends this value to the vSIM-MGMT (step 5 ; 5 ). vsim CORE → vSIM MGMT : PID

The user transmits the registration data REGDATA-U (eg name, address, accounting information, ID card number) and the PID to the POS / POP (step 6 ; 5 ). The vSIM-CORE service initiates a registration process for the user U. For this, it signs PID, its own certificate, and the user certificate received. Afterwards, vSIM-CORE sends this packet to the POS / POP (step 7 ; 5 ).

After the POS / POP has received the request, it selects a ticket-i, binds it to the key K-pub-TSS-MNO (step 8th ; 5 ) and send it back to the TSS MNO (step 9 ; 5 ). In this case, the POS / POP may be any point of sale accredited by the MNO, such as an Internet portal.

Once the POS / POP is convinced of the trust of both user U and device, it adds the CERT-U and the IMSI-i (of the selected ticket) to REGDATA-U. Then POS / POP signs the collected information with its private part of its K-POS signature key and sends the signed data and signature (online or offline) to the MNO (step 10 ; 5 ). Optionally, POS / POP encrypts the data with the public part of K-MNO.

The MNO checks the data and generates the subscriber-related portion of the vSIM-Credential with IMSI-i, the symmetric key Ki and the certificate CERT-U. Furthermore, the MNO signs this bundle with the private signature key K-MNO and finally activates the signed vSIM credential and the corresponding NONCES in its authentication center (step 11 ; 5 ). The mobile device can now request an available MNO registration service over an existing communication channel. This service can be realized, for example, as a network telecommunication service or Internet service.

Phase 2: "Secure delivery of the vSIM-Credentials and installation "

The second phase of the protocol describes the safe delivery (roll-out) and installation of the subscriber-related portion of the vSIM credential. This process is in the 6 illustrated in detail. To obtain the subscriber-related portion of the vSIM credential, the user logs in to the MNO's registration service. For this, the user U transmits the ID-U and the matching password CHV-U to the service vSIM-MGMT. vSIM-MGMT then loads the associated key pair Ku (user-related portion of the vSIM-Credential) from the protected storage (step 1 ; 6 ). U → vSIM MGMT : ID U , CHV U

In a following step, the vSIM-MGMT initializes a rollout procedure and sends request to vSIM-CORE (step 2 ; 6 ). vsim MGMT → vSIM CORE : init_rollout_vsim

After receiving this message, it releases the corresponding ticket-i and verifies the authenticity and integrity of the ticket-i (step 3 ; 6 ). Then, vSIM-CORE extracts the NONCE-U value from Ticket-i, prompting U to prove its identity. vsim CORE → vSIM MGMT : NONCE U

The service vSIM-MGMT signs the NONCE-U together with ID-U. This bundle will be sent back to vSIM-CORE.

Once the service vSIM-CORE has received the message, it will generate a vSIM Credential request and submit it to the MNO's assigned registration service (step 4 ; 6 ) in front. For this purpose, the service vSIM-CORE extracts the NONCE MNO from the ticket i and signs it together with IMSI-i. Then, vSIM-CORE sends its generated signature and the obtained user signature to the MNO.

After receiving the request from the vSIM-CORE, MNO checks the messages, the CERT-U, and the Cert-TSS MNO (either based on the data received or from the local store) (step 5 ; 6 ). If invalid or revoked, it responds with an error message and stops the log.

Otherwise the request will be approved by the MNO. Then, MNO prepares the subscriber-related portion of the vSIM credential for transmission to the vSIM-CORE. It generates a randomly selected session key Ks. Subsequently, the key Ks with to the corresponding key from TSS-MNO to the target platform (step 6 ; 6 ), so that the data (in this case the key Ks) can only be used by an associated authorized entity. The MNO encrypts the subscriber-related portion of the vSIM credential with the session key, and sends both to the TSS MNO (step 7 ; 6 ).

Finally, TSS-MNO releases the session key Ks. With this key, it decrypts the subscriber-related portion of the vSIM-credential and verifies the attached signature (step 8th ; 6 ). If the decryption is successful and verified, vSIM-CORE seals the obtained vSIM credential to one (or more) valid platform configurations. After that it completes the process and completes the installation.

alternative could the MNO split the key Ks in one generate previous level, and an encrypted subscriber-related Integrate the vSIM credential already in the Ticket-i. In this Case, the MNO only sends the key Ks to vSIM-CORE Target platform.

1.3.3 Trusted migration process Subsystems (TSS-SIGMA)

In the present scenario, a local user or owner must be able to transfer the vSIM credential or its execution environment from one source TSS-MNO-S to another, even like, device (eg, when purchasing a new one) mobile phone). For this, the following method provides a protocol for transmitting a (complete) trusted subsystem TSS-Sigma. All safety-critical data (including the basic storage key (SRK)) are migrated to destination TSS-MNO-D. The same remote owner (RO) is required on both subsystems TSS-MNO-S and TSS-MNO-D.

The Migration procedure provides that a complete key hierarchy (1) between execution environments of identical stakeholders is migratable, (2) if, and only if one for this Purpose of certain security policy exists on both platforms and entitled to do so.

The advantage of the proposed migration is that the migration process does not require a trusted third party (TTP). Only the appropriate owner, in combination with TSS MNO's local validation mechanisms, will be involved to migrate the trusted subsystem (including TM Sigma bound keys, particularly the Storage Root Key (SRK)) to the target platform. The migration protocol is described in the following section and in 7 illustrated.

One For example, such a method to securely migrate an SRK is in the current TCG MPWG Reference Architecture [1] not provided. The method described allows a migration between two instances of the same stakeholder (inter-stakeholder migration) perform.

1.3.3.1 Platform and Protocol Prerequisite

Similar Under the prerequisites in Section 1.3.2.1, the MTP has the same precursors executed. In addition, the MNO has a procedure for possession by a distant owner, such as exemplified in section 1.3.1.

1.3.3.2 Protocol and Informal description

To Start of the migration process initializes device owner (DO) of the source platform MTP-S the migration process. Therefore he starts the migration service of the TSS-MNO-S. This service offers following basic functionality.

The platform MTP-S (or TSS-DM) is commissioned by the migration service of TSS-MNO-S to set up a secure channel to the target platform MTP-D. DO S → TSS MNOS : init_migrate_vsim

After the connection is available, TSS-MNO-D activates the corresponding migration service in TSS-MNO-D to perform the import procedure. Then, the target subsystem TSS-MNO-D performs a local check of TSS-MNO-S. If invalid or revoked, it responds with an error message and stops the log. In other case, TE-MNO-D requests a confirmation of the local owner DO.

Then, the target subsystem TSS-MNO-D generates a random value NONCE-MNO-D. To provide evidence of its trustworthiness, TSS-MNO-D sends all necessary information to the source subsystem TSS-MNO-S. This includes the current state of the platform SiD, the certificate of TSS MNO-D, the security policy SP-MNO-D and the value NONCE-MNO-D.

After this the message was received from the target subsystem TSS-MNO-S the state of TSS-MNO-D. If the target system in one trustworthy state is and an acceptable security policy and configuring, becomes the current one State of TSS-MNO-S bound to the value NONCE-MNO-D and all stopped further actions and then TSS-MNO-S deactivated. It should be noted that the source system may be appropriate Data transmitted to reactivate the target system.

Of the TSS-MNO-S generates a symmetric migration key K-M serializes its instance and encrypts it the K-M. This is sent to an acceptable configuration of TSS-MNO-D bound.

Then, the bound key KM and the encrypted instance become the target platform TSS-MNO-D sent. In particular, this includes the fully isolated key hierarchy K-MNO-S with SRK-MNO-S, the security policy SP-MNO-S, and the required SC-MNO-S.

After all the target subsystem TSS-MNO-D decrypts the received K-M and uses SRK-MNO-S as its own SRK. The subsystem checks the obtained security policy SP-MNO-S and the subsystem configuration SC-MNO-S. With this information, the TSS-MNO-D then builds the internal Structure of the source subsystem.

To successful completion of TSS-Sigma-D transmits the Target platform a status message and, where appropriate, a platform certificate to the source system.

The Source platform TSS-Sigma-S deletes all safety-critical Data or makes them permanently unusable. Then transmitted the source system optionally a status message to the target system and / or performs a platform validation.

1.4 Conceptual models for subscriber authentication

• • Modell „One": Verfahren zur Zugangserteilung eines Kommunikationsteilnehmers in mobilen, zellbasierten Kommunikationsnetzen mit Kompatibilität zur GSM/UMTS-Authentifizierung
• • Modell "Two": Verfahren zur Zugangserteilung eines Kommunikationsteilnehmers in mobilen, zellbasierten Kommunikationsnetzen mit Plattform-Attestierung zur Gewährleistung der Nutzung von Basisdiensten
• • Modell "Three": Generalisiertes Verfahren zur Zugangserteilung in Netzwerkinfrastrukturen unter Benutzung Plattform-Attestierung zur Gewährleistung der Nutzung von Basisdiensten

The following section presents three exemplary approaches to vSIM-based subscriber authentication:

• • Model "One": Procedure for accessing a communication subscriber in mobile, cell-based communication networks with compatibility with GSM / UMTS authentication
• • "Two" model: Procedure for granting access to a communication subscriber in mobile cell-based communication networks with platform attestation to ensure the use of basic services
• • Three model: generalized access network infrastructure process using platform attestation to ensure the use of basic services

1.4.1 Model "One": Procedure for granting access to a communication subscriber in mobile, cell-based communication networks with compatibility with the GSM standard

Of the Approach of the model "One" allows the access of a communication participant to a mobile, cell-based communication network using software-based Access authorization passes.

• – Feststellung der Teilnehmeridentität eines Benutzers
• – Ermöglichung einer Dienstnutzung eines mobilen, zellbasierten Kommunikationsnetzwerkes
• – Bindung des Zugangsberechtigungsnachweis zu bestimmten vertrauenswürdigen Plattform-Konfiguration, und

The technical realization of this model can be implemented in conventional communication terminals without technological changes to the mobile, cell-based network infrastructure and the authentication protocol. In addition to the main task of replacing the conventional SIM functionality, this model provides the following features:

• - Determination of the subscriber identity of a user
• Enabling service utilization of a mobile cell-based communication network
• - Binding the conditional credential to certain trusted platform configuration, and

The Main task of virtual, software-based access credentials, it is a functional replacement of a conventional safety token (SIM card) for subscriber authentication in mobile, cell-based To ensure communication networks. Further tasks and requirements regarding GSM TS 11.11 [8] are not accepted.

The cryptographic algorithms for subscriber authentication and Key generation is compliant in the presented case to the GSM standard. The basic implementation of the subscriber authentication and Key generation algorithms of the UMTS standard [11] are analogous with respect to the vSIM architecture.

All subscriber-related procedures are performed within the TSS-MNO and using the service vSIM-CORE. These include in particular the algorithms of the GSM standard A3 and A8 [10]. These are responsible in the presented example for the subscriber authentication and key generation. The algorithm A5 / 3 for securing the communication channel is integrated within TSS-DM [11]. Of the Protocol procedure is described below and in 8th illustrated.

1.4.1.1 Platform and Protocol Prerequisite

Of the MTP has run an initial startup process and that trusted operating system and trusted Services loaded. In particular, this process includes in particular the instantiation of the services vSIM-CORE and vSIM-MGMT. The trustworthiness the platform is checked so that the installed Hardware and running software, in a trusted Condition and configuration is. It is capable of this condition, if requested by an authorized entity to report and to authenticate.

1.4.1.2 Protocol procedure and informal description

The informal description of the process is divided into two phases. Phase 1 constructs the protocol for initializing the services vSIM-CORE and vSIM-MGMT. In phase 2, the exemplary embodiment takes place the subscriber authentication taking into account the GSM standards and using a vSIM credential.

Phase 1: "Initialization of the vSIM Credential"

First, the local user initializes the vSIM service and authenticates. For this, he / she sends his / her unique identifier ID-U, together with the correct password CHV-U to the vSIM-MGMT service (step 1 ; 8th ). The vSIM-MGMT service checks the submitted user data and, in the case of a successful check, loads the corresponding credential (user-related portion of the vSIM credential) from the protected storage area (step 2 ). The proof of identity in particular contains the signature key of the user U. U → vSIM MGMT : ID U , CHV U

Subsequently, the service vSIM-MGMT connects to the trusted interface of the service vSIM-CORE and sends an initialization request to vSIM-CORE (step 3 ; 8th ). After receiving this request, vSIM-CORE generates a random value RAND-AUTH and sends it as an authentication message (challenge) to the service vSIM-MGMT. vsim CORE → vSIM MGMT : EDGE AUTH

The service vSIM-MGMT uses the corresponding private part of the user U's signature key and signs the authentication message RAND-AUTH and sends this value to the service vSIM-CORE (step 4 ) back. vsim MGMT → vSIM CORE : SIGN U (EDGE AUTH )

As soon as vSIM-CORE has received the signed message, it checks its status. After successful verification, the service vSIM-CORE decrypts the subscriber-related portion of the vSIM-credential and initializes the GSM algorithms A3 and A8. For initialization vSIM-CORE uses the subscriber data IMSI-i and Ki of the vSIM-Credentials (step 5 ; 8th ).

Phase 2: "Subscriber Authentication"

Of the vSIM-CORE communicates indirectly (via the TSS-DM) with the MNO. The communication between the involved communication parties is transparent. For this, TSS-DM must have suitable procedures or Services provide these messages between to the service vSIM-CORE and the MNO.

The following protocol sequence represents the vSIM-based authentication procedure in GSM networks (step 6, step 7 ; 8th )
First, the MTP initializes the authentication process and sends the command GSM_AUTH_ALGORITHM to the service vSIM-CORE of the TSS-MNO.

In the following step, the MTP establishes access to the GSM network. For that sends TSS-MNO the identifier IMSI-i (or TMSI-i) to the MNO. vsim CORE → MNO: IMSI i

The MNO internally generates a number of authentication triplets. These triplets include an authentication challenge RAND-i, a temporary session key Kc, and the expected authentication response SRES. The Kc and the SRES are calculated using the GSM A38 algorithm. The MNO responds with the authentication request RAND-i to the MTP. MNO → vSIM CORE : EDGE i

Of the RAND-i is sent by the TSS-DM to the service vSIM-CORE of the TSS-MNO forwarded. After that, it uses the A3 algorithm together with the key Ki. The result of the A3 algorithm is the authentication response (response) SRES *.

The vSIM-CORE sends this message SRES * to the MNO. vsim CORE → MNO: SRES *

After all The MNO compares the SRES with SRES *. If these are identical, the participant is considered authenticated. The vSIM-CORE and MNO are in charge the common session key Kc and gives Kc to TSS DM. TSS-DM then takes over Kc to establish the Communication channel.

1.4.2 Model "Two": procedure for granting access a communication subscriber in mobile, cell-based communication networks with remote attestation to ensure basic network access

• – Feststellung der Teilnehmeridentität eines Benutzers
• – Ermöglichung zur Dienstnutzung eines mobilen, zellbasierten Kommunikationsnetzwerkes
• – Bindung des Zugangsberechtigungsnachweis zu bestimmten vertrauenswürdigen Plattform-Konfiguration,
• – Gegenseitige Authentifizierung zwischen dem MNO und der MTP,
• – Basis-Netzwerkzugang zu subskriptions-unabhängigen und/oder nicht teilnehmerbezogene Diensten in einer allgemeinen Kommunikationsdomäne,
• – fein-granulare Funktionsbeschränkung (z. B. SIM-Lock), und
• – Dynamischer down-/upgrade von Diensten

This section describes a more comprehensive approach compared to the previous model. In addition to Model One, it uses the technological capabilities of platform attestation to provide access to the base network to use subscription-independent and / or non-subscriber-based services such as public, free or optional services. Besides the main task to provide a replacement for the conventional SIM functionality, this model provides the following features:

• - Determination of the subscriber identity of a user
• - Enabling the service usage of a mobile cell-based communication network
• - Binding the credentials to certain trusted platform configuration,
• Mutual authentication between the MNO and the MTP,
• Basic network access to subscription-independent and / or non-subscriber-related services in a general communication domain,
• - Fine-granular functional restriction (eg SIM-Lock), and
• - Dynamic down / upgrade of services

As in 9 As illustrated, all devices within a generally accessible communication domain are capable of using and accessing subscription-independent and / or non-subscriber-related (MNO) services of the base network.

Such Services may include, for example, local, location-based services or be the wifi-based internet access. In the event that one Mobile phone assigned to the general communication domain It uses attestation mechanisms for access to the basic network to obtain.

The transition to the subscriber-authenticated area (subscription-dependent MNO services, eg. Telephony) of the MNO requires a successful Carrying out subscriber authentication by means of a vSIM-Credentials. An MTP thereby has access to services within the area the specific communication services offered by the MNO (GSM, UMTS, telephony, etc.), as well as access to the offered Services of the basic network.

1.4.2.1 Platform and Protocol Prerequisite

The MTP has performed an initial startup process and loaded the trusted operating system and trusted services. In particular, this process includes the instantiation of Services vSIM-CORE and vSIM-MGMT. The trustworthiness of the platform is checked so that the installed hardware and running software is in a trusted state and configuration. It is able to report and prove this condition when requested by an authorized entity.

1.4.2.2 Protocol and informal description

The following description of the protocol flow is divided into three phases. 10 illustrates this protocol. The first phase of the protocol describes access to the basic network. It uses platform attestation and ticketing mechanisms. In the second phase, the vSIM credential is initialized. Finally, the third phase implements the subscriber authentication procedure.

Phase 1: "Basic Network Access"

The MTP initializes the basic authentication of the device. For this, the trusted execution environment TE-DM sets up a platform attestation and device authentication to the MNO. Thereafter, TE-DM makes this request and connects to the appropriate Network Access Point (NAP-MNO) (step 1 ; 10 ). For this, the TSS-DM generates a random value RAND-BASE and performs a platform attestation. Then, the basic authentication service of the execution environment TE-DM sends the value RAND BASE, the attestation data and its certificate Cert-DM to the network access point NAP-MNO.

As soon as This request has been received from the NAP MNO this the state of the MTP (client). In the case of the integrity check fails or no accepted reference state is found, If the NAP-MNO breaks the protocol and responds with an error message. Is the attestation of the platform successful and the MTP will considered trustworthy.

Thereafter, an accredited entity of the NAP MNO generates both a session key K-BASE and a network ticket (step 2 ; 10 ). Such an entity may be, for example, an authentication center (AUC-MNO) belonging to the mobile network provider MNO. Essentially, the ticket contains the following information:

After that, AUC-MNO encrypts both the ticket BASE with the public (or possibly shared) K-NAP key, and K-BASE, and sends both to the NAP MNO (step 3 ; 10 ). This one reaches it to the client platform (step 4 ; 10 ) further. In addition, the message is bound to a trusted subsystem TSS-DM with the corresponding public key K-TSS-DM and a valid platform configuration.

As soon as the trusted subsystem TSS-DM has received the signed message, it checks the status of the signed value RAND-BASE (step 5 ; 10 ). If invalid or revoked, the subsystem responds with an error message and ends the log. In other case, the AUC MNO is authenticated by the authentication response.

Then TSS-DM decrypts the session key K-BASE and sends the encrypted data together with an authenticator (MTP) to the NAP MNO. The authenticator (MTP) in the present case is composed of the platform identity ID-MTP, the current network address ADDR and a time stamp TIME.

If NAP-MNO has received the encrypted ticket verified it's the embedded information. If the status is valid is attested, platform and access to the general Services.

Phase 2: "Initialization of the vSIM Credential"

The initialization of a vSIM-Credentials is in steps 7 - 11 of the 10 shown. The process of this process is identical to step 1 - 5 For the detailed description of the protocol flow please refer to section 1.4.1.3 (Phase 1).

Phase 3: "Subscriber Authentication" (Version 1)

Identical to Section 1.4.1.3 (Phase 2), this variant performs subscriber authentication with compatibility with the GSM standard. In an additional step, the key K-BASIS is replaced by the session key Kc on the side of the NAP-MNO and the MTP (step 12 ; 10 ) exchanged.

At this point, mutual authentication between the AUC-MNO and U has been performed. The AUC MNO is sent by signed authentication request from step 4 authenticated. On the other hand, the user proves his identity through SRES. The authentication between NAP-MNO and U is implicitly proved by a valid message key Kc.

This method can be optimized by making RAND-i already in the encrypted key message from step 4 embedding. In this case, vSIM-CORE extracts the RAND-i from this message, computes the authentication response SRES, and sends both results to the MNO. The MNO internally generates the expected SRES and the corresponding session key Kc.

If An explicit authentication of these entities is required is, additional steps must be performed become. The NAP attests to the platform through the following Steps. First, the NAP pulls the timestamp out of the authenticator Au out. Then NAP increases the value and encrypts it with the common session key Kc (or a derived keys). Finally sends return the message to MTP.

Phase 3: "Subscriber Authentication" (Variant 2)

alternative For Phase 3, the following protocol describes the authentication procedure with deviation to the GSM authentication standard.

These Variant provides a slightly modified authentication method which, however, represents a significant increase in public safety land mobile network (PLMN). Especially Protocol errors in the signal system 7 (SS7) can thereby to be bypassed. The following variant uses the former, negotiated Information of Besisnetzwerkzugangs from phase 1. In conventional GSM infrastructures becomes an authentication striplet over sent the SS7 network [9]. This triplet contains one Challenge RAND, the right answer. SRES, and the message key Kc.

While the initial access to the mobile communication network by the Message key K-BASE is a renewal this key is not necessary. This is especially true for embedding the session key Kc. This avoids the transmission of unprotected Session keys.

The The basic idea behind this variant is the still existing communication tunnel between NAP-MNO and MTP based on the key K-BASE is protected. Instead of a renewal of the session key The MNO sends only one service update message to the respective network access point NAP and MTP.

1.4.3 Model "Three" - Generalized Method for subscriber authentication to general network infrastructures

The following section introduces a generic model for subscriber authentication. It takes over the different aspects of the previous models and generalizes them on an abstract level. The method uses generalized assumptions for this. This concerns in particular the structural structure of the subscriber-related portion of the vSIM-Credentials and the functionality or integrated algorithms of the trusted service vSIM-CORE.

One vSIM-Credential is an identity of a subject based access authorization card. This one is used around the To authenticate the identity of a communication participant. It contains a unique identifier ID-U of the subject U and at least one on cryptographic encryption mechanisms (eg symmetric or asymmetrical keys) or "not cryptographic encryption mechanisms " (eg one-way hash chain) information.

Just authorized subjects can create a vSIM credential read or modify the information contained therein. A vSIM credential can provide additional information, such as device identity or a list of valid application areas.

The MTP instantiates a vSIM CORE service, which is in a separate and protected execution environment is running. The service vSIM-CORE is for the core functionality the subscriber authentication in charge. In particular, leads this service does the actual authentication mechanisms.

The specific execution of mechanisms or protocols depends on the specific application. The service vSIM-CORE can be trusted functionality on the one hand import, as well as other (external) trusted Provide services. Furthermore contains at least one participant-related portion of a vSIM-Credential.

1.4.3.1 Platform and Protocol Prerequisite

Of the MTP has run an initial startup process and that trusted operating system and trusted Services loaded. This includes in particular the instantiation the services vSIM-CORE and vSIM-MGMT. The trustworthiness the platform is checked so that the installed Hardware and running software, in a trusted Condition and configuration is. It is capable of this condition, if requested by an authorized entity to report and to authenticate.

1.4.3.2 Protocol and Informal description

In Based on model "Two", the description of the protocol flow divided into three phases.

Phase 1: Remote Attestation

In the first phase is device authentication through platform attestation, as described by way of example in 1.4.1.3 (Phase 1). In this general case, the network entity MNO goes through a corresponding entity of the general network infrastructure replaced. Such an entity may be, for example Authentication Server (ALS) within this network.

Phase 2: "Initialization of the vSIM Credential"

The Initialization of the vSIM services and the vSIM credential becomes identical for the protocol flow from section 1.4.1.3 (phase 2). However, the protocol procedure is based on generalized assumptions and thereby enables a broader foundation for more authentication methods and protocols.

The The present method for subscriber authentication aims to services offered to a given participant to authenticate and authorize the ALS.

In The first two models are based on subscriber authentication procedures common secrets (symmetric key Ki) limited. In particular, this restriction is in the generic Procedure is no longer given.

Illustration XX shows a simple example of the generic method below the use of asymmetric encryption methods.

It In this case, a random value RAND-SRV is used. With this is requested a service extension to the ALS. The TE-OE is extracted the RAND SRV from the ticket BASE.

After that The TE-OE creates the authentication response XRES * -SRV and signs it the RAND SRV with its private signature key K-priv-TM-AS. Together with UID and a service identifier SRV becomes this signature XRES * SRV sent to the ALS.

As soon as the ALS has received this message, he verifies the signature from XRES * SRV. If the signature is valid, becomes platform certified and performed a service extension.

4 references

• [1] Trusted Computing Group. Trusted Computing Group website. https://www.trustedcomputinggroup.org ,
• [2] Trusted Computing Group. TCG MPWG Mobile Reference Architecture. Technical Report Version 1.0, 2007 ,
• [3] Trusted Computing Group. TCG MPWG Mobile Trusted Module Specification. Technical Report Version 0.9 Revision 1, TCG, 2006 ,
• [4] Trusted Computing Group. Trusted Computing Platform Alliance (TCPA) Main Specification. Technical Report 1.1b, Trusted Computing Group, 2002 ,
• [5] Trusted Computing Group. Trusted Platform Module Protection Profiles. Technical Report 1.9.7, Trusted Computing Platform Alliance (TCPA), 2002 ,
• [6] Trusted Computing Group. TPM Main Part 1 Design Principles. Technical Report Version 1.2 Revision 94, TCG, 2005 ,
• [7] Trusted Computing Group. TCG Specification Architecture Overview. Technical Report Revision 1.3, TCG, 2007 ,
• [8th] 3rd Generation Partnership Project. 3GPP TS 11.11; Specification of the Subscriber Identity Modules - Mobile Equipment (SIM-ME) interface. Technical Report 3.3.2, 3GPP, 1997. Technical Specification Group Services and System Aspects ,
• [9] 3rd Generation Partnership Project. 3GPP TS 01.02; General description of a GSM Public Land Mobile Network (PLMN). Technical Report 6.1.0, 3GPP, 2001. Technical Specification Group Services and System Aspects ,
• [10] 3rd Generation Partnership Project. 3GPP TS 55.205; Specification of the GSM-MILLENAGE Algorithms; An example algorithm set for the GSM Authentication and Key Generation functions A3 and A8. Technical Report 6.0.0, 3GPP, 2002. Technical Specification Group Services and System Aspects ,
• [11] 3rd Generation Partnership Project. 3GPP TS 21.101: Technical Specifications and Technical Reports for a 3GTR UTRAN-based system. Technical Report 6.6.0, 3GPP .

QUOTES INCLUDE IN THE DESCRIPTION

This list The documents listed by the applicant have been automated generated and is solely for better information recorded by the reader. The list is not part of the German Patent or utility model application. The DPMA takes over no liability for any errors or omissions.

Cited non-patent literature

• - Trusted Computing Group. Trusted Computing Group website. https://www.trustedcomputinggroup.org [0124]
• - Trusted Computing Group. TCG MPWG Mobile Reference Architecture. Technical Report Version 1.0, 2007 [0124]
• - Trusted Computing Group. TCG MPWG Mobile Trusted Module Specification. Technical Report Version 0.9 Revision 1, TCG, 2006 [0124]
• - Trusted Computing Group. Trusted Computing Platform Alliance (TCPA) Main Specification. Technical Report 1.1b, Trusted Computing Group, 2002 [0124]
• - Trusted Computing Group. Trusted Platform Module Protection Profiles. Technical Report 1.9.7, Trusted Computing Platform Alliance (TCPA), 2002 [0124]
• - Trusted Computing Group. TPM Main Part 1 Design Principles. Technical Report Version 1.2 Revision 94, TCG, 2005 [0124]
• - Trusted Computing Group. TCG Specification Architecture Overview. Technical Report Revision 1.3, TCG, 2007 [0124]
• - 3rd Generation Partnership Project. 3GPP TS 11.11; Specification of the Subscriber Identity Modules - Mobile Equipment (SIM-ME) interface. Technical Report 3.3.2, 3GPP, 1997. Technical Specification Group Services and System Aspects [0124]
• - 3rd Generation Partnership Project. 3GPP TS 01.02; General description of a GSM Public Land Mobile Network (PLMN). Technical Report 6.1.0, 3GPP, 2001. Technical Specification Group Services and System Aspects [0124]
• - 3rd Generation Partnership Project. 3GPP TS 55.205; Specification of the GSM-MILLENAGE Algorithms; An example algorithm set for the GSM Authentication and Key Generation functions A3 and A8. Technical Report 6.0.0, 3GPP, 2002. Technical Specification Group Services and System Aspects [0124]
• - 3rd Generation Partnership Project. 3GPP TS 21.101: Technical Specifications and Technical Reports for a 3GPP UTRAN-based system. Technical Report 6.6.0, 3GPP [0124]

Claims (43)

A method and device for facilitating access to communication networks, service use by communication networks and identification of subscriber identity in communication networks, characterized in that usage data and subscriber identities are protected by a non - exchangeable Trusted Module (TM) which is not specifically for this purpose Access to communications networks designed for service use by communication networks and identification of subscriber identity in communication networks. Furthermore, characterized in that data of the stakeholders, such as the participant's access authorization card, are managed and stored in separate security areas, which are protected by the TM. Method according to claim 1, characterized in that that there are separate security areas TSS-U, TSS-MNO, TSS-U and, if applicable, TSS-DO the stakeholder DM, MNO, U and possibly DO supported. Continue by doing so characterized in that these areas can be combined as desired are. Method according to claim 2, characterized in that that the security area TSS-DM and / or other suitable Security areas the vSIM-Base service of the stakeholder DM and / or another appropriate stakeholder, which for the correct execution of services for platform attestation and, where appropriate, communication services and / or, where appropriate, other types of basic services is. Method according to one of claims 2 to 3, characterized in that the security area TSS-MNO the Service vSIM core of the MNO stakeholder, which for the correct execution of the subscriber authentication service and / or subscriber-related additional services is. Method according to one of claims 3 or 4, characterized in that the security area TSS-U the Service vSIM-Mgmt of Interest Representative U executes which is responsible for the correct execution of the user identification authentication service and user-related ancillary services, particular of user-related administrative services is. Method according to claim 5, characterized in that that the security area TSS-DO the service vSIM-OwnMgmt of the stakeholder DO executes which one for the correct execution of the management services of the device owner and owner-related add-on and administration services responsible is. Method according to Claim 6, characterized that the service vSIM Core the subscriber-related data and the Service vSIM-MGMT keeps the user-related data. Of Further characterized in that the service vSIM-MGMT a Subscriber Authentication Service Provides or Supports. Method according to claim 7, characterized in that that the services vSIM-MGMT and vSIM-Core and possibly vSIM-Core generate a sub-service to prove their identities, use and safely safekeep and / or manage directly or indirectly can. Furthermore, characterized in that the identity from vSIM-Mgmt through user-related data, the identity of vSIM-OwnMgmt through user-related administrative data and the Identity of vSIM core through subscriber-related data is detected. Further characterized in that the proof identity by appropriate asymmetric methods and / or symmetric cryptography and / or application of a hashing algorithm and / or the application of a keyedhash massage authentication code (HMAC) and / or hash-lock method and / or challenge-response method and / or the attachment of an electronic signature is achieved. Method according to claim 8, characterized in that that the services vSIM-Core, vSIM-MGMT and possibly vSIM-DM and vSIM-DO a one-way or reciprocal procedure for detection initiate and carry out their identity. Method according to claim 9, characterized that vSIM core on behalf of user U, but under control the external service provider or MNO the subscriber authentication service the network associated with the service provider or MNO takes up. Method according to claim 10, characterized in that the subscriber authentication service complies with the GSM standard and / or UMTS standard and / or different authentication standards and / or different identification methods. Method according to one of claims 2 - 11, characterized in that the service vSIM-base before, during or a method according to the subscriber authentication method for platform attestation to ensure platform integrity performs. The method of claim 11 or claim 12, characterized characterized in that platform attestation for the use of subscriber-related Services and / or non-subscriber services of a service provider, such as a local network access point service provider, is used to authorize yourself for the services offered and / or to prove this service use (Accounting). Method according to claim 13, characterized in that that for service use of subscription-independent and / or non-subscriber services a ticket through the appropriate Service provider is issued. A method according to claim 13 or claim 14, characterized characterized in that one or more further suitable methods for mutual authentication between the participating communication partners be performed. Method according to one of claims 13 to 15, characterized in that for the communication between the involved communication partners a confidential and secured Communication channel is established and maintained. Method according to claim 16, characterized in that this is the key to securing communication symmetric cryptographic session K-BASE is. A method according to claim 10 and claim 17, characterized that the session key K-BASE or a derived key and / or the established trusted one and secured communication channel for the protection the communication channel of the subscriber-related service usage becomes. Method according to one of claims 1 to 18, characterized in that an initial assignment and means one or more security areas by an external service provider, such as the MNO. Method according to claim 19, characterized that participant-related data of the stakeholders, such as the access authorization card of the subscriber, by the service provider preassigned and / or introduced. Method according to claim 20, characterized in that that user-related data, such as the identification badge the user is preassigned and / or introduced by the service provider. Method according to one of claims 1 to 18, characterized in that the initial assignment and means one or more security areas through the POP / POS and / or Device owner and / or the user initiated become. Method according to claim 22, characterized in that that a suitable procedure for occupying a security area by a distant stakeholder, such as the MNO. The taking over by the distant interest representative takes place after delivery to the POS / POP and / or the corresponding Device owner or user. Method according to claim 23, characterized that for the seizure of a security area of a Representative of interest, the device owner and / or the user has an initial and / or original and / or trusted base environment TSS * Sigma installed and / or activated. A base environment corresponds to TSS * Sigma a security environment that only basic functionality and / or Provide services or functionalities by all participating communication partners. Method according to Claim 24, characterized that the base environment TSS * Sigma their current state, configuration data and the intended use to the stakeholder, for example, by showing appropriate attestation data can. Method according to claim 25, characterized in that that the stakeholder more information, such as accepted system states and / or security requirements and / or other or other purposes defined and the basic environment TSS * Sigma directly or indirectly instructs this defined system state or configuration to achieve or set up. Method according to claim 26, characterized in that that a feedback to the appropriate stakeholders takes place as soon as the defined system state or configuration of a fully established TSS * sigma. The feedback can, for example, as a simple status message and / or as part of a further platform certification. Method according to one of claims 19 to 27, characterized in that a suitable method for taking possession TSS Sigma security area of a device owner DO and / or a user U, is performed. Method according to one of claims 19 to 29, characterized in that the registration of a communication subscriber and the delivery of the subscriber-related data, such as the proof of access, both to a user, as also to the TSS MNO of the corresponding communication terminal and optionally to a defined system state or system configuration of Communication terminal are bound. Method according to claim 29, characterized that for the registration the proof of identification a user, such as the digital signature key user U, unique to the user's identity is assigned. Furthermore, characterized in that this unique Assignment via personal registration at an appropriate registration service of the corresponding MNO. Furthermore, characterized in that the registration service checks the user's registration data and sends these to the MNO Further characterized in that appropriate to ensure the integrity of the data Techniques, such as the use of digital signatures becomes. Method according to claim 30, characterized that the provision and delivery of the subscriber-related access authorization by means of a user and subscriber-related registration ticket is carried out. A method according to claim 34, characterized by that the registration service selects a registration ticket of the MNO and / or requests and to the communication terminal or TSS-MNO of user U binds and then transmits. Further characterized in that the MNO is the selected one Ticket and assigns it to the appropriate user. Method according to claim 32, characterized in that that the TSS MNO directly or indirectly and the registration ticket transfers the delivery service of the MNO to the delivery of the subscriber-related access authorization to initiate. Method according to claim 33, characterized that the TSS MNO has the registration ticket with the identity user U and the TSS MNO and this connection detectable, for example by using digital Signatures. The method of claim 30 or claim 34, characterized marked that the MNO delivery service the registration data checked by the user and / or the registration ticket and selects a subscriber-related conditional pass or created, binds to TSS-MNO and transmits to TSS-MNO. Method according to one of claims 1 to 35, characterized in that a TSS-DO suitable services and Method supports, so the transmission a complete TSS sigma between two communication terminals (Migration) is guaranteed. A method according to claim 36, characterized in that a direct and complete transmission TSS sigma between two stakeholders of a remote owner. Furthermore, characterized in that the transmission takes place only if identical or mutually accepted system configuration is present at the target system. Method according to claim 37, characterized in that the source system TSS-Sigma-S and the target system TSS-Sigma-D each other's current system state and system configuration attest. Method according to claim 38, characterized in that that the current system state by the migration service of the Source system is locked and deactivated if necessary. Farther characterized in that the system state is serialized and optionally with the configuration data of the target platform TSS-Sigma-D is bound and transmitted to this. Farther characterized in that the migration service of the target platform TSS-Sigma-D establishes the identical system state of TSS-Sigma-S by the migration service releases the data, if necessary further necessary services installed and imported the data. Method according to claim 39, characterized that after successful completion of the migration procedure the Target platform TSS-Sigma-D transmits a status message and optionally performs platform validation. Method according to claim 40, characterized in that that after successful completion of the migration process and the receipt of the status message and, if necessary, the attestation data the source platform TSS-Sigma-S all safety-critical data deletes or permanently unusable. Method according to claim 41, characterized that the migration service of the source system transmits a status message and optionally performs platform validation. Process according to claims 39 to 42 in that the migration service of the source system transmits suitable data to reactivate the target system.