General Question: Device specific value store

General Question: Device specific value store

[Matthias Schoepfer]

Hi!

I have a general, maybe dumb question. Is there a smart, recommended way 
to deal with device specific data (i.e. serial number, credentials for 
backend access, you name it), that is specific for *one* device, and 
hence does not belong into the rootfs. I know, that there are (safe) 
hardware stores for it, but what, if your device does not have one. The 
current approach is to use an additional file system. Is there a good 
way to create huge numbers of such filesystems that just hold different 
values generated of a cvs file or such. What would be the yocto way 
without crafting scripts over scripts?!

Thanks and Regards,

    Matthias

Re: General Question: Device specific value store

[Morné Lamprecht]

On Mon, Jun 17, 2019 at 05:25:56PM +0200, Matthias Schoepfer wrote:
>Is there a smart, recommended way to deal with device specific data (i.e.  
>serial number, credentials for backend access, you name it), that is specific 
>for *one* device, and hence does not belong into the rootfs. I know, that there 
>are (safe) hardware stores for it, but what, if your device does not have one.

Not sure if I'm misunderstanding your question, but this should be part of your 
device commissioning process, i.e. like injecting specific security keys 
etc...so basically this will part of your image install / flash process, and not 
really part of the Yocto build process. The specifics of such a process would 
depend on your specific commissioning process.

		- Morné

Re: General Question: Device specific value store

[Matthias Schoepfer]

Hi Morné,

thanks for you answer. Maybe, I will explain more: we have a Dragonboard 
410c based hardware. We use a read-only rootfs in one partition 
(actually two with A/B approach) and we have a data partition for user 
data as well as device specific data. We can partition and flash the 
device through fastboot. So, if we can prepare ext4 filesystems (maybe 
through yocto instead of hand-crafted scripting) for each device, 
commissioning will be an easy task for the manufacturer.

I guess, we are not the only ones that need to store device specific 
information besides the rootfs, and I do not find a whole lot about it 
in the yocto manuals. I wonder, if there are best practices, how to 
protect the data from getting corrupted (intentionally by an attacker or 
by accident through ... flash corruption or whatever).

Regards,

    Matthias

On 6/24/19 9:08 AM, Morné Lamprecht wrote:
> On Mon, Jun 17, 2019 at 05:25:56PM +0200, Matthias Schoepfer wrote:
>> Is there a smart, recommended way to deal with device specific data 
>> (i.e.  serial number, credentials for backend access, you name it), 
>> that is specific for *one* device, and hence does not belong into the 
>> rootfs. I know, that there are (safe) hardware stores for it, but 
>> what, if your device does not have one.
>
> Not sure if I'm misunderstanding your question, but this should be 
> part of your device commissioning process, i.e. like injecting 
> specific security keys etc...so basically this will part of your image 
> install / flash process, and not really part of the Yocto build 
> process. The specifics of such a process would depend on your specific 
> commissioning process.
>
>         - Morné

Re: General Question: Device specific value store

[Gabriele Zampieri]

[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]

Hi Matthias,

an easier solution may be write those data during production. I don't think
that having a custom partition for each device is a good idea. You could
start the device in "production mode" and inject into the device specific
data through serial or USB. Obviously you must have some piece of software
running on the device that can read/write that partition.

In my opinion Yocto does not mention anything about this procedure probably
because this is not the standard way.

Gabriele

Il giorno mar 25 giu 2019 alle ore 10:53 Matthias Schoepfer <
matthias.schoepfer@googlemail.com> ha scritto:

> Hi Morné,
>
> thanks for you answer. Maybe, I will explain more: we have a Dragonboard
> 410c based hardware. We use a read-only rootfs in one partition
> (actually two with A/B approach) and we have a data partition for user
> data as well as device specific data. We can partition and flash the
> device through fastboot. So, if we can prepare ext4 filesystems (maybe
> through yocto instead of hand-crafted scripting) for each device,
> commissioning will be an easy task for the manufacturer.
>
> I guess, we are not the only ones that need to store device specific
> information besides the rootfs, and I do not find a whole lot about it
> in the yocto manuals. I wonder, if there are best practices, how to
> protect the data from getting corrupted (intentionally by an attacker or
> by accident through ... flash corruption or whatever).
>
> Regards,
>
>     Matthias
>
> On 6/24/19 9:08 AM, Morné Lamprecht wrote:
> > On Mon, Jun 17, 2019 at 05:25:56PM +0200, Matthias Schoepfer wrote:
> >> Is there a smart, recommended way to deal with device specific data
> >> (i.e.  serial number, credentials for backend access, you name it),
> >> that is specific for *one* device, and hence does not belong into the
> >> rootfs. I know, that there are (safe) hardware stores for it, but
> >> what, if your device does not have one.
> >
> > Not sure if I'm misunderstanding your question, but this should be
> > part of your device commissioning process, i.e. like injecting
> > specific security keys etc...so basically this will part of your image
> > install / flash process, and not really part of the Yocto build
> > process. The specifics of such a process would depend on your specific
> > commissioning process.
> >
> >         - Morné
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 3280 bytes --]

Re: General Question: Device specific value store

[Larry Brown]

[-- Attachment #1: Type: text/plain, Size: 3896 bytes --]

You could either partition the flash with intentional space left at the end
of the disk and write/read directly to the flash at the specified location
or you could put it at the end of the uboot space.  There is a chunk of
unused space at the end of the uboot image that is not used IIRC that
should give enough for a serial and key.  You'd have to test to find out
for sure.  You could cat the uboot image to hexdump to see how much space
is left empty.  The idea of a space at the end of the flash is probably
better as reformatting or re-partitioning with this space left alone should
retain your values.

If anyone has issues with these suggestions feel free to correct me but it
seems pretty safe to me since you have control over how you partition your
device and this data will be pretty static.


On Tue, Jun 25, 2019 at 6:09 AM Gabriele Zampieri <gabbla.malist@gmail.com>
wrote:

> Hi Matthias,
>
> an easier solution may be write those data during production. I don't
> think that having a custom partition for each device is a good idea. You
> could start the device in "production mode" and inject into the device
> specific data through serial or USB. Obviously you must have some piece of
> software running on the device that can read/write that partition.
>
> In my opinion Yocto does not mention anything about this procedure
> probably because this is not the standard way.
>
> Gabriele
>
> Il giorno mar 25 giu 2019 alle ore 10:53 Matthias Schoepfer <
> matthias.schoepfer@googlemail.com> ha scritto:
>
>> Hi Morné,
>>
>> thanks for you answer. Maybe, I will explain more: we have a Dragonboard
>> 410c based hardware. We use a read-only rootfs in one partition
>> (actually two with A/B approach) and we have a data partition for user
>> data as well as device specific data. We can partition and flash the
>> device through fastboot. So, if we can prepare ext4 filesystems (maybe
>> through yocto instead of hand-crafted scripting) for each device,
>> commissioning will be an easy task for the manufacturer.
>>
>> I guess, we are not the only ones that need to store device specific
>> information besides the rootfs, and I do not find a whole lot about it
>> in the yocto manuals. I wonder, if there are best practices, how to
>> protect the data from getting corrupted (intentionally by an attacker or
>> by accident through ... flash corruption or whatever).
>>
>> Regards,
>>
>>     Matthias
>>
>> On 6/24/19 9:08 AM, Morné Lamprecht wrote:
>> > On Mon, Jun 17, 2019 at 05:25:56PM +0200, Matthias Schoepfer wrote:
>> >> Is there a smart, recommended way to deal with device specific data
>> >> (i.e.  serial number, credentials for backend access, you name it),
>> >> that is specific for *one* device, and hence does not belong into the
>> >> rootfs. I know, that there are (safe) hardware stores for it, but
>> >> what, if your device does not have one.
>> >
>> > Not sure if I'm misunderstanding your question, but this should be
>> > part of your device commissioning process, i.e. like injecting
>> > specific security keys etc...so basically this will part of your image
>> > install / flash process, and not really part of the Yocto build
>> > process. The specifics of such a process would depend on your specific
>> > commissioning process.
>> >
>> >         - Morné
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>


-- 
Larry Brown
S/V Trident
Palm Harbor, FL
~~~~~~~~~~~~~~~~~_/)~~~~~~~~
    ~     ~          ~~           ~
~           ~~_/)    ~      ~ ~        ~
     ~                  _/)          ~

[-- Attachment #2: Type: text/html, Size: 5504 bytes --]

Re: General Question: Device specific value store

[Morné Lamprecht]

On Tue, Jun 25, 2019 at 09:25:13AM -0400, Larry Brown wrote:
>>> I wonder, if there are best practices, how to protect the data from getting 
>>> corrupted (intentionally by an attacker or by accident through ... flash 
>>> corruption or whatever).

Ideally your hardware should have some sort of hw-based secure key storage, and 
use that to support some sort of secure boot scheme. You can then implement a 
chain of trust, allowing you to securely verify a hash signature of the data 
during bootup, to ensure that it hadn't been tampered with or gotten corrupted.

Atmel / Microchip, for example, offers a range of Crypto Authentication ICs that 
could be added to your hardware to support this, if you hardware didn't have 
built in support for something like this. Their offering also included tools to 
securely inject the data into the secure ICs during manufacturing, or 
alternatively, you could write your own tool to interface with their API.

		- Morné

Re: General Question: Device specific value store

[Andrea Adami]

On Wed, Jun 26, 2019 at 12:03 PM Morné Lamprecht <morne@linux.com> wrote:
>
> On Tue, Jun 25, 2019 at 09:25:13AM -0400, Larry Brown wrote:
> >>> I wonder, if there are best practices, how to protect the data from getting
> >>> corrupted (intentionally by an attacker or by accident through ... flash
> >>> corruption or whatever).
>
> Ideally your hardware should have some sort of hw-based secure key storage, and
> use that to support some sort of secure boot scheme. You can then implement a
> chain of trust, allowing you to securely verify a hash signature of the data
> during bootup, to ensure that it hadn't been tampered with or gotten corrupted.
>
> Atmel / Microchip, for example, offers a range of Crypto Authentication ICs that
> could be added to your hardware to support this, if you hardware didn't have
> built in support for something like this. Their offering also included tools to
> securely inject the data into the secure ICs during manufacturing, or
> alternatively, you could write your own tool to interface with their API.
>
>                 - Morné
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


Hi,
almost all flash have a non-volatile storage.
It was OTP on old NOR, now there are more flavors: your board appears
to have eMMC and so OTP/MTP should be supported by the mmc stack.
Check out this link:
https://www.synopsys.com/designware-ip/technical-bulletin/memory-options.html

Regards
Andrea