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

[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.