Towards Secure Sealing of Privacy Policies

^*Kostas MOULINOS¹, John ILIADIS², Vassilis TSOUMAS³

¹Hellenic Data Protection Authority, 8 Omirou st, Athens, GR-10463, Greece
Tel: +30-10-3352628, Fax: +30-10-3352617, E-mail: kostas@dpa.gr

²Department of Information & Communication Systems Engineering, University of the Aegean
Research Unit, 30 Voulgaroktonou St., Athens GR-11472, Greece
Tel: +30-10-6492112, Fax: +30-10-6492299, Email: jiliad@aegean.gr

³Dept. of Informatics, Athens University of Economics and Business
76 Patission St., Athens GR-10434, Greece, e-mail: bts@aueb.gr

Abstract A common practice among companies with an online presence is to sign on to a "seal" programme in order to provide customers with a sense of security regarding the protection of their personal data. Companies must adhere to a set of rules, forming a privacy protection policy designed by the seal issuer in accordance to underlying laws, regulatory frameworks and related best practice. Some of the most widely used seal programmes are TRUSTe, BBOnline, WebTrust and BetterWeb. Using the functionality they offer a user can verify online that a specific organisation adheres to a published privacy policy. In this paper, we argue that the verifications means these programmes use are vulnerable to DNS spoofing attacks. Furthermore, we present a privacy policy verification ("seal") scheme, which is not vulnerable to the aforementioned attack. We also argue that there are disadvantages in operating seal schemes that attempt to publicly certify compliance levels with a self-regulatory privacy protection model. On the contrary, these disadvantages are softened when used in a regulatory model that has adopted comprehensive laws to ensure privacy protection.

Keywords Security, Electronic Commerce, Trusted Third Party (TTP), Public Key Infrastructure (PKI), Digital Seal, Privacy, Data Protection Authorities.

1.Introduction

One of the major concerns of Internet users today is the privacy of personal data they release every time they visit a website. To help users trust websites, companies with an online presence started announcing their privacy practices. These practices make use of sets of rules governing the organizational policy regarding personal data protection. These rules are documented in a statement, which is called privacy policy.

The percentage of web sites that currently include statements about their privacy and personal data practices is growing. Various privacy bodies (such as TRUSTe, BBOnline, WebTrust and BetterWeb) and trade associations (such as the Online Privacy Alliance and the American Electronics Association) promote appropriate disclosure practices and common standards for privacy protection.

There are three different ways to inform visitors about what (if any) personal data is being collected and how it will be used [OECD99]:

1. Posted privacy policies: the privacy policy is declared via a specific web page,

2. the terms and conditions of online agreements: the privacy policy is included in the terms and conditions of online agreements which apply between the site and its visitors,

3. digital labelling: The basic idea is that a uniform “vocabulary” for web site information practices, developed by a particular online community or organisation, can be used to describe the practices of individual sites.

P3P is the most widely known standard for digital labelling. P3P supports interactions involving HTTP; it lets users specify their own privacy preferences and allows websites to express in a simple way their privacy practices on the collection and use of personal data. One special instance of digital labelling is the digital seal programmes. Privacy bodies and trade associations develop their own privacy protection rules and issue digital seals to companies committed to adhere to the specified rules.

The efficiency and acceptance of digital seals, depends on a number of reasons, including the security of the underlying technology, the brand name of the digital seal issuer and last but not least, the legal framework surrounding online privacy. On a legal level, the most widely accepted privacy protection models are [EPIC01]:

1. Comprehensive laws: privacy aspects are regulated based on a general law that governs the collection, use and dissemination of personal data both by the public and private sector,

2. self-regulation: companies and industry establish codes of practice and engage in self policing.

Well known digital seal programmes such as TRUSTe, BBOnline, WebTrust and BetterWeb are operating under a self regulatory privacy regime. Many problems of seal programmes operating in such a regime have been found [FORRE99]. In this paper we argue that these programmes are vulnerable to specific spoofing and masquerading attacks. Furthermore, we propose a novel digital seal technological solution (SSPP – Secure Sealing of Privacy Policies) that is resistant to the aforementioned attacks. Our solution is based on digital certificates and it is suitable to operate in an environment where comprehensive laws regarding privacy protection exist.

This paper is organized as follows: In section 2 we present the role of privacy policies in transactions between users and organizations and an outline of the existing mechanisms for online validation of these policies. In section 3 we present in detail the mechanism we propose for validating online privacy policies and we also present the framework within which our mechanism should be operated. In section 4 we evaluate our mechanism against security requirements such a mechanism should meet, and we provide also a comparative evaluation with other, similar mechanisms. Finally, in section 5 we present our concluding remarks.

2.Privacy Policies and Online Verification

An essential aspect of any privacy protection regime is oversight. In most countries with an omnibus data protection or privacy act there is also an official agency that oversees enforcement of the act. The powers of these officials vary widely by country. Under Article 28 of the European Union Data Protection Directive [EUDIR], every EU country must have an independent enforcement body.

2.1The Role of Privacy Policies

One of the most important obligations stemming from the international legislative framework regarding data controllers (i.e. the persons responsible for controlling the use of personal and sensitive data their organisation manages) is notifying the subjects when their personal data is being processed. The practice an organisation follows, as far as personal data is concerned, is called privacy policy and must be communicated to the public. In the Internet, a privacy policy can be communicated through the web pages of a site. A user usually decides on the level of trust he is going to put on an organization with an online presence, depending on the privacy policy this organization follows.

According to [OECD99] there are mechanisms an organisation can use in order to increase the level of trust users put on the organisation. These mechanisms are mostly supported by privacy seal bodies, which use digital seals as a technological means to offer an online verification that a specific organization follows an accredited privacy policy. Privacy seal bodies set forth the requirements to be met, for the organisation to be accredited.

The better seal programmes conduct monitoring and compliance checks, provide education information, offer consumer dispute resolution and enforce sanctions against errant companies. Privacy seal programmes present various disadvantages, when operating within a self-regulatory system. All too often seal program operators have been shown to be ineffective and reluctant to take enforcement measures against their membership. A Forrester research report [FORRE99] revealed that privacy seal bodies become more of a privacy advocate for the industry rather than for consumers, because they are financially dependent to the organisations they accredit.

2.2Online Mechanism for Verifying Privacy Policies

A user visiting an organisation's web site can verify that the organisation follows an accredited privacy policy, using a privacy seal verification scheme. The user clicks on an image ('the seal') that transfers him to the web pages of the respective privacy seal body. These pages report to the user that the web site he has been visiting belongs to an organisation that follows -or not- a specific, accredited privacy policy. The privacy seal body develops this policy. Even though this practice is widespread all over the US, it presents certain disadvantages:

1. Privacy seal bodies providing online statements on the accreditation of organisations’ privacy policies do not publicise the implementation details of their verification mechanism. This is –most probably– bad security practice. Security through obscurity belongs surely in the past. However, it seems that instances of its usage remain a problem of the present tense,

2. the existing mechanisms are vulnerable to attacks like DNS spoofing [DEVIV98] and masquerading,

3. the existing mechanisms do not (and could not, using the existing functionality) verify that the privacy policy published by an accredited organisation at their website, is the one that organisation has been accredited for,

4. privacy seal bodies most often operate in self regulating environments. The respective seal mechanisms have not been tested in environments where comprehensive laws for protecting personal data are in force.

To deal with the aforementioned restrictions, we consider that a privacy seal mechanism must meet the following requirements:

1. It must be open for scientists to review,

2. it must be suitable for operation within environments where comprehensive laws concerning personal data protection exist,

3. it must be resilient to security threats [CGGG98], [SKG99],

4. it must be able to provide proof that the policy residing at the web site is the one the respective organisation has been accredited for, by the authoritative body (i.e. Data Protection Authorities in environments that have adopted comprehensive laws).

2.3Existing Privacy Seal Verification Mechanisms

Existing privacy seal bodies, operating globally in the commercial arena, offer online mechanisms for customers to verify that an organisation follows an accredited privacy policy. These mechanisms (digital seals) look alike, more or less. We shall give a short description of the existing mechanisms, and point out their deficiencies.

The accreditation and seal registration procedure of these mechanisms encompasses five steps (Figure 2), if accreditation is successful, and three steps only if accreditation of the applying organisation is rejected. If the applying organisation is accredited, it receives a digital seal, which can be installed in its Web pages, enabling users visiting the site to confirm that the privacy seal body has accredited that organization, i.e. the organization follows an accredited privacy policy.

Figure 1: Accreditation and Seal Registration procedure

Users visiting an accredited site can click on the Digital Seal image it carries; this transfers them to web pages of the privacy seal body, asserting whether the organization they were visiting follows an accredited privacy policy or not. Accredited organizations are not required by Digital Seal issuers to use secure means, like SSL, for their web pages carrying a Digital Seal or for their customers to communicate personal data to them. Moreover, some the of privacy seal bodies do not use integrity protection mechanisms for their communication with users seeking online verification of the accreditation status of a specific organisation.

3.Secure Sealing of Privacy Policies – SSPP

3.1Operational Framework

We propose an alternative mechanism for users to validate the digital seals issued by privacy seal bodies to organisations with an online presence. We also claim that the role of privacy seal bodies must be undertaken by Data Protection Authorities (DPAs) in environments with comprehensive laws regarding personal data protection.

If private bodies undertake the role of privacy seal issuers, then a large number of different seal programmes, acronyms and underlying privacy policy content will emerge. This will lead to confusion of the public and to privacy policies that may or may not –depending on each case– provide an adequate protection layer for personal data. Private sector privacy seal bodies operating in environments that lack a solid legal personal data protection framework self develop or adopt sectoral laws regulating different sectoral activities, such as health, video rental records to name but a few examples from the commercial world. Truste, for example, offers a wide range of privacy policy seals ranging from safe harbor privacy seals to children's and e health programs. This could cause confusion to the general public On the contrary, if DPAs undertake that role -in environments with comprehensive laws- then there will only be one, uniform acceptable privacy policy content. DPAs, having performed an extensive audit of the organisation requesting accreditation, will be setting the policy requirements this organisation has to meet, in order to comply with the personal data protection requirements imposed by the comprehensive legal framework.

Furthermore, bodies offering privacy seal services must operate as trusted third parties towards the public. The public trusts these organisations because they do not -or rather, should not- engage in commercial transactions with the digital seal applicants. If the role of privacy seal issuance and privacy policy accreditation is undertaken by private, profit making bodies, then the trust public puts on them may be reduced. Private, profit making organisations cannot operate as third parties to this extent, because they are financially dependent to the digital seal applicants. Also, if there is no legislative framework controlling their operation, the public trust may become even more downgraded.

An essential aspect of a privacy protection regime is the sanctions imposed to violators. In self regulatory systems, these sanctions cannot be legally imposed. DPAs (operating in environments with comprehensive laws) can enforce such sanctions effectively

We consider for the rest of the paper that the role of privacy seal issuance and privacy policy accreditation is undertaken by DPAs, due to the reasons we have pointed out. We shall now present a mechanism DPAs can use in order to issue digital seals and let users validate a digital seal online. We shall be calling our mechanism Secure Sealing of Privacy Policies (SSPP). Our mechanism requires the use of digital certificates from organisations requesting accreditation. In specific, organizations with an online presence that request privacy policy accreditation must be operating an SSL enabled Web site. The pages that must be SSL protected are at least those that carry the Digital Seal, plus those that interact with the former in order to provide a uniform service to the customers.

In the next few lines we provide a high level overview of our mechanism, which is presented in more detail in the sections to follow.

An organisation applies for a digital seal to the authoritative DPA. The DPA audits the services provided by the organisation and asserts whether they comply with the legal framework on personal data protection. The audit procedures themselves are of no interest to our mechanism. The DPA is responsible for design and maintaining the audit procedures, according to the policy it wishes to follow regarding accreditation.

If the organisation qualifies, the DPA issues a digital seal and registers the organisation in a database that contains all the accredited organisations. When a customer visits the site of those organisations, he must be able to verify the validity of the digital seal placed by the organisation in its Web pages.

3.2SSPP – The Mechanism

We present our mechanism in this section through an example of a transaction between Alice, a user, and Bob, an organization that follows a privacy policy that has been accredited by a privacy seal body called Trend. We assume that Trend operates a Digital Seal Authority and has provided Bob with a Digital Seal. Alice communicates with Bob and verifies the Digital Seal she sees at Bob's pages by communicating with Trend, and Trend communicates with Bob while verifying the validity of Bob's Digital Seal. Therefore, the communication channels are three:

1. Alice communicates with Bob

2. Alice communicates with Trend

3. Trend communicates with Bob

We assume that all communications occurring within the framework of our mechanism use HTTP over SSL, to protect the information being exchanged. Table 1 contains a list with all the acronyms we use throughout our mechanism.

3.2.1Registration of Bob

Bob requests accreditation from Trend. Our mechanism does not require any specific method for communicating this request. The request contains formatted information, as presented below. For this reason, we propose the use of a request collection mechanism that will allow automated filing and processing of the requests themselves. Bob initiates the accreditation request by communicating the following information to the DSA:

1. Identification and contact information of Bob,

2. Cert W,

3. the set of URL-Ws, and

4. the set WPC-Ws. These pages must contain the prospective Digital Seal itself, i.e. the image file that represents the Digital Seal and a URL pointing to the DSA.

Trend must then perform an extensive audit of the services provided by Bob, and decide whether to accredit Bob. Trend should establish a well defined set of rules and controls to be used throughout the audit, and should also produce a publicly available document that states what is Bob being accredited for, if the audit is successful and it is issued a Digital Seal. As we have already mentioned in the previous section, Trend should ideally be a Data Protection Authority (in environments with comprehensive laws regarding personal data protection) and should base his evaluation on the respective data protection legislative framework. If Trend decides to accredit Bob, it proceeds with signing the following information with a private key reserved for that purpose only and storing it at the Database of Accredited Organisations (DAO):

1. H Cert W (to be used as an index for Digital Seals at the DAO),

2. Cert W,

3. the Accreditation Validity Period (AP),

4. the set of URL W,

5. the respective set of H-URL W.

The DSA should then instruct Bob to install the set of pages WPC W at his Web server. These pages differ only to the ones that were hosted by the server previously in that they include the graphic image of the Digital Seal and a respective link to the DSA verification script.

3.2.2Verification of the Digital Seal

When a user visits Bob’s site, and specifically one of the pages included in the set of URL W, the user can verify the validity of Digital Seals these pages bare, by clicking on the Digital Seal graphic images. The underlying link executes a script hosted by DSA, and the response of the DSA verification is returned to the user by the DSA Web server. Digital Seal verification is performed by the DSA, on behalf of the user.

Suppose that Alice (a user) wishes to communicate with Bob, and verify the Digital Seal found on Bob's page URL W, which was issued by the Digital Seal Authority of Trend. The verification steps are the following:

Step 1

Alice communicates with Bob using the HTTPS protocol (HTTP over SSL). When Alice views a page hosted by Bob's Web server, containing a Digital Seal graphic image, she can click on that image and the underlying URL will direct Alice to the Digital Seal verification script hosted by Trend's Web server. Alice must send to Trend at that time the hash of Bob's SSL certificate (H Cert W) and the URL of the page she was viewing at Bob's Web server (URL W).

Step 2

Trend locates Bob's Digital Seal record in his database, using as an index the H Cert W he received. If Trend does not locate any Digital Seal record with that index, Trend returns a page to Alice, informing her that Trend has not accredited the Web site she had been visiting. If Trend locates the corresponding Digital Seal record, but Cert W has expired, he informs Alice that the Digital Seal has expired. The Digital Seal record may also contain revocation information on Cert W and respectively on the Digital Seal (see also next step of the verification phase). If Cert W is revoked, then Trend informs Alice that the Digital Seal is revoked as well.

Step 3

Trend communicates with the CA that issued the SSL certificate for Bob's Web server and verifies the validity of this SSL certificate. If Bob's Web server SSL certificate has been revoked Trend informs Alice that the Digital Seal is revoked as well, because of the respective SSL certificate revocation. Trend also stores the revocation information in the respective Digital Seal record at DAO. If other verification requests occur before Bob obtains a new SSL certificate and Digital Seal, the verification will not need to proceed any further than step 2.

Step 4

Trend checks whether URL W Alice was viewing is contained in the retrieved Digital Seal record. If it is not, Trend informs Alice that the contents of that page, and the respective services provided through that page, could have been accredited but Bob had not requested accreditation for them.

Step 5

Trend retrieves the address of Bob (fully qualified hostname of Web server) from Bob's certificate, which is contained in the Digital Seal record retrieved in step 2. Trend proceeds with connecting to Bob using the HTTPS protocol.

Step 6

Trend retrieves page URL W from Bob's Web server, computes H URL W and verifies that this hash is one of the hashes in the set of URL W contained in the Digital Seal record retrieved in step 2. If the computed H URL W is not contained in the aforementioned set, Trend informs Alice that although Bob's page had been certified, there have been changes in that page for which Trend was not notified and thus the Digital Seal the page bares should not be considered valid.

Step 7

If all the previous steps are completed successfully, Trend returns to Alice a status page stating that the Digital Seal is valid. The status page contains the following information:

1. Identification information of DSA,

2. identification information of Bob, as it is contained in Cert W,

3. the digitally sealed page of Bob's Web server Alice has verified, URL W,

4. the date and time of the accreditation of URL W,

5. the validity period of the presented Digital Seal.

3.2.3Implementation Issues

In step 1 of the Digital Seal verification phase, Alice has to send H Cert W and URL W to Trend. This information is used in order to identify Bob to Trend, and inform Trend of the URL he has to visit later in the verification phase. One of the most practical ways to do that is to include both H Cert W and URL W as parameters to the link referenced by the Digital Seal graphic. Thus, a link under a Digital Seal graphic could look like:

https://dsa.Trend.org/verify?hCertW=B7CA3F5F75FBD3C57A36B21E1161AF4C
&UrlW=https://www.Bob.com/pageX.html

The Digital Seal Policy, designed by the DSA should clearly state that Alice must verify the correctness of information contained in the aforementioned link in Bob's digitally sealed pages before clicking on it. It is Bob himself that includes this identification information; therefore he could provide false information.

There is at least one alternative for having Bob identify himself to Trend, relieving Alice from the responsibility of verifying the identification information before them being communicated to Trend. Trend could use the HTTP Referrer request header field to retrieve this information, without any intervention either from Alice or Bob. In this case, Trend should also retrieve Cert W in step 6 of the verification phase, compute H Cert W and compare it with the one stored in the Digital Seal record. However, the Referrer request header field is not a trusted source of information. One of the vulnerabilities such a method presents is that the Referrer fields are sometimes blocked by firewalls.

Other mechanisms can be found to implement step 1 of the Digital Seal verification phase as well. Another implementation mechanism could be investigated, providing a secure channel for communicating to Trend identification information concerning Bob without requiring any manual intervention from Alice or Bob. Such a mechanism could also be used in order to communicate to Trend the actual contents of URL W, thus reducing the steps of the verification phase by two, since steps five and six would become redundant.

The Digital Seal verification mechanism could be more lax, and possibly efficient, if it did not check for any changes in WPC W (based on comparing their hashes). In this case, Alice would have to trust that Bob would not tamper with the digitally sealed WPC Ws of his. However, we consider that protecting the integrity of WPC Ws is essential because:

1. Minor changes in the WPC Ws could result in major fluctuations in the level of personal data protection offered, and

2. changes in the WPC Ws could be performed by Bob’s malicious, authorised personnel, without being traced.

Therefore, it could become more difficult for Trend to monitor and audit Bob, and guarantee for the privacy measures and policy Bob provides. As a consequence, it could also become more difficult for Alice to begin trusting an organization, simply because she trusts Trend. However, integrity protection of WPC Ws is also an efficiency issue. Organisations seeking privacy policy accreditation will be restricted as to how often they can perform changes in their services, because they will have to re apply for a Digital Seal every time they perform even the slightest change in their WPC Ws. Protecting the integrity of WPC Ws or not is, therefore, an issue to be decided by each organisation. Whatever the decision of the organisation is, it must be published in the policy document concerning Digital Seals, and that information be made readily available to customers.

The records of expired or revoked Digital Seals should be archived. These archives could prove to be useful in the future, supporting cases of DSA arbitration on matters of repudiation or other disputes.

The recommended expiration date of a Digital Seal is the date of expiration of the respective Cert W. There is no point in the former being posterior to the latter, because a Digital Seal expires automatically at the time of expiration of Cert W. Moreover, it is not efficient for the former to be prior to the latter, because thus it is inevitable that more than one Digital Seals would have to be obtained by an organisation, in the lifetime of its Cert W.

It is also recommended that the DSA specify a set of Certificate Authorities it approves, for organisations to receive their certificates from. One of the criteria for including a CA in that set should be the kind of mechanisms used by that CA in order to distribute certificate status information. The DSA must be able to check the status of organisations’ certificates promptly (step 3 of the Digital Seal verification phase), thus certain certificate status information mechanisms may suit a DSA more than others.

4.Addressing Threats

In this section we provide a short evaluation of the capability of SSPP to deal with security threats. We introduce another entity in our mechanism, Mallory. Mallory is a malicious entity trying to subvert the communication protocols or the services provided. The threats in the aforementioned communications and the respective mechanisms that face these threats are analysed in this section. We follow the threat model presented in [CGGG98] and [SKG99].

1. Monitoring of communication lines. Protection of the confidentiality is achieved through SSL. According to our proposal, both Bob and Trend should operate HTTP over SSL on their Web Servers. HTTPS on Bob’s Web Server enables Alice to send personal data to Bob, protecting their confidentiality. SSL on Trend’s Web Server is used for integrity protection (see list item 4). Other Digital Seal schemes do not require the use of SSL on Bob’s Web Server, thus risking Alice’s personal data being exposed to the public.

1. Shared key guessing. Random symmetric encryption keys are produced by SSL and distributed to the communicating parties, for each communication session. Their randomness, and the fact that they are not reused over different communication sessions, makes them hard to guess.

2. Shared key stealing. Random symmetric encryption SSL keys are distributed using an asymmetric distribution protocol, based on the use of the asymmetric keys of Bob and Trend, which are contained in their respective certificates. These keys cannot be stolen in transit, however Bob and Trend should protect adequately the confidentiality of their private keys.

3. Unauthorized modification of information in transit. Protection of the integrity of communicated data is achieved through SSL. SSL protects the integrity of both Alice’s personal data, while being communicated to Bob, and Trend’s privacy statement regarding Bob, while being communicated to Alice. Other privacy seal mechanisms do not require the use of SSL by Bob, or even by Trend. This jeopardizes the integrity of Alice’s personal data being communicated to Bob, and the integrity of Trend’s accreditation statements, while those are communicated to Alice [GARFI97].

4. Forged Network addresses and Masquerading. Mallory could not take advantage of security vulnerabilities in DNS [DEVIV98] and HTTP to pretend to be Trend or Bob, since both Bob and Trend possess SSL certificates issued by a CA. Mallory may possess a valid certificate and try to masquerade its Web site into looking like Bob's Web site, without asserting that it is Bob itself, but trying to claim some trust from Alice simply because the Web site looks like Bob’s. The Digital Seal (or the lack of) provides Alice with a way to verify whether Mallory is an organization to be trusted, as far as privacy issues are concerned, or not. Alice should verify the validity of the SSL certificates of Bob and Trend, before trusting information derived from them. However, since Trend has to verify anyway the validity of Bob's SSL certificate (step 3 of Digital Seal verification), technically there is no need for Alice to verify the SSL certificate of Bob herself. This delegation of certificate status verification makes the process more transparent for Alice. However, we should mention that Alice might want to verify the validity of Bob's SSL certificate herself because she, besides Trend, is also taking a risk by trusting Bob's SSL certificate [RIVE98]. Other privacy seal mechanisms do not offer that kind of protection, due to the lack of SSL in Bob’s or Trend’s Web site and the lack of binding between the issued Digital Seal and the respective SSL certificates.

5. Password stealing. Our Digital Seals mechanism does not require the use of passwords. However, if the services provided by Bob require the use of passwords, then these will be encrypted by SSL. Even if Mallory captures the encrypted passwords, she will not be able to replay them, because SSL protects against replay attacks [OFREI96].

6. Unauthorized Access. Although our mechanism does not feature any access control functions, it provides a countermeasure against the impact of a potential unauthorized access to Bob's resources. If the pages hosted by the Web server of Bob are modified, the respective Digital Seals will be rendered invalid, thus Alice will know that the respective services are not the ones Bob intended to offer.

7. Repudiation of Origin. Trend and Bob cannot repudiate their actions because Mallory can neither replay SSL sessions, nor initiate an SSL session with Alice, pretending to be Trend or Bob. If Bob wishes to ensure that Alice will not be repudiating her actions as well, he could require from Alice to authenticate herself using a certificate or other means.

8. Private key stealing or compromise. Private keys should be protected with adequate mechanisms, in general. The most valuable private key in the Digital Seals mechanism we presented is probably the private key used to sign the Digital Seals themselves. This key is only used offline by DSA and should be protected against disclosure or modification by adequate protection mechanisms. However, since the data signed with this key (the actual Digital Seal) is not used directly by anyone except Trend, a potential compromise of this private key can be recovered relatively easily if the DAO is not compromised at the same time as well.

5.Conclusions

We have presented a novel mechanism and a respective framework of operation for authorities operating privacy policy accreditation schemes and mechanisms offering online verification of privacy policy accreditation. We have proposed that the role of privacy policy accreditation must be undertaken by DPAs in environments with comprehensive laws, because DPAs can be impartial during the transaction (act as trusted and third parties, as they ought to), and because they can impose sanctions.

Our mechanism is more suitable for operation in environments with comprehensive laws, in comparison to other mechanisms. What we propose is not to access in a generic way the operation of an organisation applying for a seal only, but restrict that organisation as to the contents of its web pages. This ensures that DPAs can apply a single, comprehensive and widely known and understood privacy policy framework to all organisations, while at the same time users can verify that an organisation bearing an SSPP seal follows that specific policy. However, we should mention that since our mechanism uses web page digests, it is somewhat more cumbersome for organisations to alter their web pages at will. This is a business issue to be evaluated by managers, when selecting the privacy seal issuer they will ask services from.

Our mechanism differs technically from the mechanisms used globally by private profit making companies offering privacy seal services. Its differences render it immune to certain types of electronic threats the other mechanisms are vulnerable to. Moreover, it is open for scientific review, while private companies offering this service are somewhat reluctant to publishing technical details of their mechanism.

We have presented a novel mechanism and a respective framework of operation for verifying online the accreditation status of organizations claiming to follow specific privacy policies. We have also provided a comparative evaluation of our mechanism and proposed framework of operation against others. We believe that such mechanisms must improve further over time, as privacy issues and respective laws and requirements keep changing. We also believe that the technical issues regarding such a mechanism must be studied carefully, before deploying it at a large scale. Privacy seal services are surely useful. Private organisations offering these services are probably running in a very profitable track, however they should probably also have a second look at the underlying legal framework for these services and the security requirements for the mechanism they deploy for letting users verify online the accreditation status of an organization.

6.References

[CGGG98] Crijns M., Gatziani M., Gritzalis S., Grufferty S., Iliadis J., Kyrloglou N., Landrock P., Moulinos K., Mueller O., Passa P., Polemi D., Spinellis D., Varvitsiotis A., Issues facing the secure link of Chambers of Commerce, European Commission, COSACC (AD4001) project, Del. 3, December 1998.

[DEVIV98] De Vivo M., De Vivo G., Isern G., “Internet Security Attacks at the Basic Levels”, Operating Systems Review, ACM Press, Vol. 32 No 2, April 1998.

[EPIC01] Electronic Privacy Information Center, “Privacy & Human Rights: An International Survey of Privacy Laws and Developments”, ISBN: 1-893044-13-0, 2001.

[EUDIR] Directive 1999/93/EC of the European Parliament and of the Council on a Community framework for electronic signatures, 13 December 1999.

[FORRE99] Forrester Reasearch Inc, “Privacy Wake-Up Call”, September 1, 1999.

[GARFI97] Garfinkel S., Spafford G., Web Security and Commerce, O' Reilly & Associates, 1997.

[OECD99] OECD, “Inventory Of Instruments and Mechanisms Contributing to the Implementation and Enforcement of the OECD Privacy Guidelines on Global Networks”, DSTI/ICCP/REG(98)12/FINAL, May 1999.

[OFREI96] Freier A., Karlton P., Kocher P., The SSL Protocol Version 3.0, Netscape Communications, November 1996 (http://home.netscape.com/eng/ssl3/ draft302.txt).

[RIVE98] Rivest L., “Can we eliminate certificate revocation lists?”, Proceedings of the Second International Conference on Financial Cryptography, Anguilla, British West Indies, February 1998, Springer Verlag

[SKG99] Diomidis Spinellis, Spyros Kokolakis, and Stephanos Gritzalis. Security requirements, risks, and recommendations for small enterprise and home-office environments. Information Management and Computer Security, 7(3):121-128, 1999