/99 $10.00 (c) 1999 IEEE

Transcription

1 WWW Distribution of Private Information with Watermarking Patrick Dymond and Michael Jenkin Department of Computer Science, York University 4700 Keele St., North York, Ontario, Canada (416) Abstract This paper considers the use of browser plugins and Java code (within standard HTTP mechanisms) to serve private condential documents securely over the World Wide Web to a group of mobile or otherwise distributed users. Web security mechanisms typically require use of either an underlying security system for transport mechanism (e.g., SSL[7]) alternate servers and data streams (e.g., S-HTTP[9]), security-oriented plugins within the browser (e.g, [6]), or helper applications (e.g., [11]). The method described here operates by providing a per-user security mechanism coded in Java which operates as part of a standard web-browser environment. This system appears to be very appropriate for serving lower-security, non-public documents, les and images to a group of heterogeneous users over the world wide web. It can also be appropriate in circumstances where the standard security mechanisms are not available. We also describe an adaptation which provides automatic per-user \watermarking" of decoded pages to allow identication of the decoder. 1 Introduction For a group of authorized distributed users, and especially for mobile users seeking access to shared private data, the world wide web may be the most accessible communications channel available. However, existing world-wide web mechanisms are not well-suited for providing private documents to a limited set of authorized users, where some degree of condentiality or privacy is required. (See [5] for a general introduction to security and the web.) Several avenues to augment existing web technology with varying degrees of security 1 exist. These dierent mechanisms interact with the world wide web at dierent levels and provide varying levels of security and convenience for the users. Existing mechanisms include Network-level security. For example, the SSL (Secure Sockets Layer) proposed by Netscape [7] and PCT (Private Communication Technology) [2] proposed by Microsoft provide security at the transport layer and essentially encrypt the entire datastream at the network level. SSL and PCT provide mechanisms for authentication of clients and servers as well as providing data condentiality (encryption) and message authentication. Although this type of approach can potentially provide a high level of security the approach is not without its drawbacks. Perhaps the most of these is that the entire datastream must be encrypted. This can result in some reduction in transmission performance. This is discussed further below. HTTP-level security. For example, S- HTTP (Secure HTTP)[9] is an augmented version of HTTP with additional features to enable secure transmission. Unfortunately S-HTTP is not supported 1 Of course no mechanism can provide complete security, rather dierent mechanisms each provide dierent features and degrees of protection. 1

2 by Microsoft's or Netscape's standard browsers, and it would appear that this standard is not in wide use. Alternate suites of software (browsers, servers, etc.) to deal with encrypted data are required. HTTP server-based security. Many HTTP servers, including NCSA and Apache, provide access conguration les which allow the server site manager to associate usernames, passwords, and internet domain constraints on the users who may access the pages. These techniques do not provide secure transmission although they do provide limited security in terms of data access. One unfortunate problem with this type of security is that well-known attacks exist. For example [10] describes a bruteforce approach to obtaining the password to an access conguration le protected web page. CCI-based security. Browsers such as Netscape and Internet Explorer provide a standard mechanism to enable helper applications for the user's browser written using CCI (Common Client Interface) standards, to deal with novel MIME-types. [11] describes a system which uses PGP[4] to encrypt and transmit web pages which are then decrypted outside of the browser via a registered helper application. Although this type of approach can provide extremely strong cryptographic protection of the transmitted data, such systems are limited by the CCI (Common Client Interface) link. Either a separate display program must be made available to display the plaintext, or alternatively the plaintext must be made available to the browser for display. In either event, plaintext may be intercepted on the client machine. One other practical diculty with this type of approach is the need to support software versions of the security system for the various browsers and hardware/software platforms that exist. Within-browser security. Browsers such as Netscape and Internet Explorer provide a standard mechanism to enable addition of new plug-ins. These plug-ins extend the functionality ofthebrowser by providing code within the browser to deal with novel MIME types. [6] describes a prototype system for serving condential information using this technique. In this system the server provides an encrypted version of portions of the page to be served. When these sections are received by the authorized user's browser they are automatically decrypted and displayed within the browser. The system reported in [6] was implemented using a very straightforward cryptography system, but the approach is actually independent of the specic cryptography system used, and stronger cryptography mechanisms could be readily incorporated. As is the case with CCI-based systems, the within-browser approach requires plugins to be constructed and supported for dierent browsers and dierent hardware platforms. Unlike the CCI-based approach, the within-browser system does not require that the plaintext be available on the client except when displaying the data. Each of these dierent approaches provide dierent levels of security. SSL/S-HTTP provide very high levels of security in a relatively transparent manner. This level of security is justied for some transactions on the internet and the web, such as encoding nancial information, However, for private information requiring only a lower degree of security, or in cases where the above security systems are not readily available, it may be useful to adopt the approach considered here, of adding your own security features to existing web servers, using CCI and plugin mechanisms within the browsers. 2

3 1.1 Reasons to consider alternatives to SSL Although SSL is an eective standard and has been put to extensive use on the web for tasks such as credit card transactions where a single, powerful security standard is essential, it may nevertheless not be the most appropriate security mechanism in some other contexts. SSL encrypts the data stream at the socket layer. This permits potentially strong security { the entire data stream is protected. But all material, including material which does not need to be secure, is protected to the same level. It is not possible to selectively encrypt the stream or to choose dierent levels of security for dierent portions of the datastream. As encrypting/decrypting the datastream is not without cost, computational resources must be expended at the both the client and the server in order to process the data. In addition to computational costs SSL encryption leads to increased communication costs. Strong encryption tends to reduce the eectiveness of network compression schemes. Thus many modern communication systems which rely on compression to achieve throughput are disadvantaged. SSL and S-HTTP also require a web server willing to provide the service. (The web server must be either SSL or S-HTTP enabled.) This often requires that an information provider wishing to provide secure data must manage their own web server or to utilize a host which provides the appropriate secure mechanism. As this can be quite expensive, many commercial sites use one host for non-secure information and a smaller second secure host for secure transactions. This tends to complicate the design and maintenance of commercial web sites. 1.2 An alternative approach In [6], we described the design of a system which allows an information provider wanting to serve secret material over the web to do so via embedding encoded material within regular web pages. On the server, the embedded material is stored encrypted using a global password, and identied in HTML as being of a special MIME type, (which signals any authorized browser to use a privacy plugin provided for that MIME type to decrypt and display the material.) Using the single global password, authorized users fetch the provided pages and decrypt the embedded material using the privacy plugin. The detailed implementation of this mechanism is briey summarized below. In addition to the limitations described above concerning plugin-based security systems, the system described in [6] relied on a single global decryption password. This makes the global system open to attack, especially when the encrypted information is of a specic form. For example, in the implementation described in [6], the security plugin decrypted Macintosh PICT les. As these les have a standard format portions of the plaintext are known and this makes the encryption vulnerable to attack. In this paper we describe a similar system which provides an enhanced level of security while avoiding the practical problem of maintaining dierent implementations for different machines and architectures. Based upon the ideas introduced for CCI- and plugin-based systems, the system described here uses Java to provide a platform-independent decryption system. This Java-based security system provides security within the browser and hence avoids the potential security problems associated with transferring the plaintext outside of the browser, while requiring only a single version of the code be maintained. As Java code is used to render the decoded imagery or text, this approach also readily permits watermarking and content-specic data-compression to be performed. 2 Encryption via a Global Key This method (described in more detail in [6]) is intended to solve the problem of serving se- 3

4 The information provider generates pages with both plaintext HTML documents as well as encrypted les (secrets.) As the encryption is performed o-site, the ISP (Internet Service Provider) need not have access to the plaintext version of the material being served. Plaintext.pict Encryption process Encrypted.pict Plaintext.html Figure 1: Site setup http server cret information embedded within regular web pages (prepared by the information provider) in such a way that it can be readily obtained only by users in possession of the secret global key. The process of serving pages with encrypted embedded regions involves two main phases; (i) the setup of the site and distribution of keys to authorized users, and (ii) serving the encrypted pages to the authorized user community. The information provider (as opposed to the ISP) generates the les that make up the web site. This site may include both plaintext and encrypted material on the same HTML page (Figure 1). The encryption process uses any appropriate standard encryption algorithm. (Our demonstration implementation uses a public domain version of the Unix crypt command, but many other cryptographic techniques could be used instead.) This encryption process can take place anywhere, and in particular it can take place on a dierent machine than the HTTP server (ISP) machine. In this case plaintext versions of the encrypted les need never exist on the HTTP machine and thus the material is hidden from the server's machine. In the most straightforward implementation all of the encrypted les on the site are encrypted with the same global password. For simplicity imagine that the information to be served consists of private images contained on otherwise plaintext pages. The images are stored on the server only as encrypted crypto-pict les (where crypto-pict is a new MIME data-type). The information provider then distributes the global key to the authorized user community. In the system described in [6], each user augments their web browser (the sample implementation uses Netscape Navigator) with a plugin. This plugin allows for the transparent decryption of the encrypted images provided by the server. The user's browser is congured to recognize the new MIME-type of the encrypted images and to assign the interpretation of this type to the plugin. It is instructive to note that the approach described in [6] to decrypt and display the data oers a number of advantages over CCI or helper-application based approaches. The datastream never leaves the browser so the encrypted data is not open to straightforward attacks on the server or on the client. It is also possible to avoid the browser's normal caching mechanism by having the plugin acquire the datastream directly rather than relying on the browser's standard mechanisms for le transfer. (This avoids attacks based on obtaining a copy of the encrypted datastream from the copy maintained in the browser's cache.) A more recent implementation of the method in [6] uses a Java applet to decrypt and display the encrypted portions of pages rather than relying on the plugin mechanism. As Java applets are platform-independent and can be written to be browser-independent, a Java-based implementation oers a number of advantages over the plugin-based implementation described in [6]. Only a single version of the software needs to be written (the applet is platform and browser independent) and the applet interface mechanism is much more stable than the interface mechanism available 4

5 Client request_page(user,page) Process page Decrypt embedded security document request encrypted page Server validate user encrypt secure page components with users key Figure 2: Per-user encryption information ow to browser plugins. Finally, it is more dicult to formulate attacks on the plugin itself as the Java applet-based decrypter bytecode is loaded from the host machine directly rather than having to be installed by the user as is the case with the plugin-based implementation. 3 Individual (per-user) Keys An apparent limitation of the global key approach is that a single encryption key exists and loss of this key opens up the entire encrypted database to unauthorized use. In order to provide a higher level of security, but still to provide a level of security and complexity below that available and required with SSL and S-HTTP, we generalize the global key approach by assigning to each user their own decoding key and then augmenting the HTTP server through CGI (Common Gateway Interface) programs on the server. The information ow for this approach issketched in Figure 2. Requests for non-secret information to the server are processed in the normal fashion through the regular HTTP mechanism. Requests for pages with encrypted material can best be described by an example. Figure 3 shows the HTML source for a page within which a secret (encrypted) image is placed. The page is stored as plaintext on the server. The browser obtains the page through the normal HTTP mechanism and then displays the <HTML> <HEAD> <TITLE>Crypter</TITLE> </HEAD> <BODY> <script Language="JavaScript"> document.writeln("<h1> Sample document with encrypted component</h1>"); document.writeln("the following image must be decrypted"); document.writeln("<hr>"); document.writeln("<applet archive=\"decoder.jar\" code=\"decoder.class\" width=200 height=100>"); document.writeln("<param name=image value=\"encrypted.gif\">"); document.writeln("<param name=userid value=\"" + prompt("enter user name") + "\">"); document.writeln("<param name=decoder value=\"" + prompt("enter decoder key") + "\">"); document.writeln("</applet>"); document.writeln("<hr>"); </script> </body> </html> Figure 3: Sample HTML code to interface the Java decrypter with the server page. The page itself contains JavaScript segments which generate HTML source which are customized to contain the user's name and decryption key. In the example presented here the user is prompted for this information at run time, but more sophisticated methods for storing this information at the client are possible including mechanisms such as Cookies and other persistent browser objects. The generated page contains a Java applet which is passed as parameters the user's name and decryption key. The Decoder applet is passed sucient information (the image and userid) to be able to construct a HTTP request for the appropriate encoded document. This request is formulated as a CGI request to the server. The CGI program will receive as arguments su- 5

6 cient user identication information (userid) to encrypt the document for the specic user along with the name of the document (image) to be served. The CGI application veries the user name and determines the user's encryption key. The document to be encoded is then encrypted with the per-user key and the encrypted document transmitted to the Java applet. The sensitive information is then decrypted and displayed by the Java applet using the method described above. As is the case in the CCI-based system described in [11], one mechanism for having the client communicate the user's name to the server is to use a public-key system such as PGP. In this case, along with an optional user name, the client may provide the public encryption key for this user. Indeed it would be possible to use a dierent public encryption key (and corresponding private decryption key) for each encrypted document to be transmitted to the client. The secret information can also be maintained in an encrypted form on the server. As requests are received the data would be rst decoded by the CGI application (using the local server decryption key) and then re-encoded with the user's key. An alternative would be not to decrypt the version of the document stored on the server, but rather to encrypt the already-encrypted version of the document for a second time and then to transmit the result. In this case the plaintext version of the document would not necessarily exist on the server's machine. The user would be responsible for doubly decrypting the document; once with the user's key and once with the global decryption key. The advantage in not maintaining a plaintext version of the database on the server is that the plaintext documents are not available for perusal even by attackers with privileged access to the client machine. As in the case with the global key approach, we do not consider here the task of key distribution and assume that this is dealt with through some alternative, secure communications stream. For each user an encryption key known to the server and decryption key known to the user must be held. It is easy to see that this system is compatible with various publickey crypto-systems such as PGP (where the user encryption key can be a user's public key) as well as private-key approaches such as the Unix Crypt command. In the case that key distribution can take place oine, i.e. through a medium other than the World Wide Web, unencoded secret information need not appear anywhere except within the decoder plugin on the user's machine. 4 Watermarking No matter how secure the system for the transmission of data is, there is always the possibility that the data will be obtained fraudulently. In order to aid in later prosecution or to assist in determining where the security breach has occurred, it is important that the decoded document be marked with information identifying the decoder, so that it can be traced back should it be later discovered in unauthorized hands. (Clearly such watermarking could include other information available to the decrypting mechanism including the date of the decryption.) As each user has a unique decrypting key, and as the Java applet has control of the decrypting and rendering process, a straightforward technique would be to have the applet mark the rendered material in a way that uniquely identies the user who decrypted the document. If this mark is suciently well hidden and robust, then a user who copies the document will also copy information sucient to identify themselves as source of the security breach. Various techniques exit for watermarking an image so that it can be later identied. (See [1] and [3] for specic technique and [8] for an analysis of dierent attacks on watermarking techniques.) The most eective of these watermarking techniques involve per- 6

7 muting the base image in such a way that even a small portion of a watermarked version of the image can be used to identify the watermark. Watermarking can be added to the decryption system in one of two ways, either at the browser-level or at the level of the CGI. Browser-based watermarking It is straightforward for the Java applet to employ one of a number of dierent watermarking strategies to uniquely mark the image. The only added complexity is that the Java drawing model does not provide ne control over the displayed colours within the applet. Thus watermarking strategies based on using the colourmap to encode the mark are not applicable. That being said, systems such as [1] can be easily adapted to the Java applet environment. CGI-based watermarking Rather than providing watermarking within the browser, the CGI-mechanism can be used to watermark the material before encrypting the material for transfer to the browser. As the CGI-based approach provides the watermarking on the server, more sophisticated, and hence computationally expensive, watermarking algorithms can be utilized. Watermarking at the CGI-level also ensures that the watermarking process cannot be defeated by an attack on the Java-based decryption process. One drawback with the CGI-based watermarking approach, however, is that it places an extra computational load on the server. 5 Discussion This paper describes a Java applet-based privacy scheme for le distribution on the world-wide web. This mechanism provides for the encryption of data within a web page and for decryption of this information within the user's browser. Each user is assigned a unique decoding key, and pages are encrypted via a CGI program executing on the server. The mechanism requires little modication to a standard web browser or HTTP server. The browser is augmented through the addition of a decoding Java-applet, and the server is augmented through the addition of a simple CGI program which encrypts requested secrets with the appropriate encoding key. As the encryption process takes place on the server on a per-user basis, it is possible to assign dierent encryption algorithms to dierent users, and even to the same user for different materials or at dierent times, although the negotiation process for the preferred encryption algorithm must be quite simple given the limited communication that takes place between the client and server. One mechanism would be to have the client and server agree an the mechanism at the time of key transfer. Note that SSL and S-HTTP provide much more sophisticated negotiation strategies for encryption algorithm negotiation. Another potential extension over the globalkey approach involves the watermarking process. In [6] watermarking is performed at the client level within the plugin. As the encryption process here takes place on the server, it would be possible to perform the watermarking here as well. This provides a greater range of watermarking strategies as (i) the code to perform the watermarking does not have tot within the memory limits of the browser/client, and (ii) the watermarking code is not distributed to users via distribution of the plugin. Although the per-user key process discussed here provides somewhat more security than a single global key, it does requires more overhead and is not without cost. The service provider must permit the execution of CGI programs; and unless some kind of double encryption technique is used, (e.g. where the secret information to be served is stored in an encrypted format and then decrypted before encrypting with the user's encoding key) plaintext versions of the documents would be visible 7

8 to the service provider. The main execution-time cost incurred on the server running the CGI script is due to the use of the encryption function. This cost depends on the complexity of the encryption function used. For example the Unix crypt algorithm, for which public-domain implementations are available, can be implemented very eciently to run as a CGI program. On the client machine, the main additional cost (over that of a regular web page access) is for decryption. Because simpler decryption algorithms may be selected, and only some parts of the the datastream may require decryption, this approach can compare favourably with methods using full datastream encryption, such as SSL. Acknowledgments The authors acknowledge the nancial support of NSERC Canada. References [1] I. J. Cox, J. Kilian, T. Leighton, and T. Shamoon. Secure spread spectrum watermarking for multimedia. Technical report, NEC Research Institute, Technical Report [5] S. Garnkel and G. Spaord. Web Security & Commerce. O'Reilly & Associates, Inc., Cambridge, MA, [6] M. Jenkin and P. W. Dymond. A pluginbased privacy scheme for world-wide-web le distribution. In HICCS-97, Hawaii, [7] Netscape Inc. Secure sockets layer. /assist/security /index.html, [8] F. A. Petitcolas, R. J. Anderson, and M. G. Kuhn. Attacks on copyright marking systems. In Proc. 2nd Workshop on information hiding, Portland, Oregon, [9] E. Rescorla and A. Schiman. The secure hypertext transfer protocol. Internet-draft draft-ietf-wts-shttp.01.txt, [10] \Ryan". defeating. http. access. control. edu. 2600: The Hacker Querterly, pages 40{43, [11] J. D. Weeks, A. Cain, and B. Sanderson. Cci-based web security: a design using pgp. In World-wide Web Journal: The 4th Int. Word Wide Web conference. O'Reilly and Associates Inc., [2] J. Benaloh et al.. Private communication technology protocol. http: // /windows/ ie/ pct.htm, [3] J. Fridrich, A. C. Baldoza, and R. Simard. Robust digital watermakring based on key-dependent basis functions. In Proc. 2nd Workshop on information hiding, Portland, Oregon, [4] S. Garnkel. PGP: Pretty Good Privacy. O'Reilly & Associates, Inc., Cambridge, MA,