SYSTEM AND METHOD TO IMPROVE INTERNET TRANSACTION SECURITY

Field of the invention The present invention relates to security arrangements for arranging transactions over a communications network.

Background of the invention

Web-based electronic banking, or e-banking, has become crucial element in financial systems. Many evaluations of web-based electronic baπk- ing systems indicate that the systems have serious security weaknesses. The latest trend in e-banking is now mobile e-banking. End users are able to access their financial systems by using mobile devices or so-called smart phones.

Typically the screen size of these smart phones is very limited as compared to personal computers and thereby application user interfaces have to be simplified. Another characteristic is that the complex system configurations, such as for example network connection related configurations, are not easily examined by the end user and majority of end users are not able to recognize if faulty and malicious configuration exists in their smart phone. At the same time these smart phones are very vulnerable to malicious configuration attacks because smart phone configurations are often operated remotely by service providers. Security of the remote configuration protocols, such as

Open Mobile Alliance OMA Client Provisioning protocol, is known to be weak.

Although smart phones are more vulnerable to hostile attacks these vulnerabilities also exist in home computers and in all other equipment connecting to the Internet. Many known computer viruses try to change system configuration of the host in order to access private user data.

One serious weakness in current browser implementations is how SSL protocol security has been implemented. All browsers allow end-users to establish a secured connection to a server even though the server's certificate is not valid. End users are used to accept these unverified servers and thereby the whole SSL framework is basically broken. This industry wide problem makes it trivial to establish a shadow web service, which looks exactly the same as a real web service but is actually located in a hostile server. Thereby misleading web links in emails and faulty configurations in a client device are

likely to work in case a hostile attacker somehow manages to get those into the client device. Since the so-called SSL framework Is broken, current web- services are vulnerable to active man-in-the-middle attacks.

Brief description of the invention There is now provided an enhanced solution for transactions between two devices over a network. This solution may be achieved by methods, communications devices, and a computer program product, which are characterized by what is disclosed in the independent claims. Some embodiments of the invention are set forth in the dependent claims. According to an aspect of the invention, a first device is pre- configured with security mode setting information indicating resources and/or serving entities requiring a specific security mode. In response to a need to transmit a request for a resource to a second device, the first device checks if the request is associated with a resource and/or entity defined in the security mode setting information. The specific security mode is activated in response to the request being associated with a resource and/or entity in the security mode setting information. User-authorized exceptions to security procedures are prevented during the specific security mode. An indication of the capability of the first device to function in the specific security mode is transmitting to the second device.

According to another aspect of the invention, there is provided a method for controlling access to web services. The method comprises: receiving a web resource request from a client device provided with a security mode capability during which user-authorized exceptions to security procedures for the web service transaction are rejected, checking the request for an indication of the client to operate in the security mode, and acting on the request on the basis of the indication.

The present invention enables to automatically improve end user security ievel when a user is connecting to sensitive data located in remote web server over the Internet. Furthermore, web service providers, such as financial institutes, may select a minimum security level, which an end user has to follow in order to gain access to their financial services over the Internet.

The embodiments of the invention provide several advantages, which will be apparent on the basis of the following detailed description.

Brief description of the drawings

In the following, some embodiments of the invention will be described in further detail by means of some embodiments and with reference to the accompanying drawings, in which Figure 1 is a flow diagram illustrating a method according to an embodiment of the invention;

Figure 2 is a flow diagram illustrating a method according to an embodiment of the invention;

Figure 3 is a flow diagram illustrating a method according to an em- bodiment of the invention;

Figure 4 is a flow diagram illustrating a method according to an embodiment of the invention;

Figure 5 is a functional block diagram illustrating modules of the system according to an embodiment of the invention; and Figure 6 illustrates functional units of a communications device.

Detailed description of embodiments

Some embodiments of the invention are explained in the following. It is to be understood that these embodiments are only examples. The present features may be applied in any Internet Protocol (IP) based communications system, where a client device may request web services from a server over one or more communications networks. The server may be directly or indirectly connected to the Internet. The server accepts or rejects the request; in case of acceptance, the server sends the requested web resource to the client over the communications network(s). Since the communication is not limited to using any specific communication network, but various current and future wireless and wired networks may be used to deliver the web service related requests and responses, the network architecture is not disclosed in further detail,

First, let us study features for a web browser client device for im- proved browsing. in one aspect of the present method, there is provided a runtime analysis of servers to which an end user is attempting to connect with a www browser. In case the target server analysis shows that the name of the bookmark or another identifier, such as at least part of the actual URL (Uniform Re- source Locator) has similarities with a pre-installed keyword list, the browser

automatically changes its mode to force certain security features on to improve security level. In one embodiment domain names are applied. This new security mode with improved security level is referred as safe mode below.

One embodiment of such run-time analysis for HTTP(S) requests is illustrated in Figure 1. It is to be understood that the illustrated features are not limited to any particular protocol. in step 102 there is a need to request a web resource. The analysis phase of Figure 1 is performed to recognize if the end user is either directly or indirectly trying to access 102 a web page with a similar or near similar name as his financial services or other private services. For instance, the method may be initiated in response detecting an input from the user for retrieving a web page, in another embodiment step 102 is entered in response to detecting a request, such as an HTTP GET request. The URL analysis is carried out by comparing characteristics of the connection against a predefined list of key- words.

The client device is pre-configured with safe mode setting information indicating resources and/or serving entities requiring a specific security mode. Such safe mode setting information may include a keyword list. The keyword list is a list of words, URLs, domain names that the actual web ser- vice has. For example, a brand name is a good keyword candidate.

In one embodiment the keyword list is produced by a service operator. It can be installed to a device or it can be downloaded from a secure web site in runtime. In one embodiment some keyword list items are built fnside a web browsing system in the client device. For instance, domains reserved for financial institutions may always be treated as secure, it is possible that some or all of these mechanisms are in use simultaneously and although a single keyword list is disclosed, there may be a plurality of keyword lists used in the present method.

If a pre-installed keyword list is in use, it is in one embodiment ac- cess-controlled. The keyword list may be installed to the device such that applications of the client device may only read this data, thus enabling to prevent any modifications after the installation.

In one embodiment digitally signed software techniques are used for installing the keyword list. For instance, digitally signed software installation techniques available in operating systems may be used. In order to successfully install a keyword list, the keyword iist should be digitally signed by an or-

ganization operating the installation service and corresponding valid public key must exist in the client device's certificate storage. The keyword list may be verified using some cryptographic hash function. The client device may calculate a hashed message authentication code (HMAC) fingerprint over the used keyword list and send it to a verifying server. The server compares fingerprint sent by the client device to the one stored in its database to verify that the used keyword list is not modified.

If the keyword list is fetched from the network server, the system security should be considered very carefully to avoid misuse of keyword list. The keyword list may include rules and other elements to define client behavior in case perfect or partial match is found. The user device, in one embodiment the browser may store and apply several keyword lists. For instance, there may be a keyword list for each server, but it may be adequate to protect only the most sensitive servers. In the embodiment of Figure 1 , characters of the selected bookmark and/or URL are checked 104 and compared 106 to the entries in the keyword list. The checking 104, 106 may be implemented in various ways. For instance, characters in the URL and/or bookmark are compared to characters in the keyword list. If complete or adequate enough match exists, safe mode is entered 110. Otherwise next entry in the iist is entered until the whole list has been searched. If no match is found, browsing is continued 108 in normal mode.

In one embodiment URL and/or bookmark is only partially searched. For instance, only part of the host name indicated by a URI is searched for. The features of Figure 1 may be repeated every time a need to request a web resource is detected, or only when a request to a new domain or server is detected. If the browser has been in safe mode when entering step 102, the step 108 also represent exit from the safe mode and in step 110 the safe mode is continued. It is to be noted that the serving entities and/or resources, for which the safe mode is to be applied, may be predefined in the client device by various means and formats, and it is not necessary to use a list of keywords.

The safe mode setting information comprises one or more rules specific for the associated resource and/or entity, or common to at least part of the associated resources and/or entities. The web resource request transmission and HTTP or HTTPS/SSL related operations and the security policy in the

client device may be controlled during the safe mode in accordance with the rules associated with the resource and/or entity.

Figure 2 illustrates in further detail operations during the safe mode according to an embodiment. It is to be noted that not all features illustrated in Figure 2 are necessary for the safe mode, and it is also possible to add new features to the safe mode procedures. The illustrated method may be applied in the web browser or browsing system of the client device.

When the safe mode is turned 200 on, the method according to an embodiment distinguishes 202 between plain HTTP connections and SSL se- cured HTTPS connections.

In case the safe mode is on, the method in accordance with an embodiment checks 204 if plain HTTP connection is allowed inkeyword list. If so, the connection with the server is plain HTTP connection and at least some of the following features may take place. The method may disable 206 ail HTML authentication and other dialogs where user is able to give input to a server. Further, the method may be configured to prevent execution of any unsigned program component, such as Java scripts, embedded into accessed web pages. Thus, the present safe mode procedures may improve security level also for plain HTTP connections. It is even possible that in keyword list plain HTTP connections are totally disabled.

In case the safe mode is on and the requested connection is SSL secured HTTPS connection the method forces 212, 214 SSL security procedures, i.e. no exceptions or alleviations are allowed. In case the SSL negotiation fails due to a mismatch in server certificate, the method will refuse 230 the connection. The method refuses any user exceptions after unsuccessful SSL negotiation 230 or during the SSL procedures 212, 214.

In one embodiment the method is arranged to prevent user authorizations for accepting faulty certificates, such as expired certificates. In a further embodiment display of a dialog for the end user to accept server side faulty certificate is prevented.

In one embodiment the client, in one embodiment the browser application, will advertise 216 its safe mode capabilities to a web server. The browser may inform the server about at least some of the following information: « genera! safe mode capability of the browser and/or safe mode attributes

β keyword list properties or further keyword list related information, such as calculated HMAC over the keyword list β keyword list version and/or validity information

In one embodiment the capability information advertised by the browser includes at least some of the foliowing client system level information elements: system information (such as operating system name and version information), anti-virus software information (such as name and version information and last execution date), or firewall information, such as personal firewall name, version and status information. The client capability information is sent to the web server being connected in order to enable the server to check the client configuration, the checking being further illustrated later in connection with Figure 4.

There are many implementation options available for arranging transmission of the (safe mode) capability advertisement to the server. In one embodiment the capability information is transmitted in one or more HTTP message header fields in step 216. Since the HTTP protocol allows using vendor specific header fields, it is possible to define a new specific field for safe mode usage. It is also possible to apply certain extensible HTTP headers, such as Expect and Pragma headers, which are defined in RFC_2616. Send- ing the information is basically implementation specific and any information transmission mechanism may be used as long as client and server use the same mechanism. In one embodiment the safe mode advertisement is sent also during plain HTTP operations, i.e. in step 208.

In steps 218 and 210 the received web page is displayed. Later, when an input to move to another page is detected, procedures illustrated in steps 220 to 228 may be applied. Also with reference to step 112 of Figure 1 , after step 220 or 226 the analysis procedure of Figure 1 may be repeated for a new request (not shown in Figure 2). In case the new request does not require safe mode, the browser state may be changed 224 to the normal mode for conventional browsing. In one embodiment server redirections, such as HTTP redirect, are rejected 228, 230 during the safe mode.

According to an aspect, there is provided a method for controlling access to web services on the basis of specific client device configuration information transmitted in a web request, such as an HTTP GET request. A re- quest is formed for a web page in a client device, in one embodiment in step 216 of Figure 2. The request is transmitted to a web server.

Figure 3 illustrates features for controlling access to web resources by allowing or denying web resource requests on the basis of such client device information in web page requests.

The request transmitted from the client device is received in step 300. In one embodiment the request comprises at least an indication of specific security mode capability during which user-authorized exceptions to security procedures are rejected or prevented, but may also comprise further configuration information as further illustrated later.

The client device specific configuration information in the received request for web page is checked 302. Then, the server further acts on the request on the basis of the checking step 302.

The suitability of the client device for the requested service may be decided 304 on the basis of the received client device specific configuration information and predetermined security requirements of the web server. The server recognizes and is able to distinguish between clients that are able to perform safe mode and clients that are not. Thus, safety mode information is applied in steps 302 and 304, but aiso other checks may be performed.

The request may be allowed and the requested web page may be transmitted 306 to the client device in response to the client device specific configuration information meeting the predetermined security requirements.

In one embodiment, the server rejects the request if the client does not support the safe mode, i.e. no indication is detected or the indication is not acceptable. In an alternative embodiment, not shown in Figure 3, the server may proceed with the request even if the client device does not support the safe mode. For instance, a limited service or an HTTP redirection may be provided for the client device. There are many possibilities available for arranging differentiated service provision for client devices supporting the safe mode and for client devices not supporting the safe mode.

In one embodiment the server, on the basis of the check 304, the server refuses 308 to offer service for clients that do not advertise their safe mode capabilities. The server may also perform an HTTP redirect to another web page from which user is able to download the keyword list installation package and instructions.

In one embodiment the server is in step 302 arranged to check the web browser client on the basis of HTTP User Agent header field. Only brows-

ers known to support the safe mode are allowed in step 304 to continue to keyword list installation procedure.

In one embodiment further system information, such as anti-virus software identification information, and firewall information is sent from the cli- ent to the web server and used in steps of Figure 3. Hence, the web server may block connections from clients that are not implemented securely enough or which have outdated operating system or weak security protection and thereby are more vulnerable to viruses, Trojan horses and other attacks.

Figure 4 illustrates a further embodiment for arranging checking of the appropriateness of the client device, which may be implemented in steps 302 to 308 of Figure 3. The procedure checks 402 if an appropriate indication for safety mode is included in the received request. If so, the server may be arranged to perform at least some of the following additional checks. In this step the server may also check further safe mode attributes in the HTTP(S) request and reject 410 service, or offer a limited service, for requests not including appropriate safe mode attributes.

A keyword list version and its validity is checked 402. In this embodiment the client may be arranged to include this information in the request in step 216. In case the keyword list version has become obsolete, the server may request client to update the keyword list before continuing the service.

Presence and correctness of an HMAC calculated over keyword list is checked 404. In this embodiment the client is arranged to calculate and send an HMAC calculated for the web server in step 216, for instance.

Further client system information, such as used security protections and configurations, is checked in step 408.

If any of the above checks fails, the server may refuse 410 the connection and thereby deny end-user's access to a requested service.

In one embodiment the client device is arranged to send a digital fingerprint to the server. In case the fingerprint sent by the client is not the same as corresponding fingerprint stored in the server, the server may refuse the connection. In such a case the server may silently discard any further messages or instruct the client about the issue.

In case the client system information indicates 406 that for some reason the client security is exposed to some known security problem, the server may refuse the connection and instruct the client to repair the problem.

Figure 5 illustrates logical modules for a client device 500 and a server system 550, for instance a server system providing a web based banking portai.

The browser 510 is configured to provide an analysis module 512 for providing the analysis features illustrated in Figure 1 by applying one or more keyword lists 514, an operating mode control module 516 for controlling operations in the safe mode by applying at least some of the client device safe mode related features illustrated above, and an advertisement module 518 for advertising the client properties to the web server, and a connection module 520 for providing connectivity, such as HTTP(S) request transmission and response reception, between the client device and the server system 550. The server system comprises one or more WWW servers/backeπd servers 560, a connection manager 570 processing and managing requests from the client 500 by means of data stored in a database 572. The connection manager 570 may be arranged to implement some or al! above-illustrated server related features.

Figure 5 also illustrates an application installer 530 by an operating system in the client device and a keyword installation module 580 in the server system 550 for providing at least installation of the keyword list(s) 514 to the client device 550, but possibly also for installing other components or control data to the client device 500.

Figure 6 illustrates functional units of a communications device. The communications device comprises a memory 604, a user interface 602, such as an input device and a display, a transceiver 606 for implementing wired or wireless data transfer, and a control unit 600 implemented by one or more processors. The memory 604 may comprise both volatile memory and nonvolatile memory, such as Flash memory or EEPROM (electrically erasable programmable read-only memory). Different applications may be implemented in the communications device by executing a computer program code stored in the memory 604 in the processor of the control unit 600. The communications device may be configured by means of the computer program code executed in the processor of the control unit 600 and/or hardware solutions to implement above-illustrated functions related to secure communications. The computer program code may be stored on a separate memory means, from which it may be loaded on the communications device.

The above illustrated server device, such as a HTTP server connected to the Internet, and the client device both comprise these basic units of a communications device illustrated in Figure 6. The client device may be any computing device, for instance a conventional desktop or laptop computer, a mobile communications device, a PDA device provided with mobile communications functionality, or a combination of one or more devices, such as a combination of a portable computer and a mobile communication card.

The accompanying drawings and the description pertaining to them are only intended to illustrate the present invention. Different variations and modifications to the invention wil! be apparent to those skilled in the art, without departing from the scope of the invention defined in the appended claims. Different features may thus be omitted, modified or replaced by equivalents.