In a recent email exchange with @Bryce, we became aware of what we believe may be an issue as we begin to launch our product. So, we are asking for some clarification.
Given that one could take any photon and flash any PRODUCT_ID() and PRODUCT_VERSION() to to that device…
And suppose some all-of-a-sudden not-so-nice bad person decides to flash firmware with someone else’s Product/Firmware pair (I randomly pick a number less than the last product I created).
And suppose that device does nothing but publishes at the max rate limit for Products.
Further suppose that the developers wish for and they chose to automatically move claimed Products into their Product “namespace” for lack of a better term. They made that choice because they are working with the kind of customer who 1) claims on their own and 2) performs this real-time on setup and 3) on their own schedule, independent of our knowledge.
Then, given the above, wouldn’t it be possible to then spoof the product and sit and run up the developers costs by continually publishing?
So, is this breach possible? Is our concern unfounded? If our concerns are valid, could we have some ideas on protecting ourselves from this, given that we need to automatically move our devices into our product namespace?
A simple FIRMWARE_KEY() that could be passed during handshaking seemed like a reasonable method.
thanks for reading this and sorry if we missed something that addresses this issue.
Jeff here, a product manger at Particle. Thank you very much for expressing your concern. Hopefully I can share some knowledge that will help reduce your anxiety about product device security.
First, I would recommend you check out the Product Security Guide if you haven’t yet read it. It covers in depth a lot of the issues you raised in your question.
As you are aware, there are 2 representations of a device’s product association: one in the cloud, and one compiled into firmware (the PRODUCT_ID macro). As you astutely pointed out, it is possible for someone to accidentally or maliciously compile your product ID into firmware and run it on a Particle device. When this happens, a mismatch occurs: the product the device claims it is is different than what the cloud has on file for that device (because presumably, that device hans’t been imported into your product).
When this occurs, by default, the device is placed into a “Quarantined” state. When this happens, the device will temporarily lose all product privileges. In your product’s devices hub on the Particle Console, you will see a list of your quarantined devices and have the option to approve/deny these unrecognized devices. The purpose of quarantine is to avoid the scenarios you mentioned --> having these devices act as members of your product when they shouldn’t.
I will mention that you do have the option of changing this setting to “Auto approve,” which will automatically import unrecognized devices into your product under certain conditions. This is a less secure option, but may be necessary if you don’t have access to the list of Device IDs that you are expecting to come online and self-identify as your product.
If at all possible, I would recommend keeping your product set to “Quarantine” unrecognized devices, and import all device IDs that should act as your product as early as possible. To your comment, device setup can happen independently of importing into your product. If you have more questions about how this works, I would be happy to clarify clarify.
So, how you explained it and how we interpreted/understood the documentation is 100% in alignment, so thanks for the response.
Since we will be a “Factory Flash” type of product, we were not really wanting to keep a DB of all of the devices we flash. Our factory will have to record every device ID and then we will have add the step to verify against that list on signup. I am sure that won’t work well… it never does. We see it as extra cost and an opportunity to make an error and create (frankly) more cost in servicing a call.
We think this problem could be solved with a simple FIRMWARE_KEY() macro that would allow us to present devices authenticated against a secret key. Another option would be for Particle to somehow encrypt the PRODUCT_ID(), rather than just a simple progressive integer We’d like some consideration of these ideas as a possible intermediate-term solution.
Our current attempt to work around this issue is to verify that a user account was successfully created. We attach the device ID (we have moved off the ProductID ) to the URL query string when the user gets directed to our website and creates his/her account. We intend to first verify Account Creation. We will need to then sweep THAT new device out of Quarantine and into approved devices. I suppose we can trigger that real-time and error at that time in the case where we don’t recognize the DeviceID. We will play with that and I can update you on this once we test it all out.
Are there any ideas out there in Particle land on another “workaround” in consideration of our (again) desire 1)not to authenticate a device through a list on a database and 2) automatically process devices imported into our product 3) sleep through the night.
I’m curious how you are purchasing your devices. At scale, we recommend using our wholesale store. When you purchase in bulk from the wholesale store, our ops team (cc @margaret) will send you a file containing all of the device IDs you ordered as part of the fulfillment process.
In that way, you wouldn’t need to record each device ID on the line, you’d already have it and simply upload it to the Console.
We've deduced that there probably isn't a JS wrapper for that function, but we've been through the docs as thoroughly as possible and cannot find Particle's method to perform this task.
Could someone point us to where we need to go? This is sort-of our last "obstacle"....
Device owner’s Access Token allowed us to approve and move out of quarantine so …
We are still concerned re: thread topic using this approach.
I’d like to take the conversation offline but we need to put this off for a few days. We may be able to think this through better after we consume Friday beers. Today is still Thursday here.
bad person decides to flash firmware with someone else’s Product/Firmware pair (I randomly pick a number less than the last product I created).
) to the URL query string when the user gets directed to our website and creates his/her account. We intend to first verify Account Creation. We will need to then sweep THAT new device out of Quarantine and into approved devices. I suppose we can trigger that real-time and error at that time in the case where we don’t recognize the DeviceID. We will play with that and I can update you on this once we test it all out.
