# Tokens Shuffling Approach for Privacy, Security, and Reliability in IoHT under a Pandemic
## 3 Proposed Approach (TSA)
### Main Phases of TSA  
1. Collect the spatial data for the user and save them locally on the user's phone by the proposed application to manage these data. The application will save the spatial data for the last 14 days (this period is related to the incubation period without symptoms). The application enables the user to determine a blind point (such as his house), and the data of this area will not be saved. The importance of this step is summarized in two points: The first is reducing the load on the service providers, especially in exceptional circumstances, so we do not need to connect, track, or save the data of millions of users who are not infected. Instead, TSA uses the resources of the user's device to save data (Dew computing). The second is protecting data locally, reducing connecting costs, and enhancing user privacy. 2. In the case in which the user is proven to have an infection, we will rely on an independent server \"SP1\" to verify the infection and manage the generation of tokens. SP1 will send tokens to a list of service providers such as SP2, regardless of whether the service is a medical or tracing one during the pandemic. Two unique tokens are generated (T1, T2) by SP1 for each infected person. The validity of the tokens is one day. T1 will be sent to the fog node, the manager for the user's area, while T2 will be forwarded to the SP2, which can be a monitoring and tracking service for the placesof the spread of the disease. SP1 does not send data about the user's identity or his name to the fog node or SP2. Additionally, SP1 does not have data about the locations of the user. Using an independent server to manage tokens will distribute the load between service providers, and the level of privacy and reliability of user data will be enhanced. So, no data will be accepted without verifying that the user has an effective token. In other words, they are closing the ports in front of frivolous or fake users who may send false data to service providers to affect the quality of services or statistics, etc. Moreover, sending a different token to SP2 than one of the fog nodes will enhance privacy and prevent the fog node from revealing the user's data to SP2. After proving the infection and generating the tokens, the user must share his saved data with SP2. SP2 is interested in tracking the places of the spread of infection and some important statistics during pandemics. We have presented two different scenarios to ensure the security and privacy of these data and its users:  
First Scenario (Figure 1): Infected user A communicates with his area's fog node with an alias in addition to his T1. The fog node verifies the validity of a user's token (T1). Then, it sends the user a list of all the aliases of the users connected with the fog node (i.e., in the same area managed by that fog node). Then, through the proposed application, users communicate with each other and exchange T2 among themselves. For example, A exchanges A with B and C. Then, A encrypts the data for the first seven days, with B.T2 added within it as a reliability identifier. Then, A repeats the same process over the second seven days with C.T2 (to create 14 days). Note that encryption will be carried out using the SP2 public key. Then, each user sends their data to the fog node, which will not be able to see these data because they are encrypted. The fog node collects the data of several users and sends them as a single block to SP2. In this case, the fog provides protection for users' privacy (K-Anonymity), where K is the number of anonymized users whose data are being sent. Second Scenario (Figure 2): Instead of exchanging the token, the users will exchange the data encrypted with the SP2 public key, but this time without the token, and then each user (e.g., A) sends their new collected data to the fog node with his encrypted token (A.T2) as well. Figure 1: First Scenario of TSA.