(Created page with "{{admon/caution|DRAFT|This is just a DRAFT. We try and make sure the information here is up to date and correct, but please check before depending on it.}} {{admon/important | C...") |
No edit summary |
||
Line 1: | Line 1: | ||
{{admon/caution|DRAFT|This is just a DRAFT. We try and make sure the information here is up to date and correct, but please check before depending on it.}} | {{admon/caution|DRAFT|This is just a DRAFT. We try and make sure the information here is up to date and correct, but please check before depending on it.}} | ||
<!-- All fields on this form are required to be accepted by FESCo. | <!-- All fields on this form are required to be accepted by FESCo. | ||
Line 13: | Line 6: | ||
<!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --> | <!-- The actual name of your feature page should look something like: Features/Your_Feature_Name. This keeps all features in the same namespace --> | ||
= | = RPM Signature Checking During Installation <!-- The name of your feature --> = | ||
== Summary == | == Summary == | ||
Back in the dawn of time, rpm grew the ability to check cryptographic signatures of a package. We've never used this during installation, because it was unclear where the root of trust would come from - there's no way to tell that the public keys are valid. This is filed in bugzilla <a href="https://bugzilla.redhat.com/show_bug.cgi?id=998">here</a>. | |||
That problem is now solvable. | |||
== Owner == | == Owner == | ||
<!--This should link to your home wiki page so we know who you are--> | <!--This should link to your home wiki page so we know who you are--> | ||
* Name: [[User: | * Name: [[User:Pjones| Peter Jones]] | ||
<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--> | <!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved--> | ||
Line 26: | Line 21: | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/ | * Targeted release: [[Releases/19 | Fedora 19 ]] | ||
* Last updated: | * Last updated: 23-Jun-2012 | ||
* Percentage of completion: | * Percentage of completion: 20% | ||
<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --> | <!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --> | ||
== Detailed Description == | == Detailed Description == | ||
Using the Secure Boot mechanism, we can make a UEFI binary, which for this discussion we'll call "Hello, World!", or "HW" for short. In that binary, we add an extra section that holds a list of public keys. We then get the binary signed with the UEFI signing service. | |||
During installation, we verify the signature against the hardware keys. If the signature is invalid, we warn the user that something has gone horribly wrong. If it's valid, we extract the public keys from the binary using a simple tool, and we add them to the rpm database. We then run the anaconda transaction with keys in place. | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
No more risky installation from untrusted repositories. | |||
== Scope == | == Scope == | ||
< | <ol> | ||
<li> Write the small utility to generate the binary | |||
<li> Write the small utility to verify the binary and extract the keys | |||
<li> Get a new binary signed every time we change the signing keys. | |||
</ol> | |||
== How To Test == | == How To Test == | ||
Standard installation should test that it's working. Invalid binaries are easily provided to test a negative cryptographic test. | |||
== User Experience == | == User Experience == | ||
Substantially the same as current experience, but with a nice sense of security. | |||
== Dependencies == | == Dependencies == | ||
pesign will provide utilities for doing this which it doesn't have yet. | |||
== Contingency Plan == | == Contingency Plan == | ||
Contingency plan is current status quo. | |||
== Documentation == | == Documentation == | ||
Not yet. | |||
== Release Notes == | == Release Notes == | ||
Line 75: | Line 63: | ||
== Comments and Discussion == | == Comments and Discussion == | ||
* See [[Talk:Features/ | * See [[Talk:Features/SignatureCheckingDuringInstall]] | ||
[[Category:FeaturePageIncomplete]] | [[Category:FeaturePageIncomplete]] |
Revision as of 20:25, 23 June 2012
RPM Signature Checking During Installation
Summary
Back in the dawn of time, rpm grew the ability to check cryptographic signatures of a package. We've never used this during installation, because it was unclear where the root of trust would come from - there's no way to tell that the public keys are valid. This is filed in bugzilla <a href="https://bugzilla.redhat.com/show_bug.cgi?id=998">here</a>. That problem is now solvable.
Owner
- Name: Peter Jones
- Email: <your email address so we can contact you, invite you to meetings, etc.>
Current status
- Targeted release: Fedora 19
- Last updated: 23-Jun-2012
- Percentage of completion: 20%
Detailed Description
Using the Secure Boot mechanism, we can make a UEFI binary, which for this discussion we'll call "Hello, World!", or "HW" for short. In that binary, we add an extra section that holds a list of public keys. We then get the binary signed with the UEFI signing service.
During installation, we verify the signature against the hardware keys. If the signature is invalid, we warn the user that something has gone horribly wrong. If it's valid, we extract the public keys from the binary using a simple tool, and we add them to the rpm database. We then run the anaconda transaction with keys in place.
Benefit to Fedora
No more risky installation from untrusted repositories.
Scope
- Write the small utility to generate the binary
- Write the small utility to verify the binary and extract the keys
- Get a new binary signed every time we change the signing keys.
How To Test
Standard installation should test that it's working. Invalid binaries are easily provided to test a negative cryptographic test.
User Experience
Substantially the same as current experience, but with a nice sense of security.
Dependencies
pesign will provide utilities for doing this which it doesn't have yet.
Contingency Plan
Contingency plan is current status quo.
Documentation
Not yet.