In this section, an analysis of the proposed communication architecture, its communications and its security is provided.
A flowchart illustrating system communication is shown in Fig. 7.
First of all, health staff workers need to be previously registered and authenticated by the manager at the server. The manager have a global view with all the events through the web application and will be responsible for the emergency management. He is also registered on the system and has the possibility of modifying the staff information if necessary.
The key generator corresponds to a service running in the server as second process and generating keys to protect communications.
Once the manager assigns a worker to a emergency (1) he/she obtains the information related to the event and his/her intervention on the affected area (2). If the first responder finds a new victim, he/she makes a first triage and stores the output on a new NFC tag (3). In other case, if the worker finds a victim who is already registered he/she reads the NFC tag, analyzes the information and updates it if necessary (4).
Note that first reponders’ routes depend on the triage they carry out. When a new patient is found, extra information is not needed. Otherwise, next victim to attend is decided depending on the priority defined by the previous triages performed on him/her.
Finally, the worker can send information to a group (based on an specific role), for example to doctors (6) (7), or a direct message to another peer (7).
Simulation and efficiency analysis
A prototype of the system has been developed, with a web application (see Fig. 8a) and a mobile application (see Fig. 8b).
The implementation comprises:
-
a web application developed with JavaScript in the backend (with Nodejs) and Vuejs in the frontend,
-
a mobile application implemented in Android with Kotlin and the 5.5 SDK version
Regarding the hardware, a laptop with Windows x64 and 16 GB RAM was used for the web application and a Pixel 2 with Android to run the mobile application.
A simulation tool has been developed based on JavaScript and the Google maps API in order to validate the approach proposed to assign resources. It also allows to represent and monitoring the emergency situation.
Some random points of different colors representing people affected by the emergency have been generated and located on the map. Colors are the result of the first triage (red, yellow, green and black). In Fig. 9, the costs of the naïve approach (allocation to the nearest AMP) and the one defined in this paper are compared. The blue part is the cost of traditional method, and the black part is the cost of the proposed system. The improvement of black zone over blue one is observable. In this case, the evaluation is supported by the output of 100 iterations with 1000 victims.
In Fig. 10, improvements for 100 iterations with different victims amount are represented. In all the cases, there are improvements. Note that all the locations in the simulations where randomly generated, and the output of this figure is the mean of all solutions of iterations.
The code of the testing tool is available in a Github repository [36].
Security analysis
In the system developed, standard signcryption protocols are used in order to guaranteeing confidentiality and authenticity of data by combining signature and encryption while communication overhead and computational costs are reduced. Details on the formal security analysis of signcryption protocols may be fount at [37].
During Unsigncryption, user B computes \(y \leftarrow H_2({\hat{e}}(S_{ID_b}, T))\) to retrieve the ephemeral session key k used to encrypt the message m. Only the intended recipient in possession of the private key can retrieve this value. Otherwise, it will be necessary to invert the hash function \(H_2\) and solving instances of the Elliptic Curve Diffie–Hellman problem.
For sender identification verification, the signature must be verified using both the public key \(Q_{ID_a}\) of the sender and the master public key (mpk) by user B. Obtaining user keys while they are distributed by the PKG is not viable since that are sent ciphered with SNOW3G.
In the multiple receiver signcryption, the message m is encrypted by the sender using Snow3G with an ephemeral key K derived from randomly selected integers. This k may be calculated only by the intended recipients since it is calculated as the output of a hash function over a secret information. Again, signature verification requires the public keys of users and master.
Forward secrecy is also achieved thanks to the use of ephemeral ciphering keys. Although an adversary managed to know sender’s secret keys, deciphering previous messages will not be possible since ciphering keys are derived from random information that change for every message sent.
The proposed scheme provides protection against different attacks. Attacks related to multiple requests to the server, Denial of Service (DoS) attack, are restricted because only requests associated with a number of legitimate members of the health staff will take effect.
Once the corresponding private key is assigned, no more requests of this kind will be attended. Thus, the typically “Man in the Middle” (MiTM) attack which conveys a successful authentication to the server with an identifier of legitimate members of the health staff is improbable. This false identification would be easily detectable because the number of members who can make requests to the server is limited to those who are working at the time of the request. This authentication is one of the most important points on every cloud computing system based on mobile phones [38]. It should be clarified that resistance to certain types of attacks such as DOS and MiTM is not a feature of the algorithm but of the specific application domain. When using it in a different domain, its invulnerability to the same attacks can not be guaranteed.