Method for securing a gadget access to a library

The invention relates to a method for securing a gadget access to a library.

The World Wide Web, thereafter referred to as the "Web", is a system of interlinked hypertext pages which can be accessed through the Internet. More precisely, a user can operate a Web browser to display on his/her computer Web pages which are stored in a distant Web server.
For that purpose, the Web browser downloads the code source of such Web pages, via the Internet, from the Web server to the computer.

Such Web pages may contain multimedia data - such as text, images and videos - and/or provide access to applications. Also, Web pages generally allow navigating between them using hyperlinks.

Specific technologies have been developed in order to increase inter-connectivity and interactivity in the Web-delivered contents, such technologies being commonly named Web 2.0.

The Web 2.0 allows users not 'only to retrieve applications and/or information - as the in prior Web - but also to participate in their creation and/or development.

In this context of the Web 2.0, portable software programs called "gadgets" or "widgets" have been developed to provide end users with applications that can be installed and executed within Web pages.

Practically, Web gadgets are files based on extensible Markup Language (XML), a general-purpose specification allowing the creation of marked-up languages such as the extensible HyperText Markup Language (XHTML).

Gadgets also use XHTML elements, metadata and scripting languages such as JavaScript®, in order to access objects embedded in other applications.

To operate a gadget, a Web browser needs to download the gadget from a specific server, thereafter called gadget container, which stores features to be implemented in an XML file of the gadget, called thereafter primary file.

More precisely, the gadget container requests the transmission of the gadget XML file to a Web hosting server and, after reception, implements the features within such XML or primary file.

Gadgets are created by independent developers but, to provide some compatibility, the features to be implemented therein have been defined and/or standardized de facto. Thereafter, a set of features define to run a gadget is called a library.

Thus, a developer using such features - typically JavaScript® interfaces or API - in the operation of a widget has the assurance that the widget can be implemented through any container complying with these given features.

As an example, a special feature allows to check for the presence of another feature in a container: gadgets.utH.hasFeature(feature name)

Nevertheless, a problem with gadget development lies on the possibility to develop a gadget in order to spam users. If, for instance, a service provider provides a new standard feature allowing a gadget to send e-mails or launch phone calls, a spam developer can try to create a gadget which would wrongly use that feature to spam users.

A proposed solution for that problem might be to limit access to libraries in order to avoid the operation of a spamming gadget, for instance by limiting its use for a limited number of operations: Nevertheless, this limitation does not allow the development of gadgets to be hosted anywhere, and copied by anyone, according to the gadget development philosophy. It would also restrain gadgets' development even if specific developers are known to be trustworthy and/or even if gadgets' code was deeply checked by the gadget container owner.

The present invention aims to solve such problem by providing a method which allows both public access to gadget development and enhanced security on gadget operations.

For that purpose, the invention relates to a method for securing the operation of a gadget requiring access to features hosted in a library of a gadget container in order to implement these features into a primary file of such gadget, the primary file being sent by a Web hosting server to the gadget container to allow the implementation of the features with the primary file, wherein:

- the gadget container retrieves the primary file of the gadget from the Web hosting server with a signature, based on a public key /private key encryption system, associated therein,

- the gadget container controls, with a public key of the public/private key encryption system, the signature associated to the gadget primary file,

- the gadget container decides to authorize or to refuse the implementation of its library features depending on whether it accepts or refuses the signature associated with the primary file.

A method according to the invention delivers a light and transparent service agreement for the use of specific features stored in gadget containers while keeping the ease of programming gadgets through open standards.

Thus the invention is fully compatible with gadget's approach since the gadget is not encrypted but rather signed, so that everyone can examine its code to develop it and/or to use it.

In one embodiment, the signature associated to the primary file de-rives from an encryption, with a private key of the public/private key encryption system, of an identifier depending on the primary file code.

In one embodiment, the identifier depending on the primary file code is a Hash function of the primary file.

In one embodiment the gadget container decides to authorize the access to the features of the library when it both identifies the authorized private key as an authorized private key and establishes the integrity of the primary file.

In one embodiment the gadget container decides to refuse the access to the library features if either:

- the private key is not recognized, or
- the private key is not authorized, or
- the integrity of the primary file is not established.

In this case, a message indicating a lack of authorization may be transmitted to the Web browser requesting to operate the gadget.

In one embodiment the feature is dynamically generated depending on an IP address associated to a request for operating the gadget.

In one embodiment, the authorization for access is given for a certain lack of time.

In one embodiment, the primary file is an XML file and the features comprise Javascript® code.

The invention also relates to a gadget container hosting features to be implemented into a primary file of a gadget, such primary file being received from a Web hosting server upon request by the gadget container, wherein the gadget container comprises:

- Means for retrieving the primary file of the gadget with a signature, based on public/private key encryption system, associated therein,

- Means for controlling, with a public key of the public/private key encryption system, the signature associated to the gadget primary file,

- Means for authorizing or refusing the access to the library's features depending on whether it accepts or refuses the signature associated within the primary file in order to implement a method according to any of the previous embodiments.

The invention also relates to a gadget primary file requiring access to features hosted in a library of a gadget container in order to implement these features for its operation, wherein it comprises a signature, based on public key/private key encryption system, associated therein in order to implement a method according to any of the previous embodiments.

The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same becomes better understood by reference to the following detailed description when taking in conjunction with the accompanying drawings wherein:

- Figures 1 and 2 represent the operation of a public/private key system for digital signature as used in the invention, and

- Figure 3 represents a sequence of operations in a method according to the invention.

In reference to figures 1 and 2, the essential aspects of a signature through public-key cryptography, also known as asymmetric cryptography, are represented.

In one application of this form of cryptography, any of a plurality of different private keys can be used to encrypt a file while a public key can be used to identify which private key was used to encrypt the file.

For that purpose, public and private keys are codes mathematically related whereby the private key code cannot be practically derived from the public key code while the public key can be used to decrypt private key based encryptions.

Further, private key signature requires a file treatment to get an identifier 12 of this file 10 - for example its Hash function that a private key 14 encrypts thereafter.

Thereafter, the encrypted signature 16 of the file 10 is obtained by encrypting the identifier 12 with the private key 14. To finish with, a certificate 18 is joined to the encrypted signature 16 and to the file 10 in order to identify a public key 24 which should be used thereafter to verify the signature of the signed file 19.

4 For that purpose, the signed file 19 (figure 2) is treated in order to retrieve both a file 20 and an encrypted signature 26 so that an identifier 22 -its Hash function according to this example - is derived from this file 20 and so that the public key 24 decrypts the signature 26 to obtain an identifier 22' - its Hash function according to this example.

If identifiers 12, 22 and 22' are identical, it is established that the file 20 corresponds to the file 10 - integrity condition - and that it was signed by a private key 14 which can be identified - identification condition.

Such signature identification process is used in this embodiment of the invention wherein a private key is used to incorporate a signature into a gadget code.

More precisely, a private key is used to encrypt an identifier of such gadget code, as its Hash function, as previously described in reference to figure 1. For instance, such signature may appear under a heading "Signature" in the primary or XML code of a gadget as in the following sequence:

iQCVwUBNI6/9rgiQr+16we9AQExEQP/esoaFA/wLiYrhrfBJqGnMJZRI3WI8jZ/f2fMU3qPfO WGkOoyZBujsq1kMEaxai4m+WqaXremZdsQFaiRxaJTcrE1Sv+8DeaNTQIgMila/Cp/d1ZGj YkgbfFdat/Y8iual JFiEddMK2IJMf0hhSo1 ozSmxizYYI U

restrictedLibrary.action();

]]>

It is underlined that various parameters given in this example - e.g. the name of the XML tag, its emplacement in' the XML stream, the kind of signature, the type of gadget specification - do not limit the scope of the invention since they can vary depending on the gadget to be signed.

With a private signature associated to its code, a gadget file can be identified by a gadget container in order to control its access to a hosted features following the sequence of operations explained hereunder in reference to figure 3 where references used in figures 1 and 2 may be used to refer to ) private/public keys.

To start with a gadget operation, a Web browser 32 requests, upon activation of an HTML iframe tag 30 associated to a gadget, the donwloading of such gadget. For instance, the iframe tag may appear as: