2

This is the scenario: I have a machine connected to a MQTT AWS-IoT Core broker. This machine is authorized with the AWS certificates to publish in the topic P/serialnb/deleterecords/record_id. This topic will delete a record in the database. In a web-http architecture the user should be authorized to this transaction since it is logged with login/password and the browser/server exchange sessions between them.

Now lets say that the machine was hijacked and a hacker got access to the certificates and to the topic. So, the hacker has access to the machine serial number and the topic that delete the files in the database.

How could I mitigate this problem since the connection between machine broker has not this layer of security - only authorized users to publish in this topic?

Improve this question

2 Answers 2

Reset to default
0

You revoke the certificate if it's compromised.

This why EVERY device needs it's own certificate and where possible you should make sure the private key for that certificate is stored in a Secure Element so it can not be accessed/copied from the device.

Improve this answer
7
  • what do you mean by "Secure Element"?
    – IgorAlves
    Apr 2, 2021 at 20:58
  • revoke the certificate is a good option, after we know it was compromised. But do y have another idea before this time?
    – IgorAlves
    Apr 2, 2021 at 21:02
  • If you don't know that's been compromised you don't have any idea about having to disable the user credentials. Revoking the certificate is the solution here.
    – hardillb
    Apr 2, 2021 at 21:35
  • 1
    A secure element is a hardware token that holds private keys and carries out cryptographic operations with those keys on input without allowing access to the keys. They are used to allow devices to use the keys without making them extractable.
    – hardillb
    Apr 2, 2021 at 21:43
  • Do you mean physical protection?
    – IgorAlves
    Apr 2, 2021 at 23:36
0

While revoking the certificate will work after you know that this device is compromised, I think you're ignoring another, more important threat. If I'm a hacker and get a hold of one of your devices, I should not be able to affect the data that's coming from the other devices. Otherwise, I could silently send in some wrong data occasionally, using topics corresponding to other devices. Eg: Knowing that serial numbers are sequential, I could guess other serial numbers. Making a stored device certificate hard to get on the device using a secure element maybe too expensive depending on the type of device and the kind of data you get. Instead (or additionally), you should prevent devices from accessing topics they are not supposed to access.
The key to the problem is in two possibilities (and yes, it starts with each device having its unique certificate first):

  1. In the AWS IoT rules, use the principal() function as the key serial number to the device rather than sequential serial number. You can translate to the sequential serial number using a dynamodb and the get_dynamodb(...) function if you want, by looking up your table that you populate when you make the devices. The principal() function gives the certificate thumbprint and that is not easy to guess for the other devices.
  2. Alternatively, you can include the sequential serial number in the certificate and then have a policy on your IoT endpoint so that the serial number part of the topic has to match the serial number put into the certificate.
  3. Yes, I said 2 above. I dont recommend this one. But if you want, you can just have a random long string be the serial number for devices. This way, atleast the hacker cant guess the other machine serial numbers. But be sure to have a different certificate for each device anyway, otherwise, you cant revoke and will still get charged IoT message charges for the hacker's possibly unsuccessful attempts !
Improve this answer
4
  • 1
    And in case you were thinking of how to prevent deletions of records of the compromised machine, perhaps you should just mark as deleted and not actually delete the record. That way, you can recover if you know it is hacked. If you also want to protect against modifications, you will basically have to have versioned data. If you use S3 as your store, you can get this out of the box. Some databases have it too. MongoDB as an example. Perhaps some AWS provided databases provide it too.
    – kalyanswaroop
    Apr 2, 2021 at 23:26
  • Related to the rules, yes I have control on that. The machines are not allowed to publish or subscribe to topics that are not related to its processes. But I didn't get your idea of principal(). At the end of the day the principal() is just another string and I would need to query the dynamo in each transaction to get this string. Are you suggesting query dynamo through HTTPs and then Publish?
    – IgorAlves
    Apr 2, 2021 at 23:34
  • The solution with database design is a solution. But I my question is related to the user itself. Do y think a solution like username/password/session something possible in MQTT architecture? I want to explore a solution in the Authorization side (IF POSSIBLE) before go with this solution of data protection avoiding delete.
    – IgorAlves
    Apr 2, 2021 at 23:40
  • I'm saying that in your select statement for the IoT Rule, use the principal function. docs.aws.amazon.com/iot/latest/developerguide/… Using that function allows you to get a non-spoofable client identification string. i.e, if I hack one device, I cannot then spoof another, since I dont have its certificate. The policies are another way to ensure that can enforce that devices cannot spoof. Perhaps you are also considering thing groups and allowing some topics on them ?
    – kalyanswaroop
    Apr 3, 2021 at 4:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.