Mutual Authentication Protocol for Role-Based Access Control Using Mobile RFID

.


Introduction
The popularization of computers and the development of network technologies have made the Internet an integral transmission medium for modern information systems.Completeness, security, and confidentiality are the requirements when transmitting information over the Internet.Thorough security mechanisms ensure that only legal users log into remote servers to retrieve services and data.The effective prevention of malicious online attacks is an important issue in information security.With advances in radio frequency identification (RFID) technology, handheld devices with an RFID reader have become more prevalent.As such, users can utilize handheld RFID readers via wireless Internet to obtain the information or services stored within electronic tags.The largest problem of mobile RFID is privacy.Therefore, the protection of users' privacy must be considered when establishing a mobile RFID network.
RFID systems are contactless identification systems that transmit data via radio waves so that large amounts of data can be read without requiring any contact.With modern technological advances, RFID has been applied in numerous industries.Mobile RFID and traditional RFID technologies differ in that the system need not be stored in a fixed location, but can be embedded into a mobile reader, such as a personal digital assistant (PDA) or cell phone.Mobile RFID uses high frequency RFID as a close-range sensor and uses telecommunication services to transmit data.However, the largest issues with this technology are security and privacy for the reader [1].
This study proposes a certification mechanism so that the back-end database can verify readers and authorize them in a mobile RFID architecture.The reader accesses the role-based access control (RBAC) server in a back-end database and receives permission for two-way identification of the database and electronic tag while restricting the number of tag reads and the readable information content.

Relative Works
Electronic tags improve upon traditional barcodes, which are read by a barcode reader via the photoelectric effect, converting light information into electronic information to retrieve the data stored within the code.While barcode recognition requires a close proximity to be successfully read, RFID tags can actively or passively emit radio waves, making them able to be correctly identified within range of the waves.The read distances for RFID differ with the output power and frequency used.As radio waves have a high penetrating power, the contents can be scanned through a barrier such as product packaging.
Recently, mutual authentication protocols in RFID systems were proposed [2,3].In [2], a mutual authentication propocol is achieved with time stamps, hash function function and PRNG (Pseudo-Random Number Generator).In [3], it proposed a lightweight anonymity and mutual authentication protocol.There are some new information security issues of RFID were addressed in [4].However, there is no literature which discusses the topic for both the RFID authentication and RBAC.

RFID Security Requirements
Although RFID is contactless and provides quick recognition, the transmission of information through wireless communications poses a problem with regard to privacy and malicious attackers.Therefore, a safe RFID protocol must meet the following requirements: (1) Data integrity: The RFID should still be able to identify information even if the tag has been attacked and modified.(2) Confidentiality independence: Even if a tag has been compromised and the key is known, it cannot be used to forge other tags in order to deceive the back-end server.(3) User privacy: An attacker cannot use the information sent by a tag to retrieve all the data within the tag to determine its location.(4) Forward secrecy: Even if an attacker is able to compromise a tag and retrieve the data stored within the tag, that information cannot be used to find previously sent data.(5) Protection against replay attacks: Even if an attacker can obtain the legal information sent from a tag to a reader, repeated sending of this data cannot be used to deceive the back-end server.(6) Protection against denial of service attacks: Even if an attacker can intercept or block data to cripple the system, the RFID system can still identify tags normally.(7) Protection against forgery attacks: Even if an attacker illegally obtains some of the information within a tag, it cannot be used to forge a legal tag and deceive a legal reader.

Mobile RFID Technology
Mobile RFID uses a mobile device such as a cell phone or PDA to quickly retrieve data from a product's electronic tag using wireless Internet.As RFID systems have multiple applications, there are a multitude of possible reading environments and applications.Mobile RFID is mainly used when the electronic tag must be used with a mobile reader.Therefore, this study proposes a mobile reader to read tags based on the mobile RFID infrastructure created by Lee and Kim [5].After the mobile reader reads the electronic tag, the embedded middleware sends information to the authentication server (AS), after which the AS, object name server (ONS), electronic product code information service (EPCIS), and service provider send relevant tag information back to the user's mobile reader.
According to the mobile RFID infrastructure proposed by Lee and Kim [5], mobile readers read tags in seven steps (Figure 1).
Step 1: The mobile reader requests to read the electronic tag and receives a reply.
Step 2: The mobile reader reads the information in the electronic tag and sends it to the AS.
Step 3: After AS certification, it inquires the ONS for the detailed information storage address for the electronic tag.
Step 4: The ONS receives the inquiry and sends the electronic tag URL to the AS.
Step 5: The AS retrieves the information in the electronic tag from the object information server (OIS) via the URL.
Step 6: The OIS sends the electronic tag information to the AS.
Step 7: The AS sends the electronic tag information to the mobile RFID reader.According to the mobile RFID infrastructure proposed by Lee and Kim [5], mobile readers read tags in seven steps (Figure 1).
Step 1: The mobile reader requests to read the electronic tag and receives a reply.
Step 2: The mobile reader reads the information in the electronic tag and sends it to the AS.
Step 3: After AS certification, it inquires the ONS for the detailed information storage address for the electronic tag.
Step 4: The ONS receives the inquiry and sends the electronic tag URL to the AS.
Step 5: The AS retrieves the information in the electronic tag from the object information server (OIS) via the URL.
Step 6: The OIS sends the electronic tag information to the AS.
Step 7: The AS sends the electronic tag information to the mobile RFID reader.

Role-Based Access Control
RBAC was introduced in 1992 by Ferraiolo and Kuhn [6] and mainly uses user-role-permission to control user access.Roles are given to users based on their position or work content within an organization.Thus, users indirectly obtain a role-class.When a userʹs position changes, their role is simply adjusted, thus lowering the administrative cost and increasing convenience.Sandhu et al. [7] later improved the model and named it NIST (National Institute of Standards and Technology) RBAC [6].
Recently, RBAC [7][8][9][10][11] has become a hot topic in the field of access control.Compared to normal access control policies, RBAC adds a role between the user and permission.This simplifies changes to user access and lessens the burden for management.
In actual application systems, with a low number of roles, managers can effectively centralize role management, use, and access.However, as systems have become more complex and as the number of roles increases, in a large distributed environment, system management of the relationship between these roles is a difficult problem.Completely relying on centralized management will place a great burden on managers.Entrusting role access in a distributed system can create an RBAC model that allows users to entrust other users with their role-class so that the entrusted user can complete work for the original user, further reducing the management burden.
Entrusting access is an important technology that improves the application of distributed environments.There are three basic elements that make up RBAC: 1. Users that describe role-class.2. Permission that describes the tasks for each role, where the tasks in the system may be abstract.3. Roles that are combinations of users and permissions, with the roles listing users and their respective access.
Access control based on roles includes four elements that each have their own corresponding relationships.These elements are users (USERS), roles (ROLES), permissions (PRMS), which are further divided into operations (OPS), objects (OBS) and sessions (SESSIONS).Each element is explained in further detail below.

Role-Based Access Control
RBAC was introduced in 1992 by Ferraiolo and Kuhn [6] and mainly uses user-role-permission to control user access.Roles are given to users based on their position or work content within an organization.Thus, users indirectly obtain a role-class.When a user's position changes, their role is simply adjusted, thus lowering the administrative cost and increasing convenience.Sandhu et al. [7] later improved the model and named it NIST (National Institute of Standards and Technology) RBAC [6].
Recently, RBAC [7][8][9][10][11] has become a hot topic in the field of access control.Compared to normal access control policies, RBAC adds a role between the user and permission.This simplifies changes to user access and lessens the burden for management.
In actual application systems, with a low number of roles, managers can effectively centralize role management, use, and access.However, as systems have become more complex and as the number of roles increases, in a large distributed environment, system management of the relationship between these roles is a difficult problem.Completely relying on centralized management will place a great burden on managers.Entrusting role access in a distributed system can create an RBAC model that allows users to entrust other users with their role-class so that the entrusted user can complete work for the original user, further reducing the management burden.
Entrusting access is an important technology that improves the application of distributed environments.There are three basic elements that make up RBAC: 1. Users that describe role-class; 2. Permission that describes the tasks for each role, where the tasks in the system may be abstract; 3. Roles that are combinations of users and permissions, with the roles listing users and their respective access.
Access control based on roles includes four elements that each have their own corresponding relationships.These elements are users (USERS), roles (ROLES), permissions (PRMS), which are further divided into operations (OPS), objects (OBS) and sessions (SESSIONS).Each element is explained in further detail below.

‚
USERS: Human beings that interact with the system or artificial intelligence, such as intelligent robots.
‚ ROLES: Work functions or work positions that can be seen as a role within an organization or access control mechanism and are used to determine permissions within a firm.
‚ PRMS: Authority regarding objects in an access machine, including methods of storage and retrieval or operations.
‚ SESSIONS: Duration of role assignment, indicating the start and end times that a user has a certain role.
The corresponding relationships between these elements include User Assignment (UA), Permission Assignment (PA), User_Sessions, and Session_roles.These are explained in detail below.

‚
UA: Users can have more than one role and roles can be assigned to more than one user.Sessions are the unit for access control.During any session, users can only act in one role.Many different roles with different functions simultaneously participate in any session.Conferences include directors, operational managers, marketing managers, and project members.However, for this session, participants may have more than one role.
‚ PA: Roles can have more than one permission, and permissions can be assigned to more than one role.When maintaining the relationships between users and roles and between roles and permissions, users' roles can be changed, added, or removed, effectively changing, adding, or removing permissions.This simplifies work for managers and work systems which, in turn, reduces costs.

‚
User_Sessions: When a user wishes to use the role assigned, a user session is created.A single user can create multiple sessions, but a user session can only correspond to one user.

‚
Session_roles: Session_roles are the roles for the users included in a user session.User sessions can have more than one role and roles can be used in more than one user session.
The hierarchical relationship between roles mimics the actual structure within the organization, such that users can inherit the permissions for each role, reducing management efforts.
Early RBAC was mainly adopted for internal employee access system resources and designed with intelligent agents for a firm's intranet in order to aid in safety control systems where role assignment and permissions could manage access systems.
RBAC can be used on the Internet, where a role-server stores user-role assignments.When users retrieve information, identity is first verified with the role server before the role can be utilized.Then a service request is made with the web server and role information is displayed.Finally, the web server uses role-permission-assignment, the role hierarchy, and relevant restrictions to determine whether this role is permitted to complete the request.

System Architecture and Concept
The RBAC server assigns role-classes to restrict the number of times a mobile reader can retrieve information.This study proposes an RBAC role-class appointment certification protocol that can be used in a mobile RFID network where the back-end database assigns role-classes to readers.When a reader retrieves the permissions given to a role, the reader first verifies the permissions with the back-end database and then reads the electronic tag.The proposed method also authorizes readers, and the number of times one reader retrieves tag information is not affected when other readers read the same tag.

Mobile RFID System Architecture
When an unauthorized reader makes a request to read an electronic tag, it must first undergo two-way verification with the back-end database.The database gives the reader a security certificate and then restricts its working parameters according to the role-class table in the RBAC server which is illustrated in Figure 2.
The RBAC server recognizes the reader's identity to prevent illegal readers from stealing information.In this complex procedure, as RFID readers must be given role-classes, the server must effectively control roles that can read RFID tags.This study proposes that roles serve as keys to authenticate users, assign roles, and manage role keys and user permissions to read RFID tags.If RID1 reads TID1, it needs to acquire the relative role-class to access the information of the tag.We will propose the detailed mechanism in Section 3.3.

RBAC Server Architecture
Before a reader authority is verified with the back-end database, it must first be certified by the RBAC server and retrieve its permissions from the role-class table in the RBAC server to know its executable actions.
Figure 3 shows the process by which the server determines role-class for users.When a user uses the mobile RFID, the back-end database certification system and the RBAC database permissions table determine that user's role-class.
For a reader to read an electronic tag, after it is certified by the back-end database, the assigned role-class along with the maximum number of reads can be used to determine the reader's RID1 and TID1 role and permission level.When a reader receives certification from the back-end database, it is also given a role-class level and a maximum number of reads.When a reader reads an electronic tag, one read is sent to the tag and removed from its maximum number of reads.The RBAC server recognizes the reader's identity to prevent illegal readers from stealing information.In this complex procedure, as RFID readers must be given role-classes, the server must effectively control roles that can read RFID tags.This study proposes that roles serve as keys to authenticate users, assign roles, and manage role keys and user permissions to read RFID tags.If RID 1 reads TID 1 , it needs to acquire the relative role-class to access the information of the tag.We will propose the detailed mechanism in Section 3.3.

RBAC Server Architecture
Before a reader authority is verified with the back-end database, it must first be certified by the RBAC server and retrieve its permissions from the role-class table in the RBAC server to know its executable actions.
Figure 3 shows the process by which the server determines role-class for users.When a user uses the mobile RFID, the back-end database certification system and the RBAC database permissions table determine that user's role-class.
The RBAC server recognizes the reader's identity to prevent illegal readers from stealing information.In this complex procedure, as RFID readers must be given role-classes, the server must effectively control roles that can read RFID tags.This study proposes that roles serve as keys to authenticate users, assign roles, and manage role keys and user permissions to read RFID tags.If RID1 reads TID1, it needs to acquire the relative role-class to access the information of the tag.We will propose the detailed mechanism in Section 3.3.

RBAC Server Architecture
Before a reader authority is verified with the back-end database, it must first be certified by the RBAC server and retrieve its permissions from the role-class table in the RBAC server to know its executable actions.
Figure 3 shows the process by which the server determines role-class for users.When a user uses the mobile RFID, the back-end database certification system and the RBAC database permissions table determine that user's role-class.
For a reader to read an electronic tag, after it is certified by the back-end database, the assigned role-class along with the maximum number of reads can be used to determine the reader's RID1 and TID1 role and permission level.When a reader receives certification from the back-end database, it is also given a role-class level and a maximum number of reads.When a reader reads an electronic tag, one read is sent to the tag and removed from its maximum number of reads.For a reader to read an electronic tag, after it is certified by the back-end database, the assigned role-class along with the maximum number of reads can be used to determine the reader's RID 1 and TID 1 role and permission level.When a reader receives certification from the back-end database, it is also given a role-class level and a maximum number of reads.When a reader reads an electronic tag, one read is sent to the tag and removed from its maximum number of reads.A two-way security mechanism was designed for the back-end database and reader to give the reader a security certificate and a role-class.Table 1 shows the symbols used in the certification mechanism, and Figure 4 shows the reader safety certification mechanism.Readers must obtain a security certificate from the back-end database and send the command for the electronic tag to the RBAC server to obtain a role-class.Readers obtain role-classes and security certificates from the RBAC server in the back-end database.

Mobile RFID System Architecture
A two-way security mechanism was designed for the back-end database and reader to give the reader a security certificate and a role-class.Table 1 shows the symbols used in the certification mechanism, and Figure 4 shows the reader safety certification mechanism.Step 3.3: The RID, random number r 2 , initial tag time stamp TS 1 , reader security certificate Cert R , role-class, and K y are used to create M 3 , which is sent to the reader.The RID, random number r 1 , role-class, and K x are used to create M 4 , which is sent to the electronic tag Step 4: The reader receives M 3 and uses K y to decrypt random number r 1 , initial tag time stamp TS 1 , reader security certificate Cert R , and the role-class.TS 1 and r 2 are used in a hash function to create M 5 The reader must first be authorized by the back-end database before it is given a security certificate.Then, after certification with the back-end database, it can read the electronic tag.In this mechanism, the back-end database first verifies the reader to permit it to read the electronic tag information.The proposed method authorizes readers, and the maximum number of times one reader can retrieve tag information and the updated time stamp are not affected when other readers read the same tag, in order to increase security.Figure 5 shows the architecture for the maximum number of reads and time stamp updating.Every reader has its allocated reading amount.If a reading is requested, the allocated reading amount will decrease by 1 time.The detailed mechanism is illustrated in Figure 6.The reader must first be authorized by the back-end database before it is given a security certificate.Then, after certification with the back-end database, it can read the electronic tag.In this mechanism, the back-end database first verifies the reader to permit it to read the electronic tag information.The proposed method authorizes readers, and the maximum number of times one reader can retrieve tag information and the updated time stamp are not affected when other readers read the same tag, in order to increase security.Figure 5 shows the architecture for the maximum number of reads and time stamp updating.Every reader has its allocated reading amount.If a reading is requested, the allocated reading amount will decrease by 1 time.The detailed mechanism is illustrated in Figure 6.After receiving security authorization, the reader reads the electronic tag and the tag automatically updates the time stamp and uses the shared key to send it to the back-end database.The role-class is compared to the internal table to confirm executable commands, and the remaining number of reads is sent back to the reader.After the reader is given a security certification from the back-end database and reads an electronic tag, the database notifies the reader of the remaining number of reads and the updated time stamp.These are then recorded in the back-end database.Figure 6 shows the mechanism for the number of reads and RBAC role-class certification.After receiving security authorization, the reader reads the electronic tag and the tag automatically updates the time stamp and uses the shared key to send it to the back-end database.The role-class is compared to the internal table to confirm executable commands, and the remaining number of reads is sent back to the reader.After the reader is given a security certification from the back-end database and reads an electronic tag, the database notifies the reader of the remaining number of reads and the updated time stamp.These are then recorded in the back-end database.Figure 6 shows the mechanism for the number of reads and RBAC role-class certification.We conclude the performance of Figure 4 and Figure 6 in Table 2.The first number represents the execute times in Figure 4 and the second number represents the execute times in Figure 6.

The Performances
of Figure 4 and Figure 6 Tag

Security Analysis
Below is an overview of the security analysis performed for the mechanism proposed in this paper.
(1) User privacy: As the encrypted data sent was calculated using the random numbers generated Step 5: M 4 and M 5 are sent to the electronic tag.The tag can check the correctness of M 5 using TS 1 and r 2 which were obtained by decrypting M 4 .Therefore, the tag authenticate the reader Step 5.1: One is subtracted from TC n to become TC n´1 Step 5.2: TS 1 is verified as the initial time stamp sent from the electronic tag.If it is, it is updated to TS 2 Step 5.3: TS 2 , TC n´1 , r 2 , and K x are used to create an encrypted M 6 , which is sent to the reader Step 6: The reader receives M 6 Step 6.1: K y , Cert R , r 2 , and M 6 are encrypted to create M 7 , which is sent to the back-end database Step 7: The back-end database receives M 7 Step 7.1: After receiving M 7 , K y is used to decrypt M 6 , Cert R , and r 2 .If Cert R verifies the reader is authorized, K x is used to decrypt M 6 to retrieve the updated time stamp TS 2 Step 7.2: The back-end database uses K y to encrypt M 8 Step 8: The reader receives M 8 Step 8.1: The reader uses K y to decrypt TS 2 , TC n´1 and r 2 .r 2 is checked to ensure that the signal is sent from the back-end database We conclude the performance of Figures 4 and 6 in Table 2.The first number represents the execute times in Figure 4 and the second number represents the execute times in Figure 6.

Security Analysis
Below is an overview of the security analysis performed for the mechanism proposed in this paper.
(1) User privacy: As the encrypted data sent was calculated using the random numbers generated from the electronic tag and reader, r 1 and r 2 , the values were untraceable.Moreover, attackers cannot have the tag key to determine the tag identity.Data is anonymous and untraceable, providing user privacy.(2) Non-linkability: Tags create different random numbers for each reading.Thus, all response values are different, making it impossible for attackers to determine whether data was sent from the same tag.(3) Confidentiality: In the proposed mechanism, each tag's key is shared with the back-end database.
If the reader is not authorized, it cannot read the electronic tag because it does not have the tag key.(4) Data integrity: The tag reduces the number of reads based on the data sent from the reader and uses the shared key to encrypt this data before sending it to the reader.Readers must send a certificate to the back-end database to verify its legality.The time stamp and number of reads are only sent to the reader after verification to ensure data integrity.(5) Protection against replay attacks: As the data sent from the tag M n is calculated using the random numbers generated from the reader r 2 and the tag r 1 , and r 2 is different during each read, even if an attacker captures data sent from a tag, they are unable to resend the captured data.

Conclusions
The security of mobile RFID reader privacy was investigated in this study.The back-end database gives a security certificate Cert R to a reader which allows it to send data to the back-end database when reading an electronic tag, verifying the reader's security and ensuring privacy for the mobile RFID reader.Certified readers also receive a role-class from the back-end database which includes a maximum number of reads and a list of executable commands.The entire process of secure transmissions via the back-end database ensures anonymity and user privacy and prevents unauthorized readers from conducting denial of service attacks.
As this mobile reader architecture is not limited to a fixed operating connection, the security considerations extend beyond insufficient computing resources for electronic tags to the security issues associated with traditional RFID arising from any tag being able to be read from a mobile reader.As mobile RFID readers are easily acquired, they may be used for malicious attacks.Introducing a security certification mechanism to mobile RFID can help remedy these shortcomings.

Figure 1 .
Figure 1.The steps of reading tags for mobile readers.

Figure 1 .
Figure 1.The steps of reading tags for mobile readers.

Figure 2 .
Figure 2. The diagram of role-class assignment.

Figure 2 .
Figure 2. The diagram of role-class assignment.

Figure 2 .
Figure 2. The diagram of role-class assignment.

3. 3 .
Mobile RFID System Architecture 3.3.1.Reader Security Certificate and Role-Class ArchitectureReaders must obtain a security certificate from the back-end database and send the command for the electronic tag to the RBAC server to obtain a role-class.Readers obtain role-classes and security certificates from the RBAC server in the back-end database.

Figure 4 .
Figure 4.The reader safety certification mechanism.

Figure 4 .
Figure 4.The reader safety certification mechanism.

Figure 5 .
Figure 5.The architecture for the maximum number of reads.

Figure 5 .
Figure 5.The architecture for the maximum number of reads.

Figure 6 .
Figure 6.The mechanism for the number of reads and RBAC role-class certification.

Figure 6 .
Figure 6.The mechanism for the number of reads and RBAC role-class certification.
n Encrypted value using the shared keys K x and K y3.3.2.Number of Reads and Time Stamp Updating

Table 2 .
The mechanism performance.

Table 2 .
The mechanism performance.