Towards Secure Sealing of Privacy Policies
MOULINOS1, John ILIADIS2,
Data Protection Authority, 8 Omirou st, Athens, GR-10463, Greece
Tel: +30-10-3352628, Fax: +30-10-3352617, E-mail: email@example.com
2Department 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: firstname.lastname@example.org
3Dept. of Informatics, Athens University of Economics and Business
76 Patission St., Athens GR-10434, Greece, e-mail: email@example.com
Keywords Security, Electronic Commerce, Trusted Third Party (TTP), Public Key Infrastructure (PKI), Digital Seal, Privacy, Data Protection Authorities.
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]:
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]:
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,
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.
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.
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.
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,
the existing mechanisms are vulnerable to attacks like DNS spoofing [DEVIV98] and masquerading,
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:
It must be open for scientists to review,
it must be suitable for operation within environments where comprehensive laws concerning personal data protection exist,
it must be resilient to security threats [CGGG98], [SKG99],
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).
Figure 1: Accreditation and Seal Registration procedure
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.
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
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.
Alice communicates with Bob
Alice communicates with Trend
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.
Accreditation Validity Period. This is the validity period of a Digital Seal.
The digital certificate used by the Bob’s Web server in order to enable SSL connections to it.
Database of Accredited Organisations. This is the database that contains information on the organisations that have been accredited by Trend and possess a Digital Seal.
Digital Seal Authority: the technological and functional infrastructure Trend operates in order to support online verification of the Digital Seals it issues.
The result of a predetermined hash function (e.g. MD5, SHA-1) on Cert W
H URL W
The hash function result of a page WPC W hosted by Bob’s Web server.
A URL to a page hosted by Bob’s Web server, which will bare the Digital Seal. Bob may decide to place a Digital Seal to more than one pages hosted by his Web server.
The actual page (the data contained therein) hosted by Bob’s Web server, and pointed at by URL W.
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:
Identification and contact information of Bob,
the set of URL-Ws, and
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):
H Cert W (to be used as an index for Digital Seals at the DAO),
the Accreditation Validity Period (AP),
the set of URL W,
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.
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:
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).
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.
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.
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.
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.
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.
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:
Identification information of DSA,
identification information of Bob, as it is contained in Cert W,
the digitally sealed page of Bob's Web server Alice has verified, URL W,
the date and time of the accreditation of URL W,
the validity period of the presented Digital Seal.
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:
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:
Minor changes in the WPC Ws could result in major fluctuations in the level of personal data protection offered, and
changes in the WPC Ws could be performed by Bob’s malicious, authorised personnel, without being traced.
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.
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].
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.
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.
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.
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].
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.
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].
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.
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.
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.
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.
[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
* Corresponding author