WO2003107584A1

WO2003107584A1 - Non-repudiation of service agreements

Info

Publication number: WO2003107584A1
Application number: PCT/SE2003/000934
Authority: WO
Inventors: Rolf Blom; András MEHES
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2002-01-02
Filing date: 2003-06-04
Publication date: 2003-12-24
Also published as: AU2003238996A1; GB2403880B; JP2005529569A; JP4213664B2; GB2403880A; GB0424869D0; CN1659820A; DE10392788T5

Abstract

The invention generally relates to efficient non-repudiation of service agreements between a user (10) and a service provider (20) in a communication system. An additional trusted party (30), a so-called service agreement manager is introduced, and the invention is based on the idea that the service agreement manager (30) shares a secret key (K_i) with a user terminal (10) and that the service provider (20) has a trust relation with the service agreement manager (30). The non-repudiation scheme proposed by the invention is furthermore based on preparation of relevant service agreement information, cryptographic processing (14/34) of this information based on the shared secret key (K_i) in order to generate user-signed service agreement verification information. The user-signed verification information is subsequently forwarded to the service provider (20) to enable verification (26/36) of the service agreement based on the trust relation between the service provider (20) and the service agreement manager (30).

Description

NON-REPUDIATION OF SERVICE AGREEMENTS

TECHNICAL FIELD

The present invention generally relates to robust and secure e-commerce in modern communication systems such as mobile communication systems.

BACKGROUND

Many coinmunication systems of today, including mobile communication systems, employ authentication and encryption procedures for the purpose of improving system security and robustness.

In mobile communication systems, for example, users authenticate towards the network and/or service providers in order to gain access to basic network services as well as other services, and the authentication also serves as a base for billing the users. The basic security protocol of modern communication systems normally involves a challenge- response authentication procedure, most often based on secret key cryptography. Challenge-response authentication is well known in the art and several standards on basic challenge-response authentication exist, e.g. for GSM (Global System for Mobile Communications) and UMTS (Universal Mobile Telecommunications System) networks.

In e-commerce and especially for small payment systems, it is essential for the service provider to be able to prove that a user has agreed to pay for a service (user non- repudiation of service charges/service agreements).

Known techniques for non-repudiation usually employ digital signatures that are based on public-key cryptography schemes, which are expensive from a computational point of view. SUMMARY OF THE INVENTION

The present invention overcomes these and other drawbacks of the prior art arrangements.

It is a general object of the present invention to provide an efficient and robust mechanism for non-repudiation of service agreements between a service provider and a user in a communication system.

It is an object of the invention to provide a mechanism that makes a service provider able to prove or verify that the user has indeed accepted a given service agreement.

For example, it may be interesting for the service provider to be able to prove that the user has agreed to pay for a service, including verification of the accepted service charge.

Another object of the invention is to provide a mechanism for improved challenge- response based authentication and key agreement (AKA) in a communication system.

These and other objects are met by the invention as defined by the accompanying patent claims.

Briefly, the invention normally involves a third trusted party, a so-called service agreement manager. The invention is based on the idea that the service agreement manager shares a secret key with a user terminal and that the service provider has a trust relation with the service agreement manager. The non-repudiation scheme proposed by the invention is furthermore based on preparation of relevant service agreement information, cryptographic processing of this information based on the shared secret key in order to generate user-signed service-agreement verification information. The user-signed verification information is subsequently forwarded to the service provider to enable verification of the service agreement based on the trust relation between the service provider and the service agreement manager.

The service agreement manager could be any trusted party that manages or otherwise participates in the management of a service agreement between a service provider and a user, and may for example be implemented on the network operator side in a communication system.

The service agreement manager may even be distributed between different nodes or parties, and may for example include a user identity broker and a payment broker arranged between the service provider and the identity broker. In this case, a chain of trust may be established between the service provider, the payment broker and the identity broker, where the user terminal typically shares the secret key with the identity broker.

The preparation of service agreement information is normally performed or initialized by the service provider, but it should be understood that this information may be prepared by any of the involved parties as long as both the user and the service provider accept the agreement.

The cryptographic processing of the service agreement information is normally performed on the user side, but may in some cases involve the service agreement manager as well. Preferably, the user terminal performs the cryptographic processing based on a non-repudiation key locally derived from the shared secret key in order to generate the required verification information.

The mere fact that the service provider receives the user-signed verification information and has the ability to store this information may deter users from repudiating entered service agreements. If desired or otherwise appropriate, actual verification can be performed on-line or off-line by the service agreement manager, or even directly by the service provider.

For example, the service agreement manager may generate expected verification information at least partly based on the prepared service agreement information and the shared secret key, and when required verify that user-signed verification information forwarded from the service provider actually corresponds to the expected verification information.

Conveniently, the user-signed verification information may be generated by the user terminal in response to a challenge initiated from the service agreement manager or based on a user-side-initiated ticket, in both cases in combination with the given service agreement information.

Alternatively, however, the cryptographic processing of the service agreement information is performed both on the service agreement manager side and the user side. In this case, the service agreement manager preferably generates a cryptographic representation of the service agreement information based on the shared secret key and forwards this representation to the user terminal (typically via the service provider), and then the received cryptographic representation is processed based on the shared secret key on the user side to generate proper verification information.

For example, for a ticket-based solution, the cryptographic processing on the service agreement manager side may include encryption of a ticket generated based on the prepared service agreement information, and the user-side processing then generally includes decryption of the encrypted ticket.

As should be understood, the service agreement information may be a general electronic contract. However, the invention has turned out to be particularly useful in applications where the service agreement information includes service charge information and the service agreement manager acts as a payment provider or charging center on behalf of the service provider.

For general contract signing, a specially designed embodiment that allows off-line verification by the service provider involves masking both expected verification information generated by the service agreement manager and user-signed verification information by means of local instances of the same masking function. The expected verification information generated based on the shared secret key and the general contract is masked by the service agreement manager and forwarded to the service provider. The user-signed verification information is received from the user side and masked by the service provider, thus allowing verification of the service agreement at the service provider side by comparing the masked expected verification information and the masked user-signed verification information.

Advantageously, the service agreement manager generates the expected service- agreement verification information by applying a cryptographic hash of the contract as a random challenge in a normal challenge-response based authentication and key agreement procedure.

In a series of particularly useful embodiments, non-repudiation of service agreements is integrated with a challenge-response based authentication and key agreement (AKA) procedure for network access (e.g. GMS/UMTS AKA), using the same shared secret key that is normally employed for AKA. This means that existing infrastructure can be re-used.

In clear contrast to the invention, state-of-the-art techniques for providing non- repudiation of service agreements are based on public-key cryptographic schemes directly between the service provider and the user terminal, employing an asymmetric key pair. Although not necessary, it has turned out to be beneficial to isolate keying material for non-repudiation of the service agreement from keying material for normal AKA. In this respect, the keying material for non-repudiation may even be tied to a specific payment broker that interoperates with an authentication manager, where the user terminal shares the secret key with the authentication manager.

In another related aspect of the invention, the basic principle of the above isolation mechanism is employed to improve challenge-response based authentication and key agreement (AKA). In short, ordinary AKA procedures may be improved by isolating a first set of AKA parameters for access to a network managed by a network operator from a second set of AKA parameters for access to services by a service provider by means of a predetermined function, such as a pseudo-random function, using a representation of at least part of the first set of AKA parameters as input to generate the second set of AKA parameters. This has the advantage that even if keying material for service access is lost or stolen it cannot be used for the fundamental network access.

The invention offers the following advantages:

• Efficient and robust non-repudiation of service agreements in a communication system.

• Deterring users from repudiating entered service agreements.

• Providing new business possibilities for network operators to act as trusted service agreement managers. For example, operators may gain a natural role in the payment process. • Efficient ways of extending basic challenge-response procedures such as UMTS/GSM AKA, making it possible to tie payment agreements to user authentication.

• Easy migration with existing infrastmcture.

• Easily implemented without having to introduce new GSM or UMTS Subscriber Identity Modules (SIMs). Terminals have to be changed anyhow to accommodate new payment protocols.

Other advantages offered by the present invention will be appreciated upon reading of the below description of the embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention, together with further objects and advantages thereof, will be best understood by reference to the following description taken together with the accompanying drawings, in which:

Fig. 1 is a schematic general overview of the basic participants and their mutual relations according to a preferred embodiment of the invention;

Fig. 2 is a schematic signal exchange diagram for home authentication in a mobile communication system when a mobile user roams into a visited network;

Fig. 3 is a schematic signal exchange diagram for authentication with delegated verification in the way it is usually implemented in cellular systems today; Fig. 4 is a schematic diagram illustrating the overall structure and basis for the proposed general scheme for non-repudiation of service agreements according to a preferred embodiment of the invention;

Fig. 5 is a schematic exemplary signal exchange diagram for non-repudiation of service agreements using a dedicated non-repudiation key, with possible off-line verification;

Fig. 6A is a schematic exemplary signal exchange diagram for on-line verification of service agreements using a dedicated non-repudiation key;

Fig. 6B is a schematic exemplary signal exchange diagram for on-line verification of service agreements using an existing AKA key as non-repudiation key;

Fig. 7A is a schematic exemplary signal exchange diagram for establishing proof of user authentication by means of masked authentication data combined with off-line verification of service agreements;

Fig. 7B is a schematic exemplary signal exchange diagram for establishing proof of user authentication by means of masked authentication data combined with on-line verification of both authentication and service agreements, using either a dedicated key or an existing AKA key for non-repudiation of the service agreements;

Fig. 8A is a schematic exemplary signal exchange diagram for ticket-based non- repudiation, with possible off-line verification;

Fig. 8B is a schematic exemplary signal exchange diagram for ticket-based non- repudiation, with on-line verification; Fig. 9 is a schematic exemplary signal exchange diagram for ticket-based non- repudiation, where the base ticket is prepared by the authentication/payment manager on behalf of the user;

Fig. 10 is a schematic exemplary block diagram for contract signing based on the introduction of masked verification data allowing off-line verification by the service provider;

Fig. 11 is a schematic exemplary signal exchange diagram for the contract signing implementation of Fig. 10;

Fig. 12A is a schematic exemplary signal exchange diagram for AKA-integrated non- repudiation of service agreements based on different isolated keying sets, with possible off-line verification;

Fig. 12B is a schematic exemplary signal exchange diagram for AKA-integrated non- repudiation of service agreements based on different isolated keying sets, with on-line verification;

Fig. 13 is a schematic exemplary block diagram in a distributed implementation involving an identity broker as well as a payment broker, employing an established chain of trust between the identity broker, payment broker and service provider;

Fig. 14 is a schematic exemplary signal exchange diagram for non-repudiation of service agreements in a post pay scenario in the set-up shown in Fig. 13;

Fig. 15 is a schematic exemplary signal exchange diagram for non-repudiation of service agreements in a prepaid scenario in the set-up shown in Fig. 13; Fig. 16 is a schematic block diagram illustrating an example of a service agreement manager according to a prefened embodiment of the invention;

Fig. 17 is a schematic block diagram illustrating an example of a service provider according to a preferred embodiment of the invention; and

Fig. 18 is a schematic block diagram illustrating an example of a user terminal according to a preferred embodiment of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Throughout the drawings, the same reference characters will be used for conesponding or similar elements.

Overview

It may be useful to begin by outlining the basic participants and their mutual relations with respect to Fig. 1, which is a schematic general overview of a communication system according to the proposed invention.

The basic participants include a user 10, a service provider 20 and an additional party generally called a trust provider 30, which may perform various tasks on behalf of the service provider and or user. The trust provider 30 has a trust relation with the user (or rather with a properly configured user terminal) established through a shared secret key. The trust provider 30 and the service provider 20 may have an agreement that is manifested as a contractual trust relation. The relationship between the user 10 and the service provider 20 is normally regarded as an induced trust relation, which is established when the services offered by the service provider are requested or otherwise initiated.

The trust provider may for example be related to a network operator with which the user has a trust relation, for example established through a subscription or a pre-paid account. This established trust relation is typically manifested in a cryptographic relationship, through a shared secret key (symmetric cryptography) enabling for example a challenge-response procedure such as the AKA (Authentication and Key Agreement) procedure for GSM/UMTS and/or similar procedures. The network operator may have an agreement with the service provider, which agreement typically is manifested by a similar cryptographic relationship. The service provider may then employ the challenge-response procedure, such as GSM/UMTS AKA, for an indirect mutual authentication with the end-users of their services.

It is known to use the home operator as a base of trust for user authentication when a mobile user roams into another network managed by a so-called visited operator, as schematically illustrated by Figs. 2 and 3.

Fig. 2 is a schematic signal exchange diagram for user authentication with on-line verification by the home operator in a mobile communication system when a mobile user roams into a visited network.

The basic UMTS AKA procedure employs a shared secret key Ki, such as a subscription key associated with a user-operator subscription or a key derived therefrom, to produce a response to a challenge as well as two session keys, one for confidentiality protection (C_k) and one for integrity protection (I_k) of the traffic between the user and the visited operator. The home operator, or more specifically the HSS/AuC (Home Subscriber Server/Authentication Center) and HLR/AuC (HLR, Home Location Register), generates a random challenge (RAND) together with an authentication token (AUTN), which is later used by the user to verify that the challenge is fresh and generated by the home operator. From this challenge, the response (RES/XRES) and the keys (C_k) I_k) are calculated using the shared secret key. In GSM AKA, no integrity key or authentication token is generated, but the basic challenge-response procedure is the same. The shared secret key is traditionally implemented in a SIM card used in GSM mobile units or a UMTS SIM card (USIM) used in UMTS mobile units, depending on AKA implementation.

Referring to Fig. 2, which more or less corresponds to the standardized Extensible Authentication Protocol (EAP), one way of implementing the required signaling is summarized below:

In an initial phase, the user sends an identifier to the visited operator, and the visited operator forwards the identifier to the home operator. Based on this identifier, a HSS/AuC or equivalent on the home operator side retrieves the corresponding secret key, generates a quintet (RAND, AUTN, C_k) I _; XRES) and sends

1. Challenge (RAND), Authentication token (AUTN)

to the visited operator. These parameters are forwarded to the user by the visited operator.

2. Challenge (RAND), Authentication token (AUTN)

The user checks the AUTN, and if it is OK, calculates the Response (RES), the confidentiality key (C_k) and the integrity key (LJ. The response is sent back to the home operator via the visited operator.

3. Response (RES)

4. Response (RES)

The home operator checks if RES equals the expected response (XRES). If this is the case the keys are securely transferred to the visited operator. 5. Integrity and confidentiality keys (I and C_k)

The home operator sees the RES from the end-user and can verify that the end-user has been authenticated via the visited operator. However, the home operator has no evidence of what service agreement the user has accepted.

If the signaling is implemented in the way it is done in cellular systems today, then the home operator will not even have any evidence of user authentication. In this case, referring to Fig. 3, the signaling will be as follows:

1. RAND, AUTN, I_k, C_k, XRES

2. RAND, AUTN

The user checks the AUTN, and if it is OK, calculates the response RES, the confidentiality key C_k and the integrity key I_k.

3. RES

The visited operator checks if RES equals XRES. If this is the case, then the user is authenticated.

Exemplary general scheme for non-repudiation of service agreements

Fig. 4 is a schematic diagram illustrating the overall structure and basis for the proposed general scheme for non-repudiation of service agreements according to a preferred embodiment of the invention.

The inventors have realized that it is essential for a service provider to be able to prove that a user has accepted a given service agreement, and especially that a user has agreed to pay for a service, including verification of the accepted service charge (user non-repudiation of service agreements/service charges). This is particularly important when user authentication and payment/charging is performed via/with the help of a third trusted party such as a network operator or equivalent.

Therefore, it is proposed that the trust provider 30 acts as a general service agreement manager on behalf of the service provider and/or the user for the purpose of non- repudiation ofa service agreement between the service provider and the user. The non- repudiation scheme according to a prefened basic embodiment of the invention comprises preparation of relevant service agreement information, as well as cryptographic processing of the prepared information based on the secret key shared between the service agreement manager and a user terminal in order to generate user- signed service-agreement verification information. The user-signed verification information is subsequently forwarded to the service provider to enable verification of the service agreement based on the trust relation between the service provider and the service agreement manager.

The preparation of service agreement information in suitable electronic form (e- contract) is normally performed or at least initialized by the service provider in a contract preparation/initialization unit 22, but this information could be prepared by any of the involved parties as long as both the user and the service provider accept the agreement. For example, the service agreement manager 30 could optionally prepare the service agreement information on behalf of the service provider 20.

The cryptographic processing of the service agreement information is normally performed on the user side in a tamper-resistant module 12 in the user terminal 10. Preferably, the user terminal 10 performs the cryptographic processing in a cryptographic engine 14 based on a non-repudiation key locally derived from the shared secret key in order to generate the required verification information. In some implementations, however, the cryptographic processing may be performed by both the user terminal 10 in cryptographic engine 14 and the service agreement manager 30 in cryptographic engine 34.

The mere fact that the user-signed verification information is securely forwarded from the user terminal 10 to the service provider 20 may have a repudiation-deterring effect. Preferably, however, verification is performed on-line or off-line by the service agreement manager, or alternatively even directly by the service provider. In the offline procedure, verification information including at least a user-signed verification part, and preferably also the corresponding challenge or other input together with the user identity, is normally stored in a storage location from which it can later be retrieved by the service provider 20 and presented as evidence that the user has accepted the service agreement. In the on-line procedure, the verification information is normally forwarded more or less directly from the service provider 20 to the service agreement manager 30, thus enabling on-line proof. Based on the presented verification information, the service agreement manager 30 may then perform relevant calculation(s) and/or comparison(s) to verify, in the verification unit 36, that the user has actually accepted the service agreement.

The service agreement manager may conveniently be associated with a database that includes user ID and associated secret key Ki information for a set of users. This enables the service agreement manager to gain access to the relevant secret key for a given user based on the corresponding user ID, for various purposes such as generating user authentication parameters, cryptographic processing of service agreement information and/or service-agreement verification.

As will be explained later on, verification could alternatively be performed directly by the service provider 20 in verification unit 26.

The trust relation between the service provider 20 and the service agreement manager 30 should provide guarantees for the service provider about statements made or data provided by the service agreement manager. Since the transmitted information (e.g. service agreement information, charging data, authentication parameters and/or other suitable information) is generally considered sensitive and the identity of the communicating parties is essential for the guarantees mentioned above, the communication link between the service provider and the service agreement manager should be secure. This could be achieved by e.g. using TLS or IPSec, or by encrypting/signing individual messages.

Examples of AKA-integrated non-repudiation/verification of service agreements It may be useful to begin by describing the invention in the context of AKA-integrated non-repudiation/verification of service agreements.

In a series of preferred embodiments, non-repudiation of service agreements and especially service charges is integrated with challenge-response based authentication and key agreement (AKA) for network access (e.g. GMS/UMTS AKA or similar authentication), using the same shared secret key that is normally employed for AKA. A great advantage with AKA-integrated non-repudiation is that existing infrastructure can be re-used.

In this context, it is normally assumed that the trusted service agreement manager acts as an authentication/payment manager for authenticating the user, authorizing the user for access to a service and/or establishing proof that the user has agreed to the conditions for use of a service. In a typical scenario, a network operator may implement the authentication/payment manager as a security system for establishing secure and trusted communication with a user and an access point. The operator also has trust relations with service providers and communicates with these over secure links. In response to a request for service access, the authentication/payment manager employs a secret key (generally denoted K , shared with the requesting user, to assist in authentication, authorization, non-repudiation and/or payment or charging procedures. With respect to service charges, the user agreement to pay for a service may then be tied to the UMTS/GSM AKA or similar authentication. This should preferably be performed in such a way that the service provider can be assured that the user can not deny the service agreement at a later stage.

Fig. 5 is a schematic exemplary signal exchange diagram for non-repudiation of service agreements using a dedicated non-repudiation key, with possible off-line verification. In this example, the normal challenge-response (AKA) scheme is extended with the derivation of an additional session key, which will only be shared between the user and the operator side, as well as additional service agreement information.

Consider a user that wants to access a service offered by a service provider. The user typically has to be authenticated before the service is offered. The user ID does not have to be a public identifier but it should allow a mapping to a user-associated secret key Kj, which may enable charging to be performed correctly, e.g. to the correct account. For example, the key Kj could be a subscription key, if the user has a subscription with a home operator, or a cryptographic key associated with a pre-paid account. The transfer of the user ID is generally indicated by dashed lines, since this could be regarded as an initializing phase and also partly because this is likely to be part of the batch processing of authentication vectors between the service provider and operator. It is normally required that the service provider receives information from the user that can be used to determine the identity of the authentication/payment manager to which the user is associated; for example the identity of the user's home operator. This enables the service provider to forward the user ID to the relevant authentication/payment manager in a request for AKA parameters. Based on the received user ID, the authentication/payment manager identifies the secret key Ki and generates suitable AKA parameters. The authentication/payment manager generates a random challenge RAND and calculates an expected response XRES based on the secret key Kj and the random challenge RAND as input to a given function g, and also generates the usual integrity and confidentiality keys I_k, C_k based on Ki and RAND.

The user should also agree to pay for the service. The agreement should be such that the service provider later can prove that the user really did agree. The idea here is to generate an additional key, denoted R_k, for non-repudiation of the service agreement at the same time as the user authentication and key agreement is performed and authentication parameters such as RAND and XRES, as well as (integrity) and confidentiality keys I_k, C_k are generated.

A basic exemplary signal exchange is summarized below:

1. RAND, AUTN, I_k, C_k, XRES

The service provider generates service agreement information including one or more information items such as identification of the service, service charges, time of validity, service provider identifier and so forth. In the following, the service agreement information is exemplified by a cost parameter COST_UNIT indicating a given value, the cost of a service unit. This cost parameter may, if desired, be accompanied by a nonce to randomize it, timestamps to indicate time of validity, a service identifier and a service provider identifier.

2. RAND, AUTN, COSTJ NIT

The user checks the AUTN, and if it is OK, calculates the response RES, the confidentiality key C_k and the integrity key I_k as in the standard AKA scheme. In addition to this, the extended AKA scheme generates a non-repudiation key, R_k, which is also based on the shared secret key Ki and RAND. The R_k is then used to calculate a MAC (Message Authentication Code), the COSTJVIAC, over RAND and COST_UNIT. COST_MAC = MAC(R_k, RAND || COST_UNIT). The COST MAC is returned to the service provider together with RES, the response for authentication. The service provider must not be able to fake the COSTJVIAC for the system to achieve the goal of non-repudiation.

3. RES, COST_MAC

The service provider checks that RES matches XRES. The service provider also retains verification information, for example the user ID, RAND, COST_UNIT and COST_MAC for later proof of the user agreement.

If desired or requested, the service provider may later forward the verification information to the authentication/payment manager on the operator side.

4. COSTJUNIT, COSTJVIAC, USER ID, RAND

The authentication/payment manager on the operator side then acts as a verifier and checks that COST JVIAC equals the expected XMAO=MAC(R_k, RAND || COST_UNIT) to verify that the user has accepted the service agreement and the service cost.

Of course, there is a risk that the user fakes the COST_MAC. To this end, some strategy for random on-line testing of the COSTJVIAC may be used to deter users from such actions.

In essence, this exemplary approach is based on extending the basic AKA with a non- repudiation key shared between operator and user, but which is not distributed to the service provider. This non-repudiation key can be used by the user to "sign" messages, which the operator is capable of verifying. As described above, an exemplary solution is to MAC data sent to the user together with the RAND using a key derived from RAND and verify the authenticity of the data. As should be understood, it is equally feasible to first perform the normal AKA signaling, verifying that RES equals XRES at the service provider, and later on, when the user requests a service over the secured link to the service provider, perform the non-repudiation signaling. This means that the service provider, after successful user authentication, sends the cost parameter COST_UNIT and associated information to the user upon a service request from the user. The user then calculates the COSTJVIAC and returns the COSTJVIAC to the service provider to enable verification of the service agreement.

Fig. 6A is a schematic exemplary signal exchange diagram for on-line verification of service agreements using a dedicated non-repudiation key. This example involves online user authentication and verification of the service agreement.

A basic exemplary signal exchange is summarized below:

1. RAND, AUTN

The service provider generates the relevant service agreement information such as a service cost parameter, COST J NIT for transfer to the user.

2. RAND, AUTN, COST JINTT.

The user checks the AUTN, and if it is OK, calculates the response RES, the confidentiality key C_k, the integrity key I_k and non-repudiation key, R_k. The COSTJVIAC is calculated and returned to the service provider together with RES, the response for authentication.

3. RES, COSTJVIAC For on-line authentication, the service provider forwards RES to the operator side. The COST_UNIT and COSTJVIAC information may be appended to RES at the same time.

4. RES, COST_UNIT, COSTJVIAC

The authentication/payment manager checks if RES equals the expected response (XRES) and that COSTJVIAC equals the expected XMAC. If the user has a prepaid account, the manager may also check that the user has sufficient funds on his account. If these conditions are met the keys are sent to the service provider.

5. I_k, C_k

When the service provider receives the keys for protecting the session between user and service provider this also indicates that the service agreement is OK.

Alternatively, as previously discussed with reference to the off-line case, it is feasible to first perform the normal AKA signaling, and later on, when the user requests a service over the secured link to the service provider, perform the non-repudiation signaling. This generally means that RES is verified and the keys I_k, C_k are sent to the service provider, and subsequently the special non-repudiation signaling is initiated by the service provider upon a service request. In the following, however, the AKA- integrated examples will mainly be described with integrated AKA and non- repudiation signaling.

Fig. 6B is a schematic exemplary signal exchange diagram for on-line verification of service agreements using an existing AKA key as non-repudiation key. If the service provider always performs on-line verification of the service agreement before the keys are sent from the operator side, then the COSTJVIAC could be generated with I_k as non-repudiation key and there would be no need to extend the AKA to generate a special non-repudiation key R . However, the service provider would not have the ability to record and keep a proof of the service agreement, as he would later receive the key I_k to be used for integrity protection of the session. The operator may keep a hash of the agreement so that the service provider cannot change data retrospectively.

Non-repudiation combined with masked authentication data

As illustrated in Figs. 7A and B, the user authentication can be modified to allow for proof of identification by introduction of masked verification data, thus enabling a service provider to present valid evidence that a user has actually been authenticated.

The overall authentication is initially based on a challenge-response procedure in which the authentication/payment manager generates an expected response XRES and the user subsequently generates a conesponding response RES. A basic idea here is to introduce a masking function f, which masks the generated expected response, and transmit the masked expected response XRES', instead of the initial expected response XRES, to the service provider. The user generates and transmits a corresponding user response RES in a conventional manner, and the service provider thus receives a masked expected response XRES' from the operator side, as well as the usual user response RES from the user. The service provider then calculates a masked user response RES' by means of an instance of the same masking function that was used on the operator side. In order to authenticate the user, the service provider simply verifies that the calculated masked user response RES' corresponds to the masked expected response XRES' received from the operator side. The masking procedure enables the service provider to prove that the user has been properly authenticated, and at the same time also prevents and/or disarms interception attacks.

The service provider may then be challenged to provide response values, or preferably response-challenge pairs, and/or service-agreement verification information to prove that users have actually been present in the network and/or utilized other services, before payments are transferred. Apparently, the authentication/payment manager and the service provider have a relation, which implies that the masking function has been exchanged between the authentication/payment manager and the service provider. This also holds true for similar information and/or functions that have to be common for the two parties.

Fig. 7A is a schematic exemplary signal exchange diagram for establishing proof of user authentication by means of masked authentication data combined with off-line verification of service agreements. In addition to the usual AKA parameters, the authentication/payment manager generates a masked expected response XRES' as a function of XRES and an optional masking random challenge SALT. For example, the masking random challenge may be based on the random challenge RAND or generated as a completely independent random value. Subsequently, the masked expected response XRES' and the random challenge RAND are transmitted, possibly together with the optional masking random SALT, to the service provider. If off-line verification of the service agreement with R_k is used, then I_k and C_k can be distributed together with RAND, AUTN and XRES'.

A basic exemplary signal exchange is summarized below:

1. RAND, AUTN, XRES', I_k, C_k, [SALT]

2. RAND, AUTN, COSTJUNIT

3. RES, COSTJVIAC

The service provider then generates RES' using an instance of the same masking function / and the same random input RAND/SALT and checks that the masked response RES' equals the masked expected response XRES'. The service provider preferably stores RES, RAND, USER ID as authentication proof information together with COST UNIT, COSTJVIAC as service-agreement verification information at a suitable location for later retrieval, if necessary, as evidence of the user authentication and the service agreement. If challenged by the authentication/payment manager, or some other related party, to provide proof of the authentication of a given user and the accepted service agreement, the service provider can transmit the information to the operator side.

4. RES, RAND, USER ID, COSTJ NIT, COSTJMAC

It should be noted that batches of randomized service-agreement verification information for a number of services provided by the service provider can be transferred off-line without any re-authentication.

Preferably, the authentication/payment manager then retrieves the secret key Kj associated with the given user and calculates the expected response value XRES based on the received RAND and the secret key K_l3 and finally compares the received RES value with the calculated XRES value to verify whether the user has actually been authenticated at the service provider. If the RES value matches the XRES value, the proof information is considered valid. In the same way, the authentication/payment manager calculates the expected service agreement verification information XMAC based on the non-repudiation key R_k and RAND, COSTJUNTT received from the service provider. The authentication/payment manager then compares COSTJVIAC with XMAC to verify the service agreement.

Alternatively, the service provider simply transmits the RES value and the user ID of a given user. In this case, the authentication/payment manager typically needs to store XRES values (or RAND values allowing re-calculation of conesponding XRES values) for the users so that a comparison between RES and XRES can be performed.

If the optional masking random challenge SALT was not explicitly transmitted from the authentication/payment manager, the service provider may derive it prior to verification of authentication, preferably based on the random challenge RAND. A masked user response RES' is then calculated by the service provider by means of the user response RES and the optional, received or derived, masking random challenge SALT as input to the masking function

As mentioned, the masking random challenge SALT is optional and may be omitted from the authentication procedure. In such a case, no random challenge SALT is input to the masking function/^* for calculating the masked expected response XRES' and masked user response RES', respectively. However, in order to increase the security, and particularly to defeat pre-computation attacks, the masking random challenge SALT is preferably included as masking function input. Thus, the masking random challenge SALT could be generated as a completely random value by the authentication/payment manager and subsequently transmitted to the service provider together with the masked expected response XRES' and random challenge RAND. However, in order to avoid additional signaling between the operator side and the service provider, the masking random challenge SALT could alternatively be derived from the random challenge RAND. In this case, the authentication/payment manager preferably generates the masking random challenge SALT by some function h of the random challenge RAND. Hence, no special masking random challenge SALT needs to be transmitted to the service provider, which instead may use the same function h to generate the masking random challenge SALT from the random challenge RAND. An example of a usable masked random challenge SALT is simply to reuse the random challenge RAND as masked random challenge SALT, with h hence being represented as a unity function.

The function h may be a public function or a function associated and distributed with the business agreement between the service provider and the legal party (such as a home operator) of the authentication/payment manager.

The masking function /used on one hand by the authentication/payment manager for generating the masked expected response and on the other by the service provider to calculate the masked user response could be a one-way function and/or a hash function. Preferably, the masking function is a cryptographic hash function having one-way functionality and properties that make it infeasible to find two distinct inputs, which hash to a common value.

The masking function /may be a public function, or a private function known by the authentication/payment manager and the service provider. In the latter case, the private masking function could be associated with a business agreement between the legal party, such as a given home operator, of the authentication/payment manager and the service provider. If the legal party of the authentication/payment manager, for example a home operator, has such business agreement with several different service providers, a corresponding private function may be used by the operator for each service provider, i.e. each operator-provider agreement is manifested in a private masking function.

In order to allow smooth migration in relation to existing infrastructure, the service provider is preferably notified whether or not the masking function has been employed when calculating the distributed expected response. Thus, the protocol for distributing authentication parameters is preferably extended with such an indication. Similarly, an indication of which masking function to use may be included in the protocol if a choice between different masking functions is present.

If an on-line procedure is desired, as illustrated in Fig. 7B, the authentication proof information and the service-agreement verification information are forwarded more or less directly from the service provider to the authentication/payment manager.

A basic exemplary signal exchange is summarized below:

1. RAND, AUTN, XRES', [SALT] 2. RAND, AUTN, COSTJTNIT

3. RES, COSTJVIAC

The service provider generates RES' and checks that the masked response RES' equals the masked expected response XRES'. Then the signaling proceeds.

4. RES, COST_UNIT, COST _MAC

On the operator side, RES and COSTJVIAC are compared to XRES and XMAC, respectively. If the verification is successful, the keys are securely transferred to the service provider.

5. I_k, C_k

As previously discussed, for on-line verification of a service agreement, it is possible to use either a dedicated non-repudiation key R_k or the integrity key I_k as a non- repudiation key for calculating the COSTJVIAC and XMAC parameters.

For more information on the masking procedure, reference is made to our co-pending US Patent Application Serial No. 10/278,362, filed on October 22, 2002, which is incoφorated herein.

Exemplary ticket-based approach In the following we will describe some examples of AKA-integrated non-repudiation of service agreements with a ticket-based approach.

Ticket based payment systems in general are well known in the literature, see for example U.S. Patent 5,739,511. A particular ticket system is based on the idea that a BASE_TICKET is repeatedly hashed, a given number N of times, by a known hash function into a STARTJTICKET:

START TICKET = HASH( HASH( .. HASH(BASEJTICKET))),

where the BASEJTICKET typically corresponds to TICKET_N, and the STARTJTICKET corresponds to TICKETJ). The party paying generates the preimage of STARTJTICKET or the last TICKET used. The party receiving the payment can then check that the preimage hashes into that ticket. Since the tickets are mutually interrelated by the hash function, or other suitable one-way function, the START_TICKET can be obtained from any further ticket by repeatedly applying the function. This means that a check of the progress of the payment transaction can be obtained without the need for repeatedly performing a complex and time-consuming verification process. The number of times the hash function must be applied to obtain the start ticket is directly related to the number of tickets consumed by the user of the service.

One condition for such a ticket-based system to be secure is that the base ticket is unpredictable. The base ticket may thus be formed by concatenation of some random entity and a hash of other known information elements.

In accordance with the invention, the previously described non-repudiation scheme with its variants can be extended in such a way that the user may return a START TICKET and a keyed non-repudiation MAC, denoted TICKET JVIAC, of START πCKET and COSTJ NIT to enable non-repudible payments for several events/services without having repeated contact with the operator or performing a new user authentication. There are several variants on how the START_TICKET can be produced. A main feature would be that the service provider should be able to verify that the STARTJTICKET is genuine and is issued by or on behalf of the authenticated user.

A particular solution for ticket generation is that the user generates the BASEJTICKET and derives the STARTJTICKET. The user then utilizes a non- repudiation key such as R_k and computes a non-repudiation TICKETJVIAC, over the STARTJTICKET and the COST_UNIT and sends the STARTJTICKET and the TICKETJVIAC to the service provider. The service provider either stores the verification information for optional later verification in an off-line procedure, or sends the message on-line to the operator side for verification of the TICKETJVIAC to accept the tickets.

Fig. 8A is a schematic exemplary signal exchange diagram for ticket-based non- repudiation, with possible off-line verification.

A basic exemplary signal exchange is summarized below:

1. RAND, AUTN, I_k, C_k, XRES

The service provider generates the relevant service agreement information, here exemplified by the cost parameter COST_UNIT, and preferably forwards this information with the necessary AKA parameters to the user.

2. RAND, AUTN, COSTJ NTT

The user checks the AUTN, and if it is OK, calculates RES, the keys I_k, C_k, and preferably also R_k. The user generates a BASEJTICKET and derives the

STARTJTICKET by repeated hashing a selected number of times. The R_k is then used to calculate TICKET_MAC, over START TICKET and COSTJUNIT. TICKETJVIAC = MAC(R_k5 STARTJTICKET || COST_UNIT). If an explicit randomization is desired, TICKETJVIAC could alternatively be calculated as MAC(R_k, STARTJTICKET || COST JNIT || RAND). The TICKETJVIAC and the STARTJTICKET are returned to the service provider together with RES. 3. RES, STARTJTICKET, TICKETJVIAC

The service provider retains verification information, for example the user ID, RAND, COST UNIT and COSTJVIAC for later proof of the user agreement.

As the tickets are consumed by the user, the service provider checks, for each ticket, that TICKET -1=HASH(TICKETJ), or that the START_TICKET can be obtained by repeatedly applying the hash function.

If desired or requested, the service provider may later forward verification information such as COSTJJNIT, STARTJTICKET, LASTJTICKET and TICKETJVIAC to the authentication/payment manager on the operator side. This enables the authentication/payment manager to verify the TICKETJVIAC and determine the number of tickets consumed in order to charge the user with the proper amount.

Fig. 8B is a schematic exemplary signal exchange diagram for ticket-based non- repudiation, with on-line verification. This example involves on-line user authentication and ticket-based verification of the service agreement.

A basic exemplary signal exchange is summarized below:

1. RAND, AUTN

The service provider generates the relevant service agreement information such as a service cost parameter COSTJJNIT for transfer to the user. 2. RAND, AUTN, COST_UNIT.

The user checks the AUTN, and if it is OK, calculates RES, the keys I_k, C_k, and preferably also R_k. The user generates a BASEJTICKET and derives the START TICKET, and then a TICKETJVIAC is calculated. The TICKET vlAC and START_TICKET are returned to the service provider together with RES.

3. RES, STARTJTICKET, TICKET_MAC

For on-line authentication and verification, the service provider forwards RES to the operator side. The COSTJJNIT, STARTJTICKET and TICKETJVIAC information may be appended to RES at the same time.

4. RES, COSTJJNIT, STARTJTICKET, TICKETJVIAC

The authentication/payment manager checks if RES equals the expected response (XRES) and that TICKETJVIAC equals the expected XMAC. If these conditions are met the keys are sent to the service provider.

5. I_k, C_k

The user then starts consuming tickets, and the service provider checks the tickets. The LAST_TICKET received is finally forwarded from the service provider to the operator side for verification and subsequent handling of the payment.

Fig. 9 is a schematic exemplary signal exchange diagram for ticket-based non- repudiation, where the base ticket is prepared by the authentication/payment manager on behalf of the user. In this example, the operator side generates the BASEJTICKET based on COST_UNIT information and other relevant data received from the service provider (or prepared by the operator on behalf of the service provider) and derives the START TICKET. The operator then encrypts the BASEJTICKET with a non- repudiation key such as R_k into ENCJTICKET = ENC(R_k, BASEJTICKET) and sends it together with the START_TICKET to the service provider. The service provider then forwards the ENCJTICKET, preferably together with RAND and AUTN to the user, which may extract the BASE TICKET by decryption. The user is then capable of deriving the STARTJTICKET, and can start consuming tickets once the service provider has access to the necessary session keys I_k, C_k. Non-repudiation is ensured since only the user can decrypt the BASEJTICKET and thus generate correct preimages.

A basic exemplary signal exchange for the on-line case is summarized below:

1. RAND, AUTN, ENCJTICKET, START TICKET

2. RAND, AUTN, ENC TICKET.

The user checks the AUTN, and if it is OK, calculates RES, the keys I_k, C_k, and preferably also R_k. Conveniently, the user regenerates the BASEJTICKET by decrypting the ENCJTICKET using Rk, and then derives the START TICKET. The user returns the RES to the service provider.

3. RES

For on-line user authentication, the service provider forwards RES to the operator side.

4. RES

The authentication/payment manager checks if RES equals the expected response XRES, and sends the session keys to the service provider upon successful authentication. 5. I , C_k

It should be understood that the ticketing procedure does not have to be included in the authentication stage of the overall signaling but could be performed later.

General contract signing

As previously indicated, the service agreement information may be a general electronic contract. For general contract signing, a specially designed embodiment that allows off-line verification by the service provider involves masking of both expected verification information generated by the service agreement manager and user-signed verification information by means of local instances of the same masking function.

The below solution for signing a contract that includes various service agreement information has similarities with the ticket-based system for payments described above and in its basic form it also makes use of a masking mechanism similar to that used for non-repudiation of user authentication.

The solution is based on the assumption that the user and a general service agreement manager have a shared secret. When focusing slightly more on the payment part of the overall procedure, the service agreement manager is sometimes referred to as a payment provider in the following. If the payment provider is a cellular GSM/UMTS operator such a shared secret exists and it is stored in the (U)SIM on the user side. A relatively generic setting is illustrated in Fig. 10.

Preferably, the service provider 20 or the payment provider 30 prepares the contract to be signed by the user 10. Typically, the contract is then securely distributed to all the relevant parties. The payment provider 30 on the operator side, uses the shared secret in a keyed hash function to calculate a keyed hash, denoted a signature MAC, of the contract. The keyed hash function can either be performed as a true keyed hash or a hash followed by a keyed function. A particular solution fitting the AKA and (U)SIM case is to hash the contract into a variable RAND_CONT corresponding to the normal RAND in the AKA procedure, and feed this RAND_CONT into the AKA procedure and in this way generate a signature MAC conesponding to the normal RES. The signature MAC may also be generated with the help of one of the keys coming out of the AKA procedure. This normally assumes that either a correct AUTN variable is available or that the sequence number checking mechanism is disabled.

The signature MAC is then passed through a (public) masking function (this refers to a generalization of the masking function /previously described). The masking function is a cryptographic hash function, i.e. it is in practice impossible to find the preimage of an output from the function. The masked signature MAC is sent to the service provider 20 to be used by him to verify the user's signing of the contract.

When the user signs the contract he also employs the shared secret and calculates the signature MAC by means of a keyed hash function. The user sends the signature MAC to the service provider, which knows the public masking function and thus can check the signature.

To give the user a simple procedure to check the authenticity of the contract, the masked signature MAC could be sent to the user at the same time as the contract itself. The contract may also contain other information used in the complete payment procedure, e.g. a SALT used in the public masking function.

When the AKA procedure is used, the contract signing idea boils down to letting RAND in the AKA procedure be a HASH of the contract data the user shall sign. Fig. 11 is a schematic exemplary signal exchange diagram for the contract signing implementation of Fig. 10, when re-using an AKA procedure.

Upon a service request from the user, the service provider forwards the received USER ID, possibly together with the contract CONT if this is prepared by the service provider, to the service agreement manager. The service agreement manager may generate a RAND_CONT as a function y of the contract CONT. The service agreement manager then calculates an expected signature MAC, denoted XMAC based on Ki and RAND_CONT: XMAC = g(K_{, RAND_CONT). This signature MAC is then masked by a general masking function m into a masked expected signature MAC denoted XMAC, optionally using a random masking challenge RAND/SALT as additional input to the masking function.

1. XMAC, RAND/SALT

The service provider then forwards the contract CONT to the user.

2. CONT

Using an instance of the function y, the user generates RAND CONT if this parameter is not forwarded from the operator side, and also calculates the user signature MAC based on Kj and RAND_CONT: MAC = g(K_i? RAND_CONT). This MAC is forwarded to the service provider.

3. MAC

The service provider may then use an instance of the general masking function m to calculate a masked user signature MAC, denoted MAC, and finally compare the calculated MAC to the XMAC received from the operator side to verify the contract. Preferably, the service provider retains verification information such as MAC, RAND_CONT/CONT and USER ID. If challenged by the service agreement manager, or an on-line procedure with the service agreement manager is desired, the service provider may forward this verification information to the service agreement manager.

The service agreement manager then verifies that MAC equals XMAC, which means that the service agreement based on the contract is finally verified and that the user is at least implicitly authenticated.

A novelty of the general contract signing procedure is that it allows off-line verification by the service provider by means of introduction of masked verification data. In other words, the contract preparation performed between the service provider (SP) and the operator may be separated in time from the contract signing/verification performed between the user and the service provider (SP). Natural applications of this scheme include cases when a number of contracts are prepared in one SP-operator session either for the same user with different conditions (e.g. at different times or service levels), or for multiple users with similar conditions (e.g. when providing a subscription offer).

Isolation of keying material In another approach, returning again to AKA-integrated non-repudiation of service agreements, AKA data can be used as secret inputs to a pseudo-random function (PRE) to derive a new set of AKA data and/or a non-repudiation key.

By way of example, instead of doing a direct extension of the AKA procedure to generate the additional key R_k) the keys C_k and I_k can be used as secret inputs to a pseudo random function, which is used to derive new confidentiality (C_k) and integrity (I_k) k^eY^s _> a non-repudiation key (Rk) and a new response (RES'). The C_k and I'_k are used and distributed instead of C_k and I_k. In this way the original AKA scheme, which usually is implemented in a smart card, does not have to be changed. A major benefit is that it is possible to isolate keying material for GSM/UMTS use and keying material used for user authentication and non-repudiation when accessing services. Thus even if keying material for services is lost or stolen it cannot be used to access the fundamental communications services.

A variant in utilizing the isolation step would be to use it to generate a new shared secret used in a full AKA scheme.

If we denote keying material in general by K(i), then the derivation step is denoted K(i+1) = PRF(K(i), SALT), where PRE is a pseudo-random function. The SALT should contain random information and may e.g. contain information unique for a service and/or a service provider. For example, the PRE can be implemented as in the Secure Real-Time Transport Protocol (SRTP).

Although K(i) typically is output data from a basic AKA, it should be understood that other data may be used as argument to the PRF function. In addition, the number of input arguments and result variables may vary according to the particular application at hand.

Fig. 12A is a schematic exemplary signal exchange diagram for AKA-integrated non- repudiation of service agreements based on different isolated keying sets, with possible off-line verification.

The authentication payment manager generates the usual AKA data based on the secret key Kj and a random challenge RAND. Let K(0) = [C_k) I_k; XRES)]. The authentication/payment manager calculates K(l) = [C_k, I'_k, R_k, XRES'] = PRF(K(0), RAND/SALT). The SALT may be equal to RAND combined with service provider Id, SP ID.

1. RAND, AUTN, ι'_k, C'_k, XRES', [SALT] 2. RAND, AUTN, COSTJJNIT, [SALT]

The user checks AUTN as usual. He then runs the AKA to derive K(0) = I_k, C , RES and applies the PRE on K(0) to derive K(l) = C' , I'_k, R_k and RES'. The user also generates the COSTJVIAC over RAND and COSTJJNIT using R_k.

3. RES', COSTJVIAC

The service provider checks that RES' matches the XRES' received from the operator side, and stores verification information for later retrieval if necessary. If challenged or on its own initiative, the service provider may forward the verification information to the operator side for verification of the service agreement.

Fig. 12B is a schematic exemplary signal exchange diagram for AKA-integrated non- repudiation of service agreements based on different isolated keying sets, with on-line verification.

1. RAND, AUTN, XRES', [SALT]

2. RAND, AUTN, COST_UNIT, [SALT]

The user checks AUTN as usual, and then runs the AKA to derive K(0) = I_k, C_k, RES and applies the PRE on K(0) to derive K(l) = C'_k, I*_k, R_k and RES'. The user also generates the COST_MAC over RAND and COSTJJNIT using R_k.

3. RES', COST_MAC

The service provider checks that RES' matches the XRES' received from the operator side, and forwards the verification information to the operator side for verification of the service agreement. 4. COSTJJNIT, COSTJVIAC

If COSTJVIAC matches XMAC, the session keys I'_k, C' are transferred to the service provider for use in the communication between the service provider and the user.

5. C_k) I'_k

Of course, the ticket-based solution described above may also be based on keying material derived from the initial AKA parameters.

It should be understood that the isolation of the keying material for normal network access from authentication and keying material for access to services provided by the service provider is a general stand-alone feature of the invention, which is not limited to any combination with non-repudiation of service agreements.

In the procedure described above, the SALT is assumed to be available at the operator side as well as at the user. If the SALT equals the RAND this is trivially true but if other information like time-stamps or a SALT independent of RAND value should be used, these values have to be agreed with/sent to the user. An especially important case is when the user cannot determine the true SPJD (Service Provider Identity) from context but has to rely on received information and this SPJD is used to isolate parameters for different service providers. In this case the information could be transfened in the AUTN parameter in the standard AKA procedure or it could be sent in a MACed message as described for signing of contracts above, i.e. a keyed MAC protects the sensitive parameters. The key used for the keyed MAC should be a key shared only by the operator and the user, e.g. I_k or R_k.

This generally corresponds to generating service dependent AKA parameters from the basic AKA procedure. Exemplary applications involving a payment broker

Fig. 13 is a schematic exemplary block diagram in a distributed implementation involving an identity broker as well as a payment broker, employing an established chain of trust between the identity broker, payment broker and service provider.

In the scenario to be described we introduce an additional participant namely a payment broker 40. The set-up of Fig. 13 thus includes a user 10, a service provider 20, an authentication manager 30 sharing a secret with the user, and a payment broker 40. The payment broker may have relations with several operators/authentication managers and mediates user authentication information between operators and service providers, assists in verifying payments/user ability to pay and handles payment/charging data. The payment broker may take the role of a trusted third party, which can verify user service agreements.

Payments may be linked to the operator with whom the user may already have a payment relation or they may be linked to and performed via an independent party or by the payment broker himself.

We also introduce the concept of a user identity broker, normally ananged on the operator side in association with the authentication manager. Users may want to use different identities for different services. The identity broker normally maps user identities for service access to user identities for operators (i.e. TMST). Identity brokering may take place in several steps.

The relation between the user's service ID and the user's id at the operator has to be given to the identity broker. Usually the operator running the identity broker will generate this pairing. For security reasons it is natural to have the last identity brokering function performed by the operator. The Service ID may have several parts. Individual parts may indicate the payment broker and the identity broker to be used. One user may of course use several payment brokers for a given operator identity. The payment broker may keep a record showing which operator a given user service Id is associated to if that information cannot be derived from the user service Id.

Below, two signaling schemes will be described with reference to the scenario depicted in Fig. 13. The first scheme is for a user with a post pay subscription and the second scheme is for prepaid services.

Post pay scenario

Fig. 14 is a schematic exemplary signal exchange diagram for non-repudiation of service agreements in a post pay scenario in the set-up shown in Fig. 13.

1. User service ID including ID of payment broker, USER_SERVICE JD, PB ID

2. USER_SERVICEJD, SPJD.

The payment broker knows to which operator/identity broker the user service id is associated.

3. USER_SERVICEJD, SPJD, PBJD

The operator, taking on the role of identity broker, maps the USER SERVICE JD to the operator internal ID (IMSI) and retrieves corresponding AKA parameters RAND, AUTN and K(0)=[C_k, I_k, XRES]. The operator derives K(l) = [C_k) I'_k, XRES'] = PRF(K(0), [RAND, PBJD]) where PBJD is the payment broker ID, RAND is optional. By explicitly letting K(l) depend on PBJD the keying material is tied to a specific payment broker. 4. RAND, AUTN, C'_k, I'_k, (SPJD || PBJD, keyed MAC(I_k, SPJD || PBJD)

The keys C'_k and I'_k are used for secure communication between the payment broker and the user. Thus I'_k may be used as a non-repudiation key, e.g. when calculating COSTJVIAC, and C'_k may be used to derive e.g. an ENCJTICKET.

The payment broker then derives K(2) = [C"_k, I"_k, XRES"] = PRF[K(1), [RAND, SPJ ]).

5. RAND, AUTN, C"_k, I"_k, XRES", (SPJD || PBJD, keyed MAC(I_k, SPJD || PBJD)

6. RAND, AUTN, COSTJJNIT, (SPJD || PBJD, keyed MAC(I_k, SPJD || PBJD)

The user checks AUTN and calculates K(0), K(l) and K(2) using the shared secret key Ki, the received RAND and the pseudo-random function(s).

7. RES"

The service provider checks RES" and determines the user's authorization level. The service provider now initiates the use of a secure connection to the user using C" and

T"

I k-

When a service for which the user has to pay is invoked the user should send a COST_MAC.

8. COST_MAC

9. COSTJJNIT, COSTJVIAC

The payment broker verifies the COSTJVIAC, and initiates a payment procedure. 10. OK

Prepaid scenario

Fig. 15 is a schematic exemplary signal exchange diagram for non-repudiation of service agreements in a prepaid scenario in the set-up shown in Fig. 13.

In this case we illustrate a case when the user uses a prepaid account and gets tickets generated by the payment broker. Here, the required transfer of context information for the derivation of isolated AKA parameters is omitted.

1. USER_SERVICEJD, PBJD

2. USER SERVICE JD, COST UNIT, SPJD

The payment broker knows to which operator/identity broker the USER_SERVICEJD is associated.

3. USER_SERVICEJD, COSTJJN T, SPJD, PBJD

The operator maps the USER_SERVICEJD to the operator internal ID (IMSI) and retrieves conesponding AKA parameters RAND, AUTN and generates K(0)=[C_k, I_k, XRES]. The operator derives K(l) = [C'_k, I'_k, XRES'] = PRF(K(0), [RAND, PBJd]) where PBJd is the payment broker Id, RAND is optional. By explicitly letting K(l) depend on PBJd the XRES' and the keying material is tied to a specific payment broker.

The operator also checks the users prepaid account. Depending on the policy employed the operator reserves a number, N#, of COST JJNITS on the users account and sends N# to the payment broker. 4. RAND, AUTN, C'_k, I'_k, N#

The payment broker generates a BASEJTICKET and calculates the STARTJTICKET and the ENCJTICKET using C_kas encryption key. The STARTJTICKET is generated such that it is valid for some number N'# < N# of COST JJNITS.

The payment broker then derives K(2) = [C"_k, I"_k, RES"] = PRF[K(1), [RAND, SPJd]).

5. RAND, AUTN, C"_k, I"_kj XRES", ENC TICKET, STARTJTICKET

6. RAND, AUTN, COSTJJNiT, START_TICKET, ENC_TICKET

7. RES"

The service provider checks RES" and initiates the use of a secure connection to the user using C"_k and I"_k.

When a service for which the user has to pay is invoked the user should send a TICKET to the service provider. To be able to do this the user decrypts the ENC TICKET and iterates the HASH function to check the number of tickets he has and to check that the STARTJTICKET is valid.

He then sends a TICKET, say TICKETJ.

8. TICKETJ The service provider checks the tickets received. When the session is closed, the service provider sends the last ticket received to the payment broker.

9. LAST TICKET

The payment broker checks the received ticket and generates a charging record, which is sent to the operator.

10. CHARGING RECORD

Finally, the user account is adjusted accordingly.

Re-authentication

The service provider may for different reasons want to have a possibility to re- authenticate a user. One way of achieving this is to iterate the generation of K(n), i.e. when the n:th authentication takes place, keying material K(n+1) = PRF[K(n), [RAND, SPJD]) is used. This means that the service provider has access to an instance of the pseudo-random function, PRE, in order to be able to generate the required authentication parameters and session keys. In short, the service provider generates new session keys and expected response of order n+1 using the pseudorandom function, and sends RAND to the user in a re-authentication request. The user then generates the new session keys and user response of order n+1 using the pseudorandom function, and returns the generated user response of order n+1 to the service provider. The service provider may then verify the received response, and start communicating with the user based on the new session keys.

Preferably, n is sent to the user, which may keep a simple replay list to guard against replay attacks. More on implementational aspects

The above-described steps, actions and algorithms may be implemented in software/hardware or any combination thereof. For hardware implementations, ASIC (Application Specific Integrated Circuit) technology or any other conventional circuit technology may be used. Although, special tamper-resistant hardware may be prefened for security reasons, properly protected software implementations are often more convenient.

Fig. 16 is a schematic block diagram illustrating an example of a service agreement manager according to a prefened embodiment of the invention. The service agreement manager 30 of Fig. 16 basically includes a communication interface 31 to a link for external communication, a database 32, an authentication and keying unit 33, a verification unit 36, an optional ticketing unit 37 and a payment/charging unit 38. The database 32 includes information such as user ID and associated secret key Kj information. The authentication and keying unit 33 is operable for generating the relevant authentication and key parameters and may also hold the optional masking and pseudorandom functions used in various embodiments. The verification unit 36 performs relevant calculation(s) and or comparison(s) to verify that the user has accepted a given service agreement. The optional ticketing unit 37 may generate relevant tickets on behalf of the user and/or perform ticket verification. As the name indicates, the payment unit 38 handles transfer of payments and makes sure that e.g. charging is performed conectly, e.g. to the conect account.

Fig. 17 is a schematic block diagram illustrating an example of a service provider according to a preferred embodiment of the invention. The service provider 20 of Fig. 17 basically includes a communication interface 21 to a link for external communication, a contract preparation unit 22, an optional authentication unit 23, a unit 25 for information forwarding and/or storage, and an optional verification unit 26. In the contract preparation unit 22, the service provider typically prepares the relevant service agreement information in accordance with the requested service and the cunent conditions for use of the service. Alternatively, the contract preparation is performed by some other party on behalf of the service provider, but usually such external contract preparation is anyway initialized from the service provider. For masked contract signing and/or user authentication, the service provider may perform verification of an accepted service agreement and/or user authentication in the verification unit 26 and/or authentication unit 23. In off-line procedures, the service provider may want to store verification information in the unit 25 for later forwarding to the service agreement manager 30 or other party assigned by the service agreement manager.

Fig. 18 is a schematic block diagram illustrating an example of a user terminal according to a prefened embodiment of the invention. The user terminal 10 of Fig. 18 basically includes a communication interface 11 to a link for external communication and a tamper-resistant module 12. The tamper-resistant module 12, which may resemble a removably ananged SIM or USIM card, includes an I/O unit 101, an AKA algorithm unit 102, a securely implemented (encapsulated) shared secret key Ki 103, a cryptographic processing unit 104 for purposes such as MAC/decryption and an optional ticketing unit 105 for ticket-based non-repudiation. It may even be possible to modify existing (U)SIM cards by implementing functionality such as the cryptographic processing and ticketing as software in the (U)SIM application toolkit environment of the (U)SIM cards, with a suitable interface between the AKA unit and the application toolkit environment.

The embodiments described above are merely given as examples, and it should be understood that the present invention is not limited thereto. Further modifications, changes and improvements which retain the basic underlying principles disclosed and claimed herein are within the scope and spirit of the invention.

Claims

1. A method for non-repudiation of a service agreement between a user and a service provider in a communication system, said method comprising the steps of: - securely sharing a secret key between a user terminal and a service agreement manager, said service provider having a trust relation with said service agreement manager; preparing service agreement information; cryptographically processing, based on said shared secret key, said service agreement information to generate user-signed service-agreement verification information; and forwarding said user-signed verification information to said service provider to enable verification of the service agreement based on the trust relation between said service provider and said service agreement manager.

2. The method according to claim 1, wherein said step of cryptographically processing said service agreement information is securely performed in said user terminal to generate said user-signed verification information.

3. The method according to claim 1 or 2, wherein said step of cryptographically processing said service agreement information is performed based on a non- repudiation key locally derived from said shared secret key.

4. The method according to claim 2, further comprising the steps of: - generating, at said service agreement manager, expected verification information at least partly based on said service agreement information and said shared secret key; and verifying, at said service agreement manager, that said user-signed verification information conesponds to said expected verification information.

5. The method according to claim 2, wherein said user-signed verification information is generated in said user terminal in response to a random challenge initiated from said service agreement manager, and said service agreement information.

6. The method according to claim 2, wherein said user-signed verification information is generated in said user terminal based on a user-side-initialized ticket, and said service agreement information.

7. The method according to claim 1, wherein said step of preparing service agreement information is initialized by said service provider.

8. The method according to claim 1, wherein said step of cryptographically processing said service agreement information comprises the steps of: - said service agreement manager performing cryptographic processing of said service agreement information based on said shared secret key to generate a cryptographic representation of said service agreement information, said cryptographic representation being forwarded to said user; and said user terminal performing cryptographic processing of said cryptographic representation based on said shared secret key to generate said user- signed verification information.

9. The method according to claim 8, wherein said step of said service agreement manager performing cryptographic processing comprises the steps of: - generating a ticket based on said service agreement information; and encrypting said ticket based on a non-repudiation key locally derived from said shared secret key; and said step of said user terminal performing cryptographic processing comprises the step of decrypting said encrypted ticket based on said non-repudiation key locally derived from said shared secret key.

10. The method according to claim 1, wherein said service agreement information is a general electronic contract, and said method further comprises the steps of: said service agreement manager generating expected service-agreement verification information based on said shared secret key and said electronic contract; - said service agreement manager masking said expected verification information by a masking function; said service agreement manager forwarding said masked expected verification information to said service provider; said service provider masking said user-signed verification information by an instance of the same masking function to generate masked user-signed verification information; said service provider verifying that said masked user-signed verification information conesponds to said masked expected verification information obtained from said service agreement manager.

11. The method according to claim 10, wherein said step of said service agreement manager generating expected service-agreement verification information comprises the step of applying a hash of the contract as a random challenge in a normal challenge-response based authentication and key agreement procedure.

12. The method according to claim 10, wherein said masking function is a crytpographic hash function.

13. The method according to claim 1, wherein said non-repudiation method is integrated with a challenge-response based authentication and key agreement (AKA) procedure for network access, said shared secret key being the same as a secret key used for AKA.

14. The method according to claim 13, wherein keying material for non-repudiation of the service agreement is isolated from keying material for said challenge-response based AKA procedure.

15. The method according to claim 14, wherein said keying material for non- repudiation is generated by means of a pseudo-random function based on keying material for AKA as input to said pseudo-random function.

16. The method according to claim 14, wherein said keying material for non- repudiation is tied to a specific payment broker interoperating with an authentication manager, said authentication manager and said user terminal sharing said secret key.

17. The method according to claim 14, wherein said keying material for non- repudiation is tied to said service provider in order to isolate said keying material from conesponding keying material for another service provider.

18. The method according to claim 1, wherein said service agreement information includes service charge information and said service agreement manager is a payment provider handling payment of said service on behalf of the user.

19. The method according to claim 1, wherein said service agreement manager includes a user identity broker and a payment broker arranged between said service provider and said identity broker, and a chain of trust is established between the service provider, the payment broker and the identity broker, said identity broker sharing said secret key with said user terminal.

20. The method according to claim 19, further comprising the step of said payment broker verifying said user-signed verification information based on a non-repudiation key obtained from said identity broker, derived based on said shared secret key.

21. A system for non-repudiation of a service agreement between a user and a service provider in a communication system, said system comprising: means for securely sharing a secret key between a user terminal and a service agreement manager, said service provider having a trust relation with said service agreement manager; means for preparing service agreement information; means for cryptographically processing, based on said shared secret key, said service agreement information to generate user-signed service-agreement verification information; and - means for forwarding said user-signed verification information to said service provider to enable verification of the service agreement based on the trust relation between said service provider and said service agreement manager.

22. The system according to claim 21, wherein said means for cryptographically processing said service agreement information is securely implemented in said user terminal.

23. The system according to claim 21 or 22, wherein said means for cryptographically processing said service agreement information operates based on a non-repudiation key locally derived from said shared secret key.

24. The system according to claim 22, further comprising: means for generating, at said service agreement manager, expected verification information at least partly based on said service agreement information and said shared secret key; and means for verifying, at said service agreement manager, that said user- signed verification information corresponds to said expected verification information.

25. The system according to claim 22, wherein said user-signed verification information is generated in said user terminal in response to a random challenge initiated from said service agreement manager, and said service agreement information.

26. The system according to claim 22, wherein said user-signed verification information is generated in said user terminal based on a user-side-initialized ticket, and said service agreement information.

27. The system according to claim 21, wherein said service agreement information is prepared by said service provider.

28. The system according to claim 21, wherein said means for cryptographically processing said service agreement information comprises: means for performing, at said service agreement manager, cryptographic processing of said service agreement information based on said shared secret key to generate a cryptographic representation of said service agreement information, said cryptographic representation being forwarded to said user; and means for performing, in said user terminal, cryptographic processing of said cryptographic representation based on said shared secret key to generate said user- signed verification information.

29. The system according to claim 28, wherein said means for performing cryptographic processing at said service agreement manager comprises: means for generating a ticket based on said service agreement information; and - means for encrypting said ticket based on a non-repudiation key locally derived from said shared secret key; and said means for performing cryptographic processing in said user terminal comprises means for decrypting said encrypted ticket based on said non-repudiation key locally derived from said shared secret key.

30. The system according to claim 21, wherein said service agreement information is a general electronic contract, and said system further comprises: means for generating, at said service agreement manager, expected service-agreement verification information based on said shared secret key and said 5 electronic contract; means for masking, at said service agreement manager, said expected verification information by a masking function; means for forwarding, at said service agreement manager, said masked expected verification information to said service provider; L0 - means for masking, at said service provider, said user-signed verification information by an instance of the same masking function to generate masked user- signed verification information; means for verifying, at said service provider, that said masked user- signed verification information corresponds to said masked expected verification 5 information obtained from said service agreement manager.

31. The system according to claim 30, wherein said means for generating expected service-agreement verification information comprises means for applying a cryptographic hash of the contract as a random challenge in a normal challenge- 0 response based authentication and key agreement procedure.

32. The system according to claim 30, wherein said masking function is a crytpographic hash function.

5 33. The system according to claim 21, wherein said non-repudiation system is integrated with a system for challenge-response based authentication and key agreement (AKA) for network access, said shared secret key being the same as a secret key used for AKA.

34. The system according to claim 33, further comprising means for isolating keying material for non-repudiation of the service agreement from keying material for said challenge-response based AKA.

35. The system according to claim 34, wherein said keying material for non- repudiation is generated by means of a pseudo-random function based on keying material for AKA as input to said pseudo-random function.

36. The system according to claim 34, wherein said keying material for non- repudiation is tied to a specific payment broker interoperating with an authentication manager, said authentication manager and said user terminal sharing said secret key.

37. The system according to claim 34, wherein said keying material for non- repudiation is tied to said service provider in order to isolate said keying material from conesponding keying material for another service provider.

38. The system according to claim 21, wherein said service agreement information includes service charge information and said service agreement manager is a payment provider operable for handling payment of said service on behalf of the user.

39. The system according to claim 21, wherein said service agreement manager includes a user identity broker and a payment broker arranged between said service provider and said identity broker, and a chain of trust is established between the service provider, the payment broker and the identity broker, said identity broker sharing said secret key with said user terminal.

40. The system according to claim 39, further comprising means for verifying, at said payment broker, said user-signed verification information based on a non- repudiation key obtained from said identity broker, derived based on said shared secret key.

41. A user terminal comprising: means for securely holding a secret key shared with an external service agreement manager, said service agreement manager having a trust relation with a service provider; - means for receiving information representative of a service agreement between a user and said service provider; means for securely performing cryptographic processing of said service agreement representative information based on said shared secret key to generate user- signed service-agreement verification information; - means for forwarding said user-signed verification information to said service provider to enable verification of the service agreement based on the trust relation between said service provider and said service agreement manager.

42. A service agreement manager for assisting in management of a service agreement between a user and a service provider in a communication system, said service agreement manager comprising: means for securely holding a secret key shared with a user terminal, said service agreement manager having a trust relation with said service provider; means for receiving user-signed service-agreement verification information generated by said user terminal based on information representative of said service agreement, and said shared secret key; means for verifying, based on said shared secret key, said user-signed verification information, thus confirming user-acceptance of the service agreement.

43. A service provider for providing service to a user in accordance with a given service agreement between the user and the service provider in a communication system, said service provider comprising: means for establishing a trust relation with a service agreement manager, said service agreement manager sharing a secret key with a user terminal; means for receiving, from said user terminal, user-signed service- agreement verification information generated at least partly based on information representative of said service agreement, and said shared secret key; means for generating masked user-signed verification information by a masking function; means for receiving, from said service agreement manager, expected verification information masked by an instance of the same masking function, said expected verification information being generated at least partly based on said service agreement information and said shared secret key; - means for verifying that said masked user-signed verification information conesponds to said masked expected verification information to confirm user-acceptance of the service agreement.

44. A method for improved challenge-response based authentication and key agreement (AKA) involving a user, a service provider and a network operator having a trust relation with said service provider, said network operator sharing a secret key with said user for mutual generation of AKA parameters, wherein the improvement is defined by isolating a first set of AKA parameters for access to a network managed by said network operator from a second set of AKA parameters for access to services by the service provider by means of a predetermined function using a representation of at least part of said first set of AKA parameters as input to generate said second set of AKA parameters.

45. The method according to claim 44, wherein said first set of AKA parameters and said second set of AKA parameters are generated on the network operator side as well as the user side based on said shared secret key and a challenge initially generated on the network operator side, and said second set of AKA parameters are securely transferred from said network operator to said service provider.

46. The method according to claim 45, wherein said service provider generates a further set of AKA parameters for re-authentication purposes by means of an instance of said predetermined function using at least part of said second set of AKA parameters as input.

47. The method according to claim 44, wherein said predetermined function is a pseudo-random function.