These examples come from this book that Keith put me onto, it's called Abusing the Internet of Things, Blackouts, Freakouts and Stakeouts. These were examples of what not to do. So, there's a company called Onity that made door locks for hotels and the room keys, we've all had these room keys, right? You stick them in a slot and LED lights up and you go. This particular one had used these cards with three tracks of magnetic information and Onity choosed to use track number three and not use the other two. So, there's all this information that we'll see in a minute because was put down on this track. The data fields on that track consists of the following fields, there's a 16-bit ident value. These values assigned identify which lock the card is associated with, and in the case of employees, like the housekeeping staff and so forth, the 16-bit identifier is the employee's ID and the locks have a list of these master key IDs, so when the service folks go down the hallway, they can just walk from room to room and the lock does a comparison and sees this is a master key, click, it opens and then they go. There were some flag bits, there was a 16-bit expiration date that defines the length of time the card is valid. So, you've got a reservation for a week, so there'll be some time in there where the key card won't work anymore. 24-bits that weren't used, and then a 24-bit what they call the keycode value plus a look-ahead value, so the way this works is the locks are programmed with these values example 100 and 50, so the lock would accept cards with values that went from 100 to 150. Every time a valid card is inserted in the lock, the lock resets its keycode value to the keycode value from the card that was just swiped that resulted in a successful lock opening, thereby invalidating all the other cards. So not only was there an expiration date associated with the older cards, but when a new key card was successfully swiped in lock, the lock updated this value and invalidated all of the previous 24-bit keycode values. These keycodes representing the master keys are also programmed into the lock, as I said. The fields on that mag strip are encrypted with a site code, it's a random 32-bit value assigned by the manufacturer to identify a specific property and a property meaning a Hilton hotel in Miami or Hyatt hotel in New York City, a very specific place. Okay? Not a property like the hotels read. No, it's not that kind of property, but the physical property. The encryption algorithm interestingly has some custom thing that they cooked up which is a poor choice, they should have used the standard encryption algorithm. What data does the lock have? So, the lock has the site code, it has an ident value it says,"Which lock am I?" Because there's all hundreds of locks in a hotel. Key codes for the master key values, date and time, so it has a notion of time. The most recent keycode value from the last card swipe lock open operation that's what the lock has. What's supposed to happen is the card is swiped, the data is decrypted using the site code which is stored in the lock, the ident and the expiration date fields are checked. Then the keycode value is checked and if it's in that look-ahead range, from 100 and 150, the lock opens and the lock remembers keycode value. Looks pretty good. Until cleverer engineer came along. So, these locks get set up initially when the hotel is setup and built and ready to start accepting guests. With a portable programmer that attaches by a little programming port on the bottom of the lock which isn't shown in this picture, but there's a little multi-pin connector. The technician would go around and plug the portable programmer in, and he would program up the lock and then he'd go to the next lock and the next lock, and then they were all ready to go. So, far so good. If I remember correctly, when I read this material, it was an engineering conference at some hotel that had these Onity Locks, and some enterprising engineer thought there's an access port at the bottom of this, and jury rigged a connector and hooked it up to a $50 Arduino. He was able to establish communications with the lock, there was no security in place. I don't know what protocol it was, I don't recall them, it doesn't matter. But he was able to instruct the lock to dump its memory. It dumped the memory out, back to his system that he could see. Now, this is a cartoon example, I made a text file and I wrote a dump program so you could see, but I just put in site code and the site code and these other field site, and I highlighted them in red. It turned out that the site code was just sitting not protected, not encrypted, sitting plain text in memory. Along and then they figured out that with the site code he could send it open commands and the lock would open, and not only that, they were able to take the master key codes from employees for like the housekeeping service, and with a key card programmer, they would have started manufacturing their own master keys. Hopefully you can see that this is a bad thing. So, many, many burglaries were reported at these hotels, and this tarnished the reputation of Onity lock company and the reputation of the hotels. This was a big deal. Onity's response initially was that they would place a mechanical cap over the programming port and secure it with a torx screw head. Because they thought not very many people carry a torx screw wrench with them, and update to the firmware. Right? Problem is as torx wrenches are actually easy to obtain, go to any hardware store, buy a little set of torx wrenches. They put a barrier in place to keep anybody from just walking up and plugging in something, but that barrier wasn't very high, so it was very easy for an attacker just to step over that barrier instead of it being a 50 foot wall to try to get over. It was like a toothpick on the ground, they just could walk right past that. So, getting a little cover, mechanical cap off it was no big deal. They finally realized that they needed to do a redesign of the printed circuit board to be updated in order to enable a secure firmware update, and I'm certain that they moved those site codes and those keys into something that was protected by encryption, and the author of this work didn't follow up any attempt subsequent attacks. But the point is Onity quietly worked with hotels, keep this out of the press as much as possible to replace the printed circuit boards and get the new firmware installed, and get these new circuit boards filled into these locks. So, think about it, millions of these printed circuit boards were replaced, what did that cost Onity? A lot. Cost them a lot of money. These boo boos can cause companies a huge amount of money, so on the security front, it's really important to be always applying the security mindset when you're doing product development. Z-Wave door lock was another good boo boo. This is the names of the folks that worked on this one, from that book previously mentioned. So, they went out and got a Z-Wave controller device and I'm going to go to Home Depot and get one of these Z-Wave door locks. So, what happened here is, so this is the researcher's Z-Wave controller over here. I can try and establish communication with this lock. So, originally, the device comes unpaired, and when it's in that state, from the Z-wave controller, they can send it a command to initiate a key-exchange. Okay. So far so good. So, common key is determined, maybe it's Diffie-Hellman or something along those lines. This common key is stored in EEPROM, and the device is paired now. Then, frame encryption key is generated and that key is used to encrypt the payloads in subsequent communication, and then data origin authentication key is generated to use to generate a MAC value to address replay attacks that we talked about in the previous class. The flaw in this lock was the researchers could transmit a new key-exchange packet to the lock, okay? It should be rejected because the device is paired already with a controller. The lock firmware failed to check if there was already an existing common key stored in EEPROM. It didn't do that check, and so it went through the key-exchange sequence again, enabling the Z-Wave controller or a different Z-Wave controller, I don't recall if they actually did that, but they showed that they could force the lock into a new key-exchange sequence effectively locking out the original controller which would have been the base unit in your house with an attacker's Z-Wave controller standing outside your front door, and then they could send the open command and get in your house. A simple bug. It could have been found with a code review, I don't know the details of what their development process was, but that one slipped through the cracks. This one talks about how Bluetooth BLE vulnerability, and this guy Mike Ryan wrote this whiepaper, and there's a link to it there if you want to go read it. Some Bluetooth master and a slave can use encryption to secure data exchanged between the nodes, and they must establish a shared secret key known as the long-term-key, LTK. The exchange process starts by selecting a temporary key, TK, and according to the BLE's specification, TK equals zero if "Just Works" mode is selected. So, a "Just Works" mode is used for devices that don't have any kind of a display, they don't have any kind of input capability, so there's no way to enter a pairing code or anything like that. So, think about industrial IoT sensors that are using Bluetooth BLE, they might be deployed in "Just Works" mode. Okay. So, if TK isn't equal to zero, then a value in the range from zero to 999,999 is used. Once that TK is established, then the device establishes a short-term key as a derived key, and then eventually establishes this long-term-key. Problem with that is Ryan created a tool called Crackle, and he captured the BLE data exchange and input that data into Crackle. Crackle attempted to perform a brute force attack on the temporary key by choosing values from zero up to that 999,999 number, and then, once the TK is found, their short-term key could be found by decrypting it with a temporary key, and then the long-term-key which is used for the primary data encryption between the two devices can be found by decrypting it with the short-term key. The flaw is that the range of the TK values is relatively small, and, unlike in AES256 where it's impractical to attempt a brute force approach because it takes kind of 40, 50 years in my scenario to try every single key. This one only required a million attempts, so it was practical to try every key. Devices don't have to use a "Just Works" mode, and can rely on schemes where the keys are 128-bits, but in this simple mode of Bluetooth BLE, there's a security risk, and it's subject to a brute force attack on the key. It's computationally reasonable to try a million keys in some reasonable amount of time. This is something to be aware of. Questions?
