TELECOM Digest     Fri, 22 Jul 94 15:45:00 CDT    Volume 14 : Issue 331

Inside This Issue:                           Editor: Patrick A. Townson

    Re: Secret Life of Bank Machines: Simple Tech Explanations (Stan Schwartz)
    Re: Secret Life of Bank Machines: Simple Tech Explanations (Mike Deignan)
    Environmental Network Funded by Ontario Government (Joan McCalla)
    Mobitex Standard Description Wanted (Oliver Mauss)
    Book Review: "The PC Internet Tour Guide" by Fraase (Rob Slade)
    Re: CWA Charges Sprint With Illegal Action (David A. Kaye)
    Re: Conference Call Circuit? (John Lundgren)

TELECOM Digest is an electronic journal devoted mostly but not
exclusively to telecommunications topics. It is circulated anywhere
there is email, in addition to various telecom forums on a variety of
public service systems and networks including Compuserve and GEnie.
It is also gatewayed to Usenet where it appears as the moderated
newsgroup 'comp.dcom.telecom'. 

Subscriptions are available at no charge to qualified organizations
and individual readers. Write and tell us how you qualify:

                 * telecom-request@eecs.nwu.edu *

The Digest is edited, published and compilation-copyrighted by Patrick
Townson of Skokie, Illinois USA. You can reach us by postal mail, fax 
or phone at:
                    9457-D Niles Center Road
                     Skokie, IL USA   60076
                       Phone: 708-329-0571
                        Fax: 708-329-0572
  ** Article submission address only: telecom@eecs.nwu.edu **

Our archives are located at lcs.mit.edu and are available by using
anonymous ftp. The archives can also be accessed using our email
information service. For a copy of a helpful file explaining how to
use the information service, just ask.

*************************************************************************
*   TELECOM Digest is partially funded by a grant from the              *
* International Telecommunication Union (ITU) in Geneva, Switzerland    * 
* under the aegis of its Telecom Information Exchange Services (TIES)   * 
* project.  Views expressed herein should not be construed as represent-*
* ing views of the ITU.                                                 *
*************************************************************************

Additionally, the Digest is funded by gifts from generous readers such
as yourself who provide funding in amounts deemed appropriate. Your help 
is important and appreciated.

All opinions expressed herein are deemed to be those of the author. Any
organizations listed are for identification purposes only and messages
should not be considered any official expression by the organization.
----------------------------------------------------------------------

From: stans@panix.com (Stan Schwartz)
Subject: Re: Secret Life of Bank Machines: Simple Tech Explanations Sought
Date: 22 Jul 1994 13:17:08 -0400
Organization: PANIX Public Access Internet and Unix, NYC



Peter,
 
  I think I can help you with a couple of your questions, based on my
personal experiences (and former employer).

> I'm looking for simple technical explanations of how bank machines and
> bank machine networks work for a radio series on "everyday technology"
> I'm working on.  Specifically:

> (1) How is my "PIN Number" kept secret from everyone but me?  Is it 
> stored on the magnetic stripe on my "bank card" or in some form in the 
> bank's "central computer?"  Or somewhere else?

The PIN is not on the card.  In our application, a PIN-offset is
encoded on the card.  The offset is sent with the PIN from the
transaction terminal (ATM or POS) and when combined with an algorithm
at your bank, produces the anticipated result.  Any other result will
cause a response of "invalid PIN".

> (3) How is the traffic between different banks' networks (and different 
> "networks of networks" like Cirrus and Plus and, here in Canada, Interac) 
> handled?  Do all banks' computer speak "the same language" in the same 
> way that all Internet computers speak TCP/IP?

Interbank transaction processing is done through privately owned
"clearing houses" that basically have a big internal table of where to
steer each transaction based on card number (ususally the first 4 to 6
digits).  Each bank doesn't have to speak the same language, as long
as they can communicate with the clearing house.

> (4) I'm assuming the process of, say, withdrawing $20 from a machine goes 
> something like this:

>  - I stick my card in, card reader gets my "client number"
>    from the magnetic stripe, asks me for my PIN Number,
>    somehow verifies that I entered the right one (or not)

>  - the local computer in the bank machine presents me with a 
>    menu of possible transactions (perhaps based on information
>         it got about my various accounts from the "central
>     computer"?) and takes me through a series of questions...
>    Withdraw... Savings... $20.00

>  - the bank machine computer the packages up the request
>    and sends it off to "central" which verifies (a) that I
>    have enough money in my account and (b) that I haven't
>    gone over my "daily limit" and, if everything's okay,
>    sends a signal to this effect back to the bank machine,

>  - the bank machine, having received an "okay to dispense"
>    signal, spits out $20 and sends back a "debit $20 from
>    his account" message to "central."

It depends on the bank and the system.  If you're not at your own
bank, it's more than likely that PIN verification is packaged with the
withdrawal request, thereby cutting down on transmissions and
transaction time.  If you're at your bank, the opportunity exists to
transmit more information between the host and the ATM, so PIN processing 
might be done up front.  You will also have more transaction options
at your own bank.

> (5) How do bank machines "count money?"  This would seem like a hard
> sort of thing to pull off, especially given that you have to be right
> pretty near well 100% of the time.

The first part of the process is usually a modified currency counter
(the kind that you see behind the tellers at your local bank).  For
verification, I know that some of them use a light sensor, which
passes each bill over a beam of light.  If the lens on the other side
of the bill doesn't see the correct amount of light, then the bills
are dumped into a "reject" bin because the machine assumes that it has
more than one bill stuck together.

> (6) Besides the recent "Chemical Bank computer error results in double
> withdrawls from 100,000 accounts" problem in February, are there other
> large-scale problems which have occured with banking machine networks?

Chemical Bank's problem was not related so much to the ATM's
themselves as it was to the bank's overnight batch processing.
Apparently the transaction file was fed into the jobstream more than
once during the course of the run.  While this does happen on
occasion, it's usually corrected before any customers are affected (or
aware) of a problem.

> (7) A 1992 New Scientist article talks about how the process of
> "shouldering" people when they're entering their PIN, then collecting
> their carelessly discarded receipt and, using the card number printed
> on the receipt, using "readily available equipment which costs less
> that $1600" to crank out a duplicate card using "published documents"
> as a guide.  Is such equipment still "readily available" and what
> would the "published documents" be?  Is this a widespread problem in
> the U.S.?

Yes, see Long Island Newsday dated 7/21/94.


Stan

------------------------------

From: md@pstc3.pstc.brown.edu (Michael P. Deignan)
Subject: Re: Secret Life of Bank Machines: Simple Tech Explanations Sought
Date: 21 Jul 1994 13:51:31 GMT
Organization: Center For Political Incorrectness & Environmental Ignorance
Reply-To: mpd@anomaly.sbs.com


In article <telecom14.329.3@eecs.nwu.edu>, Peter Rukavina <peter@crafts-
council.pe.ca> writes:

> I'm looking for simple technical explanations of how bank machines and
> bank machine networks work for a radio series on "everyday technology"
> I'm working on.

Several years ago when I was working for a national consulting company
here in the northeast I had the opportunity to work on ATM software at
banks, so I can provide a little generic information.

> (1) How is my "PIN Number" kept secret from everyone but me?  Is it 
> stored on the magnetic stripe on my "bank card" or in some form in the 
> bank's "central computer?"  Or somewhere else?

Several methods that were used are as follows:

1. The PIN number is stored on the mag stripe. It is then verified at
   the ATM when you punch your code in.

2. The PIN is stored electronically at the bank's central computer. When
   you enter your PIN at the ATM, it is sent to the central computer and
   verified, with a result code being returned to the ATM (ok to 
   proceed, bad pin, etc.)

3. Some banks didn't allow you to pick your PIN. Instead, each ATM card
   had a serial number. A PIN was automatically generated using an
   algorithm based upon that serial number. The ATM software could then
   read your card's serial number and determine what your PIN should be,
   prompt you for it, and see if it matches.

This was before the big interbank ATM networks were established, though, 
so now they adhere to those standards if they're a member of a large
ATM network.

> (2) How is the security of tranmissions between bank machines and the 
> "central computers" ensured?  I have an old "Discover" magazine article 
> which talks about a 64-bit digital key generated by "white noise" which 
> is placed in both bank machine and central computer and used to DES 
> encrypt everything that passes between the two... is this accurate?

Again, different systems vary. I've never seen a system that uses the
method you describe, but then again, I only worked at regional banks.
Many ATM's are intelligent and do a significant amount of processing
on their own; all they need to do is send a small message back to the
central computer to effect an account transaction and get a one-byte
reply code back. For instance, a typical data stream to the central
computer will consist of a transaction code, account number, and
amount. So, you may be talking 20 bytes total going to the central
computer, and then a one-byte reply code being returned (00=okay,
01=insufficient funds, 02= account closed, etc.)

Some banks use encryption to encrypt the data stream going from the
ATM to the central computer, others don't. Encryption schemes vary
depending on what the bank is comfortable with. Some use revolving
encryption which changes on a regular basis.

> (3) How is the traffic between different banks' networks (and different 
> "networks of networks" like Cirrus and Plus and, here in Canada, Interac) 
> handled?  Do all banks' computer speak "the same language" in the same 
> way that all Internet computers speak TCP/IP?

Most ATM's are programmed to recognize a native card (ie one from the
ATM's bank) and a foreign card. A whole set of subroutines will exist
for foreign cards. The transaction requests are still sent back to the
central computer which then knows to route the request to a Cirrus/Plus 
clearing house. Cirrus/Plus publish their own standards by which
member banks must format their data and communicate with their networks.

> (4) I'm assuming the process of, say, withdrawing $20 from a machine goes 
> something like this:

Essentially, the scenario you paint is sometimes used.

> (5) How do bank machines "count money?"  This would seem like a hard
> sort of thing to pull off, especially given that you have to be right
> pretty near well 100% of the time.

"Count money" how? In dispensing? Its fairly mechanical and works
almost flawlessly.

> (7) A 1992 New Scientist article talks about how the process of
> "shouldering" people when they're entering their PIN, then collecting
> their carelessly discarded receipt and, using the card number printed
> on the receipt, using "readily available equipment which costs less
> that $1600" to crank out a duplicate card using "published documents"
> as a guide.  Is such equipment still "readily available" and what
> would the "published documents" be?  Is this a widespread problem in
> the U.S.?

Depending on the bank's standards, you could conceivably do this. You
need a source of blank magstripe cards, and a magstripe programmer/
reader.  Most bank cards adhere to a standard for placing account numbers, 
pins, etc., in certain locations (otherwise how could you use your
card in a foreign machine?) so if you can find that document in your
research, then you should, fairly easily, be able to make a basic card
which will work at the ATM. About a year ago in MA a couple of guys
set up fake ATM machines at local shopping malls, and collected
people's account/pin numbers, manufactured their own duplicate cards,
and then started withdrawing money from people's accounts.

------------------------------

From: mccallj@gov.on.ca (Joan McCalla)
Subject: Environmental Network Funded by Ontario Government
Organization: Government of Ontario
Date: Thu, 21 Jul 1994 17:56:22 GMT


July 21, 1994

       Ontario's First Electronic Environmental Network Receives 
                       $1.2 million from Province

      TORONTO - The jobsOntario program is providing a $1.2 million
grant to launch the first province-wide electronic environmental
network Ontario Minister of Economic Development and Trade Minister
Frances Lankin announced today.

      The $3.1 million Environmental Inter-Network (EIN) will link
hundreds of separate sources of environmental information into a
single, user-friendly network.  It is also expected to create some 70
new person- years of direct employment in its first three years and
result in 14 to 20 full-time permanent jobs.

      "Our investment in Ontario's information infrastructure is an
investment in the jobs of the future," said Ms. Lankin.  "It helps us
develop the skills, technology and network capacity needed in a
modern, vibrant economy. This network will use Ontario-developed
technology and foster other network-related products and services."

      The project was developed by Ontario Environmental Network
(OEN), an association serving more than 500 Ontario environmental
groups, and NirvCentre(Web), a not-for-profit network operation. Other
partners include the Recycling Council of Ontario, the International
Institute for Sustainable Development, York University and Open Text
Corporation.  Within three years the network is expected to have 1,300
active users including not-for-profit organizations, corporations,
government agencies and individuals.
      
      "Projects such as the EIN demonstrate that effective
telecommunications infrastructure can be used in innovative ways,"
said Ms. Lankin.  "This network will boost efforts to protect the
environment by making it easier for groups and individuals to access
information and communicate with each other."

      She noted that the network is itself environmentally friendly,
since it reduces the need for paper, while disseminating large amounts
of information. The network is expected to be fully operational by
this September.

      "Building on state-of-the-art technology, EIN is a ground-breaking 
effort to build an on-line community of information providers,
environmental organizations, businesses and individuals," said Kirk
Roberts, Executive Director of NirvCentre(Web).

      "For environmentalists using the EIN, everything from research
to networking to public education can now be achieved more
effectively," said Irene Kock, Co-chair of the Ontario Environment
Network Steering Committee.

      "Today's announcement reflects our sector development approach
to economic renewal," said Ms. Lankin.  "We are working with various
sectors, including telecommunications, computing and environmental
protection, to help our economy become more competitive and create the
high-skill, long- term jobs of the future."

      Provincial support for this network comes from the Ontario
Network Infrastructure Program, a $100 million jobsOntario Capital
initiative. It was established to help increase access to and the
development of an advanced information infrastructure throughout
Ontario.  This investment was recommended in the province's
telecommunications sector strategy, released in February 1993.


Contacts:   Lucy Rybka-Becker, Minister's Office
            (416) 325-6909

            John Cooper, Marketing & Public Affairs Branch
            (416) 325-6694
      
            Internet address: mccallj@gov.on.ca

Editor's Note: contact lists of Ontario Environmental Network members
located throughout the province are also available.

------------------------------

From: mauss@manekenpix.informatik.rwth-aachen.de (Oliver Mauss)
Subject: Mobitex Standard Description Wanted
Date: 21 Jul 1994 13:06:41 GMT
Organization: Rechnerbetrieb Informatik - RWTH Aachen


I have unsuccessfully been looking for a detailed description of the
link layer for the Ericsson Mobitex system. I know about the frame
structure and coding scheme, but would also like some information on
the specified channel model, modulation/filtering parameters, required
BER, etc. Can anyone give me a hint where to look?

Also, I would appreciate it if anyone knew any papers describing
Mobitex modem designs.

Thanks in advance,


Oliver C. Mauss            | Aachen University of Technology - RWTH
                           | Integrated Systems for Signal Processing
phone: +49 (0)241 80 7632  | ISS - 611810
fax:   +49 (0)241 8888 195 | Templergraben 55
mauss@ert.rwth-aachen.de   | 52056 Aachen, Germany

------------------------------

Date: Thu, 21 Jul 1994 15:03:59 MDT
From: Rob Slade <roberts@decus.ca>
Subject: Book Review: "The PC Internet Tour Guide" by Fraase


BKPCINTG.RVW  940428
 
Ventana Press, Inc.
P.O. Box 2468
Chapel Hill, NC 27515
919/942-0220  FAX 919/942-1140
dilennox@aol.com  lwenzel@aol.com
"The PC Internet Tour Guide", Fraase, 1994, 1-56604-084-1, U$24.95
mfraase@farces.com
 
Fraase's book is a real grab bag.  Written (on a Mac) by someone who
admits to having an aversion to MS-DOS, it really has little system
specificity other than the PC basis of the programs on the included
disk.  It has some good information, some excellent writing, some
gaps, some errors, some promises and a lot of graphics (of which the
author seems inordinately fond).
 
Overall, the discussion of Internet applications and use covers the
major topics, and gives the new user a reasonable understanding of the
basic tools.  The chapter on "Getting Connected" proposes a very
broadly based and helpfully divided overview of the various options.
It starts with talk of the university, government, and corporate
options, of which many potential users remain unaware.  The difference
between dedicated dial-up IP and dial-up terminal is raised, although
the promised discussion of dial-up terminal and commercial "email
gateway" access never seems to materialize.  The personal and
community aspects of the net get a lot of space.  Some important, but
often neglected, aspects of file characteristics and transfer are
raised, albeit briefly.  The "Neat Stuff" section really does have
some interesting and little known resources.
 
On the other hand, the quality of the information is very uneven.  The
setup of the included programs is said to be easy, but I suspect that
a very thorough familiarity with modems would be needed in view of the
extremely brief instructions for the SLIP software configuration.  The
"points of interest" are interesting, but seldom have anything to do
with the surrounding text.  (A pleasant exception to this are some of
the useful and helpful points in the email section.)  The directions
on how to use and access resources on the net are *not* going to be
helpful unless you are using the included software (and that type of
dial-up connection).  Every set of directions starts with UMSLIP, and
most use gopher, even where email or telnet would be faster and more
efficient.  There are a number of dated addresses, as well as some
that are just plain wrong (one suspects through bad editing).
Seasoned Internauts will be able to correct these errors, but then,
seasoned Internauts aren't likely to be using the book.  (Some of the
errors relate to DOS rather than the net: the LHA program, for
example, produces files with an .lzh extension rather than  .lha.  Again, 
MS-DOS users familiar with BBSes are unlikely to have problems.)
 
At one seminar I was told to promote this book because it had
software.  The software included may be useful, depending upon the
user's level of access to the net, but is neither necessary nor
unique.  Providers that do handle IP access can also handle terminal
access, but many access providers cannot provide IP access at all.  In
any case, (as the book states almost every time UMSLIP is mentioned),
both UMSLIP and Minuet are shareware, and available online.  (It is
also interesting to note that the book acknowledges the superiority of
PPP to SLIP -- but provides SLIP.)  (In any case, I can't comment on
the program disk -- my review copy came without one.)
 
An interesting feature is the promise of an electronic update to the
guide, distributed via electronic mail.  The book has a coupon for two
of the quarterly updates free; regular price is $25 per year.  I'll
try to add a note to a later edition of this review.
 
For those who want to set up a direct IP connection quickly, (particularly 
for residents of Minnesota,) this is probably your book.  The tools
are "real" TCP/IP programs, without the UUCP limitations of "The DOS
User's Guide to the Internet" (cf BKDOSINT.RVW).
 
copyright Robert M. Slade, 1994   BKPCINTG.RVW  940428. Distribution
permitted in TELECOM Digest and associated newsgroups/mailing lists.


Vancouver      ROBERTS@decus.ca    
Institute for  Robert_Slade@sfu.ca 
Research into  rslade@cue.bc.ca    
User           p1@CyberStore.ca    
Security       Canada V7K 2G6      

------------------------------

From: dk@crl.com (David A. Kaye)
Subject: Re: CWA Charges Sprint With Illegal Action
Date: 21 Jul 1994 15:25:18 -0700
Organization: CRL Dialup Internet Access  (415) 705-6060  [login: guest]


Phillip Dampier (phil@rochgte.fidonet.org) wrote:

> Sprint Long Distance illegally shut down a San Francisco subsidiary
> that markets services to the Spanish-speaking community just one week
> before the 177 workers were set to vote on unionizing in a National
> Labor Relations Board election, the Communications Workers of America
> declared in charges filed with the NLRB.

According to the afternoon {San Fransisco Examiner}, Sprint regularly
told its managers that it was their "duty" to prevent unionization
votes in their offices and that they should do anything in their power
to prevent them.  Apparently, according to the article, this is policy
througout Sprint, not just in the La Familia operation.

Effective two days ago I am making all my LD calls with 10288 until I
get around to changing my dial-1 situation.  Nominally, I make about
$250 of inter-LATA calls a month.  At least AT&T is unionized, gives
rate info instantly, and has a domestic partners plan in action.
Neither MCI nor Sprint can offer those.


dk@crl.com       National Car Rentals now includes domestic
San Francisco  partners in rental agreements at no extra cost!

------------------------------

From: jlundgr@eis.calstate.edu (John E. Lundgren)
Subject: Re: Conference Call Circuit?
Date: 21 Jul 1994 19:52:30 -0700
Organization: California Technology Project of The Calif State Univ


Todd McLaughlin <toddm@rahul.net> writes:

> I've made a simple circuit between my two phone lines so I can host a
> conference call.  The sound quality is rather disappointing, though.
> The second call that is made sounds very distant.  I'm guessing a
> simple amplifier would fix the problem.  A friend said I needed to get
> a phone transformer, but he didn't seem to know much about it.  Has
> anyone else done this with promising results?  Or if someone can tell
> me a bit about the phone transformer ...

The transformer that you need is really two hybrid phone patches 
back-to-back.  The two wire circuit has to be split into a four-wire 
circuit with a send pair and a receive pair.  Then the amplifiers (2) can 
be put from the send pair of the first line to the receive pair of the 
second line, and vice-versa.  But it has to be a good match so that you 
won't get ringing and instability.

Another method is to use a gyrator, or negative impedance converter, I
think that's what the phone co used to call it.


John Lundgren  jlundgr@eis.calstate.edu 
jlundgre@pop.rancho.cc.ca.us 
Rancho Santiago College - 17th St. at Bristol - Santa Ana, CA 92706

------------------------------

End of TELECOM Digest V14 #331
******************************

