Dear all, (and may the new year be happy to you and your beloved)
In the course of evaluating the FW update flows for systems with FIP images, we identified the following requirements:
Req1: The FIP image, or the components in the FIP, must have a version field. Each version field will be compared against the anti-rollback counter of the platform that the FIP or its component is bound to.
Req2: We must be able to increment the FIP version field (though a FIP image FW update) without affecting the anti-rollback counter value. The anti-rollback counter should be incremented only for security updates upon explicit request.
Req3: The version field should be present even if the FIP does not contain image certificates.
Currently the FIP carries a version field in the different certificates, the anti-rollback counters are updated every time the root certificate value increased. This is not flexible enough and does not allow trial/acceptance of updates.
Can we open a discussion on how to enhance the version/anti-rollback counter update in TF-A?
Best regards, Etienne Carriere
ST Restricted
Hi Etienne,
It sounds good to have the version information for each images. But can the anti-rollback thing be handled outside of FIP image?
This anti-rollback counter may depend on the FWU multi-bank update. If so, I think it is natural that the FWU metadata has such image version for each bank, and security update (which is marked in a flag of Capsule header) will drop the accepted flag in the older banks. This is because the firmware is not always stored with FIP image. Some platform may store each firmware in different media. To cover such cases, FWU metadata itself should provide the version field (and 'anti-rollback' protocol too).
What would you think?
Thank you,
2022年1月5日(水) 19:23 Etienne CARRIERE via TF-A <tf-a@lists.trustedfirmware.org
:
Dear all, (and may the new year be happy to you and your beloved)
In the course of evaluating the FW update flows for systems with FIP images, we identified the following requirements:
Req1: The FIP image, or the components in the FIP, must have a version field. Each version field will be compared against the anti-rollback counter of the platform that the FIP or its component is bound to.
Req2: We must be able to increment the FIP version field (though a FIP image FW update) without affecting the anti-rollback counter value. The anti-rollback counter should be incremented only for security updates upon explicit request.
Req3: The version field should be present even if the FIP does not contain image certificates.
Currently the FIP carries a version field in the different certificates, the anti-rollback counters are updated every time the root certificate value increased. This is not flexible enough and does not allow trial/acceptance of updates.
Can we open a discussion on how to enhance the version/anti-rollback counter update in TF-A?
Best regards, Etienne Carriere
ST Restricted
TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
Hello Masami-san
-----Original Message----- From: Masami Hiramatsu masami.hiramatsu@linaro.org Sent: Wednesday, January 5, 2022 3:27 PM Subject: Re: [TF-A] fw update & anti-rollback versioning
Hi Etienne,
It sounds good to have the version information for each images. But can the anti-rollback thing be handled outside of FIP image?
The version value comes with the update images and should have the same level of confidence as the images content themselves. I think the version info should be authenticated using existing FIP certificates support.
Do you think the version ID could come from a specific channel (may not the best word) during update sequence? I mean outside FIP (or any updated) image content. Who would be responsible to set such the value? (and possibly attest it's reliable)
This anti-rollback counter may depend on the FWU multi-bank update. If so, I think it is natural that the FWU metadata has such image version for each bank, and security update (which is marked in a flag of Capsule header) will drop the accepted flag in the older banks. This is because the firmware is not always stored with FIP image. Some platform may store each firmware in different media. To cover such cases, FWU metadata itself should provide the version field (and 'anti-rollback' protocol too).
What would you think?
FWU metadata is also manipulated by non-secure world, so I don't think is can content such a sensitive data. Make sense?
Best regards, Etienne
Thank you,
2022年1月5日(水) 19:23 Etienne CARRIERE: Dear all, (and may the new year be happy to you and your beloved)
In the course of evaluating the FW update flows for systems with FIP images, we identified the following requirements:
Req1: The FIP image, or the components in the FIP, must have a version field. Each version field will be compared against the anti-rollback counter of the platform that the FIP or its component is bound to.
Req2: We must be able to increment the FIP version field (though a FIP image FW update) without affecting the anti-rollback counter value. The anti-rollback counter should be incremented only for security updates upon explicit request.
Req3:
The version field should be present even if the FIP does not contain
image certificates.
Currently the FIP carries a version field in the different certificates, the anti-rollback counters are updated every time the root certificate value increased. This is not flexible enough and does not allow trial/acceptance of updates.
Can we open a discussion on how to enhance the version/anti-rollback counter update in TF-A?
Best regards, Etienne Carriere
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
-- Masami Hiramatsu
ST Restricted
Hi Etienne
Please see my replies inline. I have used below terminologies to avoid confusion
1. Anti-rollback counter – Present in the certificate 2. Platform NV-counter – Present in the hardware
Regards Manish Badarkhe
From: Etienne CARRIERE via TF-A tf-a@lists.trustedfirmware.org Date: Thursday, 6 January 2022 at 16:10 To: Masami Hiramatsu masami.hiramatsu@linaro.org Cc: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org, Jose Marinho Jose.Marinho@arm.com Subject: [TF-A] Re: fw update & anti-rollback versioning Hello Masami-san
-----Original Message----- From: Masami Hiramatsu masami.hiramatsu@linaro.org Sent: Wednesday, January 5, 2022 3:27 PM Subject: Re: [TF-A] fw update & anti-rollback versioning
Hi Etienne,
It sounds good to have the version information for each images. But can the anti-rollback thing be handled outside of FIP image?
The version value comes with the update images and should have the same level of confidence as the images content themselves. I think the version info should be authenticated using existing FIP certificates support.
Do you think the version ID could come from a specific channel (may not the best word) during update sequence? I mean outside FIP (or any updated) image content. Who would be responsible to set such the value? (and possibly attest it's reliable)
This anti-rollback counter may depend on the FWU multi-bank update. If so, I think it is natural that the FWU metadata has such image version for each bank, and security update (which is marked in a flag of Capsule header) will drop the accepted flag in the older banks. This is because the firmware is not always stored with FIP image. Some platform may store each firmware in different media. To cover such cases, FWU metadata itself should provide the version field (and 'anti-rollback' protocol too).
What would you think?
FWU metadata is also manipulated by non-secure world, so I don't think is can content such a sensitive data. Make sense?
Best regards, Etienne
Thank you,
2022年1月5日(水) 19:23 Etienne CARRIERE: Dear all, (and may the new year be happy to you and your beloved)
In the course of evaluating the FW update flows for systems with FIP images, we identified the following requirements:
Req1: The FIP image, or the components in the FIP, must have a version field. Each version field will be compared against the anti-rollback counter of the platform that the FIP or its component is bound to.
IMO keeping single version for FIP may not work as it contains both Trusted and Non-Trusted Images and we can’t compare it against either Trusted or Non-Trusted platform NV-counter. However, we can add FIP version but it will only get used for sanity purpose.
We already have ‘version’ field inside each image certificate. Platform already use this field in TBBR flow to compare it against platform NV-counter. All Trusted and Non-Trusted FW versions gets compared against Trusted and Non-Trusted platform NV-counter respectively. Currently, all Trusted FWs hold same value, likewise for Non-Trusted FWs also. If we are looking to have every FW image have its own version value then platform must support NV-counter per image. Does ST platform supports multiple NV-counters?
Req2: We must be able to increment the FIP version field (though a FIP image FW update) without affecting the anti-rollback counter value. The anti-rollback counter should be incremented only for security updates upon explicit request.
I think you mean here to maintain separate ‘anti-rollback counter’ and “version” field in the image certificate. We like to know the use case how it will get consumed during the FW update flow. Do you want to use per image “anti-rollback counter” value to update its corresponding platform NV-counter, and per image version field only for the comparison against its platform NV-counter.
Req3:
The version field should be present even if the FIP does not contain
image certificates.
Can you use in this case (Non-TBBR flow) same FIP version explained above?
Currently the FIP carries a version field in the different certificates, the anti-rollback counters are updated every time the root certificate value increased. This is not flexible enough and does not allow trial/acceptance of updates.
Can we open a discussion on how to enhance the version/anti-rollback counter update in TF-A?
Best regards, Etienne Carriere
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
-- Masami Hiramatsu
ST Restricted -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
Hello Manish,
Sorry of the late response.
On Fri, 7 Jan 2022 at 19:09, Manish Badarkhe Manish.Badarkhe@arm.com wrote:
Hi Etienne
Please see my replies inline. I have used below terminologies to avoid confusion
Anti-rollback counter – Present in the certificate Platform NV-counter – Present in the hardware
Thanks, i'll try to use the appropriate wording.
Regards
Manish Badarkhe
From: Etienne CARRIERE via TF-A tf-a@lists.trustedfirmware.org Date: Thursday, 6 January 2022 at 16:10 To: Masami Hiramatsu masami.hiramatsu@linaro.org Cc: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org, Jose Marinho Jose.Marinho@arm.com Subject: [TF-A] Re: fw update & anti-rollback versioning
Hello Masami-san
-----Original Message----- From: Masami Hiramatsu masami.hiramatsu@linaro.org Sent: Wednesday, January 5, 2022 3:27 PM Subject: Re: [TF-A] fw update & anti-rollback versioning
Hi Etienne,
It sounds good to have the version information for each images. But can the anti-rollback thing be handled outside of FIP image?
The version value comes with the update images and should have the same level of confidence as the images content themselves. I think the version info should be authenticated using existing FIP certificates support.
Do you think the version ID could come from a specific channel (may not the best word) during update sequence? I mean outside FIP (or any updated) image content. Who would be responsible to set such the value? (and possibly attest it's reliable)
This anti-rollback counter may depend on the FWU multi-bank update. If so, I think it is natural that the FWU metadata has such image version for each bank, and security update (which is marked in a flag of Capsule header) will drop the accepted flag in the older banks. This is because the firmware is not always stored with FIP image. Some platform may store each firmware in different media. To cover such cases, FWU metadata itself should provide the version field (and 'anti-rollback' protocol too).
What would you think?
FWU metadata is also manipulated by non-secure world, so I don't think is can content such a sensitive data. Make sense?
Best regards, Etienne
Thank you,
2022年1月5日(水) 19:23 Etienne CARRIERE: Dear all, (and may the new year be happy to you and your beloved)
In the course of evaluating the FW update flows for systems with FIP images, we identified the following requirements:
Req1: The FIP image, or the components in the FIP, must have a version field. Each version field will be compared against the anti-rollback counter of the platform that the FIP or its component is bound to.
IMO keeping single version for FIP may not work as it contains both Trusted and Non-Trusted Images and we can’t compare it against either Trusted or Non-Trusted platform NV-counter. However, we can add FIP version but it will only get used for sanity purpose.
We already have ‘version’ field inside each image certificate. Platform already use this field in TBBR flow to compare it against platform NV-counter. All Trusted and Non-Trusted FW versions gets compared against Trusted and Non-Trusted platform NV-counter respectively.
Currently, all Trusted FWs hold same value, likewise for Non-Trusted FWs also. If we are looking to have every FW image have its own version value then platform must support NV-counter per image. Does ST platform supports multiple NV-counters?
No, our platforms usually don't have much NV monotonic counters the boot stage can reach. Using a single platform NV counter for the whole single update-able FIP image would be very convenient. But maybe that requirement to is too specific.
Req2: We must be able to increment the FIP version field (though a FIP image FW update) without affecting the anti-rollback counter value. The anti-rollback counter should be incremented only for security updates upon explicit request.
I think you mean here to maintain separate ‘anti-rollback counter’ and “version” field in the image certificate. We like to know the use case how it will get consumed during the FW update flow.
Not really. The current issue is rather that platform NV-counter are being upgraded when anti-rollback NV counters in certificates have increased. This does allow update trials that should allow reverting to the last accepted image set, that must conform to platform NV-counters.
Do you want to use per image “anti-rollback counter” value to update its corresponding platform NV-counter, and per image version field only for the comparison against its platform NV-counter.
I have no real strong opinion here. If certification version fields a standard way to manage certificate updates/upgrades, then I think it is a this field can be a good place to store anti-rollback counters.
If expecting a single rollback counter for the FIP image protection, it cannot be relate to the certificate version field.
Req3:
The version field should be present even if the FIP does not contain
image certificates.
Can you use in this case (Non-TBBR flow) same FIP version explained above?
Currently the FIP carries a version field in the different certificates, the anti-rollback counters are updated every time the root certificate value increased. This is not flexible enough and does not allow trial/acceptance of updates.
Can we open a discussion on how to enhance the version/anti-rollback counter update in TF-A?
Best regards, Etienne Carriere
-- Masami Hiramatsu
Hi Etienne,
Sorry for replying later.
2022年1月7日(金) 1:10 Etienne CARRIERE etienne.carriere@st.com:
Hello Masami-san
-----Original Message----- From: Masami Hiramatsu masami.hiramatsu@linaro.org Sent: Wednesday, January 5, 2022 3:27 PM Subject: Re: [TF-A] fw update & anti-rollback versioning
Hi Etienne,
It sounds good to have the version information for each images. But can the anti-rollback thing be handled outside of FIP image?
The version value comes with the update images and should have the same level of confidence as the images content themselves. I think the version info should be authenticated using existing FIP certificates support.
Hm.
Do you think the version ID could come from a specific channel (may not the best word) during update sequence?
Yeah, I thought that the version ID comes from the capsule header.
I mean outside FIP (or any updated) image content. Who would be responsible to set such the value? (and possibly attest it's reliable)
Who builds the capsule file. Or, should we decouple the version value from the capsule file?
This anti-rollback counter may depend on the FWU multi-bank update. If so, I think it is natural that the FWU metadata has such image version for each bank, and security update (which is marked in a flag of Capsule header) will drop the accepted flag in the older banks. This is because the firmware is not always stored with FIP image. Some platform may store each firmware in different media. To cover such cases, FWU metadata itself should provide the version field (and 'anti-rollback' protocol too).
What would you think?
FWU metadata is also manipulated by non-secure world, so I don't think is can content such a sensitive data. Make sense?
Hmm, if so, FWU metadata based multi-bank update itself is not secure. What happen if the first bootloader choose an incorrect (old) FIP image to load because of cracked FWU metadata?
Thank you,
Best regards, Etienne
Thank you,
2022年1月5日(水) 19:23 Etienne CARRIERE: Dear all, (and may the new year be happy to you and your beloved)
In the course of evaluating the FW update flows for systems with FIP images, we identified the following requirements:
Req1: The FIP image, or the components in the FIP, must have a version field. Each version field will be compared against the anti-rollback counter of the platform that the FIP or its component is bound to.
Req2: We must be able to increment the FIP version field (though a FIP image FW update) without affecting the anti-rollback counter value. The anti-rollback counter should be incremented only for security updates upon explicit request.
Req3:
The version field should be present even if the FIP does not contain
image certificates.
Currently the FIP carries a version field in the different certificates, the anti-rollback counters are updated every time the root certificate value increased. This is not flexible enough and does not allow trial/acceptance of updates.
Can we open a discussion on how to enhance the version/anti-rollback counter update in TF-A?
Best regards, Etienne Carriere
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
-- Masami Hiramatsu
ST Restricted
Hello Masami-san,
From: Masami Hiramatsu masami.hiramatsu@linaro.org Hi Etienne,
Sorry for replying later.
2022年1月7日(金) 1:10 Etienne CARRIERE etienne.carriere@st.com:
Hello Masami-san
-----Original Message----- From: Masami Hiramatsu masami.hiramatsu@linaro.org Sent: Wednesday, January 5, 2022 3:27 PM Subject: Re: [TF-A] fw update & anti-rollback versioning
Hi Etienne,
It sounds good to have the version information for each images. But can the anti-rollback thing be handled outside of FIP image?
The version value comes with the update images and should have the same level of confidence as the images content themselves. I think the version info should be authenticated using existing FIP certificates support.
Hm.
Do you think the version ID could come from a specific channel (may not the best word) during update sequence?
Yeah, I thought that the version ID comes from the capsule header.
I mean outside FIP (or any updated) image content. Who would be responsible to set such the value? (and possibly attest it's reliable)
Who builds the capsule file. Or, should we decouple the version value from the capsule file?
I think it must be decoupled from the capusle file. When the BL2 loads the FIP partition, it should check anti-rollback counter against platform counter, so this anti-rollback counter should be tied to the FIP image, no?
This anti-rollback counter may depend on the FWU multi-bank update. If so, I think it is natural that the FWU metadata has such image version for each bank, and security update (which is marked in a flag of Capsule header) will drop the accepted flag in the older banks. This is because the firmware is not always stored with FIP image. Some platform may store each firmware in different media. To cover such cases, FWU metadata itself should provide the version field (and 'anti-rollback' protocol too).
What would you think?
FWU metadata is also manipulated by non-secure world, so I don't think is can content such a sensitive data. Make sense?
Hmm, if so, FWU metadata based multi-bank update itself is not secure. What happen if the first bootloader choose an incorrect (old) FIP image to load because of cracked FWU metadata?
It is (in my view), the task of the bootstage to ensure whatever images are to be booted that they match both authentication and version rollback protection. If metadata are fully corrupted, then device will be bricked, for sure. For platform where firmwares are stored in a non-secure storage media, next to kernel, filesystems etc..., we cannot overcome such DoS attack. Same case as a Linux kernel corrupting other parts of its filesystems storage media, preventing it from working.
Br, etienne
Thank you,
Best regards, Etienne
Thank you,
2022年1月5日(水) 19:23 Etienne CARRIERE: Dear all, (and may the new year be happy to you and your beloved)
In the course of evaluating the FW update flows for systems with FIP images, we identified the following requirements:
Req1: The FIP image, or the components in the FIP, must have a version field. Each version field will be compared against the anti-rollback counter of the platform that the FIP or its component is bound to.
Req2: We must be able to increment the FIP version field (though a FIP image FW update) without affecting the anti-rollback counter value. The anti-rollback counter should be incremented only for security updates upon explicit request.
Req3:
The version field should be present even if the FIP does not contain
image certificates.
Currently the FIP carries a version field in the different certificates, the anti-rollback counters are updated every time the root certificate value increased. This is not flexible enough and does not allow trial/acceptance of updates.
Can we open a discussion on how to enhance the version/anti-rollback counter update in TF-A?
Best regards, Etienne Carriere
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
-- Masami Hiramatsu
-- Masami Hiramatsu
tf-a@lists.trustedfirmware.org
-
Etienne Carriere -
Etienne CARRIERE -
Manish Badarkhe -
Masami Hiramatsu