Does adding a randomized string in S3 file path has equal security to Google Drive shared link

Question

I would like to use an AWS S3 bucket to store my IoT firmware file and allows all of my IoT devices to access it to update the firmware to the latest version.

I want that the firmware file in the S3 bucket is secret to only me and my devices. But I don't want to embed any credentials inside the devices. And I cannot use a pre-signed URL as it has a limited expiration time and I want to avoid creating another API or Lambda to generate the pre-signed URL.

I am thinking it would be great if I can generate something like Google Drive's shared link (in the picture below) in S3.

Then I realize that I could just put a randomized string in my S3 path and make only that file publicly accessible. For example.

my-bucket/firmware-v1.bin <-- private
my-bucket/firmware-v2.bin <-- private
my-bucket/QMeOvULdBEI0qGf0KFOl/latest.bin <-- public permanently

Then I will let all my devices remember the link https://<aws-s3-domain>/my-bucket/QMeOvULdBEI0qGf0KFOl/latest.bin to check for update.

I would like to know how secure is this method compared to Google Drive's shared link.

Answer 1

Is it as secure as a Google Drive shared link? Yes, that is to say, not at all.

A shared link from Google Drive is not meant to provide security. It is meant to prevent brute-force attacks from randomly guessing the link. Your idea would provide the same functionality as well - but the problem is, your threat model does not consist of other internet users who know nothing about your link. When you say:

I want that the firmware file in the S3 bucket is secret to only me and my devices.

I am assuming that to mean you want to keep the link secret from the users (consumers) of your devices. This is futile, because the end user has any number of ways of getting ahold of the link, or the file itself after it has been downloaded to the device.

As long as the bucket is exposed on the internet, there is no way to validate that a request is coming from one of your devices and not from a user who has investigated the device to identify whatever criteria you are using.

That said, while nothing will achieve the exact goal you're asking for, there are some steps you might be able to take:

• If you know where these devices are going to be deployed (such as if they're purpose-built for a site, or if your target market is only in the US) you can geo-restrict requests to the bucket. This will prevent spurious requests from geolocations you know will not need to be supported.
• You can rate-limit incoming requests. If a user is sniffing traffic externally from the device, without breaking into its internals, they will only be able to see the SNI field of your requests (e.g., s3.region.amazonaws.com). This would prevent brute-forcing based solely on the SNI. This will, of course, not work if they are running a TLS MITM on their network.