[18.04 FEAT] Sign POWER host/NV kernels

Bug #1696154 reported by bugproxy on 2017-06-06
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
High
Andy Whitcroft
The Ubuntu-power-systems project
High
Steve Langasek
linux (Ubuntu)
High
Andy Whitcroft
linux-signed (Ubuntu)
High
Andy Whitcroft

Bug Description

Feature Description:

Sign POWER host and NV kernels with sign-file in anticipation of POWER secure boot. Provide the associated certificate. Ideally it would be possible to reuse the UEFI shim private key and certificate used to sign and verify x86_64 kernels. More details to follow. Guest kernels will be addressed in a future separate feature request.

Business Case:

As a system administrator I want to verify the integrity of my kernels so that I can prevent malicious kernels from being executed.

Use Case:

Signed POWER kernels will be validated by OPAL as OpenPOWER systems boot when keys are properly installed and the system is booted in secure mode.

Test Case:

Sign and install a POWER kernel on an OpenPOWER machine with a firmware level that supports secure boot. Install a PK, distro KEK certificat, and distro DB certificate. Boot the system and verify that it will boot the kernel. Negative tests: Separately remove the signature, install an usigned kernel, and modify the kernel image and test that the kernel will not boot.

bugproxy (bugproxy) on 2017-06-06
tags: added: architecture-ppc64le bugnameltc-155050 severity-high targetmilestone-inin1710
Changed in ubuntu:
assignee: nobody → Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
affects: ubuntu → linux (Ubuntu)
tags: added: kernel-da-key
Changed in ubuntu-power-systems:
assignee: nobody → Canonical Kernel Team (canonical-kernel-team)

------- Comment From <email address hidden> 2017-07-10 16:49 EDT-------
Hi Canonical,

Here are some clarifications on the feature from the security team:

> To clarify, this feature is only asking for a change to the Ubuntu kernel build
> process to produce a signed kernel and no other development. They should be able
> to do that with sign-file and the existing UEFI shim key."

In support to a full secure boot up to the payload OS in 2018, a signed kernel will be very nice to have for 17.10. Will you be able to sign the Ubuntu kernel for the 17.10 release?

Regards,
Vicky

bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2017-07-13 16:51 EDT-------
Hi Canonical,

Please let me know if there are any concerns on signing the the Ubuntu kernel for the 17.10 release.

Thanks,
Vicky

Andy Whitcroft (apw) on 2017-07-17
Changed in ubuntu-power-systems:
assignee: Canonical Kernel Team (canonical-kernel-team) → Andy Whitcroft (apw)
assignee: Andy Whitcroft (apw) → Canonical Kernel Team (canonical-kernel-team)
Changed in linux (Ubuntu):
assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) → Andy Whitcroft (apw)
status: New → In Progress
importance: Undecided → High
Changed in ubuntu-power-systems:
status: New → In Progress
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2017-07-18 17:15 EDT-------
Is there any update that you can share at the moment?

Manoj Iyer (manjo) on 2017-07-19
Changed in ubuntu-power-systems:
importance: Undecided → High

apw is assigned this bug, kernel/foundations team will turn on the signing on the kernel and push it to a PPA for your testing. As for priority.. It is next on apw's list after he clears validations for the point release.

Changed in ubuntu-power-systems:
assignee: Canonical Kernel Team (canonical-kernel-team) → Steve Langasek (vorlon)

------- Comment From <email address hidden> 2017-07-20 14:16 EDT-------
Canonical please clarify. I was on a call with Andrew Cloke earlier today. He said this could be done but not done in time for 17.10 GA in October. It would happen after 17.10 GA.

bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2017-07-20 17:52 EDT-------
Canonical please clarify. I was on a call with Andrew Cloke earlier today. He said this could be done but not done in time for 17.10 GA in October. It would happen after 17.10 GA.

Work is ongoing to clarify the timeline for enabling signed Power kernels.

Manoj Iyer (manjo) on 2017-07-24
tags: added: triage-g
Steve Langasek (vorlon) wrote :

One open technical question from the Canonical side: can you confirm that the POWER firmware implementation will support embedded certificate chains as part of the vmlinux signature data? Our existing SecureBoot signing regime uses an on-line signing key which is chained to a our CA certificate, and it is the latter that we would normally provide for db.

It appears that the kmodsign tools support embedded certificates in the signature data, but we would like to confirm that the firmware implementation is also compatible with this.

------- Comment From <email address hidden> 2017-08-01 19:06 EDT-------
(In reply to comment #15)
> One open technical question from the Canonical side: can you confirm that
> the POWER firmware implementation will support embedded certificate chains
> as part of the vmlinux signature data? Our existing SecureBoot signing
> regime uses an on-line signing key which is chained to a our CA certificate,
> and it is the latter that we would normally provide for db.
>
> It appears that the kmodsign tools support embedded certificates in the
> signature data, but we would like to confirm that the firmware
> implementation is also compatible with this.

It seems that the Canonical CA should be added to the KEK and the "on-line signing key" should be added to the DB.

In our current SecureBoot design, the vmlinux embedded signature will be verified only against the DB certificate list. However, in order to add a certificate to DB, the certificate should be signed by any of the KEK entries. The PK will be used to authorize updates to the KEK certificate list.

Colin Watson (cjwatson) on 2017-08-04
Changed in launchpad:
status: New → Fix Committed
importance: Undecided → High
assignee: nobody → Andy Whitcroft (apw)

This has been deployed to dogfood. I have uploaded a package which generates a signing object containing a ppc64el binary kernel. This built and published as expected. After much playing I managed to confirm it was indeed signed as expected and by the key included with the result.

Andy Whitcroft (apw) wrote :

We generated a archive Opal signing key. Uploaded a full set of tests to the primary archive. Reviewed the results for all of these. Looking good. This is ready to deply.

tags: added: qa-ok
Andy Whitcroft (apw) wrote :

Deployment to production seems successful. I have uploaded a modified kernel to a PPA and built a signed kernel image from that. I am attaching that signed kernel and the public key component of the signing key for it. NOTE: this key is _not_ a final official canonical key it is a key for a PPA and for testing only.

There are two files:

  vmlinux-4.11.0-13-generic.opal.signed -- this is the bootable signed binary
  opal.x509 -- the DER format public key with which this binary is signed

Any testing, review appreciated. Please report back to this bug.

Changed in linux-signed (Ubuntu):
status: New → In Progress
importance: Undecided → Critical
importance: Critical → High
assignee: nobody → Andy Whitcroft (apw)
Steve Langasek (vorlon) wrote :

Thanks for the guidance regarding KEK vs. db. One further question, is it correct that the POWER implementation will be limited to 2048-bit RSA keys, the same as UEFI SecureBoot?

Andy Whitcroft (apw) wrote :
bugproxy (bugproxy) on 2017-08-24
tags: added: targetmilestone-inin1804
removed: targetmilestone-inin1710
Steve Langasek (vorlon) wrote :

Does IBM have any feedback for us regarding the test kernel Andy provided?

We have generated an online signing key to be included in db for OPAL. In the absence of feedback about whether 4096-bit keys are supported, we have generated a 2048-bit key.

Our current plan for secure delivery of the public key to IBM is to deliver the keys in person to George next month. Does this timeline fit IBM's needs for receipt of the public keys? Does it meet your expectations for a trust path for the keys, or is there another protocol that should be used?

In your reply of August 1, you wrote:

> However, in order to add a certificate to DB, the certificate should be
> signed by any of the KEK entries. The PK will be used to authorize updates
> to the KEK certificate list.

Can you please clarify if this means you are expecting the db entry to be delivered as an x509 certificate issued by the CA key listed in KEK, or if it should be delivered according to the format defined in the UEFI spec for authenticated variable updates?

------- Comment From <email address hidden> 2017-09-07 19:41 EDT-------
(In reply to comment #25)
> Does IBM have any feedback for us regarding the test kernel Andy provided?
>

We're planning to test this month. We'll give feedback as soon as the test is completed. The tentative target will be Sept. 29 or sooner.

> Can you please clarify if this means you are expecting the db entry to be
> delivered as an x509 certificate issued by the CA key listed in KEK, or if
> it should be delivered according to the format defined in the UEFI spec for
> authenticated variable updates?

Our team needs to have some discussions before finalizing the expected format. We'll get back to you soon. Thanks!

On Thu, Sep 07, 2017 at 11:50:09PM -0000, bugproxy wrote:
> ------- Comment From <email address hidden> 2017-09-07 19:41 EDT-------
> (In reply to comment #25)
> > Does IBM have any feedback for us regarding the test kernel Andy provided?

> We're planning to test this month. We'll give feedback as soon as the
> test is completed. The tentative target will be Sept. 29 or sooner.

> > Can you please clarify if this means you are expecting the db entry to be
> > delivered as an x509 certificate issued by the CA key listed in KEK, or if
> > it should be delivered according to the format defined in the UEFI spec for
> > authenticated variable updates?

> Our team needs to have some discussions before finalizing the expected
> format. We'll get back to you soon. Thanks!

Thanks. Do you have a timeline for when you will have this decision?
While we have procedures in place for signing/revoking keys whenever
necessary in the event of a key compromise, ordinarily this KEK key is not
available for signing. We have a window when we will be able to do this
signing from September 25 to September 29 and after that we do not have a
window scheduled until next year, so it would be good to know before then
what format you need this signed key matter to be provided in.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

------- Comment From <email address hidden> 2017-09-08 13:05 EDT-------
(In reply to comment #27)
> (In reply to comment #25)
> > Does IBM have any feedback for us regarding the test kernel Andy provided?
> >
>
> We're planning to test this month. We'll give feedback as soon as the test
> is completed. The tentative target will be Sept. 29 or sooner.
>
>
> > Can you please clarify if this means you are expecting the db entry to be
> > delivered as an x509 certificate issued by the CA key listed in KEK, or if
> > it should be delivered according to the format defined in the UEFI spec for
> > authenticated variable updates?
>
> Our team needs to have some discussions before finalizing the expected
> format. We'll get back to you soon. Thanks!

Our team confirms that it should be delivered according to ESL format.

Attached is the ESL db update for Canonical's POWER SecureBoot signing key. It is signed with Canonical's KEK key, which will be provided to IBM out of band to ensure integrity of the delivery channel.

------- Comment From <email address hidden> 2017-09-27 16:47 EDT-------
(In reply to comment #30)
> Attached is the ESL db update for Canonical's POWER SecureBoot signing key.
> It is signed with Canonical's KEK key, which will be provided to IBM out of
> band to ensure integrity of the delivery channel.

Thanks Andy and Vorlon for the attached files. The kernel appended signature verified successfully.

We didn't test the Canonical-POWER-SB-20170926.esl.signed file yet.

Questions:

1) The certificate provided contains a 4096-bit key and it was signed using sha512WithRSAEncryption. We had no problem to use it to verify the kernel appended signature - the kernel crypto API supports 4096-bit RSA keys. However, we don't have much space in our keystore and that's why we prefer to use 2048-bit RSA keys, same as UEFI SecureBoot. Could the Canonical-POWER-SB-20170926.esl.signed file be regenerated to contain a certificate that contains a 2048-bit RSA key instead? The certificate would be signed using sha256WithRSAEncryption.

2) We will need to put in the KEK a certificate that can be used to verify the signed ESL db updates provided by Canonical. How does Canonical have provided that for UEFI SecureBoot? certificate, ESL (not signed, since PK is not provided by Canonical)?
Currently, we are working on the code that will validate/process the authenticated variable updates. We will probably start testing it by the end of this year.

Thanks,
Claudio

Hi Claudio,

> ------- Comment From <email address hidden> 2017-09-27 16:47 EDT-------
> (In reply to comment #30)
> > Attached is the ESL db update for Canonical's POWER SecureBoot signing key.
> > It is signed with Canonical's KEK key, which will be provided to IBM out of
> > band to ensure integrity of the delivery channel.

> Thanks Andy and Vorlon for the attached files. The kernel appended
> signature verified successfully.

> We didn't test the Canonical-POWER-SB-20170926.esl.signed file yet.

> Questions:

> 1) The certificate provided contains a 4096-bit key and it was signed
> using sha512WithRSAEncryption. We had no problem to use it to verify the
> kernel appended signature - the kernel crypto API supports 4096-bit RSA
> keys. However, we don't have much space in our keystore and that's why
> we prefer to use 2048-bit RSA keys, same as UEFI SecureBoot. Could the
> Canonical-POWER-SB-20170926.esl.signed file be regenerated to contain a
> certificate that contains a 2048-bit RSA key instead? The certificate
> would be signed using sha256WithRSAEncryption.

The opal.x509 attachment is a test key only; it is not the same as
Canonical-POWER-SB-20170926.esl.signed, which is our production 2048-bit
key.

> 2) We will need to put in the KEK a certificate that can be used to verify
> the signed ESL db updates provided by Canonical. How does Canonical have
> provided that for UEFI SecureBoot? certificate, ESL (not signed, since PK
> is not provided by Canonical)? Currently, we are working on the code that
> will validate/process the authenticated variable updates. We will
> probably start testing it by the end of this year.

The current plan is to deliver this KEK as a certificate via a secure
in-person channel to George Wilson. I assume once delivered, if you need
this in ESL form for loading that IBM can perform this transformation (since
the only way to turn it into a signed ESL would be via the PK, which we
don't have).

------- Comment From <email address hidden> 2017-10-04 17:33 EDT-------
I have received the KEK from Emily in person.

------- Comment From <email address hidden> 2017-10-04 18:16 EDT-------
BTW, I learned from Emily that Canonical plans to issue Power keys/certs separately from those for the x86 UEFI shim. So moving from SHA-512 to SHA-256 may not be much of a priority from a reuse point of view. If we need any key changes, it would be good to send them before or during next week while Emily will be in NY meeting with vorlon.

On Thu, Oct 05, 2017 at 01:52:46AM -0000, bugproxy wrote:
> ------- Comment From <email address hidden> 2017-10-04 17:33 EDT-------
> I have received the KEK from Emily in person.

> ------- Comment From <email address hidden> 2017-10-04 18:16 EDT-------

> BTW, I learned from Emily that Canonical plans to issue Power keys/certs
> separately from those for the x86 UEFI shim. So moving from SHA-512 to
> SHA-256 may not be much of a priority from a reuse point of view. If we
> need any key changes, it would be good to send them before or during next
> week while Emily will be in NY meeting with vorlon.

Yes, if you need the hash changed from SHA512 to SHA256 on the 2048-bit db
key, please let us know this week so that we can arrange to have a new ESL
signed.

We believe the Launchpad side of this is done, so closing this task.

Changed in launchpad:
status: Fix Committed → Fix Released
Manoj Iyer (manjo) on 2017-11-06
summary: - [17.10 FEAT] Sign POWER host/NV kernels
+ [18.04 FEAT] Sign POWER host/NV kernels
Changed in linux (Ubuntu):
milestone: none → ubuntu-18.04
Changed in linux-signed (Ubuntu):
milestone: none → ubuntu-18.04
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers