home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / security / misc / 1671 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  4.2 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!att-out!rutgers!ub!acsu.buffalo.edu!owens
  2. From: owens@acsu.buffalo.edu (Bill Owens)
  3. Newsgroups: comp.security.misc
  4. Subject: Re: Tripwire release
  5. Message-ID: <BxBtuD.CKM@acsu.buffalo.edu>
  6. Date: 7 Nov 92 03:32:37 GMT
  7. References: <LIMES.92Nov5142000@ouroborous.eng.sun.com>
  8. Sender: nntp@acsu.buffalo.edu
  9. Organization: UB
  10. Lines: 67
  11. Nntp-Posting-Host: cookiemonster.cc.buffalo.edu
  12. X-Newsreader: Tin 1.1 PL5
  13.  
  14. Greg Limes (limes@ouroborous.eng.sun.com) wrote:
  15. > owens@acsu.buffalo.edu (Bill Owens) writes:
  16. >|   Without adding the overhead of a digital signature for each file which
  17. >|   tripwire is keeping track of, could the program perhaps be set up to
  18. >|   check a cryptographic signature on the entire database?  If the key
  19. >|   used to make the signature were kept secure, presumably by encrypting
  20. >|   it, then I think this setup would be equally secure.
  21. >I think this is insufficient.
  22. >Let's say you protected a key program with such a signature, and used
  23. >a shell that would check such signatures before executing the program.
  24. >I'm a baddie, with sufficient (but maybe temporary) privileges on your
  25. >system that I can change the bits in the program (or maybe I'm a
  26. >virus). I change what I want to change, subverting the program. Then I
  27. >find some other bits that I don't care about, and twiddle them until
  28. >the signature is right. If I can make that backward calculation either
  29. >directly or by trial-and-error in a reasonable time, then your
  30. >signature protection system is no protection.
  31.  
  32. Hopefully that attack is computationally infeasible for good message
  33. digest functions, like MD5 and Snefru.  But with such privileges, and a
  34. database on a writable filesystem, the intruder could simply modify the
  35. database to reflect the new value, and then modify the database's
  36. signature to agree. However, that's not what I was suggesting.  To
  37. re-establish the context of my original comment; I was replying to
  38. another article, and using the author's terminology (which I realize
  39. now is potentially confusing):
  40.  
  41. Kevin McCurley (mccurley@cs.sandia.gov) wrote:
  42. >I would like to comment that this use of the term "signature" should
  43. >not be confused with the much stronger term of signature that is
  44. >common in cryptology literature.
  45.  
  46. The 'digital signature' I was referring to was what Kevin brought up;
  47. not just a message digest like MD5 but rather a message digest
  48. encrypted through a public-key cryptographic system. Such signatures
  49. are regarded as unforgeable, and if the checksum is a strong one, it
  50. should be a guarantee of the authenticity of the file being signed.
  51.  
  52. Kevin went on to say that if a digital signature were used for every
  53. file which tripwire was monitoring, then a read-only database would not
  54. be necessary. I was proposing to modify this idea by using the usual
  55. checksum routines (MD5, MD4, Snefru, etc.) to build the database, in
  56. the name of speed, with the added step of creating a digital signature
  57. for the *entire database*. Tripwire could then check that signature
  58. using the public key of the signer (the software maintainer, probably)
  59. and know that the database was good.
  60.  
  61. This allows a modification of the original setup; now, the database may
  62. be kept on a rw filesystem, for ease of maintenance, and only the
  63. secret key used for the signature need be protected. The key systems
  64. I'm familiar with (PGP and RIPEM) encode the secret key with DES,
  65. which, IMO, should be sufficient. The public key and the signing
  66. program could be protected by tripwire, so they could also be on the rw
  67. filesystem.  As a first cut, the signing/checking process could be
  68. handled manually, rather than by tripwire; eventually, parts of the
  69. RSAREF package could be used within tripwire to do the job.
  70.  
  71. Now that I've hopefully made myself clear, does this seem reasonable?
  72. The main question I have is whether MD5 is usable for this purpose;
  73. that is, whether an MD5 digest of an MD5 digest of a file guarantees
  74. the original file's integrity. Although I don't see any reason why not,
  75. my mathematical knowledge is nowhere near that level ;)
  76.  
  77. Bill.
  78. Bill Owens                                              owens@acsu.buffalo.edu
  79. 104E Computing Center                             uunet!acsu.buffalo.edu!owens
  80. Buffalo, NY 12460                                                 716/645-3511
  81.