PRODUCT_ID() Security Concerns

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 :blush: 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.

Hmm, I’m not sure but I was under the impression that a device which device ID isn’t listed in the product creators account would be quarantined.

unless the product creator decides/wants them to move automatically, is my point.

That shouldn’t come with security concern…

Hey @BulldogLowell,

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.

Hope this is helpful,

Jeff

2 Likes

Hey Jeiden,

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 :wink: ) 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.

Thanks for your valuable assistance!

Hey @BulldogLowell,

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.

2 Likes

OK, I see. We have been using a mixed bag of devices we bought off of your website or Amazon.

We will buy from the wholesale store when we do our PPL.

Thanks for that, very helpful!

2 Likes

@jeiden,

Thanks again for your assistance so far. We have searched the various API docs for a method for us to move product out of quarantine. We are using the JavaScript SDK. We checked your github repository here and your JS SDK docs here, as well as the (extremely helpful :)) areas regarding Authentication and Client On-Boarding as well.

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”…

Thanks!

Hey @BulldogLowell,

Happy to help. While there is not yet support in our JS SDK, the API endpoints to approve/deny devices from quarantine are documented here: https://docs.particle.io/reference/api/#quarantine.

Hope this helps,

Jeff

perfect!

I promise you I searched… The docs are a bit divergent, I’m more of a linear thinker. :expressionless:

Onward and Upward!!!

many thanks!!!

1 Like

@jeiden,

One last favor, if you would:

the docs call for a POST to this endpoint:

POST /v1/products/:productIdOrSlug/devices 

can you show me a prototype curl?

e.g.

curl https://api.particle.io/v1/products/<MY_PRODUCT_NUMBER>/devices -d id=<DEVICE_ID> -d access_token=<ACCESS_TOKEN>

i think it is right but I’m getting:

{"ok":false,"error":"Organization not found for user's role."}

thanks…

Hmm are you using a valid access token of a member of your product team?

yeah, but to be sure, I wanted to check we were passing everything we needed for the endpoint

Device owner’s Access Token allowed us to approve and move out of quarantine so … :ballot_box_with_check:

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.

great help, thanks!

1 Like