ZLA: Towards Zero-Leak Private Information in Online E-commerce Transactions

Transcription

1 ZLA: Towards Zero-Leak Private Information in Online E-commerce Transactions Hiroshi Fujinoki, Christopher A. Chelmecki, and David M. Henry Department of Computer Science Southern Illinois University Edwardsville Edwardsville, Illinois , USA s: Abstract In this paper, we propose new security architecture, called ZLA (Zero Leak Architecture), which guarantees zero possibility of customers private information leak from online shopping web sites even in the worst case: the security administrator of the e-commerce web site becomes an attacker. The proposed security architecture assumes three parties of merchants, shipping carriers, and credit card companies. ZLA covers a whole procedure in an online shopping transaction from the time a customer browses an online shopping site, up to the time the customer confirms delivery of the correct products. Our performance studies suggested that the cost factor of running ZLA is 1.8 (1.8 times more computational power and faster network) to achieve the same queuing delay and transaction throughput compared to the existing architecture, where there is no protection against the customers private information leaks in the worst case. The proposed architecture will contribute to flourish of e-commerce by eliminating the risk of private information leaks with relatively low cost of more powerful computations, especially as predicted by Moore s law. 1. Introduction The risk of private information leaks from servers has been a serious issue. Our previous survey revealed Internet users conflict between their favor to online shopping and fear for their personal information leaks [1]. Many of online shopping sites are currently implemented based on the client server model, which practically forces their customers to provide their personal information to the servers owned by merchants. This implies that there is nothing customers can do to protect their privacy once they provide their personal information to the servers but to trust the server side security administrations. The problem is that it is difficult for customers to know how serious the server side is for protecting customers information. If some merchants do not look serious in protecting customers privacy, all what we should do is just to avoid them, but how can we know for sure which merchants are good ones? In an extreme case, if the security administrator commits stealing the personal information from the merchant s server, there is nothing customers can do to proactively stop such crimes. In designing a security architecture that guarantees no information leak, we categorized attackers in the two groups of those who have physical accesses to the server host computers where customers information is stored and those who do not. We called the former internal attackers and the latter external attackers. Internal attackers are server side system administrators, or someone (in the facility the administrators work) who manage to steal the access rights of the administrators by some means, such as duplicating the server room key or accidentally watching a memo that shows the administrator s password on it. Handling customers information in electronic commerce has another dimension. Any possible dispute regarding a transaction, such as a claim about delivery of a damaged product, must be resolved while any of the three parties should not have access to the complete information about each transaction. We defined the complete information about a transaction to mean who ordered what product. Also from the view point of the legal issues, the ability to reconstruct the complete information for each transaction is mandatory, since the United States Money Laundering Act (U.S. Code 12, Section 1829) prohibits anonymous transactions valued over $100 [2]. The complete information about each such online transaction must be reconstructed and disclosed to a legislative authority up on a court s disclosure order, while none of the three parties involved in a transaction should have access to the complete information without a court order. The recent security incidents caused serious damages to electronic commerce customers due to the leakages of their privacy information. A new solution is needed, which guarantees no leakages of customers private information no matter what happen in the server side, while the solution satisfies the legal requirement. This paper proposes a new solution, called ZLA (zero leak architecture), which eliminates the possibility of leaking customers private information in a sense that it is minimized to a level customers can assume that such leakages will not

2 happen at the same time the solution satisfies the legal requirement. The rest of this paper is organized as follow. Section 2 describes the existing related work. In Section 3, the zero leak security architecture for online shopping applications is described by applying the architecture to online transactions typically performed in online shopping web sites today. In Section 4, ZLA is analyzed for its protections against different types of unauthorized and malicious accesses to customers private information. This section also describes our performance analyses of ZLA for its queuing delay and throughput. Section 5 summarizes the conclusions, followed by the references. 2. Existing related work The risk of private information leaks from servers has been a serious issue. It becomes a significant issue especially when service vendors and data storage providers are separated in cloud computing. Many of the existing data protection methods, such as ing a whole disk [3] and separation of stored data from code execution [4], will be effective to external attackers, but neither of them will be an effective solution against threats by internal attackers. To secure personal information from insiders threats, ing personal information using customers biometric information without storing decryption keys in the server side have been proposed by Uludag and Zhang [5, 6]. Although these solutions will be effective in hiding customers information in e- commerce applications, none of the merchants, shipping carriers, or credit companies except the customers have access to the complete customer information, which fails to satisfy the legal requirement. Mazières proposed a distributed file system, SUNDR, which prohibits unauthorized users from performing any read access to the files stored in their storage devices [7]. SUNDR chops the contents in each file and spread the chops to multiple segments, called data blocks in such a way that the mapping of the segments in a file is hidden by virtual i-node. Mattsson proposed column-level database ion to protect users information from both external and internal attackers [8]. The column-level database ion is performed by ing security sensitive data, calculating the HMAC hash of the data, and attaching the hash to another column in the same row of the table. The owner of the data uses the hash to find target data by matching the hash value. The decryption key for the secure data is not stored in the database, but in the applications that use the database. Although the above two solutions are effective for protecting customers information from external attackers, the solutions will not be effective against information threats by the internal attackers. Since the solutions are applied to the system level, neither of them can protect customers information after customer s information is produced by an application but before such information is passed to the systemlevel solutions. This implies that the true zero-leak protection should also cover the application level, especially in the client side of applications. Secure Electronic Transaction (SET) protocol has been proposed to secure electronic payments using credit cards for online transactions such as purchasing goods through merchants web sites [9]. Since its introduction, several extensions to SET have been proposed, some of which were proposed for realizing customers anonymity in SET [10]. Rennhard proposed new network application architecture for online shopping using SET, which hides customers network address from the merchants and credit card companies to protect customers privacy [10]. Rennhard s solution consists of an overlay network called Pseudonymity Network (PN), which uses intermediate proxies and a security protocol (for key exchanges and ions) called Pseudonymous Secure Electronic Transaction (PSET) protocol for the messages exchanged by the involved parties to hide customers network addresses and identities. Although SET and its enhancements will be effective for protecting customer payments by hiding customers credit card information from the merchants, none of them prevents customers information from leaking at their servers if shipping goods is handled through merchants. As most of the online customers do not pick up the products at the online stores, supporting shipping the products while the merchants do not have access to customers identity is another must to achieve true zero leak online shopping sites. Inclusion of product shipping as a part of zero leak design is essential along with the context of service integration in service oriented architectures (SOAs), where various services in online shopping, such as payments for the goods and shipping the goods to customers, should be integrated to automate businesses for better transactional turnarounds and for reducing running costs [11, 12]. To enhance customers anonymity in online transactions, Tygar introduced the concept of certified delivery by enhancing goods atomicity [13]. The term certified delivery means that a customer will receive the product if and only if the money for the product is transferred from the customer to the merchant (this concept was called goods atomicity ) and that the delivered goods must be correct. The true challenge for realizing certified delivery is in the tradeoff between disclosures of customer s information to all the involved parties and achieving anonymity. The more information about each transaction is disclosed to each party, the easier it will be for them to handle any dispute for each transaction, but it obviously sacrifices anonymity in each transaction. Zhang proposed three security enhancements to SET [14]. They are protection of the customers private key using Active-X, database ion, and

3 guaranteeing certified delivery in SET. Active-X is used to protect customers private key. When the private key of a customer is referenced by the customer s local host process, active-x prompts the user to enter the user s secret key to approve the use of private key. Lekkas proposed a new approach for securing electronic payments, called E-coins [15]. E-coin is a new approach in that it performs payments by securely transferring virtual currency (i.e., E-coins) issued by an individual instead of transferring payment information for actual currency as SET does. One of its features is untraceable, meaning that it is not possible to identify who (as a real human) issued the currency and for what product it was used for, although the first who proposed the concept as on-line virtual currency was Chaum [16] in our best knowledge. E-coins is proposed as an off-line electronic payment method, meaning that payment transactions can be completed without contacting a central bank. An electronic payment system proposed by Eslami [17] is based on the same concept. Despite their effectiveness in improving anonymity in online transactions, none of the above solutions guarantees no information leak when a shipping of the ordered goods is handled by merchants. Thus, a new security architecture that guarantees zero possibility for customers information leak, from the time a customer browses an online shopping site, up to the time the customer confirms delivery of the correct product(s) ordered by the customer, is needed. 3. Description of ZLA The proposed architecture assumes the four parties of the customer, the merchant, the shipping carrier, and the credit card company, none of whom, except the customer, has access to the complete information regarding each online transaction. The customer is a user who visits an online shopping web site where the user makes orders to particular products. The merchant is the party who owns and maintains an online shopping web site to take orders from customers. The carrier is the party who sends the products the merchant sells to their customers. The credit card company is the party who makes payment to the merchant for the products a customer ordered. ZLA must allow merchants and the other parties to handle any accident in a transaction, while no single party owns complete information about each transaction. For example, if a customer has a question about the payment amount charged by the credit card company for a particular order, the merchant and the credit card company need to collaborate on the investigation. If the products are lost during their shipping, the customer may request the merchant to provide its shipping and product information to the carrier for an insurance claim. For a disclosure order from a court, the three parties collaborate. To handle such situations, there must be a mechanism that logically integrates users information about a particular transaction while no single party accesses to the complete information about each transaction. Each of the merchant, the carrier, and the credit card company is assumed to have their digital certificate that contains their digitally signed public key. Merchants have obtained the digital certificates of the shipping carriers and the credit card companies. The merchants make those certificates available to their customers through their online shopping sites. It is also assumed that the web server and browser used by the merchants and the customers support secure connections (e.g., SSL). ZLA does not require customers to have their digital certificate. It may not be a reasonable requirement to mandate customers to have digital certificate, since requiring digital certificate to customers, as many existing secure transaction protocols do, costs customers and such solutions will not be widely adopted. Table 1 lists the major cryptographic keys used in ZLA. The keys with a star are those provided in the digital certificate endorsed by a SA (security authority). OT in the key names means one time. For each transaction, eight one-time keys are created, but they are all one-time, meaning that once a transaction is completed (when the merchant server finalizes a transaction), they are discarded. Name of the key Symbol Purpose Merchant public * MP To the messages to this merchant Merchant private * MS To decrypt the messages to this merchant Credit card company public * CP To the messages to this credit card company Credit card company private * CS To decrypt the messages to this credit card company Carrier public * SP To the messages to this carrier Carrier private * SS To decrypt the messages to this carrier Customer OT public for merchant UOTP-M To decrypt signature for the final order message Customer OT private for merchant UOTS-M To signature for the final order message Customer OT public for cc company UOTP-C To decrypt signature for the protected message Customer OT private for cc company UOTS-C To signature for the protected message Customer OT public 1 for carrier UOTP-S1 To the tracking number from the carrier Customer OT private 1 for carrier UOTS-S1 To decrypt the tracking number from the carrier Customer OT public 2 for carrier UOTP-S2 To decrypt signature for the protected message Customer OT private 2 for carrier UOTS-S2 To signature for the protected message Table 1 List of the major cryptography keys used in the proposed zero leak architecture ZLA assumes that each merchant is assigned a unique identification number. To guarantee the uniqueness in the numbers, a central organization that manages and assigns the merchant identification numbers is proposed. The organization of the architecture is shown in Figure 1 (a). Shipping Carrier s Server A Certificate Merchant Server C Certificate Customer Customer s Local Host Computer Credit Card Company s Server B Certificate Merchant Identification Number Allocator (a) Organization of the zero-leak online shipping site Shipping Carrier s Server Merchant Server Customer s Local Host Computer Credit Card Company s Server : Order request : OI and digital certificates : Final order message : and payment request 5 : Payment approval : and shipping request : Shipping request acceptance : Final confirmation (b) Procedure in the message exchanges Figure 1 - The organization of ZLA (a) and its procedure (b)

4 The procedure of the zero leak transaction is as follow. First, a customer visits the online shopping site operated by a merchant. After the customer s browser and the merchant web server establishes an application level secure connection, the browser downloads the merchant s digital certificate to confirm the merchant s identity. Then, the customer specifies the product names, the number of the products, the carrier, and the credit card she wants to use for this transaction (message in Figure 1 (b)). When the customer finishes entering the preliminary order information, the merchant server calculates the total payment amount and creates an order token for this order. The order token is the information that uniquely identifies each transaction in all the four parties. The order token consists of the unique merchant identification number, the date of the token s creation in year, month and day, followed by a unique transaction number issued by the merchant. Once the order token is created, the merchant server creates order information (OI) that contains the details of the order specified by the customer, such as the product names, the number of the products, the carrier name, and the credit card name. The merchant then sends the OI, the order token, and the digital certificates of the shipping carrier and the credit card company in one message, called the order confirmation to the customer through a secure connection (message in Figure 1 (b)). When the customer s browser receives the order confirmation, the client side process displays the contents in the order confirmation and asks the customer s approval for the order. Then, the public keys of the carrier (S P ) and the credit card company (C P ) are extracted from their digital certificates. The customer side process constructs the four pairs of onetime s followed by construction of the final order message. The public key of the credit card company (C P) public keys for the carrier (U OTP-S1 and U OTP-S2 ). The customer digitally signs the whole data structure using her first one-time asymmetric private key (U OTS-S1 ), which is then ed by the carrier s public key (S P ). The digital signature is attached to the ed data structure to make it protected (Figure 2). The payment information () is prepared by the customer in a similar way to. contains the information needed to acquire payment approval from the credit card company, such as the credit card number, the name of the card holder, expiration date, and etc. The protected is created in the same way as, except that it contains only one one-time public key, U OTP-C (Figure 3). from customer Order token From merchant One-time public for transferring tracking # (U OTP-S2 ) One-time public for this (U OTP-S1 ) Message Digest The public key of the carrier (S P ) One-time private for this (U OTS-S1) Figure 3 Construction of the protected One-time public asymmetric key for this merchant (U OTP-M ) OI One-time private for this merchant (U OTS-M ) The order token OI Message Digest Protected Segment OI Public key of the merchant (M P ) Protected Segment Protected Final order message from customer Figure 4 Construction of the final order message Order token From merchant One-time public for this (U OTP-C ) Message Digest One-time private for this (U OTS-C) Protected Figure 2 Structure and the construction of the protected segment for the selected carrier The final order message is constructed as follow. First, the customer creates shipping information () for the carrier. contains the mailing address of the customer, type of shipping (express, insured, etc), and other information needed for shipping the ordered products. Then, the customer side process constructs the protected, which contains the, the order token from the merchant, and the two one-time asymmetric After the customer s local process prepares the protected and the protected, it constructs the final order message by concatenating, the copy of the OI from the merchant, the order token from the merchant, the one-time public key (U OTP-M ), the protected, and the protected. Then, the local process calculates the message digest of the whole final order message, which is ed by the one-time private key of the merchant (U OTS-M ). After that the final order message is ed by the merchant s public key (M P ). The ed message digest is attached to the ed final order message. Finally the whole structure is sent to the merchant using a secure connection (message ). The procedure of constructing the final order message is shown in Figure 4. When the merchant receives the final order message, the merchant decrypts the whole message

5 using its private key (M S ). The merchant extracts the OI, the order token, its one-time public (U OTP-M ), the protected, and the protected. Using his one-time public (U OTP-M ), the merchant decrypts the ed hash digest and tests the integrity of the whole message. Then, the merchant concatenates the protected, the order token, and the requested payment amount. The merchant sends the information to the credit card company (message ). This message should be digitally signed by the merchant. Note that the merchant can not decrypt the protected or the protected, since their decryption requires the credit card company s private key (C S ) or the shipping carrier s private key (S S ). When the credit card company receives the protected from the merchant, the credit card company decrypts the protected using its private key (C S ) and confirms the integrity of the protected using the one-time public key (U OTP-C ) in the protected. After the integrity is confirmed, the credit card company identifies the customer s account and compares if the order token and the payment amount extracted from the protected match those sent from the merchant. If they match, the credit card company examines the customer s payment credential to approve the payment request. The credit card company constructs the approval message that contains the same order token, and the approved payment amount. The message is digitally signed and ed by the credit company. Then, it is sent to the merchant with the digital signature (message ). After the merchant receives the payment approval from the credit card company, the merchant sends the protected and the order token together to the carrier specified in the OI (message ). When the carrier receives the message, it decrypts the protected using its private key (S S ) and examines the signature using the second one-time public key from the customer (U OTP-S2 ). The carrier issues a tracking number for this shipping. The tracking number and the order token are concatenated together and they are ed by the first one-time asymmetric public key from the customer (U OTP-S1 ). Then the information is sent to the merchant as an acknowledgement for the shipping request (message ). When the merchant receives the acknowledge from the carrier, the merchant sends the ed tracking number and the order token to the customer (message ). The merchant does not have access to the tracking number, since it is ed by the one-time key issued by the customer (U OTS-S1 ). When an accident happens in a transaction, any party who is involved in each such accident can reconstruct the necessary information about the transaction using the order token. For example, if a customer has a question about payment amount charged by the credit card company for a particular order, the customer contact the merchant and the credit card company and show the order token as the only information needed to identify her transaction. Any accident that involves the carrier should be resolved in the same way. Each administrator can never provide the information about customers to the administrators in other parties without a disclosure order from a court. 4. Performance evaluations In this section, the zero leak architecture is analyzed from the viewpoint of its effectiveness against the existing security threats. The five security threats are eavesdropping, replay, modification, masquerading, and traffic analysis. This section also describes the results of the performance evaluations for ZLA by implementing a prototype of ZLA. 4.1 Analyses on ZLA s coverage of different security risk types In analyzing the resistances to different types of unauthorized or malicious accesses to customers private information by external and internal attackers, we developed a model for analyses as shown in Figure 5. We expect the primary methods of unauthorized accesses by internal attackers are through direct accesses, while those for external attackers are performed by bug exploits and message interceptions. Message interceptions are typically performed in the forms of eavesdropping, replay, modifications (i.e., man-in-middle), masquerading, and traffic analysis. internal attackers direct accesses bug exploits external attackers unauthorized/malicious accesses to customer information message intercepts Figure 5 A model for unauthorized/malicious accesses to customer s private information The followings are our analyses for the effectiveness of ALZ against unauthorized/malicious accesses by internal attackers through direct accesses: (i) Internal attackers at merchants: The attackers have access only to the information about the products ordered by their customers, the order tokens for each transaction, and the network address of the customers. Any other information is not stored at the server, nor accessible by the attackers. (ii) Internal attackers at shipping carriers: The attackers have access to the information that identifies each customer, such as the customer s full name and mailing address, but not the one about the products ordered by the customers or the amount of the payment for the products. Since the order tokens contain a unique merchant identification number, if the merchant s name provides any clue to the products, it may be possible for internal attackers at shipping carriers to guess the products ordered by each customer.

6 (iii) Internal attackers at credit card companies: The attackers have access to the information that identifies each customer, such as the customer s full name, mailing address, telephone number, credit card number, and the amount of the payment for each transaction. Similar to internal attackers at shipping carriers, the order tokens allow the attackers to identify the merchant in each transaction, which may allow the attackers to guess what products were purchased. The followings are our analyses for unauthorized accesses by external attackers through message interceptions: (i) Eavesdropping: Protection against this threat is provided by ions in multiple network layers. For example, SSL, IPSec, STS, WPA, and ions performed in the application process guarantee that the message contents will not be released to external attackers during their transmissions, assuming that the keys for ing messages are correctly exchanged between two parties. (ii) Replay: Although the external attackers who have physical access to network equipments, such as routers, and transmission cables, can perform replays, they will not cause any effect to a transaction since none of the eight messages (those shown in Figure 1) is cumulative and each message is unique. The uniqueness of each message is guaranteed by the unique order token issued by a merchant. If two identical messages arrive, whichever arrives later will be dropped without any effect to the application (this assumes that replay causes duplicates of the initial messages and those duplicates always arrive after the initial message). (iii) Modification: Any unauthorized modification of each of the eight messages will be detected by their message digest. However, it has been known that the attackers can perform man-in-the-middle attacks to intercept Diffie-Hellman key exchange algorithm. This problem can be prevented by confirming the identity of the merchants, shipping carriers, and the credit card companies using their digital certificates in the application level. (iv) Masquerading: Masquerading merchants, shipping carriers or credit card companies by external attackers is impossible since the correctness of their public keys is guaranteed by their digital certificates in the application level. If an attacker tries to take over an ongoing transaction, by masquerading an existing customer, the attacker needs the order token, which is ed by a merchant s, a shipping carrier s, credit card company s or a customer s private key. (v 1 ) Traffic analysis between a customer and a merchant: We assumed that external attackers have access only to the packet headers, but not to their payload field when transport-layer secure connections are used. Since the merchant s network address may identify the merchant (and what business the merchant does), it is important to make sure that customer s network address does not identify the customer. If the above conditions are met, the traffic analyses will not be possible. (v 2 ) Traffic analysis between a merchant and a carrier: From the network addresses of a merchant and a shipping carrier, they can be identified easily from their network addresses. However, determining the merchant and the shipping carrier will not reveal who is the customer. This satisfies our zero-leak requirement because anonymity of the customer is still preserved. (v 3 ) Traffic analysis between a merchant and a credit card company: In the same was as v 2, anonymity of the customer will be preserved as long as the transport-layer connections are used for ZLA. For bug exploits by the external attackers, since none of the three servers holds complete information for each transaction, an external attacker who manages to access the data stored at a server still can not obtain complete information about a transaction by the same reasons for the internal attackers. 4.2 Evaluations of ZLA on queuing delay and throughput The online shopping web site shown in Figure 1 was implemented using ZLA. Its prototype was evaluated for the response time and the throughput when the workload from customers was changed. The workload was controlled by changing the time interval between two transactions generated at the customer computer. Each customer s request that consisted of the eight message exchanges was treated as a transaction. The testbed consisted of an isolated local area network with one computer for each of the three servers and a customer. The merchant server consisted on a Intel Core 2 Quad CPU Q6600 at 2.4 GHz. The shipping carrier, the credit card company, and customer s computer were all Intel Pentium 4 CPU at 3.2 GHz each. All three servers were available for SSL2/3 and TSL1 clients and all provided 4096-bit 3DES cipher block chaining (CBC) certificates to clients. In CBC mode, each block of plain text was XOR'd with the previous ed block before itself being ed. This ensured that blocks were interdependent and not subject to dictionary attacks. 3DES ed the data once using DES, performed decryption with a second arbitrary DES key, and re-s the data using a third arbitrary DES key. Using the testbed we built, we performed the following experiments: Experiment Definition: The effect of workload to queuing delay and the throughput of the transactions were measured and analyzed. The merchant server logged the start time (T S : arrival of message ) and the end time (T E : arrival of ) of a transaction. We first measured base transaction turnaround time (T BASE ) as T BASE = T E -T S when only one transaction was requested by a customer. We then measured T E -T S (= T hereafter) for each transaction when multiple transactions were requested. We applied Poisson

7 distribution to randomly generating the transactions. We tested 14 different transaction intervals: 0.1ms, 1ms, 10ms, 50ms, 100ms, 125ms, 150ms, 175ms, 200ms, 225ms, 235ms, 250ms, 300ms, and 500ms. Each experiment consisted of n transactions (n=100) and we repeated the same experiment m times (m=20). We calculated the average queuing delay as: m n ( T, i, j) m + n j= 0 i= 0 (1) where (T, i, j ) indicates T of the i-th transaction in an experiment for its j-th run. Finally, we calculated the average of the averages for the 20 runs of an experiment. For transaction throughput, we calculated how many transactions were completed at the merchant server (arrivals of message ) per second and averaged them for the 20 runs of the same experiment. average queuing delay (milliseconds) (a) (b) Existing method Zero-leak architecture (w/ certificate cache) Zero-leak architecture (w/out certificate cache) average inter-transaction intervals (milliseconds) Figure 6 Results of the queuing delay analysis completed transactions per second 9 8 (α) (β) (a) (b) Existing method Zero-leak architecture (w/ certificate cache) Zero-leak architecture (w/out certificate cache) average inter-transaction intervals (milliseconds) Figure 7 Results of the throughput analysis Using the experiment testbed and configurations above, we measured T for transactions in the existing method, ZLA without certificate caching, and ZLA with certificate caching. In the existing method, none of the message contents was ed against the merchant. In certificate caching, the client computer already had the digital certificates for all the three servers, while the certificate were first downloaded by the client at the beginning of an experiment in without certificate caching. Analysis #1 ( queuing delay analysis ): Figure 6 shows the observed queuing delay in the experiment. We observed that takeoff points of the queuing delay were 125ms interval (i.e., 8 transaction per second) and 225ms (4.44 transactions per second) for existing method (indicated by (a) in the figure) and ZLA without certificate caching ( (b) in the figure). Its ratio was 125:225 = 1.0:1.8. We did not observe meaningful effect from caching certificates. The average queuing delays at 0.1ms transaction interval were 15.8ms and 29.4ms for the existing method and ZLA without certificate caching (their ratio is 15.8:29.4 = 1.00:1.86). Analysis #2 ( throughput analysis): Figure 7 shows the observed throughput in the experiment. The peak throughput for the existing method was 7.8 transactions per second ( α in the figure) and it was 4.2 for ZLA without certificate caching ( β in the figure). Their ratio is 1: Conclusions The proposed ZLA is designed to protect the customers private information in online e-commerce applications from malicious uses even in the worst cases, where the internal security administrators become attackers. This is a challenging goal since there is a regulation in most of the countries that obligates the e-commerce providers to investigate the details in transactions (such as U.S. Code 12, Section 1929). To achieve the goal, we designed and developed a new architecture for e-commerce applications, called ZLA (Zero Leak Architecture). The ZLA s core concept is to split customers transaction information to three different parties in such a way that none of them has complete information about each transaction. Complete information for a transaction can be reconstructed only if the three parties collaborate, which should happen only when the law enforcement organization requires the three parties to collaborate. We described how the proposed ZLA provides protections against both external and internal attackers for three different categories of attacks: message interceptions, bug exploits and direct accesses. We evaluated the overhead of the ZLA from the viewpoints of the queuing delay and the throughputs of the transactions when workload to a merchant server was increased. The results of the performance analyses suggest that the ZLA s overhead in both queuing delay and throughput is a factor of around 1.8 (longer queuing delay by a factor of 1.8 and less throughput by a factor of 1.8). These results suggest that, with 1.8 times more computational power and faster networks, ZLA will provide equivalent operational performance of queuing delay and throughput to the existing unsecure systems, while the ZLA will significantly reduce the possibility of private information leaks from e-commerce servers. Along with the still-existing Moore s law, the hardware overhead will be most probably justifiable. The recovery cost, especially from large-scale customers information leaks, will be

8 more than the hardware cost in the future. In many such cases, they will also significantly damage the reputation of the companies, which adds to the cost of recoveries. References [1] Hiroshi Fujinoki, Jacob W. Keister, Clinton W. Bandy, and Steven R. Lickenbrock, SoKey: New Security Architecture for Zero-Possibility Private Information Leak in Social Networking Applications, Proceedings of IEEE Communications Quality and Reliability Workshop, pp. 1-6, May [2] Retention of records by insured depository institutions, the U.S. Code Online via GPO Access, pp , TITLE 12-BANKS AND BANKING, CHAPTER 16-FEDERAL DEPOT INSURANCE CORPORATION, Laws in effect as of January 3, URL: getdoc.cgi?dbname=browse_usc&docid=cite: +12USC1829b [3] Laszlo Hars, Discryption: Internal Hard-Disk Encryption for Secure Storage, Computer, vol. 40, no. 6, pp , [4] Bryan Parno, Jonathan M. McCune, Dan Wendlandt, David G. Andersen, and Adrian Perrig, CLAMP: Practical Prevention of Large-Scale Data Leaks, Proceedings of IEEE Symposium on Security and Privacy, pp , May [5] Umut Uludag, Sharath Pankanti, Salil Prabhakar, and Aniket K. Jain, Biometric Cryptosystems: Issues and Challenges, Proceedings of the IEEE, vol. 92, no. 6, pp , [6] Ge Zhang and Chao Zhang, A Biometric-based Framework for Digital Rights Protection, Proceedings of the International Conference on Signal Processing, vol. 3, pp , [7] David Mazières and Dennis Shasha, Don t Trust Your File Server, Proceedings of the Hot Topics in Operating Systems, pp , May [8] Uif T. Mattsson, A Practical Implementation of Transparent Encryption and Separation of Duties in Enterprise Databases: Protection against External and Internal Attacks on Databases, Proceedings of the IEEE International Conference on E-Commerce Technology, pp , [9] IBM Corporation, An overview of the IBM SET and the IBM Commerce Point Products, ew.html, June [10] Marc Rennhard, Sandro Rafaeli, Laurent Mathy, Bernhard Plattner, and David Hutchison, Towards Pseudonymous e-commerce, Electronic Commerce Research, vol. 4, pp , [11] Boualem Benatallah and Hamid R. Motahari Nezhad, Service Oriented Architecture: Overview and Directions, Advances in Software Engineering, vol. 5316, pp , [12] Mike P. Papazoglou and Willem-Jan van den Heuvel, Service Oriented Architectures: Approaches, Technologies and Research Issues, The International Journal on Very Large Data Bases, vol. 16, pp , [13] Doug Tygar, Atomicity versus Anonymity: Distributed Transaction Electronic Commerce, Proceedings of the International Conference on Very Large Databases, pp. 1-12, August [14] Xuan Zhang, Qinlong Huang, and Peng Peng, Implementation of a Suggested E-commerce Model Based on SET Protocol, Proceedings of ACIS International Conference on Software Engineering Research, Management and Applications, pp , May [15] Dimitrios Lekkas and Diomidis Spinellis, Implementing Regular Cash with Blind Fixed- Value Electronic Coins, Computer Standards & Interfaces, vol. 29, no. 3, pp , March [16] D. Chaum, A. Fiat, and M. Naor, Untraceable Electronic Cash, Proceedings of Advance in Cryptography, pp , [17] Ziba Eslami and Mehdi Talebi, A New Untraceable Off-line Cache System, To appear in Electronic Commerce Research and Applications, 2010.