Add image download signatures for authenticity checks

[flavio-fernandes]

SHA256 checksum for the download link

Is your feature request related to a problem? Please describe:

It feels a little too late to be checking SHA256 on the image file

Describe the solution you'd like:

Co-located with the download link, it would be awesome to have the sha256 for the .7z file, so we are certain that it has not been tampered with even before we uncompress it.

Describe alternatives you've considered:

A good reference on what I'm proposing can be seen on the download links for Raspbian or Ubuntu, under verify your download.

Additional context

By having the checksum co-located with the link, we can make it harder for ill intended people to tamper with the images.

Vote for this feature on FeatHub: https://feathub.com/MichaIng/DietPi/

[MichaIng]

@flavio-fernandes
Many thanks for your request.

Hmm it is very common to include hashes/checksums into the archive, to the final image, which must be original and not corrupted by failure download AND faulty unpacking. However of course if the archive itself is corrupt already, one could skip unpacking in the first place. Not sure how to do best, place a hash file for a specific algorithm into our download directory, file meaningful file ending, to be easily and automated compared, or put the same style hash file with MD5+SHA1+SHA256 contained, like the one in the archive, into the download dir, with archive file name + ".hash" file ending?

[flavio-fernandes]

@flavio-fernandes
Many thanks for your request.

Hmm it is very common to include hashes/checksums into the archive, to the final image, which must be original and not corrupted by failure download AND faulty unpacking. However of course if the archive itself is corrupt already, one could skip unpacking in the first place. Not sure how to do best, place a hash file for a specific algorithm into our download directory, file meaningful file ending, to be easily and automated compared, or put the same style hash file with MD5+SHA1+SHA256 contained, like the one in the archive, into the download dir, with archive file name + ".hash" file ending?

@MichaIng Thanks for following up!

I think that the checksum as it is now is fine for detecting issues with corruption during download.

The category I'm talking about here is more geared towards some ill-intended person deliberately messing with the compressed file and carefully rebuilding the image. So, maybe it is best to separate these two cases.

So, to make the hacker's life harder, I would think that having a checksum published right next to the compressed file is a good thing. Different sites do it differently, but at the end of the day -- assuming the website is not compromised -- having a checksum to compare against the downloaded file would be awesome.

-- flaviof

[MirisWisdom]

Love those kinds of threads - hope it's fine to join in!

Just a thought: hashes are designed for proving integrity, but aren't inherently reliable for proving authenticity. If a website is compromised to the point of altering the download, then nothing should stop an attacker from altering the hash file itself.

Signatures (a la GPG) would be more suitable for this sort of scenario, since a GPG signature aims to prove authenticity (and implicitly, integrity). Mind you, authenticity flies out the window if the GPG key is stolen, though the practical risk of that depends on your adversary's capabilities.

---

As an example: the Hyper-V images are published with a GPG signature for their respective archives. Additionally, the commits representing the releases are also signed with GPG:

If GitHub were to be compromised, the attacker would also need to compromise my own key to impersonate and release tampered releases on my behalf.

[MichaIng]

@yumiris

hope it's fine to join in!

More than welcome!

hashes are designed for proving integrity, but aren't inherently reliable for proving authenticity

Indeed, these hashes placed beside or inside the download are ONLY meant to check for corruptions through download or unpacking, before flashing it.

The category I'm talking about here is more geared towards some ill-intended person deliberately messing with the compressed file and carefully rebuilding the image. So, maybe it is best to separate these two cases.

This is indeed another request (though we can fulfil both together), since placing hashes/checksums onto the same server where the download is placed, cannot guarantee authenticity. An attacker can modify both, the file and the hashes, without much more effort. Note that due to HTTPS, in theory it is impossible that you get a file from a wrong source, e.g. an attacker/MITM cheats you out a faulity download, or presents you a fake website, when using the official domain.

So we basically talk about us creating a key to sign all downloads and enable users to verify all downloads against our public key. Luckily this is on the roadmap anyway since I plan to setup a DietPi APT repository, which then should be fully signed in the first place. The same key pair can then be used for all other downloads outside of the repo as well. Should be easy then to not only flash the signatures besides the downloads but also add them to the website next/below the download link.

[muxnulljack]

Just wanted to let you know that I was interested in deploying your project on my Pi as an alternative to Raspbian because it's much better suited for my use-case, but I will not be using it because you do not offer signed images or shas.

So we basically talk about us creating a key to sign all downloads and enable users to verify all downloads against our public key. Luckily this is on the roadmap anyway since I plan to setup a DietPi APT repository, which then should be fully signed in the first place. The same key pair can then be used for all other downloads outside of the repo as well. Should be easy then to not only flash the signatures besides the downloads but also add them to the website next/below the download link.

+1, you should do all of this.

[Joulinar]

Well feel free to download and install Raspberry OS lite and use DietPi PREP script to transform it into DietPi. Than you don't need to use DietPi images and will get same result.

[muxnulljack]

@Joulinar or I can go use another distribution with signed shasums and not bother with a workaround, which is exactly what I'm going to do? Is there any reason not to do what's described above?

[Joulinar]

Sorry I don't won't force you to use DietPi. Feel free to use whatever you want. I just offered a way to reach a goal on short notice and not wait on some feature update. DietPi is developed and maintained by a single person. Therefore not everything could be done right away. And others might take some more time to be implemented. But as I said, you are free to use whatever you want.

[MichaIng]

@muxnulljack
The download archives contain MD5 checksum, SHA1 and SHA256 hashes for the contained image, which should in combination with strict HTTPS serve for both, integrity and authenticity.

The topic here is only to additionally place hashes onto the download pages, which is more a convenience topic instead of adding any security... Yeah okay you can additionally check the archive before extracting it instead of the contained image only.

As this is hence minor, we simply didn't find the time and mood to add all hashes to the website, especially since this means that those need to be updated on every new image upload, which practically requires some automation. But as the website goes through some rework anyway, I think we'll do that soon.

[ghost]

@Joulinar

Well feel free to download and install Raspberry OS lite and use DietPi PREP script to transform it into DietPi. Than you don't >need to use DietPi images and will get same result.

Wheres The "DietPi PREP script" ?

[ravenclaw900]

You can download it at https://raw.githubusercontent.com/MichaIng/DietPi/master/PREP_SYSTEM_FOR_DIETPI.sh.

[ghost]

@ravenclaw900 Thanks Appreciate it.

[Joulinar]

Have a look to our online docs for a guide how to use the script https://dietpi.com/docs/hardware/#make-your-own-distribution

[PaulCodeFun]

Can not believe that there is still no way to check for authenticity. If I put a device in my home wifi I need this very basic feature.

[MirisWisdom]

Can not believe that there is still no way to check for authenticity. If I put a device in my home wifi I need this very basic feature.

@PaulCodeFun What scenario do you worry would threaten the authenticity of the image? (e.g. the download connection being tampered with? MichaIng account being breached into?)

[MichaIng]

I'll start working on this next week. Needed to read into best practice about how to integrate signing downloads with CI/CD, where/how to store the key etc. If we do this, then it should be a real security advantage above HTTPS and not just give the illusion of more security. If someone who gains root access on our server to manipulate downloads, could sign them in the same turn, then nothing was won.

[PaulCodeFun]

First of all, thank you guys for your work. I still did try out dietpi today and its awesome.

Using a digital signature makes me trust the executable a little more. Its proof to me that I downloaded the right thing from the source I meant to download it from and wasnt the victim of some DNS-spoofing attack for example. And also with a signature you stand for your product with your name. If it does shady stuff and has your signature on it.... that doesn't look too good ;D

[MichaIng]

DNS spoofing should be ruled out by HTTPS. Our domain is in the preload list and has HSTS set. So as long as you use a non ancient browser, which reads the HSTS preload list or at least stores the HSTS headers when visiting the website once, no one can serve downloads from elsewhere via our domain. Also DNSSEC is enabled. Of course no system is 100% safe. Someone could hack my DNS provider account (despite 2FA), bend the records to a malicious server, remove the CAA records, and create a new certificate.

With public website, forum, GitHub account and email address, practically it doesn't matter whether I sign a single download from our website or not, it is easy to make any shady stuff public on all our channels, which is good, and naturally we are responsible for all downloads provided via our server. But I know what you mean.

I do fully agree that signed downloads make sense, it just takes time for me (which is limited) to read into those topics and best practices properly, and when doing a security relevant step, I want to do it right and well founded.

[PaulCodeFun]

I guess serving me a malicious version from a different source is a little more difficult than I thought. Unless its a state actor that wants in ;) Thanks for the explanation.

[MichaIng]

Yes, in times where HTTPS was more an exception than a standard, signature checks were at least more important. Nowadays with modern webservers and browsers, HTTPS implies authenticity to a quite high degree. But it never hurts to further raise the bar.

[MichaIng]

SHA256 added, a PR for adding GPG signatures is up: MichaIng/DietPi#6623

Our public keyring has been updated on GitHub, to contain the new signing key(s): https://github.com/MichaIng.gpg

I'm open for suggestion how to add them best to our download page. Current idea:

Download Image: ⬇️ Download (SHA256) (Signature)

I am just thinking now: Any reason to not use SHA512 hashes?

[ravenclaw900]

Counterpoint: is there any reason to use SHA-512? SHA-256 and SHA-512 are currently both cryptographically secure, and I haven't seen any projects that solely offer SHA-512. Using some big Linux distributions as examples: Debian offers both, Ubuntu offers SHA-256, Fedora offers SHA-256, Arch offers SHA-256, Linux Mint offers SHA-256, openSUSE offers SHA-256, etc. I think it makes sense in this case to be similar to everyone else, especially since the projects that have been going for a while probably know what they're doing.

[MichaIng]

Using the stronger hash at least does not hurt, does it? I could imagine that most other projects started to use SHA256 a long time ago, when SHA1 was officially broken, and just have no good reason to switch to SHA512, as both are indeed seen as secure. But when newly starting to provide hashes, one must ask why not to use the strongest hash in the first place. The only argument against it would be if it was e.g. not widely supported yet, or if the additional size somehow causes problems. But I do not see any of this being true.

[MirisWisdom]

Using the stronger hash at least does not hurt, does it? I could imagine that most other projects started to use SHA256 a long time ago, when SHA1 was officially broken, and just have no good reason to switch to SHA512, as both are indeed seen as secure. But when newly starting to provide hashes, one must ask why not to use the strongest hash in the first place. The only argument against it would be if it was e.g. not widely supported yet, or if the additional size somehow causes problems. But I do not see any of this being true.

It is generally more computationally intensive. Imagine the millions of devices checking the SHA-512 of the latest DietPi image - all of that electricity, all of that emission. The global calamity will soon be upon us, and DietPi will be at the forefront of raising the global temperatures.

On a slightly more serious note, it's very much a case of practicality. As it stands, SHA-256 & SHA-512 are both practically very secure, with the former being more efficient to calculate. This makes SHA-512 practically overkill. What are the benchmarks of 512 on low-end devices such as the Pi?

Of course, mathematically speaking, SHA-512 is the more secure option; however, considering the surrounding security (HTTPS, GPG, etc.), SHA-256 shouldn't be a problem.

Nevertheless, you could always go with 512 (or both) if you absolutely wanted to -- it ultimately depends on whether you prioritise mathematically purer security or practical security. There's nothing wrong with either or, depending on your threat model :)

[ravenclaw900]

I agree with all of @MirisWisdom's points above. It all depends on your threat model. With all the extra security being added around the DietPi images, using the "weaker" (but still completely cryptographically secure) hash shouldn't be a problem. Even the dashboard uses a comparatively "weak" hash (unsalted SHA-512) for storing passwords when compared to bcrypt or Argon2; this is because it generally runs on local networks and there's no singular password database that anyone would be able to get access to.

Just to give a benchmark for context from my RPI Zero:

dietpi@rpi0w:~$ time sha256sum 800M.bin
2df3affbd412fa3620fa014f41b06459e2f55e4f4a419ab154cd349c78a25749  800M.bin

real	0m43.237s
user	0m35.926s
sys	0m5.034s
dietpi@rpi0w:~$ time sha512sum 800M.bin
bab0ba77a17bd7e4838f7dec0fba29d81d99905ad41e39ff597b52ef2a8561f3d7e8b6b9d1e33a4a0315223983556cae940171a2aa94150f00f8cde7d09a3afb  800M.bin

real	6m43.067s
user	6m31.991s
sys	0m6.239s

So there's also a pretty big difference in efficiency. It's probably true that many hash calculations aren't going to be done on these low-end devices (our CI maybe?), but it works as a good demonstration.

All that said, when in doubt, I don't think it would hurt to do both. Sadly, many users probably aren't even going to bother to check the hashes, so what we're talking about only applies to the 10% that will. Those 10% will probably know the difference in security between SHA-256 and SHA-512, and will be able to evaluate what is best for them.

[MichaIng]

Ah, I was not aware that generating those hashes (hence also verifying them) can take so much time. That is a good argument to keep SHA256 for now. For additional security, the signatures are better suited anyway. AFAIK gpg uses SHA256 as well by default for the detached signature while it supports SHA512, between and below as well.

[MichaIng]

PR up to add hashes and signatures to our download page: #291