Signing software packages
I'm writing a little pet project that involves automated software updates. To determine the package's authenticity these kind of services normally sign the packages cryptographycally. This is the first time I'm confronted with PKI cryptography in a software project so I'm a little confused. Here's what I know so far, please correct me if I'm wrong.
* Package signing can be done with PGP (or gnupg).
* I understand that the server delivering the software packages will have its own set of keys (public and private).
* The 'clients' need the server's public key to verify the packages, however embedding the server's public key in the client software is a bad idea. Should the server's private key be compromised the server's key pair must change and clients should be aknowledged. Clients should then get the server's new public key.
The hairy bit for me is, how do clients know the new key is safe? A malicious user could be spoofing the service providing a new set of keys and properly signed software that will pass the verification rules of the client.
I understand there are companies like Verisign or Thawte that will issue digital certificates that will address the problem of autheticity of the keys. But is this really necessary? I mean, I would like to be able to change the keys at any time without discontinuing service and not have to put the service offline untill some company issues a new certificate.
As an example, many apt-rpm repositories contain signed packages how does the client know package "PackA" comes from Repository#1 instead of EvilRepository#2 posing as Repository#1?
Any help is appreciated.
Friday, April 25, 2003
I think end-users are generally supposed to get the public keys from a secondary source they trust, like your company's website. e.g. http://www.softwareco.com/public_key. Of course it's possible for an adversary to take over your domain or spoof the HTTP traffic, but that's quite a bit harder to do than just embedding a fake public key in the software download itself.
As I understand it, companies like Verisign exist to provide an extra layer of security, to verify that the aforementioned adversary has not actually spoofed the connection you use to get the public key.
Friday, April 25, 2003
go ahead and embed the public key in your app. Will people really be trying to factorise it or whatnot?
On the other hand, keep your private key on a computer that is air-gapped from everything.
Saturday, April 26, 2003
The question you are asking boils down to "what is the root of my chain of trust"? (Ignore the mixed metaphor!)
Every chain of trust has to end somewhere. Why do I trust this package? Because it was downloaded from a secure server. How do I know I actually got the real bits from the server? Because the server signed the bits with a private key. How do I know I have the corresponding public key?
Oops, I don't know that.
A chain of trust must end somewhere. That's the point of companies like Verisign. Every Windows box by default ships with the Versign cert in its Trusted Root Certificate Store. Now the story ends "...because Verisign signed the public key certificate. How do I know Verisign signed it? Because Verisign's cert is in my trusted root store."
I understand that you don't want to incur the inflexibility of going with a third party. If you want PKI security, you basically have two choices: (1) live with the cost of letting professional trust providers manage your trust chains, or (2) do what they do yourself -- provide an infrastructure for secure delivery of root certificates, revocation lists, etc.
Since you are by your own admission a PKI newbie, I urge you in the strongest possible terms to not attempt to roll your own key management system.
Can you tell us a bit more about why you want to provide security? What are the assets being protected, what are the threats, and how will cryptography mitigate those threats?
Monday, April 28, 2003
Fog Creek Home