Re: Making sure a program gets to the receiver intact
Eric writes:
From: an169306@anon.penet.fi How can I insure a program, once put on FTP sites stays untampered with?
The best solution is not digital signatures but rather digital timestamping. The question is not persistence of authorship but rather persistence through time. [Discussion of the implications of getting your keys hacked, over time]
The holes: 1: Someone hacking the keyservers, substituting a key for all the people who signed, and modifing the archive to show that. That's why keyservers are inherently non-trustable; the trust comes from
Some good points, but on the whole I'll disagree. Either way, the solution pretty much comes down to "eternal vigilance".... The interesting technique that digital timestamping provides is that it lets you show that the version you claim you posted to the ftp site got there before the [different] version that's there now. To use that technique, either you need to broadcast the details of the digital timestamping in an unhackable public fashion, or else someone who wants to validate the archived data needs to check with you to be sure that they have a good checksum matching your timestamp. An ftp server *could* timestamp each incoming document, keeping the master timestamp data in an un-hackable location, and post the current timestamps for the current time period [e.g. day] in the (hackable) archive, and then register the day's timestamp file with a notary service so you can be sure that the file hasn't been compromised later. On the other hand, without signatures, it's not too hard for a Bad Guy to store bogus files on the server and get them timestamped too - the user needs a good way to check for previous editions of the document in the timestamp file. With digital signatures, at least a given file has some internal consistency. the Web of Trust connections you have, though a keyserver run by a widely-trusted person carrying only keys signed by him/her/it is stronger.
2: Someone breaking into my apt, sticking a keyboard monitor on, getting my passphrase and key. Yup. That's a problem with signatures.
Bill
Bill Stuart writes:
How can I insure a program, once put on FTP sites stays untampered with? ... On the other hand, without signatures, it's not too hard for a Bad Guy to store bogus files on the server and get them timestamped too - the user needs a good way to check for previous editions of the document in the timestamp file. With digital signatures, at least a given file has some internal consistency.
The holes: 1: Someone hacking the keyservers, substituting a key for all the people who signed, and modifing the archive to show that. That's why keyservers are inherently non-trustable; the trust comes from the Web of Trust connections you have, though a keyserver run by a widely-trusted person carrying only keys signed by him/her/it is stronger.
2: Someone breaking into my apt, sticking a keyboard monitor on, getting my passphrase and key. Yup. That's a problem with signatures.
Another, practical, problem with integrity checks (both signatures and timestamps) for files on public archive servers is that the receiver has to expect them and know how to verify them. Current ftp and www clients certainly don't have facilities to do this automatically, and neither do users have reason to suspect foul play if a timestamp or signature is missing for some file. It's somewhat analogous to the situation ten years ago when some nut was lacing over-the-counter drugs with poison and putting the packages back on the shelf. The major drug companies responded by including tamper-evident seals on their packages, but until consumers learned to expect the seals, all the bad guys had to do was remove the seal entirely before replacing the tainted packages. In the short term, given today's infrastructure, there's not a lot you can do. Of course, in the medium- and long- term, the best solution is to design good schemes and deploy them widely enough that people learn to expect them. -matt
On Tue, 27 Dec 1994, Matt Blaze wrote:
including tamper-evident seals on their packages, but until consumers learned to expect the seals, all the bad guys had to do was remove the seal entirely before replacing the tainted packages. In the short term, given today's infrastructure, there's not a lot you can do.
Of course, in the medium- and long- term, the best solution is to design good schemes and deploy them widely enough that people learn to expect them.
One solution, or start of a solution, is to tell the user about the signature checks, and how to go about verifying them in teh README text file, that most users come to expect in a package of software. Or perhaps add into the tar and zipped packagea file called SIGNATURECHECK or something suitably obvious, as well as explaining it. I believe most users expect the README file enough to look in it, at least skimming it. i want to know everything http://www.mcs.com/~nesta/home.html i want to be everywhere Nesta's Home Page i want to fuck everyone in the world & i want to do something that matters /-/ a s t e zine
Nesta Stubbs says:
One solution, or start of a solution, is to tell the user about the signature checks, and how to go about verifying them in teh README text file, that most users come to expect in a package of software.
And if someone edits that out of the README? .pm
On Tue, 27 Dec 1994, Perry E. Metzger wrote:
Nesta Stubbs says:
One solution, or start of a solution, is to tell the user about the signature checks, and how to go about verifying them in teh README text file, that most users come to expect in a package of software.
And if someone edits that out of the README?
put it int he file that pops up from the FTP server when you switch to that directory, am not sur what the file is called, but like when you switch to the pub/Linux directory on sunsite, it gives youa rundown of what Linux is and all. Then the person would hav to hack access to the FTp server to change that. And I assume ti is easier for the maintaner of the FTp site to keep track of that one readme, then it is to keep track of the readmes in all the ppackages. i want to know everything http://www.mcs.com/~nesta/home.html i want to be everywhere Nesta's Home Page i want to fuck everyone in the world & i want to do something that matters /-/ a s t e zine
On Dec 27, 7:14pm, Nesta Stubbs wrote:
put it int he file that pops up from the FTP server when you switch to that directory, am not sur what the file is called, but like when you switch to the pub/Linux directory on sunsite, it gives youa rundown of what Linux is and all.
The ftpd's that implement the directory-change messages is not a standard one, and that functionality has been added to the servers which support it (possibly Linux ships with wuftpd, but no commercial version of Unix I know does.) The extended servers are very widely available, and although they do make ftp so much nicer to administer, they are not as widely deployed as I would have expected by now. Ian.
From: wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204) The specific question is tampering of files on archive sites. The larger issue is information, particularly software, distribution. My position is that timestamping is a better solution than signatures for the tampering issue and that both are useful for the larger issue. Some good points, but on the whole I'll disagree. Either way, the solution pretty much comes down to "eternal vigilance".... Well, "eternal vigilance" is really "public information". Both the timestamping problem and the signature problem resolve down the same problem about secure _cleartext_ transmission. How do people gain an assurance that they have the same shared piece of information? The first advantage that timestamping has over signatures is that timestamps are temporal and signatures are not. Private keys for signatures change over time by design, but timestamp roots do not, also by design. That is, once a timestamp root has been securely transmitted, there is an assurance that everything up to that point is OK. Spoofing a signature, however, can be done by spoofing a key change; there are public information solutions to this as well, but they still do not have temporal assurances. The second advantage is the the timestamp roots are more widely shared than individual public keys. Because more people look at this one piece of information, it's much harder to completely forge. The cost of verification is smaller per person, but there is much more total verification performed. The root keys in a certification hierarchy have the same property of wide sharing, but the effect on public key distribution is not the same. The creation of the timestamp root is a _technically_ linkage of all the individual timestamps, while the root key of a certifying authority creates _social_ links between the root key and the other keys. The technical linkage is stronger. The interesting technique that digital timestamping provides is that it lets you show that the version you claim you posted to the ftp site got there before the [different] version that's there now. You can also post a public announcement, timestamped, which has the location and the timestamp of the information and the archive. This public announcement has public information properties as above. To use that technique, either you need to broadcast the details of the digital timestamping in an unhackable public fashion, The "unhackable" nature is not even necessary to assume. All you need is the ability to post public information with some non-zero probability of success. Eventually the public information gets out. The timestamp will indicate priority. There's also the possibility of timestamping the entire directory tree periodically. This is all publicly verifiable, so an interposer would have to intercept the very first transmission and could not come along later and perform undetectable corruption. On the other hand, without signatures, it's not too hard for a Bad Guy to store bogus files on the server and get them timestamped too - Sure, that's the whole point. Any information protection, signatures or timestamps, can simply be replicated. The timestamp algorithm gives you a temporal ordering to distinguish between the two, which signatures don't have. On the other hand, I'll amplify Matt's point by pointing out that any deployed mechanism to increase the difficulty and cost of information subversion is better than what exists now, which is strictly ad hoc. The integration issues of any public authentication system will be difficult, regardless of the underlying mechanism. Eric
participants (6)
-
eric＠remailer.net -
Ian Farquhar -
Matt Blaze -
Nesta Stubbs -
Perry E. Metzger -
wcs＠anchor.ho.att.com