Smart and Secure Cross-Device Apps for the Internet of Advanced Things

Abstract

Today, cross-device communication and intelligent resource sharing among smart devices is limited and inflexible: Typically devices cooperate using fixed interfaces provided by custom-built applications, which users need to install manually. This is tedious, time consuming, bears security and privacy risks, and contrasts the idea of Internet of Things (IoT) where intelligent devices operate in concert to enrich the overall user experience by sharing resources and capabilities.

We present Xapp, a context-aware service mobility framework for Android. Our goal is to enable users to securely distribute the functionality of applications to mutually untrusted smart devices, e.g., to enable a smartphone to use a nearby Android TV screen as a display for a video call, let a smartphone navigation app direct an autonomous vehicle, or let it use the vehicle for an object-recognition task rather than using a cloud service with the attendant privacy risks. We built a prototype for Android as the first step towards this goal. Our system is a set of extensions to the existing Remote-OSGi service platform, an emerging industry standard which unfortunately does not secure the communications between devices. This paper describes our proposal for the required security architecture. We designed and implemented an authentication protocol suite, where trust is bootstrapped using NFC for the sake of usability. On top of this we built a fine-grained access control system so that mutually mistrustful Xapp apps can be used simultaneously in the same neighborhood and even on the same devices. Hence, with Xapp users can run an Android app across multiple devices without having to install it on each of them individually. As proof of concept we present the implementation and evaluation of a video call app.

A Protocols

As explained in Sect. 3.3, the protocols assume a shared symmetric secret key between $\mathcal {M}$ and $\mathcal {H}$, denoted $K_\mathcal {M} \in \{0,1\}^n$, which is used to authenticate and encrypt tokens with the help of an authenticated encryption scheme AE = (AEnc, ADec), where n is a security parameter.

Fig. 5.

Token Issuing Protocol (TI) and Secure Channel Establishment Protocol (SCE)

Token Issuing Protocol. The Token Issuing Protocol (TI) is shown in Fig. 5(a). Both $\mathcal {M}$ and $\mathcal {C}$ generate a new asymmetric key pair. $\mathcal {C}$ sends its public key $pk_\mathcal {C}$ to $\mathcal {M}$ over an out-of-band channel. Generally we require that this channel is integrity-protected at least in one direction ($\mathcal {C}$ to $\mathcal {M}$), so that it is immune to man-in-the-middle attacks where an attacker attempts to replace $pk_\mathcal {C}$ with a different public key. We use Near-Field Communication (NFC), which directly allows $\mathcal {M}$ to verify the identity of $\mathcal {C}$ due to the physical proximity required for NFC. However, alternative implementations are also feasible, for example using QR codes. $\mathcal {M}$ creates a new Token $[T_\mathcal {L}]$, which contains the client key $K_\mathcal {C}$, as well as a description of $\mathcal {C}$ ’s privileges on $\mathcal {H}$, denoted by the Policy $P_{\mathcal {C,H}}$. $K_\mathcal {C}$ is derived using a key agreement scheme DH (e.g., Diffie-Hellmann [15]) between $\mathcal {C}$ and $\mathcal {M}$. Finally, $\mathcal {M}$ sends the token to $\mathcal {C}$ together with its public key $pk_\mathcal {M}$.

Secure Channel Establishment. The client $\mathcal {C}$ uses the Secure Channel Establishment Protocol (SCE) to connect to the Loader $\mathcal {L}$ as shown in Fig. 5(b): $\mathcal {C}$ sends $[T_\mathcal {L}]$ and a randomly chosen nonce $N_\mathcal {C}$ to $\mathcal {L}$. $\mathcal {L}$ decrypts $[T_\mathcal {L}]$ using $K_\mathcal {M}$, thereby verifying its integrity due to the authenticated encryption. Next, $\mathcal {L}$ extracts $K_\mathcal {C}$ and the Policy $P_{\mathcal {C,H}}$, which is forwarded to the Resource Controller RC. $\mathcal {L}$ stores $K_\mathcal {C}$ securely in a database and later provides a decryption service to instances of $\mathcal {C}$, so that $K_\mathcal {C}$ cannot be exfiltrated by modules in $I_{\mathcal {C}}$. Then, $\mathcal {L}$ generates a random nonce $N_\mathcal {L}$, which it sends back to $\mathcal {C}$. Finally, both sides compute a shared secret session key $K_\mathcal {S} = \mathsf KDF (K_\mathcal {C} \; || \; N_\mathcal {L} \; || \; N_\mathcal {C})$ using a suitable key derivation function KDF [12]. In our implementation we use an HMAC/SHA1-based key derivation function. After this step, the secure channel establishment is completed and $K_\mathcal {S}$ will be used to protect all further communication.

$\mathcal {C}$ also uses SCE to connect to $I_{\mathcal {C}}$. Therefore $\mathcal {C}$ creates a new token $[T_{I_{\mathcal {C}}}]$ with a randomly chosen key $K_I$. Since no policy is established between the client and the host it attaches an empty dummy policy and encrypts the complete token $[T_{I_{\mathcal {C}}}]$ with $K_\mathcal {C}$. On the client side, $I_{\mathcal {C}}$ decrypts $[T_{I_{\mathcal {C}}}]$ using the decryption service provided by $\mathcal {L}$.