August Lock Firmware Keys

David Wang, the guy who has done some absolutely amazing research on Apple’s secure enclave technology recently reached out to me on twitter, asking if August had stopped leaking the firmware keys for their locks. Unfortunately this is not a question I can answer in 140 characters. I will provide a more detailed writeup on the multiple issue with the August smart lock sometime in the near future. However, in this article I will be focusing on the firmware keys used by August.

Firmware key?

At present all August locks use a AES to secure communication between a user’s phone and their lock. Each lock is capable of having 256 encryption keys enrolled into it. These keys are numbered between 0 and 255. Only a session established using the key found in slot 0 can populate any of the other key slots. This makes key 0 the most privileged key in any August lock. This key, key 0, is the firmware key. It is important to note that all firmware keys apear to be are unique. As AES is a symmetrical encryption algorithm, and because of the way August establishes encrypted sessions between a user’s phone and an August lock this key must be known to both the lock and August’s webservers. However, none of this explains why I call it the firmware key. The reason I call it the firmware key is the first mechanism I discovered to obtain a lock’s 0 key was extracting it from firmware updates for the Texas Instruments bluetooth chip (CC2541) used by the August lock.  One of the things which makes learning a lock’s firmware key interesting is firmware keys do not appear to ever change. This means that if one can learn the firmware key for a lock they can gain access to the lock indefinitely (forever?). Further evidencing the longevity of firmware keys is the following string pulled from the latest version of August’s android application.

“Cannot delete key 0! What are you doing?”

What August Has Fixed

During my talk I mentioned that August let guests download firmware for any lock they had access to. Shortly afterwards August patched their webserver to not allow guests to download copies of the Texas Instruments chip’s firmware which containing the firmware key.

Why It Is Not Simple

Owners of August locks can still download the firmware for the Texas Instrument chip which contains the firmware key. This allows any user who is granted owner level access to a lock to obtain the firmware key. This key will give them access to the lock long after their owner status has been revoked. For this reason alone it remains a bad idea to buy a used August lock. Additionally, any guest who recovered a firmware key prior to August’s patch will find it still works.

As was previously mentioned downloading the firmware was the first mechanism I discovered to recover a firmware key, it is not the only mechanism. On the original August lock (not the homekit version) August implemented a feature which by design allows all users to read the entirety of the Texas Instrument chip’s flash memory. This chip is responsible for bluetooth communication, encryption of packets, decryption of packets, and key management. This is to say all 256 encryption keys are stored in the chips flash memory. This means that guests can still recover the firmware key (and any other key) for August locks over bluetooth LE by just asking for them.

As none of my August locks are the homekit version I have not been able to confirm if the homekit version has a similar feature which would allow a user to read the key material from the lock.

Tangential Tease

update: As this article is now being read by a non-technical audience I need to clarify this section. This tease pertains to on going research I am doing, while I do not have results I can share the initial indications are the security mechanisms in the keypad device appear to be very reasonable.

August locks use symmetrical encryption for security. August sells a product which communicates directly with their locks (without any internet connection) and is to be placed outside the user’s house. This device does not appear to have any secure key storage as it appears to (only?) uses a BCM20737. (This is unlike the iPhone which has a secure enclave for this purpose.) What are the security implications of this?