[coreboot] How to protect binary in flash chip? OTP?

Martin Roth gaumless at gmail.com
Fri May 6 16:49:47 CEST 2016


Hi Zheng,
 This sort of issue is a definite problem I've seen for consultants,
but I'm not sure that protecting the ROM is the solution. it seems
like having a better contract in place at the start might be a better
way to go about it.  Unfortunately that doesn't help you for this job.

Maybe knowing that they won't be able to use your services in the
future is enough of a deterrent?

I understand and sympathise with your situation, but I'd really hate
to see this sort of DRM make it into coreboot.

Please let me know if there's anything other than DRM solutions that
we can do to help you out.  If you have or want to set up a website as
a coreboot consultant, we'd be happy to add you to our consulting
page.

Martin

On Fri, May 6, 2016 at 3:08 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 06.05.2016 09:49, Patrick Rudolph wrote:
>> On 2016-05-06 02:45 AM, Zheng Bao wrote:
>>> Is there any way to protect the binary image in flash chip from being
>>> copied? Once the customers
>>> gets the image, they can produce millions of board and do not tell me.
>>> I just want to know the
>>> amount of the mass production.
>>> [...]
>>
>> As you want to execute code from it, it needs to be readable.
>> Protecting it from software doesn't make much sense as you could just
>> de-solder the flash chip.
>>
>> I guess what you want to know is: Should a copied image boot on another
>> board ?
>>
>> I've got two solutions:
>> 1.
>> You could encrypt the binary and store the secret in a TPM.
>> That way every board would have the same encryption key.
>> No idea if this is possible on your platform and how much work it would
>> be to implement in coreboot.
>> That'd be a good GSoC project :-)
>>
>> 2.
>> If you don't have a TPM you could use serial numbers of
>> CPU/Southbridge/SoC.
>> That way every board would have it's own encryption key.
>> But I guess the decryption code could easily be reversed engineered.
>
> I wouldn't go with encryption, but rather with some check which refuses
> to boot if serial number (SoC, MAC address, ...) and a hash of it (in
> OTP) mismatch. That way even reflashing the board won't erase the hash
> by accident, and you can just give the manufacturer as many OTP images
> as needed. They just need to supply the serial numbers to you in advance.
>
>
>> An end user would be able to do a backup and would be able to reflash
>> the bios *on the same board*.
>
> Yes, ability to reflash is important.
>
> Regards,
> Carl-Daniel
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot



More information about the coreboot mailing list