- cypherpunks-legacy - lists.cpunks.org

(Non)Privacy in Phone System...
by Phiber Optik 07 Feb '93

07 Feb '93

My last message was about LMOS/MLT, and MLT's monitoring capabilities of subscriber lines. Another phone company testing system worth mentioning is SARTS (and DACS and SMAS. That's three, but they're related.) SARTS is the Switched Access Remote Test System, and is used in testing special service circuits. And what's special service? A lot of things that AREN'T POTS (Plain Old Telephone Service). Anything from WATS service, to digital carriers (DDS, T1, etc.), and so on. And it's the hard working men and women of the aptly named Special Services Center (or just "Special Services") who oversee nearly every aspect of installation and maintenance. Ah, yes. (Clears throat) The reason I mention them is because every digital carrier goes through your friendly neighborhood BOC central office, whether it be a company's private carrier or someone's dedicated connection to the Internet (EFF's, toad's, etc.). Like MLT is a system used to test subscriber lines in real time, so SARTS is a system used to test special service circuits. In conjunction with SMAS (Switched Maintenance Access System), and the ability to jack-in with their favorite test equipment (such as the much liked T-BERD), together they make up an unbeatable arsenal in trouble shooting. So why do they screw up your leased-line service? There are three rules in maintenance: Training, training, and, of course, training. Or lack thereof. The lovely system which complements these, and even supercedes the need for SMAS points, is DACS, the Digital Access and Cross-connect System. One of its most notable abilities, is providing per-channel 64kbps (DS0) electronic cross-connection and test access to individual channels, IN ANALOG OR DIGITAL FORM, from a T1 (DS1). Sounds neat. The FBI says "It can't be done! You have to make it built in!" But it IS built in, they're just not allowed to play with it (or are they anyway?) Life is funny sometimes. I'm going to pause for now, and concentrate on my Sherlock Holmes movie. I'll see if my messages are well received, and pick it up tomorrow.

1 0

Re: 'Sunday Times' article on GSM changes
by Phiber Optik 07 Feb '93

07 Feb '93

> > Thanks for going into more detail on the REMOB fantasy. > > Can you tell the group what facilities are available that actually do > allow a technician to monitor a particular line (or group of lines), > e.g. what could a telco emp or a phone phreak do (regarding a short or > long term wiretap) if they wanted? And what facilities are *actually > used* when a court-ordered wiretap is implemented? My impression is > that the two are different. > > John > I'm glad you brought up this subject, John, because there is indeed a good deal of misinformation in this area. I'll start off with some of the numerous facilities available to a telco technician. The first I'll mention is MLT (Mechanized Loop or Line Testing), a system which is part of the LCAMOS group of systems (Loop and Cable Admini- stration Maintenance Operations System). Used by Repair Service Attendants, it's seamlessly accessed through LMOS (Loop Maintenance Operations System), when the attendant specifies a 'mask' (form type) that would involve a real- time test to be performed. At the heart of LMOS is a System 370-type pro- cessor. Attendants access the various functions through a Front End (FE) system, commonly running Unix. The data comprising customer records and their corresponding trouble reports/service histories is kept on a high- capacity storage system (nicknamed the HICAPs). Each front-end accesses data from different HICAPs for the respective areas they cover. Getting back to masks, when the attendant gets a call on 611, upon the customer hanging up, they usually issue the TEST mask, which accesses MLT which in turn establishes a metallic connection to the phone line. MLT then carries out impedance, capacitance, frequency/amplitude response tests (at 404Hz, 1004Hz, and 2804Hz, standard), tests for line activity, etc., etc. The attendant then has the option to open a trouble record (using the ESTablish mask), to initiate further testing and repair, possibly dispatching someone, etc. I'm getting a bit off topic, but I thought some background was in order rather than just saying "MLT monitors lines, so there". What I'm driving at in this scenario is that there is also a mask known as TV, for Trouble Verification. The /FORm associated with this mask requests such information as the phone number, the 3-digit employee code, a callback number for security, and the type of TV (RCA, Magnavox, Toshiba, just kidding :), types being talk, (the attendant can be heard) or monitor without speech path, to name the most relevant. It would not be impossible to substitute "someone with a computer and the know-how" in the place of the word "attendant", but don't overestimate this possibility. It's bragged about FAR more than it is actually done. But it remains a possibility. I'll continue this in successive messages, so it's in manageable chunks.

1 0

Re: CELP speech compression code at cygnus.com:/pub/celp.speech.tar.Z
by pmetzger＠shearson.com 07 Feb '93

07 Feb '93

> From: gnu(a)toad.com (John Gilmore) > > The code is up for FTP where you-all can get it. I made both compressed > and gzip'd versions (gzip gives smaller files than compress, is faster > to decompress, but slower to compress). > > -rw-rw-r-- 1 gnu cygnus 2571835 Feb 5 16:04 celp.speech.tar.Z > -rw-rw-r-- 1 gnu cygnus 2099441 Feb 5 16:09 celp.speech.tar.z > > Much of the tar file is samples of compressed and uncompressed speech, > (used for testing the code). The actual C code is about 340K uncompressed, > and there's also a Fortran version in there. > > I have a copy of the actual compression standard, but not online. > The Information Liberation Front is welcome to a copy -- maybe > I should just leave it on the table at the next meeting and hope someone > "anonymously" picks it up and scans it in. It's public domain, so > there's no special thrill from liberating it. It occured to me that some people might not get the significance of all this, so prehaps I ought to amplify. With the ability to compress speech down into the same baud rate as, say, a V.32 modem, all one would have to do to have perfectly secure voice communications is replace your phone with a setup that took in your speech, digitized it, compressed it, encrypted it, and sent it over the modem to the other side where this would be inverted. Fast enough software compression of voice would mean any PC with a DSP card and a V.32 modem could become an unbreakable scrambler. The chief problem is that the DSP needed to do decent compression is very crunchy, and encryption also tends to be crunchy, so there aren't typically enough cycles on your average PC. Of course, were someone to commercially market a board that did all this in hardware... Perry

4 3

It's the Information, (that keeps you from being) Stupid!
by Arthur Abraham 07 Feb '93

07 Feb '93

Charles E. Wareing writes: >I've heard (via Tv reports, reading, etc) that PhiberOptik (paraphrasing >here) "...knows more about Phone Systems than most Bell engineers". Why >on Earth would you respond the way you did, rather than: > > 1. Ignoring it > 2. Providing pointers to technical sources > 3. Refuting it with information. I strongly support this statement, particularly 3. -a2.

1 0

Re: White Mail
by Phil Karn 07 Feb '93

07 Feb '93

>E-MAIL RULING MAY HAMPER CLINTON ADMINISTRATION Hmm, I wonder what would happen if they start using PGP? After all, the Federal government has full rights to use RSA. (Dunno about IDEA). I have mixed feelings on this issue. On the one hand, the people have a right to know how government authority is being exercised. On the other hand, even people in government have privacy rights. And if you mandate that their email is a public record, then they will just find other ways to have private conversations. Maybe the real answer lies in not giving them so much power in the first place. Phil

1 0

PAX code posted
by dclunie＠pax.tpa.com.au 07 Feb '93

07 Feb '93

After many requests from loyal fans, I have posted the ugly and crude scripts that used to be the PAX anonymous and encrypted remailing service to alt.sources.

1 0

RE: 'Sunday Times' article on GSM changes
by DrZaphod 06 Feb '93

06 Feb '93

In Message Fri, 5 Feb 93 13:14:58 EST, phantom.com!thug(a)netcomsv.netcom.com (Murdering Thug) writes: >According to what I read it seems that the whole issue of cellular radio >signal encryption is really a non-issue. They could have the most secure >standard for radio signal encryption and it wouldn't matter. The FBI >already uses tie lines and REMOBs (remote observation units) at the telephone >switching centers to access the conversation on any particular local loop >(phone number) that they want. The reason cells are encrypting is to protect against "unauthorized persons" [i.e civilians who havn't joined the fedz and DON'T live off other people's money [ours]]. I think this is another case that shows: letting other people encrypt your data for your protection never works out to be much good. I agree with Thug in that we need to employ our OWN encryption from one end to the other. That CRYPTOCUP soundz pretty good right about now. TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod(a)ncselxsi.uucp] Technicolorized

1 0

RE: 'Sunday Times' article on GSM changes
by Eric Fogleman 06 Feb '93

06 Feb '93

(Thug writes) > According to what I read it seems that the whole issue of cellular radio > signal encryption is really a non-issue. They could have the most secure ... > What makes you think they don't have the same kind of REMOB/BLV capability > to the cellular telephone switches? I mean, if a conversation is scrambled ... If getting around GSM encryption is no problem, then why are governments pushing the issue? Eric Fogleman

5 5

CELP speech compression code at cygnus.com:/pub/celp.speech.tar.Z
by gnu 06 Feb '93

06 Feb '93

The code is up for FTP where you-all can get it. I made both compressed and gzip'd versions (gzip gives smaller files than compress, is faster to decompress, but slower to compress). -rw-rw-r-- 1 gnu cygnus 2571835 Feb 5 16:04 celp.speech.tar.Z -rw-rw-r-- 1 gnu cygnus 2099441 Feb 5 16:09 celp.speech.tar.z Much of the tar file is samples of compressed and uncompressed speech, (used for testing the code). The actual C code is about 340K uncompressed, and there's also a Fortran version in there. I have a copy of the actual compression standard, but not online. The Information Liberation Front is welcome to a copy -- maybe I should just leave it on the table at the next meeting and hope someone "anonymously" picks it up and scans it in. It's public domain, so there's no special thrill from liberating it. John

1 0

hardware scramblers
by deboni＠diego.llnl.gov 05 Feb '93

05 Feb '93

I don't know a whole lot about this subject, but I'd like to hazard a suggestion about hardware scramblers. I once upon a time saw an article in some source, perhaps Popular Science or the like, on how to build a cheap voice scrambler for telephones using a circuit called a ring demodulator (or something like that). The curcuit had a ring of diodes, looking like a bridge rectifier, with the voice and noise source feeding in and some function of the inputs feeding out. The idea was to pick a radio station at random, use its audio as a noise source, and let your partner at the other find the station that renders the signal comprehensble. This only works if both parties have access to the same radio signals, and can easily be defeated in short order by any eavesdroppers with radios, but taping your conversation does them no good. Further, it's cheap, requires no compression or sophisticated hardware, and uses the whole telephone voice bandwidth. I've never tried this, so I don't know how well it works, but since it's an old idea, perhaps it could be dressed up for modern needs. Tom DeBoni deboni(a)llnl.gov

1 0