Cracking the Code: A Deep Dive into HID SEOS Protocol Security

In the world of physical security, HID Global’s SEOS technology has long been considered the gold standard for secure access control. Used by government agencies, healthcare providers, and major corporations, it was designed to succeed the aging iClass system by implementing modern cryptographic standards. However, because the protocol remained proprietary and undocumented, it effectively operated as a "black box." At Black Hat Asia, security researchers Iceman and Adam Foster changed that by presenting the first open-source implementation of the SEOS protocol, integrated directly into the Proxmark3 project.

The Anatomy of an RFID Protocol

To understand why SEOS is significant, one must understand the evolution of RFID security. Early systems transmitted card numbers in plaintext, which were easily sniffable. Later systems added basic passwords, but modern threats require the level of sophistication found in SEOS. SEOS isn't just a simple card; it’s a file-system-based application running on a smart card chip. It uses the ISO 7816 standard for its APDU (Application Protocol Data Unit) communication, which is the same standard used by EMV credit cards.

The protocol is structured around a Global Directory File (GDF) and multiple Application Directory Files (ADFs). These files contain Data Objects (OIDs) which hold the actual credential information, such as the Wiegand card data used to open a door. Access to these objects is guarded by a multi-layered authentication process that includes privacy keys, MAC (Message Authentication Code) keys, and diversification functions.

The Layered Defense: The "Onion" Model

Iceman and Foster describe the SEOS communication as an onion. To get to the actual data, you must peel back several layers of security:

1. Application Selection: The reader selects the SEOS application using a specific Application ID (AID).
2. Privacy Layer: A GetADF command is used to retrieve an encrypted blob. This blob, when decrypted with a privacy key, provides a "diversifier" used for further key generation.
3. General Authentication: The reader and card perform a handshake to establish Secure Messaging. This involves generating a session-specific key using the diversifier.
4. Secure Messaging: All subsequent commands, such as Get Data, are encrypted via AES and signed with a MAC. This uses a technique called "MAC chaining," where each message’s signature depends on the signature of the previous message, preventing replay attacks and out-of-order execution.

Technical Deep Dive: Cryptographic Implementation

The researchers highlighted the complexity of the Secure Identity Object (SIO). The SIO is a carrier-independent container that can live on a card, a mobile phone, or even in the cloud. It utilizes AEAD (Authenticated Encryption with Associated Data) algorithms, specifically EIX and EIX Prime.

One of the most technical challenges discussed was the implementation of the Key Diversification Function (KDF). The system takes a 48-byte input and runs it through an HMAC-SHA1 process to produce a 16-byte diversified key. During their research, the team discovered a common pitfall: most academic papers and the Bouncy Castle crypto library implementations use Big Endian formatting, whereas many embedded C implementations (like those used for the Proxmark3) default to Little Endian. Correcting these byte-order issues was critical to successfully decrypting the payloads.

Decoding the Wiegand Payload

Once the final layer of the SIO is decrypted, the researchers were left with the "Padded Wiegand" format. This format is essentially the raw binary data that identifies a user. For example, a standard 26-bit Wiegand (H10301) credential might be represented as a series of hex bytes. The first byte indicates the bit shift required to align the data. By shifting the bits and applying the correct Wiegand parity checks, the researchers were able to extract the Facility Code and Card Number—the ultimate goal of the read process.

Mitigation and Defense

While the presentation "dismantled" the protocol, it actually reinforced that SEOS is a highly secure implementation when compared to legacy technologies like HID Prox or standard iClass. The researchers noted that SEOS uses adopted open standards and robust AES encryption.

For security professionals, the takeaway is clear:

• Audit your systems: Don't rely on "security through obscurity." Now that SEOS is no longer a black box, it can be tested against your specific environmental configurations.
• Use Elite Keys: The researchers mentioned that custom or "Elite" keys provide an additional layer of security beyond the standard HID factory keys, making it significantly harder for unauthorized readers to initiate the protocol handshake.
• Stay Updated: Ensure your readers and controllers are running the latest firmware to support these advanced cryptographic features.

Conclusion

The work performed by Iceman and Adam Foster is a milestone for the physical security community. By bringing SEOS into the open-source Proxmark3 ecosystem, they have empowered researchers to move beyond marketing white papers and truly evaluate the security of the systems protecting our buildings. As Iceman stated, "Systems like this need independent testing... we want to see vendors embracing this type of research." For those interested in hardware hacking, the full implementation is now available in the Proxmark3 GitHub repository, providing a wealth of information for further study.