Secure Obfuscation for Encrypted Group Signatures.

In recent years, group signature techniques are widely used in constructing privacy-preserving security schemes for various information systems. However, conventional techniques keep the schemes secure only in normal black-box attack contexts. In other words, these schemes suppose that (the implementation of) the group signature generation algorithm is running in a platform that is perfectly protected from various intrusions and attacks. As a complementary to existing studies, how to generate group signatures securely in a more austere security context, such as a white-box attack context, is studied in this paper. We use obfuscation as an approach to acquire a higher level of security. Concretely, we introduce a special group signature functionality-an encrypted group signature, and then provide an obfuscator for the proposed functionality. A series of new security notions for both the functionality and its obfuscator has been introduced. The most important one is the average-case secure virtual black-box property w.r.t. dependent oracles and restricted dependent oracles which captures the requirement of protecting the output of the proposed obfuscator against collision attacks from group members. The security notions fit for many other specialized obfuscators, such as obfuscators for identity-based signatures, threshold signatures and key-insulated signatures. Finally, the correctness and security of the proposed obfuscator have been proven. Thereby, the obfuscated encrypted group signature functionality can be applied to variants of privacy-preserving security schemes and enhance the security level of these schemes.

Introduction

Group signature was proposed by Cham and Heyst [1], which is a special type of digital signature for a group of persons. In the group signature setting, there is a group having numerous members and a single manager (the group manager). A single verification key called the group public key is associated with the group. Each group member has its own secret signing key based on which it can produce a signature relative to the group public key. The group manager has a master secret key. Given a signature Σ, based on the master secret key, the group manager can extract the identity of the group member who created Σ. It is called traceability. On the other hand, those who are not holding the master secret key are unable to extract the identity of the group member who created Σ, which is called anonymity. In fact, a group signature has the following properties[1,2]: (i) only members of the group can sign messages; (ii) the receiver can verify whether it is a valid group signature; (iii) anonymity; (iv) traceability.

Group signature schemes provide functionalities which are applicable in many practical scenarios. In recent years, applications of group signature schemes in many emerging technologies or privacy-sensitive applications are studied, such as in social networks [3,4], medical information systems [5-7], Vehicular Ad hoc Networks (VANets) [8,9], electronic voting [10], Wireless Sensor Networks (WSNs) [11], electronic cash [12,13], and cloud computing [14-18] especially. These studies make great contributions for protecting security of information systems and privacy of users against various attacks. However, all these schemes are developed in the black-box model (or the so-called “black-box attack context”). In a black-box attack context, an adversary can access only the functionality of a cryptosystem. However, there is another security model (the white-box model) in which an adversary has total visibility of the implementation of the cryptosystem and full control over its execution platform. That is, the implementation of the cryptosystem is running in a White-Box Attack Context (WBAC).

In fact, we can find many typical WBACs, such as (1) a server or an endpoint for which a hacker has got the “root” or “admin” privilege; (2) a malicious host where mobile agents are running [19,20]; (3) an outdoor sensor node (of a WSN) captured by an attacker [21,22]; (4) the Digital Right Management (DRM) components in cable TV set-top boxes or IPTV equipments [23,24]; (5) On Board Units (OBUs) and Road Side Units (RSUs) in a VANet (e.g., the device suffers from the so called "Industrial insiders’ attack" in [25] or the "On-board tampering" attack in [26], or even the “Malware attack” in [27]); and (6) mobile devices (e.g., smart phones and tablets) captured by an attacker [28].

In WBACs, obfuscating techniques should be used while implementing key-related cryptographic functionalities to protect privacy-preserving schemes or security protocols based on group signature schemes. Hence, we contribute to the security requirements as follows.

A special obfuscatable group signature functionality, i.e., the encrypted group signature, is proposed with a concrete scheme, and then a corresponding obfuscator is provided.

Security notions of the encrypted group signature functionality and notions of the corresponding obfuscators are proposed. The most important one of the new security notions is average-case secure virtual black-box property (ACVBP) w.r.t. Dependent Oracles and Restricted Dependent Oracles, which describes the security requirement of protecting the output of the proposed obfuscator, i.e., the obfuscated implementation of encrypted group signature functionality against collision attacks from group members. The security notions fit for many other application scenarios.

The correctness and security of the proposed obfuscator are proven. The efficiency of the proposed encrypted group signature functionality and its obfuscator is analyzed.

Besides the contributions to cryptography, the result is useful in many applications. For example, the proposed technique can be applied in cloud computing. In this application, an inner user can upload a file anonymously on the private cloud of a company. However, in the case that an investigation is needed, the group manager is capable of opening the identity of the user. For another example, in a privacy-preserving emergency call (PEC) scheme for mobile healthcare social networks, the obfuscatable encrypted group signature scheme and its obfuscator can be used to implement a decentralized emergency response system for a rapid response of emergency care in the network. The application demonstrates that, with the help of encrypted group signature technique, the PEC preserves users’ privacy by hiding their identities, and it avoids unnecessary disclosure of personal health information. The details of these applications are provided in Section 6.1.1 and 6.1.2 to demonstrate the applicability in concrete scenarios.

Furthermore, we found that the proposed solution can be adapted to identity-based cryptography and key-insulated cryptography. Therefore, how to transform the proposed obfuscatable encrypted group signature scheme into an obfuscatable encrypted identity-based signature scheme and an obfuscatable encrypted key-insulated signature scheme are sketched out in Section 6.1.3.

The remainder of this paper is organized as follows. The next section presents background information about obfuscation and obfuscators. The section also provides a brief introduction on the complexity assumptions needed in this paper. Section 3 first proposes an overall scheme that is a combination of a group signature scheme and an asymmetric encryption scheme, then an obfuscatable Encrypted Group Signature (EGS) functionality based on the overall scheme is provided. Section 4 presents an obfuscator for the proposed EGS functionality and proves the correctness and security of the obfuscator. Moreover, a series of security notions of the functionality and the obfuscators is also introduced in Section 4. In Section 5, we compare the results of the proposed scheme with the ones in other studies on obfuscation for cryptographic purpose. A discussion on possible applications and extensions of the proposed scheme and the obfuscator is provided in Section 6. The rationale behind the obfuscatable sign-then-encrypt functionalities and our main contributions is also discussed in this section. Finally, the article concludes in Section 7 with future work.

Preliminaries and Background

2.1 Obfuscation and Its Recent Advances

Informally, the goal of obfuscation is to make a computer program "unintelligible" while preserving its functionality, and an obfuscator is a “compiler” that performs such transformations [29,30]. As the results in [29-33] are mainly about the difficulties or even impossibilities of obfuscation, it is a hard work to find a secure obfuscator, even though for a special functionality. Some positive results were reported besides these negative results for general-purpose obfuscation, such as in [29-33]. However, these positive results mainly serve as theoretical illustrations and many of these positive results are not suitable for practical applications.

Despite these positive results for theoretical study, obfuscators for cryptographic-related functionalities with acceptable runtime cost remained elusive until the obfuscatable encrypted signature [34] and the obfuscatable re-encryption [35] were proposed. Fortunately, after these two articles were published, several obfuscatable cryptographic-related functionalities were identified and the corresponding secure obfuscators were proposed in recent years [36-41].

We note that these positive results do not violate the general impossibility results. One of the reasons is that they are not general-purpose obfuscation. The other one is that they have used distinct weak security criteria such as the ACVBP proposed by Hohenbergeret al. [35] or the simulation-based average-case virtual black-box property proposed by Hofheinz et al. [42].

Two general-purpose obfuscators [43,44] were proposed in recent two years, however, they either use a weak security notion or use the homomorphic encryption techniques with high costs of space and time.

Both general-purpose obfuscators and specialized obfuscators for cryptographic functionalities usually set the input as a (probabilistic) circuit in theoretical analysis. A brief review on probabilistic circuits and circuit obfuscators is provided in the following subsection.

2.2. Probabilistic Circuits and Circuit Obfuscators

As prerequisites of security analysis, we use the conventional definitions and notations of probabilistic circuits and circuit obfuscators following those in [29,30,34,35].

Let Poly(λ) denote the set of all polynomials of λ. Let ℂ be a set of polynomial-size circuits with input length l (λ) ∈ Poly(λ) and output length l (λ) ∈ Poly(λ). Usually, we use ℂ = {ℂ} to denote a class of such circuits, where there exists an associated Probabilistic Polynomial Time (PPT) generation algorithm which takes as input 1 and generates a random circuit ℂ ∈$ ℂ. In studies on obfuscation for cryptographic purpose, it usually corresponds to the random generation of system parameters or cryptographic keys on the security parameter 1. The generation process is denoted by C ← ℂ. When a circuit C is used as an input argument or an output result of an algorithm, it is assumed that a specification of the circuit is used implicitly.

Let para be the set of regular input parameters and rand be the random input variable. Suppose that C(para, rand) is a probabilistic circuit. Given an arbitrary regular input para, we can consider C(para,·) (or C (·)) as a sampling algorithm for the distribution obtained by evaluating the output of C(para, rand) on random variable rand. Given a couple of probabilistic circuits (C 0, C 1) whose regular inputs are of the same length, the two distributions produced by C 0(para,·) and C 1(para,·) are denoted by the pair (C 0(para), C 1(para)). The statistical difference between them is defined in (1) [34].

Moreover, for a Turing machine M, its black-box access to a probabilistic circuit C can be divided into two categories, i.e., “oracle access” and “sampling access”. Oracle access means that the Turing machine M is allowed to set both regular and random inputs. It is denoted by M as the traditional way. Sampling access means that the Turing machine M is only allowed to set the regular input. It is denoted by M ≪.

An obfuscator for a class of circuits ℂ = {ℂ} is a PPT machine which takes a circuit C ∈ ℂ as input and outputs an unintelligible circuit C' which preserves the functionality. The formal description of “preserving functionality” is given by Definition 1 in section 4.2.

2.3. Complexity Assumptions

The overall scheme containing the obfuscatable EGS functionality in this paper is built based on a group signature scheme [45] and an asymmetric linear encryption scheme [46], so, we make use of the following four complexity assumptions as the theoretical basis of our work.

Remark 1

Although most cryptosystems based on pairings assume for simplicity that bilinear groups have prime order. In our case, it is important that the pairing is defined over a group G containing |G| = n elements, where n = pq has a (ostensibly hidden) factorization in two large primes, p ≠ q. Moreover, G and G denote the cyclic subgroups of G with respective order p and q.

The Computational Diffie-Hellman (CDH) assumption in bilinear groups. This assumption states that, given a triple for random exponents a, b ∈ Z, there is no PPT algorithm that can compute g ∈ G with non-negligible probability. Because of the bilinear pairing, CDH in G implies a “Gap Diffie Hellman” assumption.

The subgroup decision assumption. Consider an “instance generator” algorithm 𝓖𝓖 that, on input a security parameter 1, outputs a tuple (p, q, G, G , e), in which p and q are independent uniform random λ-bit primes, G and G are cyclic groups of order n = pq with efficiently computable group operations (over their respective elements, which must have a polynomial size representation in λ), and e: G × G → G is a bilinear map. The subgroup decision assumption is that on input a tuple (n = pq, G, G , e) derived from a random execution of 𝓖𝓖(1), and an element w selected at random either from G or from G , there is no (PPT) algorithm can decide whether w ∈ G with non-negligible advantage.

The Hidden Strong Diffie-Hellman assumption. We first define the l-HSDH problem as follows: On input three generators g, h and g of G , and l-1 distinct triples where c ∈ Z, output another such triple distinct of all the others. The Hidden Strong Diffie-Hellman assumption states that, in a family of prime order bilinear groups generated by the instance generator 𝓖𝓖, there is no PPT algorithm can solve the HSDH problem in the bilinear group with non-negligible probability for sufficiently large λ ∈ ℕ.

The Decisional Linear (DLIN) assumption. We first define the Decision Linear Problem in G as follows: Given u, v, h, u , v , h ∈ G as input, output yes if a+b = c and no otherwise. The DLIN assumption states that, there is no (PPT) algorithm can solve the Decision Linear Problem with non-negligible advantage.

Remark 2

The DLIN problem is originally defined in a prime-order group in [46]. In our case, we use the DLIN assumption over composite-order group, similar assumptions could be found in literatures such as [47] and [48].

An Obfuscatable Encrypted Group Signature Functionality

We propose an overall scheme that is a combination of a group signature scheme and an asymmetric encryption scheme. The scheme consists of seven algorithms: Setup, Enroll, Sign, Verify, EKGen, Enc and Dec. Based on the scheme, an obfuscatable EGS algorithm implements the EGS functionality is then provided.

3.1. The Overall Scheme

There are seven types of roles (see Fig 1) in the scheme: The first type is the group master. It is a trusted authority (TA) which is in charge of initializing system parameters, generating public parameters, setting up the group and issuing secret signing keys to the group members. Furthermore, the TA also certificates public encryption keys for all users (member or nonmember of the group). Sometimes, the master key MK is destroyed once the group is set up. The second type is the group manager, which is given the ability to identify signers using the tracing key TK, but not to enroll new users or create new signing keys. The third type is regular member users (group members, or signers) that each one is given a distinct secret signing key K ID. The fourth type is verifiers, who can verify signatures using the public parameters. The fifth type is encryptors and the sixth type is decryptors which are not shown in Fig 1 as they are too simple. These three types (i.e., the fourth type, the fifth type and the sixth type) of users could be either a group member of nonmember. The seventh type is obfuscators.

Fig 1

The usage of the Setup algorithm.

Algorithms proposed in [45] (a group signature scheme) and [46] (an asymmetric linear encryption scheme) are used to construct the overall scheme. Hence, the algorithms of the overall scheme are similar to the corresponding algorithms in [45] and [46]; in fact, they are slightly modified or only different in description. Note that it is not a trivial work to the overall scheme because the signing algorithm Sign and the encryption algorithm Enc should be “compatible” to construct the obfuscatable EGS functionality. These algorithms in the scheme are introduced in the following subsections. To make the algorithms easier to understand, we list frequently used symbols in Table 1.

Table 1

Symbols.

Symbol	Description
pub	A tuple consists of system parameters and public values
MK	The master enrollment key
TK	The group manager’s tracing key
2k	The maximum number of signers
{0,1}m	The message space
G, G T	Cyclic groups
G p, G q	Subgroups of G
ID	The user’s identity
s ID	A secret unique value corresponding to ID
K ID	The private signing key
M	A message
σ	A signature
PK e	The encryption key
SK e	The decryption key
C	Ciphertext

3.1.1. Setup

The Setup algorithm takes a security parameter in unary as input. The algorithm outputs pub (a tuple consists of system parameters and public values), the master enrollment key MK, and the group manager’s tracing key TK. Suppose that up to 2 signers are supported in the group, and the message space is {0,1}, where k = O(λ) and m = O(λ). Let Gen[group] denote the set of generators of the “group”. The usage of the algorithm is illustrated in Fig 1.

The algorithm proceeds as follows.

Algorithm Setup(1λ,1,1)

Begin

,p and q are prime numbers s.t. log2 p = Θ(λ)>k∧log2q=Θ(λ)>k

n←p·q

builss a cyclic bilinear group G of order n

Let G be the cyclic subgroups of G of order p

Let G be the cyclic subgroups of G of order q

Ω←g ω ∈ G

u,v',v 1,…,v ∈ Gen[G]

PP←(g,h,u,v’,v 1,…,v Ω,A) ∈ G × G × G × G

MK←(g ,ω) ∈ G × Z

TK→q ∈ ℕ

output (pub,MK,TK)

End

3.1.2. Enroll

The algorithm Enroll serves for creating a signing key for a user whose identity is ID, where 0≤ID< 2

Fig 2

The usage of the Enroll algorithm.

The algorithm proceeds as follows.

Algorithm Enroll (pub,MK, ID)

Begin

(g, h, u, v', v 1,…,v , Ω, A) ← PP

(g ,ω) ← MK

End

3.1.3. Sign

The signing algorithm takes pub(a tuple consists of system parameters and public values), a group member’s private signing key K ID, and the message M = (μ 1,…, μ ) ∈ {0,1} as input. The algorithm outputs a signature (σ 1, σ 2, σ 3, σ 4, π 1, π 2) using the following procedure.

Algorithm Sign(pub, K)

Begin

(g, h, u, v', v ,..., v , Ω, A) ← PP

(μ ,...,μ ) ← M

output (σ 1, σ 2, σ 3, σ 4, π 1, π 2)

End

3.1.4. Verify

The group signature verification algorithm Verify takes pub(a tuple consists of system parameters and public values), a signature σ from an unknown group member, and a message M as input. If the signature σ is valid, it outputs 1, otherwise, outputs 0. Note that the verification algorithm outputs 1 only implies that the signature is generated by a member of the given group, but does not reveal the identity of the original signer.

Algorithm Verify(pub, σ, M)

Begin

(σ 1, σ 2, σ 3, σ 4, π 1, π 2) ← σ

(g, h, u, v', v 1, …, v , Ω, A) ← PP

(μ 1, …, μ ) ← M

output 1

Else

output 0

End

3.1.5. Open

As it is illustrated in Fig 3, to recover the identity of the signer, the group manager using the algorithm Open to test whether the signature is generated by a specific member of the group. If it is true, the algorithm outputs the identity of the member, otherwise, the output is ⊥.

Fig 3

The usage of the Open algorithm.

The algorithm proceeds as follows.

Algorithm Open(pub, σ, TK)

Begin

(σ 1, σ 2, σ 3, σ 4, π 1, π 2) ← σ

(g, h, u, v', v ..., v , Ω, A) ← PP

For Each ID

output 1; exit;

output ⊥

End

3.1.6. EKGen

The encryption key generation algorithm EKGen takes the public parameters pub as input, and generates a key pair (PK , SK ) as follows. Note that for each user, the TA should provide a certification for the public encryption key PK .

Algorithm EKGen(pub)

Begin

(g,h,u,v′,v 1,…,v Ω,A)←PP

PK ←(g ,g ),SK ←(a,b)

output(PK SK )

End

3.1.7. Enc and Dec

The encryption algorithm Enc takes the public parameters pub, the encryption key PK , and a (encoded) plaintext M ∈ G as input. The algorithm encrypts the plaintext and then outputs the ciphertext as follows.

Remark 3

For simplicity, we use to denote the encryption algorithm while the encryption key is PK . Similarly, we use to denote the decryption algorithm while the decryption key is SK .

Algorithm

Begin

(g, h, u, v', v 1,…, v , Ω, A) ← PP

(PK , PK ) ← PK

C←(PKe,0 x, PKe,1 y, gx+y ⋅ M)

Output C

End

The decryption algorithm Dec works as follows.

Algorithm Dec

Begin

(C , C , C ) ← C

(a, b) ← SK

output M

End

3.2. The Encrypted Group Signature Functionality

The encrypted group signature (EGS) functionality , with respect to a tuple pub that consists of system parameters and public values, the signing key sk, and the encryption key PK , works as follows.

Algorithm

Begin

IF(M = NULL)

output (pub, PK)

Else

(σ 1, σ 2, σ 3, σ 4, π 1, π 2) ← Sign(pub,sk,M)

End

The activities of the overall scheme and the EGS functionality, include setting up the system, activating a group manager, enrolling a group member, generating and verification of a encrypted group signature, and opening the signature, are illustrated in Fig 4.

Fig 4

The activity diagram.

3.3. Efficiency Analysis

In Table 2, we list the numbers of various operations that are needed to perform each algorithm in section 3.1 and 3.2 column by column. It is shown from the table that the scheme has high efficiency in general, as the time-consuming pairing operation is only used in the Verify algorithm.

Table 2

Efficiency of the algorithms (listed in number of operations).

		Setup	Enroll	Sign	Verify	Open	EKGen	Enc	Dec	EGS
In Z n	Rand	2	1	5	0	0	2	2	0	17
	Add	0	1	0	0	0	0	1	0	6
	Mult	0	1	1	0	0	0	0	0	1
	Inv	0	1	0	0	0	0	0	2	0
	Neg	0	0	2	0	0	0	0	0	0
In G	Rand	0	0	0	0	0	0	0	0	0
	Mult	0	0	2m+9	m+1	0	0	1	2	2m+15
	Exp	2	3	2m+12	m	1	2	3	2	2m+30
	Inv	0	0	0	0	0	0	0	2	2
In G T	Mult	0	0	0	3	0	0	0	0	0
	Inv	0	0	0	3	0	0	0	0	0
G 2→G T	Pair	1	0	0	6	0	0	0	0	0

“Rand” denotes the operation that generates a random element of the group or ring. “Add” and “Mult” denote the addition and multiplication, respectively. “Neg” denotes the operation that generates an addictive inverse and “Inv” denotes the operation that generates a multiplicative inverse. “Pair” denotes the pairing operation.

Remark 4

The algorithm Setup also needs some operations that have not been listed in Table 2, such as generation of groups and large prime numbers, and random selection of group generators.

Remark 5

The algorithm Open can be done in constant time. Because the value can be calculated once and for all for each user, we can construct a lookup table of for all users in the group. With the help of the lookup table, the algorithm “Open” only needs to compute (σ 2).

In the next section, we introduce an obfuscator for the proposed EGS functionality, and prove the correctness and security of the obfuscator.

A Secure Obfuscator for the Special EGS Functionality

In this section, we introduce a secure obfuscator for the special EGS functionality. The proposed obfuscator can either be deployed in a physically secure device or in the signer’s host.

Fig 5 illustrates the workflow of obfuscation.

Fig 5

The workflow of obfuscation.

4.1. Design of the Obfuscator

In this subsection, we propose an obfuscator Obf for the that implements the encrypted group signature (EGS) functionality as follows.

(PK ,PK )←PK

(K 1,K 2,K 3)←sk

Constructs and outputs an obfuscated circuit that does the following on the input message M:

Begin

IF(M=NULL)

output(pub,PK )

Else

(μ 1…μ )←M

(PK ,PK )←PK

For(i=1;i≤4;i++)

EndFor

For(i=1;i≤6;i++)

IF(i≤3)

Else IF(i=5)

Else

EndFor

For(i=1;i≤4;i++)

EndFor

End

In Table 3, we list the numbers of various operations that are needed in an obfuscating transformation. Although the obfuscator looks complicated, it remains in high efficiency because the time-consuming pairing operation is never used and the complexity has nothing to do with the number of signers.

Table 3

Efficiency of the obfuscator.

Operation	In Z n					In G
	Rand	Add	Mult	Inv	Neg	Rand	Mult	Exp	Inv
Number	24	9	7	0	2	0	2m+29	2m+43	0

“Rand” denotes the operation that generates a random element of the group or ring. “Add” and “Mult” denote the addition and multiplication, respectively. “Neg” denotes the operation that generates an addictive inverse and “Inv” denotes the operation that generates a multiplicative inverse.

In the next two subsections, we study the “correctness” and “security” of the obfuscator respectively.

4.2. Preserving Functionality

The correctness of an obfuscator Obf requires that, on a circuit C, Obf(C) behaves identically to C on all inputs with probability 1. Formally, this property is called “Preserving Functionality” as described in Definition 1 [34,35].

Definition 1. Preserving Functionality

A PPT machine Obf is a circuit obfuscator for a class of probabilistic circuits ℂ = {ℂ} if, for every probabilistic circuit C ∈ ℂ, (2) holds: where the statistical difference StaDiff between C(x) and C′(x) is given by (1).

Theorem 1. (Preserving Functionality). Consider any circuit and let circuit . On every possible input, the output distributions of and are identical.

Proof. Suppose that PK = (g , g ). On an arbitrary message M≠NULL, the output of is (c = Enc(σ , PK )i = 1,2,3,4, c = Enc(π , PK )) where (σ 1, σ 2, σ 3, σ 4, π 1, π 2) = Sign(M, sk ID). Let sk ID = (K 1, K 2, K 3) and M = (μ 1…μ ) ∈ {0,1}. We have where s, t 1, t 2, t 3, t 4, r 1,…, r 6, s 1,…, s 6 are uniformly random elements of Z .

Because , we have: where In (10), x 1, y 1, x 2, y 2, x 3, y 3 are uniformly random elements of Z .

For the same input M, suppose that the output of is Consequently, we have: In the above six equations, are uniformly random elements of Z .

Let , the two tuples of ciphertexts are listed in Table 4.

Table 4

Comparison of ciphertexts.

i	ci	c_i'
1	g^r_1a,g^s_1b,g^r_1+s_1⋅K_1⋅h^t_1	g^a(x_1^*+x_1),g^b(y_1^*+y_1),g^(x_1^*+x_1)+(y_1^*+y_1)⋅K_1⋅h^t_1^*
2	g^r_2a,g^s_2b,g^r_2+s_2⋅K_2⋅h^t_2	g^a(x_2^*+x_2),g^b(y_2^*+y_2),g^(x_1^*+x_1)+(y_1^*+y_1)⋅K_1⋅h^t_2^*
3	g^r_3a,g^s_3b,g^r_3+s_3⋅K_3⋅V^s⋅h^t_3	g^a(x_3^*+x_3),g^b(y_3^*+y_3),g^(x_3^*+x_3)+(y_3^*+y_3)⋅K_1⋅V^s^*⋅h^t_3^*
4	g^r_4a,g^s_4b,g^r_4+s_4⋅g^−s⋅h^t_4	g^ax_4^*,g^by_4^*,g^x_4^*+y_4^*⋅g^−s^*⋅h^t_4^*
5	g^r_5a,g^s_5b,g^r_5+s_5⋅h^t_1t_2⋅(K_1)^t_2⋅(K_2Ω)^t_1	g^a(x_5^*+x_1t_2^*+x_2t_1^*),g^b(y_5^*+y_1t_2^*+y_2t_1^*),g^(x_5^*+x_1t_2^*+x_2t_1^*)+(y_5^*+y_1t_2^*+y_2t_1^*)⋅h^t_1^*t_2^*⋅(K_1)^t_2^*⋅(K_2Ω)^t_1^*
6	g^r_6a,g^s_6b,g^r_6+s_6⋅u^t_2⋅g^−t_3⋅V^t_4	g^ax_6^*,g^by_6^*,g^x_6^*+y_6^*⋅u^t_2^*⋅g^−t_3^*⋅V^t_4^*

Clearly, the two tuples of ciphertexts are identically distributed.

If the input is a null message M = NULL, both the output of and the output of are (pub, PK ).

This ends the proof.

4.3. Security Properties

4.3.1. Security notions for the EGS functionality and the obfuscator

Average-Case Secure Virtual Black-box Property (ACVBP) was proposed in [35], and it was extended to ACVBP w.r.t. Dependent Oracles in [34]. The generalization allows distinguishers to have sampling access not only to <> but also to a set of oracles dependent on C.

Definition 2

A circuit obfuscator Obf for ℂ satisfies the ACVBP w.r.t. dependent oracle set T if the following condition holds: There exists a PPT oracle machine S (simulator) such that, for every PPT oracle machine 𝓓 (distinguisher), every polynomial f, all sufficiently large λ ∈ ℕ, and every z ∈ {0,1}poly(, where 𝓓 << means that 𝓓 has sampling access to all oracles contained in T(C) in addition to C.

To the best of our knowledge, in obfuscating sig-then-encrypt functionalities, T(C) is always assigned to the signature function, such as in [34,36,38,41,49,50]. However, we have to investigate the effects of collision attacks from some members of the same group against the proposed obfuscator. In this scenario, the adversary against the obfuscator can get the signing key of a corrupted group member, that is, the adversary can query the Enroll oracle on the identity of a corrupted member. Because there are some restrictions on these kinds of queries, we define a set of restricted oracles dependent on C as 𝓡(C). Each element of 𝓡(C) is an oracle-restrictions pair. For example, in this paper 𝓡(C) = {(Enroll, id≠ID)}. Conventionally, when 𝓡(C) consists of only one element, we omit the braces. Moreover, we suggest that the restrictions could be written as superscripts of the oracle, e.g., Enroll [.

Based on the above intuition, we extended ACVBP w.r.t. Dependent Oracles (Definition 2) to ACVBP w.r.t. Dependent Oracles and Restricted Dependent Oracles as follows.

Definition 3

A circuit obfuscator Obf for ℂ satisfies the ACVBP w.r.t. dependent oracle set T and restricted dependent oracle set 𝓡 if the following condition holds: There exists a PPT oracle machine S (simulator) such that, for every PPT oracle machine 𝓓 (distinguisher), every polynomial f, all sufficiently large λ ∈ ℕ, and every z ∈ {0,1}poly(, where 𝓓 << means that 𝓓 has sampling access to all oracles contained in T(C) and 𝓡(C) in addition to C.

Besides the security notion for the obfuscator in WBAC, we should also provide security notions for the EGS functionality. There is a number of existing security notions of group signature schemes. Fortunately, as shown in Fig 6, there are two cores that imply other security notions as it was discussed in [2]. Hence, we focus on the full traceability (FT) and full anonymity (FA). Note that we use the CPA-full-anonymity[46] instead of the CCA2-full-anonymity[2].

Fig 6

Security notions of group signature schemes.

We formally define full-traceability (FT w.r.t. EGS Functionality) using the following experiment.

Begin

(PK , SK ) ← EKGen(pub)

st←(pub, TK, PK );Θ←∅;L ← ∅;Γ←ε;count←true

While(cont = true) do

IF(cont = true)

Θ←Θ∪{id};Γ ← Enroll(pub, MK, id)

EndWhile

IF(0 = Verify(pub, σ, M)) return 0;

IF(⊥ = Open(pub, TK, σ, M)) return 0;

IF(∃id ∈ [0,…, 2 – 1], s.t. id = Open(TK, σ, M) ∧ id ∉ Θ ∧ (M, ID) ∉ L)

return 0

Else

return 1

End

Definition 4

(FT w.r.t. EGS Functionality). Let (Setup, Enroll, Sign, Verify) and (EKGen, Enc, Dec) be a pair of group signature and public key encryption schemes. The group signature scheme is FT w.r.t. the EGS functionality if the following condition holds: For every PPT oracle machine 𝓕 (adversary), every polynomial f, all sufficiently large λ ∈ ℕ, and every st ∈ {0,1}poly(, We formally define full-anonymity (FA w.r.t. EGS Functionality) using the following experiment.

Begin

(PK ,SK ) ← EKGen(pub)

SK ← ∅;id ← 0

While(id < 2) do

SK ← SK ∪ Enroll(pub,MK,id);id ← id + 1

EndWhile

return d

End

Definition 5

(FA w.r.t. EGS Functionality). Let (Setup, Enroll, Sign, Verify) and (EKGen, Enc, Dec) be a pair of group signature and public key encryption schemes. The group signature scheme is full anonymous w.r.t. the EGS functionality if the following condition holds: For every PPT oracle machine 𝓕 (adversary), every polynomial f, all sufficiently large λ ∈ ℕ, and every st ∈ {0,1}poly(, Next, we consider a pair of stronger security notions, which require that the group signature scheme is still secure even when the adversary is given an obfuscated circuit. The following experiments are used to describe the strengthened definitions of full-traceability and full-anonymity respectively.

Begin

(PK) ← EKGen(pub)

st ← (pub, TK, PK );SK ← ∅;Θ ← ∅;L ← ∅;Γ ← ε;cont ← true

While(id < 2) do

SK ← SK ∪ Enroll(pub, MK, id);id ← id + 1

EndWhile

While(cont = true) do

IF(cont = true)

Θ ← Θ ∪ {id};Γ ← Enroll(pub, MK, id)

EndWhile

IF(0 = Verify(pub, σ, M)) return 0;

IF(⊥ = Open(pub, TK, σ, M)) return 0;

IF(∃id ∈ [0, …, 2 - 1], s.t. id = Open(TK, σ, M) ∧ id ∉ Θ ∧ (M, ID) ∉ L)

return 0

Else

return 1

End

Algorithm O (id)

Begin

Extract sk from SK

End

Begin

(PK , SK ) ← EKGen(pub)

SK ← ∅;id ← 0

While(id < 2) do

SK ← SK ∪ Enroll(pub, MK, id);id ← id + 1

EndWhile

return d

End

Algorithm O (id)

Begin

Extract sk from SK

End

Now we give definitions of full-traceability (FT) and full-anonymity (FA) w.r.t. EGS Obfuscator as follows.

Definition 6

(FT w.r.t. EGS Obfuscator). Let (Setup, Enroll, Sign, Verify) and (EKGen, Enc, Dec) be a pair of group signature and public key encryption schemes. The group signature scheme is FT w.r.t. Obf if the following condition holds: For every PPT oracle machine 𝓕 (adversary), every polynomial f, all sufficiently large λ ∈ ℕ, and every st ∈ {0,1}poly(,

Definition 7

(FA w.r.t. EGS Obfuscator). Let (Setup, Enroll, Sign, Verify) and (EKGen, Enc, Dec) be a pair of group signature and public key encryption schemes. The group signature scheme is FA w.r.t. Obf if the following condition holds: For every PPT oracle machine 𝓕 (adversary), every polynomial f, all sufficiently large λ ∈ ℕ, and every st ∈ {0,1}poly(,

Definition 8

A circuit obfuscator Obf for ℂ is rerandomizable (RR) w.r.t. dependent oracle set T and restricted dependent oracle set 𝓡 if the following condition holds: There exists a PPT oracle machine RR such that, for every PPT oracle machine 𝓓 (distinguisher), every polynomial f, all sufficiently large λ ∈ ℕ, and everyz ∈ {0,1}poly(, when C ∈ ℂ and C′←Obf(C), (24) holds. In (24), 𝓓 << means that 𝓓 has sampling access to all oracles contained in T(C) and 𝓡(C) in addition to C.

Note that if a circuit obfuscator Obf for ℂ is rerandomizable w.r.t. dependent oracle set T and restricted dependent oracle set 𝓡 and Obf also satisfies the ACVBP w.r.t. dependent oracle set T and restricted dependent oracle set 𝓡, we say that Obf is RR&ACVBP w.r.t. dependent oracle set T and restricted dependent oracle set 𝓡.

There are six new security notions that are proposed in this section. Relationships among the proposed security notions and known security notions are shown in Fig 7. In Fig 7, the arrows denote the “imply” relationships. Most of the “imply” relationships are easy to verify so we omit the detail analysis, except the complex one that is investigated in Theorem 3.

Fig 7

Relationships among the proposed security notions and known security notions.

As illustrated in Fig 7, some new security notions are equal to old ones. Especially, Definition 5 (FA w.r.t. EGS Obfuscator), Definition 7 (FA w.r.t. EGS functionality) and the CAP-full-anonymity (in [46]) are equivalent. Hence, from the practice point of view, it seems that Definition 5 and Definition 7 are somewhat useless because in fact depict the same security of CAP-full-anonymity. However, to provide these security notions and investigate them are necessary, both to acquire the result and to fulfill the completeness of theory.

4.3.2. The main security theorem

Theorem 2. The proposed obfuscator Obf for the proposed EGS functionality satisfies ACVBP w.r.t. dependent oracle and restricted dependent oracle .

Proof. We have , and . Then we define a pair of probabilities in (25) and (26). They are the probabilities that 𝓓 << outputs 1, given the real and simulated distributions, respectively. sk ID = (K 1, K 2, K 3) is encrypted in the real distribution while (K 1′, K 2′, K 3′) ∈ $ G 3 is encrypted in the simulated distribution. It is the only difference.

Let and We construct a simulator Sim that works as follows

(g , g ) ← PK

For contradiction, assume that the probability that a distinguisher can distinguish between C' and C" is not negligible. That is, the difference between the following two probabilities is not negligible. Without loss of generosity, we suppose that Pr-Pr = δ > 0.

Then an adversary pair (𝓐, 𝓑) which breaks the indistinguishability of the linear encryption scheme is constructed as follows. 𝓐 produces a plaintext pair 〈sk ID, sk′〉, and the associated public setting and some global parameters of the asymmetric encryption scheme using 𝓐.Init and plays the following security game with 𝓓 and 𝓑.

We list the usage of the algorithms that are used in Game1, i.e., 𝓐.Init, 𝓐.OC, 𝓐.OS, 𝓐.OE, 𝓐.Guess, and 𝓑.CipherTextGen, in Table 5.

Table 5

The algorithms in Game1.

Algorithm	Usage
𝓐.Init	Initiate the parameter.
𝓐.OC	Reply the O^<<C_pub,sk_ID,PK_e()>> queries from 𝓓.
𝓐.OS	Reply the O^<<Sign_sk_ID()>> queries from 𝓓.
𝓐.OE	Reply the O^<<EnrollMK[id≠ID]()>> queries from 𝓓.
𝓐.Guess	Guess the value of d in 𝓑.CipherTextGen
𝓑.CipherTextGen	Generate the challenge ciphertext.

The descriptions of the algorithms are as follows.

Algorithm 𝓐.Init(1λ)

Begin

st ← (pub,priv)

output (st, challenge)

End

Remark 6

We suppose that 𝓐 generates the system parameters honestly, that is, 𝓐 does not set any “backdoor” in the parameters. Otherwise, the system parameters could be generated by a trusted third party.

Remark 7

After 𝓐 is initialized, pub,ID and sk ID are private “member variables” of 𝓐.

Algorithm 𝓐.OS(M)

Begin

End

Algorithm 𝓐.OS(id)

Begin

IF(ID = id) output ⊥

Else output Enroll(pub,M,id)

End

Algorithm 𝓑.CipherTextGen(challenge)

Begin

IF(d = 0)

(K 1,K 2,K 3)←sk

Else

(K 1,K 2,K 3)←sk′

output ct,PK

End

Algorithm 𝓐.Guess(ct,st)

Begin

d' ← 0

Else

output d'

End

Note that if d = 1, is the same as which is generated by Sim, otherwise, is really a valid output of Obf.

Algorithm 𝓐.OC(M)

Begin

End

We compute Pr[d′ = 0∧d = 0] and Pr[d′ = 1∧d = 1] in the security game as follows.

Finally, the advantage of 𝓐 (as an adversary in a chosen-plaintext attack against the linear encryption scheme LE) can be calculated as follows.

Recall that δ = Pr-Pr, if δ is non-negligible, so is . This contradicts the security property (i.e., semantically secure against chosen-plaintext attacks) of the linear encryption scheme based on the decisional linear assumption. This ends the proof.

Remark 8

By a natural extension on the proof of the security of the ElGamal encryption scheme, the linear encryption scheme is semantically secure against chosen-plaintext attacks, assuming the decisional linear assumption holds [46].

Remark 9

Definition 3 (ACVBP w.r.t. Dependent Oracles and Restricted Dependent Oracles) fits for many application scenarios. Examples are shown in Table 6. Moreover, the proof of Theorem 3 does not work under the ACVBP or ACVBP w.r.t. Dependent Oracles.

Table 6

Some of the scenarios that Definition 3 should be used.

Cryptosystem	Restricted oracle
Identity-based cryptosystem	Extract the private key of an identity id≠ID
Forward-secure cryptosystem	Get the private key of a time period t′<t
t, N-key-insulated cryptosystem	Get the user keys of at most t time periods
t, N-threshold cryptosystem	Get at most t-1 pieces of the shared secret

4.3.3. FT and FA w.r.t. the proposed EGS Obfuscator

We prove the relationship between Definition 3, 4, 6 and 8 which is already shown in Fig 7 as follows.

Theorem 3. If an obfuscator Obf for a EGS functionality satisfies RR&ACVBP w.r.t. dependent oracle and restricted dependent oracle , then the FT w.r.t. EGS Functionality implies the FT w.r.t. EGS Obfuscator.

Proof. Suppose that a group signature scheme is FT w.r.t. the EGS functionality but not FT w.r.t. Obf. There exists a PPT oracle machine 𝓕 (forgery) and Q Obf ∈ ℕ such that is not a negligible value where the superscript Q Obf implies that 𝓕 queries the oracle O(·) at most Q Obf times.

We denote the maximum advantage of the forgery 𝓕 which can query the oracle O(·) at most q Obf(1≤q Obf≤Q Obf) times in the experiment as . Clearly, we have Therefore, ∃q′ Obf(1≤q′ Obf≤Q Obf), s.t. We design the experiment as follows. In the experiment, the simulator Sim works the same as in the proof of Theorem 2.

Begin

C* = C (

End

Furthermore, we design a security game as follows.

We list the usage of the algorithms of 𝓓 that are used in Game2, i.e., 𝓓.Init(), 𝓓.Sig(id, M), 𝓓.Answer_O (id) and 𝓓.RR, in Table 7.

Table 7

The algorithms of 𝓓 in the Game2.

Algorithm	Usage
𝓓.Init()	Initiate the values of private keys except for id = ID.
𝓓.Answer_O EGS(id)	Reply the O^<<O_EGS(id)>> queries from the forgery 𝓕.
𝓓.Sig(id, M)	Reply the O^<<Sign_sk_ID()>> queries from the forgery 𝓕.
𝓓.RR(C)	Re-randomize the input obfuscated circuit C.

The existence of 𝓓.RR is guaranteed by the hypothesis. The other three algorithms work as follows.

Algorithm 𝓓.Init( )

Begin

While(id<2) do

IF (id ≠ ID)

id ← id + 1

EndWhile

End

Algorithm 𝓓.Sig(id, M)

Begin

IF (id = ID)

//Get the output via oracle query

Else

output Sign (M) //Compute the output directly

End

Algorithm 𝓓.Answer_OEGS(id)

Begin

IF (id = ID)

𝓓.RR(C*)

Else

End

Let be the probability of 𝓕 (and 𝓓) outputs 1 when coin = 0 and 𝓕 queries at most q′Obf times. Clearly, we have Let be the probability of 𝓕 (and 𝓓) outputs 1 when coin = 1 and 𝓕 queries at most q′Obf times. equals to .

Hence, 𝓓 is a distinguisher of a simulator and a real obfuscator because: In the above analysis, we show that, if the FT w.r.t. EGS Functionality is satisfied, but the FT w.r.t. EGS Obfuscator is NOT satisfied, then it contradicts the RR&ACVBP w.r.t. dependent oracle and restricted dependent oracle . This ends the proof.

The following propositions are easy to verify, hence we omit the proofs.

Proposition 1

The proposed obfuscator Obf is rerandomizable w.r.t. the dependent oracle and the restricted dependent oracle .

Proposition 2

The group signature scheme in [45] satisfies the following security properties with regard to the proposed EGS functionality or the proposed obfuscator Obf:

FT w.r.t. the proposed EGS functionality.

FA w.r.t. the proposed EGS functionality.

FT w.r.t. the proposed obfuscator Obf.

FA w.r.t. the proposed obfuscator Obf.

Related Studies and Comparison

The work of Barak et al. [30] initiated the theoretical investigation of obfuscators and has been a landmark in the research of obfuscation. The main result is that general-purpose obfuscation is impossible even under rather weak security definitions. This result is extended in many publications, such as the impossibility of obfuscation with auxiliary input [32], the impossibility of approximate obfuscation [31], the impossibility of efficient best-possible obfuscation [33], and the impossibility of restricted circuit classes [29]. Because of the difficulties or even impossibilities of various obfuscations, it is challenging to find a secure obfuscator even for a special functionality.

Fortunately, some positive results were obtained besides these negative results. It was shown by Canetti that under a very strong Diffie-Hellman assumption, point functions can be obfuscated [51]. Further work from Wee [52] relaxes the assumptions required for obfuscation. Lynn et al. [53] gave several provable obfuscations for complex access control functionalities in the random oracle model. Moreover, Hofheinz et al. [42] provided some specific examples also with theoretical importance. One example is that we can easily transform an asymmetric encryption scheme into an obfuscatable symmetric encryption scheme, another example is that we can easily transform digital signature scheme into an obfuscatable MAC (Message Authentication Code).

However, these positive results mainly serve as theoretical illustrations. For instance, because the speed of the encryption algorithm in an asymmetric encryption scheme is usually much slower than that of a traditional block cipher, the strongly obfuscatable symmetric encryption scheme [42] is not suitable for practice. It is similar for the obfuscatable MAC [42], because the speed of verification algorithm in a digital signature scheme is usually much slower than that of using a keyed-Hash Message Authentication Code (HMAC).

Besides these positive results for theoretical study, some obfuscatable cryptographic functionalities and corresponding obfuscators for these cryptographic functionalities with acceptable runtime costs are introduced in recent years. In Table 8, we list the functionalities and obfuscators to the extent of our knowledge, and the last line is the proposed scheme in this paper. Furthermore, we provide a comparison on the security notions of obfuscation for different signature-related schemes in Table 9.

Table 8

A comparison of highly relative studies.

Functionality	Year	Base scheme(s) or building component(s)	Complexity Assumptions
Re-encryption [35]	2007	The linear encryption scheme (in [46]).	DLIN
Encrypted signature [34]	2010	The linear encryption scheme (in [46]), and Water’s signature scheme (in [54]).	DBDH, DLIN
Encrypted verifiable Encrypted signature [36]	2011	The linear encryption scheme (in [46]), and Water’s signature scheme (in [54]).	Exponent l-weak DH, DBDH, DLIN
Two-step oblivious signature [38]	2012	The linear encryption scheme (in [46]), Water’s signature scheme (in [54]), and Pedersen’s VSS protocol (in [55]).	SDHI, DLIN
Functional re-encryption [37]	2012	Re-Encryption (in [35])	SXDH
Encrypted Blind Signature [49]	2013	Schnorr’s Blind Signature, and the linear encryption scheme (in [46]).	DH
Encrypted Proxy Signatures [50]	2013	Tightly Structure-Preserving Signatures (in [56]), and the linear encryption scheme (in [46]).	DLIN, DBDH
Conditional Re-encryption with Keyword Search [39]	2013	A modified version of ElGamal encryption.	DBDH
Encrypted Verifiably Encrypted Signatures [41]	2014	The linear encryption scheme (in [46]), and Water’s signature scheme (in [54]).	CDH, AgExt, DLIN
Re-encryption, Functional Re-encryption, and Multi-hop Re-encryption [40]	2014	Regev’s encryption scheme (in [57])	DLWE
Encrypted Group Signature (this paper)		The linear encryption scheme (in [46]), and a group signature scheme (in [45]).	CDH, SD, HSDH, DLIN

Acronyms used in the last column are explained as follows:

• Decisional Linear (DLIN);

• Decisional Bilinear Diffie-Hellman (DBDH);

• Strong Diffie Hellman Indistingshuishability (SDHI);

• Symmetric External Diffie-Hellman (SXDH);

• Diffie-Hellman (DH);

• Computational Diffie-Hellman (CDH);

• Aggregate Extraction (AgExt);

• Decisional Learning with Errors (DLWE);

• Subgroup Decision (SD);

• Hidden Strong Diffie-Hellman (HSDH).

Table 9

A comparison on the security notions of obfuscation for different signature-related schemes.

Reference No.	The main Security notion for the obfuscator	The dependent oracle(s)	The restricted dependent oracle(s)	The scheme-related security notion(s) w.r.t Obfuscator
[34]	ACVBP w.r.t. DOs	Sign	N/A	EU w.r.t. ES Functionality
[36]	ACVBP w.r.t. DOs	Sign	N/A	/
[38]	ACVBP w.r.t. DOs	Sign	N/A	/
[49]	ACVBP w.r.t. DOs	Sign	N/A	Blindness w.r.t. EBS Obfuscator; One-more Unforgeability w.r.t. EBS Obfuscator
[50]	ACVBP w.r.t. DOs	Sign	N/A	EU w.r.t. ES Functionality
[41]	ACVBP w.r.t. DOs	Sign	N/A	EU w.r.t. EVES Obfuscator; Opacity w.r.t. EVES Obfuscator
This paper	ACVBP w.r.t. DOs and RDOs	Sign	Enroll	FT w.r.t. EGS Obfuscator; FA w.r.t. EGS Obfuscator

Acronyms used in the above table are explained as follows

• Dependent Oracle (DO)

• Restricted Dependent Oracle (RDO)

• Existential Unforgeability (EU)

• Encrypted Blind Signature (EBS)

• Encrypted Verifiably Encrypted Signatures (EVES)

From Table 8, we can see that the proposed obfuscator is the first obfuscator for group oriented security schemes. Furthermore, as shown in Table 9, ACVBP w.r.t. DOs and RDOs introduced in this paper is the first security notion to fulfill the security requirement to protect a signature related scheme against collusion attacks. This new security notion should also be used to capture the security requirements of obfuscation of identity-based cryptosystems, forward-secure cryptosystem, key-insulated cryptosystem and threshold cryptosystem.

As we have mentioned at the end of section 2.1, there are two general-purpose obfuscators (in [43,44,58]) proposed in 2013 and 2014.

The first one is constructed for indistinguishability obfuscation that supports all polynomial-size circuits, which were given by Garg et al. [43] and strengthened by Barak et al. [58]. However, it uses a weak security notion of obfuscation, i.e. the indistinguishability obfuscation [29] which says that, for any pair of circuits C 0 and C 1 that agree on all inputs C 0(x) = C 1(x), it should be hard to distinguish the obfuscation of C 0 from that of C 1. The new security notion used in this paper, i.e. the ACVBP w.r.t. DOs and RDOs, is stronger than the indistinguishability obfuscation.

The second general-purpose obfuscator is capable of obfuscating all polynomial size circuits [44]. The obfuscator, which uses graded encoding schemes is proven that the obfuscator exposes no more information than the program’s black-box functionality, and achieves virtual black-box security, in the generic graded encoded scheme model. The obfuscator is obtained by developing techniques used to obfuscate d-CNF formulas in [59], and applying them to permutation branching programs. This yields an obfuscator for circuits in the complexity class NC1 and the obfuscator can be extended to a more powerful one for any polynomial-size circuit by using the homomorphic encryption technique. However, the complexity and expansion rate of homomorphic encryption are too large to be applied in practical applications.

Remark 10

NC1 denotes the class of decision problems decidable by uniform boolean circuits with a polynomial number of gates of at most two inputs and depth O(logn), or the class of decision problems solvable in time O(logn) on a parallel computer with a polynomial number of processors. Many cryptographic functionalities are out of this class.

Remark 11

The impossibility results in [29,30,32] do not extend to idealized models, such as the random oracle model, the generic group model, and particularly the generic graded encoding model which is used in [44], hence the “generic purpose obfuscator” does not contradict these impossibility results.

Hence, although there have been some important advances in general-purpose obfuscation, such as in [43,44,58], there is no practically general approach for designing obfuscators under the security notion used in this paper. Therefore, it is a challenging work to find an obfuscatable encrypted group signature (EGS) functionality and design a corresponding efficient obfuscator.

Discussions

In this section, we first introduce possible applications and extensions of the proposed technique. Then, the rationale behind the obfuscatable sign-then-encrypt functionalities are investigated. Finally, the contribution of our findings is discussed at the last subsection.

6.1. Possible Applications and Extensions

Group signature schemes are applicable in many practical applications, such as in social networks [3,4], medical information systems [5-7], VANets [8,9], electronic voting [10], WSNs [11], electronic cash [12,13], and cloud computing [14-18]. These studies make great contributions for protecting security of information systems and privacy of users against various attacks. However, these applications are rather complicated. Therefore, to illustrate the applicability of the proposed technique, two simple examples are provided in section 6.1.1 and 6.1.2.

Moreover, the proposed technique can be adapted to identity-based cryptography and key-insulated cryptography. These extensions are introduced in section 6.1.3.

6.1.1. An Application in cloud computing

Group signature technique is perfectly suited for privacy-preserving security schemes in cloud computing. The proposed application is inspired by [18]. The application scenario for encrypted group signature schemes is a single company hosting a private cloud for its employees, e.g. providing access to file sharing or printing services. Usually, there is no need to identify the employee who has uploaded a certain file, and in some cases this may even be a confidential information (e.g. for labor unions within the company). However, in the event of uploading a file illegally, the company’s management may have a severe interest in finding the responsible employee, regardless of potential reasons for preserving anonymity. The application is illustrated in Fig 8.

Fig 8

An application in cloud computing.

6.1.2. An Application in mobile healthcare social networks

The second application is a privacy-preserving emergency call scheme for mobile healthcare social networks. It is adapted from [4].

As illustrated in Fig 9, a privacy-preserving emergency call system enables patients in life-threatening emergencies to accurately and fast transmit emergency data to the nearby helpers via mobile healthcare social networks. Once an emergency happens, the personal digital assistant (PDA) of the patient runs the emergency call procedure to collect the emergency data including patient health record, patient physiological condition, as well as the current emergency location. The emergency call procedure then generates an emergency call with the emergency data inside and epidemically disseminates it to every user in the patient’s neighborhood. If a physician happens to be nearby, the PEC ensures the time used to notify the physician of the emergency to be the shortest.

Fig 9

A decentralized emergency response scheme.

In an emergency situation, a patient must reveal his/her information to the nearby users in order to ask for their instant help. However, with privacy concerns, the patients would preserve the identity privacy and prevent their transactions being linked to their unique identities. On the other hand, a TA must be able to trace the emergency call and identify the corresponding patient. In this way, any malicious attacker who has generated a bogus emergency call would be detected and punished. Details of the application are listed as follows and illustrated in Fig 10.

Fig 10

An application in a privacy-preserving emergency call system based on mobile social network.

(1) Initialization Phase:

At the beginning, the Trusted Authority (TA) uses the algorithm Setup to generate system parameters, public values, the master enrollment key MK, and the group manager’s tracing key TK.

(2) Registration Phase:

When a patient who needs medical services for possible emergency situations joins the system, TA uses the algorithm Enroll to issue a secret signing key sk and delivers the key to the patient through a secure channel.

(3) Obfuscation phase:

The patient uses the obfuscator Obf to generate an obfuscated implementation of encrypted group signature functionality in his/her personal computer. Then the patient transfers the obfuscated implementation to his/her PDA.

(4) Emergency call generation phase:

The emergency call generation is started by a detection of the abnormal physiological condition from body sensors. This condition can be pre-implanted into the patient’s PDA with the instructions of the medical professionals.

Let patient n denote a user who has an emergency situation. The patient n ’s PDA generates an emergency call according to the following steps.

(4.1) General information collection phase: The PDA intelligently collects the following general information:

Location (LOC): It contains the emergency location information which can be measured by a global positioning system (GPS) of the patient PDA.

Incident (INC): It contains a general description of the environment where the emergency occurs.

Time (TIME): It contains the exact time when the emergency occurs.

(4.2) Encrypted Signature generation phase: The PDA uses the obfuscated implementation EGS to generate an encrypted group signature on “LOC||INC||TIME”. The encrypted group signature will be put into the “EGS” component.

(4.3) Data encryption phase: The PDA encrypts the patient n ’s physiological condition (PC) and health record (HR).

(4.4) Information dissemination phase: The PDA disseminates the Emergency Call Message to the neighboring users and APs (Access Points). Note that denotes the ciphertexts of GS and PC||HR where .

(5) Emergency call response phase:

User n receives the ECM from patient n and executes the following steps, where a PDA represents user n ‘s PDA:

(5.1) Cryptographic preprocess: First, the PDA decrypts the encrypted part of the message () and gets the plaintext GS,PC||HR. Second, the PDA verifies the group signature “GS” by using the verification algorithm Verify. If the verification passes, user n confirms the information “LOC||INC||TIME.”

(5.2) Local response: As an emergency response, user n firstly makes a phone call (e.g., dialing 911) to report the emergency to the hospital/first-aid center. Then, the PDA executes the step (5.3).

(5.3) Information re-dissemination phase: The PDA checks the “TIME” component: If the time period from the emergency occurrence to the user n receiving it, is larger than the threshold value, then the emergency call is discarded. Otherwise, the PDA forwards the ECM to the neighboring users.

6.1.3. Extensions to identity-based signatures and key-insulated signatures

In a traditional (certification-based) public-key cryptosystem, the association between a user’s identity and his/her public key is obtained through a digital certificate issued by a Certifying Authority (CA). The CA checks the credentials of a user before issuing a certificate to the user. If a signer wants to sign a message, first the signer obtains a digital certificate for his/her public key from a CA. The signer then signs the message using the private signing key and sends the signed message along with his/her certificate to the receiver. The receiver (verifier) first verifies the validity of the certificate by checking the certificate revocation list published by the CA, then the receiver verifies the signature using the public key in the certificate. If many CAs are involved between the signer and the verifier, then the entire certificate path has to be verified.

Hence, the process of certificate management requires high computational and storage efforts. To simplify the certificate management process, Shamir [60] introduced the concept of identity-based cryptosystem. In such cryptosystems the public key of a user is derived from his/her identity information and a private key is generated by a Trusted Authority (TA). The advantage of an identity-based cryptosystem is that it simplifies the key management process which is a heavy burden in the traditional certificate based cryptosystems. In these cryptosystems, the verifier can verify the signer’s signature just by using his/her identity information. In general, an identity based cryptosystem has the following properties:

user’s public key is his/her identity (or derived from the identity).

no requirement of public key directories

the verification process of a signature requires only the signers’ identity (along with some public system parameters)

These properties make identity-based cryptosystems advantageous over the traditional certification-based cryptosystems, as key distribution is far simplified. It needs a directory only for authenticated public system parameters of the KGC (Key Generation Center), which is clearly less burdensome than maintaining a public key directory for total users.

As a by-product of the paper, we found that one could easily transform the proposed functionality to an obfuscatable encrypted identity-based signature by applying the following steps.

The KGC sets up the group for all users.

The KGC broadcasts the tracing key as a public value.

When generating a signature, the signer appends his/her identity at the end of the signature.

Merge the verification algorithm and the opening algorithm together.

The obfuscators, and even the encryption key generation algorithm, the encryption algorithm and the decryption algorithm can be used in the identity-based scenario without modification.

Note that the main security definition (ACVBP w.r.t. DOs and RDOs) can be almost directly obtained from Section 4. Moreover, the security proof can be deducted from this paper easily. So we omit the details in this paper.

Furthermore, as suggested in [61], by identifying time periods with identities, any identity-based signature scheme yields a perfectly (but not necessarily strong) key-insulated signature scheme. Accordingly, by applying this technique to the above identity-based scheme, an obfuscatable key-insulated signature scheme and a corresponding obfuscator is acquired.

Hence, besides the encrypted group signature, this paper adds two more new items in the list of obfuscatable cryptographic functionalities, i.e., the encrypted identity-based signature and the encrypted key-insulated signature.

6.2. The Rationale Behind the Obfuscatable Sign-Then-Encrypt Functionalities

Intuitively, design a sign-then-encrypt functionality needs a signing algorithm and an asymmetric encryption algorithm which are “commutable”. Hence, the obfuscator can encrypt the private signing key by using the encryption algorithm with the public encryption key. In fact, all the works which are listed in Table 9 follow the thread of the idea in [34]. We explain the idea formally as follows.

In a digital signature scheme, the signing algorithm 𝓢 takes the secret signing key sk ∈ 𝕊 and a message M ∈ 𝕊 to return a signature (also sometimes called a tag) σ ∈ {0,1}*∪⊥. The algorithm may be randomized. We write 𝓢(sk, M) for the operation of running Sign on inputs sk, M and letting σ be the signature returned.

In an asymmetric encryption scheme, the encryption algorithm 𝓔 takes the public encryption key PK ∈ 𝕊 and a plaintext M ∈ 𝕊 to return a value called the ciphertext. The algorithm may be randomized. We write C←𝓔(PK, M) for the operation of running 𝓔 on inputs PK, M and letting C ∈ 𝕊 be the ciphertext returned.

Suppose the encryption is semantic secure (IND-CPA). If (34) holds, it is expected that we can obtain a secure obfuscator of 𝓔∘𝓢.

Eq (34) implies that Usually, the signing algorithm and the encryption algorithm are randomized. Therefore, (34) could be relaxed. Consider the implicit usage of random variables in the encryption algorithm and signing algorithm, we denote the set of random variables in the encryption process as R and the set of random variables in the signing process as R . Let and be the corresponding encryption process and signing process, respectively. In order to satisfy the requirement of preserving functionality, (35) is sufficient.

As to the security requirement, the formal security analysis hinges on the security model of the signature scheme. Because there are many variations of digital signature schemes (e.g., group-oriented, identity-based, etc.), it is out of the scope of this paper.

6.3. The Contribution

The paper has introduced a new secure obfuscator for encrypted group signature and corresponding security notions.

Theoretically, six new security notions of the encrypted group signature functionality and its obfuscators are proposed. The notions are ACVBP w.r.t. w.r.t. Dependent Oracles (DOs) and Restricted Dependent Oracles (RDOs), rerandomizable w.r.t. dependent oracle set and restricted dependent oracle set, full-traceability w.r.t. EGS Functionality, full-anonymity w.r.t. EGS Functionality, full-traceability w.r.t. EGS Obfuscator, and full-anonymity w.r.t. EGS Obfuscator.

The most important one of the new security notions is ACVBP w.r.t. DOs and RDOs which describes the security requirement of protecting the output of the proposed obfuscator, i.e., the obfuscated implementation of encrypted group signature functionality against collision attacks from group members. The security notions fit for many other cryptographic schemes which collision attacks from users need to be considered, such as identity-based signature schemes, ring signature schemes, attribute-based signature schemes and key-insulated signature schemes.

Practically, as it was discussed in Section 5, a generic obfuscator (for various sign then encrypt functionalities) is hard to find. Therefore, the obfuscators for various sign then encrypt functionalities must be studied one by one. In [34], Hada proposed the first obfuscatable sign-then-encrypt functionality and a corresponding obfuscator. Since then, most of the research work has been done on proposing various sign-then-encrypt functionalities and obfuscators, such as obfuscators for oblivious signature, encrypted blind signature, encrypted proxy signature, and encrypted verifiably encrypted signature. Note that it is not a trivial work to find an obfuscatable cryptographic functionality. For example, many widely-used signature schemes have not been found any obfuscatable concrete scheme (even in the sign then encrypt form), such as identity-based signature schemes, attribute-based signature schemes and key-evolvement signature schemes (include forward-secure signature, key-insulated signature, and intrusion-resilient signature).

A special obfuscatable group signature functionality, i.e., the encrypted group signature, is proposed with a concrete scheme, and then a corresponding obfuscator is provided in this paper. The correctness and security of the proposed obfuscator are proven. Then the efficiency of the proposed encrypted group signature functionality and its obfuscator is analyzed. The results of this paper can be used as building blocks of privacy preserving security protocol of various emerging applications such as social networks, medical information systems, Vehicular Ad hoc Networks (VANets), electronic voting, Wireless Sensor Networks (WSNs), electronic cash, and especially cloud computing.

Finally, as by-products of this paper, besides the encrypted group signature, we add two more new items in the list of obfuscatable cryptographic functionalities, i.e., the encrypted identity-based signature and the encrypted key-insulated signature.

Conclusions and Future Work

Group signature technique is used in many privacy-preserving security schemes for social networks, cloud computing, VANets, WSNs, electronic voting and electronic cash. To provide a building block for these schemes in white-box attack contexts, we give an obfuscatable EGS functionality, and then provide an obfuscator for the proposed EGS functionality. We also introduce a new security notion (ACVBP w.r.t. Dependent Oracles and Restricted Dependent Oracles) to capture the requirement of protecting the output of an obfuscator for EGS functionality against collision attacks from group members. Moreover, five other new security notions are also provided. We prove that the proposed obfuscator preserves EGS functionality and satisfies the proposed security notions. As a byproduct of this study, ACVBP w.r.t. Dependent Oracles and Restricted Dependent Oracles fits for many types of cryptosystems, such as identity-based cryptosystems, forward-secure cryptosystems, key-insulated cryptosystems and threshold cryptosystems. Finally, we have introduced two possible applications and two extensions of the proposed technique.

In the future, we plan to adopt the obfuscatable EGS functionality in practical security solutions for validation. By using the proposed obfuscatable EGS functionality as a building block, we also consider exploring novel approaches for designing privacy-preserving security schemes. Furthermore, we will try to explore the design strategy for generalized constructions of obfuscatable sign-then-encrypt functionalities.