Looking back at Republica 2019 and IndieWebCampBerlin

A personal view from republicamp

It was a while ago now since I was in Berlin for both IndieWebCampBerlin and Republica19. As I needed to report back to BBC R&D, I created a slide deck which I finally gave today at work. It would have been earlier in the month if I wasn’t sick when it was arranged.

I posted a modified version of the slide deck on slideshare, but its pretty much there. Of course like most of my presentations, its better with me delivering it but you can get a sense of what I found interesting and why.

The slides are divided into 2 parts. Indiewebcamp is slides 4-23 and Republica is slides 24-73.

Enjoy!

Google Titan key security problem?

I was sure I tooted/tweet a thank you to the Google team in Berlin’s Re:publica conference. But it looks like it never quite happened due to connectivity issues with the wifi at certain points of the day.

So first of all I want to say thanks for giving me a titan security key for spending time listening to what changes Google had made to their security as announced in Google IO 2019.

I was surprised to see Google there with all the ill feeling about the 5 stacks, their monopoly and business practice.

But before I could get home try the key/system, I saw a bunch of problems with the key.

Google Titan Bluetooth Security Key Can Be Used to Hack Paired Devices

Titan-ic disaster: Bluetooth blunder sinks Google’s 2FA keys, free replacements offered

Obviously I was a little concerned, although I had not added the titan key to my google 2 factor auth yet.

After a bunch of reading, it seems its not completely flawed. The Google security blog confirms my research.

The problem is with the Bluetooth fob which to be honest is super convenient wasn’t the most secure idea in the world. The bluetooth stack is limited in its range but because of that, its not got as much security as most things on the net.

Due to a misconfiguration in the Titan Security Keys’ Bluetooth pairing protocols, it is possible for an attacker who is physically close to you at the moment you use your security key — within approximately 30 feet — to (a) communicate with your security key, or (b) communicate with the device to which your key is paired. In order for the misconfiguration to be exploited, an attacker would have to align a series of events in close coordination:

When you’re trying to sign into an account on your device, you are normally asked to press the button on your BLE security key to activate it. An attacker in close physical proximity at that moment in time can potentially connect their own device to your affected security key before your own device connects. In this set of circumstances, the attacker could sign into your account using their own device if the attacker somehow already obtained your username and password and could time these events exactly.

Before you can use your security key, it must be paired to your device. Once paired, an attacker in close physical proximity to you could use their device to masquerade as your affected security key and connect to your device at the moment you are asked to press the button on your key. After that, they could attempt to change their device to appear as a Bluetooth keyboard or mouse and potentially take actions on your device.

This all being a big mistake, Google has offered a replacement key. However because my key hasn’t been added to my account yet, I get a message saying no action is required but a email to override this. However after double checking my key is a type T3 meaning it wasn’t effected.

Good work Google…