Secure Communication in Disasters

This paper reports on the challenge of designing an application for bootstrapping secure communications in ad-hoc situations. The starting point of this work was based on prior work in “spontaneous security”: making use of Human-Interactive Security Protocols (HISPs) which exploit a human-based unspoofable channel to bootstrap secure comunications. Our approach was to develop a realistic scenario in which spontaneous and secure communications are necessary, and to use this to drive the development of the application. We settled on exploring how to provide secure communications in disasters: situations where existing communication and security infrastructures may be unavailable. Using the disaster scenario to guide development, we implemented a mobile application which allows users to create ad-hoc WiFi networks and bootstrap secure communications over these networks.


INTRODUCTION
Current security architectures are often rigid and unable to support situations where requirements are hard to identify upfront, or situations where flexibility is essential.Much of the domain of computer security is based on networks of shared secrets, or relies on certification structures and public key cryptography.It is notoriously difficult to make such structures dynamic, not least because the decisions about how parties are accredited and connections made are fixed by the designers of systems rather than those using them.Likewise, infrastructures like PKIs bind names to public keys, curtailing the possibility of naming flexibility.In response to these shortcomings, efforts have been made over the past 10 years to develop spontaneous security ; one key aspect of this research has been the development of Human-Interactive Security Protocols (HISPs).
HISPs are protocols for authenticating systems and exchanging encryption keys based on the comparison of short strings over an empirical channel : an unspoofable human-based communication channel (Roscoe and Nguyen 2006).These protocols use a combination of digital communication channels and the empirical channel to bootstrap secure communications using knowledge that a human can only have gained via direct interaction with the system.The security of these protocols has been proven through formal evaluation; however, given the central role of a human agent in their correct use, the specific design and usability of their implementation is critical.
In order to design an application demonstrating the capabilities of HISPs and spontaneous security, we decided to use a realistic scenario as a means of exploring the problem domain.To represent the need for flexibility and security, we focussed on the challenges of communication in a disaster situation.
Disasters, like the Japanese tsunami of 2011, can destroy communication infrastructures as well as security infrastructures.In such events, establishing communications is a vital and time-critical jobone which cannot ignore the importance of security.Rescue operations often require cooperation among forces from different sectors, e.g.police forces, rescue teams, the military, as well as civilians.Security is necessary to guarantee the integrity, confidentiality and availability of communication channels in these operations, however it cannot be specified upfront.It is for these reasons that we decided to focus on this exemplar as a means of designing our application and showcasing the possibilities offered by spontaneous security.
In the following sections, we provide a brief overview of the security protocols that we use, and present our application -discussing the role of the disaster scenario in making specific design decisions.

SPONTANEOUS SECURITY
Spontaneous security aims to support users to decide ad-hoc on what systems can communicate with each other with no need for pre-existing structures or infrastructures of encryption keys.A central means of achieving this is based on the discovery of highly efficient protocols for authenticating systems and exchanging keys, through the comparison of short strings generated by the parties involved.
A HISP allows two or more parties who trust one another, or a single party who trusts one or more others, to bootstrap a secure network using no more than an ability to communicate a small number of bits over an empirical channel.Another way of looking at them is that if the people involved create an insecure channel between their devices, and already have an unfakeable way of passing a small amount of information amongst them, then they can either turn the insecure channel into a secure one or discover the presence of an intruder who is trying to subvert it.The unfakeability of the empirical channel might arise from physical proximity (where participants can see and talk to one another), or real-time unspoofable interaction such as speaking on the phone.
The following describes the Symmetric HCBK protocol (SHCBK) (Roscoe and Nguyen 2008); a typical group HISP which can secure an arbitrarilysized group.
where hk * is the XOR of all hk A 's for A ∈ G Where −→ N represents a high bandwidth channel subject to the Dolev-Yao attack model (Dolev and Yao 1983), SHCBK has each node "publish" its name and a collection of information that it wishes to bind to that name.It also sends a hash1 of a randomly generated key hk A coupled with the name.
Once a node has received that information from all the others -and therefore become committed to the set of identities, INFO and hashed keys -it publishes its previously secret hk A .The point is that by the time of this last publication, it is committed to all the data used in the above protocol, even though it does not yet know all the hk A s.A careful security analysis of this protocol (see (Roscoe and Nguyen 2008), for example) demonstrates that any attacker is unable to profit from combinatorial analysis aimed at getting the check-strings (i.e.digests) to agree even though nodes have different views of the authenticated information.Good HISPs such as SHCBK therefore offer maximum security for a given amount of human effort.
The digest function (Roscoe andNguyen 2006, 2008) is designed so that, as hk varies, the probability that digest(hk, X) = digest(hk, Y ) for X = Y is less than , where typically is very close to the theoretically optimal value of 2 −b for b the number of bits in the output of digest.It must also have the property that for any fixed value d, the chance that digest(hk, X) = d as hk varies is less than also.More details of this protocol can be found in (Chen et al. 2012).
As an example, Alice and Bob want to create a secure connection between their mobile devices.First they connect their devices using a normal channel (e.g.Bluetooth, WiFi), and we assume this connection is initially insecure.Alice and Bob then run the protocol which generates a check-string (e.g. a sixdigit number) and exchange this value.One method of exchanging the value is for Alice to read the checkstring and Bob to type it on his own mobile device.
Another is for them to both read it, compare the one heard with the check-string displayed on their own devices, and confirm that it indeed matches.
Because Alice and Bob are in physical proximity, they can make sure that no one can fake this check-string.
The communication channel they use to exchange the check-string is an empirical channel: no one can alter the check-string and no one can fake the origin of the check-string.The check-string is then used to test the presence of the attacker.For example, if the check-string entered matches the one generated by their own devices, they can be confident that the connection has been secured; otherwise, it is likely that the connection is insecure and an attacker (e.g. a man-in-the-middle attacker) is in presence.

HISP APPLICATION
Based on the disaster scenario, we assume that people will have their own mobile devices to communicate, and have designed our application accordingly.The connection between devices uses the peer-to-peer (ad hoc) WiFi mode.This allows the creation of a communication network for situations where the existing infrastructure may be unavailable.To secure communications over this network we break down the application into three steps: group formation, running the protocol, and ongoing communication.
To simplify our discussion, an important assumption has to be made before bootstrapping security for a group: members of a group are capable of verifying the legitimacy of every other member of the group.

Group formation
Formally, bootstrapping a group can be defined as follows: all members acknowledge a list L, which contains details of all members; the resulting group G contains exactly the same number of members recorded in L and no one, except for the members included in L, can be allowed to join G.To satisfy this task, we need to identify and overcome the following challenges: collecting members' information and counting the number of members.
In GAnGs (Chen et al. 2008) the authors present two solutions for collecting group members' information when they are in the same room.The first solution is to use an untrusted projector as a central node by displaying its Bluetooth address as a 2D barcode.
All members connect their mobile phones to the projector by reading this barcode and send their details to the projector which then broadcasts the list L to the group; whilst this is fairly simple, it is not suitable for the disaster scenario.The second solution is to create a tree structure to collect members' information one by one by reading 2D barcodes of Bluetooth addresses.This can be a laborious process which involves a large amount of human effort (e.g. 30 human interactions for a group of ten members).
Our solution is tailored to WiFi, where one device (the Initiator) can broadcast2 messages include its IP address and profile.Other devices within communication range can pick up these messages and display the Initiator's profile.The user can then choose whether or not to join this group.
The second step is to count group membersverifying that the size of the group G matches the size of list L. This is to prevent an insider from creating multiple fake identities and passing the authentication step.For example, when comparing digests, an insider can compare digests multiple times and fake the presence of the identities he/she has created.
When a group is small (e.g. 3 or 4 members), counting is straightforward.However, as the size of the group grows, so does the likelihood of mistakes.For example, in a group of over 100 members, it is unreasonable to expect all members to count the whole group consistently and individually.One simple solution is to utilise "crowd-knowledge" to remove illegal members from list L. Another is to divide a large group into small groups, and create a strategy for merging the smaller groups into a larger one.
In our application, we assume that the Initiator manages the counting on behalf of others.This means that the Initiator knows how many members are in the group and he/she can remove illegal identities.

Running the protocol
Since the Initiator manages the group formation, they are also responsible for starting the HISP.When the protocol starts, devices broadcast Message One: A, INFO A , hash(A, hk A ).At this stage, each device must ensure that it has received exactly N unique copies of Message One, where N equals to the size of the group.This is critical to guarantee that all members are committed to hk A s.
A device must not process other messages until it has received all N copies of Message One.This will guarantee the failure of this stage will be detected in the digest comparison stage.
When all devices have received all Message Ones, they start to broadcast Message Two: hk A .Similar to the previous stage, all devices need to make sure they have received all N copies of Message Two.Once they have, they compute and display the digest value.
The digest comparison stage serves to check whether there is any mistake or attacker in the previous two stages of communication.To symmetrically compare digests in a group of size N (N > 2), a total number of N (N − 1)/2 two way interactions, or N (N − 1) one way interactions (for example, taking photos of 2D barcodes), have to be made.Given N = 8, there can be 28 to 56 interactions.In order to improve usability, we must reduce the number of human interactions involved in this stage.In our application, we have assumed that there is one trustworthy member who is known by the rest of the group, and all members are close to each other so they can hear each other speaking.We further assume that the trustworthy member is the Initiator.
The Initiator reads out the digest to the group members who enter this value into their own devices (manually entering the digest has already been shown to be both usable and secure (R. Kainda and Roscoe 2009)).The device then checks that the value entered matches with its own version.When this is completed, all members raise their hands to indicate that the digest comparison is successful; or speak loudly if the digest comparison has failed.The Initiator reading the digest to the rest of the group is a typical one-to-many empirical channel.Since we assume the Initiator is trustworthy, we have used this empirical channel to improve usability; if we consider the step of raising hand and checking as one single interaction, the total number of interactions is reduced to 2N .

Communication: cooperation in disasters
After the protocol is successful, we use Diffie-Hellman public keys (included in IN F O A ) to generate shared symmetric keys and then we generate a group key by using the symmetric keys.We have implemented text messaging, voice messaging and sending photos on the basis of a map function (see Figure 2).We have also augmented text and voice communication with location and photography functions to facilitate rescue operations.The location function can track a user's location on the map; the photo function is used to post notices on the map (e.g.newly hazardous areas).

FUTURE RESEARCH
We have discussed basic issues of group formation and comparison of digests.More needs to be done to explore how to establish and maintain a sufficiently large ad hoc group of devices using the connection technology available in a given scenario.For example, should a group be formed using a single initiator, a tree structure, broadcasting over a fully connected graph, or some other topology?This question can be posed both for initial network formation and for digest comparison between humans.How should we manage group amalgamation and splitting, or adding and removing single members?We have also indicated that naming is difficult in disasters, but how to manage identities remains a significant challenge in disasters.

CONCLUSION
We have discussed how we designed and implemented a secure communication application in a disaster scenario.Our implementation shows that we can optimise performance by designing and regulating the group formation and the digest comparison process.It also shows that we can easily build various communication functions on top of this security platform to facilitate rescue operations in disasters.

Figure 1 :
Figure 1: Screen shots (left to right, top to bottom): (i) join a group; (ii) start the protocol; (iii) display the digest; (iv) enter the digest; (v) send a text message; (vi) send a voice message.

Figure 2 :
Figure 2: Devices running the secure communication application.