1 Twitter in Disaster Mode: Security Architecture Theus Hossmann, Paolo Carta, Dominik Schatzmann, Franck Legendre Communication Systems Group ETH Zurich, Switzerland ABSTRACT Recent natural disasters (earthquakes, floods, etc.) have shown that people heavily use platforms like Twitter to communicate and organize in emergencies. However, the fixed infrastructure supporting such communications may be temporarily wiped out. In such situations, the phones capabilities of infrastructure-less communication can fill in: By propagating data opportunistically (from phone to phone), tweets can still be spread, yet at the cost of delays. In this paper, we present Twimight and its network security extensions. Twimight is an open source Twitter client for Android phones featured with a disaster mode, which users enable upon losing connectivity. In the disaster mode, tweets are not sent to the Twitter server but stored on the phone, carried around as people move, and forwarded via Bluetooth when in proximity with other phones. However, switching from an online centralized application to a distributed and delay-tolerant service relying on opportunistic communication requires rethinking the security architecture. We propose security extensions to offer comparable security in the disaster mode as in the normal mode to protect Twimight from basic attacks. We also propose a simple, yet efficient, anti-spam scheme to avoid users from being flooded with spam. Finally, we present a preliminary empirical performance evaluation of Twimight. Categories and Subject Descriptors C.2.1 [Network Architecture and Design]: Wireless Communications General Terms Design, Security Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ACM SWID 2011, December 6, 2011, Tokyo, Japan. Copyright 2011 ACM /11/ $ Per Gunningberg, Christian Rohner Communication Research Group Uppsala University, Sweden 1. INTRODUCTION In recent disaster events (e.g., earthquakes, floods), online social networks (OSNs) such as Facebook and Twitter have proven to be the communication tools of choice for affected people. Not only were they heavily used for spreading news and updates across the world  but also for connecting and organizing victims  locally at the disaster site. However, these platforms were not explicitly designed for emergency situations in the first place. In fact, their value in such environments could be greatly improved by extending them with features specially designed for hostile circumstances. One drawback of today s OSNs in disaster situations is their dependance on fixed network infrastructure. If the wired and/or cellular infrastructure is wiped out by natural forces (or even just congested in the aftermath of a disaster) the client-server communication of current OSNs is not feasible. Thus, in the time until emergency response forces are able to repair infrastructure or deploy temporary communication solutions (e.g., wireless mesh networks, satellite phones) people are left without any means to communicate. To overcome this limitation, the use of delay tolerant opportunistic networks [3, 4] has been proposed. The approach we use in this paper is based on these ideas. Our goal is to augment OSN applications which the users already have installed on their mobile phones and use in their every day life with an additional feature, the disaster mode. In particular, we implement the disaster mode in Twimight 1, our open source Twitter client. We choose Twitter since it has proven to be a highly useful communication platform in past emergency situations [1, 2]. Upon losing Internet connectivity, the user can simply enable the disaster mode to start opportunistic communications [5, 6]. Tweets entered in disaster mode then are stored locally on the phone, carried around as people move, and forwarded using Bluetooth as they are in proximity with other phones. Once connectivity is regained, the user s disaster tweets are uploaded to the Twitter server. Such mobility-assisted opportunistic communication has the advantage of being ready instantly after losing connectivity. No deployment of temporary infrastructure is required, since people have everything that is need on their phones. 1 Download:
2 However, it has the disadvantage of being a purely besteffort technology and comes with potential delays in tweet delivery depending on the density of people and on their mobility. Hence, the disaster mode is mainly suited to provide a communication means to people in a first phase (during the hours or few days after a disaster happens), before emergency response gets active and reaches the disaster site. In a second phase, once rescue missions have started and specialized forces are in place, there may be better suited technologies (e.g., satellite communication) to coordinate operations. We illustrate these two phases and the respective communication needs in Figure 1. In this paper, we focus particularly on the security aspect of Twimight. Moving away from an online centralized service to a distributed and delay-tolerant service relying on opportunistic communications requires rethinking the security architecture. Since tweets are no longer exchanged directly with the Twitter servers but relayed potentially over multiple opportunistic hops, authenticity, integrity and confidentiality have to be guaranteed without accessing the server. The contributions of this paper are the following: We describe the design and prototype of Twimight, our disaster Twitter client. It behaves like a normal Twitter client but includes a disaster mode, enabling opportunistic communication where tweets spread epidemically (Section 2). We propose a security architecture to secure the dissemination of tweets in disaster mode. We introduce the Twimight Disaster Server (TDS) for managing and distributing cryptographic keys and certificates before a disaster happens, such that all components are in place once connectivity is lost. We also propose a simple, yet efficient strategy to throttle the dissemination of spam (Section 3). Finally, we validate the dependability of Twmight in disaster mode using small-scale experiments. We evaluate the performances of the opportunistic dissemination of tweets in terms of delay, hop count and impact on the battery consumption (Section 4). As a final note, we want to highlight that one of the main design goal of Twimight is simplicity. We believe that the environment and circumstances of a natural disaster differ from case to case and it is hard to predict what exact features are needed in a future situation. Hence, we do not aim at providing a highly specialized and sophisticated solution. Instead, we want to let people use the tools they know from their everyday life, modifying them as little as possible. We trust that affected people will self-organize and figure out the right usage of the tool for a particular situation. 2. TWIMIGHT ARCHITECTURE In this section we provide a brief overview of the architecture of Twimight with the main focus on the disaster mode Phase 1: Self-organization Phase 2: Response forces Transition No infrastructure Self-organization of victims Broadcast updates/news in disaster area Message to relatives/friends I m ok! Setup of temp. infrastructure Inter-operability with infrastructure Collect and aggregate data from phase 1 Temp. infrastructure is operational Emergency resp. forces in control Priority channels for authorities Figure 1: Two phases of disaster response. time and the opportunistic spreading of tweets 2. We have implemented Twimight as a disaster ready Twitter client in Java for the Android operating system. Figure 3 gives an overview of the two modes of operations, normal and disaster, which we detail next. Twimight accesses user data using OAuth and the Twitter API after the user grants access to Twimight by logging in with its Twitter credentials. Twimight in Normal mode: Twimight supports most basic Twitter functionality like showing a timeline (i.e., the most recent tweets of the followed users), sending tweets, re-tweeting and replying to and setting favorites, direct messages etc. In normal operation, Twimight queries Twitter for new tweets every 2 Minutes. The tweets obtained from the queries are cached locally in a SQLite database. Figure 2a shows the timeline in normal operation and the actions a user can take. Twimight in Disaster mode: Twimight has a checkbox in the settings menu to enable the disaster mode as shown in Figure 2b. The normal Twitter client functionalities stay the same but now rely on opportunistic communications. Upon enabling the disaster mode, the tweets of the user are internally assigned the special status of disaster tweets. They are stored locally in a separate table for opportunistic spreading and later publication to the Twitter servers whenever connectivity is detected. Compared to the normal mode of operation of Twitter, disaster tweets are sent epidemically and are thus public to everyone. Disaster tweets are highlighted in red on the user interface (Figure 2c) to mark them as important regardless of the receiver being one of the sender s followers or not. The goal is that all tweets sent during a disaster can be received and displayed to as many people as possible. In disaster mode, the device enables Bluetooth and maintains the CPU awake acquiring a wake lock to constantly listen to connection requests from other devices. Further, it scans periodically for reachable Bluetooth devices. The scanning interval has been set to 2 minutes ±U[0, 20] seconds. It represents a tradeoff between energy consumption and delay as a longer scanning interval would miss short 2 For a more detailed discussion of Twimight functionality see also .
3 (a) Normal timeline and tweed context menu. (b) Enabling disaster mode. (c) Timeline with highlighted disaster tweet. (d) Sending tweets in disaster mode. Figure 2: Twimight screenshots. connection opportunities. The interval has been randomized in order to avoid scanning collisions (i.e., two devices always scanning at the same time will never see each other). Once two phones have discovered one another, they connect to each other and exchange the new disaster tweets, thereby spreading them epidemically. We choose Bluetooth for opportunistic communication, because in spite of its limitations (cumbersome pairing, etc.), it offers an acceptable trade-off between battery lifetime and service provided. Another big benefit is that it can be used without rooting the Android devices. Adding alternative ad hoc communication methods such as WiFi Ad Hoc and WiFi-Opp  is planned for the future. From Disaster to Normal mode: As soon as connectivity to the Twitter servers is re-established, the disaster tweets sent (or re-tweeted) by the user are published to the Twitter server. Publishing only own tweets avoids duplicate publication and authorization issues. To ensure the reliable dissemination of tweets to the greater number, epidemic spreading (taking every opportunity to replicate a tweet) is mandatory at first. However, with the epidemic dissemination of tweets, not only do we potentially use a lot of network resources but victims of a disaster can also get overwhelmed with the number of received tweets that are displayed in their timeline. There are hence clear needs to scale such dissemination both at the network and human levels. In future work, we consider to limit the spreading of tweets to a given geographical range e.g., 5 km around the source. We will also introduce the new concept of humantriggered re-dissemination where users could retweet a given tweet thus extending its range further e.g., for another 5 km. This would allow important tweets to be spread further. Future work will also consider more efficient and scalable spreading schemes for private messages between users. We intend to leverage opportunistic routing protocols that avoid flooding all the network to reach the destination . Finally, we also plan to integrate resource management strategies to remove tweets as the buffers get full. 3. TWIMIGHT SECURITY EXTENSION Regular communication through the Twitter service provides both message authenticity and confidentiality. Only authenticated users can submit tweets and private messages between two users are only shown to the intended recipient. Flooding attacks are blocked at the Twitter server by throttling traffic from the same source. We propose a complementary security server to offer comparable security also in the disaster mode where devices exchange tweets among themselves and cannot rely on the online Twitter servers or a centralized security service. We implemented security features to achieve comparable security and to protect Twimight at least from basic attacks. 3.1 Assumptions and Requirements The security architecture of Twimight relies on the basic assumption that security elements (certificates, keys, etc.) can be established before a disaster happens. However, once connectivity is lost and the disaster mode is running, the protocols have to work in a completely distributed fashion. Hence, we describe here a hybrid architecture based on a centralized infrastructure (i.e., our Twitter security/disaster server and the Twitter servers) for establishing the security elements, but operating without any infrastructure during a disaster. Such a hybrid scheme simplifies the design of the architecture considerably, compared to a fully distributed security architecture. The downside is that it implies that new users cannot join the network during a disaster. We will address this latter issue in future work. In terms of threats, we assume that the attacker can communicate with peers in range via Bluetooth, i.e., she can read the messages sent to her during a contact and can send arbitrary messages. Further, she can try to attack the communication of the clients with our centralized security infrastructure. However, we assume that the attacker does not have access to the phone of benign users (i.e., we trust the normal users phones, including the operating system and other Apps running on the phone).
4 Twitter Servers Twitter Servers 2 2 Internet 3 Internet Twitter Client Ad Hoc Communication (Bluetooth) 4 5 Db 1 5 Db (a) Normal operation. (b) Disaster mode operation. Figure 3: Two modes of operation. Continuous blue lines mean normal operations. Dashed red lines refer to attempts in disaster mode, whilst continuous red lines means operations that are performed without problems in disaster mode. Based on these assumptions, we specify the following three requirements for our security architecture: 1. Authenticity of disaster tweets has to be verifiable, to prevent an attacker from lying about the sender of a message. 2. Confidentiality of direct messages between Twimight users using encryption in disaster mode such that an attacker receiving such a message for relaying cannot read its content. 3. Anti-spam scheme minimizing the impact of an attacker flooding the network with useless messages (denial of service attack). For the first two requirements, we use a Public Key Infrastructure (see Section 3.2). For the last requirement, we use a buffer and prioritization strategy which can limit the spreading of spam (see Section 3.5). 3.2 Public Key Infrastructure To support the implementation of security in Twimight, we introduce the Twimight Disaster Server (TDS). The TDS essentially serves as a Certificate Authority with three main functions: 1) Issuing certificates for public keys (thereby binding a public key to a Twitter ID), 2) distributing public keys, and 3) revoking invalid keys. Figure 4 shows an overview of the security architecture. The TDS is the only certificate authority we allow for signing public keys. We distribute the root certificate with the Twimight installation package 3. Communication with the TDS is encrypted using the HTTPS protocol to prevent eavesdropping. At the TDS, the client is identified by its Twitter user ID, which is sent (along with the other parameters of a request) by the HTTP POST method. To guarantee the authenticity of the request, the client also 3 Updating the root certificate requires an update of the application. sends the request token which it obtained in the OAuth authorization process of the client with the Twitter server. The Twitter user ID together with this token is then used by the TDS to query the Twitter server to verify the identity. The request token is cached at the TDS for the duration of its validity for authentication of further requests without querying the Twitter API each time 4. In the following, we describe the key management, from generation to revocation of certificates and their associated public/private key pairs. Key generation: Twimight creates public/private key pairs locally on the handset to avoid sending private keys over the network. Twimight checks whether a new key pair has to be generated: 1) Upon startup of the application and after logging in to Twitter, 2) Periodically after T = 7 days (the reason for this is explained below, see Key Expiration Date ). If such a check does not find a valid key pair (i.e., no key at all, no certificate or an outdated key), Twimight generates a new key pair. Key certification: After creation of the key pair, the client sends the public key to the TDS for certification. The certificate including the serial number, public key, Twitter ID and expiration date is sent back to the client. Upon reception, the client verifies the signature with the root certificate. If this check fails or no response is received from the TDS, the client starts over with generating a new key pair. It makes 3 attempts before giving up and waiting for the next key generation check to try again. Note that the option to turn on the disaster mode is greyed out in the settings until a key is successfully signed. Further, to prevent denial of service attacks, only one certificate per user per day is issued. Key storage: On the client side, the private key as well as the public key and the corresponding certificate are stored as 4 Note that this token will also allow us posting (signed) disaster tweets on behalf of a user from the TDS to Twitter. But that s not part of the security architecture.
5 Infrastructure Part Distributed Part Verification of Twitter ID & request_token Encrypted Direct Messages Disaster-Tweets + Signatures + Certificates Twimight Disaster Server Revocation List Certification HTTPS Twimight Client Key pair & Certificate Revocation List Certificates Key Generator Follower- Certificates Figure 4: Hybrid (infrastructure / distributed) security architecture. an Android shared preference to make them inaccessible to other applications on the phone. On the server side, during the key certification requested by a client, the TDS stores the public key and the corresponding certificate with its expiry date in its certificates database. Explicit Key Revocation To invalidate keys (e.g. stolen phone) the TDS maintains a revocation list. Normally, clients poll the certificate authority using the Online Certificate Status Protocol (OCSP) during key validation to check its validity. Since this online check cannot be performed by the clients during a disaster, we cannot rely on OCSP and have to cache the revocation list locally on the devices. To keep the local copy up-to-date, the Twimight application synchronizes the revocation list during normal operations after startup or periodically after one day. In case a phone gets stolen, to actually perform key revocation, the user has to (re)login (on a different device) and trigger the key revocation from the application settings. Further, we plan to implement key revocation service provided by a web application hosted on the TDS to allow revocations after a successful authentication. Key Expiration Date The revocation list contains all revoked keys that are not yet expired. Since we have to distribute the revocation list to mobile phones, we are interested in limiting its size to save bandwidth and power. Therefore, the keys signed by the TDS have a lifetime of only 14 days, which is rather short compared to typical certificate lifetimes of several years. This ensures that entries on the revocation list can be removed timely and keeps the revocation list compact. To ensure that all clients have a valid certificate during a disaster, they have to update their keys before they expire. In more detail, we propose that clients already update their key after half of its lifetime. This enforces that all Twimight users have a valid key for at least the next T = 7 days. Please note that we currently assume that after 7 days some network infrastructure (permanent or temporary) should be up again. Further, the key lifetime can easily be adjusted anytime to optimize this trade-off between the length of the revocation list and the expected disaster duration. In addition, this approach allows us to adjust the key life time for individual users. For example, we plan to distribute keys with extended lifetime to special Twimight users like official rescue teams. 3.3 Disaster Tweet Authenticity Once in disaster mode, Twimight applications are scanning for new peers to exchange disaster tweets. These disaster tweets include the message text and meta-data such as creation time and tweet ID. This data is signed (using the user s private key), the user s certificate is attached (public key) and the message is stored in the local disaster database together with the previously received tweets. See Figure 7 for the detailed format. Before transmitting, and after receiving, each peer performs the following checks to validate the tweets: 1. The creation time of a tweet must be in the past The certificate s validity is checked with the root certificate embedded in Twimight. 3. The certificate is checked for validity against the local revocation list and the expiration date is controlled. 4. The tweet signature is verified. The tweet s signature allows checking the integrity of the text and meta-data, preventing any attacker from tampering for example with the creation time. It also allows authenticating the tweet s author. In any case, if a check fails the tweet is discarded. All valid tweets are entered in the DisasterTable buffer, ordered by their creation time. 3.4 Direct Message Confidentiality Direct messages are a way of communicating privately in Twitter. To guarantee privacy even if direct messages are forwarded from device to device, they are encrypted with the public key of the receiver. Hence, we must make sure to have all relevant public keys readily available once communication breaks. Since Twitter only allows sending direct messages to the followers of a user, this is a manageable task: At startup time and periodically after one day of runtime, Twimight polls the TDS to provide the active public keys of all the followers. 5 To account for small deviations of the clocks, we allow the creation time to be at most t = 1h in the future.
6 Appr. 42m The user interface prevents sending direct messages to users for which no public key is available (i.e., if the user attempts to enter a direct message she is notified about the lack of key). The content of a direct message is encrypted using the destination s public key. The tweet and its meta-data is then signed as described above in 3.3 to provide authenticity of the sender and data integrity. The sender s certificate is appended and the message is stored in the local disaster database. For details about the packet format, see Figure 7. During peering, the direct messages are exchanged. Before transmitting, and after receiving, the peers perform the following checks: Appr. 79m The creation time of a tweet must be in the past The certificate s validity is checked with the root certificate embedded in Twimight. 3. The certificate is checked for validity against the local revocation list and the expiration date is controlled. 4. The tweet signature is verified. If one of these tests fails, the message is discarded, otherwise the message is inserted into the DisasterDMTable buffer. Further, if a node is the destination of a direct message, the message is decrypted and the user is notified. 3.5 Spam Control It is known that user behavior and in particular tweet volume of Twitter user varies broadly from few tweets a month to multiple tweets per hour. In order to prevent (too) high volume users ( spammers ) from claiming the full network resources, we propose to rely on two simple mechanisms. In a first step, we ask the users to voluntarily limit their tweeting to important news by displaying a friendly warning to the user after each 20 disaster tweets. Recall that we rely on user collaboration and self-organization in a disaster, and hence believe that simply raising user awareness is effective. As a second, more technical solution, we implement the following constraints for message exchange: 1) We limit the number of messages which are sent from one peer to the other to M tot = 500. Since the maximum size of a message is known (140 characters + meta-data of fixed length), we can drop communication if a peer wants to send us more than the allowed amount of data. 2) Out of the M tot tweets transmitted, we reserve a maximum of M self = 250 spots for our own tweets (and re-tweets). This ensures that even in presence of high volume users we can maintain at least M self M tot of the capacity for other communication. This splitting is important since we assume that users start heavily re-tweeting content that they consider important to fill the reserved capacity with useful content. This human-based filtering could be supported by filtering functions in the user interface which for example allow to display only re-tweets, or to filter out the tweets of a certain user. Figure 5: G-floor layout in the ETZ building at ETH Zurich. 4. VALIDATION As a first step towards validating and evaluating Twimight, we have carried out multiple small-scale experiments in our building at ETH Zurich focusing on the basic opportunistic functionality 6. The mobility patterns and the interactions reflect a typical office scenario. The experiments involved five people working on two floors in the ETZ building (see Figure 5), who were carrying Nexus One phones running Android during usual working hours. The longest experiment lasted 2 days and included 915 tweets. To generate a good amount of traffic we have used an automatic tweet generator. This implies that a part of the tweets were generated during the night, when users were inactive (at home). To account for these circumstance we have identified and separated them. 4.1 Delivery Delay The delivery delay is an important metric used to evaluate opportunistic network and routing protocols performance. It measures the time between creation and delivery. Figure 6a represents the delivery delay CDF of Tweets (automatic and manually generated). This illustrates that around 30% of the messages created during the day were delivered within 4 minutes. This can be attributed to the office scenario, where office mates are almost constantly connected. Interestingly, after about 2 hours, almost all messages were delivered, which shows the efficiency of the epidemic spreading. 4.2 Hop Count Another interesting parameter used to evaluate opportunistic networks is the hop count distribution. Results are shown in Figure 6b: 49% of the Tweets were delivered directly while 51% tweets were relayed over multiple hops. This 6 The experiments for evaluating the security architecture and features are under way.
7 (a) Delivery Delay CDF. (b) Hop Count. (c) Battery Consumption. Figure 6: Performances of Twimight (w/o security features). shows that Twimight provides a reliable multi-hop dissemination service. 4.3 Power consumption Since mobile devices are constrained on battery power (especially in a disaster where the power infrastructure may be damaged), a critical parameter for Twimight is energy efficiency. Hence, we evaluated the power consumption of different Bluetooth scanning intervals (1, 2 and 4 minutes) as well as WLAN ad hoc communication, by sampling the battery level periodically. To limit the impact of external influences on the outcome, we ensured that no phone calls or text messages were sent or received during the experiment (even though the phones were connected to the GSM network). The display was only turned on a few times during the measurement. In Figure 6c we present the battery level over time for a single measurement. We observe that the highest energy consumption is caused WiFi Ad Hoc communication. In this case, the battery lasted only for 16 hours. Better results were achieved with using Bluetooth. Clearly, the scanning interval affects the uptime strongly. A scanning interval of 1 minute resulted in an uptime of 41 hours. Increasing the interval to 2 minutes extends the lifetime significantly by a factor of almost 1.5 to 58 hours. Further increase of the scanning interval to 4 minutes results in 68 hours uptime. Based on these results, we have chosen a scanning interval of 2 minutes a good trade-off in terms of battery lifetime and missing short forwarding opportunities. 5. RELATED WORK Public key cryptography is a widely used convention to uniquely authenticate different entities based on certificates issued by a trusted Certificate Authority (CA) or CA hierarchy. In an opportunistic or ad hoc network, the CA duty can be handed over to nodes which have to sign certificates of others once secure pairing is performed. The crucial part then comprises the dissemination of the certificates in a distributed way in order for nodes to build user-based certificate chains. In  and , every entity generates its own self-created credentials, lets it be signed by other entities and distributes it to nodes it encounters. While in  nodes can build certificate chains similar to PGP , in  the signature process is only allowed through secure pairing or over a common friend. The problem with both approaches is the fact that certificate chains may break in opportunistic networks and conscious signing may lead to problems when meeting complete strangers of which no prior information, connection or other reason to trust is available. In this paper, we considered a hybrid approach where we assumed users can access the PKI infrastructure (our Twimight Disaster server) before a disaster occurs. This simplifies greatly the management of certificates. Temporary deployments of wireless mesh networks  have been proposed for disaster relief. However, the nodes for building a wireless mesh networks have to be distributed first and then deployed. This requires access of an emergency response team to the disaster area. We can imagine that such an operation, even if the emergency response forces are well equipped and trained, takes at least a few hours (in case of difficult terrain maybe even days) to execute. Also, it is difficult to get a complete coverage without careful planning. Hence, during these first hours after a disaster the most critical time in which many lives can be saved people are left on their own, without any means of communication to organize themselves. Using satellite communications, suffers from the same setup time since satellite phones are not usually readily available to regular people in disasters. 6. CONCLUSIONS In this paper, we presented Twimight, a Twitter application for Android phones relying on opportunistic communications to spread tweets in an epidemic fashion in disaster situations. Moving away from a online centralized service to a distributed and delay-tolerant service relying on oppor-
8 tunistic communications required extending the security architecture of Twitter for Twimight. We proposed security extensions to allow (i) tweets being relayed over opportunistic hops in a secure fashion (integrity, authentication), (ii) the confidentiality of direct tweet messages, and (iii) a simple anti-spam scheme avoiding misbehaving users to flood the network with less important tweets. Acknowledgment This work was partially funded by the European Commission under the SCAMPI (FP ) FIRE Project. 7. REFERENCES  A. Chowdhury, Global pulse,  A. Bruns, Tracking crises on twitter: Analysing #qldfloods and #eqnz. Presented at the Emergency Media and Public Affairs Conference, Canberra,  A. Vahdat and D. Becker, Epidemic routing for partially-connected ad hoc networks, Tech. Rep.,  W. Zhao, M. Ammar, and E. Zegura, A message ferrying approach for data delivery in sparse mobile ad hoc networks, in ACM MobiHoc,  E. Nordström, P. Gunningberg, and C. Rohner, A search-based network architecture for content-oriented and opportunistic communication, Uppsala University Technical Report , 2009,  PodNet Project. [Online]. Available:  T. Hossmann, F. Legendre, P. Carta, P. Gunningberg, and C. Rohner, Twitter in disaster mode: Opportunistic communication and distribution of sensor data in emergencies, in ExtremeCom,  S. Trifunovic, B. Distl, D. Schatzmann, and F. Legendre, Wifi-opp: Ad-hoc-less opportunistic networking, in ACM CHANTS,  T. Hossmann, T. Spyropoulos, and F. Legendre, Know thy neighbor: Towards optimal mapping of contacts to social graphs for DTN routing, in IEEE Infocom,  J. P. H. S. Capkun, L. Buttyan, Self-organized public-key management for mobile ad-hoc networks, in IEEE Transactions on Mobile Computing,  L. B. S. Capkun, J. P. Hubaux, Mobility helps peer-to-peer security, in IEEE Transactions on Mobile Computing,  P. R. Zimmermann, The Official PGP User s Guide, MIT press,  R. Bruno, M. Conti, and E. Gregori, Mesh networks: commodity multihop ad hoc networks, Communications Magazine, IEEE, APPENDIX - Twimight Packet Format Data Packet: TID Type MID Creation Time CC flag Creation Time UID Text RT Pub Hop Public Signature flag flag count key Time DID Tweets Direct Messages Text SName RName Pub Public Signature flag key Figure 7: Data packet format. Bold fields are encrypted in Direct Messages respectively signed in Tweets. Disaster Tweets: The format of disaster tweets is shown at the top of Figure 7. The data fields shown in the figure are summarized in Table 1. The signature is calculated over the fields TID, Creation Time, UID, Text and RT flag. Field TID Creation Time UID Text RT flag Pub flag Hop count Public key Signature Purpose Tweet ID, assigned by sender node. Timestamp of sending the tweet. Twitter user ID of sender. Tweet text. Mark re-tweets. Mark disaster tweets already published to Twitter. Nr. of forwarded hops. Signed public key of sender. Digital signature of tweet. Table 1: Data fields of a disaster tweet. Direct Messages: The format of direct messages is shown at the bottom of Figure 7. The fields are summarized in Table 2. Field MID Creation Time DID Text SName RName Pub flag Public key Signature Purpose Direct message ID, assigned by sender node. Timestamp of sending the tweet. Twitter ID of destination user. Direct message text. Twitter username of sender. Twitter username of receiver. Mark disaster tweets already published to Twitter. Signed public key of sender. Digital signature of tweet. Table 2: Data fields of a disaster direct message.
Certificate Management in Ad Hoc Networks Matei Ciobanu Morogan, Sead Muftic Department of Computer Science, Royal Institute of Technology [matei, sead] @ dsv.su.se Abstract Various types of certificates
Study of Different Types of Attacks on Multicast in Mobile Ad Hoc Networks Hoang Lan Nguyen and Uyen Trang Nguyen Department of Computer Science and Engineering, York University 47 Keele Street, Toronto,
30 Years of Wireless Ad Hoc Networking Research: What about Humanitarian and Disaster Relief Solutions? What are we still missing? Franck Legendre, Theus Hossmann, Felix Sutton, Bernhard Plattner Communication
Introduction to Mobile Ad hoc Networks (MANETs) Advanced Computer Networks Outline Ad hoc networks Differences to other networks Applications Research areas Routing Other research areas Enabling Technologies
Heterogeneous network establishment assisted by cellular operators Marc Danzeisen (1)(2), Torsten Braun (1), Daniel Rodellar (2), Simon Winiker (1)(2) (1) University of Bern, Computer Networks and Distributed
Bit Chat: A Peer-to-Peer Instant Messenger Shreyas Zare email@example.com https://technitium.com December 20, 2015 Abstract. Bit Chat is a peer-to-peer instant messaging concept, allowing one-to-one
Digital Certificates (Public Key Infrastructure) Reshma Afshar Indiana State University October 2015 1 List of Figures Contents 1 Introduction 1 2 History 2 3 Public Key Infrastructure (PKI) 3 3.1 Certificate
Chapter 9: Transport Layer and Security Protocols for Ad Hoc Wireless Networks Introduction Issues Design Goals Classifications TCP Over Ad Hoc Wireless Networks Other Transport Layer Protocols Security
152 JOURNAL OF COMMUNICATIONS, VOL. 5, NO. 2, FEBRUARY 2010 Preventing Unauthorized Messages and Achieving End-to-End Security in Delay Tolerant Heterogeneous Wireless Networks Hany Samuel and Weihua Zhuang
Cryptography and Network Security Chapter 14 Fifth Edition by William Stallings Lecture slides by Lawrie Brown Chapter 14 Key Management and Distribution No Singhalese, whether man or woman, would venture
Security in Ad Hoc Network Bingwen He Joakim Hägglund Qing Gu Abstract Security in wireless network is becoming more and more important while the using of mobile equipments such as cellular phones or laptops
Secured On-Demand Position Based Private Routing Protocol for Ad-Hoc Networks Ramya.R, Shobana.K, Thangam.V.S firstname.lastname@example.org, k email@example.com,firstname.lastname@example.org Department of Computer Science,
WIRELESS PUBLIC KEY INFRASTRUCTURE FOR MOBILE PHONES Balachandra Muniyal 1 Krishna Prakash 2 Shashank Sharma 3 1 Dept. of Information and Communication Technology, Manipal Institute of Technology, Manipal
Cryptography and Network Security Chapter 14 Fifth Edition by William Stallings Lecture slides by Lawrie Brown Chapter 14 Key Management and Distribution No Singhalese, whether man or woman, would venture
SPINS: Security Protocols for Sensor Networks Adrian Perrig, Robert Szewczyk, J.D. Tygar, Victor Wen, and David Culler Department of Electrical Engineering & Computer Sciences, University of California
21 CHAPTER 1 INTRODUCTION 1.1 PREAMBLE Wireless ad-hoc network is an autonomous system of wireless nodes connected by wireless links. Wireless ad-hoc network provides a communication over the shared wireless
Peer-to-peer Cooperative Backup System Sameh Elnikety Mark Lillibridge Mike Burrows Rice University Compaq SRC Microsoft Research Abstract This paper presents the design and implementation of a novel backup
Public Key Infrastructure (PKI) In this video you will learn the quite a bit about Public Key Infrastructure and how it is used to authenticate clients and servers. The purpose of Public Key Infrastructure
SECURITY ASPECTS IN MOBILE AD HOC NETWORK (MANETS) Neha Maurya, ASM S IBMR ABSTRACT: Mobile Ad hoc networks (MANETs) are a new paradigm of wireless network, offering unrestricted mobility without any underlying
Wireless Sensor Networks Chapter 14: Security in WSNs António Grilo Courtesy: see reading list Goals of this chapter To give an understanding of the security vulnerabilities of Wireless Sensor Networks
Design of Simple and Efficient Revocation List Distribution in Urban areas for VANET s Ghassan Samara, Sureswaran Ramadas National Advanced IPv6 Center, Universiti Sains Malaysia Penang, Malaysia email@example.com,
AuthAnvil User Guide Version R91 English August 25, 2015 Agreement The purchase and use of all Software and Services is subject to the Agreement as defined in Kaseya s Click-Accept EULATOS as updated from
CHAPTER 6 CROSS LAYER BASED MULTIPATH ROUTING FOR LOAD BALANCING 6.1 INTRODUCTION The technical challenges in WMNs are load balancing, optimal routing, fairness, network auto-configuration and mobility
Scaling 10Gb/s Clustering at Wire-Speed InfiniBand offers cost-effective wire-speed scaling with deterministic performance Mellanox Technologies Inc. 2900 Stender Way, Santa Clara, CA 95054 Tel: 408-970-3400
A Comparison Study of Qos Using Different Routing Algorithms In Mobile Ad Hoc Networks T.Chandrasekhar 1, J.S.Chakravarthi 2, K.Sravya 3 Professor, Dept. of Electronics and Communication Engg., GIET Engg.
Implementation Guide SAP NetWeaver Identity Management Identity Provider Target Audience Technology Consultants System Administrators PUBLIC Document version: 1.10 2011-07-18 Document History CAUTION Before
BlackBerry Enterprise Service 10 Secure Work Space for ios and Android Version: 10.1.1 Security Note Published: 2013-06-21 SWD-20130621110651069 Contents 1 About this guide...4 2 What is BlackBerry Enterprise
ADSS Server is a multi-function server providing digital signature creation and signature verification services, as well as supporting other infrastructure services including Time Stamp Authority (TSA)
Certificate Management PAN-OS Administrator s Guide Version 7.0 Contact Information Corporate Headquarters: Palo Alto Networks 4401 Great America Parkway Santa Clara, CA 95054 www.paloaltonetworks.com/company/contact-us
Certificate Revocation Management in VANET Ghassan Samara Department of Computer Science, Faculty of Science and Information Technology, Zarqa University Zarqa, Jordan. Gsamara@zu.edu.jo ABSTRACT Vehicular
Kaspersky Lab Mobile Device Management Deployment Guide Introduction With the release of Kaspersky Security Center 10.0 a new functionality has been implemented which allows centralized management of mobile
GO!Enterprise MDM Device Application User Guide Installation and Configuration for Android GO!Enterprise MDM for Android, Version 3.x GO!Enterprise MDM for Android 1 Table of Contents GO!Enterprise MDM
Business Issues in the implementation of Digital signatures Much has been said about e-commerce, the growth of e-business and its advantages. The statistics are overwhelming and the advantages are so enormous
Salesforce1 Mobile Security Guide Version 1, 1 @salesforcedocs Last updated: December 8, 2015 Copyright 2000 2015 salesforce.com, inc. All rights reserved. Salesforce is a registered trademark of salesforce.com,
Introduction Security and privacy are two of the leading issues for users when transferring important files. Keeping data on-premises makes business and IT leaders feel more secure, but comes with technical
(KMIP) Addressing the Need for Standardization in Enterprise Key Management Version 1.0, May 20, 2009 Copyright 2009 by the Organization for the Advancement of Structured Information Standards (OASIS).
Lecture slides by Lawrie Brown for Cryptography and Network Security, 5/e, by William Stallings, Chapter 14 Key Management and Distribution. 1 Opening quote. 2 The topics of cryptographic key management
Security for Ad Hoc Networks Hang Zhao 1 Ad Hoc Networks Ad hoc -- a Latin phrase which means "for this [purpose]". An autonomous system of mobile hosts connected by wireless links, often called Mobile
BlackBerry Enterprise Server for Microsoft Exchange Version: 5.0 Service Pack: 2 Feature and Technical Overview Published: 2010-06-16 SWDT305802-1108946-0615123042-001 Contents 1 Overview: BlackBerry Enterprise
Tomás P. de Miguel DIT- 15 12 Internet Mobile Market Phone.com 15 12 in Millions 9 6 3 9 6 3 0 1996 1997 1998 1999 2000 2001 0 Wireless Internet E-mail subscribers 2 (January 2001) Mobility The ability
BlackBerry Enterprise Server for Microsoft Exchange Version: 5.0 Service Pack: 4 Feature and Technical Overview Published: 2013-11-07 SWD-20131107160132924 Contents 1 Document revision history...6 2 What's
EXTENDING NETWORK KNOWLEDGE: MAKING OLSR A QUALITY OF SERVICE CONDUCIVE PROTOCOL by Pedro Eduardo Villanueva-Pena, Thomas Kunz Carleton University January, 2006 This report examines mechanisms to gradually
Security Guide BlackBerry Enterprise Service 12 for ios, Android, and Windows Phone Version 12.0 Published: 2015-02-06 SWD-20150206130210406 Contents About this guide... 6 What is BES12?... 7 Key features
CHAPTER 1 Note The information in this chapter applies to both the ACE module and the ACE appliance unless otherwise noted. The features in this chapter apply to IPv4 and IPv6 unless otherwise noted. Secure
A Lightweight Secure SIP Model for End-to-End Communication Weirong Jiang Research Institute of Information Technology, Tsinghua University, Beijing, 100084, P.R.China firstname.lastname@example.org Abstract
QUALITY OF SERVICE METRICS FOR DATA TRANSMISSION IN MESH TOPOLOGIES SWATHI NANDURI * ZAHOOR-UL-HUQ * Master of Technology, Associate Professor, G. Pulla Reddy Engineering College, G. Pulla Reddy Engineering
1 Opportunistic Ad Hoc Networking: the Case for Car to Car Communications Mobiquitous 2005 Mario Gerla Computer Science Dept UCLA What is an opportunistic ad hoc net? A wireless ad hoc extension of the
Overview The following note covers information published in the PCI-DSS Wireless Guideline in July of 2009 by the PCI Wireless Special Interest Group Implementation Team and addresses version 1.2 of the
GO!Enterprise MDM Device Application User Guide Installation and Configuration for Android with TouchDown GO!Enterprise MDM for Android, Version 3.x GO!Enterprise MDM for Android with TouchDown 1 Table
GOV.UK Guidance BlackBerry 10.3 Work and Personal Corporate Published Contents 1. Usage scenario 2. Summary of platform security 3. How the platform can best satisfy the security recommendations 4. Network
Content-Centric Networking Applications For Medical Devices and Healthcare Management Systems DISCUSSION DOCUMENT JULY 2012. PARC, 3333 Coyote Hill Road, Palo Alto, California 94304 USA +1 650 812 4000
Security+ Guide to Network Security Fundamentals, Third Edition Chapter 12 Applying Cryptography Objectives Define digital certificates List the various types of digital certificates and how they are used
Enabling SSL and Client Certificates on the SAP J2EE Engine Angel Dichev RIG, SAP Labs SAP AG 1 Learning Objectives As a result of this session, you will be able to: Understand the different SAP J2EE Engine
Special Properties of Ad-hoc Wireless Network and Security Models Han Zhong Department of Computer Science, University of Auckland E-mail: email@example.com Abstract:There are certain amounts of
Energy Effective Routing Protocol for Maximizing Network Lifetime of WSN Rachana Ballal 1, S.Girish 2 4 th sem M.tech, Dept.of CS&E, Sahyadri College of Engineering and Management, Adyar, Mangalore, India
http:// PERFORMANCE ANALYSIS OF AD-HOC ON DEMAND DISTANCE VECTOR FOR MOBILE AD- HOC NETWORK Anjali Sahni 1, Ajay Kumar Yadav 2 1, 2 Department of Electronics and Communication Engineering, Mewar Institute,
Voltage's Encrypted Email October 2004. Report #471 Ferris Research Product Brief Sponsored by Ferris Research, Inc. 408 Columbus Ave., Suite 1 San Francisco, Calif. 94133, USA Phone: +1 (415) 986-1414
The Benefits of SSL Content Inspection ABSTRACT SSL encryption is the de-facto encryption technology for delivering secure Web browsing and the benefits it provides is driving the levels of SSL traffic
User Guide Supplement S/MIME Support Package for BlackBerry Smartphones BlackBerry Pearl 8100 Series SWD-292878-0324093908-001 Contents Certificates...3 Certificate basics...3 Certificate status...5 Certificate
DIGITAL RIGHTS MANAGEMENT SYSTEM FOR MULTIMEDIA FILES Saiprasad Dhumal * Prof. K.K. Joshi Prof Sowmiya Raksha VJTI, Mumbai. VJTI, Mumbai VJTI, Mumbai. Abstract piracy of digital content is a one of the
www.novell.com/documentation Android App User Guide ZENworks Mobile Management 2.7.x August 2013 Legal Notices Novell, Inc., makes no representations or warranties with respect to the contents or use of
Websense Content Gateway HTTPS Configuration web security data security email security Support Webinars 2010 Websense, Inc. All rights reserved. Webinar Presenter Title: Sr. Tech Support Specialist Cisco
Licensing Guide BES12 Version 12.1 Published: 2015-04-02 SWD-20150402115554403 Contents Introduction... 5 About this guide...5 What is BES12?...5 Key features of BES12... 5 About licensing...7 Steps to
1(11) Server based signature service Overview Based on federated identity Swedish e-identification infrastructure 2(11) Table of contents 1 INTRODUCTION... 3 2 FUNCTIONAL... 4 3 SIGN SUPPORT SERVICE...
International Journal of Engineering and Technical Research (IJETR) ISSN: 2321-0869, Volume-2, Issue-4, April 2014 Intrusion Detection System in MANET : A Survey S.Parameswari, G.Michael Abstract MANET
SHORT MESSAGE SERVICE SECURITY February 2008 The Government of the Hong Kong Special Administrative Region The contents of this document remain the property of, and may not be reproduced in whole or in
App Distribution Guide Contents About App Distribution 10 At a Glance 11 Enroll in an Apple Developer Program to Distribute Your App 11 Generate Certificates and Register Your Devices 11 Add Store Capabilities
DDL Systems, Inc. ACO MONITOR : Managing your IBM i (or AS/400) using wireless devices Technical White Paper April 2014 DDL Systems, Inc. PO Box 1262 Valparaiso, IN 46384 Phone: 866 559-0800 Introduction
Technical Standards for Information Security Measures for the Central Government Computer Systems April 21, 2011 Established by the Information Security Policy Council Table of Contents Chapter 2.1 General...
A Practical Authentication Scheme for In-Network Programming in Wireless Sensor Networks Ioannis Krontiris Athens Information Technology P.O.Box 68, 19.5 km Markopoulo Ave. GR- 19002, Peania, Athens, Greece
Advance in Electronic and Electric Engineering. ISSN 2231-1297, Volume 4, Number 4 (2014), pp. 381-388 Research India Publications http://www.ripublication.com/aeee.htm Security and Privacy Issues in Wireless
1 Routing and Channel Assignment in Multi-Channel Multi-Hop Wireless Networks with Single-NIC Devices Jungmin So + Nitin H. Vaidya Department of Computer Science +, Department of Electrical and Computer
Chapter 5 Simple Ad hoc Key Management 5.1 Introduction One of the most important consequences of the nature of the MANET networks is that one cannot assume that a node that is part of a network will be
Effective: April 12, 2016 Symantec and the Norton brand have been entrusted by consumers around the world to protect their computing devices and most important digital assets. This Norton Mobile Privacy
Content Teaching Academy at James Madison University 1 2 The Battle Field: Computers, LANs & Internetworks 3 Definitions Computer Security - generic name for the collection of tools designed to protect