SHA-256

Hi Jay,

1. The only hardware accelerated security module is the AES-128.

2. IAR is the only supported IDE/Compiler for the 8051 architecture.

Best Regards

Joakim

Ok, it is clear about hardware acceleration for AES-128, and the IAR compiler exclusiveness.

My 'similar' question would be if the IAR environment has ( or planning to have ) libraries for BigNumbers, some crypto libraries, etc? ( for CC2541)...

Thanks,

Alex.

Hi Alex,

Not that I know of. You may want to consult IAR directly. Feel free to share any information you obtain,

Best Regards

Joakim

Joakim - 

Thanks for the speedy answer. 

My next question would be -- is it feasible ( possible? )  to do something like the core of srp ( srp.stanford.edu) on CC2540/CC2541? 

Thanks,

Alexl.

Hi Alexl,

I'm not familiar with SRP so I would not be able to answer that. What specific security are you looking for? In the current BLuetooth low energy (BTv4.1) there are some limitations, but generally, the following already applies to the protocol;

• Authentication – Protection against MITM attacks, either by passcode or out of band pairing
• Authorization – Possibility to disallow features or data access for unknown or limited devices
• Integrity – Ensures non-corrupted and reliable data transfer over the air
• Confidentiality – Encryption by 128bit Advanced Encryption Standard (AES)
• Privacy – Protection against sniffing by using frequency hopping on 37 channels

Best Regards

Joakim

Joakim - 

First, I should say, that I'm not a security expert, so my considerations below may be false.

I agree and understand, that BTv4.1  ( and BTv4.0), are providing support for security protocols and methods. You mentioned them. And most is boiling down for AES-128...

But I think  that the 'devil is in details', as usual. In case of BT specs -- key(s) exchange ( or initial set-up) and  key storage.  The BT specs suggests: 
a. no key ( key == 0) 
b. key within 0-999,9999 range; // which is breakable within less then a second... based on https://lacklustre.net/bluetooth/
c.Out-of-band key exchange/negotiations.

Let us put aside the key storage for a while. ( My understanding is that for getting the key(s) from 'storage' - in general, you would need to get physical possession of the device, or control over device...).

At this point, my focus is on initial key(s) setup, exchange. The goal - not to make my devices bullet proof from the 'government sponsored attacks ...', but to make the BLE usage practical. Let me elaborate:

Around 2 years ago, when I was using TI sniffer in my home office, I saw only my toy devices. Today, I  see a couple of  Apple TV from my neighbours, and somebody else toys...  I guess, in a future -- it would be even more devices around... Based on that,  I think:

1. Option a)  above -- no key ( key 0 ) - is not an option. Just to eliminate the mistakes of wrongly connecting to somebody else device, with no bad or fun intentions in mind.

2. Option b) looks better... But then... There is no protection if somebody has 'bad intentions'.  I still do not want somebody get control of my lights, door bell,  alarm clock, etc... ( I'm intentionally skipping cases of locks, engine start-up, etc. There are article on Internet already regarding those security threats. I'm not even thinking about THOSE GUYS... My bigger concern is somebody started to learn security, and in need of some practicing... let me call it 'fun intentions' ;)  I still do not want them to gain access on my devices ).

3. Option c) - out of band exchange. It seems to address my concerns. ( Even if it is only 1  key exchange at the beginning, and we are not talking about backward/forward security ). 
But then, I started to look into implementation, thinking how to make it... And I  found no simple and elegant solution. And even if such  is found and implemented -- it is probably going to be proprietary, meaning compatibly issues, etc.

While reading on subject, I run into SRP ( srp.stanford.edu). Which seems to address my challenge - just to use it as substitution for out-of-band key exchange. ( The idea is not mine, I'm not the first suggesting it...)

My question  - is it doable on CC2540/CC2541 chips?  If it is doable, are there some peaces already -- SHA libs, Bignuber libs, crypto lib(s), etc. -  available for those chips? I wonder if somebody is working on such implementation already - specifically on those  chips. 

Or, may be I've overlooked something. I know that a lot may be done on 8-bit chip. But  may be I'm missing some 'underwater stone'.

Alex.

Hi Alex,

For future Bluetooth low energy releases, I know that there are discussions around Diffie-Hellman (DH) Key Exchange and also Elliptic Curve Cryptography (ECC). Mathematically, ECC is very hard to break. There are people who state it's unbreakable but my assumption is always that everything can be broken giving right set of equipment and time. It's also a question of "worth"... Is it worth spending $$$ to build system Y to break the security in X hours/days/weeks.

Anyhow, you are correct that the future must bring more secure systems and I believe Bluetooth SIG is well aware of that.

You can do advanced stuff on CC2540/41 when it comes to security, although it requires some decent knowledge to be able to implement it and also to make it fit in the flash... Maybe assembly programming is needed. Also note that the power consumption will significantly improve when introducing more advanced security.

I personally believe that within 1-2 years, security is going to be much more advanced within Bluetooth Smart. Partly by more adopted security modules by BT SIG, but also more complex and higher performing solutions in terms of wireless MCUs offering.

Also, I know for a fact that a couple of CC2541 implementations out on the field includes very powerful application level security. I do not know any details and I do not think the companies behind the implementations wants to share either.

Best Regards

Joakim

Responding to the original question about sha-256.  Yes, it is possible to run SHA-256 on the 8051.  r-project has a public domain version available at http://svn.r-project.org/.  Removing the 64-bit data types results in code that compiles with IAR.  Without further optimizations, the computations may run long enough to interfere with BLE communications.  YMMV :)