FLAT: Federated Lightweight Authentication for the Internet of Things

Ad Hoc Networks 107 (2020) 102253

Contents lists available at ScienceDirect

Ad Hoc Networks

journal homepage: www.elsevier.com/locate/adhoc

FLAT: Federated lightweight authentication for the Internet of Things

Maria L.B.A. Santos a, Jéssica C. Carneiro a, Antônio M.R. Franco a, Fernando A. Teixeira b, ∗ Marco A .A . Henriques c, Leonardo B. Oliveira a, a UFMG, Belo Horizonte, Brazil b UFSJ, Ouro Branco, Brazil c Unicamp, Campinas, Brazil

a r t i c l e i n f o a b s t r a c t

Article history: Federated Identity Management schemes (FIdMs) are of great help for traditional systems as they improve Received 3 March 2020 user authentication and privacy. In this paper, we claim that traditional FIdMs are mostly cumbersome

Revised 2 June 2020 and then ill-suited for IoT. As a solution to this problem, we came up with Federated Lightweight Au- Accepted 16 June 2020 thentication of Things (FLAT), namely a federated identity authentication protocol exclusively tailored to Available online 26 June 2020 IoT. FLAT replaces weighty protocols and public-key cryptographic primitives used in traditional FIdMs by Keywords: lighter ones, like symmetric cryptographic primitives and Implicit Certificates. Our results show that FLAT Internet of Things can reduce the data exchange overhead by around 31% when compared to a baseline solution. Also, the security FLAT Client, the role played by an IoT device in the protocol, is more efficient than the baseline Client authentication in terms of data exchange, storage, memory, and computation time. Our results indicate that FLAT runs federated identity management efficiently, even on top of resource-constrained devices like Arduino. ©2020 Elsevier B.V. All rights reserved.

1. Introduction Federated Identity Management (FIdM) [7] , in turn, improves the IdM idea by enabling a domain to control accesses to its re- The development of the Internet of Things (IoT) [1–3] is a na- sources from external users. For instance, it allows an external tional priority in several countries around the world and is signif- user to authenticate to a local server and utilize its services with- icantly impacting our society. Studies suggest that we are already out having to create an identity or register credentials locally. In- surrounded by 20 billion IoT devices. 1 The IoT development has en- stead, the authentication process between the user and the Ser- abled a diverse number of applications in academy and industry. vice Provider (SP) is mediated by the Identity Provider (IdP) of the When it comes to IoT, one of the most signiﬁcant challenges user’s home domain. FIdM, hence: to its full realization lies in the ﬁeld of Identity Management • enables applications like Single-Sign-On (SSO);

(IdM) [4]. IdM refers to the identiﬁcation of users in a given system • increases privacy by limiting the amount of information shared;

(e.g., a network, application, or service) and controlling their ac- • and improves the end-user experience and security by elimi- cess to resources within that system. (Here, the term identiﬁcation nating the need for new accounts registration and restricting means the process for authenticating the identity of a user [5]). the number of entities that hold their password. Ideally, IdM provides administrators with the tools to manage the full user’s identity life-cycle (e.g., setup, maintenance, and tear Fig. 1 illustrates how traditional FIdM works. The Client initi- down) and, thus, are vital to the security and productivity of or- ates communication with the SP ( Fig. 1 , step 1). The SP, in turn, ganizations. redirects the Client to the IdP (step 2). Next, the Client requests an assertion (or token) to the IdP (step 3) and authenticates itself to the IdP by presenting its credentials (steps 4 and 5). The IdP, in ∗ Corresponding author. exchange, sends the assertion to the Client (step 6). This assertion E-mail addresses: [email protected] (M.L.B.A. Santos), is then used by the Client to get access to the SP service (steps [email protected] (J.C. Carneiro), [email protected] (A.M.R. Franco), 7 and 8). All these steps are normally protected and authenticated [email protected] (F.A. Teixeira), [email protected] (M.A.A. Henriques), by public key infrastructure certiﬁcates, which have to be validated [email protected] (L.B. Oliveira). by all participants. 1 https://www.gartner.com/en/newsroom/press-releases/

2017- 02- 07- gartner- says- 8- billion- connected- things- will- be- in- use- in- 2017 So far, unfortunately, IoT technology cannot fully enjoy the ben- - up- 31- percent- from- 2016 eﬁts of either IdM or FIdM. This is so because both IdM or FIdM https://doi.org/10.1016/j.adhoc.2020.102253 1570-8705/© 2020 Elsevier B.V. All rights reserved. 2 M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253

Fig. 1. Traditional FIdM (adapted from Birrell and Schneider [6] , Figure 2).

widely adopted approaches are inadequate to IoT [8] . First and We describe FLAT development Section 7 , discuss its per- foremost, there is no such thing as IdM for IoT devices. Instead, formance ﬁgures ( Section 8 ), and then sum up our ﬁndings in existing (F)IdM schemes, IoT devices make use of credentials ( Section 9 ). of individual (human) users to log on and enjoy domain services.

However, this is both insecure and inappropriate as devices should 2. Background not have the same clearance level as users, and some IoT devices just cannot be naturally linked to any individual user. For exam- This section introduces some necessary concepts related to ple, what user should a light traffic system be running as?). Sec- FLAT, including the characterization of IoT devices, fundamental ond, the IoT mobile nature and dynamics urge a higher level of concepts in FIdM, and some cryptosystems used in the solution. scalability and interoperability across multiple domains when compared to conventional network elements [8] . And last but not least, 2.1. IoT the authentication process on existing (F)IdM schemes typically build upon the login/password paradigm, which is usually okay Society is experiencing an increasing number of connected de- for humans but ill-suited for devices [9] , and leverage expensive vices: smartphones, sensors, and computers can communicate and RSA/DSA cryptosystems, hence, incurring significant computational cooperate to perform specific tasks [1] . In this sense, IoT is a net- resources overhead [10] . So, there is patently a dire need for a work of everyday objects with certain capabilities communicating FIdM able to meet IoT special needs. to reach a specific goal [13] . As a solution to this problem, we propose a FIdM protocol ex- There are numerous possibilities in IoT, including applications clusively tailored to IoT called Federated Lightweight Authentica- in several different domains such as healthcare, transportation, tion of Things (FLAT) 2. In short, we design, developed, and eval- smart cities, smart homes, agriculture, and traffic management [2] . uate a lightweight authentication protocol well-suited for IoT-like Undoubtedly, IoT can bring a series of advantages and enhance- devices based on Federated Identity. By lightweight, we mean FLAT ments to businesses and also increase the comfort and quality of replaces cumbersome protocols and costly public-key cryptosystem services. The possibilities brought by IoT have caught the attention operations used in traditional FIdM by more efficient ones. This of the scientific community, hence making IoT a research topic of lightnness , in turn, enables even highly resource-constrained IoT general interest. devices to participate in a federation and then to enjoy its ben- Among several open research topics in IoT, there are privacy, efits. Our key insight while conceiving FLAT was to combine sym- standardization, and authentication [1] . FLAT approaches exactly metric cryptosystems and Implicit Certificates [12] synergistically. the authentication issue in IoT, considering the lack of computa- Additionally, we built a prototype of FLAT and evaluated its perfor- tional resources and the potential mobility of devices, as well as mance and security. Our results indicate that FLAT runs efficiently other inherent aspects of IoT that are not present in the traditional on top of constrained devices like Arduino Due. Internet. This paper is organized as follows. We first present the concepts necessary to understand the authentication solution ( Section 2 ) and discuss the related work ( Section 3 ). 2.2. IoT Devices Next, we argue the need for lightweight cross-domain authentication schemes ( Section 4 ). As the IoT devices contemplate environments with very differ- Then, we present how FLAT meet this need ( Section 5 ) and ent needs, these devices also have diverse characteristics, varying evaluate the security of the protocol ( Section 6 ). in size, type, and computational capabilities. Some devices have very low computational and storage capabilities, so protocols and processes executed by these devices must

2 Santos et al. [11] introduced FLAT ﬁrst concepts and preliminary results. be lightweight. Here, this kind of IoT devices is referred to as re- M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253 3

Fig. 2. IdM main operations.

Table 1 users and devices to these resources and manages the entire life-

Examples of IoT devices. cycle of users’ (and devices’) digital identities [14] . Digital iden- Class Device CPU(GHz) SRAM(MB) Flash(GB) tity, in turn, is a set of attributes or any other data that together

− − − can uniquely identify one entity (user, device, institution), usually restricted Memsic IRIS 8.0 x 10 3 7.8 x 10 3 1.2 x 10 4 − − − Arduino Mega 1.6 x 10 2 7.8 x 10 3 2.4 x 10 4 proven through the use of credentials [14]. 2560 According to Nogueira et al. the main operations of an IdM sys- − − Arduino Due 8.4 x 10 −2 9.4 x 10 2 4.9 x 10 4 tem are: (i) identiﬁcation, (ii) authentication, (iii) authorization and

intermediary Raspberry Pi 1.0 512.0 until 32.0 (iv) auditing [15] . Identiﬁcation provides an identity to the system. Zero W

BeagleBone 1.0 512.0 4.0 Authentication, in turn, occurs when the system verifies the iden- Black tity using the credentials. The process of authorization involves granting privileges to an entity after authentication. Auditing is registering the actions of an entity in the system. stricted devices. As Table 1 shows, devices such as Memsic IRIS 3 , For instance, imagine a user would like to access a technical re- Arduino Mega 2560 4 and Arduino Due 5 are in this category. port provided by a technology company ( Fig. 2 ). This user would Some other devices do not have major resource constraints, present her credentials to the company’s system to be identified with flash memory in gigabytes and higher CPU speeds. These IoT (step 1, Fig. 2 ). These credentials will be sent to the authentication devices are referred to here as intermediary devices. Raspberry Pi process (step 2, Fig. 2 ), where it will verify if the user is legiti- Zero W 6 and BeagleBone Black, 7 shown in Table 1 , are in this cat- mate, i.e., if the user is genuinely who she claims she is. After the egory, both with 512 MB of SRAM. The flash memory in Raspberry authentication process, the system will check the access privileges Pi Zero W is variable, but there is support for up to 32 GB, while of the user (authorization process, step 3, Fig. 2 ) to grant access the BeagleBone Black has a flash memory of 4 GB. to the technical report or not (step 4, Fig. 2 ). The auditing process There are also devices in IoT networks that have superior com- takes place by registering all the details related to these steps in a putational power when compared to the devices shown in Table 1 . log file kept by the system. These devices are equivalent to robust servers and equipment Windley defines the specific steps of authorizing the execution found in the traditional Internet. of a requested action in an IdM system ( Fig. 3 ) [14] . The user In FLAT, the Client device is a restricted IoT device with a high shows her credentials to a Policy Enforcement Point (PEP) and level of mobility. On the other hand, the SP is represented by an makes a request to the system (step 1, Fig. 3 ). Then, the PEP will intermediary IoT device. authenticate the user using her credentials in the authentication In some scenarios, the restricted devices might be connected to server (step 2, Fig. 3 ). The PEP gives the authenticated credentials the network through gateways, which can take care of more com- to the Policy Decision Point (PDP) (step 3, Fig. 3 ), that using infor- plex network and security operations, as gateways are resource- mation about the security policy (step 4, Fig. 3 ) and the identities rich devices. It is important to note that this work considers the (step 5, Fig. 3 ), decides which access permission the user has in direct connection of restricted devices to the network, and thus, the system. This decision is sent to the PEP, denying or allowing does not make use of gateways to execute authentication and au- the user’s request (step 6, Fig. 3 ). thorization tasks or to connect to the network. FLAT focuses on the authentication part of the IdM system, In the authentication protocol proposed here, the only device defining necessary assumptions and implementing the mecha- considered to have a higher computational power, equivalent to nisms to authenticate restricted devices in IoT. When describ- servers in the traditional Internet, is the IdP. ing FLAT, the term Client will be used to refer to the system user/device. 2.3. IdM and FIdM Traditionally, there are three different models used in IdM systems [16] : isolated, centralized, and federated. When it comes to security in IoT, IdM has a fundamental role In the isolated model, a single server is responsible for provid- in protecting the network resources since it controls the access of ing the service and also for storing identity information [16] . In practice, an SP would not only provide the service requested by

the user but also performs authentication and authorization tasks. 3 http://www.aceinna.com//wireless- sensor- networks/index.cfm . As all the information is stored in each SP, the user would need 4 https://store.arduino.cc/usa/arduino- mega- 2560- rev3 .

5 https://store.arduino.cc/usa/arduino-due . different credentials for each SP it would like to access. Thus, this

6 https://www.raspberrypi.org/products/raspberrypi- zero- w/ . solution does not provide good usability (as the user would have

7 https://beagleboard.org/black . to manage several different credentials), and it is also not storage 4 M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253

Fig. 3. Authentication and authorization steps. Adapted from [14] .

Fig. 4. Isolated IdM model. Based on [16] . efficient, as the identity information of the same user will be stored in different SPs. This model is represented in Fig. 4 . The centralized model ( Fig. 5 ), on the other hand, delegates to a central IdP the task of storing the identity information of all users from all SPs [16] . Differently from the isolated model, there is a clear definition of different entities for the SP and the IdP. The IdP is now responsible for storing all the identity information, taking this task from the SPs. Remember that in the isolated model Fig. 5. Centralized IdM model. Based on [16] . the identity information was scattered in each SP of the network. As the number of users grows, this model can present scalability problems, since only one entity is responsible for every single user. adopts a federated model. According to Maler and Reed [17] , FIdM This model can also be problematic in the occurrence of a security is technologies and processes that allow the distribution of identity flaw, as all the identity information is centralized: once the IdP is information and the delegation of activities related to these identi- compromised, all user’s information is also compromised. ties between different domains [17] . The FIdM model allows a do- In the federated model (FIdM), the IdPs and SPs are in separate main to manage the identities of external users transparently [18] . servers, as in the centralized model. However, there is more than It also makes possible the use of SSO, where a user can authenti- one IdP. The federated model enables the use of services from dif- cate a single time to gain access to several services, avoiding fre- ferent domains by external users in a transparent way: the user quent login tasks and remembering different authentication data credentials are global identities in the federation, and the SPs from [17] . However, as it involves different domains, FIdM also imposes different domains are a single global SP [16] . Fig. 6 shows the fed- challenges related to security and system architecture, such as the erated IdM model. deployment of secure communication, strong authentication mech- Considering the need for a solution that takes into account the anisms, user information management to preserve privacy, man- potential mobility of IoT devices between different domains, FLAT agement of identifiers and IdP discovery [17] . M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253 5

Fig. 6. Federated IdM model. Based on [16] .

In FIdM, the SPs and IdPs exchange authentication and autho- 2.4. SAML rization messages, so the users from a local system can access resources of an external system that participates in the federation SAML 8 is an ITU (X.1141) and OASIS standard framework based [19] . The information flow in SSO applications in a FIdM model can on Extensible Markup Language (XML) created to exchange secu- have different variants, with two primary standards being identi- rity information and used to enable SSO and identity federation. 9 fied: (i) SP-initiated, where the SP sends an explicit access request The basic components of SAML are assertions, profiles, bindings to the IdP; and (ii) IdP-initiated, where the IdP typically is an ac- and protocols [21] . Assertions are a description of attributes, au- cess portal so the user can utilize services from several SPs [17] . thentication or authorization of an entity. These assertions are sent In the SP-initiated approach, the SP does not know in which IdP in a certain format determined by the SAML protocols, which de- the identity information of the user is stored. This issue is many fine how the request and response messages should be sent. SAML times referred to Where Are You From (WAYF), since the SP needs bindings establish how the integration between SAML messages to identify the IdP of the user, i.e., where the user’s information and communication protocols will be executed. SAML profiles, in is coming from. This problem can be solved by a smart client turn, are responsible for deciding how all the other components (that knows the correct IdP) or even asking the user to choose will be described to fit the needs of a specific application. from a list of IdPs [17] . IdP-initiated approaches, on the other As a protocol made to provide security, it implements not only hand, might be susceptible to Cross-Site Request Forgery attack a standard way of exchanging authentication and authorization (CSRF) [20] . messages but also defines security components that should be FLAT adopts the IdP-initiated approach, as the Client needs to present, such as XML-signatures, Transport Layer Security (TLS) contact its IdP before requesting the service to the SP. This choice and HyperText Transfer Protocol (HTTP) over Secure Sockets Layer was made since the IdP works as a Key Distribution Center (KDC) (SSL). SAML also makes use of XML-encryption. Regarding privacy, for the symmetric key used in Client ↔ SP communication, and thus, SAML supports the use of pseudonyms, transient identifiers, and needs to previously distribute the key before Client and SP can ex- assurance levels [21] . change messages. Like in other FIdM systems, a simple authentication flow using Fig. 1 shows how a traditional FIdM message flow works. Client SAML starts with the user trying to access a resource in an SP. The will make a service request to SP (step 1, Fig. 1 ). The SP, in turn, user will then receive a SAML request for authentication that will will redirect the Client to her IdP (step 2, Fig. 1 ). Then, Client asks be passed to its IdP. When the IdP receives the user’s credentials, a for an assertion so she can prove her identity to the SP (step 3, SAML response is built containing information about the authenti- Fig. 1 ). Next, the IdP requests and receives the Client’s credentials cation of the user. This message is signed by the IdP. The response (steps 4 and 5, Fig. 1 ), and sends the assertion to the Client (step is passed on to the SP, which checks the information in the re- 6, Fig. 1 ). The Client forwards the assertion to the SP (step 7, Fig. 1 ) sponse and can provide access or not to the requested resource. to get access to the service (step 8, Fig. 1 ). There are well-established standards that define the identity information exchange between different domains [7] . Security As- 8 https://www.oasis-open.org/standards#samlv2.0 . sertion Markup Language (SAML), Shibboleth, OAuth, and OpenID 9 http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.

Connect are widely used FIdM solutions. html . 6 M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253

SAML is a highly conﬁgurable solution, being able to adapt to server in order to get an access token. With the access token, the different application needs. Although SAML is already a consoli- Client can contact the resource server again and get access to the dated solution and can be integrated into other frameworks, it re- protected resource [23] . quires long XML messages and high computational power, as it OAuth is used with HTTP and TLS and is highly conﬁgurable, uses asymmetric cryptography. Thus, it is not adequate for com- making it possible to interoperate with other solutions to en- putationally restricted devices, and it is not used in FLAT. able authorization in several different applications. Differently from OAuth, FLAT is an authentication solution, not an authorization 2.5. Shibboleth framework.

10 Shibboleth is an open-source federated SSO solution based on 2.7. OpenID Connect SAML 2.0. There are mainly three components in Shibboleth: the IdP, the SP and the Discovery Service (DS). As in other FIdM solu- OpenID Connect 13 is a solution built on top of OAuth 2.0, pro- tions, the SP provides services to the users, and the IdP is responsi- viding an identity layer able to verify identities in the authenti- ble for the identities and authentication. The DS is responsible for cation process. OpenID Connect integrates an authentication solu- finding out which IdP holds the identity information about a spe- tion to the authorization defined in OAuth 2.0, using JavaScript Ob- 11 cific user. Shibboleth also carries the advantages of FIdM systems ject Notation (JSON) Tokens to communicate authentication infor- already mentioned in this chapter, such as increased user privacy mation [24] . JSON Web Signature (JWS) and JSON Web Encryption and usability. (JWE) are used to protect the integrity and confidentiality of the The typical flow in Shibboleth is similar to other FIdM solu- exchanged messages. tions, starting with the user trying to access a service in the SP In OpenID Connect basic flow, the Client sends a request to the [22] . After the IdP discovery process, the user will receive an au- OpenID Provider (OAuth 2.0 authorization server with authentica- thentication request from the SP and will redirect it to the IdP. De- tion capabilities). Using the terms of OAuth, the resource owner pending on the SAML binding and profile determined by the SP, will then be authenticated in the OpenID Provider. With the autho- the authentication response provided by the IdP will contain more rization of the resource owner, the OpenID Provider is able to pro- or less attributes regarding the identity of the user in the SAML vide an ID Token together with an access token to the Client [24] . assertion. With this authentication response, the SP can then de- This ID token is one of the most important extensions of OpenID to cide if it will authorize or not the access to the resource. Note that OAuth since it is responsible for providing information about the in this context, the IdP is responsible for authentication, while the authentication of the resource owner, including the intention of SP is responsible for authorization. It relies on a previously estab- the authentication and its expiration. The Client sends the access lished trust between the SPs and IdPs in the federation, as in other token to the protected resource, being returned an authorization FIdM solutions. grant. Note that Shibboleth is based on SAML and thus has to pay OpenID Connect also allows the use of levels of assurance and for the SAML costs previously mentioned. FLAT, on the other hand, is implemented using a REST-like approach [24] . OpenID, however, does not incorporate SAML and makes use of only symmetric cryp- is also based on asymmetric cryptography, and thus, not adequate tography on the Client-side to be more efficient and than well-suit to the IoT environment where restricted devices will also make au- for IoT. thentication requests. FLAT only uses symmetric cryptography on the Client-side, allowing even resource-constrained devices to run 2.6. OAuth the protocol and authenticate.

OAuth 12 is an open authorization framework and an Inter- 2.8. Cryptosystems net Engineering Task Force (IETF) standard –Request for Com- ments (RFC) 6749. OAuth aims to be a secure authorization so- This section presents a description of the cryptosystems used in lution for accessing HTTP services/resources [23] . OAuth provides FLAT and the reasons why they were chosen as lightweight alter- a layer of secure authorization to enable limited access to pro- natives to the IoT context. tected resources through access tokens, that contains access attributes restricting the time and scope of the permission [23] . Al- 2.9. ECDSA and ECIES though OAuth is an authorization solution, it is usually integrated into other tools to provide authentication and authorization, en- Elliptic Curve Cryptography (ECC) [25,26] refers to cryptosys- abling the user to log in and enjoy services in third-party websites tems whose security relies on the difficulty of the discrete log- using her credentials from an existing account. arithm problem in the group formed from the points on an el- The participating entities of an OAuth flow are the resource liptic curve over a finite field (Elliptic Curve Discrete Logarithm owner, the resource server, the Client, and the authorization server. Problem –ECDLP). To date, the best-known solutions to ECDLP The resource owner, as the name says, owns a resource that should are sub-exponential on the key size. ECDLP time-complexity con- be protected when being accessed by a Client. The resource is trasts with the underlying problems of traditional cryptosystems hosted on the resource server. The Client is an entity that would (e.g., RSA/DSA), whose best-known solutions, to date, are sub- like to access the protected resource. The authorization server, un- exponential on the key size [27] . In practice, this difference in der authorization provided by the resource owner, provides access time-complexity allows ECC to obtain the same security level with tokens to the Client so that she can access the resource [23] . significantly smaller keys. The use of shorter keys provides a set In a typical scenario, a Client makes an authorization request of advantages to ECC-based algorithms such as lower requirements to the resource owner, which then provides an authorization grant for storage and memory, less bandwidth to transmit keys over the (credential granting resource owner authorization) to the Client. network, and less energy consumption in restricted devices [28] . The client forwards the authorization grant to the authorization Elliptic Curve Integrated Encryption Scheme (ECIES) is an asymmetric encryption algorithm based on ECC, and thus, can provide

10 https://www.shibboleth.net/ .

11 https://wiki.shibboleth.net/conﬂuence/display/CONCEPT .

12 https://oauth.net/ . 13 http://openid.net/connect/ . M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253 7 the same security level of traditional algorithms (such as RSA) with • Verifying: to verify the signature of U over M , V needs to com- = ( ) the use of smaller keys. For example, considering a security level pute the hash of M: e H M . Then V computes u1 and u2 −1 of 128 bits, using RSA the key length would be around 3072 bits using the two parts of the signature ( r and s ): u 1 = es mod −1 while using ECC the key length could be as short as 256 bits [28] . n and u 2 = rs mod n . Next, V computes R = (x R , y R ) = u 1 G + The operation of ECIES is described using three procedures [29] : u 2 QU , where G is the base point generator. V then sets v = x R

• key deployment: after deﬁning a set of parameters to be used and compares v and r: if v is equal to r the signature is valid. in the scheme (MAC function, symmetric encryption scheme, Using point compression, ECDSA can produce public key certiﬁ- elliptic curve parameters, point compression), the entity V (the cates around 25% smaller than other algorithms based on asym- recipient of the encrypted message) generates an elliptic curve metric cryptography [31] . ECDSA is an ISO (ISO 14888-3), ANSI

key pair (dV , QV ) and ensures that U (the sender of the en- (ANSI X9.62), IEEE (IEEE 1363-20 0 0), FIPS (FIPS 186-2), and SECG

crypted message) receives the public key QV . (SEC 1) standard. • encryption: to encrypt a message M , entity U generates an ECDSA is used as the digital signature algorithm in FLAT, given = ( , ) elliptic curve key pair (k, R), where R xR yR . U derives a the characteristics and advantages presented by ECC in general and

shared secret z using the secret key k and the public key QV by the ECDSA itself. generated by V . Next, U uses a key derivation function to generate a symmetric key K from z . U parses the a leftmost bits to 2.10. ECQV form an encryption key EK and the b rightmost bits to form a MAC key MK , where a is the size of the key used in the The Elliptic Curve Qu-Vanstone (ECQV) certificate [12] is an im- symmetric encryption scheme chosen and b is the size of the plicit certificate scheme, where the public key is reconstructed key used in the MAC algorithm chosen. U then uses the key from public data [12] . The public key is not stored explicitly in EK to encrypt the message M , generating ciphertext EM . Finally, the certificate, eliminating the need for separate public key and U computes the tag D on the ciphertext EM using the MAC signature fields (as in traditional certificates) and thus, provides a scheme and the key MK . The final ciphertext output by ECIES smaller certificate, when compared to traditional solutions such as is the triple C = (R, EM, D ) . RSA or ECDSA certificates. For instance, considering a security level • decryption: Upon the reception of ciphertext C , V first needs of 128 bits, while an implicit certificate size is around 257 bits of to parse C to recover R, EM and D . V derives a shared secret length (plus identification data), an ECDSA certificate is around 769

z using her secret key dV and the public key R. V then uses bits, and an RSA certificate is around 6144 bits [32] . a key derivation function to obtain the key K from z . Next, V The main operations of the implicit certificate scheme (ECQV) parses the a leftmost bits to form an encryption key EK and the are [33] : b rightmost bits to form a MAC key MK , where a is the size of • the key used in the symmetric encryption scheme chosen and Setup: the Certificate Authority (CA) establishes the elliptic

b is the size of the key used in the MAC algorithm chosen. V curve domain parameters and the hash function and generates

uses the MAC algorithm chosen to check the tag D and verify it a key pair. Formally, the CA generates an elliptic curve key pair

is the tag on EM . The last step in the decryption procedure is (dCA , QCA ), where dCA is the private key and QCA is the public

to decrypt EM using EK to obtain the original message M . key. QCA is also distributed to U, the subject requesting a cer- tiﬁcate, and to V, the one that will receive the certiﬁcate.

The shorter key of ECIES reflects in its execution time. For • Certificate request: the subject who is requesting a certificate example, ECIES has a lower execution time when compared to to the CA generates a key pair and sends a certificate request

RSA [30]. Considering a security level of 128 bits, encrypting a to the CA using its public key. Formally, U generates an elliptic 1024-bytes plaintext using 256-bits ECIES and 3092-bits RSA takes, curve key pair ( k U , R U ), where k U is a private value necessary respectively, 16.96 ms and 18.88 ms. The running time is much to compute the private key, and R U is a public value. U also more discrepant for a 256-bits security level. Encryption using generates a string U , that represents her identity. The pair ( U, ECIES with 512 bits key takes ≈ 81.52 ms against 1,827.05 ms us- R U ) is the certiﬁcate request that will be sent to the CA. ing RSA with 15,360 bits key. • Certiﬁcate generation: CA generates and sends an implicit cer-

ECIES is also an ANSI (ANSI X9.63), IEEE (IEEE 1363a), ISO (ISO tiﬁcate to the subject after conﬁrming her identity and receiv-

18033-2), and SECG (SECG SEC1) standard. The use of smaller keys ing the certificate request. Formally, the CA generates an ellip- and its consequent advantages make ECIES a right asymmetric en- tic curve key pair ( k, kG ), where the value k is private and the cryption solution to IoT, and thus, was chosen as the asymmetric value kG is public. The CA then computes PU = RU + kG, an el- encryption scheme used in FLAT. liptic curve point that is the public key reconstruction data. The The Elliptic Curve Digital Signature Algorithm (ECDSA), as the certificate CertU = (PU | U ) is the concatenation of the public- name indicates, is a digital signature algorithm equivalent to the key reconstruction data and U , the value representing the iden- Digital Signature Algorithm (DSA) but based on ECC. ECDSA pro- tity of U. Next, the CA computes e = H(CertU ) as the hash of vides faster signature generation when compared to DSA, since it the certificate Cert U . Finally, the CA computes the private key is possible to achieve the same security level with smaller param- = + ( contribution data r ek dCA mod n), where n is the order of eters. There are three different procedures necessary for the func- the base point generator. tioning of ECDSA [29]: • Public key extraction: extracts the public key of the subject • Key deployment: after defining a set of parameters to be used using CA’s public key, the implicit certificate, and the elliptic in the scheme (hash function, elliptic curve parameters), entity curve domain parameters. When the certificate receiver V re- U (the subject of the signature, who signs) generates an ellip- ceives the certificate, it has to extract the public key. Formally, tic curve key pair ( d U , Q U ) and entity V (the recipient of the V computes e = H(CertU ) as the hash of the certificate received. = + , signature) receives the public key QU . Then, V computes QU ePU QCA using the public key recon- • Signing: U generates an elliptic curve key pair ( k, R ), where struction data from the certificate and the CA’s public key. Q U R = (x R , y R ) . U then sets r = x R and computes the hash e of is U’s public key extracted from the certificate. the message M to be signed: e = H(M) . Next, U computes s = • Certificate reception: when the subject receives the certificate, −1 k (e + rdU ) ( mod n ), where n is the order of the base point she checks that the implicit certificate she received is valid. For- generator. The signature is the pair S = (r, s ) . mally, U extracts the public key from the certificate, computing 8 M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253

the hash of the certificate e = H(CertU ) and then calculating All these solutions, however, are based on asymmetric cryptog- = + = QU ePU QCA to obtain the public key. Then U computes dU raphy. FLAT, on the other hand, considers an IoT-tailored protocol r + ekU (mod n ) to obtain the private key. Next, U computes for authentication, which uses only symmetric cryptographic prim- = , QU dU G where G is the base point generator. If QU is equal itives on the Client device. Furthermore, these proposals do not to Q U , then the certificate is valid. take advantage of federated authentication and requires external gateways to interact with constrained-devices. As explained above, the only operation necessary when the re- ceptor of the certificate (relying party) receives the implicit cer- 3.1.2. Symmetric cryptography with gateways tificate is the public key extraction. This makes implicit certifi- There are also works with symmetric cryptography and gate- cates also more computationally efficient than traditional certifi- ways [47,48] . cates since the process of extracting the public key is faster than In the work of Dammak et al. [47] , they proposed Token-Based signature verification (of the CA’s explicit signature) in traditional Lightweight User Authentication (TBLUA) —a protocol to leverage certificates [32] . Differently from traditional certificates, in implicit authentication and key negotiation for resource-constrained de- certificates, after being extracted, the public key will only be vali- vices. This protocol fits a network model in which users are in- dated when it will be used in some communication process, with teracting with gateways that manage a pool of smart devices, and the same being applied to the proof that the subject of the cer- only the smart devices are resource-constrained. The protocol re- tificate, in fact, knows the private key [12] . This means that the lies on symmetric cryptography and one-way hash functions to ne- association of the public key to its owner and the ownership of gotiate session tokens between the parties. Besides, it relies on Per- the private key are not distinct processes [12] . fect Forward Secrecy (PFS) to generate per-session unique keys. FLAT uses implicit certificates in the communication between Nafi et al. [48] also propose a new lightweight key manage- SP and IdP to reduce communication, storage, and computational ment protocol based on a matrix for IoT, which consists of a set of costs. protocols for initialization, pairwise and group key establishment, node addition, key revocation, and periodic key renewal phase. 3. Related work They assume a network architecture with constrained nodes, gateway nodes, and a remote server node. In this section, we discuss works on Authorization & Authenti- These proposals, however, do not address federated authentica- cation for IoT in general ( Section 3.1 ), and then we discuss FIdM tion problem. Moreover, they require external gateways to interact schemes in particular ( Section 3.2 ). We also present a comparison with constrained-devices, a requirement that FLAT does not have. summary of the related work in Section 3.3 . 3.1.3. Asymmetric cryptography without gateways 3.1. Overall authentication & authorization for IoT Yavuz [34] proposes a signature scheme for authentication of resource-constrained devices called ETA (Efficient and Tiny Authen- In the IoT context, there is no consolidated solution or consen- tication). The author claims that traditional signature schemes are sus on how to provide Authentication & Authorization for smart not suitable for constrained devices as they require high compu- devices with very different computational power and character- tational power and energy consumption. ETA also provides smaller istics [34–42,42–52] . In what follows, we discuss some of the signatures and key sizes than other existing similar solutions. In approaches that address authentication and authorization for IoT the work of Porambage et al. [53] , it is proposed an authentica- with asymmetric cryptography and gateways ( Section 3.1.1 ), with tion protocol for distributed IoT applications (e.g., Wireless Sen- symmetric cryptography and gateways ( Section 3.1.2 ), and propos- sor Networks). Their protocol relies on implicit certification to pro- als without gateways ( Section 3.1.3 ). vide end-to-end mutual authentication. Its operation is separated into two phases – registration and authentication. In the registra- 3.1.1. Asymmetric cryptography with gateways tion phase, trusted parties obtain their implicit certificates from a Some solutions approach the authentication and/or authoriza- trusted authority (e.g., a Certification Authority). Then, in the au- tion issue in IoT through asymmetric cryptography and consider thentication phase, a pair of nodes can exchange their implicit cer- the existence of gateways for interacting with constrained de- tificates to achieve mutual authentication and to establish a secret vices [36,38,39,46] . key for trusted communication. Xi et al. [36] present a key agreement and authentication pro- Neto et al. [37] propose an authentication and access control so- tocol for IoT devices named TDS (The Dancing Signals). Their pro- lution for each step in the life-cycle of IoT devices. Using attribute posal provides faster key generation when compared to other solu- and identity-based cryptography, they developed several protocols tions, and is resistant to predictable channel attacks. TDS is mod- to enable Attribute Based Access Control (ABAC) and authentica- eled only to provide keys to physically close devices. Kumari et al. tion in IoT environments. The proposed solution can be run in both [39] present an ECC-based authentication protocol targeted to IoT powerful and constrained devices. and cloud servers. Their solution is evaluated in terms of per- Zeng et al. [44] propose a multi-server approach to provide formance, and its security is formally analyzed using the AVISPA anonymous user authentication for IoT devices. They also per- tool. The authors present authentication and authorization proto- formed a security evaluation of the solution. In the work of cols that take into consideration the heterogeneity of the network. Harbi et al. [54] , they point out security issues in Inter-Cluster Hammi et al. [38] present an authentication solution for IoT Multiple Key Distribution Scheme (ICMDS) [55] and propose an named ”Bubbles of Trust”. Their approach is to provide authen- enhanced mechanism that overcomes the security flaws. Their ap- tication using a decentralized system based on blockchain to en- proach is based on mutual authentication and session key agree- sure availability and integrity. Their solution is evaluated in an im- ment schemes. As in ICMDS, the revised scheme relies on ECC to plementation using Ethereum blockchain. Khalid et al. [46] also generate and verify signatures as well as to encrypt and decrypt proposes a decentralized authentication and access control mecha- data. nism for IoT based on blockchain. The recent emerging blockchain Bu et al. [45] propose a scheme for sharing confidential infor- technology can be a suitable solution for authentication and access mation (e.g., cryptography keys) in IoT systems. In this scheme, it control services in IoT, due to its decentralized nature and crypto- is assumed that sensors (i.e., service providers) are not physically graphic properties. safe and could get tampered. Their goal is to securely distribute M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253 9 secrets from dealers (e.g., an Identity Provider) to clients using a that the taxonomy presented in their work can be used as a guide network of sensors. The scheme is designed to avoid passive (e.g., to designers of IdM systems to build solutions that can preserve channel eavesdropping) and active attacks (e.g., message injection) users’ privacy. using an improved version of TSS (Threshold Secret Sharing) to dis- Some recent works, however, aim to provide improvements or tribute secrets among sensors. Besides, Physical Unclonable Func- changes in widely used solutions to achieve enhanced privacy, at- tions (PUFs) are used to negotiate the key pairs between dealers tribute aggregation, or to increase efficiency [56,57] . and clients. Chadwick and Inman [56] propose a linking service to aggregate Wang et al. [35] propose a two-factor authentication scheme attributes of different IdPs. The authors argue that for many exist- for wireless sensor networks that can provide privacy protection to ing Web applications, it is not enough to receive identity attributes users. They analyze case studies to show that previous approaches from only one IdP per session established with a selected SP. When to the privacy issue in wireless sensor networks cannot adequately the user wants to access a service, the SP redirects him/her to address the problem. They investigate possible solutions, conclud- his/her IdP. Then, the IdP sends a response to the SP, asking it to ing that public-key cryptography is a suitable approach. Li et al. contact the linking service, which can provide attribute aggregation [43] propose a three-factor authentication model for wireless sen- from the IdPs selected by the user. In this model, the user has to sor networks. Based on a two-factor authentication scheme pre- previously authenticate himself/herself into the IdPs for the link- viously proposed, the authors design an anonymous multi-factor ing service to create a link entry with his/her local identifier. With authentication for IoT, using the user’s fingerprint and fuzzy com- attribute aggregation, the user can select the information he/she mitment to protect the user’s information. Ometov et al. [40] pro- wants to share with each SP and also use attribute information vides a comparison between different multi-factor authentication from different IdPs in the same SP session. solutions for IoT, listing its advantages and disadvantages. Isaakidis et al. [57] also focus on the privacy aspect of FIdM Although such approaches are suitable for constrained devices, systems. In their work, the authors propose a new approach based our work differs from them in the sense that we are only attached on algebraic Message Authentication Codes (MACs) to enhance to symmetric cryptography primitives when it comes to the IoT privacy in existing FIdM systems. The solution, UnlimitID, uses nodes. Furthermore, we offer federated authentication for devices attribute-based pseudo-identities to provide unlinkability between across different authentication domains. the SPs and IdPs, thus avoiding the creation of user behavior profiles or logs. UnlimitID is designed to work with OAuth, without 3.2. FIdM any changes in the SPs (some changes are necessary for Client and IdP). In what follows, we discuss works on FIdM for the traditional FIdM is already a consolidated solution in the traditional Inter- Internet ( Section 3.2.1 ) and FIdM for IoT ( Section 3.2.2 ). net, as it has several standards and protocols being widely used, such as Shibboleth, OpenID, and OAuth. However, considering the 3.2.1. FIdM for the traditional Internet IoT scenario, there is still no consensus on how to provide authen- This section covers works related to authentication and FIdM tication and authorization to users and devices. In this sense, dif- for the traditional Internet, where there are already several known ferent FIdM solutions for IoT have been proposed [8,9,58–64] , as standards and solutions, such as Shibboleth, OpenID, and OAuth. we described in the next section. There are various works that address FIdM, its main characteristics, and existing solutions [6,7,17,56,57] . These works also eval- 3.2.2. FIdM for the Internet of Things uate different contexts and recommend FIdM solutions that better Some authentication and authorization proposals for IoT are fit specific business needs. based on FIdM solutions for the traditional Internet ( [8,9,58– In his work, Chadwick [19] gives a detailed view of FIdM. The 60,65,66] ). The main advantage of such solutions is that they al- author defines digital identities, describes FIdM standards and the low integration with traditional FIdM systems while trying to re- widely adopted systems, as well as discusses the main research duce the costs of these solutions by changing some aspects of the topics. He also presents good design practices to build an IdM sys- original approach. tem and the privacy concerns regarding FIdM models. The work of Liu et al. [58] presents a framework for authen- Shim et al. [7] present the main concepts of FIdM, describing tication and authorization in IoT. Their approach uses OpenID to existing standards and reference architectures. The paper gives a provide authentication and Role-Based Access Control (RBAC) to broad view of FIdM and a big picture of how SAML, Liberty Al- deal with the authorization. The work also describes a protocol to liance FIdM architecture, and WS-Federation work. It also rein- establish session keys between two entities and provides a brief forces the advantages of using FIdM, for instance, SSO and the high security evaluation. The key establishment is based on ECC, and level of control the user has over his information, shared across both the key request to access a device and the key establishment domains. procedures use an intermediary entity, similar to a gateway. The The work of Maler and Reed [17] also addresses main concepts authors do not provide an implementation/prototype or a perfor- and configurations of FIdM models. It presents widely used FIdM mance evaluation of the proposed solution. As mentioned before, standards such as SAML, OpenID, and InfoCard, including a com- FLAT does not use gateways to provide authentication, relying on parison of security and privacy, user-centric identity support, SSO, symmetric cryptography to be lightweight enough to run in Client and how lightweight they are. The authors offer a brief interop- devices. FLAT also does not address authorization and is not based erability analysis of the described standards. They also discuss the on OpenID or other known FIdM technologies for the traditional main security and privacy issues related to FIdM, such as user’s Internet, in order to deliver a more tailored and efficient solution tracking by IdP and phishing attacks to username/password, and for IoT. some approaches to mitigate these issues. Fremantle et al. [8] propose a federated identity model to pro- Birrell and Schneider [6] make an analysis of existing FIdM vide access control to IoT devices, evaluating the possibility of an systems, focusing on privacy-related issues. The paper evaluates authentication and authorization model for IoT based on OAuth 2.0 widely used FIdM architectures under the privacy properties of un- with the MQTT protocol. In another work, Fremantle et al. [9] pro- detectability, unlinkability, and confidentiality. Based on these ar- pose an extension to the OAuth 2.0 protocol to provide a FIdM chitectures’ design choices, the authors perform an analysis of the solution for IoT devices as well as enhance the privacy of users. benefits and disadvantages of each approach. The authors claim Their solution is called OAuthing and enables users and devices to 10 M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253 be registered automatically, providing each user/device anonymous lar scenarios, FLAT is a solution that can be applied to diverse IoT identities. scenarios. Cirani et al. [59] propose an authorization architecture for IoT Some proposals use symmetric cryptography on IoT devices and using an external authorization service based on OAuth, called IoT- external gateways [61–64] . OAS. Their architecture transfers the authorization logic from the Turkanovi c´ et al. [61] analyze the mutual authentication issue constrained device to the external service, allowing the device or between a sensor node and a user. The authors designed a solution smart object to protect its resources by only making a request describing a session key agreement and an authentication protocol to the authorization framework. They focus on the authorization to establish mutual authentication between the parties involved problem, and federated authentication is not addressed. (user, sensor node and gateway node) without the communication Domenech et al. [60] describe an authentication and autho- between the user and the gateway. rization model for IoT based on SAML and XACML standards, the Amin and Biswas [62] propose a scheme for authentication and AAI4WoT. The authors provide a prototype as well as an evalu- key agreement that enhances the Turkanovic et al. scheme. They ation in terms of storage, communication, CPU usage, and power leverage a multi-gateway network architecture to reduce power consumption. As AAI4WoT is based on SAML, it requires long XML consumption by keeping the nodes as close as possible to the gate- messages [67] . Besides, as it uses asymmetric cryptography, it re- ways. Moreover, the authors report and fix issues on the scheme of quires a great number of computational resources and, therefore, Turkanovi c´ et al. and evaluate the security of the revised version is not fit for resource-constrained IoT devices. using BAN logic and the AVISPA tool. These works develop solutions based on traditional FIdM ap- Yang et al. [63] demonstrate a feasible node captured attack – proaches. FLAT, conversely, does not rely on traditional FIdM ap- a scenario where an adversary has physical access to a device and proaches. Instead, FLAT designed a FIdM exclusively tailored to IoT. thus can extract secret data from its memory –in the scheme Other works try to transfer the authentication and authoriza- of Amin and Biswas. Then, they proposed a scheme that imple- tion tasks to an external gateway or to a more powerful node in ments a heuristic to classify nodes into three possible statues – the network, so preserving the resource-constrained IoT devices normal, possible compromised, or compromised –and thus decide [68–71] . whether the node should participate in the authentication. Their Horrow and Sardana [68] present the requirements for an IdM work does not propose an authentication protocol per se. Instead, system for IoT and propose an IdM framework for IoT using cloud- they proposed an enhancement to fix security issues in the Amin based technologies. The computation is performed in the cloud in- and Biswas [62] scheme. stead of having computing nodes process the information sent by Wazid et al. [64] propose LDAKM-EIoT—a device authentica- sensors. The authors present a general architecture to approach the tion and key management mechanism for edge-based IoT environ- identity management issue in IoT, but they do not describe in de- ments. The proposal relies on cryptographic hash functions and tails how would be the protocols to implement this architecture. bit-wise XOR operations–rather than on conventional cryptosys- Hummen et al. [69] propose some optimizations to Datagram tems like AES–to make LDAKM-EIoT more efficient. They also as- Transport Layer Security (DTLS) in order to use certificates in IoT sume a gateway node responsible for receiving, processing, and for- devices, such as pre-validation of certificates in a gateway and a warding data to IoT devices. delegation procedure that allows another entity to validate the cer- These solutions make use of an extra entity –like a gateway – tificate instead of the constrained device. However, they present to perform authentication and authorization tasks. In FLAT, on the preliminary results and only evaluate the computational overhead. other hand, there is no need for an authenticating node to rely on Markmann et al. [70] approach the authentication for resource- such an extra entity. constrained devices in IoT using Identity-Based Cryptography (IBC) and ECC. They assume the presence of a node with more compu- 3.3. Comparison summary tational power in each domain in order to provide the end-to-end authentication utilizing IBC. This node works as a trusted authority For the sake of comparison, we summarized the works dis- (similarly to a CA), and a federation of these trusted authorities is cussed above in Table 2 . Note that several works propose FIdM required to provide authentication between different domains. or authentication schemes for IoT. However, they either rely on Karim & Adnan [71] proposed an OpenID-based authentication asymmetric cryptography or rely on external entities to perform service for the Internet of Things. In their scheme, they make use IdM tasks. Therefore, they do not fully meet the IoT needs. FLAT, of the CoAP [72] protocol to couple with the communication over- conversely, is a federated authentication protocol that solely relies head and leverage an authentication gateway to perform authen- on symmetric cryptography on the Client-side and then can imple- tication. They pick a scenario where users are clients and devices ment a FIdM system light enough for constrained devices. are servers (e.g., a user accessing a smart device). Also, they rely on devices’ unique IDs (e.g., Device Description Data) to carry out 4. The call for a lightweight cross-domain authentication device registration. The discussed solutions use entities other than IoT devices to There are many situations when IoT nodes from different do- perform authentication and authorization tasks. FLAT, however, mains need to talk to each other securely. A real-world situation does not transfer the computation to an external entity, developing that came to our attention by way of one of the biggest technol- a protocol that can be executed even by restricted devices. ogy companies is this: Suppose that an autonomous (driverless) Some works address FIdM solutions for specific IoT scenarios truck that hauls iron ore has gotten out of order in the middle

[65,66] . For example, Witkovski et al. [65] propose a solution for of a mine. 14 And that a technical rescue team, from a different IoT device authentication based on session keys and symmetric company that provides repair services to several mining compa- cryptography with the use of a gateway to integrate the tradi- nies, has to provide in-situ emergency care in order to get the truck tional Internet and IoT in the maintenance of electronic devices ﬁxed. To do so, ideally, the rescue team needs its technical appa- in a smart home scenario. Hong et al. [66] claim that Bluetooth ratus to communicate seamlessly and securely with the truck’s en- Low Energy (BLE) can be used as an access control alternative in gine to start assisting. Note that here we have devices (the engine smart homes. A prototype of the BLE access control solution was built on top of resource-constrained devices and applied to speciﬁc 14 https://www.technologyreview.com/s/603170/mining- 24- hours- a- day- with- smart home scenarios. Unlike these approaches targeting particu- robots/ . M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253 11

Table 2 Related work comparison.

Work Symmetric Gateway Client device Context Authorization Authentication FidM for the FidM for IoT Crypto on Client Internet

Chadwick 2009 — — Advanced General — Shim et al. 2005 — — Advanced General — Maler and Reed 2008 — — Advanced General — Birrell and Schneider — — Advanced General — 2013 Chadwick and Inman — — Advanced General — 2009 Isaakidis et al. 2016 — — Advanced General — Wu et al. 2017 — — Constrained Sensors — —— Yavuz 2013 — — Constrained General — —— Porambage 2014 — — Constrained General — —— Neto et al. 2016 — — Constrained General —— Zeng et al. 2018 ——Intermediary General — —— Harbi et al. 2019 — — — General — —— Bu et al. 2019 — — — General — —— Wang et al. 2014 — — Constrained General — —— Li et al. 2018 — — Constrained General — —— Ometov et al. 2019 ———Smart city — —— Xi et al. 2016 — Constrained Sensors — —— Kumari et al. 2018 — Constrained General — —— Hammi et al. 2018 — Constrained Smart city — —— Khalid et al. 2020 — Constrained General —— Dammak et al. 2019 Constrained General — —— Naﬁ et al. 2020 Constrained General — —— Yang et al. 2020 — — Constrained General — —— Liu et al. 2012 — — General — Fremantle et al. 2014 — Constrained General — Fremantle et al. 2016 — Constrained General — Cirani et al. 2015 — Constrained General —— Domenech et al. 2016 — Intermediary General — Horrow & Sardana 2012 — Constrained General — Hummen et al. 2013 — Constrained General — — Markmann et al. 2015 — Constrained General — — Karim & Adnan 2019 — Constrained General — — Hong et al. 2016 — Constrained Smart home —— Witkovski et al. 2015 Constrained Smart home — Turkanovi c´ et al. 2014 Constrained General — — Amin and Biswas 2016 Constrained General — — Wazid et al. 2019 Constrained General — — FLAT —Constrained General — —

and the repair equipment) from distinct domains (the mining com- It is easier if each client has to authenticate only with the IdP pany and the technical rescue company) that need to inter-operate of its own domain in a federated environment instead of having as soon as possible and in an authenticated manner (as a truck a central authentication authority. Moreover, a plain (centralized) like this cannot be accessed by someone or something it does not implementation of such a system (i.e., without the employment of recognize). FIdM) is not appropriate to both car users and tollway companies. Other examples can be listed as, for example, the authentica- The system is inappropriate to the user because it may compro- tion of airplanes to airport equipment all over the world. The use mise his privacy. 15 For instance, it makes it possible for the toll of FIdM can signiﬁcantly simplify the process of secure identiﬁca- company to keep track of the users’ mobility pattern and then in- tion of each new airplane that lands and needs to use airport ser- fer part of users daily routine. Moreover, a centralized approach is vices. By using FIdM, instead of getting to know all airplanes from also inappropriate to the toll company because it may not com- all airlines (as a centralized identity management approach would ply with contemporary data privacy laws ( e.g . The EU General Data do), the airport service provider must know only the credentials Protection Regulation). of the IdP of each airline, a more straightforward task. Therefore, The employment of a FIdM system could easily solve the above the adoption of FIdM in this context guarantees to the airport that privacy issue were it not for the resources it requires. For instance, the just landed airplane is an authorized client accordingly to its one of the most popular protocols for cross-domain message ex- airline IdP. change, the Security Assertion Markup Language (SAML) [17] re- Another example is automated cashless toll systems. Here, cars lies on asymmetric cryptography and then is inadequate to the (clients) are equipped with tags that automatically authenticates IoT scenario, due to the computational resources required. There to the toll gate, authorizing the car to get into the tollway after are indeed streamlined FIdM proposals, some even tailored to IoT processing the payment. It is getting more common to have sev- ( e.g . [9,59,60] ). However, as we discuss in Section 3 , those propos- eral companies providing the car tags that must be recognized and als still require asymmetric operations from Clients and, therefore, talk to the toll gate equipment, which belongs to another com- are not ideal for resource-constrained environments as the car tags. pany. With a continually increasing number of cars (client tags) and companies that provide these cashless toll services in large countries or even in continents, the scalability gets compromised 15 https://www.theverge.com/2013/3/27/4150702/golden- gate- bridges- new- if a traditional (centralized) approach is adopted. cashless-tollway-promises-convenience-for-privacy . 12 M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253

So, the major challenge for solving the privacy issue lies in design- as a way of making certificates issued by one federation Certifi- ing a FIdM that fits the resources of IoT devices. cation Authority valid in another federation. This is done through cross-certification or the creation of a new root Certification Au- 5. FLAT: a federated lightweight authentication protocol for IoT thority that will issue certificates for the Certification Authorities of all participant federations. FLAT revamps the traditional FIdM authentication to achieve a federated lightweight authentication solution for IoT. In what fol- 5.1.5. Setup lows, we talk about the FLAT various assumptions ( Section 5.1 ), FLAT assumes that several procedures will take place before protocol description ( Section 5.2 ), efficiency ( Section 5.3 ), and mes- the Client deployment. A central point for security is the gener- sage description ( Section 5.4 ). ation of cryptographic keys. Physical Unclonable Functions (PUFs) are known to be resistant to physical attacks. FLAT, therefore, as- 5.1. Assumptions sumes the use of (PUFs) for generating the device’s cryptographic keys [74] . In FLAT, briefly, we assume the PUF output is submit- FLAT focuses on a critical part of a FIdM model: authentication. ted to an error correction algorithm and then cryptographically For other parts, FLAT assumes the use of existing approaches. Be- hashed [74] . The final result is loaded into output is generated, low, we describe FLAT assumptions. formatted and stored in each device, shared with the IdP, and then used as a key to secure the Client ↔ IdP communication. We 5.1.1. Device capability assume this whole process takes place in a secure environment FLAT assumes the Client, SP, and IdP run over devices of low, ( e.g .at a physically secure room inside the device’s home domain.) medium, and high computational capabilities, respectively. This is so because: 5.2. Protocol description

• IoT devices are normally resource-constrained, making the Fig. 7 shows a high-level overview of FLAT’s operation. For read- Client the main motivation of our work; ability, we decided not to represent all the cryptographic primitives • the SP, in the end, is still a kind of server and, most likely, will in Fig. 7 , individually. There, instead, dotted lines denote no cryp- be endowed with more resources than the Client; tosystem being used, dashed lines indicate symmetric cryptosys- • and the IdP is probably like any other IdPs, i.e.a Cloud server tems (MACs and secret-key encryption), and solid lines, asymmet- that will run 24/7. ric cryptosystems (digital signatures and public-key encryption).

By definition, IoT devices are interconnected via the Internet. As We use a scenario where a car with an attached constrained for the Client, this can be done either through the devices’ own ca- IoT device interacts with an automated cashless toll system to il- pabilities ( e.g .by featuring a mobile chip like modern e-book read- lustrate FLAT (Fig. 7). Here, the toll company represents the SP; the ers/smartwatches usually do) or indirectly by requiring the device device attached to the car, the Client; and the car domain (the car to connect to a hotspot close to the SP. After obtaining the SP ser- rental company, the car company owner, the department of motor vice broadcast, the Client could also ask the SP to forward its pack- vehicles, etc.) the IdP. In context, the service here is the tollway, ets to the IdP, as it is expected that the SP is permanently con- i.e.the passage through the toll road. Broadly, the Client requests nected to the Internet. to its IdP a session key and an assertion. The IdP, in turn, sends the session key to both the Client and SP, securely. Besides, the IdP sends a signed assertion to the Client. Last, the Client uses the 5.1.2. Service discovery session key to secure the communication with the SP and forward Service discovery allows participants of a network to do things the signed assertion to be validated by it in order to allow access like service announcements and consultation [73] . In IoT, devices to the requested service. use services provided by SPs physically close to them and, thus, SPs Notably, whenever the Client wants to access a service ( e.g .go convey service information using beacons, i.e .periodically broad- through a toll gate), it requests the IdP to issue a key to the SP and casted messages within a certain radius. FLAT assumes that the the Client itself ( Fig. 7 , step 1), so the Client and SP can commu- Client discovers the SP and its services using beacons. nicate with each other, securely. The IdP respond to this request and issues the key to the Client ( Fig. 7 , step 2) and SP ( Fig. 7 , 5.1.3. Trust establishment steps 3, 4, and 5). Regarding the SP, this is a three-hand shake FLAT assumes the trust between IdPs and Clients as well as IdPs process because the SP and IdP first exchange certificates (in this and SPs takes place a priori. FLAT assumes the trust between IdPs case, Implicit Certificates – Fig. 7 , steps 3 and 4) to establish a se- and Clients is established during a Client setup, where shared sym- cure channel for the key issuing ( Fig. 7 , step 5). Next, as usual in metric keys are pre-loaded into IdPs and Clients. FIdM, the Client requests and receives an assertion ( Fig. 7 , steps 6 As for IdPs and SPs, they usually are from different domains and 7). Last, the Client requests the service by presenting the as- and, previously, not known to each other. FLAT assumes the trust sertion to the SP ( Fig. 7 , step 8), then the SP provides the service between them derives from digital certificates issued by a standard ( Fig. 7 , step 9) – e.g .by opening the toll gate. f shows the complete Certification Authority. description of FLAT, with all steps taken in the authentication process. First, the Client sends a key request to IdP, indicating the SP 5.1.4. Interfederation providing the service it would like to access (step 1.1, Protocol 1 ). In case the Client tries to use a service offered in a differ- The IdP then exchange certificates with the SP (steps 2.1 and 2.2, ent federation, FLAT assumes a model based on the GANT Au- Protocol 1 ) and after verifying SP’s certificate, sends a symmetric thorisation INfrastructure for the research and education commu- key to the SP, so it will be able to communicate with the Client nity (eduGAIN) 16 for communication between different federations. (step 2.3, Protocol 1 ). The SP sends a signed nonce to the IdP as eduGAIN is an interfederation service that allows the connection a confirmation of the reception of the key (step 2.4, Protocol 1 ). of academic identity federations and their own infrastructures for Next, the IdP also sends the symmetric key to the Client (step 1.2, authentication and authorization. The interfederation can be seen Protocol 1 ). The Client can then send an assertion request to the IdP (step 3.1, Protocol 1 ), that responds with the assertion (step

16 https://www.geant.org/Services/Trust _ identity _and _security/eduGAIN . 3.2, Protocol 1 ). This assertion signed by the IdP is forwarded to M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253 13

Fig. 7. A simpliﬁed version of FLAT applied to a tollway scenario.

Protocol 1. FLAT protocol description. 14 M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253 the SP (step 4.1, Protocol 1 ), which then can provide the service to Table 3 the Client (step 4.2, Protocol 1 ). Countermeasures adopted by FLAT. Property Countermeasure 5.3. Efficiency Authentication MACs and digital signatures Confidentiality Symmetric and asymmetric encryption We have taken some measurements to guarantee the FLAT”s Liveness Nonces efficiency, especially on the Client-side. First, we decided that all Integrity MACs, digital signatures and PUFs communication involving the Client —the most constrained de- Availability Authentication between the parties vice —would be carried out using symmetric cryptosystems. These Privacy FIdM model: limit the access to identity information are more efficient than asymmetric cryptosystems regarding not only computation but also communication ( e.g .they do not require FLAT also assumes that the adversary has access to the mes- certificate exchange). To make this come true and, yet, secure the sages being transmitted in the protocol. This means that the ad- communication between the Client and SP we use the IdP as a Key versary can eavesdrop and modify messages. The adversary is also Distribution Center, or KDC for short. able to replay messages previously sent in the protocol. It is as- Second, we tried to decrease the message exchange load on the sumed that the adversary knows the authentication protocol and Client-side. By way of example, instead of the Client first contact- its steps. FLAT adopts a set of countermeasures to secure the mes- ing the SP ( Fig. 1 , step 1) for only then being redirected to the IdP sages transmitted in the protocol (see Section 6 for an analysis of ( Fig. 1 , step 3), Clients, in FLAT, start by directly contacting the IdP the countermeasures utilized in FLAT in order to protect the in- ( Fig. 7 , step 1) as soon as it gets the SP service announcement. (Re- tegrity, confidentiality, authenticity, liveness, availability, and pri- call we assume Clients get aware of the SP and the services it pro- vacy). vides through the use of Service Discovery –c.f. Section 5.1 , Service Discovery.) 6.2. Security properties Last, FLAT replaces conventional certificates with Implicit Cer- tificates [12] —also known as Elliptic Curve Qu-Vanstone (ECQV) This section discusses FLAT under the security properties of au- — during the SP-IdP communication ( Fig. 7 , steps 3 and 4). Im- thentication, confidentiality, liveness, integrity, availability, and pri- plicit Certificates reconstruct public keys from public informa- vacy. tion, so there is no need to store them in certificates, explicitly. FLAT uses (i) Message Authentication Codes (MACs) and digital This, in turn, reduces the sizes of the certificates and then saves signatures for providing both authentication and integrity; (ii) ci- bandwidth. Further, the certificate verification in this cryptosys- phers for confidentiality; and (iii) nonces for liveness, i.e .for pre- tem is performed implicitly, which in turn makes it more efficient, venting replay-attacks [5] . Table 3 summarizes the countermea- too. (For detailed information on Implicit Certificates, please refer sures adopted by FLAT to reduce the possibilities of attacks related to Brown et al. [12] .). to each of the security properties. 5.4. Message description 6.2.1. Authentication In order to ensure authenticity in Client ↔ SP, IdP ↔ SP and The message used in FLAT is shown in Fig. 9 . The first Client ↔ IdP communication, FLAT uses MACs and digital signatures. byte is used for message type –in FLAT, there are ten mes- Regarding Client ↔ IdP communication, FLAT relies on a pre- sage types, namely: key request, Client key, certificate-challenge, shared symmetric key ( k ). When the IdP sends a message to certificate-response, SP key, key acknowledgment, assertion request, IdP,C the Client using this key (steps 1.2 and 3.2, Protocol 1 ), the Client assertion, service request, and service The second byte is used for knows it is communicating with its IdP, since only the IdP has storing the sequence number. The following two fields have three access to the symmetric key shared through a secure channel in bytes each and are reserved for storing the source and destination the pre-deployment stage. The same applies to the case when the identifiers in the application layer. Hence, FLAT supports domains Client is sending a message to its IdP (steps 1.1 and 3.1, Protocol 1 ). up to 2 24 ( ≈ 16 million) clients in size. Next, we have a two-byte This symmetric key is used in MACs that protect the messages be- field to store the payload size. Recipients use this field to get to ing exchanged, ensuring its authenticity, i.e., that it was really the know the amount of data they should read. Last, we set a payload IdP (or the Client) who sent it. of at most 280 bytes so that FLAT can accommodate data and cryp- IdP ↔ SP communication starts with a certificate exchange (steps tographic elements typical of an IoT secure communication proto- 2.1 and 2.2, Protocol 1 ). Both SP and IdP certificates are signed by col. the same CA, allowing one to verify the other’s certificate and vice- 6. Security evaluation versa. Once the certificate is verified, when the SP receives a message signed by the IdP and verifies it using the certificate’s pub- In this section, we evaluate the FLAT security. We first define lic key, the SP knows it was really the IdP who sent the message the attack model; then, we discuss the protocol under the secu- (steps 2.3 and 3.2, Protocol 1 ). Similarly, if the IdP receives a mes- rity properties of authentication, confidentiality, liveness, integrity, sage signed by the SP, it can verify its authenticity (steps 2.2 and availability, and privacy; and lastly, we present a formal security 2.4, Protocol 1 ). analysis. Communication between Client and SP also makes use of symmetric keys. After the IdP makes sure it is in fact interacting 6.1. Attack model with the SP (through certificate exchange) and the Client (through the pre-shared symmetric key), it distributes to the SP and the As mentioned in Section 5.1 , there is a pre-distribution of the Client a symmetric key ( k SP,C ). The authentication of messages sent symmetric key used in the Client ↔ IdP communication. It is as- between Client and SP is ensured by MACs (steps 4.1 and 4.2, sumed the presence of a secure channel to share the key before Protocol 1 ). the execution of the authentication protocol. Note that SP’s certificate sent in step 2.2, Protocol 1 is included The adversary may also have physical access to the IoT devices. within the signature. As it bears the CA’s signature over the certifi- FLAT considers the use of PUFs to mitigate the risks in such a sce- cate’s contents, this signature is not necessary. This certificate was nario. included in the signature for the sake of readability. M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253 15

FLAT makes use of implicit certificates (ECQV) to authenticate To increase security, the nonces could be encrypted as well. Al- IdP ↔ SP communication. The implicit certificate scheme is consid- though it is an unlikely possibility, if an attacker has access to ered secure 17 , i.e., an attacker is not able to successfully falsify an a large number of messages and one of the nonces is repeated implicit certificate and a private key that was not issued by a legit- at some time, she might be able to perform an attack using an imate CA [75] . The composition of ECQV implicit certificate scheme old message. For the sake of readability, nonce encryption is sup- and ECDSA (as used in FLAT) is also known to be secure [75] . pressed from the protocol description.

6.2.2. Confidentiality 6.2.4. Integrity FLAT protects the confidentiality of the messages containing To ensure integrity in protocol messages, FLAT uses MACs and ↔ ↔ sensitive information. For that, it uses symmetric encryption in digital signatures. In Client IdP and Client SP communication Client ↔ IdP (steps 1.2, 3.1 and 3.2, Protocol 1 ) and Client ↔ SP (steps MACs are used to provide authentication and integrity to the mes- 4.1 and 4.2, Protocol 1 ) communication, and also asymmetric en- sages, since it makes use of symmetric cryptography (steps 1.1, 1.2, ↔ cryption in IdP ↔ SP (step 2.3, Protocol 1 ) communication. Messages 3.1, 3.2, 4.1, 4.2, Protocol 1 ). IdP SP communication is protected not carrying sensitive information, such as nonces and certificates using digital signatures to guarantee non-repudiation, authentica- (steps 1.1, 2.1, 2.2, and 2.4, Protocol 1 ), are not encrypted. tion, and integrity to the messages being exchanged (steps 2.2, 2.3, A known attack on confidentiality is the eavesdropping of mes- and 2.4, Protocol 1 ). Step 2.1, Protocol 1 is the only one that does sages, i.e., when an attacker successfully intercepts a protocol mes- not include MACs or signatures (except for the signature in the sage during its execution. As pointed out before, messages contain- certificate), sending a nonce and a certificate. Step 3.2, Protocol 1 , ing sensitive information are encrypted, so even if an attacker in- besides the MAC also contains the assertion, which is a signature tercepts one FLAT message, she cannot decrypt its contents. ensuring the assertion was really issued by the IdP. Although this The Man-In-The-Middle attack (MITM) can also affect the con- message is being sent to the Client, it will be forwarded and inter- fidentiality of the information being sent in FLAT. In such an at- preted by the SP (step 4.1, Protocol 1 ), as the Client can not process tack, the attacker stays in between two communicating parties, asymmetric cryptosystems. impersonating a to b and vice-versa. A countermeasure to this One attack to integrity is tampering, which is basically mak- attack is to enable authentication between the parties, requiring ing changes to messages being transmitted. MITM attacks can also proof that they are whom they claim to be during the communi- involve the alteration of messages, i.e., instead of only collecting cation. In FLAT operation, the IdP ↔ SP communication is authen- and passing on the information being sent by each of the commu- ticated through the use of digital signatures, with certificate ex- nicating parties, the attacker can also change the contents of the change before the shared key is sent to the SP. Furthermore, the messages. In this case, FLAT adopted countermeasure is to protect Clients identity is confirmed by the IdP and vice-versa for their the integrity through the use of MACs or digital signatures, as ex- previously shared symmetric key is being employed.The communi- plained before. cation between the Client and the SP is authenticated as well. This Physical tampering is another attack on integrity that can af- is so because the IdP verified the Client’s and SP’s identities be- fect confidentiality. In such a scenario, the attacker will have phys- fore sending them their shared symmetric key. Both the SP and the ical access to the device, getting access to the stored keys or other Client then use this symmetric key in their communication. Thus, information. If the attacker can successfully extract the key from FLAT enables authentication between the communicating parties to the device, the entire authentication process can be compromised. avoid MITM attacks. FLAT uses PUFs to generate keys, which are considered robust and of evident tampering [77] . Thus, even if physical tampering occurs in the IoT device, there will be changes in its behavior, and the key 6.2.3. Liveness generation will be compromised. In this case, it will not be possi- An attack on liveness is the replay attack. In this scenario, an ble to communicate with the IdP and the protocol will not run. attacker intercepts messages from the protocol and can use them later out of the original session or in another moment of the same 6.2.5. Availability session. FLAT uses in its operation randomly generated nonces to Availability is another security property evaluated in the con- ensure the liveness of the messages being sent. Thus, even if an text of FLAT. This security property ensures that the system is attacker can intercept a message and replays it, the attack will not available when the users need it. be successful since the liveness of the message can be verified by In FLAT, it can be considered an attack where a fake SP sends the nonces. fake messages to a legitimate Client. At the time the Client receives Furthermore, FLAT uses a nonce to identify the session with the the advertisement message, it cannot know that it is a fake SP. SP. Besides ensuring the liveness of the message, the nonce n _SP However, since FLAT incorporates a certificate exchange step be- (received by the IdP in step 2.2, Protocol 1 ) is sent to the Client tween SP and IdP (steps 2.1 and 2.2, Protocol 1 ), the SP will be (step 3.2, Protocol 1 ). So when the SP receives this message (step identified as fake by the IdP, and the protocol will not be con- 4.1, Protocol 1 ), it knows the message refers to the same service cluded. request made in the previous steps. Another possibility would be fake Clients sending a series of re- Another attack that can affect liveness and confidentiality is the quests to legitimate SPs to achieve a denial of service attack. In oracle attack. In this kind of attack, the adversary uses the system this case, Clients would need to communicate with their respec- as an oracle, analyzing the answer to a known message in order to tive IdP first, since Clients only communicate directly with the SPs obtain information. The attack is performed using a reply message in the two last steps of the protocol (steps 4.1 and 4.2, Protocol 1 ). of a session during a subsequent session [76] . As a countermea- For the protocol to run, the IdP will need to communicate with sure, FLAT uses a pseudo-random generator to generate nonces in the SP, confirming its identity through the use of certificates. It order to avoid nonce repetition, and thus, leakage of information. is unlikely that a fake Client will be bounded to a legitimate IdP FLAT also uses MAC to authenticate the symmetrically encrypted since the symmetric key exchange that guarantees the communi- messages and signatures for the asymmetrically encrypted mes- cation between Client and IdP is done through a secure channel in sages to mitigate the risks of padding oracle attacks. the pre-deployment stage. After receiving the certificate (step 2.1, Protocol 1 ), the SP will interrupt the protocol execution after ver-

17 Proof available in [12] . ifying that the certiﬁcate is not valid. Even in the case of a fake 16 M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253

Listing 1. Scyther SPDL code snippet.

Client impersonating an IdP, the result would be the same, as the In Scyther, the protocol must be described in a file using the certificate will not be valid. If the number of Clients requesting the Security Protocol Description Language (SPDL). The tool then au- SP (which is an intermediary IoT device) is large enough, it might tomatically analyses the protocols to check if they are prone to be too many requests for it to process. However, in either case, the known attacks that could violate the claimed security properties. authentication will not be successful. We described FLAT in three SPDL files, each containing a description of the communication between a pair of roles. The first file 6.2.6. Privacy describes the communication between the Client’s and IdP’s roles As FLAT adopts the federated model, it increases privacy by lim- during steps 1.1, 1.2, 3.1, and 3.2 of Protocol 1 . The second file de- iting the number of entities that hold the device’s identity infor- scribes the communication between the IdP’s and SP’s roles during mation by only its own IdP. The federated model also increases pri- steps 2.1, 2.2, 2.3, and 2.4. Finally, the last file describes the com- vacy as it allows the entities (user/device) to limit the identity in- munication between the Client’s and SP’s roles during steps 4.1 and formation that they would like to share with the SPs. For instance, 4.2. We refer to Listing 1 to an SPDL code snippet showing an ex- the IdP can share with the SP only the necessary data to provide ample of the description of the steps 4.1 and 4.2. As we can check access to the service, avoiding sending all the information it has in Fig. 8 , Scyther verification has found no known attacks in our about a specific user/device. protocol. Other strategies not addressed here (as they are out of the scope of this paper) include the improvement of the privacy in fed- 7. Development erated models by the use of pseudonyms [6] . We developed a prototype of FLAT. The prototype comprises 6.3. Formal security analysis three modules: Client, SP, and IdP. Both our Client and SP modules are efficient enough to be run on top of resource-constrained We used Scyther [78] to formally verify that FLAT provides the IoT devices like Arduino. The IdP, conversely, is supposed to be security properties described in Table 3 . Scyther is a tool that hosted on a server-like device. This is so because we envision the provides automatic verification of security protocols. Scyther has IdP being the single identity provider for all IoT devices in a given been used to verify the security of many protocols. For instance, domain. Scyther has been applied to the analysis of protocols in the ISO/IEC Broadly, our development involved four stages: (i) the devel- 11770 [79,80] and ISO/IEC 9798 [81] standards. In these analyses, opment of the communication functions, (ii) the implementation Scyther identified security issues in both standards and was later of the cryptosystems, (iii) the integration of the communication used to verify the revised versions to ensure they had the issues functions and the cryptosystems, (iv) the port of the integration to fixed. Arduino. M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253 17

Fig. 8. Scyther results example.

Fig. 9. FLAT Message description.

the IoT world [5] . Precisely, we use Elliptic Curve Digital Signa- tures (ECDSA) and the Elliptic Curve Integrated Encryption Scheme (ECIES) as opposed to their traditional counterparts DSA and RSA [5] . We used RELIC 18 as an underlying cryptographic library. On top of RELIC, we implemented higher-level cryptosystems like Implicit Certiﬁcates. Besides, the toolkit already implemented more common cryptosystems needed in FLAT like ECDSA, ECIES, AES, and HMAC. Respectively, FLAT employs these cryptosystems for digitally signing, asymmetrically encrypting, symmetrically encrypting, and message authentication.

7.3. Security level

According to Barker [82] , a security level of 128 bits is considered acceptable for current use and also for 2030 and beyond, i.e., this security level is not known to be insecure for the mentioned period. Another document from the National Institute of Standards and Technology (NIST) [83] also considers AES-128, SHA-256 and HMAC (with a key length of at least 112 bits) as safe to use, as

Listing 1. Client finite-state machine-like implementation. well as a security level of 112 bits for elliptic curve signatures. The security level implemented in the protocol is approximately 128 bits. For the symmetric encryption was used AES-128, that gives a security level of 128 bits. For the HMAC was used the cryp- 7.1. Communication tographic hash function SHA-256. Regarding the ECC cryptographic functions (ECIES, ECDSA, implicit certificates), was used the curve The communication functions have been developed using the BN-254, which was thought to provide a security level of 128 bits. Arduino Wi-Fi library in C/C++. When an Arduino Wi-Fi Shield is However, a recent work shows that it actually offers a security attached to an Arduino board, this library makes message trans- level of around 100 bits [84] . mission using Wi-Fi (802.11b/g) possible. The library provides both UDP and TCP protocols. FLAT was built on top of UDP and was developed based on the idea of a finite-state machine (Code Listing 1 ) 7.4. Architecture going through each step of the authentication protocol. If the syn- chronization between any pair of interlocutors is lost during the Fig. 10 shows the architecture of FLAT, i.e .the modules (Client, protocol, the process can be restarted through the transmission of SP, and IdP) and submodules (communication and cryptography) a special message. that comprise our solution. On the Client module, there are only symmetric cryptosystems (AES and HMAC). On the SP and IdP 7.2. Cryptography modules, besides the symmetric components, there are also asymmetric cryptosystems (Implicit Certificates, ECDSA, and ECIES). All asymmetric cryptosystems used in FLAT are based on El- liptic Curve Cryptography (ECC), as they incur less computation, communication, and storage overhead and therefore suit better 18 https://github.com/relic-toolkit . 18 M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253

Fig. 10. FLAT architecture.

7.5. Demonstration SG90. Last, we employ some LED bulbs to signal access granted or denied. We developed a demo to showcase our FLAT prototype by demonstrating the functionalities of our architecture and execut- 8. Results ing operations on multiple classes of devices. Our demo covers the authentication part of FLAT applied to a toy cashless tollway sim- We evaluated FLAT authentication protocol in terms of com- ilar to that described in Section 4 . We say toy because we run putation, communication, protocol total run-time, SRAM and stor- FLAT over a mock-up tollway comprised of a toy car and toy gate. age, and scalability. Unless otherwise noticed, the numbers for ( Fig. 11 ). the Client, SP, and IdP in this section refer to numbers mea- In our demo, a car (client) runs FLAT and tries to authenticate sured by running FLAT on top of the demo hardware configura- to a toll gate (SP) by using an assertion supplied by its own do- tion, namely: Arduino Due, Raspberry Pi, and Laptop Dell Inspiron main. If the authentication is successful, a green LED lights, the –c.f. Section 7.5 for details. Moreover, the performance numbers toll gate opens, and the car is granted access to the tollway. Other- correspond to the average value of 100 runs. wise, red LED lights, the gate keeps closed, and the car’s access to We used another protocol as a starting point for some com- the tollway is denied. parisons and called it Baseline . Baseline is similar to a traditional The Client, SP, and IdP have been respectively instantiated by FIdM protocol ( Fig. 1 ) and does not use Implicit Certificates as an Arduino Due (84 MHz Atmel, 96 KB SRAM, 512 KB flash), a FLAT does. For fairness, however, we instantiated Baseline using Raspberry Pi (Raspberry Pi zero W ARM1176JZF-S 1GHz single-core, the same parameters as FLAT: certificate fields, level of security, 512MB RAM), and a Laptop Dell Inspiron (Intel Core i7 2.7 GHz, 8 message format, ECC-based cryptosystems, and so forth. Baseline GB RAM). They correspond to our vision that roles in FLAT will be certificate size is 134 bytes, as opposed to the Implicit Certificate played by heterogeneous devices (c.f. Section 5.1 ). For communica- size used in FLAT, which is 70 bytes. This is so because Baseline tion, the Arduino board is equipped with an Arduino Wi-Fi shield certificate includes, besides the identification information (in our (802.11b/g), and a MikroTik router plays the role of an access point. case, 37 bytes), the public key (32 bytes), and the Certificate Au- For controlling the toll gate, we used a Tower Pro servo motor 9G thority signature (65 bytes). On the other hand, Implicit Certificates M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253 19

Fig. 11. FLAT demo: access (a) granted and (b) denied.

Fig. 12. SRAM costs. require only the identification information (37 bytes) and the pub- sram). Therefore, FLAT, including the needed Arduino libraries to lic key extraction data (33 bytes). run the protocol, takes only 16% of the Client’s total memory (Ar- duino, 15.7 KB out of 96 KB of SRAM). 8.1. RAM & storage To evaluate the storage usage in the Client device, we measured: The size occupied by Arduino’s native libraries, the size oc- We evaluated the FLAT Client requirements regarding SRAM cupied by FLAT communication functions, the size of FLAT cryp- ( Fig. 12 ) and storage. This approach was taken because the Client is tographic functions, and the total size occupied by FLAT, including the most constrained entity in the solution. Thus, the memory and Arduino’s native libraries. storage usage in such device is a critical part of the authentication To measure the size of Arduino’s native libraries, an empty protocol. sketch that did not execute any specific function was loaded into We used an Arduino sketch, whose only goal is to calculate the the Arduino board. Its size was 73.5 kB (Arduino, storage). We also SRAM usage, to measure the SRAM used by the Arduino firmware. uploaded a version of FLAT Client application without the cryp- The results of this experiment show that 4.8 kB of SRAM were tographic functions to the Arduino Due in order to measure the in use by Arduino’s firmware, equivalent to about 5% of the total size of the communication functions, which was found to be 6.8 available in Arduino Due (Firmware, sram) kB (Communication, storage). In order to measure the SRAM usage by FLAT, a second ex- A complete version of FLAT, including the cryptographic library periment was conducted. This experiment showed that FLAT uses RELIC and all communication and cryptographic functions, was also 10.9 kB, equivalent to 11% of the total SRAM (FLAT, sram). As the uploaded to the Client device. We measured the size of the appli- Arduino Due has 96 kB of SRAM available, there is 80.3 kB of cation, and then subtracted the size of the communication func- free SRAM, equivalent to 84% of the total memory available (Free, tions and the Arduino’s native libraries from this value. The result 20 M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253

Fig. 13. Communication costs.

Fig. 14. Communication costs. was the storage usage by the cryptographic library and functions this message is 76 bytes (payload of 66 bytes plus a header of alone (45.5 kB, Crypto, Fig. 13 ). FLAT complete application (includ- 10 bytes). Therefore, in this step 2.4, the evaluation considers the ing RELIC, cryptographic functions, communication functions, and 76 bytes transmitted by the SP and the 76 bytes received by the Arduino’s native libraries) summed 125.8 kB (Total, Fig. 13 ). IdP. The analysis does not take into account UDP/IP headers, as the Considering the total storage available in the Client device (512 same network protocol stack is applied to both FLAT and Baseline. kB), FLAT uses less than 25 % of the flash memory, showing that it We consider this is as a reasonable approach, since the idea of this has a small memory footprint. analysis is to establish a comparison between FLAT and Baseline. In total, FLAT exchanges around 500 bytes on the Client-side. It 8.2. Communication is worth pointing out that the FLAT Client is around 65% more efficient regarding Tx, Rx, and total data exchanged in comparison Fig. 14 shows the amount of data sent (Tx) and received (Rx) with Baseline. Likewise, FLAT, as a whole, is 31% more efficient by the Client, SP, and IdP in both FLAT and Baseline. In this exper- than Baseline regarding data exchange (Tx plus Rx). This lower iment, we calculated and summed the corresponding sizes of each communication overhead on the Client-side is mainly because we cryptographic primitive in each message transmitted in the proto- use symmetric cryptosystems –they do not require certificate ex- col. This approach was preferred since the data types used in the change. FLAT SP is around 9%, 14%, and 12%, respectively, more effi- implementation might send some extra data. cient with respect to Tx, Rx and total data exchange than Baseline Note that by taking this approach, the communication costs SP. These light Client and SP, however, come with a price. To al- only contemplate application layer data, i.e., the sizes considered leviate the Client and SP, FLAT demands more from the IdP. And for evaluation were the messages defined in the protocol de- then, because the use of (shorter) Implicit Certificates, the IdP to- scription (payload) and the size of the defined message format tal message exchange is only 20% higher than in Baseline. As the ( Fig. 9 ), with the header. For instance, when we evaluate step 2.4, IdP can be a powerful device and, able to handle the total load, we Protocol 1 , we consider the size of the ECDSA signature (64 bytes) believe that this amount of extra communication is not a concern, together with the size of the nonce (2 bytes). The total size for specially when compared to the very short Client messages. M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253 21

Fig. 15. Computation costs.

Fig. 16. Total protocol run-time.

8.3. Computation solution for constrained devices. In Baseline, on the other hand, the Client needs to compute the following asymmetric operations: We also evaluated the computational costs involved in the cryp- ECIES encryption (1 time), ECIES decryption (1 time), ECDSA sig- tographic functions used by FLAT and Baseline. These costs were nature (2 times) and ECDSA signature verification (5 times). And estimated considering the time to execute each cryptographic func- while symmetric operations are known to be negligible [10] even tion for each message transmitted by the protocol. in resource-constrained devices, asymmetric operations are known This evaluation consisted of two steps. In the first step, the time to be slow [85] , even the most efficient ones based on ECC. The to execute each cryptographic function (ECIES encryption, ECDSA second reason comes from the Client delegating several tasks to signature verification, etc.) was measured in each device. In the the SP and IdP. Because of that the FLAT SP and IdP end up be- second step, considering each message exchanged, the times were ing 4% and 2% less computationally efficient than Baseline, respec- summed to obtain the total time for Client, SP, and IdP. If we take tively. This is a minimal price to pay compared to the gains ob- step 2.4, Protocol 1 again as an example, the evaluation will con- tained on other fronts, though. sider the time to generate a signature on the SP (around 5 ms) and the time to verify the signature on the IdP (around 0.5 ms). Note that the time to generate or verify nonces was considered negli- 8.4. Total Run-time gible. It is essential to mention that the steps executed before the operation stage of the protocol (for instance, certificate generation We have measured the total amount of time that takes to run by a CA and generation of public/private key pairs) were not taken FLAT —around65 ms ( Fig. 16 )—and compared that to Baseline. into consideration. This evaluation considered the time necessary to run all the cryp- The computational costs of FLAT and Baseline considering tographic operations executed by Client, SP, and IdP in both FLAT Client, SP, and IdP are depicted in Fig. 15 . The FLAT Client is and Baseline. The total time is the sum of the computational costs around 520 times faster than the Baseline ( Fig. 15 , Client). There calculated for each device. Similarly to the evaluation of the com- are two main reasons for this. First, FLAT runs solely symmet- putational costs, the total run-time considered only the time to ex- ric cryptosystems on the Client-side. This is, in fact, one of the ecute the cryptographic functions that make the two protocols dif- main strategies proposed by FLAT in order to make it a lightweight ferent. 22 M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253

FLAT takes around 65 ms to run (for a 90% confidence interval Client only to have a low power Wi-Fi connection. This could elim- FLAT runs in 64.65 ± 0.33 ms), which corresponds to around 4% inate the need for an Internet connection on the Client side: Only of the total time required to run Baseline (for a 90% confidence a connection to the SP would be necessary. interval Baseline runs in 1618.49 ± 0.08 ms). This is a direct consequence of the computation ( Section 8.3 ) Declaration of Competing Interest and communication ( Section 8.2 ) numbers previously shown, i.e .FLAT exchanges fewer and smaller messages as well as requires The authors declare that they have no known competing finan- significantly less computational work from the Client. cial interests or personal relationships that could have appeared to Notably, the fact that FLAT is computationally more efficient in influence the work reported in this paper. the slow part of the protocol (Client – Section 8.3 ) —and only slightly less (4% and 2%) in the fast part (SP and IdP, respectively) — helps in improving its total run-time speedup compared to Base- Acknowledgments line. We would like to thank Michelle Wangham, André Lins, Clayton 8.5. Scalability Reis, Artur Souza, Antônio Maia, Pedro Pinto, Emerson Mello, and Mark Horowitz for contributing with fruitful discussions to this FLAT scales smoothly regarding the number of Clients. If the work. We also thank RNP for funding the work group GT-CoFee, number of Clients gets too large for a given IdP, we only need to and CNPq for funding the process 306472/2017-1, and FAPEMIG for create one more IdP certified by the same Certificate Authority. Of funding the process APQ-02990-15. This study was financed in part course, this could be done in any federation. In FLAT, this process is by the Coordenação de Aperfeiçoamento de Pessoal de Nível Supe- straightforward, as we can adopt a limit on the number of clients rior - Brasil (CAPES) - Finance Code 001. that an IdP can attend and, if such a limit is reached, another IdP is installed. New clients would be communicating with this new References IdP, without any changes to the previous configuration. [1] L. Atzori , A. Iera , G. Morabito , The internet of things: a survey, Comput. Netw.

9. Conclusion 54 (15) (2010) 2787–2805. [2] J. Gubbi , R. Buyya , S. Marusic , M. Palaniswami , Internet of things (IoT): a vision, architectural elements, and future directions, Fut. Gener. Comput. Syst. 29 (7) As IoT gains more visibility and IoT solutions are being incorpo- (2013) 1645–1660 . rated in the most diverse fields, there is a real need to ensure the [3] E. Borgia, The internet of things vision: Key features, applications and open issues, Comput. Commun. 54 (2014) 1–31 . security of the developed IoT applications and preserve the privacy [4] L.B. Oliveira , F.M.Q. Pereira , R. Misoczki , D.F. Aranha , F. Borges , M. Nogueira , of their users. M. Wangham , M. Wu , J. Liu , The computer for the 21st century: present secu- In this work, we design, develop, and evaluate a federated rity & privacy challenges, J. Internet Serv. Appl. 9 (1) (2018) 24 . [5] W. Stallings , Cryptography and Network Security: Principles and Practice, Pear- identity authentication protocol exclusively tailored to IoT called son, 2016 . FLAT. FLAT considers that Clients will run on top of devices with [6] E. Birrell , F.B. Schneider , Federated identity management systems: a priva- low computational capabilities and, thus, requires only symmet- cy-based characterization, IEEE Secur. Priv. 11 (5) (2013) 36–48 . [7] S.S.Y. Shim , G. Bhalla , V. Pendyala , Federated Identity Management, IEEE Com- ric (light) cryptographic capabilities from them. Besides, FLAT em- put. 38 (12) (2005) 120–122 . ploys Implicit Certificates rather than regular certificates in the [8] P. Fremantle , B. Aziz , J. Kopecký, P. Scott , Federated identity and access man- IdP ↔ SP communication for saving both computation and band- agement for the internet of things, in: International Workshop on Secure In-

ternet of Things (SIoT’14), 2014, pp. 10–17. width. FLAT also replaces ineﬃcient cryptosystems like RSA/DSA [9] P. Fremantle , B. Aziz , OAuthing: privacy-enhancing federation for the Internet by others more suitable to IoT and reduces the message load in of Things, in: Cloudiﬁcation of the Internet of Things (CIoT’16), 2016, pp. 1–6 . the Client device. We developed and evaluated a prototype of FLAT [10] A. Perrig , R. Szewczyk , V. Wen , D. Culler , J.D. Tygar , SPINS: security protocols on top of constrained devices like Arduino. Precisely, we evaluated for sensor networks, Wirel. Netw. 8 (5) (2002) 521–534. [11] M.L.B.A. Santos , J.C. Carneiro , F.A. Teixeira , A.M.R. Franco , M.A .A . Henriques , the prototype applied to a cashless toll system in terms of storage, L.B. Oliveira , Federated authentication of things: demo abstract, in: Proceed- SRAM, communication, computation, and total run-time. ings of the 17th ACM/IEEE International Conference on Information Processing

FLAT computation in the Client is 520 times more efficient than in Sensor Networks, in: IPSN ’18, IEEE Press, 2018, pp. 136–137. [12] D.R.L. Brown , R.P. Gallant , S.A. Vanstone , Provably secure implicit certificate the baseline solution. FLAT uses around 16% of Client’s SRAM and schemes, in: International Conference on Financial Cryptography (FC’02), 2002, 24% of Client’s flash memory when running in an Arduino Due pp. 156–165 . device. Moreover, FLAT total run-time represents 4% of the to- [13] A . Whitmore , A . Agarwal , L. Da Xu , The internet of things a survey of topics and trends, Inf. Syst. Front. 17 (2) (2015) 261–274 . tal time necessary to run Baseline. Regarding the communication [14] P.J. Windley , Digital Identity: Unmasking Identity Management Architecture costs, FLAT is also 31% more efficient than the baseline protocol (IMA), O’Reilly Media, Inc., 2005 . when considering the total data exchange. Our results confirm that [15] M. Nogueira , A. Santos , J. Torres , A. Zanella , Y. Danielewicz , Gerência de iden- tidade na internet do futuro, Minicurso Apresentado no Simpósio Brasileiro de

FLAT can run eﬃciently on top of IoT devices. Redes de Computadores e Sistemas Distribuídos-SBRC (2011) 1–6 . FLAT is a step towards the development of a complete IdM sys- [16] Y. Cao , L. Yang , A survey of identity management technology, in: 2010 IEEE In- tem that could take care of all the lifecycle of an IoT device, as ternational Conference on Information Theory and Information Security, IEEE,

2010, pp. 287–293. it provides a lightweight authentication solution, contemplates the [17] E. Maler , D. Reed , The venn of identity: options and issues in federated identity mobility aspect of devices considering different security domains, management, IEEE Secur. Priv. 6 (2) (2008) 16–23 . and has an operational prototype. [18] A. Jøsang , S. Pope , User centric identity management, in: AusCERT Asia Paciﬁc

As future works, we consider the development of a complete Information Technology Security Conference, Citeseer, 2005, p. 77. [19] D. Chadwick , Federated identity management, Found. Secur. Anal. Des. V IdM system. By now, FLAT is an authentication solution for IoT. (2009) 96–120 . The next steps will complete the IdM solution with the implemen- [20] A. Armando , R. Carbone , L. Compagna , J. Cuellar , G. Pellegrino , A. Sorniotti , tations of the authorization, service discovery process, and tear- From multiple credentials to browser-based single sign-on: Are we more secure? in: IFIP International Information Security Conference, Springer, 2011, down. pp. 68–79 . Another future work includes the proposal and evaluation of [21] H. Lockhart , B. Campbell , Security assertion markup language (SAML) v2. 0 different communication possibilities for the Client device. The technical overview, 2, 2008, pp. 94–106 . OASIS Committee Draft [22] Shibboleth Consortium, Shibboleth Consortium - Privacy Preserving Identity

Client could use the SP as an intermediate to communicate with Management, 2018. https://www.shibboleth.net/ . the IdP, using SP’s permanent Internet connection and enabling the [23] D. Hardt , The Oauth 2.0 Authorization Framework, 2012 . M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253 23

[24] N. Sakimura , J. Bradley , M. Jones , B. de Medeiros , C. Mortimore , Openid con- [55] A. Mehmood , M.M. Umar , H. Song , Icmds: secure inter-cluster multiple-key nect core 1.0 incorporating errata set 1, 2014 . The OpenID Foundation, Specifi- distribution scheme for wireless sensor networks, Ad Hoc Netw. 55 (2017) cation 97–106 . [25] V.S. Miller , Use of elliptic curves in cryptography, in: Conference on the Theory [56] D.W. Chadwick , G. Inman , Attribute aggregation in federated identity manage- and Application of Cryptographic Techniques, Springer, 1985, pp. 417–426 . ment, IEEE Comput. 42 (5) (2009) 33–40 . [26] N. Koblitz , Elliptic curve cryptosystems, Math. Comput. 48 (177) (1987) [57] M. Isaakidis , H. Halpin , G. Danezis , UnlimitID: privacy-preserving federated 203–209 . identity management using algebraic MACs, in: Workshop on Privacy in the [27] D. Johnson , A. Menezes , S. Vanstone , The elliptic curve digital signature algo- Electronic Society (WPES’16), ACM, 2016, pp. 139–142 . rithm (ECDSA), Int. J. Inf. Secur. 1 (1) (2001) 36–63 . [58] J. Liu , Y. Xiao , C.P. Chen , Authentication and access control in the Internet of [28] V.G. Martínez , L.H. Encinas , C.S. Ávila , A survey of the elliptic curve integrated Things, in: International Conference on Distributed Computing Systems Work- encryption scheme, Ratio 80 (1024) (2010) 160–223 . shops (ICDCSW), IEEE, 2012, pp. 588–592 . [29] D. Brown, Standards for Efficient Cryptography 1 (SEC-1), (2009). [59] S. Cirani , M. Picone , P. Gonizzi , L. Veltri , G. Ferrari , IoT-OAS: an oauth-based au- [30] V. Gayoso Martínez , L. Hernández Encinas , A. Queiruga Dios , Security and prac- thorization service architecture for secure services in IoT scenarios, IEEE Sens. tical considerations when implementing the elliptic curve integrated encryp- J. 15 (2) (2015) 1224–1234 . tion scheme, Cryptologia 39 (3) (2015) 244–269 . [60] M.C. Domenech , A. Boukerche , M.S. Wangham , An authentication and autho- [31] D.B. Johnson , A.J. Menezes , Elliptic curve dsa (ECDSA): an enhanced DSA, in: rization infrastructure for the Web of Things, in: ACM Symposium on QoS Proceedings of the 7th Conference on USENIX Security Symposium, 7, 1998, and Security for Wireless and Mobile Networks (Q2SWinet’16), 2016, pp. 39– pp. 13–23 . 46 . [32] Certicom, Explaining Implicit Certificate, 2018. [61] M. Turkanovi c´ , B. Brumen , M. Hölbl , A novel user authentication and key [33] Certicom , SEC 4: Elliptic Curve Qu-Vanstone Implicit Certificate Scheme agreement scheme for heterogeneous ad hoc wireless sensor networks, based (ECQV), Technical Report, Standards for Efficient Cryptography, 2013 . on the Internet of Things notion, Ad Hoc Netw. 20 (2014) 96–112 . [34] A .A . Yavuz , ETA: efficient and tiny and authentication for heterogeneous wire- [62] R. Amin , G. Biswas , A secure light weight scheme for user authentication less systems, in: ACM Conference on Security and Privacy in Wireless and Mo- and key agreement in multi-gateway based wireless sensor networks, Ad Hoc bile Networks (WiSec’13), ACM, 2013, pp. 67–72 . Netw. 36 (2016) 58–80 . [35] D. Wang , P. Wang , On the anonymity of two-factor authentication schemes for [63] S.-K. Yang , Y.-M. Shiue , Z.-Y. Su , I.-H. Liu , C.-G. Liu , An authentication infor- wireless sensor networks: attacks, principle and solutions, Comput. Netw. 73 mation exchange scheme in WSN for IoT applications, IEEE Access 8 (2020) (2014) 41–57 . 9728–9738 . [36] W. Xi , C. Qian , J. Han , K. Zhao , S. Zhong , X.-Y. Li , J. Zhao , Instant and robust [64] M. Wazid , A.K. Das , S. Shetty , J. JPC Rodrigues , Y. Park , Ldakm-eIoT: lightweight authentication and key agreement among mobile devices, in: ACM Conference device authentication and key management mechanism for edge-based IoT de- on Computer and Communications Security (CCS’16), ACM, 2016, pp. 616–627 . ployment, Sensors 19 (24) (2019) 5539 . [37] A .L.M. Neto , A .L. Souza , I. Cunha , M. Nogueira , I.O. Nunes , L. Cotta , N. Gen- [65] A . Witkovski , A . Santin , V. Abreu , J. Marynowski , An IdM and key-based au- tille , A .A . Loureiro , D.F. Aranha , H.K. Patil , et al. , AoT: authentication and access thentication method for providing single sign-on in IoT, in: IEEE Global Com- control for the entire IoT device life-cycle, in: ACM Conference on Embedded munications Conference (GLOBECOM’15), IEEE, 2015, pp. 1–6 . Network Sensor Systems (Sensys’16), ACM, 2016, pp. 1–15 . [66] J. Hong , A. Levy , P. Levis , Demo: building comprehensible access control for the [38] M.T. Hammi , B. Hammi , P. Bellot , A. Serhrouchni , Bubbles of trust: a decentral- Internet of Things using beetle, in: ACM International Conference on Mobile ized blockchain-based authentication system for IoT, Comput. Secur. 78 (2018) Systems, Applications, and Services (MobiSys’16), 2016 . 126–142 . [67] M. Ali , T.S. Sobh , S. El-Gamal , Identity management: lightweight SAML for less [39] S. Kumari , M. Karuppiah , A.K. Das , X. Li , F. Wu , N. Kumar , A secure authentica- processing power, IJ Inf. Technol. Comput. Sci. (2015) 42–49 . tion scheme based on elliptic curve cryptography for IoT and cloud servers, J. [68] S. Horrow , A. Sardana , Identity management framework for cloud based Inter- Supercomput. 74 (12) (2018) 6428–6453 . net of Things, in: International Conference on Security of Internet of Things [40] A. Ometov , V. Petrov , S. Bezzateev , S. Andreev , Y. Koucheryavy , M. Gerla , Chal- (SecurIT’12), 2012, pp. 200–203 . lenges of multi-factor authentication for securing advanced IoT applications, [69] R. Hummen , J.H. Ziegeldorf , H. Shafagh , S. Raza , K. Wehrle , Towards viable cer- IEEE Netw. 33 (2) (2019) 82–88 . tificate-based authentication for the Internet of Things, in: Workshop on Hot [41] H. Kim , E. Kang , E.A. Lee , D. Broman , A toolkit for construction of authoriza- Topics on Wireless Network Security and Privacy (HotWiSec’13), ACM, 2013, tion service infrastructure for the Internet of Things, in: ACM/IEEE Interna- pp. 37–42 . tional Conference on Internet-of-Things Design and Implementation (IoTDI’17), [70] T. Markmann , T.C. Schmidt , M. Wählisch , Federated end-to-end authentication ACM/IEEE, 2017, pp. 147–158 . for the constrained Internet of Things using IBC and ECC, ACM SIGCOMM Com- [42] M. Wu , F. Quintão Pereira , J. Liu , H.S. Ramos , M.S. Alvim , L.B. Oliveira , New di- put. Commun. Rev. 45 (4) (2015) 603–604 . rections: proof-carrying sensing–towards real-world authentication in cyber– [71] A . Karim , M.A . Adnan , An OpenID based authentication service mechanisms physical systems, in: Proceedings of ACM Conf. on Embedded Networked Sen- for Internet of Things, in: 2019 IEEE 4th International Conference on Computer sor Systems (SenSys). New York: ACM, 2017 . and Communication Systems (ICCCS), IEEE, 2019, pp. 687–692 . [43] X. Li , J. Niu , S. Kumari , F. Wu , A.K. Sangaiah , K.-K.R. Choo , A three-factor anony- [72] Z. Shelby , K. Hartke , C. Bormann , B. Frank , RFC 7252: the constrained applica- mous authentication scheme for wireless sensor networks in internet of things tion protocol (CoAP), Internet Eng. Task Force (2014) . environments, J. Netw. Comput. Appl. 103 (2018) 194–204 . [73] C.N. Ververidis , G.C. Polyzos , Service discovery for mobile ad hoc networks: a [44] X. Zeng , G. Xu , X. Zheng , Y. Xiang , W. Zhou , E-aua: an efficient anonymous survey of issues and techniques, IEEE Commun. Surv. Tut. 10 (3) (2008) 30–45 . user authentication protocol for mobile IoT, IEEE Internet Things J. 6 (2) (2018) [74] G.E. Suh , S. Devadas , Physical unclonable functions for device authentica- 1506–1519 . tion and secret key generation, in: ACM/IEEE Design Automation Conference [45] L. Bu , M. Isakov , M.A. Kinsy , A secure and robust scheme for sharing confiden- (DAC’07), ACM/IEEE, IEEE, 2007 . pp. 9–14 tial information in IoT systems, Ad Hoc Netw. 92 (2019) 101762 . [75] D.R. Brown , M.J. Campagna , S.A. Vanstone , Security of ECQV-certified ECDSA [46] U. Khalid , M. Asim , T. Baker , P.C. Hung , M.A. Tariq , L. Rafferty , A decentralized against passive adversaries, IACR Cryptol. ePrint Archive 2009 (2009) 620 . lightweight blockchain-based authentication mechanism for IoT systems, Clust. [76] J. Hamid , M. Gianluigi , W.D. Lilburn , Handbook of Electronic Security and Dig- Comput. (2020) 1–21 . ital Forensics, World Scientific, 2010 . [47] M. Dammak , O.R.M. Boudia , M.A. Messous , S.M. Senouci , C. Gransart , To- [77] S. Katzenbeisser , Ü. Kocaba s¸ , V. Roži c´ , A.-R. Sadeghi , I. Verbauwhede , C. Wachs- ken-based lightweight authentication to secure IoTnetworks, in: 2019 16th mann , PUFs: Myth, fact or busted? A security evaluation of physically unclon- IEEE Annual Consumer Communications & Networking Conference (CCNC), able functions (PUFs) cast in silicon, International Workshop on Cryptographic IEEE, 2019, pp. 1–4 . Hardware and Embedded Systems (CHES’12), IACR, Springer, 2012, pp. 283– [48] M. Nafi, S. Bouzefrane , M. Omar , Matrix-based key management scheme for 301 . IoT networks, Ad Hoc Netw. 97 (2020) 102003 . [78] C. Cremers, The scyther tool: verification, falsification, and analysis of security [49] L.B. Oliveira , M. Scott , J. Lopez , R. Dahab , TinyPBC: pairings for authenticated protocols, in: Computer Aided Verification, 20th International Conference, CAV identity-based non-interactive key distribution in sensor networks, in: Inter- 2008, Princeton, USA, Proc., volume 5123/2008 of Lecture Notes in Computer national Conference on Networked Sensing Systems (INSS), 2008 . Science, Springer, 2008, doi: 10.1007/978- 3- 540- 70545- 1 _ 38 . pp. 414–418 [50] A. Souza , Í. Cunha , L. B Oliveira , Nomadikey: user authentication for smart de- [79] C. Cremers , M. Horvat , Improving the ISO/IEC 11770 standard for key manage- vices based on nomadic keys, Int. J. Netw. Manag. 28 (1) (2018) e1998 . ment techniques, in: International Conference on Research in Security Stan- [51] D. Aranha , L.B. Oliveira , J. López , R. Dahab , Nanopbc: implementing crypto- dardisation, Springer, 2014, pp. 215–235 . graphic pairings on an 8-bit platform, in: Conference on Hyperelliptic Curves, [80] C. Cremers , M. Horvat , Improving the ISO/IEC 11770 standard for key manage- discrete Logarithms, Encryption, etc (CHiLE 20 09), 20 09 . ment techniques, Intern. J. Inf. Secur. 15 (6) (2016) 659–673 . [52] E. Souza , H.C. Wong , Í. Cunha , Í. Cunha , L.F.M. Vieira , L.B. Oliveira , End-to-end [81] D. Basin , C. Cremers , S. Meier , Provably repairing the ISO/IEC 9798 standard authentication in under-water sensor networks, in: 2013 IEEE Symposium on for entity authentication 1, J. Comput. Secur. 21 (6) (2013) 817–846 . Computers and Communications (ISCC), IEEE, 2013, pp. 0 0 0299–0 0 0304 . [82] E. Barker , Recommendation for key management, Part 1: General, NIST Special [53] P. Porambage , C. Schmitt , P. Kumar , A. Gurtov , M. Ylianttila , Two-phase authen- Publication 800–57 Part 1, Revision 4, 2016 . tication protocol for wireless sensor networks in distributed IoT applications, [83] E. Barker , A. Roginsky , Transitioning the use of cryptographic algorithms and in: IEEE Wireless Communications and Networking Conference (WCNC’14), key lengths, SP 800-131A Rev. 2 (DRAFT), 2018 . IEEE, 2014, pp. 2728–2733 . [84] R. Barbulescu , S. Duquesne , Updating key size estimations for pairings, J. Cryp- [54] Y. Harbi , Z. Aliouat , A. Refoufi, S. Harous , A. Bentaleb , Enhanced authentication tol. (2017) 1–39 . and key management scheme for securing data transmission in the internet of [85] D.J. Malan , M. Welsh , M.D. Smith , Implementing public-key infrastructure for things, Ad Hoc Netw. 94 (2019) 101948 . sensor networks, ACM Trans. Sensor Netw. 4 (4) (2008) 22:1–22:23 . 24 M.L.B.A. Santos, J.C. Carneiro and A.M.R. Franco et al. / Ad Hoc Networks 107 (2020) 102253

Maria Luiza holds a Master’s Degree in Computer Sci- Marco A. A. Henriques : Bachelors in Electrical Engineer- ence from the Federal University of Minas Gerais. She ing from Juiz de Fora Federal University - MG - Brazil is a Computer Engineer (Federal Center of Technologi- (1986), M.Sc. in Electrical Engineering from Chiba (Na- cal Education of Minas Gerais) and also holds a Pro- tional) University - Japan (1990), and Ph.D. in Computer fessional Bachelor’s Degree in Computer Networks and Science from Chiba (National) University - Japan (1993). Telecommunications from Universit E¸ Joseph Fourier (UJF- Worked as a researcher and Associate Professor at the IUT1, France). She was part of research projects related to Information Engineering Department, Shinshu (National) Security for the Internet of Things, Data Mining and Arti- University - Japan (1993 - 1996). Presently, is an Asso- ﬁcial Neural Networks. Her research interests include In- ciate Professor at the School of Electrical and Computer ternet of Things, Information Security and Computer Net- Engineering, University of Campinas (Unicamp). Besides works. his academic activities at Unicamp, he worked also as coordinator of Computer Engineering undergraduate course, head of Unicamps Computing Center (CCUEC) and Uni-

Jéssica Carneiro is a MSc student in the Computer camp General Coordinator of Communications and Information Technology oﬃce

Science Department at Universidade Federal de Minas (CTIC). Main activities: teaching, researching and advising undergrad, master and

Gerais. She got her BSc in Computer Science at Univer- doctorate students in the ﬁeld of Computer Science and Engineering, with empha-

sidade Federal de Minas Gerais in 2018. Her research in- sis on information security and high performance computing. terests include computer security, post-quantum cryptog-

raphy, hash-based signatures, IoT security. Leonardo B. Oliveira is a visiting associate professor of Engineering at Stanford University, a professor of Com- puter Science at UFMG, and a research productivity fellow of the Brazilian Research Council (CNPq). Leonardo has been awarded the Microsoft Research Ph.D. Fellow- ship Award, the IEEE Young Professional Award, and the Intel Strategic Research Alliance Award. He published pa- pers on the security of IoT/Cyber-Physical Systems in publication venues like IPSN and SenSys, and he is the

Antônio Franco is an MSc student in the Computer (co)inventor of an authentication scheme for IoT (USPTO

Science Department at the Federal University of Minas Patent Application No. 20170214529A1). Leonardo served

Gerais. He is also the Chief Technology Oﬃcer of Paciﬁc as General Chair and TPC Chair of the Brazilian Sympo-

Security, a Brazilian company that acts in the offensive sium on Security (SBSeg) in 2014 and 2016, respectively,

security ﬁeld. He had previous experience as an Offen- and as a member in the Advisory Board of the Special Interest Group on Informa-

sive Security Engineer and got some industry certiﬁca- tion and Computer System Security (CESeg) of the Brazilian Computer Society. He

tions like OSCE, OSCP, Security+, CCNA, and LPI. is a former member of the Technical Committee of Identity Management (CT-GId) of the Brazilian National Research and Educational Network (RNP).

Fernando A. Teixeira is a professor at UFSJ in Ouro Branco (Brazil) since 2010. He got his Computer Science PhD degree from UFMG in 2015 and his Strategic IT Man- agement MBA degree from FGV in 2009. He was a Soft- ware Development Leader at Squadra Technology from 2001 to 2010, and the Co-founder of ETEG Technology in 20 0 0. He also was a Consultant at PoP-MG RNP from 1998 to 20 0 0.