⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.wsdof.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
12 posts / 0 new
Last post
Tue, 2019-08-20 15:49
#1
point85
Offline
Last seen:11 months 3 weeks ago
加入:2018-06-29 15:31
Securing SUOTA

Hi,

使用提供的示例DS允许任何用户to approach our device and upload new user firmware. Is there an easy way to secure against this? A way to enable or disable the service? Or maybe only allow it under certain conditions?

Thanks in advance.

Device:
DA1468x
Tue, 2019-08-20 16:28
MHv_Dialog
Offline
Last seen:2 months 2 weeks ago
Staff
加入:2013-12-06 15:10
Hi point85,

Hi point85,

My assumption is that you are using a smartphone, a tablet or a PC to serve the firmware upload. I will refer to this as the master and the device featuring the DA1468x as the slave.

I would recommend that you implement some authentication scheme, and I will describe one in the following:

  1. On the slave device side, the SUOTA service is disabled as default. A command sent to the device will trigger the next step in a sequence. The master should have a way of comparing the current firmware on the device with the most recent to see if an update is available. The user should probably be prompted before and upgrade takes place.
  2. The slave device should then place a random challenge (a random set of bytes) in a characteristic that the master must read and resolve using a shared key before it returns the result to the client. You can use AES128 encryption with a size of the random challenge and shared key being 16bytes.
  3. The slave device will enable the SUOTA service only after it has received a valid response to the challenge.

The simpler alternative is to require that some shared key is sent to the slave device in order to enable the SUOTA service. If the master and slave devices are BT bonded, then this approach is almost as safe as the more complicated one described above.

I hope this gives you some inspiration.

/MHv

Tue, 2019-08-20 17:00
point85
Offline
Last seen:11 months 3 weeks ago
加入:2018-06-29 15:31
Awesome response. Thanks.

Awesome response. Thanks.

So essentially it is possible to enable and disable the SUOTA service. I don't suppose you have an example of how to do this?

Tue, 2019-08-20 17:03
(Reply to #3)
MHv_Dialog
Offline
Last seen:2 months 2 weeks ago
Staff
加入:2013-12-06 15:10
Hi point85,

Hi point85,

I don't have an example available, but I have a crack team of supporters behind me willing to provide something like that. Stay tuned for a day or two...

/MHv

Tue, 2019-08-20 17:06
point85
Offline
Last seen:11 months 3 weeks ago
加入:2018-06-29 15:31
Wow, that would be super. We

Wow, that would be super. We have the SUOTA working well on our prototypes in our custom firmware. Just need to get it secured!

I await your response! Thanks.

Wed, 2019-08-21 17:46
(Reply to #5)
MHv_Dialog
Offline
Last seen:2 months 2 weeks ago
Staff
加入:2013-12-06 15:10
Hi Again,

Hi Again,

The team asks that you please take a look at our secure booting app note. It addresses how you can sign your firmware to prevent 3rd party from linjecting malicious firmware via SUOTA.

/MHv

星期四,2019-08-29十一33
(Reply to #6)
point85
Offline
Last seen:11 months 3 weeks ago
加入:2018-06-29 15:31
Thanks.

Thanks.

I was told previously this cannot be done on the DA14680?

Do you have link to the application note?

Thanks.

Thu, 2019-08-29 16:38
PM_Dialog
Offline
Last seen:3 days 16 hours ago
Staff
加入:2018-02-08 11:03
Hi point85,

Hi point85,

Could you take a look at theDA14682/DA14683 Secure Boot Tutorialfrom our support website?

Thanks, PM_Dialog

星期四,2019-08-29十六48
point85
Offline
Last seen:11 months 3 weeks ago
加入:2018-06-29 15:31
This is not for DA14680

This is not for DA14680 though?

Fri, 2019-08-30 17:24
PM_Dialog
Offline
Last seen:3 days 16 hours ago
Staff
加入:2018-02-08 11:03
Hi point85,

Hi point85,

My apologies, but I’ve just read that you are using the DA14680. The secure boot feature is supported only in DA14682/3. This feature is not supported in DA14680/1 product. The DA14682/3 has a special OTP for secure boot functionality, because it should be written only by the CPU. The secure boot is an additional functionality that is supported only by DA14682/3 products. Since you are using the DA14680, the secure boot functionality is impossible to be achieved. Keep in mind that for new designs I would strongly recommend you to move onto DA14682/3 products.

Thanks, PM_Dialog

Mon, 2019-09-02 09:36
point85
Offline
Last seen:11 months 3 weeks ago
加入:2018-06-29 15:31
Is the DA14682 a drop in

Is the DA14682 a drop in replacment for the DA14680?

From the datasheet, memory + pinouts etc. all look the same. Is there anything we should be aware of?

Thanks.

Mon, 2019-09-02 16:36
PM_Dialog
Offline
Last seen:3 days 16 hours ago
Staff
加入:2018-02-08 11:03
Hi point85,

Hi point85,

Please check DA14680/1 and DA1682/3 datasheets respectively, and you will see that Secure Boot is supported only in DA14682/3 products (Section 3.6.2 Secure Boot), as they have dedicated OTP for this kind of functionality. Regarding the replacement, let me ask the Team internally if it is possible.

Thanks, PM_Dialog