IoT in medical & pharmaceutical: Designing lightweight RFID security protocols for ensuring supply chain integrity.

Nowadays the sharing of trade in counterfeit and pirated goods is constantly growing and fake products are found in a large number of industries - particularly pharmaceuticals, food, and medical equipment - that can pose serious health and safety risks. With the intention of avoiding any loss of client confidence and any disclosure of sensitive information, Internet of Things (IoT) solutions are increasingly used to fulfill this need for a reliable and secure infrastructure in medical & pharmaceutical industry. When looking at the technologies used to identify products and packaging, balancing security and hardware limitations is often a difficult task and using cost-effective techniques such as bit-oriented lightweight functions is a challenge. In this study, we first assess the security level of a recently proposed protocol and prove its vulnerabilities, due to a lack of complexity in bit-oriented functions. Then, to address these exposed flaws, a lightweight improved protocol based on Authenticated Encryption (AE) cryptosystems is presented. Security analysis results demonstrate that weaknesses of previous efforts have all been adequately addressed; additionally, the improved protocol has a robust security posture in terms of confidentiality and integrity. Moreover, FPGA and ASIC simulations are carried out using five different AE schemes from CAESAR competition to develop three use-cases, in whose best scenario the proposed tag has 731 LUT and needs 3335 gates for the security module.

Introduction

Illicit trade in fake goods is a major challenge in the global economy, resulting in a plethora of adverse effects on the economy, as well as on public health, safety, and security [1]. Organized criminal groups operate wherever there is an opportunity to make profits from counterfeiting or piracy operations, frequently bypassing security measures. Despite continuous efforts to monitor this risk, the share of trade in counterfeit and pirated goods is constantly growing, and fake or fraudulent products are found in a large and growing number of industries, particularly pharmaceuticals, food and drink, and medical equipment, that can pose serious health and safety risks. Every day new threats of counterfeits are reported [2] in this billion-dollar market, in which approximately half of the counterfeit pharmaceuticals sold are fraudulent versions of treatments. This is “an unaffordable vulnerability” [3]. With “counterfeiting and piracy on the rise”, it is no surprise that the current context of the COVID-19 pandemic opens great opportunities for counterfeiters [4], as governments the world over are looking for COVID-19 facemasks and test kits. Since the onset of the crisis, many cases have been reported in the news where authorities have intercepted counterfeit COVID-19 test kits, pressing worldwide anti-fraud centers as well as the United States’ Food and Drug Administration (FDA) [5] to alert consumers about unauthorized fraudulent test kits.

To combat this risk surrounding the rising significance of counterfeit products and medications, government agencies (e.g. the FDA) and organization (e.g. pharmaceutical suppliers) are exploring enforcement solutions, among which IoT solutions can help maintain a secure supply chain [6]. Moreover, the adoption of IoT technologies in the healthcare and pharmaceutical sectors is continuously expanding, including – among other aspects – a high demand for hospital-based IoT services oriented towards patient safety, work efficiency, and medical environment management [7]. Within the IoT ecosystem, radio frequency identification (RFID) technologies are among the technologies most used to enable automatic identification and tracking of products, people, and assets. In fact, various RFID initiatives have been undertaken since the early 2000s to secure supply chain integrity by supporting real-time tracking, tracing & authentication of pharmaceuticals products. Since then, the RFID market has grown and is currently estimated to be valued at over one billion US$ [8]. Assuredly, counterfeit drugs concerns have encouraged the industry to use RFID technologies within pharmaceutical supply chains, with industry players ranging from drug manufacturers to packaging solutions providers, warehouse and distribution centers, to clinical facilities. Today “mass serialization” is proposed as the standard for identifying drug packages, by equipping each of them with a unique identifier, such as a 2D barcode or RFID entered into an online database for track-and-trace purposes. Unfortunately, weaknesses in track-and-trace the system leave the system vulnerable to counterfeiters, calling for an increased attention towards RFID technology adoption [9], aligned with the Drug Quality and Security Act [10] and the Drug Supply Chain Security Act [11].

Ironically, if these technologies are to prevent trade in counterfeit and pirated goods, they may themselves constitute an issue. Given the importance of RFID (and other IoT devices) used to track and manage supply chains, security issues are raised by the professional and academic community, calling for security requirements at all layers of any IoT-based infrastructure [12]. In fact, in a recent bibliometric analysis on IoT, Dachyar et al. [13] found a significant increase in the number of articles on IoT – with growth and development in an interdisciplinary manner – and, following a pattern of analysis of research trends, they show a clearly-increasing number of researches on security attacks and protocols. This is particularly important with passive Ultra High Frequency (UHF) RFID tags equipped with a highly constrained microchip holding limited processing power and memory capabilities. These tags, constituting the first layer of an RFID infrastructure (Fig. 1), are used to identify drugs, high value and consignment products in hospitals, to track biospecimen sampling or COVID-19 test kits in the supply chain. Fig. 2 (adapted from GS1[14]) shows the supply chain activities where key steps are undertaken. Without the proposed RFID tag security – at any of these steps – malicious attacks may be undertaken. For better understanding, COVID-19 test kits will be employed here as a realistic use case to illustrate the effect of health and safety risks in bypassing security measures. In the following scenario we consider a supply chain process involved in production of a COVID-19 test kit from a plant to a hospital, assuming that RFID tags are encoded and applied to final assembled kits targeted for tracking as well as to the component products contained in the kits requiring identification. A potential attack scenario could be implemented as follows:

Fig. 1

The infrastructure of an IoT-enabled traceability system.

Fig. 2

Opportunities to conduct a malicious attack in the supply chain.

RFID tags are applied to COVID-19 test kits (for collection of nasal swab specimens) to ensure automatic identification (for efficient logistics management), authentication (for patient safety), and anti-counterfeit measures (for brand protection).

Kits are shipped from the assembly plant.

Kits are received and completed at the packaging sites (where RFID tag is applied) opportunity to conduct an attack:

Tags information is captured (using an unauthorizedreader);

Kits equipped with original RFID tags are identified in the shipping zone;

New tags are cloned;

New tags are applied to the fake kits;

Fake kits are shipped as “authentic kits” to the distribution center;

Authentic kits are sold to selected customers.

Fake kits are received at the distribution center where they are stored and cross the dock to clinical sites:

Opportunity for conducting a similar attack to the one described at the packaging site above.

Kits are received at the hospital, where they are temporarily stored and used. Another opportunity to conduct an attack arises here:

Tags information is captured (using an unauthorizedreader);

Kits (tags) are identified and retrieved in the storage area in the hospital;

Authentic kits are stolen;

Fake kits are produced to replace authentic kits;

Fake kits are used with potential harmful effects to the health of the patients;

Authentic kits are sold directly to selected customers (according to the best offer).

As discussed in the above scenario, a malicious attack can be undertaken at various phases of the supply chain, compromising it’s integrity and raising the critical importance for securing any layer of the supporting IT infrastructure. In an IoT-based medical system, one of the weakest layer may be the technology used for item automatic identification and data capture. By incurring an unauthorized access to the information on tags (e.g. passive disclosure attack) an adversary could then compromise the whole system. Therefore, researchers are working on the development of secure authentication and communication protocols to prevent malicious attacks. For example, Li et al. [15] presented an authentication protocol for Telecare Medicine Information Systems (TMIS) and claimed that the proposed protocol is able to satisfy the security requirements of a Medical IoT system. However, Bensallah et al. and Zhou et al. [16], [17], in two different research papers, proved that Li et al.’s protocol is vulnerable to desynchronization and impersonation attacks. In addition, Zheng et al. [18] proposed another lightweight authentication protocol for TMIS system based on a Hash function by which Safkhani and Vasilakos [19] showed that their protocol is not resistant against replay, impersonation, and desynchronization attacks. On the other hand, other researchers attempted to present an authentication protocol based on ECC (Elliptic Curve Cryptography) cryptosystems for medical applications. For example, Liao and Hsiao [20] designed an ECC-based protocol which Zhao et al. [21] proved their vulnerability to a tag disclosure attack. In addition, in order to increase the security level, Chou et al. [22] used a combination of a hash function and an ECC module in their protocol. However, Zhang and Qi [23] – by showing the weaknesses of Zhou et al.’s protocol – presented a new protocol with the same concept. Finally, Farash [24] proved in turn that Zhang and Qi’s protocol is also vulnerable to an impersonation attack. Fotouhi et al. suggested a lightweight protocol based on the two-factor authentication scheme [25]. The proposed protocol was designed for wireless body area networks (WBAN) in health-care IoT applications and by using XOR and hash functions provided a secure environment. Another WBAN-based protocol for e-health systems was introduced by Arfaoui et al. [26]. In order to respect patients’ privacy and protect the confidential data of medical records, the authors presented a context-aware and lightweight anonymous authentication and key agreement scheme which was suitable for applications in emergency and normal situations.

Since using an ECC cryptosystem alone cannot guarantee the security of a protocol, as well as it causes more burden on a tag’s hardware, some research have been undertaken on ultra-lightweight and lightweight protocols. For instance, Fan et al. [27] recently proposed a lightweight RFID mutual authentication scheme and suggested relevance to application in medical privacy protection in IoT systems. The authors analyzed the security of the proposed protocol and claimed that it provides tag anonymity, replay attack resistance, synchronization attack resistance, forward secrecy, mutual authentication, and DoS attack resistance. However, a subsequent review revealed that the proposed protocol suffers from trivial weaknesses, as was shown by Aghili and Malla [28] and more comprehensively later by Aghili et al. [29]. In those works, the security of the proposed scheme is scrutinized and serious security pitfalls are shown. More precisely, they present an efficient secret disclosure and traceability attacks that violate the designers’ claims. In addition, by focusing on bit-oriented operations in the ultra-lightweight function, Aghili et al. [29] also proposed an improved protocol called SecLAP following the same design strategy and stated optimum security against an active adversary who can control the channel between the tag and the reader as well as between the reader and the server. Although the authors claimed SecLAP was fully secure, we show that this protocol has serious security breaches, which we intend to address here. We present traceability and passive secret disclosure attacks against this protocol, with the complexity of eavesdropping one session of the protocol and with success probability of ‘1’. The disclosed parameters can be used to trace the tag/reader in any later session, which compromises tag/reader privacy. In addition, we present below a passive full secret disclosure attack against SecLAP which is capable of disclosing a -bit secret key, -bit and -bit with the computational complexity of . We explain limitations of ultra-lightweight protocols that cause the above protocols to compromise. Given that new authentication protocols have recently been introduced with lightweight cryptographic methods which have complicated protocol’s structures [30], we present an uncomplicated improved protocol and employ a cryptosystem that provides a higher security level than ultra-lightweight functions and is able to satisfy the hardware requirements of lightweight tags.

The Paper’s Contribution: This paper has three main contributions:

We provide the first third-party security analysis of SecLAP, which may be the latest attempt to design a secure ultra-lightweight protocol for constrained environments. More precisely, we execute a passive attack, which can partially disclose secret parameters of the protocol with the complexity of eavesdropping on one session of the protocol with negligible computational complexity. In addition, we present a full secret disclosure attack that can extract all secret parameters of the protocol with the complexity of .

To overcome the security flaws in SecLAP, we present an improved protocol based on an Authenticated Encryption (AE) scheme and provide informal and formal security evaluations to show the robustness of the protocol. This scheme not only is able to solve the confidentiality issues of the current protocols, but also provides the message integrity simultaneously.

Given that an AE module can use different implementation designs, we simulate the structure of a tag (FPGA and ASIC) under five encryption schemes and measure its hardware requirement as a candidate for constrained environments. We show that the improved protocol can meet the security requirements with a reasonable hardware cost.

Paper Organization : The required preliminaries and a brief description of SecLAP protocol are introduced in Section 2. We present results of security investigation of SecLAP protocol in Section 3. Then, we discuss our suggested encryption scheme in Section 4 and propose the improved protocol in Section 5. The security analysis and hardware implementation results are respectively explained in Sections 6, 7 and we conclude the paper in Section 8.

Preliminaries

Notations

Table 1 depicts the notations used in the rest of this paper. In order to propose a robust ultra-lightweight protocol, Aghili et al. presented a new component called modular rotation function which is used in the structure of SecLAP. Given two -bit strings and and a -bit string , the modular rotation function is defined as follows:

Table 1

Notations used in this paper.

Symbol	Description
R	An RFID reader
RID	The identification value of the reader R
S	A cloud server
T	An RFID tag
TID	The identification value (ID) of the tag T
K	The current session number
K_new	The new session number
PRNG()	The pseudo random number generator
Cro(x,y)	The bit-oriented operation defined by Fan et al.
Rot(x,y)	The rotation of sting x based on the hamming weight of y
MRot_K(x,y)	The bit-oriented operation defined which is used in SecLAP
od(x)	Odd bits of string x.
ev(x)	Even bits of string x.
⊕	The bitwise XOR operation
∥	The concatenation operation
Mark	Two temporary bits that are used to indicate the status of the last session
X¯	The bitwise complement of the string X
ID_t	Tag’s ID in the improved protocol
IDS	Secret Tag’s ID in the improved protocol
K_t	Encryption key
N_x	A random number

As illustrated in Fig. 3, the odd bits of are concatenated with the even bits of , the result is XORed by the bits of and the result is rotated to the left depending on the value of . The result is used as the odd bits of the final result. We can represent it as , where and respectively denote the odd bits of and the even bits of .

Fig. 3

The structure of function in SecLAP, where .

The even bits of are concatenated with the odd bits of , the result is XORed by the bits of and the result is rotated to the left depending on the value of . The result is used as the even bits of the final result. We can represent it as .

It is clear is more complicated compared to that has been explained in the Appendix.

Random Oracle Model (ROM)

Random Oracle [31] is a random black box function that provides a unique response for a truly random input as a security proof for evaluating protocols. Every time a same input is given to the random oracle function, the same output is returned. A Random Oracle Model, denoted by , is defined by . Here is a function chosen uniformly at random from the set of all functions with the same domain and range.

In general (as in our paper), the output’s length of is predefined to some fixed value, e.g.  bits. Hence, we re-define as . Given an input , will give as the output.

Adversary

We consider a computationally unbounded adversary with access to or a real cryptographic component , which could be a cryptographic protocol and is the total length of the observable messages in each query. The adversary’s “running time” is determined by the number of oracle queries that it makes to . We use the symbol (big-Oh), for “the expected running time of at most” and (big-Omega), for “the expected running time not less than”.

Indistinguishability

In the cryptology terminology, is considered as an ideal system and the distinguisher tries to distinguish the candidate crypto system with -bit output length from . In the framework of indistinguishability, the distinguisher faces with either or and aims to understand whether interacts with or . Now we present the formal definition of indistinguishability following [32]:

Considering a probabilistic polynomial time (PPT) algorithm (called distinguisher) as an algorithm that its running time on input is at most and may use (true) randomness to produce (possibly) non-deterministic results. The crypto system and the random oracle are (computationally) indistinguishable if for any PPT distinguisher , interacting with one of these components and generating a binary output ( or ), it holds that: where is a negligible function of the security parameter .

In this framework, the maximum number of queries is bounded and denoted by .

A crypto system is said to be indistinguishable from a random oracle if for any PPT distinguisher with and performs at most queries to it holds that: where is a negligible function of the security parameter .

Description of SecLAP

SecLAP was proposed to improve the security drawbacks of its predecessor (Fan et al.) based on a similar designing paradigm. As depicted in Fig. 4, it is implemented as follows:

Fig. 4

Mutual authentication phase of SecLAP  [29].

The reader starts the authentication process by generating a new random number and sends it along with to the tag.

Once the tag receives the message, it:

generates a random number ;

computes and ;

and sends to the reader;

Upon receipt of the message, the reader obtains from and verifies the received . Then, it computes , , and , and forwards to the server. If the tag is not authenticated, the protocol will be terminated.

When the server receives the message:

extracts and finds the related and in the database and verifies the received ;

generates another random number ;

computes , and sends to the reader.

Once the reader receives , it:

retrieves from and verifies the received ;

computes and ;

and sends to the tag;

Once receipt the message , the tag:

retrieves from and verifies to authenticate the server/reader;

calculates ;

computes and ;

and sends to the reader.

When the reader receives the message, it:

calculates and verifies the received ;

computes , , , , , , , ;

and sends to the server.

Once the server receives the message, it:

extracts , and respectively from , , , and and verifies accordingly to update and ,

adds to its database ,

computes and sends it to the reader.

Upon receipt of the message , the reader verifies it before updating as . If is verified correctly, the reader computes  and sends it to the tag.

The tag verifies the correctness of received to update as and the protocol is completed.

Security analysis of SecLAP

Aghili et al. have claimed the optimum security of SecLAP against an active adversary, and showed that SecLAP is completely secure by using informal and formal evaluations like Burrows–Abadi–Needham (BAN) logic. In this section, we present a security evaluation and prove that SecLAP is not resistant against secret disclosure and traceability attacks.

Partial secret disclosure attack

This section explains some properties of SecLAP that can be used to reveal information related to secret parameters. Based on this information, the adversary can trace the tag or the reader which compromise their anonymity. More precisely:

On the other hand, from the definition of we know that the and . Hence:

The above equation can be simplified as follow:

Next, assume that the adversary has eavesdropped the first run of the exchanged messages between the reader and the tag, i.e.,  and , where and . According to the above argument, we can write: and:

Similarly, we can argue that: and, given Eqs. (5), (6):

In any of Eqs. (5), (6), the left side is a linear combination of the public parameters and the right side is a linear combination of secret parameters. Hence, each equations reveals a bit of the secret information. In addition, as long as the tag has not updated its secrets those bits of information remain fixed and the adversary can use it as a source of traceability, which compromises the designers claim on the security of the protocol against traceability.

Given that the channel between the reader and the server is also insecure, to trace the reader, the adversary eavesdrops , a sent message from the reader to the server, where . Recall from Eq. (3): Combining Eqs. (8), (5), reveals a single bit of as follows:

It worth noting that the related information in Eq. (9) is independent of the tag’s data. Hence it is enough to compromise the reader anonymity.

Other eavesdropped messages by the adversary could be used to disclose other information as follows:

, and sent from the reader to the server,

, sent from the server to the reader,

and sent from the reader to the tag,

and sent from the tag to the reader,

, , , , , , sent from the reader to the server,

sent from the server to the reader,

sent from the reader to the tag,

For example: Now the combination of Eqs. (5), (10), reveals a bit of , as follows: Given that will not be updated at the end of the session, it can be used to compromise the tag’s anonymity and trace the tag holder in any session.

Similarly, and from and Eqs. (7), (9), (11) we can disclose , which combined with Eq. (12) reveals two bits of and also .

The success probability of disclosing all values mentioned in this section is ‘1’ and the complexity is only eavesdropping one session of the protocol.

In Fig. 5, a toy example of calculation of when , , and is provided. Following this example, . On the other hand: see equations in Box I.

Fig. 5

A toy example of calculation of .

Which shows that as it is expected from Eq. (5), . In this way, the adversary could extract one bit hidden information.

Full secret disclosure attack

The secret parameters of SecLAP are , and , where and are constant values while is a dynamic value which is updated after each successful run of the protocol. Most of the transferred messages are masked by and produced by , which is more complicated than the used by Fan et al. Hence, designers of SecLAP expect decent protocol security against secret disclosure attacks. However, we present an attack to extract those secret parameters efficiently. Despite the designers’ claim that SecLAP is secure even against an active adversary – with full control over the channel between the tag and the reader and the reader and the server – we consider the weakest adversary who can only eavesdrop the channel between the tag and the reader, let alone the server and the reader. To initiate the attack, we assume that the adversary eavesdrops any transferred message from the tag to the reader or from the to in session ; this is known as the learning phase of the attack. Hence, at the end of this learning phase, the adversary very likely has the following information:

sent from to ;

and and sent from to ;

and sent from to ;

and sent from to ;

sent from to ;

On the other hand, from the definition of we know that the while is used to produce the even bits of . Hence, we can argue that any bit of the output, , is a linear function of a bit from with either a bit from or a bit from , i.e. , where , , and . However we may not know the exact value of and , from the definition of , we know that if is an odd value then will also be an odd value while will be even and if is an even value then will also be even while will be odd. In addition, if then , for any , obviously addition takes place module . In addition, given and in , we can uniquely determine related values of and . It comes from the fact that while . Therefore, given to extract -linear equation out of , the only unknown parameter will be and , which has the total complexity of . In the rest of the paper, we use odd-offset and even-offset to denote and respectively. Now, given the eavesdropped and from a session of the protocol and the above properties of , the adversary uses the below procedure to extract the secret parameters of SecLAP:

for :

for :

;

;

for :

for :

;

;

Steps 2a, 2b, 2(d)i and 2(d)ii produce linear equations while the unknown parameters are and . Hence, the adversary uses linearly independent equations to determine and and the rest of equations to filter wrong guesses.

return the candidate and and .

Given that , , and the returned and should also pass.

The above attack has the complexity of time solving a linear equation with equations of independent variable. Hence, it is expected to do not return any candidate exclude the correct pair of and in Step 2(d)iv. However, any possible wrong guess also filtered in Step 3. Given that any wrong guess passes Step 3 with the probability of , the algorithm will return the correct value of and . Next, given and and also the eavesdropped the adversary extracts and calculates as . The adversary can also use other eavesdropped messages, i.e. , , and to filter any possible wrong guess.

Because the computational complexity of solving a system of linear equation of variables has the complexity of , the expected complexity of extracting , and is . For , the adversary will be able to extract those secret parameters with the complexity of , while the expected complexity is at least , which shows a huge gape.

It should be noted that since the channel between the reader and the server is also insecure, the adversary can eavesdrop . Assuming that the adversary has already disclosed and , it can easily also extract . Similarly, the adversary can use to extract which – along with other known parameters – can be used to construct . In this way, the adversary reveals the entire secret parameter of the protocol with the computation complexity of with only one eavesdropping session of the protocol between the parties, i.e. tag, reader, and server.

Traceability attack

In Section 3.2, we presented an attack where any passive adversary who eavesdrops the transferred messages of a session of the protocol between the legitimate tag, the reader, and the server will be able to extract , , and with the complexity of . Given that and are constant values for any tag/reader and will not be updated after the protocol completion, they can be used to trace the tag/reader, which contradicts the designers’ claim.

Distinguishability in ROM

In this section, we show that SecLAP is not also a secure protocol in ROM. To distinguish SecLAP from ROM we use the observation used to partial recover secret parameters in Section 3.1. From the structure of the messages one can deduce that:

This property can be used as a metric to determine that the used protocol is SecLAP and not .

To distinguish SecLAP from , the adversary does as follows:

eavesdrops messages of a session of the given protocol, transferred over the channel.

evaluates Eq. (13) and returns if it is true; otherwise returns .

To determine the adversary’s advantage, it is clear if the adversary communicates with SecLAP then with the probability of ‘1’ returns in Step 2 while if it communicates with then returns with the probability of ‘2−1’. To improve the adversary’s advantage, we can increase the number of eavesdropped sessions. For an adversary who eavesdropped sessions, the advantage will be as follows:

which is the maximum advantage that an adversary can get after queries. It should be noted that the other combinations of transferred messages can also be used for distinguishing SecLAP from ROM. For example:

An interesting point with Eq. (14) is the fact that to distinguish the protocol the adversary only requires to eavesdrop the channel between the tag and the reader. It is clear that the adversary can use both Eqs. (13), (14) (and several other combinations) to achieve same advantage with eavesdropping less number of sessions. Therefore, SecLAP has security flaws in ROM.

Authenticated encryption

Given that the improved protocol in Section 5 uses an AE-based encryption module, in this section we provide a brief introduction to this concept. The common approach to provision of confidentiality and integrity in a communication process is to use a secure encryption scheme and a secure message authentication code (MAC) respectively. Authenticated encryption (AE) provides these two security objectives simultaneously. An important objective in using an AE scheme as opposed to a simple encryption function is to prevent message forgery. By adding an authentication service to the message, the received ciphertext is not accepted as it is and will be verified to determine whether it has been manipulated or forged. Encrypt-then-MAC, Encrypt-and-MAC and MAC-then-Encrypt are traditional approaches of AE scheme designs. Unfortunately, these methods are inefficient, as they use two separate keys, one for encryption and another for authentication [33].

An AEAD scheme is an AE model which supports associated data (AD) also. Associate data is part of the transferred information, for which confidentiality may not appear important but integrity in this element is nonetheless necessary, e.g. with headers or routing information. As shown in Fig. 6, the AEAD takes a plaintext of an arbitrary length upper-bounded to a fixed value, a key, and a nonce, and produces a ciphertext and a MAC-value. Its encryption and decryption functions are respectively as follows, where are key, nonce, associated data, plaintext, ciphertext, and MAC-value, respectively. MAC generator is a built-in component of an AEAD module that generally receives the output of the last step of an encryption process and transforms data by some simple operations. In most AEAD schemes, if the MAC-value () is verified then the decryption function returns the plaintext ; otherwise it returns an error symbol, e.g. .

Fig. 6

General structure of an AEAD module.

To design a secure AEAD scheme for different applications, in 2014 a competition entitled CAESAR (Competition for Authenticated Encryption: Security, Applicability, and Robustness) was created [34], which was a competition to promote research related to authenticated encryption and to boost the understanding of AE in the cryptographic research community. Such competitions have a long and promising story in the field of symmetric cryptography, e.g. AES [35], eStream [36], SHA3 [37], and PHC [38]. It should be noted that NIST [39] has also begun a competition for standardization of lightweight AE and hash function schemes for which the candidates of its second round were announced September 9, 2019. A secondary aim of the CAESAR competition was to design a dedicated AEAD scheme which could be more resource-efficient than conventional approaches. A dedicated scheme would indicate an AE module that needs only one key for encryption and MAC processes. The first round of CAESAR received 57 submissions, and all of them have been confirmed as approved candidates. After almost five years of analysis and comparisons by independent researchers, following the last round in 2019, six designs were been selected as the final portfolio to be implemented here in our protocol. As shown in Table 2, the selected designs were classified into three use-cases, (i) lightweight applications; (ii) high-performance applications; and (iii) defense in depth.

Table 2

CAESAR Competition final portfolio [34].

Use-case category	CAESAR finalist candidates
Lightweight applications	ACORN [40] & ASCON [41]
High-performance applications	AEGIS-128 [42] & OCB [43]
Defense in depth	COLM [44] & Deoxys-II [45]

AE-based improved protocol

In order to overcome the security flaws of previous protocols, in this section we propose an AE-based authentication protocol. The goal of using an AE module is to achieve a higher security level (i.e. confidentiality and integrity simultaneously) rather than previous protocols with reasonable hardware and communication cost. The notations employed from the improved protocol have been listed in Table 1. Since the structure of this protocol is based on an AEAD design with single-key, the stored information in the header is not encrypted and the sender could transfer some general values via this route. In addition, by using only one key for encryption and integrity processes, the structure of the protocol and the tag could be simpler. To gain a deeper understanding of the counterfeiting scenario in the introduction, an authentication process for a COVID-19 test kit in a hospital is considered. Hence, we assume each kit has been equipped with an RFID tag and the nurse uses an RFID reader to detect the tag and check its authenticity. Our proposed protocol has two phases and functions as follows:

Initialization phase

In this phase, the default values of the parameters are stored into the parties (Tag, Reader, and Database) and the encryption key is shared. In the database there is a record for each tag that consists the set , where and respectively denotes the old and the new tag’s parameters. These values are updated after each successful session of the protocol and are initially blank. is also stored in the tag. The database could be local and integrated with the reader or a dedicated server with remote access.

In Fig. 7, we assume the reader hosts the local database; in the security analysis section, we discuss two different situations.

Fig. 7

Authentication and key agreement phase of the improved protocol.

Authentication phase

When a nurse wants to use a kit, she has to activate the reader and the following steps must be taken.

The reader generates a random number , and sends and Hello message to the embedded tag in the kit.

Upon receiving the messages, the tag generates as a nonce and computes as and its using an AEAD scheme, actually the output of the AEAD scheme will be and is the ciphertext. The random number is used in the AD part of the message and the tag sends to the reader.

When the reader receives the messages, given , looks up the database, finds related , decrypts and verifies the received to authenticate the tag.

It then generates and updates the tag’s records as , , , – and have same length– and updates its database accordingly. It worth noting is used in the AD segment and is XORed with the ciphertext part,

Since the tag has the required parameters to compute and in order to decrease the communication cost, the reader only sends the generated and to the tag.

After receiving the messages, the tag computes and verifies the received . If the comparison holds, the tag authenticates the reader and updates its to and to . Therefore, the mission is completed and the kit is valid; otherwise it terminates the session.

Security analysis of the improved protocol

The following section describes the security evaluation of the improved protocol. Both informal and formal methods are utilized to prove that the proposed protocol is resistant against various kinds of IoT threats. In terms of the informal evaluation, the protocol robustness is analyzed against various attacks such as traceability, replay, and disclosure. In addition, the formal evaluation is performed by a manual as well as an automated method, which will be introduced later.

Informal security analysis

In order to assess the resistance of the improved protocol based on the informal method, we present an adversary model with some assumptions. We consider that the adversary has access to communication channels and can eavesdrop all transferred messages. She can intercept the line and transfer her packets to the tag or the reader. In addition, she is able to run all functions – such as PRNG and encryption – without having access to secret keys.

Traceability attack

To perform the traceability attack on a protocol, the adversary needs an instant and fixed value to detect a tag in various situations. In the proposed protocol, the tag transfers and that is randomized by and and is also updated after each successful session of the protocol. Although, as far as the tag has not participated in a successful session of the protocol, is constant and could be used to trace the tag, however, it is not possible to use it to do traceability attack after a successful session of the protocol. It should be noted is used to provide scalability in the proposed protocol. In this way, the reader finds the related tag in its database in constant time, independent of the number of tags that are covered by the reader. If After receiving a new Hello message with an iterative , the tag typically generates a fresh and calculates a new ; consequently the adversary could not find the similarity among different messages from a tag and the protocol is resistant against the traceability attack, assuming that it has participated in a successful session. It worth noting that it is possible to drop in the sent message by the tag. Thereby, the adversary will not be able to trace the tag even if the tag has not participated in a successful session, because it sends and , and and the are randomized by and . However, in this case the reader must do an exhaustive search in its database to find the target tag, which is not scalable.

Secret disclosure attack

The secret disclosure attack occurs when the tag or the reader is unable to protect confidential information (e.g. encryption keys or identification numbers) against unauthorized users. In the improved protocol, the confidential and important tag’s parameters are and . Hence, if the attacker has access to them or is able to reveal them, she can potentially have full access to the system. Given that all transferred messages on a public channel will be encrypted by an AE-based algorithm and the important parameters are not sent as a cleartext, if the attacker eavesdrops transferred packets, useful information about confidential values cannot be found and the probability of revealing information is negligible. Therefore, the proposed protocol is not vulnerable to the secret disclosure attack.

Replay attack

To implement the replay attack on a protocol, the adversary needs to store what is being exchanged on a channel and later sends to the same tag or reader as a valid response without knowing the content of the message itself. To prevent this attack in the improved protocol, both parties must transfer fresh data. Hence, two random numbers and guarantee the freshness of and messages. If the adversary eavesdrops the transferred messages in a valid session and sends this to the reader as a legitimate tag, when the reader checks the validity of based on a fresh , the comparison does not hold. In addition, due to using a fresh in the tag’s side, the replay attack is also impossible on the tag. Therefore, we can claim that the improved protocol is resistant against the replay attack.

Back-end channel security

As mentioned earlier, the communication channel between the tag and the reader is public and the adversary is able to capture transferred messages. The implementation concerning the back-end channel between the reader and the server could adopt one of two possible models. The channel could be private and the adversary would thus have no access to it, or it could be considered as a public channel. Because a modern reader like the ZEBRA MC3390R handheld RFID reader has powerful hardware components (e.g. 1.8 GHz hexa-core 64-bit Processor, up to 4 GB RAM, and Android operating system), it can support all encryption algorithms and can establish a VPN (Virtual Private Network) connection. Therefore, by assuming a public channel between the reader and the server in the improved protocol, the transferred messages are protected and the protocol remains secure. Furthermore, whether the database server is local or cloud-based has no significant impact on the improved protocol security.

Formal analysis

While in Section 6.1 we heuristically proved the security of the improved protocol against various attacks, in this section we use formal approaches to validate the robustness. To evaluate the security of a cryptography protocol, several formal methods are available from literature, which are either manual, such as GNY logic [46] and BAN logic [47] or automatic such as Scyther [48], AVISPA [49], Proverif [50] and CryptoVerif [51]. Among them, in this section, we use GNY logic – as a manual method – and Scyther tool – as an automated method – to analyze the security of the improved protocol formally, and both are widely accepted in literature to validate the security of a cryptographic protocol formally (e.g. see [52], [53], [54]).

Formal security evaluation through GNY logic

According to Table 3’s notations, the robustness of the improved protocol is deduced as below:

Table 3

GNY logic notations and logic rules in this paper.

Notations	Description
♯(X)	X is fresh
(X,Y)	Combination of two formula X and Y
〈K〉	Shows K is a secret parameter
{X}_K	X is encrypted using K as the key
P◃X	P receives X
P⟷KQ	K is securely shared between P and Q
P∋K	P possesses K
ϕ(X)	X is recognizable
∗(X)	X was not originated by the party who receives it.
F1:P|≡♯(X)P|≡♯(X,Y),P|≡♯(F(X))	Means that if P believes freshness of X, then it deduced that P believes freshness of any formula of X.
F10:P|≡♯(X),P∋XP|≡♯H(X)	Means that if P believes freshness of X and P possesses X, then it deduced that P believes freshness of any one-way formula of X i.e. H(X).
P2:P∋(X),P∋(Y)P∋(X,Y),P∋F(X,Y)	Means that if P possesses X and Y, it also possesses any formula of them.
I3:AB, where A:P◃∗H(X,〈S〉),P∋(X,S),P|≡P⟷SQ, P|≡♯(X,S) and B:P|≡Q|∼(X,〈S〉),P|≡Q|∼H(X,〈S〉)	Means that if P receives an one-way formula of X and a secret parameter S which was not originated by itself, and he possesses X or S and he believes S is a shared secret between itself and Q, and also believes freshness of X or S, then it is deduced that P believes Q sent a formula of X with S, and also believes Q sent the one-way formula of X and S i.e. H(X,〈S〉) .

The messages of the improved protocol are rewritten using GNY logic notations, as represent in Table 4.

Table 4

Improved protocol messages’ GNY logic expression.

# M.	Description
M1	T_i◃Hello,N_1R
M2	R_j◃M1={ID_t_i,N_1R,N_1t}_K_t_i,IDS_t,N_1t,MAC(N_1R,ID_t_i,N_1t,IDS_t,〈K_t〉)
M3	T_i◃N_2R,MAC(N_2R,N_1t,N_1R,IDS_t,〈K_t〉)

The plain messages are deleted that Table 5 shows the output.

Table 5

Improved protocol messages’ idealization (M. denotes Message).

# M.	Description
IM2	R_j◃M1={ID_t_i,N_1R,N_1t}_K_t_i,MAC(N_1R,ID_t_i,N_1t,IDS_t,〈K_t〉)
IM3	T_i◃MAC(N_2R,N_1t,N_1R,IDS_t,〈K_t〉)

The improved protocol’s assumptions and goals are extracted, as represented in Table 6.

Table 6

Assumptions and security goals of improved protocol (A./G. denotes Assumption/Goal).

# A./G.	Description
A1	R_j|≡♯N_1R
A2	R_j∋N_1R
A3	R_j|≡ϕ(N_1R)
A4	R_j|≡♯N_2R
A5	R∋N_2R
A6	R_j|≡ϕ(N_2R)
A7	T_i|≡♯N_1t
A8	T∋N_1t
A9	T_i|≡ϕ(N_1t)
A10	R_j|≡R_j⟷K_t,ID_t_i,IDS_tT_i
A11	T_i|≡T_i⟷K_t,ID_t_i,IDS_tR_j
A12	R_j∋K_t
A13	R_j∋ID_t_i
A14	R_j∋IDS_t
A15	T_i∋K_t
A16	T_i∋ID_t_i
A17	T_i∋IDS_t
G1	R_j|≡T_i|∼MAC(N_1R,ID_t_i,N_1t,IDS_t,〈K_t〉)
G2	T_i|≡R_j|∼MAC(N_2R,N_1t,N_1R,IDS_t,〈K_t〉)

Given messages and protocol assumptions and using GNY logic rules, we deduce security goals as depicted in Table 7.

Table 7

Security goals deduction of the improved protocol.

DN	GMA	UR	DD	GN
D1	A1	F1	R_j|≡♯(N_1R,ID_t_i,N_1t,IDS_t,〈K_t〉)	−
D2	A2, A12, A13, A14	P2	R_j∋(N_1R,ID_t_i,N_1t,IDS_t,〈K_t〉)	–
D3	D1,D2	F10	R_j|≡♯MAC(N_1R,ID_t_i,N_1t,IDS_t,〈K_t〉)	–
D4	IM1, D3, A10, D1	I3	R_j|≡T_i|∼MAC(N_1R,ID_t_i,N_1t,IDS_t,〈K_t〉)	G1
D5	A7	F1	T_i|≡♯(N_2R,N_1t,N_1R,IDS_t,〈K_t〉)	−
D6	A8, A15, A16, A17	P2	T_i∋(N_2R,N_1t,N_1R,IDS_t,〈K_t〉)	–
D7	D5,D6	F10	T_i|≡♯MAC(N_2R,N_1t,N_1R,IDS_t,〈K_t〉)	–
D8	IM2, D7, A11, D5	I3	T_i|≡R_j|∼MAC(N_2R,N_1t,N_1R,IDS_t,〈K_t〉)	G2

As presented in Table 7, according to rule of GNY logic and considering , we deduce that . Then, using and based on rule , it is deduced that . Given and based on rule , since is one-way function we deduce that . Considering and based on rule , it is deduced that which is the security goal. guaranties the integrity of the messages which are sent by through the insecure channel. According to rule of GNY logic and considering , we deduce that . Then, using and based on rule , it is deduced that . Given and based on rule , since is one-way function, we deduce that . Considering and based on rule , it is deduced that which is the security goal.Similar to , guaranties the integrity of the random number , which is sent by .

Formal security evaluation through Scyther tool

The Scyther tool as an automated security evaluation method is also considered as part of this analysis. The evaluation begins with the description of the improved protocol in the Security Protocol Description Language (SPDL) as the input for the Scyther tool. As Fig. 8 depicts, there is no security breach in the verification results and the robustness of the protocol has been confirmed.

Fig. 8

Security results of improved protocol through the Scyther tool.

In reliance on the analysis results and security breaches reported for previous protocols, Table 8 compares the robustness of the improved protocol to other protocols against traceability, desynchronization, replay and secret disclosure attacks. As shown, the AE-based protocol can resist against attacks and has an acceptable security level.

Table 8

Comparison of resistance to different attacks.

Protocols	Liao and Hsiao [20]		Zheng et al. [18]		Fan et al. [27]		SecLAP [29]		AE-based
Resistance to traceability attacks	No		No		No		No		Yes
Resistance to desynchronization attacks	No		No		No		No		Yes
Resistance to replay attacks	No		No		No		No		Yes
Resistance to secret disclosure attacks	No		Yes		No		No		Yes

Hardware implementation

In order to better understand the impact of using different cryptography schemes on the proposed protocol, the FPGA and ASIC implementation of a tag were simulated. By the FPGA implementation, the very low-level information and fundamental building blocks of a proposed tag (e.g. Lookup Table (LUT) and Flipflop) were measured. In addition, ASIC implementation was also simulated, with the intention of having the manufacturing technology information and Gate Equivalent (GE) comparison.

For FPGA implementation, Vivado 2017.7 synthesis tool of Xilinx has been employed to synthesize the proposed cryptography algorithms on spartan-7 FPGA family of Xilinx of which Table 9 shows the results. However, as the aim of the proposed protocol is to introduce a new lightweight authentication protocol, the hardware implementation was simulated for five CAESAR finalist candidates with different use-cases. Namely, ACORN and ASCON from the lightweight use-case, OCB and AEGIS-128 from the high-performance category, and COLM from the defense-in-depth use-case have been selected. As an example, the schematic model of ACORN has been illustrated in Fig. 9 consisting of the encryption module, PRNG, XOR, and Concatenation functions, and the hardware implementation result is based not only on the encryption module but also covers a group of all mentioned components.

Table 9

FPGA and ASIC implementation results, where SM and AE-P denote Security-module and AE-protocol respectively.

Encryption scheme	FPGA		ASIC
	LUT	FlipFlop	Area (μm^2)	Delay (ns)	Power (mW)	GE (SM)	GE (AE-P)
ACORN	731	476	23 321.49	1.42	1.003	3338	6743
ASCON	1540	980	41 962.73	0.59	1.167	12 157	15 565
AEGIS-128	5582	1970	110 996.52	1.71	7.396	38 934	42 342
OCB	4124	1699	245 625.71	0.62	5.869	71 966	75 374
COLM	7535	2771	276 981.16	0.61	4.690	107 810	111 218

Fig. 9

Schematic model of ACORN circuit.

In addition, the key-length and data-length of the encryption module have been considered, at 128-bit and 64-bit respectively. As shown in Table 9, in terms of the area of FPGA simulation, two lightweight candidates show the least LUT and are suitable for designing alightweight tag.

For ASIC implementation, the CMOS 90 nm technology was used in 1-round. The implementation target was set to reach a minimum area and maximum performance. Hence, the number of gates (GE), area overhead, power consumption, and delay are reported in Table 9.

By using ACORN, a given tag totally needs to accommodate 6743 gates for all components (named AE-Protocol) that 3408 gates are used to implement PRNG and logical functions, and 3335 gates for the ACORN cryptography module (named Security-module). It is worth noting that 3335 gates are the total amount of a complete encryption module, including cipher core, pre-processor and post-processor. The results of other encryption schemes are listed in Table 9 and it is clear that the proposed protocol could be applicable in different domains and applications.

In order to have a clearer picture of the tag’s weight and required area on a chip, Fig. 10 compares five candidates based on LUT and GE.

Fig. 10

Area Comparison based on FPGA and ASIC results.

As expected – and as shown in the chart – both CAESAR lightweight schemes (i.e. ACORN and ASCON) utilize the least amount of hardware circuits to implement an RFID tag. However, the number of LUT of the new protocol is greater than LUT in Fanet al. and SecLAP, a lightweight tag needs roughly 3K to 4K GE for the security module [55]. Hence, the proposed protocol can satisfy the lightweight requirements and the results prove that it is applicable in other domains of IoT with minimum resource consumption.

Discussion and conclusion

At the starting point of this paper, we have looked at illicit trade in fake goods as a major challenge in the global economy, and discussed IoT technologies as a mean to combat this risk and help maintain a secure supply chain. While the presented scenario relies on compromising the supply chain integrity for COVID-19 test kits, the reader is aware that the same malicious attacks could be conducted in any supply chain; raising the importance of securing the supporting IT infrastructure.

Within the scope of this paper, we have focused on the data capture/sensing layer of an IoT infrastructure and explored the recent development of secure authentication and communication protocols to prevent malicious attacks. Accordingly, we have presented a traceability and passive secret disclosure attacks against the studied protocols (e.g. SecLAP) where we extracted all secret parameters with the complexity of . In fact, attempting to increase the robustness of current protocols by improving the way messages are calculated, while keeping their basic structure would just provide incremental improvements, and would not prevent ways to break them. By their nature, we believe that the weak-point of ultra-lightweight protocols is the structure of bit-oriented functions. Therefore, we proposed an AE lightweight uncomplicated improved protocol that employs a cryptosystem able to satisfy the hardware requirements of lightweight tags. Informal and formal security evaluations to show the robustness of the protocol were also provided. The security analysis and hardware implementation results were also presented to validate our work. More specifically, we simulated the structure of a tag (FPGA and ASIC) under five encryption schemes and measured its hardware requirement as a candidate for constrained environments. While the scope of the discussion was limited to passive UHF RFID technologies, similar research may be conducted for ensuring the data integrity gathered from other technologies used (a) in different activities of a supply chain (b) at all the layers of the supporting IoT infrastructure. For instance, for the data capture/sensing layer, numerous competitive technologies and techniques are available to develop counterfeit-proof packaging. For instance, passive HF RFID tags for NFC (Near Field Communications) are increasingly used in retail applications for security purposes as well as a means to interact with customers. Otherwise, with billions of bar codes scanned every day one can rightly argue that automatic recognition technologies such as bar codes should be considered as a stand-alone or as a complementary technology to prevent counterfeiting. This is particularly true for innovative covert bar codes using inks that fluoresce when exposed to ultraviolet (UV) or infrared (IR) light. Since they cannot be detected or duplicated by commonly available methods, covertly printed two-dimensional (2D) QR or Data Matrix codes can be used to replicate the ID encoded in the RFID tag applied or integrated into the packaging. At the point of use, there is therefore a need to have a reader equipped with an RFID module as well as a UV–IR lighting module to illuminate and decipher the code using the proper decoding algorithms. More recently we have also witnessed the availability of invisible bar code hidden into colored surfaces (e.g. Digimarc Barcode) that carries the same data as 2D Data Matrix codes and repeated across the entire surface of thermal-printed labels. With the compatibility of numerous cameras and scanners, existing reading devices would then need to be upgraded by installing the required automatic content recognition software to unlock the code and verify it. This last step can also be done using a track & match application with related information hosted on an IoT platform. Otherwise, security issues of “less constrained devices” could be explored, including electronic data loggers used to verify the end-to-end condition compliance in a distribution channel or active RFID tags used for wireless monitoring of environmental fluctuations with real-time alert capabilities. These devices rely on other technologies and use other authentication and communication protocols, but all of them may be vulnerable to security breaches. Whatever the selected identification–authentication technology, stakeholders may also want to track the progress of the products (i.e. COVID-19 kits) throughout the supply chain, using ubiquitous cloud based-IoT traceability platforms. As these platforms constitute another layer in the IoT Infrastructure (Fig. 1), they are used to store critical information and prevent counterfeit and pirated goods, but, they may themselves constitute another target in the design of a secure solution. This has raised higher requirements for data encryption, and the design of secure public key encryption schemes for securing sharing of sensitive data in the cloud [56], [57] as well for the development of lightweight AE scheme to prevent unauthorized data manipulation (i.e. data integrity) and access to information hosted on the cloud (i.e. data confidentiality) [58], [59] Security and privacy become even more important, as healthcare organizations are increasingly targeted by cyberattacks leading experts to call for national standards in “battle” against healthcare data security breaches [60]. In this context, this is no surprise that the Canadian Centre for Cybersecurity released a warning that the COVID-19 pandemic presents an elevated level of risk to the cybersecurity of Canadian health organizations involved in the national response to the pandemic [61]. But while organizations are warned to apply cyber defense best practices, they mainly analyze their monitoring of network logs, monitor the behavior of their servers, and address security vulnerabilities as they discover them — but they never look at the thousands of sensors evolving in their own ecosystem.

CRediT authorship contribution statement

Masoumeh Safkhani: Conception and design of study, Acquisition of data, Analysis and/or interpretation of data, Writing - original draft, Writing - review & editing. Samad Rostampour: Conception and design of study, Acquisition of data, Analysis and/or interpretation of data, Writing - original draft, Writing - review & editing. Ygal Bendavid: Conception and design of study, Acquisition of data, Analysis and/or interpretation of data, Writing - original draft, Writing - review & editing. Nasour Bagheri: Conception and design of study, Acquisition of data, Analysis and/or interpretation of data, Writing - original draft, Writing - review & editing.

Declaration of Competing Interest

No author associated with this paper has disclosed any potential or pertinent conflicts which may be perceived to have impending conflict with this work. For full disclosure statements refer to https://doi.org/10.1016/j.comnet.2020.107558.