FSEE: A Forward Secure End-to-End Encrypted Message Transmission System for IoT

Leakage of long-term secrets is a major concern when cryptographic schemes are implemented on devices with weak protection capability, especially for resource-constrained IoT devices. Forward secrecy is a means to minimize the damage when such an event takes place. For pub-/sub-based IoT systems, several end-to-end (from publisher to subscriber) encrypted message transmission schemes have been proposed to tackle the confidentiality problems brought by malicious message brokers. But none of them provide forward secrecy. 'is article presents FSEE, a forward secure end-to-end encrypted message transmission system for pub-/sub-based IoT. To support FSEE, we design a novel group key exchange protocol BA-GKE, which relies on a semi-trusted key exchange server to provide forward secrecy and support asynchronous communication between groupmembers.We prove its forward secrecy by ProVerif. 'e core idea of FSEE is to establish a forward secure symmetric key per device using BA-GKE asynchronously, and this device-specific key is shared with the device and its authorized subscribers for encrypting messages securely. By adding a semi-trusted key exchange server to realize BA-GKE in the current IoTarchitecture, FSEE does not need to change the existing message broker and could be deployed incrementally. 'e experimental results show that FSEE has comparable performance to existing prominent research and provides higher security.


Introduction
In order to realize large-scale communication between multiple entities in the Internet of ings (IoT), many IoT systems distribute messages based on the publish-subscribe (pub/sub) paradigm. A typical pub-/sub-based IoT system contains devices with sensors, user's mobile applications, and the message broker (generally deployed on the cloud platform) [1], and the network architecture is shown in Figure 1. Devices and applications perform as publishers and subscribers in the systems. Devices publish the sensor collected data to a specific topic (such as topic_stat), and authorized users' applications subscribe to the topic. With the help of the message broker's subscription collection and Currently, the data transmitted between clients (publishers and subscribers) and the message broker in IoT systems are generally protected by TLS [1][2][3]. e publisher encrypts and sends the packets to message broker through the secure channel established between the two parties via TLS. e message broker gets the plaintext by decrypting the packets, then encrypts for each authorized subscriber, and sends the corresponding packet to the subscriber again via TLS. TLS is designed for one-to-one communication between two entities, and the message broker could get all the plaintext of each client. is approach forces us to trust the broker for data processing [4]. Since the IoT device manufacturers or IoT cloud platform vendors usually establish and maintain the broker, we cannot take its trustworthiness for granted.
Under normal circumstances, the data generated by IoT devices are usually closely related to users' living habits, whereas the message broker is not completely reliable. e centralized services provided by the message brokers perform like a black box for IoT users, where users do not have control over how brokers use their data [5]. Many Internet-accessible message brokers even do not deploy any security policies, and anyone can inject data or receive messages [6]. Some researchers show that the MQTT message brokers of a speci c tra c monitoring system were disclosing the tra c ow of Mexico City [7]. Servers infected by spyware may leak secret credentials to an adversary, which may hamper the security of missioncritical data [8]. What's more, most of the current IoT systems are constructed based on the MQTT messaging protocol, and the MQTT protocol is not designed for hostile environments. Yan Jia et al. found that the MQTT protocol has serious aws. Platforms using MQTT protocol can allow adversaries to access devices, launch largescale denial of service (DoS) attacks, steal users' private information, and forge users' device status [9].
To address the privacy and con dentiality concerns brought by malicious message brokers, several end-to-end (from publisher to subscriber) encrypted message distribution methods have been proposed. Essentially, the existing methods can roughly be divided into three categories. e rst category is that the publisher and subscriber coordinate to establish an encryption key [10][11][12][13][14]. e broker in the middle does not know the key and therefore cannot get the plaintext. is approach ensures that the messages are encrypted from the publisher to the subscriber, and only the communication endpoints own the cryptographic keys, which are necessary to decrypt the messages. ere is no need to trust the underlying message broker. e second category is the re-encryption method [15][16][17]. e broker with some speci c information (such as re-encryption keys) can transform the ciphertext of a publisher into the ciphertexts that can be decrypted by authorized subscribers. e third category is based on some trusted entities, such as trusted broker (as [3,9]) or trusted hardware [18]. However, none of the existing endto-end encryption schemes provide forward secrecy.

e Need of Forward Secrecy in IoT.
Leakage of longterm secret keys is a major concern when cryptographic schemes are implemented on devices with weak security protection capability (especially for resource-constrained IoT devices). Forward secrecy is used as a means to minimize the damage when such an event takes place. Forward secrecy ensures that the compromise of entities at this moment does not impact the security of the entities' previous completed communication. Most current designs of secure communication protocols consider forward secrecy an indispensable design goal [19]. Because adversaries with massive storage abilities and powerful penetration capabilities are increasing [20], long-term secrets leakage is often more likely to happen than expected: the keys may be stolen by system intruders or extracted from the stolen smartphones, law enforcement agencies may force users to reveal their key according to law, backup software may inadvertently upload a copy of the key to network storage, and so on [21].

e Challenges for Achieving Forward Secure Key Exchange
Asynchronously. At present, there are generally three methods to achieve forward secrecy in key establishment [20]. One is to extend the traditional DH key exchange protocol [22,23], it requires entities to be always online to interact with each other, and asynchronous communication is not supported.
is method is not suitable for IoT systems, as multiple authorized users of a device are not necessarily online at the same time, and the o ine users will a ect the communication of online users. e second method is to use precomputed key, which is also a common method to achieve forward secrecy without interaction. But this method is prone to message suppression attacks [20]. e third method is to convert a puncturable public key encryption scheme [24] into a puncturable key exchange scheme to provide forward  secrecy [25]. However, because of the high computational complexity of puncturable encryption, this method is not suitable for low-power IoT devices. Naturally, we are interested in the following question: 1.3. Motivation Question. How to establish a forward secure session key asynchronously among a group while keeping low overhead for each member?
1.4. Our Scheme. Identity-based public key cryptography can greatly simplify the management of certificates by taking user's identity as its public key, whereas key exchange based on implicit authentication (such as HMQV [26]) can greatly reduce the communication overhead. In our work, combining BKEM [27] proposed by Colin et al. with identitybased implicit authentication [28], we propose an efficient forward secure asynchronous group key exchange protocol BA-GKE. Based on BA-GKE, a forward secure end-to-end encrypted message transmission system FSEE is designed for IoT. More details are given below.

e New
Protocol: BA-GKE. BA-GKE is essentially an extension of DH-based key exchange in groups, which relies on a semi-trusted server to provide forward secrecy and support asynchronous communication of group members. We present a formal security validation of BA-GKE using ProVerif. e results show that it can provide mutual authentication for group members, guarantee the confidentiality of generated session keys, and provide forward secrecy at the same time.
1.6. e New Solution: FSEE. Based on the group key exchange protocol BA-GKE, we design FSEE, which utilizes BA-GKE to update the symmetric key between the device and its multiple authorized users in IoT. e core idea of FSEE is to establish a symmetric key per device that can be used to protect sensitive messages. is device-specific key is shared with the device and its authorized users. Due to the use of BA-GKE, FSEE adds a semi-trusted key exchange server to the current IoT architecture, does not need to change the existing message brokers, and can seamlessly integrate into existing ones. FSEE empowers the device owner the ability to control their data by controlling with whom to share the encryption key. Each device owner is responsible for authorizing and revoking access rights to its devices, without relying on a fully trusted third party.

Our
Contributions. Specifically, our main contributions are as follows: (1) Combining BKEM and identity-based implicit authentication, an efficient group key exchange protocol BA-GKE is proposed, which can establish a forward secure session key asynchronously among a group while keeping low overhead for each member. (2) Based on the protocol BA-GKE, we propose FSEE, an end-to-end encrypted message transmission system for IoT to address the confidentiality concerns of malicious brokers and compromised clients. FSEE achieves confidential and forward secure end-to-end communication in IoT, and supports asynchronous communication and decentralized authorization at the same time.
(3) Based on the open-source MQTT broker HiveMQ, the forward secure end-to-end encrypted message transmission system is implemented and tested. e experimental results show that FSEE not only is easy to implement on the existing commercial brokers, but also has comparable performance to recent prominent research while providing higher security. e proposed system can be used for real-time IoT applications. e manuscript is organized as follows. Section 2 presents the related work. In Section 3, assumptions and the requirements for end-to-end encryption system are discussed. In Section 4, we detail some basic components of our scheme, including BKEM, identity-based implicit authenticated key agreement protocol, identity-based public encryption and message authentication code. e design of BA-GKE is presented in Section 5. Based on BA-GKE, Section 6 designs the forward secure end-to-end encryption system FSEE. en, Section 7 implements the system and evaluates the performance of our scheme. Finally, we conclude this article in Section 8.

Related Work
Security of IoT systems has been studied extensively, such as physical security of IoT devices [29][30][31], secure authentication [32,33], access control [34,35], data integrity [36], and outsourcing of computations [37]. Realizing end-to-end security for pub/sub communication has only been studied by few approaches to date.

Schemes Based on Trusted Broker.
Currently, most IoT systems use TLS to protect the packets between brokers and clients [3]. e message broker could get all the plaintext produced by the devices and users.
is approach forces users to trust the broker for data processing. Due to the access control problem in MQTT [9], Yan Jia et al. propose MOUCON, in which the access rights to a message for every client are checked based on specific policies. However, full trust in the broker is also required, which does not solve the confidentiality concern caused by malicious brokers.

Schemes Based on Trusted Key Server.
A transparent endto-end encryption scheme for pub-/sub-based cyber-physical systems (CPSs) is provided by Markus et al. [13], in which a trusted key server is required to distribute the topicspecific key to all the authorized clients. is approach forces users to trust the key server, whose compromise can lead to the breach of millions of client accounts and permissions.

Schemes Based on Proxy
Re-Encryption. PICADOR uses a lattice-based proxy re-encryption scheme to realize a pub/ subsystem with end-to-end encryption [15]. However, based on the publisher's private key and each subscriber's public key, PICADOR requires a trusted authority to generate a reencryption key for each subscriber. Compromise of the trusted authority may lead to the exposure of all the publishers' private keys. Furthermore, PICADOR does not satisfy forward secrecy. References [16,17] are also proxy reencryption-based schemes, which have the same problem as PICADOR.

Schemes Based on Secret
Sharing. Sana belguith et al. [38] propose an efficient revocable secure pub/sub system based on the idea of secret sharing. A broker is divided into three parts: topic matching, routing, and message sending. e adversary cannot compromise all the brokers. ree brokers re-encrypt the publisher's message in turn and then send it to the subscriber. However, the scheme requires the development of a custom message broker, which is difficult to deploy and does not achieve forward secrecy too.

Schemes Based on
Hardware. Segarra et al. restrict the broker to run only in a trusted execution environment (TEE) [18] to tackle the problem of malicious or compromised brokers, thus ensuring that the broker software is executed as intended. However, TEE is not available on every server, which is difficult to deploy. Additionally, several attacks against the current mainstream TEE were shown [39], rendering its benefit questionable.

Schemes
Based on IBE or ABE. JEDI [11] uses WKD-IBE algorithm to implement end-to-end encryption between devices and users in IoT. Sieve [12]and Yu at el. Reference [40] use ABE to control which principals have access to encrypted data in the cloud. All of these schemes support asynchronous communication and decentralized authorization but do not provide forward secrecy as well.

Schemes Based on Chaos
Cryptography. Some schemes [41][42][43][44][45] implement real-time image encryption for IoT using chaos-based cryptography. Essentially, chaos-based cryptography utilizes chaotic signals to generate pseudorandom sequences, which is more suitable for video and image encryption compared to traditional cryptography techniques (DES, IDEA, and AES) [46]. ese efforts focus on solving the problems of large data capacity, strong adjacent pixels correlation, high real-time performance, and high redundancy among raw pixels, and they do not provide forward secrecy as well.

Assumption and Requirements for End-to-End Encryption System
3.1. Assumption. As is shown in Figure 1, the device owner is a special user of its devices, who can grant their device's access rights to others (such as guests, office members, and maintenance workers) and also revoke their authorization. We make the following assumptions: (1) Each device corresponds to a unique device owner and is completely controlled by its owner. A device trusts its owner completely. If the device owner is compromised, the adversary can gain full control over its device. (2) When a user initially purchases an IoT device from the manufacturer and binds it to the message broker, we call the user the owner of the device. e device owner operates his mobile APP and establishes a local connection with the device. We assume that the device and the device owner are mutually authenticated through the local connection, and some initial secret keys are reliably exchanged between the two. (3) By distributing authorization tokens to other users through secure channels (such as the local connection or some out-of-band channels), the device owner can grant their device's access rights to others.

Requirements for End-to-End Encryption Scheme.
Based on the consideration of security and availability, we summarize five requirements that end-to-end encryption methods should meet.

Confidentiality.
Confidentiality ensures that the interpretation of a message is impossible for anyone except the target authorized users. As the authorized user set is dynamically changing (a user is authorized or revoked), there are two meanings of confidentiality here: first, newly joined users should not be able to interpret encrypted data before their joining time; second, revoked users that previously had a key should not be able to interpret future encrypted data using their previous revoked key.

Support Asynchronous Communication.
In the Internet of ings, data generated by a device may be obtained by multiple authorized users. Generally, these users may not always be online. Users who are offline cannot affect the communication between the device and other users. erefore, an IoT end-to-end encryption solution also needs to support asynchronous communication. Even if a user is offline at a certain time, it will not affect other users to get the updated symmetric session key. Once the user is online, the latest session key can be obtained.

Forward Secrecy.
Forward secrecy means that compromise of long-term secrets does not lead to compromise of session keys of previously completed sessions. Namely, the confidentiality of previously encrypted messages can be guaranteed when an entity is compromised later.

Deployability.
To ensure wide deployment of the endto-end encryption system, the security scheme should be designated in a deployable manner; that is, the security scheme should make as few modi cations as possible to the current IoTmessage broker, preferably easy to implement on the existing ones, to minimize the cost of implementing the security scheme. Otherwise, the redevelopment of a customized message broker will not only take too long but also is incompatible with existing systems and cannot be interconnected.
Furthermore, most IoT devices are powered by batteries and with limited resources. erefore, operations of IoT devices should be as simple as possible.

Decentralized Authorization.
Relying on a centralized authority to achieve ne-grained authorization of all devices has poor scalability, and this authority may become the target of adversaries. erefore, the end-to-end encryption scheme should not rely on a centralized trusted third party, and the authorization of each device should be fully controlled by its owner. If an adversary compromises a device owner, it only threatens the safety of the owner and its devices, and the safety of other users and devices will not be a ected.

Blinded Key Encapsulation Mechanism (BKEM).
e concept of key encapsulation mechanism (KEM) is to use public key encryption algorithm to transport keys for use in symmetric encryption and does not provide any forward secrecy. Blinded key encapsulation mechanism (BKEM) [27] is proposed in the scenario with cloud participation. e semi-trusted cloud is used to provide forward secrecy for communication between entities. BKEM consists of three entities: a cloud server, an initiator, and multiple responders. A BKEM has two additional algorithms: blinding algorithm and unblinding algorithm.
A blinded KEM (BKEM) consists of ve algorithms (KG, Encap, Blin d, De cap, Unblin d). Figure 2 is a DH based BKEM. Let G be a cyclic group of prime order q with generator P.

KG(λ) ⟶ (ek, dk):
e key generation algorithm is executed by the cloud, and on input security parameter, output an encapsulation key ek and a decapsulation key dk.
Encap(ek) ⟶ (C, k): e encapsulation algorithm is executed by the initiator, takes as input an encapsulation key ek, and outputs an encapsulation C and a group session key k. e initiator will transfer the encapsulation C to whoever he wants to establish the shared session key. Note that encapsulation C must be transmitted to the intended responders secretly; otherwise, anyone who knows the encapsulation C can interact with the cloud to get the nal session key k.
Blin d(t, C) ⟶ ( C, uk): e blinding algorithm is executed by multiple responders. Each responder chooses a random blind value t, inputs the encapsulation C from the initiator, outputs a blinded encapsulation C and an unblinding value uk. uk is closely related to the selected random blind value t. en, responders send the blinded encapsulation C to the cloud.
De cap(dk , C) ⟶ k: e decapsulation algorithm is executed by the cloud. It takes decapsulation key dk and a blinded encapsulation C as input, outputs a blinded key k to the responders.
Unblin d(uk, k) ⟶ k: e unblinding algorithm is executed by the responders. It takes as input an unblinding value uk and a blinded key k from the cloud and outputs the nal session key k.
In BKEM, the cloud is semi-trusted. e initiator uses the cloud to negotiate the same group session key with multiple responders noninteractively, and multiple responders do not need to be online at the same time, thus supporting asynchronous communication. BKEM is essentially a DH key exchange between the initiator and the cloud. e encapsulation C generated by the initiator is actually its DH public key. e initiator secretly transmits the encapsulation C to the responders, and the cloud cannot obtain the encapsulation C, which ensures that only the initiator and the responders can negotiate the same session key, whereas the cloud cannot get any useful information of the session key. In addition, based on the property of DH key exchange, compromise of user's long-term secrets does not Security and Communication Networks lead to compromise of session keys of previously completed sessions. So forward secure communication between the initiator and the responders is realized.

Identity-Based Authenticated Key Exchange (ID-AKE).
Sherman et al. proposed an identity-based key exchange protocol (ID-AKE) [28]. While completing the key exchange, the identity of both sides can be implicitly authenticated. e scheme includes the following three stages: system setup, key extraction, and interaction.
AKE.Setup(λ AKE ) ⟶ (msk AKE , params AKE ): On input a security parameter λ AKE , e Key Generation Center KGC AKE generates (G, G T , e) where G and G T are groups of prime order q and e: G × G ⟶ G T is the pairing function. KGC chooses three cryptographic hash functions and a key derivation function K. All three of these are modeled as random oracles. KGC also randomly chooses an arbitrary generator P of G. An element s is randomly chosen from Z * q as the master secret key msk AKE , and the corresponding public key is P pub � sP. Finally, KGC keeps msk AKE secret and makes public parameters params AKE � 〈G, G T , q, e, P, P pub , H, H 0 , K〉 public.
AKE.Extract(msk AKE , ID i ) ⟶ S ID i : On input an identity ID i and master secret key msk AKE , the public key If user A and user B want to authenticate each other and finally exchange a session key, they first interact with each other to exchange some information and then use their private key, the received information and the identity of the other party to authenticate each other, and negotiate the same session key. e interaction process is shown in Figure 3.
is scheme can provide session key indistinguishability and KGC forward secrecy, and also can be proved to be secure in the CK (Canetti-Krawczyk) model [47]. e session key indistinguishability means that the real session key is indistinguishable from a random value for the adversary. KGC forward secrecy means that although the adversary can not only get the private key of both sides but also get the master secret key of KGC, he still cannot recover the session key previously negotiated by both sides. IBE.De c(sk ID i , CT i ) ⟶ m/⊥: input receiver's private key sk ID i and the ciphertext CT, and output the plaintext m or a special reject symbol ⊥.

Message Authentication Code (MAC).
A MAC scheme is a pair of efficient algorithms (S, V), where S is called a signing algorithm and V is called a verification algorithm. Algorithm S is used to generate tags and V is used to verify tags.
S(k, m) ⟶ t: k is a key and m is a message, and output t as the tag of message m.
V(k, m, t) ⟶ r: k is a key, m is a message, and t is a tag, and output r as either accept or reject.

Protocol Design.
BKEM can only realize forward secure and asynchronous key exchange between the initiator and responders in authenticated-links model [47], and the users and cloud server also need to authenticate each other when using BKEM to construct a secure group key exchange protocol in unauthenticated-links model [47].
Here, combining ID-AKE with DH-based BKEM, a novel group key exchange protocol BA-GKE is proposed. Our scenario consists of the following participants: (1) e initiator, also the group manager, wants to establish a shared session key with a set of responders. (2) Multiple responders want to allow the initiator to establish a shared key with them. (3) e server temporarily stores information assisting the responders to compute the shared session key.
e BA-GKE group key exchange protocol is defined in Figure 4 in the case of one responder and is parameterized by the following components. e process of the protocol includes two phases: In phase 1, based on the ID-AKE protocol of Sherman et al. [28], the initiator and the server authenticate each other, and a session key sk is negotiated, which is used by the server and multiple responders to authenticate each other in the next phase; in phase 2, based on BKEM, the initiator negotiates a common session key k with multiple responders with the help of server. In this phase, the identity-based encryption scheme (IBE) is used to transfer sk and encapsulation C to each responder. Speci cally, BA-GKE works in the following steps.

System Initialization.
On input the security parameter λ AKE , the KGC of ID-AKE KGC AKE output msk AKE and public parameters params AKE .

Server and Initiator Registration.
On input server's identity ID S and initiator's identity ID I , KGC AKE runs algorithm AKE.Extract, uses msk AKE to generate server's private key S S and initiator's private key S I , and sends the corresponding private key to them securely.

Responder Registration.
If initiator ID I wants to negotiate a common session key with multiple responders, the initiator acts as the KGC of an IBE scheme. On input security parameter λ IBE , the initiator outputs a master secret key msk IBE and public parameters params IBE . en, the initiator runs algorithm IBE.Extract, uses msk IBE and each responder's identity ID R to generate its private key sk R , and sends the private key to the corresponding responder through secure channel.

Initiator and Server Authentication.
Initiator and server run algorithm AKE.Interact to exchange information with each other, and nally output the same session key sk, which is used as the MAC key in the following steps.

Encapsulation Key Generation.
e server runs algorithm KG of BKEM generates an encapsulation key ek and  Security and Communication Networks a decapsulation key dk, computes the session identifier sid � H 1 (ID I , W I , ID S , W S , ek), and uses session key sk as the MAC key to generate ek's tag t S I . Finally, the server sends (ek, t S I ) to the initiator.

Encapsulation Generation.
Upon receiving the messages (ek, t S I ) from the server, the initiator first uses sk to verify t S I . If it is not a valid tag, the initiator outputs ⊥; otherwise, it runs Encap to get the group session key k and encapsulation C and also computes the session identifier sid � H 1 (ID I , W I , ID S , W S , ek). For each responder R j , initiator runs algorithm IBE.Enc, takes each responder's identity ID R j , encapsulation C, sk, and session identifier si d as input, and outputs the ciphertext CT R j to the corresponding responder R j .

Blinded Encapsulation Generation.
On receiving the ciphertext CT R j , each responder R j runs algorithm IBE.De c, takes its private key sk R j and CT R j as input, and gets the plaintext (C, sk, sid). en, the responder runs algorithm Blin d to generate the blinded encapsulation C and an unblinding value uk, uses sk as the MAC key to generate C's tag t R , and finally sends (C, t R , sid) to the server.

Decapsulating for Responders.
Upon receiving the messages (C, t R , sid) from the responder, the server first uses sk to verify the tag t R . If it is not a valid tag, the server outputs ⊥; otherwise, it runs algorithm De cap, takes its decapsulation key dk and responder's blinded encapsulation C as input, and outputs a blinded key k. Finally, the server uses MAC key sk to compute k's tag t S R and sends (k, t S R ) back to the responder.
Unblinding for blinded key on receiving the messages (k, t S R ) from the server, the responder uses sk to verify the tag t S R . If it is not a valid tag, the responder outputs ⊥; otherwise, it runs algorithm Unblin d, uses its unblinding value uk and k as input, and gets the final group session key k.

Formal Security Validation with ProVerif.
is section presents a formal verification of the proposed protocol using ProVerif [48]. Our verification ensures that BA-GKE provides the secrecy of generated group session key, the authentication between group members, and forward secrecy. ProVerif is an automatic verifier for cryptographic protocols defined in the Dolev-Yao model [49]. In this model, the adversary is an active eavesdropper, who can add, delete, modify, and delay messages on the network. In ProVerif, the cryptographic primitives are considered idealized that they are unbreakable without knowing the employed secret keys.
A protocol description in ProVerif is divided into three parts: the declarations, the process macros, and the main process. e ProVerif description of our scheme is given in the appendix. As described in lines 1-43, the declaration part consists of the used types, the security properties, the cryptographic primitive functions, and the list of defined events and queries. e queries defined in lines 29-31 are used to verify the confidentiality of messages transmitted between the initiator and responders. e initiator and responders select a message and use the new group session key to send the message, and test whether the adversary can get the encrypted data through the queries in lines 30 and 31. Lines 38-43 define a series of events to verify mutual authentication between initiator and responders. e second part of the ProVerif program describes the process macros for participants: initiator (Lines 44-72), key exchange server (Lines 73-99), and responders (Lines 100-122). When defining the process macro of initiator and responders, the events defined before are inserted to track the authentication results between the two parties.
In the last part, the main process of the protocol is defined in lines 123-134. In order to prove that the protocol satisfies forward secrecy, two phases are defined in the main process. In phase 0, instantiate the corresponding key material, insert the key into the correct table, and run the corresponding process macros infinitely. In phase 1, the private key of the users is output to the adversary. Finally, the running result of ProVerif is shown in Figure 5.
Lines 1-2 show the results of the queries not attacker (secretowner) and not attacker(secretuser) returned by ProVerif. As we shall see, these results are true, which means that the secrecy of the random values secretowner and secretuser are preserved by the protocol. In other words, the secrecy of the group session key generated by our scheme is preserved. In addition, we use phases to prove forward secrecy properties. In phase 1, even if the participants get corrupted (their private key is leaked to the adversary), the secrets exchanged in phase 0 are preserved, so our protocol achieves forward secrecy. Furthermore, lines 3-4 inform us that the proposed scheme provides mutual authentication of the initiator and responders. As such, the proved correspondence property in line 3 implies that the initiator authenticates responders by the fact that responders can correctly retrieve the group session key. Similarly, line 4 indicates that the responders can authenticate the initiator.

FSEE: The End-to-End Encryption
System for IoT 6.1. System Framework. In this section, we develop FSEE, which allows forward secure end-to-end encrypted message transmission in pub/sub communication in IoT. e core idea of FSEE is using BA-GKE to update the session key per device between its authorized users, and the security of previously negotiated session key is guaranteed even when users' long-term secrets are compromised.
As BA-GKE relies on a semi-trusted key exchange server for noninteractive key exchange and forward secrecy, FSEE adds a semi-trusted key exchange server to the existing IoT architecture. It includes four types of entities: the IoT devices, the message broker, multiple authorized users, and the key exchange server. ese entities constitute two networks, and the specific structure is shown in Figure 6. In the actual deployment, the message broker and key exchange server can be deployed together or separately.
On one hand, the device, message broker, and multiple authorized users constitute a data transmission network. All kinds of information collected by the device will be sent to users' applications through the message broker.
On the other hand, multiple authorized users and the key exchange server form a key update network. It is responsible for updating the group session key between the authorized users and the device when the user set changes. When a user's access rights are revoked by the owner, BA-GKE group key exchange protocol proposed in the previous section is adopted, and the group session key between authorized users is updated through the key exchange server. Since BA-GKE is relatively time-consuming, hash chain could be used to update the group session key when the device owner authorizes a new user to access its device.

Steps of FSEE.
Speci cally, FSEE includes the following seven steps.

System Establishment Stage.
e device manufacturer is the key generation center of ID-AKE and runs the AKE.Setup algorithm, enters the security parameters, and returns public parameter params AKE and master secret key msk AKE . e device manufacturer entrusts the key exchange service of all its devices to a third-party key exchange server and runs AKE.Extract to generate the private key S S for the third-party key exchange server.

Device Owner Registration. When a user purchases an
IoT device, the user is the owner of the device. e manufacturer runs AKE.Extract to generate and send the private key S I to the owner through a secure channel (SMS or sent with the device).
At the same time, the device owner, as the key generation center of IBE, chooses the corresponding security parameters and returns the public parameter params IBE and master secret key msk IBE .

Device Registration.
Generally, a newly purchased IoT device begins its life cycle through "device discovery." e device owner operates his mobile APP, and the APP establishes a local connection with the device [1]. After the "device discovery" stage, the device and the device owner complete the mutual authentication and both sides share an initial key ik and a key encryption key kek through the local connection. e shared initial key ik is the rst group session key shared between the device and its owner.

Authorization Stage.
When the device owner wants to grant the device access rights to others, the device owner rst

Security and Communication Networks
uses hash chain to generate a new session key k ′ from the current one k using a hash function, and the generated new session key is sent to newly joined users. At the same time, a key update command is broadcasted, so that the device and other authorized users can also update their shared session key through the same hash function. is is to maintain the consistency of the shared session key between the group members. From then on, the device and all its authorized users use the new session key to encrypt and decrypt transmitted messages. In addition, for each newly joined users ID j , the device owner uses its IBE master secret key msk IBE to generate new user's IBE private key sk ID j and sends it to the new user through secure channel. e new user keeps their private key sk ID j secret.

Revocation Stage.
When the device owner wants to revoke the access rights of a user, as the initiator of BA-GKE, the device owner starts a round of BA-GKE to update the group session key with the remaining authorized users. Specifically, it includes two phases: in the first phase, based on ID-AKE, the device owner and the key exchange server authenticate each other; in the second phase, based on BKEM, the device owner negotiates a new shared session key with the remaining authorized users with the help of the key server. Identities of the remaining authorized users are used to encrypt the new encapsulation C, whereas identities of revoked users are not used. e encrypted encapsulation C is sent to the remaining authorized users, which can use their private key to get the encapsulation C, and then interact with the key exchange server to get the updated group session key, whereas the device owner does not encrypt the new encapsulation C for revoked users, who cannot decrypt the ciphertext to get the encapsulation and thus the updated group session key cannot be obtained.
6.2.6. Update the Key of IoT Devices. As IoT devices are generally resource-constrained, the calculation of the device should be as simple as possible. In our scenario, when a new user joins, the device updates the session key through the hash chain just like other users. However, the device does not participate in the revocation process of the above BA-GKE protocol between group members, and the updated session key during the revocation stage is distributed directly by the device owner.
When a group member is revoked, the device owner encrypts the updated session key directly with the key encryption key kek shared with the device and then transfers it to the device. e device uses the key encryption key to get the updated session key. When the device successfully receives the new session key, the device and the device owner also use the shared key encryption key as the input of a hash function, and both sides update the key encryption key kek synchronously to a new one kek′. Key encryption key update is to ensure the forward secrecy of the communication between the device and the device owner.

Update Session Key Using BA-GKE Periodically.
When the authorized user set remains unchanged for a long time, the device-specific session key will remain unchanged, which reduces the security of our system. erefore, we use BA-GKE to update the device-specific session key periodically at the end of each hour (or other intervals). FSEE performs key rotation using BA-GKE only at the end of each hour or when a user is revoked, and cheap symmetric key encryption and hash operation is incurred for the rest of the time.

System Analysis.
In this section, we provide a comprehensive analysis of the proposed FSEE and show that our scheme has achieved all the requirements mentioned in Section 2.

Confidentiality.
When new users join the group, the group session key is updated using hash chain. Based on the one-way property of hash function, the session key obtained by the new user cannot be used to derive the former session key.
When a user is revoked, the device owner, as the initiator of BA-GKE, relies on the key exchange server to renegotiate the new group session key. e new session key is independent of the old one. e revoked user cannot use the former session key to derive the new group session key updated by BA-GKE after revocation.
End-to-end encryption ensures that no server processing the messages or any third-party adversaries can read the message sent between the source and destination, so the underlying broker cannot get any valid information.

Forward Secrecy.
When the adversary gets the longterm IBE private key of the authorized users, he can get all the encapsulation C generated by the owner every time the system uses BA-GKE to update the group session key, because the ephemeral encapsulation key ek and decapsulation key dk of the key exchange server change once every time the session key is updated. Even if the adversary gets the previously generated encapsulation C, it cannot interact with the server to recover the previously negotiated group session key. When the adversary gets the long-term ID-AKE private key of the key server, he could not get the encapsulation C, and knowing encapsulation key ek and decapsulation key dk could not help him to get the session key too.

Asynchronous Communication.
When new users are authorized, the group session key is updated by hash chain, and the offline group members will not affect the key update process. When a user is revoked, as long as the device owner and the key exchange server are online, the online group members can update to the latest group session key, and the key updating process will not be affected by the offline ones. In addition, the device owner can send the encrypted encapsulation CT to the key exchange server for temporary storage. Once the offline users are online, they can get the latest encrypted encapsulation CT from the key exchange server. If the member is not revoked, it can decrypt with its private key to get the latest encapsulation C and then use it to interact with the server to get the latest group session key. In a word, our end-to-end encryption scheme supports asynchronous communication.
6.3.4. Deployability. In our scheme, the message broker is only responsible for message routing and forwarding and does not participate in the group key exchange process. Our scheme does not need to change the existing IoT message broker. When IoT device manufacturers develop new devices, they can deploy our solution in the device and user application, and build their key exchange server for all their customers based on existing cloud service providers. erefore, our scheme has lower deployment costs and supports incremental deployment.

Decentralized
Authorization. FSEE allows each device owner to act as an authority of its devices in its own trust domain, without a single trusted third-party managing the global authorization information.

Implementation and Performance Evaluation
We evaluate FSEE in this section. In what follows, we first introduce our prototype implementation and then measure FSEE's performance.

Prototype Implementation.
e prototype of FSEE contains multiple modules, including devices, user applications, a message broker, and a key exchange server. e development of the device and user applications is based on Eclipse Paho Java Client library [50]. e construction of message broker is based on an open-source MQTT server HiveMQ [51]. HiveMQ provides a flexible extension framework that allows developers to create custom extensions, and the key exchange server is implemented as a HiveMQ extension. Cryptographic operations are supported by Java Pairing-Based Cryptography Library [52]. e prototype system runs on a laptop computer configured with Intel Core i7-5600U 2.6 GHZ CPU and 8G RAM. e computer's operating system is Windows7. e development environment of the device, user application, and key exchange server is IntelliJ IDEA 2018.1.6.

BA-GKE Implementation.
e BA-GKE group key exchange protocol used in FSEE is constructed based on DH-based BKEM, ID-AKE [28] and IBE. e IBE scheme chooses the identity-based encryption scheme proposed by Boneh-Franklin et al. [53]. e ID-AKE [28]and IBE [53] schemes are constructed based on a symmetric bilinear group. erefore, to achieve the security level of 80 bits, FSEE uses the configuration file "a.properties" provided by the JPBC library to generate a type "A" symmetric bilinear group based on a 160 bits prime order elliptic curve y 2 � x 3 + x mod p(p ≡ 3 mod4) with embedding degree 2.

Client Implementation.
Functions of device and user application are simulated via Java console programs that rely on the Eclipse Paho Java Client library. It is relatively easy to implement the IoT device, as there are no complex cryptographic operations on the device, and only symmetric cryptographic algorithms are performed. e user application is also based on Eclipse Paho Java Client library, and two packages of JPBC library are added to support calculations related to bilinear pairing.

Message Broker and Key Exchange Server
Implementation. In the prototype system, the message broker and key exchange server are deployed together on the same computer. e message broker is built based on HiveMQ Community Edition [54] to realize message routing and forwarding. HiveMQ is a world-class, enterprise-ready MQTT broker that provides fast, efficient, and reliable movement of data to and from connected IoT devices.
e key exchange server is realized as an extension of HiveMQ based on HiveMQ Community Extension SDK [55]. HiveMQ Community Extension SDK contains multiple HiveMQ interceptors, which provide a convenient way for extensions to intercept and modify MQTT messages. e key server uses Publish Inbound Interceptor to provide key exchange services for each authorized user.

Topic Design of FSEE.
FSEE utilizes the key exchange server to provide a symmetric session key per device, which is used by the device and its authorized users to communicate with each other securely. To build a foundation to transmit key materials to and from the key exchange server, FSEE introduces a specific key exchange topic that is used for all communication between the key exchange server and users to establish a secure group session key based on existing pub/sub MQTT protocol. Each client has its subtopic based on its clientID and role (owner or not), and the topics to be handled by the device, device owner, and other authorized users are shown in Table 1.
e key exchange topics are divided into two subcategories according to whether the user is the device owner or not: a topic prefixed with Fsee/keyex/I/ is used by the device owner to interact with the server for authentication (prefixed with Fsee/keyex/I/toKS/), to obtain the encapsulated key from the server (prefixed with Fsee/keyex/I/toC/), and to send encrypted encapsulation to other authorized users (prefixed with Fsee/keyex/I/toR/). Another type of topic prefixed with Fsee/keyex/R/ is used by other authorized users to interact with the server to obtain the final symmetric session key.
Each device publishes data to the topic Fsee/data/deviceID, and all authorized users subscribe to the topic, thereby realizing data transmission in the system. When the device owner authorizes a new user to access the device, the device owner issues a key update command to topic Fsee/keyup/deviceID. e device and other authorized users subscribe to the topic to ensure that once the key update command is received, they use the hash function to update the device-speci c session key.
e key exchange server intercepts packets with topic pre xed with Fsee/keyex/I/toKS/ and Fsee/keyex/R/toKS/ in the Publish Inbound Interceptor. If the topic of the packet is Fsee/keyex/I/toKS/clientID, it means that this is a message sent by the device owner to the key exchange server. e server obtains the authentication message from the packet payload, and the server's authentication message and encapsulation key are returned to the owner through topic Fsee/keyex/I/toC/clientID. If the topic is Fsee/keyex/R/toKS/clientID, it means that other authorized users are requesting the server to decapsulate its key. e server obtains the blinded encapsulation from the packet payload, and the blinded key is returned to the user through the topic Fsee/keyex/R/toC/clientID. When a user's access rights are revoked, the device owner uses BA-GKE to update the session key, and the device owner publishes the updated new session key to the topic Fsee/keyup/toD/deviceID. e device subscribes to the topic to get the latest session key.

Evaluation.
In this section, we evaluate the performance of FSEE based on the prototype system. Table 2 shows the performance of our type A curve implemented on JPBC. Preprocessing feature could be used to save time in the long run when a particular element is exponentiated and paired several times. e most timeconsuming operation is exponentiation in G 1 and pairing. Figure 7 gives the computational overhead of each module (including device, device owner, key server, and other authorized users) in the system when using BA-GKE to update a symmetric key.

Overhead of Updating the Symmetric Key Using BA-GKE.
e key server provides decapsulation services for each authorized user, so its computational cost increases linearly with the number of users, which increases by 15 ms for each additional authorized user. e device owner rst interacts with the key exchange server based on ID-AKE and then encrypts the encapsulation for each authorized user. Its processing overhead is about 45 ms in the case of one authorized user and increases by 9 ms for each additional authorized user. Other users use their own IBE private key to obtain the encapsulation and interact with the server to get the nal symmetric key, and the calculation overhead is about 37 ms.
e key of the IoT device is directly updated by the owner, and devices only need to perform one symmetric decryption algorithm, so their computational cost is about 0.2 ms. e overhead of the key server and device owner increases linearly with the number of authorized users. e key server is generally deployed on a workstation or cloud   platform with abundant resources. While the device owner only manages the access rights of his own device through a mobile phone application, the number of authorized users n of one device is generally not too large (n ≤ 20), and it is also considered a practical cost of performing about 2 n asymmetric operation per message on an iPhone 3GS [56]. Furthermore, it is also easy for the device owner to achieve constant calculation overhead using e cient identity-based public key broadcast encryption algorithms [57,58].

Secure Communication.
To realize end-to-end security of pub/sub communication in IoT, clients in FSEE use the computed device-speci c key to encrypt and decrypt messages using AES. We study the resulting per-message processing overhead for publishing and subscribing to messages by comparing the computation overhead to unprotected communication, which uses the same pub/substack without any enabled security features. As the runtime depends on the size of transmitted messages, we perform the measurements for message sizes of 128 B, 512 B, 1 kB, and 2 kB to represent smaller and larger value clusters typically used in IoT. As shown in Figure 8, the increased processing overhead per message is about 0.2 ms-0.3 ms at publisher and subscriber compared to communications without any enabled security features. Overall, the high level of security achieved by applying FSEE to sensitive pub/subcommunication in IoT only introduces a modest increase in computation time, which is suitable even for resource-constrained IoT devices. Table 3 compares FSEE with other systems in regard to con dentiality, forward secrecy, decentralized authorization, deployability, and performance. e schemes based on chaos cryptography is designed for one-to-one communication, while our work is aimed at one-to-many communication, so chaos cryptography-based schemes are not included in the scope of comparison. We re-implemented JEDI using our crypto library for a fair comparison and use it as a medium to compare with proxy re-encryption-based schemes [15] and ABE (attribute-based encryption)-based schemes [12,40].

Con dentiality.
Most of the message broker in commercial IoT system is not completely trusted. In a scheme that completely relies on a trusted broker, the broker can get all user's data that does not meet the con dentiality requirement.

Forward Secrecy.
Most current designs of secure communication protocols consider forward secrecy an indispensable design goal [19]. None of the existing solutions satis es forward secrecy. 7.2.6. Decentralized Authorization. In a scheme relying on a centralized trusted server or broker, the authorization and revocation of device access rights must be managed by the server or broker. erefore, these schemes have poor scalability, and the server may become the target of the adversary.

Deployability.
Reference [38] divides the broker's function into three part, and the designed new broker needs to be customized to meet the corresponding requirements; reference [18] needs to install special hardware, both of which are di cult to deploy.

Performance.
Trusted broker-based schemes do not meet the requirement of con dentiality, and References [18,38] are di cult to deploy, so these schemes are not reimplemented on our experimental platform. Trusted key server-based schemes are faster than FSEE when distribute symmetric key, but similar to FSEE when using a symmetric key to transmit data in the common case. In JEDI [11], it reimplemented PICADOR [15], whose performance is comparable to JEDI. JEDI uses WKD-IBE [59] to distribute the symmetric key, the time to transmit a symmetric key (including one encryption and one decryption) is about 95 ms, and the decryption time contains the time to generate a decryption key for the encrypted pattern and the time to decrypt the ciphertext. When computing the time of JEDI, we use a pattern of 20 attributes, with the rst 14 attributes representing the URI and the last 6 attributes representing the time. ABE algorithms are more complicated than IBE, and the computational overhead of ABE-based schemes is much bigger than IBE based ones, which is not appropriate for resource-constrained IoT devices. FSEE takes about 115 ms to distribute a symmetric key using BA-GKE. e computational overhead of FSEE is slightly higher than JEDI, but it can provide forward secrecy.
In summary, existing schemes fall into one of the four categories. (1) Trusted broker-based schemes need to fully  trust the broker, which contradicts the confidentiality requirement. (2) In trusted key server-or broker-based schemes, a single component is trusted for all resources in the system. Granting or revoking access to a user requires the participation of the trusted party to generate new keys. (3) Some schemes need to redevelop a customized message broker or install special hardware, which is difficult to deploy. (4) None of the existing schemes achieve forward secrecy.

Conclusion
In this work, we propose FSEE, a forward secure end-to-end encrypted message transmission system for pub/sub communication in IoT, which addresses the confidentiality concerns of malicious adversaries that fully compromise the message broker. To support FSEE, a novel group key exchange protocol BA-GKE is designed to distribute symmetric key per device between each device and its multiple authorized users, and its security is verified by ProVerif. FSEE can achieve confidential and forward secure end-toend communication in IoT, and support decentralized authorization, deployability, and asynchronous communication at the same time. Experimental evaluations were also conducted to test the performance of FSEE. Further explorations of efficient user revocation and encrypted data persistence are also interesting and may be our future research direction.  Data Availability e data used to support the findings of this study are included within the article.

Conflicts of Interest
e authors declare that there are no conflicts of interest regarding the publication of this article.