Benjamin Aziz
email: benjamin.aziz@port.ac.uk

Paul Fremantle
email: paul.fremantle@port.ac.uk

Wei † Rui

Alvaro Arenas
email: alvaro.arenas@ie.edu

A Utility-based Reputation Model for the Internet of Things

Keywords: Internet of Things, Utility Reputation, Trust Management

The MQTT protocol has emerged over the past decade as a key protocol for a number of low power and lightweight communication scenarios including machine-to-machine and the Internet of Things. In this paper we develop a utility-based reputation model for MQTT, where we can assign a reputation score to participants in a network based on monitoring their behaviour. We mathematically define the reputation model using utility functions on participants based on the expected and perceived behaviour of MQTT clients and servers. We define an architecture for this model, and discuss how this architecture can be implemented using existing MQTT open source tools, and we demonstrate how experimental results obtained from simulating the architecture compare with the expected outcome of the theoretical reputation model.

Introduction

The Internet of Things (IoT) is an area where there is significant growth: both in the number of devices deployed and the scenarios in which devices are being used. One of the challenges for the Internet of Things is supporting network protocols which utilise less energy, lower bandwidth, and support smaller footprint devices. One such protocol is the MQ Telemetry Transport (MQTT) protocol [START_REF] Locke | MQ Telemetry Transport (MQTT) V3.1 Protocol Specification[END_REF], which was originally designed to support remote monitoring and Supervisory Control And Data Acquisition (SCADA) scenarios but has become popular for the IoT.

Another challenge with IoT networks is that small devices may not perform as well as needed due to a number of factors including: network outages or poor network performance due to the use of 2G or other low bandwidth networks, power outages for devices powered by batteries, deliberate vandalism or environmental damage for devices placed in public areas, and many other such challenges. Therefore we identified that a reputation model for devices connecting by MQTT would be a useful construct to express consumers' (applications') trust in the behaviour and performance of these devices as well as measure the level of performance of the server aggregating data from such devices according to some predefined Service Level Agreement (SLA). In addition, we implemented the reputation model to demonstrate that it could be used in real MQTT networks.

Our model of reputation is based on the notion of a utility function, which formally expresses the consumer's level of satisfaction related to various issues of interest against which the reputation of some entity is measured. In the case of MQTT networks, one notable such issue is the Quality of Service (QoS) with regards to the delivery of messages; whether messages are delivered exactly once, more than once or at most once to their consumers. The model, inspired by previous works [START_REF] Arenas | Reputation management in collaborative computing systems[END_REF][START_REF] Silaghi | Reputation-based trust management systems and their applicability to grids[END_REF], is general enough to be capable of defining the reputation of client devices and servers at various levels of abstraction based on their level of performance in relation to the delivery of messages issue of interest.

The paper starts with an overview of the MQTT protocol (Section 2). From this, we then mathematically define the reputation model for MQTT clients and server (Section 3), based on their ability to keep to the requirements of the protocol. We then outline a system architecture (Section 4) for monitoring the MQTT protocol and thereby being able to calculate the reputation by observing the behaviour of MQTT clients and server in a real network. We show how this system was implemented and we demonstrate the results of this implementation (Section 5). Finally we look at related work (Section 6) and conclude the paper outlining areas for further research (Section 7).

MQTT Overview

MQTT [9] is described as a lightweight broker-based publish/subscribe messaging protocol that was designed to allow devices with small processing power and storage, such as those which the IoT is composed of, to communicate over low-bandwidth and unreliable networks. The publish/subscribe message pattern [START_REF] Birman | Exploiting Virtual Synchrony in Distributed Systems[END_REF], on which MQTT is based, provides for one-to-many message distribution with three varieties of delivery semantics, based on the level of QoS expected from the protocol. In the "at most once" case, messages are delivered with the best effort of the underlying communication infrastructure, which is usually IPbased, therefore there is no guarantee that the message will arrive. This protocol is termed the QoS = 0 protocol. In the second case of "at least once" semantics, certain mechanisms are incorporated to allow for message duplication. Despite the guarantee of delivering the message, there is no guarantee that duplicates will be suppressed. This protocol is also known as the QoS = 1 protocol. Finally, for the last case of "exactly once" delivery semantics, also known as the QoS = 2 protocol, the published message is guaranteed to arrive only once at the subscribers. The protocol also defines message structures needed in commu-nications between clients, i.e. end-devices responsible for generating data from their domain (the data source) and servers, which are the system components responsible for collating source data from clients/end-devices and distributing these data to interested subscribers. Servers are often also referred to as brokers, as they intermediate between the data publishers and subscribers.

A Reputation Model for MQTT

We show in this section how the model of reputation defined for business processes in [START_REF] Aziz | Reputation-controlled business process workflows[END_REF][START_REF] Aziz | Enforcing reputation constraints on business process workflows[END_REF] can be adapted, with minimum changes, to the MQTT protocol to obtain the reputation of client devices and the server.

Monitoring Events

Central to the model defined by [START_REF] Aziz | Reputation-controlled business process workflows[END_REF][START_REF] Aziz | Enforcing reputation constraints on business process workflows[END_REF] was the notion of an event, which is a signal produced by an independent monitor system, which is monitoring the interactions occurring between the different entities in the monitored environment, in this case the client and server entities participating in the MQTT protocol. An event is defined as follows:

Event : TimeStamp × Ag × Msg × Id × N
where TimeStamp is the timestamp of the event generated by the monitor system issuing it, Ag is the identity of the agent (client device or server) to whom the event is related, Msg is the specific message of interest (e.g. Publish and Pubrel messages), Id is an identity value of the protocol instance and finally, N is a natural number representing the number of times the message Msg has been monitored, i.e. was sent.

For example, the following event, issued at monitor system's local time: denotes that the server responsible for the environment temperature, temp server, has been monitored, within the same instance number 1234 of the protocol, to have published only once the specific message Publish to the subscribers of the temperature topic. In both these examples, the assumption is that the monitor system is capable of detecting that the protocol instance being monitored has terminated before it issues any events related to that instance. Although theoretically this is impossible due to the halting problem, in practical terms, the monitor system can assume the protocol to have terminated after some reasonable amount of time has elapsed since the last protocol message. The monitor generates events in the above form, which are used by a reputation engine to determine the reputation values for client devices and servers in an MQTT-based environment. The reputation engine will then use a utility function pre-supplied to the engine by subscribers to determine the level of satisfaction of a subscriber with regards to the results reported within an event:

ev ex 1 =
utility : Event × SLA → [0, 1] ∀(t, a, m, i , n) ∈ Event, sla ∈ SLA • utility((t, a, m, i , n), sla) = r ∈ R
This utility function will consider a SLA, defined as follows:

SLA : Ag × Top × Iss → N 0
Here the SLA considers an issue of interest to the subscriber, Iss, which will be in our case the QoS level value fixed to one of 0, 1 or 2, expected from a particular agent Ag in relation to a specific topic Top. The outcome of the utility function is a real number r representing the satisfaction level of the subscriber in terms of both the SLA and the real values reported by events.

For example, consider the following SLA instance sla = ((temp server, temperature, QoS ), 2) then given the event ev ex 2 , the utility function could return the following value: utility(t, temp server, Publish, 1234, 1, ((temp server, temperature, QoS ), 2)) = 1

This indicates that the subscriber's requirements have been fulfilled, as indicated by their SLA (r = 1), with the results reported by the event ev ex 2 . On the other hand, considering the same SLA, the utility function might return: utility(t, temp server, Publish, 1234, 0, ((temp server, temperature, QoS ), 2)) = 0 to show that the subscriber has a satisfaction value of 0 since the number of times the message was delivered to the subscriber is lower (i.e. 0) than what its QoS level is defined in the SLA (i.e. 2), therefore breaching the exactly-once delivery semantics to the subscriber principle in MQTT.

Since the number of times a message is delivered will either confirm or not to the level of QoS expected by the subscriber, in all of the above cases, the score given will reflect either total satisfaction (i.e. 1) or total dissatisfaction (i.e. 0).

Reputation Models

After introducing the main notions of an event and a utility function, we can now define models of reputation for the clients (e.g. sensor devices) and the MQTT server (broker) that aggregates the messages from the clients before publishing them to the subscribers. The subscribers are assumed to be the business applications or data consumers, and we do not include them in the reputation model. The MQTT standard does not prohibit a client from acting as both a device (i.e. source of data) and a subscriber (i.e. consumer of data). However, in our case, we only measure the reputation of the "source of data" clients.

The Server Reputation Model The first reputation model reflects the behaviour of MQTT servers. Given a set of events, Event, captured by the monitor system and relevant to the server for whom the reputation is being calculated, then we can define the server's reputation function computed at a particular point in time and parameterised by a specific SLA as follows:

[Srv , SLA, TimeStamp] s rep sla : Srv × SLA × TimeStamp → [0, 1] ∀ eset s : ℘(Event) • s rep sla(s, sla, t) = ev ∈esets .snd(ev ) =fst(sla) = s ∧ id top(ev , sla) ϕ(t,te)utility(ev ,sla) #esets
where #s denotes the cardinality of a set s and ϕ(t, te) is a time discount function that puts more importance (emphasis) on events registered closer in time to the moment of computing the reputation. One definition of ϕ(t, te) could be the time discount function defined by [START_REF] Huynh | An integrated trust and reputation model for open multi-agent systems[END_REF], which we redefine here as ϕ(t, te) = e -t-te λ , where t is the current time at which the reputation is calculated, te is the timestamp of the event being considered and λ is recency scaling factor used to adjust the value of the function to a scale required by the application. After this, the server reputation function, s rep sla, is defined as the weighted average of the utilities obtained from all the generated events with respect to some SLA.

The above definition aggregates the set of all relevant events, i.e. the events that first have the same server name as that appearing in the SLA and second that are on an instance of the protocol related to the topic of the SLA. The first condition is checked using the two operators fst and snd, which will return the first and second elements of a tuple, whereas the second condition is checked using the predicate id top(ev , sla), which returns a True outcome if and only if the identity number of an instance of a protocol captured by ev corresponds to the topic value mentioned in the SLA sla. Considering the example events of the previous section, we would have the following calculation of id top(ev , sla): id top(12 : 09 : 52, temp server, Publish, 1234, 1, ((temp server, temperature, QoS ), 2)) = True

The above definition calculates the sum of the time-discounted utility function values, with respect to the given SLA and the events gathered, and average these over the total number of events gathered (#eset s ) in any one instance when this reputation value is calculated.

Based on the definition of s rep sla, we next aggregate the reputation of a server across every SLA that binds that server to its subscribers:

[Srv , TimeStamp] s rep : Srv × TimeStamp → [0, 1] ∀ slaset s : ℘(SLA) • s rep(s, t) = sla ∈ slasets .fst(sla) = s s rep sla(s,sla,t) #slasets
Which provides a more general indication of how well a server s behaves in relegation to a number of subscribers. This reputation is again calculated in a particular point in time, t, however it is straightforward to further generalise this reputation function over some time range, between t and t .

The Client Device Reputation Model After introducing the reputation model of the server, we define here the client's reputation model. Like the server, a client might also be implementing the QoS correctly, but it requires multiple reconnections, duplicate messages etc., while the server does not. For instance, if the devices are not sending PINGs or responding to them, or this is delayed, it might indicate a problem is more likely to occur in the future. Similarly, if the device needs to send multiple duplicate messages or needs to be sent duplicate messages, it also might indicate possible failure in the future. Thus, the reputation model for a client may be based on either the "Keep Alive/PING" case or the "Client's Retransmission Procedure" case. However, we start with the definition of an overall reputation model that generalises these two cases.

Given a set of events, Event, captured by the monitor system relevant to some client, then we define the client's reputation function computed at a particular point in time in a specific process (Keep Alive/PING procedure or retransmission procedure) and parameterised by a specific SLA as follows:

#pset s

This definition gathers the set of all related events, i.e. the events that first have the same client name as that appearing in the SLA and second that are on an instance of the protocol related to the topic of the SLA. The definition is parameterised by the client, an SLA, a timestamp and the specific procedure (e.g. Keep Alive/PING or retransmission). The SLA represents what the expectation is, from the server's point of view, of the client's behaviour in the context of the specific procedure. Similar to the case of s rep sla, a utility function is applied to measure the satisfaction of the server, in a time-discounted manner, in relation to the client's behaviour and this is then averaged over the total number of events captured in a specific instance of time.

For example, consider the case of the Keep Alive/PING procedure, then c rep sla ka is defined as the time-discounted average of the utilities obtained from all generated events with respect to the Keep Alive/PING procedure.

[Client, SLA, TimeStamp, KeepAlive] c rep sla ka :

Client × SLA × TimeStamp × KeepAlive → [0, 1]
∀ pset s : ℘(Event) • c rep sla ka(c, sla, t, ka) = ev∈kapingsets .snd(ev) =fst(sla) =c ∧ id top(ev,sla) ϕ(t,te)utility(ev ,sla)

#kapingset s

In this procedure, the client sends a Pingreq message within each KeepAlive time period, then the receiver answer with a Pingresp message when it receives a Pingreq message from the gateway to which it is connected. Clients should use KeepAlive timer to observe the liveliness of the gateway to check whether they are connected to broker. If a client does not receive a Pingresp from the gateway even after multiple retransmissions of the Pingresq message, it fails to connect with gateway during the Keep Alive period.

Hence, for the above example, using id top to show a set of related events ev corresponds to the topic value mentioned in the SLA, sla, we would have that: id top(12 : 09 : 52, client, Pingreq, False, False, 1234, 1, ((client, temperature, QoS ), 0)) = True

The event ev kaping = (12 : 09 : 52, client, Pingreq, False, False, 1234, 1) generated by the monitor, could reflect a client device that has sent once the Pingreq message to connect to the gateway within the instance number 1234 of the protocol during the Keep Alive period. Then, given the SLA instance sla = ((client, temperature, QoS ), 0), the client should deliver this Pingreq message in relation to a specific topic (in this case temperature) at most once within each KeepAlive time period, but there is no guarantee the message will arrive.

From the definition of c rep sla p, we generate a more general reputation for some client in a particular point in time t within a period, Period, as follows:

[Client, SLA, TimeStamp] c rep sla : Client × SLA × TimeStamp → [0, 1] ∀ periodset s : ℘(Period ) • c rep s la(c, sla, t) = ev∈periodsets .snd(ev) =fst(sla) = c ∧ id top(ev,sla) c rep sla p(c,sla,t,p) #periodset s
Giving an example based on the Keep Alive/PING procedure, assume the KeepAliveTimer is set to 60, then calculating c rep sla(c, sla, t) will give us the reputation of the client device during the whole Keep Alive period of 60 seconds. In another example, based on the retransmission procedure, we assume that Nretry is set to 10. Aggregating over the c rep sla(c, sla, t) values yields reputation in relation to the client's retransmissions within a 10 time-unit limit.

Finally, based on the definition of c rep sla, we can further generalise the reputation value over all relevant SLAs for a specific client, c, and in a particular point in time, t, as follows:

[Client, SLA] c rep : Client × SLA → [0, 1] ∀ slaset s : ℘(SLA) • c rep(c, t) = crep (c, t) = sla ∈ slasets .fst(sla) = c c rep sla(s,sla,t) #slasets
This definition gives a more general indication of how well the client device generally behaves in relation to the SLAs it holds with the server (possibly on behalf of the subscribers dealing with the server). These could include scenarios where the clients might use the Keep Alive/PING procedure to observe the liveliness of the gateway to check whether they are connected to a broker. Moreover, in the case of messages that expect a response, if the reply is not received within a certain time period, the client will be expected to retransmit this message.

The reputation model of a client in different procedures might cause different failures. Thus, as we demonstrated above the first reputation model, c rep sla p, will lead to new models with slight variations capturing this variety of failures. For example, for the case of a client's retransmission procedure, all messages that are "unicast" to the gateway and for which a gateway's response is expected are supervised by a retry timer Tretry and a retry counter Nretry. The retry timer Tretry is started by the client when the message is sent and stopped when the expected gateway's reply is received. If the client does not receive the expected gateway's reply during the Tretry period, it will retransmit the message. In addition, the client should terminate this procedure after Nretry number of retransmissions and should assume that it is disconnected from the gateway. The client should then try to connect to another gateway only if it fails to re-connect again to the previous gateway.

One such client reputation, is defined based on a specific TRetry timer: Again, for the above definition, for sla = ((client, temperature, QoS ), 2), and given the event ev nretry = (12 : 09 : 52, client, Publish, False, False, 1234, 1), it could indicate that the client should not retransmit again in the retransmission period due to the fact that QoS is set to 2 (meaning the message is guaranteed to be delivered exactly-once to the subscribers). In this case, the DUP flag must be set to False, in order to prevent a retransmission.

A Reputation System Architecture for MQTT

Our architecture for a reputation system for an MQTT network is composed of a reputation monitor and a reputation engine, as shown in Figure 1. The architecture defines the capabilities of the various components in an MQTT network. The reputation monitor (also sometimes referred to as the proxy) will monitor the MQTT interactions that take place among the MQTT network components, namely the client devices, server and subscribers. Monitoring implies that the reputation monitor will issue events to the reputation engine whenever these are required after each time it has captured an MQTT communication relevant to the utility functions predefined by the consumers (possibly the subscribers). These events could represent aggregations/abstractions of data collected from such communications, in order to minimise the additional network traffic created by this process.

Once an event has arrived at the reputation engine, it is either stored for applying further aggregations/abstractions or it is used immediately to compute new updates for the various reputation values for the clients and the server. The calculations are based on the reputation models defined in the previous sections, and the updates to these reputation values are then stored in a local reputation database. In our architecture, we only consider the monitoring problem, however, it is easy to extend this architecture in the future to include a control step, where the reputation values for different participants are then used to impact/feed back into the MQTT network communications.

Simulation of the Model

We implemented the architecture, described in the previous section, by running a number of off-the-shelf open source tools. First, we used the Mosquitto tool [START_REF]Mosquitto: An open source mqtt v3[END_REF] as the broker (server). Mosquitto is an open source MQTT broker written in the C language that implements the MQTT protocol version 3.1. The Mosquitto project is highly portable and runs on a number of systems, which made it an effective choice for our experiments.

In order to simulate the client, we used the source code for the Eclipse Paho MQTT Python client library [START_REF] Paho | [END_REF], which comes with Java MQTT client API and implements versions 3.1 and 3.1.1 of the MQTT protocol. This code provides a client class, which enables applications to connect to an MQTT broker to publish messages, receive published messages and to subscribe to topics. It also provides some helper functions to make publishing one off messages to an MQTT server very straightforward. Using this library we created a set of programs that would publish and subscribe to the Mosquitto broker. Finally, to implement the monitoring function we needed to capture all the traffic between the client and the server. For this we extended the Paho MQTT test proxy [START_REF] Paho | [END_REF], which acts as a "reverse proxy", impersonating an MQTT server and sending all the traffic on to a real broker after capturing the messages. The proxy represents a mediator between clients and the broker. By extending this proxy we were able to trace all the packets being sent and received and send monitoring information to our reputation engine in order to calculate the reputation of the client and broker.

Results

To begin with, we assume that the network will misbehave with regards to the messages that are exchanged among the various entities in the system. This misbehaviour is modelled as the network dropping some messages according to a predefined rate (e.g. 0-100%). There could be other sources of network misbehaviour, such as the insertion of new messages and the repetition or modification of transmitted messages, however, for simplicity, we consider only the suppression of messages as our example of how the network could misbehave and how such misbehaviour would affect the reputation of MQTT clients and servers.

In our case, we chose the rate of successful message delivery to be in the range of 50% to 100%, where 50% means that one message in every two is dropped by the network, and 100% means that every message is delivered successfully to its destination. This latter case is equivalent to the normal behaviour discussed above. There are a number of tools that can drop network packets selectively. However, we created a new tool based on the above-mentioned proxy that specifically targets disrupting MQTT flows by dropping MQTT packets. The tool allowed us to target a percentage of dropped packets and therefore calculate the reputation under a given percentage of packet loss.

Since our aim is to demonstrate, in general terms, how reputation-based trust can be obtained in an IoT system such as an MQTT network, and for simplicity, we opted to consider only one source of misbehaviour, namely message suppression, without considering the other sources. Despite the fact that such sources are also interesting, they do not affect the generality of our approach.

Reputation Results

To compute the reputation value of clients and servers, we collected events related to the QoS level agreed between the client and the server throughout the 5-minute measurement window, and used the server and client reputation model proposed in Section 3.2 to calculate their reputation values. The QoS level monitoring is important as it is directly related to the issue of message suppression when messages are communicated over the unreliable network. In the presence of such abnormal behaviour, the reputation values of the clients and the server are shown in Figure 2 versus the rate of successful message delivery (0.5 to 1).

From this figure, we note that despite starting at low reputation levels in line with the low delivery rate of messages, these reputation values will increase reaching the optimal value of 1 when the rate of delivery of messages is 1. This optimal case represents the case of normal behaviour when every message is delivered successfully to its destination.

Related Work

Reputation is a general concept widely used in all aspects of knowledge ranging from humanities, arts and social sciences to digital sciences. In computing systems, reputation is considered as a measure of how trustworthy a system is. There are two approaches to trust in computer networks: the first involves a "black and white" approach based on security certificates, policies, etc. For example, SPINS [START_REF] Perrig | Spins: Security protocols for sensor networks[END_REF], develops a trusted network. The second approach is probabilistic in nature, where trust is based on reputation, which is defined as a probability that an agent is trustworthy. In fact, reputation is often seen as one measure by which trust or distrust can be built based on good or bad past experiences and observations (direct trust) [START_REF] Jøsang | A Survey of Trust and Reputation Systems for Online Service Provision[END_REF] or based on collected referral information (indirect trust) [START_REF] Abdul-Rahman | Supporting trust in virtual communities[END_REF].

In recent years, the concept of reputation has shown itself to be useful in many areas of research in computer science, particularly in the context of distributed and collaborative systems, where interesting issues of trust and security manifest themselves. Therefore, one encounters several definitions, models and systems of reputation in distributed computing research (e.g. [START_REF] Fullam | Learning trust strategies in reputation exchange networks[END_REF][START_REF] Jøsang | A Survey of Trust and Reputation Systems for Online Service Provision[END_REF][START_REF] Silaghi | Reputation-based trust management systems and their applicability to grids[END_REF]).

There is considerable work into reputation and trust for wireless sensor networks, much of which is directly relevant to IoT trust and reputation. The Hermes [START_REF] Zouridaki | Hermes: A quantitative trust establishment framework for reliable data packet delivery in manets[END_REF] and E-Hermes [START_REF] Zouridaki | E-hermes: A robust cooperative trust establishment scheme for mobile ad hoc networks[END_REF] systems utilise Bayesian statistical methods to calculate reputation based on how effectively nodes in a mesh network propagate messages including the reputation messages. Similarly TRM-IoT [START_REF] Chen | Trm-iot: A trust management model based on fuzzy reputation for internet of things[END_REF] evaluates reputation based on the packet-forwarding trustworthiness of nodes, in this case using fuzzy logic to provide the evaluation framework. Another similar work is CORE [START_REF] Michiardi | Core: a collaborative reputation mechanism to enforce node cooperation in mobile ad hoc networks[END_REF] which again looks at the packet forwarding reputation of nodes.

Our approach differs from the existing research in two regards: firstly, the existing reputation models for IoT utilise the ability of nodes to operate in consort as the basis of reputation. While this is important in wireless sensor networks, there are many IoT applications that do not utilise mesh network topologies and therefore there is a need for a reputation model that supports client-server IoT protocols such as MQTT. Secondly, the work we have done evaluates the reputation of a reliable messaging system based on the number of retries needed to successfully transmit a message. Although many reputation models have been based on rates of packet forwarding, the analysis of a reliable messaging system (like MQTT with QoS > 1) is different as messages are always delivered except in catastrophic circumstances. Therefore we looked at the effort and retries required to ensure reliable delivery instead. We have not seen any similar approach to this and consider this the major contribution of the paper.

Conclusion

To conclude, we defined in this paper a model of reputation for IoT systems, in particular, for MQTT networks, which is based on the notion of utility functions. The model can express the reputation of client and server entities in an MQTT system at various levels, and in relation to a specific issue of interest, in our case the QoS level of the delivery of messages in the presence of a lossy network. We demonstrated that it is possible, using off-the-shelf open source MQTT tools, to implement an architecture of the reputation system that monitors the MQTT components, and we showed that the experimental results obtained from running such a system validate the theoretical model.

Future work will focus on adapting the reputation model and its architecture and implementation to other IoT standards, e.g. the Advanced Message Queuing Protocol (AMQP) [START_REF] Vinoski | Advanced Message Queuing Protocol[END_REF], the Extensible Messaging and Presence Protocol (XMPP) [START_REF]XMPP Standards Foundation[END_REF], the Constrained Application Protocol (CoAP) [START_REF] Shelby | Constrained Application Protocol (CoAP) draft-ietf-core-coap-18[END_REF] and the Simple/Streaming Text Oriented Messaging Protocol (STOMP) [START_REF] Stomp | The Simple Text Oriented Messaging Protocol[END_REF]. We also plan to consider other issues of interest when calculating reputation where satisfaction is not necessarily a binary decision, for example, the quality of data generated by client devices and the quality of any filtering, aggregation or analysis functions the server may apply to such data in order to generate new information to be delivered to the consumers. Further, we intend to apply Bayesian statistics to the results to improve the probabilistic calculation of the reputation values. Some other interesting, though more advanced areas of research, include the strengthening of the model to be able to cope with malicious forms of client and server behaviour, for example, collusion across such entities in order to produce fake reputation values for a targeted victim, and a study on the welfare of IoT ecosystems based on the different rates of the presence of ill-behaved and wellbehaved entities in the ecosystem, and how variations in the presence ratio of such entities would lead to a notion of reputation reflecting the wider ecosystem.

[

  Client, SLA, TimeStamp, Procedure] c rep sla p : Client × SLA × TimeStamp × Procedure → [0, 1] ∀ pset s : ℘(Event) • c rep sla p(c, sla, t, p) = ev∈psets .snd(ev) =fst(sla) = c ∧ id top(ev,sla) ϕ(t,te)utility(ev ,sla)

[

  Client, SLA, TimeStamp, TRetry] c reptr sla tr : Client × SLA × TimeStamp × TRetry → [0, 1] ∀ tretryset s : ℘(Event) • c reptr sla tr (c, sla, t, tr ) = ev∈ kapingset s .snd(ev ) = fst(sla) = c ∧ id top(ev , sla) ϕ(t,te)utility(ev ,sla) #tretryset s For example, consider the following sla = ((client, temperature, QoS ), 1), then given the event ev tretry = (12 : 09 : 52, client, Publish, False, True, 1234, 2), it could reflect an event in the retransmission procedure. If the client does not receive a Puback message with QoS level 1 within a time period defined by the TRetry value, the client may resend the Publish message with the DUP flag set. When the server receives a duplicate message from the client, it re-publishes the message to the subscribers, and sends another Puback message. Similarly, another variation of the client's reputation function may be based on the NRetry counter instead: [Client, SLA, TimeStamp, NRetry] c repnr sla nr : Client × SLA × TimeStamp × NRetry → [0, 1] ∀ nretryset s : ℘(Event) • c reptr sla tr (c, sla, t, nr ) = ev ∈ kapingset s .snd(ev ) = fst(sla) = c ∧ id top(ev , sla) ϕ(t,te)utility(ev ,sla) #nretryset s

Fig. 1 .

 1 Fig. 1. The Reputation System Architecture.

Fig. 2 .

 2 Fig. 2. Reputation Values for the Clients (c rep) and Servers (s rep) vs. the rate of Successful Message Delivery.


Andreas Fuchs

Christoph Krauss

Jürgen Repp

Christoph Krauß

Advanced Remote Firmware Upgrades Using TPM 2.0

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Information Technology (IT) is one of the main drivers for innovations in our everyday private and work life. Especially, the use of highly connected embedded systems is increasingly growing, e.g., to enable new (safety-critical) applications in areas such as automotive, aerospace, energy, healthcare, manufacturing, or entertainment. An example is a connected car which communicates with other cars or the infrastructure to increase traffic safety and efficiency.

However, the increased connectivity (even to the Internet) and physical accessibility of the embedded systems also introduces new threats with regard to IT security and privacy. Successful attacks may have serious consequences -even to life and limb of people.

One approach for securing embedded systems is the use of Hardware Security Modules (HSMs) as a security-anchor. An HSM provides secure storage for cryptographic keys, a secure execution environment for (cryptographic) operations, and additional mechanisms such as secure boot to ensure the integrity of the platform. One promising approach is the use of the latest version of the Trusted Platform Module (TPM) 2.0, an international open standard developed by the TCG. TPM 2.0 and the corresponding TPM Software Stack (TSS) provide a high flexibility which is of great value to cost-efficiently secure different types of embedded systems on the basis of one common standard. TPM and TSS 2.0 can be realized in different specialized profiles. For example, the TCG already specified a TPM 2.0 Automotive Thin Profile [START_REF]TCG TPM 2.0 Library Profile for Automotive-Thin[END_REF] which is suitable for small resource-constrained electronic control units (ECUs) in a car such as an engine control unit. For more powerful embedded systems, other profiles such as PC Client might be appropriate. Also the TPM 2.0 itself provides a high flexibility. In contrast to TPM 1.2, a TPM 2.0 can be realized not only as an additional hardware chip (which provides high security but also introduces high costs) but also as a System on Chip (SoC) or Firmware TPM. Thus, one general approach can be applied to different types of embedded systems.

A central aspect to ensure security is the support for remote firmware upgrades to deal with vulnerabilities discovered after deployment. A great challenge for remote upgrades is the protection of device-resident data, i.e., data that remains on the device during the flashing process. Device-resident data are usually large data sets which are not changed for the upgrade and contain intellectual property of the manufacturer or data created on the device during operation containing person-related data. It must be ensured that only new upgrades by the original firmware manufacturer can be installed and downgrade attacks or attempts to install malicious firmware upgrades are prevented.

In this paper, we first discuss the benefits of integrating TPM / TSS 2.0 in an embedded system. Next, we present a concept for advanced remote firmware upgrade of such an embedded system using the TPM 2.0 as a trust anchor for realizing an enhancement to the classical secure boot. Our concept additionally includes the enforcement of intellectual property rights (IPR) and privacy protection for device-resident data. As proof-of-concept, we implemented our concept for an automotive head unit using a hardware TPM 2.0 and the TPM Software Stack 2.0 low-level System API.

This paper is organized as follows. In Section 2, we present background on TPM / TSS 2.0 and related work. Our concept and prototypical implementation is presented in Section 3. Finally, Section 4 concludes the paper.

Background and Related Work

In the last years, the security of embedded devices has been intensively investigated. The attacks on firmware upgrades go back to hacks against consumer electronics like the Playstation Portable [START_REF]How to Downgrade a PSP[END_REF] in the mid 2000s all the way to most recent attacks against safety critical systems such as automotive ECUs [START_REF] Greenberg | Hackers Remotely Kill a Jeep on the Highway -With Me in It[END_REF][START_REF] Miller | A Survey of Remote Automotive Attack Surfaces[END_REF].

In order to prevent completely arbitrary firmware to run, different vendor solutions and standards have been implemented. On x86 systems UEFI introduced Secure Boot in 2013 [START_REF] Wilkins | UEFI Secure Boot in Modern Computer Security Solutions[END_REF]. Gaming consoles include solutions of signed software since Playstation 2 and XBox 360 [START_REF] Van Woudenberg | 20 ways past secure boot[END_REF]. IPhones and Android phones included Secure Booting features from the beginning [START_REF]Verified boot[END_REF]3]. Automotive ECUs provide Secure Boot via SHE and EVITA [START_REF] Henniger | Security requirements for automotive on-board networks[END_REF][START_REF]) AK Security: SHE-Secure Hardware Extension[END_REF][START_REF] Weyl | Secure on-board architecture specification[END_REF]. All these basic Secure Boot schemes, however, target primarily the integrity of the base firmware. The security of device-resident data during such firmware upgrade in terms of confidentiality as well as integrity is not targeted by any of these solutions; especially not the binding of these against trustworthy and fresh basic firmware images.

In order to provide the security for device-resident data in our proposed scheme, the functionalities of the Trusted Platform Module (TPM) 2.0 are used. Alternative solutions such as Intel TXT, TrustZone, Security Fuse Processor, or Secure Elements [4, [START_REF]Secure Boot -For QorIQ Communications Processors[END_REF][START_REF][END_REF], can usually not directly provide these feature without further extensions. Intel SGX and some GlobalPlatform Trusted Execution Environment [START_REF]Global Platforms: Trusted execution environment specifications[END_REF]12] provide similar capabilities, but only for applications running within the shielded environment, not the Rich Operating System. The means for retaining the security of the resident data during upgrade needs to be manually implemented within each application. Alternative HSMs such as TPM 1.2, SHE or Evita [START_REF]) AK Security: SHE-Secure Hardware Extension[END_REF][START_REF]Trusted Computing Group: TPM Main Specification, Level 2 Version 1[END_REF][START_REF] Weyl | Secure on-board architecture specification[END_REF] cannot provide the specific feature that are required within this proposed concept. Specifically, Enhanced Authorization of TPM 2.0 is required in order to provide the security guarantees for this paper.

2.1 Background on TPM 2.0 and TSS 2.0

The second iteration of the Trusted Platform Module (TPM), namely the TPM 2.0 Library Specification [START_REF]Trusted Computing Group: Trusted Platform Module Library Specification[END_REF] has been released by the Trusted Computing Group (TCG) in October 2014. It provides a catalog of functionalities that can be used to build TPMs for different platforms. Since then, a so-called TPM profile has been released for PC Clients [START_REF]Trusted Computing Group: PC Client Platform TPM Profile (PTP) Specification, Family 2[END_REF] in January 2015, but also a TPM profile for Automotive Thin [START_REF]TCG TPM 2.0 Library Profile for Automotive-Thin[END_REF] in March 2015. In June 2015, the TPM 2.0 was also approved by ISO as successor to TPM 1.2 in ISO/IEC 11889:2015 [START_REF]Trusted Computing Group TPM 2.0 Library Specification Approved as an ISO/IEC International Standard[END_REF].

Accompanying the TPM specifications, the TCG has engaged with the specification of a TPM Software Stack (TSS) 2.0 for this new generation of TPMs. It consists of multiple Application Programming Interfaces (APIs) for different application scenarios. A so-called Feature Level API has been published for review [START_REF]Trusted Computing Group: TSS Feature API Specification[END_REF] in November 2014 and is currently still under development. It targets high-level application in the Desktop and Server domain. For lower-level applications, such as embedded, the so-called System API specification [START_REF]Trusted Computing Group: TSS System Level API and TPM Command Transmission Interface Specification[END_REF] was released as a final version in January 2015 in conjunction with the TPM Command Transmission Interface (TCTI) for IPC module abstraction. The System API and TCTI were designed such that embedded applications could leverage on TPM 2.0 functionalities whilst minimizing requirements against the platforms. As such, they can for example be used in heap-less scenarios where only stack-based memory allocation are possible.

Difference of TPM 2.0 to TPM 1.2

Compared with TPM 1.2, TPM 2.0 is a complete rewrite. Many of the new features were not compatible with the data type and function layout of TPM 1.2. The main purpose of TPM 2.0 remained to provide Roots of Trust for Storage and Reporting. In combination with a Root of Trust for Measurement, this allows the provisioning of reliable identities, securely stored secrets, and reporting and enforcement of software integrity. The new features of TPM 2.0 in comparison to TPM 1.2 include:

-Cryptographic Agility: Whilst TPM 1.2 was restricted to RSA ≤ 2048 bit and SHA1, TPM 2.0 merely provides placeholders for cryptographic algorithms that can be filled up with from the TCG's Algorithm Registry [START_REF]Trusted Computing Group: Algorithm Registry[END_REF]. The PC-Client TPM Profile for example requires RSA, ECC, SHA1, SHA256 . . . -Symmetric Algorithms: TPM 1.2 was bound to use RSA for all encryptions.

This was time consuming and inefficient. TPM 2.0 also supports symmetric cryptography such as AES and HMACs. -Enhanced Authorization: TPM 1.2 was very limited on authorization mechanisms. In general, it used SHA1 hashes of passwords. In addition, some functions further had the possibility to include bindings to a single set of PCR values (such as key usage and sealing). With TPM 2.0 the concept of Enhanced Authorization was included, which allows the forming of arbitrary policy statements based on a set of policy commands. This provides a high flexibility requiring multiple factors to be fulfilled but also to allow different paths for policy fulfillment. -Non-Volatile Memory: With TPM 2.0 the capabilities of the TPM's integrated non-volatile memory (NV-RAM) were enhanced. They can now be used as counters, bitmaps, and even extended PCRs. -Many more enhancement were made. A lot of those are outline in [START_REF] Challener | A Practical Guide to TPM 2.0: Using the Trusted Platform Module in the New Age of Security[END_REF].

Platform Configuration Registers

One of the core functionality of TPMs is the capability to store the status of the software/firmware that was started on a device. In order to do so, each software component -starting from the pre-BIOS as Root of Trust for Measurementcalculates a hash of the next component in the boot-chain and sends this hash to the TPM. These hashes are called configuration measurements and stored within the TPM's Platform Configuration Registers (PCRs). For space efficiency, those measurements are not stored in plain, but as a hash-chain, such that a PCR's value represents a hash-chain of the measurements of the boot-chain.

The TPM's PCRs can be used to report or protect the device's integrity. The most well-known case is the concept of Remote Attestation, where a signature over a selection of PCRs is transferred to a remote entity. This entity can then determine the current configuration of a device and assess its trustworthiness. Another use case is local attestation, where certain actions of the TPM -such as data sealing (cf. Section 2.4) -can be restricted to specific device configuration states via PolicyPCR (cf. Section 2.6).

Data Sealing

The Trusted Platform Module (TPM) 2.0 has the capability for sealing data similar to the TPM 1.2. The purpose of sealing is to encrypt data with the TPM and to ensure that only this TPM can unseal the data again. In order to unseal the data, an authentication secret can be provided or a policy session that follows the scheme for Enhanced Authorization (cf. Section 2.6) can be used.

NV-RAM Counters

A TPM comes with an internal non-volatile memory. This memory can be used to make keys of the TPM persistent but can also be allocated by applications. The set of TPM2 NV * commands provides ways to allocate memory in so called NV-Indices and perform read and write operations.

With TPM 2.0 additional classes of NV-Indices were introduced: Extendable NV-Indices and NV-Counters. The latter can be used to define strongly monotonic 64 bit counters that may only be incremented but not directly written, reset, or decremented. In order to prevent attackers from merely freeing and reallocating an NV-counter with a smaller value, any NV-counter is initialized to the highest value that has ever been present in any NV-counter of the TPM. This way, decrementation of NV-counter is always prevented. One of the main purposes of NV-counters is the use in Enhanced Authorization via TPM2 PolicyNV against a maximal value.

Enhanced Authorization

With TPM 2.0 a new concept for authorizing functions of objects was introduced under the name Enhanced Authorization. Any object that requires authorization can either be authorized using a secret value assigned during creation (similar to TPM 1.2) or using a policy following this scheme.

Enhanced Authorization consists of a set of policy elements that are each represented via a TPM command. Currently, eighteen different policy elements exist that can be concatenated to achieve a logical and in arbitrary order and unlimited number. Two of these policy elements -PolicyOr and PolicyAuthorize -act as logical or. Due to implementation requirements, policy statement are, however, neither commutative nor distributive. Once defined they need to be used in the exact same order. In this paper, we use the following notation: P olicy abc := P olicyX 1 () ∧ P olicyX 2 () ∧ . . . P olicyX n () where P olicy abc is the "name" for this policy, such that it can be referred to from other places and P olicyX i () describes the n concatenated TPM2 Policy commands that are required to fulfill this policy.

Out of the eighteen currently defined Policy commands of the TPM 2.0 library specification, the following four policies are utilized in our concept described in Section 3. They are now explained in more detail.

TPM2 PolicyOr

The PolicyOr element allows the definition of logical or of up to eight policy branches. Each of these policy branches itself can be an arbitrary combination of policy elements of unlimited length. In order to satisfy a PolicyOr, one of the branches needs to be satisfied before calling the PolicyOr command. To add further branches, multiple PolicyOr elements can be combined. In this paper, we represent a PolicyOr as

P olicy abc := P olicyOr([Branch 1 ] ∨ [Branch 2 ] ∨ . . .)
TPM2 PolicyAuthorize PolicyAuthorize allows the activation of policies after the definition of an object. In order to achieve this, a public key K pub is registered with a policy. This policy element then acts as a placeholder for any other policy branch that is signed with the corresponding private key K priv . In order to satisfy such a policy, a branch needs to be satisfied first, and then PolicyAuthorize is called with the cryptographic signature that authorizes this branch as allowed. If such a signature for the currently satisfied branch can be provided, then the PolicyAuthorize element is also fulfilled. Logically, a Poli-cyAuthorize can be viewed as an or for all branches that were signed with the corresponding private key. P olicy abc := P olicyAuthorize(K pub abc )

Authorization 1 := Sig(K priv abc , [Branch 1 ]) Authorization 2 := Sig(K priv abc , [Branch 2 ])
After signatures have been provided for certain branches, we say:

P olicy abc := P olicyAuthorize(K pub abc ,[Branch 1 ]∨ [Branch 2 ])
TPM2 PolicyPCR The PolicyPCR element allows functions on an object inside the TPM to be restricted to a specific combination of PCR values and thereby software configurations. A similar but less flexible capability also existed with TPM 1.2 with the keyUsageInfo for keys and digestAtRelease for sealed data. With TPM 2.0 this capability can now be applied to any authorization policy. It can further be targeted at certain operations only. In combination with PolicyOr and PolicyAuthorize it is possible to also authorize several software versions. P olicy abc := P olicyP CR(Sof twareV ersion)

TPM2 PolicyNV

The PolicyNV element provides the possibility to include NV-indices into the evaluation of a policy. This can be used to switch between different modes of operation, by selectively enabling and disabling certain branches of a PolicyOr and PolicyAuthorize. Furthermore, it can be used to invalidate branches of a PolicyOr and PolicyAuthorize when combined with an NV-counter, as this paper presents.

P olicy abc := P olicyN V (N V index, operation, value)

An example could be the comparison of the NV index N V abc against a maximum allowed value of 20. If and only if the number stored within this N V abc is smaller or equal to 20 can this policy element be fulfilled. Otherwise, it would fail.

P olicy abc := P olicyN V (N V abc , ≤, 20)

Remote Firmware Upgrades Retaining IPR and Privacy

A Trusted Platform Module 2.0 can be used for a multitude of application cases. One of those cases is the realization of secure remote firmware upgrades with the protection of IPR-related data material and privacy sensitive information stored in device-resident data. The remainder of this paper will focus on this use case.

Scenario

Firmware upgrades are a necessity of all software based systems to fix bugs and vulnerabilities. During such a software upgrade, not all data stored on a device shall be replaced by the incoming firmware upgrade. The two categories of data not included in a software upgrade are large unchanged data sets and data created on the device during operation.

The requirements that come along with this is that consecutive software versions need to have access to this data, whilst it needs to be stored inaccessible to malicious firmware images. Also this data must become inaccessible to old versions of the firmware after an upgrade in order to prevent so called "downgrade attacks". In a downgrade attack, an attacker installs an outdated version of the firmware that has known vulnerabilities in order to exploit them. Such attacks have for example been used for breaking the first generation of PlayStation Portable. The classic realizations of sealing, as employed by TPM 1.2 [START_REF]Trusted Computing Group: TPM Main Specification, Level 2 Version 1[END_REF], however, is not applicable in these scenarios, because they do not allow the "updating" of referenced PCR values from the sealed blobs.

Classically, this would have to be done by allowing the updater to "reseal" the data for the state after upgrading, which requires the upgrade module to be privileged. Furthermore, it was impossible to disallow usage of the old seal for accessing the data. With the framework for "Enhanced Authorization" (EA) in TPM 2.0, it is possible to achieve this use case respecting the circumstances and requirements outlined above. In the following, the set of requirements is listed, the concept described, and a prototypical implementation outlined.

Requirements

The requirements for securing large data sets and personal information during a firmware upgrade can be summarized as follows:

1. Provide confidentiality of IPR and user data. 2. Only allow original manufacturer firmware to read / write data. 3. Prevent access by old firmware after an upgrade to new firmware. 4. Do not require "privileged mode" such as updaters to unseal the data.

Concept

Our concept for providing these requirements can be divided into three phases: Provisioning, Firmware Upgrade, and Firmware Usage.

Provisioning After provisioning of the device, the very first thing should be the definition of an NV index that represents the device's currently required minimal firmware version. This has to be done first, in order to ensure that the NV index is initialized with a value of 0 (read Zero), cf. Section 2.5 for details. This counter is initialized as a single 64 bit unsigned integer value and then incremented once in order to be readable:

N V V ersion := T P M 2 N V Def ineSpace(counter) T P M 2 N V Increment(N V V ersion )
The IPR and user data is stored in an encrypted container or partition on the devices flash that lays outside of the actual firmware binaries. The key to this encrypted container is then sealed with the TPM to the following policy:

P olicy Seal := T P M 2 P olicyAuthorize(K pub M anu )
This policy allow the manufacturer as the owner of K priv M anu to issue new policies in the future for accessing the stored data. For the initial firmware of version v1, the manufacturer will provide the following policy:

Sig K priv M anu , T P M 2 P olicyP CR(F irmware v1 )∧ T P M 2 P olicyN V (N V V ersion ≤ v1)
The PCRs that represent the integer state of F irmware v1 may be used until the nv index N V V ersion that represents the currently required minimal version exceeds the value of v1.

P olicy Seal :=T P M 2 P olicyAuthorize K pub M anu , T P M 2 P olicyP CR(F irmware v1 )∧

T P M 2 P olicyN V (N V V ersion ≤ v1)
Note that the signed policy cannot be part of those components of the firmware that is measured into the representing PCRs. The reason is that this would lead to a cyclic relation that cannot be fulfilled.

Firmware Upgrade Whenever a firmware upgrade is issued by the manufacturer, it will be accompanied by a newly signed policy, that (similar to the original policy) grants access to the encrypted container based on the PCR representation of that firmware. This access again is only granted until the NV index representing the minimum required version exceeds this firmware's version:

Sig K priv M anu , T P M 2 P olicyP CR(F irmware v2 )∧ T P M 2 P olicyN V (N V V ersion ≤ v2)
This leads to P olicy Seal being: P olicy Seal :=T P M 2 P olicyAuthorize K pub M anu , T P M 2 P olicyP CR(F irmware v1 )∧

T P M 2 P olicyN V (N V V ersion ≤ v1) ∨ T P M 2 P olicyP CR(F irmware v2 )∧ T P M 2 P olicyN V (N V V ersion ≤ v2)
During the update process, the updater mode stores the firmware including its policy on the device's flash drive. However, it does not require access to the encrypted container.

A similar concept with TPM 1.2 would have required that the updater mode would have required access to the encrypted container and to reseal the secret, or the manufacturer would have to have known the secret and bind it for the new PCR values. This is one of the main benefits of this TPM 2.0 based approach.

Firmware Runtime Whenever a legitimate firmware version starts, it can unseal the necessary data and read/write to these storage areas. In order to invalidate access by outdated firmware versions, during each start, the firmware will check the currently stored minimal required firmware version inside the TPM counter and increment it to its own firmware version. This invalidates the usage of PolicyAuthorize branches for previous firmware version, since they require a lower value for the N V V ersion counter. Firmware should only perform this increment when it successfully completed its self test and started up correctly, since a recovery of the previous version is impossible afterwards. Instead the issuing of a new firmware version would be required. Of course a manufacturer may choose to issue a certain recovery firmware version, or multiple such version by, e.g., encoding those as the "odd version" vs. regular firmware as "even versions".

We write the increment of the NV counter as

T P M 2 N V Increment(N V V ersion , v1)
which invalidates any older policies and thereby any outdated firmwares. This leads to: P olicy Seal :=T P M 2 P olicyAuthorize K pub M anu , T P M 2 P olicyP CR(F irmware v1 )∧

T P M 2 P olicyN V (N V V ersion ≤ v1)
A similar concept with TPM 1.2 could only have removed the sealed blobs for older versions from the flash drive, but in case of a readout of the flash from an earlier state, there would have been no possibility to actually disable these older policies with the TPM. This is another main benefit of this TPM 2.0 based approach.

Security Considerations

The presented concept relies on the correct cryptographic and functional execution of a TPM 2.0 implementation for the encryption and correct handling of the policy tickets respectively. Furthermore, the scheme relies upon a set of specific assumptions in order to function properly:

-The private ticket signing key of the vendor must be kept confidential.

-The provisioning needs to use the correct ticket public key for verification.

-The scheme does not protect against runtime-attacks against software.

Prototypical Implementation

The described concept was implemented in a proof-of-concept demonstrator for a typical automotive Head Unit. An Intel NUC D34010WYK in combination with Tizen In-Vehicle Infotainment (IVI) [START_REF]Tizen Association: Tizen[END_REF] using Linux kernel 4.0 was chosen for this implementation. These 4th generation NUCs are one of first commercial off-the-shelf (COTS) devices equipped with a TPM 2.0 implementation. Our demonstrator is shown in Fig. 1. To protect IPR and privacy sensitive data, the Linux LUKS implementation (Linux Unified Key Setup) is used to create and to open an encrypted container for storing this data. The key for the encrypted container in turn is protected by TPM 2.0's enhanced authorization mechanisms as described in Section 2.6.

For ease of demonstration the representation of firmware versions in the PCR values was simplified -namely not calculations of the overall firmware hashes. Instead of measuring the complete firmware at boot and extending a PCR with this measurement, we measure a single file into the PCR called version f ile. A TPM monotonic counter is used to represent the version number.

Note that the standard Linux Integrity Measurement Architecture (IMA) [START_REF]The Integrity Measurement Architecture[END_REF] could also not be used in practice for this scenario. Due to the event-driven startup mechanisms under modern Linux systems, the exact order of PCR extension can vary, which renders them unusable for sealing. Instead, the complete image would have to be measured from within the initial ramdisk. A future publication will demonstrate a possible approach based on e.g. [START_REF] Corbet | dm-verity[END_REF].

In Algorithm 1 and 4, we assume that the TPM 2.0 equivalent of a Storage Root Key (SRK) -a TPM Primary Key under the Storage Hierarchy -is already computed. If the NV counter N V C is already defined, it is used directly. Otherwise N V C gets defined.

Provisioning When the device is started for the first time, the following steps shown in Algorithm 1 are executed for provisioning the protected storage. It consists of the definition of the NV version counter, the instantiation of the policy, the creation of the LUKS container and the sealing of the LUKS key. To ease readability, we wrapped some of the details within simplified function calls. All functions prefixed with T P M 2 are equivalent of corresponding TPM functions. not def ined(N V C) will check, whether the NV index has been defined by performing a T P M 2 N V Read and checking the resulting value. The public key pub key manu of the manufacturer, loaded into the TPM, is bound to the object S encrypted by SRK via the policy calculateded by T P M 2 P olicyAuthorize. The corresponding private key to pub key manu now can be used to alter policies necessary for unsealing the encrypted key S. The functions load policy and load signature will load the policy respective the signature associated by the manufacturer with the version stored in the version file. The session.T P M 2 P olicy function represents an execution of those policy commands on the TPM, referring to the policy session session. For the signed approved policy, a ticket derived from this policy and the public key of the manufacturer is computed by T P M 2 V erif ySignature, if the signature verification is successful. The current policy value of the session will be compared with the approved policy and the TPM then validates that the parameters to T P M 2 P olicyAuthorize match the values used to generate the ticket. After the crypto file system is mounted, the device should perform a self test f irmware self test and the NV counter will be incremented until the value which corresponds to the current firmware version is reached. Thus, the object enc SRK (S) can't be unsealed by firmware versions less than version, providing protection against downgrade attacks.

Conclusion

In this paper, we discussed the benefits of integrating a TPM 2.0 (and the corresponding TSS 2.0) as HSM in an embedded system and presented a new concept for advanced remote firmware upgrades of such an embedded system while additionally enforcing intellectual property rights (IPR) and privacy protection for device-resident data. This new approach is only possible by using new features introduced by TPM 2.0 such as NV-RAM counters and Enhanced Authorization. Our approach secures device-resident data by ensuring that only new firmware upgrades of the manufacturer can be installed and downgrade attacks or attempts to install malicious firmware upgrades are prevented. In our prototypical implementation for an automotive head unit, we protected deviceresident data of the manufacturer (i.e., navigation maps) and of the car user (i.e., contacts and preferred navigation destinations) against unauthorized access before, during, and after an upgrade. Our general concept can be applied in different application scenarios using different TPM and TSS 2.0 profiles.

Fig. 1 .

 1 Fig. 1. TPM 2.0 Head Unit Demonstrator

Algorithm 1 (

 1 Provisioning) /* NV Creation */ if not def ined(N V C) then N V C := T P M 2 N V Def ineSpace(counter) /* Policy Initialization */ pubkey := T P M 2 LoadExternal(pub key manu) policy := T P M 2 P olicyAuthorize(pubkey) /* LUKS creation */ S := generate random key() create crypto f s(S) /* Sealing */ SRK := get srk() enc SRK (S) := T P M 2 Create(S, SRK, policy) save(enc SRK (S))

Firmware release Algorithm 2

 2 shows how the manufacturer can produce signatures for new firmware versions with a corresponding TPM 2.0 policy without using a TPM. The function compute policy calculates the policy based on the session := T P M 2 StartP olicySession() session.T P M 2 P olicyP CR(P CR) session.T P M 2 P olicyN V (N V C, <=, version) policy := T P M 2 P olicyAuthorize(pubkey, ticket, approved policy) /* Unsealing the container key and mount */ SRK := get srk() enc SRK (S) := load() T P M 2 Load(enc SRK (S)) S := T P M 2 U nseal(enc SRK (S), session) mount crpyto f s(S) f irmware self test() /* Invalidate old firmwares */ while T P M 2 N V Read(N V C) < version do T P M 2 N V Increment(N V C)

PCR value, after extending a PCR by the firmware digest, and the version of the firmware. This computation is performed by the manufacturer according to the TPM2.0 specification. This policy will be signed with the private key of the manufacturer. The device later must be able to associate the policy and the signature with the version to be installed. ). The version of a signed firmware to be installed must be greater or equal to the current NV counter because this demonstrator should be able to execute the provisioning process several times and the hardware TPM's monotonic counter cannot be decremented again. To be more precise, even if the counter is undefined by T P M 2 N V U ndef ineSpace it is not possible to reset the counter to a smaller value because for the next definition the counter will be initialized to be the largest count held by any NV counter over the lifetime of the TPM. In practice it would be possible to store the initial policy directly in the firmware image for version 1. In order to perform the simulated upgrade of the firmware binary, we increment the value encoded within the firmware representing version file.

Runtime The steps described in Algorithm 4 are executed in the boot process to mount the encrypted container. They consist of the PCR extension with the digest of the version file, the satisfaction of the policy, using this policy for unsealing the container key, the opening of the encrypted container and then the invalidation of old firmware by incrementing the NV version counter.