This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Writing OOB Pin to softdevice

Theoretically, if I were to expose a GATT service to let a central write a 128 bit PIN to my characteristic, would I then be able to persist this PIN somewhere in the softdevice so that all other services could starting using OOB as their security level? If so, where? What other settings need to change to support OOB once this is done?

Edit (Jul-1-14): As suggested below, I should throw in that I'm also trying to validate the demand for a way to deliver an OOB PIN to an SoC. (@Ulrich - Thanks for the tip)

Parents
  • Thank you for your well thought out answer. I understand what you are saying about PIN sharing being as good as its weakest link. I am trying to see if there would be a market for a BLE chip which uses USB to accept an OOB pin. The lack of centrals supporting OOB is a bit of a chicken/egg problem for which I don't have any solution.

    For now, I wrote a 128bit key using a ECDH key exchange GATT service. Then I added the ble_app_hrs service and an open source AES implementation on to my ECDH service to encrypt heart rate information. I have this entire service stack sharing secret keys, encrypting heart rate information, and streaming this encrypted info to a tiny iPhone app I wrote.

    Since my service successfully shares private keys using ECDH, maybe OOB key exchange can be solved somehow. Any thoughts?

    ECDH: github.com/.../nano-ecc AES: github.com/.../tiny-AES128-C

  • I'm not cryptographer, but that certainly sounds much safer than sending the OOB key in the plain :)

    You are right in that OOB central support is the main road bump to accomplish things with less application responsibility, and I can only cross my fingers and hope we will see a solution for that soon.

    For now, it is possible to add read and write authorization to all of your attributes and add an encryption/decryption layer that these values get filtered through before being sent/written - and which initiates the ECDH key exchange if it has not yet been performed. I don't think there are any adopted services for encryption yet, so you would have to control both sides in all of your applications to pull this off.

Reply
  • I'm not cryptographer, but that certainly sounds much safer than sending the OOB key in the plain :)

    You are right in that OOB central support is the main road bump to accomplish things with less application responsibility, and I can only cross my fingers and hope we will see a solution for that soon.

    For now, it is possible to add read and write authorization to all of your attributes and add an encryption/decryption layer that these values get filtered through before being sent/written - and which initiates the ECDH key exchange if it has not yet been performed. I don't think there are any adopted services for encryption yet, so you would have to control both sides in all of your applications to pull this off.

Children
No Data
Related