SCB-HC-ECC–Based Privacy Safeguard Protocol for Secure Cloud Storage of Smart Card–Based Health Care System

The advent of the internet has brought an era of unprecedented connectivity between networked devices, making one distributed computing, called cloud computing, and popular. This has also resulted in a dire need for remote authentication schemes for transferring files of a sensitive nature, especially health-related information between patients, smart health cards, and cloud servers via smart health card solution providers. In this article, we elaborate on our proposed approach for such a system and accomplish an informal analysis to demonstrate the claim that this scheme provides sufficient security while maintaining usability.


INTRODUCTION
With the advent of cloud computing, we can rent servers and run geophysical modeling applications on the authoritative node present everywhere globally. We can securely store an enormous amount of data that can be accessed only by authorized users and applications (1)(2)(3). It enables us to rent a virtual server, switch it on or off, and expand it to fulfill users' immediate requirements. It increases association, adaptability, availability, and competency and speeds up the development process to imitate the deviations afforded to workload demand and also provides cost reduction over with efficient and optimized computations (4)(5)(6)(7)(8). As healthcare evolves, the need for innovative information system development is necessary (9,10).
Cloud computing is the new paradigm for outdated conventional computing by adopting newer technology and many economic aspects. It is beneficial for both customers and service providers (2,11). However, it has many advantages and disadvantages that restrict its usability. It includes architecture that supports many potential applications, programming models to support vast-scale data-centric computing, and provision for security and privacy protection of data. Security of data is challenged by both outside and inside threats (12)(13)(14). They can make use of a user's data for their benefit. Consequently, the popularity of cloud computing increases issues in security and privacy areas as well (15)(16)(17).
Consider a healthcare organization in which patients use a smart card that electronically holds patients' medical information. A smart card mechanism is used globally for secure identity, access, and payment applications. Smart health card solutions for patient and provider identity management are deployed worldwide and are accessible from various vendors (18,19). A smart card mechanism offers a robust foundation for healthcare ID cards, empowering enhancement in healthcare procedures and in-patient and provider identity verification while securing data and protecting privacy (20)(21)(22). Smart healthcare cards are available with two chips, one for the patient, and one for health professionals. Smart health cards can be an essential information source in case of an emergency when the patient is unresponsive. It could be the first source of information to know about the patient. However, smart cards are restricted in memory size, allowing the storage of only a limited amount of data. As such, the memory-intensive data, such as lab reports or diagnostic images and additional patient-related information, can be stored in a cloud server and accessed via the smart health card by healthcare professionals through the smart card solution provider (23)(24)(25).
Moving over to the cloud has proven to be helpful for both healthcare professionals and patients. The cloud also engages the patient with their health insurance plans by offering them generous access to their additional healthcare data that is not there in the smart health card, resulting in improved patient outcomes. Providing health care data in the cloud engages the interoperability of several segments of the health care industry, such as pharmaceuticals, insurance, and payments (13,26,27).
The following sections of the paper are organized as follows. Section II discusses related works on implementing and authentication of a smart card-based health care system with the cloud. Section III gives the preliminaries required for our work. Section IV gives an overview of the proposed system and system model. Section V describes the security and performance analysis of our scheme compared with other schemes. The conclusion is provided in Section VI.

RELATED WORKS
Many works have addressed implementing and authenticating smart card-based health care information systems. Moudgil et al.
(1) designed a cloud-based smart health card monitoring system. Their proposed monitoring system helps health care providers, such as hospitals, physicians, and pharmacists, by managing all the patient data electronically, securely, and efficiently. It uses Bluetooth technology to transmit live patient monitoring data. It also supports off-line storage of medical and information and periodic updates to the cloud database. However, they do not focus on how the smart card and cloud servers are synchronized and how the mutual authentication happens between them. Yang et al. (28) design a MedShare system that publishes patient data to a cloud server using a two-way authorization process. They use the national identification card that patients swipe to publish data in the cloud. However, identification cards are only used for authentication purposes and do not carry any health care information. Li et al. (29) design a mutual authentication and privacy preservation protocol for the TMIS system. They use the AES encryption algorithm for encrypting patient information. Kausar et al. (30) design an intelligent card-based system using an iris-based biometric cryptosystem for an innovative card-based healthcare system. They focus only on how the patient data is stored and retrieved in the smart card. Their system does not include any security phases and is not integrated with cloud storage (31,32).
Al-Saggaf et al. (33) propose a biometric-based remote authentication scheme using a smart card. They use a hashing function for transferring all the information. However, they do not mention the specific cryptographic technique for storing the data in the smart card. Kumari et al. (23) design an ESEAP system, which is an ECC-based mutual authentication protocol for the smart card. However, their system does not support the various phases, including health center data upload, medical data upload, and the lab technician phase. Ganesh et al. (34) propose the smart, automated health machine using IoT, which provides health services to the local area. They discuss the authentication phase using the smart card system to secure their privacy, but the system is not integrated with the cloud (35,36).
The research work emphasizes the authentication to recognize that unauthorized users cannot access a user's private data but disregards an elusive privacy issue. In contrast, data sharing happens between the other users, such as the patient's smart card medical data and the cloud service provider. We propose a solution to address the data-sharing privacy issue for this type of environment.
The main contribution of the article is as follows: 1. Mutual access authority is attained by an anonymous access request matching approach with concern about security and privacy so that the cloud is not aware of who the patient is. 2. Mutual authentication between the healthcare organization that accesses the patient data using a smart card via the smart health card solution provider to the cloud server for further treatment. 3. The ECC-based encryption on the patient-related data in the cloud server and the smart health card. 4. Notification to the smart health card solution provider about changes in the patient data by the health care organization.

PRELIMINARIES Elliptic Curve Cryptography
Elliptic-curve cryptography (ECC) is a technique for an asymmetric cryptosystem built on the algebraic structure of elliptic curves over finite fields (29). Let p be a large prime number and E denote the elliptic curve over the prime finite field Z P E : y 2 = x 3 + c.x + d (mod p)with(c, d) ∈ Z P and 4c 3 +27d 2 (mod p)#0 and produces grouping E p c, d .
Base point G on the elliptic curve has a large order n, where n is a large prime number.  2. Generate (pub,priv) key pair to be generated 3. Let k be the random number such as positive integer selected by A where P m is the plain text point and P B = n B * G where n B < n which is private key, P B is the public key and C m is the cipher text.

Let us find
3. Because of the multiplicative inverse property, kn B * kG can be written as n B * kG 4. p m = p m + n B * kG − n B * kG Finding the value of k or private key n B is an elliptic curve discrete logarithmic problem (ECDLP) that requires a fully exponential running time. To compute the 160-bit key size of private key n B , we require 8.5 * 10 11 MIPS.

ECCDSA
The elliptic curve equivalent of the digital signature algorithm (DSA) is the elliptic curve digital signature algorithm (ECDSA). The ECDSA was first projected in 1992 by Scott Vanstone in response to NIST (37).
ECDSA has three phases: key generation, signature generation, and signature verification.
ECDSA Key Generation: A is an entity that uses the key pair with a particular set of ECC domain parameters (p,q,g) that does the following: Choose P as its public key, and d is the private key ECDSA Signature generation A's message m is signed with domain parameters D = {q, FR, a, b, G, n.h} and key pairs (P,d) perform the following steps: 1. Choose a random integer z, 1 ≤ x ≤ n − 1 2. Calculate xG= (x 1, y 1 ) and change x1 to an integerx 1 3. Calculate s = x 1 mod n. If s=0, then go to step 1 4. Calculate z −1 mod n. 5. Calculate SHA-1(m) and convert the output to an integer f. 6. Calculate v= z −1 (f+ds) mod n. If v=0, then go to step 1. 7. A's signature for the message m is (s,v).

ECDSA Signature verification
To verify A's signature (s,v) on m, the entity B gets an authentic copy of A's domain parameters D = {q, FR, a, b, G, n.h} and its public key P. B does the following: 1. Verify (s,v) are integers in the interval [1,n-1] 2. Calculate SHA-1 (m) and convert the output to an integer f 3. Calculate w = v −1 mod n 4. Calculate i 1 =fw mod n and i 2 =sw mod n 5. Calculate X = i 1 G + i 2 Q 6. Calculate X = 0; then reject the signature. Otherwise, convert x coordinate x1 of X to an integer and thenx 1 calculate u=x 1 mod n 7. Accept the signature only if u = s

SHA-256
Secure hash algorithm-256 (SHA-256) is a cryptographic hash function with a message digest size of 256 bits. It is a keyless hash function; it detects the changes in the message called the manipulation detection code (MDC). A message is handled by blocks of 512 = 16 × 32 bits, in which each block is needful of 64 rounds (38)(39)(40).
It uses the Boolean operations AND, XOR, OR, and Bitwise complement that are indicated by ∧, ⊕ and ∨, − . Integer addition modulo 2 32 , indicated by A + B.
The RotR(A, m) indicates the circular right shift of m bits of the binary word A.
The ShR(A, m) indicates the right shift of m bits of the binary word A.
A||B denotes the concatenation of the binary words A and B.

SYSTEM MODEL Architecture
The proposed system emphasizes the elimination of all the above stated factors that are discussed in the existing systems (23,41,42). The architecture of the proposed system is shown in Figure 1.
The system architecture shows that the patient goes to the health care professional, such as doctors or pharmacists, and health insurers and diagnosis lab technicians show how the interactions occur. First, both the patient and health care professional swipe their respective smart cards in the card reader: the patient's smart card by the patient and the professional smart card by the health care professional to mutually authenticate each other. Subsequently, the patient performs the second-factor authentication by entering a PIN or password or biometric. After the authentication phase, the patient's basic medical pieces of information are read from the patient's smart card. Suppose further detailed medical information is necessary to proceed with the next level, such as to take treatment from the doctor, to purchase medicine from the pharmacist, or to claim the insurance from the health insurer. In that case, the cloud server is contacted via the smart card solution provider (19,(43)(44)(45). The cloud server responds to the health professional's request by fetching the patient information and sending it to the health care professional. Later, when the patient data are modified or additional information needs to be added, the data are sent to the healthcare professional's cloud server. The following are the various phases of our proposed protocol.

Adversary Model
In this paper, we regard the adversarial model as follows: 1. X to capture the message transmitted on the cloud environment (46,47

Preliminary Phase
When the smart card is purchased from the smart card issuer, the patient's basic personal information or health care professional's information is stored in an encrypted form using ECC. To do that, the following ECC security parameters are chosen. In this phase, the cryptographic algorithm ECC is chosen by the health care professional as well as by the smart card solution provider (SP) for encrypting the patient data in the patient's smart card and the detailed information of the patient's medical information stored in the cloud server.

Algorithm for Preliminary Phase
Input: ECC parameters Output: Public key Y and private key s 1: Let p be a large prime number, and E denote the elliptic curve over the prime finite field Z P .

Registration Phase
A new user U i such as a patient or health care professional purchases the smart card from the SP and registers it as follows: Algorithm for registration:

Login Phase
The login phase is common to patient and health care professional cards issued by the smart card SP. The user U i (patient or health care professional) logs in with the system to access the information stored in the smart card as follows:

Algorithm for login:
Input: ID and pwd i Output: Login Access Request 1: U i provides ID and pwd i , and then the smart card computes, Here, a is a secret nonce picked by U i , and T is the current time stamp.

Authentication Phase
The authentication steps are as follows: Algorithm for authentication where, c is a nonce selected by SP, and T 2 is the current time stamp. According to the category, the health care professional belongs to the type of data retrieved, and data that is being synchronized with the cloud server differs. The below phases denote per the type of health care professional what type of data can be accessed or modified in the patient data.

Data Synchronization Phase
This phase starts when patient data is altered by the health care professional and should be synchronized with the cloud server to maintain consistency between the data stored in the cloud and the smart card and to store additional information that could not be stored in the cloud due to memory constraints. The following are the cases when the patient data should be synchronized with a cloud server. (v) Similarly, additional health care professional information also can be stored in a cloud server.
After performing a successful login, the health care professional gets an option to store the information as follows:

Data Retrieval Phase
This phase starts when patient data needs to be retrieved by the health care professional to study the patient's medical history and diagnose the disease to proceed with further treatment. The following are the cases when the patient data should be retrieved from the cloud server.
(i) The doctor wants to view the patient's previous history to know more in depth about the health problem. (ii) The pharmacist can sell the medicine according to the prescription uploaded in the cloud server. (iii) The insurance provider can check the hospital bill to process the claim for the medical expenditure.

Algorithm: Data retrieval
Input: Signature Sig, Encrypted file Output: Unencrypted file 1: Data retrieval starts after the smart card authentication is over with the card issuer and request made for accessing additional information by the health professional.
2: After receiving the request, the cloud server S searches the data over the encrypted form from its database using the MCKS-MAT scheme (49). We have constructed the multiattribute tree (MAT) for the partient or health care professional record set by choosing the category as the root of the tree. File search is considered to be a separate phase. 3: The cloud server retrieves the data and then transfers it to the smart card SP. The decryption performed at the smart card solution provider by using s also computes and checks its ECCDSA hash to detect any tampering.

File Search
To search the patient records in the cloud server, we adopt the MCKS-MAT scheme (49) by which we have constructed the MAT for the patient record set. The number of levels in the MAT index tree L is equal to the number of attributes in the patient file. The MAT index tree is encrypted using the ECC encryption algorithm. Along with the patient files, the encrypted MAT tree is stored in the cloud server, which protects the cloud server against a cipher text attack, known plaintext attack and known background attack. The construction and explanation of the MCKS-MAT scheme is beyond the scope of our work.

INFORMAL ANALYSIS
We have assessed that the proposed method has the ability to protect the user from different cryptographic attacks.

User Anonymity
Our scheme provides user anonymity, such as patient and health care professional (doctor, lab technician, and insurer) anonymity, for example, during the entirety of the phases, the user's ID is always masked and unattainable even from any trapped messages. Hence, the smart card SP, after getting ID, e i , and A from the user U i , it computes M = h(s ⊕ ID) and B= M ⊕ A and discloses it to the user. Furthermore, the ID is not revealed to anyone. Hence, our scheme confers the property of user anonymity.

Forward Secrecy
Our scheme confers the forward secrecy property as each session key is fresh due to the randomness of c. SP computes D1 = c.P, D2 = c.C1. From that, it computes the session key SK = h(ID h1 (D2) M ′ ). Thus, each session key is completely autonomous of other sessions. Thus, even in the

Replay Attack
Our scheme protects against replay attacks by providing sufficient checks of validity for each transmitted message. Thus, our scheme is able to withstand a replay attack as it includes the time stamp in the transmitted message. Kumar et al. (12) does not sustain doctor unlinkability. Kumar et al. (12,23) does not support forward secrecy, stolen smart attacks. Our scheme protects against several known security attacks (50).

Man-in-the-Middle Attack
Our scheme prevents the man-in-the-middle attack as each datum that we are transferring between the entities is associated with the time stamp and hash conditions. In case any adversary A verifies the time stamp, it further has to verify f ′ = f , which is impossible due to the characterization of the one-way hash function.

Data Confidentiality
In case any adversary tries to read the patient's or health care professional's information, it needs to decrypt the information, which is not possible without knowing the key and hash value. The freshness of s and one-way hash function ECCDSA ensures data confidentiality.

Data Non-repudiation
The proposed protocol supports data non-repudiation in various phases.  information even to the cloud server, so the unlinkability is preserved between the doctor and patient.

PERFORMANCE ANALYSIS
We performed various cryptographic operations on a machine with a dual core processor of 2:4 GHz and equipped with 2 GB RAM running with the windows 10 operating system.  23) does not support forward secrecy. However, all the schemes do not support the stolen smart card attack as it is focusing on telecare medicine information system. In summary, our scheme provides support for several security features and protects against several known attacks.

Computation Cost
In this section, we project performance of our proposed framework with the related schemes that operated in the cloud computing environment to enable secure medical data communication, such as the Kumar Table 2 presents the execution time of various cryptographic operations, such as key generation, signature generation, ECC encryption/decryption, and symmetric cryptographic operations. Table 3 shows the computation cost of the SCB-HC protocol with other relevant protocols. The computation cost of the      proposed protocol is 1.6169, which is slightly higher than the existing protocols. However, our scheme adopts the ECC cryptographic operations, Table 4 shows the communication cost of various components in bits which are not used in any of the existing schemes. Because it uses ECC operations, our scheme is more against the existing scheme. The efficiency of the proposed protocol in each phase is shown with other relevant protocols (52). Figure 2 shows the computation cost in HUP in which our proposed scheme SCB-HC takes 0.339 seconds, which is less than the Li et al. (29) and Kumar et al. (12,23) schemes even though our scheme SCB-HC is more secure compared with existing schemes. Figure 3 shows the computation cost of TUP. It also takes 0.339 seconds, which is less than the existing schemes. Figures 4, 5 shows the computation cost of MRP and LUP, which take 0.0528 and 0.3594, respectively. Only SCB-HC has this phase as it deals with the medi reclaim and lab technician upload phases, and this is the added advantage in the SCB-HC scheme that is not available in any of the existing phases. Figure 6 shows the total communication cost of all the scheme. The total cost of the SCB-HC scheme is 1.6169 s as it includes additional phases MRP and LUP, which are not present in any of the existing schemes. Also, SCB-HC uses ECC encryption and decryption and the ECCDSA signature algorithm, which is more secure and efficient compared with the existing schemes.

Communication Cost Comparison
We analyze the communication cost of the SCB-HC protocol with other relevant protocols. Table 5 shows the communication cost comparison of the various schemes in which SCB-HC has the communication cost of 3,602 bits and other relevant schemes are 3,984, 3,220, and 2,336 bits, respectively. Figure 7 shows the communication cost comparison for SCB-HC with various schemes. The SCB-HC has slightly higher cost compared with the Kumar et al. (12,23) schemes as our scheme has various additional phases and the ECC cryptographic technique, which is not supported by other schemes.

CONCLUSION
We elaborated our suggested methodology for a remote authentication scheme with the smart card-based health care information using the ECC algorithm in the present article. We performed an informal analysis to substantiate the claim that our scheme provides sufficient security while maintaining usability. Maintaining user anonymity also maintains that others cannot access data without prior approval of the file owner. It also supports file integrity with the help of ECCDSA. Furthermore, we show that our proposed protocol is effective in terms of the communication and computation cost in secure cloud storage of smart card-based health care information.
The current work only involves integrating remote authentication with the smart card. In the future, we will focus on designing a smart card with a higher capacity to store large information, such as X-ray films and SCAN images.

DATA AVAILABILITY STATEMENT
The original contributions presented in the study are included in the article/supplementary material, further inquiries can be directed to the corresponding author/s.

AUTHOR CONTRIBUTIONS
SS and KB: conception or design of the work and data collection. SS, KB, and SB: data analysis, interpretation, and drafting the article. NK and GR: critical revision of the article and funding and final approval of the version to be published. All authors contributed to the article and approved the submitted version.