Short attribute-based signatures for arbitrary Turing machines from standard assumptions

This paper presents the first attribute-based signature (ABS) scheme supporting signing policies representable by Turing machines (TM), based on well-studied computational assumptions. Our work supports arbitraryTMs as signing policies in the sense that the TMs can accept signing attribute strings of unbounded polynomial length and there is no limit on their running time, description size, or space complexity. Moreover, we are able to achieve input-specific running time for the signing algorithm. All other known expressive ABS schemes could at most support signing policies realizable by either arbitrary polynomial-size circuits or TMs having a pre-determined upper bound on the running time. Consequently, those schemes can only deal with signing attribute strings whose lengths are a priori bounded, as well as suffers from the worst-case running time problem. On a more positive note, for the first time in the literature, the signature size of our ABS scheme only depends on the size of the signed message and is completely independent of the size of the signing policy under which the signature is generated. This is a significant achievement from the point of view of communication efficiency. Our ABS construction makes use of indistinguishability obfuscation (IO) for polynomial-size circuits and certain IO-compatible cryptographic tools. Note that, all of these building blocks including IO for polynomial-size circuits are currently known to be realizable under well-studied computational assumptions.


Introduction
In a traditional digital signature scheme, each signer possesses a secret signing key and publishes its corresponding verification key. A signature on some message issued by a certain signer is verified with respect to the public verification key of the respective signer, and hence during the verification process, the explicit signer gets identified. In other words, standard digital signatures can guarantee no privacy in the relationship between signers and claims attested by signatures due to the tight correspondence between the signing and verification keys.
Attribute-based signatures (ABS), introduced by Maji et al. [19], aims to relax such a firm relationship between signers and signatures issued by them, thereby ensuring some form of signer privacy. ABS comes in two flavors, namely, key-policy and signature-policy. In a key-policy ABS scheme, a setup authority holds a master signing key and publishes system public parameters. Using its master signing key, the authority can give out restricted signing keys corresponding to specific signing policies. Such a constrained signing key enables a signer to sign messages with respect to only those signing attributes which are accepted by the signing policy embedded within the signing key. The signatures are verifiable by anyone using solely the public parameters. By verifying a signature on some message with respect to some signing attributes, a verifier gets convinced that the signature is indeed generated by a signer possessing a signing key corresponding to some signing policy that accepts the signing attributes. However, the verifier cannot trace the exact signer or signing policy used to generate the signature. The signature-policy variant interchanges the roles of signing attributes and signing policies. Other than being an exciting primitive in its own right, ABS has countless practical applications such as attribute-based messaging, attribute-based authentication, anonymous credential systems, trust negotiation, and leaking secrets.
A central theme of research in the field of ABS has been to expand the class of admissible signing policies in view of implementing ABS in scenarios where the correspondence between signers and signatures is more and more sophisticated. Starting with the initial work of Maji et al. [19], which supports signing policies representable by monotone span programs, the family of supported signing policies has been progressively enlarged by Okamoto and Takashima [20] to admit non-monotone span programs, by Datta et al. [6] to support arithmetic branching programs, and further by Tang et al. [25], Sakai et al. [23], Tsabary [26], as well as El Kaafarani and Katsumata [16] to realize arbitrary polynomial-size circuits. On the other hand, Bellare and Fuchsbauer [4] have put forth a versatile cryptographic primitive termed as policy-based signatures (PBS) and have exhibited a generic transformation from PBS to ABS. Their generic conversion can be used in conjunction with their proposed PBS construction to build an ABS scheme for general polynomial-size circuits as well.
While the circuit model is already powerful enough to capture arbitrary computations, an important bottleneck of this model is that it is non-uniform in nature and thus ABS schemes supporting circuit-realizable signing policies can withstand only signing attribute strings of bounded length, where the bound is determined during setup. Another drawback of representing signing policies as circuits is that generating a signature with respect to some signing attribute string using a signing key corresponding to certain signing policy is at least as slow as the worst-case running time of that policy circuit on all possible signing attribute strings. These are serious limitations not only for ABS itself, but also for all the aforementioned applications of ABS In this paper, we aim to express signing policies in a uniform computational model, namely, the Turing machine (TM) model, which is the most natural direction to overcome the above problems. First, we would like to mention that concurrently and independently to our work, Sakai et al. [24] have developed an ABS scheme which can withstand TM-realizable signing policies under the symmetric external Diffie-Hellman (SXDH) assumption. Unfortunately however, in their ABS scheme, the size of a signature scales with the running time of the signing policy TM used to generate it on the signing attribute string with respect to which it is created. As a result, for ensuring signer privacy, their scheme should impose a universal upper bound on the running times of the signing policy TMs, and should enforce the size of the signatures to scale with that system-wide upper bound. Evidently, such a universal runningtime bound in turn induces a bound on the lengths of the allowable signing attribute strings. Moreover, it implies that the signing algorithm should also have running time proportional to that universal time bound, i.e., incurs the worst-case running time in order to generate the signatures. Consequently, it is clear that their scheme actually fails to achieve both the advanced properties which are the sole utility of considering the richer TM model over the circuit model, namely, unbounded-length signing attribute strings and input-specific running time of the signing algorithm. Further, the failure to achieve these rich properties is in fact the result of their approach that involves giving out non-interactive zero-knowledge (NIZK) proofs for each of the evaluation steps of the signing policy TM on the signing attribute string considered in a manner analogous to how an NIZK proof is issued for each gate of the signing policy circuit in [23]. In contrast, our goal in this paper is to devise techniques to accomplish both the rich properties expected from the TM model and thereby truly expand the state of the art in the field of ABS beyond the essential barriers of the circuit model. Additionally, we aim at making the signature size as small as that of an ordinary digital signature scheme, that is, dependent only on the size of the signed message-a feature that has remained elusive despite the tremendous progress in the field of ABS so far.

Our contribution
In this paper, we present the first ever key-policy ABS scheme supporting signing policies representable as Turing machines (TM) which can handle signing attribute strings of unbounded polynomial length, as well as have arbitrary (polynomial) running time, description size, and space complexity. Thus, our work captures the most general form of signing policies possible. Moreover, in our ABS scheme, generating a signing key corresponding to a signing policy takes time polynomial in the description size of that signing policy, which may be much shorter compared to the worst-case running time of that signing policy. Also, the signature generation time only depends on the time the used signing policy takes to run on the signing attribute string with respect to which the signature is being generated, rather than its worst-case running time. These features were beyond the reach of any other known ABS construction. On a more positive note, for the first time in the literature, the signature size of our ABS scheme only depends on the size of the signed message and is completely independent of the associated signing policy. This is a significant achievement from the point of view of communication efficiency. Further, using the technique of universal TM, our key-policy ABS construction can be readily converted into a signature-policy variant while preserving the same level of expressiveness as the key-policy version. Table 1presents a comparison of our work and prior works in the area.
Our ABS construction is shown to possess perfect signer privacy and existential unforgeability against selective attribute adaptive chosen message attacks under well-studied computational assumptions. The construction makes use of indistinguishability obfuscation dep(x): depth of x (IO) for polynomial-size circuits. Other than IO, we make use of standard digital signatures (SIG), injective pseudorandom generators (PRG), and certain additional IO-compatible cryptographic tools, namely, puncturable pseudorandom functions, somewhere statistically binding (SSB) hash functions, positional accumulators, cryptographic iterators, and splittable signatures. Among the cryptographic building blocks used in our ABS construction in addition to IO, iterators and splittable signatures are realizable using IO itself in conjunction with one-way functions, whereas all the others have efficient instantiations based on standard number theoretic assumptions or one-way functions. Very recently, a series of works [2,9,[12][13][14][15] have finally provided an IO candidate based on the sub-exponential security of three well-studied computational assumptions, namely, learning parity with noise (LPN), existence of boolean pseudorandom generators (PRG) in NC 0 , and Decisional Linear (DLIN).
We note that while the proposed ABS scheme demonstrates asymptotically better performance compared to existing schemes as described above, the concrete computational overhead might not outweigh that of existing schemes at this point primarily due to fact that the current realization of IO is highly inefficient. However, IO research has so far advanced a long way over the last two decade since its inception by Barak et al. [3], and we believe efficient IO candidates would be discovered in the future improving the concrete overhead of the proposed ABS scheme. On the other hand, the existing ABS schemes, especially those supporting comparably expressive signing policies [16,[23][24][25][26] would still continue to suffer from the asymptotic worst-case efficiency bottleneck. Another limitation of the proposed ABS scheme is that it only achieves selective unforgeability as mentioned above. We leave it as an interesting open problem to construct an ABS scheme for the same class of access policies and with the same asymptotic efficiency as ours while achieving adaptive security at the same time.
To achieve our result, we extend the techniques employed by Koppula et al. [17] for designing message-hiding encoding schemes for TMs, or by Deshpande et al. [7] for designing constrained pseudorandom functions (CPRF) for TMs secure in the selective challenge selective constraints model to withstand adaptive signing key queries of the adversary. We give an overview of our techniques in the next section. For any set S, υ $ ← − S represents the uniform random variable on S. For a randomized algorithm R, we denote by ψ = R(υ; ρ) the random variable defined by the output of R on input υ and randomness ρ, while ψ $ ← − R(υ) has the same meaning with the randomness suppressed. Also, if R is a deterministic algorithm ψ = R(υ) denotes the output of R on input υ. We will use the alternative notation R(υ) → ψ as well to represent the output of the algorithm R, whether randomized or deterministic, on input υ. For any string s ∈ {0, 1} * , |s| represents the length of the string s. For any two strings s, s ∈ {0, 1} * , s s represents the concatenation of s and s . A function negl is negligible if for every integer c, there exists an integer k such that for all λ > k, |negl(λ)| < 1/λ c .

Turing machines
A Turing machine (TM) M is a 7-tuple M = Q, inp , tape , δ, q 0 , q ac , q rej with the following semantics: -Q: The finite set of possible states of M.
inp : The finite set of input symbols.
tape : The finite set of tape symbols such that inp ⊂ tape and there exists a special blank symbol '_' ∈ tape \ inp .   Correctness: IO(1 λ , C) preserves the functionality of the input circuit C, i.e., for any C ∈ C λ , if we compute C = IO(1 λ , C), then C (υ) = C(υ) for all inputs υ. Indistinguishability: For any security parameter λ and any two circuits C 0 , C 1 ∈ C λ with same functionality, the circuits IO(1 λ , C 0 ) and IO(1 λ , C 1 ) are computationally indistinguishable. More precisely, for all (not necessarily uniform) PPT adversaries D = (D 1 , D 2 ), there exists a negligible function negl such that, if

Indistinguishability obfuscation
Efficiency: For any security parameter λ and any circuit C ∈ C λ , the size of the obfuscated circuit IO(1 λ , C) is polynomial in λ and the size of C.
We remark that the two distinct algorithms D 1 and D 2 , which pass state ξ , can be viewed equivalently as a single stateful algorithm D. In this paper we employ the latter approach, although here we present the definition as it appears in [3]. When clear from the context, we will drop 1 λ as an input to IO. The circuit class we are interested in are polynomial-size circuits, i.e., when C λ is the collection of all circuits of size at most λ. This circuit class is denoted by P/poly. The first candidate construction of IO for P/poly was presented by Garg et al. [8] in 2013. Their construction uses nonstandard instance dependent assumption on graded multilinear encodings. Since then, there has been a rapid progress towards designing IO from better understood cryptographic tools and complexity assumptions. Very recently, a series of exciting works [1,2,9,12,13,15,18] have finally provided an IO candidate based on the sub-exponential security of four well-studied computational assumptions, namely, learning with errors (LWE), learning parity with noise (LPN), existence of boolean pseudorandom generators (PRG) in NC 0 , and symmetric external Diffie-Hellman (SXDH).

IO-compatible cryptographic primitives
In this section, we present the syntax and efficiency considerations of certain IO-friendly cryptographic tools which we use in our ABS construction. The security properties these primitives are described in Online Appendix A.

Puncturable pseudorandom function
Pseudorandom functions (PRF) [10] are a fundamental tool of modern cryptography. A PRF is a deterministic keyed function with the following property: Given a key, the function can be computed in polynomial time at all points of its input domain. But, without the key it is computationally hard to distinguish the PRF output at any arbitrary input from a uniformly random value, even after seeing the PRF evaluations on a polynomial number of inputs. A puncturable pseudorandom function (PPRF), first introduced by Sahai and Waters [22], is an augmentation of a PRF with an additional puncturing algorithm which enables a party holding a PRF key to derive punctured keys that allow the evaluation of the PRF over all points of the input domain except one. However, given a punctured key, the PRF evaluation still remains indistinguishable from random on the input at which the key is punctured. Puncturable pseudorandom function PPRF [22]: A puncturable pseudorandom function (PPRF) F : K pprf × X pprf → Y pprf consists of an additional punctured key space K pprf-punc other than the usual key space K pprf and PPT algorithms where pprf-inp and pprf-out are polynomials in the security parameter λ, The setup authority takes as input the security parameter 1 λ and uniformly samples a PPRF key K ∈ K pprf . F .Eval(K , x) → r : The setup authority takes as input a PPRF key K ∈ K pprf along with an input x ∈ X pprf . It outputs the PPRF value r ∈ Y pprf on x. For simplicity, we will represent by F (K , x) the output of this algorithm. F .Puncture(K , x) → K {x} : Taking as input a PPRF key K ∈ K pprf along with an element x ∈ X pprf , the setup authority outputs a punctured key K {x} ∈ K pprf-punc . F .Eval-Puncured(K {x}, x ) → r or ⊥ : An evaluator takes as input a punctured key K {x} ∈ K pprf-punc along with an input x ∈ X pprf . It outputs either a value r ∈ Y pprf or a distinguished symbol ⊥ indicating failure. For simplicity, we will represent by F (K {x}, x ) the output of this algorithm.
The algorithms F .Setup and F .Puncture are randomized, whereas, the algorithms F .Eval and F .Eval-Punctured are deterministic.
Correctness under puncturing: Consider any security parameter λ, Then it must hold that Efficiency: The F .Setup algorithm runs in time polynomial in the security parameter λ, while the algorithms F .Eval and F .Punctured run in time polynomial in λ and the input size pprf-inp . Moreover, the size of the full PPRF keys is polynomial in λ, whereas that of the punctured keys is polynomial in λ and pprf-inp . Hence, the algorithm F .Eval-Punctured also runs in time polynomial in λ and pprf-inp . Boneh and Waters [5], have shown that the tree-based PRF constructed by Goldreich et al. [10] can be readily modified to build a PPRF from one-way functions.

Somewhere statistically binding hash function
We provide the definition of somewhere statistically binding hash function as defined by Hubacek et al. [11]. A somewhere statistically binding hash can be used to create a short digest of some long string. A hashing key is created by specifying a special binding index and the generated hashing key gets the property that the hash value of some string created with the hashing key is statistically binding for the specified index, meaning that the hash value completely determines the symbol of the hashed input at that index. In other words, even if some hash value has several pre-images, all of those pre-images agree in the symbol at the specified index. The index on which the hash is statistically binding should remain computationally hidden given the hashing key. Moreover, it is possible to prove that the input string underlying a given hash value contains a specific symbol at a particular index, by providing a short opening value. Somewhere statistically binding hash function SSB Hash [11]: A somewhere statistically binding (SSB) hash consists of PPT algorithms (SSB.Gen, H, SSB.Open,SSB.Verify) along with a block alphabet ssb-blk = {0, 1} ssb-blk , output size ssb-hash , and opening space ssb-open are some polynomials in the security parameter λ. The algorithms have the following syntax: The setup authority takes as input the security parameter 1 λ , an integer n ssb-blk ≤ 2 λ representing the maximum number of blocks that can be hashed, and an index i * ∈ [0, n ssb-blk − 1] and publishes a public hashing key hk.
The algorithms SSB.Gen and SSB.Open are randomized, while the algorithm SSB.Verify is deterministic.
Correctness: For any security parameter λ, integer n ssb-blk ≤ 2 λ , i, i * ∈ [0, n ssb-blk Efficiency: The SSB.Gen algorithm runs in time polynomial in the security parameter λ and log n ssb-blk . Moreover, the hash and opening values have size polynomial in λ and log n ssb-blk . Hence, the SSB.Verify algorithm also runs in time polynomial in λ and log n ssb-blk . On the other hand, the algorithms H hk and SSB.Open run in time polynomial in λ and n ssb-blk in the worst case. The first construction of an SSB hash is presented by Hubacek et al. [11]. Their construction is based on fully homomorphic encryption (FHE). Recently, Okamoto et al. [21] provides alternative constructions of SSB hash based on various standard number theoretic assumptions such as the Decisional Diffie-Hellman assumption. In this paper, we consider ssb-blk = 1 and n ssb-blk = 2 λ .

Positional accumulator
We will now present the notion of a positional accumulator as defined by Koppula et al. [17]. Intuitively, a positional accumulator is a cryptographic data structure that maintains two values, namely, a storage value and an accumulator value. The storage value is allowed to grow comparatively large, while the accumulator value is constrained to be short. Message symbols can be written to various positions in the underlying storage, and new accumulated values can be computed as a string, knowing only the previous accumulator value and the newly written symbol together with its position in the data structure. Since the accumulator values are small, one cannot hope to recover everything written in the storage from the accumulator value alone. However, there are additional helper algorithms which essentially allow a party who is maintaining the full storage to help a more restricted party maintaining only the accumulator value recover the data currently written at an arbitrary location. The helper is not necessarily trusted, so the party maintaining the accumulator value performs a verification procedure in order to be convinced that it is indeed reading the correct symbols. Positional accumulator [17]: A positional accumulator consists of PPT algorithms (ACC.Setup, ACC.Setup-Enforce-Read, ACC.Setup-Enforce-Write, ACC.Prep-Read, ACC. Prep-Write, ACC.Verify-Read, ACC.Write-Store, ACC.Update) along with a block alphabet acc-blk = {0, 1} acc-blk , accumulator size acc-accumulate , proof space acc = {0, 1} acc-proof where acc-blk , acc-accumulate , acc-proof are some polynomials in the security parameter λ. The algorithms have the following syntax: The setup authority takes as input the security parameter 1 λ and an integer n acc-blk ≤ 2 λ representing the maximum number of blocks that can be accumulated. It outputs the public parameters pp acc , an initial accumulator value w 0 , and an initial storage value store 0 . ACC.Setup-Enforce-Read(1 λ , n acc-blk , ((x 1 , i 1 ), . . . , (x κ , i κ )), i * ) → (pp acc , w 0 , store 0 ) : Taking as input the security parameter 1 λ , an integer n acc-blk ≤ 2 λ representing the maximum number of blocks that can be accumulated, a sequence of symbol-index pairs ((x 1 , i 1 ), . . . , (x κ , i κ )) ∈ ( acc-blk × [0, n acc-blk − 1]) κ , and an additional index i * ∈ [0, n acc-blk − 1], the setup authority publishes the public parameters pp acc , an initial accumulator value w 0 , together with an initial storage value store 0 . ACC.Setup-Enforce-Write(1 λ , n acc-blk , ((x 1 , i 1 ), . . . , x κ , i κ ))) → (pp acc , w 0 , store 0 ) : On input the security parameter 1 λ , an integer n acc-blk ≤ 2 λ denoting the maximum number of blocks that can be accumulated, and a sequence of symbol-index pairs ((x 1 , i 1 ), . . . , (x κ , i κ )) ∈ ( acc-blk × [0, n acc-blk − 1]) κ , the setup authority publishes the public parameters pp acc , an initial accumulator value w 0 , as well as, an initial storage value store 0 . ACC.Prep-Read(pp acc , store in , i in ) → (x out , π acc ) : A storage-maintaining party takes as input the public parameter pp acc , a storage value store in , and an index i in ∈ [0, n acc-blk − 1]. It outputs a symbol x out ∈ acc-blk ∪ { } ( being the empty string) and a proof π acc ∈ acc . ACC.Prep-Write(pp acc , store in , i in ) → aux : Taking as input the public parameter pp acc , a storage value store in , together with an index i in ∈ [0, n acc-blk − 1], a storagemaintaining party outputs an auxiliary value aux. ACC.Verify-Read(pp acc , w in , x in , i in , π acc ) →β ∈ {0, 1} : A verifier takes as input the public parameter pp acc , an accumulator value w in ∈ {0, 1} acc-accumulate , a symbol x in ∈ acc-blk ∪ { }, an index i in ∈ [0, n acc-blk − 1], and a proof π acc ∈ acc . It outputs a bitβ ∈ {0, 1}. ACC.Write-Store(pp acc , store in , i in , x in ) → store out : On input the public parameters pp acc , a storage value store in , an index i in ∈ [0, n acc-blk − 1], and a symbol x in ∈ acc-blk , a storage-maintaining party computes a new storage value store out . ACC.Update(pp acc , w in , x in , i in , aux) → w out or ⊥ : An accumulator-updating party takes as input the public parameters pp acc , an accumulator value w in ∈ {0, 1} acc-accumulate , a symbol x in ∈ acc-blk , an index i in ∈ [0, n acc-blk − 1], and an auxiliary value aux. It outputs the updated accumulator value w out ∈ {0, 1} acc-accumulate or the designated reject string ⊥.
Following [7,17], in this paper we will consider the algorithms ACC.Setup, ACC.Setup-Enforce-Read, and ACC.Setup-Enforce-Write as randomized while all other algorithms as deterministic.
Correctness: Consider any symbol-index pair sequence (( Setup(1 λ , n acc-blk ). For j = 1, . . . , κ, iteratively define the following: The following correctness properties are required to be satisfied: (ii) For any security parameter λ, n acc-blk ≤ 2 λ , sequence of symbol-index pairs if store κ and w κ are computed as above and (x out , π acc ) = ACC.Prep-Read(pp acc , store κ , i * ), then ACC.Verify-Read(pp acc , w κ , x out , i * , π acc ) = 1 Efficiency: The ACC.Setup algorithm runs in time polynomial in the security parameter λ and log n acc-blk . Moreover, the accumulator values and proofs have size polynomial in λ and log n acc-blk . Thus, the algorithms ACC.Verify-Read and ACC.Update also run in time polynomial in λ and log n acc-blk . The storage has size polynomial in the number of values stored so far. Hence, the algorithms ACC.Write-Store, ACC.Prep-Read, and ACC.Prep-Write run in time polynomial in λ and n acc-blk in the worst case. The first construction of a positional accumulator is presented by Koppula et al. [17] based on IO and one-way function. Recently, Okamoto et al. [21] provided an alternative construction of positional accumulator from standard number theoretic assumptions. Such as the Decisional Diffie-Hellman assumption.

Iterator
Here, we define cryptographic iterators again following [17]. Informally speaking, a cryptographic iterator consists of a small state that is updated in an iterative fashion as messages are received. An update to incorporate a new message given the current state is performed with the help of some public parameters. Since, states are relatively small regardless of the number of messages that have been iteratively incorporated, there is in general many sequences of messages that lead to the same state. However, the security property requires that the normal public parameters should be computationally indistinguishable from specially constructed enforcing parameters which ensure that a particular state can only be obtained as the outcome of an update to precisely one other state-message pair. Note that this enforcement is a very localized property to a specific state and hence can be achieved information-theoretically when it is fixed ahead of time where exactly this enforcement is desired. Iterator [17]: A cryptographic iterator consists of PPT algorithms (ITR.Setup, ITR.Setup-Enforce, ITR.Iterate) along with a message space M itr = {0, 1} itr-msg and iterator state size itr-st , where itr-msg , itr-st are some polynomials in the security parameter λ. Algorithms have the following syntax: The setup authority takes as input the security parameter 1 λ along with an integer bound n itr ≤ 2 λ on the number of iterations. It outputs the public parameters pp itr and an initial state v 0 ∈ {0, 1} itr-st . ITR.Setup-Enforce(1 λ , n itr , (μ 1 , . . . , μ κ )) → (pp itr , v 0 ) : Taking as input the security parameter 1 λ , an integer bound n itr ≤ 2 λ , together with a sequence of κ messages (μ 1 , . . . , μ κ ) ∈ M κ itr , where κ ≤ n itr , the setup authority publishes the public parameters pp itr and an initial state v 0 ∈ {0, 1} itr-st . ITR.Iterate(pp itr , v in ∈ {0, 1} itr-st , μ) → v out : On input the public parameters pp itr , a state v in , and a message μ ∈ M itr , an iterator outputs an updated state v out ∈ {0, 1} itr-st . For any integer κ ≤ n itr , we will write ITR.
The algorithm ITR.Iterate is deterministic, while the other two are randomized.
Efficiency: The algorithms ITR.Setup and ITR.Iterate run in time polynomial in the security parameter λ and log n itr . Also, the state has size polynomial in λ and log n itr . Koppula et al. [17] have presented a construction of cryptographic iterators from IO and one-way function.

Splittable signature
The following background on splittable signatures is taken verbatim from Koppula et al. [17] as well. A splittable signature scheme is essentially a normal signature scheme augmented by some additional algorithms that produce alternative signing and verification keys with different capabilities. More precisely, there are "all-but-one" signing and verification keys which work correctly for all messages except for a specific one, as well as there are "one" signing and verification keys which work only for a particular message. Additionally, there are "reject" verification keys which always reject signatures. Splittable signature SPS [17]: A splittable signature scheme (SPS) for message space M sps = {0, 1} sps-msg and signature space S sps = {0, 1} sps-sig , where sps-msg , sps-sig are some polynomials in the security parameter λ, consists of PPT algorithms (SPS.Setup, SPS.Sign, SPS.Verify, SPS.Split, SPS.Sign-ABO) which are described below: SPS.Setup(1 λ ) → (sk sps , vk sps , vk sps-rej ) : The setup authority takes as input the security parameter 1 λ and generates a signing key sk sps , a verification key vk sps , together with a reject verification key vk sps-rej . SPS.Sign(sk sps , m) → σ sps : A signer given a signing key sk sps along with a message m ∈ M sps , produces a signature σ sps ∈ S sps . SPS.Verify(vk sps , m, σ sps ) →β ∈ {0, 1} : A verifier takes as input a verification key vk sps , a message m ∈ M sps , and a signature σ sps ∈ S sps . It outputs a bitβ ∈ {0, 1}. SPS.Split(sk sps , m * ) → (σ sps-one,m * , vk sps-one , sk sps-abo , vk sps-abo ) : On input a signing key sk sps along with a message m * ∈ M sps , the setup authority generates a signature σ sps-one,m * = SPS.Sign(sk sps , m * ), a one-message verification key vk sps-one , and all-but-one signing-verification key pair (sk sps-abo , vk sps-abo ). SPS.Sign-ABO(sk sps-abo , m) → σ sps or ⊥ : An all-but-one signer given an all-but-one signing key sk sps-abo and a message m ∈ M sps , outputs a signature σ sps ∈ S sps or a distinguished string ⊥ to indicate failure. For simplicity of notation, we will often use SPS.Sign(sk sps-abo , m) to represent the output of this algorithm.
We note that among the algorithms described above, SPS.Setup and SPS.Split are randomized while all the others are deterministic. Efficiency: The algorithms SPS.Setup, SPS.Sign, and SPS.Verify run in time polynomial in the security parameter λ and the supported message length sps-msg . Koppula et al. [17] have constructed a splittable signature scheme using IO and one-way function.

Notion of attribute-based signatures for TMs
First, we will formally define the notion of an attribute-based signature scheme where signing policies are associated with TMs. This definition is similar to that defined in [23,25] for circuits. x ∈ U abs , and a message msg ∈ M abs , a signer outputs either a signature σ abs ∈ S abs or ⊥ indicating failure. ABS.Verify(pp abs , x, msg, σ abs ) →β ∈ {0, 1} : A verifier takes as input the public parameters pp abs , a signing attribute string x ∈ U abs , a message msg ∈ M abs , and a purported signature σ abs ∈ S abs . It outputs a bitβ ∈ {0, 1}.
We note that all the algorithms described above except ABS.Verify are randomized. The algorithms satisfy the following properties: • At the end of interaction A outputs a message-signature pair (msg * , σ * abs ). A wins if the following hold simultaneously: (i) ABS.Verify(pp abs , x * , msg * , σ * abs ) = 1. (ii) A has not made any signature query on msg * under x * .
The ABS scheme is said to be existentially unforgeable against selective attribute adaptive chosen message attack if for any PPT adversary A, for any security parameter λ,

Adv abs,uf-cma
for some negligible function negl.

Remark 3.1
Note that in the existential unforgeability experiment above without loss of generality, we can consider signature queries on messages only under the challenge attribute string x * . This is because any signature query under some attribute string x = x * can be replaced by a signing key query for a signing policy TM M x ∈ M λ that accepts only the string x. Since x = x * , M x (x * ) = 0, and thus M x forms a valid signing key query. We use this simplification in our proof.

Overview of the proposed ABS scheme
Here we explain the high level technical ideas underlying our ABS scheme. We start by adapting the techniques of Deshpande et al. [7] and Koppula et al. [17] to the ABS setting. Our master signing key consists of a PPRF key k and a set of public parameters pp acc of a positional accumulator. We assign a different signing key-verification key pair of a standard SIG scheme to each of the possible signing attribute strings and we define such an SIG signing key-verification key pair associated with a signing attribute string x as those obtained by running the setup algorithm of SIG using the randomness obtained by evaluating the underlying PPRF with key k on w inp , where w inp is the accumulation of the bits of x using pp acc . Our signing key corresponds to some TM M would comprise of two IO-obfuscated programs P 1 and P abs . The first program P 1 , also known as the initial signing program, takes as input an accumulator value and outputs a signature on it together with the initial state and header position of the TM M. The second program, P abs , also known as the next step program, has the PPRF key k hardwired in it. It takes as input a state and header position of M, along with an input symbol and an accumulator value. It essentially computes the next step function of M on the input state-symbol pair, and eventually outputs the proper SIG signing-verification key pair, if M reaches the accepting state. More precisely, in case of reaching to the accepting state, P abs first computes the PPRF with key k on input w inp . After that, it generates and outputs a SIG signing key-verification key pair by running the setup algorithm of SIG using the computed pseudorandom string.
The program P abs also performs certain authenticity checks before computing the next step function of M in order to prevent illegal inputs. For this purpose, P abs additionally takes as input a signature on the input state, header position, and accumulator value, together with a proof for the positional accumulator. The program P abs verifies the signature in order to ensure authenticity, as well as checks the accumulator proof to get convinced that the input symbol is indeed the one placed at the input header position of the underlying storage of the input accumulator value. If all these verifications pass, then P abs determines the next state and header position of M, as well as the new symbol that needs to be written to the input header position. The program P abs then updates the accumulator value by placing the new symbol at the input header position, as well as signs the updated accumulator value along with the computed next state and header position of M.
Our ABS public parameters would contain pp acc along with the IO-obfuscated verifying program V abs , which has the PPRF key k hardwired in it. It takes as input an accumulator value and performs the following steps: First, it runs the PPRF with key k on the accumulator value to generate a pseudorandom string. Next, it runs the setup algorithm of SIG using that pseudorandom string to generate and output the SIG verification key associated with the accumulator value.
In order to sign a message under some signing attribute string accepted by the TM embedded in its signing key, a signer first computes the accumulation w inp of the bits of x using pp acc which are also included in the PPRF key k, and then obtains a signature on w inp together with the initial state and header position of M, by running the program P 1 . The signer then repeatedly runs the program P abs , each time on input the current accumulator value, current state and header position of M, along with the signature on them. Additionally, in each iteration, the signer also feeds w inp to P abs . The iteration is continued until the program P abs either outputs the proper signing-verification key pair or the designated symbol ⊥ indicating failure. After that, the signer signs the message using the obtained SIG signing key. The ABS signature consists of the generated SIG verification key-signature pair. The signature verification process on some message under some claimed signing attribute string requires first generating the SIG verification key associated with the claimed signing attribute string by accumulating the bits of the claimed signing attribute string using pp acc and inputting the accumulated value to V abs . It then checks whether the generated SIG verification key matches the one included within the ABS signature, as well as whether the SIG signature included within the ABS signature verifies under that SIG verification key.
While the above strategy appears to be sound, there still remain some subtle issues. Observe that to handle the positional accumulator related verifications and updations, the program P abs must have pp acc hardwired in it. During the course of the selective unforgeability proof, we have to modify the signing keys given to the adversary A to embed the punctured PPRF key k{w * inp } punctured at w * inp instead of the full PPRF key k. Here, w * inp is the accumulation of the bits of the challenge signing attribute string x * , committed by A at the beginning of the experiment, using pp acc included within the public parameters given to the adversary A. In order to make this substitution, it is to be ensured that the programs P abs included in those signing keys always outputs ⊥ for signing attribute strings corresponding to w * inp even if reaching the accepting state. As usual, we would carry out the transformation one signing key at a time through multiple hybrid steps. Now, suppose for transforming the signing keys we attempt to follow a strategy similar to that of [7,17]. Let the total number of signing keys queried by A beq key . Consider the transformation of the νth signing key (1 ≤ ν ≤q key ) corresponding to the TM M (ν) that runs on the challenge signing attribute string x * for t * (ν) steps and reaches the rejecting state. In the course of transformation, the program P (ν) abs contained in the νth signing key would first be altered to one that always outputs ⊥ for inputs corresponding to w * inp within the first t * (ν) steps. Towards accomplishing this transition, in successive hybrids, the steps of execution of M (ν) on x * would be repeatedly programmed and unprogrammed within P (ν) abs taking the help of IO. In order to perform this operation using IO, at various stages, we need to guarantee program functional equivalence, and for that we need to generate pp acc in read/write enforcing mode, certain special statistically binding modes indistinguishable from the normal setup mode. However, in the prefixed version of positional accumulator employed in [7] or in [17], to setup pp acc in read/write-enforcing mode, we require the entire sequence of symbol-position pairs arising from iteratively running M (ν) on x * up to the step we are programming in. This was not a problem for [7,17] since in their security model the adversary A was bounded to declare the TM queries prior to setting up the system. On the contrary, in our unforgeability experiment, A is allowed to adaptively submit signing key queries corresponding to signing policy TMs of its choice throughout the experiment. In such a case, we would be able to determine those symbol-position pairs only after receiving the νth queried TM M (ν) from A. However, we would require pp acc while creating the signing keys queried by A before making the νth signing key query, and even for preparing the public parameters. Thus, it is immediate that we must generate pp acc prior to receiving the νth signing key query from A. This is clearly impossible as setting pp acc in read/write enforcing mode requires the knowledge of the TM M (ν) , which is not available before the νth signing key query of A.
Observe that the root cause of the problem discussed above is the use of a single set of public parameters pp acc of the positional accumulator throughout the system. Therefore, we attempt to assign a fresh set of public parameters of the positional accumulator to each signing key. However, for compressing the signing attribute strings to a fixed length, on which the PPRF can be applied to produce the pseudorandom strings specifying the SIG signing keyverification key pairs associated with those signing attribute strings, we need a system-wide compressing tool. We employ a somewhere statistically-binding (SSB) hash function for this purpose.
Our idea is that while signing a message under some signing attribute string x using its legitimate signing key for some TM M, the signer first computes the hash value h by hashing x using the system-wide SSB hash key, which is part of the ABS public parameters. The signer also computes the accumulator value w inp by accumulating the bits of x using the public parameters of positional accumulator, specific to its signing key. Then, using the obfuscated initial signing program P 1 included in its signing key, the signer will obtain a signature on w inp along with the initial state and header position of M. Finally, the signer will repeatedly run the obfuscated next step program P abs included in its signing key, each time giving as input all the quantities as earlier, except that it would now have to feed the SSB hash value h in place of w inp in each iteration. This is because, in case P abs reaches the accepting state, it would require h to apply the PPRF for producing the SIG signing key-verification key pair associated with x. The same change would also apply to the public verifying program V abs , namely, it would also take as input the SSB hash value of a signing attribute string in place of the accumulator value obtained by accumulating its bits.
However, this approach is not completely sound yet. Observe that, a possibly malicious signer can compute the SSB hash value h on the signing attribute string x, with respect to which it wishes to generate a signature despite of the fact that its signing policy TM M does not accepts it, but initiates the computation by accumulating the bits of only a substring of x or some entirely different signing attribute string, which is accepted by M. To prevent such malicious behavior, we include another IO-obfuscated program P 2 within the signing key, we call the accumulating program, whose purpose is to restrict the signer from accumulating the bits of a different signing attribute string rather than the hashed one. The program P 2 takes as input an SSB hash value h, an index i, a symbol, an accumulator value, a signature on the input accumulator value (along with the initial state and header position of M), and an opening value for SSB. The program P 2 verifies the signature, and also checks whether the input symbol is indeed present at the index i of the string that has been hashed to form h, using the input opening value. If all of these verifications pass, then P 2 updates the input accumulator value by writing the input symbol at the ith position of the accumulator storage, and signs the updated accumulator value (along with the initial state and header position of M). The signature used by P 2 is also a splittable signature that facilitates the security proof. The obfuscated initial signing program P 1 included in the signing key is also modified to take as input a hash value, and output a signature on the accumulator value corresponding to the empty accumulator storage together with the initial state and header position of M.
Moreover, for forbidding the signer from performing the computation by accumulating an M-accepted substring of the hashed input, we define the SIG signing key-verification key pair associated with a signing attribute string as the output of the setup algorithm of SIG using the pseudorandom string generated by applying the PPRF on the pair (hash value, length) of the signing attribute string instead of just the hash value. Note that, without loss of generality, we can set the upper bound of the length of signing attribute strings to be 2 λ , where λ is the underlying security parameter, in view of the fact that by suitably choosing λ we can accommodate signing attribute strings of any polynomial length. Since the lengths of the attribute strings are bounded by 2 λ , the lengths can be expressed as bit strings of size λ. Hence, the total size of the hash value-length pair corresponding to a signing attribute string would still be bounded. Also, the obfuscated next step programs P abs included in our signing keys, must also take as input the length of the signing attribute strings for applying the PPRF if reaching to the accepting state.
Thus, the signing procedure of our ABS scheme becomes the following: to sign a message under some signing attribute string using its legitimate signing key corresponding to some TM M, a signer first hash the signing attribute string with the system-wide SSB hash key. The signer also obtains a signature on the empty accumulator value, by running the obfuscated initial signing program P 1 on input the computed hash value. Next, it repeatedly runs the obfuscated accumulating program P 2 to authentically accumulate the bits of the hashed signing attribute string. Finally, it runs the obfuscated next step program P abs iteratively on the current accumulator value along with other legitimate inputs, until it obtains either the SIG signing key-verification key pair associated with the signing attribute string under consideration or ⊥. Once it obtains the SIG signing key-verification key pair associated with the signing attribute string, it simply signs the message using the SIG signing key, and outputs the SIG verification key-signature pair as the ABS signature on the message.
Notice that the problem with enforcing the public parameters of the positional accumulator while transforming the adaptively queried signing keys will not appear in our case as we have assigned a separate set of public parameters of positional accumulator to each signing key. However, our actual proof of selective unforgeability involves many subtleties that are difficult to describe with this high level description, and is provided in full details in the sequel. We would only like to mention here that to cope up with certain issues in the proof, another IO-obfuscated program P 3 is also included within the signing keys, we call the signature changing program, that changes the splittable signature obtained from P 2 on the accumulation of the bits of the signing attribute string, before starting the iterative computation with the obfuscated next step program P abs . Our ABS scheme is described below: ABS.Setup(1 λ ) → (pp abs = (hk, V abs ), msk abs = (K , hk)): The setup authority takes as input the security parameter 1 λ and proceeds as follows: 2. Next it generates hk $ ← − SSB.Gen(1 λ , n ssb-blk = 2 λ , i * = 0). 3. Then, it creates the obfuscated program V abs = IO(Verify.Prog abs [K ]), where the program Verify.Prog abs is described in Fig. 1.  4. It keeps the master secret key msk abs = (K , hk) and publishes the public parameters pp abs = (hk, V abs ).

Proof overview of Theorem 4.1
Signer privacy: Observe that the ABS scheme described in Sect. 3.3 clearly preserves signer privacy since the signature on some message with respect to some signing attribute string only contains the SIG verification key obtained from hashing the signing attribute string with the system wide SSB hash function and its length together with an SIG signature on the message verifiable under that SIG verification key. In particular, the ABS signatures do not depend on the signing keys used to generate them. Existential unforgeability: We provide here a bird's eye view of the proof of existential unforgeability of the ABS scheme proposed in Sect. 3.3. We avoid many subtle technical details which are actually not easy to describe at an informal level and can hinder the intuitive blueprint of proof. Recall that in the selective unforgeability experiment, the adversary A has to commit to some signing attribute string x * , under which it wishes to output a forgery, at the beginning of the experiment, and then is supplied with the public parameters, and is allowed to adaptively request any polynomial number of signatures and signing keys associated with signing policies that do not accept x * . At the end, A outputs a forged signature on some message msg * under x * , and is declared to be the winner if it has not queried any signature on msg * under x * .
To argue selective unforgeability of the above ABS construction, we first change the original unforgeability experiment into one in which we hardwire the punctured PPRF key k{x * } punctured at x * within the verifying program V abs included within the public parameters given to A, as well as in the signing programs P abs included within all the signing keys provided to A. More precisely, we modify the program V abs into a new program V abs as follows: When run on some signing attribute string x = x * , the program V abs runs identically to V abs , but it uses the punctured PPRF key k{x * } in place of the full PPRF key k. On the other hand, when run on x * , it uses a hardwired stringr * sig as the randomness for generating the SIG verification key corresponding to x * . We setr * sig to be the evaluation of the PPRF with key k on x * . We similarly modify the signing programs P abs into new programs P abs as follows: When run on some signing attribute string x = x * , P abs runs identically to P abs except that it uses the punctured PPRF key k{x * } in place of the full PPRF key k. On the other hand, when run on input x * , P abs outputs ⊥. Observe that the programs V abs and V abs are clearly functionally identical since the punctured PPRF key behaves identically to the full PPRF key on all inputs x = x * . For the same reason, for all the signing keys given to A, the programs P abs and P abs are also functionally identical since A is allowed to request signing keys for only those signing policies that does not accept x * . Thus, by the security of IO, which stipulates that obfuscations of functionally identical programs are computationally indistinguishable, the modified experiment is computationally indistinguishable from the original one. After that, we apply the pseudorandomness at punctured point property of PPRF to change the pseudorandom stringr sig hardwired within V abs to a uniformly random one. This modification essentially ensures that a perfectly distributed SIG signing key-verification key pair gets associated to x * . Note that once this alteration is made, we can directly prove the unforgeability of our ABS scheme relying on the unforgeability property of SIG.
We follow the same technique introduced in [7] for handling the tail hybrids in the final stage of transformation of the signing keys in our unforgeability experiment. Note that as in [7], we consider TMs which run for at most T = 2 λ steps on any input. Unlike [17], Deshpande et al. [7] have devised an approach to obtain an end to end polynomial reduction to the security of IO for the tail hybrids by means of an injective pseudorandom generator (PRG). We directly adopt that technique to deal with the tail hybrids in our unforgeability proof. Please refer to [7] for a high level overview of the approach. Here, hk $ ← − SSB.Gen(1 λ , n ssb-blk = 2 λ , i * = 0) and K $ ← − F .Setup(1 λ ). Thus, the distribution of the signature σ abs is clearly the same regardless of the signing key sk abs (M) that is used to compute it. Existential unforgeability: We will prove the existential unforgeability of the ABS construction of Sect. 3.3 against selective attribute adaptive chosen message attack by means of a sequence of hybrid experiments. We will demonstrate based on the security of various primitives that the advantage of any PPT adversary A in consecutive hybrid experiments differs only negligibly as well as that in the final hybrid experiment is negligible. We note that due to the selective attribute setting, the challenger B knows the challenge attribute string x * = x * 0 . . . x * * −1 ∈ U abs and the SSB hash value h * = H hk (x * ) before receiving any signing key or signature query from the adversary A. Suppose, the total number of signing key query and signature query made by the adversary A beq key andq sign respectively. As noted in Remark 3.1, without loss of generality we will assume that A only queries signatures on messages under the challenge attribute string x * . Please refer to Fig. 6 for an overview of the hybrid transitions and their analysis. The description of the hybrid experiments follows: