4 ms·

Just imagine what the developer thought when his boss said "we don't want to buy an actual certificate, find something that works". And now this developer is l

Just imagine what the developer thought when his boss said "we don't want to buy an actual certificate, find something that works". And now this developer is learning on HN he should remove that line in his resumé. Or maybe he thought it was a clever idea... Let's call it a learning experience.

voltagex_ 9y ago
It's a driver associated with some open source Android stuff. Driver signing certificate are $100+/year.
varenc 9y ago
This seems a better and more secure solution than buying an actual certificate. If they had a single certificate and used that across devices then the private key could be compromised and used to authenticate malware or pull off a man in the middle attack on an HTTPS site since your system now trusts this new CA. By generating the private key locally and throwing it away, you can be relatively confident that no one has the private key to this new root CA. What's silly in the first place is that something not trusted to install unsigned drivers still has the perms to install a new root CA but given that constraint, this is a better solution than what Savitech did.
- ChristianBundy 9y ago
  > If they had an actual root CA with a private key, that private key could be compromised and used to authenticate malware or pull of a man in the middle attack on an HTTPS site. If they had an actual root CA with a private key, they'd sign it locally (on the company machine). In no scenario would the company's private key be given to a customer (unless we're talking about Adobe).
  - varenc 9y ago
    Yes, that's the ideal case... But what do you want to do more? 1) Trust some company to keep a very important private key secure for a long time? (with attackers knowing it's a single high-value target) 2) Or be confident that the private key was used once and destroyed forever? Even if the private key generated on your device could be recovered it would only be good for an attack against you making it a lower priority to attackers.
    - dec0dedab0de 9y ago
      Or be confident that the private key was used once and destroyed forever? Even if the private key generated on your device could be recovered it would only be good for an attack against you making it a lower priority to attackers. Doing it that way completely undermines the reason for having a cert in the first place. You might as well not have one at all.
      - usrusr 9y ago
        The difference is that with the on the fly cert, you blindly trust one piece of code, at one point in time, and when it did not lie to you then you will be safe from it later. A conventional cert owner on the other hand could theoretically turn on you any time (e.g. when ownership multiplies into pwnership) once "automatic trust" for the next binary is established. I'd still prefer the latter, given reasonable standards in terms of key handling, but the one-time trust is not completely without merit. It would certainly be more reasonable though to just allow one-time blind trust without forcing the installer to create a certificate that may or may not be as private as advertised.
      - ComodoHacker 9y ago
        There's a difference. With auto-generated root certs you can't just steal one private key, sign your malware with it and push it to all users of the original software.
- weddpros 9y ago
  I wouldn't trust anything closed source to forget that private key. I can't see how buying an actual cert could be more risky than installing a new root CA. The goal of signing is to ensure origin and anti-tampering: two fails in this case. So now you may have a tampered with driver that doesn't remove the private key and uses the new CA to inspect your TLS traffic, and you wouldn't know.
  - AstralStorm 9y ago
    Can you trust random procedures of company xyz to secure their private key store? I don't. Not even Microsoft themselves. There were embarrassing slips.
lultimouomo 9y ago
I don't think this was done to skim in money, but to let you install a driver that binds only with your mobile USB ID. Alternatively they would need to ship hundreds of different drivers or a single driver that binds to hundreds of different device IDS. Not nice.

voltagex_ 9y ago

It's a driver associated with some open source Android stuff. Driver signing certificate are $100+/year.

varenc 9y ago

This seems a better and more secure solution than buying an actual certificate. If they had a single certificate and used that across devices then the private key could be compromised and used to authenticate malware or pull off a man in the middle attack on an HTTPS site since your system now trusts this new CA. By generating the private key locally and throwing it away, you can be relatively confident that no one has the private key to this new root CA. What's silly in the first place is that something not trusted to install unsigned drivers still has the perms to install a new root CA but given that constraint, this is a better solution than what Savitech did.

ChristianBundy 9y ago
> If they had an actual root CA with a private key, that private key could be compromised and used to authenticate malware or pull of a man in the middle attack on an HTTPS site. If they had an actual root CA with a private key, they'd sign it locally (on the company machine). In no scenario would the company's private key be given to a customer (unless we're talking about Adobe).
- varenc 9y ago
  Yes, that's the ideal case... But what do you want to do more? 1) Trust some company to keep a very important private key secure for a long time? (with attackers knowing it's a single high-value target) 2) Or be confident that the private key was used once and destroyed forever? Even if the private key generated on your device could be recovered it would only be good for an attack against you making it a lower priority to attackers.
  - dec0dedab0de 9y ago
    Or be confident that the private key was used once and destroyed forever? Even if the private key generated on your device could be recovered it would only be good for an attack against you making it a lower priority to attackers. Doing it that way completely undermines the reason for having a cert in the first place. You might as well not have one at all.
    - usrusr 9y ago
      The difference is that with the on the fly cert, you blindly trust one piece of code, at one point in time, and when it did not lie to you then you will be safe from it later. A conventional cert owner on the other hand could theoretically turn on you any time (e.g. when ownership multiplies into pwnership) once "automatic trust" for the next binary is established. I'd still prefer the latter, given reasonable standards in terms of key handling, but the one-time trust is not completely without merit. It would certainly be more reasonable though to just allow one-time blind trust without forcing the installer to create a certificate that may or may not be as private as advertised.
    - ComodoHacker 9y ago
      There's a difference. With auto-generated root certs you can't just steal one private key, sign your malware with it and push it to all users of the original software.
weddpros 9y ago
I wouldn't trust anything closed source to forget that private key. I can't see how buying an actual cert could be more risky than installing a new root CA. The goal of signing is to ensure origin and anti-tampering: two fails in this case. So now you may have a tampered with driver that doesn't remove the private key and uses the new CA to inspect your TLS traffic, and you wouldn't know.
- AstralStorm 9y ago
  Can you trust random procedures of company xyz to secure their private key store? I don't. Not even Microsoft themselves. There were embarrassing slips.

lultimouomo 9y ago

I don't think this was done to skim in money, but to let you install a driver that binds only with your mobile USB ID. Alternatively they would need to ship hundreds of different drivers or a single driver that binds to hundreds of different device IDS. Not nice.