home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / privacy / p01_002.txt < prev    next >
Text File  |  1996-09-03  |  22KB  |  460 lines

  1. PRIVACY Forum Digest -- Saturday, 30 May 1992 -- Volume 1, Number 2
  2.  
  3. Moderated by Lauren Weinstein (lauren@cv.vortex.com)
  4.          Vortex Technology, Topanga, CA, U.S.A.
  5.  
  6.                   ===== PRIVACY FORUM =====
  7.  
  8. CONTENTS
  9.  
  10.     Privacy BRIEFS (Moderator)
  11.     E-mail privacy; a cheap solution? (Charlie Stross)
  12.     Personal Data (Willie Smith)
  13.         The Concept of Privacy (A. Padgett Peterson)
  14.     Privacy Rights (Mark Rasch)
  15.     Query: Search and Seizure (Mark Rasch)
  16.  
  17. *** Please include a MEANINGFUL "Subject:" line on all submissions! ***
  18.  
  19. ---------------------------------------------------------------------------
  20. The PRIVACY Forum is a moderated digest for the discussion and analysis of
  21. issues relating to the general topic of privacy (both personal and
  22. collective) in the "information age" of the 1990's and beyond.  The
  23. moderator will choose submissions for inclusion based on their relevance and
  24. content.  Submissions will not be routinely acknowledged.
  25.  
  26. ALL submissions should be addressed to "privacy@cv.vortex.com" and must have
  27. MEANINGFUL "Subject:" lines.  Subscriptions are by an automatic "listserv"
  28. system; for subscription information, please send a message consisting of
  29. the word "help" (quotes not included) in the BODY of a message to:
  30. "privacy-request@cv.vortex.com".  Mailing list problems should be reported
  31. to "list-maint@cv.vortex.com".  Mechanisms for obtaining back issues will be
  32. announced when available.  All submissions included in this digest represent
  33. the views of the individual authors and all submissions will be considered
  34. to be distributable without limitations. 
  35.  
  36. For information regarding the availability of this digest via FAX, please
  37. send an inquiry to digest-fax@cv.vortex.com.
  38. ---------------------------------------------------------------------------
  39.  
  40. VOLUME 1, NUMBER 2
  41.  
  42.     -------------------------------------------------------------
  43.         Quote for the day:
  44.  
  45.     "We are all interested in the future, because that
  46.      is where you and I will be spending the rest
  47.      of our lives."
  48.             -- Criswell, 
  49.                "Plan 9 From Outer Space" (1959)
  50.  
  51.     -------------------------------------------------------------
  52.  
  53. Privacy BRIEFS (from the Moderator)
  54.  
  55. --- 
  56.  
  57. A plan is under consideration by the Justice Ministry in the Netherlands
  58. to track all vehicles via computer technology.  This would include both
  59. vehicular and road sensors and would be mandatory.  The plan would be to
  60. automatically detect and report offenses ranging from speeding to parking
  61. violations.  Some privacy concerns, particularly regarding the ability of
  62. such a system to track the exact location of all vehicles at all times, have
  63. been raised.  "People may view it as an invasion of privacy, like Big
  64. Brother," said ministry researcher Gerard de Raaf.  However, he also claimed
  65. that such fears could be eased through "restrictions" on access to the
  66. collected data.
  67.  
  68. ---
  69.  
  70. A bill is working its way through the California legislature which would
  71. make illegal the use of "automated" speeding ticket machines.  These units,
  72. which automatically detect speeders, take photos of the vehicular license
  73. plate (and in some cases the driver), then automatically issue tickets, have
  74. been undergoing considerable criticism.  Concerns about the fairness of the
  75. system are numerous, including problems with driver identification, delay in
  76. tickets being issued, and the lack of consideration of extenuating
  77. circumstances.  At least one police organization plans to lobby the Governor
  78. to veto the bill if it passes both houses.
  79.  
  80. ---
  81.  
  82. A court battle is currently raging over whether or not the White House has
  83. the right to delete backup tapes of e-mail communications that they do not
  84. consider to be covered by the federal Records Act.  Similar messages, which
  85. originally had been thought to be completely deleted, played a key role in
  86. the recent Iran-Contra investigations.  The White House believes that it
  87. should be able to decide on its own which items do or do not fall under the
  88. Records Act (which provides for the turning over of such materials to the
  89. National Archives).
  90.  
  91. -----------------------------------
  92.  
  93. Date:    Thu, 28 May 92 11:53:12 PDT
  94. From:    Charlie Stross <charless@sco.COM>
  95. Subject: e-mail privacy; a cheap solution?
  96.  
  97. I'm puzzled by the common conception on the net that e-mail is
  98. innately insecure because organization XYZ can crack any message
  99. encrypted using method ABC, and that it's not possible to use a
  100. secure encryption method because such a technique is innately
  101. expensive (both in cost and computer time) and illegal. I feel
  102. that until we -- the public -- have cheap, easy and unbreakable
  103. encryption facilities at our disposal, we will remain vulnerable
  104. to both the psychological pressure of knowing that our
  105. correspondence might be monitored and the potential danger that
  106. this is actually the case.
  107.  
  108. I am particularly interested in the fact that no cheap and 
  109. computationally intractible public encryption methods are in common
  110. use. Inventing a secure, computationally inexpensive, and cheap 
  111. encryption device for point-to-point communications doesn't look
  112. like an obstacle. In fact, even a home-brew system should be quite 
  113. effective. I know relatively little about cryptography but here's my
  114. attempt at a privacy gadget costing less than #300 that's capable
  115. of defying the governmental security agency of your choice:
  116.  
  117. Take a CD-ROM drive with a device driver for playing audio CD's
  118. and randomly accessing audio tracks. Most multi-media kit should
  119. already be capable of doing this. Take a random music CD off your
  120. shelf and start playing it at a random offset; redirect the bit
  121. stream to a file. (You need to make a note of the initial file 
  122. offset of the data you're recording.) Now take the file you wish to
  123. encrypt. Run-length encode it to eliminate recurring byte sequences. 
  124. Split it into chunks -- say 64 bytes -- and split the audio file 
  125. into similar-sized chunks. The audio file is used as a one-time 
  126. pad for a simple cypher algorithm which is applied to the target 
  127. file. At the start of the file, record the offset into the CD at 
  128. which the key sequence begins; for each 64-byte chunk of the key, 
  129. compute a CRC and append it to the corresponding chunk of the 
  130. encrypted file.
  131.  
  132. To decode such an encrypted file takes just one thing; a copy of
  133. the CD which was used as the key. The offset into the key disk is
  134. obtained from the header of the encrypted file, and 64-byte
  135. chunks are read and used to decrypt the file. If the 64-byte key
  136. sequences do not match the CRC of the original key (interleaved
  137. in the encrypted file) you know you've got a badly-formed key
  138. disk. It is not possible to recover a 64-byte key from a 32-bit 
  139. CRC.
  140.  
  141. Run-length encoding is desirable in order to stop the bit-pattern
  142. of the key from being exposed in any sparse sections of the encrypted
  143. document.
  144.  
  145. The point is, the widespread availability of music CD's gives us
  146. an incredibly cheap supply of one-time pads suitable for e-mail
  147. encryption with a high degree of integrity. The only requirement
  148. is that the recipient and the sender agree beforehand on the
  149. recording to use as a pad; this shouldn't be an obstacle to
  150. point-to-point messaging. With suitable checks, such a system
  151. should be virtually impossible to crack -- and given the ability
  152. to take a bit-stream from a CD-ROM drive and put it in a file, an
  153. encyphering/decyphering package should be so easy to write that
  154. it would be virtually impossible for any government to supress it
  155. (short of banning CD players and computers).
  156.  
  157. Even if this technique is susceptible to attack using massively
  158. parallel systems with arrays of CD-ROM drives (which I doubt), CD
  159. recorders are rumored to be due on the market within the near
  160. future, and DAT drives already are; recorded atmospheric noise would 
  161. make a suitably random key. The only proviso I should add is --
  162. don't pay for your music CD's by traceable means! (Given a
  163. listing of your music collection and your recipient's collection,
  164. it would then be a trivial task to crack a message encoded using
  165. one of the few disks you both own a copy of.)
  166.  
  167. Am I missing something? Is there some reason why all the heat and
  168. noise about encryption seems to be concentrated on encryption algorithms 
  169. which are subject to export restrictions and may be breakable via
  170. chosen-plaintext attack, rather than on simple one-time pad systems? 
  171. I think we should be told.
  172.  
  173.    [ While one-time systems are theoretically secure, this is only the
  174.      case when the pad source is sufficiently random and *only* used once,
  175.      and when an absolutely secure technique for pad distribution exists.
  176.      Music CDs or CD-ROMs would be a poor choice, since they are widely
  177.      available and are far from random data--they are in fact
  178.      highly structured (both in their data formats and in terms of 
  179.      the encoded audio itself).  Getting sufficiently random numbers
  180.      is not trivial--radioactive decay rates are frequently mentioned
  181.      as a possibility.  And you never, ever want to use the same
  182.      pad source more than once or you've essentially thrown any 
  183.      security completely out the window.  Given the logistical
  184.      issues involved, use of one-time pad systems is quite reasonably
  185.      normally restricted to the most critical of applications.  It is
  186.      doubtful that most Internet communications fall into this category!
  187.      Bottom line: Use of your "Sgt. Pepper's" CD as a one-time pad
  188.      source is definitely not a great idea! -- MODERATOR ]
  189.  
  190. -----------------------------------
  191.  
  192. Date:    Thu, 28 May 92 08:35:49 PDT
  193. From:    wpns@roadrunner.pictel.com (Willie Smith)
  194. Subject: Personal Data [Subject field provided by Moderator]
  195.  
  196. I was struck by a thought while reading the introductory Privacy
  197. Digest, should there be some way for each individual to keep, maintain,
  198. and allow access to information about them?  There would need to be
  199. some kind of authentication mechanism so people to whom I give my data
  200. to (for credit card applications for instance) would know I hadn't
  201. fudged the data, and there would have to be appropriate rules about the
  202. use of such data (once I've been approved or not for the credit card
  203. they have to dump the personal data into the bitbucket), but it seems
  204. to me that some combination of smart-card technology with cryptographic
  205. checksums and various levels of access might work.
  206.  
  207. Here's a question, what kinds of data about yourself do you consider
  208. appropriate for dissemination, to whom would you release them, and
  209. under what circumstances?  F'rinstance:
  210.  
  211.     Public data - anyone can access at any time
  212.         Name
  213.         Logical address (PO Box)
  214.         Internet address
  215.         Phone number (answering machine only?)
  216.  
  217.     'Friends&Family' data - anyone I want to tell
  218.         Physical address (street address)
  219.         Phone number (the one I answer)
  220.         License plate number
  221.  
  222.     Tax data - IRS, state tax folks only
  223.         Income from all sources
  224.         SSN (ha!)
  225.  
  226. To some extent, this is pretty much the way it works now, except every
  227. company I've ever done financial business with has my SSN, and someone
  228. with the right resources can map Internet Address --> Physical Address
  229. --> What I paid for my house.  On the other hand, maybe this is a
  230. technological solution to a non-tech problem, and we all know those
  231. don't work.  Besides, what would TRW et al do with themselves? 
  232.  
  233. Hey, can I get a list of the subscribers to the Privacy Digest?  :+)
  234.  
  235. Willie Smith
  236. wpns@pictel.com
  237.  
  238.    [ While I know you meant it as a joke, it's worth pointing out
  239.      at this juncture that the Privacy Digest subscriber list
  240.      is considered confidential and is not available.  Natch.
  241.      -- MODERATOR ]
  242.  
  243. -----------------------------------
  244.  
  245. Date:    Thu, 28 May 92 08:36:41 PDT
  246. From:    padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
  247. Subject: The Concept of Privacy [Subject field provided by Moderator]
  248.  
  249.     The concept of privacy is a transitory one and has never truely
  250. existed outside of our thoughts (else we would not need a judicial system).
  251. For all of recorded history there have existed cyphers and secret writings
  252. (though not always intentional, EBCDIC is not encryption) to maintain the
  253. privacy of those thoughts.
  254.  
  255.     Never has privacy been considered a "right" available without
  256. effort, just until recent times, the collection of extensive data about
  257. individuals had been a localized phenomena resricted to narrow regimes
  258. (and even there required the cooperation of the individuals or at least
  259. a lack of any wholesale organized resistance).
  260.  
  261.     Today, the distributed nature of information gathering, coupled 
  262. a vested interest by governments (for taxation) and institutions (for
  263. credit purposes) makes it nearly impossible to avoid any records. 
  264.  
  265.     However, this is not to say that a measure of privacy is 
  266. impossible since the current records keeping is demonstrably fallable,
  267. and while it is impossible to avoid records being made at all, it is
  268. possible to generate conflicting ones such that determination of the
  269. true record becomes impossible.
  270.  
  271.     For example, my true E-Mail address begins @tccslr... this is
  272. an alias address that will always reach me, however, the mail server
  273. does not use this when generating the return address for my mail, 
  274. instead it pick up the system name that the mail came from, in this
  275. case @hobbes... There are several other non-generic names that could
  276. have been used since I could have sent the mail from any of a number
  277. of different systems.
  278.  
  279.     I realize that this sounds more like a RISK, so I will not go
  280. into the difficulty of making an automated system use a generic name
  281. that is not transmitted, rather it is the multiple identities that
  282. becomes the privacy issue: for my E-Mail, padgett@tccslr... is the
  283. same as padgett@hobbes... is the same as ... yet to a computer each
  284. is a different individual.
  285.  
  286.     For some time I received multiple copies of a newsletter
  287. simply because at some point it had picked up more than one of my
  288. addresses. In this case it took manual intervention to remove all
  289. but one.
  290.  
  291.     In the same way, today so much information is collected for 
  292. each individual that it is impossible to sort automatically when 
  293. conflicts occur or the same individual is recorded more than once.
  294. This becomes particularly bothersome when two companies consolodate
  295. and the same individual is recorded in each slightly differently.i
  296.     This can be used by the individual to perform his/her own 
  297. classification much like a "canary trap". If mail comes for "Padsett"
  298. I know that the source is one airline's data base. Another database
  299. thinks I am "Ashley P." Yet another thinks of me as "Patrick". GIGO.
  300.  
  301.     Rather than being annoyed, for some years I have been amused
  302. by it and over the years (this is not a short term occupation) have
  303. been interested in the propagation of such multiple identities.
  304.  
  305.  
  306.                 Warmly,
  307.                     Padgett
  308.  
  309. -----------------------------------
  310.  
  311. Date:    Wed, 20 May 92 13:52:00 PDT
  312. From:    Rasch@DOCKMASTER.NCSC.MIL
  313. Subject: Privacy Rights [Subject field provided by Moderator]
  314.  
  315. There has been a lot of talk on the net, (and off the net) about
  316. whether or not it is legal or proper for a system administrator
  317. to capture keystrokes of intruders/trespassers who are using
  318. their system to break into the systems of others.  We all
  319. remember Cliff Stoll's expliots in "The Cookoo's Egg" where he
  320. traced the German Hackers through LBL by keystroke capture, and
  321. then notified downstream users that they were being attacked. 
  322.  
  323. Several people (and organizations) have taken the position that
  324. keystroke capture both violates privacy rights and constitutes
  325. illegal electronic surveillence.  I believe that, with respect to
  326. *intruders* both these arguments are specious.
  327.  
  328. Fourth Amendment
  329.  
  330. The principal protection against *governmental* intrusions into
  331. privacy rights is the Fourth Amendment to the constitution which
  332. provides that:
  333.  
  334.      The right of the people to be secure in their persons,
  335.      houses, papers, and effects, against unreasonable
  336.      searches and seizures, shall not be violated, and no
  337.      Warrants shall issue, but upon probable cause,
  338.      supported by Oath or affirmation, and particularly
  339.      describing the place to be searched, and the persons or
  340.      things to be seized.
  341.  
  342. It is important to note that this only applies to searches
  343. performed by the government. Burdeau v. McDowell, 256 U.S. 465,
  344. 475 (1921) even if the government is not acting in a law
  345. enforcement capacity New Jersey v. T.L.O., 469 U.S. 325, 336
  346. (1985). Thus, to the extent a sysop is not a "government agent"
  347. the Fourth Amendment is not implicated. 
  348.  
  349. Also, in order for there to be a Fourth Amendment violation, the
  350. individual must have exhibited an actual subjective expectation
  351. of privacy (Katz v. U.S., 389 U.S. 347, 361 (1967) (Harlan, J.,
  352. concurring)) and society must be prepared to recognize that
  353. expectation as objectively reasonable.  An intruder should have
  354. niether a subjective expectation of privacy, nor should society
  355. recoganize any expectation of privacy as "reasonable."   Thus, if
  356. you break into my system, I should be able not only to kick you
  357. off, but also to monitor what you do on my system.
  358.  
  359. Finally, the general sanction for violation of the Fourth
  360. Amendment is suppression of the illegally seized evidence and its
  361. fruits. Weeks v. U.S., 232 U.S. 383, 398 (1914) (federal search);
  362. Mapp v. Ohio, 367 U.S. 643, 655 (1961) (state search).  Thus, a
  363. private keystroke capture of an intruder would not violate the
  364. Fourth Amendment.
  365.  
  366. Electronic Surveillance
  367.  
  368. In 1986 Congress amended the Electronic Communications Privacy
  369. Act to prohibit the unlawful interception of electronic
  370. communications, including e-mail and the like.  In general, the
  371. law, contained in Title 18 of the United States Code, Section
  372. 2511, prohibits the interception of wire, oral or electronic
  373. communications.  HOWEVER, there are several provisions which
  374. would permit keystroke monitoring in certain circumstances.
  375.  
  376. First, 18 U.S.C. 2511(2)(a)(i) notes that:
  377.  
  378.      It shall not be unlawful under this chapter for an
  379.      operator of a switchboard, or an officer, employee, or
  380.      agent of a provider of wire or electronic communication
  381.      service [bbs operator] . . . to intercept, disclose or
  382.      use that communication in the normal course of his
  383.      employment while engaged in any activity which is
  384.      necessarily incident to the rendition of his service or
  385.      to the protection of the rights or property of the
  386.      provider of that service, except that a provider of
  387.      wire communication service to the public shall not
  388.      utilize service observing or random monitoring except
  389.      for mechanical or service quality control checks.
  390.  
  391. While this statute is not a model of clarity, and fails to define
  392. key terms like what is a *provider* of electronic communication
  393. service (the network administrator? the sysop?) it appears to
  394. permit electronic interception and keystroke capture it this is
  395. necessary to protect the rights and property of the provider of
  396. the service.  If the intruder is breaking in to the computer of
  397. *another* (not the provider) and the provider can easily
  398. terminate this unauthorized use, then it could be argued that the
  399. keystroke capture is not necessary to protect *his* property. 
  400. However, the statute uses the term "necessarily incident to . ."
  401. not "neccesary to" and, in light of the strong possibility of
  402. downstream liability to the provider for somehow permitting the
  403. intruder to use his system to break into another's, a strong
  404. argument can be made that keystroke monitoring of intruders is
  405. reasonable, prudent, and necessarily incident to the protection
  406. of rights and property.
  407.  
  408. In addition, 18 U.S.C. 2510(13) defines a "user" of electronic
  409. communications as:
  410.  
  411.      any person or entity who -
  412.  
  413.      (A)  uses an electronic communication service; and
  414.  
  415.      (B)  is duly authorized by the provider of such service
  416.           to engage in such use.
  417.  
  418. Since an intruder is not authorized to use the service, he is not
  419. a "user" entitled to protection under the statute.  Finally,
  420. while warning banners are helpful to demonstrate a lack of
  421. authorization to use a particular system, they are not required
  422. to demonstrate a lack of authorization any more than "No
  423. trespassing" signs are necessary to demonstrate a lack of
  424. authorization for an individual to, for example, break into your
  425. house. (a simplistic analogy admittedly)
  426.  
  427. This is, of course, only part of the story.  Many states have
  428. privacy statutes, and their own definitions of illegal electronic
  429. interception, and this does not address potential civil liability
  430. to users for excessive keystroke capture.  However, I believe
  431. that if keystroke monitoring is accomplished in a reasonable and
  432. prudent fashion, it would not run afoul of either the
  433. constitutional or statutory provisions.  Let the trespasser
  434. beware!!!
  435.  
  436. Mark Rasch, Esq.
  437. Arent Fox Kintner Plotkin & Kahn
  438. Internet: Rasch @ catwalk.dockmaster.mil
  439.  
  440. The views expressed herein are mine, and mine alone.
  441.  
  442. -----------------------------------
  443.  
  444. Date:    Tue, 19 May 92 15:40:00 PDT
  445. From:    Rasch@DOCKMASTER.NCSC.MIL
  446. Subject: Search and Seizure [Subject field provided by Moderator]
  447.  
  448. My name is Mark Rasch, and I am a lawyer at the firm of Arent Fox in
  449. Washington, D.C.  (formerly with the Department of Justice) I am
  450. interested in participating in the privacy forum, and am especially
  451. interested in issues pertaining to search and seizure laws as they relate
  452. to computerized information or electronic communications.
  453.  
  454. Does anybody have any useful information on the subject?
  455.  
  456. -----------------------------------
  457.  
  458. End of PRIVACY Forum Digest
  459. Volume 1, Number 2
  460.