USING CAMPUS CARDS IN AN ACS
Option 1. Classical Technology.
Most Access Control Systems (ACS) operate using the first, classical technology.
Advantages:
The primary advantage is the freedom to choose an ACS supplier from a multitude of available options. Furthermore, with such card utilization technology, the university can purchase exclusively “hardware” — access controllers, readers, locks or turnstiles, interface modules, etc. — and then, using an SDK (software development kit), develop its own “mathematics,” meaning its own ACS management software. This yields both savings and valuable experience for the in-house department of software product development and support.
Integration of the ACS with other campus applications is organized strictly at the software level — through automatic synchronization of different databases, adding secondary functions to the ACS functional layout such as time & attendance tracking, video identification/verification subsystems, etc.
Disadvantages:
All access points must have a wired connection with the ACS database (DB) server. Even if a controller provides an autonomous fallback mode in case of communication issues, with the specified volumes of users and university specific operational traits (the ACS database is updated virtually every day), any communication disruptions between the ACS controllers and the DB are highly undesirable.
Due to the wired topology, the cost of the system ends up being quite high; moreover, this is driven not so much by the price of the equipment itself as by the costs of establishing the wired communication channels. Because of this, such systems (with very rare exceptions) begin and end “at the turnstile.” An ACS built according to this scheme rarely includes more than a dozen or two access points.
The specific layout of Ukrainian university campuses, where educational buildings are scattered across an entire city, also significantly complicates (and inflates the cost of) the ACS, since communication channels must meet fairly strict requirements regarding reliability and bandwidth.
Using the card as an identifier harbors another highly serious threat: since the identifier is the non-rewritable (and unencrypted!) ROM code of the card, the carrier will be able to perform its duties in the ACS exactly until the next “group of Chinese comrades” learns to manufacture cards into which any “non-rewritable” serial number can be written… in other words, until they learn to clone the ROM code of the cards. Given that the campus cards we are considering emulate a Mifare Standard RFID card, it can be argued that such a moment has arrived. To ensure a more or less acceptable level of security, the ACS will have to be combined with an additional identification system, for example, implementing two-factor access control using a “card + fingerprint” or “card + video face identification” scheme. Such an option seriously impacts both the cost of the system and its reliability, and as you can imagine, by no means for the better.
Option 2. The Card’s Hard Drive
Let us move on to the second option: the ACS uses the rewritable memory of the card to store the user’s access plan and other information.
In this case, the assigned user access rights are written onto the campus card, and the controller at the access point only needs to read them and independently make a decision to grant or deny access. Storing a list of identifiers in its own memory is no longer required. It is sufficient for it to know the parameters of the specific access point for which the controller is responsible, alongside the real time/date (for the correct operation of access schedules and audits).
Thanks to this approach, communication with the controller database is not required in all cases or at all access points. Undoubtedly, the most critical access points — such as the turnstiles at the entrance or in the most important zones of the campus — must operate in real-time to ensure their live monitoring and management.
Online access points under this technology of campus card utilization play another highly important role: they act as intermediary hubs, passing through which triggers a data update on the user cards. The update works both ways: from the ACS database, access right updates are written to the card (as needed), and from the card to the database, information recorded onto it at autonomous access points is uploaded.
Autonomous access points (more correctly referred to as wireless access points) in this case can be classroom doors, laboratories, departments, service and technical premises, dormitory room doors, and finally, locker locks in a sports complex or swimming pool. Such points are scattered throughout the entire campus, their quantity exceeds the number of entrance turnstiles by orders of magnitude, and running cables to them is either an absolutely unsolvable task or an insanely expensive luxury. But if managing such points in real-time is not a mandatory function (which is the case in the absolute majority of scenarios), the wires do not need to be run! Access rights are read from the card (these rights, let me remind you, are updated every time a user passes through an online access point, meaning at least twice a day, upon entering and leaving the campus), and then the controller independently makes the access decision. It also records the audit trail (the fact of passage) and other information both into its own internal memory and onto the card for subsequent transfer to the ACS database via an online access point.
Such access points can have various hardware implementations: this can be either a classical pairing of “controller – reader – actuator – power supply unit,” or electronic locks, and even miniature electronic cylinders (where the controller, reader, and all other components are integrated structurally). A wide selection of ACS equipment types makes it quite simple to integrate both new and existing room doors into a single unified system, along with various devices (turnstiles and barriers, the aforementioned swimming pool lockers, or, for example, special locks with an anti-panic bar for evacuation exits), and even laboratory equipment, server cabinets, etc.
The systems described allow for the completely free mixing of all the listed equipment types within a single integrated ACS: wired (IP) and wireless, online and offline (autonomous) access points. For each specific task, one can freely choose which type of ACS equipment most adequately fits the set requirements in terms of the “price / functionality” ratio.
When using the technology of writing data to cards, the concept of building an ACS, from which we began examining this topic, will look as follows: the campus card is used to record the user access plan. Concurrently, protecting information against unauthorized reading and/or writing is handled by the ACS itself, relying both on the built-in cryptographic protection capabilities of the cards and on the software features of the ACS management software.
The ACS addresses a fairly wide range of tasks: starting from the “first line of defense,” i.e., organizing security access control to the campus territory or a building/zone, and ending with instructor monitoring questions (thanks to logging the audit trail, i.e., the time/date of opening/closing the lock on a classroom door), laboratories, laboratory equipment, pool lockers, dormitory room doors, etc. Accordingly, the depth of ACS deployment into the campus is entirely unrestricted — neither by time (as most such systems are rolled out in phases, starting with those very entrance turnstiles) nor by the type or quantity of equipped premises and monitored devices.
Thanks to the technology of writing data to the card, an additional opportunity arises for integrating the ACS with other campus applications. The user profiles of the ACS can hold supplementary information: the student’s library card number or their grade book number, the employee’s personnel number for the time & attendance tracking system, and other user identifiers across various campus applications. During initialization (writing) of the access card, additional sectors are created in its memory — and identifiers are written into them.
Following this, the university only needs to install special hardware at the required points (in the reading room, at the department, or at the staff entrance) that reads and decodes the required identifier with its subsequent transfer to the corresponding campus application. That is, the ACS can take upon itself the hardware component of various identification applications, while the applications themselves (software and specialized databases) can be developed by the university itself. This technology allows campus applications to operate with the concept of a “user identifier” rather than a “card identifier” — if a card breaks or is lost, it is simply reissued, and all identifiers previously assigned to the user are restored on it (eliminating the need for constant synchronization of the card identifier database for a very large volume of users).
Disadvantages:
The downsides of systems operating under the described technology of campus card usage, of course, also exist.
Firstly, they are manufactured exclusively outside our country. At the moment, I am not aware of a single domestic system that could write to a card if not the access plan information, then at least a unique user identifier (unlinked to the unencrypted serial number of the card). In the West, however, such systems have been manufactured and used for quite a long time. and it is precisely these that are used as the ACS in the majority of European (and not only European) campuses. The average number of access points in such systems hovers around 600–1,500. However, there are systems that include 4–5 thousand, and sometimes even around 10 thousand access points. The number of users in the DB of such systems can exceed 100 thousand people.
Secondly, one has to state another “disadvantage” — quite often, the development of the project and the implementation of an ACS in universities are handled by companies whose experience is restricted solely to deploying security systems in offices and at industrial enterprises. The urge to use boilerplate design methods and the widespread practice where such companies make their primary earnings specifically “on the wiring” significantly hinder the advancement of this concept. And only if the customer (the higher education institution or university) builds upon the experience of applying an ACS in European campuses and possesses a fairly clearly defined concept for implementing a full suite of campus applications does the university’s ACS stand a chance to transform from an “entrance turnstile” into a system responsible for solving a fundamentally greater spectrum of tasks.
—
A. V. Katrenko
Commercial Director
“Smart Security” (Russia)
){kind=link}