The Tapplock, a Typical IoT Problem Child?

Fresh problems for the troubled smart padlock

Alasdair Allan
6 min readJun 20, 2018

It began with a video. The long delayed Tapplock, the “world’s first smart fingerprint padlock,” was apparently vulnerable to the simplest of attacks. Using a suction cup you could unscrew the back of the lock and then, with just a screwdriver, take it apart and open the shackle.

The Tapplock. (📷: Tapplock)

Back in 2016 Tapplock raised $320,000 on Indiegogo for their lock, leaning heavily on the “unbreakable design” in their pitch for funding. However delivered over a year late, with some backers still waiting for the Tapplock Lite, the lock has proved less than secure.

Despite claims from company that the vulnerability of the lock was down to a simple quality control issue, the publicity around the video led to some quite serious attention being paid to the smart padlock.

Andrew Tierney—better known to the security community as cybergibbons—of British security firm Pen Test Partners was the first to take a look at things, and it didn’t go well for the lock.

The shackle of the lock is built from a Zinc Aluminium alloy called ‘Zamark 3.’ More commonly used for die cast toy cars, and for door furniture like the handles rather than the padlocks that secure them, it was not a good choice. The “virtually unbreakable” padlock fell to a set of 12-inch bolt cutters in under 10 seconds.

Unlocking the Tapplock using Bluetooth, in under two seconds. (📷: Pen Test Partners)

But that wasn’t the worst of it, in fact it was probably the least of it. Because Tierney went on to defeat the security around the lock’s Bluetooth LE connection in under 45 minutes. Allowing anyone with a mobile phone to remotely unlock the Tapplock in around 2 seconds with just a simple script.

“The app communicates over HTTP. There is no transport encryption… and it was apparent that the lock was vulnerable to trivial replay attacks.” — Andrew Tierney, Pen Test Partners

Worse yet, after further investigation, it turned out that the only thing needed to unlock the padlock is to know the lock’s Bluetooth LE MAC address. Something that is broadcast by the lock itself during the standard discovery process. Yet, this wasn’t the end of things.

After Tierney disclosed the vulnerability, security researcher Vangelis Stykas took a look at the cloud backend of the lock and discovered that it was equally vulnerable.

“Tapplocks API endpoints had no security checks other than a valid token to access any data.This results in anyone with a valid login (easily obtained by creating an account) being able to manipulate every Tapplock available.”—Vangelis Stykas, Security Researcher

After some pressure Tapplock brought down their cloud service ahead of Stykas’ disclosure until a fix could be applied. But it turns that even this isn’t the end of the story, there’s a reason why the lock seems to be riddled with security problems.

Because it turns out that Don Coleman, my co-author on “Make: Bluetooth,” recognised the Bluetooth UUID of the Tapplock, and it explains so much. The code that Tapplock based their lock around was never intended to be secure.

“…I saw [Tierney] was writing to 6e400002-b5a3-f393-e0a9-e50e24dcca9e which I recognised as the Nordic Semiconductor UART service used by Adafruit, RFduino, Espruino, and others. I created an fake lock using a Microbit and Sandeep Mistry’s android-nRF5 with BLEPeripheral. Both the iOS and Android Tapplock apps discovered my [fake] peripheral as a lock. I used Tierney’s code to implement the MAC address to secret key logic and wrote a node app using Noble to find locks and send the unlock code. It sends the bytes to my fake lock.”—Don Coleman, Chariot Solutions

Investigating the Tapplock app with a decompiler, in a similar fashion to how Mistry and I reverse engineered the Estimote beacons a few years ago when we hacked the CES scavenger hunt, led Coleman to conclude that Tapplock was indeed using the Nordic Semiconductor UART service, or rather the RFduino version of the service.

“There’s actually a few RFduino references in the code and logs… There are a bunch of constants for the Serial API commands. Every Bluetooth action is reported to the cloud in plaintext which is why [Tierney] could see everything that was happening. The constants are named nicely so I could follow along and improve my Node.js Tapp library.” — Don Coleman, Chariot Solutions

However for anyone that’s built a product to a deadline the presence of the RFduino code come might not come as much of a surprise. There’s a great deal of pressure on startups to ship product, and real problems with the business models around the Internet of Things.

Prototypes, intended as nothing more than proof-of-concept, have an alarming tendency to ship as product. Not thought about during the prototyping phase, where code like RFduino UART service is reused wholesale to save time and effort, security is often times bolted on top as an after thought, after the prototype has already become the product.

For a lock that shipped late to crowdfunding backers after a “manufacturing experience [that had been] rocky” the pressure to turn a prototype into a product might well have been overwhelming.

In a way then, despite the multiple vulnerabilities discovered, the Tapplock is a typical problem child of the Internet of Things. It’s an extreme corner case of what happens when the software mantra of “ship early, ship often” is applied to hardware, where fixing problems is a lot harder than rolling out a new version of your website.

However the severity of the vulnerabilities found with the lock has brought a number of issues around the IoT into sharp focus. While vulnerabilities in smart devices are inevitable, the distinction here between creating them and exploiting them, especially in this case, can be stark.

“There is a very important distinction between the amount of time and skill it takes to find a vulnerability and the amount of time and skill it takes to exploit it.” — Andrew Tierney, Pen Test Partners

The vulnerabilities of the lock have even brought into question the concept on responsible disclosure, something that’s held almost as sacred in the security community as peer review is inside academia. The question as to who security researchers have a responsibility to, the company that builds a product, or the consumers that own and use it, is a key issue.

Another issue that the vulnerabilities raised was that reviews of the lock in the press, leading up to the disclosures of the vulnerabilities, have been almost entirely uncritical with little or no thought to security.

“People are uncritically reviewing [Internet of Things] devices with not even the slightest thought about security.” — Andrew Tierney, Pen Test Partners

Reviews of the lock seem to have taken the claims of the company around the security of the padlock as truth, without further investigation. For a product whose primary function was security, that wasn’t good journalism.

A smart network-connected product isn’t just another gadget. These are products that have access to, or can generate, potentially sensitive personal data. However like startups, journalists are often under intense time pressure. But it’s obvious that we need to do better, the flaws found in the Tapplock were surface level exploits—a real test of the lock would take days, not minutes—and should have been obvious enough for at least a few of the journalists that reviewed the lock to raise questions around its security.

As makers, building products, we need to put the security and privacy of our users and customers first. Security has to be built into our prototypes by design, and by default. It can no longer be an afterthought.

We need to push beyond the GDPR and look at the entire life cycle of a smart device. From manufacture, to final disposal, and to encourage our industry to make different and more ethical design choices. Because in the future, our own privacy and security, or a lack of it, will be inherent in the design of our smart devices.