Behavioural approach to operation of access control systems and its vulnerabilities

The goal of this article is to describe behavioural operation of access control systems and to point out some workarounds for some exploitation.

---

Abstract

The goal of access control systems is to limit an access from free to controlled, and to restrict access for unauthorized users. They can be met on daily basis, while man can often be a participant as well. Human societies are organized, hierarchical and with expected behaviour because of controlling the access. This paper deals exclusively with access which is controlled. This is a case in which not every Supplicant is automatically allowed to access the asset, but only those, who are authorized for that type of access. A description of such behavioural system is elaborated throughout the paper. This includes a description of system's environment, user roles, bounds between statuses of user's role and system internal processes. In second part, three examples of attack methods to access control system, which may lead to unauthorized access to asset, are described, illustrated and evaluated.

Keywords: access control; authentication; authorization; accounting; registration

---

Prologue

Controlling the access is quite an old natural phenomenon, old as mankind itself. It deals with protection of wide range of assets, such as valuables, value object, knowledge, information, activity, position in society or organization, human life, etc.

Asset is something whose characteristics lead to be useful and rare, and needs to be protected against misuse and undesirable effects. This protection is provided by access control system.

On the other hand, there is another sort of systems, which does not restrict or control the access and therefore does not do the controlling of the access. This type of systems are not dealt with in this paper.

Access Control System

This sort of system is a form of formalized, organized constellation of elements with their relations between each other, which communicates with its surroundings and behave due its expected strictly defined behaviour. Access control system (or the System) is set of security tools, methods, procedures, legal-administrative measures, directives, notices, regulations and contracts. Access control systems are supported with legislative framework, which permits their usage within its scope (e.g. property law, right to property).

Participating entities

In terms of access control, Entity can be a person, group, organization, computer's running process, etc.
Identity can be defined as a set of attributes which describes one specific Entity (first name, surname, date of birth, sex, height, eyes colour, etc.). Therefore, an Identity is needed for pointing at specific Entity among others.

External
External_entity is an Entity, which is external from the system's point of view. Sometimes it can be referred to as System_user, that is the Entity which uses the system for its own purpose.

In its basic form, access control system is used by these External_entities:

• Authority
• Supplicant

Authority - is an Entity which is an owner of the asset and wants to control/restrict its access. Hence access control system is chosen, installed, set and operated by the Authority, therefore its desired condition for securing the asset is achieved.

Supplicant - is an Entity which wants to access to the asset. For doing so, he enters the access control system and uses its procedures and processes to gain the access to desired asset.

Fig. 1: Access control system with its external Entities

Internal
Beside described External_entities, there are Entities inside the system as well. These are called internal.

As this concept of abstraction of Entity and Identity solely exist and residue inside the System, they are marked with adjective "Virtual".
Virtual_entity bears and owns its Virtual_identity.

---

Basic operation of the System consists of the following activities and tasks:

Setting-up the system:
• - create an ability to access the asset for Supplicant
• - revocation of supplicant's ability for accessing the asset

Operation of the system:
• - protect the asset against unauthorized access
• - allow access to the asset for authorized Supplicants only
  • - log accounting details of every authorized access

---

Further sections are using the following terminology:

• entity - subject external to the System, which is performing in a role
• role - a main character of particular activity/task
• status of the role - current status of role as seen by the System

System itself stores following information:

• Database_of_registered_users - a list of registered users
• Database_of_authorizations - a list of valid authorization entries
• Database_of_accounting - a log with accounting information for all users

Fig. 2: Databases used inside the System

ACTIVITY: CREATING ABILITY TO ACCESS THE ASSET:

setting up the System

Fig. 3: Procedure for creating ability to access the asset

There is an entity of Supplicant, who has the role of Applicant.
Applicant is a role of the Entity which wants to have an access to the specific asset.
Furthermore, role of Applicant's role has three role statuses. This is how the System sees the Applicant. Therefore, Supplicant occurs in all three cases of role status.

(default status): In the beginning, Applicant (represented by Entity of Supplicant) is in a state of External_applicant, who wants to have an allowed access to the specific asset.

After the process of Registration, an image of Applicant (Virtual_entity) is saved into the System which transforms External_applicant to Registered_user.
Registered_user is External_applicant who has undertaken the Registration process.

After the process of Authorization, authorization record is saved in the System, thereafter which Registered_user becomes Asset_user.
Asset_user is Registered_user who has been authorized by Authority in Authorization process for the ability to access specific asset.

These processes are further described in the following sections in behavioural manner:

process: REGISTRATION

Purpose of Registration is to create an object (Virtual_entity) inside the System, which will represent its (usually real) original model (owner) in an authentic way (which in this case means Entity of Supplicant). A user account in the System is created for the Applicant (entity of Supplicant), who has agreed to abide with terms of agreement set by Authority. It is some form of Virtual_entity which is written down in e.g. a list on page of paper, filling cabinet, computer database, etc. Subsequently, this Virtual_entity represents External_entity in the System which means that everything that is made by Virtual_entity is referring to its owner (Supplicant in this particular case). That is due bound between External_entity and Virtual_entity, which is in this case 1:1 (one-to-one).

The Registration per se is a process after which External_applicant becomes Registered_user. This process is basically conditioned by several procedures. During these procedures, several steps are made such as creation of new Virtual_entity inside the System, creation of a new Virtual_identity from registration form, assignment of Virtual_identity to the Virtual_entity, establishment of a method for claiming Virtual_identity (authentication method), approvement of terms of the contract.

After the Registration process, there is a new entry in Database_of_registered_users which contains newly created Virtual_entity of registered user. This entry operates as Virtual_entity which represents Entity of Applicant inside the System. This newly created Virtual_entity contains a set of attributes from registration form used in process of Registration, its Virtual_identity (user identification number, name, address, e-mail contact, login, password, etc.).

process: AUTHORIZATION

Purpose of Authorization is to create traceable entry in form of ordered pair (U_i ; A_j), where:
- U_i is one specific i-user out of set set_Registered_users,
- A_j is one specific j-asset out of set set_Assets.

Existence of such entry will prove that user U_i was authorized to access the asset A_j. There are several ways how to manage this need.

The Authorization itself is a process after which Registered_user becomes Asset_user. This process is basically conditioned by several requirements specified by Authority, which Registered_user undertakes responsibility to abide. Authorization entry is confirmed by Authority. It is a crucial step for ability to get granted access to the asset.

After the Authorization process, there is a new entry in Database_of_authorizations containing Registered_user and specific asset to which access was allowed to be granted to. Only the existence of this valid entry grants permission for Registered_user to do activity within the scope of the authorization (access the specific asset). Doing this, Registered_user becomes Asset_user and can access the asset in accordance with asset user agreement.

---

In some cases, processes Registration and Authorization can be joined into one which allows to grant permission to accessing the asset directly.

After finishing processes of Registration and Authorization, the System is set to control and grant the access for the specified Applicant to specified asset.

ACTIVITY: REVOKING ABILITY TO ACCESS THE ASSET

setting up the System

As processes of Registration and Authorization allow to grant the permission to accessing the asset for specific Supplicant, there are complementary two which cancel this option:

• - deauthorization
• - deregistration

Their behavioural description is as follows:

process: DEAUTHORIZATION

Nature of Deauthorization process is inverse to Authorization. During the process, one specific entry is invalidated or removed from Database_of_authorizations causing to revoke permission for accessing the specific asset for Asset_user. This particular Asset_user will not be able to reach the asset in the following attempts anymore as process Authorization_check will keep on failing. Asset_user is degraded down back to Registered_user as well.

process: DEREGISTRATION

Function of process Deregistration is inverse to the Registration. Its goal is to remove specific Registered_user from the System. During the process, one specific entry of Virtual_entity with its Virtual_identity is invalidated or removed from Database_of_registered_users which represents specific removed Registered_user. After the process, owner of deleted Virtual_entity cannot be authenticated in process of Authentication anymore as he cannot claim his Identity to non-existing Virtual_identity (relationship 1:1).

TASK: CLAIMING THE ACCESS TO THE ASSET:

operating the System

Fig. 4: Procedure for accessing the asset

There is Entity of Supplicant, who has the role of Claimant.
Claimant is a role of Entity which wants to access the specific asset at the moment.
Furthermore, Claimant's role divides into three role statuses. This is how the system sees the Claimant. Therefore, Supplicant occurs in all three cases of role status.

(default status): At the beginning, Claimant (represented by entity of Supplicant) is in state of Anonymous_claimant, who wants to access the specific asset at the moment.

After the successful process of Authentication, Identity of Anonymous_claimant is revealed which transforms Anonymous_claimant to Authenticated_claimant.
Authenticated_claimant is in fact the Anonymous_claimant who has claimed and proven a specific Identity by agreed Authentication method in process of Authentication.

After the successful process of Authorization_check, Authenticated_claimant becomes Authorized_claimant.
Authorized_claimant is Authenticated_claimant who has passed the Authorization_check and is able to access a desired specific asset.

These processes are further described in behavioural manner in the following sections:

process: AUTHENTICATION

Purpose of process Authentication is to prove an Identity of Anonymous_claimant. For properly working access control, it is necessary to determinate exact Identity of demanding Claimant.

Process of Authentication per se is claiming specific Virtual_identity and its proving with a method agreed beforehand. One of its form can be e.g. by submitting login (attribute of Virtual_identity) and secret password which would be known only by owner of Virtual_identity. Submitted data for claimed Virtual_identity are verified against the Database_of_registered_users by the System.
In case of successful match, claimed Virtual_identity has been proven and Anonymous_claimant is transformed to claimed specific Authenticated_claimant in accordance with Registration's binding 1:1-rule.
In case of failure, claimed Virtual_identity has not been proven by Anonymous_claimant and Anonymous_claimant remains in this role status.

In case of failure, claimed Virtual_identity has not been proven by Anonymous_claimant and Anonymous_claimant remains in this role status.

process: AUTHORIZATION_CHECK

Purpose of process Authorization_check is determination of right for accessing the asset for its possessor: if Authenticated_claimant was authorized for accessing the asset. As Authorization_check works solely with Authenticated_claimants, it is a crucial need for proper function of foregoing process of Authentication.

Process of Authorization_check itself is lookup for entry of authorization inside Database_of_authorizations. Lookup verifies presence of valid authorization entry for Registered_user (represented by Authenticated_claimant identified in the previous step) and specific asset which would permit Claimant for accessing desired asset.
As the valid authorization entry is found, Registered_user was authorized to access specific asset, therefore Claimant exists as Asset_user in the System.
In case of failed lookup action, there is an implicit rule of failed Authorization_check resulting in forbidden access for Authenticated_claimant to the specific desired asset.

After successful process of Authorization_check, Authenticated_claimant will become Authorized_claimant in the System. Authorized_claimant is always permitted for accessing desired specific asset.

---

Accessing the asset is an activity which usually immediately follows after successful Authorization_check.

process: ACCOUNTING

Accounting is a process monitoring the asset for access of individual specific Asset_users.

Once access of Authorized_claimant is technically made by e.g. starting downloading the file, beginning the phone call, withdrawing the money from the account, etc., exact time of the access is recorded to the Database_of_accounting along with Virtual_identity of Authorized_claimant, type of specific asset and many other details describing the nature of the access for further logging and accounting purposes.

Result of Accounting process is information about past activities of Asset_user which could lead to further processes such as monitoring, statistics and even billing, etc.

---

ATTACKS AND EXPLOITATIONS

The main task of access control system is to control the access to the assets and grants only those Supplicants, who have been authorized for such action. Therefore, attack is an action or series of actions, which lead to unauthorized access.

Beside brute-force attack (e.g. force to break the jail bars, brute-force attack to Asset_user's password, etc.) which leads to compromised element and broken System as a whole unit, and attacks focused on flawed design (e.g. improper design of authentication algorithm, unencrypted communication, etc.), there are at least two main types of attack to deceive the access control systems:

• - 1 exploitation of Virtual_identity
• - 2 exploitation of Authorization

1_A. using a fake Virtual_identity

Attacker undertakes the Registration process, receives an authorization from Authority and gets ability to access the desired asset which he uses subsequently. However, information from Accounting process points out at Virtual_entity which has not Identity of its original owner. Therefore attacker will gain the access to the asset and e.g. does not need to pay the bill.

Example:
Default status: Eve is interested in accessing to the asset. "Bob" is Identity of fake entity which does not exist.

Method: Eve undertakes the Registration process using fake Identity e.g. "Bob". After that, Bob receives an authorization to access desired specific asset by Authority. In the following steps Eve commences an attempt to access the asset using fake identity of Bob. Passing through the Authentication and Authorization_check processes with Bob's Virtual_entity, Eve gets a granted access to the asset. System monitoring tool solely sees Bob, who claims his right to accessing the asset. As "Bob" is authorized for such an action, Eve gets to the asset. This particular access is recorded by Accounting process to Bob's debit.
Further settlement for using the asset will not succeed as Bob is fake Entity with fictitious name, address, etc.
Eve got to the asset by using this method.

System is prone to mistakes or frauds without proper Identity approval during Registration process.

1_B. misuse/theft of Virtual_identity

Attacker uses someone else's Virtual_identity for accessing the asset. cause: Attacker needs to get Proving_factor for claiming and proving someone else's Virtual_identity during Authentication process.

Example:
Default status: Alice is authorized for the access to the asset. Eve is not registered in the System.

Method: Eve already got Alice's Proving_factor by unspecified way. Eve accesses the asset claiming Alice's Virtual_identity with Alice's Proving_factor. Authentication of Alice is successful and System sees Alice despite Eve's presence in behind. As Alice's role status is Asset_user, this particular access to the asset is granted and Eve gets to the asset in a name of Alice. An Accounting process records this particular access to Alice's debit.
Eve got to the asset by using this method.

Attack of this kind is possible in case that attacker is able to somehow obtain Proving_factor of eligible Asset_user.

2. misuse of Authorization

Attacker is somehow able to authorize himself for ability to access the asset. While claiming the access to the asset, the Systems grants him as he is seen as authorized Asset_user.
Cause: This can happen only if there is a way how to create an entry to the Database_of_authorizations which represents the authorizating right.

Example:
Default status: Eve has been registered in the System, however she has not been authorized for accessing the asset.

Method: Eve is somehow able to create authorization entry in Database_of_authorizations. Afterwards, she claims the access to the asset. She is subsequently authenticated and authorized due that newly created entry, therefore she obtains permission for the access. An Accounting process records this particular access to Eve's debit.
Eve got to the asset by using this method.

For better clarity and documentary purposes it is appropriate to implement some journaling procedure which logs every step made in the settings of the System.

---

DISCUSSION

As seen above, access control system works properly in all three cases in accordance with its function. Despite that, asset was accessed by unauthorized External_entity.

In case of method 1_A, proper precaution could be used as verification and proving methods for Applicant. Therefore Applicant in the Registration process will need to prove his Identity in a trusted manner. This method is not a technical vulnerability of the System but loose option of administrative policy strictness.

Both 1_B and 2 methods were committed outside the System. For that reason, there is an importance for securing elements outside the System as well.

In case of 1_B, there is a need for more effective precautions against the theft of user's Proving_factor.

For another case (2), there is a need for better security procedures with proper constrains of a list of Entities, who can create/modify an authorization entry.

CONCLUSION

The methods described above are only elementary - they can be modified, extended or combined with one another. They do not deal with details such as flaws of specific elements used inside the System (e.g. implementation flaw of encrypting algorithm), neither wrong design of System architecture, nor brute-force attacks.

For proper functions of access control system, it is vital to act in accordance with law during its operation, and use its available tools (such as contracts, agreements, etc.) as particular elements of the System to its advantage. Main reasons are such as contract settlement, protection of property (asset) and identity (Identity of Supplicant).

Every access control system is as secure as its particular elements. All of them should be appropriate to the value of asset they are dealing with, as a quotation about chain's weakest link applies here as well.

In these days, many access control systems are implemented using electronic components, e.g. electronic attendance systems, enterprise ICT systems, computer networks, even different services on the internet. They consist of various architectures with mixed elements, however the principles described in this paper still work inside them in such manner.

Bibliography

[1] VLČEK, L. Podstata bezpečnosti a riadenia prístupu k aktívu. Access Server, 2014, vol. 12, n. 8, p. 1-5. ISSN: 1214- 9675.
[2] BURDA, K.; WIESER, V. Authentication, Authorization and Accounting Infrastructures. In Proceedings of the 6th International Conference on Teleinformatics. 2011. s. 1-2. ISBN: 978-80-214-4231- 3.
[3] NAKHJIRI, Madjid a Mahsa NAKHJIRI. AAA and network security for mobile access: radius, diameter, EAP, PKI and IP mobility. Chichester: Wiley, 2005, xx, 295 p. ISBN 0-470-01194-7.
[4] HASSELL, Jonathan. Radius. Iss. 1. New York: O´Reilly, 2003, 190 p. ISBN 0-596-00322-6.
[5] METZ, C. AAA protocols: Authentication, authorization, and accounting for the Internet. Ieee Internet Computing [online]. IEEE COMPUTER SOC, 1999, vol. 3, no. 6, pp. 75-79.