No, I'm afraid we still haven't implemented such a scheme yet.
Regarding encryption & authentication, if secure boot is enabled then you don't necessarily need authentication as the signature verification will cover this.
Something like AES-CBC should be suitable. Use a randomly generated IV and store it somehow (in a separate file or as a header) and have the device download the encrypted image and decrypt using a key stored in the existing firmware.
Note that if already using HTTPS then an equivalent scheme is to hide the firmware update behind a long randomly generated directory name, provided the firmware never logs the request URL and the server is configured to disable directory listings. (An attacker who can access an existing firmware will be able to find out this directory name, but they would also be able to find out the stored key for a pre-encrypted image.)
The other option is to configure the HTTPS server to verify each specific device somehow before serving the firmware. This has the advantage that if an attacker recovers a key for one device, it can't be reused on other devices - and you can blacklist a compromised device. This is more difficult to implement on the server side, though - the other schemes can be done with any generic HTTPS static fileserver.