Writing OOB Pin to softdevice

[Sai]

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)

[Sai]

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

[Ulrich Myhre]

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.

[Sai]

When you said "that certainly sounds much safer," were you referring to the USB option or the option of using ECDH for 128 bit key exchange?

Yes, you are right that I will have to control both sides of the exchange. I wonder how I can validate the idea some more to see if a startup would be interested in using such an encryption service.

[Ulrich Myhre]

Both are safer, but the USB option would be the safest. For the last question I really don't know, but I have seen a few posts asking about how to improve security, so there are interested parties. You should add that to the initial question so it is easier to get the responses you need.