Cloud IoT Device uniqueness / device state logging

16 views
Skip to first unread message

Bruce Sandler

unread,
Nov 28, 2018, 12:12:46 PM11/28/18
to Google Cloud Pub/Sub Discussions
Hi there,

I have recently been looking into Google Cloud IoT with MQTT as a solution for updating state of IoT devices and logging state changes in Stackdriver.

1. It is currently possible for multiple devices to use the same private key and device id when communicating with IoT Core over MQTT.
Is there a way to ensure that only a single device subscribes and receives configuration changes for a given device id?

2. Device state topic messages are not automatically logged in Stackdriver.
I was thinking of writing a cloud function for that. 
State topic messages include additional attributes such as projectId and deviceId which are helpful, but they don't include device metadata which I would like to include as labels in the log message.
There seems to be a way to do that, by resolving several attributes from the message (location, registry, device, project), using API discovery to get the IoT Core client then invoking the getDevice API to retrieve its metadata. Is there a simpler way to log state messages with IoT device metadata in Stackdriver?

Thanks,
Bruce

Jinjun (Cloud Platform Support)

unread,
Nov 28, 2018, 9:12:28 PM11/28/18
to Google Cloud Pub/Sub Discussions
Hello,

First of all, sharing device key and id among multiple devices is not recommended. Please study this documentation for device security recommendations [1]. With shared device id, there is no way to send configuration changes to only a given device. Because in MQTT protocol, the topic for configuration updates is in /devices/{device-id}/config format [2], device-id is the only identification on each different device.

Device state and device metadata are different things. Device state topic certainly won't have device metadata posted. It looks like cloudiot API or cloudiotdevice API is the right approach to get device metadata, but I am not sure which API. Can you elaborate on which getDevice API you are considering?


Bruce Sandler

unread,
Nov 29, 2018, 8:52:07 AM11/29/18
to Google Cloud Pub/Sub Discussions
Hi Jinjun,

Thank you for your reply. 
It looks like my questions were misunderstood. I apologize for this. Let me rephrase:
I do not intend to share device id among multiple devices, the opposite - my intent is to actively detect and prevent this from happening accidentally or maliciously.
The private key is not meant to be shared, but it is possible that it is accidentally used in 2 different devices during their setup or stolen by a 3rd party.

It seems like there should be a device registration process whereby during the initial connection, the device receives a unique id from Cloud IoT and uses it to identify itself during all communications, possibly by embedding it in the JWT token. Other devices would not be able to register and receive unique ids. 

Regarding device metadata, device state topic already has some metadata posted as message attributes: projectId, location, registryId, deviceId, deviceNum and subfolder. (It is mentioned here and I have verified that it's included for not only telemetry messages but also state messages: https://cloud.google.com/iot/docs/how-tos/mqtt-bridge)
To retrieve custom metadata, I use googleapiclient.discovery to retrieve the client for the cloudiot API, then client.projects().locations().registries().devices() to get the device by name, then I retrieve metadata with device.get('metadata').
This is done per state message. Ideally, there should be a way to embed device metadata as PubSub message attributes.

Jinjun (Cloud Platform Support)

unread,
Nov 29, 2018, 10:12:32 PM11/29/18
to Google Cloud Pub/Sub Discussions
Hello Bruce,

Thanks for the clarification on both issues.

It seems correct that if you share the private key with multiple devices, if the key is compromised, all the devices with this key will be compromised. That's why we don't recommend doing that. If the private key is stolen by 3rd party, unless they also steal the full resource path, they won't be able to reach the public key stored in the device manager on the platform to get themselves authenticated. That would be less an issue.

About to embed device metadata into the device state Pub/Sub topic, you can access our Public Issue Tracker [1] to request this feature to be able to neatly get the metadata.

Hope these answered all your concerns.


Reply all
Reply to author
Forward
0 new messages