Re: [Suit] Parameters and Commands

[Thomas Fossati <[e-mail]>]

Thanks Brendan, got it!

Cheers, t

On 28/02/2020, 11:40, "Brendan Moran" <[e-mail]> wrote:




    Hi Thomas,


    I think we’re confusing the steps of validation/execution a bit here. The order is:



    1. Verify firmware author’s authorization. (Signature validation)
    2. Execute Manifest
         1. Each time a condition is encountered:
              1. If measurement is requested in manifest, record measurement
              2. If measurement is required by internal policy, record measurement
    3. Seal the measurements (e.g. signature)
    4. Execute the firmware image



    You’ve said that BL2 is only trusted after BL1 verifies it. However, this is handled in a modular way in SUIT. The manifest is verified prior to execution, so BL1 can trust
     it. When BL2 is verified, the BL2 manifest is already verified and trusted, so it can be trusted to indicate the need for a measurement to be recorded.


    I think it’s important that we strongly define the purpose of each security mechanism we have in place. Secure boot is for authority enforcement: only authorised parties can place firmware on a device. This leaves some gaps: Is the firmware authorised,
     but old? A device with no secure time source can’t know that. If a third party wants to interact with a device, knowing that the firmware is authorised isn’t good enough, they have to know it’s the expected firmware—version numbers can lie—so we need a strong
     guarantee of exact version that secure boot alone cannot provide.


    Measured boot fills these gaps. The “version” of the firmware is exposed precisely via a trusted third party: the previous execution stage.






    Let’s try and define exactly which threat could be opened by allowing the signer of the manifest to also set measurement policy. First an assumption: the holder of the private key for authorising firmware has become nefarious: change of heart,
     theft of keys, etc.



    1. The manifest author tries to hide that a version has changed by not to reporting the firmware.
         1. The verifier notices that firmware version isn’t being reported and takes corrective action.
    2. The manifest author tries to hide that a version has changed by making a measurement before an update, but not reporting after
         1. This attempt at subterfuge is visible in the manifest and its lifetime is limited. The next measurement will make it irrelevant.
    3. The manifest author tries to hide that a version has changed by recording a measurement of one offset, but executing from another.
         1. This attempt at subterfuge is visible in the manifest. It can be further exposed by requiring offset measurements in multi-image devices.




    Are there other threats here? I don’t think there’s much space for a bad actor in this.


    I would argue that we make it required for:

    1. A condition-image to specify either Record-on-success or Record-always.
    2. Run Image to specify either Record-on-success or Record-always, and to require Run Image to automatically invoke a condition-image




    I think that would remove any scope for bad actors to even attempt to hide, while still allowing flexible reporting and, more importantly, a sensible way to communicate verification policy to a verifier.


    Best Regards,
    Brendan





    On 27 Feb 2020, at 17:18, Thomas Fossati <[e-mail]> wrote:

    Hey Brendan,

    I'm having a bit of trouble parsing this bit:

    On 27/02/2020, 16:23, "Brendan Moran" <[e-mail]> wrote:

    [...] For example, BL1 loads BL2. BL1 trusts the author of BL2
    (which is the basis of secure boot).  BL1 executes the policy laid out
    by BL2’s signer.



    BL1 can trust BL2 only after it has measured it, therefore "executing
    the policy laid out by BL2's signer" can only happen *after* a
    successful verification, do you agree?  If so, there is a temporal
    mismatch in the logic above.  That, or I am missing something important,
    which is what usually happens :-)

    cheers!










IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.