<div dir="auto">Thanks for clarifying.<div dir="auto"><br></div><div dir="auto">How can a user add a usign EdDSA ed25519 key for e.g. a self-hosted package set?</div><div dir="auto"><br></div><div dir="auto"><a href="https://openwrt.org/docs/guide-user/security/release_signatures">https://openwrt.org/docs/guide-user/security/release_signatures</a> links to <a href="https://openwrt.org/docs/guide-user/security/keygen">https://openwrt.org/docs/guide-user/security/keygen</a> which describes how to generate release signing keys with GPG and usign.<br></div><div dir="auto"><br></div><div dir="auto"><a href="https://git.openwrt.org/project/usign.git">https://git.openwrt.org/project/usign.git</a><br></div><div dir="auto"><br></div><div dir="auto">I would imagine that a firmware update check script would download a signed JSON file; possibly with an ed25519 ld-signatures signature within the record. You just just pop the proof key from the JSON before [canonicalizing/sorting keys and] checking the hash and signature.</div><div dir="auto"><a href="https://w3c-dvcg.github.io/ld-signatures/">https://w3c-dvcg.github.io/ld-signatures/</a><br></div><div dir="auto"><br></div><div dir="auto">It could just parse </div><div dir="auto"><a href="https://downloads.openwrt.org/releases/">https://downloads.openwrt.org/releases/</a> , but would that require semver to sort and identify release candidates.<br></div><div dir="auto"><br></div><div dir="auto">Ideally, it would link directly to the latest firmware download URLs for the given target architecture.</div><div dir="auto"><br></div><div dir="auto">YAML-LD that may be over-normalized:</div><div dir="auto"><br></div><div dir="auto">releases:</div><div dir="auto"> - version:</div><div dir="auto"> security_release:</div><div dir="auto"> archs:</div><div dir="auto"> - architecture: x86</div><div dir="auto"> models:</div><div dir="auto"> - name: model105</div><div dir="auto"> sysupgrade_url:</div><div dir="auto"> firmware_url:</div><div dir="auto">proof:</div><div dir="auto"> type: Ed25519Signature2018</div><div dir="auto"> proofPurpose: assertionMethod</div><div dir="auto"> created: "2019-08-23T20:21:34Z"</div><div dir="auto"> verificationMethod: "did:example:123456#key1"</div><div dir="auto"> domain: "<a href="http://example.org">example.org</a>"</div><div dir="auto"> jws: "eyJ0eXAiOiJK...gFWFOEjXk"</div><div dir="auto"><br></div><div dir="auto">It could be run as a periodic cron task that logs to syslog and caches to /tmp for display with LuCI.</div><div dir="auto"><br></div><div dir="auto">Config options:</div><div dir="auto"><br></div><div dir="auto">updater.enabled: bool (True/False?)</div><div dir="auto">updater.time_between_checks: cron ("24h"?)</div><div dir="auto">updater.notify_webhook: URL ("")</div><div dir="auto">updater.notify_email: email address ("")</div><div dir="auto">updater.consider_nightlies: bool</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">IDK how much trouble it would be to generate such (ed25519 ld-signatures JSON-LD) release manifests as a new step in the release workflow? Or how to return target-specific firmware URLs for the LuCI notification.</div><div dir="auto"><br></div>People that are already considering testing nightlies may not be as likely to be as out of date as folks with regular releases installed.<div dir="auto"><br></div><div dir="auto">Thanks again for clarifying that there are ed25519 package signing public keys baked into the firmware releases.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sat, Feb 1, 2020, 12:25 PM Jo-Philipp Wich <<a href="mailto:jo@mein.io">jo@mein.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Wes,<br>
<br>
> It's definitely an issue that the sha256 checksum check was broken.<br>
> But, can someone explain why a person who is MITM'ing ipk downloads<br>
> would change the package and not the checksum?<br>
<br>
the repository index files containing the SHA256 checksums are signed using<br>
usign, which is a derivate of the ECDSA based OpenBSD signify utility. The<br>
public ECDSA key is built into the firmware image and used to check the<br>
signify-signed repository index. Forging the index itself is not possible<br>
without possession of the secret key.<br>
<br>
> Are there GPG signatures of the package checksums signed with a key<br>
> that ships with the release?<br>
<br>
There are usign (signify) ECDSA ones.<br>
<br>
> Are package repos downloaded over HTTPS? Is there a CA bundle in the<br>
> release with which repo x.509 certs are validated?<br>
<br>
No since so far the required storage footprint for a functional SSL stack<br>
(library plus certs etc.) exceeded the available space on a large fraction of<br>
supported models.<br>
<br>
> The OpenWRT firmware couldn't access https sites without installing<br>
> multiple packages first. Then they had me install all the root certs<br>
> over an unencrypted connection. The opkg repos and install files are<br>
> all downloaded over http.<br>
<br>
Yes but they are (assuming fixed SHA256 issue) verified using preshared EC keys.<br>
<br>
1) opkg downloads Packages.gz and Packages.sig, if either of these fail,<br>
the repo is ignored<br>
2) opkg verifies that the uncompressed contents of Packages.gz match the<br>
Packages.sig signature using EC keys built into the image, if the signature<br>
cannot be verified, the downloaded lists are deleted and the repo is<br>
ignored<br>
3) opkg translates package names to actual file names using the verified<br>
package index information and downloads these .ipk files<br>
4) opkg verifies that the size of the downloaded .ipk files match the size<br>
mentioned in the verified package index information, if not the downloaded<br>
package is deleted and the installation aborted<br>
5) opkg computes the sha256 sums of the downloaded .ipk files and verifies<br>
that they match the ones specified in the verified package index<br>
information, if not the downloaded package is deleted and the installation<br>
aborted [this step has been fixed]<br>
6) opkg unpacks and installs the .ipk<br>
<br>
> With full seriousness, I really hope nobody expects operational<br>
> security using these routers.<br>
<br>
Depends on the thread model of course but without an encrypted transport<br>
channel, there'll be no confidentiality about the packages being installed,<br>
but [assuming a fixed opkg] it is not possible to modify the contents in-flight.<br>
<br>
> Side note: something like these would be great to have; IDK which<br>
> repos are appropriate for possible new issues to be owned by someone<br>
> who knows what is going on:<br>
> <br>
> ENH: CDN for package repos and latest version file<br>
<br>
We're in the process of testing <a href="http://cdn.openwrt.org" rel="noreferrer noreferrer" target="_blank">cdn.openwrt.org</a> which has been sponsored by<br>
KeyCDN but so far the results are mixed and we're having consistency issues yet.<br>
<br>
> ENH,SEC: firmware update check script<br>
<br>
Yeah, that would be good.<br>
<br>
> ENH,SEC: send an email when the firmware is out of date<br>
<br>
I don't see how this can be done reliably as most mails sent directly from<br>
dynamic dialup IPs are classified spam nowadays. Any other solution would<br>
require embedding secrets in the firmware images.<br>
<br>
> ENH,SEC: luci: display firmware update check result and link to latest firmware<br>
<br>
Yes, that would be useful.<br>
<br>
> ENH,SEC: add package repo (and firmware?) signing key to keyring<br>
<br>
They are.<br>
<br>
> ENH,SEC: include ca-certificates and/or openwrt-certificates in builds?<br>
<br>
That wasn't feasible so far due to the 4MB flash support target.<br>
<br>
HTH,<br>
Jo<br>
<br>
_______________________________________________<br>
openwrt-devel mailing list<br>
<a href="mailto:openwrt-devel@lists.openwrt.org" target="_blank" rel="noreferrer">openwrt-devel@lists.openwrt.org</a><br>
<a href="https://lists.openwrt.org/mailman/listinfo/openwrt-devel" rel="noreferrer noreferrer" target="_blank">https://lists.openwrt.org/mailman/listinfo/openwrt-devel</a><br>
</blockquote></div></div></div>