Commit 6288c0c8 authored by Denis Pynkin's avatar Denis Pynkin

system-updates-and-rollback: add info about ed25519 signature

Describe the usage of ed25519 signatures.
Signed-off-by: default avatarDenis Pynkin <denis.pynkin@collabora.com>
parent b9958808
......@@ -334,7 +334,7 @@ is first stored in a temporary directory, validated and only then it becomes par
of the local OSTree repository before the real upgrade process starts by rebooting
in the new deployment.
Metadata such as GPG signatures can be attached to each `commit` to validate it,
Metadata such as EdDSA or GPG signatures can be attached to each `commit` to validate it,
ensuring it is appropriate for the current system and it has not been corrupted
or tampered. The update process must be interrupted at any point during the update
process should any check yield an invalid result; the [atomic upgrades mechanism
......@@ -438,7 +438,7 @@ OSTree commit will produce identical results on the devices.
### OSTree security
OSTree is a distribution method. It can secure the downloading of the update by
verifying that it is properly signed using public key cryptography (GPG).
verifying that it is properly signed using public key cryptography (EdDSA or GPG).
It is largely orthogonal to verified boot, that is ensuring that only signed data
is executed by the system from the bootloader, to the kernel and
userspace.
......@@ -490,20 +490,56 @@ server-provided signature without using any other mechanism, but unlike IMA and
#### Verified updates
Once a verified system is running, an OStree update can be triggered.
On the server, OSTree commits can be signed using GPG. GPG ensures that the
commit was not modified, damaged, or corrupted.
This occurs via the `ostree gpg-sign` command line.
Apertis is using [ed25519](https://ed25519.cr.yp.to/) variant of EdDSA signature.
Ed25519 ensures that the commit was not modified, damaged, or corrupted.
On the client, GPG is also used to ensure that the commit comes from a trusted
On the server, OSTree commits must be signed using ed25519 secret key.
This occurs via the `ostree sign --sign-type=ed25519 <COMMIT_ID>` command line.
The secret key could be provided via additional CLI parameter or file by
using option `--keys-file=<path_to_file>`.
Ostree expect what secret key consists of 64 bytes (32b seed + 32b public) encoded
with base64 format. The ed25519 secret and public parts could be generated by
numerous utilities including `openssl`, for instance:
```
openssl genpkey -algorithm ed25519 -outform PEM -out ed25519.pem
```
Since ostree is not capable to use PEM format directly, it is needed to [extract the
secret and public keys](http://openssl.6102.n7.nabble.com/ed25519-key-generation-td73907.html)
from pem file, for example:
```
PUBLIC="$(openssl pkey -outform DER -pubout -in ${PEMFILE} | tail -c 32 | base64)"
SEED="$(openssl pkey -outform DER -in ${PEMFILE} | tail -c 32 | base64)"
```
As mentioned above, the secret key is concatenation of SEED and PUBLIC parts:
```
SECRET="$(echo ${SEED}${PUBLIC} | base64 -d | base64 -w 0)"
```
On the client, ed25519 is also used to ensure that the commit comes from a trusted
provider since updates could be acquired through different methods like OTA over
a network connection, offline updates on plug-in mass storage devices,
or even mesh-based distribution mechanism. OSTree searches for keyring files in
`/usr/share/ostree/trusted.gpg.d`. Any public key in a keyring file in that
directory will be trusted by the client. No private keys should be present in
this directory.
or even mesh-based distribution mechanism.
To enable the signature check, repository on the client must be configured by
adding option `sign-verify=true` into the `core` or per-remote section, for instance:
```
ostree config set 'remote "origin".sign-verify' "true"
```
OSTree searches for files with valid public signatures in directories
`/usr/share/ostree/trusted.ed25519.d` and `/etc/ostree/trusted.ed25519.d`.
Any public key in a file in these directories will be trusted by the client.
Each file may contain multiple keys, one base64-encoded public key per string.
No private keys should be present in these directories.
In addition it is possible to provide the trusted public key per-remote by adding
into remote's configuration path to the file with trusted public keys (via
`verification-file` option) or even single key itself (via `verification-key`).
In the OSTree configuration, the default is to require commits to be signed.
However, if no keyring is available, no commit can be trusted.
However, if no public key is available, no any commit can be trusted.
#### Securing OSTree updates download
......@@ -557,8 +593,8 @@ device class, depending on the specific use-case.
#### Security concerns for offline updates over external media
OSTree static deltas can provide the GPG signature for the contained commit
as inlined metadata to check if the file is provided by a valid provider and
OSTree static deltas includes the detached metadata with signature for the
contained commit to check if the commit is provided by a valid provider and
its integrity.
The signed commit is unpacked to a temporary directory and verified by OSTree
......@@ -579,10 +615,8 @@ device that presents different data during the first and second read of
a single file – passing the signature test, then presenting a different
image for decompression.
Care will be taken during the installation to only read the contents of
the mass storage device once, performing verification and decompression
in a single pass or re-checking contents once they have been unpacked on
the main storage.
The content of the update file is extracted into the temporary directory
and the signature is checked for the extracted commit tree.
### Error handling
......@@ -590,6 +624,11 @@ If for any reason the update process fails to complete, the update will
be blacklisted to avoid re-attempting it. Another update won't be
automatically attempted until a newer update is made available.
The only exception from this rule is failure due incorrect signature check.
The commit could be re-signed with the key not known for the client at
this moment, and as soon as client acquire the new public key blacklist
mechanism shouldn't prevent the update.
It is possible that an update is successfully installed yet fail to
boot, resulting in a rollback. In the event of a rollback the update
manager must detect that the new update has not been correctly
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment