Copy protection of data

IS 2 178 174 T3

DESCRIPTION

Data protection against copying.

Field of the invention

The present invention relates to the protection of data against copying and has a particular application in the protection of data transmitted over a network such as, for example, hypermedia transmitted through a web-based network.

Background

As is known, data in the form of hypermedia, such as hypertext, is often written in the HTML hypertext language and arranged on web pages that are provided by a server connected to a client over a network. The client may have a personal computer or other processing device capable of presenting the data retrieved from the server to the user. The network may have a local area network (LAN), a wide area network (WAN), or the Internet. For example, the World Wide Web comprises many servers connected through the Internet in a network, which have addresses in the form of a uniform resource locator (URL).

The hypertext information is available on web pages that include sensitive areas to allow the user to establish a link with another web page, which can be found on the same server or on a different one, being routed to the document through the use of the URL of the sensitive area of ​​the web page.

Web customers usually access hypermedia information through a browser. General information about the World Wide Web and HTML can be obtained in chapter 1 of the document ráHTML 3.2 and CGI Unleashedrá by J. December and M, Ginsberg, 1996 (ISBN 1 - 57521 - 177 - 7).

As is known in the art, text, graphics and other descriptive files such as video images, animated graphics and audio samples can be displayed on HTML web pages. Hypermedia has the great advantage that the client can quickly switch between documents by clicking on sensitive areas of the document, which allow him to move from one website to another located perhaps in another physical location.

Individual documents presented on HTML pages can be copyrighted documents. Because of the ease with which the copyrighted document can be viewed, transmitted, and copied on the Web, it is difficult for the copyright owner to enforce the copyright. For example, when a graphic file has been downloaded to a client, they can easily copy it to their computer's hard drive and reproduce it digitally many times, without significant degradation from one copy to another.

In the document JAVA, THE WEB, AND SOFTWARE DEVELOPMENT »by E.Yorudon, COMPUTER, vol. 29, No. 8, August 1996, emphasizes the need for development tools to help create secure access to functions and data, as well as secure transmission of confidential data over the Internet. The procedures described include adding digital signatures to the applets that are downloaded from the Web, so that the user can be sure of their source and origin. In a client-server system, a user's authorization to access certain functions or data can be determined by an application program that, in turn, can work with a Web browser to encrypt and decrypt transmissions between stations. work of the user and the server.

In the document raJava Security: From Hot Java to Netscape and Beyondrá, by D. Dean, EWFelten and DSWallach, Proceeding of the 1996 IEEE Symposium on Security and Privacy, 6 to 8 May 1996, pages 190 to 200, are indicated and describe flaws in the Hot Java and Netscape browsers that compromise security.

Summary of the invention

With a view to solving the aforementioned problem, the present invention provides a method for protecting data downloaded from a server computer to a client computer, said procedure comprising:

ES 2 178 174 T3 download a protected copy of the requested data from the server to a client and run a program on the client to: (a) unprotect the downloaded data to thereby provide access to an unprotected copy of the requested data and (b) suppress the copying functions of the client's computer in relation to the unprotected copy of the requested data.

Preferably, the protected copy of the requested data is cryptographically protected. Data can be cryptographically protected by encryption or by an integrity check procedure such as hashing.

More specifically, the procedure following the present invention may include: downloading a program on the client and executing the downloaded program on the client and sending a request to the server to download a file containing the protected copy of the requested data.

The present invention has a particular, although not exclusive, application in the downloading of data through a network such as, for example, the World Wide Web, but it can also be applied to LANs, WANs and the distribution of data by means of storage to long term such as 3.5 ”floppy disk or CD-ROM based technology.

The method of the present invention can be used with a conventional browser.

The client can download from the server a message related to the web page that includes information about the object of the program, and can then send a request to the server regarding the message to retrieve the object of the program. The web page can be written in HTML code. The program object may comprise a Java applet, although the present invention contemplates the use of other program objects such as Active X or OLE.

As a consequence of the processing of a Java applet, the usual copy and storage functions will not be presented to the user and thus security is provided for the unprotected data presented to the user.

The data presented may comprise text, graphics, images, audio, or any other suitable type of data.

The object of the program may include data relating to a cryptographic key, which can then be used to convert the downloaded cryptographically protected data into unprotected data for presentation to the user.

An authentication procedure can be employed to ensure that cryptographically protected data is only downloaded to an authenticated client. The authentication procedure can be carried out in connection with a payment system, to allow the collection of copyrights corresponding to the cryptographically protected data downloaded.

As will be understood, copy protection systems will never be completely satisfactory, because by making data available to users there is always the possibility that they will copy them. However, according to the present invention, the difficulty involved in violating the security system provided by the inventive procedure will induce users to pay the amount that allows the use of the protected data, thus reducing the risk that the owner poses. of the data provide the data through the World Wide Web or other open access networks.

The downloaded data may be steganographically marked with a digital watermark, for example. When the identity of the customer is known, it can be included in the watermark to provide more security against fraudulent copies.

Also, the present invention includes a server configured to carry out the inventive procedure.

They will follow a particular form of implementation, a procedure to download encrypted data from a server to a client comprises: registering the client on the server determining the identifier

ES 2 178 174 T3 of the client's machine by analyzing its hardware or software configuration, transmitting the machine identifier to the server, combine the transmitted machine identifier with a cryptographic key to create a unique determiner for the client and transmit the unique determiner to the client for storage and later use in identifying the client to the server to allow the download of encrypted data from the client to the server, then identify the client to the server based on the unique determiner and, finally, download the encrypted data using the cryptographic key to the identified client for decryption using the unique determiner key.

The downloaded data can be decrypted by the client using the unique determiner key.

The client can be identified to the server by determining again the machine identifier for the client, comparing it with the machine identifier included in said unique determiner and communicating it to the server based on the result of the comparison.

The server can test the client to authenticate it before downloading the encrypted data, generating a response as the default cryptographic function of the cryptographic key for the client that owns the server and as the function of the key included in the unique determiner stored in the client. and based on the result of the comparison.

Brief description of the drawings

To facilitate the understanding of the present invention, an example is described below in relation to the attached drawings, in which:

Figure 1 is a schematic illustration of a conventional client and a server connected through the World Wide Web, Figure 2 is a schematic illustration of a conventional screen provided by a Web browser to the client 3, Figure 3 is an illustration schematic of the Web server 1 connected to a client 3 through the World Wide Web 2, following the present invention, Figure 4 is a schematic illustration of the screen of a web browser following the present invention,

Figure 5 is a schematic illustration of the data flows between the client and the server following an example of the present invention,

Figure 6 is a schematic flow diagram associated with step S10 of Figure 5,

Figure 7 is a schematic illustration of the BT (BTC) copyright file structure,

Figure 8 is a flow chart showing in detail the actions carried out during the wrapping step 10.5 of Figure 6,

Figure 9 is a schematic flow diagram associated with step S12 of Figure 5,

Figure 10 is a schematic illustration of the data flows associated with a procedure to register a client in the server and

Figure 11 is a schematic illustration of the authentication, which takes place after the registration, according to Figure 10, corresponding to step S9 of Figure 5.

Detailed description

Next, an example of the present invention will be described in relation to the World Wide Web (WWW). As is well known, the information pages of a Web server are identified by an individual URL, allowing a browser running on a client's computer to

ES 2 178 174 T3 access them. Referring to Figure 1, a Web server 1 is connected via the World Wide Web 2 to a customer's computer in the form of a PC 3. The HTML web pages can be downloaded to the customer's computer 3 from the Web server 1 to be presented to the user of the client's computer 3. The HTML document can include links to other HTML pages of the same Web server or a different one, in a way that is well known. Also, HTML web pages can include embedded objects such as graphics, images, and the like.

The client 3 runs a browser that receives the HTML documents from the web server 1 and presents them on the computer screen. In this example, the browser is Java capable, that is, it can interpret Java byte codes received from the server. In particular, as is known in the art, when the HTML document includes one of the so-called Java applet tags, the server downloads a corresponding applet, consisting of Java byte codes, which are interpreted and executed by the browser. Usually, the downloaded Java applet allows interactivity between the user of the computer 3 and the displayed image. For more information, see Chapter 18 of the HTML 3.2 and CGI Unleashed ^ document, cited above.

In Figure 2, an example of the on-screen presentation of an HTML web page is shown. The on-screen presentation is displayed in a window 4 provided by the browser. Microsoft Internet Explorer 3.1 and Netscape Navigator are examples of suitable browsers. The browser includes a series of conventional controls that are activated by clicking the mouse, in the usual way. For example, the browser includes a print button 5 that allows printing the complete page shown inside the browser window 4. Likewise, the browser includes a control, shown schematically in 6, with the drop-down menu option raver origin ^, which allows you to provide a screen of the specific HTML code that is being executed.

Within the browser window 4, a page 7 is displayed, defined by a sequence of lines of HTML code indicating the text and layout provided on the page. Also, the code indicates areas that receive graphic image data or other data that is downloaded in separate files that have a predetermined label. In this example, a graphics file is presented with the tag HTML code determines that the gif file appears in the predefined area of ​​the page. Therefore, on page 7, the gif file is presented in zone 8 defined by the downloaded HTML code. Below is a code example for the gif file, indicated as Code Extract # 1.

Code extract n ° 1

CE1.1 <HTML>

CE1.2

CE1.3 <HEAD> <TITLE> Company X's Homepage </TITLE> </HEAD> CE1.4

CE1.5 <BODY>

CE1.6 Welcome to Company X's Homepage CE1.7

CE1.8 <IMG ALIGN = middle SCR = "a_graphic.gif"> <P>

<td colspan="2">CE1.9</td>

<td>CE1.10</td><td>&lt;A HREF=\another.html"&gt; link to another web page &lt;/A&gt;</td>

<td>CE1.11</td><td>&lt;/BODY&gt;</td>

<td>CE1.12</td><td></td>

<td>CE1.13</td><td>&lt;/HTML&gt;</td>

If the user presses the right mouse button on the computer in the area of ​​the displayed image 8, a drop-down menu 9 appears that provides the user with options including the option C will save to save the digital data corresponding to the gif file on the disk. computer hard drive or some other storage location, and also the ráiiiipriiiiirPP option for printing with a printer connected to the computer 3 (not shown). Therefore, the user of the computer 3 can make a copy of the digital data comprising the graphics displayed in the zone 8 and these can be sent without restrictions to other locations. Because the data is recorded in digital form, it can be reproduced many times without degrading the image quality.

In addition, the entire page 7, including graph 8, can be printed using the print button on the

EN 2 178 174 T3 browser 5. However, the quality of the printed image will be, in the best of cases, that presented on the computer screen. The printed image belongs to the analog domain and therefore all the procedures that move the image to the digital domain further reduce the quality.

The HTML page presented 7 also includes a sensitive area 10. When the mouse of the computer is pressed in the sensitive area, a link is established with another web page that is then presented in window 4. The HTML code associated with the sensitive area 10 It includes a URL to establish the link with another web page in a way that is well known per se.

As is well known in the art, the HTML code can also include a Java applet that consists of a programming object that is downloaded from server 1 and that can be executed locally in browser 4. In HTML, the applets are indicated using a code tag applet as described below. When the browser's HTML interpreter finds such a tag on a web page, it returns to the web server, which then downloads Java byte codes to the browser. Typically, applets are used to display animated graphical symbols on a web page, although many other applications, well known to those of ordinary skill in the art, can be provided. The location and presentation size of the applet are determined by the instructions in the lines of the HTML code.

If the user clicks the right mouse button on the data presented after executing the applet, no drop-down menu is provided corresponding to menu 9 shown in Figure 2. The user can use the origin button ^ 6 to view the lines code that make up the HTML page that is rendered, but this does not reveal the data that is rendered when the browser executes the applet. When you run an applet, the Java interpreter can present gif files within the applet, although gif files are normally downloaded directly to the web page, as they generally do not need to be processed on the basis of Java byte codes.

The present invention provides a method whereby data can be safely downloaded from the website and cannot be saved or copied while being displayed, without committing significant fraudulent actions.

Next, an example of a download procedure following the present invention will be described in greater detail, in relation to Figures 3, 4 and 5. In this example, a web page containing image data protected by copyright is downloaded. from server 1 to client computer 3 via the World Wide Web 2. The resulting screen display in browser 4 is shown in Figure 4 and the processing steps are shown in greater detail in Figure 5.

In step S1, the client 3 requests the server 1 for information about a web page. The petition comprises a petition for a conventional Hypertext Transfer Protocol (HTPP) page. Then in step S2, the server obtains the page or creates it instantly and downloads the HTML code corresponding to the page on the client 3 through the World Wide Web (WWW) 2. Usually, the HTML code includes references to images, graphics and sound bytes and the like and, in response to these codes, the server sends HTTP requests for the presentation of the corresponding files on the web page. For example, in relation to the web page 7 shown in Figure 4, the code includes a graphic image 11 constituted by a gif file. To obtain the data for the screen display 11, an HTTP request is sent to the server in step S3, and the corresponding binary graphic data is downloaded in step S4. These data are presented below in zone 11 on page 7 shown in Figure 4. However, these data are not protected by any copyright, since the user can save and copy them through the right button of the mouse as indicated above in relation to Figure 2.

However, according to the present invention, zone 12 of the presented page 7 is protected by copyright. The HTML code associated with page 7 of Figure 4 is shown in Code Excerpt # 2 provided below, and refers to applet A1 of line CE2.8.

IS 2 178 174 T3

Code extract n ° 2

CE2.1 <HTML>

CE2.2

CE2.3 <HEAD> <TITLE> Main page of Company X </ TITLE> </HEAD> CE2.4

CE2.5 <BODY>

CE2.6 Welcome to the homepage of Company X with additional CE2.7 copyright protection

CE2.8 <APPLET CODE = BTCBrowserApplet.class WIDTH = 200 HEIGHT = 150>

CE2.9 <PARAM NAME = VALUE file = “a_graphic.gif”>

CE2.10 </APPLET>

CE2.11 <IMG SRC = "another_graphic.gif"> <P>

CE2.12

CE2.13 <A HREF=$another.html"> link to another web page </A>

CE2.14 </BODY>

CE2.15

CE2.16 </HTML>

The Java byte codes to run the applet are downloaded from server 1 to client 3 in step S6 of Figure 5. Applet A1 is then run on the client, using the browser's Java interpreter, to prepare for the browser to receive the data to be presented in zone 12 of the web page, downloaded from the server.

The data to be displayed in zone 12 is cryptographically protected and therefore cannot be easily decrypted by controlling the downloaded signals. In this example, cryptographic protection includes encryption of downloaded data along with hashing, as discussed in more detail later.

The A1 applet allows you to decrypt the downloaded file and check its integrity, that is, to check if it has been subjected to hashing. More specifically, applet A1 includes the following: a hash algorithm HA, a hash master key KMH, an encryption algorithm EA, an encryption key K_AND and a BTC file request. The term BTC used here refers to a file of copyrighted data for viewing in the browser.

The applet A1 is executed, in step S7, on the client computer 3 and in step S8, the applet determines the sending of a BTC file request to the server 1.

In step S9, the server carries out an authentication step to determine whether it is safe to download the requested BTC file on the client. Authentication can be done in a number of ways. For example, the server may not download the file until the customer has paid the BTC file copyright fee charged by the owner of the file for viewing the file. In our co-pending patent application No. EP-A-0 941 524 entitled Transaction System, a micro-payment system for this purpose is described. Alternatively, the server can learn about the customer 3 in relation to some other service provided, such as an Internet home sales system, and the customer's credentials can be authenticated by procedures already used for the service.

Assuming that the client 3 passes the authentication stage S9, in the stage S10 the server prepares the BTC file to download it to the client 3.

In Figure 6, step S10 is shown in greater detail. In step S10.1, the relevant data is obtained, which may comprise graphics data, audio, video, text or data of another suitable format.

In step S10.2, a watermark is placed on the data. This may include changing some of the bits of the data stream to record a series that is imperceptible in the image displayed by the browser 4, when the data is downloaded to the client. Watermarking is a well-known example of the technique called steganography. In the document ^ Disappearing Cryplographyrá de P. Wayner, Academic Press, 1996 (ISBN 0-12-738671-8), a general analysis of this

ES 2 178 174 T3 technical and digital watermarks. Watermarks provide additional security in case of copying protected data, since information about the origin of the copy can be obtained from the watermark. Therefore, if in the authentication step (step S9) the server obtains a particular identity for the client, in step S10.2, a watermark can be included in the data to mark the identity.

In step S10.3, the watermarked data is sliced ​​on the server, using a copy of the HA hash algorithm that has been downloaded to the A1 applet and a session hash key K_SH specifies for the file. The hashing procedure consists of using the HA algorithm and the KSH key, together with the data bits of the encrypted data, to create additional HV bits, as parity bits, which are added to the data string. Hashing ensures that data sections are not removed or replaced by others (for example, that the rápay US $ 1 rá (rápague 1USDrá) command is not changed to the rápay US $ 100rá (rápay 100 USDrá) command. A suitable shape hashing algorithm is the SHA which is described in more detail in the National Institute of Standards and Technology, Federal Information Processing Standards Publication 180-1 (NIST FIPS PUB 180-1) SECURE HASH STANIARI.

In step S10.4, the data is encrypted in the server 1, by means of a copy of the algorithm EA and the key KE that has been previously downloaded to the client, in the Java byte codes of the applet A1. The IES algorithm is provided as an example of an encryption algorithm in the National Institute of Standards and Technology, Federal Information Processing Standards Publication 46-2 (NIST FIPS PUB 48-2) IATA ENCRYPTION STANIARI (IES). The AE encryption algorithm actually consists of a pair of algorithms, one of which is used for encryption and the other for decryption. As will be understood, the key KE is periodically changed, this being the way of proceeding that is considered correct within the technique.

In step S10.5, the resulting file is wrapped in a proprietary BTC file format which in turn includes additional cryptographic protection techniques.

The proprietary BTC file format is shown in Figure 7. The BTC file format comprises H header information and an embedded EF file. Processing carried out at stage

S10.6 is shown in greater detail in Figure 8.

The BTC file is created in the manner indicated in step S10.5. In step 10.5.1, partial information is generated for the H header, comprising a version number for the file format and any specific CI copyright protection control information for the file.

In step S10.5.2, the integrity of all this information is protected by generating a hash value HVhead by means of a hash key HKhead.

In step S10.5.3, the hash key used in the HKhead header and the generated hash value HVhead are added to the H header to complete it.

In step S110.5.4 the encrypted watermarked file generated in step S10.4 is added to the header H to become part of the embedded EF file of Figure 7.

In step S10.5.5, the information describing the hashing performed in step S10.3 is added to the EF file. This information comprises the specific hash key for the KSH session used in the embedded file, hereinafter referred to as HKembedded, and the HV hash value generated in step S10.3, which hereafter shall be referred to as HVembedded. The BTC file will be complete.

In step S11 (Figure 5) the BTC file is downloaded to client 3.

Next, in step S12, the BTC file is processed by the applet A1 that has been previously downloaded to the client 3. The processing carried out in step S12 is shown in greater detail in Figure 9. In steps S12 .1 and S12.2, the integrity of the content of the H. In step S12.1, the HVhead hash value of the header is generated by the HA hash algorithm and the hash key used in the HKhead header (retrieved from the H header of the BTC file). In step S12.2, this value is checked against the HVhead hash value retrieved from the H header of the BTC file.

If the result of the check is not satisfactory, an error message is displayed in zone 12

ES 2 178 174 T3 (Figure 4) of the browser window 4, in step S12.3. However, if the integrity check is successful, the applet A1 checks in step S12.4 if it knows how to process files of the type indicated in the version number retrieved from header 1 of Figure 7. If the result of the check is unsatisfactory, an error notice is displayed in zone 12 (Figure 4) of browser window 4, in step S12.9. However, if the check is successful, applet A1 can use the specific copyright protection control information CI for the file (found in header H of Figure 7) when processing data manipulation requests. of the users.

In step S12.5, the embedded file EF is decrypted by the encryption algorithm EA and the key KE previously downloaded in applet A1.

In steps S12.6 and S12.7, the integrity of the content of the decrypted file is checked as described below. In step S12.6, the hash value HVembedded is generated by the hash algorithm HA and the hash key used in the embedded file (retrieved from the embedded file EF in the BTC file). In step S12.7, this value is checked against the HVembedded hash value retrieved from the EF file embedded in the BTC file.

If the result of the check is not satisfactory, an error message is displayed in zone 12 (Figure 4) of the browser window 4, in step S12.3. However, if the integrity check is successful, the applet A1 can display the contents of the decrypted file in the area 12 (Figure 4) of the browser window 4, in step S12.8.

Therefore, if the BTC file contains image data, the image is displayed, along with its imperceptible watermark, in area 12 of web page 7 shown in Figure 4. The user cannot save or copy the data. of image. Because the Java-capable browser runs an applet for zone 12 image data, the right mouse button functions are disabled for zone 12. Therefore, if the user clicks the right mouse button, no menu option is automatically provided to save, copy or print the data presented in zone 12. The right mouse button functions are disabled according to Java operation. usual for applets described above. The user will be able to use the print button 5 of the browser 4, but will only obtain a low quality image and will not be able to retrieve the digital data comprising the image 12 in order to provide a high quality copy.

Also, if the downloaded BTC file is hidden in the browser, it will be hidden in its cryptographically protected form so that when copies of the hidden file are made, the downloaded data in the BTC file cannot be accessed, unless the user undertakes a considerable amount. of fraudulent actions to violate the code.

It will be understood that no copyright protection system can be completely satisfactory, since the presentation of a copyrighted document to users provides the opportunity to copy it. The purpose of this system, however, is to make a small payment in relation to the copyrighted document that is more attractive than the effort to violate the protection regime provided by the present invention. An analogy can be made with copying pages of a book using a photocopier. In theory, it will be possible to photocopy all the pages of a book, however, in practice this is very impractical and it will probably be easier to buy another copy of the book. Similarly, in the described example of the present invention, it is easier to pay to view the copyrighted document than it is to spend time violating the copyright protection system.

Many modifications and variations of this system are possible. For example, the execution of applet A1 can be modified following the downloaded copyright control information CI to provide a limited set of functions by pressing the right mouse button in screen area 12. For example, clicking the mouse's right button in screen area 12 may optionally provide a drop-down menu that offers the user a copyright notice with information about the copyright owner of the displayed image.

Likewise, the menu may offer an option to save the document in an unprotected format after paying an additional fee higher than the one paid to initially view the image.

Regarding the applet A1 downloaded in step S6 of Figure 5, it may not be necessary to include the encryption and hash algorithms EA and HA for each download operation. It is preferable,

ES 2 178 174 T3 although not essential, keep the algorithms secret so that they can be preloaded on the client's computer and saved on the hard disk in a data file.

If the server 1 knows the identity of the client 3, at the time of requesting the applet A1, individual hash and encryption keys can be downloaded into the Java byte codes, in step S6. The embedded EF file of Figure 7 can be encrypted and hashed by the individual keys, specific to customer 3, when the file is prepared for download in step S10. The use of individual keys, specific to the client 3, improves security.

Next, an example of how an individual key can be provided will be described, in relation to Figures 10 and 11. Figure 10 illustrates an initial registration procedure by which information from client 3 is disclosed to Web server 1 In step R1, client 3 contacts Web server 1 with a registration request for the copyright protection system. The web server 1, in stage R2, provides the client with a program that is here called the identity plate #. The identity plate is usually provided on a compact optical disk (CD), perhaps in combination with other software, eg for internet purchases or a micro-payment system. By sending the CD by means of a postal service to a specific address, a reasonable assurance could be had that the client machine that executes the identity plate corresponds to the user who requested it. The CD may also include EA and HA hashing and encryption algorithms that can be preloaded on the customer's hard drive.

In step R3, the badge program is executed to provide a machine identification code (MID) that provides a basically unique identification of the customer. The badge program scans the customer's computer for hardware and software. Here are examples of client characteristics that can be used to create the MID:

The physical components of the computer (memory size, presence of CD drive)

Characteristics of the phosphor components (manufacturer, number of tracks of the hard disk)

Location of status information on the hard drive (bad sectors)

Location of long-term files on the hard disk (operating system executables) Operating characteristics

Logical directory and file structures

Files created expressly to identify the machine

Data added to long-term files to identify the machine

Application settings and operating system

Hardware identification number, eg hard disk.

For added security, the identity plate can only be run once for registration.

In stage R4, the MID is sent to the web server 1 via WWW 2. In stage R5, a cryptographic key KI is embedded along with the MID in the byte codes of the Java applet which is then downloaded in step R8 on client 3 and stored on your computer's hard drive in step R7. The individual key KI actually comprises a group of keys that are provided individually to each client 3 for use in the hashing and encryption described above.

In Figure 11, it is shown how the authentication step, which is step S9 of Figure 5, can be carried out after the registration procedure of Figure 10.

In step Q1, the badge program is used to generate a current MID which is compared, in step Q2, with the MID stored on the customer's hard disk in step R7, during the registration procedure. If the MIDs are equal, the current value of the MID is sent to the web server 1 in step Q3.

IS 2 178 174 T3

In step Q4, the web server 1 transmits a random number, RAND, to the client 3 for testing. Next, in step Q5, the client calculates the ANSWER as a cryptographic function of the MID, the RAND number and the individual stored cryptographic key KI.

In stage Q6, the ANSWER is sent to Web server 1 through WWW 2. While, in stage Q5, the Web server also generates a response, specifically ANSWER ', in the same way used to the client 3. In step Q7, the ANSWER is compared with the ANSWER 'and if they match, the authentication of the client will have been successful. In this situation, the BTC file can be downloaded, as shown in steps S10 and S11 of Figure 5, by individual customer-specific keys, to carry out encryption and hashing. The keys used can be session keys generated from key batches and a batch number.

Other forms of authentication may be used. For example, a smart card can be used in the same way as the SIM card used in GSM mobile phones, in combination with a SIM card reader connected to the client 3. This has the advantage that the identity of the user is monitored instead. of the identity of the client's computer and, in this way, the client can switch from one machine to another and continue using the service.

Referring again to Figure 3, the illustrated Web server 1 has different functional blocks 13, 14 and 15. Block 13 carries out the cryptographic processes associated with steps S10.3 and

S10.4 of Figure 6, block 14 performs the watermarking processes described in connection with step S10.2 and block 15 performs the other procedures. In some situations, it may be desirable to provide separate cryptographic servers and watermark servers so that keys and watermarks can be provided as separate services to several different web servers.

Although the described example of the present invention uses the Java programming language, it is understood that other hypermedia languages ​​can be used, such as Active X and OLE.

The registration and authentication procedure described in relation to Figures 10 and 11 can also be used in other authentication procedures in which the client is requested to register with a web server. Therefore, this procedure could be used in procedures that include other data transfer regimes between the client and the server, in which it is necessary to carry out registration and authentication.