First responders, search-and-rescue teams, and military personnel often work in "tactical edge" environments defined by limited computing resources, rapidly changing mission requirements, high levels of stress, and limited connectivity. In these tactical edge environments, software applications that enable tasks such as face recognition, language translation, decision support, and mission planning and execution are critical due to computing and battery limitations on mobile devices. Our work on tactical cloudlets addresses some of these challenges by providing a forward-deployed platform for computation offload and data staging (see previous posts).

When establishing communication between two nodes--such as a mobile device and a tactical cloudlet in the field--identification, authentication, and authorization provide the information and assurances necessary for the nodes to trust each other (i.e., mutual trust). A common solution for establishing trust is to create and share credentials in advance and then use an online trusted authority to validate the credentials of the nodes. The tactical environments in which first responders, search-and-rescue, and military personnel operate, however, do not consistently provide access to that online authority or certificate repository because they are disconnected, intermittent, limited (DIL). This blog post, excerpted from the recently published IEEE paper Establishing Trusted Identities in Disconnected Edge Environments--I coauthored this paper with Sebastián Echeverría, Dan Klinedinst, Keegan Williams--presents a solution for establishing trusted identities in disconnected environments based on secure key generation and exchange in the field, as well as an evaluation and implementation of the solution.

Identification, Authentication, and Authorization

In the context of tactical cloudlets, our latest work focused on developing a trusted identity solution that meets four major requirements:

• The solution cannot require network connectivity to a third party (such as the Internet), an enterprise or wide-area network, or a certificate authority (CA). In a DIL environment, these connections may be unreliable, non-existent, or even undesirable. The solution therefore cannot use certain technologies, such as a central authentication service or Internet-based identity management.
• The solution cannot place any specific security requirements on hardware, such as a Trusted Platform Module (TPM) processor. Multi-organization groups often come together to support missions and must be able to join the group without specially-provisioned hardware.
• The solution cannot require pre-provisioning of credentials on mobile devices. Although cloudlets themselves can be pre-provisioned for a specific mission or deployment, end devices must be able to join during the mission in a contested environment.
• The solution must address the threats of a tactical environment. The main difference with other threat models is that there will likely be an adversary in physical proximity to the system. The solution must therefore consider loss or theft of the mobile devices, proximity to short-range radios, and the ability of an adversary to control or contest any network connection to the Internet or enterprise network.

Our work focused on creating a solution for establishing trusted identities in disconnected environments based on secure key generation and exchange in the field that meets the above requirements. For the implementation and evaluation of the solution, we use our open source tactical cloudlets system that is targeted at supporting disconnected operations.

A Trusted Identity Solution

Establishing trust in a disconnected environment (i.e., disconnected from the enterprise) requires decentralized security solutions and infrastructure that are challenging to implement due to basic security concerns, such as how to exchange keys, how to manage keys, how to integrate with existing applications, and how to configure security policies. We first explored several solutions for decentralized security with a focus on their applicability to disconnected environments. In particular, we focused on mobile clients interacting with servers deployed in the field:

• Hardware-based solutions require the process of an onboard secure hardware component that stores security credentials.
• Software-based solutions rely on credentials stored in software components of a system, such as certificate stores, configuration files, and databases.
• Hybrid solutions have a software and a hardware component. For example, layered trust models have a software layer built on top of a hardware layer. Such a hybrid solution might use smart cards as secure containers for digital certificates and a software public key infrastructure (PKI)-based trust model built on top. Hybrid solutions, however, can inherit both advantages and disadvantages of software-based and hardware-based solutions.
• Human-centric solutions, as the name indicates, involve humans for establishing trust. Examples of human-centric solutions that could be applicable to disconnected environments include social networks and biometrics and behaviometrics.

The solution that we devised is presented in Figure 1 and is based on the design presented in a 2015 IEEE paper on cyber foraging that I co-authored. In this latest implementation, a tactical cloudlet is composed of a cloudlet host computer that acts as a server. This server is connected via ethernet to a WiFi access point that provides wireless access to clients and to the cloudlet's services, and uses RADIUS for WiFi authentication. These two components define a cloudlet unit. A cloudlet client is a mobile device with WiFi capabilities. Both the cloudlet host and the cloudlet client also have Bluetooth and/or USB capabilities (which will be used for pairing).

The developed solution follows the identity based cryptography (IBC) methodology while using secure key agreement to facilitate logistical requirements of disconnected environments. Our implementation depends on the Stanford Identity Based Encryption (IBE) Library, which uses the Boneh Franklin scheme as a key encapsulation mechanism (KEM) and off-the-shelf (OpenSSL) ciphers and HMACs for the actual encryption. Identity-based short signatures are used for the WiFi authentication process.

The selected secure key agreement without a trusted third party ceremony takes advantage of deployments in disconnected environments; specifically, the presupposition of physical proximity. The proposed solution requires a participant's physical proximity to the private key generator (PKG) (i.e., cloudlet) for the initial identification and authentication. The cloudlet admin trusts the device user, so it can also trust a device carried by the device user. Physical proximity can then be used to establish trust between the device and the cloudlet with the help of the users.

We decomposed our solution to establish trust into four subprocesses: bootstrapping, pairing, WiFi authentication, and API requests. The first two processes perform the actual trust establishment; the other two are used to authenticate a paired device requesting access at the WiFi and network level respectively. In addition, we identified two ways to revoke device credentials: automatic and manual.

1) Bootstrapping

The bootstrapping process establishes the encryption and identity parameters on the cloudlet. Every cloudlet deployment starts from a clean state, which is why the first step of the process deletes any existing server credentials.

2) Pairing

Pairing is the process of identifying a client device to the cloudlet, authorizing it to access that cloudlet, and transferring the required credentials. A mobile device user would begin by presenting their device to the cloudlet admin. The cloudlet admin would decide if the user is authorized to use the cloudlet based on physical credentials and characteristics (e.g., photo ID, uniforms and insignia, personal knowledge, or delegation of trust). If approved, the cloudlet admin would log in to the cloudlet and the mobile user would connect the candidate mobile device to the cloudlet via USB or Bluetooth.

3) WiFi Authentication Process

The cloudlets provide all of their services over WiFi using standard 802.1X authentication. Clients connect to a cloudlet's WiFi access point (AP) and request access to the network. The AP provides the RADIUS Server Certificate and the client verifies its own copy of the RADIUS Server Certificate, which it obtained via pairing. '

4) API Request Process

Services on a cloudlet are provided by a simple HTTP request/response protocol. To secure the requests, the client can decide to use any of the cryptographic elements generated in the previous phases, or can generate and share a new secret key. If a new secret key is generated, it must be replaced as the password for that device in the list of paired devices on the server. Each request/response pair is encrypted and decrypted using the agreed-upon secret key/password.

Automatic and Manual Device Credential Revocation

To address elements of the threat model, our solution includes two ways of revoking device credentials, therefore terminating the connection between the cloudlet and the mobile device.

• Automatic, due to deployment timeout. The last step of the bootstrapping process mentioned earlier establishes a deployment duration. The cloudlet will automatically disable all device credentials at the end of the configured duration. As a result, the cloudlet will no longer accept pairing or API requests from any device until a new deployment is configured.
• Manual, due to known loss or compromise. To address elements of the threat model, our solution requires a way to manually revoke device credentials if a device is known to have been lost or stolen. Once credentials are revoked, the device is removed from the list of paired devices, and the cloudlet will no longer accept API requests from that device.

Threat Modeling, Vulnerability, and Ceremony Analysis

We first evaluated our solution against a threat model for disconnected environments that we used to develop the trusted identity solution. The context for the threat model is a client/server type of system in which the client is a mobile device and the server is providing capabilities to mobile devices. The server is fully disconnected from the network and provides capabilities to proximate mobile devices connected via WiFi. We developed our threat model using Microsoft's SDL Threat Modeling Tool, which generated 60 potential threats, and consolidated them into the 14 relevant threats as detailed in our paper along with accompanying mitigations.

The solution that we developed fully addressed 5 of the 14 threats identified above. It also partially addressed one of the threats due to an explicit tradeoff. Of the 14 threats described above, 6 are addressed outside of the solution, which we addressed through ceremony analysis, described below. Two threats are not addressed by the solution, but we provide potential mitigations that we did not implement in our paper.

We also evaluated our trusted identities solution by performing architectural and technical analysis of possible vulnerabilities based on the threat model. Given the set of threats that we identified, we created a simple attack tree. The goal for an attacker would be to gain access to the data being shared between clients and the cloudlet. We identified four possible paths to access to that data, only two of which are relevant when considering the trusted identity solution:

• Remote Network (Internet) Access. This is not relevant because the clients and cloudlet are expected to operate in a disconnected environment.
• Physical Server Access (including via a USB port). We exclude this threat because physical security controls in a disconnected environment are outside the scope of the identity solution, i.e., physical attacks on the cloudlet would bypass the identity solution credentials.
• Local Network Access. This threat includes Bluetooth or WiFi from an unauthorized device.
• Physical Device Access (Compromised Authorized Device). We include physical security of the mobile device because it is much more prone to loss or theft than the cloudlet, which would result in a compromise of the identity solutions.

As described in our paper, we also conducted ceremony analysis, which extends the concept of network protocol by including human beings as nodes in the network. Ceremonies include all protocols, applications with a user interface, and security provisioning workflows. In essence, there is nothing out-of-band in a ceremony. Security analysis of a node in a ceremony is the same for both human and computer nodes: With what will an attacker be able to fool the node into making an incorrect decision?

As our threat model analysis demonstrates, there are multiple threats in the threat model that are addressed outside of the implementation. In essence, there are assumptions that are made by the solution and left open for arbitrary people to satisfy in arbitrary ways. In addition, the pairing process requires an out-of-band channel (physical proximity plus visual confirmation). These are all elements that benefit from a ceremony analysis to provide guidance on how to validate or enforce all elements of the end-to-end solution.

Ceremony nodes in the exchange of credentials between a cloudlet and a mobile device are shown in the figure below. The human nodes are the following:

• Mobile user. Owner and user of the mobile device.
• Cloudlet admin. User responsible for operating a cloudlet in the field.
• Cloudlet provider. User responsible for setting up a cloudlet for use in the field. The cloudlet provider physically hands over a cloudlet to a cloudlet admin.

With the exception of the device ID and device credentials exchange shown in the figure above, all other exchanges between nodes in the ceremony are considered out-of-band for the trusted identities solution. The ceremony analysis therefore demonstrates the need to provide assurances for all other exchanges.

Wrapping Up and Looking Ahead

The paper presented a trusted identity solution for disconnected environments that combines identity-based cryptography (IBC) with mechanisms for secure key exchange without a trusted third party. The solution was developed based on a threat model for disconnected environments and implemented in our open-source tactical cloudlets project targeted at deployment in these types of environments. Evaluation of the implementation was done against the threat model and using vulnerability analysis.

The evaluation and implementation of our trusted identity solution shows a resilient solution that addresses most of the threats and characteristics of disconnected environments if combined with proper application-, OS-, network- and site-level controls. The ceremony analysis that we conducted provided guidance on threats that are addressed outside of the trusted identity solution. Even though the solution was implemented in the context of a client/server tactical cloudlets system, we believe the solution could be applied to any form of trusted communication between two or more computing nodes.

Our current work is expanding the threat model to connected cloudlets for VM migration. Future work will focus on expanding the threat model to include Internet-of-Things (IoT) devices connected to cloudlets for data staging.

We welcome your feedback on our work in the comments section below.

Additional Resources

Read the paper that I coauthored with Dan Klinedinst, Establishing Trusted Identities in Disconnected Edge Environments.

The implementation of the tactical cloudlets system that includes the developed trusted identity solution is available at https://github.com/SEI-TAS/pycloud/wiki.