As already discussed in Section 2.1.1, a well-known business model for the 2-party web-based service is the Application Service Provider (ASP). An ASP "deploys, hosts and manages access to a packaged application to multiple parties from a centrally managed facility. The applications are delivered over networks on a subscription basis. This delivery model speeds implementation, minimizes the expenses and risks incurred across the application life cycle, and overcomes the chronic shortage of qualified technical personnel available in-house" [IDC, 1999]. For these reasons, the ASP model has significant business impact and was forecasted annual growth rates between 75% and 89% [Mizoras, et al., 2001; Terdimann, et al., 2000].

Speaking in terms of the definition in Section 2.1, the ASP is the service provider and the ASP customer is the data holder (who is, in this case, the service user at the same time). We will refer to this business model throughout the rest of the chapter.

Yet one reason that inhibits the wide spread use of this new kind of services is the question of data ownership and confidentiality. Classical Enterprise Resource Planning (ERP) installations that were based on the purchase and local installation of software and hardware ensured that confidential data did not leave the customer company's premises. In the ASP model this is no longer the case. Using software services over the Internet requires the customer to transfer potentially sensitive business data to the service provider which may include internal financial figures, product launch schedules and the like.

This obviously raises security concerns on behalf of the customers who urge the ASP to use firewalls, dedicated servers and encryption of the communication channel to protect their most confidential business data. These protective measures may, however, not suffice as the data is still required in unencrypted form for the ASP to process and to deliver the actual service results. In Table 3-1, we describe four different kinds of attacks. With exception of the first threat, an external attack against the customer's database, prevention along the conventional lines is very difficult.

#

Threat

Description

Risk indicators

1

External attack against the customer's database

External attacks directed at the service provider's database are still possible, and the risk is hard to estimate

Audit of the ASP's system security

2

Malicious ASP staff

Malicious staff on the provider's side (bribed or disgruntled employees etc.) may want to cause harm to their company and its customers

Fluctuation rate of ASP employees

3

Incompetent ASP staff
"Social Engineering"

Incompetent staff on the provider's side may unintendedly grant data access to unauthorized parties

Staff / workload ratio

4

Bankruptcy of the ASP or change of ownership

Bankruptcy or acquisition of the ASP leads to the transfer of the customer's business data, in the worst case to a direct competitor of the customer

Financial and competitive position of the ASP

Table 3-1: Threats to confidential business data of ASP customers

External attacks are usually accounted for with adequate cryptographic and organizational measures but cannot be completely ruled out. The damage caused by disgruntled or malicious ASP staff is even harder to predict and prevent. The CSI/FBI Computer and Crime Survey [CSI, 2003] shows that disgruntled employees are the most likely source of attacks, even more likely than independent hackers or competitors (86% vs. 74% / 53%, resp.). The risk of an attack by disgruntled employees is hard to measure. A possible indicator might be the number of employees who leave the ASP company per year (fluctuation rate).

Although applications like online banking and online book stores have become ubiquitous, people working in sensitive areas in IT companies are still vulnerable to trivial attacks called social engineering [Rusch, 2004]. One example of social engineering is walking into an office, telling an unsuspecting person that you need to fix a problem with the intranet and therefore need her password. The probability of getting the password is higher than one might expect.

Finally, the potential consequences of bankruptcy and/or change of ownership of the provider may be serious. Online retailer amazon.com's privacy statement clearly states that customer data is sold in the case of a change of ownership.

“…we might sell or buy stores, subsidiaries, or business units. In such transactions, customer information generally is one of the transferred business assets... Also, in the unlikely event that Amazon.com, Inc., or substantially all of its assets are acquired, customer information will of course be one of the transferred assets…” [Amazon.com, 2004]

Technically, no corporate purchase can change the validity of a privacy policy that the former company has agreed to, but even if the new data owner is legally bound to a privacy policy, enforcing this in an international law suit is often infeasible. In the worst case, a direct competitor of one of the provider's customers might end up owning all the outsourced business data. However unlikely, this scenario has considerable potential to scare customers.

In this section, we present a service architecture that allows for processing data with a very high level of privacy protection. Sensitive data is not only withheld with respect to non-trusted third parties, but also to the service provider itself. The service provider will not dispose of any unencrypted customer data at any time. Contrary to the concept of [Asonov and Freytag, 2002], no hardware equipment is involved. Our approach requires the service provider to work directly with encrypted data.

Following the approach of public key infrastructure first proposed by [Rivest,et al., 1978; Rivest, et al., 1978], the basic idea is to transform the sensitive data with the help of a secret key only known to the customer. The service provider uses the corresponding public key in order to process the encrypted data. Without the private key, the service provider cannot see any sensitive information in plaintext (as is intended by the customer). Without the public key, it cannot even compute the data.

From an infrastructure point of view, the architecture requires the following actions.

• The creation of a private key and its safe-keeping.

• The creation of a public key and distribution of it to the service provider.

• Equipment of customer software with the transformation algorithm.

• The adaptation of the service provider's business logic such that encrypted data can be processed.

How these requirements are dealt with in practice is discussed in Section 3.8.3. The volume of infrastructure requirements implies that the approach is more suitable for Application Service Provider (ASP)-like solutions which allow at least for some customization than for fine-grained, standardized web services. We use the following terminology.

d _i , i=1..nSensitive input data from the data holder

pPrivate key of the data holder

qPublic key (given to the service provider)

S:(d _{i ,} d _j ) →S(d _{i ,} d _j )Operation / Service on plain customer input data

T _p : d _i →T _p (d _i )= t _i Encryption / Transformation function

S':(t _i , t _j ) →S'(t _{i ,} t _j )Operation / Service on encrypted customer data

T _p ^-1 : t _i →T _p ^-1 (t _i )Decryption / Retransformation function

Figure 3-1: A sketch of the proposed service architecture

Figure 3-1 describes the general service procedure. The customer wants the service provider to perform some service S on the confidential data D she provides. After installing the key infrastructure, critical data is marked up as “sensitive” and the application running on the customer machine encrypts it using the provided transformation scheme T and the private key p. The server, who only sees encrypted data, now uses the public key q to perform the requested service S. Once the server has performed its service, the encrypted pseudo-solution S(T _p (D)) is retransferred to the customer who applies a re-transformation (usually T _p ^-1

Note that the retransformation is not necessarily the inverse function T-1. For reasons of simplicity, we work just with T-1 throughout the rest of the chapter.

The whole procedure is summed up in Figure 3-2.

Figure 3-2: Steps of the proposed service architecture

The “transformation schemes” T that we referred to in the previous section are actually encryption functions in the cryptographic terminology. These functions map plaintext, the readable sensitive data, to ciphertext, its encoded counterpart. Cryptanalysts determine the security of an encryption scheme in terms of its resistance against six attacks of increasing scale. [Stallings, 1999] and [Schneier, 1996] give an overview of the different attacks that we summarize in Table 3-2.

Type of Attack

Known to Attacker

Difficulty of attack

No encryption algorithm

-Ciphertext to be decoded

Most
difficult

|

Ciphertext only

-Ciphertext to be decoded

-Encryption algorithm

Known plaintext

-Ciphertext to be decoded

-Encryption algorithm

-One or more plaintext-ciphertext pairs formed with the secret key

Chosen plaintext

-Ciphertext to be decoded

-Encryption algorithm

-Plaintext message chosen by attacker, together with its corresponding ciphertext generated with the secret key

Chosen ciphertext

-Ciphertext to be decoded

-Encryption algorithm

-Purported ciphertext chosen by attacker, together with its corresponding decrypted plaintext generated with the secret key

Chosen text

-Ciphertext to be decoded

-Encryption algorithm

-Plaintext message chosen by attacker, together with its corresponding ciphertext generated with the secret key

-Purported ciphertext chosen by attacker, together with its corresponding decrypted plaintext generated with the secret key

Least
difficult

Table 3-2: Difficulty of cryptographic attacks

The architecture presented in this Chapter is based on a particular class of encryption functions, so-called privacy homomorphisms (PHs). [Rivest,et al., 1978] introduce them as “encryption functions that permit encrypted data to be worked with without preliminary decryption of the operands”. We now define the homomorphic property of privacy homomorphism.

Definition (Homomorphic encryption function)

An encryption function T _p : d _i →T _p (d _i ) is homomorphic with regard to a Service S iff ∀d _i , d _j ∈ dom(T): T ^-1(S'(T(d _i ), T(d _j )) = T ^-1 (T(S(d ₁ , d ₂ ))) = S(d ₁ , d ₂ )

Referring to Figure 3-3, this means that it does not matter whether you first perform the service on plaintext and then encrypt the data or whether you first encrypt the confidential data and perform the service on encrypted data. However, working with encrypted data imposes significant restrictions on the extent of feasible operations on the underlying data. There are two fundamental findings with important implications.

First, a secure encryption scheme can never preserve order. This means that for a given set of attribute values such as e.g. (3; 17; 31; 35; 42), no secure encryption scheme allows for determining the order (T _p (3), T _p (17), T _p (31), T _p (35), T _p (42)) on the ciphertexts [Rivest,et al., 1978]. An important conclusion is that attributes in encrypted databases cannot be sorted at all.

Second, the multiplication operation can be preserved at a higher level of security than addition. On the scale that measures the security of encryption schemes (see Table 3-2), the maximum level of security for addition-preserving encryption schemes is known-plaintext-resistance [Brickell and Yacobi, 1987]. This is less secure than the maximum level for multiplication-preserving ones, chosen-ciphertext resistance. The implication is that encryption schemes that preserve all basic arithmetic operations can reach at most the lower additive security level.

Figure 3-3: The basic idea of a privacy homomorphism

To employ PHs in service environments, the basic idea would be to transfer the encrypted confidential data T(d ₁ ) and T(d ₂ ) to the service provider instead of the plaintext pair d ₁ and d ₂ . The provider then computes the pseudo-solution S'(T(d ₁ ), T(d ₂ )) which is, due to T 's homomorphic property, equal to T(S(d ₁ ·d ₂ )). Applying the inverse function T ^-1 then decrypts the pseudo-solution and yields the desired result S(d ₁ ,d ₂ ). The three solid arrows in Figure 3-3 clarify this procedure.

Example: The sample PH that [Rivest,et al., 1978] describe yields that the multiplicative product of two encrypted numbers is equal to the encryption of the corresponding plaintext product.

T(d ₁ )·T(d ₂ )= T(d ₁ ·d ₂ )

Applying the inverse function gives

T ^-1(T(d ₁ )· T(d ₂ ))= T ^-1(T(d ₁ · d ₂ ))= d ₁ · d ₂

In this case, the provided service S is the multiplication of numbers.

If one considers “multiplication” as a simple kind of service, the encryption function T thus guarantees a very high level of privacy protection because the customer may use the service while revealing neither the factors nor the result to the service provider.

Whereas this multiplicative PH is a very secure one (chosen-ciphertext-resistant), performing addition on encrypted data turns out to be a more complicated issue. [Ahituv, et al., 1987] show that an additive PH may reach at most known-plaintext-resistance. [Brickell and Yacobi, 1987] are the first to present an R-additive PH that permits the addition of up to R numbers with ciphertext-only-resistance. Finally, [Domingo-Ferrer and Herrera-Joancomarti, 1999] present a PH allowing all field operations (addition, subtraction, multiplication and inverse multiplication) on an arbitrary number of ciphertexts. Though it is ciphertext-only resistant, it would still force the potential attacker to acquire plaintext information from the customer in order to be successful, which transfers at least some of the responsibility from the service provider to the customer (see [Boyens and Günther, 2002]). If a plaintext-ciphertext pair has been known to the attacker, it will be difficult for the customer to deny at least part of the responsibility for the break-in. A practical solution for this problem is to codify these responsibilities in the service contract. The customer would then be at least partially responsible for a potential break-in. See Table 3-3 for an overview of existing privacy homomorphisms.

PHs have been employed for very specific purposes such as multi-application smart-cards [Domingo-Ferrer, 1997], signature schemes [Johnson, et al., 2002] and electronic voting [Asonov,et al., 2001]. The field of research with most potential impact however is the field of securely outsourced database services, see [Damiani,et al., 2003; Hacigumus,et al., 2002; Hacigumus,et al., 2002; Ozsoyoglu, et al., 2003] and our discussion in Section 2.2.3.2.

Authors

Service S

Secure against

Remarks

[Rivest,et al., 1978]

Chosen-ciphertext attack

Based on RSA

Preserves equality

[Brickell and Yacobi, 1987]

Ciphertext-only attack

First R-additive scheme

[Domingo-Ferrer, 1996]

Known-plaintext attack

[Domingo-Ferrer and Herrera-Joancomarti, 1999]

Ciphertext-only attack

Supports all field operations

Table 3-3: Overview of existing privacy homomorphisms

We will now describe the PH in use with the proposed architecture.

Now that the basic service idea and the corresponding transformation scheme are introduced, we will discuss which actual services the service provider is able to carry out on the modified information he possesses. Naturally, encrypted data cannot be processed with the same range of operations as unencrypted data. We will distinguish between two different elementary service types.

The first elementary service type concerns basic database queries, such as retrievals and updates. We will analyze the basic relational operators concerning their suitability for handling encrypted records and give examples in Section 3.6.1.

The second elementary service type consists of the basic arithmetic operations, addition and subtraction, multiplication and division. We will show to what extent and on which kind of plaintext data these operations can be applied in Section 3.6.2.

In this section, we will discuss a few sample services based on the encrypted employee and monthly_accounttables presented in the previous paragraph. We think that HR data is particularly appropriate for this purpose, for two reasons. First, sensitive data can be found in various forms such as regular wages and bonus payments, absent and overtime hours, and sometimes even church affiliation. Second, HR Management tools are often subject to outsourcing and therefore represent a suitable application field for the proposed architecture.

S ₁ : Mean monthly absent hours in specific departments

Formally, this figure is calculated as the average µ _i over the absent hours of the employees e in department dep1

µ_dep1=(Σ_{(e.department= dep1)} e.absence) / |{e | e.department= dep1}|

In order to calculate the mean absent hours for the ‘Finance’ department in August, the following actions are required on the provider’s part.

1) Retrieve the absence attribute of all employees in the finance department.

SELECT absence AS department_absence FROM employee e, monthly_account m WHERE (e.employee_no = m.employee_no) AND (e.department = T_p(‘Finance’))
Note that this query includes a join over encrypted data, namely the employee number in both tables.

2) Calculate the sum over department_absence.

sum_{‘Finance’}= Σ_{(e.department= Tp(‘Finance’)} e.absence

3) Return the encrypted sum_{‘Finance’} and the plain record_count_{‘Finance’}= |{e | e.department= ‘Finance’}| to the customer.

4) Finally, the customer decrypts the sum and divides it by the count to obtain the result µ_dep1.

µ _{‘Finance’}= T _p ^-1(sum_{‘Finance’}) / record_count_{‘Finance’}

Note that lacking the possibility of dividing the two numbers leads to at least some involvement of the customer. A good example for a service that does not need any kind of customer intervention is the multiplication of matrices, as only multiplication and addition is required.

S ₂ : Standard deviation of payments among departments

This metric measures the income disparities among different departments. We will use a service similar to S₁ to calculate µ_i ^* , the mean incomes per department.

σ _all =((Σ_{(departments i)} |µ _all - µ _i ^*|²) / |{ i | dep_i is department }|) ^½

with µ _all=(Σ_{(departments i)} µ _i ^*) / |{ i | dep_i is department }|

1) Compute the mean payments µ _i ^*for all departments using a similar service to S₁.

2) Compute the average µ _all over all µ _i ^* 's using S₁ again.

3) Compute the sum of the squared differences: squared_dev:= Σ_{(departments i)} |µ _all - µ _i ^* |².

• 4) Return squared_dev and the number of departments department_count to the customer.

5) The customer decrypts the squared deviation sum, divides it by the department count and draws the square root.

Again, some customer involvement is required. However the major part of the calculation is done by the provider, which especially pays off if the underlying databases are large.

The proposed architecture should not be considered as a “one-size-fits-all” solution that works for every kind of network services. It focuses on applications that require some basic database and arithmetic operations on sensitive data. It is especially valuable for service bundles whose main value lies in their variety and their completeness in many smaller, granular services. In other words, wage accounting services are more suited for the architecture than for complex data mining metrics such as the ones proposed in [Cutler and Sterne, 2000].

Different attributes require different encryption measures. The proposed algorithm is best suited for numbers that will later be processed with arithmetic operators. Primary key values in contrast often just serve as identification means, and are not subject to later processing. Hence it would be useful to encrypt these values with a very secure cryptographic algorithm such as RSA [Rivest,et al., 1978]. As the private key p has already been chosen, it can be used to encode the key values with this alternate algorithm.

Regarding this, the proposed software solution is not suited for complex calculation problems, but for the aggregation of many single, rather simple services. A good example is the calculation of aggregate HR figures that we discussed here. Speaking in terms of the trade-off idea sketched in the introduction, the trade-off in this approach is that for a certain kind of security, the user can only have a limited number of services S(D) from the service provider. He has to give up a certain amount of security to obtain a more extensive service offering.

Complementary to the practical reasoning, there is also theoretical work especially on the question whether or not SQL algebra can be securely outsourced. At least a part of the SQL algebra can be mapped to logical operations such as OR, AND, NOT. However, there does not yet exist a homomorphic bit-encryption scheme that is homomorphic to the complete set of these logical operations [Maurer, 2004]. But even if such an encryption scheme existed, it is not sure whether the entire SQL algebra could be mapped to these logical operations. The results that [Fischmann and Günther, 2003] derive from the related code obfuscation approach by [Barak, et al., 2001] suggest that mapping SQL algebra on encrypted data is not entirely possible. Further research is needed to (a) determine whether the complete set of logical operations can be covered by a homomorphic bit-encryption scheme and to (b) determine which parts of the SQL algebra can be mapped to logical operations.