I am testing the Embedded API using the TCP socket interface. It appears that the only thing securing the connection is the 8byte Device Key. I was hoping that only a message from the device with that SIM card and Device Key would be able to pass traffic. It appears that it doesn’t matter where the traffic originates from, as long as the Device Key is valid it accepts and processes the data. This would allow the device to very easily be spoofed if they have the 8byte key.
Is my assessment of the Embedded API correct or have I missed something? If that is the case what do others use to harden or secure their device to cloud communications when the device doesn’t have higher-end encryption capabilities? Or at least have some assurance that the traffic originated with the device?
I will have to verify this since it has been a long time since this has been touched by myself but I believe it matches the device key with the iccid/imsi of the device. I will look into it
After reviewing it that does appear to be correct that the device key is the only thing needed to authenticate as that device. We do have other authentication mechanisms that the SDK uses but for the embedded api that would be all that is required to send a message as a device.
That being said you won’t be charged for messages that don’t originate on the device as we charge for usage we get from the carrier and something spoofing the device would not incur usage. You can also regenerate keys though doing that and changing the key on the device might not be possible for many use cases. You can also entirely forgo our cloud services and just send things to other services using whatever authentication scheme they allow for.