Abusing the Internet of Things (2015)
Chapter 2. Electronic Lock Picking: Abusing Door Locks to Compromise Physical Security
One of the oldest evidence of locks dates back to 4,000 years ago within the ruins of the ancient Egyptian empire. This lock came to be known as the Egyptian lock because of its popularity in the area. The lock was made of wood and contained wooden pegs of different lengths. A slot in the door provided access to a wooden key with pegs of complementary lengths. The key needed to be inserted into the lock and lifted up, to align the pegs evenly at the top of the bolt, thereby allowing the door to open.
Since the Egyptians, we’ve had influences from the Greeks, the Romans, and various eastern implementations from China, Turkey, and India. Later influences from Britian and the United States have brought us to the various types locks we rely upon today, which include a combination of movable levers, cylindrical keys, and pin tumblers to make it a little harder for the lock to open without the correct key.
We depend upon locks in our homes for our physical safety, even while many of us are aware of how easy it is to pick locks using different techniques. Many states and countries have combatted the prevalence of lock picking tools by issuing regulations that prohibit the possession of these tools. As you can imagine, the mere existence of regulations is unlikely to deter a malicious entity who might want to gain physical access to a given premises.
Looking into the future of IoT-enabled devices, it becomes important for us move beyond traditional physical lock picking and analyze electronic mechanisms that can put us in a state of higher risk. This chapter takes a look at the security surrounding existing electronic door locks, their wireless mechanisms, and their integration with mobile devices. We will step through these topics in the next few sections and ultimately demonstrate the current security mechanisms (or lack thereof) in electronic door locks. After establishing the bad security decisions manufacturers might be making, we will be more aware of potential risks and have a better idea of what securing these types of locks will require in the future.
Hotel Door Locks and Magnetic Stripes
One of the most popular door-lock vulnerabilities, discovered by researcher Cody Brocious, affects millions of door locks installed in hotels around the world. Given its potential impact, no conversation on the topic is complete without a discussion of it. In fact, after Brocious exposed this issue at the Black Hat security conference in July 2012, hotels experienced actual cases of intruders abusing this flaw to enter hotel rooms and steal property. Brocious’s work is popular in the information security community becuase it abuses basic security design flaws, so it is a perfect place to begin understanding security issues surrounding electronic door locks.
The Onity Door Lock
The Onity HT door lock is extremely popular. If you’ve stayed at hotels, you’ve likely encountered it and implicitly relied upon its mechanisms for your safety and privacy. As shown in Figure 2-1, the Onity lock consists of a magnetic key-card reader. Hotel guests are issued magnetic key-cards, which open the lock when swiped through the reader. Hotel employees can issue these cards to guests upon check-in or when a guest requests an additional card. The hotel can issue master keys to employees, such as house-cleaning staff, that can open multiple doors.
Figure 2-1. The Onity door lock
Though the Onity lock employs a traditional mechanism of using magnetic cards as keys, it is important to study, because the next generation of IoT-based door locks are likely to employ a hybrid approach that preserves traditional mechanisms (physical keys and magnetic-stripe cards) along with smarter methods to include wireless authentication and electronic keys, which we will study in the following sections of this chapter. Security issues surrounding the Onity lock are also important to understand because they lay the foundation for understanding fundamental security design flaws that can potentially be exploited to impact millions of locks deployed worldwide. We must strive to prevent such scenarios in the future.
The Magnetic Stripe
We’ve all come across cards with magnetic stripes multiple times in our lives. From credit cards to mass-transit tickets to hotel room keys, we’ve come to depend upon cards with magnetic stripes for access to services and physical places. Figure 2-2 illustrates the back side of a typical credit card with a magnetic stripe (also known as a magstripe). The label (1) shows the megnetic stripe, while (2) is the signature strip and (3) represents the CVC code. The scope of our discussion in the following sections pertains to hotel-room key cards, which typically have only the magnetic strip on the back with the logo of the hotel in the front.
Figure 2-2. Card with magnetic stripe
Typically, magstripes contain three distinct tracks that can store different blocks of data. Tracks 1 and 2 are commonly used by the financial industry to issue ATM, eebit, and credit cards, yet there are no restrictions on which particular track an entity may use. The Onity door lock happens to use Track 3, which contains the following sequence of data:
16-bit ident value
An identity value to keep track of the door the key is assigned to and which copy the card is. In the case of a master card created for hotel personnel, a value representing the identity of the hotel employee is stored instead of the door identifier. When checking into the hotel, the first key created will have the copy identifier set to 0, while subsequent copies will add 1 to this number to identify the number of the copy.
8-bit flags byte
Used to set miscellaneous values in one byte for various other miscellaneous options.
16-bit expiration date
Set upon guest check-in to indicate the length of time the card will be valid.
24-bit unknown field
Set to all +0+s.
24-bit keycode value
This value is programmed into individual locks. When this is done, the locks are also configured to have a look-ahead value. For example, if a lock was programmed with a keycode value of 100 and a look-ahead value of 50, it would accept integers between 100 and 150 as valid keycode values. Every time a valid card is inserted, the lock resets its keycode value to the value of the card. In this way, the lock increments its keycode value to make sure older cards are invalidated. Note that specific keycode values representing master keys are also stored in the locks. The hotel may decide to segment areas with different master keycodes so that only certain areas of the hotel can be opened with any given master keycard.
The values are encrypted using the sitecode value, which is a unique 32-bit value randomly assigned by Onity to identify the hotel property. If this value is compromised, it can be abused to generate arbitrary magnetic cards to unlock doors and also to program the locks themselves (discussed in following sections).
The actual encryption algorithm that uses the sitecode value is documented in Appendix B of Cody Brocious’s whitepaper.
In addition to typical key cards described here, the system also includes programming and spare cards. When a programming card is swiped through the lock followed by a spare card, the spare card becomes the guest card for the lock. These cards are used when the encoding machine (used to program the guest cards) isn’t working. Programming cards are also encrypted using the sitecode value, while the spare cards are not encrypted. When spare cards are created in a batch (to be used with programming cards), each subsequent card has an incremental value.
When a guest inserts the card into the lock, the data on the card is decrypted using the sitecode. Next, the expiration date is checked to see if it is still valid. Finally, the keycode value is checked and the lock opens if it is within the look-ahead range.
The Programming Port
A programming port, accessible using a DC adapter, is located at the bottom right of the lock. A portable programmer (PP) device is used to program the lock when it is installed and when batteries are replaced, which causes memory to reset. Upon installation, the PP is used to configure the lock with its ident value and keycode value.
The PP can also be used to connect to the lock and issue it commands, such as a command to open, but the PP would also need to supply the correct sitekey.
The PP can also be used to read blocks of memory from the lock using the programming port.
Security Issues
Brocious’s whitepaper describes various security issues pertaining to Onity locks. These issues are important for us to understand because they affect millions of hotel room doors outfitted with the these locks. They also represent the lack of basic security controls that other lock makers should avoid.
Microcontroller Vulnerability
If the sitecode is known, it is possible to open the lock by connecting to the programming port using a simple microcontroller, such as the inexpensive ($50 or less) and popular Arduino.
Cody Brocious describes the Arduino code (also known as a sketch) required to open the lock in Appendix A of his whitepaper. Basically, Brocious’s sketch takes advantage of the fact that any part of memory can be read from the programming port using the Arduino. Brocious uses this to read the sitecode from memory and then invokes the open command along with the sitecode, which causes the lock to open.
This is a severe security issue, given the millions of Onity locks installed in various locations around the world. Armed with only an Arduino microcontroller purchased at a neighborhood electronic store, anyone can walk up to a door protected by the lock and open it. In fact, famous hotel chains such as Holiday Inn, Extended Stay, Quality Inn, Laquinta Inn, Red Roof Inn, Motel Six, Budget Inn, Courtyard By Marriot, and Comfort Inn have reported burglaries as a result of this particular security issue.
Master Keycode in Lock Memory
Master keycards can be created by reading the master keycode from the lock memory. This value, in addition to the sitecode that can also be read from memory, can be used to construct master keys. As stated previously, the hotel may choose to segment locks in different sections of the venue with different master keys, so the master keycard can be limited to the particular section of the hotel real estate.
This is also a severe issue, because a one-time creation of the master keycard can allow a potential intruder access to an entire section of the hotel.
Unencrypted Spare Cards
As stated earlier, each subsequent spare card is created with an incremental value and is not encrypted. These spare cards are used when the encoding machine is not working. So, if an intruder were to get hold of a spare card with the value 500, he or she could create another card with the value 499 and 501 and attempt to open other locks.
Of course, it is not possible to easily ascertain exactly what doors the newly created spare card might open, which makes this attack a little difficult to execute.
Vendor Response
On July 24, 2012, Brocious revealed his research and his paper to the world, providing anyone armed with a cheap Arduino board with all the information needed to break into millions of hotel rooms. This also alerted the public to the risk they were taking when staying in hotel rooms protected by the Onity lock. Onity was also put under scrutiny by the public and hotel owners, who looked to them to provide a solution to the problem.
On July 25, 2012 and August 13, 2012, Onity issued a response, stating that they would issue a firmware upgrade to alleviate the issue. They also promised to insert a mechanical cap into the programming port to prevent access to the port, along with an additional TORX screw to secure the mechanical cap.
There are several problems with Onity’s statements. First, a mechanical cap makes it only slightly harder for the average criminal to break in, as they now need only a few additional physical tools (TORX-based screwdrivers are available for a few dollars in electronic and grocery stores) to break it open and eventually gain access to the programming port. Also, as pointed out in Brocious’s rebuttal, the design of the Onity lock does not allow for a true firmware update without updating the circuit board. Therefore, in reality, hotel owners would have to replace the actual circuit board (which is more costly on millions of installed locks) rather than issue a simple firmware update.
A few weeks after posting their response, Onity removed every trace of it from their website. Further investigation revealed that Onity had been working with certain hotel chains to replace circuit boards, depending upon the year the lock was manufactured.
This particular set of security concerns targeting a specific manufacturer reveals critical issues we must all be cognizant of when it comes to the design of mass-produced devices, the cost of fixes, and, ultimately, the negative effect on brand reputation for both the manufacturer (Onity) and the client (hotel chains upon whom patrons depend for their security). First, it is vital that mass-produced devices contain the ability to issue software-related fixes whenever possible, because it is less costly and therefore more scalable. Second, given the interest of independent researchers on security analysis, vendors need to be more transparent and engaging with the research community, to make sure they are promoting ethics and the trust of their ultimate consumers.
In this section, we took a look at one of the more popular door locks that millions of people depend on for their safety. Although the type of lock we looked at can be deemed traditional (magnetic-stripe based), it is still an important lesson for the future, because the next generation of locks are likely to include a hybrid magnetic stripes and additional mechanisms for electronic keys. The lessons learned in this section provide a solid foundation to continue our quest into the analysis of door locks that include wireless and electronic key functionality, as covered in the following sections.
The Case of Z-Wave-Enabled Door Locks
Z-Wave is a wireless protocol specifically designed for home automation. It transmits data in small chunks, so it can use less power and can easily be embedded in devices such as light bulbs, entertainment systems, and various household appliances.
The Z-Wave protocol was first developed by a company called Zen-Sys, which was acquired by Sigma Designs in 2008. The Z-Wave standard is maintained by a consortium of manufacturers as part of the Z-Wave Alliance forum.
To get started with Z-Wave, you first need to buy a developer kit from Sigma Designs and then you can download the Z-Wave SDK. To become Z-Wave certified, you must be a member of the Z-Wave Alliance.
In this section, we will discuss a specific security vulnerability discovered in the in Z-Wave implementation by Sigma Designs that affected door locks. This will provide a good perspective on critical security issues that have impacted the secure design of wireless door locks built with Z-Wave.
Z-Wave Protocol and Implementation Analysis
The Z-Wave protocol consists of the following layers:
Physical layer
This layer consists of physical layer specifications for radio communication.
Transport layer
This layer is responsible for packet transmission and retransmission, wnen the packet sent was not acknowledged to have been delivered to the destination. Devices with limited power supply, such as battery-powered door locks, are often designed to enter sleep mode. Such devices turn on their radio on a periodic basis to look for incoming data. The transport layer is responsible for coordinating the waking up of the device when such an event occurs. In this case, the transmitting device sends several back-to-back packets in 100ms intervals to make sure the sleeping device notices one of the packets.
Network layer
Z-Wave uses mesh-based networking that enables any node to talk to nearby nodes directly or through available relays. Nodes communicate directly if they are within range, or they can link with another node that has access to the destination node to exchange information. Every Z-Wave network can have up to 232 devices and one primary controller device. This flexibility, along with the low-power approach, makes Z-Wave attractive for devices used for home automation.
Application layer
This layer is responsible for parsing the packet and decoding the Z-Wave commands and parameters. The Z-Wave SDK can be used to parse the incoming payload, including the command class specified. Z-Wave command classes define specific functionality, such as alarm sensors, door locks, thermostats, and others. Each command class, in turn, can contain multiple commands, such as to get the temperature of a thermostat or to set the thermostat to a specific temperature.
In July 2013, Security researchers Behrang Fouladi and Sahand Ghanoun released a whitepaper that evaluated security implications surrounding the Z-Wave protocol affecting door locks. The authors also released a free tool called Z-Force, which lets you analyze captured Z-Wave traffic and transmit specifically crafted packets. The only additional hardware component required is the $75 CC1110 RF Transceiver.
In their quest to analyze the Z-Wave protocol, Fouladi and Ghanoun studied a particular door lock that used Z-Wave. Their research focused on the application layer of Z-Wave, where they found that that the first time the lock was paired with a controller (such as the Mi Casa Verde controller), the controller and the lock exchanged encryption keys. The keys are generated using a hardware-based pseudorandom number generator (PRNG) on the Z-Wave chip and encrypted using a hard-coded temporary default key in the chip’s firmware (the value of which was found to be four bytes of zero).
After successful key generation takes place, Fouladi and Ghanoun found that two new keys were created using the exchanged keys as input. First, a frame encryption key is created to encrypt the data payloads in subsequent communications. Next, a data origin authentication key is created to ensure that an external entity cannot replay the network packet, because it uses a message authentication code (MAC) algorithm that makes it difficult for a rogue entity to capture and replay the traffic. Fouladi and Ghanoun’s paper provides a detailed cryptographic analysis.
Exploiting Key Exchange Vulnerability
Fouladi and Ghanoun found that the Z-Wave implementation had a severe vulnerability pertaining to initiating the original key-exchange protocol between a given lock and the controller. They found that even after the lock was paired wih a controller, they could transmit a key-exchange packet that caused the lock to accept a brand-new shared key submitted by the attacker.
The flaw here is that, once paired with the controller, the lock should check the current key in its electrically erasable programmable read-only memory (EEPROM) and load the existing key if one exists. The lack of this fundamental validation step allowed Fouladi and Ghanoun to arbitrary open door door locks enabled by Sigma Design’s Z-Wave implementation.
Another side effect of this attack was that, since the shared keys on the lock were replaced with those of the attacker, events sent to the controller (such as “Door is Open”) will be rejected by the controller, because the keys shared between the lock and the controller are different, causing for the authenticity check to be rejected. This, in turn, creates a situation in which any logic built into the controller to alert owners of the door being open will be bypassed.
The research and findings by Fouladi and Ghanoun are a good example of how a simple validation check can have severe implications on the physical security of our homes and offices, where we rely upon door locks to help preserve the safety of ourselves and our loved ones. This incident shows the need for not just lock manufacturers, but also for those who implement firmware and radio protocols, to make sure their design is sound when it comes to security. In this case, a single oversight from the Z-Wave protocol implementer deemed the design of various locks insecure.
According to Fouladi and Ghanoun, Sigma Designs was responsive and worked with them to figure out how to best verify and proceed with the remediation of the vulnerability. Although this is a positive gesture as part of Sigma Designs, the issue of firmware updates still stands. Managers of physical facilities and homes do not usually have a process of checking for firmware updates and applying them to their door locks and controllers. In many cases, the functionality to update is not implemented or is too expensive to apply in scale.
The main point to take away, as we look into physical security in the IoT space, is that a simple oversight can continue to leave millions of homes vulnerable, given the complexity and cost of remediation.
Bluetooth Low Energy and Unlocking Via Mobile Apps
So far, we’ve studied research and attacks pertaining to magnetic-stripe keycard-enabled doors, providing a solid foundation to understand basic attacks against popular door locks. We’ve also looked at Z-Wave-enabled door locks and seen how a simple mistake in the implementation of a protocol can deem door locks insecure.
In this section, we will take a look at the Kwikset Kevo door lock, shown in Figure 2-3, which uses Bluetooth Low Energy (BLE). What makes this lock particularly interesting, from an IoT perspective, is the ability to control it using an iPhone app.
Figure 2-3. The Kwikset Kevo door lock
Here we will discuss known BLE weaknesses and how to capture wireless traffic, but we will pay particular attention to the iOS app, which sets this lock apart from the ones we have looked at so far.
Understanding Weaknesses in BLE and Using Packet-Capture Tools
Established in 2010 as part of the Bluetooth 4.0 standard, BLE has received phenomenal support in the industry because it uses low power, which is extremely important in devices such as smart phones, tablets, and IoT devices. Bluetooth hardware chips are available for as little as $2, which puts it at a significant advantage over competing protocols such as ZigBee and Z-Wave.
The Bluetooth Special Interest group maintains the current Bluetooth specification. Note that the specification covers classic Bluetooth as well as BLE, and these two standards are not compatible with each other (i.e., Bluetooth devices implemented on specification prior to 4.0 cannot communicate with another BLE device).
BLE operates in the 2.4 GHz spectrum, which is split into 40 channels, 37 of which are used to transmit data, while the other three are used by unconnected devices to broadcast device information and establish connections. Devices can broadcast data to any scanning device or receiver in listening range. This allows devices to send one-way data to other devices.
The broadcasting device sends an advertising packet, which contains a 31-byte payload that includes information about the broadcasting device and also any additional custom information. When 31 bytes is not enough to transmit the necessary information, BLE supports a mechanism called Scan Response, which listening devices can use to request a second advertising frame that is also 31 bytes long, bringing the total to 62 bytes.
WARNING
Note that the advertising packets used to broadcast do not contain any security mechanisms, so sensitive information should not be sent during broadcast.
To transmit data in both directions, devices need to establish a connection between a master device and a slave device. The master device picks up advertising packets transmitted by the slave and requests the slave to establish a permanent connection. A single device can act as a master and slave at the same time. A slave device can connect to multiple master devices, and a master device can connect to multiple slave devices.
BLE packets can be captured using a USB-based Ubertooth One device, along with the Ubertooth suite of software tools that can be built using the build guide. These tools include a spectrum analyzer (shown in Figure 2-4), which you should run immediately after purchasing an Ubertooth One, to make sure things are working correctly.
Figure 2-4. Ubertooth Spectrum Analyzer
The Ubertooth project aslo includes a tool called ubertooth-btle, which can be used to capture BLE traffic by running the following command:
[bash]$ ubertooth-btle -f -c capture.cap
The -f flag specifies that the tool should follow new BLE connections as they are established, and the -c flag specifies the name of the file the captured data should be written to. This file can be opened using the Wireshark network sniffer, as shown in Figure 2-5.
Figure 2-5. BLE advertising packet analysis in Wireshark
Every BLE packet contains an access address (AA), which is a unique identifier to refer to a specific connection. When a device transmits an advertising packet, a fixed AA of 0x8e89bed6 is used as the AA (as shown in Figure 2-5).
It is possible to mimic BLE devices by using the LightBlue iOS app on an iPhone, as shown in Figure 2-6. This is useful to test Ubertooth One functionality and make sure the capture tools are working. Notice that the advertising virtual device with name Blood Pressure shown in Figure 2-6 is captured in the Wireshark analysis shown in Figure 2-5.
Figure 2-6. Simulating a BLE device with the LightBlue iOS app
In his whitepaper “Bluetooth: With Low Energy Comes Low Security”, researcher Mike Ryan describes how to capture BLE connections. Essentially, connections hop across the 37 channels reserved for transmission using a hopIncrement value. The nextChannel value is calculated as follows:
nextChannel ≡ channel + hopIncrement (mod 37)
The master and the slave use this formula to calculate the next channel and hop to it at the same time. The master transmits a packet, followed by the slave. If there is no data to transmit, they will issue a network packet with no data. Therefore, in order to sniff BLE conections, the ubertooth-btle tool also hops along the same sequence of channels when the -f flag is specified.
In his paper, Ryan discloses a critical security issue in BLE that is important to understand: the key-exchange protocol used by BLE is vulnerable to brute-force attacks. The master and the slave device can use encryption to secure the data being transmitted. In order to do this, they must establish a shared secret known as the long-term key (LTK). In most cases, the master and the slave reuse the LTK for subsequent connections. The key-exchange protocol begins by selecting a temporary key (TK) based on the well-respected AES encryption protocol.
According to the BLE specification, the value of the TK is 0 if the Just Works mode is selected. This mode is used by devices that have little to no display or input mechanism, so the pairing is automatic. Otherwise, a value between 0 and 999999 is used. This is a more common method, in which the user is asked to verify the number generated on both the slave and the master devices using a display. Once the TK is calculated, the master and the slave use the TK to establish a short-term key (STK). The STK is used to eventually establish the LTK.
Ryan has released a tool called crackle, which takes captured BLE data and attempts to brute-force it using a TK value of 0 through 999999. Once the TK is found, the STK can easily be verified by decrypting it with the TK. Finally, the LTK can be obtained by decrypting it using the STK. Assuming the captured data is stored in a file called capture.pcap, the following command runs the crackle tool:
[bash]$ crackle -i capture.pcap -o decrypted.pcap
TK found: 249592
LTK found: 26db138d0aa63a12dd596228577c4731
Done, processed 106 total packets, decrypted 19
Now a tool such as Wireshark can open the decrypted.pcap file, which contains data in clear text. Note that Ryan’s brute-force method is not effective against out-of-band (OOB) mode, in which a 128-bit key is exchanged through a mode other than BLE. In this case, brute-forcing the entire 128-bit key space can be time consuming and ineffective. But most devices use either the Just Works mode or the six-digit-value mode, so a majority of BLE devices are vulnerable.
Anyone investigating a BLE IoT device should be familiar with Ryan’s research and the Ubertooth set of tools, because they are indispensable for analysis of network traffic and testing if the products in question are securely designed. Furthermore, as of this writing, the current Bluetooth specification (4.1) does not address Ryan’s brute-force attacks, so devices that rely upon BLE encryption remain vulnerable.
Kevo Kwikset Mobile App Insecurities
The Kwikset Kevo lock shown in Figure 2-3 can be operated via the companion Kevo iOS app on an iPhone.
Upon first launch, the user is asked to specify an email address and password. As shown in Figure 2-7, passwords must be at least eight characters long and include at least one number.
Figure 2-7. Minimum password requirements in the Kevo iPhone app
As shown in Figure 2-8, Kevo has implemented a policy that locks out the account if an incorrect password is attempted six times in a row. The lockout is effective for 24 hours.
Figure 2-8. Kevo account lockout after six incorrect attempts
If the user has forgotten his or her password, Kevo requires a correct answer to one of the security questions associated with the account (Figure 2-9). These questions are selected by the Kevo app, which prompts the user to answer them when creating the account.
Figure 2-9. Kevo security question for password reset
If a malicious person has temporarily gained access to the user’s email account, he or she can attempt to guess the answer or obtain it by social engineering the target via phishing attacks. While Kevo has done a good job with respect to requiring password complexity, implementing a lockout, and requiring a secret answer to a question, users should be aware that this type of information can and is routinely stolen by means of phishing attacks and malware.
The lock also implements a mechanism that allows users to send others electronic keys. All you have to do is provide the individual’s email address and that person will receive an email from Kevo, as shown in Figure 2-10. To unlock the lock, the target individual must first set up an account with the Kevo iPhone app and verify their email.
Figure 2-10. Sending electronic keys to external parties
The security risk here is the possibility of a malicious entity having gained temporary access to the target individual’s email account. Since the target has to set up a new account and answer the security questions for the first time, the malicious entity can pick arbitrary answers to the security questions, which will in turn lock out the legitimate user from resetting the password.
The lock contains a program button that is easily available by lifting the indoor cover. As shown in Figure 2-11, the user must press this button and hold the phone next to the lock to allow the phone to open the lock. Once this is set up, the user needs to touch the external face of the lock to wake it up. When this happens, the lock communicates with the iPhone using BLE and unlocks (or locks) when a preprogrammed iPhone is found within the vicinity.
Figure 2-11. Program button on physical lock to associate an iPhone
However, someone with a new iPhone that has never been programmed can just download the Kevo app and open the door, as long as they are able to guess or obtain the password and sign into the app. Though Kevo has implemented security mechanisms to control the password, a case could be made that this could be made more secure by requiring the pairing of a new device to use the program button even when the password is known.
This brings us to the issue of physical access to the lock itself. Lock bumping using various methods is a known art and technique that many individuals have perfected. In fact, when the Kevo lock itself was tested against bumping, individuals were able to bypass the physical key mechanism.
Given that physical bumping is a known issue affecting many locks, the mobile app feature implemented in Kevo can allow someone with an iPhone and temporary physical access to the lock to reprogram the lock within seconds to associate with a new lock—in essence, virtually bumping the lock. This can easily be done by holding the reset button shown in Figure 2-12 for a few seconds and then following the steps in Figure 2-11 to associate the lock with a new device. Someone with temporary physical access to the lock can easily do this without having the skills to physically bump the lock, which requires additional training and tools.
Figure 2-12. Reset button on physical lock
A caveat to this is that the individual would have to be inside the location being protected, because the reset and program buttons are internally facing. However, the risk here is in temporary workers (such as cleaning or maintenance staff), who might be around the home for a brief amount of time and can then easily abuse this feature to re-enter the house without permission. Furthermore, they can issue additional electronic keys to others.
This section provides a good example of issues we need to think through as we increasingly become dependent on our physical safety using mobile apps. Attacks such as password guessing and phishing have traditionally compromised our digital information, yet the same attacks on platforms such as the Kevo iPhone app can compromise the physical safety of our premises.
Lock manufacturers need to be increasingly cognizant of these threats and implement tighter controls. Given the physical nature of firmware within IoT devices, the situation is complicated by the fact that, even when updates are offered using the application interface, many users have the tendency to delay the update in interest of their time. Many people don’t want to have to deal with waiting for their door lock to install a security patch while they are in the middle of leaving or entering their house to attend to a chore.
This means that IoT-based manufacturers such as Kevo must strive to implement the right security features in the initial versions of their product. This is not easy, because it is hard to perfect security, so users of these devices should be aware of potential risks such as the ones outlined in this section.
Conclusion
Human beings have the understandable tendency to protect our belongings, our privacy, and our physical security. We invented door locks thousands of years ago and still depend upon the concept of doors and locks to protect our spaces.
The case for abuse of the best of locks using lock-picking tools is not news to most of us. However, with the advent of electronic door locks in the IoT space, we have to be aware of the decisions we are making today from a security perspective and how our decisions are likely to influence our future in an impactful way.
In the case of the Onity door lock, we’ve shown how a poor implementation of security can put millions of physical spaces at risk and how this situation has been exploited in various burglaries. This is also an example of how costly security fixes can be when people have to manually go up to millions of door locks and issue an update. Furthermore, the Onity example is a lesson for door lock manufacturers to do a better job of being transparent to their customers and the work of independent security researchers.
The Z-Wave example demonstrated how the designer of a network protocol can inadvertently put a large number of door locks at risk, such that they can be arbitrarily opened by simple hardware and software tools. When we think of IoT security, we ought to include and inspect the design principles being deployed by not just the ultimate physical manufacturers, but also organizations that supply SDKs and protocols that enable these devices.
Finally, in the case of BLE, we looked at the important research from Mike Ryan that has put many devices at risk, given the ability to brute-force connections written using the protocol. Additionally, we glanced upon the design of the Kevo door lock, which includes functionality to use iPhones to unlock doors that subject it to the same type of traditional attack vectors such as password guessing and phishing. We also looked at how the ability to reprogram the door lock can be viewed as a case of virtual lock picking, where the malicious entity has brief physical access to the lock, but in this case, the entity needs only an iPhone in lieu of a lesson in lock picking.
We hope to look forward to a bright future in which our IoT-based ecosystem enhance our lives and help us protect our spaces. This chapter provides the current state of popular door locks in the market and research that has deemed some of their mechanisms vulnerable. These lessons are fundamental in our understanding of what we need to correct in our approach to securing IoT door locks today as we continue to refine devices that will be in our lives in the future.