I have a Nano 33 IoT on the way and I am in the process of educating myself on the IoT end of things.
I can not find any best practices in regards to securing the bluetooth device with a pairing passkey.
Am I just blind?
How are you doing it now?
First I clearly stated I was new to the IoT technology on the Arduino platform. There is no "doing it now" until I get the product physically in my hands.
U-BLOX has provisions for authentication built into the processor. The default is set to no authentication.
The only reference I have seen in any regards to Securing Bluetooth was "Why? It takes too much to build Bluetooth security for development boards." If I understand the U-Blox documentation this "feature" is already built in and is just a matter of configuring. With no experience on the IOT end of things I was hoping a veteran had figured out how to configure the code.
IMO as a web app developer I believe best practices should be observed even in cases of a testing development platform. How do you take a project from development to production quickly if you don't have a cornerstone like "security" implemented?
Ahem. One does not necessarily follow from the other. We see lots of posts from people who are new to a technology, and do have devices and are playing with them.
To address your other point, development often proceeds in overlapping stages, where the first stage is exploratory and may legitimately omit the checks and balances that are required to steer further development.
Otherwise, a detailed and fully featured plan may fail because something really basic was overlooked at the start.
Thank you for the link to the documentation, you may find some "veterans" here, but often it is a combination of generalist advice that solves a problem on this forum.
I also believe in best practices, and do my best to follow them. But as embedded devices come with a lot of "gotchas", it's often not productive to try to solve all the problems before you even have a device in your hand.
Can you steer us to particular pages or sections in the document, or is that crystal clear obvious from, say, the index? Also, can you narrow your doubts to specific questions?
Arg Section 4 is the security section. Page 7 and 8 get into the various security configurations. Now not being familiar with the Nano IoT I don't know if one would send commands to the board, some how use ArduinoBLE, or if another library like nina has the functionality.
So to be more specific. I would like to know how to implement Level 4(EDITED) security where the board requires a key when it is paired.
Thanks, that is clearer. I don't know the answer but I can say, the configurations would be chosen when you configure the library with your code and upload it. Because generally, libraries don't provide post upload configuration options.
Another thing, often security is a problem on small architectures because the encryption that we take for granted on more powerful machines, is provided by a lot of CPU horsepower that isn't available on all platforms.
Thanks aarg. What I am seeing leads me to believe you send it through the serial monitor to change the security level and that you are prompted for a key to be stored somewhere on the U-BLOX chip.
To me this makes the most sense as it prevents an error in coding thus providing a possible unknown security breach.
Thanks again for your time
Well, yes, configuration with keys and such small data is common, for example wifi logins and so on. I do use those. One of my apps has a config menu for login rather than hard coding it which as you say, is a security risk as well as being inconvenient. Usually those would be stored in EEPROM.
Again, not to grind the axe too sharp, but it would be easier to work through that feature, when you can actually run it on your target.
Think I found what I was looking for. Now it is about figuring out how to do this on the arduino ... Page 57
Almost like sending commands to the old modems... A-gad ... I just dated myself
Again, not to grind the axe too sharp, but it would be easier to work through that feature, when you can actually run it on your target.
I try to research most everything I do before I start a project to gain as much big picture insight into the project. From experience when you see the whole picture from the get go it streamlines development by avoiding redundancies that are not needed. If a key is required and it is indeed onboard then security is looked after. And if this is easy it also gives encryption which could reduce the need for doing that again.
Okay, and what is your passkey implementation? Will that be provided by the user or stored semi-permanently on the device?
The passkey is stored on the U-BLOX chip (I think) then you will need that passkey to connect with another device. If you needed to connect another board you would used the push button method... Push a button and the board allows the next device to connect for 30 seconds.
Still trying to figure out the actual process but I think I am at a point where I will need the IoT Nano in my hands so I can try and pass the documented AT codes.
At the moment the ArduinoBLE library does not support pairing. Pairing is an optional feature in BLE and not required for most use cases with Arduinos. You can simply connect an app (e.g., BLE Scanner or many others) to the Arduino when it is running a BLE peripheral sketch. Likewise for two Arduinos; a BLE central can connect to a BLE peripheral device.
The document you posted has list of applicable devices on page two. The NINA-W10 (W101 or W102) used on the Arduino Nano 33 IoT is not in that list.
I believe there were some requests regarding pairing on the ArduinoBLE GitHub page. You can have a look and see whether there are any indications for future inclusion of this feature.
You can still add some application-level authentication that requires a central to set some characteristics before getting access to data you do not want to have publicly available. Peripheral devices can disconnect a central at any time they chose.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.