Slashdot Mirror
Microsoft Warns Of Two Apps That Installed Root Certificates Then Leaked the Private Keys (zdnet.com)
Catalin Cimpanu, reporting for ZDNet: Microsoft has issued a security advisory this week warning that two applications accidentally installed two root certificates on users' computers, and then leaked the private keys for all. The software developer's mistake means that malicious third-parties can extract the private keys from the two applications and use them to issue forged certificates to spoof legitimate websites and software publishers for years to come.
The two applications are HeadSetup and HeadSetup Pro, both developed by German audio hardware company Sennheiser. The software is used to set up and manage softphones -- software apps for making telephone calls via the Internet and a computer, without needing an actual physical telephone. The issue with the two HeadSetup apps came to light earlier this year when German cyber-security firm Secorvo found that versions 7.3, 7.4, and 8.0 installed two root Certification Authority (CA) certificates into the Windows Trusted Root Certificate Store of users' computers but also included the private keys for all in the SennComCCKey.pem file.
The two applications are HeadSetup and HeadSetup Pro, both developed by German audio hardware company Sennheiser. The software is used to set up and manage softphones -- software apps for making telephone calls via the Internet and a computer, without needing an actual physical telephone. The issue with the two HeadSetup apps came to light earlier this year when German cyber-security firm Secorvo found that versions 7.3, 7.4, and 8.0 installed two root Certification Authority (CA) certificates into the Windows Trusted Root Certificate Store of users' computers but also included the private keys for all in the SennComCCKey.pem file.
Looks like the opt-out option is to leave the page...
This makes me wonder if this violates the GDPR's spirit.
It violates both the spirit, and the law. (According to law.stackexchange.com).
You need to read up on PKI.
ANYONE can create a "root CA". If they then convince some user, browser vendor or OS vendor to install that "root CA" (PEM file including the root CA public key) on their systems, then any system or intermediate certificate that is signed with the private key of the root CA will then be trusted by that system.
When some entity wants to issue a new "root CA" they create the "root CA" keys, one of which is "public" that they give away to anyone who wants to trust that "root CA" and the other key is the "private key" for the root CA. THIS "private key" must be kept secret!!!!!
In the early days the suggested practice was to build a standalone system that could create the keys (Any linux box can do it: A Raspberry Pi is perfectly capable.) and then create the keys for the root CA. The export the files for the root CA including the public key, but NOT the private key unless it's to copy it to a backup storage device. THEN take the "standalone system" and ALL copies of the "private key" and turn off the power and store in a vault like a safety deposit box or some other airgapped, extremely secure system.
Then when a vendor asks for an intermediate or system certificate to be signed by the "root CA", the vendor cert would be copied to an offline storage device, taken to the vault, and only then would the system with the private key be turned on, just long enough to sign the vendor cert and copy the signed output to the offline storage. The ONLY thing taken out of the vault would be the signed vendor cert and the private key would never leave the vault. Then the vendor could install their signed vendor cert on their webserver: Since everyone knows the public key for the root CA they can verify the signature of the vendor cert since the public key can decrypt what was encrypted with the root CA private key.
As long as the "private key" for the CA remains secret, then the owner of that key is the ONLY entity that can sign the customer's certs. That's the basis for the whole SSL infrastructure and all the padlocks in the browser: We trust the entity that owns the root CA to only sign a cert for a vendor if they have verified the vendor is real. Because we trust the root CA issuer, we transitively trust the vendor with the TLS cert signed by the root CA.
When the "root CA private key" is made public, ANYONE can sign anything and appear as if they were the entity that issued the root CA. So Joe Hacker can now create a TLS cert that looks like it was signed by Sennheiser.
Bottom line: Sennheiser has screwed up and is letting ANYONE IN THE WORLD create a TLS cert that will tell the OS or browser that it has been signed by Sennheiser, and if a system trusts that Sennheiser root CA then ANYONE can create a cert that will be accepted by the system.
Suggest: If you have a system, browser or app that trusts the Sennheiser root CA, remove that entry from the trusted root CA list and wait until someone who knows what they are doing tells you it's OK to put it back in.