DRAFT
Many attacks have been described against low-frequency (125kHz) proximity card systems. Nobody should be surprised to learn that they’re not considered very secure – and yet, most new installations use these cards.
I want to raise awareness of the limitations of these systems, demonstrate the many simple ways in which they can be defeated, and discourage new installations. This article lists the most practical ways in which to attack these systems. As I become aware of new attacks, I will update the article.
I will mention specific product names, but these attacks can be applied to many different products which use the same operating principles.
We will be dealing with the ‘common case’ when proximity cards are used for access control: HID Proximity cards, an HID reader such as the ProxPoint, transmitting Wiegand back to the controller. Other designs are possible (and desirable), but in my experience, the vast majority use this setup.
An access control system using proximity cards is usually laid out like so:
For a user to authenticate against the system, the following steps take place:
All proximity cards contain a coil and some circuitry. Some long-range types contain a battery, but we will not be dealing with them here. The coil picks up an RF field from the reader and uses it to provide power to the internal circuitry.
The most common coils are tuned to 125kHz or 13.56MHz. We will refer to cards running at about 125kHz as Low Frequency (LF) cards. We will refer to cards running at 13.56MHz as High Frequency (HF) cards.
There are many different types of card on the market. The most common cards run at 125kHz and are made by HID (for example, the ProxCard II. There are very similar cards running at 128kHz or 134kHz from manufacturers such as Indala.
These cards all behave in the same way. When the card is placed in the reader’s field, the circuitry derives a power supply and clock. It then transmits a preprogrammed code to the reader and powers down.
The method of transmission is interesting. Instead of the card actively transmitting RF energy, it manipulates its own power draw in a way that can be detected by the reader. Because the card and reader are inductively coupled together, an increase in load causes a decrease in the output voltage on the reader side. This change in voltage can be measured by the reader and is used to transfer information from card to reader. (For more information, see here.)
The reader generates an RF carrier to power and clock the card. When it receives a valid transmission from a card, it will transmit the card number out of its Wiegand interface.
The reader does not make the access control decision (allow or deny). This is good design; the reader is physically accessible to the insecure side of the door and can easily be tampered with. Instead, it transmits the card’s code to the door controller using its Wiegand output.
The Wiegand interface uses three wires: GND, D0 and D1. To transmit a ‘0’ bit, the D0 line is pulled to 5V. To transmit a ‘1’ bit, the D1 line is pulled to 5V. There are no formal timing requirements, but most devices transmit and recieve pulses around 50uS wide and with a gap of 5000uS between pulses.
The most common format for card numbers is as follows:
(image from HID’s Understanding Card Data Formats document)
This is often referred to as Wiegand 26.
Cards almost always support other formats, but Wiegand 26 is the defacto standard. Almost all system components default to Wiegand 26 without further configuration.
User codes should be different for every card. They’re often printed on the card itself:
Facility codes are the same for an entire ‘facility’, which is usually the domain controlled by a single access control system. This can be as small as a single office or can span multiple buildings. It has the obvious purpose that if two people from different companies have the same user code, they can’t open doors at each other’s buildings. It partitions the code space to prevent collisions.
The door controller receives and decodes the Wiegand signal from the reader. Depending on how the controller is configured, it can make a decision (allow or deny) based on that signal, or it can forward it on to the management backend. Usually, the door controller communicates with the backend through an RS485 bus. This is a multidrop bus, so many door controllers can communicate using a single set of cabling.
If the door controller or management backend elect to unlock the door, a relay on the door controller is energised.
The door strike is wired to the relay on the door controller. Its purpose is to physically lock or unlock the door. Normally-open and normally-closed types are available, so:
The strike can also be wired to the relay in normally-open or normally-closed configurations. In this way, default behaviour for the system (when unpowered) can be specified. For example:
Usually, there is a fire safety requirement that says that there must be an exit path in the event of a fire. This may require you to choose fail-safe strikes and have them continuously energised in some cases.
Door strikes usually require 12V at a few hundred milliamps to trigger.
Most attacks occur in two stages:
The wiring between components must be physically secure. Communication between card reader, door controller and door strike is completely unencrypted and unauthenticated.
If an attacker can access the wiring carrying the Wiegand codes between reader and door controller, they can sniff the Wiegand codes. They can then replay the codes directly into the wiring or use them to create a new card.
The same cards may be used for unrelated systems (e.g. printers, vending machines) which may not have secured cabling. The same Wiegand codes can be sniffed from there and used to clone a card.
If an attacker can access the door strike wiring, they can manually energise the strike (by applying a voltage across the wiring) or de-energise it (by cutting one of the wires).
If an attacker can access the door controller itself, the preceding attacks are also possible.
Most RS485 wiring between door controllers and the management backend can also be sniffed and replayed, though the exact formats are not standardised. Some door controllers and backends do use encrypted communication over the RS485 lines.
One big problem is that the card reader itself must be able to withstand physical attacks. The card reader usually has a ‘pigtail’ collection of wires coming out of the back, including the critical Wiegand lines. If an attacker removes the reader from the wall, the Wiegand lines are exposed. This is usually easy to do. Some readers have their mounting screws well secured, such as these:
Some have their mounting screws exposed, so a few moments with an electric drill is all that’s necessary:
Some are physically quite robust. Potting of the electronics is common, and is a good precaution.
One factor that makes physically securing a reader difficult is that any metals in or around the reader will affect the read range. As a result, almost all readers are made of plastic and can be broken off the wall with a hammer.
The same is true of door strikes, but even low-end door strikes are solidly built; they just need to be at least as strong as the door that they lock.
One obvious way to read people’s cards is with an off-the-shelf reader, like what might be installed on a building. They can be powered from batteres and the beep can be disabled. The attacker might get near someone on a lift and swipe the reader over their pockets. Some companies mandate visible security passes, making it even easier as you can see the pass and know where to swipe the reader.
The reader will output the Wiegand code of the card, so you need a sniffer/replayer and some way to use that code (either replay it into the Wiegand wiring or clone a card). Slightly simpler might be to use a reader with RS232 output and connect that to a laptop.
This is a design flaw in the system – there is nothing the card can do to know that it’s talking to a legitimate reader. As soon as it’s powered, it transmits its code, not knowing if the receiver is friendly or malicious.
A less practical attack, but using the same design flaw, is to put a fake reader on a wall near an entry point. Users will swipe their cards on it thinking that it will open the door. The card numbers can be collected and exploited as above.
The reader and cards transmit on a known frequency. If you can get close to a reader while it’s communicating with a card, you can capture the card’s transmission. It may be possible to do this at long range, since the reader operates at a very high power level (necessary to power the card). The attacker only needs to observe the card’s transmission, not power the card.
Again, the card does not make any attempt to hide its transmission. Every transmission is identical, permitting replay attacks.
Once you’ve captured the card’s transmission, you can either replay it directly at a reader or extract the user/site code.
With the user/site code, you can:
The numbers themselves provide opportunities for attacks.
The total number of code available is relatively small (by cryptographic standards). With Wiegand 26, there are 256 site codes and 65536 user codes, for a total of 16,777,216 card numbers.
Assume a random distribution of card numbers and that you can make one swipe attempt every three seconds. If there is exactly one valid card in the system, it will take (on average) 291 days to find it; not very useful.
If you know the site code (say, you cozy up to someone at their security vendor), you can guess a single valid card in 1.4 days, on average.
If there are more cards set up in the system, guessing a valid user code becomes proportionally easier. If you have 100 cards set up, a valid card can be guessed in 2.8 hours, on average.
If you know someone’s user code (not many people know that the number printed on their card is important!) you can brute-force the site code in 13 minutes, on average.
Usually, cards are sold in sequential order. If you know one card number (perhaps your own, if you’re an inside attacker or corporate spy) it’s very likely that:
It also means that you really shouldn’t reissue old cards to new employees, as the old employee may be able to produce a new card with the same site/user code. They’re cheap; destroy them (securely!)
Some companies require that people display their security passes on their body (often with additional conditions like “it must be above your waist” and “you must challenge anyone who isn’t wearing a pass”). Some subset of those companies also print the user number on the card. Obtaining a user code then becomes a simple matter of reading the number off people outside the building.
This is a device which connects to the D0, D1 and GND lines of the Wiegand interface. When it detects a Wiegand transmission, it captures it. Under user control, it can replay that same transmission onto the Wiegand lines. Each transmission is identical, so that will appear the same as a legitimate card swipe.
Examples of these devices are:
The RF sniffer/replayer works identically to the Wiegand sniffer/replayer, but looking at the RF transmissions instead. An antenna or coil picks up transmissions from legitimate cards, stores them and later replays them, impersonating the original card.
Examples of these devices include:
If you get someone’s card number and facility code, the low-tech approach is to simply order an identical card from the manufacturer.
In a perfect world, you’d use a different access control system. If you must use 125kHz prox cards, there are some things you can do to make life more difficult for attackers.
Does any of this matter?
It depends entirely on your situation.
Most physical access control systems are subject to the following attacks:
Like all security systems, you must weigh up the costs and risks for your own situation.
For me, the most interesting future work here is the ability to clone a person’s card from a distance. Physical attacks on the reader and wiring make your entry obvious and traceable. Trying to excite a person’s card while it’s on their body carries risk that you may later be identified as “that guy who stood too close to me”. RF capture and replay offers a low-risk option.
To this end, I intend to replicate the work on proxclone.org, focusing on long-range capture of card transmissions. I will document the work and provide costings to make it easier to evaluate the costs of an attack on these systems.
