+

WO2003107584A1 - Non-repudiation de contrat de maintenance - Google Patents

Non-repudiation de contrat de maintenance Download PDF

Info

Publication number
WO2003107584A1
WO2003107584A1 PCT/SE2003/000934 SE0300934W WO03107584A1 WO 2003107584 A1 WO2003107584 A1 WO 2003107584A1 SE 0300934 W SE0300934 W SE 0300934W WO 03107584 A1 WO03107584 A1 WO 03107584A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
user
agreement
service agreement
information
Prior art date
Application number
PCT/SE2003/000934
Other languages
English (en)
Inventor
Rolf Blom
András MEHES
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/278,362 external-priority patent/US7194765B2/en
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to GB0424869A priority Critical patent/GB2403880B/en
Priority to AU2003238996A priority patent/AU2003238996A1/en
Priority to JP2004514264A priority patent/JP4213664B2/ja
Priority to DE10392788T priority patent/DE10392788T5/de
Publication of WO2003107584A1 publication Critical patent/WO2003107584A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/04—Masking or blinding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce

Definitions

  • the present invention generally relates to robust and secure e-commerce in modern communication systems such as mobile communication systems.
  • the present invention overcomes these and other drawbacks of the prior art arrangements.
  • the service provider may 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.
  • AKA challenge- response based authentication and key agreement
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the cryptographic processing of the service agreement information is performed both on the service agreement manager side and the user side.
  • 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.
  • 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.
  • the service agreement information may be a general electronic contract.
  • 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.
  • 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.
  • 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.
  • 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.
  • AKA challenge-response based authentication and key agreement
  • 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.
  • 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.
  • the basic principle of the above isolation mechanism is employed to improve challenge-response based authentication and key agreement (AKA).
  • 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.
  • a predetermined function such as a pseudo-random function
  • 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.
  • Fig. 18 is a schematic block diagram illustrating an example of a user terminal according to a preferred embodiment of the invention.
  • Fig. 1 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.
  • Figs. 2 and 3 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.
  • Ki shared secret key
  • 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.
  • the response (RES/XRES) and the keys (C k) I k ) are calculated using the shared secret key.
  • 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.
  • Fig. 2 which more or less corresponds to the standardized Extensible Authentication Protocol (EAP), one way of implementing the required signaling is summarized below:
  • the user sends an identifier to the visited operator, and the visited operator forwards the identifier to the home operator.
  • 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
  • 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.
  • 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.
  • the signaling will be as follows:
  • 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 .
  • the visited operator checks if RES equals XRES. If this is the case, then the user is authenticated.
  • 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.
  • 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 of a 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.
  • service agreement information in suitable electronic form 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.
  • 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.
  • 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.
  • 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.
  • verification is performed on-line or off-line by the service agreement manager, or alternatively even directly by the service provider.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • AKA challenge-response based authentication and key agreement
  • 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.
  • 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.
  • 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.
  • K secret key
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the authentication/payment manager 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • the service provider may later forward the verification information to the authentication/payment manager on the operator side.
  • 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.
  • 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.
  • 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.
  • the service provider generates the relevant service agreement information such as a service cost parameter, COST J NIT for transfer to the user.
  • 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.
  • RES 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.
  • 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.
  • RES the expected response
  • COSTJVIAC the expected response
  • 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.
  • 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.
  • 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.
  • 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.
  • the authentication/payment manager generates a masked expected response XRES' as a function of XRES and an optional masking random challenge SALT.
  • the masking random challenge may be based on the random challenge RAND or generated as a completely independent random value.
  • 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'.
  • 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.
  • 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.
  • 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.
  • 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.
  • the service provider simply transmits the RES value and the user ID of a given user.
  • 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.
  • 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
  • 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.
  • the masking random challenge SALT is preferably included as masking function input.
  • 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.
  • the masking random challenge SALT could alternatively be derived from the random challenge RAND.
  • the authentication/payment manager preferably generates the masking random challenge SALT by some function h of the random challenge RAND.
  • 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.
  • 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.
  • 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.
  • the service provider is preferably notified whether or not the masking function has been employed when calculating the distributed expected response.
  • the protocol for distributing authentication parameters is preferably extended with such an indication.
  • an indication of which masking function to use may be included in the protocol if a choice between different masking functions is present.
  • 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.
  • the service provider generates RES' and checks that the masked response RES' equals the masked expected response XRES'. Then the signaling proceeds.
  • RES and COSTJVIAC are compared to XRES and XMAC, respectively. If the verification is successful, the keys are securely transferred to the service provider.
  • 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:
  • 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.
  • 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.
  • 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.
  • TICKET JVIAC keyed non-repudiation MAC
  • 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.
  • 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.
  • 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
  • TICKETJVIAC MAC(R k5 STARTJTICKET
  • the service provider retains verification information, for example the user ID, RAND, COST UNIT and COSTJVIAC for later proof of the user agreement.
  • 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.
  • the service provider generates the relevant service agreement information such as a service cost parameter COSTJJNIT for transfer to the user.
  • a service cost parameter COSTJJNIT for transfer to the user.
  • 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.
  • the service provider forwards RES to the operator side.
  • the COSTJJNIT, STARTJTICKET and TICKETJVIAC information may be appended to RES at the same time.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • the service provider forwards RES to the operator side.
  • 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
  • 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.
  • the ticketing procedure does not have to be included in the authentication stage of the overall signaling but could be performed later.
  • the service agreement information may be a general electronic contract.
  • 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 solution is based on the assumption that the user and a general service agreement manager have a shared secret.
  • 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 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.
  • the service provider 20 or the payment provider 30 prepares the contract to be signed by the user 10.
  • 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.
  • the user 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.
  • 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.
  • Fig. 11 is a schematic exemplary signal exchange diagram for the contract signing implementation of Fig. 10, when re-using an AKA procedure.
  • the service provider 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.
  • 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.
  • the service provider then forwards the contract CONT to the user.
  • 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.
  • 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.
  • 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).
  • 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.
  • PRE pseudo-random function
  • 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 e Y 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 .
  • 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.
  • 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.
  • the PRE can be implemented as in the Secure Real-Time Transport Protocol (SRTP).
  • 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.
  • 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 SALT may be equal to RAND combined with service provider Id, SP ID.
  • 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.
  • the user also generates the COST_MAC over RAND and COSTJJNIT using R k .
  • the session keys I' k , C' are transferred to the service provider for use in the communication between the service provider and the user.
  • ticket-based solution described above may also be based on keying material derived from the initial AKA parameters.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • the first scheme is for a user with a post pay subscription and the second scheme is for prepaid services.
  • 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.
  • User service ID including ID of payment broker, USER_SERVICE JD, PB ID
  • the payment broker knows to which operator/identity broker the user service id is associated.
  • K(l) depend on PBJD the keying material is tied to a specific payment broker. 4.
  • the keys C' k and I' k are used for secure communication between the payment broker and the user.
  • 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 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).
  • 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
  • the payment broker verifies the COSTJVIAC, and initiates a payment procedure. 10. OK
  • 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.
  • the payment broker knows to which operator/identity broker the USER_SERVICEJD is associated.
  • 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 k as encryption key.
  • the STARTJTICKET is generated such that it is valid for some number N'# ⁇ N# of COST JJNITS.
  • 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).
  • the service provider checks RES" and initiates the use of a secure connection to the user using C" k and I" k .
  • the user 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.
  • TICKETJ He then sends a TICKET, say TICKETJ.
  • 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.
  • the payment broker checks the received ticket and generates a charging record, which is sent to the operator.
  • the service provider may for different reasons want to have a possibility to re-authenticate a user.
  • 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.
  • 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.
  • n is sent to the user, which may keep a simple replay list to guard against replay attacks. More on implementational aspects
  • ASIC Application Specific Integrated Circuit
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne une non répudiation efficace de contrats de maintenance entre un utilisateur (10) et un fournisseur de services (20) dans un système de communication. Une partie supplémentaire (30) de confiance, c'est à dire un gestionnaire de contrat de maintenance est introduit et l'invention est fondée sur le fait que le gestionnaire de contrat de maintenance (30) partage une clé secrète (K<SB>I</SB>) avec un terminal utilisateur (10) et que le fournisseur de services (20) présente une relation de confiance avec le gestionnaire de contrat de maintenance (30). Le schéma de non répudiation, proposée dans l'invention, est fondé de plus sur la préparation d'informations de contrat de maintenance pertinentes, le traitement cryptographique (14/34) desdites informations étant fondées sur la clé secrète (K1) partagée de façon à produire des informations de vérification de contrat de maintenance signées par l'utilisateur. Lesdites informations de vérification signées par l'utilisateur sont transmises ensuite au fournisseur de services (20) pour permettre la vérification (26/36) du contrat de maintenance fondé sur la relation de confiance entre le fournisseur de services (20) et le gestionnaire de contrat de maintenance (30).
PCT/SE2003/000934 2002-01-02 2003-06-04 Non-repudiation de contrat de maintenance WO2003107584A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
GB0424869A GB2403880B (en) 2002-06-12 2003-06-04 Non-repudiation of service agreements
AU2003238996A AU2003238996A1 (en) 2002-06-12 2003-06-04 Non-repudiation of service agreements
JP2004514264A JP4213664B2 (ja) 2002-06-12 2003-06-04 サービス合意の否認防止（ｎｏｎ−ｒｅｐｕｄｉａｔｉｏｎ）
DE10392788T DE10392788T5 (de) 2002-06-12 2003-06-04 Nichtablehnung von Dienstvereinbarungen

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US38850302P 2002-06-12 2002-06-12
US60/388,503 2002-06-12
US10/278,362 2002-10-22
US10/278,362 US7194765B2 (en) 2002-06-12 2002-10-22 Challenge-response user authentication
US45529103P 2003-03-17 2003-03-17
US60/455,291 2003-03-17

Publications (1)

Publication Number Publication Date
WO2003107584A1 true WO2003107584A1 (fr) 2003-12-24

Family

ID=29740732

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2003/000934 WO2003107584A1 (fr) 2002-01-02 2003-06-04 Non-repudiation de contrat de maintenance

Country Status (6)

Country Link
JP (1) JP4213664B2 (fr)
CN (1) CN1659820A (fr)
AU (1) AU2003238996A1 (fr)
DE (1) DE10392788T5 (fr)
GB (1) GB2403880B (fr)
WO (1) WO2003107584A1 (fr)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006079419A1 (fr) * 2005-01-28 2006-08-03 Telefonaktiebolaget Lm Ericsson (Publ) Authentification et autorisation d'utilisateurs dans un systeme de communications
WO2007111557A1 (fr) * 2006-03-28 2007-10-04 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil pour la manipulation de clés utilisées pour le cryptage et l'intégrité
JP2008532114A (ja) * 2005-02-14 2008-08-14 ノキア コーポレイション 無線通信システム内の最適なデータ転送のための方法及び装置
EP1992185A2 (fr) * 2006-03-07 2008-11-19 Electronics and Telecommunications Research Institute Procédé de réauthentification rapide dans un umts
CN100563153C (zh) * 2004-04-07 2009-11-25 华为技术有限公司 一种在端到端无线加密通讯系统中用户登记鉴权的方法
EP2182672A1 (fr) * 2007-11-16 2010-05-05 Huawei Technologies Co., Ltd. Procédé, système et équipement de distribution de clé
WO2010128348A1 (fr) * 2009-05-08 2010-11-11 Telefonaktiebolaget L M Ericsson (Publ) Système et procédé d'utilisation d'une architecture gaa/gba en tant qu'outil de signature numérique
US8560847B2 (en) 2007-12-03 2013-10-15 China Iwncomm Co., Ltd. Light access authentication method and system
WO2014155319A1 (fr) * 2013-03-28 2014-10-02 Idcapt Procede d'authentification
US9106409B2 (en) 2006-03-28 2015-08-11 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for handling keys used for encryption and integrity
US20210099866A1 (en) * 2018-07-13 2021-04-01 Micron Technology, Inc. Secure vehicular services communication
US11223954B2 (en) 2017-04-11 2022-01-11 Huawei Technologies Co., Ltd. Network authentication method, device, and system

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2168085A2 (fr) * 2007-06-20 2010-03-31 Mchek India Payment Systems PVT. LTD. Procédé et système pour authentification sécurisée
US9385862B2 (en) 2010-06-16 2016-07-05 Qualcomm Incorporated Method and apparatus for binding subscriber authentication and device authentication in communication systems
KR101400736B1 (ko) 2013-10-16 2014-05-29 (주)씽크에이티 신뢰기관과의 연계를 통한 부인방지기능을 포함한 전화인증서 구현방법 및 시스템
WO2016154946A1 (fr) * 2015-03-31 2016-10-06 SZ DJI Technology Co., Ltd. Systèmes et procédés d'authentification mutuelle d'uav
EP3254404A4 (fr) 2015-03-31 2018-12-05 SZ DJI Technology Co., Ltd. Systèmes d'authentification et procédés de génération de règlementations de vol
WO2016154943A1 (fr) 2015-03-31 2016-10-06 SZ DJI Technology Co., Ltd. Systèmes et procédés pour des communications de dispositif de géorepérage
EP3485420A4 (fr) * 2016-07-14 2020-04-29 Kumar, Srijan Système de type client-serveur pour des jeux avec des jetons, vérifiables et à loyauté prouvable, sans collusion possible, et méthodes d'utilisation correspondantes

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6199052B1 (en) * 1998-03-06 2001-03-06 Deloitte & Touche Usa Llp Secure electronic transactions using a trusted intermediary with archive and verification request services
WO2001030016A2 (fr) * 1999-10-01 2001-04-26 Ecomxml Inc. Procede permettant d'empecher des parties de denoncer apres coup une transaction executee avec une tierce partie de confiance

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0727894B1 (fr) * 1994-08-30 2004-08-04 Kokusai Denshin Denwa Co., Ltd Systeme de certification

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6199052B1 (en) * 1998-03-06 2001-03-06 Deloitte & Touche Usa Llp Secure electronic transactions using a trusted intermediary with archive and verification request services
WO2001030016A2 (fr) * 1999-10-01 2001-04-26 Ecomxml Inc. Procede permettant d'empecher des parties de denoncer apres coup une transaction executee avec une tierce partie de confiance

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100563153C (zh) * 2004-04-07 2009-11-25 华为技术有限公司 一种在端到端无线加密通讯系统中用户登记鉴权的方法
JP2008529368A (ja) * 2005-01-28 2008-07-31 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 通信システムにおけるユーザ認証及び認可
JP4643657B2 (ja) * 2005-01-28 2011-03-02 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 通信システムにおけるユーザ認証及び認可
WO2006079419A1 (fr) * 2005-01-28 2006-08-03 Telefonaktiebolaget Lm Ericsson (Publ) Authentification et autorisation d'utilisateurs dans un systeme de communications
KR100995423B1 (ko) 2005-01-28 2010-11-18 텔레폰악티에볼라겟엘엠에릭슨(펍) 통신 시스템에서 사용자 인증 및 권한 부여
US7877787B2 (en) 2005-02-14 2011-01-25 Nokia Corporation Method and apparatus for optimal transfer of data in a wireless communications system
JP2008532114A (ja) * 2005-02-14 2008-08-14 ノキア コーポレイション 無線通信システム内の最適なデータ転送のための方法及び装置
JP4637185B2 (ja) * 2005-02-14 2011-02-23 ノキア コーポレイション 無線通信システム内の最適なデータ転送のための方法及び装置
EP1992185A4 (fr) * 2006-03-07 2013-01-02 Korea Electronics Telecomm Procédé de réauthentification rapide dans un umts
EP1992185A2 (fr) * 2006-03-07 2008-11-19 Electronics and Telecommunications Research Institute Procédé de réauthentification rapide dans un umts
AU2007229977B2 (en) * 2006-03-28 2011-02-24 Telefonaktiebolaget Lm Ericsson (Publ) A method and apparatus for handling keys used for encryption and integrity
WO2007111557A1 (fr) * 2006-03-28 2007-10-04 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil pour la manipulation de clés utilisées pour le cryptage et l'intégrité
US9641494B2 (en) 2006-03-28 2017-05-02 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for handling keys used for encryption and integrity
JP2009531954A (ja) * 2006-03-28 2009-09-03 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 暗号化および整合性のために使用されるキーを処理する方法および装置
US9106409B2 (en) 2006-03-28 2015-08-11 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for handling keys used for encryption and integrity
EP2182672A4 (fr) * 2007-11-16 2011-08-31 Huawei Tech Co Ltd Procédé, système et équipement de distribution de clé
US8484469B2 (en) 2007-11-16 2013-07-09 Huawei Technologies Co., Ltd. Method, system and equipment for key distribution
EP2182672A1 (fr) * 2007-11-16 2010-05-05 Huawei Technologies Co., Ltd. Procédé, système et équipement de distribution de clé
US8560847B2 (en) 2007-12-03 2013-10-15 China Iwncomm Co., Ltd. Light access authentication method and system
WO2010128348A1 (fr) * 2009-05-08 2010-11-11 Telefonaktiebolaget L M Ericsson (Publ) Système et procédé d'utilisation d'une architecture gaa/gba en tant qu'outil de signature numérique
WO2014155319A1 (fr) * 2013-03-28 2014-10-02 Idcapt Procede d'authentification
FR3003979A1 (fr) * 2013-03-28 2014-10-03 Idcapt Procede d'authentification
US11223954B2 (en) 2017-04-11 2022-01-11 Huawei Technologies Co., Ltd. Network authentication method, device, and system
US20210099866A1 (en) * 2018-07-13 2021-04-01 Micron Technology, Inc. Secure vehicular services communication
US11863976B2 (en) * 2018-07-13 2024-01-02 Micron Technology, Inc. Secure vehicular services communication

Also Published As

Publication number Publication date
GB0424869D0 (en) 2004-12-15
AU2003238996A1 (en) 2003-12-31
GB2403880A (en) 2005-01-12
JP2005529569A (ja) 2005-09-29
CN1659820A (zh) 2005-08-24
JP4213664B2 (ja) 2009-01-21
DE10392788T5 (de) 2005-05-25
GB2403880B (en) 2005-11-09

Similar Documents

Publication Publication Date Title
US7194765B2 (en) Challenge-response user authentication
Horn et al. Authentication protocols for mobile network environment value-added services
US7472273B2 (en) Authentication in data communication
KR101158956B1 (ko) 통신 시스템에 증명서를 배분하는 방법
US8887246B2 (en) Privacy preserving authorisation in pervasive environments
KR101485230B1 (ko) 안전한 멀티 ｕｉｍ 인증 및 키 교환
CN101969638B (zh) 一种移动通信中对imsi进行保护的方法
WO2003107584A1 (fr) Non-repudiation de contrat de maintenance
US20040151322A1 (en) Method and arrangement for efficient information network key exchange
US9608971B2 (en) Method and apparatus for using a bootstrapping protocol to secure communication between a terminal and cooperating servers
WO2008117006A1 (fr) Procédé d&#39;authentification
EP2082539A1 (fr) Système faisant appel à un jeton d&#39;autorisation pour séparer des services d&#39;authentification et d&#39;autorisation
US20070192602A1 (en) Clone resistant mutual authentication in a radio communication network
CN1859097B (zh) 一种基于通用鉴权框架的认证方法及系统
CN113824570B (zh) 一种基于区块链的安全终端的认证方法和系统
Madhusudhan A secure and lightweight authentication scheme for roaming service in global mobile networks
CN100450305C (zh) 一种基于通用鉴权框架的安全业务通信方法
Go et al. Wireless authentication protocol preserving user anonymity
CN101547091A (zh) 一种信息发送的方法及装置
CN114666114A (zh) 一种基于生物特征的移动云数据安全认证方法
CN114095930B (zh) 结合接入认证的卫星网络用户违规处理方法及相关设备
Kim et al. New key recovery in WAKE protocol
WO2003071736A1 (fr) Procede et appareil permettant la reduction de l&#39;utilisation du plan de signalisation dans des procedures de fourniture de certificats
Wang et al. Delegation-Based Roaming Payment Protocol with Location and Purchasing Privacy Protection
Leuca Security issues in wireless communications

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

ENP Entry into the national phase

Ref document number: 0424869

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20030604

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 3660/DELNP/2004

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2004514264

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 20038137070

Country of ref document: CN

122 Ep: pct application non-entry in european phase
点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载