An Order-specified Aggregate Authority-transfer Signature
Takuya Ezure and Masaki Inamura
Graduate School of Science and Engineering, Tokyo Denki University, Saitama, Japan
Keywords:
Digital Signature, Aggregate Signature, Authority Transfer, Gap-Diffie-Hellman.
Abstract:
We propose an order-specified aggregate authority-transfer signature based on the gap Diffie-Hellman group.
In various organizations, to reduce the number of approvals required by someone who has relevant authority,
the authority for a task can be transferred to a subordinate or another person who executes the task. Currently,
authority is commonly transferred via a document, such as an authority-transfer agreement. However, to speed
up the process and maintain the integrity of the evidence, we believe that it is better to transfer such authority
via a computer network. In this paper, we propose an authority-transfer signature scheme using an order-
specified aggregate signature and a group signature, and we propose a new authority-transfer system. In the
signature method, a group signature scheme is used to express authority. Moreover, it transfers the authority
owned by the manager to another member of the group. The difference from the group manager of the group
signature is that this manager not only manages the group but also delegates authority. With the order-specified
aggregate signature, it is possible to handle multiple signatures efficiently while verifying the order. We show
that a safe and efficient authority-transfer system can be constructed using this new digital signature.
1 INTRODUCTION
In recent years, various systems utilizing digital sig-
natures have been developed to improve the efficiency
of the business transacted by an organization. For ex-
ample, in a document-browsing system, a manager
can see who has read a document and, if there have
been multiple readers, the order in which the docu-
ments were read. Organizations can use this system
to ensure that the workflow of approvals is done cor-
rectly. Because of the restricted validity of digital
certificates, such systems are used in a closed envi-
ronment such as within a single organization. How-
ever, the business of an organization is not completed
only internally, and other organizations are involved.
Therefore, it is necessary to make a system incorpo-
rating the employees of other organizations as well,
for example, if multiple companies are jointly work-
ing on a project.
The first function required is to transfer the author-
ity of the manager to someone else, which must be
verifiable. For a general digital signature, first, a com-
mercial digital signature is acquired from a trusted
third-party certificate authority, and a manager per-
forms key management. When the manager received
electronic document which needs a signature from an
employee, the manager signs it using the private key
that he owns, and sends it back to the employee. How-
ever, this method relies on the manager, and if he is
absent, it may take time for the digital signature to
be applied. As a solution to this problem, a man-
ager’s signing authority could be delegated to an em-
ployee, for one project. Therefore, we focused on Yao
et al.’s method, which can transfer authority using a
group signature, which is an anonymous digital sig-
nature (Yao and Tamassia, 2009). To be precise, Yao
and colleagues proposed an anonymous-signer aggre-
gate signature scheme. However, since its function is
almost the same as the group signature, it is treated as
a group signature in this paper.
The second function required is the ability to ag-
gregate multiple signatures and to reduce the size of
a signature. A joint project may need multiple digital
signatures. In a multisignature scheme, several people
sign the same message (Itakura and Nakamura, 1983).
The signatures are aggregated and rendered as a single
digital signature. In an aggregate signature scheme,
several people sign different messages (Boneh et al.,
2003). Again, the signatures are aggregated and ren-
dered as a single digital signature.
The third function required is to verify the order
of signing. In a joint project, the order of signatures
may be important in concluding contracts and the like.
Therefore, we thought that it was necessary to be able
Ezure, T. and Inamura, M.
An Order-specified Aggregate Authority-transfer Signature.
DOI: 10.5220/0007359103090318
In Proceedings of the 5th International Conference on Information Systems Security and Privacy (ICISSP 2019), pages 309-318
ISBN: 978-989-758-359-9
Copyright
c
 2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
309

to verify the order of signing.
To summarize the above, three functions are re-
quired for a digital signature scheme for joint projects.
The first is to transfer the manager’s signature author-
ity. The second is to aggregate multiple signatures to
make verification more efficient. The third is that the
signature order can be viewed.
In this paper, we propose an order-specified aggre-
gate authority-transfer signature with the above three
functions and an authority-transfer system that can be
jointly used by multiple organizations. First, we ex-
plain Yao et al.’s group signature scheme. Next, we
propose a signature scheme with a shorter verifica-
tion time than the scheme of Yao et al. We propose
the order-specified aggregate authority-transfer signa-
ture that adopts the structuring method of Yanai et
al (Yanai et al., 2017). We use a graph for the com-
plicated relationships between signers. Finally, we
propose an authority-transfer system using the order-
specified aggregate authority-transfer signature.
2 RELATED WORK
2.1 Gap Diffie-Hellman Group
Okamoto and Pointcheval defined the gap Diffie-
Hellman (GDH) group (Okamoto and Pointcheval,
2001). Consider a multiplicative cyclic group G with
prime order p. They defined two Diffie-Hellman
(DH) problems as follows:
Computational Diffie-Hellman (CDH) Problem:
For a, b ∈ Z
∗
p
and g ∈ G, given (g, g
a
, g
b
), compute
g
ab
.
Decisional Diffie-Hellman (DDH) Problem:
For a, b, c ∈ Z
∗
p
and g ∈ G, given (g, g
a
, g
b
, g
c
),
decide whether c
?
= ab.
Like the GDH group, the DDH problem is defined
as easy, whereas the CDH problem is hard.
2.2 BLS Signature by Pairing
Various studies based on the GDH group defined in
section 2.1 have been conducted. It has been shown
that a GDH group on an elliptic curve can be con-
structed using a function called pairing. We first de-
fine the computational co-Diffie-Hellman (co-CDH)
problem and the decisional co-Diffie-Hellman (co-
DDH) problem on the elliptic curve. Consider dif-
ferent additive cyclic groups G
0
1
and G
0
2
with prime
order p. Two problems are defined for the DH prob-
lem as follows:
co-CDH Problem: For a ∈ Z
∗
p
and g
1
∈ G
0
1
, g
2
∈ G
0
2
,
given (g
1
, g
2
, ag
1
), compute ag
2
.
co-DDH: For a, b ∈ Z
∗
p
and g
1
∈ G
0
1
, g
2
∈ G
0
2
, given
(g
1
, g
2
, ag
1
, bg
2
), determine whether a
?
= b.
We will explain the features of pairing. Let G
1
and
G
2
be different additive cyclic groups of prime order
p that can perform pairing. e is a computable bilin-
ear map e:G
1
× G
2
→ G
τ
. Pairing has the following
characteristics:
• If P
1
, P
2
∈ G
1
and Q ∈ G
2
then e(P
1
+ P
2
, Q) = e(P
1
, Q)e(P
2
, Q).
• If P ∈ G
1
and Q
1
, Q
2
∈ G
2
then e(P, Q
1
+ Q
2
) = e(P, Q
1
)e(P, Q
2
).
• If a, b ∈ Z
∗
p
and P ∈ G
1
, Q ∈ G
2
then e(aP, bQ) = e(bP, aQ) = e(abP, Q)
= e(P, abQ) = e(P, Q)
ab
.
When using additive cyclic groups on the ellip-
tic curve, such as G
1
and G
2
, it is generally consid-
ered that the co-CDH problem is hard. On the other
hand, owing to the features of this pairing, the co-
DDH problem can be easily solved, and the GDH
group can be configured on the elliptic curve.
Boneh et al. showed that a signature scheme con-
structed using the features of this pairing can be re-
alized. This is the Boneh-Lynn-Shacham (BLS) sig-
nature scheme (Boneh et al., 2001). It is based on
groups G
1
and G
2
and is structured as follows:
Key Generation: g is a generator of G
1
. The private
key of the signer is a random element x ∈ Z
∗
p
, and
his public key is v = xg.
Signing: H:{0, 1}
∗
→ G
2
is a one-way hash func-
tion. m is both a plain message and a signing tar-
get. The signer computes h = H(m) and returns
σ = xh.
Verification: When the verifier is given (g,v, m, σ),
he computes h = H(m) and verifies
e(g, σ) = e(v, h).
2.3 Aggregate Signature
An aggregate signature is a scheme in which a plu-
rality of people sign each message, and the signatures
are aggregated and represented by one digital signa-
ture. It is possible to reduce the signature size and
the verification time by aggregating this plurality of
signatures. On the basis of the BLS signature in sec-
tion 2.2, an aggregate signature called the BGLS sig-
nature was proposed by Boneh et al., which we will
explain below (Boneh et al., 2003).
Consider a group U of n signers who contribute
to an aggregate signature. Let i ∈ U (1 ≤ i ≤ n) be a
ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy
310

signer participating in the aggregate signature. Each
user i selects a message m
i
to be signed and creates
a signature σ
i
for it. These signatures are then com-
bined into one BGLS signature. The security depends
on the co-CDH problem. The algorithm consists of
key generation, signature, aggregation, and verifica-
tion. Also, like the BLS signature, we use the def-
inition of the GDH group on the elliptic curve for
(G
1
, G
2
). The algorithm is structured as follows:
Key Generation: g is a generator of G
1
. The private
key of the signer i ∈ U is a random element
x
i
∈ Z
∗
p
, and his public key is v
i
= x
i
g.
Signing: H:{0, 1}
∗
→ G
2
is a one-way hash func-
tion. Let m
i
be the message of signer i. The signer
i computes h
i
= H(m
i
) and returns σ
i
= x
i
h
i
.
Aggregation: Collect all individual signatures σ
i
(1 ≤ i ≤ n), and calculate σ =
∑
n
i=1
σ
i
.
Verification: When the verifier is given (g, v
i
, m
i
, σ)
(1 ≤ i ≤ n), he computes h
i
= H(m
i
) (1 ≤ i ≤ n)
and verifies e(g, σ) =
∏
n
i=1
e(v
i
, h
i
).
2.4 Group Signature
A group signature is a digital signature scheme in
which a verifier can confirm only the affiliation of a
signer to a group and cannot identify who signed it.
The group signature can protect privacy by prevent-
ing identification of the signer.
This section describes the aggregate group signa-
ture proposed by Yao et al (Yao and Tamassia, 2009).
For simplicity, some methods have been changed.
This signature scheme was created based on the group
signature proposed by Chen et al (Chen et al., 2006).
This group signature can be made using the BGLS
signature algorithm. Therefore, because the secu-
rity of the BGLS signatures has been proved, we can
prove the security of the aggregate group signatures.
Here, we explain how a group signature is created
from a BGLS signature. In advance, members create
secret keys and public keys, and send the public key
to group manager GM. The GM performs the BGLS
signature (group signature key) on the public key and
returns it to the member. The group signature is the
aggregate of the BGLS signature of the message and
the group signature key.
As a result, not only the group signatures of the
same group but also the group signatures of other
groups can be aggregated together. In addition, in-
formation such as an expiry date can be included in
the group signature key of each member issued by
the GM, and this information can be verified. Fur-
ther, Yao and colleagues proposed a method of dele-
gating authority by putting authority information into
a group signature key.
An aggregate group signature is organized as fol-
lows:
Preconditions:
• G
1
and G
2
are the additive cyclic group and the
multiplicative cyclic group of the prime order
q, respectively, where G
1
is the GDH group.
• π is the generator of G
1
.
• A map e:G
1
× G
1
→ G
2
is a bilinear map.
• H:{0, 1}
∗
→ G
1
is a one-way hash function.
Set-up:
• A trusted third-party creates the parameter
para(G
1
, G
2
, e, π, H).
• Member U chooses a private s
u
∈ Z
∗
q
as his pri-
vate key and computes P
u
= s
u
π as his public
key.
• Similarly, the GM chooses a private key s
A
∈ Z
∗
q
and computes the public key P
A
= s
A
π.
Join:
• U randomly chooses a number of pri-
vates (x
1
, . . . , x
l
∈ Z
∗
q
) and computes one-
time signing factors X
u,1
= x
1
π, . . . , X
u,l
=
x
l
π and one-time signing public keys K
u,1
=
s
u
x
1
π, . . . , K
u,l
= s
u
x
l
π. Keys P
u
, X
u,i
, and K
u,i
are sent to the GM, for all i ∈ [1, l].
• The GM tests if e(K
u,i
, π) = e(P
u
, X
u,i
) for all i.
If the test fails, the protocol terminates. Other-
wise, the GM runs the BGLS signing algorithm
on inputs s
A
and strings TkK
u,i
(T is the author-
ity information) to obtain S
u,i
= s
A
H(T kK
u,i
)
for all i. S
u,i
is the ith one-time signing permit
for U and is given to U. The GM adds tuples
(P
u
, K
u,i
, X
u,i
) to his record for all i.
Sign:
• U runs the BGLS signing algorithm with pri-
vate key s
u
x
i
and message M and obtains a sig-
nature S
u
= s
u
x
i
H(M).
• U aggregates signature S
u
with one-time sign-
ing permit S
u,i
associated with private s
u
x
i
. This
is done by running the aggregation function of
the BGLS scheme, which returns a signature
S
g
= S
u
+ S
u,i
.
Aggregate:
This is the same as the aggregation algorithm in
the BGLS scheme. It takes as inputs n signatures
S
g
k
and the corresponding values P
A
k
and K
u
k
,i
k
for
all k ∈ [1, n]. Set S
Agg
=
∑
n
k=1
S
g
k
.
S
Agg
is outputted as the aggregate group signature.
Note that the kth GM public key P
A
k
for k ∈ [1, n]
An Order-specified Aggregate Authority-transfer Signature
311

does not need to be the same. In other words, sig-
natures from different organizations can be aggre-
gated.
Verify:
• For 1 ≤ k ≤ n, compute the hash digest H(M
k
)
of message M
k
and h
k
= H(T
k
kK
u
k
,i
k
) of the
statement on the one-time signing permit.
• S
Agg
is accepted if
e(S
Agg
, π) =
∏
n
k=1
e(H(M
k
), K
u
k
,i
k
)e(h
k
, P
A
k
).
Open:
If S
Agg
is valid, the GM can easily identify a mem-
ber’s public key P
u
k
from K
u
k
,i
k
by consulting the
record.
3 AGGREGATE
AUTHORITY-TRANSFER
SIGNATURES
In this paper, we assumed that a plurality of people,
including those with different memberships, can ver-
ifiably sign a document. We may want to verify a
signer’s identity, their affiliation, or authority at the
time of signing. We can do this using Yao et al.’s
method, as discussed in section 2.4 (Yao and Tamas-
sia, 2009). We believe that strong anonymity of a
group signature is not necessary. Because an aggre-
gate transfer signature is not a group signature. More-
over, as the number of signatures increases, the veri-
fication time increases. In this section, we propose
an aggregate transfer signature with short verification
time based on Yao et al.’s method. Unlike group man-
ager GM, the manager M of this signature scheme not
only manages groups but also delegates authority.
3.1 Security Definition
In this section, we describe the security of an aggre-
gate authority-transfer signature. A signature is de-
fined as secure when it satisfies the following: cor-
rectness, unforgeability, and traceability. It is the
same as the security of a group signature without
anonymity and unlinkability.
Correctness: A signature created by a legitimate
member passes verification and identifies the
signer.
Unforgeability: Only legitimate members can make
valid signatures. Even if an attacker collaborates
with another member or manager, it can not forge
the signature of a member who is not collusion.
Traceability: The signature that passes the verifica-
tion can always identify the signer. Even if an at-
tacker collaborates with other members, it is im-
possible to create a signature that the verification
passes but the signer cannot identify.
3.2 Construction
Preconditions:
• G
1
and G
2
are the additive cyclic groups of the
prime order q.
• G
1
and G
2
are the co-GDH groups.
• G
3
is the multiplicative cyclic group of prime
order q.
• P is is the generator of G
1
.
• Q is is the generator of G
2
.
• A map e:G
1
× G
2
→ G
3
is a bilinear map.
• H
1
:{0, 1}
∗
× G
2
→ G
1
and
H
2
:{0, 1}
∗
× G
2
→ Z
∗
q
are one-way hash func-
tions.
Set-up:
• A trusted third-party creates the parameter
para(G
1
, G
2
, G
3
, P, Q, e, H
1
, H
2
).
• Member U chooses a private s
u
∈ Z
∗
q
as his pri-
vate key and computes P
u
= s
u
P as his public
key.
• Similarly, the manager M chooses his private
key s
A
∈ Z
∗
q
and computes the public key
P
A
= s
A
Q.
Join:
• U randomly chooses a private x ∈ Z
∗
q
and com-
putes signing factors X
u
= xQ and public keys
K
u
= xs
u
Q. Keys P
u
, X
u
, and K
u
are sent to the
M.
• The M confirms that P
u
is U’s public key. The
GM tests if e(P, K
u
) = e(P
u
, X
u
). If the test
fails, the protocol terminates. Otherwise, the
M runs the BGLS signing algorithm on in-
puts s
A
and strings T
u
kK
u
(T
u
is the authority
information transferred by manager) to obtain
S
u
= s
A
H
1
(T
u
kK
u
). S
u
is an authority-transfer
key and is given to U. The M adds tuples
(P
u
, K
u
, X
u
, T
u
) to his record.
Sign:
U signs message M. U gets an authority-transfer
key S
u
from the M. U randomly chooses r ∈ Z
∗
q
.
U computes the following:
B = rQ. (1)
C = S
u
+ H
2
(MkB)xs
u
P + rP. (2)
K
u
= xs
u
Q. (3)
The signature is σ = {B,C, K
u
, T
u
}.
ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy
312

Aggregate:
Aggregation takes as inputs n signatures,
σ
k
= {B
k
,C
k
, K
u
k
, T
u
k
}, and the corresponding val-
ues P
A
k
and K
u
k
for all k ∈ [1, n]. Only C
k
can be
aggregated and becomes C
Agg
=
∑
n
k=1
C
k
. The ag-
gregate authority-transfer signature is
σ
Agg
= {B
k
,C
Agg
, K
u
k
, T
u
k
} for all k ∈ [1, n].
Verify:
• For 1 ≤ k ≤ n, compute the hash digests
H
1
(K
u
k
kT
u
k
) and H
2
(M
k
kB
k
).
• σ
Agg
is accepted if
e(C
Agg
, Q) =
∏
n
k=1
(e(H
1
(K
u
k
kT
u
k
), P
A
k
))
·e(P,
∑
n
k=1
(H
2
(M
k
kB
k
)K
u
k
+ B
k
)).
Open:
If σ
Agg
is valid, the M can easily identify a mem-
ber’s public key P
u
k
from K
u
k
by consulting the
record.
3.3 Construction
In this section, we describe the advantages and disad-
vantages of the aggregate authority-transfer signature
compared with Yao et al.’s method (Yao and Tamas-
sia, 2009). The following are the verification formu-
las of Yao et al.’s method and the aggregate transfer
signature when N signatures are aggregated.
The Verification Formula for Yao et al.’s Method:
e(S
Agg
, π)
=
n
∏
k=1
e(H(M
k
), K
u
k
,i
k
)e(h
k
, P
A
k
). (4)
The Verification Formula for Aggregate
Authority-transfer Signature:
e(C
Agg
, Q)
=
n
∏
k=1
(e(H
1
(K
u
k
kT
u
k
), P
A
k
))
· e(P,
n
∑
k=1
(H
2
(M
k
kB
k
)K
u
k
+ B
k
)). (5)
The number of pairings calculated when verifying
the aggregate signature for N signatures for each for-
mula is shown in table 1
From table 1, it can be seen that the number of
pairings at the time of verification of the aggregate
authority-transfer signature is about half of that of
Yao et al.’s method if the number of signatures, N,
is large. An advantage is that the verification time
can be shortened by reducing the number of pairings.
A disadvantage is that the number of signatures of a
Table 1: Number of pairings when verifying an aggregate
signature (N signatures).
Yao et al.’s Aggregate
method authority-transfer signature
2N + 1 N + 2
point on the elliptic curve increases by 1 for each mes-
sage. However, since the points on the elliptic curve
are not large, the advantage of shortening the verifi-
cation time is greater than the disadvantage that the
signature size increases.
3.4 Security Analysis
This section explains the security of the aggregate
authority-transfer signature described in section 3.2.
First, we will prove the security of a single authority-
transfer signature that does not aggregate. Next, we
prove the security of the aggregate authority-transfer
signature.
3.4.1 Correctness
The correctness of the authority-transfer signature is
proved as follows:
e(C, Q)
=e(S
u
+ H
2
(MkB)xs
u
P + rP, Q)
=e(S
u
, Q) · e(H
2
(MkB)xs
u
P, Q)· e(rP, Q)
=e(s
A
H
1
(T
u
kK
u
), Q) · e(H
2
(MkB)xs
u
P, Q)
· e(rP, Q)
=e(H
1
(T
u
kK
u
), s
A
Q) · e(P, H
2
(MkB)xs
u
Q)
· e(P,rQ)
=e(H
1
(T
u
kK
u
), P
A
) · e(P, H
2
(MkB)K
u
)
· e(P,B)
=e(H
1
(T
u
kK
u
), P
A
) · e(P, H
2
(MkB)K
u
+ B). (6)
3.4.2 Unforgeability
In the authority-transfer signature scheme, attackers
can be either a member or a manager. We do not con-
sider cases where the third party is an attacker because
fewer information is available than other attackers.
The ability to attack when the attacker is a mem-
ber of the group:
• Create and register new members.
• Issue authority-transfer authority key A to a
new member.
• Collusion between a new member and another
member (non-collusion with a manager).
An Order-specified Aggregate Authority-transfer Signature
313

The attack target when the attacker is a member
of the group:
Passing verification using K for a member other
than the member who has colluded or the new
member.
The ability to attack when the attacker is a man-
ager:
• Create and register new members.
• Issue authority-transfer authority key A to a
new member.
• Collusion between a new member and an exist-
ing member.
The attack target when the attacker is a manager:
Passing verification using K for members other
than the member who has colluded or the new
member.
Security is considered by looking at the signature
formula. The signature C = S
u
+ H
2
(MkB)xs
u
P + rP
can be divided into the following:
A =S
u
= s
A
H
1
(T
u
kK
u
). (7)
D =H
2
(MkB)xs
i
P + rP. (8)
The respective verification equations are the fol-
lowing:
e(A, Q) = e(s
A
H
1
(T
u
kK
u
), Q)
= e(H
1
(T
u
kK
u
), s
A
Q). (9)
e(D, Q) = e(H
2
(MkB)xs
i
P + rP, Q)
= e(P, H
2
(MkB)K
u
) · e(P, B). (10)
The authority-transfer key A of formula (7) and
signatures K and T are keys issued during the interac-
tion between the member and a manager. Therefore,
there is a possibility that the key information is leaked
because of communication leakage or collusion. In
addition, old signatures can also be obtained. We set
the following attack environment which is favorable
to attackers.
Attacker’s Environment: An attacker can obtain all
authority-transfer keys A, signatures
σ = {B,C, K
u
, T
u
}, and messages M issued, in-
cluding the forgery target.
For an attacker to forge a signature, they must
forge both expression (9) and expression (10). Ex-
pression (9) is the same as the BLS signature, where
the message is the authority information T
u
and the
signature K
u
. Forging the authority information T
u
and the signature K
u
corresponding to the message is
difficult because of the security of the BLS signature.
It is difficult for an attacker who is a member to forge
a signature other than the signature K
u
. Therefore,
the attack target of an attacker who is a member is
the same as the attack target of an attacker who is a
manager. The attacker tries to forge expression (10)
using the signature K
u
, where the verification formula
of expression (9) is established. There are roughly
two methods for forging expression (10).
• Obtain xs
u
from the signature K
u
= xs
u
Q made by
the forgery target. Alternatively, obtain r
n
from
signature B = rQ.
This is difficult because it is a discrete logarithm
problem on an elliptic curve.
• Obtain H
2
(MkB)xs
u
P or rP from the signature
C made by the forgery target. Then, extract
H
2
(MkB) from H
2
(MkB)xs
u
P, find xs
u
P, and use
it for forgery.
If it is possible to find the same signature B = rQ
in multiple signatures, there is a possibility that xs
u
P
can be obtained, but since the r used for a signature is
random, the probability of a match is low.
3.4.3 Traceability
Expression (9) of the verification expression is a BLS
signature in which the message is the authority infor-
mation T
u
and the signature K
u
. Therefore, it is dif-
ficult to make a signature that can pass verification
with the signature K
u
that cannot be tracked because
of the security of the BLS signature, even if a member
collaborates with another member.
3.4.4 Unforgeability of the Aggregate
Authority-transfer Signature
The security of the aggregate authority transfer signa-
ture will be briefly described. Authority transfer sig-
nature and aggregate authority transfer signature indi-
cate that unforgeability is equivalent.
We prove this security using the method of
Boldyreva (Boldyreva, 2002; Boldyreva, 2003),
which is used in Inamura et al.’s system as the security
proof (Inamura et al., 2011; Inamura and Iwamura,
2013). Let A be an attacker who is attempting to forge
an aggregate authority-transfer signature C
0
Agg
. Let B
be an attacker who forges an authority-transfer signa-
ture. If A’s attack succeeds, it indicates that B’s attack
succeeds. If B’s attack succeeds, it is obvious that A’s
attack will succeed, so the proof of this is omitted.
Attacker B has a verification key of the object
to be forged σ
1
= {K
u
1
, T
u
1
, P
A
1
, B
1
} and responds
to the random oracle and the signature oracle. At-
tacker B executes A as an honest player. First, B gives
σ
1
= {K
u
1
, T
u
1
, P
A
1
, B
1
} to A. Attacker A outputs other
signature keys and verification keys
ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy
314


(S
u
2
, x
2
s
u
2
, r
2
, T
u
2
, K
u
2
, B
2
, P
A
2
), . . . ,
(S
u
n
, x
n
s
u
n
, r
n
, T
u
n
, K
u
n
, B
n
, P
A
n
)

.
Also, attacker A uses the random oracle and the signa-
ture oracle to find C
0
Agg
and the message (M
1
, . . . , M
n
)
to be signed, and responds to B. Attacker B computes
the following using C
0
Agg
:
C
0
Agg
−
n
∑
i=2
(S
u
i
+ H
2
(M
i
kB
i
)x
i
s
u
i
P + r
i
P)
= S
u
1
+ H
2
(M
1
kB
1
)x
1
s
u
1
P + r
1
P.
Therefore, the authority-transfer signature corre-
sponding to σ
1
can be computed, and B’s attack suc-
ceeds.
As described above, it is difficult to forge the ag-
gregate authority-transfer signature if forgery of the
authority-transfer signature is difficult.
4 ORDER-SPECIFIED
AGGREGATE
AUTHORITY-TRANSFER
SIGNATURE SCHEME
In this proposed method, we adopt the structuring
method proposed by Yanai et al. for the aggre-
gate authority-transfer signature described in sec-
tion 3 (Yanai et al., 2017). Using graphs, we show the
complex relationships between signers. As a method
of structuring, when signing, we refer to the graph.
The messages of all of the signers before the current
signer are gathered and signed in addition to the cur-
rent message. The generated signature and the sig-
natures for the adjacent signers are aggregated, and
a new aggregate signature is created. For a proof of
security, see Yanai et al.
4.1 Series-parallel Graph
4.1.1 Definition of a Series-parallel Graph
Let G be a set of graphs. A series-parallel graph is
a graph generated by applying either a serial graph
or a parallel graph recursively in an arbitrary order.
Specifically, a series-parallel graph G(I, T ), which
starts at the initial vertex I and terminates at the ter-
minal vertex T , is defined as follows.
G(I, T ) is generated either by following step 1 or
step 2.
1. With a unique label i in G, G
i
(I
i
, T
i
) is composed
of one edge connecting I
i
and T
i
. We call such a
graph an atomic graph and denote it by φ
i
∈ G.
2. For step 2, either one of the following steps is ex-
ecuted:
(Parallel graph) Given n graphs G
i
(I
i
, T
i
), for
1 ≤ i ≤ n, construct G(I, T ) by setting
I = I
1
= I
2
= ··· = I
n
and T = T
1
= T
2
= ··· = T
n
.
(Serial graph) Given n graphs G
i
(I
i
, T
i
), for
1 ≤ i ≤ n, construct G(I,T ) by setting I = I
1
,
T
1
= I
2
,. . . , T
n−1
= I
n
, and T
n
= T .
Intuitively, in the above definitions, constructing
G(I, T ) means compositions of n atomic graphs φ
i
∈
G for i = [1, n] either as a serial one or a parallel
one (Yanai et al., 2017).
4.1.2 Graph Composition
For two atomic graphs φ
1
, φ
2
∈ G, we define a compo-
sition of parallel graphs as φ
1
∪ φ
2
and the composi-
tion of serial graphs as φ
1
∩φ
2
. In other words, φ
1
∪φ
2
means to construct G(I, T ) by setting I = I
1
= I
2
and
T = T
1
= T
2
, and φ
1
∩ φ
2
means to construct G(I, T )
by setting I = I
1
, T
1
= I
2
, and T
2
= T . We denote by
T (i) a set of graphs connecting to the initial vertex I
i
of the ith graph in a way such that
T (i) = {x|I
i
= T
x
∧ 1 ≤ x < i ∧ G
x
(I
x
, T
x
) ⊂ ψ
n
},
where n is the number of atomic graphs and ψ
n
is the
whole graph for any n, by I(i) a set of graphs connect-
ing to the terminal vertex T
i
of the ith graph in a way
such that
I(i) = {x|T
i
= I
x
∧ i < x ≤ n ∧ G
x
(I
x
, T
x
) ⊂ ψ
n
},
by {a
j
}
j∈T (i)
, for all a
j
for j ∈ T (i). A whole graph
that includes multiple graphs in its terminal vertex T
i
can be denoted by ψ
I(i)
. That is, if ψ
I(i)
includes a sin-
gle atomic graph φ
i
in the terminal vertex, then ψ
I(i)
is equal to ψ
i
(Yanai et al., 2017).
4.1.3 Weight of a Graph
We define a weight function ω
i
(ψ
n
) that represents
a weight of each label i for a graph ψ
n
. Intuitively,
ω
i
(ψ
n
) is the number of paths including an edge with
a label i from I
i
to T
n
for ψ
n
. We denote by #ψ
n
the
number of edges in ψ
n
for any structure ψ
n
(Yanai
et al., 2017).
4.1.4 Toy Example
In this section, we show a toy example of a series-
parallel graph and its parameters. For a graph shown
in figure 1, its parameters are given as shown in ta-
ble 2.
We call the initial node for the whole graph as
“whole initial” and the terminal node for the whole
graph as “whole terminal”, respectively. In the
columns of T (i) and I(i), we give the indexes of cor-
An Order-specified Aggregate Authority-transfer Signature
315

Table 2: Signer structure.
Graph
φ
i
composition T (i) I(i) ω
i
(ψ
n
)
in ψ
i
φ
1
ψ
1
= φ
1
Whole 2,3 3
initial
φ
2
ψ
2
= φ
1
∩ φ
2
1 Whole 1
terminal
φ
3
ψ
3
= φ
1
∩ φ
3
1 4,5 2
φ
4
ψ
4
3 Whole 1
= φ
1
∩ φ
3
∩ φ
4
terminal
φ
5
ψ
5
3 Whole 1
= φ
1
∩ φ
3
∩ φ
5
terminal
responding atomic graphs. We also denote by ψ
n
as
whole graph.
We show a toy example of the extraction in table 3.
We utilize a series-parallel graph as the signer
structure. Here, an edge of a series-parallel graph cor-
responds to a signer, and a unique edge for the graph
corresponds to a unique index that represents the po-
sition of each signer in any structure (Yanai et al.,
2017).
Figure 1: Example of graph ψ
n
.
4.2 Construction
Preconditions:
The preconditions are the same as those for the ag-
gregate authority-transfer signature in section 3.2.
Set-up:
The setup is the same as that for the aggregate
authority-transfer signature in section 3.2.
Join:
The join condition is the same as that for the ag-
gregate authority-transfer signature in section 3.2.
Sign:
U is the ith signer and signs message M
i
for ψ
i
.
U refers to the graph before the signature, and it
verifies the signature of the previous signer. We
pass (para, {P
A
j
, M
j
}
j⊂ψ
T (i)
, ψ
T (i)
, {σ
Agg
j
}
j∈T (i)
)
to the verification algorithm. If the verification
fails, the protocol terminates. Otherwise, U ran-
domly chooses r ∈ Z
∗
q
. U computes the following:
B
i
= rQ. (11)
K
u
i
= xs
u
Q. (12)
h
i
= H
2
(M
i
kB
i
). (13)
{h
j
= H
2
(M
j
kB
j
)}
j⊂ψ
T (i)
. (14)
Finally, U computes
C
i
=
∑
j∈T (i)
C
j
+S
u
i
+xs
u
(
∑
j⊂ψ
T (i)
h
j
+h
i
)P+rP.
S
u
i
= s
A
i
H
1
(T
u
i
kK
u
i
) is an authority-transfer key.
T
u
i
is the authority information transferred by
the M. The order-specified aggregate authority-
transfer signature is
σ
Agg
i
= ({B
j
, K
u
j
, T
u
j
}
j⊂ψ
i
,C
i
).
Verify:
Given (para, {P
A
j
, M
j
}
j⊂ψ
I(i)
, ψ
I(i)
, {σ
Agg
j
}
j∈I(i)
),
we check if i ≤ 3
logP
log3
holds (Tada, 2003).
If not, the protocol terminates. Next, we
check whether all of the authority information
{T
u
j
}
j⊂ψ
I
(i)
is appropriate. The verifier computes
C =
∑
j∈I(i)
C
j
if |{σ
Agg
j
}
j∈I(i)
| > 1. Otherwise,
if |{σ
Agg
j
}
j∈I(i)
}| = 1, we set C = C
j
. Then,
we check if the following equation holds with
H
1
(K
u
j
kT
u
j
) and H
2
(M
j
kB
j
) for all j:
e(C, Q)
=
∏
j⊂ψ
I(i)
e

ω
j
(ψ
I(i)
)H
1
(K
u
j
kT
u
j
), P
A
j

· e P,
∑
j⊂ψ
I(i)


∑
l⊂ψ
T ( j)

H
2
(M
l
kB
l
)

+ H
2
(M
j
kB
j
)

ω
j
(ψ
I(i)
)K
u
j

+
∑
j⊂ψ
I(i)
ω
j
(ψ
I(i)
)B
j
!
.
Open:
Open is the same as that for the aggregate
authority-transfer signature in section 3.2.
Table 3: Signer structure.
ψ
i
Indexes j ∈ ψ
i
ψ
1
1
ψ
2
1,2
ψ
3
1,3
ψ
4
1,3,4
ψ
5
1,3,5
ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy
316

5 PROPOSED
AUTHORITY-TRANSFER
SYSTEM
In this section, we propose an authority-transfer sys-
tem using the order-specified aggregate authority-
transfer signature proposed in section 4. This system
can be used by multiple organizations. This system
has the following features:
• The number of digital certificates issued by the
trusted authority is lower. The number of certifi-
cates does not depend on the number of members.
• Managers can easily transfer their authority to
members.
• The authority of the signer can be verified.
• Signatures of different organizations can be ag-
gregated.
• The verification time is small.
• The order of signing can be verified.
5.1 Entities
In the authority-transfer system, there are five entities
(figure 2). We will explain the role of each.
Figure 2: Configuration of the authority-transfer system.
5.1.1 Certificate Authority
A certificate authority is a trusted third-party. It issues
commercial digital certificates based on an applica-
tion from a manager in an organization. All organiza-
tions participating in this system must use certificates
from the same certificate authority so that the same
parameters are used for signing and verification.
5.1.2 Member
Members are employees of an organization. They reg-
ister in the group and apply for a manager to issue an
authority-transfer key.
5.1.3 Online Certificate Status Protocol
Responder
The online certificate status protocol (OCSP) respon-
der holds the revocation information for a signature
and can respond in real time to inquiries about the
validity of the signature. If each organization has
an OCSP responder, the verifier needs to communi-
cate with each of them, which takes time. Therefore,
all organizations participating in this system use the
same OCSP responder, which reduces the verification
time.
5.1.4 Manager
Each organization has a manager, who manages the
commercial digital signatures authenticated by the
certificate authority. When a manager receives an ap-
plication for a key from an employee in his organiza-
tion, he registers the employee with the group. Then,
he issues an authority-transfer key and transfers his
authority to sign to the member, thus delegating his
authority.
5.1.5 Verifier
The verifier verifies the order-specified aggregate
authority-transfer signature. The verifier queries the
OCSP responder whether the signer has not been re-
voked.
5.2 Construction
Preconditions:
The preconditions are the same as those for the ag-
gregate authority-transfer signature in section 3.2.
Set-up:
• A trusted third-party certificate authority cre-
ates parameters
para(G
1
, G
2
, G
3
, P, Q, e, H
1
, H
2
).
• Member U chooses a private s
u
∈ Z
∗
q
as his pri-
vate key and computes P
u
= s
u
P as his public
key.
• Similarly, the manager M chooses his private
key s
A
∈ Z
∗
q
and computes the public key
P
A
= s
A
Q.
• The M sends the public key P
A
to the certificate
authority to apply for a certificate.
• The certificate authority reviews the application
and sends a certificate to the M.
Join:
This is almost the same as the join condition for
An Order-specified Aggregate Authority-transfer Signature
317

the aggregate authority-transfer signature in sec-
tion 3.2. Also included in the authority informa-
tion T is the serial number for the revocation in-
formation.
Sign:
This is the same as that for the order-specified ag-
gregate authority-transfer signature in section 4.2.
Verify:
A revocation check is added to the verification for
the order-specified aggregate authority-transfer
signature in section 4.2:
• The verifier transmits the serial number in-
cluded in the authority information T of all sig-
natures to be verified to the OCSP responder.
• The OCSP responder refers to the revocation
list and checks for the serial number from the
verifier. If it is not in the list, he sends a “valid”
message to the verifier; otherwise, he sends an
“invalid” message.
• If the verifier receives an “invalid” message
from the OCSP responder, the verification fails.
Open:
This is the same as that for the aggregate
authority-transfer signature in section 3.2.
Management of Revocation Information:
If a manager wants to invalidate a key, he sends
the serial number in the authority information T
to the OCSP responder.
6 CONCLUSIONS
In this paper, we proposed an order-specified aggre-
gate authority-transfer signature that can be used to
delegate authority, aggregate signatures, and main-
tain the order of signing. Moreover, we proposed an
authority-transfer system using that signature scheme.
An advantage of an aggregate authority-transfer
signature is that the verification time is reduced com-
pared to that in Yao et al.’s method. A disadvantage
is that signature size is larger compared to that in Yao
et al.’s method. For this reason, we believe that the
proposed method should be operated in a system that
requires a quick response.
As a future work, we will consider the security of
the order-specified aggregate authority-transfer signa-
tures, implement the authority-transfer system, and
consider whether the method is practical.
ACKNOWLEDGEMENTS
This work was supported by JSPS KAKENHI Grant
Number JP16K00192.
We would like to thank Enago for the English lan-
guage review (https://www.enago.jp).
REFERENCES
Boldyreva, A. (2002). Efficient threshold signature, mul-
tisignature and blind signature schemes based on the
gap-diffie-hellman-group signature scheme. Cryptol-
ogy ePrint Archive, Report 2002/118.
Boldyreva, A. (2003). Threshold signatures, multisigna-
tures and blind signatures based on the gap-diffie-
hellman-group signature scheme. In Public Key Cryp-
tography - PKC 2003, LNCS, volume 2567, pages 31–
46. Springer.
Boneh, D., Gentry, C., Lynn, B., and Shacham, H. (2003).
Aggregate and verifiably encrypted signatures from
bilinear maps. In Advances in Cryptology - EURO-
CRYPT 2003, LNCS, volume 2656, pages 416–432.
Springer.
Boneh, D., Lynn, B., and Shacham, H. (2001). Short signa-
tures from the weil pairing. In Advances in Cryptology
- ASIACRYPT 2001, LNCS, volume 2248, pages 514–
532. Springer.
Chen, X., Zhang, F., and Kim, K. (2006). New id-based
group signature from pairings. Science Press J. of
Electronics (China), 23(6):892–900.
Inamura, M. and Iwamura, K. (2013). Content approval
systems with expansions of a new pair-connected-
structured aggregate signature scheme. IGI Global In-
ternational J. of E-Entrepreneurship and Innovation,
4(2):15–37.
Inamura, M., Iwamura, K., Watanabe, R., Nishikawa,
M., and Tanaka, T. (2011). A new tree-structure-
specified multisignature scheme for a document circu-
lation system. In International Conference on Security
and Cryptography - SECRYPT 2011, pages 362–369.
SciTePress.
Itakura, K. and Nakamura, K. (1983). A public-key cryp-
tosystem suitable for digital multisignatures. NEC Re-
search & Development, 71:1–8.
Okamoto, T. and Pointcheval, D. (2001). The gap-
problems: A new class of problems for the security
of cryptographic schemes. In Public Key Cryptogra-
phy - PKC 2001, LNCS, volume 1992, pages 104–118.
Springer.
Tada, M. (2003). A secure multisignature scheme with sign-
ing order verifiability. IEICE Trans. on Fundamentals
of Electronics, Communications and Computer Sci-
ences, E86-A(1):73–88.
Yanai, N., Iwasaki, T., Inamura, M., and Iwamura, K.
(2017). Provably secure structured signature schemes
with tighter reductions. IEICE Trans. on Fundamen-
tals of Electronics, Communications and Computer
Sciences, E100-A(9):1870–1881.
Yao, D. and Tamassia, R. (2009). Compact and anonymous
role-based authorization chain. ACM Trans. on Infor-
mation and System Security, 12(3):15:1–15:27.
ICISSP 2019 - 5th International Conference on Information Systems Security and Privacy
318