NO326342B1 - Method and arrangement for automatic service delivery, licensing and configuration of client software - Google Patents

Description

Known technique.

A publication published by Microsoft Corporation, in June 2004, with updated edition 2005, entitled "IEEE 802.11 Wireless LAN Security with Microsoft Windows XP" describes security in wireless networks with respect to various techniques. It states that although wireless ELAN networks provide freedom of movement, they may also require the user to take into account security issues that are not as prominent on a private cable system for single-wire ELAN technology such as internal Hoveo^the security probes are the authentication of wireless clients and the encryption and the data integrity of frames on wireless ELAN. In particular, a so-called "EAP-TLS authentication" is described on pages 1-13. Under point 9 you will find the heading "EAP success from the radio server", where a description is given of how the keying from the server to the access point takes place.

In the publication entitled "Deploying Wi-Fi Protected Access (WPA™) and WPA2™ in the Enterprise", published by the Wi-Fi Alliance, in March 2005, the implementation of the security solution WPA and WPA2 irm in existing wireless networks is described. In particular, pages 7-9 describe the keying with so-called symmetric numeric keys of the user's identification, storage of information such as user identity, which in this publication is referred to as "credentials" (equivalent to the English term "credentials").

Introduction

The present invention (see Figure 1 for an overview) enables a user-specific service, such as a service built around a mobile terminal (100) with a client software (such as Mobile IP), to work specifically with an associated server infrastructure (101,102) using a delivery server (103). The overall design goal is to minimize the necessary customizations on the client and give as much control as possible to the server side. The service is designed to work with any client operating system.

A basic prerequisite is that the client is by default bound to the user-specific service when installing the software. There is a configurable number of days of free trial for this service after initial activation. After the trial period has expired, the user is directed to a payment service (104) where she or he is given the option to continue the service by accepting a fee, paid by credit card or by other means. By paying, the user receives a full software license. Equipped with a full software license, the user can use the client with a user-specific ie sole supplier.

The system is managed via a standard web interface accessible to a personal management computer (105).

Note that the service concept can be considered in a general context. The client can receive licenses from one actor and service delivery from another actor.

License policy

The construction of the user-specific service depends on the licensing policy for the service. The policy chosen is based on the following three foundations: 1. A client software license is always associated with a service subscription. During the trial period, there is a 1:1 connection, i.e. the client can only be used with the user-specific service. If the subscription is renewed by payment, and a full software license is approved, it is a 1:n connection. This means that the client can be used with any service provider. However, the client is still connected to the user-specific service when it comes to license management. If the user reinstalls the client software, on the same terminal or another terminal, the locally stored license information will be an unknown license by default. In this case, the user must re-activate once with the user-specific service to unlock the client and restore the original configuration and regain their full license rights. 2. A service subscription, and thereby a software license, is registered with a unique terminal but can be moved between terminals. However, the user can use the license from only one terminal at a time. The user-specific configuration system will automatically detect a license transfer and then change the registered terminal association accordingly. However, the installation of software on the original terminal will still operate under full license rights. For this reason, a one-time restriction should be inserted as a legal clause in the license text. 3. A service subscription, and thereby a software license, can be activated for a trial period only once for a specific terminal. The user can re-activate from the same terminal with the same account name to recreate tap service configuration data. Any attempt to register multiple times from the same terminal with 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 transfers, which in turn can be blocked by the server.

The present invention provides a client/server arrangement for the secure and automatic configuration of a wireless terminal with a client for a license key-dependent, user-specific service subscription provided by a service provider through the production and use of the encryption key and user-specific information in a server, and where the server is arranged in a host computer connected to the test provider, characterized by the features that appear in the accompanying independent patent claim 1.

Further advantageous features of the present invention appear from the accompanying non-independent patent claims 2 to 15 inclusive.

Brief description of the invention.

Client/server arrangement for secure and automatic configuration of a wireless terminal for a user-specific service subscription through the production and use of encryption keys and user-specific information, where the client is arranged in the terminal (100) and the server is arranged in a host computer (103) connected to a service provider, which is characterized by the fact that the client (100) is arranged to transfer from the terminal to the server (103) a terminal-specific identity (320) and a user identity

(321) entered by the user, that 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 enckey) is used to encrypt data that is transmitted from the server to the terminal, that the server (103) is arranged so that the general encryption key (323 enckey) is encrypted with a cryptographic key (327), that the server (103) is arranged to store user identity (321), terminal-specific identity (320) and user-specific client key (326) in a database, that the server (103) is arranged to return to the client

(100) license key (324 licinfo), client encryption key (322 clikey), 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 key ( 327), that the client (100) is arranged to decrypt the general encryption key (323 enckey) with cryptographic key (327) and decrypt the client encryption key (322 clikey), license key (324 licinfo) and other information transmitted from the server with the general the encryption key (323 enkey), and that the client (100) is further arranged to use the client encryption key (322 clikey) for signing subsequent requests to the server.

The arrangement described in the section above can further include that a client (100) who is all registered as described in 1 and uses the user-specific service upon receiving an error code when using the service, is further arranged to transfer from the terminal

(100) to the server (103) a request for service activation where a terminal-specific identity (320) and the selected user identity (321) are stated in the request, and that this request is signed by the client with client encryption key (322 clikey), that the server (103) is arranged to check that the request from the client (100) is signed with a client encryption key (322 clikey), and if the request is correct, license activation is carried out and if the request is signed incorrectly, the request is treated as an anonymous inquiry which described in point 1, that the server (103) is arranged to carry out license activation by asking the user to accept terms of service and provide payment information, and that the server (103) is further arranged to transmit payment information to the credit card company (104), upon acceptance, updated license information is transferred to the client (100) and the AAA database is updated, and upon refusal, the request is rejected.

Furthermore, arrangements as described above can be arranged so that the service is Mobile IP and the error code is error message 131 from a Mobile IP home agent (101).

Furthermore, arrangements as described above can be arranged such that the client (100) is also arranged to transmit the client model/version number, operating system type and operating system version, preferred language and reason for the inquiry (103).

Furthermore, arrangements as described above can be arranged in such a way that the server (103) requires that a valid email address or valid mobile number is also provided which can later be used to contact the customer.

Furthermore, arrangements as described above can be arranged such that the server (103) allows the client (100) reinstallation by issuing a copy of configuration information when the request contains a known terminal-specific identity (320) and the user provides a username (321) that already exists .

Furthermore, arrangements as described above can be arranged such that the server allows license transfer by issuing a new signed configuration information when the request contains a new terminal-specific identity (320) and the user provides a username

(321) which already exists.

Furthermore, arrangements as described above can be arranged so that repeated license transfers are only allowed a certain number of times by setting a limit on the number of license transfers that are allowed per registered user name (321).

Furthermore, arrangements as described above can be arranged such that the server (103) blocks the issuance of configuration information when the request contains a known terminal-specific identity (320) and the user provides a new username (321).

Furthermore, arrangements as described above can be arranged so that the client (100) can detect that a device identity, called "device-id", which does not have a valid license has been registered, and offers the user automatic creation of configuration and license.

Furthermore, arrangements as described above can be arranged so that the client (100) can detect that the version of configuration data in the client does not correspond to the client software version, and offer the user automatic updating of configuration information to the correct version.

Furthermore, arrangements as described above can be arranged such that the client (100) can detect that it is not possible to reach the home agent (101) and redirects the user to a website that offers assistance with configuration.

Furthermore, arrangements as described above can be arranged such that the server (103) can issue a "provider section" for 3rd parties which can give 3rd parties the opportunity to issue licences, without 3rd parties gaining access to change the service provider and URL for configuration.

Furthermore, arrangements as described above can be arranged such that the server (103) can issue a "provider section" for 3rd parties which can give 3rd parties the opportunity to issue signed profiles, without 3rd parties gaining access to issue licenses for client software . Furthermore, arrangements as described above can be designed so that the configuration from server (103) to client (100) is signed by the server to avoid incorrect configuration and denial-of-service attacks against the client.

System overview

If we use Mobil-IP as the user-specific service example, called "SmartRoaming" in the rest 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 Administrative servant

104 Credit card payment server (operated by payment intermediary)

Figure 1 describes the logic of interaction between the components. The client interacts with the Mobil-IP agent according to the usual IETF standards over the standard interface marked with 10 in the figure. The key to the system's operation is how the client communicates with the delivery server over the proprietary interface 20 described in the present description. Note that the communication roads marked with 15 correspond to pure traffic flow, and the roads marked with 25 correspond to correspond to tj only control flow.

Communication between the client and the delivery server is implemented as a proprietary interface over http(s). The built-in browser in the client terminal (100) is used to request, display and download information. All logic is implemented on the server side

(103). Each transaction starts with the client sending a request to the server. The server determines the correct status for the client and generates a series of redirects corresponding to the various steps in each transaction planned for the client. Some transactions initiate an 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 upon installation to handle this type of content, e.g. using a browser plug-in to avoid the configuration information file download dialog normally provided by the browser. The interaction between the client (100) and the delivery 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) each time the client receives a Mobile -IP error 131 (authentication failure) from the home agent (101). The last situation can be provoked from the servant to get attention from the client. See the section 'Counted aspects of the service' for a full list of situations that can trigger the sending of a request. 2 Note that the request always starts with the client sending a "solicit" request message to the server and receiving key information such as the address of the correct delivery server , a security token (challenge) and a pre-formulated request string to be used in the subsequent request. In this way, multiple management servers can be used and server migration and load balancing can be achieved. 3 A software lock in the client that can represent three states (i) the initial state corresponding to a fresh installation and no previous activation attempts, (ii) locked state corresponding to trial phase and (iii) unlocked state corresponding to full license rights. 4 A capacity in the client to recognize SmartRoaming profiles among the set of all profiles. The ability to work specifically with the SmartRoaming service for such profiles.Profi len is classified as a SmartRoaming profile if and only if its profile GUID (technical acronym for: "globally unique identifier") matches the one stored in the provider's 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 incorrect configuration information and denial of service attacks in the case of false configuration information.

The most important transactions over the delivery interface are:

1 initial service activation

2 license activation after the end of the trial period.

3 renewal of the service after the end of each subscription period

Note that service activation is a prerequisite for license activation. Furthermore, the initial service activation must come from the mMterminal which will receive configuration data and run the Mobile IP client. Other service-related tasks, such as license activation, service renewal, etc. can come either from the target terminal or from another terminal (typically a PC) via the separate account management web interface. The interaction between the client and the delivery server is further governed by a security model based on the following: 1 Service configuration data stored on the client is signed by the delivery server, thereby making the data tamper-proof. 2 Critical data (such as user credentials and keys) is stored on the client in encrypted format. 3 The client-server communication is signed and encrypted, thereby preventing intrusion attempts by malicious clients. 4 Key management is secure, thereby preventing disclosure of key information.

Common conditions in the service

The following subsections describe system aspects common to both client and server. More detailed information for respective client- and server-side components is provided in later sections.

Command loop

The client must have as little built-in intelligence as possible. The overall control must be on the server side. The purpose is to simplify client implementation and to have a design that is flexible for change even after the client has been installed.

The command loop has two phases; the first phase (called the "solicit" phase) is initiated directly by the client (not via the browser), and the document returned has 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 performed by the browser. The "Solicit" phase returns information such as redirect address, URL to be used and challenge values (technical term: "challenge"). Note that the challenge value is only valid for a short time, e.g. a few minutes, in order to obtain protection against repeated transmission.

The solicit phase is done as the first transaction in the request from the client to the delivery server, and enables the service provider to control the IP addresses used by the service and formulate the master URL to use for subsequent requests. In this way, new servers can be introduced and service migration can be done without any changes to the client.

Note that the client only opens a URL (called "solicit URL"), which can be opened in anonymous or named mode. The server responds with a simple URL (containing the "token" that the client will parse and replace, eg device identifier (320), username, challenge value, signature, client version, reason for the request), and then launches a browser with it resulting URL. From this point, the client does not interact with the delivery server, everything is done in the browser (until the time when the browser, if needed, receives a new configuration, or the Mobile IP connection is restarted).

The HTTP(S) interface between client and delivery server is based on always requesting the same base URL. Two different parameter sets can be added, depending on the request type, such as anonymous or the name, as described below. The server handles requests in a specified access point in the web server. The server determines the current status of the client and schedules the correct transaction. The server responds with (a series of) redirects, each with a more specific URL, depending on the type of transaction issued. Each transaction can result in an HTTP download if the client's configuration needs updating. The client will send a new request again only in certain circumstances as described below.

A request from the client can be either (i) anonymous or (ii) named. The first is used when the client has no previous configuration data, typically a fresh installation, or that configuration data has been modified, e.g. in the event of a signature check that fails. In this case, no account identifier can be added to the request (therefore anonymous). The second corresponds to the case when the client has a set of valid configuration data for a given SmartRoaming service account. In this case, the identifier associated with the account will be added to the request (hence the name). A named request is triggered (i) if the client does not have a valid configuration, (ii) if the user selects "My account" from the client's user interface, (iii) the client version is different from the configuration version, or (iv) when the client receives Mobile- IP Error 131 (authentication failure) signaled to the client while in use to get attention.

The delivery server does this temporarily by invalidating authentication data stored in the AAA server (102) for the relevant user account. The servant can plan a set of actions for the client before the client is notified. Once notified, the client sends a request to the server and performs the required transaction. The detailed sequence of events is as follows: 1. The servant needs (wants) attention from the client, e.g. to inform that a trial period has expired. 2. The server temporarily changes authentication data in the AAA server (102) to an invalid value that does not match the corresponding profile setting in the client. 3. At the next re-registration from the client, an error code 131 is provoked, according to

The Mobile IP standard defined in IETF RFC3344.

4. The client takes an error 131 for a SmartRoaming profile as a signal and that the server wants its attention, and sends a name request. 5. The server decides which transaction to start (eg an expired trial) and performs a chain of redirects accordingly.

6. The transaction is completed.

7. The client continues normal Mobil-ff operation.

8. The client can himself take the initiative to contact the server according to certain criteria as described earlier.

In order to ensure a correct response via the command loop in case of error 131, it is a key condition that the agent does not store credentials temporarily (also, technical term: "caching"), but always retrieves these directly from the AAA server (102). Furthermore, the AAA server mfrastructure must scale together with the agent mfrastructure (101) to ensure fast 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's website. In this case, the client will display a message asking the user to accept or not accept the redirection. The message displayed should be varied according to the reason for the redirect. The table below shows possible reasons for redirection.

Action taken by the client and message displayed in each of the cases above are as follows. Note that these conditions should be handled in the client in the same order as in the list. 1. The client establishes a standard supplier posting. Therefore, redirection is not needed and no message is displayed. 2. The client either automatically establishes a standard supplier posting (hard-coded) or displays the following redirect message: <Service Provider> contact data is not valid Do you want to save it?

3. The client displays the following message:

Mobile IP is not activated for your terminal. Do you want to activate it with <Default Service Provider>?

4. The client displays the following message:

Your Mobile IP license is not valid.

Do you want to recreate it from <Supplier>?

5. The client displays the following message:

You do not have a profile

Would you like to collect one from <Supplier>?

6. The client displays the following message:

Your active profile is not valid

Do you want to reproduce it from <Supplier>

7. The client displays the following message:

Your <Supplier> account has been suspended

Do you want to resume operation?

8. The client displays the following message:

Your Mobile IP license is not valid.

Do you want to recreate it from <Supplier>?

9. The client displays the following message:

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

10. The client displays the following message:

You have a valid <Provider> profile, but the terminal is unable to reach the home agent. You are redirected to <Supplier> for assistance in finding the error.

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

An important point regarding how 131 can be provoked; the server must use an (invalid) key to provoke 131. However, this invalid code must also be known by the client. We use the encrypted password as the invalid key. The reason for this is that the client must be able to verify the MIP authenticator of the Mobile IP RRP message that returns error code 131, hence verify that it is coming from the home agent as expected. This is to avoid the client becoming vulnerable to DoS attacks.

Service Activation

Service activation refers to the process of establishing a new subscription and starting a trial period. Registration is immediately followed by downloading SmartRoaming configuration data. The term re-activation is used when configuration data from a previous activation has been lost or changed in the terminal. A request can be sent to the server and result in a repeated download. The process of unlocking the client by continuing the service subscription after the trial period is called license activation and is discussed in a later section.

When activation has started, the client will start the standard browser in the terminal (100) and will be directed to a registration page that asks for (among other things) a username/password combination.

If the delivery server (103) determines that there is no account with the specified terminal id, 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. However, the establishment of accounts must be dependent on a check that the lock status of the requesting client does not indicate that the client is already in a trial period under a different name.

The server side (103) must store information about the establishment of each account and keep control of the time accordingly. If the name is found and the password is correct, an existing account is reactivated. 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 time of initial activation must be saved.

If the user exists and the password does not match, it must be considered a non-unique username. The user must then be asked to choose another name. The server should then offer some options that are unique but still similar to the user's original suggestion.

In the case of a SmartRoaming reactivation request, the server must first check whether the user account is a trial account or a fully licensed service account. In the former case, the server must check the lock status reported by the client. If this is not true, the client must make a request to the server to change its lock status.

Signaling for service activation via an anonymous request is described in Figure 2. Note that 200 indicates the service provider's area of responsibility, while 210 indicates the credit card company. The initial request represents the "solicitation" phase, and enables the service provider to formulate a URL that is then used by the client, as well as the server address and a "token" that is used to avoid denial of service attacks (technical term: "Denial of Service") . When the "solicif" response is received, the client generates a request to the server, which will redirect to the activation page. Once this page is filled, an account is generated. Another redirect is then returned so that the client can finally retrieve the resulting configuration data.

The following sequence is illustrated in Figure 2:

201 Solicit request from client software

202 Solicit response to the client software

203 Anonymous request from the client's browser

204 Redirection

205 Service Activation Page

206 Updating AAA information

207 Redirection

208 Request for configuration

209 Configuration data download (browser engages client software automatically)

License Activation

The command loop will capture the situation where an active SmartRoarning subscription has expired after a trial period. When this happens, the client will be redirected to a license page. The already existing username values associated with the existing SmartRoaming profile will be sent directly in a name request. By accepting the terms of the service and presenting payment information, the user can continue the service subscription and obtain 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 license lock will be downloaded. Note that no new download of the profile is needed at this point. The user can continue to use the installed software and the SmartRoaming profile.

If the user refuses to pay, the person concerned does not have the right to continue using the software, and the service subscription is invalidated. However, the service account is not removed. The user may at any time initiate a license activation process to continue the service subscription and obtain a full software license.

Signaling for license activation is described in figure 3. If we assume that this occurs during Mobile IP operation, the supplier server (103) will invalidate the account in the AAA server (102) and the next Mobile IP registration request to the client will experience an error 131.1 response to this the client will send a name request. If we assume that the trial period has expired, the client (100) will be redirected to a license activation page. After completing the credit card transaction with the credit card company

(104) and updating the account in the AAA server (102), a new redirect is generated and the client can download updated configuration data.

The following sequence is illustrated in Figure 3.

220 MlP registration request

221 AAA request

222 AAA response

223 MIP registration response (131)

224 Solicit request from client software

225 Solicit response to client software

226 The name request from the default browser in the client

227 Redirection

228 License Activation Page

229 Kjedit card transaction

230 Transaction OK

231 Updating AAA information

232 Redirection

233 Configuration data download request

234 Configuration download (browser will automatically engage client software)

Renewal of service

The command loop mechanism will also capture the situation when an active SmartRoaming subscription has expired. When this happens the client will experience a Mobile IP error number 131, client request will be initiated and the terminal browser will be redirected to a payment page to continue his/her subscription. Note that this page will be different than the launch activation page since the user has already obtained a license. The user will continue to use the same installed software and SmartRoaming configuration, therefore 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 delivery server must install a web server certificate issued by a well-known certificate authority. The client must only communicate with the delivery server if it has a valid certificate for the name smartroaming.com.

A terminal ID (320) that uniquely identifies the client installation must always be appended to the request. This applies to both anonymous and named requests, the terminal ID can be obtained from an arbitrary source in the terminal. For a Symbian terminal it can be an IMEI value. For a PC, it could be the processor's serial number. The formatting of the terminal id is open, i.e. it must be treated as a variable-length text string. The Service Provider section is signed. The Service Activation URL is part of this section and therefore signed. This can be a non-https URL. If it is an https URL, however, it can be checked that the server has a certificate that matches the requested URL (issued by a CA that has a "root" certificate installed in the client). Other information items that must always be added as parameters to any request are:

1. Client (Mobile IP) software version

2. Client OS platform and version

3. Client terminal_id

4. Client terminal model

5. Preferred language

6. Reason for the inquiry

The effect of sending over the terminal id (320) in an anonymous request is that the server can determine the exact licensing state. By comparing the received service ID with the database of registered service IDs, and also taking into account the username that was provided in the subsequent registration step, the server can distinguish between the most common scenarios numbered 1-4 in the table below (see table 2 for a more complete overview)

A named request always starts with a "solicit" phase, which implements a "challenge-response" part of a named request. A "challenge value" from the "solicit" phase must be included in the subsequent http requests, to avoid replay attacks.

A named request contains the username in addition to the terminal ID. In contrast to the anonymous request, the request itself is also signed. The signing is proof of the identity of the client and the server can proceed directly to the user account without the need for manual user authentication. The security is based on the fact that upon initial activation the server will generate a client key and return this to a client. The server will also use the same value to verify that the request matches the account name, and thereby comes from the same client that did the original activation, based on a server-generated challenge (challenge) and the username.

Multi-vendor options.

Note that the service may offer support for multiple service providers. The idea is that an owner of a service (eg Birdstep) can issue signed service sections for a set of providers, each provider having their own (unique) signing key (private/public) pair. The vendor service sections are again protected by the "root" key pair known only by Birdstep. A wide range of provider definitions can be pre-configured in the client when deployed. Using this mechanism, vendors can sign configurations and control download URLs. Note that the same configuration mechanisms can be used to serve multiple licensees, allowing customers such as terminal manufacturers to issue client licenses for use of the service and still leave the terminal easily configurable for multiple service providers.

Anonymous https requests

Data flow and security aspects of sending anonymous requests are illustrated in Figure 4. Note that the diagram only captures the first (request) step and the final (download) step in the chain of transactions. Intermediate steps with redirection are suppressed in the illustration. Furthermore, the illustration focuses on how the service ID parameter is handled. The handling of other parameters (client version and client operating system platform) is not shown in the diagram. The color code is as follows:

1 white identifies plaintext (original) values

2 grays represent signature values

3 shaded represent encrypted values

Boxes with a black frame represent permanently stored values (306). Boxes with a dotted frame represent transient-generated values (305). The left part of the figure corresponds to the client side and the higher part of the figure corresponds to the server side. The gray bold arrows indicate traffic over the https interface (308/309). The black curves and arrows show how different elements are input and output from signing and encryption operations. The gray squares correspond to signature calculation (304). The small black circles correspond to encryption (302), and white circles indicate decryption (301). The configuration structures we take into account here are mainly:

1 Account information (acctinfo)

2 Mobile IP profile settings (profile)

Figure 4 has the following meaning of the symbols:

301 decryption

302 encryption

303 verify

304 sign

305 transient generated

306 Permanently stored

307 Cryptographic secret key

308 https request (parameterized)

309 https download (mime encoded)

310 httpmsg

311 acctinfo

312 profile

Figure 4 shows the following data elements:

320 terminal id

321 user pages

322 clikey

323 enkey

324 license info

325 signature

326 mipkey

327 cryptographic secret key

328 signing key

After determining the license status (ref. table above), the delivery agent will know if there is already a 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 its re-creation of the original configuration. In case (3), the terminal ID will be replaced and the remaining information will be updated after recalculation of the necessary signatures and encrypted values. In case (1), a new account will be established and filled with the correct information before it is calculated. The username is taken from the form displayed on the registration 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 requests and by the server to verify authenticity. The client key is further encrypted with another key (enckey) before downloading to the client. The server stores clear test value of clikey. The encryption key (enckey) is also generated as a cryptographic random key. This key is encrypted with a cryptographic secret key that is also used to sign data sent down to the client.

The license information (licinfo) can contain arbitrary textual information. At a minimum, it must reflect the current licensing phase (trial or full license) so that the client knows how it will operate. LicenseStatus is an integer (0=Unknown, l=Trial, 2=Full) and the "License Info" parameter can be any text. Otherwise, license info may contain data such as licensed user, expiration date, etc. These details are for information purposes and will not be used by the client (except to display them on the screen). The mobile IP profile is populated according to the home agent. An NAI is generated from the account username added to the site ("smartroaming.com"). A Mobil-Ip authentication key (mipkey) is generated from random data and encrypted with enkey before it is downloaded to the client. The server only stores the plaintext value of the key. NAI and mipkey are forwarded to the AAA server as well.

The purpose of encrypting the mipkey is to prevent users from distributing the details of a SmartRoaming profile to the public and potential misuse in Mobile IP clients other than the SmartRoaming clients such as Birdstep offers. The purpose of encrypting the klikey is to make it more difficult to "spoof" client inquiries. Any attacker must then guess both the encryption algorithm and the signing algorithm. The unencrypted values of these keys need only be stored in volatile memory in the client.

Signatures are calculated over entire "acctinfo" and profile structures. Encrypted values must be included in the calculation instead of using the corresponding plaintext values. This is because the client only wants to know the encrypted values, and the signature must match this. The client will use the signatures to verify that the downloaded configuration is authentic before using the parts.

The name https request

Data flow and security aspects of sending a named request are illustrated in Figures 5 and 6. Figure 5 corresponds to the example when no configuration data needs to be downloaded. Figure 6 describes the example when either profile configuration or account information needs to be updated.

Before sending a named request, the client must verify the configuration structures against the signatures to ensure they are authentic. The cryptographic secret key 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 has a valid license by comparing the terminal id (320) in the "acctinfo" structure with the real id reported by the terminal itself. The signature key is used in this calculation and clikey must be decrypted first when using enkey. If the license verification is OK, the client can continue to send the name request.

The named request will include the username along with the terminal id. The parameter list in the request will be signed using the clikey parameter (again after decrypting the key) and the signature added to the parameters in addition to a challenger value. On the server side, the terminal/user ID combination is used to look up the account information. The corresponding clikey will be used to verify the signature of the request. If they all match, the account is verified and the server can continue directly without further user authentication. If the verification fails, the request is not valid and must be dropped.

For the download case (Figure 6), the encryption and signature calculation is exactly the same as an anonymous request.

Mobile IP registration

Data flow and security aspects of sending Mobile IP registration request are shown in the figure below. UDP/434 communication with the Mobil lp agent represents a different signaling scheme than the HTTP(S) communication with the delivery server. Mipkey must be decrypted in the client to calculate the authenticator for the Mobile IP registration message. This in turn requires that the enkey is decrypted. On the service side (the home agent in this example), the cleartext key is obtained from the RADIUS server and the authenticator is verified.

Claims (15)

1. Client/server arrangement for secure and automatic configuration of a wireless terminal with a client (100) for a license key-dependent, user-specific service subscription provided by a service provider through the generation and use of encryption keys and user-specific information in a server (103), and where the server (103) is arranged in a host computer connected to the service provider, characterized in that the client (100) is arranged to transmit from the terminal a request for activation of the user-specific service subscription to the server (103) comprising a terminal-specific identity (320) and a user identity (321) entered by the user, and that the server (103) is arranged to a) activate the requested license key-dependent, user-specific service subscription by generating a license key (324 licinfo), a client encryption key (322 clikey), a user -specific client key (326 mipkey) and a general encryption key (323 enckey) for use to NOK ypter data transmitted between the server and the terminal, b) to encrypt the general encryption key (323 enkey) with a cryptographic secret key (327), c) to store user identity (321), territory-specific identity (320) and user- specific client key (326) in a database, and d) returning to the client (100) license key (324 licinfo), client-encryption key (322 clikey), 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 key (327), and that the client (100) is arranged to configure the terminal for the license key-dependent, user-specific service subscription by decrypting the general encryption key (323 enckey) with the cryptographic the secret key (327) and to decrypt the client encryption key (322 clikey), the license key (324 licinfo) and configuration information transmitted from the server with the or the encryption key (323 enkey), and that the client (100) is further arranged to utilize, in the terminal configured with the decrypted license key and the decrypted configuration information, the license key-dependent, user-specific service subscription by using the client encryption key (322 clikey) for signing subsequent inquiries to the service provider concerning the user-specific service subscription. 2. Arrangement according to claim 1, further characterized in that the server is arranged to register the terminal and the client (100) for the user-specific service and that the client (100) upon receiving an error code when using the service, is further arranged to transfer from the terminal to the server (103) a request for service activation where a terminal-specific identity (320) and the user identity (321) are provided in the request, and signing this request by the client with the client encryption key (322 clikey), that the server (103) is arranged to check that the request from the client (100) is signed with a client encryption key (322 clikey), and if the request is correct, license activation is carried out and if the request is signed incorrectly, the request is treated as an anonymous inquiry which described in point 1, that the server (103) is arranged to carry out license activation by asking the user to accept terms of service and provide payment information, and that the server (103) is further arranged to transmit payment information to the credit card company (104), upon acceptance, updated license information is transferred to the client (100) and the AAA database is updated, and upon refusal, the request is rejected. 3. Arrangement according to claim 2, characterized by that the license key-dependent, user-specific service subscription provides is Mobile IP service, and that the error code is error message 131 from a Mobile IP home agent (101) according to the Mobile IP standard defined in IETF RFC3344. 4. Arrangement according to crawl, further characterized by that the client (100) is also arranged to transfer to the server information that includes the client model/version number, terminal operating system type and operating system version, preferred language and reason for the request for activation. 5. Arrangement according to krawl, further characterized in that the server (103) is arranged to require the client to also provide a valid email address or a valid mobile terminal number which can later be used to contact the customer. 6. Arrangement according to claim, further characterized in that the server (103) is arranged to transfer to a permission to the client (100) for reinstallation by issuing a copy of configuration information when the request for activation contains a terminal specific identity (320) known to the server and the user provides a user name (321) that already exists with the server. 7. Arrangement according to krawl, further characterized in that the server is arranged to allow license transfer by issuing a new signed configuration information when the request for activation contains a new terminal-specific identity (320) and the user provides a username (321) that already exists with the server. 8. Arrangement according to claim 7, further characterized in that the server is arranged to allow repeated license transfers only a predetermined number of times by setting a block for the number of license transfers that are allowed per registered user name (321). 9. Arrangement according to claim, further characterized in that the server (103) is arranged to block the issuance of configuration information when the request for activation contains a terminal-specific identity (320) known to the server and the user provides a user name (321) new to the server. 10. Arrangement according to kravl, further characterized in that the client (100) is arranged to detect that a terminal-specific identity that does not have a valid license has been registered, and to offer the user automatic creation of configuration and license. 11. Arrangement according to claim, further characterized in that the client (100) is arranged to detect that the version of configuration data in the client does not correspond to the client software version, and to offer the user automatic updating of configuration information to the correct version. 12. Arrangement according to kravl, further characterized in that the client (100) is arranged to detect that it is not possible to reach the home agent (101) and to redirect the user to a website that offers assistance with configuration. 13. Arrangement according to krawl, further characterized in that the server (103) is arranged to issue a "provider part" for a third party which can give this third party the opportunity to issue licenses for the activation of license key-dependent, user-specific service subscriptions, without this third party gaining access to change service provider and web address for configuration. 14. Arrangement according to krawl, further characterized in that the server (103) is arranged to issue a "supplier part" for third parties which can give this third party the opportunity to issue signed profiles, without this third party gaining access to issue licenses for client software. 15. Arrangement according to kravl, further characterized in that the server is arranged to sign the configuration that is transferred from the server (103) to the client (100) in order to avoid incorrect configuration and denial of service attacks against the client.