Re: Securing BLE device communication without OOB pairing (multiple devices)


Vikrant More <vikrant8051@...>
 

Hi Johan,

https://github.com/kmackay/micro-ecc has support for 5 standard curves: secp160r1, secp192r1, secp224r1, secp256r1, and secp256k1.

Out of secp256r1 and secp256k1, which one is used by Zephyr #BluetoothMesh ?

As per #BluetoothMesh specs, it should be FIPS-P256 curve.
Is Zephyr built in micro-ecc library different than what I am currently using ?

Thank You!!

On Sun, Mar 4, 2018 at 1:16 AM, Vikrant More <vikrant8051@...> wrote:
Hi Johan,

Thanks for reply !!

Ok, but I don't know how to integrate & use it in my current project since there is no any documentation available about it.
So I chose alternate way but will figure out how to use Zephyr's library in coming days.

>>Before this, Admin will Blink LED on BLE Device before transferring #CommonKey to it using Smartphone App.
>>Once user confirm it, then only #CommonKey get transfer as command to 3rd characteristic & BLE device save it as #CommonKey.

>>>>You can acheive confidentiality with the ECDH method, but without some
>>>>OOB mechanism you won't be able to securely authenticate the peer you're
>>>>talking to. So I don't see this as any different than doing pairing
>>>>using NoInputNoOutput as the IO capability.

Here, before initiating ECDH to generate share secret , Smartphone App will send commands to LED lights that will blink it for while
& App will ask Admin User -> "Have you seen any Blinking LED ?"

If he/she clicks on "yes" then only process go ahead.
[ Here APP will only connect to Devices which are in vicinity by checking their signal strength (RSSI) ]
So I think, this method may solve the issue of Authentication. Am I right ?

May be it is not enough....but I don't have any other option since LED Lights generally does not have OOB channels.
I can't use NFC since not every phone have that feature. So ... ??

Thank You !!

On Sat, Mar 3, 2018 at 9:18 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

micro-ecc is what the Zephyr TinyCrypt uses, and it is also what the
Zephyr Bluetooth Security Manager (LE pairing) and mesh implementations
use, so no need to start installing micro-ecc separately.

You can acheive confidentiality with the ECDH method, but without some
OOB mechanism you won't be able to securely authenticate the peer you're
talking to. So I don't see this as any different than doing pairing
using NoInputNoOutput as the IO capability.

Johan

On Sat, Mar 03, 2018, Vikrant More wrote:
> Hello World !!
>
> I found solution as micro-ecc library -> https://github.com/kmackay/
> micro-ecc
> to generate #AdminKey or Master key on both sides without transferring
> it on insecure Bluetooth Link.
>
> Thank You !!
>
> On Sat, Mar 3, 2018 at 12:57 PM, Vikrant More <vikrant8051@...> wrote:
>
> > Hello,
> >
> > How to use ECDH mechanism to establish common #AdminKey or Master Key,
> > using functions defined in $zephyr_base/subsys/bluetooth/host/ecc.h for
> > normal BLE devices ?
> >
> > We uses this concept, in Bluetooth Mesh where every time new
> > Public-Private Key pair get generated on both sides,
> > using which a Master key established after public keys get exchange over
> > insecure channel.
> >
> > I think it will solve my issue. How to check this mechanism without
> > Android/iOS App after implemented it on Device side ?
> >
> > Thank You !!
> >
> > On Fri, Mar 2, 2018 at 11:20 PM, Vikrant More <vikrant8051@...>
> > wrote:
> >
> >> Hello,
> >> If I enabled encryption or authentication to access BLE device
> >> characteristic, we have to do OOB pairing.
> >>
> >> But in some cases, it is not possible like budget LED lights. In this
> >> case, how to make secure communication at Zephyr App level using security
> >> keys ?
> >>
> >> ------------------------------------------------------------
> >> ----------------------------------------
> >> This is my implementation where there are 3 characteristics:
> >> 1) 1st (read) characteristic always generates 16 bytes of random data
> >> 2) 2nd (write) characteristic used for authentication
> >> 3) 3rd (write) characteristic which accepts commands
> >>
> >> When BLE device is in factory reset mode,
> >> then Smartphone App read random data from 1st Characteristic & save it as
> >> #AdminKey (AES-128) for that device.
> >>
> >> Then it again requests(read) another random data from 1st characteristic
> >> , encrypt it using #AdminKey & send to 2nd characteristic.
> >>
> >> On BLE device side, it will decrypt data using #AdminKey & compare it
> >> with recently send random data. If data matched then BLE device saves
> >> #AdminKey on self flash memory.
> >>
> >> So every device will have unique #AdminKey.
> >>
> >> Now here after, Smartphone who send encrypted random data which is
> >> encrypted using #AdminKey to 2nd characteristic will get #admin access.
> >> (Random Data from 1st Characteristic)
> >>
> >> Now if I wanna give access to my guests or family members, then in that
> >> case I have to set 16-bytes of #CommonKey (manually entered number) for all
> >> BLE devices.
> >>
> >> Before this, Admin will Blink LED on BLE Device before transferring
> >> #CommonKey to it using Smartphone App. Once user confirm it, then only
> >> #CommonKey get transfer as command to 3rd characteristic & BLE device save
> >> it as #CommonKey.
> >>
> >> As name suggest, #CommonKey is same for all devices. So here onward,
> >> Smartphone who send encrypted random data using #CommonKey will get #guest
> >> access of that BLE device. Using #guest access, in case of LED lights user
> >> can only do On/Off & intensity control.
> >>
> >> So 3rd characteristic only accept commands when user authentic itself as
> >> #admin or #guest.
> >>
> >> Can I go ahead with this method ?
> >>
> >> But I think it is not secure, since data is exchanged over unencrypted
> >> link. Isn't it ?
> >>
> >> Is somebody has better robust secure solution as per my requirements ?
> >>
> >> Thank You !!
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >


Join users@lists.zephyrproject.org to automatically receive all group messages.