Lightweight One-Time Signature for MulticastAuthentication

Pan Deng and Liuqing YangDepartment of Electrical and Computer Engineering

Colorado State University

Fort Collins, CO 80523

wsdp@lamar.colostate.edu, lqyang@engr.colostate.edu

Abstract—Authentication is a security requirement with highpriority in many multicast applications. One-Time Signature(OTS) is a promising solution to the multicast authenticationproblem. However, it often suffers from large signature sizesand frequent distributions of the public keys. In this paper, wepropose a lightweight OTS scheme to combat these drawbacks.Our approach integrates the signature amortization techniqueand one-way hash chains, which markedly reduce the averagecommunication overhead and relax the key renewal require-ments. We also introduce a partial key renewal mechanism toprovide a convenient means of renewing key pairs. In addition,our scheme is highly secure against signature forge and isresistant to packet losses. Numerical results show that our schemeachieves better performance than a former scheme under DoSattacks.

I. INTRODUCTION

A multicast protocol enables the delivery of a message to

a group of receivers simultaneously in a single transmission

from the sender. Multicast is much more efficient than one-to-

one communication protocols when the number of receivers is

very large. Therefore, the multicast protocol is widely applied

in various applications, such as live updates, news feeds and

stock quotes. In recent years, multicast has been studied by

many researchers with focus on different application environ-

ments, e.g., wireless sensor networks [1], disruption tolerant

networks [2] and smart grid [3].

In a hostile network environment, multicast communications

are subject to many cyber-security threats. For example, an

attacker may forge packets and send them to multiple receivers

for malicious purposes. Therefore, practical multicast proto-

cols often require some degree of security requirements, e.g.,

confidentiality and authenticity. Considering that multicast

messages mostly contain non-sensitive information or control

commands, the authenticity of a message is emphasized more

than the confidentiality.

Authentication requires that the receiver is able to check

whether a message indeed comes from its claimed sender.

Generally, the solutions to this problem can be divided into

two categories: symmetric key approach and asymmetric key

approach. Symmetric key approach, such as Message Authen-

tication Code (MAC), uses a secret key shared between the

sender and receiver to authenticate messages. The sender first

uses the secret key to generate a message-dependent MAC,

and then the MAC will be sent along with the message. The

receiver will verify if the same MAC can be generated with the

secret key and the received message. This method is efficient

in terms of both computation and space overhead. However,

it is not suitable for the multicast scenario, since the secret

key will be exposed to numerous receivers, thus a MAC could

be easily forged by any of them. Therefore, the asymmetric

key approach such as digital signature turns out to be more

reasonable here. With this approach, the sender keeps a private

key which is never exposed to other entities. A corresponding

public key is published and known by all receivers. A digital

signature is generated by the private key, and can be verified

using the public key later to show that a message with the

signature is truly from the owner of the private key. Traditional

digital signatures, such as RSA [4] and ElGamal [5], are

widely believed to be secure within the computation capability

of modern computers. However, the computation overhead of

these schemes are too high to be practical for many resource-

limited devices, e.g., sensors and field devices.

As an alternative to traditional digital signatures, a new

type of digital signature, one-time signature (OTS) is arousing

growing interest of numerous researchers. OTS was first

proposed independently by Lamport [6] and Rabin [7], and

since then, various improvements [8], [9], [10], [11] have been

developed. OTS only requires one-way hash functions to sign

and verify a signature, thus it is much more computationally

efficient than regular digital signatures. However, there are

two main drawbacks which severely reduce the applicability

of most OTS schemes: first, the public key size and the

signature size are usually very large, which leads to a high

communication and storage overhead; second, each key pair

is supposed to be used only once or only a few times, thus

repeated distribution of new keys is required, which induces

additional cost.

In this paper, we propose a lightweight OTS scheme for

multicast authentication which overcomes the aforementioned

drawbacks. Our scheme is based on the idea of signature

amortization, i.e., amortizing a single signature over multi-

ple packets. This technique can greatly reduce the average

communication overhead per packet, at the cost of signing

and verification delay due to packet buffering at both the

sender and receiver side. Thus, our scheme is more suitable in

bandwidth-limited environments, where the data to be sent are

not time-critical. To deal with packet losses and DoS attacks,

978-1-4673-3/12/$31.00 ©2013 IEEE978-1-4673-3/12/$31.00 ©2013 IEEE

we employ Reed-Solomon code to encode the authentication

information. We use one-way hash chains to renew public keys

in an automatic manner, which frees our scheme from frequent

distribution of public keys. In addition, a partial key renewal

mechanism is introduced to serve as a backup means of key

renewal.

The rest of this paper is organized as follows. As back-

ground review, section II briefly introduces some related

works. Section III describes our proposed scheme in detail.

Security analysis is presented in Section IV. Numerical results

are shown in Section V, where we evaluate the performance of

our scheme and compare it with a previously proposed scheme.

Finally, Section VI concludes the paper.

II. RELATED WORKS

A. HORS One-Time Signature

HORS was proposed by Reyzin and Reyzin [10], which

is an attractive OTS scheme with very fast signing and

verification. Because of its efficiency, many other works [3],

[12], [13] use HORS as the foundation of their design. The

basic idea of HORS is to map the hash of a message to a

random subset of {1, ..., N}, where the signature is generated

using this subset. Specifically, given a parameter set (l, k, t),HORS proceeds as follows:

• Key Generation: Generate t random l-bit strings

(s1, s2, ..., st), which form the private key SK. The

public key P K is then computed as P K = (v1, v2, ..., vt)where vi = f(si) and f is a one-way function.

• Signing: To sign a message m, let h = H(m), where His a hash function. Split h into k substrings h1, h2, ..., hk

of log2 t bits each. Interpret each hj as an integer ij . The

signature of m is then (si1 , si2 , ..., sik).• Verification: To verify a signature (s′1, s′2, ..., s′k) for

message m, let h = H(m). Split h into k substrings

h1, h2, ..., hk of log2 t bits each. Interpret each hj as

an integer ij , and check if f(s′j) = vij holds for each

1 ≤ j ≤ k.

B. Signature Amortization

Signature amortization is a useful method which notably

reduces the size of the authentication information carried by

each data packet. One basic idea is to amortize a single

signature over a group of packets, where each packet will

carry partial information of the signature. The receiver will

consider the whole group of packets to be authentic after the

signature is verified. For the reliability of the scheme, possible

packet losses should be taken into account. A reliable scheme

usually integrates some type of erasure code like IDA [14]

and Tornado Code [15], such that the signature can still be

reconstructed and verified even when some packets in the

group are lost during transmission. For example, a multicast

authentication scheme, SAIDA, was proposed in [16] which

employs IDA to perform erasure coding.

C. One-way Hash Chain

One-way hash chain is an important cryptographic primitive

which is widely used in many security applications [12], [13],

[17]. Given a hash function H and an initial element s1, one

can build a hash chain of length L by iteratively computing

si+1 = H(si), 1 ≤ i ≤ L − 1. Hash chains are often used

in OTS schemes to extend the use times of a public key.

For example, in HORS, if sL is released as a public key

element, then all other si can be used as private key elements.

One can easily verify if sj is in the hash chain by checking

HL−j(sj) = sL. Since calculating the inverse of a hash

function is believed to be computationally hard, exposing sjwill not give any useful information about si, ∀i < j. Thus,

one can use si in a reversed order without compromising any

security in HORS.

III. PROPOSED SCHEME

In this section, we describe our authentication scheme in

detail. Here we use HORS as a basis for our scheme for its

efficiency in signing and verification, as well as its relatively

small signature size.

A. Signature Generation

We suppose that all the packets to be sent are first di-

vided into groups at the sender side. Each group consists

of n packets. For every such group, the same operations

will be performed, so we only need to consider one group

G = P1, P2, ..., Pn, where Pi ∈ {0, 1}c for some constant c.

The signature generation procedure goes as follows:

1) Calculate packet hash for each packet as hi =H(Pi), i = 1, 2, ...n, using a collision resistant hash

function H , such as SHA-1.

2) Concatenate all packet hashes to form FG =h1‖h2‖...‖hn, where FG contains N 8-bit symbols.

3) Generate a HORS signature for FG, denoted as SG =(s1, s2, ..., sk).

4) Encode FG using an (n, m) Reed-Solomon code. To do

so, we first divide FG into N/m blocks of length m(padding zeros at the end if m does not divide N ):

FG = (b1, ..., bm), (bm+1, ..., b2m), ..., (bN−m+1, ..., bN )

where each bi is an 8-bit symbol. Feed each block

into Reed-Solomon encoding function to get a encoded

block of n symbols. For each i = 1, 2, ..., n, collect

the ith symbol of all encoded blocks together to form nsegments F1, F2, ..., Fn, which are called hash segments.

5) Similarly, encode SG into n signature segments

S1, S2, ..., Sn.

6) Attach each hash segment and signature segment to the

corresponding packet to get an authenticated packet, i.e.,

append Fi and Si to Pi, for i = 1, 2, ..., n.

When all packets are combined with authentication infor-

mation, the group is ready to be sent.

B. Signature Verification

The verification process is straightforward at the receiver

side. Assuming that at least m authenticated packets are

successfully received, the authentication information carried

by these packets can be collected to form N/m encoded

blocks, where each of them has at most n − m symbols

missing. Then, the error correction ability of Reed-Solomon

codes guarantees the reconstruction of FG and SG. Upon

successful reconstruction of FG and SG, the receiver will

verify whether SG is a valid signature for FG. If SG is valid,

then all the packets received can be authenticated by checking

whether their hashes are contained in FG.

Here, the tradeoff between reliability and communication

overhead is determined by the parameters n and m, which

should be carefully chosen according to application require-

ments. A smaller ratio n/m leads to better reliability, at the

cost of more coding redundancy, which increases communi-

cation overhead.

C. Key Extension

In the original proposal of HORS, each key pair can be used

for up to r times for small values of r, since the security of

the scheme decreases as r increases. As a result, frequent key

updating process may be required. With the help of one-way

hash chains, we can utilize these keys in a more efficient and

convenient way.

First, instead of using a single key pair, the sender can

generate t random values (s(1,1), s(1,2), ..., s(1,t)), use them

to build t hash chains of length L and store all hash chains

for later use. Note that all the computations can be done

off-line without incurring any signing delay. The group of

hash chains is aligned as a matrix of size L × t, which we

call hash chain matrix, as shown in Fig. 1. The last row,

(s(L,1), s(L,2), ..., s(L,t)), will be published as the first public

key. The second last row, (s(L−1,1), s(L−1,2), ..., s(L−1,t)) is

the corresponding private key.

(1, 1)

(2, 1)

(L, 1)

(L-1, 1)

H(·)

H(·)

H(·)

(1, 2)

(2, 2)

(L, 2)

(L-1, 2)

(1, t)

(2, t)

(L, t)

(L-1, t)

Fig. 1. Original hash chain matrix

Whenever a signature is computed and sent out, we require

all revealed secret values contained in the signature to be up-

dated. To do so, the sender simply shifts down corresponding

columns in Fig. 1. For example, if s(L−1,2) and s(L−1,t) are

used in a signature, the sender will first remove s(L−1,2) and

s(L−1,t) from the hash chain matrix, and then move the column

2 and t one element down. The hash chain matrix after the

change is shown in Fig. 2, with two “empty” elements on

the top of the column 2 and t. Now, the last row will be the

new public key for the next round. All receivers will replace

elements s(L,2) and s(L,t) with s(L−1,2) and s(L−1,t) they just

received to form the new public key. The second last row

will be the new private key with new elements s(L−2,2) and

s(L−2,t). Note that the new private key still does not contain

any elements ever exposed.

(1, 1)

(2, 1)

(L, 1)

(L-1, 1)

H(·)

H(·)

H(·)

(1, 2)

(L-1, 2)

(L-2, 2)

(1, t)

(L-1, t)

(L-2, t)

Fig. 2. Changed hash chain matrix

There are some known weaknesses with one-way hash chain

based protocols. For example, it is mentioned in [12] that

if some signed messages are lost during transmission, the

keys of the sender and receiver may lose synchronization.

Fortunately, our scheme does not severely suffer from chain

synchronization problem, since the receiver can reconstruct a

signature as long as the number of missing packets does not

exceed n − m.

D. Partial Key Renewal

Even with the key extension technique above, we can

use up one of the hash chains after L − 1 signatures are

calculated, in the worst case that each signature contains an

element from the same column. Thus we need a way to update

the exhausted hash chains. Considering that the number of

remaining elements in each hash chain may become very

different, we employ a partial key renewal strategy introduced

in [18].

In addition to the hash chain matrix, let the sender construct

a few backup hash chains off-line. We define a threshold T to

determine whether a key renewal is needed. When the number

of remaining elements of one or more columns in the hash

chain matrix become less than T , the sender will initiate a

partial key renewal process. The backup key elements, which

are the last elements of the backup hash chains, will be

sent out in the next outgoing group of packets. Here each

packet carries a copy of these elements for reliability. A key

updating command is also included in the packets, urging the

receivers to replace the elements of current public key from

those exhausted columns with the backup key elements they

received. The sender itself will also replace the corresponding

columns of the hash chain matrix with backup ones, and begin

to prepare new backup hash chains.

IV. SECURITY ANALYSIS

A. Security Level

We define the security level as the probability that an at-

tacker can successfully forge a signature, given the assumption

that an attacker cannot invert the one-way function f used in

the scheme. In our scheme, we require that each public key is

used exactly once, i.e., a public key will expire immediately

after it is used for verifying a signature. Then, the best an

attacker can do is to grab the newest group of packets, obtain

the signature which contains at most k elements of current

private key, and try to generate a forged group of packets

whose signature is a subset of exposed k elements before the

current public key expires. According to the analysis in [10],

the probability that an attacker is able to do so is at most

(k/t)k for an (l, k, t)-HORS scheme. For example, a suggested

parameter set k = 20 and t = 256 leads to a security level

at 2−73. Thus, signature forge can be considered as infeasible

for our scheme, given the perfect non-invertibility of f .

B. Denial-of-Service Attack

Denial-of-Service (DoS) attack is a notorious cyber-attack

which attempts to degrade system availability. In our scenario,

an attacker can initiate a DoS attack by simply flooding the

receivers with fake packets to interfere with regular signature

reconstruction process. Due to the nature of signature amorti-

zation, the receiver is not able to determine the authenticity of

a single packet independently. Therefore, if both fake packets

and authentic packets are received and mixed together, the

receiver cannot judge which ones should be used to reconstruct

the correct authentication information. Our scheme is resistant

to this kind of attack to some level. According to [19],

the original information, which is encoded into n segments

using a (n, m) Reed-Solomon code, can be recovered in the

presence of a altered pieces and b missing pieces as long as

2a + b ≤ n − m. That is, if we view the information carried

by the fake packets as “altered”, the receiver can successfully

reconstruct FG and SG with at most �(n−m)/2� such packets.

After SG is verified, all fake packets can be rejected by

checking FG.

V. NUMERICAL RESULTS

In this section, we present some numerical results to illus-

trate the performance of our scheme. All simulation parameters

are listed in Table I, along with their default values if not

otherwise specified in the context.

TABLE IDEFINITION OF PARAMETERS

Symbol Definition Default valuePL Packet loss probability 0.2PM Packet modification probability 0.2n Number of packets in a group 32m Number of packets required for decoding 16

(l, k, t) Parameters of HORS (80,20,256)L Length of hash chain 1024LH Length of hash output 20 (bytes)LS Length of signature 200 (bytes)

A. Key Usage Efficiency and Key Storage Cost

One benefit of our scheme is the high efficiency of key

usage, since the use of signature amortization and one-way

hash chains both increase key usage efficiency. To better

demonstrate this, define N0 as the number of packets which

can be authenticated using one hash chain matrix, we can

derive the upper bound of N0. Note that each signature will use

k elements from an L×t hash chain matrix, and n packets can

be authenticated using a single signature. Then, considering

all hash chains as equal likely to be selected for signature

generation, we have N0 ≤ Ltn/k. The default parameters give

an upper bound at 1024 ·256 ·32/20 ≈ 419430 packets. In the

worst case that one hash chain is always selected, we can still

have 1024 · 32/20 ≈ 1638 packets authenticated before a key

renewal process is triggered. Compared to another one-way

hash chain based scheme HORSE [12], our scheme further

increases N0 by a factor n.

With the default settings, the key storage cost at the sender

is 1024 · 256 · 80bits = 2.5MB. If a lower storage cost is

preferred in practice, the technique in [20] allows us to utilize

a hash chain of length L by storing at most log2 L hash values,

and performing at most log2 L hash evaluations to retrieve any

value in the chain. With this technique, the key storage cost can

be reduced to 25KB, with k log2 L = 20 ·10 = 200 additional

hash evaluations for each signature.

B. Communication Overhead

In this subsection, we derive the average communication

overhead Cp of our scheme, i.e., the size of authentication

information added to each packet. For every group of npackets, the authentication information consists of encoded FG

and SG. Before encoding, it is easy to see Size(FG) = nLH

and Size(SG) = LS . After encoding, the size of FG and SG

increases by a factor n/m. Then, the average communication

overhead for each packet can be calculated as

Cp =1

n(Size(FG) + Size(SG)) ∗ n

m=

nLh + LS

m

Fig. 3 shows the change of Cp as a function of m. Three

curves with different values of n are displayed.

In the figure, we can see that Cp decreases faster for a

smaller n. Also, since n packets need to be buffered for signing

operation at the sender side and at least m packets need to

be buffered for signature verification at the receiver side, we

may prefer a smaller (n, m) to reduce signing and verification

0 10 20 30 40 50 60 70 80 90 10020

30

40

50

60

70

80

90

100

110

m

com

mun

icat

ion

over

head

per

pac

ket (

byte

s)n = 128n = 64n = 32

Fig. 3. Average communication overhead

delay. However, since the error-correcting capability of Reed-

Solomon code is determined by n − m, a code with a

larger (n, m) is more robust against burst packet loss and

large-scale DoS attack. In practice, the tradeoff among delay,

communication overhead and robustness should be carefully

considered for different applications.

C. Authentication Probability

In this subsection, we evaluate the probability that a group

of packets can be successfully authenticated, in a hostile

environment where packet loss and forged packets may appear.

We compare the performance of our scheme with SAIDA

[16], which uses IDA to encode authentication information.

IDA is robust against packet loss, and it can be a few times

more computationally efficient than Reed-Solomon code that

we use, but it is easily subject to forged packets.

In our simulations, we assume that each packet is assigned

with a unique sequence number, ranged from 1 to n. Each

packet may be lost during transmission with probability PL.

For each sequence number, a modified packet with fake

authentication information may be sent out by an attacker

with probability PM , i.e., the receiver may get two packets

with the same sequence number. In the worst case, a fake

packet may be received, while the corresponding authentic

packet is lost. For SAIDA, the decoding strategy is to discard

all packets with repeated sequence numbers, and randomly

choose m packets from the rest to decode. If the number of

remaining packets is less than m, or at least one fake packet

is chosen for decoding, we will have a decoding failure. For a

fair comparison, we allow the receiver to retry Nr times since

IDA is more computationally efficient. Here Nr = 10 is used

in the simulations. As for our scheme, packets with repeated

sequence numbers will also be considered as “erasures” and

discarded. All remaining packets will be used for decoding.

The decoding failure occurs when the correct authentication

information cannot be reconstructed with these “erasures” and

modified packets.

Fig. 4 shows the authentication probability of two schemes

0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4

0.4

0.5

0.6

0.7

0.8

0.9

1

packet modification probability

auth

entic

atio

n pr

obab

ility

Reed−SolomonIDA

Fig. 4. Authentication probability versus packet modification probability

30 40 50 60 70 80 90 100 110 1200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

communication overhead per packet (bytes)

auth

entic

atio

n pr

obab

ility

Reed−SolomonIDA

Fig. 5. Authentication probability versus average communication overhead

under the same average communication overhead, with respect

to different values of PM . Fig. 5 shows the authentication

probability with increasing average communication overhead,

using default values of PL and PM . We can see that our

scheme outperforms SAIDA in both scenarios as expected,

due to the strong error-correcting capability of Reed-Solomon

code.

VI. CONCLUSIONS

Authentication is a critical security issue in many multicast

applications. In this paper, we propose a lightweight OTS

scheme for multicast authentication, based on signature amor-

tization technique. Unlike regular OTS schemes, our scheme

has a low average communication overhead and does not

rely on frequent distribution of public keys. Through the

numerical results, we show that our scheme can achieve a

higher authentication probability in a hostile environment,

compared with a similar scheme SAIDA. Since our scheme

incurs additional signing and verification delay, we believe

it will be most useful in situations where multicast data

without stringent real-time requirements need to be sent in

a bandwidth-limited environment.

REFERENCES

[1] L. Su, B. Ding, Y. Yang, T. Abdelzaher, G. Cao, and J. Hou, “Ocast:Optimal multicast routing protocol for wireless sensor networks,” in Pro-ceedings of 17th IEEE International Conference on Network Protocols(ICNP), 2009, pp. 151–160.

[2] W. Gao, Q. Li, B. Zhao, and G. Cao, “Multicasting in delay tolerantnetworks: a social network perspective,” in Proceedings of the 10th ACMinternational symposium on Mobile ad hoc networking and computing,2009, pp. 299–308.

[3] Q. Li and G. Cao, “Multicast authentication in the smart grid with one-time signature,” IEEE Transactions on Smart Grid, vol. 2, no. 4, pp.686–696, 2011.

[4] R. Rivest, A. Shamir, and L. Adleman, “A method for obtaining digitalsignatures and public-key cryptosystems,” Communications of the ACM,vol. 21, no. 2, pp. 120–126, Feb. 1978.

[5] T. El Gamal, “A public key cryptosystem and a signature scheme basedon discrete logarithms,” IEEE Transactions on Information Theory,vol. 31, no. 4, pp. 10–18, Jul. 1985.

[6] L. Lamport, “Constructing digital signatures from a one-way function,”Technical Report CSL-98, SRI International, Tech. Rep., 1979.

[7] M. Rabin, “Digitalized signatures,” in Foundations of secure computa-tion, Academic Press, 1978, pp. 155–166.

[8] R. Merkle, “A certified digital signature,” in Proceedings of Advancesin Cryptology (Crypto’89). Springer, 1990, pp. 218–238.

[9] A. Perrig, “The biba one-time signature and broadcast authenticationprotocol,” in Proceedings of the 8th ACM conference on Computer andCommunications Security. ACM, 2001, pp. 28–37.

[10] L. Reyzin and N. Reyzin, “Better than biba: Short one-time signatureswith fast signing and verifying,” in Proceedings of Australasian Con-ference on Information Security and Privacy (ACISP). Springer, 2002,pp. 144–153.

[11] C. Dods, N. Smart, and M. Stam, “Hash based digital signatureschemes,” Cryptography and Coding, pp. 96–115, 2005.

[12] W. Neumann, “Horse: an extension of an r-time signature scheme withfast signing and verification,” in Proceedings of International Conferenceon Information Technology: Coding and Computing (ITCC). IEEE,2004, pp. 129–134.

[13] Q. Wang, H. Khurana, Y. Huang, and K. Nahrstedt, “Time valid one-timesignature for time-critical multicast data authentication,” in Proceedingsof INFOCOM 2009. IEEE, 2009, pp. 1233–1241.

[14] M. Rabin, “Efficient dispersal of information for security, load balancing,and fault tolerance,” Journal of the ACM, vol. 36, no. 2, pp. 335–348,1989.

[15] M. Luby, M. Mitzenmacher, M. Shokrollahi, D. Spielman, and V. Ste-mann, “Practical loss-resilient codes,” in Proceedings of the 29th annualACM symposium on Theory of computing. ACM, 1997, pp. 150–159.

[16] J. Park, E. Chong, and H. Siegel, “Efficient multicast packet authenti-cation using signature amortization,” in Proceedings of the 2002 IEEESymposium on Security and Privacy. IEEE, 2002, pp. 227–240.

[17] A. Perrig, R. Canetti, D. Song, and J. Tygar, “Efficient and secure sourceauthentication for multicast,” in Proceedings of Network and DistributedSystem Security Symposium(NDSS), vol. 1, 2001, pp. 35–46.

[18] Y. Lin, S. Shieh, and W. Lin, “Lightweight, pollution-attack resistantmulticast authentication scheme,” in Proceedings of the 2006 ACMSymposium on Information, Computer and Communications Security.ACM, 2006, pp. 148–156.

[19] H. Krawczyk, “Distributed fingerprints and secure information disper-sal,” in Proceedings of the 12th ACM symposium on Principles ofdistributed computing. ACM, 1993, pp. 207–218.

[20] D. Coppersmith and M. Jakobsson, “Almost optimal hash sequencetraversal,” in Financial Cryptography. Springer, 2003, pp. 102–119.