OpenWrt One / project update

Sat Apr 13 16:45:14 PDT 2024

Fixing typos to make the whole message clearer.

On Sun, Apr 14, 2024 at 01:03:04AM +0200, Enrico Mioso wrote:
> On Fri, Apr 12, 2024 at 05:30:35PM -0400, Michael Richardson wrote:
> > 
> > Daniel Golle <daniel at makrotopia.org> wrote:
> >     >> In the first PDF, there is mention of:
> >     >> Security Support 2 * 256-bit multi-key on OTP eFuse
> >     >> Support 64 version OTP eFuse for anti-rollback
> > 
> >     > Those features require proprietary tools provided by MediaTek only to
> >     > clients under NDA. Unless some 3rd-party reverse-engineers those
> >     > tools, we won't ever use those features. Also note that those 256-bit
> >     > keys are *symmetric* keys probably, so not that useful for IDevID.
> > 
> > Yes, I know they are symmetrical.
> > Typically, the way that a 256-bit seed is used is that it is blown in the
> > MediaTek fab with a strong random number.  This seed is then provided via
> > secure storage to the OEM (us). [You ought to be thinking Johnny Nmemonic,
> > but in practive, I think it's a USB drive with a password protected .xlsx
> > file, sigh]
> > 
> > Our factory then uses the seed to generate a (256-bit ECDSA) keypair, for
> > which a CSR and then certificate are generated.  The private key is securely
> > erased, and the certificate is loaded into the device.   The device
> > "simultaenously" uses the seed to generate the same keypair, and it now has
> > the private key that goes with the certificate.
> > This process has become common, but it doesn't have a good name.
> > https://www.ietf.org/archive/id/draft-irtf-t2trg-taxonomy-manufacturer-anchors-03.html#name-carrot-method-key-setup-bas
> > (I tried to rename the methods: (A)vocado, (B)amboo, and (C)arrot, but that
> > was considered too whimsical by some)
> > 
> >     >> which is often the key to getting IDevID deployed, but I didn't find further
> >     >> mention of that in the three datasheets.
> > 
> >     > Another option for deploying IDevID is using MMU to prevent access to
> >     > the SPI-NOR I/O range from non-secure land and handling cryptographic
> >     > operations entirely in the secure enclave, e.g. using OP-TEE and fTPM.
> > 
> >     > This is possible without burning any fuses and without any proprietary
> >     > tools (but will probably not be implemented in time for the firmware
> >     > which will ship with the device -- however, it can be done after, I
> >     > can help and point who ever wants to do it to the right directions.)
> > 
> > If we are going to use OP-TEE to get an fTPM enabled, then that can be used
> > for IDevID, and it's much faster (and rather more secure) than i2c interfaced
> > discreet chips.  But, it means more factory work for us.
> > 
> > Usually, the ARM TrustZone must be initialized pretty early, at the latest in
> > our u-boot.
> > 
> > https://mediatek.gitlab.io/aiot/doc/aiot-dev-guide/master/sw/yocto/secure-boot.html
> > Has a nice picture of how the various *SECURE BOOT* goes together.
> > This is not for this CPU/SOC, but the Genio eval cards.  My guess is that
> > it's probably pretty common across their line, and it's within epsilon of
> > other ARM processors.
> > 
> > The issue is that we don't want SECURE BOOT, at least not past u-boot,
> > because that would get in the way of the people who want to use this board.
> > We might want the orange, and red pieces in the diagram.
> > 
> > My suggestion (which I think is feasible) is that we put a signed u-boot onto
> > the board, but that we turn u-boot verification of Linux-kernel/initramfs
> > (the "FIT" stuff) *off*. Owners can install their own signing keys and sign
> > their images if they want to do that.   Probably, we can leave measure boot on.
> > 
> > Measured boot collects the hashes (into the fTPM usually), and then asks a
> > third party if they are okay.  https://www.rfc-editor.org/rfc/rfc9334#name-two-types-of-environments-o
> > 
> > Having orange and red pieces "secured" *does* mean that u-boot updates would
> > have to come from openwrt.  That's descending into a thresherous way <
> > https://www.gnu.org/philosophy/can-you-trust.html > a bit.
> > Probably we can offer to sign other people's u-boot images; but probably
> > there won't be more than a dozen such requests.
> 
> No thanks - enough proprietary/signing/secure crap all over already, and I've been there long enough to tell you this is really not fun.
> 
> Please guys wake up and stop these things.
> If you really want to play with this kind of thing, why not build your own line of hardware?
> And if you're kind enough to leave off secure boot in hw, we may be able to replace the bootloader with one allowing people to do what they feel like with their hardware.
> And I am saying nothing new here since we, as project, find ourselves having to replace the bootloader sometimes, exactly due to signature checking and other limitations making things overall more difficult.
> I feel like we would damage our reputation allowing something like
> "ask us if you want your bootloader binary to be signed".
Remembers me of Symbian times, even tough it worked differently of course.
> Developing the technology is of course interesting, but the decision to engage on this should come from the user.
> This may create additional problems like e.g.: the user losing the key used to sign things and so on, and this would act as a reminder not to use this kind of technology.
> And I am all for giving a second chance to the user, so a way to disable this thing would ideally always be in place. Yes, I know this might not be easy to due how the SoC works, I am happy to hear from you on this matter.
> > 
> > An alternative is that we find a way not to sign or initialize the BROM/TF-A
> > secured boot, leaving those fuses unblown, and leave this to end owners to do.
> > That might be impossible, and my experience with other ARM boards is that
> > unless they get the fTPM loaded by the OAM board manufacturer, it just
> > doesn't work out.
> > 
> > ps: I'm willing to operate and secure the PK *I* junk that is needed to make
> >     this all work. It won't pass PCI on round one, but I'm sure if that was
> >     important, it could be done.
> > 
> 
> I am not a native speaker, so don't get offended if I define this crap, also due to the fact the PKI stuff is called "junk".
> Feel free to upload the whole PKI junk to a github repository where we can find and use it to sign whatever, thanks.
> And no, I am not against you, but really against this idea. Going to faaith against it as much as I can.
> Not against you of course. :)
> 
> Enrico
> > --
> > ]               Never tell me the odds!                 | ipv6 mesh networks [
> > ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> > ]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> > 
> 
> 
> 
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 