General questions about BLE (address and Security)

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
DeTo_1826166
Level 3
Level 3
First like received First like given

Hello everyone,

   

We want to use Bluetooth for configuring and parameters a motorized door (with a phone APP)

   

It's for small quantities then a module like the CYBLE-012011-00 could fit perfectly well.

   

I have some questions about different features in BLE :

   

1) Addresses :

   

1.a)

   

For the Company-ID part :
Does we have to purchase a 24 bit Organization Unique Identifier (OUI) ?
Can we purchase IEEE address chips for this use ?
For the company assigned part : how to be sure of the uniqueness of  the silicon-generated company-assigned part?

   

1.b)  Does we have to use the public address ? From specifications i see that we could use random static address instead.
Here a topic about it : http://www.cypress.com/forum/proc-ble/want-use-random-static-ble-address
My idea was to generate a random static address at the device first use. This address could be the same during the lifetime or reset (an other address is randomly generated) when the user press a button. Is it ok to do it like that ? It's absulutely not native in the API so maybe I'am just totally wrong...
No sure if a static address is ok with specifications because it say that static address should be generate after each power cycle..

   

2)Security
The Bluetooth could provide the possibility to the user to command his door with a phone App :

   

Security during pairing seems not that great in 4.1. Is it sufficient to add nonce and reponse-challenge schemes in the application part ?
With 4.2 security during pairing seems a lots of better, but how to be sure that it is sufficient ? (and the drawback is that module cost the double comparing to 4.1 module)
Actually many door locks using Bluetooth seems to have lack of security.

   

If we cannot reach an acceptable level of security we could just keep the configuration part and expire the session after configuration (pairing is only possible with physical access). But i would like to know if we could reach a great level of security with what Bluetooth 4.1 or 4.2 provide to us and with just few security addons in the application layer or without it.

   

 

   

Thanks for your answers

0 Likes
1 Solution
Anonymous
Not applicable

1.a) I believe you need to buy the OUI, or at least have the addresses you use be registered with BLE SIG, or something along those lines.

   

The silicon-generated numbers are based on die, wafer, and location, and thus should always be unique, since those are written by cypress themselves.

   

1.b) Not sure about this, but I would think what you are suggesting is ok.

   

2. Theoretically, the most secure method is using: whitelisting, encryption+authentication (4.2 stack I believe), and some sort of private/public key pair for verifying the user's identity after first configuration of the door. The hardest part with embedded security is getting enough space/processing power to run security, and getting enough randomness/entropy in order to create truly random numbers (or at least a large enough PRNG to prevent prediction/calculation).

   

If you can encrypt the communication between the devices, and you know potential attackers can't brute-force your response replies to the device, then challenge and response method should be okay. A large part of it will be your implementation of the security, but ultimately; If you can fit it onto the chip's code space, and you have enough random-ness of generated numbers, then you should be able to make it secure.

View solution in original post

0 Likes
2 Replies
Anonymous
Not applicable

1.a) I believe you need to buy the OUI, or at least have the addresses you use be registered with BLE SIG, or something along those lines.

   

The silicon-generated numbers are based on die, wafer, and location, and thus should always be unique, since those are written by cypress themselves.

   

1.b) Not sure about this, but I would think what you are suggesting is ok.

   

2. Theoretically, the most secure method is using: whitelisting, encryption+authentication (4.2 stack I believe), and some sort of private/public key pair for verifying the user's identity after first configuration of the door. The hardest part with embedded security is getting enough space/processing power to run security, and getting enough randomness/entropy in order to create truly random numbers (or at least a large enough PRNG to prevent prediction/calculation).

   

If you can encrypt the communication between the devices, and you know potential attackers can't brute-force your response replies to the device, then challenge and response method should be okay. A large part of it will be your implementation of the security, but ultimately; If you can fit it onto the chip's code space, and you have enough random-ness of generated numbers, then you should be able to make it secure.

0 Likes

Tnaks for the answers !

0 Likes