One distribution's non default solution does not fix this problem. I'm talking about this on a larger scale AND I would like to see it be something that is instituted by default, not an add on that you know to (1) know about and (2) go to the trouble to find and install.
So yeah, that is pretty good. I would still argue that individual signed packages are better (the point of signature is moved closer to the actual person responsible for the code).
Either way, Debian as shipped by default does not check these values, so it does little good. This really should be the default.
Well, the idea (and the way I do it) is to do the signing on your local machine. Assuming that you can physically secure a dekstop or laptop better than a public server and have a key contained only on a removable media device.
It is not perfect, but it is way better than the system we have now. At least it lowers the potential points of attack to one place. As it stands now binaries and source code can be altered anywhere between the developers machine, main distribution site, mirror sites, etc.
Fine, but can we agree that it would be vastly more difficult to attack a personal developer's machine (assuming you even knew where/what it was) than a public repository? Of course signing stuff doesn't give you total security, but it is miles better than just throwing MD5 hashes around.
Most of my development work is done on a laptop, good luck cracking into it, most of the time it is not even on a network. When it is it is generally behind NAT.
And all this security comes with Debian by default? Well why not?
And this is just one distro. Why don't the kernels get signed on kernel.org and mirrors? How about software packages in sourceforge? GNU? My question really is why isn't this standard procedure for open source developers?
MD5 is just a message digest though, it is nothing like a digital signature (it can be part of a digital signature though) and offers no indication as to its origin. Generally anyone who can upload a backdoored source can also upload its MD5 hash.
I'm one of two people who built and run the certificate authority at PSU, and we have it on box that is in a locked cabinet (inside a secure server room) and has no network connection at all. The only way to use it to sign certs is to put them on a floppy or usb storage device.
For personal certs I like this idea of only having them on a smart card or a usb device. All the better if it is a biometric activated usb device or smart card:)
MD5 is not a digital signature, it is simply a "hash" or "message digest". By itself it is utterly useless.
However, if the package maintainer were to encrypt this MD5 hash with a private key, then release that with the package it would be loads more useful.
Then a lowly end user could decrypt this encrypted hash with the package maintainer's public key, then create their own MD5 hash of the downloaded software, and last compare their hash with the unencrypted hash, then we have some security.
We could call it....ummm.......oh yeah, a "digital signature":)
No... the way to alter software is easy to conceive.
You simply have to hack into the computer holding the private keys used for the signing (very likely the same computer holding the source code as well, and the system which normally uploads new packages to the distribution point). Once there, you can make changes and sign them just as if they were official.
Assuming you knew the password for the private key (private keys really should be encrypted with a password, especially for this).
Now before you go all 'keylogger' on me:) I will say that the private key should be kept on the personal machine of the person doing the signing, so they can dl the package, and sign it locally then upload it. Additional work? Sure but worth it in my opinion. What it really comes down to is that it is easier to keep a private key secure than it is to keep software that by definition is "open" for multiple people to work on secure. I mean if you cannot figure out how to keep a small private key secure, what hope do we have for free software's security?
Frankly, I'm more worried about mirror sites right now than anything else. Let's face it, there are tons of them, we do not know nor necessarily trust the people running them, and they are much less apt to reveal a compromise than someone lie GNU or Debian.
Still though, if kernel.org were compromised (or any of its many mirrors) the end result would have been horrible. There are too many points of potential compromise in free software distribution to not start demanding everyone sign stuff, imho. How hard would it really be for GNU to set up a CA and issue certs to every one of its program maintainers, or FSF could even take on this role.
Right, but so far (at least as far as I can tell, I've been wrong before), only Redhat does cryptographic checking by default. Debian's apt-get can be made to, but why is that not the default?
First GNU, then Bitkeeper, now this, whatever shall we do?
Simple, the technology has existed for decades now.
A little something I like to call "Public Key Cryptography"
With this "Public Key Cryptography" you could conceivably sign software in such a way that it could not be altered without breaking the signature, AND ensure that nobody else could forge this digital signature (you are keeping your private key private right?)
MD5 Hashes are a step in the right direction, but by themselves are meaningless. Sort of like improving your home's security by drilling holes in your door to mount a deadbolt but not actually taking the final step and INSTALLING THE DEADBOLT.
So let's take these MD5 hashes and encrypt them with the package maintainer's private key (or distribution maintainer, whatever). Then dpkg (or rpm, emerge, whatever your favorite package tool is) could be written to decrypt this hash with the corresponding public key. Wait, there is more! Then it could generate it's own MD5 hash of the package in question and COMPARE it to the decrypted hash it just created. If they match, the package is unaltered AND came from a trusted source. This my friends is what we like to call a "digital signature"
I don't care how you do it, GPG, x.509, whatever. I'm actually leaning toward x.509 since it seems to me to make more sense to have the distro maintainer run his/her own CA and issue certs to package maintainers. This CA could then be included in whatever package tool is used and viola. No mucking about with the web 'o trust (Which rocks for ad hoc trust relationships like between people emailing each other, but sucks for this kind of hierarchal stuff)
So what do you think everyone? Good idea or should we wait for a few more server compromises before we think about securing software repositories?
If a password is compromised, it does not matter what system you run. And everything I've read indicated this break-in was the result of a compromised password.
We are using federated identity in the higher education world via an Internet2 called Shibboleth which is very similar to Liberty (both based on SAML). It has been somewhat successful in our setting.
The rational for why we wanted is was that we (Penn State University) have a very strong central authentication and account management system. That is all well and good for internal services but like any university we license resources from external entities. Such as Webassign (popular web resource for Physics students), and various library resourses like OCLC, JSTOR, etc. Shibboleth allows our students to not have to create accounts on these resourses (and remember different userids and passwords) but use their PSU access id and password.
So to carry this over to the commercial side of things with liberty, they have the concept of an identity providor. This could be your bank, your isp, whatever. You only have to create an account with them, then you can use liberty to "assert" your identity to other commercial sites. Along with that you can choose to pass attributes like your credit card number, your shipping address, whatever. The benefit being that you do not have this data stored on mutiple databases at various companies, nor do you have multiple accounts to deal with at various companies.
In the federated identity world, the showdown is going to come between Liberty and WS:Fed. Liberty currently has the advantage of actually existing, and the spec followed a very open and transparent development model that was very inclusive (as spec development goes). WS:Fed on the other hand was developed behind closed doors by Microsoft and (to a lesser extent) IBM, and is just now applying for standards body recognition.
Another noteworthy point is that Liberty by design is very similar to Shibboleth, an Internet2 Middleware initiative for higher education federated authentication/authorization that has been very successful. Both are built off of Oasis's SAML spec. Shibboleth however places far more emphasis on user privacy.
Actually I'm an Econ major (senior). Sorry, selling at a loss is STILL a bad idea most of the time. As is evident by this, CueCat, iOpener, etc. So a couple game consoles work as loss leaders, it doesn't mean every piece of hardware under the sun is going to work in that market.
Is it any more stealing than buying the camera and never taking a picture with it? Both ruin the company's (mind bogglingly stupid) business plan of expecting you recoup their loss by using something you purchased exactly as they planned.
So what if i purchase the camera but never take pictures with it? Is that stealing? What if I only bought the Playstation II to have a DVD player? Is that stealing?
Maximizing your utility on a purchase is not stealing. If the company's business plan counted on you acting a different way, then they screwed up, not you. Business is risky, doubly so when you come up with a amazingly stupid business plan that involves selling people hardware under cost. if they want to rent the camera out, then rent the camera out. If they want to sell it, then they have to accept that people will use it anyway they see fit. That is the difference between renting and selling.
Ritz put together a business that relies on revenues that it will no longer have. Congratulations to those hackers/crackers who have likely now put those individuals out of work.
And shame on those who put together the business model. Honestly the stupidest business plan in the world has to be to sell hardware for less than it costs to make it. Do you honestly think people are going to feel bad at trying to maximize their utility from products they purchased? I use things as they were not intended by the manufacturer all the time. Do they have a legitimate complaint? No, they happily sold it to me and I have no obligation to help them succeed at what is undeniably a poorly thought out business model.
Do you feel bad every time you don't purchase something you see on TV? A lot of people worked hard to put together that business. That is why it is called "risk" Sometimes you do something stupid and lose. The customers are looking out for number 1, they are not on the company's side (as companies are not on the customer's side) and if one slips up, the other takes advantage. Every time.
Now, I'm not saying it's a bad thing to hack devices like this, heck I've got an iopener (running jailbait linux) standing next to my main computer. But there is a good chance that soon nobody will use the $11 developing deal, resulting in the cameras getting pulled from the stores.
And another stupid idea dies a well deserved death. You would think someday companies would learn not to sell things for less than it cost to make them. We are talking econ 101 here people.
Call it cruel if you want, but people will never stop trying to get the most utility out of the things they purchased. Frankly I fear for the human race if that ever changes.
Slashdot Mirror
One distribution's non default solution does not fix this problem. I'm talking about this on a larger scale AND I would like to see it be something that is instituted by default, not an add on that you know to (1) know about and (2) go to the trouble to find and install.
Finkployd
Ok, my bad. I missed this part.
So yeah, that is pretty good. I would still argue that individual signed packages are better (the point of signature is moved closer to the actual person responsible for the code).
Either way, Debian as shipped by default does not check these values, so it does little good. This really should be the default.
Finkployd
Well, the idea (and the way I do it) is to do the signing on your local machine. Assuming that you can physically secure a dekstop or laptop better than a public server and have a key contained only on a removable media device.
It is not perfect, but it is way better than the system we have now. At least it lowers the potential points of attack to one place. As it stands now binaries and source code can be altered anywhere between the developers machine, main distribution site, mirror sites, etc.
Finkployd
Finkployd
Fine, but can we agree that it would be vastly more difficult to attack a personal developer's machine (assuming you even knew where/what it was) than a public repository? Of course signing stuff doesn't give you total security, but it is miles better than just throwing MD5 hashes around.
Most of my development work is done on a laptop, good luck cracking into it, most of the time it is not even on a network. When it is it is generally behind NAT.
Finkployd
And all this security comes with Debian by default? Well why not?
And this is just one distro. Why don't the kernels get signed on kernel.org and mirrors? How about software packages in sourceforge? GNU? My question really is why isn't this standard procedure for open source developers?
Finkployd
MD5 is just a message digest though, it is nothing like a digital signature (it can be part of a digital signature though) and offers no indication as to its origin. Generally anyone who can upload a backdoored source can also upload its MD5 hash.
Finkployd
I'm one of two people who built and run the certificate authority at PSU, and we have it on box that is in a locked cabinet (inside a secure server room) and has no network connection at all. The only way to use it to sign certs is to put them on a floppy or usb storage device.
:)
For personal certs I like this idea of only having them on a smart card or a usb device. All the better if it is a biometric activated usb device or smart card
Finkployd
Good point, that.
Finkployd
And this is not the default in Debian because?
Finkployd
MD5 is not a digital signature, it is simply a "hash" or "message digest". By itself it is utterly useless.
:)
However, if the package maintainer were to encrypt this MD5 hash with a private key, then release that with the package it would be loads more useful.
Then a lowly end user could decrypt this encrypted hash with the package maintainer's public key, then create their own MD5 hash of the downloaded software, and last compare their hash with the unencrypted hash, then we have some security.
We could call it....ummm.......oh yeah, a "digital signature"
Finkployd
No... the way to alter software is easy to conceive.
:) I will say that the private key should be kept on the personal machine of the person doing the signing, so they can dl the package, and sign it locally then upload it. Additional work? Sure but worth it in my opinion. What it really comes down to is that it is easier to keep a private key secure than it is to keep software that by definition is "open" for multiple people to work on secure. I mean if you cannot figure out how to keep a small private key secure, what hope do we have for free software's security?
You simply have to hack into the computer holding the private keys used for the signing (very likely the same computer holding the source code as well, and the system which normally uploads new packages to the distribution point). Once there, you can make changes and sign them just as if they were official.
Assuming you knew the password for the private key (private keys really should be encrypted with a password, especially for this).
Now before you go all 'keylogger' on me
Frankly, I'm more worried about mirror sites right now than anything else. Let's face it, there are tons of them, we do not know nor necessarily trust the people running them, and they are much less apt to reveal a compromise than someone lie GNU or Debian.
Finkployd
Good point, thanks.
Still though, if kernel.org were compromised (or any of its many mirrors) the end result would have been horrible. There are too many points of potential compromise in free software distribution to not start demanding everyone sign stuff, imho. How hard would it really be for GNU to set up a CA and issue certs to every one of its program maintainers, or FSF could even take on this role.
Finkployd
Right, but so far (at least as far as I can tell, I've been wrong before), only Redhat does cryptographic checking by default. Debian's apt-get can be made to, but why is that not the default?
Finkployd
First GNU, then Bitkeeper, now this, whatever shall we do?
Simple, the technology has existed for decades now.
A little something I like to call "Public Key Cryptography"
With this "Public Key Cryptography" you could conceivably sign software in such a way that it could not be altered without breaking the signature, AND ensure that nobody else could forge this digital signature (you are keeping your private key private right?)
MD5 Hashes are a step in the right direction, but by themselves are meaningless. Sort of like improving your home's security by drilling holes in your door to mount a deadbolt but not actually taking the final step and INSTALLING THE DEADBOLT.
So let's take these MD5 hashes and encrypt them with the package maintainer's private key (or distribution maintainer, whatever). Then dpkg (or rpm, emerge, whatever your favorite package tool is) could be written to decrypt this hash with the corresponding public key. Wait, there is more! Then it could generate it's own MD5 hash of the package in question and COMPARE it to the decrypted hash it just created. If they match, the package is unaltered AND came from a trusted source. This my friends is what we like to call a "digital signature"
I don't care how you do it, GPG, x.509, whatever. I'm actually leaning toward x.509 since it seems to me to make more sense to have the distro maintainer run his/her own CA and issue certs to package maintainers. This CA could then be included in whatever package tool is used and viola. No mucking about with the web 'o trust (Which rocks for ad hoc trust relationships like between people emailing each other, but sucks for this kind of hierarchal stuff)
So what do you think everyone? Good idea or should we wait for a few more server compromises before we think about securing software repositories?
Finkployd
If a password is compromised, it does not matter what system you run. And everything I've read indicated this break-in was the result of a compromised password.
Finkployd
Aww, good for those Internet2 users. All 15 of them.
There are around 130,000 Internet2 (actually Abilene) at my university
Finkployd
We are using federated identity in the higher education world via an Internet2 called Shibboleth which is very similar to Liberty (both based on SAML). It has been somewhat successful in our setting.
The rational for why we wanted is was that we (Penn State University) have a very strong central authentication and account management system. That is all well and good for internal services but like any university we license resources from external entities. Such as Webassign (popular web resource for Physics students), and various library resourses like OCLC, JSTOR, etc. Shibboleth allows our students to not have to create accounts on these resourses (and remember different userids and passwords) but use their PSU access id and password.
So to carry this over to the commercial side of things with liberty, they have the concept of an identity providor. This could be your bank, your isp, whatever. You only have to create an account with them, then you can use liberty to "assert" your identity to other commercial sites. Along with that you can choose to pass attributes like your credit card number, your shipping address, whatever. The benefit being that you do not have this data stored on mutiple databases at various companies, nor do you have multiple accounts to deal with at various companies.
Finkployd
WS:Federation does.
In the federated identity world, the showdown is going to come between Liberty and WS:Fed. Liberty currently has the advantage of actually existing, and the spec followed a very open and transparent development model that was very inclusive (as spec development goes). WS:Fed on the other hand was developed behind closed doors by Microsoft and (to a lesser extent) IBM, and is just now applying for standards body recognition.
Another noteworthy point is that Liberty by design is very similar to Shibboleth, an Internet2 Middleware initiative for higher education federated authentication/authorization that has been very successful. Both are built off of Oasis's SAML spec. Shibboleth however places far more emphasis on user privacy.
Finkployd
They can say it all they want, doesn't make it true.
Finkployd
Except you rent rental cars, whereas you BUY this camera. I'm under no obligation to ever return it or use it (as intended or otherwise)
Finkployd
Actually I'm an Econ major (senior). Sorry, selling at a loss is STILL a bad idea most of the time. As is evident by this, CueCat, iOpener, etc. So a couple game consoles work as loss leaders, it doesn't mean every piece of hardware under the sun is going to work in that market.
Finkployd
Is it any more stealing than buying the camera and never taking a picture with it? Both ruin the company's (mind bogglingly stupid) business plan of expecting you recoup their loss by using something you purchased exactly as they planned.
Finkployd
So what if i purchase the camera but never take pictures with it? Is that stealing? What if I only bought the Playstation II to have a DVD player? Is that stealing?
Maximizing your utility on a purchase is not stealing. If the company's business plan counted on you acting a different way, then they screwed up, not you. Business is risky, doubly so when you come up with a amazingly stupid business plan that involves selling people hardware under cost. if they want to rent the camera out, then rent the camera out. If they want to sell it, then they have to accept that people will use it anyway they see fit. That is the difference between renting and selling.
Finkployd
Ritz put together a business that relies on revenues that it will no longer have. Congratulations to those hackers/crackers who have likely now put those individuals out of work.
And shame on those who put together the business model. Honestly the stupidest business plan in the world has to be to sell hardware for less than it costs to make it. Do you honestly think people are going to feel bad at trying to maximize their utility from products they purchased? I use things as they were not intended by the manufacturer all the time. Do they have a legitimate complaint? No, they happily sold it to me and I have no obligation to help them succeed at what is undeniably a poorly thought out business model.
Do you feel bad every time you don't purchase something you see on TV? A lot of people worked hard to put together that business. That is why it is called "risk" Sometimes you do something stupid and lose. The customers are looking out for number 1, they are not on the company's side (as companies are not on the customer's side) and if one slips up, the other takes advantage. Every time.
Finkployd
Now, I'm not saying it's a bad thing to hack devices like this, heck I've got an iopener (running jailbait linux) standing next to my main computer. But there is a good chance that soon nobody will use the $11 developing deal, resulting in the cameras getting pulled from the stores.
And another stupid idea dies a well deserved death. You would think someday companies would learn not to sell things for less than it cost to make them. We are talking econ 101 here people.
Call it cruel if you want, but people will never stop trying to get the most utility out of the things they purchased. Frankly I fear for the human race if that ever changes.
Finkployd