
from different clients, into a unified format. We as-
sume that a transformation function f(·) can achieve
this purpose. After going through f
key
(·) we always
get f
key
(E
Bank−1
(50)) = f
key
(E
Bank−2
(50)). Other-
wise, the system cannot satisfy the third requirement.
Note that the second requirement is in fact a
stronger version of the first requirement. Actually, in
our designed scheme, if all steps are implemented in
software, requirements 1, 3, 4, 5 are satisfied but re-
quirement 2 is not (i.e. there is an attack involving
a malicious untrusted cloud server). In order for our
scheme to satisfy requirement 2 as well, we need the
help of a Black Box (BB), which is a tamper-resistant
hardware token.
In this paper, for convenience, we describe our
solution PPDM DT Cloud with the hardware Black
Box. In applications (such as in a private cloud) that
requirement 1 is needed instead of requirement 2,
the solution can be trivially modified by putting all
BB implementation in software and some simple key
structure modifications. Details will be described in
the beginning of Section 5.
Black Box: Here, we need a tamper-resistant
hardware Black Box to help the system defending
the eavesdropping threat. Inside the BB, there is pre-
stored key pair (a private key and a public key). The
private key can only be utilized by functions inside
the BB. In other words, the private key will never be
leaked out. Note that as all BB contain the same key
structure. In our system, we need one BB is a Client
(we call it a Client-side BB) and the same kind of
BB is also used in a DSS (we call it a DSS-side BB).
Therefore only one kind of BB is needed to be man-
ufactured, and this is a significant advantage in pro-
duction. We will elaborate the detailed usage of this
Black Box in Section 5
5 CLOUD-BASED PPDM WITH
UNTRUSTED CLOUD SERVER
We roughly divide the whole process into five phases
and the overall system is depicted in Algorithm 1:
We consider the public and private cloud environ-
ment individually. If cloud server is untrusted (i.e.
the public cloud case), there is a threat that the cloud
server can get the plain text of data from clients.
To protect clients’ privacy from the untrusted cloud
server, as stated in Section 4, we need help of an ex-
ternal hardware (the BB) to defend this attack.
On the other hand, if the cloud server is trusted
(i.e. the private cloud case), as mentioned in Section
4, strong client security is not needed. We can have a
simple scheme without using the hardware BB. In this
Algorithm 1: PPDM DT Cloud with ElGamal.
KeyGeneration:
1: CCS generates an efficient description of a multi-
plicative cyclic group G of order q with generator
g, which are published to each client of this cloud
service.
2: C
i
secretly chooses a random s
i
from
{0, . . . , q− 1}, which is C
i
’s private ElGa-
mal key. While h
i
= g
s
i
is C
i
’s semi-public
ElGamal key PubEG
C
i
, which is kept from
knowing by CCS.
3: Meanwhile, there is one pair of Paillier key pre-
stored in Client-side and DSS-side Black Box.
Progress:
Phase 1: C
i
calls Algorithm 2 to encrypt his pri-
vate database DB
i
and then submits the encrypted
database to CCS.
Phase 2: CCS assigns DB
i
to different DSS and
each DSS keeps one part of DB
i
.
Phase 3.1: Whenever there is a subset of clients
C
sub
agreed on PPDM, they negotiate on a Group
Key GPkey and send a PPDM request to CCS.
Phase 3.2: CCS forwards the PPDM request to
each DSS. Each DSS, who keeps any part of
database belonging to the member of C
sub
, calls Al-
gorithm 3 to unify the database.
Phase 3.3: According to Algorithm 4, DSS com-
bines the unified databases from different sources
into one, and sends it back to CCS.
Phase 4.1: CCS further combines input from dif-
ferent DSS according to Algorithm 4.
Phase 4.2: CCS asks different DCS to build up the
Decision Tree DT, and gets the result E
GPkey
(DT)
from DCS.
Phase 5.1: CCS calls Algorithm 5 and sends
E
GPkey
(DT) back to each member of C
sub
.
Phase 5.2: All members in C
sub
collectively de-
crypt E
GPkey
(DT) to get the final result and check
the correctness of DT.
case, BB can be substituted by software. Also as BB
is not needed, the private key of BB will be replaced
by a private key shared by CCS and all DSS.
For the sake of ease discussion, in this paper
we only present the solution with BB for PPDM in-
volving an untrusted cloud server. In our scheme,
we choose a modified ElGamal cryptography model
combining with Paillier cryptography as the encryp-
tion cryptography.
In our scheme, we use Black Box (BB) to imple-
ment three algorithms, namely Algorithm 2 in Phase
1, Algorithm 3 in Phase 3, and Algorithm 5 in Phase
4. Any outside party can only call BB to execute these
CloudbasedPrivacyPreservingDataMiningwithDecisionTree
9