Archive for the ‘ Hardware ideas ’ Category

A simple method of key verification for multi-device key exchange

There are tons of devices around with practically no user faced interface at all, which need to communicate securely with other devices. This includes devices such as a wireless thermometer communicating with a HVAC unit or a wireless lock on your door communicating with your phone when you tell it what keys to accept. The risks include violation of privacy, physical damage and economic loss.

With the current Internet of Things trend there will only be more of this type of devices in the future. To be able to use these devices securely you need to ensure there are no room for anybody to attempt to MITM these connections (to intercept it so that they are in the middle and can see and manipulate all data), but practically ensuring that can be incredibly hard if the devices don’t even have a screen.

My idea for how to achieve it securely, with minimal interaction required from the user that links the devices together, is to show a visual pattern derived from a shared key.

But since most devices don’t have any interface beyond a single LED light, that could typically be hard to achieve. But that’s fortunately not a dead end, because the simple solution is to let the two devices you’re linking together both show the exact same on/off blinking pattern, perfectly synchronized, while you hold them edge to edge. If the patterns are identical, they have the same key (details below on how this can be guaranteed). If you see that they don’t blink in perfect synchronization, then you know the devices you are trying to link do NOT have a secure direct connection to each other.

So how do you link them together in the first place? There’s lots of methods, including using NFC and holding them together, temporarily using a wired connection (this likely won’t be common for consumer grade devices), using radio based method similar to WiFi WPS (press a button on both devices), and more. The two options likely to become the most common of those are the simultaneous button press method for wireless devices and NFC. While NFC has reasonable MITM resistance as a result of its design (simultaneously interfering with both parties of a connection is nearly impossible), that doesn’t guarantee that the user will notice an attack (attacking by connecting to the devices one at a time would still work).

So by confirming that two devices have a secure communication link by comparing blink patterns, it becomes easy to ensure configuration can be done securely for a wide range of devices. But how can we be sure of this? What can two devices communicate to allow security through comparing a blink pattern? Thanks to cryptographic key exchange this is easy, since all the devices have to do is to generate a large secret number each and perform an algorithm together like Diffie-Hellman. When two devices perform DH together, they generate a shared large secret number that no other device can know. This allows the devices to communicate securely by using this large number as an encryption key. And it also allows us to verify that it is these two devices that are talking to each other by running that number through a one-way transformation like a cryptographic hash function, and using that to generate the pattern to show – and only the two devices that were part of the same DH key exchange will show the same pattern.

If anybody tries to attack the connection and perform DH key exchange with the devices separately, they will end up having DIFFERENT secret numbers and will therefore NOT show the same blink pattern.

Note that due to human visual bias, there’s a certain risk with showing a pattern with very few components (to barely have more bits than what an attacker can bruteforce) you can’t just display the binary version of the hashed key this way, since the risk is too large that many different combinations of blink patterns would be confused with each other. This can however be solved easily, you can use a form of key expansion with a hash function to give you more unique bits to compare. One way to do this is by doing an iterated HMAC. With HMAC-SHA256 you get 256 bits to compare per HMAC key. So computing HMAC(Diffie-Hellman shared secret key, iteration number) for 10 iterations you get 2560 bits to compare. There’s actually a better way to expand the shared key into enough bits, that’s reliable and fairly independent of what key exchange algorithm you deploy: SHA3’s SHAKE256 algorithm. It’s something kind of in between a hash and a stream cipher, called an extendable-output function (XOF). You get to select how many bits of output you want, and it will process the input data and give you precisely that many bits out. You want 2500 bits exactly? That’s what it will give you. This means that if the user looks at the pattern for long enough, he WILL be able to identify mismatches. 


To achieve strong security, you only need for approximately 100+ pairs of bits to be identical to ensure bruteforce is unachievable – and in this setup, it means the user only needs to be able to verify that 4% of the full pattern is identical. So if you have a blink pattern where the blink rate is at 5 bits per second, continously comparing the pattern for any 20 seconds out of the 512 seconds it would take for the pattern to start repeating would correspond to verifying that 100 bits is identical. Of course the blinking would need to be kept synchronized, which would require the devices to synchronize their clocks before starting and could also require them to keep doing so while the blink pattern is showing to prevent “drift”.

There are of course other possible methods than just on/off blink. You could have an RGB LED to represent multiple bits for every blink. You could also have geometric patterns shown on a screen when holding the screens of two devices up against each other. You could even do the same thing for mechanical/haptic outputs like Braille screens so that blind people can do it too.

What if you can’t hold the two devices physically close to each other? You could use another device as a “courier”. As one example, by letting your smartphone perform key exchange through this method with both devices one by one, it could also then tell the two devices how to connect to each other and what encryption key to use. This way your smartphone would act as a trusted proxy for key exhange. It would also be possible to have a dedicated device for this, such as a small NFC tag with an RGB LED and a smartcard like chip to perform the key exchange with both devices. Using a tag like that would make configuration of new devices as simple as to hold it against the devices and comparing the pattern, and then the connection is secure, with minimal user interaction.

Then there’s the question of how to tell the devices that the key exchange was a success or not. Typically most devices will have at least ONE button somewhere. It could be as easy as one press = success, two presses = start over. If there’s no button, and they are the type of devices that just run one task as soon as they get power, then you could use multiple NFC taps in place of button presses. The device could respond with a long solid flash to confirm a successfull key exchange or repeated on/off blinking to show it did reset itself.

Originally posted here: http://www.reddit.com/r/Bitcoin/comments/2uah2b/weve_launched_the_coolwallet_on_indigogo/co6rru6

Relevant prior art (found via Google, there may be more):
http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=7E99A2B9922A0AE79CF6CAC65634FD8C?doi=10.1.1.41.1574
http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=7E99A2B9922A0AE79CF6CAC65634FD8C?doi=10.1.1.126.4242

What I want in a smartwatch

With the smartwatch trend just starting, there’s a lot of interesting new things showing up now. The new devices includes the Pebble, Qualcomm Toq, Agent, Galaxy Gear, Metawatch, i’m Watch, Sony Smartwatch and their previous LiveView, and many more. I find these devices fascinating, and I hope that it really isn’t just a temporary fad that will pass since I think there’s quite a few things they could to that would be useful. So I’m going to write down what I’m looking for in a smartwatch, and explain what I think about the devices that are in the market now or coming soon. What I really hope is that somebody will release a smartwatch that simply gets it right, and that won’t just die out and be forgotten in a month, and I think that what I’m going to list here will be some of the things that will decide if a smartwatch will succeed or fail.

One thing that is more important than ever for these devices are the interface. You can’t have too many buttons, you can’t have a touchscreen-only interface with a bunch of on-screen buttons (too hard to aim right, and you’ll cover the interface with your fingers), you can’t have a screen too small, you can’t have a screen too big, the buttons must be easy to press at all times (I’ve experienced watches with buttons you can’t access from certain common angles), the screen can’t really be curved (can be too hard to read) which can make it harder to design something that fits well, the watch can’t be too thick (so the electronics are very limited), etc…

As for the hardware, some of the things I want is a battery that lasts at least a full week (in combination with wireless charging such as with Qi), straps that can be replaced (and you should be able to put a clip instead of straps on it, if you want it somewhere else than on your arm), waterproof and minimal bezel. Maybe even a flashlight LED, but that’s probably a bit too much.

The basic look and interface I want is something that looks like Sony’s Smartwatch and LiveView, with something around a 2″ touchscreen, decent screen resolution, a capacitive “slider” below the screen like the volume control that Sony’s Bluetooth headset SE MW600 has which lets you feel approximately where along it your finger is and how far you’re moving it, and I’d want 3 buttons just below that “slider”. Most interactions would be composed of scrolling through the options with the slider, selecting options with the buttons and using swipes on the screen to bring up additional options. Basic text input could be performed with the slider by selecting groups of characters through sliding your finger left/right over it and picking a character from the visible group with the buttons and/or the screen (if somebody else can come up with a better suggestion, please explain it in the comments below).

I would absolutely NOT want a LED notification light, my phone’s LED is bothering me enough the few times I have it on my desk with unread notifications. What I’d rather want it to have is custom vibration patterns for different types of notifications so I know what kind of messages it is I haven’t read yet, and a screen that can be always on (like e-paper screens and the refractive Mirasol screen that Qualcomm developed) so that I can glance over it quickly. An optional feature could be to let the notification-dependent vibration patterns repeat if you shake the watch, so you don’t have to look at the screen to know if it’s a call or an email that you missed (like how phone LED:s can show different colors for different notifications).

One of the major things I want from a smartwatch is being able to work as a remote control. This both means controlling my phone over Bluetooth as well as controlling my TV via IR and really anything else via my phone’s network connection. I want music controls, I want to be able to mute my TV with it when there’s an incoming call, I want to be able to lock my laptop with it when I’m walking away from it, I want to be able to unlock my door with it, and much more. Via my smartphone I could trigger tasks in the app Tasker to do just about anything, including turning my lights and stereo on/off if I’ve got a home automation device or changing the profile on my phone to turn off the sound and switch wallpaper, or just about anything else.

Connectivity is also one of the most important part for a device like this. Since battery life is so important (and since a separate cell phone contract for it would be too expensive in many places), it will really have to depend on another device for internet connectivity and more. But it should still be able to work stand-alone. I don’t really see a need for it to have WiFi, since you’re going to want to use it wherever you want, and most places don’t actually have a WiFi network you can use. Chances are that Bluetooth tethering will be the best choice in most cases. You’re likely going to have your phone directly connected to the internet more often the watch (and the watch would likely not have as good antennas as the phone anyway). But what other kinds of connectivity would be useful in a smartwatch? I’ve already mentioned IR (and I’m hoping for full IrDA support which will be fast enough for small data exchanges over small distances without having to touch anything), but two things that really would be great is NFC and something that’s mostly unknown, often called electric field modulation or body area network (BAN) or personal area network (PAN). This type of wireless communication technology modifies the electric field of the body (that field is what makes half of all FM radios go crazy when you touch them) in order to send signals to objects you touch. And one of the more awesome things it can do is to act as a key, unlocking the door when you touch it’s handle, unlock your phone when you pick it up, unlock your laptop when you put your hands on it, and it can also let you exchange contact details when you shake hands, and much more. And NFC would mostly be used to link the smartwatch to all the devices such as smartphones already equipped with NFC, which makes pairing it easy (just let the devices touch and press a button on both to accept).

The kind of information I’d want to see on the screen is summaries of notifications (who called, how many unread emails are there, are there important news headlines, etc), who’s currently calling, unread text messages, music controls, and information from various phone apps. That info could be just about anything, including sports scores, game stats, comments on my blog, Reddit replies, and more. It would also be awesome in combination with navigation apps, with a compass + gyro + accelerometer combo you could put your phone back down in your pocket and let the smartwatch show you arrows for where to go and how many meters there are to the next turn, and other simple instructions – this would be amazing for everybody on a bike who sometimes have to rely on a map and be forced to stop to check it or wobble ahead with a paper map or their phone in their hands. Being able to use it for shopping checklists (and not have to unlock the phone every 3 minutes) would also be incredibly convenient, as well as using it for voice memos.

This thing would also be useful for two-factor authentication. If you’ve used the Google Authenticator app or one of those security tokens / one-time code dongles, you know what I’m talking about – let the device generate a one-time code based on a secret key, and enter that code on your computer (or smartphone app) to log in. In combination with a PIN on the smartwatch to be able to unlock the two-factor app, this would raise the security far above what most people currently are using to log in. Today most people are using passwords that are easy to guess, and even the hardest passwords are often snatched by spyware on the computer. With a PIN protected smartwatch, it’s faaar harder for an attacker to take control of your accounts.

The possibilities are endless, you just need to be a little creative to see them.

I have a lot more ideas and will update this post with them later on, but for now this will do.

%d bloggers like this: