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]

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 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.

		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