editor's blog
Subscribe Now

ProbMe Simplifies Thing WiFi Connection

Sometime back, we took a look at Econais’s WiFi modules. We mentioned their ProbMe capability, which simplifies connecting these devices to the WiFi network.

This function has apparently gotten some traction, and they’ve made some improvements that they announced in early August. So I wanted to dig in a bit more to understand specifically how this thing works – and get clarification on what seemed (and possibly still seem) like possible complications.

First, why do this at all? This is intended for WiFi modules that will attach to all manner of Things. Most of these Things will not have displays or keyboards, so they are harder to connect to the network than your average phone or computer. How to enter the password, for example?

There is the WPS button; would that work? This is the setup mode newer routers have where, instead of choosing an SSID and entering a passphrase, the Thing listens, and you go push a button on the router; the router and the Thing do a handshake and connect up. But this assumes you have access to the router. It also assumes you have easy access to the Thing – if the Thing is a light in a warehouse with a 20-ft-high ceiling, that’s not so easy. There are also apparent security holes in this scheme (per Econais).

That’s why Econais did this ProbMe thing.  I’ll describe first how it works from a user’s standpoint, then what’s happening inside, and then address some questions.

The way ProbMe works is that, when you first power up an unconnected Thing, it enters a “listening” mode, awaiting connection instructions. The user finds a passphrase in the Thing packaging somewhere and then opens an app on their phone or computer. That app will ask for the passphrase, and then the configuration takes place automatically.

This passphrase isn’t really a security thing; after all, if it’s readily available in the documentation, then it’s not really a secret. This is rather a way to identify which Thing is being configured. And it’s expected that manufacturers may use the same passphrase for many Things (either copies of the same Thing or even groups of different Things that work together, like the components in a home entertainment system).

Because of this, you can configure multiple Things in one fell swoop. If you’re configuring all the new lights in the warehouse, for instance, you turn them all on, do the configuration, and it can work on all of them at the same time. Note, however, that this isn’t a specific thing about ProbMe – the Thing manufacturer has control over this based on how they assign the passphrases.

So what’s happening under the hood to make this happen? The app is using WiFi’s discovery mode to broadcast to all Things. In the configuration field, it has a long string containing the Thing passphrase, the SSID, and the network password; the ProbMe software in the WiFi module of the Thing parses those items, recognizes its own ProbMe passphrase at the start of the string, and then uses the information to connect to the network on its own (or ignores it if it was some other Thing’s passphrase).

probme_screenshot_200.jpg

Image courtesy Econais

How does the app know the network password? If the phone or computer has ever connected to that network before and saved the configuration, then it has that stored away. Which suggests that, if you use, say, your personal phone in the warehouse, and you’ve never connected to the warehouse network with that phone, it seems like it wouldn’t work. You’d need to connect your phone to the network first so that it would know the password.

Some obvious questions arise from this scenario regarding security. And it’s not just a “bad guy” thing; it’s also a consideration of timing.

  1. Once you power on your Things, what’s to stop someone else from configuring them before you get to it? After all, if they bought one of the same things – say, a coffeepot – then they’d know the passphrase (since the manufacturer would probably make them all have the same passphrase rather than going through the logistics hassle of personalizing each coffeepot).

    This is theoretically possible, but it’s expected that the Thing manufacturer would build in a window of time within which configuration had to happen. If it didn’t, then you’d need to power down and back up again to configure it. The chances of someone malevolent just waiting while you power on your new coffeepot is considered remote. But it is something to consider.

  2. Once you’ve configured your Thing onto your network, what’s to stop someone else from reconfiguring it?

    Once configured, the Thing is no longer able to be reconfigured without some manual intervention, like pressing a physical “Reset” button. It’s nothing that can be done wirelessly.

  3. Let’s say a new office building is being opened, and it’s move-in day. It’s modern, with lights having WiFi connections. You want to connect your lights up to your network (and not the network in the neighboring office). Folks arrive at 8AM that first day and turn on the lights. From that time, there is a window within which the lights need to be connected (or else you need to power down and up again). Let’s say it’s a 10-minute window. Let’s say the lights in the two offices get turned on within 5 minutes of each other. There is now a 5-minute overlap in the configuration windows. All the lights have the same passphrase; if one of the offices enters a passphrase within that 5-minute overlap, then all of the lights in both offices will be configured at the same time. And once that happens, you can’t reconfigure without physically resetting each light.

    The answer here isn’t one of technology; this scenario could happen. But, from a practical standpoint, they believe that IT folks for the building itself would handle this, not the tenants in the offices. Since one IT person would be doing it, he or she would be in control of which lights are configured at which times, eliminating any race conditions.

  4. What about the same scenario, only with coffeepots? Unlikely the IT guy is going to configure that.

    This is also plausible, although it’s much less likely that two people in adjacent offices would just happen to purchase the same coffeepot and power them up within a few minutes of each other. It’s also easier to reset a coffeepot than a light (although there’s no guarantee that there might not be Things where this scenario is more feasible and where the Things are less accessible). It remains a consideration.

You can read more about ProbMe in Econais’s announcement.

Leave a Reply

featured blogs
Oct 23, 2020
Processing a component onto a PCB used to be fairly straightforward. Through-hole products, or a single or double row surface mount with a larger centerline rarely offer unique challenges obtaining a proper solder joint. However, as electronics continue to get smaller and con...
Oct 23, 2020
[From the last episode: We noted that some inventions, like in-memory compute, aren'€™t intuitive, being driven instead by the math.] We have one more addition to add to our in-memory compute system. Remember that, when we use a regular memory, what goes in is an address '...
Oct 23, 2020
Any suggestions for a 4x4 keypad in which the keys aren'€™t wobbly and you don'€™t have to strike a key dead center for it to make contact?...
Oct 23, 2020
At 11:10am Korean time this morning, Cadence's Elias Fallon delivered one of the keynotes at ISOCC (International System On Chip Conference). It was titled EDA and Machine Learning: The Next Leap... [[ Click on the title to access the full blog on the Cadence Community ...

featured video

Demo: Inuitive NU4000 SoC with ARC EV Processor Running SLAM and CNN

Sponsored by Synopsys

Autonomous vehicles, robotics, augmented and virtual reality all require simultaneous localization and mapping (SLAM) to build a map of the surroundings. Combining SLAM with a neural network engine adds intelligence, allowing the system to identify objects and make decisions. In this demo, Synopsys ARC EV processor’s vision engine (VPU) accelerates KudanSLAM algorithms by up to 40% while running object detection on its CNN engine.

Click here for more information about DesignWare ARC EV Processors for Embedded Vision

featured paper

An engineer’s guide to autonomous and collaborative industrial robots

Sponsored by Texas Instruments

As robots are becoming more commonplace in factories, it is important that they become more intelligent, autonomous, safer and efficient. All of this is enabled with precise motor control, advanced sensing technologies and processing at the edge, all with robust real-time communication. In our e-book, an engineer’s guide to industrial robots, we take an in-depth look at the key technologies used in various robotic applications.

Click here to download the e-book

Featured Chalk Talk

Microchip SAM11L KPH

Sponsored by Mouser Electronics and Microchip

Adding connectivity to your embedded design opens up a whole new realm of security challenges. Inviting your device to the IoT requires careful attention to building a secure foundation. In this episode of Chalk Talk, Amelia Dalton chats with Anand Rangarajan from Microchip about the SAML11-KPH MCU and how it can help you develop your application without worrying about security.

Click here for more information about Microchip Technology SAM L10/L11 ARM® Cortex®-M23 MCUs