On 3 Dec 2016, at 6:38, Kevin Townsend wrote:
On 03/12/16 11:54, Tim Hutt wrote:
Android and iOS don't allow you to specify the keys used by BLE's
native
encryption, but there is nothing stopping you using BLE as an
insecure
transport and implementing your own encryption on top of it (well
apart
from time, skill, and flash & RAM constraints). If you did that you
would
be able to use whatever keys you wanted because you implemented it.
This seems like something that would be nice to have as a proof of
concept demo in the core repo. I'm always interested in security, but
it's far enough outside my own core area of competence (HW design, RF
and sensors) that I know trying to roll my own code would do more harm
than good and give a false sense of security. If there are people on
the dev list with up to date experience in the field, I suspect a
decent number of end users would benefit from a basic starting point
to encrypt BLE communication across a simple service and
characteristic set. The nRF52 isn't 'fast' in terms of clock speed but
it's still a reasonably capable chip with on board AES and single
precision HW floating point acceleration, and there is a decent amount
of flash and SRAM available.
+1
I think even a PSK example would be helpful.
On the NRF52, I think it would be practical to run DTLS over the
transport, even if a bit heavyweight. It would be great to have an
example of that.
Sterling
