DaS-PC-MPChan
DaS-PC-MPChan copied to clipboard
Wulf2k
Check signature when auto-updating
Ok, this seems to be quite difficult: http://stackoverflow.com/questions/21754960/how-to-use-iclrstrongnamestrongnamesignatureverificationex-method-to-identify
An easier quick-fix for this would be for you to enable https on your server. Certificates for that are free nowadays via let's encrypt.
Apart from that we should probably just implement our own signing. Dotnet seems to have frameworks for that: https://msdn.microsoft.com/en-us/library/system.security.cryptography%28v=vs.110%29.aspx
Something like:
- Store the public key in the binary
- Add the encrypted hash of the binary to the update txt
- After download check that
hash of downloaded zip file = decrypted hash
Microsoft recommends against using strong names for security: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/strong-name-signing.md.
Having the hash of the binary downloaded from the web is counterproductive. Anybody replacing the EXE download via DNS hijack would just report the hash of their own EXE in the update check.
I know it can be difficult to get right so I'll do some serious research before doing anything. Getting it right the first time is more important than stuff with security holes, so nobody has false security.
Anybody replacing the EXE download via DNS hijack would just report the hash of their own EXE in the update check.
I wrote:
Add the encrypted hash of the binary to the update txt
They would need your private key to encrypt their changed hash.
I'll look into a free https cert as well. If that can be done securely for free, then awesome.
Probably would be good to do both though.
Small note:
After download check that hash of downloaded zip file = decrypted hash
It's of course a way better to do it the other way: (encrypt the downloaded zip hash and check if it matches with the crypted correct hash), so you may use asymetrical crypting methods...
It's of course a way better to do it the other way: (encrypt the downloaded zip hash and check if it matches with the crypted correct hash), so you may use asymetrical crypting methods...
You seem to have a misunderstand of how asymmetric cryptography works. The idea is:
hash => privatekey => encrypted_hash => publickey => hash
What has been encrypted with the private key can only be decrypted with the public key and vice versa.
If you encrypt the hash once with the private key and once with the public key, you will get different results.
Oh yeah of course ... Sorry I misunderstood the way you were doing it.
Le 10 juin 2016 à 13:53, Chronial [email protected] a écrit :
It's of course a way better to do it the other way: (encrypt the downloaded zip hash and check if it matches with the crypted correct hash), so you may use asymetrical crypting methods...
You seem to have a misunderstand of how asymmetric cryptography works. The idea is:
hash => privatekey => encrypted_hash => publickey => hash What has been encrypted with the private key can only be decrypted with the public key and vice versa.
If you encrypt the hash once with the private key and once with the public key, you will get different results.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
So I had a look at this and here are the options:
- Use binary signing with a self-signed signature. I struggle with this – while there is a way to extract the certificate from the binary, I didn't find an api that would verify that the signature in the binary.
- Use strong naming, and check that the updated binary has the same strong name public key as the current one. I found all APIs required to do this.
- Use a custom digital signature approach, as explained before. There are nice apis available to do this.
I personally prefer the custom approach. It feels less hacky and we have more control over it, and if we use a PKCS #1 signature with SHA-256, I am also very certain that it will be secure. Regarding security of strong names, I am feeling a little bit uneasy about the fact that ms recommends against it. But my research showed that while the implementation was sloppy before, it actually should be secure in .Net 4.5.
@Wulf2k What's your opinion on this?
Sorry for not responding sooner. I'm leaning towards (3) but haven't fully wrapped my head around all the encryption options.
I understand encryption/signing on a conceptual level but not at the implementation level. I'm currently ranking this as a slightly lower priority than the namecrash. Depending on how much time I have this weekend I might get into it after working through all of that, but figure we should definitely be doing something about update security before the end of the month. (aka, the weekend after next weekend, but sounding slightly more professional than my usual "get to it on the weekend" stance.)