Add support for detached signatures

[tigrannajaryan]

The DownloadableFile currently allows downloading the file and also communicates the hash of the file to verify that the downloaded content matches the published content.

The verification that the published content is actually published by the authorized publisher is left out of the OpAMP spec. The assumption is that the Agent knows how to perform this operation. For example it is possible if the downloadable file is signed using GPG and the Agent has the public key for verify the signature and extract the original file.

However, another way GPG is often used is with detached signatures, where the signature is delivered separately from the original file content.

Do we want to enable support for detached signatures? This can be done by adding the signature to the DownloadableFile, e.g.:

message DownloadableFile {
    string download_url = 1;
    bytes content_hash = 2;
    bytes signature = 3; // new field to add.
}

[jpkrohling]

I would suggest having a standard naming for the files and signatures, so that the downloader could also attempt to automatically download the signature files from the same repository. While this wouldn't (at first) guard from a man-in-the-middle attack, it would help detect corrupted files. For instance:

http://example.com/config.yaml http://example.com/config.yaml.sha256asc

In the future, the client could also be configured to have a cert pinned, so that it knows which certs a server is supposed to be serving. While this doesn't 100% guarantee that there won't be a man-in-the-middle, it does make it extremely harder.

[tigrannajaryan]

I would suggest having a standard naming for the files and signatures, so that the downloader could also attempt to automatically download the signature files from the same repository.

I think this imposes unnecessary restrictions. I prefer that OpAMP does not mandate things that are not necessarily under its control. Instead OpAMP should be accommodating to existing arrangements (the file names for signatures may be already decided elsewhere).

While this wouldn't (at first) guard from a man-in-the-middle attack, it would help detect corrupted files.

To detect corrupt files we already have mandatory hash of the content (arguably may no longer be necessary if we add the signature, but perhaps can stay as a cheaper verification method).

The purpose of the signature is different: to prevent malicious Server from pushing malicious code into the Agent. The Agent does not trust the Server, we use zero-trust model and the Agent should verify the executable content via signature that cannot be signed by the Server.

I am not sure why you reference MITM in this context. We are still preventing malicious code execution even if the connection between the Agent and the Server is MITM-ed. Signature guarantees that we are guarded from MITM (in the sense that MITM is detectable and is not enough to result in malicious code execution).

In the future, the client could also be configured to have a cert pinned, so that it knows which certs a server is supposed to be serving.

I assume you refer to the code signing cert (not the connection cert). If that's what you mean then yes, this is partially implied in the spec, but I think it would be useful to explicitly tell in the Security section.

[jpkrohling]

Sorry, I'm still not up to speed with OpAMP, so, my comments here might be moot, but my point about man-in-the-middle was that the signatures for the binary could be obtained from the same repositories as the binaries themselves. Typically, this is a problem, as they should both come from different channels, as a man-in-the-middle would be able to provide a bogus binary and a matching signature for it, but using a cert pinning for the connection between the downloader and the server would make sure the connection is to be trusted. Having a signature from another channel reduces this risk (which is what you have already with the detached signatures).

[tigrannajaryan]

Typically, this is a problem, as they should both come from different channels, as a man-in-the-middle would be able to provide a bogus binary and a matching signature for it, but using a cert pinning for the connection between the downloader and the server would make sure the connection is to be trusted. Having a signature from another channel reduces this risk (which is what you have already with the detached signatures).

This is not a problem if you use code signing certificate pining on the party that does the verification, provided that the party the signs the binaries is independent from the party that controls the server where the downloads are published. MITM-ing is not going to make the bogus binary and bogus signature valid in that case. Again, for this to work the code signing server and the download server must be different and the download server under no circumstances should be allowed access to the code signing certificate's private key.

This is also precisely what OpAMP already recommends, it is not a new requirement. This issue merely says that signatures may be detached from the binaries (whether they are detached or makes no difference on the above paragraph I wrote), which is one of the possible ways to do signing (and which is the most common way people usually publish GPG-signed binaries the Linux world, whereas in Windows world the code-signed binaries typically carry the signature themselves).

Having a signature from another channel reduces this risk (which is what you have already with the detached signatures).

You are right that this adds another protection layer if both the download server and code signing server are compromised while the OpAMP server is not compromised. Adding signature as a field to OpAMP protocol achieves exactly this separation of channels.

[tigrannajaryan]

Just to make it clear if this was confusing: the OpAMP server, the download server and the code singing server should be 3 different servers for maximum security with our zero trust model (although they may also be the one and same server if security is not a concern and the corresponding attacks are understood and can be prevented by other means).