Hi Erik, Odd,
I'm also CC:ing the st-discuss list to loop in other folks.
This email relates to the following accepted proposal:
https://git.glasklar.is/system-transparency/project/documentation/-/blob/mai...
Which has been implemented and documented, and it is currently on track to be included in the upcoming st-v1.2.0 collection release.
During today's weekly meet it was raised that there's one important aspect of the proposal that (maybe?) wasn't discussed, see:
https://git.glasklar.is/system-transparency/project/documentation/-/blob/mai...
TL;DR: the stboot image (which contains the trust policy) didn't contain any secrets before, but it does if the optional decrypt key is added.
This is possibly annoying in a future scenario when there's remote attestation, since the stboot image would likely be measured (and so also need to be public in order to predict expected PCRs values).
It also makes key rotation harder, i.e., a new stboot image is needed.
It might be an annoyance that the stboot image needs to be secret.
Is this something you considered and are not bothered by? I'm asking because otherwise it's not too late to do a follow-up proposal and update the implementation to use EFI NVRAM (provisioned by stprov).
Some possile options moving forward:
- Do nothing, if you're OS package needs to be secret you're also okay with the stboot image needing to be secret (the accepted proposal). - Make a follow-up proposal and update what was already merged, to instead move the secret from stboot's trust policy to EFI NVRAM. - Make a follow-up proposal later if someone wants it. Then stboot would have to have a semantic for optionally locating decrypt keys in both the trust policy and EFI NVRAM. Perhaps a bit ugly, but not a major complication when seeing the forest for the trees.
I think all of the above would be okay. What's your preference?
-Rasmus
Hi Rasmus,
Thanks for looking into this!
Our preference is to use the solution as is, we are eager to deploy it from ST boot upstream.
Rebuilding the stboot image occasionally has to be done anyway to support new network cards, etc. and is not a significant inconvenience at this point.
Using EFI NVRAM to store the secret also brings additional risk in case the machine gets compromised, e.g., stolen.
Kind regards,
Erik
On Mon, Jan 20, 2025 at 9:18 PM Rasmus Dahlberg rgdd@glasklarteknik.se wrote:
Hi Erik, Odd,
I'm also CC:ing the st-discuss list to loop in other folks.
This email relates to the following accepted proposal:
https://git.glasklar.is/system-transparency/project/documentation/-/blob/mai...
Which has been implemented and documented, and it is currently on track to be included in the upcoming st-v1.2.0 collection release.
During today's weekly meet it was raised that there's one important aspect of the proposal that (maybe?) wasn't discussed, see:
https://git.glasklar.is/system-transparency/project/documentation/-/blob/mai...
TL;DR: the stboot image (which contains the trust policy) didn't contain any secrets before, but it does if the optional decrypt key is added.
This is possibly annoying in a future scenario when there's remote attestation, since the stboot image would likely be measured (and so also need to be public in order to predict expected PCRs values).
It also makes key rotation harder, i.e., a new stboot image is needed.
It might be an annoyance that the stboot image needs to be secret.
Is this something you considered and are not bothered by? I'm asking because otherwise it's not too late to do a follow-up proposal and update the implementation to use EFI NVRAM (provisioned by stprov).
Some possile options moving forward:
- Do nothing, if you're OS package needs to be secret you're also okay with the stboot image needing to be secret (the accepted proposal).
- Make a follow-up proposal and update what was already merged, to instead move the secret from stboot's trust policy to EFI NVRAM.
- Make a follow-up proposal later if someone wants it. Then stboot would have to have a semantic for optionally locating decrypt keys in both the trust policy and EFI NVRAM. Perhaps a bit ugly, but not a major complication when seeing the forest for the trees.
I think all of the above would be okay. What's your preference?
-Rasmus
Thanks for the response -- in that case we keep it as is!
-Rasmus
On Tue, Jan 21, 2025 at 02:18:43PM +0100, Erik Hagopian wrote:
Hi Rasmus,
Thanks for looking into this!
Our preference is to use the solution as is, we are eager to deploy it from ST boot upstream.
Rebuilding the stboot image occasionally has to be done anyway to support new network cards, etc. and is not a significant inconvenience at this point.
Using EFI NVRAM to store the secret also brings additional risk in case the machine gets compromised, e.g., stolen.
Kind regards,
Erik
On Mon, Jan 20, 2025 at 9:18 PM Rasmus Dahlberg rgdd@glasklarteknik.se wrote:
Hi Erik, Odd,
I'm also CC:ing the st-discuss list to loop in other folks.
This email relates to the following accepted proposal:
https://git.glasklar.is/system-transparency/project/documentation/-/blob/mai...
Which has been implemented and documented, and it is currently on track to be included in the upcoming st-v1.2.0 collection release.
During today's weekly meet it was raised that there's one important aspect of the proposal that (maybe?) wasn't discussed, see:
https://git.glasklar.is/system-transparency/project/documentation/-/blob/mai...
TL;DR: the stboot image (which contains the trust policy) didn't contain any secrets before, but it does if the optional decrypt key is added.
This is possibly annoying in a future scenario when there's remote attestation, since the stboot image would likely be measured (and so also need to be public in order to predict expected PCRs values).
It also makes key rotation harder, i.e., a new stboot image is needed.
It might be an annoyance that the stboot image needs to be secret.
Is this something you considered and are not bothered by? I'm asking because otherwise it's not too late to do a follow-up proposal and update the implementation to use EFI NVRAM (provisioned by stprov).
Some possile options moving forward:
- Do nothing, if you're OS package needs to be secret you're also okay with the stboot image needing to be secret (the accepted proposal).
- Make a follow-up proposal and update what was already merged, to instead move the secret from stboot's trust policy to EFI NVRAM.
- Make a follow-up proposal later if someone wants it. Then stboot would have to have a semantic for optionally locating decrypt keys in both the trust policy and EFI NVRAM. Perhaps a bit ugly, but not a major complication when seeing the forest for the trees.
I think all of the above would be okay. What's your preference?
-Rasmus
st-discuss@lists.system-transparency.org
-
Erik Hagopian -
Rasmus Dahlberg