Hacking Hotel Locks: The Saflok Vulnerabilities Expanded -Noah Holland, Josh Stiebel

Hacking Hotel Locks: The Saflok Vulnerabilities Expanded

Speakers: Noah Holland, President; Josh Stiebel

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=ZODLZuy6H4U

Overview

This talk, "Hacking Hotel Locks: The Saflok Vulnerabilities Expanded," presented by Noah Holland and Josh Stiebel, delves into the pervasive security flaws within Dormakaba's Saflok and Sapphire electronic lock systems, building upon previous revelations from DEF CON 32. While the original "Unsaflok" presentation highlighted critical vulnerabilities in MiFare Classic-based systems and the ability to create master keys, Holland and Stiebel demonstrate that the problem is far from resolved. Their research exposes new attack vectors, expands the scope of affected systems to other Dormakaba product lines, and critically, reveals that even "patched" systems utilizing MiFare Ultralight C cards remain highly vulnerable if not configured with the highest security settings.

The significance of this research cannot be overstated. Dormakaba's Saflok systems are widely deployed across hotels, resorts, and even residential apartment complexes globally, potentially affecting millions of doors. The speakers' work not only confirms the ease of exploitation for older systems but also uncovers how a seemingly secure upgrade to MiFare Ultralight C can be circumvented, often in under a minute, to gain master key access to an entire property. This talk serves as a stark warning to the hospitality industry, emphasizing that superficial security upgrades without proper implementation of advanced cryptographic measures leave guests and residents exposed to significant physical security risks.

Holland and Stiebel, through meticulous reverse engineering, patent analysis, and real-world testing, detail the mechanisms of these exploits. They introduce novel methods for obtaining critical system information, such as the property ID, without needing a discarded guest card, and demonstrate how specialized hardware like the HH6 programmer can be leveraged by attackers. Their findings culminate in a practical demonstration of creating master keys for allegedly "secure" MiFare Ultralight C systems, underscoring a systemic industry failure to prioritize robust security over convenience and cost.

Background

▶ Watch: Expanding Saflok vulnerabilities and re-exploiting patched systems (0:00)

To comprehend the vulnerabilities discussed, it's essential to first understand Physical Access Control Systems (PACS). These systems regulate who can enter specific areas. They typically come in two main forms: online PACS and offline PACS.

Online PACS, common in commercial and organizational settings, link card readers to a central server. Credentials, often encoded in Wiegand format with a facility code and card number, are transmitted from the card to the reader, then to controllers, and finally to an upstream server. This server cross-references the card number with a database to determine access rights. Advantages include centralized audit logging, real-time alerts, and granular control.

In contrast, offline PACS are prevalent in hospitality. Here, the card and reader operate independently, without constant communication with a central server or the internet. Access data is encoded directly onto the card itself. While offering convenience for properties with numerous doors where running network cabling to every reader is impractical, offline PACS inherently pose greater security risks. Privilege escalation is easier, and audit logging is decentralized, requiring physical inspection of individual locks. Some modern systems are "semi-offline," using IoT protocols like ZigBee to send logs, but their core authentication remains offline. Hotels often opt for offline systems across their entire property, even if not strictly necessary for every door, due to industry practice and cost considerations.

The "Unsaflok" talk at DEF CON 32 brought widespread attention to the vulnerabilities within Dormakaba's Saflok systems. Initially reported in news articles around March 2024, the talk revealed that Saflok systems, particularly those using MiFare Classic cards, suffered from "security through obscurity" encryption. The data stored on these cards, which acted as a container for encrypted access information, relied on a rudimentary, property-agnostic encryption algorithm. A critical finding was that the deadbolts were software-controlled, meaning that if an attacker could manipulate the card data, they could override the physical deadbolt mechanism. The original talk emphasized that these vulnerabilities were patched, with many hotels, including those in Las Vegas, having updated their systems.

However, Noah Holland's personal experience moving into a new apartment, which utilized a Saflok system, sparked further investigation. He discovered that his apartment fob, when scanned with a Flipper Zero, could parse familiar data, indicating it was indeed a Saflok system. This was significant because it was an apartment, not a hotel, highlighting that the issue extended beyond the hospitality sector. This led to the realization that Dormakaba's other product lines, such as Sapphire locks, shared the same bit format and encryption as Saflok, meaning the vulnerabilities were far more widespread than initially disclosed. The speakers also observed that data was written back to the card with each tap, a detail not fully explored in the original talk.

To further their research, Holland and Stiebel bypassed the need for direct access to Dormakaba's newer Ambiance and Community software (a web-based, locally hosted solution) by acquiring a copy of the older System 6000 software. They reasoned that the underlying system structure, fields, and format remained consistent across solutions. They set up a lab, acquiring two encoders, a demo display lock, and an HH6 programmer (also known as LPI or Munit) from eBay. This lab environment allowed them to manipulate card data, set property IDs, and delve into the system's inner workings. Extensive patent research, dating back to 1977 and as recent as 1993, proved invaluable in understanding the precise bit fields and key types used in the Saflok system, providing a "treasure trove" of technical details.

Key Findings

▶ Watch: Recap of original Saflok master key vulnerability (4:25)

Noah Holland and Josh Stiebel's expanded research on Saflok vulnerabilities yielded several critical findings that significantly broaden the scope and impact of the original DEF CON 32 "Unsaflok" talk:

1. Expanded Scope of Vulnerability: The "Unsaflok" vulnerabilities are not limited to the specific Saflok line of locks but extend to other Dormakaba offerings, such as Sapphire locks. This is because Dormakaba's different product lines share the same underlying bit format and encryption algorithms, meaning a single exploit can affect a much wider range of installations, including apartment complexes and other facilities beyond traditional hotels.

1. HH6 Programmer as an Attacker's Tool: The HH6 handheld programmer, used by hotel staff, was found to be a far more powerful and exploitable device than previously understood. Contrary to assumptions from the original talk, the HH6 can interrogate any lock, even if it belongs to a different property ID. This capability allows an attacker to easily obtain the crucial property ID from any lock, eliminating the need to find a discarded guest card. Furthermore, the HH6 supports ELPS (Emergency Lock Power Supply) mode, which essentially emulates an emergency key over its serial interface, enabling the lock to be popped open directly. This significantly lowers the barrier to entry for attackers.

1. MiFare Ultralight C: A Partial and Insufficient Patch: Dormakaba's primary mitigation, upgrading from MiFare Classic to MiFare Ultralight C credentials, was found to be largely insufficient. While Ultralight C cards are more secure than MiFare Classic and are not susceptible to direct data reading without a proper key, Holland and Stiebel demonstrated that most hotels implement them with "standard security" rather than the required "enhanced security" (per-site diversified AES-128 keys). This "standard security" configuration remains vulnerable.

1. New Exploitation Vector for MiFare Ultralight C: Despite the enhanced security of Ultralight C cards, the speakers discovered that after a secure handshake between the card and reader, the card transmits all essential data in plaintext. This allows an attacker to sniff the communication using tools like a Proxmark, extract the property ID and other necessary information, and then craft a master key. Alternatively, the Key Derivation Function (KDF) for Ultralight C is found within older Gen 1 encoder boxes, which can be used as an oracle to extract keys.

1. Unencrypted Data on Cards: Beyond the primary encrypted access data, the cards store additional information in an unencrypted format. This includes logs (detailing unsuccessful tap attempts, error codes, and timestamps) and variable keys (which allow a card to open additional, specific doors). This unencrypted data provides valuable reconnaissance for attackers and could potentially be manipulated.

1. Existence of Public Flipper Zero Exploit: The speakers discovered that a full attack tool for Flipper Zero, capable of exploiting Saflok systems, was publicly released on GitHub shortly before Dormakaba's public announcement of a vulnerability, indicating that the knowledge and tools for these exploits are already in the public domain. The author of this tool created it out of frustration after their apartment management dismissed their vulnerability reports.

In summary, Holland and Stiebel conclusively demonstrated that the Saflok vulnerabilities are more pervasive, easier to exploit, and less effectively patched than previously believed. The HH6 programmer and the plaintext data transmission in MiFare Ultralight C systems represent significant new attack vectors that allow for rapid and widespread compromise of physical security in affected properties.

Technical Deep Dive

▶ Watch: Personal discovery: Saflok vulnerabilities found in apartment locks (5:20)

The core of the Saflok vulnerability, as initially exposed and further detailed by Holland and Stiebel, lies in the design of its offline PACS and the cryptographic shortcomings of its card systems.

MiFare Classic Vulnerabilities (Recap):

For systems utilizing MiFare Classic cards, the primary vulnerability stemmed from its weak encryption. The crucial access data, comprising 17 bytes, was stored in sector zero of the card. This data included fields such as check-in/checkout dates, a bit to override the deadbolt, and critical card level and card type fields.

• Card Levels define the card's purpose (e.g., guest key, suite key, section key, grandmaster).
• Card Types dictate its functionality (e.g., open door, program lock, inhibit certain keys, resequence lock).

The encryption algorithm used was rudimentary, involving a substitution table and simple bit shifts. Critically, this algorithm was universal across all properties, meaning that if an attacker acquired the algorithm, they could decrypt and re-encrypt data for any Saflok-equipped hotel.

A significant hurdle for attackers seeking to create master keys was the sequence and combination fields. Every lock has a unique combination value, and each card level has a sequence number. For a card to be valid, its sequence and combination fields must match those expected by the lock. This acts as a "passcode." The original exploit leveraged resequencing keys. These special cards could alter the lock's sequence number to a value known to the attacker. By first using a resequencing key (often at an "emergency" level) to set a lock's sequence to a predetermined value (e.g., 1234), an attacker could then use a crafted master key with the matching sequence and combination to open any door on the property.

Speakers' Tooling and Data Discovery:

Holland and Stiebel developed custom tools for the Proxmark, specifically the hfs saflok command suite.

• hfs saflok read: Dumps all data from a Saflok card.
• hfs saflok modify: Allows modification of specific fields on a Saflok card.

These tools facilitated the recreation of the original exploit and the discovery of additional data on the cards. Beyond the 17 encrypted bytes, they found unencrypted data farther down on the card:

• Logs: When a card is tapped on a door and fails to grant access, the lock writes log data to the card, detailing error codes and the time of the tap. This provides valuable reconnaissance.
• Variable Keys: If a card is programmed to open multiple specific doors, the IDs of these additional locks are stored unencrypted on the card. This presents a potential attack vector, as these values can be sniffed and potentially manipulated, even on more "secure" systems.

HH6 Programmer Exploitation:

The HH6 handheld programmer (also known as LPI or Munit) is a critical piece of hardware for hotel staff, primarily communicating via NFC and serial, with variants supporting Bluetooth, ZigBee, and infrared. The speakers attempted to access lower-level debugging ports like JTAG and serial, but these were locked. However, they noted that the HH6's MCU has a known vulnerability, which, while not exploited by them due to lack of a Pico EMP, presents a future avenue for deeper compromise.

Crucially, the speakers disproved the claim that the HH6 errors out with a mismatched property ID. Their testing showed that an HH6 could interrogate any lock, regardless of its property ID. This allows an attacker to obtain the property ID of a facility directly from a lock, bypassing the need to acquire a discarded guest card (which hotels now often collect in secure boxes). Furthermore, the HH6 supports ELPS (Emergency Lock Power Supply) mode. In this mode, the HH6 can emulate an emergency key via its serial interface, effectively popping open the lock. This capability is reminiscent of the 2012 Onity exploit, where an Arduino could be plugged into a programming port to read site codes and open doors, leading to a significant media frenzy and real-world burglaries.

MiFare Ultralight C Exploitation:

Dormakaba's primary patch involves upgrading to MiFare Ultralight C cards and implementing per-site diversified AES-128 keys for encrypted data. While Ultralight C cards are inherently more secure than MiFare Classic (they are not "cracked," meaning their data cannot be simply read without a key), Holland and Stiebel found a critical bypass for systems not using "enhanced security."

The attack against Ultralight C proceeds as follows:

1. Property ID Acquisition: An attacker can either use an HH6 programmer to interrogate a lock and obtain the property ID (as described above) or, more subtly, sniff the communication between an Ultralight C card and a reader. Although the card and reader perform a secure handshake, the **essential card data is transmitted in plaintext immediately after the handshake**. This plaintext data includes the property ID and other fields necessary for crafting a master key.
2. Card Data Encoding: Once the plaintext data and property ID are obtained, the attacker can manipulate the card level and type fields (e.g., to create an emergency or master key) using their Proxmark tools.
3. Writing to Ultralight C Cards: This is the most complex step, as directly writing to Ultralight C requires the correct keys. The speakers identified two primary methods:

• KDF in Gen 1 Encoders: The Key Derivation Function (KDF) for Ultralight C is not in the System 6000 software but resides within the Gen 1 encoder boxes themselves. These older encoders are relatively easy to acquire online. An attacker can take a hotel card, place its UID on a UID changeable card, and then use the Gen 1 encoder to write to it. During this write operation, the encoder will write the necessary keys to the card in plaintext, which can be sniffed with a Proxmark. This effectively turns the encoder into an "oracle" for key extraction.
• Public KDF Cracks/Emulation: The community has developed cracks for the Ultralight C KDF. Attackers can find dumps of full cards with valid UID key pairs online, edit these, and then emulate them using tools like a Flipper Zero or Proxmark, or write them to UID changeable cards.

This multi-pronged approach allows an attacker to create functional master keys for MiFare Ultralight C systems, even those considered "patched" by Dormakaba, provided they are not using the "enhanced security" configuration. The speed of this process is alarming, often taking less than a minute from HH6 connection to working master key.

Demo / Proof of Concept

▶ Watch: Saflok vulnerabilities extend to Dormakaba's Sapphire locks (6:00)

Noah Holland and Josh Stiebel made their research tangible through several demonstrations and real-world proof-of-concept exercises.

A central component of their demonstration was a fully working lab setup hosted at the Physical Security Village (PSV) during DEF CON. This lab provided attendees with hands-on experience, featuring:

• A copy of System 6000 software.
• Functional encoders (both older and newer models).
• A demo display lock for immediate testing.
• An HH6 programmer for interaction with the locks.
• Their custom Proxmark tool (hfs saflok) was also available, allowing participants to dump and modify card data in real-time. This interactive environment allowed the audience to "poke around" and understand the exploit mechanisms directly.

Beyond the controlled lab, the speakers conducted real-world testing in Minneapolis, Minnesota, a week before the DEF CON talk. Their methodology for identifying vulnerable hotels was pragmatic:

1. They used Google Maps and hotel review images to visually identify properties using Saflok systems. Pictures of door locks in guest reviews often revealed the specific Dormakaba models.
2. They then drove to these identified hotels to investigate further.

This real-world reconnaissance allowed them to validate their findings in diverse operational environments.

The culmination of their real-world proof-of-concept involved demonstrating the MiFare Ultralight C exploit. After sniffing plaintext data during a card-reader handshake or obtaining the property ID with an HH6, they were able to:

1. Encode card data to create master keys.
2. Write these master keys to UID changeable cards, leveraging either the Gen 1 encoder oracle method or public KDF cracks.
3. Successfully use these crafted keys to open hotel doors, famously depicted with a speaker jumping into a hotel pool after gaining access.

The speakers also highlighted the existence of a public Flipper Zero full attack tool for Saflok systems, released by an independent researcher. This tool, found on GitHub, was created after the researcher's apartment management company dismissed their vulnerability reports, even after being mailed a master key as proof. This public tool serves as an external, independently verified proof of concept that validates the severity and practicality of these vulnerabilities, further underscoring the urgency for mitigation.

While the talk itself faced technical issues preventing the display of their heavily visual presentation with animations and diagrams, the detailed verbal explanations and the availability of their lab and tools at the PSV effectively conveyed the demonstrated proofs of concept.

Defensive Implications

▶ Watch: Discovering exposed Ambience/Community hotel management systems online (6:40)

The findings from "Hacking Hotel Locks: The Saflok Vulnerabilities Expanded" carry profound defensive implications for any entity utilizing Dormakaba Saflok or Sapphire lock systems, particularly those in the hospitality and residential sectors. The most critical takeaway for defenders is that simply upgrading to MiFare Ultralight C cards is not a sufficient patch for the Saflok vulnerabilities.

Here are the key defensive actions and considerations:

1. Implement "Enhanced Security" for MiFare Ultralight C: This is the paramount recommendation. Hotels must go beyond merely adopting MiFare Ultralight C cards and ensure they are configured with per-site diversified AES-128 keys. Dormakaba refers to this as "enhanced security." The speakers explicitly state that "standard security" Ultralight C implementations are still vulnerable to master key creation. Dormakaba's "lock update project" includes this solution, and it is reportedly a free patch, removing any cost barrier for proper implementation. Hotel administrators must actively demand and verify that this enhanced security is fully enabled.

1. Secure HH6 Programmers: The HH6 handheld programmer is a powerful attacker's tool. It can reveal property IDs from any lock and has the potential to open locks directly via ELPS mode.

• Physical Security: HH6 devices must be treated as highly sensitive assets. They should be stored securely, ideally under lock and key, with strict access controls.
• Monitoring and Auditing: Implement procedures to track HH6 usage and audit its activities regularly.
• Firmware Updates: Ensure HH6 devices are running the latest firmware, although the speakers noted a known MCU vulnerability that might still pose a risk.

1. Review and Secure Encoder Hardware: Older Gen 1 encoder boxes were identified as potential key oracles for MiFare Ultralight C systems.

• Inventory and Upgrade: Identify and replace any Gen 1 encoders.
• Physical Security: Treat all encoders as critical infrastructure. They should be in secure locations with restricted access.
• Network Segmentation: If encoders are networked, ensure they are on a segregated, protected network segment.

1. Audit Physical Access Control Policies and Practices:

• Card Issuance: Re-evaluate procedures for issuing and managing guest and staff cards. Ensure proper resequencing practices are followed for new or replacement keys, rather than simply duplicating existing ones.
• Key Collection: Continue using secure key return boxes, but understand that this alone is not a sufficient defense against sophisticated attackers who can obtain property IDs via HH6 or sniffing.

1. Understand the Industry-Wide Problem: This is not unique to Dormakaba. The broader issue is an industry tendency to prioritize cost-cutting over robust security. Hotels often opt for the cheapest access control solutions, even if they are known to be less secure. Defenders should advocate for increased investment in physical security, recognizing that the cost of a breach (reputational damage, liability, operational disruption) far outweighs the expense of proper security measures.

1. Monitor for Future Vulnerabilities: The speakers mentioned ongoing research into MiFare Ultralight C key recovery and potential attack vectors through unencrypted variable keys, even on enhanced security systems. They also pointed to the eventual need to transition to more secure technologies like Desfire cards, despite their higher per-card cost. Defenders should stay informed about emerging threats and be prepared for future upgrades.

1. Don't Rely on "Security Through Obscurity": The original MiFare Classic vulnerabilities were rooted in weak, proprietary encryption. Modern security relies on publicly vetted, strong cryptographic standards. Hotels should demand transparent security postures from their vendors.

In essence, defenders must recognize that the threat to Saflok systems is current, widespread, and easily exploitable. A proactive, multi-layered approach focusing on validated cryptographic implementation, physical security of programming devices, and continuous vigilance is essential to protect guests and property from these pervasive vulnerabilities.

Key Takeaways

• Pervasive Vulnerabilities: The "Unsaflok" vulnerabilities extend beyond MiFare Classic cards and the specific Saflok product line, affecting other Dormakaba systems like Sapphire locks across hotels and apartment complexes.
• HH6 Programmer: A Critical Attack Tool: The HH6 handheld programmer can easily obtain property IDs from any lock, regardless of its assigned property, and potentially open locks via ELPS mode, eliminating the need for a discarded guest card and significantly lowering the bar for attackers.
• MiFare Ultralight C is Insufficient Without "Enhanced Security": Simply upgrading to MiFare Ultralight C cards does not guarantee security. Most hotels using "standard security" Ultralight C implementations remain vulnerable to master key creation, as card data is transmitted in plaintext after handshake, or keys can be extracted from older encoder hardware.
• Urgent Need for Full Patch Implementation: Hotels must implement Dormakaba's "enhanced security" solution, which involves per-site diversified AES-128 keys for MiFare Ultralight C. This patch is reportedly free, leaving no excuse for continued vulnerability.
• Industry-Wide Cost-Cutting Compromises Security: The widespread persistence of these vulnerabilities highlights a systemic issue in the hospitality industry, where cost-cutting often leads to the adoption or retention of insecure access control systems.
• Public Exploits Exist: The existence of public Flipper Zero tools for Saflok exploitation means that the knowledge and means to compromise these systems are readily available to a broad audience, increasing the urgency for properties to patch.

About the Speaker(s)

Noah Holland is an undergraduate student at Michigan Tech, where he serves as the president of both the Red Team and Linux users group clubs. His expertise in physical security is further demonstrated by his role as a host of the Access Control Village at various conventions. He is also a co-founder of Badac LLC alongside Josh Stiebel.

Josh Stiebel is an alumnus of Michigan Tech and a co-founder of Matsack LLC with Noah Holland. He co-hosts the Access Control Village, contributing his knowledge to the physical security community. Josh is also noted as a recent failed PCT (Pacific Crest Trail) thru-hiker and a proud owner of the HBC 1200 machine.