Reasonable validation of a software package
Fellow cpunks: I am working on various software packages for UNIX and Windows and since this is commercial work and prior NDA's are involved, I can't include the source code for absolute validation. What would assure one that a package has not been tampered with from the company to the user? (Currently, I am using PKZIP's rather anemic AV protection, as well as signing the archive with my PGP key. I am wondering if there are any other steps I need to take to assure that a package came from me, and wasn't damaged/altered/tampered with in transit.) Thanks in advance.
This touches upon a favourite rant of mine. Anonymous User wrote:
Fellow cpunks:
I am working on various software packages for UNIX and Windows and since this is commercial work and prior NDA's are involved, I can't include the source code for absolute validation.
What would assure one that a package has not been tampered with from the company to the user?
If someone had your public key, and a trusted software module with which to use it, you could use a "Digital Signature". PGP offers such data integrity and signing functions. You also indicate you have PGP - even better. So, now you are left with ensuuring people have your public key, and the recipient having a trusted software tool. Again, PGP is relatively well accepted in this regard. Trusted - depends on the source of the recipient's copy. So, now you need to ensure that you can get your public key (to verify the digital signature with) in the hands of all your possible, or intended, recipients. Now the race is on for as many people as possible to generate PGP public keys/certificates bearing your name, or variations of it. Once that occurs, there is a fair chance that one of these keys will verfiy the digital signature on a piece of software purportedly from you. Still, not many people will have your true PGP public key/certificate, but, them's the breaks.
(Currently, I am using PKZIP's rather anemic AV protection, as well as signing the archive with my PGP key. I am wondering if there are any other steps I need to take to assure that a package came from me, and wasn'tSee above - easy or difficult - how much assurance do you want ?
damaged/altered/tampered with in transit.)See above - easy or difficult - how much assurance do you want ?
Thanks in advance.
lyal -- All mistakes in this message belong to me - you should not use them!
This illustrates the need for and role of certification authorities. See http://www.law.miami.edu/~froomkin/articles/trusted.htm for some info. On Sat, 13 Jul 1996, Lyal Collins wrote:
This touches upon a favourite rant of mine. [...] So, now you need to ensure that you can get your public key (to verify the digital signature with) in the hands of all your possible, or intended, recipients.
Now the race is on for as many people as possible to generate PGP public keys/certificates bearing your name, or variations of it. Once that occurs, there is a fair chance that one of these keys will verfiy the digital signature on a piece of software purportedly from you. Still, not many people will have your true PGP public key/certificate, but, them's the breaks.
[...] A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin@law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | It's hot here. And humid.
At 11:33 -0400 7/13/96, Michael Froomkin wrote:
This illustrates the need for and role of certification authorities.
See http://www.law.miami.edu/~froomkin/articles/trusted.htm for some info.
["this" being the possibility that someone would generate lots of signed public keys with your name on them] However, there's nothing to stop generation of many certificates from trusted CAs with your name on them. In fact, if you have a name like Michael Smith, and if a CA is successful, there *will be* lots of certificates with your name on them, even without anyone's trying to do anything crooked. The problem people overlook is that a CA binds a public key to a name but the name is in the CA's name space. For me, a verifier, to derive any value from a certificate binding (key,name), the name has to be in *my* name space. If there were such a thing as a global namespace meaningful to everyone, then we could both use it. That's the X.500 falacy/pipe-dream. The fact is, no global name space could be held in one human's mind, so there's no way a global name space could be meaningful to me. So, to use a certificate from a CA, I need to map a name from its name space (DN) into a name in my name space (nickname). Every time I've looked at that process, I've had to have a secure channel over which to learn from the person I call by that nickname what DN he goes by. If I have that secure channel, then he could tell me his public key fingerprint ove that cnnel -- and I wouldn't need the CA. - Carl +------------------------------------------------------------------------+ |Carl M. Ellison cme@acm.org http://www.clark.net/pub/cme | |PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2| | "Officer, officer, arrest that man! He's whistling a dirty song." | +-------------------------------------------- Jean Ellison (aka Mother) -+
participants (4)
-
Anonymous User -
Carl Ellison -
Lyal Collins -
Michael Froomkin