INTRODUCTION
Cloud services [1][2] have been steadily implemented as a vital part of everyone’s life, for the purpose of giving service to users the best and most convenient way, enhancing their experience In other words, it is a wide range of services that provides end-users and organizations access to resources and applications without any additional requirement other than the internet and any device that can connect to the internet (e.g personal computers, smart phones, tablets, and any other IoT devices)
Figure 1.1 Three types of Cloud Services
Source: Realvasi Digital Marketplace (2021) Generally, there are three basic types of cloud services (Fig 1.1): Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS) [3]
SaaS consists of a variety of different services of storage and backups and web servers, as well as project management tools It provides a complete product that is run and managed by a service provider SaaS can be utilized to create a service using existing software solutions without the need to build and maintain one, which in return, people rather view SaaS like an end-user application SaaS is widely used in web-based mail services, office suites, platforms for communications such as team messaging and video conferences, and more, with solutions which are available within SaaS Google Workspace is a popular service that falls into this category, containing a collection of Saas productivity tools, including popular applications like Gmail as a mailing service, Google Docs for document processing, Google Sheet for spreadsheets, and Google Slides for presentation purposes Dropbox and Zoom are also services which operate on SaaS, one being a cloud-based hosting service, giving user storage space on the cloud, the latter being a video conference and collaboration platform for host and joining video meetings
IaaS is a solution for cloud providers who want to manage SaaS tools without having to maintain it themselves, mainly scalability and cost-effective features It provides basic building blocks for cloud IT and access to networking features, computers and data storage spaces It offers scalable and reliable data storage for dynamic management, high performance computing power to effectively analyze large volumes of data and complex calculations, and reliable networking capabilities (e.g virtual networks, load balancers, firewalls, and VPN - virtual private networks) IaaS plays a significant role in handling big data and analytics workloads, with the necessary computing power and storage capability it provides, enabling businesses to make data-driven decisions It maintains all storage servers and networking hardware, eliminating the need for resource-intensive, on-site installations IaaS is widely used in services that provide scalable virtual machine, network and/or storage, one example being Amazon EC2 (Elastic Compute Cloud), one of many features of Amazon Web Service (AWS), implements scalable virtual servers in the cloud, allowing users to run applications and workloads on configurable virtual machine instances
PaaS provides databases, operating systems and programming languages for organizations and users that want to develop their own cloud services With these, it removes the need for organizations to manage any underlying structures such as hardware and operating systems, allowing them to focus on application deployment and management In PaaS, service providers manage the hardware, networking, and operating systems, while developers focus on application development and deployment In details, PaaS provides a preconfigured and managed platforms with necessary infrastructures and tools, a development environment that allows developers to write, test, and debug their applications, managed database services such as relational database (e.g MySQL, SQL Server) or NoSQL databases (e.g MongoDB), which developers can leverage for their applications IaaS also provides scalability for applications, with mechanisms for load balancing and resource allocation, allowing applications to handle varying levels of traffic and different environments without manual intervention Last but not least, IaaS comes with support for collaboration and integration with other systems or third-party services and data sources, further enhancing application development PaaS is found in one of many AWS features, called AWS Elastic Beanstalk It is a fully managed service that makes it easy to deploy and run applications in multiple programming languages, able to handle infrastructure provisioning and auto-scaling
All three of these types of cloud services usually come together within a cloud service to fulfill complete cloud functionality Other than that, there are other types of cloud services Security as a Service (SECaaS) [4] is a group of security-related cloud services which offer cloud-based security solutions, such as Firewall as a Service (FWaaS), Intrusion Detection and Prevention Systems as a Service (IDPSaaS), Secure Email Gateway as a Service, Web Application Firewall as a Service (WAFaaS), and Security Information and Event Management as a Service (SIEMaaS) Last but not least, Content Delivery Network (CDN) [5] is considered as one type of cloud service CDNs are a distributed network of servers located in various geological locations to deliver contents to users fast and efficiently, while also improving website performance, reducing bandwidth consumption, increased availability, and providing better user experience
Figure 1.2 Four different environments of cloud services
Source: Stackscale (2024) Cloud services also come with different environments, depending on the needs: public, private, or a mix of both (e.g hybrid cloud and multi cloud) (Fig 1.2)
Public cloud services are services that are made available for all users SaaS, IaaS and PaaS all provide public cloud services These services are often available to the general public or a large number of customers
Cloud services which the providers do not make it public otherwise are private cloud services These services are widely used by organizations and companies where their data are considered sensitive, for the services are only made available within the organization/company internal server, and are not accessible to external users With the infrastructure and resources dedicated solely for organizations, this environment satisfies organizations with specific compliances, good security, and performance
The mix variation such as Hybrid Cloud is widely used in organizations and companies that want to optimize the cost on their Cloud service needs, whereas mission-critical applications and data are stored in the Private Cloud side, while unusual traffic peaks and services overflowing are processed in the Public Cloud side
A Hybrid Cloud is a flexible environment that integrates and orchestrates services from multiple providers, allowing data and applications to be shared in between
Multi Cloud environment, essentially like Hybrid Cloud but consists of a bigger number of Public Cloud and Private Cloud mixed together It can have as many Public and Private Cloud environments depending on an organization’s requirement An example involves using services from multiple cloud providers simultaneously, such as utilizing AWS for some applications while having Microsoft Azure for others This type of environment offers flexibility and it is getting more common over time, for its purpose being very dependable for large and complex projects that also require more complex solutions However, because of the complex characteristics of the Multi Cloud environment, it demands a special attention to security and management, which can be a challenge to organizations and companies
As organizations increasingly adopt cloud services, understanding their types, features, and environments becomes vital for efficient and secure computing.
Authentication in Cloud services
Authentication plays a crucial role in cloud services by verifying the identity of users seeking access to a service Cloud service providers employ authentication mechanisms to establish trust and determine the legitimacy of user requests before granting access The authentication process safeguards cloud resources, protects user data, enforces access control policies, and ensures compliance with security standards By verifying the identity of users, authentication helps prevent unauthorized access, identity theft, and security breaches, thereby preserving the confidentiality, integrity, and availability of cloud-based systems and data
Authentication serves as a fundamental measure to differentiate malicious users from legitimate users, thereby mitigating potential harm to the system, the organization, and other authorized users It establishes a foundation of trust between cloud service providers and users, creating a secure environment where users can confidently access and utilize cloud services without compromising their data or resources Through robust authentication protocols, cloud service providers can authenticate users and grant access to their services while preventing unauthorized or malicious activities
The authentication process within cloud services typically begins with users initiating an authentication request to gain access to the service This commonly involves a login interface where users input their usernames or IDs along with corresponding passwords This initial step ensures that users possess the necessary credentials to proceed with authentication Additionally, the assignment of static relationships between users and service providers plays a significant role in authentication Defining roles and associating users with specific roles facilitates access control and helps determine the level of user access rights Access control models, such as Role-based Access Control (RBAC), provide a structured framework for managing user roles and granting appropriate access privileges.
Role-based access control for authentication in Cloud services
RBAC has proven to be effective in many scenarios by streamlining access control and minimizing the risk of unauthorized access By assigning users to predefined roles and managing access permissions at the role level, RBAC simplifies the administration of user access rights This promotes scalability and reduces administrative overhead, making it a practical choice for organizations with moderate user populations and well-defined access requirements
However, RBAC faces challenges in cloud service environments where scalability and fine-grained access control are critical In cloud services, which often involve a large number of users and complex data access policies, traditional RBAC implementations may become impractical and inefficient The scalability challenge arises due to the sheer volume of users, roles, and permissions that need to be managed As the number of users increases, maintaining an extensive set of roles and associated permissions becomes cumbersome and difficult to manage effectively
Furthermore, cloud services often require fine-grained access control policies, where access privileges are defined at the level of individual data or resources In such cases, RBAC's rigid role-based approach may not provide the necessary flexibility to accommodate the granular access requirements The proliferation of roles and permissions can lead to a complex and redundant role structure, impeding the system's manageability and hindering efficient access control
To address these challenges, alternative approaches to RBAC have emerged in the context of cloud services (Fig 1.3) These approaches leverage advanced access control models that offer improved scalability and fine-grained control Solutions such as Attribute-Based Access Control (ABAC) [7] and Policy-Based Access Control (PBAC) [8] provide more flexible and dynamic mechanisms for defining access policies based on various attributes and conditions By incorporating attributes such as user characteristics, resource properties, and environmental factors, these models enable fine-grained access control tailored to the specific requirements of cloud services
Figure 1.3 Overview of how RBAC works
Figure 1.4 Fine-grained Access Control described inside a smart healthcare system
Source: Semantic Scholar (2018) Traditional access control mechanisms, such as Role-Based Access Control (RBAC), have limitations in cloud service environments where scalability and fine- grained control are essential (Fig 1.4) To address these challenges, Attribute-Based Access Control (ABAC) has emerged as a more flexible solution ABAC enables access control decisions by evaluating complex rules against users' attribute sets, offering enhanced flexibility and granularity compared to traditional role-based approaches
ABAC operates based on the evaluation of attributes associated with users, resources, and contextual factors during the access request process Users are assigned attribute sets that encompass various characteristics such as name, gender, age, and organizational roles Additionally, attributes can include resource properties like sensitivity levels or classifications, as well as environmental factors like time or location By considering these attributes, ABAC provides a dynamic and context- aware authentication process
The evaluation of complex rules against users' attribute sets forms the basis of ABAC's access control decisions Service providers define rules that specify the conditions for granting access to objects or services These rules consider attribute values associated with users, resources, and the contextual factors relevant to the access request By leveraging attribute-based evaluations, ABAC allows service providers to establish fine-grained access control policies tailored to the specific requirements of cloud services
In the ABAC model, service providers utilize the attribute values associated with users to verify their identities and assign appropriate privileges For instance, within an organization, if a user's attribute set includes a "department" attribute with the value "accountant," the user can be granted privileges to access and manipulate financial data ABAC empowers service providers to enforce access control based on the attributes relevant to the specific service, ensuring that only authorized users with matching attribute values are granted access
The attribute-based approach offers several advantages in cloud service authentication First, ABAC provides enhanced flexibility by allowing the inclusion of a wide range of attributes relevant to the authentication process This flexibility enables service providers to establish access control policies based on specific user characteristics, resource properties, and contextual factors, aligning access privileges with the unique requirements of cloud services
Furthermore, ABAC promotes granular access control by evaluating complex rules against attribute sets This enables service providers to define highly specific conditions for granting access to individual objects or services The fine-grained control offered by ABAC ensures that access privileges are precisely tailored to meet the security and compliance requirements of cloud services.
Privacy problem in Authentication
RESEARCH STATEMENT
The objective of this research is to develop and implement a pseudonym-based privacy-preserving authentication system The system aims to enable users to access services while maintaining anonymity by using pseudonyms instead of their real identities Users have the ability to create and manage multiple pseudonyms, each representing different roles and permissions, which can be used across various organizations and service providers Importantly, these pseudonyms are unlinkable, ensuring that any attempts to correlate them would not reveal the users' real identities, while it can be used along with signing the user’s attributes and credentials to verify validation In case of misusers, these pseudonyms can be used during revoking those users’ access to reveal their identity if needed The service provider can manage these pseudonyms creation policies, such as how many pseudonyms a user can create and manage at a time, and the lifetime of each pseudonym
In the context of authentication for cloud-based services, the pseudonym system offers conditional privacy During the verification process, users are only required to anonymously sign a limited number of attributes with their pseudonyms Their real identities remain hidden, and the attributes used for verification cannot be used to trace or profile them Additionally, the system includes mechanisms for revoking the privacy rights of misusers, allowing a trusted authority to retrieve their real identities if necessary
Compared to systems that lack pseudonym functionality, the proposed pseudonym-based privacy-preserving authentication system minimizes the risk of users' information being compromised By defining and identifying users through pseudonyms instead of traditional authentication methods, the chances of tracing and profiling individuals are significantly reduced
This pseudonym-based privacy preserving authentication system proposed in this paper aims to solve the following problem where:
- The users’ identities and attribute set must not be disclosed before, during, and after using the service Meaning that, users can access and use the services without any concern about disclosing their identity, or at least a minimum of attributes is disclosed but not enough for guaranteed identity disclosure throughout tracing and profiling methods This can be done effectively by generating unlinkable pseudonyms, users can access services and resources without revealing their real identities or disclosing a comprehensive set of attributes
- The verifier does not need to know the users’ real identities nor the whole attribute set, but can still prove trustworthiness through the users’ provided pseudonyms This can be done by acknowledging the users through their pseudonyms and only the required attributes is enough to gain trust and know who are being provided the services, whilst the users can keep their identities disclosed For example, from the first feature where a user provides his/her attributes and pseudonym, the service provider can consider whoever that pseudonym represents to have the valid attributes along with it
- Have an effective revocation process in place to counter and prevent misusers This process comes from the pseudonyms system, where it allows issuing authorities to retrieve a misuser’s real identity Note that issuing authorities still have no right to obtain normal users’ identities if their behavior does not pose a threat to the system.
The notion of identity confidentiality (Pfitzmann and Hansen, 2008)
This work [9] concept relates to preserving the confidentiality of users' identities in various contexts and gives the definition of anonymity Preserving user identity confidentiality and achieving anonymity are crucial considerations in various contexts to protect individuals' personal information from unnecessary disclosure Anonymity refers to the state of an entity within a set of entities being unidentifiable within that set In a large crowd, for instance, it becomes challenging to identify a specific individual, rendering them anonymous (Fig 3.1) The only feasible technique for evaluating the identity of an anonymous entity within a set is through random guessing, which becomes increasingly unreliable as the number of entities in the set grows Consequently, anonymity is effectively maintained when the group consists of an overwhelming number of entities, reducing the likelihood of successful identification using random guessing
Figure 3.1 Illustration of the definition of anonymity
Source: Author Anonymity allows subjects within the anonymous set to interact freely with other entities while keeping their identities concealed During such interactions, the interacting parties are aware that they belong to distinct sets of entities but possess no specific information about each other's identities For instance, in an interaction between representatives from Group A and Group B, both individuals know only that they belong to different groups without disclosing their actual identities
However, applying this concept becomes challenging in service-oriented architectures, particularly when user accounts and sessions need to be maintained over the short, medium, or long term Cloud services, in particular, require certain user information to establish trust and grant credentials for access Additionally, for cases involving malicious users, this proposed approach presents difficulties in identifying and preventing their activities Service providers lack sufficient data to effectively identify and prevent future misuses by such misusers Another limitation arises when the set consists of a small number of entities, making identification of the target entity relatively easy, rendering this approach ineffective in such cases
In service-oriented architectures, striking a balance between preserving user identity confidentiality and providing necessary information for authentication is essential Cloud service providers must retain some user information to establish trust and grant appropriate access credentials However, measures should be implemented to minimize unnecessary data disclosure and protect user identities Balancing these requirements ensures that user privacy is safeguarded while maintaining the integrity and security of cloud-based services.
Privacy-Attribute based credentials (Privacy-ABCs)
Attribute based credential (ABC) is a form of authentication mechanism that allows users to exclusively and selectively authenticate attributes for service access without revealing additional information Originally aimed to enhance privacy and control over personal information in digital transactions, Privacy-ABCs [10] enable users to authenticate without revealing their actual identities or disclosing unnecessary personal information For example, a movie that requires an attribute representing the age value of 18 or over The customer can selectively authenticate his/her birthday and run a proof where “today - birthday > 18” Aside from his/her name and their birthday which were received, no additional information is disclosed These systems integrate attributes in the form of tuples (attributex, value) Within these systems, the users only need to disclose some attributes that they own instead of unnecessarily disclosing the whole attribute set Fig 3.2 illustrates this example:
Figure 3.2 An example of how Privacy-ABCs work, illustrated between two person figures
Source: Author Privacy-ABCs offer selective disclosure, meaning individuals can share specific attributes or claims about themselves while keeping others attributes private This selective disclosure provides individuals with fine-grained control over the information they reveal, minimizing unnecessary exposure of personal data Therefore, within the verification process, Privacy-ABCs focuses on validating the attributes or claims made by the credentials, rather than confirming the individual's real identity This mechanism often relies on cryptographic techniques to ensure the privacy and integrity of the credentials Techniques such as zero-knowledge proofs, digital signatures, and encryption are employed to securely transfer and validate the credentials without exposing any sensitive information
U-Prove [11] is a privacy-preserving technology and cryptographic framework developed by Microsoft Research It leverages cryptographic techniques to enable selective disclosure of information, allowing users to prove certain claims or attributes without revealing unnecessary details There are several aspects that U- Prove based on Privacy-ABCs Such are the features of selective disclosure to protect individuals and their privacy by limiting unnecessary exposure of personal information And the feature of Anonymity and Pseudonymity, which is the fundamental aspect of Privacy-ABCs with minimal linkability between different transactions or interactions U-Prove follows an unlinkable token principle, with a special type of public key and signature encoded within, and the cryptographic
“wrapping” of the attributes prevents unwanted tracking of users through collusion within these tokens
Idemix (short for Identity Mixer) is a cryptographic technology developed by IBM that focuses on privacy-preserving identity management and selective attribute disclosure, giving the user an ability to “transform” themselves into unlinkable credentials, while such credentials only contain their attested attributes Both of these works in general allow users to obtain attributes from multiple issuing authorities while preventing authorities from learning the users’ attribute set
More importantly, Privacy-ABCs provide constructions to enable pseudonym generation and credential revocation, which in turn helps users generate pseudonyms with selected attributes and protect privacy by decoupling transactions from real- world identities, while it helps the system to obtain misusers’ identity in case of misbehavior for future misuse prevention
The main limitation of Privacy-ABCs schemes is that the attribute verification process involves the explicit disclosure of some attribute values Although only some attribute values are disclosed, for some cases, it can be enough to possibly narrow down the user’s identification and profiling process In other words, it still has a small risk of unintentionally disclosing a user’s whole attribute set and their identity from the disclosure of a limited amount of selected attributes.
Attribute-based signature (ABS) and Mesh signature
Attribute-based Signature (ABS) and Mesh Signature are cryptographic primitives that provide advanced signature schemes with unique properties These systems[12] provide attributes that are embedded into the signing keys in the form of descriptive elements Users are only known to hold what specific attributes, without any associated value What we get is signatures that attest not only the identity of the user who signed, but also the attributes that user claimed to be possessing The user who signed will also be in an anonymous state and is indistinguishable from other users whose attributes satisfy the predicate specified in the signature Misusers cannot forge signatures with attributes that they don’t possess even through aiming for collusion
Attribute-based Signature [13][14] is a type of signature scheme that allows the signer to attach attributes to their signature These attributes can be associated with the signer's identity, role, or specific properties This provides fine-grained access control and flexibility in verifying the authenticity and attributes of the signer ABS can be particularly useful in anonymous authentication and attribute-based messaging systems, and in scenarios where access control based on attributes is important, which is part of cloud computing environments It allows for efficient and flexible verification while preserving privacy and ensuring that only authorized parties can access the signed data
ABS proved to be useful in anonymous authentication and attribute-based messaging systems As an advantage, ABS enables users to prove that the embedded attribute set satisfies a predefined boolean function in the form of an access structure Fig 3.3 Illustrates the mechanism of ABS
Figure 3.3 Illustration of how ABS works
Source: Author Mesh Signature [15] is a cryptographic scheme that allows multiple signers to collaborate and produce a collective signature on a document or message It provides a means for distributed signing, where each signer contributes their partial signature, and the final signature is a combination of these partial signatures The distinguishing feature of Mesh Signature is its ability to withstand collusion attacks Even if a subset of the signers colludes and tries to produce a fraudulent signature on a different message, Mesh Signature prevents such attacks by ensuring that all signers must participate in the signing process to generate a valid collective signature
Mesh Signature schemes follow a similar approach since users can prove the possession of attribute sets with respect to a specific access tree structure These schemes, similar to ABS, give the user an ability to sign anonymously This scheme is popularly used in Internet of Things (IoT) technology However, Mesh signature schemes allow collusion between users, where a set of users can jointly sign with collective attributes This feature is undesirable and should be limited by service providers
Compared to Privacy-ABCs in terms of privacy, ABS and Mesh signature can achieve higher guarantees, since the attributes are not disclosed in any way However, the main and important limitation of ABS and Mesh signature is they do not support pseudonymity, which Privacy-ABCs provide.
Attribute-based pseudonymity for privacy-preserving authentication in cloud
The Structure
a Main methodologies i Pseudonyms The proposed scheme uses pseudonymity for the purpose of securing users’ identity, hiding them behind unlinkable pseudonyms This is most important to the purpose of keeping the trust between the users and the service provider From these pseudonyms, the proposed scheme can use it to revoke any misusers detected during the verification process
Pseudonym is a system that partially or totally masks a user’s real identity into another identity that represents that user Other than identities, it can also apply to masking sensitive info and attributes, providing increasing privacy for that user To achieve pseudonymity, it can be done through applying salt to an attribute, hiding part of an attribute value by replacing with a single character, symbol, number, or by removing part of that value completely (for example of a personal home address can achieve pseudonymity by removing all but the city name), or by applying hash, a combination of mentioned methods is also possible In cloud services, pseudonyms are convenient in keeping the trust between service providers and users, by having service providers knowing the users as their pseudonym and assume trustworthiness of that user through that pseudonym, meanwhile the user can keep their anonymity with their pseudonyms The following figure (Fig 4.1, 4.2) explains the functionality of the pseudonym system
Figure 4.1 Illustration of a Pseudonym system
Figure 4.2 Application of Pseudonym System in requesting access
Source: Author The figures explain that the user - named Bob - can use the Pseudonym system to generate pseudonyms While a user can generate an unlimited amount of pseudonyms, this can be limited by service providers, through the amount a user can generate or through giving a lifetime for each created pseudonym Whenever the user requests access, he sends his request along with a pseudonym to the admin From that point, the admin only knows of Bob’s pseudonym identity, and other user’s pseudonyms, and does not know of everyone’s real identity
In this proposed system, pseudonyms will be generated from the user’s attribute and their credential, creating unique and unlinkable pseudonyms, which can be used for signature generation ii Elliptic Curve Cryptography For cryptographic purposes, this scheme generates key pairs based on the Elliptic Curve Problem This problem shows its promise by providing a more solid security solution, given a smaller key pair compared to traditional encryption methods It is considered a very difficult problem, so far there are no efficient methods to solve the problem, but only by trial-and-error (brute forcing)
An Elliptic Curve is a curve that follows the following algorithm:
Source: All About Circuits (2019) Whereas a and b are two constants that define the structure of the curve, while x and y are a set of points which must satisfy the algorithm The following figure (Fig 4.3) displays the curve [17] :
Figure 4.3 Mathematical graph of the Elliptic Curve algorithm
In cryptography, ECC is used to make a key pair of a public key and private key, where private key is a point P The public key can be derived from the private key by scalar multiplication, meaning that point P will be multiplied by k times, then perform the point addiction by drawing the line through point P and point kP, to find the third point intersecting the curve By reflecting the third point against the x-axis, we can achieve the fourth point, which will be the public key.
Component and Interactions in Attribute-Based Pseudonymity For Privacy-
The proposed scheme consists of three main parties: the Certificate Authority (CA), the Verifier (Authentication Server), and the Users The structure and interactions among these parties are as follows:
○ The CA is responsible for generating public values, verification keys, and secret attribute keys
○ It issues credentials to verified users, which contain embedded attributes
○ In case of misusers, the CA has the authority to revoke their privacy rights and retrieve their real identities based on their pseudonyms
○ The Verifier operates on the service provider side and is responsible for verifying signatures sent by users
○ It follows a predefined access tree structure to validate signatures and pseudonyms
○ If any misuse is detected, the Verifier reports the misuser's pseudonym to the CA
○ Users possess valid credentials issued by the CA, including embedded attributes
○ They have the capability to generate their own pseudonyms, providing a level of anonymity
○ Users can request credentials from the Verifier party, indicating their attributes and desired access
○ When interacting with the Verifier, users sign messages with their pseudonyms for verification
Additionally, the proposed scheme allows users to share attributes with other users, enabling attribute-based collaboration or access control among authenticated parties
The following graph summarizes the flow of each sides:
Figure 4.4 Illustration of the general flow between three sides
Source: Author According to the graph (Fig 4.4), the user sends a request to the Certification Authority with their attributes and identity, this can be done through an API call from the client side to the Certification Authority The Certification Authority will generate the key pair and a credential based on the received attributes Then it will send to the User the generated credential as a response from the API With the credential, the User can then generate their pseudonyms, and then uses that pseudonym along with the received credential and pseudonym to generate a signature The user then sends the signature for the Verifier side to check the validity of that signature, by calling an API request to the Verifier In case of invalid signature, the Verifier then sends a report to the Certification Authority (through an API call) to revoke the access rights and disclose a misuser’s identity.
Function flow
The signature scheme of Attribute-Based Pseudonymity For Privacy- Preserving Authentication is composed of the following algorithms: KeyGen, CreGen, Revoke, PseuGen, Sign and SignCheck Such that KeyGen, CreGen and Revoke are being executed by the Certification Authority side, PseuGen and Sign are done by the User, and the SignCheck function is executed by the Verification (or Service Provider) side Each function will have a graph accompanied with, in order to visualize the flow of each function The following graph (Fig 4.5) describe the graph from Fig 4.4 in a functional manner:
Figure 4.5 The graph from Fig 4.4 summarized the processes into function names
KeyGen
This function is done from the Credential Authority side The input is a configurable parameter k that determines the size of the key pairs in bits Using the Elliptic Curve Algorithm, this function generates a private key and a public key The public key can be used to create a credential, while the private key can later be used during SignCheck state It also generates a set of public parameters PP = {G1, GT ,Zp, P, g, h, e(), H()}, which is necessary for later functions The following figure (Fig 4.6) illustrates the flow of this function:
Figure 4.6 Illustration of the KeyGen flow
CreGen
This function is also done from the Credential Authority side This function creates Credentials based on attributes and the public parameters PP, so it requires an attribute list received from the User With the received attributes, along with the public key generated from KeyGen, it generates a credential by hashing the attributes altogether using the public key as the main parameter for hashing After credential generation, the function saves the User’s ID which is linked with that Credential and provided attribute into the Server Database, along with the public key The Generated Credential is to be sent back to the user through a secured network route The following figure (Fig 4.7) illustrates the flow of this function:
Figure 4.7 Illustration of the CreGen flow
PseuGen
This function is executed from the User side With the received Credential, they convert it into a pseudonym with a randomized name, that contains the value of that Credential converted into a string, and the attributes that were used to generate the pseudonym This pseudonym also has its lifetime to along with its availability value, which is currently available, and can be made unavailable through different policies (lifetime or usage time), or by Revoking in case the user is a bad actor The pseudonym will be used for signature generation and later on to be sent to the Verifier side along with the signature for validation The following figure (Fig 4.8) illustrates the flow of this function:
Figure 4.8 Illustration of the PseuGen flow
Sign
This function is executed from the User side for generating signatures Firstly, it checks if the user has any Pseudonym, for it needs the secret value and the components from it If there is none, the function recalls the PseuGen function to generate a new Pseudonym The function combines the value from the Pseudonym and the values generated from Cregen, then executes the signature generation process on the combined values through hashing to create a signature, or can be assumed as a token This signature then is sent to the Verifier side to check for its validity, before granting access to the user, or request a Revoke function if the signature was invalid The following figures (Fig 4.9 to Fig 4.11) illustrates the flow of this function:
Figure 4.9 Illustration of the Sign flow (1/3)
Figure 4.10 Illustration of the Sign flow (2/3)
Figure 4.11 Illustration of the Sign flow (3/3)
Source: Author From the above flow, there exists two phases of access tree construction in order to obtain the set of challenge c and ci Both phases are detailed as the following:
● Phase 1: begin by randomly selecting a share, denoted as sharex, from the set of non-zero integers modulo p (Z*p) For each leaf node x in S′c (representing attributes for which the user lacks the corresponding secret keys) that has not been assigned a secret share in a previous iteration of phase 1, the function BOTTOM_UP_FILLING(x, sharex) is called, which the function is described in IV.4.c This process propagates from the leaf nodes towards the root node, assigning secret shares to the appropriate nodes
BOTTOM_UP_FILLING(node, share)
GET CP={x|xchild(p) and secret(x)0} and let |Cp| be its size
GET threshold gate parameters kp and nump
SET §(kp, nump) for kp points (ind(x), secret(x)) for all x ∈ Cp FOR all x ∈ C′p
GET point (ind(x), sharex) by interpolation from §(kp,nump) CALL algorithm TOP DOWN FILLING(x, sharex) ENDFOR
GET point (0, sharep) by interpolation from §(kp,nump) CALL algorithm BOTTOM UP FILLING(p, sharep) ENDIF
● Phase 2: the algorithm proceeds with TOP_DOWN_FILLING(r, c), where r represents the root node of the access tree structure and c is the challenge obtained from the Sign algorithm The TOP_DOWN_FILLING function operates from the root node downward, utilizing the challenge to determine the secret shares of the nodes in the access tree
TOP_DOWN_FILLING(node, share)
GET Cnode={x|xchild(node) and secret(x)0} and let |Cnode| be its size GET C'node={x|xchild(node) and secret(x)=0}
GET threshold gate parameters knode and numnode
SET §(kp,nump) for kp points (ind(y), secret(y)) for all yCnode
GET point (ind(x), sharex) by interpolation from §(kp,nump) CALL algorithm TOP DOWN FILLING(x, sharex) ELSE
GET point (ind(x), sharex) where sharexZ*P CALL algorithm TOP DOWN FILLING(x, sharex) SET Cnode = {Cnode ∪ x}
SignCheck
Revoke
This function is executed from the Certification Authority It requests the Verifier to provide a misuser’s pseudonym in order to be able to execute the Revoke function Firstly, the function disables the availability of the user’s pseudonym Then it executes the following flow by query against its server database to find whenever the attributes in the database matches the attributes that are used during the pseudonym generation process of that pseudonym The misuser’s identity is returned as a result The following figure (Fig 4.13) illustrates the flow of this function:
Figure 4.13 Illustration of the Revoke flow
Based on the provided information, the signature scheme implementation was conducted using C# programming language with the Bouncy Castle library [18] for elliptic curve construction and the Java math library for big number calculations The tests were performed on a machine setup with specifications of Core i7-4790s, with 8GB of RAM Due to limited resources, the security parameters were set to 8 bits
The tests involved example users with a number of attributes being 100, and was done with 50 attempts The following graph (Fig 5.1) provides the result of such attempts:
Figure 5.1 Result of 20 attempts tested on the system
Source: Author The result showed the consistency of the system when executed, within the time taken mostly up to the average of 500ms, which is a reasonable time.
Correctness
Based on the flow described from the last section, it is assumed correct if the Certification Authority is considered trustworthy, additionally the system is being done and the API communication route is secured, and lastly with the user keeping their credentials secured and not being leaked to third-parties or malicious parties The process is proved to be correct The key pairs are generated through applying ECDLP, then the private key was used to create a Credential along with the attributes During the KeyGen and CreGen process, the public key and the user’s attributes are published to the server, which later supplements for the Verifier for verifying the signature later on After the credential sent to the User it is then used to generate a Pseudonym and a Signature Then that signature is used for verification in
SignCheck As long as the process leading to the generation of signatures is consistent and the generated signature is not altered in any way, then when the SignCheck reconstructs a signature from the public key and attributes collected from the published server for comparison later, then the result will be correct Any alteration to the input signature will be detected and the SignCheck function will request a Revoke action performed to the misuser that committed that alteration The following graph (Fig 6.1) illustrates the needed operation before SignCheck:
Figure 6.1 Summary of the flow that provides input value for SignCheck
Source: AuthorFrom the mentioned assumptions, the system proves to be secured All of the functions are one-way functions, meaning that from the result of each functions, it is not possible to reverse the results to the input values by any means The signatures and pseudonyms are generated and therefore belong to the users, because it is their information generated from their attributes, and should be kept by themselves if possible In the case of a misuser possessing a credential, pseudonym and signature through forging, the misuser does not have the correct key pair for forging the correct signature, as it must be generated from the Credential Authority This also prove the high difficulty preventing the forgery, even unforgeable.
Application
The system is applicable in public services such as public transportation, coupons, medical services Depending on the selected attributes, the Service Provider can validate according to their service’s condition The Service Provider only knows about the Pseudonym sent by the user, that way the users privacy is guaranteed, and the Service Provider has the necessary attributes for verification.
Limitations
a Certification Authorities’ trustworthiness Between the three main parties playing their part within this proposed authentication system, the Certification Authorities hold the responsibility of preserving the system security from getting compromised, which can become the biggest concern of potentially compromising the privacy of other users This is because this party is the one that receives the user’s attributes to generate key pairs and credentials Moreover, assuming the Certification Authorities is trustworthy but curious, there is a considerable potential of information leakages from this party Furthermore, the Certification Authorities could pose a risk to user attribute misuse and mishandling, which is a big security concern for users if they are proven not trustworthy This limitation is also considered the biggest anonymity limitation, although this proposed system is designed with such purposes in mind b Secure channel reliability All of the sending and receiving operations and transactions within this proposed system assumes that it is all performed between secure channels This means the systems may rely on secure communication routes to ensure protection Within environments that lack such channels will make those communications susceptible to attacks such as man-in-the-middle attacks [19] c Credential management
A privacy risk towards the user can also be the cause from the user’s own carelessness By having a user’s ID, the malicious party can generate the credential, therefore a valid pseudonym and signature, which can compromise the user’s privacy. d Keys management From the very first step of authentication, a pair of cryptographic keys are created The key pairs are important in creating credentials and to sign for authentication The management of these created key pairs is also crucial, where the keys should be managed and kept protected adequately, or it will lead to being compromised from malicious sources Although choosing a key management method such as session tokens may prove to be secure due to the fact it expires after a session or a specified lifetime, leakage from third-party sources, outside influences, or an error occurred during the signing process which makes use of such private keys can make the key pairs vulnerable.
Comparison with other works
CONCLUSION
The emergence of cloud services has revolutionized data storage, offering a more convenient and virtually unlimited storage capacity compared to traditional physical devices However, ensuring proper access control becomes a critical concern, particularly for fine-grained access control policies and the need for scalability Numerous approaches have been proposed to address these challenges However, many of them either suffer from significant flaws that are unacceptable in cloud services or lack essential features related to authentication This thesis paper presents a solution for attribute-based privacy-preserving authentication, addressing the need for secure and privacy-aware authentication in cloud services The proposed scheme offers several key advantages over existing approaches Firstly, the scheme allows service providers to authenticate users and verify that their attributes meet the necessary requirements without obtaining sensitive information about the users' identity or complete attribute set This ensures a higher level of privacy protection for users Furthermore, the proposed scheme enables users to generate pseudonyms autonomously, reducing reliance on third-party attribute issuers While it may not offer the same degree of anonymity during the attribute issuance process as previous privacy-ABCs-based works, it eliminates the need for partial attribute disclosure during the verification process The scheme incorporates a secret sharing scheme into the signature construction, facilitating attribute verification while preserving the unlinkability of self-generated pseudonyms This ensures that the attributes remain private and untraceable, enhancing user privacy Additionally, the proposed scheme supports verifiable attribute delegation Service providers can specify which attributes can be shared between users, and the scheme enables verification that non- shareable attributes are not delegated This allows for fine-grained control over attribute delegation and strengthens the security of the system.
RECOMMENDATIONS FOR FUTURE RESEARCH
Based on the presented topic of attribute-based privacy-preserving authentication and the proposed signature scheme, there are some recommendations for future research These recommendations generally aim to inspire further research and advancements in the field of attribute-based privacy-preserving authentication, addressing both theoretical aspects and practical considerations for real-world applications
● Enhancing Efficiency: Investigate methods to improve the efficiency of the signature scheme, particularly in terms of signature generation and verification algorithms This could involve exploring optimizations, algorithmic improvements, or utilizing emerging technologies such as zero-knowledge proofs or secure multi-party computation
● Scalability and Performance: Conduct research on scalable solutions that can handle a large number of attributes and users without compromising performance Consider techniques like parallel processing, distributed systems, or advanced data structures to address scalability challenges
● Formal Security Analysis: Perform a rigorous security analysis of the proposed signature scheme, including both theoretical proofs and practical evaluations Explore potential vulnerabilities, attack vectors, and countermeasures to ensure the scheme's robustness against various threats
● Real-World Deployment and Evaluation: Conduct real-world deployment and evaluation of the proposed scheme in practical settings Assess its usability, performance, and scalability in real-world scenarios, and gather feedback from users and service providers to further refine and improve the scheme
● Usability and User Experience: Explore ways to enhance the usability and user experience of attribute-based authentication schemes Consider user-friendly interfaces, intuitive attribute management systems, and user-centric design principles to encourage adoption and acceptance by end-users
● Cross-Domain Applications: Explore the applicability of the proposed signature scheme in different domains beyond cloud services Investigate its potential in areas such as healthcare, finance, IoT, or social networks, and adapt the scheme to suit the specific requirements and privacy concerns of each domain.
REFERENCES
[1] Red Hat, “What are cloud services?,” Internet: https://www.redhat.com/en/topics/cloud-computing/what-are-cloud-services, Mar 14, 2022
[2] Citrix, “What is a cloud service? – cloud services solutions - citrix,” Internet: https://www.citrix.com/solutions/digital-workspace/what-is-a-cloud- service.html, Dec 4, 2023
[3] Red Hat, “Types of cloud computing,” Internet: https://www.redhat.com/en/topics/cloud-computing/public-cloud-vs-private- cloud-and-hybrid-cloud, Jul 25, 2022
[4] T Nguyen, “Security as a service (secaas) LÀ GÌ?,” Internet: https://cystack.net/blog/security-as-a-service-secaas-la-gi,
[5] omkarthorat10 GfG, “What is a content distribution network and how does it work?,” Internet: https://www.geeksforgeeks.org/what-is-a-content- distribution-network-and-how-does-it-work, Mar 23, 2023
[6] A S Gillis and L Rosencrance, “What is RBAC?: Definition from
TechTarget,” Internet: https://www.techtarget.com/searchsecurity/definition/role-based-access- control-RBAC, Mar 2023
[7] K Casey, “What is attribute-based access control (ABAC)?,” Internet: https://www.okta.com/blog/2020/09/attribute-based-access-control-abac, Sep 29, 2020
[8] NextLabs, “What is policy-based Access Control (PBAC)?,” Internet: https://www.nextlabs.com/what-is-policy-based-access-control, July 31st,
[9] A Pfitzmann and M Hansen, "A terminology for talking about privacy by data minimization: Anonymity, Unlinkability, Undetectability,
Unobservability, Pseudonymity, and Identity Management," Dec 2009, v0.32
[10] J Hajny, P Dzurenda, R Casanova-Marques and L Malina, "Privacy
ABCs: Now Ready for Your Wallets!," 2021 IEEE International Conference on Pervasive Computing and Communications Workshops and other
Affiliated Events (PerCom Workshops), Kassel, Germany, 2021
[11] C Paquin and G Zaverucha, “U-Prove Cryptographic Specification V1.1,”
Microsoft Available: https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/U-
Prove20Cryptographic20Specification20V1.1.pdf Dec 2013
[12] L Jin, Man Ho Au, W Susilo, D Xie, and K Ren, “Attribute-based signature and its applications,” Apr 2010
[13] H Maji, M Prabhakaran, and M Rosulek, “Attribute-Based Signatures *,”
2010 [Online] Available: https://eprint.iacr.org/2010/595.pdf
[14] H K Maji, M Prabhakaran, and M Rosulek, "Attribute-based signatures," in Topics in Cryptology – CT-RSA 2011, A Kiayias, Ed Berlin,
Heidelberg: Springer Berlin Heidelberg, 2011, pp 376–392
[15] X Boyen, “Mesh Signatures How to Leak a Secret with Unwitting and
Unwilling Participants,” 2007 [Online] Available: https://eprint.iacr.org/2007/094.pdf
[16] V Sucasas, G Mantas, M Papaioannou, and J Rodriguez, "Attribute-based pseudonymity for privacy-preserving authentication in cloud services," Jul
[17] M Hughes, “How elliptic curve cryptography works - technical articles,”
Internet: https://www.allaboutcircuits.com/technical-articles/elliptic-curve- cryptography-in-embedded-systems/, Jun 26, 2019
[18] "Bouncy Castle Crypto APIs," Bouncy Castle Available: https://www.bouncycastle.org/ Feb 25, 2024
[19] Safety Detectives, "What Is a Man-in-the-Middle Attack?" Internet: https://www.safetydetectives.com/blog/avoiding-the-man-in-the-middle- preventing-a-common-cyberattack, Jan 4, 2024.