Breaking Down the HID iCLASS SEOS Protocol: A Deep Dive into Access Control Security

TLDR: This research provides a technical breakdown of the HID iCLASS SEOS protocol, revealing how it uses layered encryption and diversified keys to secure access control data. By analyzing communication captures and implementing the protocol in C, the researchers demonstrated the complexity of reverse-engineering these systems. Pentesters should focus on understanding the underlying data structures and key derivation functions rather than relying on simple replay attacks.

Access control systems are often treated as black boxes by security teams, but the reality is that they are just another layer of software running on hardware. When we talk about HID iCLASS SEOS, we are looking at a protocol designed to move beyond the vulnerabilities of legacy systems. The industry has spent years moving away from cleartext RFID communication, and SEOS represents a significant step toward modern cryptographic standards like AES-128 and SHA-256. However, security through obscurity is still a major factor in this space. If you are a pentester or a researcher, you need to understand that the lack of public documentation does not mean a system is secure. It just means you have to do the work to pull the thread.

The Anatomy of an SEOS Transaction

Understanding how SEOS works requires looking at the protocol as a series of nested containers. At the top level, you have the Global Data File (GDF), which acts as the management layer. Inside that, you have Application Data Files (ADFs) that hold the actual data objects. When a reader communicates with a card, it is not just sending a static ID. It is performing a handshake that involves key negotiation and authenticated encryption.

The researchers in this talk demonstrated that the protocol relies heavily on Authenticated Encryption with Associated Data (AEAD), specifically using EAX or EAX Prime modes. This ensures that the data is both encrypted and signed in a single operation. For a researcher, this means you cannot simply sniff a packet and expect to find a static card number. You are looking at a dynamic, encrypted payload that changes with every transaction.

To replicate this, you need to look at the Bouncy Castle C# implementation, which is often used as a reference for these systems. The challenge is that while the library is open source, the specific implementation details for SEOS are proprietary. The researchers spent two weeks building a C implementation to handle the decryption, highlighting the massive gap between having the algorithm and having the protocol logic.

Reverse Engineering the Protocol

One of the most interesting parts of this research is the methodology for handling the data. The protocol uses a key diversification function (KDF) to ensure that even if a master key is compromised, it cannot be used to decrypt every card in a facility. This is a standard practice in key management, but seeing it applied to physical access control is a reminder that we are dealing with real-world cryptography.

When you are on an engagement, you will likely encounter these systems in high-security environments. If you are using a Proxmark3, you might be tempted to use standard sniffing commands like hf 14a sniff. While this will give you the raw data, it will not give you the keys. You are looking at a stream of bytes that requires a deep understanding of the ISO 7816 standard to parse correctly. The researchers showed that the data is structured in a way that requires you to peel back layers like an onion. Each layer of the protocol adds a new level of protection, from the initial handshake to the final data object.

The Wiegand Padding Trap

A critical finding in this research is how the system handles the final output. Even after you successfully decrypt the payload, you are often left with a padded Wiegand format. Wiegand is an ancient, insecure protocol, but it is still the standard for communication between readers and controllers. The researchers found that the SEOS protocol pads the Wiegand data with a specific number of zeros, which must be shifted and decoded to retrieve the actual facility code and card number.

This is where many researchers get stuck. They decrypt the payload, see a string of bytes that does not look like a standard card number, and assume they have failed. In reality, they are just one step away from the cleartext data. If you are testing these systems, you need to be prepared to write custom decoders for these proprietary padding schemes.

Defensive Considerations

For blue teams, the takeaway is clear: the security of your access control system depends on how you manage your keys. If you are using the default keys provided by the vendor, you are vulnerable regardless of how strong the underlying protocol is. Ensure that your system is configured to use unique, diversified keys for every card. Furthermore, perform independent testing of your readers. Do not rely on the vendor's marketing materials to tell you that a system is "future-proof" or "unhackable."

Access control is not a static field. As we move toward mobile credentials and NFC-based systems, the protocols will only get more complex. The work done here is a perfect example of how to approach a proprietary system: don't look for a magic exploit, look for the logic. Understand the KDF, parse the AEAD containers, and handle the padding. If you can do that, you can dismantle any protocol, no matter how much the vendor tries to hide it.