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 , Peter Rukavina 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 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 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 ******************************