GB2456742A

GB2456742A - Determining trust levels for data sources

Info

Publication number: GB2456742A
Application number: GB0712651A
Authority: GB
Inventors: Tim Gover
Original assignee: Symbian Software Ltd
Current assignee: Symbian Software Ltd
Priority date: 2007-06-28
Filing date: 2007-06-28
Publication date: 2009-07-29
Also published as: GB0712651D0

Abstract

A method and system wherein any type of communications application using any type of data source identifier can have a trust level determined for that identifier. In dependence on the trust level which is determined, the application may take action such as alerting the user to the sort of data which may be exchanged with the data source, and/or blocking access to and from the data source. A database is maintained of data source identifiers and their associated trust levels. This database may be queried by any type of communications application. To maintain integrity of the trust levels assigned to data sources in the database, information is imported into the trust level database on the basis of the authenticity of that data having been validated by having the data signed by a trusted third party digital signature, the public key for which is stored on the data communications device which uses the embodiment. Examples of data source identifiers include URL, URI, IP addresses, MAC addresses, phone numbers etc.

Description

lnteflectual Property lice LL Fc C.aivi 1(,IIfl Application No. GB0712651 RTM Date 9 October 2007 The following terms arc registered trademarks and should be read as such wherever they occur in this document: Friends Reunited MySpacc Firefox P910 UK Intellectual Property Office is an operating name of the Patent Office A Ci:ERVICE Method and System for Determining Trust for Data Sources

Technical Field

The present invention relates to a method and system for determining a level of trust to be placed in a data source to be accessed by a data communications device. More particularly, the invention relates to a method and system where a device maintains a trust database of data sources and uses the database to validate the level of trust to be placed in the data source during data communications therewith.

Background to the Invention

In recent years criminals have begun to exploit electronic communications for fraudulent purposes on a large scale. The ability to send large number of messages for very little cost combined with the relative ease in disguising the sender's identity increases the chance of success for the criminal whilst minimising their risk of detection. This is compounded by the amount of personal information that is available online (e.g. in websites such as Friends Reunited, MySpace, and the like) and may be used to created convincing highly personalised messages.

A form of identity theft commonly known as phishing' involves sending an unsolicited e-mail forging the sender address and content so that it appears as though it has been sent from a well known organisation e.g. a bank. If the recipient follows the hyperlink typically supplied in the message then they will be directed to a fake website masquerading as the real organisation. The criminals are then able to record any user information entered by the user, such as their username, password, account or card details.

With respect to mobile communications devices such as mobile telephones and PDAs, a common scam involves sending unsolicited text messages where the recipient is encouraged to send a reply message. A common example of such an unsolicited message is e.g. "you have won a prize" message. Replying to the message is often costly because it will be charged at a premium rate.

An anticipated future attack is a variant of the e-mail phishing attack but on a phone where the user is sent a text message supposedly from their bank saying that there is a problem with their account and they should phone the following number immediately.

The criminal answering the call would then be in a strong position to gain information because of the trust prompted by talking to a friendly human voice. The anticipated increase in use of voice over IP to standard telephony links may make it easier for criminals to gain access to voice calls without revealing their identity.

Other channels of communication may also be exploited such as instant messaging.

Prior Art

Various security-related prior art techniques are known to try and combat electronic fraud such as the phishing attacks described above. Below a brief review is undertaken, and commentary provided on the deficiencies.

To attempt to combat electronic fraud preventive software can be installed at both the client side i.e. on the user's data communications device such as his desktop PC, laptop, mobile telephone or PDA, and/or measures may also be undertaken at the server side i.e. at the data source itself.

With respect to client side measures, commonly such function is built into the particular software application for the data channel being used. For example, to help prevent web-based fraud, browser applications such as Internet Explorer� allow websites to be categorised into zones where each zone controls the sort of content that may be downloaded e.g. ActiveX objects and whether warning prompts are displayed.

The most recent version Internet Explorer 7 (1E7) comes with a number of anti-phishing measures as described at http://www.microsoft.comlwindows/ie/ie7/technology/default.mspx. These measures include:- 1. Improved UI features -the gold padlock indicating that SSL is in use and the root certificate is trusted is now displayed more prominently.

2. 1E7 compares the addresses of Web sites you visit to a list of sites reported to Microsoft as being legitimate. This list is stored on your computer.

3. A set of heuristic rules are used to try and identify potentially damaging websites.

More details about Microsoft's implementation can be found at: http://blogs.msdn.comlie/archive/2005/09/09/463204.aspx.

Similar techniques have been implemented by Google as a plug-in to the Firefox web browser, as described at: http://www.google.comltools/firefox/safebrowsing/ An alternative solution is provided by RoboForm as described at htp://www.roboform.com/anti-phish.html RoboForm' s product stores personal information in an electronic pass-card (encrypted file) which may optionally be stored on a USB key for portability. When the user visits a website registered with the pass-card the details can be filled in automatically.

Call or text filtering has also been used in the past. For example, some phones e.g. Sony Ericsson P910 cause incoming calls to be blocked unless the originator's number exists within the contacts database. Third party software also exists that allows equivalent filtering of text messages.

Another strategy to combat phishing attacks is to perform reverse DNS checks. The majority of phishing attacks utilise bulk e-mail where the address of the sender has been forged. A strategy for blocking these e-mails is for the receiving server to perform a reverse lookup on the sender's domain name to determine the expected IP address of the sender. If this does not match the actual IP address of the sender from then the message could considered a forgery.

Concerning measures which may be employed by owners of legitimate content at the content server side, these include:-I. Personalising secure web pages with information that only the bank should know about the end user.

2. Image cycling where the images on the website are expired every few hours and replaced with links to warning images. This prevents fake websites from simply linking to the images on the real server.

3. Requiring customers to authenticate using hardware based crypto-tokens.

4. Searching the web to find clones of the company website and attempting to get the cloned websites shutdown.

All of the above prior art techniques have drawbacks, however, which impact on their effectiveness or usefulness. For example, Internet Explorer's security zones only work with one application domain i.e. websites, and moreover there is no ability for trusted third-parties to manage the list of websites. Only the end-user or administrator may add websites. Most end-users do not have the expertise to configure this correctly / or at all. The solution is also inflexible because it is focussed on protecting the computer from malicious software i.e. ActiveX plug-ins. The only setting relevant to personal information is whether to require encryption of data submitted to web sites. However, the issue with identify theft is normally not whether the data is encrypted but who you are having the conversation with. Additionally, entries persist forever -there is no expiration of trusted websites.

Additionally, another solution of checking against a database of known phishing websites has several drawbacks: I. A database of known phishing sites is prevention after the attack. Millions of potential victims may have already been contacted before the attack has been spotted.

2. When a suspicious website is reported it must be checked which means that the verifier must be able to access and verify the web-site. The fake website could be programmed to not respond to requests from IP addresses or domains belonging to the database owner. E.g. Ignore requests from Microsoft.

3. Fraudsters could overload the verification system by creating and reporting large numbers of dummy fake websites.

4. The database must be available for a check to be made (although the client may cache recent queries).

5. The database is limited to a particular application domain i.e. web pages.

6. On mobile devices the user may not be willing to pay for the increased data charges to support dynamic checks.

7. The database will become too large to be stored effectively on a device with limited resources such as a mobile phone.

8. There are serious privacy implications if clients check the trust status of websites interactively. The owner of the database would not only be able to validate the websites viewed by a particular client but they can also determine access patterns e.g. time of visit, frequency of visit, whether websites are visited in a particular pattern.

Additionally, the improvements introduced in 1E7 neither address all the issues. For example, the technique of using heuristics to detect suspicious websites as used in 1E7 is always going to be a delicate balance between detecting subtle attacks and preventing false positives. If too many false positives occur then the end-user will simply learn to ignore the warnings. This also increases the testing burden on the owners of legitimate websites because they will want to verifS' that they are not flagged as suspicious. Moreover, the technique of maintaining a database of known good web sites, as used in 1E7 presents the following drawbacks: 1. The list of legitimate websites appears to be rather simplistic and treats all websites equally. In reality most websites can be trusted to deliver content, a subset of these might be trusted for form data e.g. searching for product descriptions, a smaller subset might be trusted for personal information e.g. your e-mail address and then even less would be trusted for sensitive data such as you bank account details.

2. The current implementations do not allow the user to select the database of known good websites.

Likewise neither does improving user interface (UI) features address the issues as a padlock icon only indicates that the root certificate for the website is present in the certificate store. Since most browsers allow new roots to be added to the certificate store it is possible that many users are now conditioned to simply clicking the button to import the new root certificate. In addition the end user typically has no way of establishing whether they should trust a particular Certificate Authority.

With respect to server side solutions, hardware based crypto-tokens provide a strong authentication mechanism making identify theft difficult but suffer from a number of disadvantages restricting its practical use to very high value content such as online banking. In particular the following drawbacks are evident: 1. Expensive to implement 2. Lack of industry standards mean that you might need a token per website 3. A customer may not be willing to carry a physical token around with them preventing them from being useful for mobile devices.

Additionally, making websites difficult to forge is also problematic. The main problem with this approach is that it requires the owner of every website to implement these measures. Also, many of the measures are heavily reliant on customer awareness and there is no clear standard about how a customer should recognise a genuine web site:- 1. A customer visiting an infrequently used website simply may not notice the lack of personalised information.

2. Displaying personalised information may still be faked using a man-in-the-middle attack where the attacker relays all of the information to the real website capturing the login details for use later on.

3. Embedded web browsers such as Opera dynamically resize content to for improved viewing on a small screen. Changing the layout may make information appear out of context or in a less prominent area so the user may simply assume that missing information is a rendering issue.

There is therefore a need for a further system to address the problems of on-line fraud such as phishing attacks or the like.

Summary of the Invention

Embodiments of the invention provide a method and system wherein any type of communications application using any type of data source identifier can have a trust level determined for that identifier. In dependence on the trust level which is determined, the application may take action such as alerting the user to the sort of data which may be exchanged with the data source, and/or blocking access to and from the data source. To maintain integrity of the trust levels assigned to data sources, information is imported into the trust level database on the basis of the authenticity of that data having been validated by having the data signed by a trusted third party digital signature, the public key for which is stored on the data communications device which uses the embodiment.

In view of the above, from a first aspect the present invention provides a method of determining a trust level for a data source, comprising the steps:-storing a database of data source identifiers and associated trust data for the identifiers, said trust data indicating a trust level to be associated with a data source identifier; and providing an application interface to said database to allow one or more communications applications which wish to access a data source to query said database to determine a trust level associated with said data source.

From a second aspect the present invention provides a data communications device able to determine a trust level for a data source, comprising:-a data store storing a database of data source identifiers and associated trust data for the identifiers, said trust data indicating a trust level to be associated with a data source identifier; and an application interface to said database to allow one or more communications applications running on said device and which wish to access a data source to query said database to determine a trust level associated with said data source.

Further features and advantages of the present invention will be apparent from the following description and claims. Further aspects of the invention will be apparent from the appended claims.

Brief Description of the Drawings

Further features and advantages of the present invention will become apparent from the following description of an embodiment thereof, presented by way of example only, wherein like reference numerals refer to like parts, and wherein: Figure 1 is a block diagram of a data communications apparatus according to an embodiment of the invention; Figure 2 is a diagram illustrating message flows between components in an embodiment of the invention; Figure 3 is a flow diagram of a first technique for populating the trust database in an embodiment of the invention; Figure 4 is a diagram illustrating message flows between components in an embodiment of the invention; Figure 5 is a flow diagram of a second technique for populating the trust database in an embodiment of the invention; Figure 6 is a diagram illustrating message flows between components in an embodiment of the invention; Figure 7 is a flow diagram of a third technique for populating the trust database in an embodiment of the invention; Figure 8 is a diagram illustrating a first technique for supplying a data source data file to a data communications device in the embodiment; Figure 9 is a diagram illustrating a second technique for supplying a data source data file to a data communications device in the embodiment; Figure 10 is a diagram illustrating message flows between components in an embodiment of the invention; and Figure 11 is a flow diagram illustrating the method for determining a trust level of a data source in the embodiment of the invention.

Description of the Embodiments

An embodiment of the invention to be described relates to a method for determining the level of trust that should be applied to data originating from a known data source by employing a database containing data source identifiers and associated meta-data.

A set of rules used by the database to determine the trust level for the data sources is described bellow. However, the nature of the physical storage of the database is not described because it is not central to the invention and it is anticipated that it would vary from device to device.

The embodiment is complementary to and should be used in conjunction with existing security mechanisms such as transport layer security to ensure that the identifier for data source in question has not been faked.

The types of data source for which the trust level may be determined include 1. Awebsite 2. Me-mail 3. A phone number or set of numbers matching a particular pattern e.g. all numbers starting with a given prefix 4. Internet Relay Chat or Instant messaging IDs 5. Network identifier e.g. MAC-address.

Other types of data source may of course be incorporated in other embodiments.

The first embodiment of the invention will now be described with respect to Figures 1 to 11. More particularly, Figure 1 illustrates a data communications device 10 representing an embodiment of the present invention. The data communications device 10 could be, for example, a laptop, a desktop computer, or a mobile device such as a mobile telephone, or a PDA equipped with data communications abilities.

The data communications device 10 will typically contain a processor 18, together with memory 16 and input and output devices 14. A network interface 12 is also typically provided, to allow the data communications device 10 to send and receive data. By the network interface 12, we intend to include any data communications interface at which data can be communicated, such as, for example, in the case of a desktop or laptop computer, a network card for interfacing with a network, or a modem, or, in the case of, for example, a mobile telephone, the network interface will be a radio interface for communicating with the cellular network. By input/output devices 14, we intend to encompass any input/output device, such as, for example, a screen, keyboard, thumb wheel, pointing device, or the like.

Additionally provided in the data communications device 10 is a data storage medium 110, storing various data and programs to allow the data communications device 10 to operate. In particular, the data storage medium 110, which may, for example, be a hard disk (such as in the case of a desktop or laptop computer), or flash memory (such as in the case of a PDA or mobile telephone), stores operating system software 112 to allow the device 10 to operate, and to provide an interface to the hardware of the device. Additionally provided are various user applications 124, which are not pertinent to the present description. In order to allow data communications to take place, a number of communications applications are also provided, such as web browser 114, phone caller application 116, instant messenger application 118, and email client application 120. Each of the communications applications is typically conventional, for example web browser application 11 4 allows for the navigation and display of web pages from the Internet. The phone caller application 116 causes the data communications device 10 to initiate telephone calls, for example, in the case of a mobile telephone, over the radio interface via the cellular network. Instant messenger program 118 is an instant messenger client program, to allow instant messages to be composed, sent, and received, and likewise email client program 120 allows email management, such as, for example, the sending, receiving and management of emails.

The communications applications 114 to 120 discussed above typically operate by using a data source identifier such as, for example, in the case of a website a URL, or in the case of an email an email address. Likewise, for the caller application a relevant data source identifier would be a phone number. Various data source identifiers to be used by the communications applications are typically stored in a contacts database (not shown), and an interface into the database is provided to allow a user to manage his contacts, and in particular the data source identifiers. To use one of the communications applications, the relevant application is started, and then is used to interface with the contacts database to select a data source identifier which the communications application is then required to access. For example, the phone caller application can interface with the contacts database to select a phone number, which it then can be instructed to call. Likewise, for the email client application, a user may start the email client application, compose an email message, and then select a data source identifier in the form of an email address to which the message should be sent.

Thus far, such a data communications device is conventional.

According to the embodiment described herein, however, additional components are provided to allow a trust level to be assigned to a data source identifier, indicating a level of trust in which the user of the device 10 should place in the data source. For example, the highest level of trust may indicate that a data source can be trusted to both provide content, as well as to accept data, including, for example, financial data, A lower level of trust may, for example, indicate that a data source can be trusted to provide content, but that only non-personal data should be supplied thereto.

Similarly, the lowest level of trust for a data source identifier may indicate that no data should be supplied thereto, and neither should any content be obtained there from.

In this respect, by "data source" we mean some entity that not only provides (i.e. is the source of data), but also may, either additionally or alternatively, receive data from the device 10.

In order to allow a trust level to be assigned to a data source identifier, the data communications device 10 also includes a trust manager application 122, and a trust database 126. The trust database 126 includes a trust database server, to allow read and write access into the trust database. The trust manager application 122 provides an application interface for the communications applications, to allow the communications applications to determine a level of trust to be applied to a data source identifier, prior to using that data source in any communications protocol.

Additionally provided is a policy store 130, which stores a series of policies, being data indexed by trust level, for each communications application, and which indicates for each communications application what steps it should take in respect of a particular data source identifier, for a particular level of trust that has been returned from the trust database for that data source identifier. Additionally provided (although not shown) is a policy store server, to allow access to the policy store, and in particular by the trust manager application 122.

Finally, the data communications device 10 also includes a certificate store 128, in which is stored public key certificates of signing authorities. For example, the public key certificates may be stored in X.509 format, and belong to signing authorities which are prepared to validate the trust level of a data source. Further details regarding this aspect will be described below.

In order for the embodiment to operate securely, it is important that the integrity of the trust database can be maintained against attack from malicious software. It is also important that the originator of updates to database can be established, and that any attempt by a third party to tamper with the database update files can be detected.

Database integrity can be provided by standard operating system security mechanisms, whereas the authenticity of the data source data to be entered into the trust database 126 is provided by cryptographic security techniques, and in particular using digital signatures to sign data source data to be entered into the trust database, and validating any data source data upon population of the database. Therefore, the actual manner by which the trust database 126 is populated and updated is important, and various techniques for populating the database will be described next.

Figures 2 and 3 illustrate a first technique for populating the trust database, using data source data in a signed data source file 202. The procedure is as follows: Firstly, a signed data file 202 containing a list of data source/trust level records is created in a structured format e.g. XML. It would also be possible to embed the data source records as extensions within a digital certificate and in theory this could be combined with a companies SSL/TLS certificate. However, data sources such as phone numbers are likely to change more frequently (months to a year) than the other signed data (public key / distinguished name). In addition, existing Certificate Authorities may not be willing to sign arbitrary extensions in certificates unless they also wish to act as trusted data source signers.

The signed data source file 202 is then sent to or downloaded by the trust manager in the device (step 3.2) and presented to the trust database for import (step 3.4). Next, the database (or, more accurately the trust database server 204) obtains the signing certificate from the certificate store 128 (steps 3.8, 3.10, 3.12, and 3.14) checks the signing certificate to ensure that it is valid and is derived from a trusted (probably root) certificate held in the device's trusted certificate store. The certificate store could be built into the trust database although in the present embodiment is shown separately. The database also checks whether the certificate is valid for signing trusted data sources (step 3.16). This may be configured as an attribute against the corresponding trusted certificate in the certificate store or as an extension within the end-entity certificate itself. Provided the certificate is valid, the database server then checks to see that the signature is valid and that the file has not been tampered with (step 3.18). If all of the above constraints are met then the data source records are imported into the database and associated with details of the signing certificate (step 3.20). The trust database server then reports back to the trust manager as to the success or failure of the importation (steps 3.22, 3.24, and 3.26).

An example individual data source record, for example in XML format is as follows:- <datasource> <name>Customer Services (Mobile) </name> <trust>ALL</trust> <type>phone</type> <match>150</match> <match>4 50</match> <I datasource> Figures 4 and 5 illustrate a second technique for populating the trust database, this time with data source identifier data and associated trust data manually entered by a user. When an end-user manually enters a URL, bookmark or phone number this may be added as a trusted data source. This is relatively safe because the user is unlikely to manually enter special Unicode characters although; there is still the risk of the user miss-spelling a domain name.

Here, the trust manager program 122 provides the ability to allow the user to command it to allow manual entry in the trust database. When the user so commands (step 5.2) the trust manager program captures the user entry 402 via a dialog box (step 5.4) and passes it to the trust database server (step 5.6) There is a need to ensure that the data source is really being entered by the user and not an application masquerading as the end-user. Therefore, the capture of the data source is performed via the database using a secure dialog (In Symbian OS the TrustedUi capability would be checked).

At the trust database the user input data is received (step 5.10) and stored as a new data source record (step 5.12). A successful save report is then returned to the trust manager (steps 5.14 and 5.8).

A third technique for populating the trust database is shown in Figures 6 and 7. Here, an application 62 is able to communicate directly with the trust database server 204 to allow a data source identifier and corresponding trust level to be entered into the trust database 126. Preferably, this feature is only provided in a secure computing environment where an executable may be uniquely identified (e.g. secure id in SymbianOS).

To perform the direct population by an application, after the application has determined that it wishes to enter the data source in the trust database (step 7.2) it passes the data source data (data source identifier and associated trust level) to the trust database server (steps 7.4 and 7.6). The database server then stores the data source data as a new record (step 7.10) and returns success to the application (step 7.14 and 7.16).

Optionally, the database may implement a policy that restricts an applications ability to import data based on the permissions/capabilities that an executable possesses (step 7.8). Moreover, the database may also optionally implement a policy placing a ceiling on the level of trust associated with an application (step 7.12).

In view of the above, the trust database can be populated in three ways: i) by importing a signed data source data file containing data source records (data source identifiers and associated trust levels), signed by a trusted signing authority, the public key certificate of which is stored in the device certificate store; ii) by allowing manual entry by a user; and iii) allowing an application running on the device 10 to enter data source data in the database. Options ii) and iii) above are straightforward, but with respect to option i), considered the most useful option, the device 10 needs to obtain the signed data source data file in order to be able to populate the database.

One possibility is that the signed data source data file is provided on device manufacture, and the database populated at that time. For example, on mobile phones operators may wish to pre-populate the database with operator trusted websites and phone numbers e.g. the help and support, billing or partner e-commerce details. It is anticipated that users will be more willing to make purchases from data sources that are clearly defined as trusted.

However, it would also be useful if cryptographically secure (i.e. digitally signed) data source files could be obtained to allow for dynamic updates of the data sources in the trust database. Figure 8 shows one mechanism to allow for this, by providing for a content owner which provides data sources to provide signed data source data which may be imported into the trust database on the device 10.

More particularly, with reference to Figure 8, the signing authority does not necessarily have to be the body responsible for delivering the signed data to a device 10. Instead, the signing authority need simply to sign data sources, possibly at the request of the owners of those data sources. The owner of the data source could then deliver the signed data file containing just their details using the following mechanism.

Firstly, the content owner 82 e.g. a bank creates a list of data sources and presents them to the signing authority 86 in a data source data file 88. Preferably this is in the standard data source data file format shown earlier. The signing authority 86 then signs the provided data source data file to produce a signed data source data file 90, which is provided to the content owner 82. The content owner 82 then places the signed file 90 on its web server 84, as signed data source data file 92 available for download.

Next, when visiting the website hosted on server 84 the client device 10 may make a request for the signed data source file 92 and may also specify the lists of acceptable signing authority names. The content-owner's web server 84 then processes this request and returns a match if found. Thus the signed data source file 92 is provided to the requesting device 10. The trust database 126 in the device 10 may then import the returned data source data file 92 in the same manner as previously described in respect of Figures 2 and 3.

In an alternative to the above, rather the device 10 having to request the signed data source data file from the server 84, the signed-data source data file 92 could be embedded as an object within web pages using an agreed mime-type effectively pushing the signed data source file to the client.

A second mechanism for providing a signed data source data file for importation into the trust database is shown in Figure 9. Here, a trusted third party such as a network operator may provide an online validation of data sources. This allows the end user, for example, to perform a bulk validation of all of their data sources e.g. when importing contacts or bookmarks from another device. The mechanism works as follows.

Firstly, the trust manager application locates the certificate for the trusted third party in the device's certificate store and validates that it is tagged for this operation.

Provided that this is the case, the contact data including data source identifiers to be validated are exported into a standard format e.g. ASN. I or XML to provide a contact data file 95. The contact data file 95 is then either transmitted synchronously over a secure channel e.g. TLS, or is signed and encrypted with the public key of the trusted third party using a mechanism such as SMIME and sent asynchronously. The contact data file 95 is therefore received via network 94 at server 98 owned by the verifying and signing authority 96.

The third party verifying and signing authority 96 then compares the data source identifiers in the contact data file 95 with those in its own trust database 97 and produces a new export in the form of signed data source file 99 where each data source identifier is tagged with a trust level. The signed data source file is then encrypted and sent back to the client device 10.The client database 10 then imports the data sources into its local trust database in the manner described previously.

With the above, therefore, signed data source data files can be provided to the device for importation into the trust database to populate the database. The use of the digital signature of the signing authority to authenticate the data source data file means that the integrity of the data source data to imported into the database can be ensured. Of course, if the trust database is compromised, then the ability to determine usefully a trust level for any particular data source when it is to be accessed by one of the communications applications is then lost.

To allow for new or different entities to sign the data source files, an end user may (policy dependent) add a new data-source signing authority certificate to the trust database. To allow the revocation of these certificates the third party certificates must be end-entity certificates derived from a trusted root certificate on the device that is also trusted from data source signing.

When the third party certificate is added its precedence must be established.

Typically, it would be appended to the list so that the device creator's certificates are always processed first. A policy setting may be used to determine whether the user may alter the list of precedence.

Additionally, from time to time signing certificates are revoked. If a certificate used to sign trusted data sources is revoked e.g. the private key has been compromised then preferably all of the data sources within the database that are signed by the certificate should be marked as revoked or deleted. Data sources marked as revoked should be given the default trust level i.e. treated as unknown. Typically the trust database would check whether a certificate has been revoked using a standard protocol such as OCSP (as described in RFC 2650) or examining a Certificate Revocation List (as described in RFC3280).

Having described how the database is populated, description will now be undertaken as to how the trust database may be used, and in particular used to police the activities of communications applications which wish to access from or send data to a data source. In this respect, reference is made to Figures 10 and 11.

Assume now that one of the communications applications 114 to 120 is being used by the user and the user wishes the application to exchange (send to and/or receive from) data with a data source. Before processing or retrieving some data (e.g. downloading the web page) the application queries the trust database to see if there is a match for that data source. If a match occurs then the level of trust associated with the data source, and any policy dictating actions to be taken by the application in response to the trust level can be obtained.

More particularly, with reference to Figures 10 and 11, when a communications application is prepared to access a data source, at step 11.2, it first accesses a contacts database to access a data source identifier.. The operating system also passes the data source identifier obtained from the contacts database by the communications application to the trust manager application 122, at step 11.4. The trust manager application then queries the trust database, via the trust database server 204, at step 11.6. The trust database then searches for the data source identifier to see if the identifier can be matched, at steps 11.8, to 11.20. Here, the data source records in the trust database are searched in a particular order, with the first non-revoked result being given the highest precedence. However, the system may return all matches for informational purposes, to allow the end user to override the decision.

More particularly, preferably signed data sources from the creator, owner, or trusted third party are first searched to try and match the data source identifier. In this case, if a data source is validated by multiple signing authorities then a predetermined ordering will be applied to the signing authorities to determine which has the highest precedence. The trust status from the signing authority with the highest level of precedence will be used.

If the signed data in the trust database does not return a match, then user defined data sources are searched. If the user defined data sources do not return a match, then data sources generated by an application running on the device (referred to as application data sources), are then searched. If there are no matches despite all of these searches, then a default trust level is returned.

Where a match is found, then the following information is obtained from the trust database: - 1. The originator of the record for the data source. This might be the user of the system, another application, the creator of the system or a trusted third party.

2. The status of the information about the data source record i.e. valid, expired, revoked 3. When the record for data source was entered and the validity period for the record.

4. The level of trust a. Trusted for all data including financial (ALL) b. Trusted for low risk personal data (PERSONAL_DATA) c. Trusted for non-personal data (OTHER_DATA) d. Only trusted to deliver content (CONTENT) ... default level for unknown data sources e. Un- trusted / blacklisted (NOT TRUSTED) Here, five trust levels are shown, but more, or preferably fewer, levels may also be used in other embodiments.

If an exact match is not found a similarity match could be made. An unknown data source that closely matches a known trusted data source would be deemed to be suspicious. The similarity match algorithm is outside the scope of this invention however a number of edit-distance algorithms already exist for purposes such as spell checking. However, the database must include the fact that a similarity match was made in the result because a client application may wish to only display probability matches in certain contexts to avoid overloading the user with false positives.

The trust level together with the above described data is then returned to the trust manager, at step 11.24.

At this point, therefore, the trust manager has obtained from the trust database the trust level associated with the data source which the communications application wishes to access. However, all that has been obtained is information relating to the trust level, and this must then be interpreted into actions to be performed by the communications application in response to the determined trust level. The actions to be performed by the communications applications are stored as policy data in the policy store 130, accessed by the policy store server 210. Therefore, having received the trust level information at step 11.26, at step 11.28 the trust manager 122 queries the policy store server 210 to determine what action the communications application in question should take in response to the determined trust level.

At step 11.30, therefore, the policy store 130 is accessed to access the policy for the particular communications application presently in question. The policy data will indicate a particular action for the communications application in response to the determined trust level, and this is determined at step 11.32. The determined action is then passed back to the trust manager at step 11.34, and received at step 11.36. The trust manager then instructs the communications application to undertake the particular action at step 11.38, and this instruction is received at step 11.40, and implemented at step 11.42. Various particular actions may be mandated by the policy data for the particular trust level, as set out below.

A first activity which may be undertaken as instructed by the policy data is to block access to the data andlor data source for data sources that are deemed to be too untrustworthy. Here, the necessary level of trust is likely to depend on the context of the application and policies configured by the device manufacturer or owner.

A second activity which may be undertaken is to provide a visual indicator for content from the data source e.g. changing the colour of a URL or marking a phone number embedded in a text message in a different colour.

A third activity which may be undertaken would be to displaying a dialog box forcing the user to confirm that they wish to access that data. However, this is not preferred, as many users have become accustomed to simply clicking ok' regardless of the dialog text.

Generally, preferably as many activities are provided as there are trust levels. For example, for the example five trust levels mentioned previously, the lowest level of trust may result in the communications application being blocked from accessing the data source altogether; the next lowest may cause a dialog box to be displayed to received explicit user confirmation; the middle level of trust may cause the data source identifier to be displayed in red; the second top level of trust may cause the data source identifier to be displayed in yellow; and the top level of trust may cause the data source identifier to be displayed in green.

Other activities may of course be undertaken, as well as combinations of activities.

For example, the second most lowest level of trust may have the data source identifier (i.e. URL, email address, phone number etc.) displayed in red, and have a dialog box displayed.

With the above embodiment, therefore, a method and system is provided which allows multiple communications applications to determine a level of trust to be applied to a data source, and to provide suitable warnings or take preventative action in response to the determined trust level.

The embodiment has various advantages. For example, the trust database is not limited to a particular application domain. In principle, any type of data source could be validated using this system e.g. domains, phone numbers, user identifiers or network identifiers.

Moreover, storing the data within an independent database with an open API allows independent applications to benefit from the same infrastructure i.e. not tied to the web browser.

Additionally, using standards based public key infrastructure techniques provides a secure update and revocation mechanism enabling multiple independent parties rate the trust level of data sources. Establishing an order of precedence for trusted data source signers enables the system to reflect the different types of ownership for mobile devices. E.g. A company phone managed by the IT department versus a retail customer who has purchased the phone on a contract.

Furthermore, to implement the embodiment no complex internet infrastructure is required. The signed data source files may be downloaded from standard web servers.

Also, allowing content owners to distribute trusted data source records enables the system to be de-centralised. This increases the resilience of the system.

For mobile device the database does not need to be connected to operate so it is well suited to mobile devices. E.g. if you sync your e-mail to the phone using Bluetooth the messaging application should still be able to display the trust status even if an internet connection is not active. Additionally, the portion of the database populated by the device owner could be propagated to another device e.g. when a customer upgrades a mobile phone.

Capturing user-defined data sources via the database using a secure UI allows any application the ability to import data sources (with user assistance) without compromising security. This is important because validating applications for security is typically an expensive process.

Several uses are also apparent. For example, on mobile phones operators may wish to pre-populate the database with operator trusted websites and phone numbers e.g. the help and support, billing or partner e-commerce details. It is anticipated that users will be more willing to make purchases from data sources that are clearly defined as trusted.

Additionally, the use of PKI infrastructure allows enterprises to act as trusted data source signing authorities for company phones by adding their own certificates.

Moreover when a new phone is purchased an application could import the contacts database or SIM card entries as trusted data sources.

Storing the data on a mobile device could allow the trust database to be queried by external devices to allow data sources to be validated on that device e.g. a PC web browser plug-in could be used to query the trust database via Bluetoothl.

Various modifications and variations may be made to the above described embodiment to provide further embodiments which make use of the inventive concept, any and all of which are intended to be encompassed by the appended claims.

Claims

Claims 1. A method of determining a trust level for a data source, comprising the steps:-storing a database of data source identifiers and associated trust data for the identifiers, said trust data indicating a trust level to be associated with a data source identifier; and providing an application interface to said database to allow one or more communications applications which wish to access a data source to query said database to determine a trust level associated with said data source.

2. A method according to claim 1, and further comprising storing policy data associated with said trust level, said policy data for informing the communications applications of action to be taken in dependence on said determination of a trust level for a data source.

3. A method according to claim 2,and further comprising, taking said action determined from said policy data.

4. A method according to claim 3, wherein said action includes blocking user access to said data source.

5. A method according to claims 3 or 4, wherein said action includes providing to the user a visual indicator relating to a data source identifier of the data source.

6. A method according to claim 5, wherein said data source identifier is displayed in a different colour.

7. A method according to any of claims 3 to 6, wherein said action includes displaying a dialog box to a user to obtain user confirmation to access a data source.

8. A method according to any of the preceding claims, wherein the storing step includes populating the database from a data source data file containing data source tryst records in a predetermined format, said file being imported into said database to establish said database records.

9. A method according to claim 8, wherein said data source data file is digitally signed by a trusted signing entity, and said populating includes obtaining a public key certificate of the trusted signing entity from said certificate store, and authenticating said data source data file prior to said importation into the database.

10. A method according to claim 8 or 9, wherein said data source data file is obtained from a third party content provider.

11. A method according to claim 10, wherein said data source data file is obtained from the third party content provided via a web server over the world wide web.

12. A method according to any of the preceding claims, wherein the storing step includes populating the database from user inputs of data source identifiers.

13. A method according to claim 12, wherein the user inputs are obtained using a secure user interface.

14. A method according to any of the preceding claims, wherein the storing step includes populating the database from information provided from an application to the application interface.

15. A method according to claim 14, wherein, prior to accepting data source data from an application, the application's permissions and/or capabilities are checked.

16. A method according to claims 14 or 15, wherein the trust level is limited to a particular level or levels for a data source trust record installed in the database by an application.

17. A method according to any of the preceding claims, wherein the storing step further comprises: providing data relating to data sources, including data source identifiers, to a verifying authority for validation of said data sources to assign a trust level thereto; receiving from said verifying authority a data source data file containing data source trust records corresponding to the data sources provided to the verifying authority; and populating the database from the data source data file, said file being imported into said database to establish said database records.

18. A method according to any of the preceding claims, wherein multiple communications applications query said database.

19. A method according to any of the preceding claims, wherein multiple types of data sources may have trust levels determined therefor.

20. A method of providing trust data for use by data communications devices, comprising the steps: compiling a set of data source identifier data relating to one or more data sources and associated trust levels for said data sources in a data source data file; providing said file to a trusted signing entity to have said data source data file digitally signed; providing the digitally signed data source data file to user data communications devices.

21. A method of providing trust data for use by data communications devices, comprising the steps of: receiving data relating to data sources, including data source identifiers, from a data communications device; comparing said data source identifiers with a database of data source identifiers having trust levels for each data source predetermined; based on said comparison, assigning a trust level to each data source identifier; compiling a data source data file containing said data source identifiers and the associated assigned trust levels; and sending said data source data file to said data communications device.

23. A computer program or suite of computer programs so arranged such that when executed by a computer they cause the computer to perform the method of any of the preceding claims.

24. A machine readable storage medium storing a computer program or at least one of the suite of computer programs according to claim 23.

25. A data communications device able to determine a trust level for a data source, comprising: -a data store storing a database of data source identifiers and associated trust data for the identifiers, said trust data indicating a trust level to be associated with a data source identifier; and an application interface to said database to allow one or more communications applications running on said device and which wish to access a data source to query said database to determine a trust level associated with said data source.