I'm creating a web app which connects to a control device. I want to secure it to make sure no one but the user can control it. for that I want to use LE secure connection pairing with numeric comparison. But my control device doesn't have a display, so I want to send the security code to my web app so the user can check the code's there and 'ok' the connection on the web app.
I wonder if this is possible and if I don't lose security while doing it this way
How do you plan to send the security code to the web app? To do it programatically implies that you already have a secure channel to the device.
On devices without a screen I've seen the security code printed on a sticker. It isn't as secure as a code which can change every time a new pairing occurs but is better than no code at all.
If the device has a button you can require the user press it before pairing or other privileged actions are taken.
Related
Looking at various GATT-based profiles, it seems that services are always exposed in the GATT server rather than the GATT client. For instance, the Time Profile (TIP) has the server exposing the Current Time Service (CTS). So, if a phone is to update a heart rate monitor with the current time using TIP, the phone will be the server whereas the monitor will be the client. But, being a heart rate monitor, the Heart Rate Profile expects the monitor to be a GATT server.
So, for a monitor that takes the current time from a phone, should it be a GATT client or server? Should it be set as a client whilst time syncing with the phone and set as a server otherwise? Should a custom profile be implemented such that the CTS is exposed in the client instead?
Thanks
Generic Attribute Profile (GATT) defines how server and client communicate with
each other using Attribute Protocol for the purpose of transporting data. Client
and server roles are determined when a procedure is initiated and released when the procedure is ended. Hence, a device can act in both roles at the same time.
I would suggest you to read Bluetooth Spec. In Part G 2.2 it explains the roles and configurations.
Client—This is the device that initiates commands and requests towards the
server and can receive responses, indications and notifications sent by the
server.
Server—This is the device that accepts incoming commands and requests
from the client and sends responses, indications and notifications to a client.
Back to your question:
The Time profile enables the device to get the date, time, time zone,
and DST information and control the functions related the time.
In your case, the monitor will be the GATT client when it takes the time from a phone. However, it can be a server at the same time for another procedure (operation, request etc.) with the phone.
In short, client and server roles are not fixed to the devices. When your phone exposes the current time, it will be server. Similarly, when it gets the current time from the monitor, it will be client. no need to customize the profile. If you want your phone to get the current time from a device and expose it to another device, just implement the same profile for client and server roles to your phone.
EDIT:
According to TIP profile spec, to get the current time information, the GATT Read Characteristic Value sub-procedure shall be used with the handle of the Current Time Characteristic. Monitor as a client will read the Current Time Characteristic from the GATT Table of the server (in this case it is the phone). As soon as the monitor retrieves the value from phone, it can update its Current Time Characteristic Value, and expose it to its environment in three ways:
Notifying it to its subscribed clients (BLE notifications). If you do it in this way, you will customize the Bluetooth TIP profile since this procedure is not defined there (I had a quick look to the document and didn't see it).
Broadcasting it in the advertisement packet (Doesn't require BLE connection)
Another BLE device connects to the monitor and reads the Current Time Characteristic value. This is the recommended way if you want to use Bluetooth SIG defined TIP profile as a server.
I'd like my Fenix 3 to do the following:
Trigger = hold down start button (i.e. shortcut)
Send message via BT or WiFi to a server (Linux or Windows or Arduino or whatever)
I'll take care of the message and open/close my garage door.
After a bike tour I'd like to easily and safely open my garage door. I have a VmWare server running at home. I could use one of the machines on this server to listen to the messages or I could set up an Arduino or similar.
The main question is: Can I write an IQ app that utilizes the shortcut concept on the clock, i.e. triggered by long click on start or lap button?
Clarification: There seems to be some kind of global actions for long press. I can for example assign "Save position" to long press on start/stop. This works even from inside of other apps.
Can the clock communicate with sensors (i.e. Arduino or other BT client) even if not in training mode?
Clarification: I need to communicate directly with my Arduino via Bluetooth, i.e. not via my iPhone.
Thanks in advance.
Short answer: Yes
Long answer: If you record the time a keydown event comes in, and then check for a "long" press when the key is let up based on the time difference, you can fake it. There is not an event for a long press of a physical key though. I am also pretty sure your app needs to be the current one for this to work.
Link to the InputDelegate event options: http://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/WatchUi/InputDelegate.html
As for the sensors question, I am not sure exactly what you are asking. Your app can do whatever you want, and it is my understanding that only one app will be running at a time.
Disclaimer: Thus far I have only been working with the emulator, I'm still waiting for my watch to get here.
You cannot write anything that hijacks user input events from another active application (including the watch face). You could make your own watch face, but it wouldn't have the ability to send network messages and it has only one way to accept user input (the look-at-watch gesture).
This is something that you can do pretty easily from a watch-app or a widget. Assuming that your fenix3 is connected to your phone via bluetooth, you can send http get requests as you see fit.
I've written a simple app that I call GIFTTT that uses the IFTTT Maker channel to open/close my garage door (and all sorts of other things).
We are testing Bluetooth in WEC2013 with a USB based dongle from generic vendor on iMx6 platform. We are using the default HCI Transport layer provided with WEC2013 BSP.
BT is turned on and able to scan all the nearby devices.
We have enabled following set of sysgen variables and registry entry.
Sysgen Variables:
SYSGEN_BTH (Bluetooth stack with universal loadable driver)
SYSGEN_BTH_BTHUTIL (Bluetooth Profile Management APIs)
SYSGEN_BTH_HID_KEYBOARD (Bluetooth HID - Keyboard)
SYSGEN_BTH_HID_MOUSE (Bluetooth HID - Mouse)
SYSGEN_BTH_AG (Bluetooth HS/HF and Audio gateway service)
SYSGEN_BTH_SETTINGS (Bluetooth settings UI)
SYSGEN_OBEX_CLIENT (Obex client)
SYSGEN_OBEX_SERVER (Obex server)
SYSGEN_OBEX_FILEBROWSER (OBEX file browser)
SYSGEN_OBEX_INBOX (OBEX Inbox)
SYSGEN_FTPD (FTP server)
SYSGEN_BTH_BTHSSVC(Support Secure Simple Pairing)
Registry entry:
[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\Default\224_1_1\Default\Bluetooth_USB_Driver]
"DLL"="bthusb.dll"
[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\Default\Default\224_1_1\Bluetooth_USB_Driver]
"DLL"="bthusb.dll"
[HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\Transports\PnP\{B3DD867A-1E6E-4215-8AA7-EAC1DFC46548}]
"flags"=dword:80000000
"driver"="bthusb.dll"
"resetdelay"=dword:0
"PacketSize"=dword:200
"BlockSize"=dword:5
[HKEY_LOCAL_MACHINE\ControlPanel\Bluetooth]
"PinAttemptInterval"=dword:200000
"PinEntries"=multi_sz:"0000","8888"
We observed different scenario's in pairing to a device.
Connecting to mobile from board(imx6+usb dongle running with WEC2013)
Here pairing is success when pair is initiated through bthsettings UI. It will trigger the 6-digit automated passkey on both the sides.
Connecting from mobile to board without opening bthsettings UI.
Here pairing is success once. When the UI is not open (BT is ON in background), pairing is initiated from mobile, both will be paired using automated
6-digit passkey method. But this will internally invoke bthsettings UI, so next time when we give pairing from mobile, mobile side will ask for manual
key insertion. As soon as the key is entered on mobile and pair is pressed, pairing rejected notification will be observed on mobile terminal.
So pairing is failed in this case.
Connecting from mobile to board when bthsettings is opened.
Here pairing is failed. When pair is initiated from mobile, manual key insertion UI will be invoked and when key is inserted and pair is pressed,
pairing rejected notification will be displayed on mobile terminal and pairing is failed.
In these failed senarios, the upper layer is responding with "Pin code request negative reply command" for "Pin code request event" from chip.
We need input on this pairing process. Why this automated key and manual key generation methods are invoked based on whether UI is open or never opened? And why manual key case is failing?
Are we missing any registry entry or stack feature ?
It all got to do with SSP(Secured Simple Pairing), which decides the pairing authentication model. This is affected in WEC8(2013) through the changes under bthsettings.
Under WEC8 they disable SSP(via function EnbaleSSP()) whenever a connection is initiated from external device and enable back SSP when conenction is initiated internally. Though this is the logic, I'm not aware of why this is introduced(and is it a bug, that'll be fixed in upcoming updates as they initially did for NDIS 5 wireless driver connection).
And as a workaround to this, disable EnableSSP().
Also SYSGEN_BTH_BTHSSVC is implicitly needed by SYSGEN_BTH_SETTINGS component, and the link is broken under WEC8.
Microsoft has provided the fix in April 2015 update. Details available here.
Currently we are setting up a Bluetooth LE device specification and we are running against the following:
The client doesn't want to pair the device via the settings menu. There is a mobile app which should connect to the peripheral.
Now the following, this is the problem:
When connecting, how do we secure our characteristics? We were thinking about prefixing a write request, but what about read requests?
We don't want everybody to see the not so sensitive data. Since it's not sensitive we don't need high security but we still need to secure it some way just in case.
Does anybody know how to do this? How to secure a characteristic?
Thanks in advance,
You could implement a challenge-response system on connection - when you connect to the peripheral you read a value from a characteristic which is randomised by the peripheral. This value has to be hashed in some way using a shared-secret and then written back to the characteristic. The peripheral then verifies the hashed value. If it matches then it populates the other characteristics and accepts write requests.
Once the central disconnects from the peripheral it ignores write requests and zeros its read characteristics until the next connection/hash handshake.
You must add Security Mode 1 Level 3 to your Services. Then, all the Service's characteristics will be protected.
I am developing a mobile application which sends some encrypted data to a Bluetooth device and this Bluetooth device sends the data to server. My question is that in this case how can I prevent replay attacks. Someone might use a fake Bluetooth device to get the signals and send them to the server.
The mobile application works in offline mode and has no connection to server. So using a synchronized nonce or counter doesn't help.
I can not also use time-stamp to narrow the attack window because mobile phone's time might not be correct (synchronized with a time server).
Communication between my mobile application and Bluetooth device is one-way and my mobile application can only send data to the device.
One way to do this would be to use a counter, but allow it to skip a large number of steps. For example if the last counter value you've seen from phone A is 123 and you get something with a counter value of 156 then you accept it, but anything outside the range of [124, 1000123] you discard (1000000 being completely arbitrary and dependent on your use case).
This would prevent a replay attack, but you do have to take care that the transmissions aren't malleable or it would be trivial to forge counter numbers. This could be accomplished by having a secret per device MAC key (which would only be possible if the server and phone communicate beforehand).
It's worth stating that it would be good for the transactions to be authenticated (only phone A has the capability to generate a message saying it's from phone A) or an attacker could move up the counter very quickly and do a denial of service on phone A. However, from the way you phrased the question it sounds like it's something you've already dealt with.