Blank Digital Signatures: Optimization and Practical Experiences

. Blank Digital Signatures ( BDS ) [18] enable an originator to delegate the signing rights for a template, containing ﬁxed and exchange-able elements, to a proxy. The proxy is then able to choose one of the predeﬁned values for each exchangeable element and issue a signature for such an instantiation of the template on behalf of the originator. In this paper, we propose optimizations for the BDS scheme from [18] and present a library, integrating this optimized version within the Java Cryptography Architecture and the keying material into X.509 certiﬁ-cates. To illustrate the ﬂexibility of the proposed library, we introduce two proof-of-concept implementations building up on XML and PDF, respectively. Finally, we give a detailed insight in the performance of the protocol and our implementation.


Introduction
In contrast to conventional digital signatures, involving a signer and a verifier, proxy-type digital signature schemes are signature schemes involving three parties, namely an originator, a proxy and a verifier.Here, the originator delegates the signing power (for some particular well defined set of messages) to a proxy.The proxy can then sign messages on behalf of the originator.Any verifier, given a message and a corresponding signature, can check whether the proxy has produced the signature on behalf of the originator (authenticity), the integrity of the message and whether the given message is one of the "allowed" messages.
Blank Digital Signatures (BDS) [18] are a special instance of proxy-type digital signatures, allowing an originator to define and issue a signature on a template, containing fixed and exchangeable elements.A designated proxy can then produce signatures for instantiations of this template (messages).More precisely, given a template signature, the proxy creates an instantiation by choosing one of the predefined values for each of the exchangeable elements and issues a signature with respect to the template signature.When verifying this signature, only the message and the corresponding signature is needed, and it is required that the verifier does not learn anything about the unused choices in the exchangeable elements in the template (privacy property).
Blank Digital Signatures give rise to a lot of interesting applications, and, accordingly, the question arises how a BDS scheme would perform in a practical implementation, and to which extent it can be integrated into off-the-shelf cryptographic frameworks such as the Java Cryptography Architecture [26] and key infrastructures such as PKIX [8].

Our Contribution
In this paper, we propose optimizations for the BDS scheme in [18] and present a full-fledged implementation of this optimized version.Firstly, we briefly revisit the scheme and discuss possible practical applications.Then, we show how the scheme can be modified to use Type-3 pairings instead of the originally proposed Type-1 pairings and introduce optimizations for the encoding of templates.Subsequently, we show how the scheme can be integrated into the Java Cryptography Architecture and how the keying material can be encapsulated within X.509 certificates.Moreover, two possible signature formats, namely an XML and a PDF signature format, are proposed.Finally, timings of our implementation, showing the practical applicability of the BDS scheme, are provided and discussed.

Background
We use additive notation for groups, which are always of prime order p.A function : N → R + is called negligible if for all c > 0 there is a k 0 such that (k) < 1/k c for all k > k 0 .In the remainder of this paper, we use to denote such a negligible function.
Definition 1 (Bilinear Map:) A bilinear map (pairing) is a map e : G 1 × G 2 → G T , where G 1 , G 2 and G T are cyclic groups of prime order p.Let P and P generate G 1 and G 2 , respectively.We require e to be efficiently computable and to satisfy: Bilinearity: e(aP, bP ) = e(P, P ) ab = e(bP, aP ) ∀a, b ∈ Z p Non-degeneracy: e(P, P ) = 1 G T , i.e., e(P, P ) generates G T .
If G 1 = G 2 , e is called symmetric and asymmetric otherwise.Asymmetric pairings can be either Type-2 or Type-3 pairings.The difference between Type-2 and Type-3 pairings is that an efficiently computable isomorphism Ψ : G 2 → G 1 exists for Type-2 pairings, while for Type-3 pairings such an isomorphism is unknown.
Definition 2 (t-SDH assumption [5]) Let p be a prime of bitlength κ, G 1 and G 2 be finite cyclic groups of order p, generated by P ∈ G 1 and P ∈ G 2 , respectively, P = Ψ (P ), α ∈ R Z * p and t > 0.Then, for all PPT adversaries A it holds that Pr c, In this paper, we concentrate on Type-3 pairings on Barreto-Naehrig curves [4] with embedding degree 12. Thus, elements in G T have a bitlength of 12 • bitlength(p).For our setting, we chose a bitlength of 256 bits, leading to a bitlength of 3072bit in G T .This choice is ideal w.r.t. the comparable strengths proposed by NIST [3], since the discrete logarithm problem should be equally hard in the additive groups G 1 , G 2 and in the multiplicative group G T .In the Type-3 setting, we can use the natural counterpart of the t-SDH assumption, i.e., the co-t-SDH assumption [7,19].
Definition 3 (co-t-SDH assumption [7,19]) Let p be a prime of bitlength κ, G 1 and G 2 be finite cyclic groups of order p, generated by Then, for all PPT adversaries A it holds that Pr c,

Digital Signature Schemes
A digital signature scheme DSS is a triple (DKeyGen, DSign, DVerify) of PPT algorithms.Thereby, DKeyGen is a key generation algorithm that takes a security parameter κ ∈ N as input and outputs a secret (signing) key sk and a public (verification) key pk.Further, DSign is a (probabilistic) algorithm, which takes a message M ∈ {0, 1} * and a secret key sk as input, and outputs a signature σ.Finally, DVerify is a deterministic algorithm, which takes a signature σ, a message M ∈ {0, 1} * and a public key pk as input, and outputs a single bit b ∈ {true, false} indicating whether σ is a valid signature for M under pk.

Java Cryptography Architecture
The Java Cryptography Architecture [26] (JCA) constitutes an API, providing standardized access to cryptographic algorithms.Each library that implements this API needs to implement a so-called cryptographic Provider, registering the provided algorithm implementations at the JCA.The desired Provider is then set by the user of the library, and instances of the algorithm implementations can be obtained using the JCA-provided factories.The primitives we use in this paper are implementations of the Signature interface, the KeyPairGenerator interface and the KeyFactory interface, respectively.The Signature interface resembles the DSign and DVerify functionality of a digital signature scheme as discussed above, whereas the KeyPairGenerator interface and the KeyFactory interface provide methods for conveniently generating and handling keys in general.Using the JCA, entire implementations can be easily exchanged by simply setting another Provider.
In this section, we introduce the notion of BDS schemes in general, and then give a brief overview of the BDS scheme from [18] (further referred to as BDSS).We discuss the basic building blocks, as well as the principles underlying the signature generation and verification.Since this paper lays focus on the practical aspects of the BDSS, we keep this section quite informal and refer the reader to [18] for more formal definitions.
A BDS scheme allows an originator to designate the signing rights for a certain template to a proxy.A template T , thereby, is a sequence of non-empty sets of bitstrings T i .Depending on the cardinality of the respective set, such sets are either called fixed or exchangeable elements, i.e., fixed elements contain exactly one bitstring, whereas exchangeable elements contain k > 1 distinct bitstrings.More formally, we have: The template length is defined as the sequence length n of the template, while the template size |T | is defined as Furthermore, each template is assigned a unique identifier id T .Once the template is defined, the originator issues a signature on T for a particular proxy.Based on this so called template signature, the designated proxy can choose concrete values for each exchangeable element (fixed elements stay fixed) and compute a so called instance signature on this message M = (M i ) n i=1 .With the instance signature at hand, anyone is able to verify the validity of the instance signature and the designation.
Besides the usual correctness property, a BDS scheme provides unforgeability, immutability and privacy.Informally, these properties are defined as follows.Unforgeability requires that, without knowledge of the secret keys, it is intractable to (existentially) forge template or instance signatures.Immutability essentially models a stronger adversary in the unforgeability setting, i.e., additionally covers adversaries knowing the signing key of the proxy.Finally, privacy requires that it is intractable (for outsiders) to determine template elements (except the ones revealed by instantiations).

Applications
Basically, a BDS scheme enables an originator to hand over a signed form (template), containing fixed and exchangeable elements, to a proxy being designated to sign an arbitrary instance of this form, i.e., a filled in form, on behalf of the originator.Figure 1 illustrates a sample template running through a BDS protocol execution.As shown in this figure, it is also possible to encode yes-/no-choices within a template by simply encoding yes and no in an exchangeable element.
In particular, a BDS scheme is applicable to any contract, which requires to leave a few choices open to an intermediary party, while the rest of the content is fixed.For instance, it would be thinkable that a broker makes a business deal on behalf of a client, using a template, previously defined and signed by An encoding m(X) ∈ Z p [X] of a message M looks as follows: Finally, the so-called complementary message polynomial m(X) is defined such that t(X) = m(X) • m(X) holds.More precisely, m(X) contains all factors which are contained in t(X) but not in m(X).For the rest of this paper, we use C T , C M and C M to denote the (polynomial) commitments to the encodings of templates, messages and complementary-messages, respectively.The commitments used in the BDSS are unconditionally hiding and computationally binding and due to the nature of the commitments (they are instantiated within bilinear groups), it holds that e(C T , P ) = e(C M , C M ).
The BDSS defines five algorithms, which we briefly introduce subsequently.We assume the public parameters pp generated in KeyGen to be an implicit input to all other algorithms.Furthermore, we assume that both, the originator and the proxy are already in possession of a keypair for a conventional DSS. KeyGen

Tweaks and Optimizations
Since the BDSS is designed for Type-1 pairings, we need to modify the scheme to make it compatible with much more efficient Type-3 pairings.In this section we discuss these modifications, together with an optimization regarding the encoding of templates and messages to reduce the degree of the encoding polynomials.

Using Type-3 Pairings
The authors of [18] informally suggested that the scheme can be used with Type-3 pairings by duplicating some of the points in the system-wide parameters, i.e., some points in G 1 also have to be mapped to points in G 2 .In the following, we discuss the necessary modifications in detail.For all these modifications it is crucial that the counterpart Q in G 2 , of a point Q in G 1 , contains the same discrete logarithm as the point Q, i.e., Q = aP and Q = aP for a ∈ Z p .Currently, the system-wide parameters pp of the BDS scheme contain a sequence P = (α i P ) t i=0 of multiples of a point P , with t being the maximal template size.For Type-3 pairings, the sequence has to be extended with the same multiples of a point P ∈ G 2 , i.e., P = ((α i P ) t i=0 , (α i P ) t i=0 ).In the subsequent protocol steps, one has to choose the appropriate representative of the required point, i.e., the representative in G 1 or G 2 .Additionally, in the verification step of the message (Verify M ) the pairing e(C M , C M ) is evaluated.Thus, in the instantiation step (Inst), the commitment to the complementary message polynomial C M needs to be computed in G 2 . 3Using this modification, the computation of C M is the only remaining computation which requires operations in G 2 .Thus, it seems to be impossible to find further optimizations based on moving computations from one group to the other.
It is easy to see that switching to the Type-3 setting does not influence the security of the scheme.The original BDSS [18] was proven secure under the t-SDH assumption.Using the co-t-SDH assumption, the security proof of the modified BDSS is (up to the extended problem instance) equivalent to the original proof in [18], and, thus, using Type-3 pairings does not influence the security of the scheme.

Aggregating Fixed Elements
An important optimization can be based on the reduction of the degree of the encoding polynomials by aggregation.The idea behind the aggregation of the fixed elements is the observation that in the originally proposed BDSS encoding, each fixed element corresponds to one factor in the encoding polynomials.The scheme does, however, not require this separate encoding.Thus, we can simply aggregate the fixed elements within one factor of the encoding polynomials by concatenating the identifier of the template, the messages and the positions of the messages in the template as follows: This reduces the degree of the encoding polynomials, and, thus, also the computation times.Note that this optimization also enables the reduction of the size of the system parameters pp, i.e., pp is no longer dependent on the number of fixed elements.Subsequently, we analyze the security of these modification.
Proof.In the original construction [18], every fixed element represents a factor in the template encoding polynomial and in further consequence in every message encoding polynomial.The modification proposed here integrates all fixed elements into a single factor, which reduces the degree of the respective polynomials.Now, we have to show that this has no impact on the security of the construction.Our argumentation is as follows.Using one factor for the fixed elements in the modified version can be seen as the original construction using only a single fixed element in the template.Therefore, the construction as such still remains secure.What remains to show, however, is that the modified encoding does not influence the correctness (signature soundness) and the unforgeability as well as immutability, respectively.
In this context, signature soundness essentially says that, given a template signature σ T for some template T , the probability that this signature will verify for any T = T is negligible in the security parameter κ.To achieve this (for fixed elements), one would need to find which is clearly intractable if H is collision resistant.The same argumentation holds for unforgeability and immutability (cases T1, M1 [18]), where the problem is to find a second preimage for H(id T m i1 i 1 . . .m iu i u ).

Implementation in JAVA and Integration into the JCA
In this section, we provide an in-depth description of the implementation related aspects of the optimized BDSS.Our design is based on the observation that the signing and verification algorithms for both, templates and messages, can be interpreted as conventional signature algorithms with special types of messages.This means that one can use a standard signature API, such as the one provided by the Java Cryptography Architecture (JCA) [26], to obtain an easy to use implementation.Furthermore, X.509 provides, among others, a convenient and well-established method to ensure key authenticity and integrity.Besides, also methods for revocation checking are provided [8].Thus, we follow this approach and integrate the keying material within X.509 certificates.Finally, we propose two container formats, i.e., XML and PDF, encapsulating the templates and messages, respectively, together with their corresponding signatures.

Overview
Figure 2 links the BDSS algorithms to the parties performing the respective computations and provides an overview of the required interaction during a usual workflow (note that all algorithms are non-interactive).The gray boxes in

TTP
Step 1 (KeyGen) Step 2 (Sign) Step 3 (VerifyT ) Step 4 (Inst) Step 5 (VerifyM) Fig. 2: BDS Scheme Computation Steps the figure logically group consecutive computation steps to units with defined input and output.For the sake of simplicity, we omitted the visualization of the distribution of the system parameters pp by the trusted third party (TTP).We, however, assume that the TTP provides means for retrieving pp in an authentic manner.For instance, our default implementation encapsulates pp within an X.509 certificate (cf.Section 5.2).To provide maximum flexibility, the library relies on a generic interface for accessing the TTP, and, consequently, our library is not bound to one fixed TTP implementation.From a JCA point of view, the generation of pp is wrapped in a KeyPairGenerator implementation and is, thus, conveniently usable by arbitrary TTP implementations.
The subsequent steps, i.e., Step 2-5 in Figure 2, are packed into two JCA Signature implementations, namely the BDSSTemplateSignature (Step 2 and 3) and the BDSSInstanceSignature (Step 4 and 5).To be compatible with the JCA Signature interface, we override the engineSetParameter method.This way, it is possible to supply so called AlgorithmParameterSpec implementations containing the additionally required parameters for executing the protocol.Furthermore, the API assumes that the signing and verification algorithms operate on arrays of bytes.Thus, we (de-)serialize the respective inputs to preserve their structure (cf.Section 5.2).Listing 1 provides an example for obtaining a BDSS signature on a template.The BDSSInstanceSignature can be used in a similar way and is therefore omitted.
Listing 1: Java Code to Obtain a BDS Template Signature Note that the returned template signature also contains the instantiation key sk T P , which needs to be removed when a use case requires to publish the template.Also note that if the privacy property of the BDSS is required, a secure transmission of the output of Step 2 in Figure 2 is inevitable.Thus, our library provides means for ECIES (see e.g., [22]) encryption and decryption.

Encoding and Key Representation in X.509
As mentioned before, it is required to (de-)serialize the templates and messages with corresponding signatures to be compatible with the API of the JCA.Consequently, a compact encoding with minimal overhead is desired to keep the transmission times low.We use a unique encoding, similar to the BER/DER [21] encoding of ASN.1 [20] and provide means for serialization and deserialization.
It also turns out that this encoding is useful to integrate the keying material as public key info into X.509 certificates [8].To (re-)extract the serialized keys from the public key info, our Java cryptographic provider provides the appropriate KeyFactory implementations (performing the deserialization).
To bring the (signed) templates and messages into a user friendly form, e.g., to support users to conveniently fill in a templates, we introduce two container formats in the remainder of this section.For both formats, we follow the approach that the templates and messages are included in a human readable form, whereas the signatures are serialized using our encoding from above.

Defining an XML Signature Format
To use XML, we added Java annotations for XML binding (JAXB), as defined in [13], to the classes serving as input-/output-containers.These annotations, together with the appropriate XML schema allow to conveniently marshal/unmarshal Java objects to/from XML using the routines provided by the Java platform.Listing 2 and Listing 3 show the proposed signature format, with "?" and "+" denoting the multiplicity of the tags, i.e., "?" means at most once, whereas "+" means at least once.Signable PDF forms seem to be an essential application of BDSS.Thus, a proofof-concept implementation using PDF as container format is introduced subsequently.Thereby, our library provides means to create, sign and verify templates and messages in PDF format.Furthermore, signed templates can directly be filled in in the same way as conventional PDF forms using a standard PDF reader.Figure 3 shows a sample template and a corresponding message, both containing a signature.

Performance Evaluation
In this section, we provide an overview of the performance of our proof-of-concept implementation.For the timings, we use the BNPairings library [15] for computing the optimal Ate pairing [30] on BN curves [4] with 256 bit group size and an embedding degree of 12.As conventional digital signatures we use ECDSA [14,17] with the NIST P-224 curve [14].The timings were performed using a single core on a Lenovo ThinkPad T420s with an Intel Core i5 2540M with 2.6/3.3GHz and 8 GB of RAM.On the software side Java 1.7.0 55 was used on top of Ubuntu 14.04/amd64.We measure the execution time of the four protocol steps (Step 2-5 in Figure 2) for different template sizes and template compositions.To isolate timingrelated influences, e.g., the garbage collector, each timing represents the mean of 100 consecutive runs.Table 1 shows the computation times for template sizes ranging from 3 to 1000.To illustrate the influence of the distribution of the element types on the timing, we provide timings for two different element type distributions.Note that it does not make sense to choose a template with less than 50% of exchangeable elements, since templates are always chosen minimal, i.e., there are no two fixed elements next to each other. 4The used element type distribution is indicated by the percentage values in the top row of Table 1. Figure 4 gives an overview of the computation time with increasing template size.As expected, the computation times depend heavily on the degree of the In practice, most forms will contain less than 100 elements, which leads to computation times of less than 180ms for each step.This is perfectly acceptable for practical use.Finally, observe that BDS allow to quite straightforwardly define the template in a way, which enables similar functionalities as redactable/sanitizable signatures [2, 6,23,25,29].Although, such an application of BDS is not considered in this paper (it has been done in [28] as a replacement for redactable signatures as used in [31]), we conclude that -due to its good performance -our BDSS implementation might also be an alternative to implementations of redactable/sanitizable signatures (e.g., [27]) in certain settings.

Conclusion and Future Work
In this paper, we proposed an optimization regarding the template and message encoding of the BDSS and modified it to use much more efficient Type-3 pairings.We introduced a JCA-based interoperable framework for the BDSS, providing an easy to use API.To illustrate the capabilities, concerning the integration into other applications, two signature formats were proposed.Moreover, we gave an overview of the performance of the scheme and our implementation.Meanwhile, our implementation based on the XML signature format has been integrated into the FutureID eSignServices framework [1] -a flexible framework for signature generation and validation.
The execution times presented in Section 6 are totally practical, since in most scenarios it can be expected that templates will have a template-size of less than 100, leading to computation times of less than 180ms for arbitrary template constellations.This shows that the BDSS is fully feasible for practical use.For further details on our BDSS implementation and optimization, we refer the reader to [9].
Finally, there are some points we leave open for future work.Quite recently, a black-box construction of BDS from non-interactive anonymous credentials was presented in [10].It would, thus, be interesting to compare the performance of an implementation of this construction to our implementation.Another interesting step would be to increase the practical usability of our implementation by integrating the BDSS within a plug-in of a PDF reader.Furthermore, we do not expect any problems when integrating the XML signatures proposed in Section 5.3 into other XML signature formats such as XMLDSig [11] or the various types of XML Advanced Electronic Signatures [12].The latter format would, in turn, enable long term signature validation, which could be of particular interest for BDSS signed contracts.
Verify T : This algorithm takes a template T , a template signature σ T , the verification keys of the originator (pk O ) and the proxy (pk P ), as well as sk T P .It computes C T and C = e(C T , P ), and outputs the result of DVerify(σ T , id T ||C||n|| pk P , pk O ).Inst: This algorithm takes a template T with corresponding message M, a template signature σ T , the signing key of the proxy sk P and the instantiation key sk T P .It computes C M and µ = DSign(τ ||C M ||M, sk P ) and returns σ M = (µ, C M , M, σ T ).Verify M : This algorithm takes M, σ M and the verification keys of the originator (pk O ) and the proxy (pk P ) and computes C M from M. Then, it checks whether DVerify(τ, id T ||C||n||pk P , pk O ) = true and DVerify(µ, τ ||C M ||M, pk P ) = true holds.If so, it checks whether the number of elements in the message is equal to n, whether there is exactly one element at each position in the message and whether e(C M , C M ) = C. On success it returns true and false otherwise.

Fig. 4 :
Fig. 4: Computation Times in Relation to the Template-Size and the Element Type Distribution.

:
This algorithm takes a security parameter κ and an upper bound t for the template size.It chooses two groups G 1 , G T of the same prime order p (with log 2 p = κ), generated by P , having a bilinear map e : G 1 ×G 1 → G T , a secure cryptographic hash function H : {0, 1} * → Z p and a random α ∈ Z * p .Finally, it outputs the public parameters pp = (H, G 1 , e, p, (α i P ) t i=0 ). 2 Sign: This algorithm takes a template T of length n, the signing key of the originator sk O and the verification key of the proxy pk P .It computes the commitment C T to T , C = e(C T , P ) and τ = DSign(id T ||C||n||pk P , sk O ) and outputs σ T = (id T , C, n, τ ) together with a private instantiation key for the proxy sk T P (required for recomputing the commitment).

Table 1 :
Timings for Various Template Sizes in Milliseconds encoding polynomials.Consequently, having more fixed elements, for the same size |T |, results in a lower degree polynomial -using our trick from Section 4.2 -and corresponding shorter computation times.