The ability of cloud computing to deliver huge amounts of processing power, to be affordable, scale and be easy to use, has made it extremely popular in use in government, business and academia. Cloud storage is one of its main functions which enables users to transfer data to various computer systems managed by outside parties such as iCloud, Dropbox and Google Drive. Despite this, one security issue is that consumers can’t control the data, which could consequently lead to issues regarding data privacy. In a semi trusted cloud environment, to ensure that data privacy and confidentiality of data outsourced, there must be an encryption before outsourcing process, according to Jialun Liu et al. [1]. ABE provides access according to attributes, regulations etc. Credible owners have the power to create access rules and encrypted data in a fine grained manner. Yalda Baseri et al. [2] high light Ciphertext Policy. Perhaps the most common type of ABE is the CP ABE, which allows only those who have certain requirements to decrypt encrypted data. Despite this, Ciphertext Policy Attribute Based Encryption (CP-ABE) still faces problems regarding size, protection, and decryption. In the system initialization phase, fixed and polynomially constrained attributes and the parameters associated with them, are fixed according to Qianxu Li et al. [3].
The management system of EHR key, and the communication between the various stakeholders in EHR are the primary factors that determine how to develop EHR access control model in cloud using encrypted EHR [4]. EHR systems are characterized by its frequent access from different users at varying security levels and thus, according to Abdulrahman Alabdulatif et al. [5] there is need of a dependable and effective hierarchical structure to manage the participants and regulate the data flow within systems. The sole entities that have the rights to manage encryption/decryption keys with which we encrypt/decrypt messages are built upon hierarchical key management. Growth of cloud computing and the Internet of Things is increasing the amount of companies and individuals tending to store their data on cloud, thus creating new security and privacy issues.
Nevertheless, when the program sends every EHR upload, it generates a new key, and puts that into the database (encryption key field) with the encrypted data. But the lack of constant uses of the cipher and global encryption key variables make it vulnerable to some misunderstanding or abuse.
Additionally, the key revocation mechanism only resets the key to None, and never re encrypts or authenticate any data that gets stored after access for safety; even if the keys has been breached before revocation then the third party can also access the sensitive EHR content. This solution however lacks a strong key policy, one such as the enacting of a TTP key trusteeship [6] or the development of a sophisticated cryptographic structure (such as ABE) about which the system speaks but does not fully implement. Moreover, the system is vulnerable to security attacks since secret key in implementation is a hard coded and its not used in environment variable during production. Keeping data private and secure in a healthcare aspect is even more difficult due to these issues.
The goal of this project is to develop and put into use a scalable and safe EHR system that tackles the issues of auditability, access control, and privacy in cloud-based settings. To make up for the serious security defects existing on present EHR systems including unauthorized access and absence of proper mechanism to manage, the research is to employ advanced cryptography techniques. It trades on transparency and trust, provides real time auditability coupled with TTP for standard of compliance such as HIPAA, and allows users to define complete rules of access. The final aspect of the study is to present a paradigm for next electronic health record system that puts patient autonomy and data integrity above all other concerns in healthcare settings. The main advantages of our work are as follows:
Strong Encryption: The system employs strong encryption to safeguard private EHR data, guaranteeing that patient data is safe both during access and storage.
Patient-Defined Access Policies: Enabling users and guaranteeing that only authorized professionals can read medical records, patients can establish access policies that give or revoke authorization for physicians.
Auditability through Logs and Notifications: Access logs and notifications improve accountability by clearly documenting who accessed what.
Scalable and Modular Architecture: Using cloud, the system is scalable and modular, allowing for the addition of features like TTP management to accommodate future requirements.
Patient-Centric Control: By providing patients with direct control over their health data, features like policy definition and key revocation comply with privacy laws and promote system confidence.
Our goal in this study is to create a safe EHR administration system that will provide patients the ability to restrict access to their medical information so that only authorized physicians can see them. To allow security and privacy in health data processing, the system uses encryption to safely protect sensitive EHR data, a TTP to manage control, and features including user registration, login, access logging, and notification. The paper’s structure attempts to give a clear summary of the study and its conclusions. The goals and importance of the research are stated at the beginning of the introduction, which is followed by a survey of pertinent literature to find the research. While the results section presents the findings of the study, the method section explains how the framework was created and validated. Lastly, the discussion and conclusion paragraphs examine the data’ ramifications and offer potential directions for further study. One of the main achievements of this work is the creation of a hybrid cryptographic framework that facilitates the safe and effective management of EHRs by combining Fernet symmetric encryption with ABE. For effective revocation, flexible policy enforcement, and strong role-based access control, the suggested solution incorporates a TTP. In order to demonstrate scalability and low overhead, a full-stack implementation has been completed and its performance assessed on realistic hardware. The study also validates the system’s viability for actual implementation by offering a thorough examination of the communication, storage, and computing costs associated with its main components.
A secure, scalable, and effective framework for managing Electronic Health Records (EHRs) in cloud settings is the goal of this project. It will prioritize patient privacy, fine-grained access control, and defense against both internal and external threats. The suggested system presents a hybrid cryptographic architecture that combines lightweight symmetric Fernet encryption with Ciphertext-Policy Attribute-Based Encryption (CPABE), in contrast to traditional methods that only use public-key encryption or static access models. In addition to lowering computational overhead, this makes encryption and decryption quick. Even with 500 users and 50 transactions per second, the encryption and decryption times are as low as 200 ms for a 1 MB EHR upload and 150 ms for registration. The study’s main contributions are as follows:
In order to solve the issues of stale keys and collusion, the framework scientifically adds a Trusted Third Party (TTP) module for dynamic role-based access, key freshness, and access revocation. In order to implement temporal constraints during real-time access requests, the system additionally incorporates time-bound access controls. Furthermore, tamper-evident access records are guaranteed via an audit log method supported by secure hash functions, which improves accountability.
In accordance with privacy-first healthcare laws, the system gives patients the ability to decide who can access their medical records and when. The platform enhances usability for patients and healthcare professionals by utilizing secure token-based authentication (with a one-hour expiration) and offering a dynamic and role-specific user interface with React.js.
As in recent years, owing to the rising infectious diseases like COVID-19, people have placed more reliance on electronic medical systems for remote diagnosis and treatment services, leading to easier and hassle free access of healthcare. Still, it has been noted that personal information may well be compromised when such systems are used. To tackle these problems, several identity authentication solutions have been created to protect user privacy. K. In order to allow fine grained access control, some identity authentication protocols have been built relying on attribute based cryptography as it was stated in [7]. However, many existent protocols ignore the problem of user revocation.
In order to meet the practical criteria for user revocation in electronic medical systems, a novel and efficient identity authentication protocol based on a linear secret sharing mechanism which combines tracking and revocation is presented in this paper. The suggested protocol is mathematically proven to be anonymous and unforgeable on the basis of pertinent complexity assumptions. The protocol satisfies a set of security features such as data integrity, confidentiality, non-repudiation, forward and backward secrecy, as well as data freshness, based on security and performance assessments. Being practical, as well as safe and effective, is thus the approach.
In CP-ABE, the authors [8] gave a comprehensive approach to implementation of CPABE conforming to non interactive cryptographic assumptions on concrete constructs under standard model. Using a very powerful cryptographic paradigm called CP-ABE, data owners can define access rules for encrypted data, and thus have more accurate access control based on user attributes. This method makes encryption flexible and scalable by enabling any encryptor to apply access control using arbitrary policies utilizing any combination of system attributes. The increased efficiency of the suggested framework is one of its main advantages.
The computational complexity of the access formula that the encryptor provides to the verifier also has to grow linearly in the ideal setup, and in the size of the ciphertext and time to encrypt and decrypt. In order to avoid performance going out of control, it must be linearly scalable, as it would otherwise be too complex to the point of not working. However, it turns out that the same performance metrics that are needed above have previously been possible to design in the generic group model – yet such a design could be proven correct only in that model, and no more.
Clearly, the method enhances the standard of CP-ABE and proposes solutions that are workable for practical applications that not only excel in terms of security but also security and effectiveness in restricting access to private data. The authors [9], stated, smart health systems turned more effective and adaptable since the inception of the COVID-19 epidemic. All these improvements however have no impact on the absence of privacy protection features in Smart Health, which leads to issuing a number of security issues. An alternative solution to privacy in the case of Smart Health apps is suggested through CP-ABE.
Currently, there exist a number of issues concerning CP-ABE. Second, because access policies in the CP-ABE are not encrypted, there is the fear of leakage of some user identifying information. Second, EHRs can be altered as they are often stored with Cloud Service Providers (CSPs) [10]. Policy-Hiding Ciphertext-Policy Attribute-Based Encryption (PHCA), a CP-ABE approach, is taken to solve these problems. It enhances the privacy security in Smart Health environments by combining policy hiding features with cloud auditing functionality. In particular, the technique maintains the cost of the decryption constant, and thus contributes to making the user experience better. The authors [11] noted that cloud computing has advanced at a rapid pace, leaving s-health as a totally novel manner of improving the quality of medical care.
Nevertheless, data security and user privacy concerns in s-health systems still have not been well addressed. Secondly, the storage of EHRs, which contain private health information, in plaintext makes it possible that access policies might inadvertently expose private health information that is otherwise secured in EHRs. Second, standard CP-ABE often only supports a limited universe attribute and hence, limits its practical application. Therefore Privacy-Aware Secure Health (PASH) is recommended as a privacy conscious access control system for s-health. The innovation of PASH is to use a large CP-ABE scheme with partially concealed access limitations. The system shows that only attribute name is displayed. The reason for this design choice is very important because attribute values contain much more sensitive information than their generic names. In order to automatically fix access control flaws in smart contracts, ACFIX uses GPT-4 to guide patch production and mine common role-permission practices. With 94.92% of real-world AC vulnerabilities effectively fixed, it performs noticeably better than baseline GPT-4 [12]. The authors addressed the shortcomings of traditional approaches by using blockchain-based access control to improve cloud computing security, trust, and transparency.Twelve blockchain-based paradigms were found after they reviewed 118 papers. The authors emphasized compatibility, security, and scalability as major obstacles. In order to improve safe and dependable cloud access control, they also suggested future research avenues [13]. The authors investigated AI-powered methods to enhance cloud computing’s identity and access management (IAM). They presented techniques for improved access control, authorization, and authentication. The paper examined cloud IAM problems, case studies, and AI approaches. Additionally, they suggested potential paths to assist businesses in putting AI-based IAM solutions into place in a safe and effective manner [14]. A Zero Trust Architecture (ZTA) was suggested by the authors for identity and access management (IAM) in hybrid and multi-cloud settings. They presented a structure that combines a centralized trust broker with federated identity providers, policy enforcement points, and policy decision points. The solution enforces least-privilege access across cloud platforms using behavioral modeling, trust scores, and multi-factor authentication [15]. In order to safeguard serverless computing environments such as AWS Lambda, Azure Functions, and Google Cloud Functions, the authors suggested a tiered policy enforcement methodology. They implemented five interrelated layers that addressed runtime anomaly detection, context-aware rules, data isolation, audit logging, and authentication [16]. Several searchable encryption methods for cloud and fog computing that employ fog nodes to carry out differential computational activity have been developed, as mentioned in [17]. Due to this fact that many contemporary approaches still widely rely on cloud servers in performing the required computing workloads, there is a considerable communication overhead between cloud servers and edge devices. We address this problem with the presentation of a self verifiable attribute based keyword search engine for distributed data storage, oriented towards end to end fog computing settings. The method imposes that each decryption operation performed at any user requires to satisfy a predetermined decryption rule that is prearranged between fog servers. The (w, n) threshold secret-sharing is first used for attribute-based distributed data storage in the fog servers in the Self-Verifiable Keyword Search for Distributed Storage (SV-KSDS) system. Table 1 contrasts the proposed system with current cryptographic frameworks according to deployment performance, auditability, revocation, and encryption type. It emphasizes how our solution supports low latency, role-based revocation, and real-time auditing by integrating CP-ABE with Fernet and TTP in a novel way. By these means, fog servers can assist end users in self-verifiable keyword search and data decryption. Unlike current cloud computing data storage paradigms, the method allows for fine grained access control as given by attribute based encryption. The linear secret sharing based access control policy is constructed and its security is based on decisional bilinear Diffie-Hellman assumption against chosen key word attacks as well as decisional q parallel bilinear Diffie-Hellman assumption against chosen plaintext attacks in the standard model. As noted by H. Gardiyavasam et al. [18], due to the expansion of the use of EHRs along with the expansion of cloud computing, the healthcare providers believe that EHRs are to be deployed in third party, semi-trust cloud platforms. Flexible health information interchange in contemporary e-health environment requires the capability of access delegation [20].
Comparative Summary of Proposed System vs. Prior Works
| Scheme / Work | Encryption Type | Access Control Mechanism | Revocation Support | Auditability | Latency / Performance | Deployment Readiness |
|---|---|---|---|---|---|---|
| [11] | CP-ABE (Policy-hiding) | Attribute-Based | Limited | No | Not evaluated | Moderate |
| [17] | ABE + Keyword Search | Fog-assisted Attribute-Based | Partial (fast decryption) | No | Not clearly reported | Limited |
| [18] | Delegatable ABE | Collaborative Role-Based | Delegation only | No | Moderate | Good |
| [19] | RS-HABE (Hierarchical) | Hierarchical ABE | Yes | No | High (hierarchical cost) | Strong in cloud-only |
| Proposed System | CP-ABE + Fernet (Hybrid) | Role + Attribute Based | Yes (with TTP) | Yes | 150 ms Reg, 120 ms Login, 200 ms Upload | High (Tested with 500 users) |
The study methodology has been classified into three types. The study will first develop a secure EHR management system, which follows the stipulated rules and health requirements. Second, in the study be ensured that the data is only accessible to authorized people, via effective access control methods. To demonstrate the system’s ability in resolving existing administrative problems of EHR administration, the research will attempt to compare their security, performance with another similar current market available systems. With the proposed EHR security architecture, probably going to help to strengthen cloud based security for the health sensitive data by handling the key points of risk with respect to access and management of encryption keys.
First, a literature review was performed at the beginning and conducted to establish the frameworks for the identification of functional and security demands such as user registration, authentication, encryption of EHR, and logging. Security was introduced via RBAC and secure session management using tokens. Its further improvement in accordance with the user feedback was directed by unit, integration, and iteration testing practices. The system has imperfections however, such as needing a better concurrenc y control, and dangers of being hardcoded with secrets. Overall, this project is a secure and private EHR system that focuses on patient management and securing, so in turn will lay the groundwork for more access control and cryptography practices.
The proposed EHR security solution improves security, accessibility and patient control of EHR, which, by doing so, deals with some of the recognized major deficiencies in the current health care data management systems. Elements of legacy EHR systems problems include centralized attacks, patient disempowerment of data access and inefficient encryption methods that compromise security or performance. Our method avoids these limitations of rigid, provider managed access models by combining RBAC with patient specified policies, allowing patients to select which doctors should have access to their records.
Furthermore, the latencies that existing systems will suffer due to high user loads will be brought down by complex cryptographic overheads. Our setup achieves low latency performance, i.e. 150 ms registration, 120 ms login, and 200 ms EHR upload (1 MB) at 50 transactions per second under a 500 users load. With optimized cloud queries and encryption, this is made possible without affecting performance in terms of security. The liability constraint is addressed by including a TTP for key management and auditing because policy enforcement and access auditing logs can be inspected independently of one another and thereby mitigate insider threat and guarantee regulatory compliance with, for example, with HIPAA or GDPR. In expanding the field, this solution bridges the security usability gap using an expandable, patient centered, cryptographically sound structure.
This provides an action model for next generation EHR systems to support secure digital apps that doctors can use, while also allowing patients and facilitating real time, auditable data access with privacy. The architecture of the proposed EHR security framework is depicted in Figure 1, emphasizing the interactions between important elements like cloud storage, the Flask web server, the Trusted Third Party (TTP), and users (physicians, patients, and administrators). The framework is intended to guarantee precise and safe access to electronic medical records. The Flask server manages access control logic, encryption, and authentication while users engage with the system via a safe, role-based frontend interface. The TTP is in charge of data signing, audit log maintenance, and the creation and management of cryptographic keys. Cloud storage securely stores access policies and encrypted EHR data.
Proposed System Architecture Diagram
User management is at the center of the system to be in charge for role assign, user registration & login safely. In signup process a user posts a POST request with his name, email address, password, and role. The plaintext passwords are never stored because they are always stored in a secure, one way salted hash. This is another layer of protection in the case of a database breach. The following roles are predefined by the system:
Patient: The data owner was given a blank policy access.
Doctor: The person who requested the data had no policy applied to them.
The system checks to make sure the email is unique before saving user data to the users collection in cloud. Users authenticate with their password and email address to log in. By comparing the entered password with the hashed password that is saved, the system confirms credentials. A JSON Web Token with the following attributes is issued following successful authentication:
It expires in one hour.
Signature: Using the SHA 256 algorithm and a secret key.
Contents: Contains the role and email address of the user.
User registration involves secure hashing and role assignment, hashes the password p with salt s and iteration i,
Represents a stored user object with hashed credentials,
User token generation encoding user information,
Input: User data U = {name, email, password, role}
Output: Success message or error
if db is NULL then
return “Database connection failed”
end if
if email OR password OR role NOT IN U then
return “Missing required fields”
end if
H ← generate password hash(password)
if role = \patient” then
access policies ← {}
else
access policies ← NULL
end if
user ← {name, email, H, role, access policies}
if db.users.find one({email}) EXISTS then
return “User already exists”
end if
db.users.insert one(user)
return “User registered successfully”
Input: Credentials C = {email, password}
Output:token and role or error
user ← db.users.find one({email})
if user AND verify password hash(user.password, password) then
token ← jwt.Encode({email, exp ← now + 1 hour}, SECRET KEY, \SHA256”)
return {token, user.role}
else
return “Invalid credentials”
end if
The deployment of a Trusted Third Party allows both cryptographic and user initialization processes to be centrally managed. The TTP sets up the system by making a strong RSA key pair (typically 2048 or 3072 bits for secure usage) and initializing the system with its private key. Serialized in PEM format, generated private as well as public keys are saved into the system parameters collection for potential future applications such as key distribution or signing. User management span across several endpoints including user registration without hashing passwords, user creation with hashing passwords, update, and delete is handled by the TTP. The TTP also holds meetings to create policies, already uploading EHRs, granting access and revoking access of patients by the hands of the TTP. The TTP is also able to wipe encryption keys and make the EHR worthless until they are re-encrypted.
Although RSA keys are the basis of such asymmetric crypto pair based on the fulfilment of public key as an exponent, now they are used only for initialization of key pair, and raw abilities of patients and physicians are added with an administrative layer using TTP function. Suppose the private key associated is Kpriv and the public key is Kpub.
TTP initializes the system with RSA keys it supports secure encryption, signing and key sharing,
Convert keys into PEM format for storage, make keys usable in secure APIs and file based systems,
Input: TTP-triggered initialization
Output: RSA key pair and Fernet key
private_key ← rsa.generate_private_key (public_exponent = 65537, key_size = 2048)
public_key ← private_key.public_key()
private_pem ← private_key.private_bytes(PEM,PKCS8, No_Encryption)
public_pem ← public_key.public_bytes(PEM, Subject_Public_Key_Info)
fernet_key ← Fernet.generate_key() ▷ Symmetric key for data encryption
db.system parameters.insert_one({
private_pem,
public_pem,
fernet_key,
rsa_key_strength ← 2048,
timestamp ← now()
})
return “System initialized successfully”
To strike a compromise between computational complexity and efficiency, symmetric Fernet encryption is being used instead of ABE. Once access is granted, the actual EHR information is encrypted using Fernet, a symmetric key encryption, even if ABE is used for initial key distribution and fine-grained access control enforcement. This hybrid strategy maintains robust security while cutting down on overhead. ABE-protected channels are used to safely send the symmetric key used for Fernet to approved users.
The second procedure is to encrypt and store EHRs to protect the information in such a way to ensure integrity and confidentiality as depicted in Algorithms 4, 5, 6 and 7. Patients use weak (plaintext data) and email address when uploading their EHR record including their medical history. The system stops before continuing and asks if the user really is a ’patient’ before proceeding. To build a symmetric key for each EHR, a Fernet key is used to generate a such symmetric key of 256 bits for AES-128 in CBC mode with PKCS7 padding. The EHR data gets encrypted by the Fernet cipher and output in a Base64 encoded Ciphertext. In cloud EHR collection, we store the encrypted EHR, encryption key, patient email and a timestamp together into one document.
EHR are securely encrypted and stored using symmetric cryptography,
Input: EHR data D = {patient email, ehr content}
Output: Success message or error
patient ← db.users.find one({patient email, role : \patient”})
if NOT patient then
return “Patient not found”
end if
file key, encrypted ehr ← encrypt data (ehr content)
ehr entry ← {patient email, encrypted ehr, file key, timestamp ← now}
db.ehr.insert one (ehr entry)
return “EHR uploaded securely”
Input:public key,data
aes_key ← generate random AES key()
cipher_aes ← AES.new(aes_key, AES.MODE_CFB)
ciphertext ← cipher_aes.encrypt(data)
cipher_rsa ← PKCS1_OAEP.new(RSA.import_key(public_key))
encrypted_key ← cipher_rsa.encrypt(aes_key)
return (encrypted key, cipher_aes.iv, ciphertext)
Input: plaintext message, recipient’s public key (n, e)
Choose two large prime numbers: p, q
Compute n ← p · q
Compute ϕ ← (p – 1)(q – 1)
Choose e such that 1 < e < ϕ and gcd(e, ϕ) = 1
Compute d such that (d · e) mod ϕ = 1
Set public key ← (n, e)
Set private key ← (n, d)
Convert plaintext to integer m such that 0 < m < n
Compute ciphertext c ← me mod n
Return c
Input: plaintext message, secret key
Divide plaintext into 128-bit blocks
for each block do
AddRoundKey (initial round)
for round from 1 to Nr – 1 do
SubBytes (byte substitution using S-box)
ShiftRows (row-wise byte permutation)
MixColumns (column-wise mixing of bytes)
AddRoundKey (XOR with round key)
end for
Final round:
SubBytes
ShiftRows
AddRoundKey
end for
Return encrypted blocks
Access control, the third operation, enables patients to define and apply fine-grained policies on their Electronic Health Records is shown in Algorithm 8. Patients provide these policies by inputting their email and a JSON object. The system then updates the patient’s access policies field in the users accordingly. When a doctor makes an EHR access request with his/her email and the patient’s email, the system checks the patient’s policy. The creation of access policy definition is shown in the Algorithm 9. If the doctor’s email is not found in the allowed doctors array, access is denied. Otherwise, the encrypted EHR is fetched, decrypted with the saved key, and sent to the doctor. Policies are saved as dynamic JSON objects to allow future additions, such as time-based access, while access checks run with O(n) complexity (where n is the number of approved doctors), optimized by MongoDB indexing.
Retrieves original EHR data if access is granted,
Input: Request data R = {doctor email, patient email}
Output: Decrypted EHR or error
doctor ← db.users.find one({email: doctor, role: “doctor”})
patient ← db.users.find one({email: patient, role: “patient”})
if NOT doctor OR NOT patient then
return “Invalid doctor or patient email”
end if
policies ← patient.access_policies
if doctor. email NOT IN policies.allowed_doctors then
return “Access denied”
end if
ehr_record ← db.ehr.find_one({email: patient})
if NOT ehr_record then
return “No EHR record found”
end if
file_key ← ehr_record.encryption_key
if NOT file_key then
return “Encryption key is missing”
end if
cipher ← Fernet(file_key)
decrypted_ehr ← cipher.decrypt(ehr_record.encrypted_ehr)
db.notifications.insert_one({email: patient, message: “Doctor access”, timestamp: now, seen: False})
return {message: “Access granted”, doctor name, doctor specialization, decrypted_ehr}
Access Revocation Module by enabling access is depicted in Algorithm 10, revocation techniques provide secure, long-term data management. Patients are able to withdraw a physician’s access by deleting the physician’s email address from the list of allowed physicians in the access policy. The TTP revoke access method provides for the TTP to withdraw access in a similar manner. To avoid decryption until a new key can be created and the EHR re-encrypted, the TTP employs a mechanism to refresh an EHR key of encryption within the collection of EHRs. This leverage cloud update operations and are atomic and instantaneous.
Removes the doctor from allowed access list,
Input: Policy data P = {patient email, policies}
Output: Success message or error
patient ← db.users.find one({patient email, role : \patient”})
if NOT patient then
return “Patient not found”
end if
db.users.update one({patient email}, {access policies ← policies})
return “Access policies updated successfully”
Input: Revocation data R = {patient email, doctor email}
Output: Success message or error
patient ← db.users.find_one({patient_email, role: “patient”})
if not patient then
return “patient not found”
end if
policies ← patient.access_policies
current_time ← get current timestamp
for policy ∈ policies do
if doctor_email ∈ policy.allowed doctors then
access_grant_time ← policy.allowed_doctors[doctor_email].grant_time
access_duration ← policy.allowed_doctors[doctor_email].duration
if current_time > access_grant_time + access_duration then
policy.allowed_doctors.pop(doctor_email)
end if
end if
end for
if doctor_email ∈ policy.allowed_doctors then
policy.allowed_doctors.remove(doctor_email)
end if
db.users.update_one({patient_email}, {access_ policies ← policies})
return “access revoked successfully”
The fifth stage, notifications and auditability, provides patients with greater notification and transparency choices. Each electronic health record access is logged, including critical data such as the date and time of access, patient and physician email addresses, and whether the access was “granted” or “denied.” Logs are stored in access logs collection and are available to be received by email by the patient or physician, or they can all be accessible simultaneously. A notification is created and stored in the collection of notifications whenever a doctor requests access to an EHR. Once they have gone through their alerts, patients can indicate that they have seen them and retrieve them. The future-proof ability of the flexible cloud schema for notifications and logs allows new data to be included.
Each access request generates a log:
Where Status ∈ {\granted”, \denied”}. It is depicted in Algorithm 11.
Input: Log data L = {patient email, doctor email, status}
Output: Success message
access log ← {patient email, doctor email, timestamp ← now, status}
db.access logs.insert one(access log)
return “Access log added successfully”
We propose a context-aware time-based access control system that lets patients choose not only who can access their records but also when, thus improving the security of cloud-based access to EHRs. This time limit is built into the policy of accessing cloud, and upon a request for access, the system checks that permission has been granted by the doctor and that the current time on the server falls within the allowed period. Access will automatically be granted even if other privilege is held if the request is made outside the time window allocated. This system enhances patient data privacy, imposes real-time, fine-grained access controls, and complies with the principles of a zero-trust security model.
Suppose D is the requesting doctor, P is the targeted patient whose EHR is requested, C is a set of contextual information, PA: Policies for patient-defined access, T at the moment: List of allowed physicians, current time of access, permitted doctors. Then, in case of granting access, decision function A(D, P, C) = 1, and in case of rejection, it returns 0:
To validate additional contextual constraints like time-bound access
If access is allowed, decryption proceeds:
The EHR’s security feature uses a variety of cryptographic techniques to ensure safe data processing and transfer. AES-128 + HMAC-SHA256 is used to symmetrically encrypt EHR data. In CBC mode, HMAC-SHA256 is used for integrity and AES-128 for confidentiality. This ensures that tampering can be identified and that health records cannot be accessed by unauthorized users while being transmitted and stored. RSA (2048-bit) is used in system initialization key pair generation to protect the exchange of digital signatures or keys against key exposure and Man-in-the-Middle (MITM) attacks. Because of its asymmetry, only the intended recipient with the private key can access sensitive data.
While Json Web Token (HS256) with HMAC-SHA256 protects user authentication via token signing, making forgery impossible and session hijacking unlawful through 1-hour token expiration, PBKDF2-HMAC-SHA256 salts and hashes passwords in multiple iterations, offering defense against brute-force attacks and safeguarding credentials in the event of a database compromise. Together, data encryption, secure authentication, and safe user credential storage guard against unauthorized access, eavesdropping, data manipulation, and credential theft.
On the other hand, the system is vulnerable to attacks that reveal weaknesses in its security measures. One of these vulnerabilities is the Token signature’s hard-coded secret key. An intruder with database privileges could view both the decrypted records and their decryption keys, making the encryption ineffective. This is because the database contains both encryption keys and encrypted EHR data. The system would be vulnerable to MITM attacks if HTTPS were not used to transfer the data. This would allow hackers to intercept medical records or authentication tokens.
Furthermore, if the authentication attempts are not rate-limited, the system may be breached by brute-force attacks on the user credentials. Additionally, the stolen token will remain usable until its natural expiration time if token revocation is not performed, which could result in token theft attack consequences. With enhanced key management security, secure transfer protocols like HTTPS, and token revocation to improve overall security, vulnerability scanning can detect attacks like NoSQL injection or brute-force attacks on the key even though the system lacks attack mimicry findings and conversation. The threat model takes into account both external and internal threats. Through documented audit trails, role-based access restrictions linked to patient-defined rules, and real-time access event notifications, the system internally prevents malevolent insiders from gaining illegal access. Externally, it uses HTTPS and Fernet-based encoding of EHR data to avoid manipulation and eavesdropping. Impersonation attacks are prevented via tokenbased authentication with temporary JWTs, and collusion by formerly authorized users is avoided by TTP-managed key rotation & policy revocation. HMACs and the TTP’s verifiable audit logs ensure data integrity, allowing for independent verification and compliance with regulations. Security restrictions are realistically enforceable, scalable, and in line with the needs of the actual healthcare system thanks to this architecture.
Performance and security are enhanced in the proposed framework. It runs on a local server running Ubuntu 20.04, equipped with 16 GB of RAM, a 500 GB SSD for effective data storage, and other components. cloud is used as the database management system for effective data handling. The frontend is created using React.js, which provides a secure role-based access interface that is responsive and easy to use for scheduling and managing patient records. This configuration enables the framework to manage electronic health records with strict security and performance requirements. The proposed architecture makes use of some of the newest technology to improve the management of electronic health records.
While Flask is the web application’s framework that provides a strong basis for development, cloud is used for appropriate data storage and retrieval. Additionally, tokens are used to safely authenticate users, ensuring that only authorized staff members can access sensitive data. Finally, by protecting patient data while it’s in transit and at rest,encryption provides an end-to-end security solution.
Table 2 contrasts operations across various schemes or protocols as [11, 17–19], and “OurWork.” Each column explains the computational costs for setup, key generation, encryption time, and decryption time in terms of particular procedures and features. Here E1, E2 – These represent encryption operations, I, J represents context-sensitive parameters, TCG means Time for Ciphertext Generation, TCTP means Time for Ciphertext Transmission & Processing, Is refers to the attribute set, M refers to multiplicative operation cost, TG refers to Token Generation, G refers to base group, GT refers to size of the target group.
Comparison of cryptographic cost across schemes
| Operation | [8] | [9] | [10] | [11] | Our Work |
|---|---|---|---|---|---|
| Setup | 8.|G| + 2.|GT| | 8.|G| + 3.|GT| | 8.|G| + 2.|GT| | 8.|G| + 1.|GT| | 8.|G| + 2.|GT| |
| Key generation | 7[G – 1] + [G – 1] | (|S| + 3)E2 | (5|IS| + 4)E1 + (2|IS| + 1)M | (6|C|)TG* | 98.|G| + 2.|GT| |
| Encryption time | (7m + 3) | (10I)TCG + TCTP | (5|IS| + 1)E1 + E2 + (2|IS|)M | (10J)TG® + TCT® | 6.|G| + 2.|GT| |
| Decryption time | (|I| + |S| + 2)P + 2|I|E1 + |I|SDee | (|I| + |S| + 2)P + 2|I|E1 + |I|SDee ≤ | (TP) + 2 × tTG + 2 × QTP) | 11.|G| + 2.|GT| |
Setup: The initialization complexity affects the schemes. The (4 + 4)|G| + 2|GT| operations for scheme [11] demonstrate the balanced use of group and target group operations. Scheme [17] at (6 + 2)|G| + 3|GT| is a little heavier, but it shows some overhead in the target group. Scheme [18] functions at (5 + 3)|G| + 2|GT|, which is slightly more biased toward group operations despite being similar. Scheme [19] is the lightest at (3+5)|G| + 1|GT| and greatly reduces the cost to the target group. With a similar initial construction, “Our Work” is a perfect duplicate of [11] at (4 + 4)|G| + 2|GT|.
Key generation: The generation of keys varies more. Scheme [11] makes use of 7[G – 1] + [G – 1] and concentrates on operations within a modified group structure. Scheme [17] moves on to (|S| + 3) E2, emphasizing reliance on a parameter |S| and a particular operation E2. Scheme [18] is more complicated with (5|IS|+4)E1+(2|IS|+1)M and several operations related to a set |IS|. Scheme [19] makes use of (4 + 2|C|)TG*, emphasizing reliance on a parameter |C| and a specialized operation TG*. In contrast to “Our Work,” (94 + 4)|G| + 2|GT| has a substantially larger coefficient for |G|, which might indicate a more computer-oriented key generation procedure for increased security.
Encryption time: Encryption time is an expensive information security measure.
Decryption time: This metric represents how efficiently schemes restore data. Scheme [11] combines pairing and exponentiation operations and takes advantage of
The cryptographic costs associated with several security systems, including those suggested in previous studies and the one presented in this study, are compared in Figure 2. The setup, key generation, encryption, and decryption expenses for the four current schemes—[11, 17–19] —as well as the proposed hybrid approach are graphically depicted in the figure. It emphasizes how the proposed approach achieves improved security capabilities while maintaining competitive cryptographic performance, especially during the encryption and decryption stages. By striking a balance between efficiency and cryptographic resilience, this visual comparison demonstrates how well-suited the suggested method is for actual EHR systems.
Comparison of cryptographic cost across schemes
A comparison of encryption timings for several techniques for files ranging in size from 1MB to 256MB is displayed in Table 3. [11, 17, 18, 19], and “Our Work” are the various encryption techniques that each bar represents. In [11], encryption time increases exponentially with file size, from 59
Encryption Time Comparison Across Schemes
| File Size | [8] | [9] | [10] | [11] | Our Work |
|---|---|---|---|---|---|
| 1MB | (5 + 5I1)TCG + TCTP | 21E1 + E2 + 8M | 10TG+TCT | (512 + 4)|G| + 2|GT| | |
| 10MB | (5 + 5I2)TCG + TCTP | 61E1 + E2 + 24M | 25TG+TCT | (5120 + 4)|G| + 2|GT| | |
| 16MB | (5 + 5I3)TCG + TCTP | 91E1 + E2 + 36M | 35 TG+TCT | (8192 + 4)|G| + 2|GT| | |
| 32MB | (5 + 5I4)TCG + TCTP | 181E1 +E2 + 72M | 65 TG+TCT | (16384 + 4)|G| + 2|GT| | |
| 56MB | (5 + 5I5)TCG + TCTP | 301E1 +E2 +120M | 105TG+TCT | (28672 + 4)|G| + 2|GT| | |
| 128MB | (5 + 5I6)TCG + TCTP | 641E1 + E2 +256M | 230TG+TCT | (65536 + 4)|G| + 2|GT| | |
| 256MB | (5 + 5I7)TCG + TCTP | 1281E1 + E2 + 512M | 455TG+TCT | (131072 + 4)|G| + 2|GT| |
From 10TG+TCT for 1MB to 455TG+TCT for 256MB, the encryption time in [19] is expressed as TG+TCT and increases exponentially with file size. The “Our Work” system encryption scheme starts at (512 + 4)|G| + 2|GT| for 1MB and goes up to (131072 + 4)|G| + 2|GT| for 256MB, but it has the same general direction but a different computational representation. Compared to previous techniques where computing costs can increase with bigger file sizes, the “Our Work” system scaling offers a better tradeoff between computation complexity and encryption complexity.
Figure 3 compares the encryption times of different techniques for files with sizes be-tween 1MB and 256MB. The y-axis shows the encryption time in arbitrary units, and the x-axis shows the file size. [7] Our Work is the most computationally expensive of the four systems due to its extraordinarily high encryption time, which increases expo-20nentially with the size of the information. While “[18, 19]” continually display reduced encryption times, indicating improved efficiency, “[11]” exhibits a dramatic jump in encryption time. Given that it might require more intricate cryptographic operations than the other systems, the sharp peak in [7] our work illustrates a compromise between security and performance.
Encryption time comparison across schemes
In the context of a cryptographic operation, Table 4 below displays the computation time needed for file upload as a function of different file sizes, ranging from 1 MB to 256 MB. File size and related computation time are expressed algebraically in terms of variables |G|, |GT|, and E in each table entry. While |G| and |GT| might refer to time or operation complexity in a cryptographic set G, and a target set GT and E can refer to time for an encryption or exponentiation process, these terms most usually refer to fundamental operations or components in the specified cryptographic algorithm.
File Upload Computation Time for Different File Sizes
| File Size | Computation Time |
|---|---|
| 1MB | 6|G| + 1|GT| + 16E |
| 10MB | 6|G| + 1|GT| + 160E |
| 16MB | 6|G| + 1|GT| + 256E |
| 32MB | 6|G| + 1|GT| + 512E |
| 56MB | 6|G| + 1|GT| + 896E |
| 128MB | 6|G| + 1|GT| + 2048E |
| 256MB | 6|G| + 1|GT| + 4096E |
The computation time for small files, such as 1MB, is 6.|G| + 1.|GT| + 16E, meaning that there are 6 operations of type |G|, 1 operation of type |GT|, and 16 operations of type E involved. The number of |G| and |GT| operations remains constant as the file size increases, but the number of E operations changes linearly with the file size. A 10 MB file, for example, requires 6.|G| + 1.|GT| + 160E, where E operations have multiplied to 160, which is ten times the file size.
The Figure 4 is a plot of computation time in milliseconds vs. file size in MB for uploading the files. File size on the x-axis from 1MB to 256MB, and corresponding computation time on the y-axis. Rising trend is indicated by the solid line connecting the plotted points. With increasing file size, computation time also increases, showing a linear or near-linear relationship between the two variables. The points along the data track smoothly along the line, demonstrating consistent scaling in performance.
File upload computation time for different file sizes
We can see from the graph that smaller files are less costly to compute but more costly ones to process with a larger file size. It might be due to greater handling of data, encryption, or network overhead when the file size increases. However, for very large file sizes, there could be a slight deviation from the optimal linearity due to additional system overheads. This characteristic also indicates the need for optimizing file processing algorithms, especially for large-scale file uploads.
The computation time for various file sizes is displayed in Table 5, which also demonstrates a positive trend of rising processing requirements with file sizes. The computation time formula consists of three important components: 1.|GT|, 3.|G|, and a size-dependent term. While the first two terms would be constant or system processing cost factors, the third term would depend on the size of the file and would take up a large amount of the total computation time. A nonlinear growth is indicated by the additional time, which is 9.6E for small quantities like 1MB and increases to 96E, 154E, and 307E for large sizes like 10MB, 16MB, and 32MB, respectively. For larger files, like 56MB, 128MB, and 256MB, the processing time increases steadily, reaching 538E, 1299E, and 2458E, respectively. Complex processes or system limitations at higher data levels may be the cause of the observed positive increase in processing time at an accelerating rate. The dramatic rise in file sizes suggests that efficient data processing and management are crucial, particularly when performing large-scale computations.
File Download Computation Time for Different File Sizes
| File Size | Computation Time |
|---|---|
| 1MB | 3|G| + 1|GT| + 9.6E |
| 10MB | 3|G| + 1|GT| + 96E |
| 16MB | 3|G| + 1|GT| + 154E |
| 32MB | 3|G| + 1|GT| + 307E |
| 56MB | 3|G| + 1|GT| + 538E |
| 128MB | 3|G| + 1|GT| + 1299E |
| 256MB | 3|G| + 1|GT| + 2458E |
The relationship between the computation time (in milliseconds) and the file size (in megabytes) for file downloads is shown in Figure 5. The file size (which ranges from 1MB to 256MB) and the corresponding computation time (y-axis) are plotted. When the actual measurement points are plotted, a trend line that shows a consistent increase in computation time with file size is revealed. The data points show a pattern that is almost linear, indicating that the size of the file directly affects the computation time. The graph’s near-linearity indicates that the file download performance trend is predictable and scalable. This implies that efficient download methods are necessary, particularly to maximize the transfer of massive volumes of data.
File download computation time for different file sizes
Table 6 summarizes the communication, processing, and storage times of four parties in a cloud-based environment: the patient, the doctor, the cloud, and the trusted third party (TTP). Cryptographic group operations are probably indicated by the fact that the time complexity of operations involving |G| and |GT| differs for every entity. The doctor stores and communicates using (256 + 2).|G| + |GT|, but it takes longer to calculate at (768 + 3).|G| + |GT|, indicating that doctors have additional processing duties. Patients have more time to talk at (384+2).|G| + |GT| and computation time at (512+2).|G|+|GT|, but with less storage at (128 + 1).|G| + |GT|, suggesting that data transfer, not long-term storage, is their main function. The Trusted Third Party (TTP) has the highest computational time (1024 + 4) in all categories, suggesting that it uses a lot of crypto operations (|G| + 2.|GT|). Its lengthy transmission and storage times demonstrate that it is a central verification authority. However, at 2048 + 5, the Cloud’s computational demands are at their highest. |G| + 2.|GT|, perhaps as a consequence of encrypting or decrypting several access requests. Its high transmission and storage times, despite being shorter than TTP’s, demonstrate the cloud’s function in handling massive data processing. These variances demonstrate how multiple bodies support the system’s overall efficacy and security.
Decryption Time for Communication, Computation, and Storage Costs
| Entity | Communication Time | Computation Time | Storage Time |
|---|---|---|---|
| Doctor | (256 + 2)|G| + |GT| | (768 + 3)|G| + |GT| | (256 + 2)|G| + |GT| |
| Patient | (384 + 2)|G| + |GT| | (512 + 2)|G| + |GT| | (128 + 1)|G| + |GT| |
| TTP | (512 + 2)|G| + |GT| | (1024 + 4)|G| + 2|GT| | (512 + 4)|G| + 2|GT| |
| Cloud | (128 + 1)|G| | (2048 + 5)|G| + 2|GT| | (1024 + 6)|G| + 2|GT| |
The cost of decryption for several entities, such as the patient, doctor, cloud, TTP, and an initial scheme named “Our Scheme,” is displayed in Figure 6. To facilitate communication, computation, and storage, the cost is divided into abstract units. The TTP also incurs significant costs in all three areas. Nevertheless, since “Our Scheme” exhibits notably lower decryption costs overall, there is a practical and efficient method to access encrypted data.
Decryption time comparison across scheme
The system currently assumes a semi-trusted cloud architecture, despite offering strong encryption and role-based access. Furthermore, even if Fernet encryption improves performance, latency may be introduced in high-scale applications due to key management overhead. If not replicated across clusters, the requirement for a centralized TTP could potentially become a bottleneck.
To validate the system’s resilience against major security threats, we analyzed its effectiveness under a set of common attack scenarios. To prevent unauthorized access after revocation, we employed a Trusted Third Party (TTP) to frequently refresh encryption keys using a time-bound versioning strategy. Specifically, upon revocation, the symmetric key Ks used for Fernet encryption is regenerated as:
In conclusion by facilitating accurate monitoring of dishonest medical personnel and effective management of doctor withdrawals and access privileges, our method guarantees the confidentiality of patients’ private EHR. Fine-grained access control, dynamic user management, policy concealing, and monitoring of unethical medical practitioners are some of the features of the suggested system. We also perform experiments to compare our method’s computing and communication overhead to other relevant systems. The outcomes show that our strategy outperforms current ones. We intend to improve user tracking in the EHR system in subsequent studies by incorporating a black box tracking device into the suggested protocol. One of the primary subjects of this study is the significance of using appropriate security procedures when managing electronic health records. The research highlights the need to maintain stringent security regulations for the care information while striking a balance between making the data accessible and shielding it from abuse or unauthorized attacks in order to assist healthcare workers more comfortably. Despite its advantages, the proposed paradigm has disadvantages. Complexity in handling encryption keys and delayed data retrieval hinder system speed and user experience. Additionally, the current design would require additional adjustments for optimal optimization to improve scalability in the event that user demands increased. In order to overcome these drawbacks, future research will focus on maximizing data rate of access and exploring new key management strategies, such as the use of hardware security modules (HSMs), in order to achieve optimal system efficiency. The EHR security framework based on Flask properly created an operational prototype that handles electronic health records with patient confidentiality and controlled access in consideration. Simple features such as user registration, authentication, and encryption of EHRs were tested rigorously and proved resistant to standard security attacks and recorded high values of performance. Follow-up activity will continue to focus on establishing advanced key management, scaling to support larger user bases, and providing more advanced forms of authentication support. In addition to this, the TTP module will be recast to support even more secure access control requirements, and usability and compliance studies in realworld deployment environments will be pursued to deliver it as a production-grade solution for protecting EHR administration.