Nektaria Kaloudi
email: n.kaloudi033@gmail.com

Aikaterini Mitrokotsa

Revisiting Two-hop Distance-Bounding Protocols: Are you really close enough?

Keywords: distance-bounding, authentication, relay attacks

The emergence of ubiquitous computing has led to multiple heterogeneous devices with increased connectivity. In this communication paradigm everything is inter-connected and proximity-based authentication is an indispensable requirement in multiple applications including contactless payments and access control to restricted services/places. Distance-bounding (DB) protocols is the main approach employed to achieve accurate proximity-based authentication. Traditional distancebounding requires that the prover and the verifier are in each other's communication range. Recently, Pagnin et al. have proposed a two-hop DB protocol that allows proximity-based authentication, when the prover and the verifier need to rely on an intermediate untrusted party (linker). In this paper, we investigate further the topic of two-hop distance-bounding. We analyse the security of the Pagnin et al. protocol for internal adversaries and we investigate the impact of the position of the linker in the distance-bounding process. We propose a new two-hop DB protocol that is more lightweight and avoids the identified problems. Finally, we extend the protocol to the multi-hop setting and we provide a detailed security analysis for internal adversaries.

Introduction

Ubiquitous computing technologies have affected radically our communications. Multiple heterogeneous devices are inter-connected and proximitybased authentication has been adopted in a wide range of applications e.g., remote unlocking, contactless payments, proximity cards for access control in services/places. Distance-bounding (DB) protocols [START_REF] Dimitrakakis | Distance-bounding protocols: Are you close enough[END_REF][START_REF] Mitrokotsa | Authentication in constrained settings[END_REF] is a valuable tool in this ubiquitous computing paradigm, since they determine an upper bound on the physical distance between two communicating parties by measuring the round-trip-time between the exchanged challenges and responses. Distance-bounding protocols have received a lot of attention in the literature and multiple works have been published focusing on the selection of optimal parameters for DB protocols [START_REF] Dimitrakakis | Expected loss bounds for authentication in constrained channels[END_REF][START_REF] Dimitrakakis | Expected loss analysis for authentication in constrained channels[END_REF][START_REF] Mitrokotsa | On selecting the nonce length in distance-bounding protocols[END_REF], on related privacy issues [START_REF] Mitrokotsa | Location leakage in distance bounding: Why location privacy does not work[END_REF][START_REF] Aumasson | A note on a privacy-preserving distance-bounding protocol[END_REF], as well as multiple attacks [START_REF] Pagnin | Distance bounding meets human based authentication[END_REF][9][START_REF] Bay | The bussardbagga and other distance bounding protocols under man-in-the-middle attacks[END_REF][START_REF] Mitrokotsa | Mafia fraud attack against the rc distancebounding protocol[END_REF] against existing DB protocols and proposed solutions [START_REF] Pagnin | Hb+db, mitigating man-inthe-middle attacks against HB+ with distance bounding[END_REF][START_REF] Boureanu | Practical and provably secure distancebounding[END_REF][START_REF] Boureanu | Practical and provably secure distancebounding[END_REF] that combat identified weaknesses. Furthermore, the concept of grouping proof distancebounding protocols [START_REF] Karlsson | Grouping-proof-distance-bounding protocols: Keep all your friends close[END_REF] has been recently introduced in order to provide not only a proof of the presence of multiple provers at the same time but also assurance regarding the physical proximity of the provers. However, in many cases (e.g., communication in Vehicular ad-hoc Networks (VANETs) and Wireless Sensor Networks (WSNs)), we need to have a proof of proximity even when the two main parties prover and verifier are not in the direct communication range of each other, but have to rely on an untrusted intermediate node (linker). Recently, Pagnin et al. [START_REF] Pagnin | Using distance-bounding protocols to securely verify the proximity of two-hop neighbours[END_REF] proposed an extension of traditional DB protocols that can verify the proximity of both next-hop and two-hop neighbours.

In this article, we investigate the security of the Pagnin et al. [START_REF] Pagnin | Using distance-bounding protocols to securely verify the proximity of two-hop neighbours[END_REF] protocol for internal adversaries and we identify three weaknesses. We discuss how the location of intermediate untrusted linkers affects the DB process and we propose a new two-hop DB protocol that overcomes the identified problems, requires no computation from the linker, and provides lower attack success probabilities in comparison to the Pagnin et al. protocol. Finally, we investigate how the proposed two-hop DB protocol can be extended to the multi-hop setting [START_REF] Mitrokotsa | Multi-hop distance estimation: How far are you?[END_REF] i.e., when multiple intermediate linkers are used to reach the prover and we discuss how the attack success probabilities are affected.

Two-hop distance bounding

Traditional one-hop DB protocols consider two "legitimate" parties: a single verifier and a single prover within one-hop communication range. Pagnin et al. [START_REF] Pagnin | Using distance-bounding protocols to securely verify the proximity of two-hop neighbours[END_REF] introduced the concept of two-hop DB which involves three entities: a trusted verifier (V), an untrusted prover (P) and an untrusted in-between linker (L). The goal is to bound the distance between V and P, while relying on the intermediate untrusted linker L. More precisely, P wants to be authenticated by V, while V wants to bound the distance of P. The prover P is not in the communication range of the verifier V (two-hop neighbours), while L is within the communication range (one-hop) of both V and P. All nodes (P, V and L) use the same communication channel.

The two-hop DB protocol proposed by Pagnin et al. is depicted in Fig. 1 and employs two secret keys: x VL shared between V and L, and x VP shared between V and P. N V , N P and N L denote random nonces, f y () a pseudorandom function, Enc y () an encryption function and MAC y () a function that computes a message authentication code. All three functions use an appropriate key here denoted as y. More precisely, it is composed of the following phases: -Initialization phase: V, L, P generate randomly their corresponding nonces. Both V and L use the pseudorandom function h and the secret key x VL in order to calculate two n-bit sequences a 0 and a 1 , while P uses the pseudorandom function h with the key x VP to generate the d 0 and d 1 registers.

-Distance-bounding phase: In this phase, a fast bit exchange phase takes place, where V sends out one bit c i to L and starts two clocks t L and t P . L responds to both V and P with one calculated bit i = (a c i ) i and V stops the first timer t L . The delay time of the responses enables V to compute an upper-bound on the next-hop distance with L and after observing the second timer t P , it computes the other bound on the twohop distance with P. This phase is time-critical and is separated by n rounds of timed challenge/response exchanges.

-Verification phase: After V receives P's nonce, i from L and the responses r i , it computes the d 0 , d 1 registers in order to verify r i and i . According to the result, V measures the bound on the physical distance to V using the clocks t L , t P .

Security Analysis

We describe what are the effects of a malicious linker L in the different phases of the Pagnin et al. protocol and analyse malicious behaviour that has not been considered before. We need to stress that the first two described security issues are related to weaknesses of the Pagnin et al. protocol to identify possible modifications of the transmitted messages that may subsequently lead to denial of service (DoS) attacks.

-Malicious L in the initialisation phase: A malicious L that receives N V from V, could send different nonces N L 1 and N L 2 to V and P correspondingly (Fig. 2), thus, disrupting the whole protocol and leading P and V to compute different registers d 0 = f x VP (N L 2 , N P ) i.e., computed by P in the initialisation, and d 0 = f x VP (N L 1 , N P ) i.e., computed by V in the verification phase. Consequently, the computation will be completely different and as a result the protocol will fail. -Malicious L in the verification phase: Similarly to the previous attack, a malicious L could modify the transmitted N P , thus disrupting the computation of d 0 by V and consequently leading to the failure of the protocol. This can be easily detected if a MAC of the nonce N P is also sent. Although this would not stop the DoS attack, it would definitely be useful to detect on time the misbehaviour of L.

Verifier V Linker L Prover P x VL , x VP x VL x VP Initialisation phase N V ←{0, 1} m NV -------→ NL ← ------- N L ← U {0, 1} m NL -------→ a 0 = f xV L (N V , N L ) a 0 = f xV L (N V , N L ) N P ←{0, 1} m a 1 = Enc a0 (x VL ) a 1 = Enc a0 (x VL ) d 0 = f xVP (N L , N P ) d 1 = Enc d0 (x VP ) Distance-bounding phase for i = {1, . . . , n} pick c i ∈ {0, 1} Start Clocks ci -------→ if c i / ∈ {0, 1}, halt Stop Clock t L i ← ------- else i = (a ci ) i i -------→ if i / ∈ {0, 1} halt ri ← ------- else r i = (d i ) i Stop Clock t P ri ← ------- Verification phase NP , ,r,MACx VP ( ,r) ← ----------- NP , ,r,MACx VP ( ,r) ← ----------- d 0 = f xVP (N L , N P ) d 1 = Enc d0 (x P ) check that ∆t Li , ∆t P i < t allowed ∀i = {1, . . . , n} Verify
-Malicious L in the distance-bounding phase: A malicious L can act as a man-in-the-middle and perform the attack that was initially described by Kim et al. [START_REF] Kim | The swiss-knife RFID distance bounding protocol[END_REF] against one-hop DB protocols [START_REF] Tu | RFID Distance Bounding Protocols[END_REF]-against the Pagnin et al. [START_REF] Pagnin | Using distance-bounding protocols to securely verify the proximity of two-hop neighbours[END_REF] protocol in order to recover bits of the key x VP , when as Enc function is employed the one time pad i.e., d 1 = d 0 ⊕ x VP . More precisely, L can during the DB phase, toggle the value of one bit i i.e., i = i transmit the same i to V and P and leave all other messages untouched.

Then, L can observe the verifier's reaction. If V accepts P, it means that P's answer r i was correct. Thus, the bit of the key x VP i will be 0, because

d 0i =d 1i . If V does not accept then d 0i = d 1i , thus, x VP i =1.
We should note that in the Pagnin et al. protocol is stated: "V computes d 0 and d 1 and verifies that all received i and r i , ∀i ∈ {1, ..., n} are correct." However, this leaves rather unclear if V actually computes i or simply verifies that the i s and r i s received during the distance-bounding phase match the ones received during the verification phase. To avoid this attack, the necessary condition is that V should recompute i using i = (a c i ) i in the verification phase and verify the received i 's. If this recomputation is performed, then the attack will not be successful and the protocol will be aborted because V will see the differences in i . However, if V simply verifies that the values of and r received in the DB phase match the ones received in the verification phase and the corresponding MAC x VP ( , r) the attack can be performed successfully.

Verifier V Linker L Prover P x VL , x VP x VL x VP Initialisation phase N V ←{0, 1} m NV -------→ NL 1 ← -------N L1 ← U {0, 1} m NL 2 -------→ a 0 = f xL (N V , N L1 ) N L2 ← U {0, 1} m N P ←{0, 1} m a 1 = Enc a0 (x VL ) a 0 = f xL (N V , N L2 ) d 0 = f xVP (N L2 , N P ) a 1 = Enc a0 (x VL ) d 1 = Enc d0 (x VP )

Effects of possible positions of the Linker

It is easy to see that the estimated distance between V and P in twohop DB mainly depends on the position of L. More precisely, L can be located either on the same line with the other two entities or anywhere else between them. In the second case, a triangle is formed. Let us denote by t 1 the estimated time required to transmit a message from V to L and t 2 the corresponding time required to transmit a message from L to P. t 1 and t 2 can be easily estimated using the ∆t P i and ∆t L i in a two-hop DB protocol [START_REF] Pagnin | Using distance-bounding protocols to securely verify the proximity of two-hop neighbours[END_REF]. Let us denote by d(A, B) the actual distance between two entities A and B.

If we construct a segment d (V, L) and a circle with centre L (Fig. 3, where P and P denote possible locations of the prover), then P can be any point inside or on this circle. We would like to estimate the third side of the formed triangle d (V, P). If we knew the included angle between d(V, L) and d(L, P), then we could determine the length of the third side. For instance, when the angle is equal to 180 degrees i.e., V, P and L are all in the diameter of the circle with centre L then d(V, P) = d(V, L) + d(L, P) ≈ c(t 1 + t 2 ) where c denotes the speed of light. Thus, in that case we have minimal error in estimating d(V, P) using a two-hop DB. We may distinguish two cases in determining the estimation error on the physical distance between V and P: L's position is unknown Using the triangular inequality, we have an upper and lower bound for the distance: c | t 1 -t 2 | -< d (V, P) < c(t 1 +t 2 )-where denotes the error in the distance-bounding process. If we have multiple linkers L j , j ∈ {1, . . . , m} in the communication range of V and P, we can run multiple times a two-hop DB protocol. We denote by t j,1 the estimated time required to transmit a message from V to L j and by t j,2 the estimated time required to transmit a message from P to L j . By observing the different sums (t j,1 + t j,2 ), we can deduce which linker is closer (i.e., produces the smallest sum) and thus, which L j has the smallest error in the distance estimation, but we cannot find its exact position.

L's position is known In this case, if we know the exact position of V and L, we can find the position of P and consequently d(V, P). However, to achieve this with high accuracy, we need to have at least three linkers in the communication range of V and P. We may run a DB protocol three times each for a different linker L j , where j ∈ {1, 2, 3} to get a good estimate of the three distances d(L j , P). If we consider that d L j P denotes the estimated distance via the DB protocol we can consider d L j P ≈ d(L j , P). Then, using trilateration [START_REF] Shih | Cola: Complexity-reduced trilateration approach for 3d localization in wireless sensor networks[END_REF] we can determine the exact location of P. We can compute d (V, P) = (x V -x) 2 + (y V -y) 2 , where x V , y V are the coordinates of V and x, y the coordinates of P. If we know the angle between d(V, L j ) and d(L j , P) this computation is simplified, i.e., if the triangle is orthogonal we only need to know the locations of two linkers. Alternatively, using the Received Signal Strength Indicator (RSSI) method [START_REF] Papamanthou | Algorithms for location estimation based on rssi sampling[END_REF] by employing multiple reference points and using the strength of the transmitted signals, we are able to estimate the distance between V and P. After computing d(V, P), it is easy to see that the estimation error of the distance d VP computed via a two-hop DB protocol is = d VP -d(V, P). Selection of the best Common Neighbour: In any case, the linker L, should be a common neighbour of both V and P. Several linkers may be located in the range of V. For every linker L j in the communication range δ of the verifier V it holds d (V, L j ) δ. Obviously, if in order to reach P, the verifier V has to rely on multiple linkers (e.g., L 1 and L 2 ), the error estimation will increase. Optimally, we want to choose the linker L j that satisfies the condition max{d(V, L j )} ≤ δ, while at the same time gives the lowest estimation error among the possible linkers.

The Proposed Two-Hop DB Protocol

In this section, we describe a novel two-hop DB protocol (depicted in Fig. 4), that overcomes the problems identified in Section 2.1, while requires no computation from the intermediate linker i.e., L simply relays messages between V and P. Furthermore, the proposed protocol as we will show in the security analysis presents higher resistance to the attacks considered by Pagnin et al. [START_REF] Pagnin | Using distance-bounding protocols to securely verify the proximity of two-hop neighbours[END_REF] for internal adversaries.

We consider the same setting of a verifier V, an untrusted linker L, and an untrusted prover P that wants to be authenticated and prove its proximity. We also consider that there is only one secret key x VP that is shared between V and P. In the initialization phase, we would like to be sure that L transfers the correct nonces. A simple solution is that each node uses the shared key to compute a MAC on the nonce it sends. As a result, P and V can understand if the received nonce from L has been altered or not. Subsequently, V and P compute the values a 0 and a 1 using a pseudorandom function and an encryption function correspondingly. In the distance-bounding phase, V chooses a random challenge bit, which is forwarded by L to P, while P computes and sends back the responses r i = a(c i ) i ∀i ∈ {1 . . . , n}. Finally, in the verification phase, P sends c, r and the corresponding MAC x V,P (c, r) that is forwarded by L and finally verified by V.

Verifier V Linker L Prover P x VP x VP Initialisation phase N V ←{0, 1} m NV ||M ACx VP (NV ) ----------→ NV ||M ACx VP (NV ) ----------→ NP ||M ACx VP (NP ) ←---------- NP ||M ACx VP (NP ) ←---------- N P ←{0, 1} m a 0 = f xVP (N V , N P ) a 0 = f xVP (N V , N P ) a 1 = Enc a0 (x VP ) a 1 = Enc a0 (x VP )
Distance-bounding phase for i = {1, . . . , n}

pick c i ∈ {0, 1} Start Clock ci -------→ ci -------→ Stop Clock t P ri ← ------- ri ← ------- r i = (a ci ) i Verification phase c,r,MACx VP (c,r) ← --------- c,r,MACx VP (c,r)
← --------check that ∆t P i < t allowed ∀i ∈ {1, . . . , n} Verify c, r and MAC xVP (c, r) Fig. 4. Efficient two-hop distance-bounding protocol.

Security Analysis

In this section, we analyse the security of the proposed two-hop DB protocol, considering internal adversaries as in [START_REF] Pagnin | Using distance-bounding protocols to securely verify the proximity of two-hop neighbours[END_REF].

Case A -Dishonest prover P, honest linker L: A dishonest prover P might be located far away from L and may want to appear closer. So, in the distance-bounding phase P has to send the wrong response ri before it receives the challenge c i from L. Since r i is determined by the two response registers a 0 and a 1 , P knows r i if a 0i = a 1i . If a 0i = a 1i then P has to guess the response r i . Thus, the success probability is

3 4 n .
Case B -Honest prover P, dishonest linker L: L may want to shorten the distance between P and V. We may consider two main strate-gies: In the first strategy, L waits for c i from V and sends it to P. Then, L sends a random response before receiving r i from P. Since r i is determined by a 0 , a 1 , and c i , the success probability is equal to 1 2 per round. In the second strategy, L sends a random challenge before receiving c i from V. Then, L waits for the response from P and forwards it to V when it sends c i . The success probability is again equal to 1 2 per round. Thus, the overall success probability is

1 2 n .
We need to note here that the problems identified in Section 2.1, when L is malicious do not apply in the new protocol. By computing the MAC of the nonces in the initialisation phase, L cannot modify the nonces without being detected, while there is no need to transfer N P in the verification phase. Also the Kim et al. [START_REF] Kim | The swiss-knife RFID distance bounding protocol[END_REF] attack cannot be applied since a MAC of all transmitted c i 's and r i 's is verified at the end. Case C -Dishonest prover P, dishonest linker L: We may discriminate into two sub-cases.

-P and L do not collaborate: In this sub-case, the success probability depends on whether Case A or Case B succeeds. More precisely, the success probability depends on whether P can guess r i correctly with probability 3 4 n (Case A). For a dishonest L (Case B), the success depends on guessing c i and r i correctly (i.e., ( 12 ) n ). Thus, the overall success probability is 5 8 n , (i.e., 3 4 for Case A or 1 2 for Case B). -P and L collaborate: In this sub-case, P collaborates with L in order to appear within the allowed distance bound. P has two options: to reveal some information about his secret key x VP (something he does not want to do) or to send one register a 0 or a 1 to L. Thus, in the latter case L can compute the half of responses r i correctly and send them in time to V. The other half, have to be guessed by L. So, the overall success probability of the attack in this sub-case is 3 4 n .

We should point out that in the above security analysis the focus is mainly on distance-shortening attacks since DB protocols are mainly employed in proximity-based authentication settings. In case that a malicious linker on purpose delays to relay information between P and V this would lead to failure of the protocol when the condition ∆t P i < t allowed does not hold.

Extension to the multi-hop DB setting

Up to now, we have considered two-hop DB protocols where P and V need to rely on a single intermediate linker. In this section, we investigate how the proposed two-hop DB protocol can be extended to a multi-hop

Verifier V Linker L 1 Linker L 2 ... Linker L m Prover P x VP x VP Initialisation phase N V ←{0, 1} m NV ||M ACx VP (NV ) ----------→ NV ||M ACx VP (NV ) ----------→ NV ||M ACx VP (NV )
----------→ ...

NV ||M ACx VP (NV ) ----------→ NP ||M ACx VP (NP ) ←---------- NP ||M ACx VP (NP ) ←---------- NP ||M ACx VP (NP )
←----------...

NP ||M ACx VP (NP ) ←---------- N P ←{0, 1} m a 0 = f xVP (N V , N P ) a 0 = f xVP (N V , N P ) a 1 = Enc a0 (x VP ) a 1 = Enc a0 (x VP )
Distance-bounding phase for i = {1, . . . , n}

pick c i ∈ {0, 1} Start Clock ci -------→ ci -------→ ci -------→ ... ci -------→ Stop Clock t P ri ← ------- ri ← ------- ri ← ------- ... ri ← ------- r i = (a ci ) i Verification phase c,r,MACx VP (c,r) ← --------- c,r,MACx VP (c,r) ← --------- c,r,MACx VP (c,r) ← --------- ... c,r,MACx VP (c,r)
← --------check that ∆t P i < t allowed ∀i ∈ {1, . . . , n} Verify c, r and MAC xVP (c, r) Fig. 5. Extended multi-hop distance-bounding protocol setting i.e., when V and P have to rely on multiple intermediate linkers L j where j ∈ {i, . . . , m}. Multi-hop distance estimation as a generalisation of distance-bounding was proposed for the first time by Mitrokotsa et al. [START_REF] Mitrokotsa | Multi-hop distance estimation: How far are you?[END_REF]. In our proposed multi-hop DB protocol, similarly as before, the goal of V is to determine an upper-bound of the distance to P and the role of intermediates L j is to forward the messages to P. Our proposed multihop DB protocol (depicted in Fig. 5) is a natural extension of the proposed two-hop DB protocol; we discuss briefly its security in this section. It is easy to see that the protocol is similar to the proposed two-hop DB protocol.

The security analysis of the multi-hop DB protocol is similar to the one for the two-hop DB protocol. Case A -Dishonest prover P, honest linkers L's: The overall success probability remains 3 4 n since only P is dishonest.

Case B -Honest prover P, dishonest linkers L's: When we have one dishonest linker the success probability is ( 12 ) n as we have shown. It is easy to see that even if we have k dishonest linkers the overall success probability is again ( 12 ) n since there is no dependency on the forwarded messages. Case C -Dishonest prover P, dishonest linkers L's: We have two sub-cases: -P and L do not collaborate: This sub-case depends on the Cases A and B. Either P (Case A) will succeed with probability 3 4 or k L's (Case B) will succeed with probability 1 2 . Thus, the overall success probability is 5 8

n .

-P and L's collaborate: If P collaborates with k L's i.e., reveals either a 0 or a 1 (thus, half of the responses) then, the overall success probability will be 3 4 n . Either P (Case A) will succeed with probability 3 4 or k L's (Case B) will succeed with probability 1 2 . Thus, the overall success probability is 5 8 n .

Table 1 summarises the best case attack success probabilities for the three protocols that we studied in this paper. It covers all the cases of malicious internal participants.

Conclusion

In this paper, we investigated the problem of two-hop DB protocols. More precisely, we examined the security of the first two-hop DB protocol [START_REF] Pagnin | Using distance-bounding protocols to securely verify the proximity of two-hop neighbours[END_REF] and we identified some weaknesses. We also discussed how the location of the linker may affect the distance-bounding process. Furthermore, we proposed a novel two-hop DB protocol, that does not require any computation from the intermediate linker, does not suffer from the identified weaknesses and reduces the attack success probabilities for internal adversaries. Finally, we investigated how the proposed two-hop DB protocol can be extended to the multi-hop DB setting and how the attack success probabilities are affected.

"PRECIS: Privacy and Security in Wearable Computing Devices" no 621-2014-4845, the STINT grant "Secure, Private & Efficient Healthcare with wearable computing no IB2015-6001 and the ERASMUS+HE2015 project.

Fig. 1 .

 1 Fig. 1. The Pagnin et al. [16] two-hop distance-bounding protocol.

Fig. 2 .

 2 Fig. 2. Attack using different nonces.

Fig. 3 .

 3 Fig. 3. Depiction of possible locations of a linker, a verifier, and a prover.

Table 1 .

 1 Best Case Attack Success Probabilities

	Protocol	P,L P, L	P, L	P,	L
			collaboration no collaboration
	two-hop DB

Acknowledgements

This work was partially supported by the People Programme (Marie Curie Actions) of the European Union's Seventh Framework Programme (FP7/2007-2013) under REA grant agreement no 608743, the VR grant


Raja Carlton Shepherd
email: carlton.shepherd.2014@rhul.ac.uk

Naeem Akram
email: r.n.akram@rhul.ac.uk

Konstantinos Markantonakis
email: k.markantonakis@rhul.ac.uk

EmLog: Tamper-Resistant System Logging for Constrained Devices with TEEs

Keywords: System Logging, Embedded Security, Trusted Computing

Remote mobile and embedded devices are used to deliver increasingly impactful services, such as medical rehabilitation and assistive technologies. Secure system logging is beneficial in these scenarios to aid audit and forensic investigations particularly if devices bring harm to end-users. Logs should be tamper-resistant in storage, during execution, and when retrieved by a trusted remote verifier. In recent years, Trusted Execution Environments (TEEs) have emerged as the go-to root of trust on constrained devices for isolated execution of sensitive applications. Existing TEE-based logging systems, however, focus largely on protecting server-side logs and offer little protection to constrained source devices. In this paper, we introduce EmLog -a tamper-resistant logging system for constrained devices using the GlobalPlatform TEE. EmLog provides protection against complex software adversaries and offers several additional security properties over past schemes. The system is evaluated across three log datasets using an off-the-shelf ARM development board running an open-source, GlobalPlatform-compliant TEE. On average, EmLog runs with low run-time memory overhead (1MB heap and stack), 430-625 logs/second throughput, and five-times persistent storage overhead versus unprotected logs.

Introduction

System logs record features such as user activity, resource consumption, peripheral use and error details. Logs are also used to enforce user accountability and to establish audit trails for forensics, event reconstruction and intrusion detection [START_REF] Kent | Guide to Computer Security Log Management[END_REF]. Consequently, logs are routinely targeted by attackers to conceal evidence of wrongdoing, and should be stored securely to preserve the auditability of a compromised system -as recommended by NIST [START_REF] Kent | Guide to Computer Security Log Management[END_REF] and ISO 27001:2013 [14]. Not only should logs be stored in a way that cryptographically preserves their confidentiality and integrity, but trusted computing primitives, e.g. Trusted Platform Modules (TPMs), have been identified as desirable in existing proposals [START_REF] Böck | Towards More Trustable Log Files for Digital Forensics by Means of Trusted Computing[END_REF][START_REF] Sinha | Continuous Tamper-proof Logging Using TPM 2.0[END_REF]. Such technologies have been used for tamper-resistant storage of logging keys, performing cryptographic operations, and providing evidence of platform integrity to third-party verifiers using remote attestation.

However, the advent of low-cost, mass-produced Internet of Things (IoT) devices complicates the use of trusted computing for tamper-resistant logging. Numerous proposals suggest using IoT devices for remote health monitoring [START_REF] Patel | A Review of Wearable Sensors and Systems with Applications in Rehabilitation[END_REF], identifying fires and gas leakages [START_REF] Chen | A Home Security ZigBee Network for Remote Monitoring Applications[END_REF], and detecting falls and injuries in the homes of the elderly and disabled [START_REF] Rashidi | A Survey on Ambient-Assisted Living Tools for Older Adults[END_REF] -all of which are natural applications for tamper-resistant logging. Unfortunately, discrete hardware TPMs, which underpin many existing proposals, cannot directly host arbitrary applications without additional processes, such as launching and locally attesting applications from a TPM-backed virtual machine [START_REF] Böck | Towards More Trustable Log Files for Digital Forensics by Means of Trusted Computing[END_REF][START_REF] Perez | vTPM: Virtualizing the Trusted Platform Module[END_REF]. Including such processes within the device's Trusted Computing Base (TCB) -the set of software and hardware components essential to its security -widens the scope for introducing security and performance defects [START_REF] Mccune | TrustVisor: Efficient TCB Reduction and Attestation[END_REF][START_REF] Singaravelu | Reducing TCB Complexity for Security-Sensitive Applications: Three Case Studies[END_REF]. One promising solution is the Trusted Execution Environment (TEE), which offers TPM-like functionality alongside strong isolated execution of critical applications, while using the core execution hardware of conventional operating systems. TEEs have become widely-deployed in recent years, notably in the form of Intel Software Guard eXtensions (SGX) and TEEs built on ARM TrustZone. Indeed, Trustonic estimated that one billion devices contained their TrustZone-based TEE alone in early 2017 [START_REF] Trustonic | Adoption of Trustonic Security Platforms Passes 1 Billion Device Milestone[END_REF]. However, TEE-based logging schemes -discussed in Section 2 -have hitherto applied only server-side TEEs to protect logs transmitted from remote devices.

In this paper, we present EmLog, which leverages the GlobalPlatform TEE and ARM TrustZone for protecting logs at source on mobile and embedded systems. EmLog offers further security benefits over past work, including public verifiability of log origin, resilience to TEE key compromise, and supports secure I/O with peripheral devices. After reviewing related work (Section 2), we formalise the requirements and threat model in Section 4. EmLog is implemented on an off-the-shelf ARM development board hosting OP-TEE [START_REF] Linaro | OP-TEE: Open Portable Trusted Execution Environment[END_REF] -an open-source and GlobalPlatform-compliant TEE that uses TrustZone (Section 6) -and evaluated using three datasets in Section 7. Finally, we conclude our work in Section 8 and identify future areas of research. To our knowledge, this is the first attempt at preserving logs on constrained devices using a standardised TEE. The contributions of this paper are: 1), the development of a novel secure logging scheme for creating tamper-resistant logs with trust assurances, tailored for ARM-based constrained devices, like wearables and sensing platforms; and 2), a test-bed implementation using a GlobalPlatform-compliant TEE that uses ARM Trust-Zone, with performance benchmarks across three datasets. The results indicate that EmLog has low run-time memory footprint, five-times persistent storage overhead, and 430-625 logs/sec throughput.

Related Work

Existing proposals may be categorised as: 1), secure untrusted system logging, focusing on cryptographic methods for detecting tampered logs on untrusted platforms; and 2), trusted logging, for applying trusted hardware primitives for log preservation. We briefly examine key proposals and their contributions.

Secure Untrusted System Logging

Schneier and Kelsey [START_REF] Schneier | Secure audit logs to support computer forensics[END_REF] propose the use of MACs with linear one-way hash chains to protect log integrity. Each chain entry is found by successively hashing the log content with the previous log's hash, which is accompanied by a MAC keyed under the hash of the previous MAC key. The initial key is a pre-shared key (PSK) between the logging device and a trusted verifier, which allows the MAC hash chain to be recomputed and verified. Bellare and Yee [START_REF] Bellare | Forward Integrity for Secure Audit Logs[END_REF] propose a similar scheme using the formalised notion of forward integrity in which it is computationally infeasible to alter past entries after a key compromise. This is achieved by updating the secret key at regular time intervals (epochs) using an update process based on a chain of pseudo-random functions to key the log MACs in each epoch. Holt [START_REF] Holt | Logcrypt: Forward Security and Public Verification for Secure Audit Logs[END_REF] proposed Logcrypt, which uses public-key cryptography alongside MACs to achieve public verifiability, so third-parties can authenticate the origin of log entries without knowledge of a secret PSK -shortfalls of [START_REF] Schneier | Secure audit logs to support computer forensics[END_REF] and [START_REF] Bellare | Forward Integrity for Secure Audit Logs[END_REF]. Ma et al. [START_REF] Ma | A New Approach to Secure Logging[END_REF] introduce FssAgg, which uses an aggregated chain of signatures to achieve public verifiability and to thwart truncation attacks, where an attacker aims to delete a tail-end subset of log entries. Yavuz et al. [START_REF] Yavuz | Efficient, Compromise-Resilient and Append-Only Cryptographic Schemes for Secure Audit Logging[END_REF] proposed LogFAS, which addresses both challenges with better storage and computational complexity than [START_REF] Holt | Logcrypt: Forward Security and Public Verification for Secure Audit Logs[END_REF] and [START_REF] Ma | A New Approach to Secure Logging[END_REF] using the Schnorr signature scheme. Recently, Hartung [START_REF] Hartung | Attacks on Secure Logging Schemes[END_REF] presented four attacks against LogFAS [START_REF] Yavuz | Efficient, Compromise-Resilient and Append-Only Cryptographic Schemes for Secure Audit Logging[END_REF] and two variants of FssAgg [START_REF] Ma | A New Approach to Secure Logging[END_REF], which enables secret key recovery and log forgery; as a result, both schemes are dissuaded from use.

Secure Logging with Trusted Hardware

Early work by Chong et al. [START_REF] Chong | Secure Audit Logging with Tamper-Resistant Hardware[END_REF] explored trusted hardware (Java iButton) to protect the initial PSK of the Schneier and Kelsey scheme [START_REF] Schneier | Secure audit logs to support computer forensics[END_REF]. Later, Sinha et al. [START_REF] Sinha | Continuous Tamper-proof Logging Using TPM 2.0[END_REF] suggested a using a TPM with a forward integrity scheme based on branched key chaining. Logs are divided into epochs (blocks), each comprising a sequence of hash-chained log entries (sub-epochs). The root entries of each epoch are hash-chained with past epochs, which creates a two-dimensional hash chain to prevent re-ordering attacks in which an attacker re-orders log blocks to mislead auditors. For each new epoch, the previous epoch's logs are securely stored using the TPM's seal functionality, which encrypts the logs with a TPMbound key so only that particular TPM can decrypt/'unseal' them. Böck et al. [START_REF] Böck | Towards More Trustable Log Files for Digital Forensics by Means of Trusted Computing[END_REF] explore the use of AMD's Secure Virtual Machine (SVM) -an early inception of the TEE -for launching a syslog client daemon and logging application from the TPM's secure boot chain. The logger executes with access to TPMbound key-pairs for encrypting and signing log entries. Upon request, the logs are decrypted and transmitted to the verifying party; the TPM keys are certified for authenticating that signed logs originated from the SVM.

Nguyen et al. [START_REF] Nguyen | Cloud-Based Secure Logger for Medical Devices[END_REF] propose streaming medical logs to a server application in Intel SGX (see Section 3) that applies the tamper-resistance. Logs are sent to the Intel SGX application ('enclave') over TLS, which computes a hash chain comprising a signature of each record; TPMs are used to authenticate the medical devices to the server, and on the server's end to securely store log hash chains using its sealing mechanism. Karande et al. [START_REF] Karande | SGX-Log: Securing System Logs With SGX[END_REF] introduce SGX-Log, which protects server-side device logs received from remote devices. SGX-Log, like [START_REF] Sinha | Continuous Tamper-proof Logging Using TPM 2.0[END_REF], uses block-based hash chains with SGX's secure storage for log integrity and confidentiality. The authors note that continual sealing also provides resilience to attacks in which large volumes of logs in memory are lost due to an unauthorised power loss. Remote attestation is also suggested to authenticate the server enclave before transmitting the logs. The proposed scheme is evaluated using three datasets, yielding a small (< 7%) overhead versus a non-SGX implementation.

Discussion

Modern TPM-and TEE-based approaches [START_REF] Nguyen | Cloud-Based Secure Logger for Medical Devices[END_REF][START_REF] Karande | SGX-Log: Securing System Logs With SGX[END_REF][START_REF] Sinha | Continuous Tamper-proof Logging Using TPM 2.0[END_REF][START_REF] Böck | Towards More Trustable Log Files for Digital Forensics by Means of Trusted Computing[END_REF] still fall short of satisfying many desirable properties identified in past work. Public verifiability of origin, as in [START_REF] Böck | Towards More Trustable Log Files for Digital Forensics by Means of Trusted Computing[END_REF], has not been addressed in recent TEE loggers, which could be potentially useful to authenticate system data from remote devices, e.g. generating trust scores from log data for access control [START_REF] Bao | Dynamic Trust Management for Internet of Things Applications[END_REF] and continuous authentication [START_REF] Micallef | Sensor Use and Usefulness: Trade-offs for Data-driven Authentication on Mobile Devices[END_REF][START_REF] Shepherd | Towards Trusted Execution of Multi-modal Continuous Authentication Schemes[END_REF]. Recent TEE-based schemes, i.e. [START_REF] Karande | SGX-Log: Securing System Logs With SGX[END_REF] and [START_REF] Nguyen | Cloud-Based Secure Logger for Medical Devices[END_REF], focus primarily on protecting logs after being received by a server-side log processing application; an attacker on the source device may simply tamper the logs before reaching the server that applies some tamper-resistance algorithm. To complicate matters, source devices are unlikely to transmit logs in real-time to minimise network and computational overhead, and so secure storage methods should be used to preserve unsent logs. Additionally, TEEs typically contain other security-critical applications, e.g. for fingerprint matching (as in Android1 ) and payment tokenisation (see Samsung Pay2 ). As a result, a TEE-based logging mechanism should operate with reasonable resource consumption, e.g. run-time memory, to limit the rise of Denial of Service (DoS) conditions.

Trusted Execution Environments (TEEs)

GlobalPlatform defines a TEE as an isolated execution environment that "protects from general software attacks, defines rigid safeguards as to the data and functions a program can access, and resists a set of defined threats" [9]. TEEs aim to isolate applications from integrity and confidentiality attacks from a conventional operating system. Applications in the conventional OS and TEEreferred to as 'untrusted' and 'trusted' worlds respectively in GlobalPlatform nomenclature -reside in separate memory address spaces, and trusted hardware is used to monitor and prevent unauthorised memory accesses from the untrusted world. TEE applications may allocate shared memory spaces or expose predefined functions via an API mediated by a high-privilege secure monitor. Next, we summarise the leading commercial TEE architectures.

The GlobalPlatform (GP) TEE maintains two worlds for all trusted and untrusted applications. A TEE-based kernel is used for scheduling, memory management, cryptographic methods and other basic OS functions; TEE-resident Trusted Applications (TAs) may access OS functions exposed by the GP TEE Internal API (see Figure 1). The GP TEE Client API [9] defines the interfaces for communicating with TAs from untrusted world applications. The GP specifications also cover the use of external secure elements (GP Secure Element API), secure storage, and networking (GP Sockets API) [11]. One method for instantiating the GP TEE is using ARM TrustZone, which enables two isolated worlds to co-exist in hardware. This is achieved using two virtual cores for each world per physical CPU core and an extra CPU bit, the NS bit, for distinguishing between untrusted/secure world execution modes. TrustZone provides secure I/O with peripheral devices connected over standard interfaces, e.g. SPI and GPIO, by routing interrupts to the TEE OS. This is performed via the TrustZone Protection Controller (TZPC), responsible for securing on-chip peripherals, and the TrustZone Address Space Controller (TZASC) for protecting memory-mapped devices from untrusted world accesses. Intel Software Guard Extensions (SGX) is an extension to the X86-64 instruction set that enables on-demand creation of 'enclaves' per application. Enclaves reside in isolated memory regions within RAM with accesses mediated by the CPU, which is considered trusted [START_REF] Costan | Intel SGX Explained[END_REF]. Enclaves may access the memory space of a regular OS, but not vice-versa, and enclaves cannot access other enclaves arbitrarily. Like TPMs, SGX offers secure storage through 'sealing' in which data is encrypted and made accessible only to that enclave. Remote attestation enables third-party verification of enclaves and secret provisioning using Enhanced Privacy ID (EPID) -a Direct Anonymous Attestation (DAA) proto-col by Brickell et al. [START_REF] Brickell | Enhanced Privacy ID from Bilinear Pairing for Hardware Authentication and Attestation[END_REF]. SGX has been supported from the release of the Skylake microarchitecture (from 2015).

Despite some high-level similarities, SGX is not GlobalPlatform-compliant. Intel SGX is currently restricted solely to Intel CPUs, while the GP TEE is typically deployed on ARM System-on-Chips (SoCs) using TrustZone, as used by many IoT devices, e.g. Raspberry Pi 33 , NEST thermostat4 , and 95% of consumer wearables according to ARM [START_REF] Arm | Markets: Wearables[END_REF]. The reader is referred to [START_REF] Shepherd | Secure and Trusted Execution: Past, Present, and Future -A Critical Review in the Context of the Internet of Things and Cyber-Physical Systems[END_REF] for a detailed survey of secure and trusted execution environments for IoT devices.

System Requirements

We formalise the requirements for a TEE-based system for protecting logs on constrained devices. The proposal should satisfy the following security and functional requirements drawn from the issues identified in Section 2: R1. Isolated execution: the system shall process logs in an environment isolated from a regular 'rich' OS, e.g. Android, to provide strong integrity assurances of the application and data under execution. R2. Forward integrity: the integrity of a given block of logs shall not be affected by a key comprise of a previous block. R3. Log confidentiality: on-device log confidentiality should be preserved to prevent the disclosure of potentially sensitive entries. R4. Remote attestation: the proposal shall allow third-parties to verify the logging application's integrity post-deployment to provide assurances that logs were sourced from an integral and authentic platform. R5. Secure log retrieval : authorised third-parties shall be able to securely retrieve device logs without human intervention. R6. Public verifiability: the system shall allow third-parties to authenticate the origin of log entries without access to private key information. R7. Truncation attack-resistant: the system shall be resistant to attacks that aim to delete a contiguous subset of tail-end log entries. R8. Re-ordering attack-resistant: the proposal shall resist attempts to change the order of entries in the log sequence. R9. Power-loss resilience: the loss of tamper-resistant logs shall be minimised in the event of a device power-loss. R10. Suitable root of trust: a root of trust for constrained device architectures shall be used, ideally without requiring additional security hardware.

The threat model considers two adversary types:

-On-device software adversary: a software-based attacker that compromises the system at time t and attempts to arbitrarily alter, forge or observe logs produced before t. This may operate at any protection level in the untrusted world, i.e. Rings 0-3, including arbitrarily altering execution flow and accessing non-TEE kernel space services.

-Network adversary: an adversary that attempts to arbitrarily alter, forge, replay or observe logs between the source device and the verifier over a network channel, e.g. WiFi/802.11. The attacker may also attempt to masquerade as a legitimate party to either end-point to collect logs illicitly.

Like past work, we trust the TEE and do not attempt to secure untrusted world logs after a compromise after time t, since a kernel-mode adversary may simply read/write directly to the kernel message buffer used to queue log entries (see Section 5.1). We also consider hardware and related side-channel attacks, e.g. power analysis, beyond the scope of this work, as these threats fall outside the security remit of TEEs. The reader is referred to the GlobalPlatform TEE Protection Profile [9] for a specification of their protection scope.

EmLog Architecture Design

We assume the presence of a GlobalPlatform-compliant TEE, a service provider that provisions EmLog into the TEE before deployment, and a third-party wishing to retrieve all or a partial set of the device's logs. The GP TEE, which maintains two sets of applications for each world, necessitates two logging components: one that collects logs from untrusted world applications and transmits these to the TEE over the GP Client API, and another that applies the protection algorithm within the TEE and responds to retrieval requests. An extension of the hash matrix in [START_REF] Sinha | Continuous Tamper-proof Logging Using TPM 2.0[END_REF] and [START_REF] Karande | SGX-Log: Securing System Logs With SGX[END_REF] is proposed to apply the tamper-resistance scheme within the GP TEE, which achieves integrity protection and public verifiability (Section 5.2). Next, the log blocks are stored every n blocks, or at a time epoch t, using the secure storage functionality of the GP TEE. After receiving a retrieval request, the source TEE authenticates the remote verifier and viceversa, after which the blocks are unsealed and transmitted over a secure channel between the TEEs (Section 5.3). We illustrate this process in Figure 2.

Log Collection

A conventional (Linux) kernel uses an internal message ring buffer to store log messages, which is made available to user space monitoring applications, such as dmesg and klogd, using the sys syslog syscall. For user-mode logging, syslogd listens on /dev/log, where logs are registered to using the syslog function from the C standard library. Logs are subsequently written to file or transmitted through the syslog protocol to a remote server over UDP. Some implementations, e.g. syslog-ng, provide further functionality like streaming logs over TCP with TLS. For collecting untrusted world logs, we suggest a syslogd variant that transmits logs to the EmLog TA within the GP TEE via the GP Client API.

Block Generation

We propose a variant of the hash matrix used in [START_REF] Karande | SGX-Log: Securing System Logs With SGX[END_REF] and [START_REF] Sinha | Continuous Tamper-proof Logging Using TPM 2.0[END_REF] for log sequence integrity. Here, hash sequences are created in which each block key, bK, is derived using a one-way hash function, h, over the previous block key and current block ID, bID; that is, bK bID = h(bK bID-1 , bID). The initial block key (bID = 0) is derived from a device-specific Root Logging Key (RLK). Each block key is used to derive an individual message key, k, for keying an HMAC in a similarly chained fashion, i.e. k (bID,mID) = h(k {bID,(mID-1)} , mID) for log entry mID in block bID, up to the block size m. Note that bK is used to derive k when mID = 0. A block-based approach provides power-loss resilience and truncation resistance (developed further in Section 5.3) while allowing the retrieval of subsets, i.e. blocks i to j, without transmitting all logs from the genesis block (bID = 0) to the remote verifier.

As it stands, this scheme is vulnerable to forgery attacks if just a single block key is compromised: an adversary can apply h on the leaked key with the next block ID to forge subsequent blocks and entries therein. Storing RLK and deriving keys within trusted hardware, e.g. an secure element (SE) or TPM, is desirable, but this adds hardware complexity to already-constrained devices with respect to raw component and integration costs. TEEs provide strong resilience to software attacks, but, unfortunately, are not invulnerable to developer-induced programming and API errors. The impact of RLK and block key divulgence, however, can be limited using key derivation, as described below.

Key Derivation. We suggest a simple scheme as follows: 1), intermediate keys (IKs) are derived from the RLK using a secure key derivation function, each of which serves c blocks; 2), each IK derives an initial block key, bK bID , for that block group, before sealing the IK immediately to storage; 3), bK bID is used to generate the block's message-specific keys; 4), the next bK bID is derived using kdf (bK bID-1 , bID) for up to c blocks, after which another IK is generated. In past proposals, a block key disclosure would require re-provisioning RLKa device-specific, possibly hardware-infused key, which would affect the device in perpetuity without potentially costly intervention. Our approach (Figure 3) limits the damage wrought by a compromised block key by affecting only future blocks in that group. In the worst case, besides divulging RLK, the exposure of IK can compromise only c blocks at most.

For the key derivation function, we suggest the HMAC-based extract-andexpand KDF (HKDF) by Krawczyk [START_REF] Krawczyk | Cryptographic Extraction and Key Derivation: the HKDF Scheme[END_REF][START_REF] Krawczyk | RFC 5869 -HMAC-based Extract-and-expand Key Derivation Function (HKDF)[END_REF] (RFC 5689). HKDF takes keying material and a non-secret salt as input, and repeatedly generates HMACs under the input to return cryptographically strong output key material. Unlike plain hash functions, used prevalently in past work, HKDF produces provably strong key material from as-strong or weaker input key material.

Log Integrity and Verifiability. For log message integrity, first compute hmac( (bID,mID) ) for message with block ID, bID, and message ID, mID, under key k (bID,mID) -derived from the previous message key or, for mID = 0, the block key. Each k should be immediately deleted from memory to limit memory consumption and exposure. This does not prevent auditing log sequences, since message keys may be regenerated from the pre-shared RLK.

In current symmetric-only schemes [START_REF] Chong | Secure Audit Logging with Tamper-Resistant Hardware[END_REF][START_REF] Karande | SGX-Log: Securing System Logs With SGX[END_REF][START_REF] Schneier | Secure audit logs to support computer forensics[END_REF][START_REF] Sinha | Continuous Tamper-proof Logging Using TPM 2.0[END_REF], public verification of log origin (R6 in Section 4) requires knowledge of block and message keys on all interested devices, derived ultimately from RLK. Revealing RLK is evidently undesirable because it enables the malicious creation and manipulation of valid blocks. Rather, we propose signing each block with an efficient signature scheme, σ, such as ECDSA, and a device-specific signing key-pair (pk, sk) over the concatenation of the block message HMACs (Figure 3). This key-pair should be certified to provide data origin authentication. The RLK and key-pair should be accessible only to the TEE, which is achievable using the TEE's secure storage mechanism or, for hardware tamper-resistance (with its complexities), using an external SE as suggested by GlobalPlatform [9]. In some circumstances, logs may contain sensitive data, in which case we suggest limiting verifiability to whitelisted entities, e.g. devices from the same manufacturer or service provider.

It is also observed that the block size, m, is inversely proportional to the number of signing operations; smaller block sizes will incur more signing operations for a given set of log entries (see Section 7 for this overhead).

Secure Storage and Remote Retrieval

Real-time log streaming is likely to be detrimental for power-and networklimited devices, and we suggest storing blocks prior to eventual transmission within the TEE's secure storage. Secure storage can be implemented in two ways according to GlobalPlatform: 1), using the file system and storage medium, e.g. flash drive, controlled by the untrusted world "as long as suitable cryptographic protection is applied, which must be as strong as that used to protect the TEE code and data itself " [10]. Or 2), using hardware controlled only by the TEE, e.g. an external SE. Method 2) is resilient against adversaries that aim to delete encrypted records from the file system5 , but naturally requires additional security hardware. For method 1), log blocks are sealed using authenticated encryption (AES in GCM mode) with a key derived specifically for the TA under execution from a separate, device-specific root storage key. This prevents other TAs or other entities from accessing secured data, thus providing on-device log confidentiality (R3), integrity and authenticity.

Securely storing every completed block, i.e. in [START_REF] Karande | SGX-Log: Securing System Logs With SGX[END_REF], may yield undesirable performance overhead for the devices targeted in this work. Rather, the parameters c (block group size) and m (block length) can control the number and size of blocks kept in RAM respectively. This satisfies truncation attack-resistance (R7) and power-loss resilience (R9), in addition to R3, by limiting the number of new blocks kept in memory (for sufficiently small values of c and m).

In past work, log retrieval is proposed using TLS [START_REF] Nguyen | Cloud-Based Secure Logger for Medical Devices[END_REF], or one-way remote attestation for authenticating the platform of the remote verifier [START_REF] Karande | SGX-Log: Securing System Logs With SGX[END_REF]. (Many remote attestation protocols, e.g. [START_REF] Brickell | Enhanced Privacy ID from Bilinear Pairing for Hardware Authentication and Attestation[END_REF], typically enable secure channels to be bootstrapped, over which unsealed logs can be transmitted securely). However, the remote authority, which may itself process logs in its own TEE [START_REF] Nguyen | Cloud-Based Secure Logger for Medical Devices[END_REF][START_REF] Karande | SGX-Log: Securing System Logs With SGX[END_REF], is likely to request reciprocal trust assurances from the source TEE, i.e. remote attestation for both the source and verifying entities. Rather than performing one-way attestation separately for both entities, one alternative is mutual TEE attestation [START_REF] Shepherd | Establishing Mutually Trusted Channels for Remote Sensing Devices with Trusted Execution Environments[END_REF] in which both communicating TEEs are attested and authenticated within the protocol run. Similarly, a secure channel can be bootstrapped from [START_REF] Shepherd | Establishing Mutually Trusted Channels for Remote Sensing Devices with Trusted Execution Environments[END_REF] between the TEE end-points over which unsealed logs can be transmitted securely without exposing them to untrusted world elements.

Implementation

We implemented EmLog using OP-TEE -an open-souce, GlobalPlatform compliant TEE by Linaro [START_REF] Linaro | OP-TEE: Open Portable Trusted Execution Environment[END_REF] -with Debian (Linux) as the untrusted world OS.

An untrusted world application was developed for collecting log entries from file, which were sent subsequently to the EmLog TA using the GP Client API [9]. Each entry was processed into a data structure comprising a 4-byte message ID, 32-byte HMAC (SHA-256) tag, and 256-byte field for the entry text. The GP Internal API [10] was used to interface with the cryptographic and secure storage methods; in OP-TEE, cryptographic methods are implemented using the LibTomCrypt library, and we opted for secure storage in which data is encrypted to the untrusted world file system (residing on 32GB eMMC flash memory). 256-bit ECDSA (NIST secp256r1 curve) was used to sign each block, which was placed into a separate data structure comprising the processed messages and a 4-byte block ID; currently, only the NIST curves are defined in the GP TEE specifications. The GP Internal API defines its own memory allocation functions, i.e. TEE Malloc and TEE Free, for dynamically (de-)allocating memory to regions accessible only to the TA, which were used frequently for memorymanaging blocks and messages at run-time.

Unsurprisingly, memory consumption quickly became problematic when working with large datasets (discussed in Section 7). For the current OP-TEE release, 32MB RAM is allocated for the TEE kernel and all resident TAs, with the rest allocated to the untrusted world OS. For a standard TA, the Linaro Working Group6 stipulates a default stack and heap size at 1kB (stack) and 32kB (data) respectively, both of which can be increased up to a maximum 1MB per TA.

Evaluation

EmLog was evaluated using a HiKey LeMaker -an ARM development board with a Huawei HiSilicon Kirin 620 SoC with 2GB RAM and an ARM Cortex A53 CPU (eight-cores at 1.2 GHz with TrustZone extensions). Such specifications are typical of modern medium-to-high end IoT-type systems, such as the Raspberry Pi 3 and Nest Thermostat. The proposal was benchmarked using three log file datasets, described briefly: The results are shown in Tables 1 to 4 and Figure 4. Table 1 shows the mean CPU time to derive 256-bit IKs, block and message keys from a pre-generated RLK using HKDF. These were measured over 1,000 iterations within the EmLog TA using the GlobalPlatform TEE Time method for system time, implemented using the ARM Cortex CNTFRQ (CPU frequency) and CNTPCT (count) timing registers. Table 1 shows the mean time for sealing and unsealing IKs and blocks (for m = 100, averaged across all entries) via the GP Internal API. Table 2 lists the mean 256-bit ECDSA and HMAC-SHA256 times computed across all entries, while Table 3 shows the mean creation and verification times of message blocks for each dataset (for varying values of m, the number of entries per block), as well as block groups. In this context, verification encompasses the time to reconstruct the hash matrix in Figure 3 and to verify the block signatures and message HMACs. Group creation and verification time was measured for varying values of c (blocks per group), which included the time for sealing and unsealing blocks to secure storage respectively. Table 4 shows the mean persistent memory consumption of logs in secure storage, which was measured directly from /data/tee in the untrusted world file system, where OP-TEE stores sealed TA files. Lastly, Figure 4 shows the relative performance of secure storage, key derivation and block and group creation/verification times from Table 1.

Discussion

Little to our surprise, block generation and verification time scales linearly with message length, which, for large values of m, is influenced heavily by the key 2). Figure 4 indicates that the relative timing overhead is ∼80-100% for every 100 message increase in the block length. Group creation and verification times rise significantly with the number of blocks, c, kept in RAM before secure storage. This is driven significantly by the secure storage overhead, which is measured at approximately 115.8ms and 94.88ms for sealing and unsealing respectively (Table 1). Despite this, however, even the largest group sizes, c = 25 and c = 50 (2,500 and 5,000 entries in total), completed between 4.0 to 9.3 seconds, corresponding to a throughput of approximately 538 and 625 logs per second. At first, it seems attractive to maximise c to avoid the expense of secure storage operations, which caused the throughput to drop to ∼430 and 525 entries for the smallest groups (c = 1 and c = 10 blocks). Maintaining many blocks in RAM, however, increases the impact of a power-loss; systems that log infrequently may see significant data loss if large numbers of logs spread over a large period of time are lost. Consequently, c should be set based on the expected log and transmission frequencies.

For memory consumption, all experiments were conducted within the Linaro Working Group's run-time recommendations (1MB stack and heap), except for c = 50 blocks (5,000 entries), which required 2MB of each. Expectedly, persistent memory consumption of block secure storage (Figure 4) scales linearly with message size. Our test-bed uses a fixed 256-byte text field for each log entry, which accounts for the broadly similar performance across all datasets. We also calculated the persistent memory consumption compared with the mean size of raw logs; the relative consumption is large for small block sizes (m < 250), due likely to the fixed-size meta-data used by OP-TEE to manage cross-TA secure storage objects. For larger block sizes, this converges to slightly under five-times overhead versus raw logs; the absolute size of smaller block sizes remains low, however, at 16-155 kilobytes, according to Table 4.

Requirements Comparison

We compare the features of EmLog's with previous work in Table 5 using the requirements in Section 4. Notably, the use of ARM TrustZone and the Glob-alPlatform TEE makes it appropriate for mobile and embedded devices targeted in this work (R10), unlike SGX-based schemes, which are restricted to Intel CPUs associated with laptop, desktop and server machines. EmLog satisfies the features of related cryptographic and trust-based proposals, such as resistance to truncation (R7) and re-ordering (R8) attacks, and public verifiability of log origin (R6). We also offer forward integrity protection for compromised block keys (R2) using more sophisticated key derivation, thus moving the cost-reward ratio further away from an attacker. By avoiding TPMs, however, we relinquish strong hardware tamper-resistance, and we urge caution of our work in highsecurity domains, e.g. military and governmental use, where complex hardware and side-channel attacks are reasonable threats. ------Bellare and Yee [START_REF] Bellare | Forward Integrity for Secure Audit Logs[END_REF] ------FssAgg [START_REF] Ma | A New Approach to Secure Logging[END_REF] ------Logcrypt [START_REF] Holt | Logcrypt: Forward Security and Public Verification for Secure Audit Logs[END_REF] ------LogFAS [START_REF] Yavuz | Efficient, Compromise-Resilient and Append-Only Cryptographic Schemes for Secure Audit Logging[END_REF] ------

Trusted Logging

Chong et al. [START_REF] Chong | Secure Audit Logging with Tamper-Resistant Hardware[END_REF] Java iButton Sinha et al. [START_REF] Sinha | Continuous Tamper-proof Logging Using TPM 2.0[END_REF] ¶ TPM Böck et al. [START_REF] Böck | Towards More Trustable Log Files for Digital Forensics by Means of Trusted Computing[END_REF] ¶ TPM & AMD SVM Nguyen et al. [START_REF] Nguyen | Cloud-Based Secure Logger for Medical Devices[END_REF] ¶ ¶ Intel SGX SGX-Log [START_REF] Karande | SGX-Log: Securing System Logs With SGX[END_REF] ¶ ¶ Intel SGX

EmLog

GlobalPlatform TEE -Satisfies requirement; -Does not satisfy; ¶-Partially satisfies; (-) -N/A.

Conclusion

In this paper, we introduced EmLog -a tamper-resistant logging scheme for modern constrained device using the GlobalPlatform TEE and ARM TrustZone.

We began with a two-part review of related work in Section 2 by summarising cryptographic proposals and those reliant upon trusted hardware for tamperresistant logging. Next, the features of TEEs were assess in further detail in Section 3, before formulating the requirements and the threat model in Section 4 using past work. After this, we introduced the architectural design and proposed an improved log preservation algorithm for providing public verifiability of log origin and key exposure resilience. We described the implementation of EmLog in Section 6 and presented indicative performance results using diverse datasets in Section 7. For the first time, our work brings secure, TEE-based logging to mobile and embedded devices, and protects against strong software-based untrusted world and network adversaries. Our evaluation shows that EmLog yields fivetimes persistent storage overhead versus raw logs for applying tamper-resistance; runs within reasonable run-time memory constraints for TEE applications, as stipulated by the Linaro Working Group; and has a throughput of up to 625 logs/sec. In future work, we aim to investigate the following avenues:

-Group logging schemes for multiple devices. Expand EmLog to allow secure and efficient sharing of logs with nearby devices. This could be used in schemes that compute trust scores prior to making group decisions [START_REF] Bao | Dynamic Trust Management for Internet of Things Applications[END_REF], e.g. authenticating users via contextual data from multiple wearable devices. -Privacy-preserving log usage. At present, devices that wish to use logs will receive raw logs, which may reveal privacy-sensitive data. In future work, we aim to explore privacy-preserving methods for using logs without exposing raw entries to other devices. -TEE performance comparison. We hope to evaluate EmLog under other TEE instantiations, namely Intel SGX and other GP-compliant TEEs, such as TrustTonic's Kinibi, especially for micro-controllers on low-end IoT devices.

Fig. 1 .

 1 Fig. 1. GlobalPlatform TEE architecture.

Fig. 2 .

 2 Fig. 2. High-level TEE-based logging workflow.

Fig. 3 .

 3 Fig. 3. Proposed two-dimensional, signature-based log structure.

Fig. 4 .

 4 Fig. 4. (a), Relative block creation and verification times versus block length; (b), relative group generation and verification for varying numbers of blocks; (c), persistent memory consumption for per block secure storage; (d), relative memory consumption for group secure storage; and (e), raw key derivation and secure storage times.

1 .

 1 U.S. Securities and Exchange Commission (SEC) EDGAR: Apache logs from access statistics to SEC.gov. We use the latest dataset 7 with over a million entries (192 MB). (Mean entry length: 115.08 characters; S.D.: 5.73). 2. Mid-Atlantic Collegiate Cyber Defense Competition (CDC): IDS logs from the U.S. National CyberWatch MACCDC event, with ∼166,000 (27 MB) of Snort fast alert logs 8 . (Mean entry length: 165.27 characters; S.D.: 38.21). 3. EmLogs: Our dataset from OP-TEE OS boot, initialisation and GlobalPlatform test suite logs via the xtest command, and untrusted world logs from dmesg. Over 25,000 records (1.7MB). (Mean entry length: 94.14; S.D.: 49.33).

Table 1 .

 1 Mean key derivation and secure storage times (milliseconds; S.D. in brackets).

		Key Derivation	Secure Storage Seal Secure Storage Unseal
	IK	Block Key Message Key	IK	Block	IK	Block
	1.530 (0.067) 1.541 (0.062) 1.547 (0.088) 59.46 (3.78) 115.8 (5.36) 48.22 (2.73) 94.88 (2.80)

Table 2 .

 2 Mean HMAC and ECDSA generation and verification times (milliseconds).

		HMAC (SHA-256) ECDSA (NIST P256)
	Create	0.056 (0.020)	20.14 (1.29)
	Verify	0.059 (0.014)	20.77 (1.33)

Table 3 .

 3 Mean block and group generation and verification times (milliseconds).

			Block				Group (fixed at m = 100)
	Dataset (m =)10	100	250	500	(c =)1	10	25	50*
	(1)	Create 40.14 (2.1) 70.45 (2.2) 115.6 (2.6) 198.7 (3.6) 229.4 (6.4) 1898 (30.2) 4622 (48.1) 9101 (80.2) Verify 41.18 (1.5) 71.88 (1.7) 114.8 (1.9) 204.3 (2.1) 213.4 (5.7) 1634 (23.7) 3967 (50.0) 8302 (78.3)
	(2)	Create 39.84 (1.9) 68.34 (1.7) 117.2 (1.7) 202.3 (2.0) 231.7 (7.3) 1910 (28.1) 4687 (64.0) 9323 (81.5) Verify 40.05 (1.6) 66.15 (1.8) 119.9 (1.8) 199.0 (2.0) 215.2 (6.1) 1658 (23.8) 4046 (47.3) 8165 (73.9)
	(3)	Create 42.14 (3.0) 69.07 (2.1) 118.6 (2.3) 201.9 (3.2) 230.0 (6.9) 1890 (27.0) 4621 (42.8) 9274 (79.0) Verify 40.01 (1.6) 69.28 (1.8) 120.4 (1.8) 200.4 (1.9) 217.3 (6.4) 1656 (25.2) 4132 (48.1) 8188 (75.5)
		* Heap size set to 2MB to accommodate all data. All other experiments recorded
		with the maximum recommendation of 1MB.

Table 4 .

 4 Persistent memory consumption for per block secure storage (kilobytes).

	Block

Sizes (m =)10 50 100 250 500 750 1000 2500 16.38 40.96 73.73 155.65 307.20 454.66 606.21 1495.04 derivation operations (approximately 1.5ms per message, shown in Table 1). At smaller values, e.g. m = 10, this is dominated mostly by the ECDSA overhead (∼20ms, as per Table

Table 5 .

 5 Security requirements comparison of related work.

	R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 Root of Trust
	Untrusted World Schemes
	Schneier and Kelsey [27]

https://source.android.com/security/authentication/fingerprint-hal

http://developer.samsung.com/tech-insights/pay/device-side-security

https://www.raspberrypi.org/products/

https://nest.com

Note that, in general, arbitrary log deletion is difficult to prevent robustly without dedicated WORM (Write-Once, Read-Many) storage.

https://wiki.linaro.org/WorkingGroups/Security/OP-TEE

http://www.sec.gov/dera/data/Public-EDGAR-log-file-data/2016/Qtr2/log20160630.zip

http://www.secrepo.com/maccdc2012/maccdc2012 fast alert.7z

Acknowledgements

Carlton Shepherd is supported by the EPSRC and the British government as part of the Centre for Doctoral Training in Cyber Security at Royal Holloway, University of London (EP/K035584/1). The authors would also like to thank the anonymous reviewers for their valuable comments and suggestions.