Immediate and Secure Emergency Connection (ISEC)
“Do you hear me?”
“How is your condition?"
“Can you move? Calm down"
“Where are you?"
“May you spell your address?"
These questions are commonly asked in the most emergency calls. While the service operator tries to calm down the caller, it is necessary to get more information, which is needed for better rescuing serve. Achieving a complete and adequate information is required to offer a proper service in the emergencies, which threat life or properties. Providing a high quality of service at the shortest responding time is the main concern of the emergency service centers like a medical emergency, police, firefighting, and social related service centers.
Because of the high priority of rescue missions, the privacy of some victims may not necessarily be protected well. In general, people are concerned about their privacy associated with their physical and mental health, which include: stress, disability and confusion, in a disaster. Moreover, the prevalence of global surveillance, including an untrusted third party or government monitoring, has caused much concern to many users. Communication service providers generally make money from mining their clients’ personal data. Based on these facts, a generic emergency communication system is expected to provide confidentiality and integrity services in any condition.
Due to the rapid growth of smartphone-based applications and global trends toward online services, traditional emergency facilities face challenges handling the types of communication that consumers expect today. In comparison to the traditional communication systems, online services, such as instant messaging (IM), provide different features that include: texting, picture/video sharing, location-based services, and most importantly, real-time delivery. The next generation 9-1-1 (NG9-1-1 project), for instance, will allow callers to take advantage of mobile device features, such as IM systems in an emergency situation. Since IMs have no security features by default, the security and privacy issues are challenging with these systems.
Privacy concerns
In messaging systems, users’ personal data (e.g., profile, private messages/photos, and location information) can be disclosed when its message database is accessed by unauthorized users. End-to-end secure communication is not sufficient for protecting user privacy. User’s personal information is typically stored in a database on the messenger server. As shown in Fig. 1, a typical messaging service provider performs credential management and provides a secure channel to deliver the clients’ messages. Although there is a secure connection to the service provider server, this capability makes a curious service provider able to freely review all messages on the server-side.
A typical secured communication managed by a curious messaging service provider
As a consequence, user’s personal information at the server would become one of the most attractive targets for the intelligence agencies. On the other hand, due to the priority of the rescuing purposes, a client’s privacy may be ignored unintentionally in order to have more accurate emergency reporting. Therefore, providing an end-to-end confidentiality and integrity with no interference of any third parties or service providers is required to protect clients’ privacy and data confidentiality.
Undelivered message problem
Due to the nature of emergency situations, efficient data needs to be delivered immediately and accurately to the rescue service centers. In this view, every tiny clue may change a victim’s fate in a life-threatening condition. Therefore, each emergency request should be considered carefully. As a basic rule of all emergency rescue facilities, it is required that: they do not ignore any request. To get some insight into the problem, consider that a network disruption, whether it was planned (e.g., upgrading or a service disruption) or unplanned because of a natural disaster, occurs in which the server is unable to deliver the emergency requests. What would happen with an undelivered emergency request? Perhaps that message was the last chance for a victim to send his request. Therefore, any emergency facility requires a reliable messaging system that guarantees to save messages and delivers them meaningfully to the receiver.
ISEC- Basic concepts
Immediate and Secure Emergency Connection (ISEC) is a framework to enhance privacy protection and send the information securely in an efficient and immediate manner. ISEC is a smartphone-based application to create end-to-end (E2E) confidentiality and integrity to the emergency center, independent from network operators. An E2E secure connection is made to the emergency server in any emergency connection. Upon receiving an emergency request, the server performs a primary evaluation and sends it to the relevant emergency service center (e.g. medical emergency, police or firefighting service). In this model, we try to minimize the number of messages as much as possible such that all critical information (e.g., location) is sent in the initial messages. Depending on the request, the server adds some information and forwards it to the relevant emergency service provider. The server side is considered to be well equipped which causes no delay and deficiency. The external lookup of the model is shown in Fig. 2.
Overall view of ISEC framework
Basically, in an emergency messaging application, the server should be accessible every time and receives the requests at the shortest time. Start-up delay, as a common source of latency in the security protocols like TLS, arises from protocol handshake (e.g., transport-layer three-way handshake) or negotiation over security association (SA). To reduce this latency, ISEC eliminates the handshake progress by preserving and renewing the required security parameters generated at the registering time. In fact, ISEC provides a virtual secure channel for every registered client and preserves it for immediate data exchanging in any emergency condition. Furthermore, ISEC makes it possible for clients to regularly get informed about the server's condition or achieves the latest changes of the secure channel (e.g., key renewing or expiring).
To provide an E2E confidentiality, ISEC exploits O2TR, introduced by Firoozjaei et al. [1]. O2TR provides E2E security between connection parties without requiring the assumption that they are persistently connected to each other. In the start-up connection, the server and the client establish an O2TR connection to exchange their Diffie-Hellman (DH) keys and long-term public keys. After that, the client is registered and an encrypted channel is established. This encrypted channel will be virtually reserved for that client and by rekeying progress the security keys (encryption key and MAC key) are refreshed regularly. Virtually reserving a secure channel for a registered client makes it possible to immediately exchange encrypted data in an emergency condition. Consequently, no handshake is required for the next communication and ISEC parties exploit the latest keys which were updated by rekeying progress, provided by O2TR protocol.
To protect the aliveness of ISEC's secure channel, the emergency server performs liveness check scheme. By this scheme, the emergency server regularly checks the aliveness of ISEC secure channel by performing socialist millionaires' protocol (SMP). Generally, SMP allows two parties with secret information x and y respectively to check whether they have the same secret without revealing any additional information about the secrets. Therefore, ISEC not only checks the aliveness of the secure channel but also protects the system against impersonation and man-in-the-middle (MitM) attacks.
