3DCrypt: Privacy-preserving Pre-classification Volume Ray-casting of
3D Images in the Cloud
Manoranjan Mohanty
1
, Muhammad Rizwan Asghar
2
and Giovanni Russello
2
1
Center for Cyber Security, New York University Abu Dhabi, Abu Dhabi, U.A.E.
2
Department of Computer Science, The University of Auckland, Auckland, New Zealand
Keywords:
Encrypted Volume, Paillier Cryptosystem, Cloud-based Secure Volume Ray-casting.
Abstract:
With the evolution of cloud computing, organizations are outsourcing the storage and rendering of volume (i.e.,
3D data) to cloud servers. Data confidentiality at the third-party cloud provider, however, is one of the main
challenges. In this paper, we address this challenge by proposing – 3DCrypt – a modified Paillier cryptosystem
scheme for multi-user settings that allows cloud datacenters to render the encrypted volume. The rendering
technique we consider in this work is pre-classification volume ray-casting. 3DCrypt is such that multiple users
can render volumes without sharing any encryption keys. 3DCrypt’s storage and computational overheads are
approximately 66.3 MB and 27 seconds, respectively when rendering is performed on a 256 × 256 × 256
volume for a 256 × 256 image space.
1 INTRODUCTION
Nowadays, cloud computing is increasingly used by
organizations for rendering of volume data (i.e., 3D
data) (Cuervo et al., 2015; KDDI Inc., 2012; Intel
Inc., 2011). Although this cloud-based rendering has
many advantages, data confidentiality, which can lead
to privacy, is one of the main concerns. For example,
the data can be a scanned MRI of a patient’s head,
whose storage and rendering were outsourced to the
cloud by a hospital. The data encryption scheme must
be such that rendering can be performed on the en-
crypted data. Although the rendered image must not
disclose any information to the cloud server, an autho-
rized user (the one holding the encryption key) must
be able to discover the secret rendered image from the
encrypted rendered image.
Ideally, one would like to use the fully homomor-
phic encryption scheme to perform any type of com-
putations over encrypted data (Baharon et al., 2013).
However, current homomorphic encryption schemes
are not computationally practical. Therefore, partial
homomorphic schemes have been typically used for
the cloud-based encrypted processing. Using the par-
tial homomorphic Shamir’s (k,n) secret sharing, Mo-
hanty et al. (Mohanty et al., 2012) proposed the en-
crypted domain pre-classification volume ray-casting.
Their work, however, cannot hide shape of the ob-
ject from a datacenter and can disclose the color of
the object when k or more datacenters collude to-
gether. Recently, Chou et al. (Chou and Yang, 2015)
used permutation and adjusted the color transfer func-
tion (used in rendering) such that critical information
about the object can be hidden from the rendering
server. Their work, however, is not secure enough.
When working on encrypted data, usually a lot of
attention is paid to the actual scheme without consid-
ering key management, an aspect critical for organi-
zations. In a typical organization, issuing the same
key to all employees, who want to share data, is not
feasible. In an ideal situation, each employee must
have her own personal key that can be used to access
data encrypted by the key of any other employ. This
scenario is often referred to as the full-fledged multi-
user model. When the employee leaves the organi-
zation, the employee’s key must be revoked and the
employee must not be able to access any data (includ-
ing her own data) anymore. However, the data must
be accessible to employees still holding valid keys.
In this paper, we present 3DCrypt, a cloud-based
multi-user encrypted domain pre-classification vol-
ume ray-casting framework based on the modified
Paillier cryptosystem. Paillier cryptosystem is ho-
momorphic to only addition and scalar multiplica-
tion operations, whereas the pre-classification volume
ray-casting performs a number of operations, includ-
ing additions, scalar multiplications and multiplica-
tions. The use of Paillier cryptosystem alone there-
Mohanty, M., Asghar, M. and Russello, G.
3DCrypt: Privacy-preserving Pre-classification Volume Ray-casting of 3D Images in the Cloud.
DOI: 10.5220/0005966302830291
In Proceedings of the 13th International Joint Conference on e-Business and Telecommunications (ICETE 2016) - Volume 4: SECRYPT, pages 283-291
ISBN: 978-989-758-196-0
Copyright
c
 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
283

fore cannot hide the shape of the object as the render-
ing of opacity, which basically renders the shape, in-
volves multiplications. We addressed this issue using
a private-public cloud model in such a way that ren-
dering tasks can be distributed among the public and
private cloud servers without disclosing both shape
and color of the object to any of them.
Our contributions are summarized as follows:
• We provide a full-fledged multi-user scheme for
the encrypted domain volume rendering.
• Unlike Mohanty et al.’s Shamir’s secret sharing-
based work, we can hide both color and shape of
the object from the cloud.
• 3DCrypt provides more security against collusion
attacks than Mohanty et al.’s work.
Our preliminary analysis performed on a sin-
gle machine shows that 3DCrypt requires significant
overhead. According to our analysis, the computation
cost at the user-end, however, can be affordable.
For example, when rendering a 256 × 256 × 256
for 256×256 image space, the computation overhead
at the public cloud server and the private cloud server
are 16.5 minutes and 15.2 minutes, respectively. For
this data and image space, the data overhead and com-
putation overhead at the image user-end are approxi-
mately 66.3 MB and 27 seconds, respectively.
2 RELATED WORK
There are very few works in the direction of encrypted
domain rendering using the partial homomorphic en-
cryption. Mohanty et al. proposed the encrypted
pre-classification volume ray-casting (Mohanty et al.,
2012) and the encrypted post-classification volume
ray-casting (Mohanty et al., 2013) using Shamir’s
(k, n) secret sharing. Their pre-classification volume
ray-casting scheme, however, cannot hide shape of
the rendered object from the cloud server. Further-
more, their scheme requires n datacenters and as-
sumes that k of them must never collude. Recently,
Chou et al. (Chou and Yang, 2015) proposed a
privacy-preserving volume ray-casting scheme that
uses block-based permutation (which creates sub-
volumes from the volume and permutes the sub-
volumes) and adjustment of transfer function to hide
both the volume and rendering tasks from the render-
ing server. Their work, however, lacks to achieve pri-
vacy due to the loss of information from the adjusted
transfer table and the use of permutation.
In literature, there are alternative schemes to ad-
dress privacy issues by outsourcing of volume ren-
dering and visualization tasks to a third-party server.
Koller et al. (Koller et al., 2004) protected the high-
resolution data from an untrusted user by only al-
lowing the user to view the low-resolution results
during interactive exploration. Similarly, Dasgupta
and Kosara (Dasgupta and Kosara, 2011) proposed to
minimize the possible disclosure by combining non-
sensitive information with high sensitivity informa-
tion. The major issue with such schemes is that they
leak sensitive information.
3 SYSTEM MODEL
Figure 1: Cloud-based rendering of medical data.
In this work, we consider a distributed cloud-based
rendering system, where a cloud server stores and ren-
ders volumes on behalf of a volume data outsourcer.
Figure 1 presents a real-world medical imaging sce-
nario of 3DCrypt. In the system model, we assume
the following entities.
• Volume Outsourcer: This entity outsources the
storage and rendering of volumes to a third-party
cloud provider. It could be an individual or part of
an organization. In the latter case, users can act as
Volume Outsourcers. Typically, this entity owns
the volume. The Volume Outsourcer can store
new volumes on a cloud server, delete/modify ex-
isting ones and manage access control policies
(such as read/write access rights).In our scenario,
the Volume Outsourcer is part of a volume captur-
ing hospital.
• Public Cloud Server: A Public Cloud Server is
part of the infrastructure provided by a cloud ser-
vice provider, such as Amazon S3
1
, for storing
and rendering of volumes. It stores (encrypted)
volumes and access policies used to regulate ac-
cess to the volume and the rendered image. It
performs most of the rendering on stored volumes
and produces the partially rendered data.
• Private Cloud Server: The Private Cloud Server
sits between the Public Cloud Server and the ren-
dering requester. It can be part of the infras-
tructure, either provided by a private cloud ser-
vice provider or maintained by an organization
1
https://aws.amazon.com/s3/
SECRYPT 2016 - International Conference on Security and Cryptography
284

as a proxy server. The Private Cloud Server
receives partially rendered data from the Pub-
lic Cloud Server and performs remaining render-
ing tasks on the volume. It then sends the ren-
dered image to the rendering requester. Note that
the Private Cloud Server does not store data, it
only performs minimal rendering operations on
partially rendered data received from the Public
Cloud Server.
• Image User: This entity is authorized by the Vol-
ume Outsourcer to render a volume stored in the
Public Cloud Server. In a multi-user setting, an
Image User can (i) render an image (in encrypted
domain) that will be accessible by other Image
Users, or (ii) access images rendered by other Im-
age Users. In both cases, Image Users do not need
to share any keying material.
• Key Management Authority (KMA): The KMA
generates and revokes keys to entities involved
in the system. For each user (be a Volume Out-
sourcer or Image User), it generates a key pair
containing the user-side key and the server-side
key. The server-side key is securely transmitted
to the Public Cloud Server, whereas, the user-
side key is either sent to the user or Private Cloud
Server depending on whether the user is a Volume
Outsourcer or Image User. Whenever required
(say in key lost or stolen cases), the KMA revokes
the keys from the system with the support of the
Public Cloud Server.
Threat Model: We assume that the KMA is
a fully trusted entity under the control of the Vol-
ume Outsourcer’s organization. Typically, the KMA
can be directly controlled by the Volume Outsourcer.
Since the KMA deals with small amount of data, it
can be easily managed and secured. We also assume
that the KMA securely communicates the key sets to
the Public Cloud Server and the Image User. This can
be achieved by establishing a secure channel. Except
for managing keys, the KMA is not involved in any
operations. Therefore it can be kept offline most of
the times. This also minimizes the chances of being
compromised by an external attack.
We consider an honest-but-curious Public Cloud
Server. That is, the Public Cloud Server is trusted
to honestly perform rendering operations as requested
by the Image User. However, it is not trusted to guar-
antee data confidentiality. The adversary can be either
an outsider or even an insider, such as unfaithful em-
ployees. Furthermore, we assume that there are mech-
anisms to deal with data integrity and availability of
the Public Cloud Server.
In 3DCrypt, the Private Cloud Server is an honest-
and-semi-trusted entity. The Private Cloud Server is
also expected to honestly perform its part of rendering
operations. The Private Cloud Server is semi-trusted
in the sense that it cannot analyze more than what can
perceptually be learnt from the plaintext volume. We
assume that the Private Cloud Server is in conflict of
interest with the Public Cloud Server. That is, both
cloud servers should not collude.
4 PROPOSED APPROACH
In this section, we present the architecture and an
overview of work flow of 3DCrypt.
Figure 2: Distribution of rendering pipeline.
Figure 2 provides an overview of the pre-
classification volume rendering pipeline, and illus-
trates how we distribute the rendering pipeline among
different components of 3DCrypt. The Volume Out-
sourcer performs pre ray-projection rendering op-
erations: gradient/normal estimation, classification,
and shading as these one-time operations can be
pre-processed. The output of these operations are
encrypted using Paillier cryptosystem, and the en-
crypted volume is sent to the Public Cloud Server.
The Image User projects rays to the encrypted vol-
ume stored on the Public Cloud Server. The Public
Cloud Server performs part of the post ray-projection
rendering operations: sampling and interpolation on
encrypted colors and opacities. Then, the Public
Cloud Server sends interpolated colors and opaci-
ties to the Private Cloud Server. The Public Cloud
Server, however, does not share information about
voxel coordinates and projected rays with the Pri-
vate Cloud Server. The Private Cloud Server de-
crypts interpolated opacities, and performs remaining
post ray-projection rendering operations: color and
opacity compostion using plaintext opacities and en-
crypted colors. Then, the Private Cloud Server sends
the encrypted composite colors and plaintext compos-
ite opacities to the Image User. Finally, the Image
User decrypts composite colors and creates the plain-
text rendered image using plaintext colors and opaci-
ties.
Figure 3 illustrates the architecture of 3DCrypt.
In this system, the Volume Outsourcer is responsible
for storing a volume and defining access policies for
3DCrypt: Privacy-preserving Pre-classification Volume Ray-casting of 3D Images in the Cloud
285

Figure 3: The architecture of 3DCrypt, a cloud-based secure volume storage and rendering system.
the volume. To achieve this, the Volume Outsourcer
interacts with the client module Store Requester. The
Volume Outsourcer provides plaintext volume and ac-
cess policies (Step i). The Store Requester performs
the first stage encryption on the input volume using
the user-side key and then sends the encrypted vol-
ume along with associated access policies to the Store
Keeper module of the Public Cloud Server (Step ii).
On the Public Cloud Server-end, the Store Keeper
performs the second stage of encryption using the
server-side key corresponding to the user and stores
the encrypted volume in a Volume Store (Step iii.a).
The Store Keeper also stores access policies of the
volume in the Policy Store (Step iii.b).
Once an Image User expects the Public Cloud
Server to render a volume, her client module Access
Requester receives her rendering request in the form
of projected rays (Step 1). The module Access Re-
quester, in turn, forwards the request to the Access
Request Processor module of the Public Cloud Server
(Step 2). In the request, the Access Requester sends
rendering parameters (such as direction of projected
rays) and user credentials (which can be anonymized)
to the Access Request Processor. The Access Request
Processor first performs the user authorization check
to find out if the user has authorization to perform re-
quested operations. For this purpose, the Access Man-
ager is requested for checking access policies (Step
3). The Access Manager fetches access policies from
the Policy Store (Step 4). Next, it matches access
policies against the access request. Then, the access
response is sent back to the Access Request Proces-
sor (Step 5). If the user is authorized to perform the
requested operation, the Volume Renderer is invoked
with rendering parameters (Step 6). The requested
volume is retrieved from the Volume Store (Step 7).
Then, most of the rendering tasks, which do not re-
quire multiplication of opacities, are performed in the
encrypted manner and the partially rendered data is
sent to the Access Request Processor (Step 8). The
Access Request Processor performs the first round of
decryption on the rendered data, hides voxel positions
(e.g., permuting coordinates of the voxels) and sends
the data, protected pixel positions and the user iden-
tity to the Private Cloud Server (Step 9). The Pri-
vate Cloud Server performs the second round of de-
cryption and obtains partially rendered opacities in
plaintext. The plaintext opacities and encrypted col-
ors are sent to the Rendering Finisher module, which
performs rest of rendering tasks involving multiplica-
tion of opacities. Since the opacities are in plaintext,
the multiplication of opacities with colors are reduced
to a scalar multiplication. The Private Cloud Server
then sends the opacity disclosed (but shape protected
as voxel positions are unknown) and color encrypted
rendered image to the Access Requester (Step 10).
The Access Requester decrypts the colors and shows
the rendered image to the Image User (Step 11).
SECRYPT 2016 - International Conference on Security and Cryptography
286

5 SOLUTION DETAILS
3DCrypt is based on a modified Pailler cryptosys-
tem that supports re-encryption (Bresson et al., 2003;
Ateniese et al., 2006; Ayday et al., 2013) and is ho-
momorphic to additions and scalar multiplications.
Therefore, using this cryptosystem, we can encrypt
a volume, for which rendering has been adjusted such
that the post ray-projection rendering tasks including
interpolation and composition can be performed by a
combination of additions and scalar multiplications.
In order to provide the multi-user support, we extend
the modified Paillier cryptosystem such that each user
has her own key to encrypt or decrypt the images.
Therefore, for adding a new user or removing an ex-
isting one, re-encryption is not required.
The main goal of 3DCrypt is to leverage resources
of the Public Cloud Server as much as possible by
storing the data volume and by performing most of the
rendering tasks. To ensure confidentiality, both colors
and opacities are stored in an encrypted form. Infor-
mation about projected rays, however, must be avail-
able in plaintext as it is required in sampling and in-
terpolation steps of the rendering operation. Since the
Paillier cryptosystem is non-homomorphic to mul-
tiplication, composition, which multiplies opacities,
cannot be computed on encrypted opacities. Thus,
we employ a private cloud that can perform composi-
tion by knowing plaintext opacities. Since the knowl-
edge of opacities and pixel positions can perceptually
disclose shape of the rendered image, we consider to
protect voxel positions from the Private Cloud Server.
We can achieve this by permuting voxel positions to
dissociate them from projected rays.
A key difficulty in integrating the Paillier cryp-
tosystem with volume ray-casting is the incompatibil-
ity of floating point operations of ray-casting opera-
tions with the modular prime operation of the Paillier
cryptosystem. One way of overcoming this issue is
by converting the floating point interpolating factors
and opacities to their fixed point representatives. We
can achieve this by rounding off a float by d decimal
points and multiplying 10
d
with the round-off num-
ber.
Figure 4 provides the technical overview of
3DCrypt’s rendering system. In 3DCrypt, the KMA
generates the color-key-set {K
C
S
,K
C
U
} and the opacity-
key-set {K
A
S
,K
A
U
} for each user in the system (either
acting as a Volume Outsourcer or Image User). Each
key set contains pair of keys: the user-side key and the
server-side key. For each user i, the server-side key of
the color-key-set and the opacity-key-set, which are
K
C
S
i
and K
A
S
i
respectively, are securely transmitted to
the Public Cloud Server. The Public Cloud Server se-
Figure 4: Encryption and decryption processes using
3DCrypt.
curely stores all the server-side keys in the Key Store,
which could be accessible only to the Store Keeper
and the Access Request Processor. When the user i
is the Volume Outsourcer, the user-side keys of the
color-key-set and the opacity-key-set: K
C
U
i
and K
A
U
i
,
are transmitted to the user. However, when the user
i is the Image User, then the user-side key of color-
key-set and opacity-key-set, K
C
U
i
and K
A
U
i
, are sent to
the user and the Private Cloud Server, respectively.
The workflow of our secure rendering system can
be divided into three major steps: data preparation,
ray-dependent rendering and composition.
5.1 Data Preparation
This step is performed by the Volume Outsourcer
prior to projection of rays. In this step, the Vol-
ume Outsourcer performs two main tasks: (i) pre ray-
projection rendering and (ii) encryption of output of
the pre ray-projection rendering using user-side keys.
The pre ray-projection rendering maps the physical
property v
i jk
of the i jk
th
data voxel to its correspond-
ing color C and opacity A values. After this step, an
input volume V is represented as V
0
, where the i jk
th
voxel of V
0
contains colors and opacity found by the
physical property of the i jk
th
voxel of V .
For a user i, the colors and opacities of V
0
are en-
crypted using K
C
U
i
and K
A
U
i
, respectively (see Section
5.4. The encryption outputs E
∗
i
(C) and E
∗
i
(A) are sent
to the Store Keeper as an encrypted volume E
∗
i
(V
0
).
The Store Keeper then uses the server-side keys K
C
S
i
and K
A
S
i
to re-encrypt E
∗
i
(C) and E
∗
i
(A) and stores the
re-encrypted volume E(V
0
) in the Volume Store.
In the encryption process, we adopt two main op-
timizations to decrease the storage overhead. First,
we use an optimized modified Paillier cryptosystem.
Second, we encrypt three color components – R, G
and B – in a single big number rather than encrypting
them independently. We discuss both the optimiza-
tions below.
3DCrypt: Privacy-preserving Pre-classification Volume Ray-casting of 3D Images in the Cloud
287

Optimization of the Modified Paillier Cryptosys-
tem. The modified Paillier cryptosystem is repre-
sented as: E(C) = (e
1
,e
2
), where e
1
= g
r
and e
2
=
g
rx
∗ (1 +Cn), and C is the plaintext color. Likewise,
we encrypt the opacity A. Note that e
1
is independent
of the plaintext color. By using a different e
1
for a dif-
ferent color (a typical case), we need 2k bits (where
k is a security parameter) for storing e
1
of each color.
We propose to optimize this space requirement by us-
ing one e
1
for encrypting t colors, requiring 2k bits
for storing e
1
for all t colors. This optimization can
be achieved by using the same random number r for
all t colors.
Encrypting Color Components. Three color com-
ponents (i.e., R, G and B) undergo the same render-
ing operations. Each color component requires 8 bits
in plaintext, but is represented by 2 ∗ k bits when en-
crypted independently. We can reduce this overhead
by representing three color components as a single big
number and encrypting this number in the place of
encrypting the color components independently. This
encrypted number will then undergo rendering in the
place of rendering of color components. One trick
to create a big number from color components is by
multiplying 10
3∗m∗(d+ f )
(where d + f represents total
rounding places during rounding operations in render-
ing) to m
th
color component and add all the multipli-
cations.
5.2 Ray-dependent Rendering
In this step, the Public Cloud Server first fetches en-
crypted volume E(V
0
) from the Volume Store and
then performs sampling and interpolation on E(V
0
).
We use the same sampling technique as used by the
conventional ray-casting. The interpolation, however,
is performed on the encrypted color E(C) and opac-
ity E(A). The interpolation can be performed as ad-
ditions and scalar multiplications when the interpo-
lating factor I
i jk
is available in plaintext. We there-
fore disclose I
i jk
to the Public Cloud Server. Since
the floating point I
i jk
cannot be used with encrypted
numbers, the Public Cloud Server converts I
i jk
to
an integer I
0
i jk
by first rounding-off I
i jk
to d deci-
mal places and then multiplying 10
d
to the round-off
value. 3DCrypt is such that it allows the Public Cloud
Server to run additions and scalar multiplications over
encrypted numbers, as shown in Equations 1 and 2,
respectively.
E(C
1
) ∗ E(C
2
) = E(C
1
+C
2
) (1)
E(C)
I
0
i jk
= E(I
0
i jk
∗C) (2)
Likewise, we can compute opacity in an encrypted
manner. The interpolated color E(C
s
) and opacity
E(A
s
) for each sample point s are pre-decrypted using
the Image User j’s server-side keys K
C
S
j
and K
A
S
j
, re-
spectively. The pre-decrypted color E
∗
j
(C
s
) and opac-
ity E
∗
j
(A
s
) are then sent to the Private Cloud Server
along with the proxy ray to which the sampling point
s is associated.
5.3 Composition
In this step, the Private Cloud Server accumulates the
colors and opacities of all the sampling points along a
proxy voxel position. Since this step involves multi-
plication of opacities (which are non-homomorphic to
Paillier Cryptosystem), the Private Cloud Server per-
forms the second round of decryption on E
∗
j
(A
s
) using
the user j’s user-side key for opacity, K
A
U
j
. The multi-
plied opacities O
s
, which will be multiplied with en-
crypted color, however is a floating point number. As
discussed above, we can convert this float to an inte-
ger by first rounding-off the float by f places and then
multiplying 10
f
with the rounded-off value. Then,
we can perform encrypted domain color composition
using Equations 1 and 2. Note that since the avail-
able interpolated colors are in encrypted form, the
composited color E
∗
j
(C) also remains encrypted. Fur-
thermore, in absence of voxel positions of the image
space, the composited plaintext opacity A does not re-
veal shape of the rendered image.
The plaintext rendered opacity A and encrypted
rendered color E
∗
j
(C) are sent to the Image User, who
decrypts E
∗
j
(C) using K
C
U
j
and views the plaintext ren-
dered image.
5.4 Construction Details
In this section, we described the algorithms used in
our proposed scheme. We instantiate two instances
of the scheme: one for the color while other for the
opacity.
• Init(1
k
). The KMA runs the initialization al-
gorithm in order to generate public parameters
Params and a master secret key set MSK. It takes
as input a security parameter k, and generates two
prime numbers p and q of bit-length k. It com-
putes n = pq. The secret key is x ∈ [1,n
2
/2]. The
g is of order:
φ(n)
2
=
φ(p)φ(q)
2
=
(p−1)(q−1)
2
and can
be easily found by choosing a random a ∈ Z
∗
n
2
and
computing g = −a
2n
. It returns Params = (n,g)
and MSK = x. K
S
represents the Key Store, ini-
tialised as K
S
← φ.
SECRYPT 2016 - International Conference on Security and Cryptography
288

• KeyGen(MSK, i). The KMA runs the key gen-
eration algorithm to generate keying material for
users in the system. For each user i, this algo-
rithm generates two key sets K
U
i
and K
S
i
by choos-
ing a random x
i1
from [1, n
2
/2]. Then it calcu-
lates x
i2
= x − x
i1
, and transmits K
U
i
= x
i1
and
K
S
i
= (i,x
i2
) securely to user i and to the server,
respectively. The server adds K
S
i
to the Key Store
as follows: K
S
← K
S
∪ K
S
i
.
• ClientEnc(D, K
U
i
). A user i runs the data en-
cryption algorithm to encrypt the data D using her
key K
U
i
. To encrypt the data D ∈ Z
n
, the user
client chooses a random r ∈ [1, n/4]. It computes
E
∗
i
(D) = ( ˆe
1
, ˆe
2
), where
ˆe
1
= g
r
mod n
2
and
ˆe
2
= ˆe
x
i1
1
.(1 + Dn) mod n
2
= g
rx
i1
.(1 + Dn) mod n
2
.
• ServerReEnc(E
∗
i
(D), K
S
i
). The server re-
encrypts the user encrypted data E
∗
i
(D) = ( ˆe
1
, ˆe
2
).
It retrieves the key K
S
i
corresponding to the user i
and computes the re-encrypted ciphertext E(D) =
(e
1
,e
2
), where
e
1
= ˆe
1
= g
r
mod n
2
and
e
2
= ˆe
x
i2
1
. ˆe
2
= g
rx
.(1 + Dn). mod n
2
• ServerSum(E(D
1
), E(D
2
)). Given two encrypted
values E(D
1
) = (e
11
,e
12
) (where e
11
= g
r
1
and
e
12
= g
r
1
x
.(1 + D
1
n) and E(D
2
) = (e
21
,e
22
)
(where e
21
= g
r
2
and e
22
= g
r
2
x
.(1 + D
2
n)), the
server calculates the encrypted sum E(D
1
+D
2
) =
(e
1
,e
2
), where
e
1
= e
11
.e
21
= g
r
1
+r
2
mod n
2
and
e
2
= e
12
.e
22
mod n
2
= g
(r
1
+r
2
)x
.(1 + (D
1
+ D
2
)n) mod n
2
.
• ServerScalMul(c, E(D)). Given a constant
scalar factor c and an encrypted value E(D) =
(e
1
,e
2
) where e
1
= g
r
and e
2
= g
rx
.(1 + Dn), the
server calculates the encrypted scalar multiplica-
tion E(c.D) = (e
∗
1
,e
∗
2
), where
e
∗
1
= e
c
1
= g
rc
mod n
2
and
e
∗
2
= e
c
2
= g
rcx
.(1 + cDn) mod n
2
.
• ServerPreDec(E(D), K
S
j
). The server runs this
algorithm to partially decrypt the encrypted data
for the user j. It takes as input the encrypted
value E(D) = (e
1
,e
2
), where e
1
= g
r
and e
2
=
g
rx
.(1+Dn). The server retrieves the key K
S
j
cor-
responding to the user j and computes the pre-
decrypted data E
∗
j
(D) = ( ˆe
1
, ˆe
2
), where
ˆe
1
= e
1
= g
r
mod n
2
and
ˆe
2
= e
−x
j2
1
.e
2
mod n
2
= g
rx
j1
.(1 + Dn) mod n
2
.
• UserDec(E
∗
j
(D), K
U
j
). The user runs this algo-
rithm to decrypt the data. It takes as input the pre-
decrypted data E
∗
j
(D) = ( ˆe
1
, ˆe
2
) where ˆe
1
= g
r
and ˆe
2
= g
rx
j1
.(1 + Dn)), and her key K
U
j
, and re-
trieves the data by computing: D = L( ˆe
2
. ˆe
−x
j1
1
) =
L(1 + Dn), where L(u) =
u−1
n
for all u ∈ {u <
n
2
|u = 1 mod n}.
• Revoke(i). The server runs this algorithm to re-
voke user i access to the data. Given the user i,
the server removes K
S
i
from the Key Store as fol-
lows: K
S
← K
S
\K
S
i
.
6 IMPLEMENTATION AND
EXPERIMENT
(a) (b) (c)
Figure 5: Secure rendering for the Head image. Figure 5a,
Figure 5b and Figure 5c illustrate the rendered image avail-
able to the Image User, the Public Cloud Server and the
Private Cloud Server, respectively.
We implemented the secure ray-casting by integrat-
ing the modified Paillier cryptosystem to the volume
ray-casting module of the open source 3D visualiza-
tion software VTK6.3.0. We run the implemented
3DCrypt on a PC powered by Intel i5-4670 3.40 GHz
processor and 8 GB of RAM, running Ubuntu 15.04.
All the components of 3DCrypt, i.e., the Volume Out-
sourcer, the Public Cloud Server, the Private Cloud
Server, the Image User and the KMA were simu-
lated. Note that VTK is typically shipped with post-
classification volume ray-casting. We modified VTK
to provide pre-classification volume ray-casting. For
dealing with big number cryptographic primitive op-
erations, we integrated the MIRACL cryptographic li-
brary with VTK.
In our implementation, we chose a 1024-bit key
size. We round-off the floating point numbers used
in rendering operations by machine precision to avoid
round-off errors. For the modified Paillier encryption,
3DCrypt: Privacy-preserving Pre-classification Volume Ray-casting of 3D Images in the Cloud
289

we choose one random number r for all voxels of a
volume, requiring one e
1
= g
r
(first cipher compo-
nent) for all voxels.
Figure 5 illustrates how 3DCrypt provides per-
ceptual security in the cloud. An image available to
the Public Cloud Server is all black since the Public
Cloud Server does not know the color and opacity of
the pixels. The image available to the Private Cloud
Server, however, contains opacity information, which
can disclose shape of the image as voxel positions are
disclosed to the Private Cloud Server.
Performance Analysis. In 3DCrypt, processing by
the Volume Outsourcer and the encryption by the Pub-
lic Cloud Server are one-time operations, which could
be performed offline. The overheads of these opera-
tions, however, are directly proportional to the vol-
ume size. The overhead for a volume is equal to the
product of a voxel’s overhead with the total number
of voxels in the volume (i.e., the dimension of the
volume). In our implementation, we need approxi-
mately 4064 bits more space to store the encrypted
color and the opacity of a voxel (as two encryptions of
1024 bits key size are required for encrypting 32 bits
RGBA values). Thus, we require approximately 8.6
GB of space to store a 256 × 256 × 256 volume in en-
crypted domain (size of this volume in plaintext is ap-
proximately 67 MB). Similarly, for encrypting color
and opacity of a voxel, the Volume Outsourcer re-
quires approximately 540 millisecond (ms). The Pub-
lic Cloud Server requires approximately 294 ms more
computation with respect to the conventional plain-
text domain pre-classification volume ray-casting im-
plemented on the same machine. Thus, the Volume
Outsourcer and the Public Cloud Server require ap-
proximately 2.52 hours and 1.37 hours, respectively,
for encrypting the 256 × 256 × 256 volume.
The rendering by the cloud servers and the decryp-
tion by the Image User are performed at runtime, ac-
cording to the ray projected by the Image User. The
overhead of performing these operations affects visu-
alization latency, which is discussed below.
In 3DCrypt, the overhead of transferring and per-
forming the last round rendering operations in the Pri-
vate Cloud Server is equal to the product of total num-
ber of sample points with the overhead of a sample
point. Total number of sample points is equal to the
sum of the sample points along all the projected rays
and the number of sample points along a ray is im-
plementation dependent. For rendering and decrypt-
ing (the first round) the color and opacity of a sample
point, the Public Cloud Server requires approximately
290 ms of extra computation. For rendering and de-
crypting (the second round) opacity of a sample point,
the Private Cloud Server requires approximately 265
ms of extra computation (with respect to the conven-
tional plaintext domain pre-classification volume ray-
casting).
In our implementation, for rendering and decrypt-
ing the 256 × 256 × 256 volume data for a 256 × 256
image project space, the Public Cloud Server and the
Private Cloud Server require approximately 16.5 ex-
tra minutes and 15.2 extra minutes, respectively. Note
that for this data and image space, the data overhead
at the Private Cloud Server is approximately 1.75 GB.
The overhead of transferring and decrypting the
color-encrypted rendered image to the Image User is
equal to the product of the number of pixels in the
image space (which is equal to the number of pro-
jected rays) with the overhead for a single pixel. In
3DCrypt, the Private Cloud Server must send approx-
imately 2024 bits more data per pixel to the Image
User. Therefore, for rendering a 256 × 256 image,
the Image User must download 66.3 MB of more data
than the conventional plaintext domain rendering. In
addition, the Image User needs approximately 408 ms
of computation to decrypt and recover rendered color
of a pixel. Therefore, before viewing the 256 × 256
image, the Image User must work approximately 27
extra seconds.
Note that these results have been collected using
a non-optimized version of our code. Our current im-
plementation is based on MIRACL, which is also not
optimized. Finally, to improve the performance of
3DCrypt, we are currently working on a new parallel
version to take advantage of a more realistic top-of-
the-line hardware configuration used for the server-
side.
7 CONCLUSIONS
Cloud-based volume rendering presents the data con-
fidentiality issue that can lead to privacy loss. In this
paper, we addressed this issue by encrypting the vol-
ume using the modified Paillier cryptosystem such
that a pre-classification volume ray-casting can be
performed at the cloud server in the encrypted do-
main. Our proposal, 3DCrypt, provides several im-
provements over state-of-the-art techniques. First, we
are able to hide both color and shape of the rendering
object from a cloud server. Second, we provide bet-
ter security to collusion attack than the state-of-the-art
Shamir’s secret sharing-based scheme. Third, users
do not need to share keys for rendering volume stored
in the cloud (therefore, maintenance of per-volume
keys is not required).
To make 3DCrypt more practical, a future work
SECRYPT 2016 - International Conference on Security and Cryptography
290

can focus on decreasing the overheads both at the
cloud and the user ends. Furthermore, it will be also
be interesting to investigate whether we can extend
3DCrypt for the encrypted domain post-classification
volume ray-casting.
ACKNOWLEDGEMENT
This research is supported by STRATUS (Se-
curity Technologies Returning Accountability,
Trust and User-Centric Services in the Cloud,
https://stratus.org.nz), a project funded by the
Ministry of Business, Innovation and Employment
(MBIE), New Zealand.
REFERENCES
Ateniese, G., Fu, K., Green, M., and Hohenberger, S.
(2006). Improved proxy re-encryption schemes with
applications to secure distributed storage. ACM TIS-
SEC, 9:1–30.
Ayday, E., Raisaro, J. L., Hubaux, J.-P., and Rougemont,
J. (2013). Protecting and evaluating genomic privacy
in medical tests and personalized medicine. In ACM
WPES, pages 95–106.
Baharon, M., Shi, Q., Llewellyn-Jones, D., and Merabti, M.
(2013). Secure rendering process in cloud computing.
In PST, pages 82–87.
Bresson, E., Catalano, D., and Pointcheval, D. (2003). A
simple public-key cryptosystem with a double trap-
door decryption mechanism and its applications. In
ASIACRYPT, volume 2894 of Lecture Notes in Com-
puter Science, pages 37–54.
Chou, J.-K. and Yang, C.-K. (2015). Obfuscated volume
rendering. The Visual Computer, pages 1–12.
Cuervo, E., Wolman, A., and et al., L. P. C. (2015). Ka-
hawai: High-quality mobile gaming using GPU of-
fload. In MobiSys, pages 121–135.
Dasgupta, A. and Kosara, R. (2011). Adaptive privacy-
preserving visualization using parallel coordinates.
IEEE TVCG, 17(12):2241–2248.
Intel Inc. (2011). Experimental cloud-based ray tracing
using intel mic architecture for highly parallel visual
processing. Online Report.
KDDI Inc. (2012). Medical real-time 3d imaging solution.
Online Report.
Koller, D., Turitzin, M., and et al., M. L. (2004). Protected
interactive 3D graphics via remote rendering. In ACM
SIGGRAPH, pages 695–703.
Mohanty, M., Atrey, P. K., and Ooi, W. T. (2012). Secure
cloud-based medical data visualization. In ACMMM,
pages 1105–1108, Nara, Japan.
Mohanty, M., Ooi, W. T., and Atrey, P. K. (2013). Secure
cloud-based volume ray-casting. In IEEE CloudCom,
Bristol, UK.
3DCrypt: Privacy-preserving Pre-classification Volume Ray-casting of 3D Images in the Cloud
291