[U-Boot] Secure update of uboot devices?

[U-Boot] Secure update of uboot devices?

[Andreas Bäck]

With the new threats like Stuxnet and Duqu one need to improve on how new
updates to software is distrubuted to devcies so one can
be sure that it's not a hacked or modified software that runs in the
device. We use uboot + usb stick to update the software in our devices.
Have anyone been trying out to add e.g cryptated,certificates or rsa keys
to uboot?

[U-Boot] Secure update of uboot devices?

[Marek Vasut]

> With the new threats like Stuxnet and Duqu one need to improve on how new
> updates to software is distrubuted to devcies so one can
> be sure that it's not a hacked or modified software that runs in the
> device. We use uboot + usb stick to update the software in our devices.
> Have anyone been trying out to add e.g cryptated,certificates or rsa keys
> to uboot?

sha1sum of the file isn't enough?

[U-Boot] Secure update of uboot devices?

[Andreas Bäck]

sha1sum sum is yes enough to verify that no files have been modified on the
file system on the already installed Linux device.

But my case here is if one need to update the software on the device out
somewhere in the world we have now made a usb stick and uboot looks for
special files first on the usb stick before it continues normal boot. How
can one ensure that the software on the usb stick is not altered on the way
to include some additional unwanted features?

I mean a sha1sum on the usb stick one would ofcource also modify at same
time as one add some files to the sub stick. I have been thinking of
public/private keys but then you have the problem that these expires

[U-Boot] Secure update of uboot devices?

[Wolfgang Denk]

Dear Andreas,

In message <CAB+EkH4j-UoUyHb=XgDbGRncX=Oq6+3+MNjWStiuojoOYUcMPw@mail.gmail.com> you wrote:
>
> sha1sum sum is yes enough to verify that no files have been modified on the
> file system on the already installed Linux device.

It is also good enough to ensure that the files on any distribution
media have not been corrupted or modified in some way.  Of course it
dies not protect against intentional modifications.

> But my case here is if one need to update the software on the device out
> somewhere in the world we have now made a usb stick and uboot looks for
> special files first on the usb stick before it continues normal boot. How
> can one ensure that the software on the usb stick is not altered on the way
> to include some additional unwanted features?

You cannot.  Actually you would have to insure first that the U-Boot
running on that system has not been tampered with.  If I were to
attack such a system, I'd probably first install (or otherwise run) a
version of U-boot that has any such security checks disabled or
removed.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There is, however, a strange, musty smell in the air that reminds  me
of something...hmm...yes...I've got it...there's a VMS nearby, or I'm
a Blit.          - Larry Wall in Configure from the perl distribution

[U-Boot] Secure update of uboot devices?

[Wolfgang Denk]

Dear Andreas,

please always keep the mailing list on Cc:

In message <CAB+EkH69iuEjcdKUYeX2NDw_v5bDJ6aLBbLPUN7ii7dnnAQmsg@mail.gmail.com> you wrote:
>
> Actually what i think I am after is authentication of uboot that have
> somewhat been discussed before in
> http://www.mail-archive.com/u-boot-users at lists.sourceforge.net/msg04707.html
> 
> But I can't find if it has been done before

I have no information that any such work has been done.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If God wanted me to touch my toes, he'd have put them on my knees.

[U-Boot] Secure update of uboot devices?

[Andreas Bäck]

Actually there seams to exsist some very old patches for this
http://lists.denx.de/pipermail/u-boot/2006-September/016960.html

Here a paper quite exact what I am after:
http://elinux.org/images/2/28/Trusted_Boot_Loader.pdf

Is there any toughts on integating this in trunk or should I try to merge
this patch with the git trunk of my own?

[U-Boot] Secure update of uboot devices?

[Mike Frysinger]

On Friday 06 January 2012 06:24:50 Andreas B?ck wrote:
> Actually there seams to exsist some very old patches for this
> http://lists.denx.de/pipermail/u-boot/2006-September/016960.html
> 
> Here a paper quite exact what I am after:
> http://elinux.org/images/2/28/Trusted_Boot_Loader.pdf
> 
> Is there any toughts on integating this in trunk or should I try to merge
> this patch with the git trunk of my own?

i think you need to outline exactly what it is you're trying to do.  "secure 
update" and "secure boot" is way too vague.  for starters, you need to outline 
the vectors you're trying to protect against.  the arm trustzone whitepaper is 
a pretty good example of things:
http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-
GENC-009492C_trustzone_security_whitepaper.pdf

there are many hardware solutions out there for verifying the integrity of u-
boot itself before executing it, but they tend to be SoC/arch specific.  the 
trusted boot paper you referred to for example really only makes sense on x86 
based platforms.

the patch you referred to however is for verifying the integrity of the kernel 
image that u-boot boots.  it doesn't help with u-boot itself.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120106/9fb93b3f/attachment.pgp>

[U-Boot] Secure update of uboot devices?

[Wolfgang Denk]

Dear =?ISO-8859-1?Q?Andreas_B=E4ck?=,

In message <CAB+EkH5g3ybYSLGYtBkATEFVG_WzeSYC3K0SmFOG4436Dr6uXA@mail.gmail.com> you wrote:
> 
> Actually there seams to exsist some very old patches for this
> http://lists.denx.de/pipermail/u-boot/2006-September/016960.html
> 
> Here a paper quite exact what I am after:
> http://elinux.org/images/2/28/Trusted_Boot_Loader.pdf
> 
> Is there any toughts on integating this in trunk or should I try to merge
> this patch with the git trunk of my own?

If you read the comments to the old patches you know why that code did
not go into mainline then.  It would not go into mainline for the same
reasons today.  This needs a major rework.

The feature itself is certainly interesting, and (cleaned up) patcehs
are welcome.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I've seen it. It's rubbish."          - Marvin the Paranoid Android

[U-Boot] Secure update of uboot devices?

[Kim Phillips]

On Fri, 30 Dec 2011 13:37:47 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Dear Andreas,
> 
> In message <CAB+EkH4j-UoUyHb=XgDbGRncX=Oq6+3+MNjWStiuojoOYUcMPw@mail.gmail.com> you wrote:
> >
> > sha1sum sum is yes enough to verify that no files have been modified on the
> > file system on the already installed Linux device.
> 
> It is also good enough to ensure that the files on any distribution
> media have not been corrupted or modified in some way.  Of course it
> dies not protect against intentional modifications.
> 
> > But my case here is if one need to update the software on the device out
> > somewhere in the world we have now made a usb stick and uboot looks for
> > special files first on the usb stick before it continues normal boot. How
> > can one ensure that the software on the usb stick is not altered on the way
> > to include some additional unwanted features?
> 
> You cannot.  Actually you would have to insure first that the U-Boot
> running on that system has not been tampered with.  If I were to
> attack such a system, I'd probably first install (or otherwise run) a
> version of U-boot that has any such security checks disabled or
> removed.

That depends on your hardware.  SoCs with Freescale SEC v4+ h/w can
enable a trusted boot mode after writing a private key to
special-purpose on-chip key memory and subsequently blowing a fuse.
The trusted boot mode ensures a continuous root of trust by booting
an initial (u-)bootloader from on-chip firmware that verifies the
authenticity of the u-boot image it loads before executing it.  The
initial bootloader is written in a similar fashion to the private
key of the chip, and similarly can never be overwritten.  Subsequent
loads, e.g., u-boot->kernel, kernel->app, are free to inherit that
same root of trust.

The Freescale BSP version of u-boot includes some of Freescale's
secure boot work [1], but since then it's been modified to use the
dedicated crypto unit to do the crypto and therefore boot much
faster. Ideally u-boot would be modified to use either s/w or h/w
crypto, but unfortunately I haven't had the time to look into it.

Kim

[1] I don't know where to find the latest that uses the h/w to do
the crypto right now, but there's some s/w crypto based code
available here:

http://git.freescale.com/git/cgit.cgi/ppc/sdk/u-boot.git/log/

[U-Boot] Secure update of uboot devices?

[Andreas Bäck]

Hello

Our linux boxes with Uboot and frescale mpc5200B are set at production with
software and that is no problem.
But then when the need to update software afterwards in the field is today
only so simple that if uboot finds a usb stick with a file uImage then it
will start that and do all the updates.
What I am after a litle more tamperproff way of knowing that the software
that is updated to these hardware software are not totally modified /
hacked.

If one could have e.g uboot to verify uImage that it signed with right
private key (The software in production would have compiled in the public
part),
I relize it can be hard to prevent all things with our current hardware but
if one could at last rise the level so that at least some jtag debugger is
need to modify the content and not only a only basic tools
found in any windows/linux computer. We are also starting to design next
generation of hardware and here more can be done in the hardware to rise
the bar even more.

Or have you any other suggestion on how this could be improved?

Thanks in advance

[U-Boot] Secure update of uboot devices?

[Simon Glass]

Hi Andreas,

On Sat, Mar 17, 2012 at 2:25 AM, Andreas B?ck <andreas.back778@gmail.com> wrote:
> Hello
>
> Our linux boxes with Uboot and frescale mpc5200B are set at production with
> software and that is no problem.
> But then when the need to update software afterwards in the field is today
> only so simple that if uboot finds a usb stick with a file uImage then it
> will start that and do all the updates.
> What I am after a litle more tamperproff way of knowing that the software
> that is updated to these hardware software are not totally modified /
> hacked.
>
> If one could have e.g uboot to verify uImage that it signed with right
> private key (The software in production would have compiled in the public
> part),
> I relize it can be hard to prevent all things with our current hardware but
> if one could at last rise the level so that at least some jtag debugger is
> need to modify the content and not only a only basic tools
> found in any windows/linux computer. We are also starting to design next
> generation of hardware and here more can be done in the hardware to rise
> the bar even more.
>
> Or have you any other suggestion on how this could be improved?

I copied you on a series I sent a few days ago which implements
verified boot using RSA, using FIT as suggested by Wolfgang. That
might be closer to what you want.

Regards,
Simon

>
> Thanks in advance
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>