But my point is that more teams needed access to signing keys because some of those teams were dedicated only to licensing issues. If they didn't need signing keys, those keys wouldn't have been compromised.
I suppose I can break it down another way.
Complexity introduces vulnerabilities.
Some complexity is necessary for the software to accomplish what the customer wants.
Some complexity is arguably necessary to protect the interests of the vendor. This is arguable because it varies between open source and proprietary software.
To me, it is upsetting when the code to protect the vendor's interests is where a critical security vulnerability exists. I don't think this is a controversial statement.
> But my point is that more teams needed access to signing keys because some of those teams were dedicated only to licensing issues. If they didn't need signing keys, those keys wouldn't have been compromised.
Cryptographically signed binaries are not used to manage licensing issues, they are used to make sure that no-one intercepts your download and replaces it with a malicious binary. It is absolutely essential that computer programs are signed or delivered through a secure connection.
Losing your signing keys will make the entire system jeopardized and new keys must be generated and securely transmitted (this is hard).
> To me, it is upsetting when the code to protect the vendor's interests is where a critical security vulnerability exists.
Yes, that would be upsetting if it were true. But it isn't. The whole system is in place to protect you, the customer.
The issue was that Microsoft left behind the ability to sign code with a Microsoft certificate by mistake.
The entire reason the attackers could use the certificate was because Microsoft left behind that functionality in the suite of software that allows enterprise customers to license their instances of Terminal Servers.
I am not railing against cryptographic signing as a concept -- what happened was Microsoft played fast and loose with their certificate chain in order to provide their customers with a way to prove that they had paid for software.
The certificate chain could have been a lot cleaner if that licensing bit wasn't necessary.
Well... No, it'd be like if ubuntu required you to sign up to corporate licensing in order to use Ubuntu. Then handing out misconfigured keys to corporate customers which could also be used to sign repos as an unfortunate side effect.
This is why Linux kernel source code is also signed cryptographically and so is their git repository (all tags are signed). They also employ a PGP-style web of trust instead of an SSL-style centralized certificate management.
The chances of someone slipping in a backdoor in kernel releases are very slim.
Yes but some one can break into whatever server is hosting the source and add a backdoor withought anyone noticing for quite a while, do you go through all the code you compile? Can't think of any specific examples right now but i remember this happening a few times
You can rather easily see the deltas. It's not perfect, but it's at least possible. That's another line of defense Windows users lack (and, usually, don't care about)
