Wireless ACS.
Over the past few years, we have all witnessed a global trend — the rejection of wires. Of course, primarily in the information sphere. Wireless technologies have one undeniable advantage compared to the classic method of transmitting data via cable — they do not limit your freedom. Freedom of movement and freedom of receiving information. This alone was enough to ensure the necessary level of user interest in such technologies (and the subsequent investment in research).
Over time, this trend has come to the security equipment industry (SEI): first, we saw several types of wireless sensors (fire and security) appear on the market — followed by wireless controllers and entire systems (again, fire and security). Today, we see cautious experiments with wireless transmission of video from surveillance cameras. And only such a section of the SEI industry as access control has remained the last stronghold of wired security systems until recently. More precisely, this is the situation on the Russian SEI market.
The reason for this is precisely the widespread myth that wireless ACS do not and cannot exist. Moreover, this myth has long since acquired the status of an axiom in the minds of a significant number of security specialists that does not require proof. The worst thing is that many developers of Russian ACS think so, and it is they who determine the development vector of this market sector in Russia and the balance of power in it.
In this case, we consider only universal or network ACS designed to control a fairly large number of access points with the possibility of centralized management/control. We do not take into account autonomous ACS for one or two doors and further by the term ACS we will understand precisely universal and network systems.
So, since the axiom about the impossibility of creating/existing wireless (and universal) ACS has been called a myth, we will try to prove that such a bold statement has sufficient argumentation.
To prove this, as is often done in mathematics, we will break the general problem into several smaller ones. More precisely, since we are talking about wireless, we will break all the wires that are currently used in ACS into subclasses and try to prove that they can be eliminated.
As is known, any (of those considered in this article) ACS consists of a control complex and access points. The access point (one or more) is controlled by an access controller connected to the control complex (ACS database) by a trunk communication channel.
In turn, the controller is connected (by wires) to the so-called harness: to the reader (readers) of access identifiers, exit buttons and sensors, magnetic locks or other actuators. And finally, the controller needs power (i.e. a 220 V power line, where the controller's power supply will be connected, or a separate 12 or 24 V line).
One interesting fact: many Russian ACS developers admit that they have worked on the idea of wireless ACS (especially in light of the active and widespread transition to IP technologies) in one way or another. However, it turned out that they all considered the transition to a wireless state exclusively for the ACS backbone, without even theoretically considering other «classes» of wires in the ACS. As a result, they came to an obvious conclusion: since the controller with the harness will not be able to be connected wirelessly in the near future and power to the controller cannot be transmitted over the air, there is no point in working on wireless ACS at this stage of technology development.
As a result, we have 3 fundamentally different «classes» of wires used in ACS. And to get that very wireless ACS, you need to get rid of all three.
Myth 1. It is quite easy to convert the ACS backbone to wireless mode — just take IP controllers and connect them to the ACS database via WiFi. However, such a backbone is unreliable, it can be opened or disabled, thereby either gaining unauthorized access to the facility or blocking the operation of the access system.
If we accept the first part of this opinion (that a wireless backbone can be made via WiFi and only WiFi) as an axiom, we will also have to agree with the second part: indeed, wireless networks are wireless because physical contact of wires is not required to connect to them. That is, an ill-wisher with the appropriate equipment can either try to connect to your network or disable it using a jammer. In theory, this applies to any wireless technology, but to WiFi in particular. And this assumption is most often based on the prevailing opinion that due to the ubiquity of WiFi networks, it is quite easy to connect to them thanks to “enthusiasts” who do this almost with their eyes closed and post methods of such illegal actions on the network.
Let's not get into the thick of the debate about the ease of cracking WiFi network access passwords — this is a question for computer network security specialists.
Instead, let's discuss the default technology choice itself: WiFi.
Of the most common wireless data transfer methods today, only WiFi seems to be an adequate contender for the role of the basic technology for the ACS backbone. Bluetooth has a limited range, GSM or 3G networks are too expensive (you either have to pay the operator for traffic, or try to deploy your own local GSM network, which may be an absolutely unsolvable task due to problems with frequency registration). There are also WiMAX or 4G networks, but they de facto have the same disadvantages (in this particular case of their application) as cellular networks. Unlike them, WiFi networks in most cases do not require registration, there is a huge amount of equipment on the market for building such networks, and you do not have to pay for traffic. Plus, such networks have a sufficient data transfer rate (which distinguishes them favorably from the above technologies) so that the speed of some remote (from the ACS server) controller would be comfortable for the user.
It is necessary to take into account another very important advantage of WiFi: if the developer of the access control system already has IP controllers, he does not need to do anything. Take a standard access point — and here it is, a wireless backbone.
The other side of the coin is the same security problems we talked about. Even if an attacker cannot connect to a WiFi network (with a properly built network, this is not as easy as it seems), he can try to disable it using a jammer, thereby forcing the facility's security to simply turn off the ACS and switch to manual control mode to ensure more or less normal operation of the facility. And only then try to gain access to the facility, but this time using human weaknesses.
This possibility is based on the assumption that without a backbone (normally functioning) the ACS will not be able to work for at least a fairly long time. Of course, in universal ACS, in the event of a loss of connection with the DB, the controllers will automatically switch to an autonomous mode and will function according to the data that they managed to save in their memory at the time of the loss of connection. However, any changes in terms of user access in this case will become impossible.
And yet, alternatives exist. Only to see them, it is necessary to take a slightly broader look at the functions that the backbone performs and determine their priority.
The main task of the backbone is to update the access matrix in the memory of the ACS controllers (i.e. the table in which each user access identifier is assigned the access points allowed to him — doors, turnstiles, etc.). And, of course, the backbone is responsible for monitoring and managing the access points (controllers) in real time.
Why not separate these functions?
For example, why not shift the task of updating the access matrix to the user card?
Traditionally, in all ACS, the card is considered only as an identifier. All that is required from the cards is the presence of some non-rewritable code, preferably unique and with a guarantee of the impossibility of cloning. However, for quite a long time now there have been cards that, in addition to the identifier (where would we be without it), also have rewritable memory, quite sufficient for storing data on user access and any additional information. In this case, the controller does not need to «know» the user's identifier in advance. It is enough for it to read the data directly from the card at the moment the user passes and compare it with the data in its memory. And make a decision based on this comparison. Users will bring their own access matrix! This technology of transmitting information via a card is called data-on-card (data on the card).
Rewritable cards (the same MiFare, for example, although the list of suitable cards is far from limited to this technology) have quite serious hardware capabilities for protecting the information stored on them — even if the card is contactless, you can access it at very short distances (unlike the same WiFi network). Plus, data encryption algorithms built into the operating system of the cards. If this is not enough, no one prevents you from encrypting the information written to the cards using software, using the ACS software.
However, with such a scheme, the question immediately arises: how to update access rights for users who have already received cards? If access rights are recorded on the card, then any change to them in the ACS software will mean absolutely nothing until we make the changes to the card itself.
The problem is quite solvable. It is enough to install access points in key (several) places that will work simultaneously and as gateways for information exchange between the card and the ACS DB.
Even if such gateways are wired, a system of 300 or 1000 access points with a dozen wired access points (at checkpoints, for example) can be called wireless. Depending on the geography of the facility and the requirements for the system, a sufficient number of such gateways (access points) can be any.
Some of the remaining functions of the highway can also be transferred to the card, taking into account the features, of course. So, it is, of course, impossible to open the door remotely at the operator's request using the card. But it is quite possible to record the history of passages on the card and transmit this information at the moment of the user's next passage through the checkpoint — the gateway. But this is only for doors for which it is not so important to see the event (passage) exactly at the moment when it occurred. The time delay depends on how often the user will pass through checkpoints. But for most objects it is often enough if the events are entered into the database in the evening, when users pass through the checkpoint at the end of the working day.
And yet, there are functions of the ACS backbone that cannot be transferred to the card. First of all, this is remote control and management of the access point.
However, if you think about it, they do not require high speeds of information exchange. And the volume of data transferred even at large facilities will not be so great.
For example, will it be a problem if after the command to open a door from the ACS operator it opens not immediately, but, for example, after 2-3 seconds? And how many events will such an access point transmit to the database (access granted/access denied/door left open, etc.) per minute?
The remaining functions (of those that the card cannot take on) no longer impose such strict restrictions on the choice of wireless technology, and developers have many more alternatives than with the classic ACS design. But we will return to this topic later, when we consider the problem of how to get rid of power supplies and wires from them.
Myth 2. Even if the ACS backbone (i.e. the communication line “ACS database – controller”) can be divided between the card and the wireless channel, it is either technically impossible or unrealistically expensive to switch the access point “strapping” to wireless mode.
Let me remind you that “strapping” is usually used to refer to all the end peripherals connected to the access controller: readers, actuators, status sensors, etc.
Any specialist/installer of ACS is well aware of the problem of the «last meter» — by analogy with the «last mile» in communications, this is how problems that arise when connecting peripherals to the ACS controller, taking into account the characteristics of each specific access point, are called. And this problem is far from mythical. Most installers have repeatedly encountered a situation when connecting a reader and a lock on the door of some office to the ACS controller is more difficult and expensive than running a hundred or two meters of trunk line from the same controller to the ACS server through the building.
Unlike the trunk line, there are no established standards and protocols by which all this peripherals are connected to the controller. More precisely, they do exist, of course, but there are many of them and most of them do not have any wireless analogs. Therefore, the only way to solve the problem is to reduce the length of the cable for connecting the «strapping» to the controller… to zero! That is, constructively combine the controller, reader, sensors (if necessary) and actuator.
The method is, in fact, far from new — devices that work on this principle have been known for a long time: these are electronic locks. They have their own controller, their own actuator, position sensors, etc. Not long ago, electronic cylinders joined them. They also meet all the requirements listed above, while having even more compact dimensions and a very simple installation technology. So, if to install an electronic lock you may have to drill a couple of holes in the door, then to install an electronic cylinder you will only need to work with a screwdriver.
Myth 3. Even if the ACS uses wireless data transmission channels and we have combined all the «strapping» with the controller, you still need to supply power to all access points, so the ACS will not be completely wireless.
The only wireless alternative known today for supplying power to the controller and actuator of the ACS is batteries. Well, or accumulators.
If we want to make a wireless ACS convenient not only for installers, but also for the specialists servicing it (for the end user), these power sources must be able to work without recharging or replacement for at least a couple of years. And the cost of replacing the power elements should not be comparable to the cost of a new system.
And here we will have to somewhat disappoint the ACS installers: with all their love for such an ACS actuator as a magnetic lock, they will have to abandon it. An electronic lock will be able to work on one set of standard (let me remind you, we are looking for a convenient and cheap option) batteries for a long time only if the door is opened by the user himself, by pressing the door handle. The task of the actuator of the access point will be reduced only to controlling the very possibility of pressing this handle. And for this, some micromotor capable of working on one set of batteries for several years is quite sufficient. In the case of an electronic cylinder, the actuator controls the clutch of the cylinder rotary handle and the tongue, and the lock itself is unlocked again by the user's hand, and the micromotor in this case is even smaller than in the lock.
However, the micromotor is not the only one that needs electricity.
We need to return to the topic of the ACS backbone. When we considered possible wireless technologies suitable for the role of transport for this backbone, we were able to expand the list of technologies and move away from WiFi as the only suitable technology.
And now, considering the issue of power supply for the access point, it is necessary to hold a «technology competition» once again.
The main condition of the new competition is energy consumption. Minimal, natural.
And here WiFi loses on all counts. Even without taking into account the actuator, an access point with a wireless WiFi adapter will discharge batteries very quickly. Most likely, the operating time on one set will be measured in hours. GSM or Bluetooth are somewhat more interesting in this regard, but still they will not allow a wireless electronic lock to work on one set of batteries for more or less long periods.
The most interesting technology in this case is wireless data transmission based on the IEEE 802.15.4 protocol. One of the implementations of this protocol is ZigBee technology. Its main features include very low energy consumption, low data transfer rates and fairly large permissible packet loss volumes (which ensures network stability even with a high level of interference).
Myth 4. ZigBee technology (more precisely, the IEEE 802.15.4 protocol) was developed for engineering systems and is absolutely unsuitable for use in ACS. An ACS backbone built on its basis will not allow the system to function fully.
Indeed, if we understand the ACS backbone as the classic set of functions that the data transmission channel between the ACS DB and the controller must perform, the network based on the IEEE 802.15.4 protocol will not be able to fully perform all the necessary functions. But this is what the idea of transferring a fairly significant part of the ACS backbone functions to the user card was implemented for, while IEEE 802.15.4 was given responsibility only for the remaining part (monitoring the state of the access point, managing it in real time, collecting audit data, etc.).
Separately, neither the «data on the card» technology nor the IEEE 802.15.4 wireless network are capable of providing developers with a real wireless alternative to the wired ACS backbone. Only their combination allows for the full implementation of all required functions wirelessly.
So, what do we have as a result?
ACS, which mainly uses autonomous (wireless) electronic locks and cylinders that run on batteries. They can transmit (and receive) data via user cards, and can also be equipped with a radio module that uses energy-efficient wireless protocols and technologies such as IEEE 802.15.4 for operational control and other functions.
In this system, it is desirable to use several online access points that also work as a gateway, providing information exchange between user cards and the ACS database (via cards, as we remember, locks with cylinders can also exchange data with the ACS database).
The number of wires used in such a system is simply insignificant compared to classic wired ACS. Therefore, we have every reason to call such a system wireless, and this is exactly what we needed to prove.
The proposed principle of building a wireless access control and management system is, of course, not an invention of the author of this article: similar wireless ACS have already existed for several years, and several development companies are already offering them.
At the same time, none of the Russian developers still consider user cards in the ACS in any other role than a pure identifier. Even if some system declares support for MiFare cards or other rewritable smart cards operating at a frequency of 13.56 MHz, in fact, the ACS identifier is always the non-rewritable and non-encryptable serial number of the card (the so-called ROM code), while the rewritable part of the key is not used in any way.
In addition, when using a card as a data carrier, developers are simply forced to create their systems in the most complete version, when all readers, controllers and maximum other components are developed and manufactured by the same company. This is due to the fact that when working with information recorded on the card, the system must be able to read and write, and also (which is even more important) encrypt and decrypt data not only at the software level, but also at the hardware level. This significantly limits the possibilities for using standard readers connected to the controller via a standard protocol (Wiegand, etc.), because otherwise the developer would have to open their encryption keys and protocols to third-party equipment suppliers, which does not fit in with the principle of building an ACS as a security system.
Russian developers often prefer to focus on developing their own software and access controllers equipped with inputs for readers of any third-party suppliers operating on standard (and, of course, exclusively wired) protocols.
At the same time, of course, it is worth understanding that there is no talk of any global war between wired and wireless ACS. There will always be objects and tasks that require the use of exclusively wired systems. However, the share of wireless ACS on the market will definitely grow, and they have very optimistic prospects on the market. If only because they are much easier to deploy, maintain and upgrade.