[OpenWrt-Devel] RFI: OpenWRT Upgrade System; ENH,SEC suggestions

[Wes Turner]

Thanks for clarifying.

How can a user add a usign EdDSA ed25519 key for e.g. a self-hosted package
set?

https://openwrt.org/docs/guide-user/security/release_signatures links to
https://openwrt.org/docs/guide-user/security/keygen which describes how to
generate release signing keys with GPG and usign.

https://git.openwrt.org/project/usign.git

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.
https://w3c-dvcg.github.io/ld-signatures/

It could just parse
https://downloads.openwrt.org/releases/ , but would that require semver to
sort and identify release candidates.

Ideally, it would link directly to the latest firmware download URLs for
the given target architecture.

YAML-LD that may be over-normalized:

releases:
  - version:
    security_release:
    archs:
    - architecture: x86
      models:
        - name: model105
          sysupgrade_url:
          firmware_url:
proof:
   type: Ed25519Signature2018
   proofPurpose: assertionMethod
   created: "2019-08-23T20:21:34Z"
   verificationMethod: "did:example:123456#key1"
    domain: "example.org"
    jws: "eyJ0eXAiOiJK...gFWFOEjXk"

It could be run as a periodic cron task that logs to syslog and caches to
/tmp for display with LuCI.

Config options:

updater.enabled: bool (True/False?)
updater.time_between_checks: cron ("24h"?)
updater.notify_webhook: URL ("")
updater.notify_email: email address ("")
updater.consider_nightlies: bool


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.

People that are already considering testing nightlies may not be as likely
to be as out of date as folks with regular releases installed.

Thanks again for clarifying that there are ed25519 package signing public
keys baked into the firmware releases.

On Sat, Feb 1, 2020, 12:25 PM Jo-Philipp Wich <jo at mein.io> wrote:

> Hi Wes,
>
> > It's definitely an issue that the sha256 checksum check was broken.
> > But, can someone explain why a person who is MITM'ing ipk downloads
> > would change the package and not the checksum?
>
> the repository index files containing the SHA256 checksums are signed using
> usign, which is a derivate of the ECDSA based OpenBSD signify utility. The
> public ECDSA key is built into the firmware image and used to check the
> signify-signed repository index. Forging the index itself is not possible
> without possession of the secret key.
>
> > Are there GPG signatures of the package checksums signed with a key
> > that ships with the release?
>
> There are usign (signify) ECDSA ones.
>
> > Are package repos downloaded over HTTPS? Is there a CA bundle in the
> > release with which repo x.509 certs are validated?
>
> No since so far the required storage footprint for a functional SSL stack
> (library plus certs etc.) exceeded the available space on a large fraction
> of
> supported models.
>
> > The OpenWRT firmware couldn't access https sites without installing
> > multiple packages first. Then they had me install all the root certs
> > over an unencrypted connection. The opkg repos and install files are
> > all downloaded over http.
>
> Yes but they are (assuming fixed SHA256 issue) verified using preshared EC
> keys.
>
> 1) opkg downloads Packages.gz and Packages.sig, if either of these fail,
>    the repo is ignored
> 2) opkg verifies that the uncompressed contents of Packages.gz match the
>    Packages.sig signature using EC keys built into the image, if the
> signature
>    cannot be verified, the downloaded lists are deleted and the repo is
>    ignored
> 3) opkg translates package names to actual file names using the verified
>    package index information and downloads these .ipk files
> 4) opkg verifies that the size of the downloaded .ipk files match the size
>    mentioned in the verified package index information, if not the
> downloaded
>    package is deleted and the installation aborted
> 5) opkg computes the sha256 sums of the downloaded .ipk files and verifies
>    that they match the ones specified in the verified package index
>    information, if not the downloaded package is deleted and the
> installation
>    aborted [this step has been fixed]
> 6) opkg unpacks and installs the .ipk
>
> > With full seriousness, I really hope nobody expects operational
> > security using these routers.
>
> Depends on the thread model of course but without an encrypted transport
> channel, there'll be no confidentiality about the packages being installed,
> but [assuming a fixed opkg] it is not possible to modify the contents
> in-flight.
>
> > Side note: something like these would be great to have; IDK which
> > repos are appropriate for possible new issues to be owned by someone
> > who knows what is going on:
> >
> > ENH: CDN for package repos and latest version file
>
> We're in the process of testing cdn.openwrt.org which has been sponsored
> by
> KeyCDN but so far the results are mixed and we're having consistency
> issues yet.
>
> > ENH,SEC: firmware update check script
>
> Yeah, that would be good.
>
> > ENH,SEC: send an email when the firmware is out of date
>
> I don't see how this can be done reliably as most mails sent directly from
> dynamic dialup IPs are classified spam nowadays. Any other solution would
> require embedding secrets in the firmware images.
>
> > ENH,SEC: luci: display firmware update check result and link to latest
> firmware
>
> Yes, that would be useful.
>
> > ENH,SEC: add package repo (and firmware?) signing key to keyring
>
> They are.
>
> > ENH,SEC: include ca-certificates and/or openwrt-certificates in builds?
>
> That wasn't feasible so far due to the 4MB flash support target.
>
> HTH,
> Jo
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200201/31483c35/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel