This is an HTML rendering of a working paper draft that led to a publication. The publication should always be cited in preference to this draft using the following reference: This document is also available in PDF format.

This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

Diomidis Spinellis Publications

Deploying a Secure Cyberbazaar
by adding Trust on Commercial Transactions



D. Spinellis,a K. Moulinos,b J. Iliadis,c D. Gritzalis,b  S. Gritzalis,cd S. Katsikasc


a Department of Management Science and Technology

Athens University of Economics & Business (AUEB)

76 Patission St., Athens GR-10434, Greece, email:


b Department of Informatics, Athens University of Economics & Business (AUEB)

76 Patission St., Athens GR-10434, Greece, email: {kdm, dgrit}


c Department of Information & Communication Systems,University of the Aegean,

Samos, GR-83200, Greece, e-mail: {jiliad, sgritz, ska}


d Department of Informatics, Technological Educational Institute (TEI) of Athens

Ag. Spiridonos St., Athens GR-12210, Greece, e-mail:



Traditional business practice depends on trust relations between the transacting parties. One of the most important aspects of this trust is the quality of the offered services or products. The Web currently constitutes an enabler for Electronic Commerce, providing a global transaction platform that does not require physical presence. However, transferring trust from the physical world to the electronic one is a process that requires a trust infrastructure to be provided by the electronic world. We believe that current infrastructure models based on Trusted Third Parties can be enhanced. We introduce the notion of Digital Seals and we provide a mechanism for transferring the trust placed by users to companies in the physical world, to the electronic one.



Security, Electronic Commerce, Trusted Third Party (TTP), Public Key Infrastructure (PKI), Digital Seal.



This work has been partially funded by the European Commission’s Telematics for Administrations Programme, COSACC (Co-ordination of Security Activities between Chambers of Commerce) AD 4001 project, 1999-2000.

1. Introduction

Electronic Commerce could be the dominant way of making business in the not so distant future. The advantages of e-commerce are numerous: it eliminates the need of intermediaries, minimizes the cost of the product delivery, provides customers with worldwide market access, provides a platform for new business models. The reasons for the current explosive growth of e-commerce are mainly two, namely the wide deployment of data network technologies, and the evolution of the World Wide Web (Web).

For the past fifty years, advances in telecommunications and computing largely [JI1] occurred side by side. Nowadays, the rate of advances in these technologies is converging. Moreover, the Internet is becoming the first manifestation of a unified channel. Information Technology is becoming more and more tied to network‑enabled applications and solutions. The Internet is becoming a major conduit for commerce [IMRG98], since it is used for communication between organizations or businesses, between individuals and organizations, between individuals, and for intercommunication within an organization.

The friendly interface of the Web and the fact that it enables users to interact using multimedia content, is attracting individuals and businesses altogether to enter into e‑commerce. The security problems Web faces [GS97] do not seem to discourage these entities against using the Web for the time being. However, as the spectrum of e‑commerce and e‑business applications is widens, the user demand for a secure application framework they can trust will augment. Users have also not been discouraged by the current lack of an appropriate legal framework for the regulation of services over the Internet. This lack forces network‑based technological applications to have specific features that allow them to operate in a loosely federated environment.

Traditional business practice depends on the trust between the involved parties. The cornerstone of this trust consists of:

1.        The security of the transactions performed. This practically means that neither the user nor the service provider (or merchant) can act in a malicious or unpredicted manner.

2.        The quality of the exchanged services or products. The consumer must be able verify that the service or product he wishes to receive originates from the provider he selects and trusts, and not from another provider who is claiming to be the former.

There are organizations that individuals typically trust, like Banks and Chambers of Commerce. These organisations often act like intermediaries between two or more parties of a transaction, protecting the interests of these parties. The role of these organisations is to deliver confidence and inspire trust in those transactions. A similar scheme applies to the distributed communication networks, that of Trusted Third Parties (TTPs). A TTP is an impartial organization delivering business confidence, through commercial and technical security features, to an electronic transaction [CEC94]. The most typical application areas of TTPs include the protection of confidentiality, integrity and authenticity in electronic transactions.

TTPs deliver confidence and trust, concerning the transactions themselves. What they do not deliver is confidence and trust regarding the service or product delivered through transactions at a loosely federated environment, like the Web. We introduce the notion of TTP‑supported "digital seals", which can be used for that purpose. A digital seal is a token, which is put on the e‑commerce company's electronic assets, like the company's Web pages, and validates certain characteristics of the company itself, the services or the products offered by that company. These characteristics include the objective information towards the user, quality of a company, quality of a product, customer satisfaction etc.

This paper is organized as follows: In section 2 we present the threats against electronic trust, while in section 3 we provide an overview of the trust relationships in a loosely federated environment, like the global Public Key Infrastructure (PKI). In section 4 we outline the framework that is needed in order to meet the evolving requirements of e‑commerce. In section 5 we propose a mechanism that contributes to providing secure e‑commerce, by enabling another level of trust in electronic transactions. Finally, in section 6 we present our concluding remarks.

2.Threats against electronic trust

The usage of electronic messaging is becoming more widespread as Information and Communication Technology becomes more effective and cheaper. This results in more information being carried electronically, and becoming vulnerable to attacks such as eavesdropping, non-authorized modification and masquerading. A short overview of the threats against a communication channel follows [CGGG98, SKG99]:

1.        Monitoring of communication lines: Electronic transaction information being transmitted in cleartext form renders an unauthorized third entity capable of monitoring it.

2.        Shared key guessing: Digital envelopes are used in order to maintain the confidentiality of exchanged information, and at the same time reduce the computational overhead of public key encryption. If the symmetric keys used in digital envelopes, or the respective symmetric ciphers, are not cryptographically strong then the exchanged messages can be recovered

3.        .Shared key stealing: Transporting a symmetric key to the other party must be done with a mechanism that protects its confidentiality. If this is omitted, it might be monitored.

4.        Unauthorized modification of information in transit: An entity monitoring the messages exchanged throughout an electronic transaction may actively block them, modify them and forward the modified ones to the recipient without the latter being able to notice the modification. This kind of attack is known as the "man in the middle attack" [Garfi97].

5.        Forged Network Addresses: The lack of security mechanisms in the DNS [DeViv98] renders the IP‑based authentication vulnerable to attacks. An imposter may succeed in authenticating himself by forging his network address. Until DNS evolves in a secure naming system, IP‑based authentication should be avoided or additional authentication measures should be used.

6.        Masquerade: This threat refers to unscrupulous entities that pretend to be trusted ones. "Web spoofing" is a widely deployed attack of this kind. It is manifested either by exploiting DNS protocol vulnerabilities and misleading users to untrusted sites, or by properly modifying the DNS records of a name server and thus allowing an attacker to mislead a name server to wrong sites. In addition to that, Web spoofing is also manifested by unauthorized modifications of HTML pages. An attacker may alter the links of an HTML page and lead an unsuspected user to malicious programs or false information. [Garfi97]

7.        Password stealing: Passwords gained their popularity due to their ease of use and implementation low cost. However, passwords transmitted in the clear and reusable passwords [Garfi96] should be avoided because they constitute a security threat.

8.        Unauthorized access: An unauthorized user may gain access to local or network resources by masquerading, password stealing and exploiting bugs of the underline operating system. A sound access control policy is required, that meets the requirements of a well‑defined security policy of the organization.

9.        Repudiation of origin: An unscrupulous user may deny having digitally signed a document, claiming prior key compromise or loss.

10.    Private key stealing: Should the private key be stolen, unauthorized entities will be able to act on the private key owner's behalf and recover confidential information.

11.    Private key compromise: Should the private key be compromised, unauthorized entities will be able to act on the private key owner's behalf and recover confidential information. A TTP should take seriously under consideration the place where the private key generation has taken place, in order to avoid possible future accusations by keyholders, claiming that the TTP colluded in having their keys compromised, or did not take the necessary security measures during key generation and transport.

3. Trust Relationships

TTPs supply technically and legally reliable means for producing objective evidence concerning an electronic transaction. TTP services are provided and underwritten by technical, legal, financial and structural means [Caste93]. TTPs are connected through chains of trust (usually called certificate paths) in order to provide a web of trust forming the notion of a Public Key Infrastructure.

A PKI consists of more than one TTPs, hence the need for cross-certification of users registered with different TTPs. Fulfillment of this requirement presupposes the establishment of communication paths [Rensb97, Cliff98, AGGPS98] between the final users. There are four distinct implementation alternatives, depending on the level of intercommunication (see Figure 1) [Gritz98]:

1.        User-to-User: Users must be capable of processing the entire certificate path that leads to the communicating party.

2.        User-TTP-User: TTP acts as an inline intermediary. Users are expected to be registered with the same TTP, and the latter becomes a communication bottleneck.

3.        TTP-to-TTP: Cross-certification is implemented on the TTP level. The communicating entities possess certificates from TTPs that corroborate. TTPs must have previously established a bilateral agreement.

4.        HighLevelTTP-to-HighLevelTTP: Cross-certification is performed at a high level of the TTP certification hierarchy. Each communicating entity trusts its own high‑level TTP, and since these are cross‑certified, the communicating entities also trust each other’s high‑level TTP and therefore the low‑level TTP that issued each other’s certificates.

Figure 1: Cross Certification Alternatives

The first alternative is not efficient because it requires the end user to obtain all the existing certificates (e.g. the case of PGP). The second alternative, the case of Kerberos authentication scheme, is not suitable for large-scale networks, since the TTP becomes the bottleneck of the whole PKI. In the last two alternatives the creation of a trust relationship requires the digital signing of an entity’s certificate by another entity (cross certification). In the case of network model (alternative 3) each TTP digitally signs the certificates of the other TTPs, while in the hierarchical model (alternative 4) the higher level TTP digitally signs the certificate of the subordinate TTP. Obstacles may emerge when these models are used on a wide scale. We identify three distinct categories of these obstacles:

1.        Technical. TTPs of a specific geographical or business domain may develop infrastructures and Certification Policies that are not interoperable with those of TTPs of another domain.

2.        Legal. Legal particularities, especially national‑level ones, may hinder the interoperability of TTPs being subject to different or even contradicting legislature and regulatory frameworks. An instance of this problem is the case of Germany, where Federal Law prohibits national TTPs to be certified by foreign TTPs [GFMER98].

3.        Managerial/organizational. Generating trust chains premises bilateral contractual agreements. These may impose restrictions on the management of a TTP, including additional, expensive protection mechanisms for the TTP itself, or minor adjustments in the Certificate Policy of the TTP. These restrictions render the aforementioned bilateral agreements unattractive to TTPs.

We conclude that end-users are restricted to isolated electronic trust islands. Users trust the security of certain transactions, which are protected by a specific group of authorities they trust. Moreover, this trust model does not enable trust on the business side of electronic transactions, that is the quality of services or products offered by e‑commerce providers. One of the reasons why this model is not capable of enabling this kind of trust is because it requires the intermediation of entities (i.e. Certificate Authorities or TTPs) that do not, and should not, belong or be involved in any way with the business sector.

The trust model we have presented needs enhancements. These could derive either from ongoing research on PKI, and from managerial solutions such as bilateral agreements between TTPs. However, we believe that another trust model is needed as well, complementary to the one we presented above. This model must enable trust on the quality of services or products offered by e‑commerce. The rest of this paper investigates solutions for communicating this kind of trust in loosely federated environments.

4.Solution Framework

Let us assume the working example of an international trade firm. This firm maintains an e‑commerce site, with a Web front‑end, at its headquarters. Having all the customers communicate with the firm through this site would result in increased traffic around the site, and thus in lower availability of the electronic commerce services offered by the firm. Furthermore, a single point of trade would be an attractive target for availability attacks either by competitors or by unscrupulous entities that have no gain in performing such an attack.

The firm should provide a distributed system for providing its services and communicating with its customers. This is achieved by a network of local agents, which also operate an e‑commerce site. Therefore customers will have the opportunity to contact the nearest local agent, this being beneficial both for the customers and for the firm itself.

However, customers who communicate with local agent sites would want to ensure that the agents (and the respective Web sites) they communicate with are indeed local agents, accredited by the firm. There is a clear need for transfer of the trust the customer’s place on the firm, to the agents.

The firm should design a well‑defined set of service quality criteria a potential local agent must meet in order to be accredited. A set of service quality criteria that would inspire trust to the customers, for the local agents. Designated representatives of the firm should audit the local agent's infrastructure and operation, and provide accreditation if the criteria are met.

Therefore, to provide a solution to the trust transfer problem it would be enough to find a way for customers to verify that a local agent meets those criteria. The firm could issue accreditation tokens to its agents, providing for the verification of compliance with the criteria, and enabling the trust transfer. We will be calling these accreditation tokens seals.

Seals provide customers with the capability to verify that a local agent is accredited by the firm, therefore they can trust the local agent as much as the firm itself, since the accreditation process includes compliance checks against quality criteria lay out by the firm. There is no point in providing different levels of accreditation, because that would cause confusion to the customers regarding the quality of services offered by the local agent. Moreover, the customers will probably be willing to trust the local agent as much as the firm, only if the agent meets the full set of quality criteria set by the firm.

We provide a mechanism for customers to validate the seals they meet while visiting local agent sites. The accreditation and seal registration procedure encompasses five steps (Figure 2), if accreditation is successful, and three steps only if accreditation of the local agent is rejected. If the local agent is accredited, he receives a digital seal, which can be installed in its HTML pages, enabling the customers that visit the agent to confirm that it is a firm‑accredited agent.

Figure 2: Accreditation and Seal Registration procedure

5. The proposed solution

5.1.            Architectural Overview

We provide a mechanism for firms to register accredited agents of theirs, and for customers to verify online the validity of a digital seal. This mechanism includes the use of digital certificates, and requires from the agent to have obtained before requesting accreditation, a digital certificate from a Certification Authority.

A local agent applies for a digital seal to the firm. The firm audits the management of the services provided by the local agent and the services themselves and asserts whether they meet the predefined quality criteria. The audit procedures and the quality criteria themselves are of no interest to this mechanism. The firm is responsible for the design of those, according to the policy it wishes to follow regarding accreditation. Whatever policy the firm decides to adopt, it should make it readily available to its customers.

If the agent qualifies, the firm issues a digital seal and registers the agent in a database that contains all the local agents that have qualified for a digital seal. When a customer visits the site of the local agent, he will be able to verify the validity of the digital seal placed by the agent in its HTML pages.

Since the number of agents may be high, the communication lines used by the database of accredited agents could become a bottleneck in the seal verification process or a deterrent factor in the verification process, should the database fail to operate. This problem must be dealt with computing and network resources of the firm itself, such as replication of the database and fallback communication lines.

We present our mechanism in the next section through an example of a transaction between Alice, a customer, and Bob, a local agent of a firm called Trend. We assume that Trend operates a Digital Seal Authority and has provided Bob with a Digital Seal. Alice communicates with Bob in order to purchase services or products. Alice 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 Error! Unknown switch argument. contains a list with all the acronyms we use throughout our mechanism.

Table Error! Unknown switch argument. : Acronyms


Accreditation Validity Period. This is the validity period of a Digital Seal.


The digital certificate used by the Web server of the agent to enable SSL connections to it.


Database of Accredited Agents. This is the database that contains information on the agents that have been accredited and possess a Digital Seal.


Digital Seal Authority: the section of the firm which is responsible for the operation of the service we present.


The result of a predetermined hash function (e.g. MD5, SHA-1) on Cert‑W


The hash function result of a page WPC‑W hosted by the agent's Web server.


A URL to a page hosted by the agent's Web server, which will bare the Digital Seal. The agent 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 the agent's Web server, and pointed at by URL‑W.

5.1.1.      Registration of the Local Agent

The agent requests accreditation from the firm. 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.

The agent initiates the accreditation request by communicating the following information to the DSA, typically the firm:

1.       Identification and contact information of the agent,

2.       Cert‑W,

3.       the set of URL-Ws, and

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

The DSA must then perform an extensive audit of the services provided by the agent, and decide whether to accredit the agent. The details of this audit are of no interest to this paper. The firm 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 the agent being accredited for, if the audit is successful and it is issued a Digital Seal. If the firm decides to accredit the agent, it proceeds with signing the following information and storing it at the Database of Accredited Agents (DAA):

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

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 then instructs the agent 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.

5.1.2.      Verification of the Digital Seal

When a user visits the site of an agent, 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 (an agent), and verify the Digital Seal found on Bob's page URL‑W, which was issued by the Digital Seal Authority of the respective firm, Trend. The verification steps are the following:

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).

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 the Web site she was visiting has not been accredited by the firm. If Trend locates the corresponding Digital Seal record, but Cert‑W has expired, he informs Alice that the Digital Seal has expired as well. 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.

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 DAA. 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.

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.

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.

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.

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:

·         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.

5.2.            Implementation 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:

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 at the 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, the customers would have to trust that the —accredited— agents of the firm would not tamper with the digitally sealed WPC‑Ws of theirs. 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 quality of services offered, and

2.        changes in the WPC‑Ws could be performed by malicious, authorised personnel of the firm's agent, witthout being traced.

Therefore, it could become more difficult for firms to monitor and audit their agents, thus guaranteeing for the services they provide and being able to accredit them. As a consequence, it could also become more difficult for customers to begin trusting agents of a firm they trust, simply because they trust the firm. However, integrity protection of WPC‑Ws is also an efficiency issue. The agents of a firm 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 firm. Whatever the decision of the firm 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 agent, in the lifetime of its Cert‑W.

It is also recommended that the DSA specify a set of Certificate Authorities it approves, for agents to receive their certificates from. The sole 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 agent certificates promptly (step 3 of the Digital Seal verification phase), thus certain certificate status information mechanisms may suit a DSA more than others.

5.3.            Addressing Threats

In this section 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 analyzed in this section. We follow the threat model presented in section 2.

1.        Monitoring of communication lines. Protection of the confidentiality in the communications mentioned above is achieved through SSL.

2.        Shared key guessing. Random symmetric 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.

3.        Shared key stealing. Random symmetric encryption SSL keys are distributed using an asymmetric distribution protocol, based on the use of the asymmetric keys of Alice, Bob and Trend which are contained in their respective certificates. These keys cannot be stolen in transit, however all three entities should protect their keys at a local level.

4.        Unauthorized modification of information in transit. Protection of the integrity of communicated data is achieved through SSL.

5.        Forged Network addresses and Masquerading. Mallory could not pretend to be Trend or Bob, since they both possess SSL certificates issued by a CA. To increase the possibility of Alice trusting the Certificate Authorities which issue certificates to Trend and Bob, Trend should have a certificate from a well‑established CA which lies high in the global PKI hierarchy and Bob should have a certificate either from a CA which belongs to a trust chain where the aforementioned CA belongs also, or from a CA that is known to be widely trusted locally, at Bob's location. If Mallory possesses a valid certificate, but tries to masquerade its Web site into looking like Bob's Web site, the Digital Seal (or the lack of) provides Alice with a way to verify whether Mallory is indeed a local agent of the firm 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].

6.        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].

7.        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, and Trend had accredited.

8.       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 obtained from a CA that belongs to one of the certification chains that Bob trusts.

9.        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 and the operation of the infrastructure we present 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, technical 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 DAA is not compromised at the same time as well.


Electronic trust concerns both the security of electronic transactions and the quality of services or products offered through them. PKI is being used to enable trust on the security of e‑commerce transactions. We introduced the notion of Digital Seals, and a respective mechanism that enables trust on the quality of services or products offered by e‑commerce infrastructures.

Our mechanism does not add to the complexity of trust relationships in PKI. On the contrary, certain features of our mechanism facilitate the use of PKI technologies; Alice can transparently delegate the verification of Bob's SSL certificate to Trend.

We analyzed an example of an e‑commerce infrastructure, involving a firm comprising several agents around the globe. We have demonstrated that our Digital Seals mechanism, along with typical PKI services, can be used to enable trust on behalf of the e‑commerce customers enhancing both the security of electronic markets, and the quality of the services or products offered through them.


[FGGGIK00]     Forret P., Gatziani M., Gritzalis S., Grufferty S., Iliadis J., Kyrloglou N.,  Landrock P., Moulinos K., Polemi D., Spinellis D., Varvitsiotis A., The C.O.S.A.C.C. Solution for the Secure Interconnection of Chambers of Commerce, European Commission, EUROMED-ETS Project, March 2000.

[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

[IMRG98]         IMRG Limited, "Electronic Commerce in Europe, An action plan
for the marketplace", White Paper, July 1998

[AGGPS98]      Amditis A., Gritzalis D., Gritzalis S., Polemi D., Spinellis D., Varvitsiotis A., Velentzas S., Review of existing results of TTPs for Healthcare Systems, European Commission, EUROMED-ETS Project, February 1998.

[Caste93]          Castell S., Code of Practice and Management Guidelines for Trusted Third Party Services, European Commission, INFOSEC S-2101 project, report no. 2, 1993.

[CEC94]           Commission of the European Community, DGXIII/B, Green Paper on the Security of Information Systems, ver.4.2.1, 1994

[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.

[Cliff98]            Clifford M., Lavine C., Bishop M., “The Solar Trust Model: Authentication without Limitation”, Proc. Of the 14th Annual Computer Security Applications Conference, IEEE Computer Society Press, pp 300-307, 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.

[Garfi96]           Garfinkel S., Spafford G., Practical Unix and Internet Security, O' Reilly & Associates, 1996.

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

[GFMER98]      German Federal Ministry of Education and Reasearch, Digital Signature Ordinance, 1998 (

[GS97]              Gritzalis S., Spinellis D., "Addressing Threats and Security Issues in World Wide Web Technology", in Proceedings of the CMS '97 3rd IFIP TC6/TC11 International joint working Conference on Communications and Multimedia Security, pp.33-46, September 1997, Chapman & Hall

[Gritz98]           Gritzalis S., Moulinos K., Lekkas D., Polidorou E., European Cross Domain PKI Architecture: Functional Specifications, European Commission, KEYSTONE (23187) project, November 1998.

[OFrei96]          Freier A., Karlton P., Kocher P., The SSL Protocol Version 3.0, Netscape Communications, November 1996 ( draft302.txt).

[Rensb97]         Rensburg A., Solms B., “A comparison of schemes for CAs”, in Proc. of the IFIP International Information Security Conference, Chapman & Hall, pp. 222-240, 1997.

[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

 [JI1]Τι εννοείς; Αρχικά δίκτυα και computing δεν αναπτύσσονταν παράλληλα αλλά τώρα αναπτύσσονται παράλληλα; Αν εννοείς αυτό, η λέξη largely δεν είναι σωστή