Ultra Lightweight Multiple-time Digital Signature for the Internet of Things Devices

TL;DR

This paper introduces SEMECS, a lightweight, energy-efficient multiple-time digital signature scheme suitable for resource-constrained IoT devices, with proven security and practical implementation results.

Contribution

We propose SEMECS, a novel elliptic curve-based multiple-time signature scheme optimized for low-resource devices, with no EC operations at signing and verified security.

Findings

Up to 19x less battery consumption compared to SchnorrQ

Achieves optimal signature and key sizes without EC operations at signer

Successfully implemented and tested on 8-bit AVR microprocessor

Abstract

Digital signatures are basic cryptographic tools to provide authentication and integrity in the emerging ubiquitous systems in which resource-constrained devices are expected to operate securely and efficiently. However, existing digital signatures might not be fully practical for such resource-constrained devices (e.g., medical implants) that have energy limitations. Some other computationally efficient alternatives (e.g., one-time/multiple-time signatures) may introduce high memory and/or communication overhead due to large private key and signature sizes. In this paper, our contributions are two-fold: First, we develop a new lightweight multiple-time digital signature scheme called Signer Efficient Multiple-time Elliptic Curve Signature (SEMECS), which is suitable for resource-constrained embedded devices. SEMECS achieves optimal signature and private key sizes for an EC-based signature without requiring any EC operation (e.g., EC scalar multiplication or addition) at the signer. We prove SEMECS is secure (in random oracle model) with a tight security reduction. Second, we fully implemented SEMECS on 8-bit AVR microprocessor with a comprehensive energy consumption analysis and comparison. Our experiments confirm up to 19x less battery-consumption for SEMECS as compared to its fastest (full-time) counterpart, SchnorrQ, while offering significant performance advantages over its multiple-time counterparts in various fronts. We open-source our implementation for public testing and adoption.

Figures

Tables

Table 1. TABLE I : Signer-side performance of SEMECS  and its counterparts on 8-bit AVR microprocessor

Scheme	$K$	Signature Generation Time (CPU cycle)	Private Key (Byte)	Signature Size (Byte)	Computation energy (mJ)	Communication energy ($\mu$J)
Full-time signatures
SPHINCS [33]	$2^{\kappa }$	2 681 600 389	1088	41000	16760.00	6115.56
ECDSA [11]	$2^{\kappa }$	48 188 992	32	64	301.18	9.55
Ed25519 [17, 19]	$2^{\kappa }$	23 211 611	32	64	145.07	9.55
$\mu$Kummer [16, 20]	$2^{\kappa }$	10 404 033	32	64	65.03	9.55
SchnorrQ [18, 21]	$2^{\kappa }$	3 740 000	32	64	23.38	9.55
$K$-time signatures
HORS [26]	1	1 180 618	16	384	7.38	57.28
	$2^{17}$
HORSE [30]	1	1 180 618	16384	384	7.38	57.28
	$2^{17}$	19 644 106	278528		122.78
XMSS [31]	1	10 233 600	16	2080	63.96	310.25
	$2^{17}$	101 509 850		2592	634.44	386.62
Zaverucha et al. [28]	1	6 250 660	16	48	39.07	7.16
	$2^{17}$
SEMECS	1	195 776	32	32	1.22	4.77
	$2^{17}$

Table 2. TABLE II : Private/public key sizes, signature size and signature generation/verification costs of SEMECS  and its counterparts

Scheme	Signer			Verifier
	Private Key Size	Signature Size	Signature Generation	Public Key Size	Signature Verification
Full-time signatures
SPHINCS [33]	$n_S$	$n_S(k_S\left(\right|t_S|$ $-x_S+1)+2^{x_S})$	$\left(2t_S-1\right)\cdot H$	$n_S$	$(k_S(\left(\log t_S\right)-x_S+1)$ $+2^{x_S}-1)\cdot H$
ECDSA [11]	$\left|q\right|$	$2\left|q\right|$	$EMul$	$\left|q\right|$	$1.3\cdot EMul$
Ed25519 [17]	$\left|q\right|$	$2\left|q\right|$	$EMul$	$\left|q\right|$	$1.3\cdot EMul$
Kummer [16]	$\left|q\right|$	$2\left|q\right|$	$EMul$	$\left|q\right|$	$1.3\cdot EMul$
SchnorrQ [18]	$\left|q\right|$	$2\left|q\right|$	$EMul$	$\left|q\right|$	$1.3\cdot EMul$
$K$-time signatures
HORS [26]	$\kappa$	$\kappa \cdot u$	$\left(u+1\right)\cdot H$	$t\cdot \left|H\right|\cdot K$	$\left(u+1\right)\cdot H$
HORSE [30]	$\left(\kappa \cdot t\cdot lo{g}_2\left(K\right)\right)$	$\kappa \cdot u$	$\left(u\cdot lo{g}_2\left(K\right)+1\right)\cdot H$	$t\cdot \left|H\right|$	$\left(u+1\right)\cdot H$
XMSS [31]	$\kappa$	$\left(l+lo{g}_2\left(K\right)\right)$ $\cdot \left|H\right|$	$(((lo{g}_2\left(K\right)+2)\cdot (lo{g}_2\left(K\right)$ $+l\cdot (w+2)))/2+4\cdot lo{g}_2\left(K\right))\cdot H$	$(2(lo{g}_2\left(K\right)+lo{g}_2\left(l\right))$ $+1)\cdot |H|$	$(lo{g}_2\left(K\right)+l$ $\cdot (w+1))\cdot H$
Zaverucha et al. [28]	$\kappa$	$\kappa +\left|q\right|$	$\left(m/2\right)\cdot \left(Ad{d}_q+H\right)$	$m\cdot \left|q\right|\cdot K$	$1.3\cdot EMul$
SEMECS	$\left|q\right|$	$\left|q\right|$	$2\cdot H+Mu{l}_q+Su{b}_q$	$\left(2K+1\right)\cdot \left|q\right|$	$1.3\cdot EMul$

Table 3. TABLE III : Experimental performance comparison of SEMECS  and its counterparts on a commodity hardware

Scheme	$K$	Signature Generation Time (CPU cycle)	Private Key$\P$ (Byte)	Signature Size (Byte)	Signature Verification Time (CPU cycle)	Public Key$‡$	End-to-End Delay (CPU cycle)
Full-time signatures
SPHINCS [33]	$2^{\kappa }$	37 466 005	1088	41000	1 051 562	1056	38 517 567
ECDSA [11]	$2^{\kappa }$	1 510 320	32	64	1 932 650	32	3 442 970
Ed25519 [17]	$2^{\kappa }$	146 620	32	64	286 750	32	433 370
Kummer [16]	$2^{\kappa }$	58 450	32	64	98 560	32	157 010
SchnorrQ [18]	$2^{\kappa }$	30 481	32	64	54 241	32	84 722
$K$-time signatures
HORS [26]	1	16 823	16	384	8 975	32 KB	25 798
	$2^{17}$					4 GB
HORSE [30]	1	16 823	16384	384	8 975	32 KB	25 798
	$2^{17}$	280 247	278 528				287 503
XMSS [31]	1	137 856	16	2080	115 239	416	253 095
	$2^{17}$	1 367 431		2592	120 983	1504	1 488 414
Zaverucha et al. [28]	1	89 180	16	48	52 872	4160	142 052
	$2^{17}$					520 MB
SEMECS	1	2 425	32	32	52 872	96	55 297
	$2^{17}$					8 MB

Equations

$${Adv}_{\text{SGN}}^{EU\text{mathchar}45CMA}(\mathcal{A})=Pr[{Expt}_{\text{SGN}}^{EU\text{mathchar}45CMA}(\mathcal{A})=1].$$

$${Adv}_{\text{SGN}}^{EU\text{mathchar}45CMA}(t,K^{\prime },K)=\underset{\mathcal{A}}{\max }\{Ad{v}_{\text{SGN}}^{EU\text{mathchar}45CMA}(\mathcal{A})\},$$

$${Adv}_G^{DL}(\mathcal{A})=Pr[{Expt}_G^{DL}(\mathcal{A})=1].$$

$${Adv}_G^{DL}(t)=\underset{\mathcal{A}}{\max }\{{Adv}_G^{DL}(\mathcal{A})\},$$

$$R_j\equiv Y^{e_j}\cdot {\alpha }^{s_j}\mathrm{mod}p,$$

$$R_j\equiv Y^{{e_j}^{\ast }}\cdot {\alpha }^{s_j^{\ast }}\mathrm{mod}p,$$

$$r_j$$

$${Adv}_{\text{ETA}}^{EU\text{mathchar}45CMA}(t,K^{\prime },K)$$

$$Pr[{\overrightarrow{A}}_{real}=\overrightarrow{a}]$$

Full text

In this paper, our contributions are two-fold: First, we develop a new lightweight multiple-time digital signature scheme called Signer Efficient Multiple-time Elliptic Curve Signature (SEMECS), which is suitable for resource-constrained embedded devices. SEMECS achieves optimal signature and private key sizes for an EC-based signature without requiring any EC operation (e.g., EC scalar multiplication or addition) at the signer. We prove SEMECS is secure (in random oracle model) with a tight security reduction. Second, we fully implemented SEMECS on 8-bit AVR microprocessor with a comprehensive energy consumption analysis and comparison. Our experiments confirm up to 19$\times$ less battery-consumption for SEMECS as compared to its fastest (full-time) counterpart, SchnorrQ, while offering significant performance advantages over its multiple-time counterparts in various fronts. We open-source our implementation for public testing and adoption. ††$\copyright$ 2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.

I Introduction

Resource-constrained devices (e.g., low-end sensors, smart-cards, RFID-tags) play an important role in emerging ubiquitous systems like Internet of Things and Systems (IoTS) and Wireless Sensor Networks (WSNs). Using service oriented architecture (SOA) further broadens the horizons of IoTS, opening up many applications where resource-constrained devices can participate as service consumers and/or providers. [1, 2, 3] It is vital for such systems to operate securely and efficiently. Hence, it is necessary to provide authentication and integrity for resource-constrained devices. For instance, guaranteeing the integrity and authentication of financial transactions in a smart-card or RFID-tag is critical for any commercial application. However, this is a challenging task due to the memory, processor, bandwidth and battery limitations of these devices.

It is also important to be able to publicly verify the authentication tags produced by resource-constrained devices. This enables any resourceful device (e.g., a laptop or a base station) to publicly audit transactions and system status.

Symmetric cryptography primitives such as Message Authentication Codes (MACs) are computationally efficient and therefore are preferred for resource-constrained devices in small-scale systems. However, such primitives are not scalable for large-distributed systems and are not publicly verifiable [4, 5]. They also cannot achieve the non-repudiation property, which is necessary for various applications (e.g., transportation payment systems, medical implants, logical/physical access with tiny devices) that may need public auditing.

Digital signatures rely on public key infrastructures for the signature verification [6, 7]. They are publicly verifiable, scalable for large systems and achieve non-repudiation. Therefore, they are highly useful authentication tools for security-critical applications such as medical devices, payment systems, secure auditing in embedded devices and security systems (e.g., building access control). However, existing digital signatures also have some limitations that might prevent them to be fully practical for highly resource-constrained devices.

In the following, we first briefly discuss some prominent digital signature alternatives and their limitations when employed on resource-limited devices. We then present our contributions by summarizing the desirable properties of our scheme, followed by its limitations.

I-A Limitations of Signer Efficient Signatures

The existing digital signature alternatives do not offer small private key size, small signature size, and high efficiency at the signer, at the same time. We elaborate on some of these alternatives below.

Traditional Signatures: RSA [8], one of the most well-known signature schemes, is computationally efficient at the verifier’s side. However, it requires an expensive operation111We refer to operations such as modular exponentiation [6], elliptic curve scalar multiplication [9] or pairing [10] as expensive operations. at the signer’s side and have large key/signature sizes. Hence, it may not be suitable for resource-constrained embedded devices (e.g., medical implants).

Elliptic Curve (EC) based schemes are highly popular on such devices due to their small key and signature sizes, along with better efficiency compared to RSA [11, 12, 13]. Various different curves, and signature schemes on these curves have been proposed, which offer improved computational efficiency and security [14, 15, 16, 17, 18]. Some of these curves are also implemented in embedded devices [19, 20, 21] such as 8-bit AVR microprocessors. However, these signature schemes still require an expensive operation (i.e., EC scalar multiplication) at the signer’s side. This requirement may hinder an efficient adoption of these schemes to low-end microprocessors with critical battery limitations (e.g., medical implants).

Online/Offline Signatures: Many techniques have been proposed to improve the efficiency of traditional signatures. These include online/offline signatures that eliminate expensive operations in signature generation via pre-computed tokens generated offline [22, 23]. Although these schemes are computationally efficient, they incur large storage overhead to the signer. Later, Shamir et al. in [24] proposed an improved online/offline signature that is more space efficient. However, by nature, these schemes require linear storage with respect to the number of signatures that can be generated, which is impractical for storage-limited signers.

One-time Signatures (OTSs): These schemes rely on one-way functions without trapdoors and offer very efficient computations [25, 26, 27]. Specifically, Lamport [25] proposed the first one-time signature scheme, where for each bit of the hash of the message, two hash outputs were stored as the public key that resulted in a very large size. Then, in HORS signature scheme [26], special message encoding techniques have been considered to significantly reduce the public while preserving the computational efficiency. Hash-based schemes also offer post-quantum security that is lacked in most of the traditional signatures. On the other hand, they have a large signature and very large public key sizes. Some EC-based OTSs also exist [28] that offer small signature size, but with a trade-off between private key size and signature generation efficiency. Moreover, in OTSs, a private/public key pair can be used only once. This may require costly private key generations at the resource-limited device for each message to be signed.

Multiple-time Signatures: For these schemes, after $K$ signatures, the key pair must be re-generated. Therefore, we refer to these schemes as $K$-time signatures. Inherently, OTSs (e.g., Lamport [25], HORS [26]) can be used as $K$-time signatures if $K$ key pairs are generated at the key generation phase. Some hash-based multiple-time signatures were proposed [29, 30, 31, 32] based on HORS signature [26]. However, these schemes either suffer from large key/signature sizes [29, 30, 31], or provide security only for a short-limited amount of time [32]. Some stateless hash-based schemes were also proposed [33], extending these multiple-time signatures to full-time (traditional) signature schemes. Although it is shown that they can be implemented on resource-constrained devices [34], it is highly computationally costly at the signer’s side, and it also requires the transmission of large signatures (e.g., up to 41 KB).

Our proposed scheme also falls into this category and inherits some of the limitations of $K$-time signatures (e.g., after $K$ signatures, the key must be re-generated). However, due to the unique construction of our scheme that leverages Fiat-Shamir transform with compact and efficient elliptic curves, it offers the highest signer efficiency among all the aforementioned $K$-time signatures (including the use of OTSs as $K$-time signatures). For instance, as shown in Table I, our scheme outperforms HORS [26] (most efficient counterpart) $6\times$ at signature generation and $12\times$ at signature size on an 8-bit microprocessor.

Lattice-based and Code-based Signatures: The main advantage of these schemes is post-quantum security. Although some of these schemes offer computational efficiency, they are still relatively computationally expensive (e.g., require heavy operations such as Gaussian Sampling [35]) and key/signature sizes might be prohibitive for resource-constrained devices [35, 36, 37, 38, 39]. Since these schemes provide long-term security (security against quantum attackers), they might be ideal for resource-constrained devices in the future, if the sizes are reduced.

There is a need for a signer efficient digital signature that prioritizes the signer efficiency by achieving optimal private key and signature sizes without requiring any expensive operations for the signature generation.

I-B Our Contribution

In this paper, we create a new multiple-time signature scheme, which we refer to as S**igner Efficient Multiple-time Elliptic Curve Signature (SEMECS). We summarize some desirable properties of SEMECS below. A detailed performance analysis is given in Section V.

$\bullet$ High Computation & Energy Efficiency at the Signer: SEMECS only requires two hash function calls, a single modular multiplication, and a modular subtraction to generate a signature. Therefore, its cost is even comparable to symmetric hash-based MACs that are not suitable for large and distributed systems. SEMECS offers very fast signature generation, (1.23 microseconds on an i7 Skylake processor). On a resource-constrained processor, this translates into high energy efficiency. Our experiments confirmed that SEMECS signature generation has 6$\times$ lower energy consumption compared to its closest counterpart and 118$\times$ lower than Ed25519 [17, 19] on 8-bit AVR microprocessor (see Table I).

$\bullet$ Compact Private Key & Signature: SEMECS only requires storing a 32-byte private key (that can be derived from a 16-byte seed with a PRF) and incurs an additional 32 Bytes to the message as the signature, for $\kappa=128$-bit security level. SEMECS has two signature components of 32 Bytes, where one of them is used to recover the first 32 Bytes of the message. Therefore, the transmission overhead is just 32 Bytes, that is optimal for EC-based digital signatures (as in BLS [12]). Thus, SEMECS is also lightweight in terms of signer storage and transmission. Due to its small signature size, SEMECS is also very energy efficient in terms of communication, in addition to its high energy efficiency in signer computation. Moreover, since SEMECS does not require any EC operation at the signer’s side, the signer does not need to store any curve parameters and codes. This is specifically important for resource-constrained devices that have limited space for the code (e.g., AVR ATmega 2560 has 256 KB).

$\bullet$ Open-source Implementation and Comprehensive Analysis: We fully implemented SEMECS on a laptop and the signature generation of SEMECS on an 8-bit AVR microprocessor. We open-sourced all of our implementations for broad testing, benchmarking and adoption purposes. We also analyzed and compared the efficiency of SEMECS with a wide variety of efficient signature schemes (see Section V) on both platforms.

$\bullet$ Provable Security with a Tight Reduction: We prove that SEMECS is existentially unforgeable against chosen-message attacks in Random Oracle Model (ROM) [40]. In Section IV, we show that SEMECS has a tight reduction to the Discrete Logarithm Problem (DLP), without the need for the forking lemma [41], as Fiat-Shamir type signatures do. In our security analysis, we exploit the fact that SEMECS is a multiple-time signature, and therefore it has higher security for a limited number of queries (as the nature of multiple-time signatures).

All the above properties show that SEMECS is potentially an ideal alternative to provide authentication and integrity for resource-constrained devices.

Differences of this work with its preliminary version appeared in WiSec 13’ [42]: (i) In this work, we developed a new signature scheme that we refer to as SEMECS that reduces the signature/private key size of our preliminary scheme ETA [42], and thereby achieves optimal signature and key sizes for an EC-based signature scheme. Moreover, SEMECS generates private key components deterministically, and therefore offers improved security against weak pseudo-random number generators. (ii) In this work, we provided a full-fledged open-source implementation of SEMECS on 8-bit AVR ATmega 2560 microprocessor with a comprehensive energy consumption analysis and comparison. We also gave comprehensive performance comparison of SEMECS with some of the most recent and efficient digital signatures (including but not limited to Ed25519 [17], SchnorrQ [15, 18], SPHINCS [33], XMSS [31], HORS [26]). (iii) In this work, we provided an improved security proof that achieves a significantly tighter security reduction compared to that of ETA.

Limitations: Despite all its merits, SEMECS also has its limitations that are inherent to multiple-time signatures: (i) It can sign up to a pre-determined $K$ messages, but then needs to be bootstrapped. (ii) It is a stateful signature scheme. (iii) In SEMECS, the public key size is linear with respect to $K$. This requires verifiers to be storage resourceful.

Potential Use-cases: Remark that for our envisioned applications, the signer computational/storage/communication efficiency is much more important than the verifier storage efficiency alone. Furthermore, these applications permit verifiers to be storage resourceful (e.g., a cloud server for medical systems, base stations in WSNs, control centers in cyber-physical systems). Similarly, it is feasible to perform the key generation phase offline in these applications. In the following, we discuss some of the potential applications for SEMECS.

Medical implants are equipped with resource-constrained microprocessors (e.g., 8-bit AVR [43], as we used in our experiments) that need to report sensitive data to doctors, hospital servers, etc. Symmetric key authentication (MACs) is usually preferred for these systems. However, these mechanisms lack non-repudiation, and public verification that are highly desirable for some medical systems, because of digital forensics and legal issues [44, 45]. Thus, there is a need for low-cost public key primitives (e.g., authentication) for these systems [46]. SEMECS can be considered as an ideal alternative for medical implants due to its signer efficiency. Our experiments on 8-bit AVR showed that SEMECS consumes less energy compared to its counterparts. In practice, this translates into a longer battery life that is critical for medical implants.

Additionally, SEMECS is highly suitable to provide authentication for SOA based IoT systems. SOA based IoT infrastructures are comprised of networked, resource-constrained devices [1, 2] that require efficient authentication mechanisms. Some essential applications of SOA based IoT includes but not limited to e-health, smart product management and smart events for emergency management [2, 47, 48]. Similarly with medical implants, non-repudiation and public verification are critical for these applications. Moreover, a server (or a broker - i.e., coordinators that operate between the server and the devices) is usually utilized the connected resource-constrained devices to provide these services [3]. Servers and brokers are usually equipped with higher-end processors, compared to the IoT devices, that has expandable memories. Therefore, in such SOA based IoT applications, we believe that the server or broker can tolerate the storage of a larger public key in exchange of a significantly higher signer efficiency that translates into longer battery life for resource-constrained devices.

Many secure WSN protocols such as clone detection [49], secure code dissemination [50] and secure logging [51] include a low-end signer that reports to resourceful servers, and base stations. SEMECS can substantially increase the lifespan of WSNs by serving as the authentication mechanism for such protocols. Moreover, SEMECS can be deployed in some token-based logical/physical access control systems.

II Preliminaries

In this section, we first give our notation and definitions. We then describe our system and security models.

II-A Definitions and Algorithms

Notation. $||$ denotes the concatenation operation. $|r|$ denotes the bit length of variable $r$. r\stackrel{{\scriptstyle\}}{{\leftarrow}}\mathcal{S}$denotes that variable$r$is randomly and uniformly selected from set$\mathcal{S}$. We denote by${0,1}^{}$the set of binary strings of any finite length.$\mathcal{A}^{\mathcal{O}{0},\ldots,\mathcal{O}{i}}(\cdot)$denotes algorithm$\mathcal{A}$is provided with oracles$\mathcal{O}{0},\ldots,\mathcal{O}{i}$. For example,$\mathcal{A}^{\mathit{SGN.Sig}{\mathit{sk}{}}}(\cdot)$denotes that algorithm$\mathcal{A}$is provided with a *signing oracle* of signature scheme$\mathit{SGN}$under a private key$\mathit{sk}$.$H{i}:{0,1}^{}\rightarrow\mathbb{Z}_{q}^{*},i\in{0,1}are distinct Full Domain Hash Functions [[52](#bib.bib52)], whereq$ is a large prime.

Definition 1

A $K$-time signature scheme SGN is comprised of a tuple of three algorithms $(\mathit{Kg},$ $\mathit{Sig},\mathit{Ver})$ defined as follows:

$(\mathit{sk}{},\mathit{PK}{})\leftarrow\texttt{SGN.Kg}{}(1^{\kappa},K)$,: The key generation algorithm takes the security parameter $1^{\kappa}$ and the maximum number of messages to be signed $K$ as the input. It returns a private/public key pair $(\mathit{sk}{}_{0},\mathit{PK}{})$ as the output. 2. -

$\sigma_{j}\leftarrow\texttt{SGN.Sig}{}(\mathit{sk}{}_{j},M_{j})$: The signature generation algorithm takes the private key $\mathit{sk}{}_{j},~{}0\leq j\leq K-1$ and a message $M_{j}$ to be signed as the input. It returns a signature $\sigma_{j}$ on $M_{j}$ as the output, and then updates $\mathit{sk}{}_{j}$ to $\mathit{sk}{}_{j+1}$. 3. -

$b\leftarrow\texttt{SGN.Ver}{}(\mathit{PK}{},M_{j},\sigma_{j})$: The signature verification algorithm takes $\mathit{PK}{}$, message $M_{j}$ and its corresponding signature $\sigma_{j},~{}0\leq j\leq K-1$ as the input. It returns a bit $b$, with $b=1$ meaning valid, and $b=0$ otherwise.

SEMECS, and its preliminary version ETA in [42], are inspired from the Schnorr signature scheme [13], which is described in the algorithm below.

II-B Models

We give our system and security models as below.

System Model: There are two types of entities in the system.

Resource-constrained Signers: Signers are storage, computational, bandwidth and power limited devices (e.g., medical implants, wireless sensors, RFID-tags). The objective of SEMECS is to minimize the cryptographic overhead of signers. 2. 2.

Resourceful Verifiers: Storage resourceful verifiers (e.g., a laptop, base station) that can be any (untrusted) entity.

We assume that the key generation/distribution is performed offline before deployment. For instance, a key generation center can generate private/public keys and distribute them to each entity in the system. Otherwise, the signer can also perform the key generation, before deployment, when it does not have any battery limitations.

Security Model: A standard security notion for a signature scheme is Existential Unforgeability under Chosen Message Attack ($\mathit{EU}\mathchar 45\relax\mathit{CMA}$) [53]. We define $K$-time EU-CMA experiment (in random oracle model [40]) for SGN as below. In this experiment, Adversary $\mathcal{A}$ is provided with two oracles: (i) A random oracle $\mathit{RO}(.)$ from which $\mathcal{A}$ can request the hash of any message $M$ of their choice up to (polynomially unbounded) $K^{\prime}$ messages. (ii) A signing oracle $\texttt{SGN.Sig}{}_{sk}(.)$ from which $\mathcal{A}$ can request a SGN signature on any message $M$ of their choice up to (pre-determined constant) $K$ messages.

Definition 2

EU-CMA experiment for SGN is as follows:

Experiment $\mathit{Expt}_{\texttt{SGN}{}}^{\mathit{EU}\mathchar 45\relax\mathit{CMA}{}}(\mathcal{A})$

1. $(sk_{0},PK)\leftarrow\texttt{SGN.Kg}{}(1^{\kappa},K)$,
2. $(M^{*},\sigma^{*})\leftarrow\mathcal{A}^{\mathit{RO}(.){},\texttt{SGN.Sig}{}_{sk}(.)}(PK)$,
3. If $\texttt{SGN.Ver}{}(PK,M^{*},\sigma^{*})=1$ and $M^{*}$ was not queried to SGN.Sig, return $1$, else, return [math].

The EU-CMA-advantage of $\mathcal{A}$ is defined as

[TABLE]

The EU-CMA-advantage of SGN is defined as

[TABLE]

where the maximum is over all $\mathcal{A}$ having time complexity $t$, making at most $K^{\prime}$ queries to $\mathit{RO}(.)$ and at most $K$ queries to SGN.

The security of SEMECS relies on the intractability of Discrete Logarithm Problem (DLP) [53], which is defined below.

Definition 3

Given a cyclic group $G$ of order prime $q$ and a generator $\alpha$ of $G$, let $\mathcal{A}$ be an algorithm that returns an element of $\mathbb{Z}_{q}^{*}$. Consider the following experiment:

Experiment $\mathit{Expt}_{G}^{\mathit{DL}{}}(\mathcal{A})$

1. y\stackrel{{\scriptstyle\}}{{\leftarrow}}\mathbb{Z}_{q}^{*}$,
2. $Y\leftarrow\alpha^{y}\bmod p$,
3. $y^{\prime}\leftarrow\mathcal{A}(Y)$,
4. If $\alpha^{y^{\prime}}\bmod p=Y$, return $1$, else, return [math].

The DL-advantage of $\mathcal{A}$ in this experiment is defined as

[TABLE]

The DL-advantage of $(G,\alpha)$ in this experiment is defined as

[TABLE]

where the maximum is over all $\mathcal{A}$ having time complexity $t$.

III The Proposed Scheme

Some DLP-based signatures (e.g., ECDSA [22], Schnorr [13]) can eliminate expensive operations from the signature generation by pre-computing the component $R=\alpha^{r}\bmod p$ for a random r\stackrel{{\scriptstyle\}}{{\leftarrow}}\mathbb{Z}_{q}^{*}{}$during the key generation. The signer stores$(r,R)$ and then use them to compute signatures during the online phase, without any expensive operation. However, this approach incurs linear storage to the signer’s side (i.e., one token per message).

It is highly desirable to construct a multiple-time signature scheme, which has constant signer storage and yet avoids expensive operations. However, this is a challenging task due to the nature of the aforementioned schemes. That is, in these schemes, the token $R$ is directly used during the signature computation and therefore its storage cannot be trivially off-loaded to the verifier’s side. This forces the signer either to store or to compute a token for each message.

III-A Preliminary Scheme: Efficient and Tiny Authentication

In our preliminary work Efficient and Tiny Authentication (ETA) [42], we designed a signature scheme that can shift the storage of ephemeral public keys to the verifier’s side without disrupting the security and verifiability of signatures. We outline our preliminary scheme ETA in Algorithm 2 for the sake of completeness.

In the following, we focus on our newly proposed SEMECS digital signature scheme and also highlight the differences between ETA and our improved scheme SEMECS.

III-B Signer Efficient Multiple-time Elliptic Curve Signature (SEMECS)

We first discuss the challenges of eliminating ephemeral keys from the signature generation in Schnorr-like signatures, which is an important step to achieve signer optimal elliptic curve signatures. We then explain our strategies in SEMECS towards addressing these challenges.

III-B1 Challenges of Removing Ephemeral Key from Signature Generation

In Schnorr-like signatures [11, 17, 18], an expensive operation is required to compute the ephemeral key (R=\alpha^{r}\bmod p,r\stackrel{{\scriptstyle\}}{{\leftarrow}}\mathbb{Z}_{q}^{*}{})$. This ephemeral key is an essential part of the signature generation and proof of security, and therefore it is a challenging task to remove it from signing without disrupting the security. For example,$R$is committed to the signature as$s\leftarrow{}r-H(M||R)\cdot y\bmod q$ in Schnorr signatures [13]. The ephemeral key enables programming of random oracle and also used in Forking Lemma [41] in the security proof of Schnorr-like signatures [17, 18].

III-B2 Eliminating Expensive Operations from Signature Generation

We first pre-compute $K$ ephemeral keys as $r_{j}\leftarrow{}H_{0}(y||j)$, $R_{j}\leftarrow{}\alpha^{r_{j}}\bmod p$ and store their hash commitments at the verifier as $\beta_{j}\leftarrow{}H_{1}(R_{j})$ for $j=0,\ldots,K-1$ (Steps 3-7 in Algorithm 3 SEMECS.Kg). This permits the derivation of $r_{i}$ to be used in signature $s_{j}$ deterministically without requiring any expensive operation, which will later to be verified by its corresponding $\beta_{j}$. Since $R_{j}$ is not required in the signature generation, we avoid expensive operations, but only rely on a few hash calls and a single modular addition/multiplication.

Our next step is to ensure that the correctness and provable security are still achieved in the absence of the ephemeral key in the signature generation. In ETA [42], we mimicked the role of $R_{j}$ in $e_{j}$ by replacing it with a random number $x_{j}\leftarrow{}\{0,1\}^{\kappa}$ as $e_{j}\leftarrow{}H(M_{j}||j||x_{j})$ (Steps 1-2 in Algorithm 2 ETA.Sig). However, this requires the explicit transmission of an extra $\kappa$-bit randomness and therefore is not optimal in terms of signature size. Moreover, this random number must be generated online, so requires a strong random number generator to be present in a low-end device.

In the following (Section III-B3), we first outline how SEMECS improves the signature generation of ETA by reducing the private key and signature sizes. We then elaborate on how SEMECS achieves the correctness and a tight security reduction in Section III-B4.

III-B3 Achieving Compact Key and Signature Sizes

Our idea is to embed randomness into the message itself by creating a “randomized message recovery” strategy, thereby avoiding an explicit transmission of randomness.

We first split message $M_{j}$ into two pieces as $(\overline{M}_{j}||\widetilde{M}_{j})$ such that $|\overline{M}_{j}|=|q|$ and $\widetilde{M}_{j}$ is the rest of message. If $|M_{j}|<|q|$ then we simply set $\overline{M}_{j}=M_{j}$ and $\widetilde{M}_{j}=0$ (Steps 1-2 in Algorithm 3 SEMECS.Sig). We then deterministically derive $z_{j}\leftarrow{}H_{1}(y||j)$, generate a randomness as $c_{j}\leftarrow{}\overline{M}_{j}\oplus z_{j}$ and compute the hash of the message as $e_{j}\leftarrow{}H_{0}(c_{j}||\widetilde{M}_{j})$. Finally, we compute $s_{j}\leftarrow{}r_{j}-e_{j}\cdot y\bmod q$ (Step 7 in Algorithm 3 SEMECS.Sig).

Our signature $\sigma_{j}$ on $M_{j}$ is $\sigma_{j}=(s_{j},c_{j})$, where the sender transmits $(\sigma_{j},\widetilde{M}_{j})$ to the receivers. Remark that, we only transmit $c_{j}$ that carries $|q|$-bit part of the message since $c_{j}\leftarrow{}\overline{M}_{j}\oplus z_{j}$. Therefore, the only component of the signature that introduces cryptographic transmission overhead is $s_{j}\in\mathbb{Z}_{q}^{*}$, which is optimal for an elliptic curve based signature scheme222$c_{j}$ does not offer confidentiality. After $\sigma_{j}=(s_{j},c_{j})$ is released, the message and $z_{j}$ are publicly recovered to permit signature verification.. This is as small as some of the most compact signatures (e.g., BLS [12]) but without requiring expensive operations at the signer’s side. Morever, it is also smaller than SchnorrQ [15, 18] and ETA [42] that transmit $e_{j}$ and $x_{j}$, respectively, as an extra information on top of $s_{j}$.

SEMECS achieves a small private key $y\in\mathbb{Z}_{q}^{*}$, which is identical to that of traditional Schnorr-like signatures [11, 17, 18] and only a half of the size that of ETA’s private key. The small and constant private key size is achieved by generating the random values with a deterministic function (e.g., a hash function) just using a seed value ($y$). Therefore, the signer doesn’t need to store all the random values generated at key generation, but only stores the seed and deterministically derives all random values from it (SEMECS.Sig Step 3-4). Moreover, unlike ETA, SEMECS signature generation does not require any fresh randomness and therefore avoids potential hurdles of weak pseudo-random number generators on the signer device [54, 55].

III-B4 Signature Verification and Tight Security Reduction

The verifier first checks the range of randomness $c_{j}\in\mathbb{Z}_{q}^{*}$ and the limit on number of permitted signatures. The verifier then computes $R_{j}^{\prime}\leftarrow{}Y^{H(c_{j}||\widetilde{M}_{j})}\cdot\alpha^{s_{j}}$ and checks whether it matches with $\beta_{j}=H_{1}(R_{j}^{\prime})\in\mathit{PK}{}$. If it does not hold, the verifier returns $b=0$. Otherwise, the verifier returns $b=1$ and uses auxiliary value $\gamma_{j}$ to recover the $q$-bit piece of message $\overline{M}_{j}$ from $c_{j}$ as $\overline{M}_{j}\leftarrow{}\gamma_{j}\oplus H_{0}(R_{j}^{\prime})\oplus c_{j}$ forming the original message as $M_{j}=(\overline{M}_{j}||\widetilde{M}_{j})$.

Note that the verifier should either know which public key component ($\beta_{j}$) it should use at SEMECS.Ver Step 2 or have a simple search operation among all $\beta$s to see if there is one that matches the calculated $H_{1}(R_{j}^{\prime})$. Therefore, there is a trade-off between a verifier computation and transmission overhead. However, both of these costs are almost negligible. Since $j$ is a value up to $K$ ($K=2^{17}$ in our experiments), the transmission of it only incurs 2-3 Bytes of extra overhead. If the verifier computation is preferred, this only adds an overhead of a binary search operation, that has a complexity of $log_{2}(K)$. In the binary search option, we basically assume that the verifier stores the public key sorted, and after the value $H_{1}(R_{j}^{\prime})$ is calculated, binary search is made on sorted $\beta$s.

We now elaborate the design rationale behind the use of two separate verification tokens $(\beta_{j},\gamma_{j})$ in SEMECS, as opposed to only one token $v_{j}$ in ETA, for $j=0,\ldots,K-1$.

(i) In Schnorr-like schemes, the randomness incorporated into message hashing is released with $s_{j}$ but not before. This is useful to construct an indistinguishable simulation in the security proof of Schnorr-like signatures333 In our security proof for SEMECS in Theorem 1, the simulator $\mathcal{F}$ programs random oracle $\mathit{RO}(.)$ such that the probability that adversary $\mathcal{A}$ querying $\mathit{RO}(.)$ on $c_{j}||M_{j}$ before querying it to the signature oracle $\texttt{SEMECS.Sig}{}_{sk}$ is as difficult as random guessing $c_{j}\in\mathbb{Z}_{q}^{*}$. Hence, the probability that simulator $\mathcal{F}$ aborts during the query phase is negligible in terms of $\kappa$ (see success probability analysis in Theorem 1). . In SEMECS, $c_{j}$ that randomizes the message hash as $H_{0}(c_{j}||\widetilde{M}_{j})$, is computed from $z_{j}$ as $c_{j}\leftarrow{}\overline{M}_{j}\oplus z_{j}$. Our idea is to store $z_{j}$ at the verifier’s side as $\gamma_{j}\leftarrow{}z_{j}\oplus H_{0}(R_{j})$ so that it can be recovered only after $s_{j}$ is released. We avoid an online transmission of $z_{j}$ but yet randomize the message hash via $c_{j}$ including $q$-bit part of the message $\overline{M}_{j}$ (with no extra transmission overhead). After $\sigma_{j}=(c_{j},s_{j})$ is released, the verifier computes $z_{j}$ from $\gamma_{j}$ via $H_{0}(R_{j})$. Note that $\beta_{j}=H_{1}(R_{j})$ does not reveal $z_{j}$ but yet permits the verification of $R_{j}^{\prime}\leftarrow{}Y^{H_{0}(c_{j}||\widetilde{M}_{j})}\cdot\alpha^{s_{j}}\bmod p$.

(ii) In SEMECS, we present an improved security proof with a reduction to DLP with a much tighter bound compared to that of ETA. The security of ETA is reduced to Schnorr signatures, whose security proof relies on Forking Lemma [41]. Intuitively, if there is an adversary $\mathcal{A}$ making at most $K^{\prime}$ $\mathit{RO}(.)$ queries, and forging signatures with probability $\epsilon$, then the Forking Lemma states that one can compute discrete logarithms with constant probability by rewinding the forger $O(K^{\prime}/\epsilon)$ times. Therefore, the security reduction loses a factor $O(K^{\prime})$ that can be very large [56].

Our key observation is that, since SEMECS is a $K$-time signature with pre-determined ephemeral public keys, we can avoid using Forking Lemma and obtain a reduction to DLP. That is, the hash of ephemeral keys are committed at the key generation phase as $\{\beta_{j}\}_{j=0}^{K-1}\in\mathit{PK}{}$. At the forgery phase, if $\mathcal{A}$ outputs a forgery on $\mathit{PK}$ as $(M^{*},$ $\sigma^{*})$, where $\sigma^{*}=(s_{j}^{*},c_{j}^{*}),~{}0\leq j\leq K-1$, by validity condition, this forgery has to be on a $\beta_{j}\in\mathit{PK}{}$. Therefore, $\mathcal{F}$ can extract private key $y$ without a need of rewinding $\mathcal{A}$ . This permits us to avoid a large factor of $O(K^{\prime})$ but only need a small constant factor $O(K)$ in our security reduction. We stress that this is possible due to special $K$-time nature of SEMECS, but it does not apply to polynomially unbounded Schnorr signature variants as proven in [56].

The detailed description of SEMECS is given at Algorithm 3 and further outlined in Figure 1.

IV Security Analysis

We prove that SEMECS is a $K$-time EU-CMA signature scheme in Theorem  1 (in the random oracle model [40]). We ignore terms that are negligible in terms of $\kappa$.

Theorem 1

$\mathit{Adv}_{\texttt{SEMECS}{}}^{\mathit{EU}\mathchar 45\relax\mathit{CMA}{}}(t,K^{\prime},K){}\leq\mathit{Adv}_{G}^{\mathit{DL}{}}(t^{\prime}){}$, where $t^{\prime}=O(t)+(2K)\cdot O(\kappa^{3})+(6K+K^{\prime})\cdot\texttt{RNG}{}$.

Proof: Let $\mathcal{A}$ be a SEMECS attacker. We construct a DL-attacker $\mathcal{F}$ that uses $\mathcal{A}$ as a sub-routine. That is, we set (y^{\prime}\stackrel{{\scriptstyle\}}{{\leftarrow}}\mathbb{Z}_{q}^{*}{},Y^{\prime}\leftarrow{}\alpha^{y^{\prime}}\bmod p)$as defined in$\mathit{DL\mathchar 45\relax experiment}(i.e., Definition [3](#Thmdefinition3)) and then run the simulator\mathcal{F} by Definition [2](#Thmdefinition2) (i.e., \mathit{EU}\mathchar 45\relax\mathit{CMA}$ experiment) as follows:

Algorithm $\mathcal{F}(Y^{\prime})$

Setup: $\mathcal{F}$ keeps three lists $\overrightarrow{\mathcal{M}}$, $\overrightarrow{\mathcal{L}}$, and $\overrightarrow{\mathcal{L^{\prime}}}$, all initially empty. $\overrightarrow{\mathcal{M}}$ is a message list that records each $M_{j}$ queried to ETA.Sig oracle. $\overrightarrow{\mathcal{L}}{}[j]$ and $\overrightarrow{\mathcal{L^{\prime}}}{}[j]$ record $(M_{j},i)$ queried to $\mathit{RO}(.)$ oracle and its corresponding $\mathit{RO}(.)$ answer $(h_{j},i)$, respectively, for cryptographic hash functions $H_{i},i\in\{0,1\}$. $(h_{j},i)\leftarrow{}\overrightarrow{\mathcal{L^{\prime}}}{}[M_{j},i]$ denotes the retrieval of $\mathit{RO}(.)$ oracle answer of $(M_{j},i)$ that has been queried before. If $(M_{j},i)$ has not been queried before then $\perp\leftarrow{}\overrightarrow{\mathcal{L^{\prime}}}{}[M_{j},i]$. $\mathcal{F}$ sets counters $(l\leftarrow{}0,n\leftarrow{}0)$ and continues as follows:

1. $\bullet$

$h\leftarrow{}\mathit{H}\mathchar 45\relax\mathit{Sim}{}(M,l,\overrightarrow{\mathcal{L}}{},\overrightarrow{\mathcal{L^{\prime}}}{},i)$: $\mathcal{F}$ implements a function $\mathit{H}\mathchar 45\relax\mathit{Sim}$ to handle $\mathit{RO}(.)$ queries. That is, cryptographic functions $H_{i},i\in\{0,1\}$ are modeled as random oracles via $\mathit{H}\mathchar 45\relax\mathit{Sim}$. If $\exists{j}:(M,i)=\overrightarrow{\mathcal{L}}{}[j]$ then $\mathit{H}\mathchar 45\relax\mathit{Sim}$ returns $\overrightarrow{\mathcal{L^{\prime}}}{}[j]$. Otherwise, it returns h\stackrel{{\scriptstyle\}}{{\leftarrow}}\mathbb{Z}{q}^{*}{}$as the answer for given$H{i}$, assigns$(\overrightarrow{\mathcal{L}}{}[l]\leftarrow{}(M,i),~{}\overrightarrow{\mathcal{L^{\prime}}}{}[l]\leftarrow{}(h,i))$and$l\leftarrow{}l+1$. 2.$\bullet$

$\mathcal{F}$ creates a simulated SEMECS public key $\mathit{PK}$ as follows:

$Y\leftarrow{}Y^{\prime}$, 2. -

For $j=0,\ldots,K-1$,

1. a)

(s_{j},e_{j},z_{j})\stackrel{{\scriptstyle\}}{{\leftarrow}}{}\mathbb{Z}_{q}^{*}$ 2. b)

$R_{j}\leftarrow{}Y^{e_{j}}\cdot\alpha^{s_{j}}\bmod p$ 3. c)

$\gamma_{j}\leftarrow{}z_{j}\oplus\mathit{H}\mathchar 45\relax\mathit{Sim}{}(R_{j},l,\overrightarrow{\mathcal{L}}{},\overrightarrow{\mathcal{L^{\prime}}}{},0)$ 4. d)

$\beta_{j}\leftarrow{}\mathit{H}\mathchar 45\relax\mathit{Sim}{}(R_{j},l,\overrightarrow{\mathcal{L}}{},\overrightarrow{\mathcal{L^{\prime}}}{},1)$ 3. -

$\mathit{PK}{}\leftarrow{}(Y,\alpha,\overrightarrow{v}{}=(\langle\gamma_{0},\beta_{0}\rangle,\ldots,$ $\langle\gamma_{K-1},\beta_{K-1}\rangle,K)$. 2. -

Execute $(M^{*},\sigma^{*})\leftarrow{}\mathcal{A}^{\mathit{RO}(.){},\texttt{SEMECS.Sig}{}_{sk}(.)}(\mathit{PK}{})$**:

1. $\bullet$

Queries:* $\mathcal{F}$ handles $\mathcal{A}$ ’s queries as follows:*

(i)* $\mathcal{A}$ queries $\mathit{RO}(.)$ on a message $M$ for $H_{i},i\in\{0,1\}$. $\mathcal{F}$ returns $h\leftarrow{}\mathit{H}\mathchar 45\relax\mathit{Sim}{}(M,l,\overrightarrow{\mathcal{L}}{},\overrightarrow{\mathcal{L^{\prime}}}{},i)$.*

(ii)* $\mathcal{A}$ queries SEMECS.Sig oracle on a message $M_{n}$. If $n>K-1$ then $\mathcal{F}$ rejects the query (i.e., the query limit is exceeded). Otherwise, $\mathcal{F}$ continues as follows:*

1. a)

If $|M_{n}|<|q|$ set $(\overline{M}_{n}=M_{n},\widetilde{M}_{n}=0)$, else split $M_{n}$ into two as $(\overline{M}_{n}||\widetilde{M}_{n})$ such that $|\overline{M}_{n}|=|q|$. 2. b)

$\mathcal{F}$* generates $c_{n}\leftarrow{}z_{n}\oplus\overline{M}_{n}$ and checks if $(c_{n}||M_{n},0)\in\overrightarrow{\mathcal{L}}{}$. If it holds then $\mathcal{F}$ aborts (i.e., the simulation fails). Otherwise, $\mathcal{F}$ continues as follows.* 3. c)

$\mathcal{F}$* inserts $(\overrightarrow{\mathcal{L}}{}[l]\leftarrow{}(c_{n}||M_{n},0),\overrightarrow{\mathcal{L^{\prime}}}{}[l]\leftarrow{}(e_{n},0)$).* 4. d)

$\mathcal{F}$* returns $\sigma_{n}\leftarrow{}(s_{n},c_{n})$ to $\mathcal{A}$ , sets $\overrightarrow{\mathcal{M}}{}[n]\leftarrow{}M_{n}$ and then increments $(n\leftarrow{}n+1,l\leftarrow{}l+1)$.* 2. $\bullet$

Forgery of $\mathcal{A}$ :* Eventually, $\mathcal{A}$ outputs a forgery on $\mathit{PK}$ as $(M^{*},$ $\sigma^{*})$, where $\sigma^{*}=(s_{j}^{*},c_{j}^{*}),~{}0\leq j\leq K-1$. By definition 2, $\mathcal{A}$ wins the $K$-time $\mathit{EU}\mathchar 45\relax\mathit{CMA}$ experiment for SEMECS if $\texttt{SEMECS.Ver}{}(\mathit{PK}{},$ $M^{*},\sigma^{*})=1$ and $M^{*}\notin\overrightarrow{\mathcal{M}}{}$ hold. If these conditions hold, $\mathcal{A}$ returns $1$, else, returns [math].* 3. -

*Forgery of $\mathcal{F}$ *: If $\mathcal{A}$ loses in the $K$-time $\mathit{EU}\mathchar 45\relax\mathit{CMA}$ experiment for SEMECS, $\mathcal{F}$ also loses in the $\mathit{DL}$ experiment, and therefore $\mathcal{F}$ aborts and returns [math]. Otherwise, if $(c_{j}^{*}||M^{*})\in\overrightarrow{\mathcal{L}}{}$ then $\mathcal{F}$ aborts and returns [math] (i.e., $\mathcal{A}$ wins the experiment without querying $\mathit{RO}(.)$ oracle). Otherwise, $\mathcal{F}$ sets $s_{j}^{*}\leftarrow{}\overrightarrow{\mathcal{L^{\prime}}}{}[c_{j}^{*}||M^{*}]$ and continues as follows:

Recall that $R_{j}\equiv Y^{e_{j}}\cdot\alpha^{s_{j}}\bmod p$ holds, where $0\leq j\leq K-1$. Moreover, since $\texttt{SEMECS.Ver}{}(\mathit{PK}{},M^{*},\sigma^{*})=1$ holds, $R_{j}\equiv Y^{{e_{j}}^{*}}\cdot\alpha^{s_{j}^{*}}\bmod p$ also holds. Therefore, we write the following equations:

[TABLE]

$\mathcal{F}$* then extracts $y^{\prime}=y$ by solving the below modular linear equations (note that only unknowns are $y$ and $r_{j}$), where $Y=Y^{\prime}$ as defined in simulation:*

[TABLE]

Note that $Y^{\prime}\equiv\alpha^{y^{\prime}}\bmod p$ holds, since $\mathcal{A}$ ’s forgery is valid and non-trivial on $Y^{\prime}=Y$. Therefore, by Definition 3, $\mathcal{F}$ wins the $\mathit{DL\mathchar 45\relax experiment}$.

The execution time and probability analysis of the above experiment are as follows:

Execution Time Analysis: In this experiment, the running time of $\mathcal{F}$ is that of $\mathcal{A}$ plus the time it takes to respond $q_{H}$ $\mathit{RO}(.)$ queries and $K$ ETA.Sig.

• •

Setup phase: $\mathcal{F}$ draws $3K$ random numbers, performs $2K$ modular exponentiations, $K$ XOR operations, and then invokes $\mathit{RO}(.)$ $2K$ times by drawing additional $2K$ random numbers. Hence, the total cost of this phase is $(2K)\cdot O(\kappa^{3})+(5K)\cdot\texttt{RNG}{}$, where $O(\kappa^{3})$ denotes the cost of modular exponentiation and RNG denotes the cost of drawing a random number. We omit the costs of XOR operations.

• •

Query phase: $\mathcal{F}$ draws $K$ random numbers to handle $\mathcal{A}$ ’s ETA.Sig queries, whose cost is $K\cdot\texttt{RNG}{}$. $\mathcal{F}$ also draws $K^{\prime}$ random numbers to handle $\mathcal{A}$ ’s $\mathit{RO}(.)$ queries, whose cost is at most $K^{\prime}\cdot\texttt{RNG}{}$.

Therefore, the approximate total running time of $\mathcal{F}$ is $t^{\prime}=O(t)+(2K)\cdot O(\kappa^{3})+(6K+K^{\prime})\cdot\texttt{RNG}{}$.

Success Probability Analysis: $\mathcal{F}$ succeeds if all below events occur.

$\overline{\mathit{E1}}$: $\mathcal{F}$ does not abort during the query phase. 2. -

$\mathit{E2}$: $\mathcal{A}$ wins the $K$-time $\mathit{EU}\mathchar 45\relax\mathit{CMA}$ experiment for SEMECS. 3. -

$\mathit{\overline{E3}}$: $\mathcal{F}$ does not abort after $\mathcal{A}$ ’s forgery. 4. -

$\mathit{Win}$: $\mathcal{F}$ wins the $K$-time $\mathit{EU}\mathchar 45\relax\mathit{CMA}$ experiment for $\mathit{DL}$-experiment. 5. -

$Pr[\mathit{Win}{}]=Pr[\overline{\mathit{E1}}{}]\cdot Pr[\mathit{E2}|\overline{\mathit{E1}}{}]\cdot Pr[\mathit{\overline{E3}}{}|\overline{\mathit{E1}}{}\wedge\mathit{E2}]$

$\bullet$ The probability that event $\overline{\mathit{E1}}$ occurs: During the query phase, $\mathcal{F}$ aborts if $(M_{j}||x_{j})$ $\in\overrightarrow{\mathcal{L}}{},~{}0\leq j\leq K-1$ holds, before $\mathcal{F}$ inserts $(c_{j}||M_{j})$ into $\overrightarrow{\mathcal{L}}$ (i.e., the simulation fails). This occurs if $\mathcal{A}$ guesses the randomized output $c_{j}$ and then queries $(c_{j}||M_{j})$ to $\mathit{RO}(.)$ before querying it to SEMECS.Sig. The probability that this occurs is $\frac{1}{2^{|q|}}$, which is negligible in terms of $\kappa$. Hence, $Pr[\overline{\mathit{E1}}{}]=(1-\frac{1}{2^{|q|}})\approx 1$.

$\bullet$ The probability that event $\mathit{E2}$ occurs: If $\mathcal{F}$ does not abort, $\mathcal{A}$ also does not abort since the simulated view of $\mathcal{A}$ is indistinguishable from the real view of $\mathcal{A}$ (see the indistinguishability analysis). Therefore, $Pr[\mathit{E2}|\overline{\mathit{E1}}{}]=\mathit{Adv}_{\texttt{SEMECS}{}}^{\mathit{EU}\mathchar 45\relax\mathit{CMA}{}}(t,K^{\prime},K){}$.

$\bullet$ The probability that event $\mathit{\overline{E3}}$ occurs: $\mathcal{F}$ does not abort if the following conditions are satisfied:

1. i

$\mathcal{A}$ wins the $\mathit{EU}\mathchar 45\relax\mathit{CMA}$ experiment for SEMECS on a message $M^{*}$ by querying it to $\mathit{RO}(.)$. The probability that $\mathcal{A}$ wins without querying $M^{*}$ to $\mathit{RO}(.)$ is as difficult as a random guess. 2. ii

After $\mathcal{F}$ extracts $y^{\prime}$ by solving modular linear equations, the probability that $Y^{\prime}\not\equiv\alpha^{y^{\prime}}\bmod p$ is negligible in terms $\kappa$, since $(Y=Y^{\prime})\in\mathit{PK}{}$ and $\texttt{SEMECS.Ver}{}(\mathit{PK}{},M^{*},\sigma^{*})=1$. Hence, $Pr[\mathit{\overline{E3}}{}|\overline{\mathit{E1}}{}\wedge\mathit{E2}]=\mathit{Adv}_{\texttt{SEMECS}{}}^{\mathit{EU}\mathchar 45\relax\mathit{CMA}{}}(t,K^{\prime},K){}$.

Omitting the terms that are negligible in terms of $\kappa$, the upper bound on $\mathit{EU}\mathchar 45\relax\mathit{CMA}$-advantage of SEMECS is as follows:

[TABLE]

Indistinguishability Argument: The real-view of $\mathcal{A}$ is comprised of the public key $\mathit{PK}{}=(Y,\alpha,p,q,\overrightarrow{v}{}=(\langle\gamma_{0},\beta_{0}\rangle,\ldots,$ $\langle\gamma_{K-1},\beta_{K-1}\rangle,K)$, the answers of $\texttt{SEMECS.Sig}{}_{sk}(.)$ as $\overrightarrow{\mathcal{\sigma}}{}=(s_{j},c_{j})$ for $j=0,\ldots,K-1$, and the answer of $\mathit{RO}(.)$ as $\overrightarrow{\mathcal{L}}{}=(h_{0},\ldots,h_{K^{\prime}-1})$ on corresponding $H_{i},i\in\{0,1\}$, respectively. That is, $\overrightarrow{\mathcal{A}}{}_{\mathit{real}}=\langle\mathit{PK}{},\overrightarrow{\mathcal{\sigma}}{},\overrightarrow{\mathcal{L}}{}\rangle$, where all values are generated/computed by SEMECS algorithms as in the real system. All variables in $\overrightarrow{\mathcal{A}}$ are computed from the values $\{y,r_{n},z_{n},h_{j},\alpha,p,q\}_{n=0,j=0}^{K-1,K^{\prime}-1}$. Hence, the joint probability distribution of all other variables in $\overrightarrow{\mathcal{A}}$ are determined by the joint probability of these values. All these are random in $\mathbb{Z}_{q}^{*}$. Therefore, the joint probability distribution of $\overrightarrow{\mathcal{A}}$ is,

[TABLE]

We denote the simulated view of $\mathcal{A}$ is as $\overrightarrow{A}_{\mathit{sim}}$, and it is equivalent to $\overrightarrow{A}_{\mathit{real}}$ except that in the simulation, values $(s_{j},e_{j},z_{j},c_{j})$ for $j=0,\ldots,K-1$ are randomly selected from $\mathbb{Z}_{q}^{*}$. Note that the joint probability distribution of these variables are identical to original signature and hash outputs (since hash function is modeled as RO). Hence, we write $Pr[\overrightarrow{A}_{\mathit{real}}{}=\overrightarrow{a}]=Pr[\overrightarrow{A}_{\mathit{sim}}{}=\overrightarrow{a}]$. $\square$

V Performance Analysis and Comparison

In this section, we first present the analytical analysis of SEMECS and its counterparts. Then, we present the results of our experiments on a commodity laptop and an 8-bit AVR embedded processor. Our evaluation metrics include key sizes, signature size, and computation costs. On the 8-bit microprocessor, we focus on the signer cost (i.e., private key, signature size, signature generation) since our system model includes resource-constrained devices as signers. For our counterparts, we consider state-of-the-art $K$-time signature schemes as well as some traditional (full-time) signatures.

Remark: Our envisioned applications require high signer efficiency to be practical on resource-constrained devices. Hence, optimizing the online signer efficiency is the essential performance objective for SEMECS. Recall that we assume verifiers are resourceful entities, which is a reasonable assumption for our envisioned applications (see Section I). Also note that in SEMECS system model, private/public keys are generated before the system deployment (see Section II-B). Hence, the key generation cost (i.e., offline cost) is not a critical performance metric for SEMECS.

V-A Analytical Performance Analysis

Here, we describe the analytical costs of our scheme, where the online costs are summarized in Table II.

**Key Generation: **Key generation of SEMECS requires $K$ EC scalar multiplications that is higher than its full-time counterparts. For instance, for EC-based signature schemes (e.g., ECDSA [11], Ed25519 [17], Kummer [16], and SchnorrQ [18]) keys are generated with only one EC scalar multiplication. However, it is comparable to its $K$-time counterparts as their key generation also depends on $K$. Note that in our system model, key distribution is performed before the deployment. Thus, we believe that this does not pose a limitation for our considered use-cases.

**Signer Overhead: **In SEMECS, signer stores a small private key that is the same size as its full-time elliptic curve counterparts. The private key of some $K$-time signatures can be deterministically derived from a $\kappa$-bit seed, which is 2$\times$ smaller than that of SEMECS. However, this makes a small difference in practice (i.e., 16 Bytes vs 32 Bytes). Signature generation of SEMECS only requires 2 hash function calls, a single multiplication, and subtraction under$\mod q$. This introduces a significantly smaller overhead compared to its alternatives. The counterparts of SEMECS either require expensive operations (i.e., EC scalar multiplication) or a very large number of hash function calls for signature generation. Only HORS [26] and Zaverucha et al. [28] have comparable signature generation speed. However, when we generate the private key components from a seed, these hash function calls dominate the signature generation cost for these schemes due to their large private key size.

**Signature Transmission: **Signature size of SEMECS is the smallest compared to its counterparts. Note that since the signature component $c_{j}$ contains the information to recover the first $|q|$ Bytes of the message, we do not consider its transmission as an overhead. SEMECS only requires additional $|q|$ Bytes to be transmitted. Since the transmission of signatures introduces an overhead to the energy consumption of signer (and verifier), we believe it is essential to minimize its size.

**Verifier Overhead: **In SEMECS the public key is linear with the messages to be signed with a single key pair. Therefore, it increases as $K$ increases (similar to its $K$-time counterparts except HORSE [30]). Considering that the verifier device is a resourceful device (e.g., server, command center) in SEMECS applications, we believe this is tolerable. The signature verification of SEMECS requires an EC double scalar multiplication (can be accelerated with Shamir’s trick [9]).

**Parameters: ** We selected parameters to provide $\kappa=128$-bit security for both SEMECS and its counterparts. For elliptic-curve based schemes (including SEMECS), we selected $|q|=256$-bit. For Zaverucha et al., we selected $m=260$, for HORS and HORSE, we selected $t=1024$ and $u=24$ to provide the desired security level. For XMSS and SPHINCS, we used the parameters suggested in the base papers. We refer the interested readers to the base papers of these schemes for the detailed explanation of their parameter choice.

V-B Performance Evaluation on Commodity Laptop

We implemented SEMECS on a laptop and compared its cost to its state-of-the-art counterparts.

**Hardware Configurations and Software Libraries: ** As our commodity hardware, we used a laptop equipped with an Intel i7 Skylake 2.6 GHz CPU with 12 GB RAM.

We implemented SEMECS on FourQ curve [15] to offer fast verification. We used the open-source implementation of this curve which can be found at444https://github.com/Microsoft/FourQlib. We used our hash function as blake due to its high efficiency and high security [57]. Specifically, we used blake2s due to its optimization on low-end devices. We open-source our implementations at

www.github.com/ozgurozmen/SEMECS

We ran the open-sourced implementations of our counterparts on our hardware setting, if possible. For the hash-based constructions, we conservatively simulated their costs with blake2s hash function, to be fair with them.

**Experimental Results: ** Table III shows the benchmarks and specific key/signature sizes for SEMECS and its counterparts. We observe that SEMECS is 7$\times$ faster than its closest counterpart (HORS [26]) in terms of signature generation. Specifically, it takes only $1.23$ microseconds to generate a signature with SEMECS. Moreover, it has a compact private key of 32 Bytes and the smallest signature (32 Bytes) among its counterparts. Signature verification of SEMECS is also fast since we used the optimized FourQ [15] curve to implement our scheme. Therefore, only HORS [26] and HORSE [30] offer faster verification. The main limitation of SEMECS is its public key size. Specifically, when $K=2^{17}$, which allows signing a message in every 20 minutes for 5 years without a key replacement, the public key size is 8 MB. However, this is much smaller than some of the most efficient $K$-time counterparts such as HORS, and Zaverucha et al., that have 4 GB and 520 MB public key, respectively. We also implemented the key generation of SEMECS on this experimental setting and observed that generating the key for $K=2^{17}$ takes $1.75$ seconds.

V-C Performance/Energy Evaluation on 8-bit Microprocessor

We fully implemented the signature generation of SEMECS on an 8-bit microprocessor to assess its energy and time efficiency on low-end embedded devices.

**Hardware Configurations and Software Libraries: ** We used 8-bit AVR ATmega 2560 microprocessor to measure the signer efficiency of our scheme compared to its counterparts. We selected this low-end device due to its low energy consumption and extensive use in practice, especially in IoT applications and medical devices [43, 58, 59]. It is equipped with 256 KB flash memory, 8 KB SRAM, 4 KB EEPROM, and its maximum clock frequency is 16 MHz.

We implemented SEMECS using Rhys Weatherley’s crypto library [60] that offers high-speed operations for low-end devices. Specifically, we used its blake2s implementation and modified its reduction algorithm to compute$\mod q$ (where $q$ is FourQ parameter) using Barrett reduction. We also open-source our 8-bit implementations at the link given above to facilitate the test and broad adoption of SEMECS.

We used the results of our counterparts that were given in 8-bit AVR microprocessors, if possible. For instance, we used the results provided in [19] for Ed25519, [20] for $\mu$Kummer and [21] for SchnorrQ. We ran the ECDSA implementation of microECC [61] on our hardware. Similar to the laptop implementation, we measured the cost of a single hash (blake2s) call on our microprocessor and conservatively estimated the hash-based schemes’ cost.

**Experimental Results: **As summarized in Table I, our analysis confirmed that SEMECS is highly efficient at the signer’s side. Signature generation of SEMECS is performed with less than 200 thousand cycles, which is 6$\times$ faster than HORS [26] and 19$\times$ faster than SchnorrQ (its fastest counterparts). In addition to this, SEMECS requires a small private key and a signature size that is the smallest among its counterparts. This makes SEMECS very desirable for applications that include resource-limited signers.

**Energy Consumption Analysis: **We analyzed the energy consumption of SEMECS and its counterparts on our experimental setting and compared with the energy consumption of two common IoT sensors (a pulse and a pressure sensor). We first derived a generic energy consumption estimation (as in [62] that offers an estimation for MICAz) for 8-bit AVR ATmega 2560 based on our SEMECS implementation and used it to estimate the energy consumption of our counterparts (similarly with [21] that uses [62]). We also calculated how much energy is required to operate IoT sensors. We took into consideration (i) energy drawn by the sensor (ii) energy drawn by the microprocessor to read data from the sensor and (iii) energy drawn by the microprocessor during the idle time.

We powered our microprocessor with a 2200 mAh power pack. This allowed us to use an ammeter/power meter connected between the battery and the microprocessor. We measured 5V of voltage and 20mA of current on load, which is verified by the datasheet of the processor555http://www.atmel.com/Images/Atmel-2549-8-bit-AVR-Microcontroller-ATmega640-1280-1281-2560-2561_datasheet.pdf. Then, we used the formula $E=V\cdot I\cdot t$ to calculate the energy consumption in Joules (as in [63]). We also considered the potential deployment of nRF24L01 Single Chip 2.4 GHz Transceiver to 8-bit ATmega for signature transmission. Based on its datasheet, we also estimated the energy consumption of signature transmission with this low-power transceiver. Specifically, nRF24L01 operates at 3.3 V, 11.3 mA and support a transmission rate of 2Mbps. Our results showed that 8-bit AVR ATmega 2560 consumes roughly $6.25nJ$ per cycle of computation and $18.65nJ$ per bit of transmission.

We also calculated how much energy is necessary to operate IoT sensors. Specifically, we used a pulse sensor666https://pulsesensor.com/ (that could serve as an example of a medical sensor) and a BMP183 pressure sensor777https://cdn-shop.adafruit.com/datasheets/1900_BMP183.pdf (that could be an example of a daily IoT application). In our energy calculations, we considered a sampling frequency of 10 seconds for the pulse sensor and 10 minutes for the pressure sensor, due to the difference/urgency in their usage. Figure 2 shows how many percentage of the battery is spent on the IoT sensor, compared with that of the cryptographic operations (i.e., signing) of different schemes. One can observe that for pulse sensor (see Figure 2(a)), HORS and SchnorrQ require the $5.16\%$ and $14.71\%$, whereas, with SEMECS, this is decreased to a negligible level ($0.89\%$). For the pressure sensor, the energy consumption of SEMECS is only $3.14\%$ where the closest counterpart is $16.41\%$. This shows that preferring SEMECS as the authentication mechanism in 8-bit AVR microprocessors significantly reduces the impact of cryptographic operations on battery life.

Based on this analysis, we noticed that SEMECS outperforms its counterparts for both computation energy and communication energy at the signer’s side. We believe that this is essential in practice to extend the battery lives of critical embedded devices such as implantable medical devices.

VI Conclusion

In this paper, we proposed a new signature scheme called SEMECS, which achieves several desirable properties that are critical for resource-constrained devices. Specifically, SEMECS only requires two hash, a modular multiplication, and a modular subtraction to compute a signature. Moreover, it has a constant-small private key and signature, that is optimal for an EC-based signature scheme. Our experiments on both laptop and 8-bit AVR confirmed the energy and computational efficiency of SEMECS. Therefore, we believe SEMECS is an ideal alternative for providing authentication and integrity services for resource-constrained devices.

Acknowledgments

This work is supported by the NSF CAREER Award CNS-1652389. We would like to thank Rouzbeh Behnia for his valuable comments.