WO2007046706A1

WO2007046706A1 - Method and arrangement for automatic provisioning, licensing and configuration of client software

Info

Publication number: WO2007046706A1
Application number: PCT/NO2006/000325
Authority: WO
Inventors: Frode Beckmann Nilsen; Thomas Horsten; Trond Lunde; Otto Andreas Rustand; Haakon Bryhni
Original assignee: Birdstep Technology Asa
Priority date: 2005-09-22
Filing date: 2006-09-22
Publication date: 2007-04-26
Also published as: NO20054840L; NO326342B1; NO20054840D0

Abstract

The present invention enables secure and automatic configuration of a user-specific service, such as a service built around the a mobile terminal (100) with a client software such as Mobile IP, to work specifically with a corresponding back-end infrastructure (101, 102) by means of a provisioning server (103). The overall design objective is ease-of-use. The secondary design objective is to minimize the required adaptions on the client leaving as much control as possible to the server side. The service is designed to work with any client-platform. The overall assumption is that the client is by default bound to the user spesific service at software installation. There is a configurable number of days free-of-charge trial period for this service after initial activation. After the trial period expires, the user is directed to a payment service (104) where he/she is given the option to continue the service by accepting a fee, paid by credit card or by other means. By paying the user also acquire a full software license. Equipped with a full software license the user may use the client together with any user specific ervice provider. The system is managed using a standard web interface available to a management PC (105). Note that the service concept can be considered in a generalized context. The client can receive licenses from one entity and service from another entity. For an overview of the system, see the attached Figure 1.

Description

Method and arrangement for automatic provisioning, licensing and configuration of client software

Introduction

The present invention (see figure 1 for an overview) enables a user-spesific service, such as a service built around a mobile terminal (100) with a client software (such as Mobile IP), to work specifically with a corresponding back-end infrastructure (101, 102) by means of a provisioning server (103). The overall design objective is ease-of- use. The secondary design objective is to minimize the required adaptions on the client leaving as much control as possible to the server side. The service is designed to work with any client operating system platform.

The overall assumption is that the client is by default bound to the user spesific service at software installation. There is a configurable number of days free-of-charge trial period for this service after initial activation. After the trial period expires, the user is directed to a payment service (104) where he/she is given the option to continue the service by accepting a fee, paid by credit card or by other means. By paying the user also acquire a full software license. Equipped with a full software license the user may use the client together with any user specific ervice provider.

The system is managed using a standard web interface available to a management PC (105).

Note that the service concept can be considered in a generalized context. The client can receive licenses from one entity and service provisioning from another entity.

License policy

The design of the user-specific service depends on the licensing policy for the service. The policy of choice is based on the following three fundamentals:

1. A client software license is always associated with a service subscription. In the trial period there is a 1:1 correspondence, ie. the client can only be used with the User- specific service. If the subscription is carried forward by payment, and a full software license is granted, there is a 1 :n correspondence. Ie. the client can be used with any service provider. However, the client is still linked to the user-specific service concerning license management. If the user re-installs the client software, on the same device or a different device, the locally stored license information will default to an unknown license. The user must in this case re-activate once with the user-specific service to unlock the client to restore the original configuration and regain his full license rights.

2. A service subscription, and hence a software license, is registered with a unique device but may be moved between devices. The user may use the license from only one device at a time, however. The user-specific configuration system will automatically detect a license transfer and then change the registered device association accordingly. The software installation on the original device will still work according to the full license rights, however. Hence, the one-at-a-time restriction must be embedded as a legal provision in the license text.

3. A service subscription, and hence a software license, can be activated for trial only once from a given device. The user may re-activate from the same device under the same account name in order to restore lost service configuration data. Any attempts to repeatedly sign up from the same device under a different account name will be blocked by the user-specific service system. Detection of abuse can be done on the server side by monitoring the number of license moves, which can then be subsequently blocked by the server. System Overview

Using Mobile IP as the user-specific service example, called SmartRoaming for the remainder of the document, the system consists of five different components:

100 Mobile IP Client

101 Mobile IP Home Agent

102 AAA server (e.g. RADIUS based)

103 Provisioning server

104 Credit card payment server (hosted by payment provider)

Figure 1 describes the logics of the component interaction. The client interacts with the mobile IP agent according to the usual IETF standards over the standard interfaces marked with 10 in the figure. The key to system operation is how the client communicates with the provisioning server over the proprietary interfaces 20 described in the present disclosure. Note that the communication paths marked with 15 corresponds to service traffic flow, and paths marked with 25 corresponds to service control flow.

Communication between the client and the provisioning server is implemented as a proprietary interface over http(s). The native web-browser in the client terminal (100) is used to request, display and download information. AU logic is implemented on the server side (103). Every transaction starts with the client sending a request to the server. The server determines the current status for the client and generates a series of re-directs corresponding to the different steps in each transaction that is scheduled for the client. Some transactions will trigger a http(s) download as the final step. The content is marked (using the Content-Type header) as a specific MIME application type (application/xxxx). The client software will register itself at installation to handle such content e.g. by means of a browser plugin to avoid the file download dialog for the configuration information, normally provided by the browser.

The interaction between the client (100) and the provisioning server (103) depends on one or more of the following key conditions:

1 The client (100) initiates a request to the server (103) in situations such as i) If the client does not have a valid configuration, (ii) If the user selects "My Account" from the client user interface, or (iii) whenever the client experiences Mobile IP error 131 (authentication error) from the Home Agent (101). The latter can be provoked by the server to get the attention of the client. See section "Common aspects of the service" for a full list of situations that can trigger sending of the request.

2 Note that the request always start with the client sending a solicit request message to the server and receive key information such as the address of the appropriate provisioning server, a security token (challenge) and a pre- formulated request string to be used by the subsequent request, hi this way, multiple provisioning servers can be hosted and server migration and load balancing can be obtained.

3 A software lock in the client that can represent three states, (i) the initial state corresponding to a fresh installation and no previous activations attempts (ii) the locked state corresponding to the in-trial phase and (iii) the unlocked state corresponding to full license rights.

4 A capability in the client to recognize SmartRoaming profiles among the set of all profiles. Morover, the ability to work specifically with the SmartRoaming service for such profiles. The profile is classified as a SmartRoaming profile if and only if the profile GUID matches the one stored in the provider account and its hash is stored in the Provider Account Information.

5 The configuration sent from the server to the client is signed by the configuration server, to avoid wrong configuration information and Denial of Service attacks by bogus configuration information.

The most important transactions over the provisioning interface are:

1 initial service activation

2 license activation after expiring the trial-period

3 service renewal at the end of every subscription period.

Note that a service activation is a pre-requisite for a license activation. Moreover, the initial service activation must originate from the target device that will receive the configuration data and run the mobile IP client. Other service related tasks, like license activation, service renewal, etc. can originate either from the target device or from a different device (typically a PC) via the separate account management WEB interface. The interaction between the client and the provisioning server is further governed by a security model based on the following:

1 Service configuration data stored on the client are signed by the provisioning server, hence making such data tamper-proof.

2 Critical data (like user credentials and keys) are stored on the client in an encrypted format.

3 The client-server communication is signed and encrypted, hence preventing spoofing attempts from malicious clients.

4 Key management is secure, hence preventing key material to be compromised.

Common aspects of the service

The following sub-sections describe the system aspects that are common to both the client and the server. More detailed information on the client and the server-side components, respectively, are given in later sections.

Command-loop

The client must have as little embedded intelligence as possible. The overall control must be at the server side. The rationale is to simplify the client implementation and to have a design that is flexible for change also after client software deployment.

The command-loop has two phases; the first phase (called solicit phase) is initiated directly by the client (not via the browser) and the returning document, having a very simple structure, as shown in the example in Table 1. This document is parsed by the client and the information is used in the subsequent phase that is executed via the browser. The solicit phase returns info like bypass addresses, URLs to used, and challenge values. Note that the challenge value is valid only for a short time, e.g. a few minutes to provide replay protection. iip_bypass : 80 .239. 52 . 82 i 80 .239 . 52 . 103 'service_con_url : ihttps : //server . com/ ?device id=$DEV ID$&device mσdel=$DEVICE MODEL$&cli ent ver=$CLI VER$&os platform=$OS PLAT$&lang=$LANG$&reason=$REASON$

Table 1: Example solicit response

The solicit phase is done as the first transaction in the requests from the client to the provisioning server, and enable the service provider to control the IP addresses used by the service, and formulate the master URL used for subsequent requests. In this way, new servers can be introduced, and service migration can be performed with no changes to the client.

Note that the client only opens one URL (termed the solicit URL), which can be opened in an named or unnamed mode. The server responds with a single URL (which contains tokens that the client will parse and replace, e.g. device id (320), username, challenge, signature, client version, reason for request), and then launches the browser with the resulting URL. From that point on the client does not interact with the server, everything is done in the browser (until the time that the browser, if required, receives a new configuration, or the Mobile IP connection is restarted).

The http(s) interface between the client and the provisioning server is based on always requesting the same base URL. Two different sets of parameters can be appended depending on the type of request, such as anonymous or named, as explained below). The server handles requests in a designated entry-point in the WEB server. The server will determine the current client state and schedule the appropriate transaction. The server will respond with (a series of) re-directs, each with a more specific URLs, depending on the derived transaction type. Every transaction may end with a http download if the client configuration needs to be updated. The client will issue a request again only at certain conditions as described below.

A requests from a client can be either (i) anonymous or (ii) named. The former is used when the client has either no previous configuration data, typically at a fresh installation, or that the configuration data has been modified, e.g. in case of a failed signature check. In this case no account ids can be appended to the request (hence anonymous). The latter corresponds to the case when the client has a set of valid configuration data for a given SmartRoaming service account. In this case the ids associated with the account will be appended to the request (hence named). A named request will be triggered (i) If the client does not have a valid configuration, (ii) If the user selects "My Account" from the client user interface, (iii) the Client version is different than the configuration version, or (iv) whenever the client experiences Mobile IP error 131 (authentication error) which signals the client during operation to get its attention.

The provisioning server will do this by temporarily invalidating the authentication credentials stored in the AAA server (102) for the user account in question. The server can schedule a set of actions for the client before the client is notified. Once notified, the client sends a request to the server, and executes the required transaction . The more detailed chain of events will be as follows:

1. The server needs (wants) the attention of the client, eg. to notify about an expired trial period.

2. The server temporarily changes the authentication credentials in the AAA server (102) to a bogus value that does not match with the corresponding profile setting at the client.

3. At the next re-registration from the client an error code 131, according to the Mobile IP protocol defined in IETF RFC3344, is provoked

4. The client takes an error 131 for a SmartRoaming profile to be a signal that the server wants its attention, hence the client sends a named request

5. The server determines which transaction to start (eg. an expired trial-period) and send a chain of re-directs accordingly

6. The transaction is completed.

7. The client continues with normal Mobile IP operation.

8. The client may itself initiate contact with the server upon certain criterias as previously described.

To ensure timely response via the command loop in case of error 131 it is a key assumption that the agent does not cache credentials but always retrieve these directly from the AAA server (102). Moreover, the AAA server infrastructure must scale along with the agent infrastructure (101) to ensure rapid response in the communication between these two components. Redirection to a service provider site

When the user starts a network-dependent application and selects the Mobile IP connection, the Mobile IP client may need to redirect the user to a Mobile IP service provider site. If so, the client displays a message, asking the user whether or not he wants to accept the redirection. The message to be displayed should vary according to the reason for redirection. The table below represents all the possible reasons for redirection.

Table 2: Possible reasons for redirection

The action taken by the client and the message displayed in each of the above cases is as follows. Note that these conditions should be handled by the client in the listed order.

1. Client automatically creates a default provider entry. Therefore redirection is not required and no message is displayed.

2. Client either automatically creates a default provider entry (when hard-coded) or displays the following redirection message:

_jThe <provider> contact data is invalid jDo you want to restore it?

3. Client displays the following message:

JMobile IP is not activated on your device

^!Do you want to activate it at <default-provider>?

4. Client displays the following message: Your Mobile IP license is invalid

Do you want to restore it from <provider>?

5. Client displays the following message:

You don ' t have a profile

IDo you want to get one from <provider>?

6. Client displays the following message:

Your active profile is invalid

Do you want to restore it from <provider>?

7. Client displays the following message:

Your <provider> account is suspended Do you want resume operation?

8. Client displays the following message:

Your Mobile IP license is invalid

Do you want to restore it from <provider>?

9. Client displays the following message:

Your account data does not match your Mobile IP client version Do you want to upgrade your account to the correct version?

10, Client displays the following message:

You have a valid <provider> profile but the terminal is unable to reach the home agent . You are beging redirected to <provider> for troubleshooting assistance.

In all the above message texts <provider> is a placeholder for the provider name (SmartRoaming.com, for example).

An important point about how to provoke 131; the sever must use a (bogus) key to provoke 131. However, this bogous key must also be known by the client. We simply uses the encrypted password as the bogus key. The rational here is that the client must be able to verify the MIP authenticator of the Mobile IP RRP message giving error code 131, hence to verify that it comes from the home agent as spected. This is to avoid that the client becomes vulnerable to DoS attacks.

Service activation

Service activation refers to the process of creating a new subscription and starting a trial period. The sign-up is immediately followed by downloading SmartRoaming configuration data. The term re-activation is used when the configuration data from a previous activation has been lost or modified on the device. A request may then be sent to the server resulting in a re-download. The process of unlocking the client by continuing the service subscription beyond the trial phase is referred to as license activation and is discussed in a later section.

When activation is started the client will launch the default browser in the terminal (100) and be directed to a sign-up page requesting (among other things) a username/password combination.

If the provisioning server (103) determines that no account with the given device id already exists, a new account must be created and a new set of configuration data must be downloaded. This corresponds to initial activation and starts the trial period. Account creation must however be conditioned on a check that the lock state of the requesting client does not indicate that the client is already in the trial-phase under a different name.

The server side (103) must record the creation of each account and keep track of elapsed time subsequently. If the name exists and the password matches, a re-activation of an existing account is in progress. The same configuration data downloaded at the original activation must then be downloaded again and overwrite the local copy. This represents a continuation of the trial period. The initial activation time must be kept.

If the user exists and the password does not match, it must be considered to be a non- unique user name. The user must then be asked to select a different name. The server should offer some alternatives that are unique but still close to the user's original proposal. In the case of a SmartRoaming re-activation request the server must check if the user account in question is a trial account or a fully licensed service account, hi the latter case the server must verify the lock state reported by the client. In case of a mismatch, the client must initiate a request to the server to change its lock state.

Signaling for service activation via an anonymous request is described in the figure 2. Note that 200 denote the service provider responsibility, while 210 denote the credit card company. The initial request represents the solicitation phase, and enable the service provider to formulate the request URL subsequently used by the client, as well as server addresses and a token used to avoid Denial of Service attacs. When the solicit response is received, the client will generate a request to the server, which will provide a redirect to the trial activation page. After completing this page an account is created. Another redirect is then returned for the client to finally retrieve the resulting configuration data.

The following sequence is illustrated in figure 2:

201 Solicit request from the client software

202 Solicit response to the client software

203 Anonymous request from the client default browser

204 Redirect

205 Trial activation page

206 Update AAA account

207 Redirect

208 Configuration request

209 Configuration download (browser will automatically engage client software)

License activation

The command loop will catch the situation when an active SmartRoaming subscription has expired beyond its trial phase. When this happens the clientwill be re-directed to a licensing page. The already existing username values associated with the existing SmartRoaming profile will be sent directly in a named request. By accepting the terms and conditions and provide his payment details, the user can continue the service subscription and acquire a full software license. The username is the link between the payment transaction and the service subscription. After payment the server must be updated with the new account status and the new value of the license lock will be downloaded. Note that no new profile download need to happen at this point. The user may continue to use the already installed software and SmartRoaming profile.

If the user rejects to pay he has no rights to continue to use the software and his service subscription will be invalidated. The service account will not be removed, however. The user may at any time trigger the license activation process to continue his service- subscription and acquire a full software license.

Signaling for license activation is described in figure 3. Assuming that this happens during Mobile IP operation, the provisioning server (103) will invalidate the account in the AAA a server (102) and at the next Mobile IP registration request the client will experience an error 131. In response to this the client will send a named request. Assuming that the server determines that the trial period has expired, the client (100) will be re-direct to a license activation page. After completing the credit card transaction with the credit card broker (104) and updating the account in the AAA server (102), a new re-direct is generated before the client downloads updated configuration data.

The following sequence is illustrated in figure 3:

220 MIP reg req

221 AAA req

222 AAA resp

223 MIP reg response (131)

224 Solicit request from the client software

225 Solicit response to the client software

226 Named request from the default browser in the client

227 Redirect

228 License activation page

229 Credit card transaction

230 Transaction ok

231 Update AAA account

232 Redirect

232 Configuration download request

233 Configuration download (browser will automatically engage client software) Service renewal

The command loop mechanism will catch the situation also when an active SmartRoaming subscription has expired. When this happens the client will experience an Mobile IP error 131, client request will be initiated and the terminal web browser will be re-directed to a payment page to continue his/her subscription. Note that this page will be different from the licensing activation page since the user has already acquired a license. The user will continue to use the same installed software and SmartRoaming configuration, hence no new data will be downloaded at this stage. The sequence diagram is very similar to the license activation transaction.

Data-flow and security model

The communication between the client (100) and the server (103) is secured by https. The provisioning server must install a WEB server certificate issued by a well-known certificate authority. The client must only communicate with the provisioning server if it holds a valid certificate for the name smartroaming.com.

A device id (320) that uniquely identifies the client installation must always be added to the request. This applies to both anonymous and named requests.The device id can be taken from any source in the platform. For a Symbian device it might be the IMEI value. For a PC platform it may be the processor serial number. The formatting of the device id parameter must be completely open, ie. it must be considered as variable- length text string. The Service Provider section is signed. The Service Activation URL is embedded in this section and hence signed. So it could be a non-HTTPS URL. If it is a https URL, however, it will get checked that it has a certificate that matches the URL requested (issued by a CA whose root certificate is present on the device). Other information elements that must be always appended as parameters in any request are:

1. Client (Mobile IP) software version

2. Client OS platform and version

3. Client device_id

4. Client device_model

5. Preferred language

6. Reason for the request The effect of passing the device id (320) in an anonymous request is that the server can determine the exact licensing state. By comparing the received device id with the database of registered device id, and in addition considering the username provided during the sub-sequent sign-up step, the server can distinguish between the most usual scenarios numbered 1 to 4 in the table below (see table 2 for a comprehensive overview):

Table 3: Most usual scenarios

A named request always starts with the solicit phace, implementing a challenge- response part of named request. A challenge from the solicit phase must be included in the subsequence http request, this preventing replay attacks

A named request contains the user name in addition to the device id. In contrast to the anonymous case the request itself is also signed. The signature is a proof of the identity of the client and the server may proceed directly to the user account with no need for manual user authentication. The security rests on the fact that the server will at initial activation generate a client key and return this to the client. The server will use the same value to verify that the request from the client matches the account name, and hence comes from the same client that did the original activation, based on a server- generated challenge and the user name.

Multi-provider capabilities

Note that the service can provide support for multiple providers. The idea is that the owner of the service (e.g. Birdstep) can issue signed service sections for a set of providers, each provider having their own (unique) siging key (privat/public) pair. The provider service sections are in turn protected by a root key pair only known by Birdstep. A number of provider definitions can be pre-configured in the client at shipment. Using this mechanism, providers can sign configurations and control the download URL for the service. Note that the same configuration mechanisms can be used to serve multiple licensors, and allow customers such as device manufacturers to issue client licenses for use of the service and still let the terminal be configurable for multiple service providers.

Anonymous https requests

The data-flow and security aspects of sending an anonymous request are illustrated in figure 4. Note that the diagram only captures the first (request) step and the final (download) step in the transaction chain. Any intermediate re-direct steps are suppressed in the illustration. Further, the illustration focuses on how the device id parameter is handled. The handling of other parameters (client version and client OS platform) are not reflected by the diagram. The color coding is as follows:

1 white represents clear-text (original) values

2 grey represents signature values

3 hashed represents encrypted values

Boxes with a solid outline represent permanently stored values (306). Boxes with a dashed outline represent transiently generated values (305). The left pane corresponds to the client side and the right pane corresponds to the server side. The gray bold arrows indicate traffic over the https interface (308/309). The black curves and arrows show how various elements are input to and output from signing and encryption operations. The grey squares correspond to signature calculation (304). The small black circles correspond to encryption (302), and white circles correspond to decryption (301). The configuration structures to consider are:

1 Account information (acctinfo)

2 Mobile IP profile settings (profile)

Figure 4 has the following legend:

301 decrypt

302 encrypt

303 verify 304 sign

305 Transiently generated

306 Permanently stored

307 Cryptographic secret

308 https request (parametrized)

309 https download (mime'ized) 310 httpmsg

311 acctinfo

312 profile

Figure 4 uses the following data elements:

320 device id

321 userid

322 clikey

323 enckey

324 licinfo

325 signature

326 mipkey

327 cryptographic secret

328 signature key

After determining the license state (ref table above) the provisioning server will know if there is already an existing user account or if a new account needs to be created. In case (4) the server will simply return the existing configuration data to the client for it to restore the original configuration. In case (3) the device id will be replaced and the remaining information will be updated after recalculating the required signatures and encrypted values. In case (1) a new account will be created and populated with the proper information before it is made subject to calculation. The username will be taken from the form displayed in the sign-up page.

A client key (clikey) will be generated as a cryptographically random key. The key is unique and will be used by the client to sign its request and the server to verify the authenticity accordingly. The client key is further encrypted by a second key (enckey) before download to the client. The server stores the clear-text value of the clikey. The encryption key (enckey) is also generated as a cryptographically random key. This key is encrypted with a cryptographic secret that is also used to sign the data sent down to the client.

The license info (licinfo) may contain any textual information. At a minimum it must reflect the current licensing phase (trial or full license) for the client to know how it should operate. The LicenseState is an integer (0=Unknown, l=Trial, 2=Full) and the Licenselnfo which may be any text. Otherwise the license info may contain data such as the licensed user, the expiry date, etc. These details are for informational purposes only and will not be used by the client (except from displaying it). The Mobile IP profile is populated according to the home agent networking environment. A NAI is generated from the account username and appended the realm "smartroaming.com". A Mobile IP authentication key (mipkey) is generated from random data and encrypted with the encley before it is downloaded to the client. The server only stores the clear-text value of the key. The NAI and the mipkey is passed also on to the AAA server.

The rationale for encrypting the mipkey is to prevent users from distributing the details in a SmartRoaming profiles to the public and potential (mis)use in Mobile IP clients other that the SmartRoaming enabled client from Birdstep. The rationale for encrypting the clikey is to make it more difficult to spoof client request. Any attacker must then guess both the encryption algorithm and the signing algorithm. The unencrypted values of these keys must only be stored in volatile memory on the client.

Signatures are calculated over the complete acctinfo and profile structures. Any encrypted values must be included in the calculation rather than using the corresponding plain-text values. This is because the client only will know the encrypted values and the signature must match accordingly. The client will use the signatures to verify if the downloaded configuration is authentic before the parts are being used.

Named https requests

The data-flow and security aspects of sending a named request are illustrated by figure 5 and 6. Figure 5 corresponds to the case when no configuration data needs to be downloaded. Figure 6 considers the case when either the profile configuration or the account information needs to be updated. Before sending any named request the client must verify the configuration structures against the signatures to ensure that they are all authentic. The cryptographic secret 327 must be used to verify the structures. The signature key structure 328 can be used to verify the other configuration structures. The client must then verify that it holds a valid license by comparing the device id (320) of the acctinfo structure with the true id reported by the device itself. The signature key is used in this calculation and the clikey must be decrypted first by using the enckey. If the license verification is successful it can proceed with sending the named request.

The named request will include the username along with the device id. The parameter list of the request will in turn be signed by using the clikey (again after decrypting the key) and the signature added to the parameters in addition to a challenge value. At the server side the deviceid/userid combination will be used to look up the account. The corresponding clikey will be used to verify the signature of the request. If they all match, the account has been verified and the server may proceed directly with no further user authentication. If the verification fails, the request is spoofed and it must be dropped.

For the download case (figure 6) the encryption and signature calculation on the server side is exactly the same as for an anonymous request.

Mobile IP registration

The data-flow and security aspects of sending a Mobile IP registration request is illustrated by the below figure. Communication of udp/434 with the Mobile IP agent represent a different signaling plane than the http(s) communication with the provisioning server. The mipkey must be decrypted in the client in order to calculate the authenticator of the Mobile IP registration message. This does in turn require that the enckey is decrypted. At the server side (home agent in this case), the clear-text key is retrieved from the radius served and the authenticator is verified.

Claims

P a t e n t c l a i m s

1. A client/server arrangement for secure and automatic configuration of a -wireless terminal for a user-specific service subscription through the generation and use of encryption keys and user-specific information, wherein the client is arranged, in the terminal (100) and the server is arranged in a host computer (103) connected to a service provider, characterized in that

the client (100) is arranged to transmit from the terminal to the server (103) a terminal- specific identity (320) and a user-identity (321) entered by the user;

the server (103) is arranged to generate license key (324 licinfo), client encryption key (322 clikey),, user-specific client key (326 mipkey) and general encryption key (323 enckey), and general encryption key (323 etickey) is used to encrypt data sent from the server to the terminal;

me server (103) is arranged so that the general encryption key (323 enckey) is encrypted with a cryptographic secret (327);

the server (103) is arranged to store user-identity (321), terminal-specific identity (320) and iiser-specific client key (326) in a database;

the server (103) is arranged to return to the client (100) license key (324 licinfo), client- encryption key (322 clikey) and user-specific client key (326 mipkey) encrypted with the general encryption key (323 enckey), together with the general encryption key (323 enckey) encrypted with a cryptographic secret (327);

and the client (100) is arranged to decrypt the general encryption key (323 enckey) with cryptographic secret (327) and to decrypt client encryption key (322 clikey), licence key (324 licinfo) and other information sent from the server with the gefteral encryption key (323 enckey);

and the client (100) is further arranged to use client encryption key (322 clikey) for signing later requests to the server.

2. An arrangement as disclosed in claim 1, further characterized by a client (100) that is already registered as described in claim 1 and is using the user-specific service, characterized in that on receipt of an error code when using the service, the client is further arranged to transmit from the terminal (100) to the server (103) a request for service activation, a terminal-specific identity (320) and the selected user-identity (321) being given in the request, and that this request is signed by the client using client encryption key (322 clikey);

and the server (103) is arranged to check that the request from the client (100) is signed with client encryption key (322 clikey), and if the request is correct license activation is implemented, while if the request is incorrectly signed the request is treated as an anonymous request as described in claim 1 ;

and the server (103) is arranged to perfoim license activation by asking the user to accept service conditions and provide payment information;

the server (103) is further arranged to send payment information to credit card company (104), and on acceptance, updated license information is transmitted to the client (100) and AAA database is updated, while on rejection the request is refused,

3. An arrangement as disclosed in claim 2, characterized in that the service is Mobil IP and the error code is error message 131 from a Mobil IP home agent (101).

4. An arrangement as disclosed in claim 1, further characterized in that the client (100) is also arranged to transmit client model/version number, operative system type and operative system version, preferred language and reason for the request (103).

5. An arrangement as disclosed in claim 1, further characterized in that the server (103) requests that a valid e-mail address or valid mobile number also be given which can later be used to contact the customer.

6. An arrangement as disclosed in claim 1, further characterized in that the server (103) allows client (100) reinstallation by issuing of a copy of configuration information when the request contains a known terrninal-specific identity (320) and the user gives a user name (321) that already exists.

7. An arrangement as disclosed in claim 1- further characterized in that the server allows license transfer by issuing fresh signed configuration information when the request contains a new temiinal-specific identity (320) and the user gives a user name (321) that already exists.

S. An arrangement as disclosed in claim.1, further characterized in that repeated license transfer is allowed only a certain number of times by putting a stop on the number of license transfers allowed per registered user name (321).

9. An arrangement as disclosed in claim 1, further characterized in that the server (103) blocks the issue of configuration information when the request contains a known terminal-specific identity (320) and the user gives a new user name (321).

10. An arrangement as disclosed in claim 1, further characterized in that the client (100) is able to detect that a device-id is registered which does not have a valid license, and offers the user automatic creation of configuration and license.

11. An arrangement as disclosed in claim I₅ further characterized in that the client (100) is able to detect a version of configuration data in the client that does not match the client software version, and offers the user automatic updating of configuration information to the right version,

12. An arrangement as disclosed in claim I₅ further characterized in that the client (100) is able to detect that it is not possible to reach the home agent (101) and redirects the user to a web page that offers configuration assistance.

13. An arrangement as disclosed in claim I₅ further characterized in that the server (103) is able to issue a "provider section" for a third party which can allow the third party to issue licenses without the third party having the right to change service provider and URL for configuration.

14. An arrangement as disclosed in claim 1, further characterized in that the server (103) is able to issue a "provider section" for a third party which can allow the third party to issue signed profiles without the third party having the right to issue licenses for client software,

15. An arrangement as disclosed in claim 1, further characterized in that the configuration from server (103) to client (100) is signed by the server to prevent incorrect configuration, and denial of service attacks on the client,