Re: [tegrarcm PATCH 0/2] Initial support for secured devices

[Alban Bedel <alban.bedel-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>]

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

On Wed, 11 Nov 2015 09:55:31 -0700
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:

> On 11/09/2015 10:19 AM, Alban Bedel wrote:
> > This series add the bare minimum to be able to use RCM on secured production
> > devices. For this the CMAC hash just has to be replaced with an RSA-PSS
> > signature, as CryptoPP already provides this algorith it is quiet trivial
> > to implement.
> >
> > Although RCM is now working this doesn't yet allow running the bootloader.
> > The miniloader works and it loads the BCT and bootloader, but the handsoff
> > to the bootloader isn't working yet. I currently suspect the miniloader as
> > the same bootloader works properly when it is flashed on a secured device
> > with the proper signature.
> 
> CC += Allen, Penny - please see and comment on the patch series on the 
> linux-tegra mailing list. Thanks.
> 
> I'm rather hesitant to apply this before it's fully proved to be 
> working, i.e. before you actually get the downloaded bootloader to work. 
> This is simply because it seems likely the patches will need fixes to 
> make them fully work.

I understand this, I mainly wanted to publish the serie. However the RCM
part is working as the miniloader works enough to at least be able to
download the BCT and bootloader.

> Some general questions:
> 
> 1) I believe older chips only support only an SBK, whereas newer chips 
> support both SBK and (RSA) PKC (or perhaps just PKC). I assume you're 
> using a chip fused to enable PKC.

Yes, I only use PKC.

> Are you confident that your changes won't negatively impact a chip
> without either SBK or PKC enabled, or with an SBK enabled (well, I
> imagine that doesn't work right now anyway...).

As long as you don't give a key nothings changes.

> In particular, I wonder about the comment "above "the CMAC hash just
> has to be replaced"; I hope that doesn't impact SBK/non-security-enabled
> chips.

According to the Android BSP doc (Tegra BSP for Android Development
Guide, Security chapter) PKC always override SBK. If an SBK key is set
while in PKC mode it is only loaded in the AES engine, it is not used
to decrypt the bootloader.

> 2) I believe Tegra supports either/both of (a) validating the (BCT and) 
> bootloader using the SBK/PKC and (b) encrypting the (BCT and) bootloader 
> using the SBK/PKC.

PKC (aka public/private key) only allow signing and SBK (aka symmetric
keys) only allow encrypting.

> Do you know which options your chip is fused for?

I fused it for PKC.

> I wonder if the bootloader isn't running because the chip is expecting to 
> decrypt it, yet you're supplying a non-encrypted binary, which of course 
> gets corrupted during the decryption process?

I doubt it, first the chip can boot from the signed image I wrote on
the EMMC. Secondly the RCM communication is working, it query the
version and send the miniloader. Finally the miniloader is running as
the BCT and bootloader get downloaded via nv3p.

I currently suspect the miniloader, some steps (like setting the BCT)
might need to be done slightly differently. Or it leave the secure mode
too early, or ...

Alban

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]