home *** CD-ROM | disk | FTP | other *** search
/ Current Shareware 1994 January / SHAR194.ISO / articles / cpd315.zip / CPD315.TXT
Text File  |  1993-08-18  |  24KB  |  470 lines

  1.  
  2. Computer Privacy Digest Tue, 17 Aug 93              Volume 3 : Issue: 015
  3.  
  4. Today's Topics:                Moderator: Dennis G. Rears
  5.  
  6.     Re: Digital Cellular - was Re: First Person broadcast on privacy
  7.     Re: Digital Cellular - was Re: First Person broadcast on privacy
  8.                      Re: Enhanced Driver's License
  9.                            Encryption policy
  10.                          Re: Encryption policy
  11.                       About 'Terminal Compression'
  12.  
  13.    The Computer Privacy Digest is a forum for discussion on the
  14.   effect of technology on privacy.  The digest is moderated and
  15.   gatewayed into the USENET newsgroup comp.society.privacy
  16.   (Moderated).  Submissions should be sent to
  17.   comp-privacy@pica.army.mil and administrative requests to
  18.   comp-privacy-request@pica.army.mil.
  19.    Back issues are available via anonymous ftp on ftp.pica.army.mil
  20.   [129.139.160.133].
  21. ----------------------------------------------------------------------
  22.  
  23. Date:     Fri, 13 Aug 93 17:19:43 EDT
  24. From:     Brinton Cooper <abc@arl.army.mil>
  25. cc:       comp-privacy@PICA.ARMY.MIL
  26. Subject:  Re: Digital Cellular - was Re: First Person broadcast on privacy
  27. Organization:  The US Army Research Laboratory
  28.  
  29.  
  30. Christopher Zguris <0004854540@mcimail.com> writes, in part:
  31.  
  32. > Okay, so if you have a fully digital system without encryption using
  33. > spread-spectrum..., how long would it take your average person with a
  34. > scanner to tune around trying to follow the call?
  35.  
  36. In the cordless phone application, the power spectral density would be
  37. so low (10 to 30 dB below the power of an equivalent CW carrier), that
  38. you signal would be undetectable beyond a very short distance.  Further,
  39. spread spectrum comes in two flavors.  In frequency hopping, the carrier
  40. changes a few hundred to a few thousand times per second; hence, it's
  41. quite impossible for someone with a scanner to follow the hop pattern
  42. manually.  Further, if cryptographically safe hopping sequences are
  43. used, it's quite difficult even to automate the process of guessing the
  44. sequence.  In "direct sequence" spread spectrum, you can think of the
  45. carrier as moving around continuously in the spectrum.  Again, this is
  46. quite hard even to detect and much harder to "break" if the design is
  47. done at all wisely.
  48.  
  49. > Or are the bulk of the eavesdroppers out there using
  50. > hacked cellular phones that would automatically follow the freq. shifts
  51. > to provide continuous coverage like the real phone?
  52.  
  53. Cellular phones generally don't do spread spectrum, so hacking them is
  54. as much work (see above) as hacking any radio receiver to do the job.
  55.  
  56. The previously quoted article mentions "spread spectrum cordless
  57. phones."  The security of spread spectrum, plus the ability for many users
  58. to share a common chanel without interference makes spread spectrum a
  59. strongly viable option for cordless phones.
  60.  
  61. Finally, as Christopher Zguris points out, digital cellular telephony
  62. offers the potential to encrypt the codes so that stealing them would do
  63. no good.
  64.  
  65. _Brint
  66.  
  67.  
  68. ------------------------------
  69.  
  70. From: Phil Karn <karn@qualcomm.com>
  71. Subject: Re: Digital Cellular - was Re: First Person broadcast on privacy
  72. Organization: Qualcomm, Inc
  73. Date: Sun, 15 Aug 1993 06:17:21 GMT
  74.  
  75. In article <comp-privacy3.13.2@pica.army.mil>, 0004854540@mcimail.com (Christopher Zguris) writes:
  76. |> Okay, so if you have a fully digital system without encryption using
  77. |> spread-spectrum (by spread-spectrum I assume you mean frequencies are
  78. |> changed very often during the call), how long would it take your
  79. |> average person with a scanner to tune around trying to follow the call?
  80. |> It would seem like most of the time would be spent on tuning and little
  81. |> on listening!  Or are the bulk of the eavesdroppers out there using
  82. |> hacked cellular phones that would automatically follow the freq. shifts
  83. |> to provide continuous coverage like the real phone?
  84.  
  85. Actually, the particular form of spread spectrum we use is "direct
  86. sequence".  You're thinking of "frequency hopping".
  87.  
  88. Your standard AM/FM/SSB scanner will be useless in intercepting CDMA
  89. cellular, and in a year or so you won't be able to buy new scanners
  90. that cover the cellular band anyway.  However, as you say, the trend
  91. is already toward modifying cell phones to act as scanners, so that
  92. stupid scanner law is pretty much irrelevant.
  93.  
  94. There are some complications, however. To monitor a call in our
  95. system, you need to know the user's "private long code", which is an
  96. offset within a 2^41-1 bit PN spreading sequence that is computed at
  97. call setup time as a by-product of a one-way crypto hash function that
  98. is used for caller authentication. However, the spreading sequence is
  99. generated by a linear feedback shift register, and standard methods
  100. exist to crack these. There are also some properties of our system
  101. that could be used as "tricks" to simplify the process.  It would take
  102. some hardware and some knowhow, though.
  103.  
  104. I should mention that this applies only to the forward (cell to user)
  105. link. The reverse (user to cell) link uses a somewhat different
  106. modulation format (though it's still spread spectrum) that requires a
  107. different ASIC to demodulate. These chips won't be as readily
  108. available since they'll not be in every phone. Also, this link is
  109. tightly power controlled, so you are not likely to be able to gather
  110. enough energy unless you're very close to the person you're
  111. intercepting.
  112.  
  113. By the way, unlike current analog systems where you only need listen
  114. to the forward link to hear both sides of the conversation fairly
  115. well, you would need to intercept both links in a CDMA system to hear
  116. both sides of the call. That's because we use digital echo cancellers
  117. at the MTSO to remove the reverse link audio from the forward link
  118. signal. This is necessary for good voice quality, since the round trip
  119. delay through the system (about 100ms in the production version) would
  120. otherwise make this "sidetone" most annoying to the user.
  121.  
  122.  Isn't one of the
  123. |> other benefits of the digital system the ability to eliminate cloning
  124. |> of ESN (it's ESN for a cellular right? so many abbreviations for serial
  125. |> numbers), if the ESN is protected than a hacked phone would be more
  126. |> difficult, or there'd be no benefit in eliminating fraud which is the
  127. |> cellular industrys' main goal with digital right?
  128.  
  129. Yes, both the IS-54B (TDMA) and IS-95 (CDMA) systems will use the same
  130. mechanisms for authenticating users. Basically it involves a one-way
  131. hash function in a challenge-response protocol. Although the strength
  132. of the function is unknown (having not been published for meaningful
  133. cryptanalytic study) the basic scheme is reasonably sound. It is more
  134. cumbersome than it could have been had a public key cryptosystem been
  135. selected, though.
  136.  
  137. These mechanisms do *not* require digital voice transmission to
  138. work. They could be applied to the current analog system, because it
  139. already uses digital control methods. However, there would be an
  140. obvious backward compatibility problem, so the carriers have decided
  141. to add the authentication features to the digital systems first (since
  142. the phones have not yet been deployed in large numbers). There will
  143. probably continue to be fraud on the analog systems as long as they're
  144. around, but eventually they'll go away when they are replaced with
  145. digital.
  146.  
  147. Unfortunately, due to government pressure, there is no meaningful
  148. encryption of the actual voice data in either of the digital cellular
  149. formats. So it is probably only a matter of time before underground
  150. kits appear to decode all of the new digital cellular formats.
  151.  
  152. C'est la vie.
  153.  
  154. Phil
  155.  
  156. ------------------------------
  157.  
  158. Date: Fri, 13 Aug 93 19:42 PDT
  159. From: John Higdon <john@zygot.ati.com>
  160. Organization: Green Hills and Cows
  161. Subject: Re: Enhanced Driver's License
  162.  
  163. MP%MPA15C@mpa15ab.mv-oc.unisys.com writes:
  164.  
  165. > Steve E.  Kolodney, director of California's Office of Information
  166. > Technology describes how California is "transforming driver's licenses
  167. > into personal identification and authentication devices."
  168. > "California licenses now look more like credit cards with magnetic
  169. > stripes as well as the owner's picture, Social Security number and
  170. > thumbprint.  Kolodney said citizens can insert their enhanced licenses
  171. > into state kiosks to reserve recreational facilities and obtain state
  172. > information."
  173.  
  174. Let us stop the folklore before it takes over as fact. While all of
  175. these items (picture, thumbprint, SSN) are on file with the DMV, only
  176. the picture actually appears on the license itself. The license number
  177. is a DMV-only number and the SSN does not appear on the card, nor does
  178. the thumbprint. The DMV makes a large point to tell license holders
  179. that the mag stripe does not contain any information that does not
  180. appear on the front of the card. Since neither the SSN nor thumbprint
  181. appear anywhere on the front, it would be assumed that they are not
  182. encoded into the stripe.
  183.  
  184. All information that is kept on record is digitized, however. But the
  185. above would lead a reader to believe that showing a physical driver's
  186. license reveals information that it definitely does not.
  187.  
  188.  
  189. -- 
  190.  John Higdon  |   P. O. Box 7648   |   +1 408 264 4115     |       FAX:
  191.  john@ati.com | San Jose, CA 95150 | 10288 0 700 FOR-A-MOO | +1 408 264 4407
  192.  
  193. ------------------------------
  194.  
  195. Date: Sat, 14 Aug 1993 18:59:35 -0400 (EDT)
  196. From: Paul Robinson <TDARCOS@MCIMAIL.COM>
  197. Reply-To: "Tansin A. Darcos & Company" <0005066432@mcimail.com>
  198. Subject: Encryption policy
  199.  
  200. "Leo J. Irakliotis" <irakliot@LANCE.ColoState.Edu>, writes:
  201.  
  202. > Hope I'll get some responses here.  Is encryption in email legal?
  203.  
  204. If you are within the United States, the opinion of the NSA
  205. notwithstanding, the answer is Yes.  And there are several packages
  206. available for it including PGP and RIPEM.  Some other countries allow
  207. encryption and others do not permit it at all.
  208.  
  209. > Is it legal for an electronic mailing list, or a usenet newsgroup
  210. > to operate using encryption?
  211.  
  212. Well, unless everyone on the mailing list has decryption software of
  213. the same type as yours, it might be a little difficult for them to
  214. read the message!  
  215.  
  216. Built right into 'rn' and several other forms of torture which I
  217. laughingly refer to as usenet news readers, is the 'rot13' encryption
  218. feature which rotates each letter of the alphabet in a message forward
  219. by 13.  This is used to post the endings to movies, or anything
  220. else where the story might be spoiled if you read it in advance.
  221.  
  222. For example:     A dog
  223. is rotated to:   N qbt
  224.  
  225. (The next letter after z is a).  
  226.  
  227.  
  228.  
  229. ---
  230. Paul Robinson - TDARCOS@MCIMAIL.COM
  231.  -----
  232. The following Automatic Fortune Cookie was selected only for this message:
  233.  
  234. The life of a pious minister is visible rhetoric.
  235.                     -- Hooker
  236.  
  237.  
  238. ------------------------------
  239.  
  240. Date: Mon, 16 Aug 93 08:59:53 BST
  241. From: A.J.C.Blyth@newcastle.ac.uk
  242. Subject: Re: Encryption policy
  243.  
  244. James R Ebright <jebright@magnus.acs.ohio-state.edu> writes
  245. >In article <comp-privacy3.13.6@pica.army.mil> irakliot@lance.colostate.edu
  246. >writes:
  247. >>Hope I'll get some responses here.  Is encryption in email legal?
  248.  
  249. >Yes.  How could it be otherwise?  As long as the headers exist and the
  250. >data is ascii characters, the net will pass it along.
  251.  
  252. The net just passes characters along - so I see no reason why 
  253. encryption would not work. The real question is what do the carriers 
  254. think about such things.? 
  255.  
  256. >>Is it legal for an electronic mailing list, or a usenet newsgroup
  257. >>to operate using encryption?
  258.  
  259. Well is ROT13 encryption.............................................???
  260.  
  261. >>If encryption is against the law, please site some references.
  262. >Encryption is illegal for ham radio in the US.  Government agencies are
  263. >regulated as to the type of encryption they may use -- to make sure it is
  264. >good enough but not too good :)  I believe cross border traffic in France
  265. >must be non-encrypted.
  266.  
  267. Here in the UK electronic mail and news is carried via British Telecom.
  268. There is a law which says that for any encrypted data which is transmitted
  269. via a public carrier, the carrier must have the ability to decrypt it.
  270. Thus they all make you give them the master key.
  271.  
  272. Andrew.
  273. __________________________________________________________________________
  274.                               Andrew Blyth
  275.  
  276. Department of Computer Science,    |   
  277. 20 Windsor Terrace,                |  Tel No. +44 91 222 8972    
  278. University of Newcastle Upon Tyne, |  Fax No. +44 91 222 8788
  279. Newcastle Upon Tyne,               |       
  280. England.                           |  EMail. A.J.C.Blyth@newcastle.ac.uk
  281. NE1 7RU.                           |
  282. __________________________________________________________________________
  283.  
  284.  
  285. ------------------------------
  286.  
  287. Date: Sun, 15 Aug 1993 03:29:55 -0400 (EDT)
  288. From: Paul Robinson <TDARCOS@MCIMAIL.COM>
  289. Reply-To: "Tansin A. Darcos & Company" <0005066432@mcimail.com>
  290. Subject: About 'Terminal Compression'
  291.  
  292. A company (Inter Pact) has run a number of advertisements on 
  293. the Internet regarding their book 'Terminal Compression' which 
  294. has been subsequently released in text form which can be downloaded via
  295. FTP, with the idea that if you read it you will send them a shareware
  296. donation. I probably would never have read the book if it hadn't been
  297. made available that way. 
  298.  
  299. The copyright slugs on the text indicate publication years of 1991-1993,
  300. seemingly indicating a recently issued book.  (One of the items in the
  301. book is the mention of the new E-Mail address for the White House, 
  302. which was only created this year.)
  303.  
  304. The book has a number of holes in it which I could see through and I
  305. decided to comment.   A shorter version of this message has gone to the
  306. Telecom Digest.  
  307.  
  308. The book deals with the combined issues of some of the dangers of
  309. technology and the threats to the privacy of individuals, I have 
  310. therefore posted this review to both the Risks List and the Privacy 
  311. List.
  312.  
  313. I will mention one hole which is so obviously inaccurate as to
  314. be ridiculous:  A government agency gets a court order telling the
  315. newspaper in the story, "The New York City Times" (note: not 'The 
  316. New York Times' but the article makes clear that the paper on Sunday 
  317. is '34 pounds') to not print any articles dealing with the ability 
  318. to read CNG emissions (this is the leakage off a computer or monitor 
  319. which can be read like a radio transmitter from a distance by 
  320. electronic equipment.)  A reporter writes an article from research,
  321. and an agency gets a prohibition not just against that article - which 
  322. is a dubvious issue to get a prior restraint order against in the absence
  323. of use of government material, anyway - but that this court order is not
  324. to stop a particular article, but to completely prohibit any articles
  325. regarding that particular *subject*!  I've never heard of a judge that
  326. would even consider issuing that type of order, (an appeals court would
  327. tear him to shreds) and this assumes the paper wouldn't (1) print the
  328. article anyway and risk a contempt citation (2) print a _blank_ article
  329. and a copy of the court order.  Apparently this order was never
  330. publicized; any time a government agency tries to suppress
  331. publication of something in a newspaper it usually makes _national_
  332. headlines; the press takes threats to the 1st Amendment *very* seriously. 
  333. CNN's use of the Noriega Tapes comes to mind, and, of course, the Pentagon
  334. Papers and the A-Bomb schematics cases. 
  335.  
  336. Without intending to spoil the story, I wanted to point out that it 
  337. mentions only AT&T as the national long distance carrier; a
  338. deafening silence exists about MCI and Sprint.  Yet later in the book it
  339. mentions 'FTS-2000' the private network for government telephone calls
  340. that MCI has unsuccessfully been fighting ever since 1/2 went to AT&T
  341. and 1/2 went to Sprint, from the time of its creation.
  342.  
  343. At a point in the book, it mentions that the National Security 
  344. Agency (NSA) uses its massive computer arrays to monitor - in real 
  345. time - every telephone call connection made in the U.S., e.g. every
  346. dial call from and to any point and the call being forwarded, and to
  347. where.  This seems to forget that despite there being some 200+
  348. service points (called LATAs in the trade) in the U.S. where every
  349. call has to go into or out of, not to mention the private cellular
  350. carriers, plus local call forwarding setups and call forwarding
  351. through PBXs.  Plus private cellular companies, trunked mobile
  352. radiotelephone companies, ham radio patches... 
  353.  
  354. Even in the book it mentions that one of the calls made by some 
  355. of the criminal elements in the book went to 'a Canadian Cellular
  356. Exchange'.  I find it hard to believe that a Canadian telephone
  357. company is going to let a U.S. government agency inquire into
  358. its phone system without a court order issued by a Canadian judge.
  359. Is Pacific Bell goint to allow someone from the Canadian Department 
  360. of Revenue or Scotland Yard have the list of who owns what non-listed
  361. number without a U.S. Court Order?  I think not.  (I'll skip over the
  362. possibility of bribery for now.)
  363.  
  364. I find it a bit far fetched to believe that it is possible to put a 'pen
  365. register' on every telephone call made in the United States.  If I call
  366. into General Electric's PBX in New York, or Northrop's in Los Angeles, 
  367. is a call transferred out of it (one of perhaps 100 that go out at any
  368. minute) mine or someone else's?
  369.  
  370. Also, in the story it notes that voice, fax or data transmissions are
  371. detected and that encrypted ones are 'red flagged'.  This is a crock. 
  372. Bits are bits; there is no way to tell based on the bit stream going
  373. through a data call whether the Zmodem Binary transfer I make is a ZIP
  374. archive, an EXE file, a binary data file, a Word Perfect file, or a binary
  375. file which has been processed with PGP or RIPEM.  Bits are Bits; there is
  376. no means to differentiate between a compressed, encrypted transmission
  377. (such as a file processed with PGP) and a binary data file.  It could be
  378. possible due to echo cancellers to tell if someone is using a data
  379. transmission device; whether a fax or modem detection is possible is
  380. another thing.  And it also assumes someone doesn't switch to a
  381. non-standard method of data transmission such as combined voice and data
  382. on a compressed transmission channel.  Or local calls to non-telephone
  383. networks such as Compuserve.  Or private long distance companies that
  384. don't use Feature Group service, but simply buy commercial inward lines in
  385. some cities and lease dedicated trunk space. 
  386.  
  387. The virus issues are a little ridiculous too.  Now a couple of years
  388. ago a man named William Harrison, I think, wrote a book called 'virus'.
  389. With the same basic idea: a series of rogue computer programs can be
  390. used to allow someone to commit crimes.  Harrison's book was much
  391. better: I've had more than 12 years of computer experience as well as
  392. extensive use of MSDOS and there wasn't *a single* technical mistake
  393. in Harrison's book.
  394.  
  395. The virus issues are rather silly.  For one thing, unless someone
  396. is careless on large machines, you can't create viruses for VMS or IBM
  397. mainframes; they have fully operational supervisor state protection
  398. against runaway programs.  It might be possible to damage some data in
  399. some files if you contaminated them, but in general the kind of virus
  400. problems that are reported on PCs because every program that runs on a
  401. PC runs with unlimited privelege.
  402.  
  403. One of the viruses is mentioned that it fries the printer port and "causes
  404. smoke, then while the user checks that, damages the disk drive".  Now, I know
  405. it's possible on very old Hercules cards to program them wrong and damage
  406. them, and some IDE drive cards have errors in them and miscommanding them
  407. could damage the card or the disk (due to errors in the design.) This one,
  408. however, is a little hard to believe. 
  409.  
  410. I have said it many times: the only reason that viruses can even exist is
  411. because the operating system does not use the memory and task protection
  412. hardware built into every Intel x86 processor higher than the 80186.  A
  413. criminally negligent practice, I would say.  A person I know claims there
  414. are bugs in the 80286 task protection hardware, which I find hard to
  415. believe.  In any case, 80386 hardware contains working task protection
  416. capability.  If viruses became so serious that it was necessary to worry
  417. about them, it would be not too dificult to release the equivalent of the
  418. IBM VM/370 operating system for PCs: at the 80386 level, everything runs
  419. in user-mode protection and does not have of I have said it many times:
  420. the only reason that viruses can even exist is because the operating
  421. system does not use the memory segmentation and task protection hardware
  422. built into every Intel x86 processor higher than the 80186.  A person I
  423. know claims there are bugs in the 80286 task protection hardware, which I
  424. find hard to believe.  In any case, 80386 hardware contains working task
  425. protection capability.  If viruses became so serious that it was necessary
  426. to worry about them, it would be not too dificult to release the
  427. equivalent of the IBM VM/370 operating system for PCs: at the 80386 level,
  428. everything runs in user-mode protection and does not have kernel
  429. priveleges.  It can refuse all disk I/O except from the ROM BIOS, any
  430. attempt to access any I/O ports is refused. Without that access - which
  431. requires privelege - a program cannot do damage and can't get access to
  432. the system.  A user could well trust a program and allow it access to the
  433. screen ports.  And the protection program could either allow certain
  434. access directly or trap access and emulate it.  So there would be no means
  435. to get access to the disk drive hardware and no means to attach to other
  436. files.  The hardware doesn't permit access without permission. 
  437.  
  438. If you don't want the story spoiled, do not read this paragraph.  At the
  439. end of the story, a character responsible for some of the problem meets
  440. with the Director of the NSA and we find out that the attacks were
  441. intentional with the knowledge of the NSA Director, to cause the country
  442. to increase security on its computers.  Then, after the director speaks to
  443. the person, he has him arrested.  Now, it's one thing to 'burn' one of
  444. your own people, but nobody is stupid enough to put someone involved with
  445. a covert agency in a public trial where he can - as a legitimate defense -
  446. expose an agency's dirty laundry.  The argument of 'National Security'
  447. won't wash in a criminal case; if the defense has evidence that will
  448. exonerate it, it is entitled to present it, and if the government requires
  449. it to be suppressed, the court will dismiss the criminal complaint.  If
  450. the man was tried in a secret trial or a military court where it could be
  451. hushed up, that's one thing: but a public trial in open court in these
  452. type of circumstances is hard to believe. 
  453.  
  454. My sister is of the opinion that people don't notice technical errors
  455. in books, movies and TV shows.  I do and I'm certain other people do, too.
  456.  
  457. ---
  458. Paul Robinson - TDARCOS@MCIMAIL.COM
  459.  -----
  460. The following Automatic Fortune Cookie was selected only for this message:
  461.  
  462. "*You* killed him? I thought he just died."- The Mechanic
  463.  
  464. ------------------------------
  465.  
  466.  
  467. End of Computer Privacy Digest V3 #015
  468. ******************************
  469.