Secret sharing approach for securing cloud-based pre-classification volume ray-casting

Abstract

With the evolution in cloud computing, cloud-based volume rendering, which outsources data rendering tasks to cloud datacenters, is attracting interest. Although this new rendering technique has many advantages, allowing third-party access to potentially sensitive volume data raises security and privacy concerns. In this paper, we address these concerns for cloud-based pre-classification volume ray-casting by using Shamir’s (k, n) secret sharing and its variant (l, k, n) ramp secret sharing, which are homomorphic to addition and scalar multiplication operations, to hide color information of volume data/images in datacenters. To address the incompatibility issue of the modular prime operation used in secret sharing technique with the floating point operations of ray-casting, we consider excluding modular prime operation from secret sharing or converting the floating number operations of ray-casting to fixed point operations – the earlier technique degrades security and the later degrades image quality. Both these techniques, however, result in significant data overhead. To lessen the overhead at the cost of high security, we propose a modified ramp secret sharing scheme that uses the three color components in one secret sharing polynomial and replaces the shares in floating point with smaller integers.

1 Introduction

With the advances in cloud computing, organizations are outsourcing 3D volumetric data rendering tasks to third-party cloud datacenters [12, 21, 22, 25]. To this end, datacenters are being used for extracting iso-surfaces and rendering the extracted iso-surfaces in the case of indirect volume rendering [12, 25], and performing volume ray-casting in the case of the direct volume rendering [21, 22]. Compared to conventional server-side rendering, such cloud-based rendering is more scalable, more economical, offers better computing resources, and can produce lower visualization latency by performing rendering in a datacenter closer to the client location.

Security and privacy, however, become major issues in cloud-based rendering. Disclosing important data/image to a third-party cloud provider leads to the concerns of confidentiality, integrity, and availability [15]. For example, an adversary can access a datacenter that stores medical data/image of patients and misuse the information in several ways. The adversary can: (i) sell the disease information to interested parties such as insurance companies; (ii) modify a medical image to provide misleading information to doctors; (iii) leak the medical information of a prominent person to the public and media. Due to these potential threats, laws, such as the HIPPA act in the USA, the PIPED act in Canada, and the Data Protection Directive in European countries, are enacted to protect the information of their citizens.

One can protect these personal volumetric data from datacenters by hiding them with a cryptosystem. To render these hidden volumetric data, however, the cryptosystem must be homomorphic to the rendering operations so that the rendered images can be recovered from the hidden image(s). In other words, if the cryptosystem hides secret volume data V with an operation H(⋅), a datacenter renders the data with an operation R(⋅), and a user recovers the secret rendered image from the hidden rendered image R(H(V)) with an operation H ⁻¹(⋅), then the condition

$$R(V) \approx H^{-1}(R(H(V))) $$

must hold. To our knowledge, there is no cryptosystem that can fulfill this requirement with acceptable overhead [19]. Somewhat homomorphic cryptosystems, which can perform certain homomorphic operations such as addition and scalar multiplication with low overhead, however, are available [2, 10]. Among the main two types of somewhat homomorphic cryptosystems: (i) secret sharing-based schemes, and (ii) public key encryption-based schemes, secret sharing-based schemes can provide better data confidentiality [1]. Therefore, secret sharing is often used to hide highly important information such as cryptographic keys [9], military data [5] etc. Furthermore, secret sharing schemes, without using an additional cryptosystem, can simultaneously provide data confidentiality, data integrity, and data availability. Among the secret sharing schemes, Shamir’s secret sharing is commonly used since it is more efficient than other secret sharing schemes such as Blakley’s secret sharing and Chinese Reminder Theorem-based secret sharing schemes [16].

To address the security and privacy concerns, this paper proposes a framework for hiding color information in cloud-based volume rendering. We focus on pre-classification volume ray-casting (or its variant) as the data rendering technique (operation R) and based our cryptosystem (H and H ⁻¹) on Shamir’s secret sharing [24]. Our framework hides the color information of 3D volume data, typically used to annotate important information such as disease information [7]. We do not hide opacities, which can disclose shape of the 3D object. We assume that discloser of the shape divulge little confidential information in the absence of colors.

The core idea of the proposed framework is to use Shamir’s secret sharing to create n shares of the volume data at the server, and send each share volume (i.e., share of secret volume) to a datacenter. The datacenter, upon receiving a rendering request, then renders a share image (which colors are hidden) using pre-classification volume ray-casting, and sends the rendered image to the client. The client then recovers the secret image from at least k share images from k datacenters. The use of Shamir’s secret sharing in conjunction with volume ray-casting, however, introduces a new challenge as the modular prime operation of secret sharing is incompatible with the floating point operation of volume ray-casting.

We can address this incompatibility issue with two approaches: either (i) exclude modular prime operation from Shamir’s secret sharing [8, 17], or (ii) convert the floating point operation of pre-classification volume ray-casting to fixed point operations [3]. We have previously published the former approach, called Secure Rendering by Modification of Shamir’s Secret Sharing (SR-MSSS) [17]. SR-MSSS is less secure than Shamir’s Secret Sharing, as excluding the modular prime operation means that it is not operating in a finite field, and is therefore not perfectly secure (i.e., it can lose some information about the secret color to datacenters). On the other hand, the latter approach, called Secure Rendering by Modification of Pre-classification Volume Ray-casting (SR-MPVR), can introduce rounding error that can lead to loss of information in the rendered image.

Both these techniques create three different color shares for the red, green, and blue color components of the 3D volumetric data. Further, representing the share of a color component by either a float or by a large integer incurs high data overhead. For applications requiring minimal overhead at the cost of security, we propose a third technique called Secure Rendering by Ramp Secret Sharing (SR-RSS) that improves upon SR-MSSS by first replacing modified Shamir’s secret sharing with a modified (3, 4, 5) ramp secret sharing to create only one share for red, green, and blue color, and then restricting the value of a share (which is a float) to a smaller number and representing it with an integer.

Experiments and analyses show that all of our three approaches hide important color information in datacenters and incur insignificant computation overhead. The data overhead, image quality, and the level of security of these techniques, however, differ with the choice of the technique. SR-MPVR provide perfect secrecy, but incurs significant data overhead and renders lossy image. SR-MSSS renders lossless image, but loses some information about the secret to datacenters and incurs significant data overhead. Finally, SR-RSS incurs the lowest overhead among the three, but is the least secure and renders lossy image.

There are three major contributions of this paper.

• 1. First, we integrate Shamir’s secret sharing with the pre-classification volume ray-casting such that the color information of data/image is hidden from the rendering site. Pre-classification volume ray-casting consists of a set of primitive operations such as addition, multiplication, scalar multiplication, division, exponentiation etc. Therefore, integration of Shamir’s secret sharing, which is homomorphic to only addition and scalar multiplication, to the rendering pipeline is challenging. We address this challenge by pre-processing the non-homomorphic operations of the ray-casting algorithm, and by adjusting the rendering such that color rendering can be realized only by additions and scalar multiplications.

• 2. Second, we modify either the Shamir’s secret sharing or the pre-classification volume ray-casting to make them compatible with each other. We analyze the loss in security due to the modification of secret sharing and the loss in image quality due to the modification of volume ray-casting, and show that both these losses can be acceptable.

• 3. Finally, we optimize our schemes, and provide a solution for applications requiring low overheads at the loss of some security.

The rest of this paper is organized as follows. In Section 2, we discuss the related work. Section 3 presents the attacker model. Section 4 provides an overview of pre-classification volume ray-casting and Shamir’s secret sharing. In Section 5, we modify pre-classification volume ray-casting to make it compatible with Shamir’s secret sharing. In Section 6, we propose our secure cloud-based volume rendering framework. Section 7 provides experimental results of the proposed framework, and analyzes its security and performance. Section 8 concludes.

2 Related work

In this section, we review existing cloud-based rendering techniques to highlight their growing importance, and then extend our discussion to the techniques addressing security and privacy issues in cloud-based imaging.

Recently, cloud-based rendering has drawn the attention of both researchers and enterprises. For example, using Azure cloud, Dorn et al. [6] proposed an adaptive data rendering framework that, according to the requirement, performs volume ray-casting either at a cloud datacenter or at the client. By echoing the concerns of scalability in server-side rendering and resource availability in client-side rendering, Vazhenin proposed yet another cloud-based rendering framework [28]. Similarly, enterprises such as NVIDIA Inc. [21], Sinha system [25], KDDI Inc. [12], NICE [20] etc. have started offering cloud-based 3D medical data rendering frameworks to hospitals.

Research addressing security and privacy issues in cloud-based rendering is a demanding yet little-explored area. To the best of our knowledge, we are the first to propose secure cloud-based volume rendering frameworks using pre-classification volume ray-casting [17] and post-classification volume ray-casting [18]. However, the security and privacy concerns in certain cloud-based computation, such as low-pass filtering [13], image de-noising [23] etc., have been addressed using Shamir’s secret sharing as the cryptosystem. The use of Shamir’s secret sharing to securely execute a new algorithm (such as pre-classification volume ray-casting) presents a new set of challenges since the algorithm’s workflow must be adjusted in such a way that even after hiding additions and scalar multiplications, important information about the input and the output must be kept hidden. Similarly, the security and privacy issues in cloud-based data/image storage, have been promptly addressed in two possible scenarios: when a single datacenter is used, and when multiple datacenters are used [1, 11, 27, 29]. In the case of the use of a single datacenter, public key encryption techniques or watermarking have been applied to protect the data/image stored in a datacenter [11, 27, 29], and in the case of the use of multiple datacenters, the secret sharing scheme has been used to distribute the secrecy among more than one datacenters [1]. For a complete list of existing cryptographic cloud storage systems, the reader can refer to AlZain et al.’s work [1], which concludes that the secret sharing-based cloud-based secure systems are more secure than the encryption-based systems. However, these cloud-based secure storage systems are designed for cloud-based archiving, and therefore use non-homomorphic cryptosystem such as watermarking, chaos-based encryption, AES, or a somewhat homomorphic cryptosystems such as Shamir’s secret sharing to hide data. Thus, these systems cannot be seamlessly extended to secure cloud-based rendering.

In this paper, we extend our earlier work on securing cloud-based pre-classification volume ray-casting framework [17]. Our previous work modified Shamir’s secret sharing to make it compatible with pre-classification volume ray-casting. In this paper, we instead modify pre-classification volume ray-casting, and use the modified ray-casting with unmodified secret sharing. Therefore, unlike our previous scheme, we can now offer perfect secrecy. Furthermore, we analyze the security and overheads of both these approaches, and optimize the previous scheme for applications seeking low overheads at the cost of high security.

3 Attacker model

We assume that both the server, which owns the secret volume data and outsources rendering operation to n datacenters, and the client, are secured (i.e., no adversary can access the server or the client). A datacenter, however, can be accessed by a malicious adversary, who can be either a malicious employee of the third-party cloud provider (which hosts the datacenter), or an outsider. Since the adversary is malicious, she can unlawfully read the content of a share volume data and/or share rendered image from a datacenter (confidentiality issue), tamper with the accessed share volume data or share rendered image (integrity issue), deny the share rendered image to the client (availability issue), or relate the identity of a patient to her data/image (privacy issue). We assume that the adversary, however, cannot access k (where, k ≤ n) or more datacenters at any point of time.

Our objective is to hide the volume data V from a datacenter using Shamir’s secret sharing H(⋅), and allow rendering operation R(⋅) on the hidden volume data H(V) such that: (i) an adversary cannot know the confidential color information from the share volume data H(V) or the share rendered image R(H(V)), (ii) a client can recover the secret image R(V) from at least k R(H(V))’s, (iii) a client can detect tampering on H(V) or R(H(V)) when n≥k, and (iv) a client will able to recover a R(V) even if n − k datacenters cannot participate.

4 Background

In this section, we will provide an overview of pre-classification volume ray-casting and Shamir’s secret sharing.

4.1 Pre-classification volume ray-casting

Volume ray-casting is one of the preferred technique to directly render volume data [26]. The main idea behind this technique is to project rays from each pixel of the image space on a given volume V, and find the color and opacity along each ray by mapping the physical properties of the object to optical properties (i.e., color and opacity). Volume ray-casting can be classified into pre-classification volume ray-casting and post-classification volume ray-casting.

Pre-classification volume ray-casting (Fig. 1), which is the focus of this paper, consists of the following rendering components: gradient and normal estimation, classification, shading, ray-projection, sampling, interpolation, and composition [14]. These components can be categorized into two main steps: the pre ray-projection step and the post ray-projection step. The pre ray-projection step consists of gradient estimation, classification, and shading, as they are performed before the projection of rays. This step finds the shaded color and opacity of each data voxel of V, and can be pre-computed independent of the view. The computed colors and opacity are typically stored in a look-up table. The post ray-projection step, on the other hand, consists of the components: sampling, interpolation, and composition. This step finds the color and opacity along each projected ray, and is performed at run time. In the following sections, we will discuss steps of post ray-projection rendering in detail.

Fig. 1

Conventional Pre-Classification Volume Ray-Casting

Sampling: In this step, a projected ray is sampled at c sample points s ₁, s ₂,..., s _c .

Interpolation: The color C _s and the opacity A _s of a sample point s are found by interpolating the colors (i.e., the shaded colors) and the opacities of eight neighboring voxels of s by

$$ C_{s} = \sum\limits_{v \in N(s)} C_{v}D_{v}, $$

(1)

and

$$ A_{s} = \sum\limits_{v \in N(s)} A_{v}D_{v}, $$

(2)

respectively, where N(s) is the set of neighboring voxels of s, $C_{v} \in \mathbb {N}$ is the given color of v, $A_{v} \in \mathbb {R}$ is the given opacity of v, and $D_{v} \in \mathbb {R}$, the interpolating factor of v, is obtained from the xyz-coordinate of s and the xyz-coordinates of each data voxel v∈N(s). When D _v is constant, interpolation requires only additions and scalar multiplications.

Composition: This step accumulates the colors and opacities of all the sample points to find the composite color and the composite opacity along a projected ray. Mathematically, the composite color C and the composite opacity A of the sample points s ₁, s ₂,..., s _c are defined as

$$ C = \sum\limits_{i=1}^{c} C_{s_{i}} O_{i} $$

(3)

and

$$ A = \sum\limits_{i=1}^{c} O_{i} $$

(4)

respectively, where O _i is defined as

$$ O_{i} = A_{s_{i}} \prod\limits_{j=i+1}^{c} \left(1 - A_{s_{j}}\right). $$

(5)

The composite color is then truncated to obtain the rendered color. Note that for constant O _i , composition can be performed only with additions and scalar multiplications.

In Appendix A, we have provided a simple example of pre-classification volume ray-casting.

4.2 Shamir’s secret sharing

Shamir’s (k, n) secret sharing is a cryptosystem that hides a secret by dividing it into n shares and recovers the secret by reconstructing it from at least k shares (k ≤ n).

4.2.1 Share creation

Given a prime number q and a secret $S \in \mathbb {Z}$, where, S < q, this step creates n shares of S by first defining a (k − 1)-degree polynomial

$$F(x) = (S + \alpha_{x} ) \bmod{q}, $$

where

$$ \alpha_{x} = \sum\limits_{i = 1}^{k-1} a_{i}x^{i} $$

(6)

and a _i < q is a random number in GF(q), and then using this polynomial to find the p ^th share of S by setting x = p.

4.2.2 Secret reconstruction

Given k distinct share numbers {x ₀, x ₁,…x _{k − 1}} and shares {y ₀, y ₁,…y _{k − 1}} such that y _i = F(x _i ), this step reconstructs the secret by first finding the (k − 1)-degree Lagrange interpolated polynomial L(x) by

$$L(x) = \sum\limits_{i=0}^{k-1} y_{i} l_{i}(x) \bmod{q}, $$

where $l_{i}(x) = {\prod }_{j=0, j \ne i}^{k-1} \frac {x - x_{j}} {x_{i} - x_{j}}$, and then solving L(x), which is equivalent to F(x) by the Unisolvence theorem.

Shamir’s secret sharing is homomorphic to addition and scalar multiplication [2]. In other words, if the participants hold shares of a set of secrets S = {S ₁, S ₂,..., S _r }, then without communicating amongst themselves, they can compute the shares of the secret ${\sum }_{i = 1}^{r} I_{i}S_{i}$, where I _i , for 1≤i ≤ r, is an integer. This property, however, cannot be used to hide operands of post ray-projection rendering operations of the pre-classification volume ray-casting, as the modular prime operation of secret sharing is incompatible with the floating point operation of ray-casting. We can address this issue either by omitting the modular prime operation from secret sharing (as we have proposed earlier [17]), or by converting a floating point to a fixed point by first rounding it off to d decimal places and then multiplying the rounded off value with K ^d.

Note that even though Chor and Kushilevitz’s secret sharing [4] can share a floating point number, their technique is not homomorphic to floating point number scalar multiplication (it is, however, homomorphic to addition and multiplication by integer scalar). Therefore, we cannot use this secret sharing for our framework.

5 Pre-classification volume ray-casting with fixed point operations

To make Shamir’s secret sharing compatible with pre-classification volume ray casting, we perform the arithmetic operations involved over a finite field, in integer domain, instead of floating point. In this section, we outline the steps that required this change and analyze the numerical precision required to bound the error in the resulting rendered color to within one (for a detail . Note that we only need to modify the floating point operations of post ray-projection rendering of colors. As we do not hide opacities, their rendering operations will not be modified.

5.1 Modifying interpolation

The interpolation of the colors (1) involves multiplying an integer C _v with a floating point D _v . We convert this multiplication to a fixed point operation as follows. Let x ^(d) be an integer obtained by first rounding off x to d decimal places and then multiplying the rounded value by 10^d. We have

$$ D_{v}^{(d)} = \left(D_{v} + \epsilon_{D_{v}, d}\right) \times 10^{d}, $$

(7)

where $|\epsilon _{D_{v}, d}| \le 0.5\times 10^{-d}$ is the round-off error.

By replacing D _v with $D_{v}^{(d)}$ in (1), we obtain the scaled interpolated color as

$$\begin{array}{@{}rcl@{}} C_{s}^{\prime} &=& \sum\limits_{v \in N(s)} C_{v} D_{v}^{(d)} \end{array} $$

(8)

$$\begin{array}{@{}rcl@{}} &=& \left(C_{s} + \epsilon_{s}\right) \times 10^{d}, \end{array} $$

(9)

where

$$\epsilon_{s} = \sum\limits_{v \in N(s)} C_{v}\epsilon_{D_{v}, d} $$

is the total round-off error resulted in the interpolation step.

Since C _v ≤255, $|\epsilon _{D_{v}, d}| \le 0.5\times 10^{-d}$, and N(s) = 8, the total error at this step is bounded:

$$|\epsilon_{s}| \le 1020 \times 10^{-d}. $$

5.2 Modifying composition

The composition of colors of c sample points, which is given in (3), adds c multiplied values, where a multiplication is between two floating point operands $C_{s_{i}}$ and O _i . Thus, to ensure that composition performs fixed point operations, we replace the interpolated color $C_{s_{i}}$ by the scaled interpolated color $C^{\prime }_{s_{i}}$ from the pervious step and O _i by an integer

$$ O_{i}^{(f)} = \left(O_{i} + \epsilon_{O_{i}, f}\right) \times 10^{f}, $$

(10)

where $\epsilon _{O_{i}, f}$ is the round-off error, and $|\epsilon _{O_{i},f}| \le 0.5\times 10^{-f}$.

By replacing C _s with $C_{s}^{\prime }$ and O _i with $O_{i}^{(f)}$ in (3), we obtain the scaled composite color C ^′ as

$$\begin{array}{@{}rcl@{}} C^{\prime} &=& \sum\limits_{i=1}^{c} C_{s_{i}}^{\prime}O_{i}^{(f)} \end{array} $$

(11)

$$\begin{array}{@{}rcl@{}} &=& (C + \epsilon) \times 10^{d+f}, \end{array} $$

(12)

where

$$\epsilon = \sum\limits_{i=1}^{c} \left(\epsilon_{{s_{i}}}O_{i} + C_{s_{i}}\epsilon_{O_{i}, f} + \epsilon_{{s_{i}}}\epsilon_{O_{i}, f} \right) $$

is the total round-off error resulted in the composition step. Since C ≤ 255, C ^′ satisfies

$$ C^{\prime} \le (255+\epsilon_{max}) \times 10^{d+f} $$

(13)

where 𝜖 _{m a x} is the upper bound of 𝜖.

We know that $C_{s_{i}} \le 255$, $|\epsilon _{s_{i}}| \le 1020 \times 10^{-d}$, 0≤O _i ≤1, ${\sum }_{i=1}^{c} O_{i} \le 1$, and $|\epsilon _{O_{i}, f}| \le 0.5\times 10^{-f}$. Therefore the error in scaled composition 𝜖 satisfies

$$ \epsilon \ge 510c \times 10^{-(f+d)} - 127.5c \times 10^{-f} - 1020 \times 10^{-d} $$

(14)

and

$$ \epsilon \le 510c \times 10^{-(f+d)} + 127.5c \times 10^{-f} + 1020 \times 10^{-d}. $$

(15)

We, however, know that the color of a pixel is a natural number, and is obtained by truncating the fractional part of the composite color C. Hence, if a part of error 𝜖 cannot change the truncated value, then it is not effective, i.e., the effective error 𝜖 _{e f f} due to 𝜖 can be obtained by

$$\epsilon_{eff} = \lfloor C+\epsilon \rfloor - \lfloor C \rfloor. $$

The lowest possible value of 𝜖 _{e f f} is ±1, since the smallest possible value of |𝜖| (say, |𝜖| approaches to zero) can also change the value of the rendered color. The following theorem provides the conditions to bound 𝜖 _{e f f} by ±1.

Theorem 1

If the number of sample points along a ray, c, satisfies c ≤ 7 × 10 ^t , for any integer t, then for d ≥ 4 and f ≥ t + 3, the effective rounding error in rendering 𝜖 _eff is bounded by ±1.

The proof is by substitution and is straightforward.

The above analysis shows that with fixed point operation, we can limit the error when computing the composite color to less then one. Consider the case where c < 700, then it suffices to round off D _v to 4 decimal places and the opacity O _i to 5 decimal places.

6 Cloud-based secure rendering

Using the above modified ray-casting operations, we now describe how secret sharing is done. We first present our secure cloud-based rendering framework using standard Sharmir’s secret sharing and the modified ray-casting operations (SR-MPVR). For completeness, we followed this with our previous scheme, SR-MSSS, which uses a weaken Shamir’s secret sharing and standard ray-casting operations (SR-MSSS). Finally, a more efficient version that uses ramp secret sharing (SR-RSS) is presented.

6.1 Architecture

The architecture of our framework consists of three components: the server that hosts the secret volume V, n cloud datacenters, and the client who is authorized to access the secret rendered image (Fig. 2). This architecture is designed with the assumption that an adversary neither can access the server or the client nor can access more than k − 1 datacenters.

Fig. 2

Our secure cloud-based data visualization framework

The framework aims to provide both a secure and practical solution. I.e, we not only aim to address data confidentiality, data integrity, and data availability issues but also wish to lessen the computation overhead, data overhead, and loss in image quality.

6.2 SR-MPVR

As shown in Fig. 3, the work flow of our framework can be divided into four steps: (i) data preparation, (ii) ray-projection, (iii) post ray-projection rendering, and (iv) image recovery.

Fig. 3

Proposed secured volume ray-casting

6.2.1 Data preparation

The data preparation step creates n shares of the secret volume V. As we only hide the color information, the hidden volumes, V ₁, V ₂,... maintains the shape and order of the voxels of V – only the color information is modified. To achieve this, the server first finds the color and the opacity of each data voxel v of a given volume V by performing gradient estimation, classification, and shading operations; and then creates n shares of V by secret sharing the color C _v of v to n shares and copying the opacity A _v of v into n times.

To create shares of C _v , we first choose a prime number q that is greater than the value of the maximum reconstructed secret (255 + 𝜖 _{m a x} ) × 10^{d + f} (which is derived in (13)). By using C _v as the secret in (6) and by setting x = p, we find p ^th share of C _v as

$$ C_{v, p} = (C_{v} + \alpha_{p}) \bmod{q}. $$

(16)

Note that we use the same q for all shares. Since we need to fix the value of q, which depends on 𝜖 _{m a x} , we also determine the rounding precisions d and f in this step.

Next, we create the p ^th share volume of V, V _p . For each voxel v in V, we create a share voxel v _p with the same xyz-coordinate and opacity, but set the color of v _p to C _{v, p} .

6.2.2 Ray-projection

The shared volume V _p is stored on datacenter p. When a client requests that the volume V be rendered from a particular viewpoint by projecting a ray, the request is sent to n datacenters. The ray is projected on each of the share volume in these datacenter.

6.2.3 Post ray-projection rendering

Sampling: Consider the projected ray on a share volume V _p . The ray is sampled at c sample points s _{1, p} , s _{2, p} ,…, s _{c, p} . Note that the xyz-coordinate s _{i, p} and xyz-coordinate s _i (a sample point on the ray when it is projected on V) are the same.

Interpolation: This step finds the opacity and color of a sample point s _p ∈V _p by interpolating the opacities and the colors of all eight neighboring voxels of s, and is the same as the operation on the secret volume V.

Since we did not change the opacity, the interpolated opacity is the same whether it is done of a share volume V _p or the secret volume V. The voxels’ color, on the other hand, has changed. By putting the color of v _p as C _{v, p} in (8), we get scaled interpolated color $C^{\prime }_{s, p}$ by

$$ C^{\prime}_{s, p} \equiv \left( C_{s}^{\prime} + \alpha_{p} D_{s_{p}} \right) \bmod{q}, $$

(17)

where $D_{s_{p}} = {\sum }_{v \in N(s_{p})}D_{v}^{(d)}$. The value for $D_{s_{p}}$ = D _s is the same for all p.

Composition: This next step composites the opacities and the colors of all the sample points s _{1, p} , s _{2, p} ,…, s _{c, p} along the projected ray. As we do not share the opacities, they can be composited by conventional composition formula given in (4). The composition of colors, however, need to be performed by the scaled composition technique that is derived in (11).

Using $C^{\prime }_{s_{i}, p}$ as the color of s _{i, p} in (11), the scaled composite color is calculated as

$$ C^{\prime}_{p} \equiv \left( C^{\prime} + K \alpha_{p}\right) \bmod{q}, $$

(18)

where $K = {\sum }_{i=1}^{c} D_{s_{i}} O_{i}^{(f)}$ has the same value for all share volume.

Using A _s as the opacity and $C^{\prime }_{p}$ as the color of a pixel, the p ^th datacenter now creates the p ^th share image, and sends it to the client.

6.2.4 Image recovery

Finally, an authorized user recovers the secret image from k share images obtained from k datacenters. As we do not hide opacities, the opacity of a pixel of a share image become the opacity of the corresponding pixel of the secret image. The color of a pixel of the secret image is recovered from k shared colors (as given in (18) by first using Lagrange interpolation to reconstruct the scaled secret color C ^′ from k shared colors $C^{\prime }_{p}$ for some p in {1,..n}, and then dividing C ^′ by 10^{d + f}. Therefore, by (12), the recovered secret color is

$$C^{\prime\prime} = C + \epsilon, $$

which is close to C (the color obtained by conventional ray-casting) as by Algorithm 1, the error 𝜖 can be bounded by ±1 for sufficiently large value of d and f.

In Appendix Appendix, we have provided a simple example of SR-MPVR.

6.3 SR-MSSS

We now describe the SR-MSSS method, an alternative to SR-MPVR. SR-MSSS uses floating point operations, but uses a variation of Shamir’s secret sharing with a weaken security guarantee. The main work flow of SR-MSSS is similar to SR-MPVR, so we only highlight the differences below.

In the data preparation step, the server defines a polynomial

$$F^{\prime}(x) = C_{v} + \alpha_{x} $$

for secret sharing, and uses this polynomial to find the p ^th share of C _v as

$$C_{v, p} = C_{v} + \alpha_{p}, $$

without the module prime operation.

As no modular prime operation is used in secret sharing, in the post ray-projection rendering step, a datacenter uses the conventional pre-classification volume ray-casting to render its share volume, and finds the composite color of a share pixel as

$$C_{p} = C + K \alpha_{p} $$

(where K is a constant) and the composite opacity as A along a ray projected on V _p (the p ^th share volume).

As no scaling up by 10^{d + f} operation is required for color rendering, at the image recovery step, the user does not divide the reconstructed color C by 10^{d + f}. The user recovers the secret image using the Lagrange interpolation as per normal Shamir’s secret sharing scheme. As evident from this discussion, the recovered secret color is equal to the secret color rendered by conventional ray-casting.

6.4 SR-RSS

We now present another alternative, SR-RSS, that uses ramp secret sharing to reduce the size of the share images.

6.4.1 Data preparation

The objective of this step is to optimize the modified Shamir’s secret sharing to create smaller share volumes.

We know that the three color components of a pixel, i.e., the red color R, the green color G, and the blue color B, are rendered by identical rendering operation, and by rendering a share, a datacenter renders all the coefficients used in the secret sharing polynomial. Therefore, we use the color component R _v , G _v , and B _v of a voxel v as three secrets in the secret sharing polynomial. Although used (3, k, n) ramp secret sharing can reduce the data overhead by three times (as instead of creating three shares, ramp secret sharing creates only one share for all three color components), resulted data overhead is sill a concern as a shared color is represented by a floating point number, requiring 4 bytes on a typical systems.

If we limit the value of k and n, however, it is possible to limit the share color to 2¹⁶, thus requiring only two bytes.

To use this trick to reduce the value of a color share, we choose a smaller share number at the time of secret sharing by setting the condition k = 4 and n = 5 for our ramp secret sharing. Thus the secret sharing polynomial becomes

$$\begin{array}{@{}rcl@{}} F^{\prime}(x) = a_{0} + R_{v}x + G_{v}x^{2} + B_{v}x^{3}, \end{array} $$

(19)

where a ₀ is a random number. Using this polynomial and choosing the value of x smaller than five, the server creates share volumes that contains only one share for all three color components of a voxel, and then sends the shared volume to the corresponding datacenter. As the value of color is less than 255 and the value x is less than equal to five, for a ₀≤26011, the value of F ^′(x) cannot exceed 65536.

Note that although we can choose n = k = 3 to restrict the value of a color share to 3315, we do not recommend this optimization as such a scheme, by not using a random number in secret sharing polynomial, can result in complete breakdown of our framework. Firstly, such (3, 3, 3) ramp secret sharing do not work for a gray image as it cannot hide black color (when all color components are 0) and white color (when all color components are 255) of a voxel/pixel. Secondly, due to spatial coherence in an image, it is easier for an adversary to guess color of a voxel/pixel from the known share value of the voxel/pixel and the share values of neighboring voxels/pixels of the target voxel/pixel. Similarly, we also do not recommend n = k as this optimization cannot guarantee data integrity and data availability (will be discussed in Section 7.1).

6.4.2 Post ray-projection rendering

Using the post ray-projection rendering operations of SR-MSSS on the p ^th share of colors (i.e., F ^′(p)’s that are obtained from (19)), we find the p ^th shared composite color (for all the three color components) by

$$C_{p} = K + Rp + Gp^{2} + Bp^{3}, $$

where R, G, and B are the red color, green color, and blue color composited by the conventional ray-casting, and K ≤ a ₀ is a constant for all the shares. As the value of each F ^′(p) is less than 65536, the value of C _p is also less than 65536. We convert C _p to an integer with precision g and send $C_{p}^{(g)}$ to the client.

6.4.3 Image Recovery

This step finds the secret color components from k given color shares, $C_{p}^{(g)}$, by first using Lagrange interpolation to find the polynomial

$$L^{\prime}(x) = K + Rx + Gx^{2} + Bx^{3} + \epsilon, $$

where 𝜖 is the rendering error due to rounding off C _p , and then solving L ^′(x). As the introduced error 𝜖 satisfies

$$|\epsilon| \le 0.5 \times 10^{-g} \times \sum\limits_{i=2}^{5} {{5}\choose{i}}, $$

we can choose g≥1 to obtain |𝜖|<1.

These optimizations, however, degrades security as both the use of ramp secret sharing scheme, and the exclusion of modular prime operation from secret sharing can disclose information about the secret. Furthermore, due to rounding error, there is a loss in information in the rendered image.

Note that we choose to optimize SR-MSSS as all of the proposed optimization tricks can be applied to SR-MSSS simultaneously. One can, however, extend the trick of using multiple secrets in a secret sharing polynomial to SR-MPVR. The trick of limiting the value of a color share by choosing a suitable share number, however, is not applicable to SR-MPVR as in the case of Shamir’s secret sharing, size of a share is independent of the share number.

7 Results and analysis

We simulated the server, datacenters, and the client of our framework in a PC powered by an Intel Core 2 Quad 2.83 GHz processor and with 4GB of RAM. We implemented our framework by first modifying the volume ray-casting module of the open source visualization package VTK to facilitate pre-classification volume raycasting, and then integrating secret sharing into the rendering pipeline. In the case of SR-MPVR, we used (3,5) Shamir’s secret sharing in conjunction with modified pre-classification volume ray-casting; in the case of SR-MSSS, we used modified (3,5) Shamir’s secret sharing in conjunction with pre-classification volume ray-casting; and in the case of SR-RSS we used (3, 4, 5) modified ramp secret sharing in conjunction with pre-classification volume ray-casting. To validate our schemes, we used four sets of test volume data: Head, Foot, Bucky, and IronProt, which details are given in Table 1. As the number of sampling points along a ray on any of these test volume does not exceed 700, for SR-MPVR, we fixed d = 4 and f = 6 to obtain |𝜖| ≤ 1. For SR-RSS, we rounded off the floating point numbers by one decimal place (i.e., chosen g = 1) to keep the error below one.

Table 1 Data sets

For Head, Fig. 4 shows the result of SR-MPVR, Fig. 5 shows the result of SR-MSSS, and Fig. 6 shows the result of SR-RSS from single view point. As SR-RSS represents three color components of a pixel by a single value, it creates a grey share image, hiding the color information. For SR-MPVR, Fig. 7 demonstrates the secret image and first share image of Foot, Bucky, and IronProt from single view point, and Fig. 8 shows the share images of Head for multiple view points (we have provided more results as supplementary material in the file MoreResult.pdf). As illustrated by these figures, the color information of the secret image is hidden in the respective share images. Therefore, an adversary having access to a share image cannot perceptually infer the color coded information of the secret image.

Fig. 4

Secure pre-classification volume ray-casting on Head for SR-MPVR

Fig. 5

Secure pre-classification volume ray-casting on Head for SR-MSSS

Fig. 6

Secure pre-classification volume ray-casting on Head for SR-RSS

Fig. 7

Secure pre-classification volume ray-casting of Foot ((a), (b)), Bucky ((c), (d)), and IronProt ((e), (f)) for SR-MPVR

Fig. 8

Secure pre-classification volume ray-casting of Head in SR-MPVR from different viewpoints

7.1 Security analysis

In addition to perceptual security, our schemes also provide data confidentiality, data integrity, and data availability.

7.1.1 Confidentiality

As SR-MPVR uses Shamir’s secret sharing, it is perfectly secure. Thus, an adversary, irrespective of its computation power, cannot get any information about the secret color of a voxel/pixel by accessing at most k − 1 datacenters.

In principle, the color of an object is independent of the shape of the object since a user can modify color from a color look-up table. Therefore, theoretically, the probability of guessing the secret color of a voxel/pixel is $\frac {1}{256}$: due to which, the probability of guessing a 512 × 512 secret image is $\frac {1}{256^{512\times 512}}$. However, practically, the range of color of an object can be less than 256. In this case, the knowledge of color adds little information unless there is some color-coded abnormality in the image (such as detection of diseases in a MRI scan). Our work hides such confidential color-coded information.

By excluding modular prime operation from secret sharing, SR-MSSS looses some information about the secret color in a group of less than k datacenters. The probability of knowing a secret from a group of less than k shares increases with an increase in the number of known shares, and this probability depends on the share number x (as there is a one-to-one mapping between the share and the share number). For example, for known share number x _i and the knowledge of one F ^′(x _i ), if we let the probability of knowing the secret pixel color C be $\frac {1}{T}$, then for k = 2,

$$T=\Bigg\lfloor \frac{F^{\prime}(x_{i})}{x_{i}} \Bigg\rfloor + 1,$$

For k = 3,

$$ T = \sum\limits_{a=0}^{\Big\lfloor \frac{F^{\prime}(x_{i})}{{x_{i}^{2}}} \Big\rfloor} \left( \Bigg\lfloor \frac{F^{\prime}(x_{i}) - a{x_{i}^{2}}}{x_{i}} \Bigg\rfloor + 1 \right). $$

(20)

When k increases, T increases, as the combination of k − 1 coefficients that satisfy a k − 2 degree polynomial F ^{′, k − 2}(x, S) is also part of the combination of k coefficients that satisfy the k − 1 degree polynomial F ^{′, k − 2}(x, S) + a _{k − 1} x ^{k − 1}.

To minimize the effect of loss of information, we can choose higher valued random numbers (i.e., a _i ’s) as coefficients in the secret sharing polynomial to obtain higher share value for lower share number. For example, even for the (2, n) modified secret sharing, if a _i >256 and x < 5, then T>256. In other words, we can provide more than 256 choices to an adversary for guessing the secret – already more than the number of color values possible.

By using (3, 4, 5) modified ramp secret sharing, SR-RSS, in addition to losing information due to the exclusion of modular prime operation, also loses information due to the use of multiple secrets in a secret sharing polynomial. Due to this information loss, an adversary, by accessing more than one datacenters, can easily guess some of the secret color by converting the (3, 4, 5) modified ramp secret sharing to (3,3,5) modified ramp secret sharing. Therefore, SR-RSS is insecure when an adversary can access more than one datacenter. To counter such scenario, one can easily adjust SR-RSS by introducing (3, k + 3, n) ramp secret sharing, where k is the maximum number of datacenters that an adversary cannot access simultaneously.

7.1.2 Integrity

By inheriting the property of (k, n) secret sharing, SR-MPVR, SR-MSSS, and SR-RSS ensures integrity of data/image. The k < n condition provides ${{n}\choose {k}}$ different ways of reconstructing the secret image. Suppose an adversary changes the color values of the share images (either directly tampering with the rendered image or tampering the share volume) of at most n − 1 datacenters, then the reconstructed images will differ to each other (as shown in Fig. 9). As a result, by comparing at most ${{n}\choose {n-1}} + 1$ reconstructed images (the worst case happens when an adversary tampers only one share image and the client uses the tampered share image in image reconstruction after exploring all other possibilities), the client can detect tampering.

Fig. 9

(a)- recovered image when one share image is tampered; ((b), (c)) - recovered images when two share images are tampered; ((d), (e)) - recovered images when all share images are tampered; and (f) - recovered image when no share image is tampered

However, if the adversary is able to temper with the share images of all n datacenters by obeying the homomorphic property of secret sharing, then all the tampered reconstructed image at the client site will be the same (as shown in Fig. 9d and e). In this case, the client will not be able to detect the tampering. Furthermore, if n = k, then tampering with even one share image is not detectable as there can be only one possible combination to recover the secret image. Therefore, for application requiring data integrity, we recommend choosing n > k.

7.1.3 Availability

By inheriting the property of (k, n) secret sharing, all of SR-MPVR, SR-MSSS, and SR-RSS also ensure data availability as the client is able to reconstruct the secret image even if at most n − k number of datacenters are unable to participate.

7.2 Performance analysis

The usability of the proposed cloud-based secured rendering techniques depends on its computational overhead, data overhead, and the quality of rendered image. The computational overhead includes creation of n share from the secret data voxels at the server and reconstruction of the secret image from k share images at the client. The data overhead includes extra bandwidth by the server to transmit n share volumes to n datacenters extra bandwidth to transmit k share images to the client. Computation of share volumes and their distribution to datacenters is performed by the server offline and therefore is less of a concern. The data overhead in transmitting k share images and the computational overhead to reconstruct the secret image, however, add to the latency in rendering. We discuss them below.

7.2.1 Computational overhead

The computation cost of our framework is equal to the computation cost required to recover colors of secret image from the share images. Therefore, computational overhead is dependent on the computation cost of Lagrange interpolation and the dimension of the image. As SR-MPVR uses modular prime operation and large integer operations, its computation cost is more than the computation cost of SR-MSSS and SR-RSS. The computation cost of SR-MSSS, however, varies with the computation cost of SR-RSS according to their requirement of the number of shares to reconstruct the secret. In our implementation, SR-MPVR and SR-MSSS takes 132 ms and 29 ms respectively to recover a 512 × 512 rendered image from the first, second, and third image shares. For the same image, SR-RSS takes 34 ms to recover the secret image from the first, second, third, and fourth share images. The overhead of SR-RSS is more than SR-MSSS as the constructed polynomial for SR-RSS is one degree higher than that of SR-MSSS.

7.2.2 Data overhead

For SR-MPVR and SR-MSSS, our rendering framework requires k share images to reconstruct the secret image. Thus, if b number of bits are required to represent a color component of a pixel of a share image, then a total of 3b k + 8 number of bits are required to reconstruct the color and opacity of a pixel: due to which, the data overhead is $\frac {3bk-24}{32}$ times more than conventional server-side rendering. The value of b, however, is dependent on how we solve the incompatibility issue of secret sharing with ray-casting. In case of SR-MPVR, b is dependent on the rounding off parameters d and f as the rendered color lays between 0 to q, where q>(255 + 𝜖 _{m a x} ) × 10^{d + f}. For SR-MSSS, b, however, is equivalent to the number of bits required to represent a floating point number. Therefore, in our implementation, which uses (3, n) secret sharing, 32 bits for a floating point number, and sets d = 4 and f = 6, the data overhead of SR-MPVR and SR-MSSS are approximately 11 times and 8 times more than the conventional server-side volume ray-casting.

In the case of SR-RSS, our rendering framework, however, requires four color shares to recover the three color components of a pixel of the secret image. Thus, if b bits are required to represent a color share, then a total of 4b + 8 bits are required to obtain the secret color and opacity value of a pixel in the secret image. We, however, know that the value of a color share cannot exceed 65536 × 10^g, where g is the number of decimal places by which a share is rounded off. Therefore, our implementation of SR-RSS, which sets g = 1, results in approximately twice the data overhead than the conventional server-side volume ray-casting.

7.2.3 Image quality

By rounding off floating point numbers during rendering, both SR-MPVR and SR-RSS renders lossy image; but SR-MSSS, without performing rounding operations, renders lossless image.

In the case of SP-MPVR and SR-RSS, we can, however, obtain better quality image by using higher precision fixed point numbers. As discussed in Section 7.2.2, a higher number of rounding bits can increase the data overhead: resulting in a tradeoff between the quality of image and the data overhead. This claim can be verified from Fig. 10, which, for our experimental setup, shows the PSNR values of Head, Foot, Bucky, and IronProt rendered images for different overheads. As illustrated, to obtain similar quality image, SR-MPVR leads to higher overhead than SR-RSS as SR-MPVR rounds off two floating point numbers in contrast to only one in SR-RSS. Note that for any of these schemes, the PSNR values of different images are different for fixed overhead as the round-off error and its effect on final rendered color are dependent on the scalar values of the data voxels.

Fig. 10

For SR-MPVR and SR-RSS, this figure shows the PSNR value of the Head, Foot, Bucky, and IronProt rendered images for different data overhead. As SR-MPVR results different PSNR for a fixed overhead (as for a fixed number of rounding bits d + f, the PSNR can change with the change in the value of d and f), we show the maximum obtained PSNR

Table 2 shows the security level, overheads, and image quality of all our proposed schemes: SR-MPVR, SR-MSSS, and SR-RSS. As highlighted, (i) SR-MPVR is best suit for applications prioritizing security over overheads and image quality; (ii) SR-RSS is suitable for applications requiring low overhead at cost of high security and loss of information from the rendered image; and (iii) SR-MSSS is designed for applications requiring lossless rendered image, and moderate security and overhead.

Table 2 Comparison among SR-MPVR, SR-MSSS, and SR-RSS

8 Conclusion

Rendering important data in third party cloud datacenters presents security and privacy challenges. In this paper, we addressed these challenges by proposing a secure cloud-based rendering framework that, by integrating Shamir’s secret sharing (or its variant) with pre-classification volume ray-casting (or its variant), can hide color of volume data or rendered image from datacenters. To address the incompatibility of secret sharing with ray-casting, we modified either secret sharing (which is the case in SR-MSSS) or ray-casting (which is the case in SR-MSSS), and to decrease high data overhead of both these techniques, we optimized modified secret sharing (which is the case in SR-RSS). Experiments and analyzes showed that SR-MPVR provides high security at the cost of high data overhead and loss of some information from the rendered image; SR-MSSS renders lossless image and provides moderate security at the cost of moderate overheads; and SR-RSS incurs low overhead at the cost of high security and the loss of some information from the rendered image.

We believe that the philosophy of this work, i.e., using a somewhat homomorphic cryptosystem to hide some operations of an algorithm, and distributing the non-homomorphic operations among more than one participants such that none of the participant can get sufficient secret information, can be the basis of designing practical secure cloud based imaging frameworks for other applications in future. In the place of secret sharing, other cryptosystems also can be used to serve any particular requirement.

Appendices

Appendix A: Example of conventional pre-classification ray-casting and SR-MPVR

In this section, we will show the working of conventional ray-casting and SR-MPVR with a simple example. Since SR-MSSS and SR-RSS are similar to SR-MPVR, we do not provide examples for these two schemes.

In our example, we will first run through the conventional pre-classification ray-casting, and then will discuss SR-MPVR. We will show that the colors rendered by SR-MPVR is almost equal to the colors rendered by the conventional algorithm

1.1 Conventional pre-classification volume ray-casting

As explained in Section 4.1 and shown in Fig. 1, the conventional volume ray-casting algorithm steps can be divided into the following steps: pre ray-projection, ray-projection, sampling, interpolation, and composition. We discuss these steps with an 8 × 8 × 8 input volume data V.

1.1.1 Pre ray-projection

This step finds the shaded colors and opacities of the voxel values, and stores them in a look up table. For our example, let us assume that the colors and opacities of the voxels are stored in Table 3.

Table 3 Color look up table for V

1.1.2 Ray-projection

In this step, a number of rays are projected to V from the image space. In the image space, the colors and opacity of a pixel are the colors and opacity rendered along the ray originated from it. Since the rendering along a ray is similar to the rendering along other rays, we discuss about the rendering along one ray X.

1.1.3 Sampling

In our example, let us assume that the projected ray X is sampled at two sample points s ₁ and s ₂.

1.1.4 Interpolation

The colors and opacities along s ₁ and s ₂ are found by trilinear interpolation of the colors and opacities of the neighbouring voxels.

In our example, let us assume that the voxels (3, 3, 3)…(4, 4, 4) are the neighbouring voxels of s ₁ and the voxels (5, 5, 5)…(6, 6, 6) are the neighboring voxels of s ₂. If the interpolating factors of voxels (3, 3, 3)…(4, 4, 4) and (5, 5, 5)…(6, 6, 6) are given as D _{3, 3, 3} = 0.125, D _3,3,4 = 0.125, D _3,4,3 = 0.125, D _3,4,4 = 0.125, D _4,3,3 = 0.125, D _4,3,4 = 0.125, D _4,4,3 = 0.125, D _{4, 4, 4=0.125} and D _{5, 5, 5} = 0.125, D _5,5,6 = 0.125, D _5,6,5 = 0, D _5,6,6 = 0.25, D _6,5,5 = 0.25, D _6,5,6 = 0, D _6,6,5 = 0.125, D _{6, 6, 6} = 0.125respectively, the interpolated colors and opacities of s ₁ and s ₂ can be calculated as $R_{s_{1}} = 42.875, G_{s_{1}} = 70.375, B_{s_{1}} = 142.25, A_{s_{1}} = 0.406$ and $R_{s_{2}} = 104.375, G_{s_{2}} = 48.875, B_{s_{2}}= 93.25, A_{s_{2}} = 0.3$ respectively.

1.1.5 Composition

In this step, the colors and opacity along the ray are found by compositing the colors and opacities of the sample points. The composited colors are then truncated to get the rendered color.

Therefore, in our example, the rendered colors and opacity are calculated as R = 43, G = 34, B = 68, and A = 0.5842.

1.2 SR-MPVR

As discussed in Section 6, our scheme, such as SR-MPVR, is targeted to cloud-based pre-classification rendering. Figure 2 shows the architecture of our scheme. In our scheme, the server performs the pre ray-projection step of ray-casting and then creates shares of output color in data preparation step. A color share and a copy of opacities represents a share volume, which is sent to a datacenter. The datacenters perform post ray-projection operation, such as sampling, interpolation, and classification, on their share volumes and send the rendered share images to the client. Finally, the client recovers the secret image from the shared images by reconstructing the secret colors from the share colors.

1.2.1 Data preparation

In this step, the server first performs pre ray-projection operations on V, and then creates three shares of V using Shamir’s secret sharing.

Without loss of generality, let us assume that the server uses (2,3) Shamir’s secret sharing. Therefore, three datacenters performing rendering operations, but shared rendered images from at least two datacentres are required to get the secret image.

Suppose we decide to round off the floating point number in interpolation step by 4 decimal places (i.e., d = 4) and the float in composition step by 6 decimal places (i.e., f = 6). Then, the server uses the secret sharing polynomial F(x) = (C + 100x) mod 2570000000011, where C is the color. Using this polynomial, three shares of colors are created. The color shares along with copies of opacities are given in Tables 4, 5, and 6, those represent the share volumes V ₁, V ₂, and V ₃ respectively.

Table 4 Color look up table for V ₁

Table 5 Color look up table for V ₂

Table 6 Color look up table for V ₃

1.3 Ray-projection

The client projects the same rays those it could have projected to the conventional ray-casting, to the data volumes presented by share tables in the datacenters.

1.3.1 Post ray-projection rendering

Post ray-projection steps are as follows.

Sampling: A ray is sampled at the same sample points where it could have been sampled in the conventional ray-casting. Thus, our discussed ray X is sampled at the sample points s ₁(3.5,3.5,3.5) and s ₂(5.5,5,6) for all three datacenters.

Interpolation: In this step, each datacenter finds the color and opacity of the sample points by interpolating the color shares and opacities given in its share table. Since we convert the interpolating factors by rounding off them by 4 decimal places, the interpolating factors of voxels (3, 3, 3)…(4, 4, 4) and (5, 5, 5)…(6, 6, 6) are calculated as $D^{(4)}_{3, 3, 3} = 1250, D^{(4)}_{3,3,4} = 1250, D^{(4)}_{3,4,3} = 1250, D^{(4)}_{3,4,4} = 1250, D^{(4)}_{4,3,3} = 1250, D^{(4)}_{4,3,4} = 1250, D^{(4)}_{4,4,3} = 1250, D^{(4)}_{4, 4, 4} = 1250$, and $D^{(4)}_{5, 5, 5} = 1250, D^{(4)}_{5,5,6} = 1250, D^{(4)}_{5,6,5} = 0, D^{(4)}_{5,6,6} = 2500, D^{(4)}_{6,5,5} = 2500, D^{(4)}_{6,5,6} = 0, D^{(4)}_{6,6,5 = 1250}, D^{(4)}_{6, 6, 6} = 1250$respectively. Using these interpolating factors, the first datacenter, second datacenter, and third datacenter calculate the colors of s ₁ and s ₂ as (R _1,1 = 1428750, G _1,1 = 1703750, B _1,1 = 2422500, R _2,1 = 2043750, G _2,1 = 1488750, B _2,1 = 1932500), (R _1,2 = 2428750, G _1,2 = 2703750, B _1,2 = 3422500, R _2,2 = 3043750, G _2,2 = 2488750, B _2,2 = 2932500), and (R _1,3 = 3428750, G _1,3 = 3703750, B _1,3 = 4422500, R _2,3 = 4043750, G _2,3 = 3488750, B _2,3 = 3932500) respectively.

Interpolation: In this step, the colors and opacity along the ray are found by compositing colors and opacities of the sample points. Each datacenter composites its colors and opacities from the interpolated colors and opacities available to it. In our example, f = 6. Using this value, the first datacenter, the second datacenter, and the third datacenter calculate their composite colors as $(R^{\prime }_{1} = 1019175750000, G^{\prime }_{1} = 930830750000, B^{\prime }_{1} = 1268224500000)$, $(R^{\prime }_{2} = 1603375750000, G^{\prime }_{2} = 1515030750000, B^{\prime }_{2} = 1852424500000)$, and $(R^{\prime }_{3} = 2187575750000, G^{\prime }_{3} = 2099230750000, B^{\prime }_{3} = 2436624500000)$ respectively. For all datacenters, the composited opacity is 0.5842.

1.4 Image recovery

In this step, the client obtains the secret colors and opacities from the share colors and opacities obtained from three datacenters. Since each datacenter has a copy of the secret rendered opacity, the opacity of a pixel is the rendered opacity along that ray at any datacenter. Therefore, for Ray X, the opacity is 0.5842, which is equal to the rendered opacity along that ray by the conventional pre-classification ray-casting.

The secret colors, however, are found by first reconstructing (using Lagrange interpolation) a value from the share colors, and then dividing the value by 10000000000. Since we use (2,3) secret sharing, we need at least two shares to obtain the secret. Without any loss of generality, we choose the shares of first and second datacenters, and find the rendered color as R = 43, G = 34, and B = 68.

Appendix B: List of symbols

Table 7 Symbol table