Magnetic stripe technology Figures and listings are at the end. Because of their widespread use, most magnetic cards adhere to well-defined standards that describe the physical and magnetic characteristics for a magnetic stripe on a plastic card. These standards outline specifications for a storage format and information interchange. This does not preclude other encoding techniques or additional data tracks for specific applications, but in most cases it makes sense to adhere to at least the basic constraints. This gives you the choice of using any commercially available magnetic encoders for your application. The technique used for encoding magnetic cards is known as "Two-Frequency, Coherent Phase Recording". Allowing for the representation of single-channel, self-clocking serial data, this methodology is generally referred to as F/2F. Self-clocking is achieved by combining data and clock bits together in a continuous, synchronous sequence. In this scheme, an intermediate flux transition signifies a one bit and the absence of an intermediate flux transition denotes a zero bit. Three data tracks defined for use on standard magnetic cards each possess different bit densities and encoded character sets. The average bit density of track 1 is 210 bits per inch (bpi). Track 1 characters are made up of six data bits and an odd parity bit, encoded with the least-significant bit first and the parity bit last, yielding a 64-character set. Taking the number of bits per inch and the number of bits per character, you can see track 1 has the capacity to hold 79 characters. Track 2 has a bit density of 75 bpi, and track 3 uses 210 bpi. Both of these tracks allow the representation of a numeric-only character set. The characters for tracks 2 and 3 are encoded using a 4-bit binary-coded decimal subset with odd parity and, like track 1, are encoded with the least significant bit first and the parity bit last. The lower density of track 2 allows up to 40 numeric characters, where 107 numerics can be squeezed onto track 3. The actual number of usable characters will be fewer since you also have the Start Sentinel, End Sentinel, and LRC characters. Though sometimes magnetic cards are moved past the read head mechanically, most applications rely on manually moving the card, either through a slotted reader or into an insertion-type reader. Typically the swipe rate is 5-20 inches per second (ips), with 50 ips being the fastest most card readers can handle. Of course, moving the card by hand will not only result in varying the absolute card velocity but, will also introduce incremental speed changes as the card accelerates and decelerates past the pickup. The F/2F scheme is very forgiving of such speed fluctuations. For all 3 tracks, the fundamental data format is similar and consists of the following elements: First, leading zero bits are encoded to indicate the presence of an encoded magnetic card and provide synchronization pulses to the read head electronics and ultimately to the controller. Next, the Start Sentinel character is encoded which indicates the start of the actual data. The coded data follows. Next, the End Sentinel terminates the data portion of the card and followed by an LRC byte (used for error detection). The LRC is essentially a horizontal parity calculated by an exclusive-OR of all the data bits from the Start Sentinel to the End Sentinel (inclusive). Finally, trailing zeros follow the LRC and fill out the remainder of the card. ANATOMY OF A MAGNETIC CARD The magnetic tracks have inherent characteristics based on details such as code set and bit and character densities. International organizations such as Mastercard and VISA impose additional constraits for their participating members and standards exist for bank debit cards and ATM cards as well. These rules specify the exact content and format of each data field in aech track as well as the intended uses for the tracks. Naturally, for nonfinancial uses, it is not necessary to comply with these standards. For dedicated uses such as access control, people tracking, and material tracking, adhering to the minimal standards is adequate. The most-often-used track is track 2, although it offers the lowest inform- ation density of the three. It contains all the information that is normally used for credit card transactions. When a customer name is required, track 1 must be used since it is the only track that permits alphanumeric data. Track 3 is specified for numeric-only data, but is unique. It is intended for change- able data and consequently may not only be read but may be rewritten by the transaction-handling equipment. A multitude of data fileds are contained in these various tracks. Figure 1 shows a brief run-down of what is generally placed on tracks 1 and 2. REAL CARD READERS The recovery of magnetically encoded F/2F data can be accomplished directly with the use of just about any microcontroller. There are no particular difficulties in deciphering the raw F/2F data stream and many early magnetic read heads contained nothing more than signal amplifiers and line drivers. These are now artifacts since all modern magnetic read heads contain integ- rated F/2F bit recovery circuitry and interface with the host controller in a standard fashion using three wires: CARD PRESENT, CLOCK, and DATA. The read heads usually rely on a single chip to perform the linear signal conditioning, sychronization, and recovery of individual bits from the data stream. The Mag- Tek 21006505 IC is representative of this type of data recovery circuit and its functionality is depicted in figure 2. Linear conditioning consists of raising the level of the magnetic pickup's input signal, rejecting common-mode noise, conditioning and detecting the signal, and finally providing a digital output for susequent processing. The enable/disable counters provide initialization for the recovery section. The recovery section locks onto the data rate and recovers the individual data bits from the data stream. The oscillator section provides the clocks for the recov- ery section and for the enable/disable timers. Card present goes low after 8 or 9 flux reversals are seen from the magnetic pickup and will return high about 50 ms after the last flux reversal. The strobe line signals that data is valid and is active low. The data pin indicates a one bit when it is low. Raw F/2F data can also be picked directly off the chip. The data rate for a high-density track scanned at 50 ips comes to 10500 bits per second (bps). This results in a transfer rate of 1500 characters per second for the 7-bit elements used on track 1, and 2100 characters per second using the 5-bit elements of track 3. I either case, this translates to a new bit arriving at the controller just under every 100 us (microsecond). Even the most anemic controller should be able to keep up. With resonably good coding techni- ques, there should be no problem handling the entire data sampling phase on an interrupt-driven basis. The low-density (track 2) data flows at a more pedes- trian 3750 bps, yielding 750 5-bit characters per second, or a new bit every 266 us. Since most dual-track read heads provide track 1 and track 2 data, this indicates that handling both tracks simultaneously is feasible under interrupt control. Keep in mind that 50 ips is a rather fast scan rate; 20-30 ips is probably a more realistic limit. MAGNETIC BIT STORMS When approaching a problem such as decoding magnetic cards, it pays to spend some time looking at the overall picture before starting to write the code. At first glance, it would seem that organizing the data into the prevailing element size during the sampling interval would make decoding easier. This could be easily done by ignoring all the leading zeros, with actual data storage comm- encing with the first one bit. Of course, this approach assumes you're getting good data. The fact that the data recovery is handled using well-proven hard- ware makes this assumption valid. If all you need to do is decode the card in a forward direction, then going about things as I just described makes sense and reduces the coding effort to a trivial exercise. If you have to support reverse decoding then this is not the optimal solution. Having considered the tradeoffs of being able to decode a magnetic card in both forward and reverse directions, I decided to structure the program to work equally well in either direction at the cost of a slight increase in initial complexity. The first step in decoding is to acquire the serial bit stream. This can be done using a dedicated sample loop or, with a little more work, using interrupt processing. Since the idea is the same regardless of the details, I decided to use a sample loop in my demonstration program (listing 1). The code simply records the incoming data stream and deposits the data in a sample buffer a byte at a time. Sampling begins when Card Present returns idle. Any incomplete byte that has been partially assembled at the time when sampling terminates is simply discarded. The abundance of leading and trailing zeros allows losing some bits at either end causing any problems. Once the sampling interval completes, control is transferred to the decoding algorithm. Presented in listing 2, the track-1 decode algorithm consists of nothing more than some initialization and the essence of the decode logic. Limiting the gyrations contained in the main body of this routine not only makes the logic easy to follow, but permits the same code to handle the decoding in either a forward or reverse direction. The initial entry point assumes a forward decode attempt and sets up the necessary flags, pointers, and counters before jumping into the main initial- ization code. After initialization, the sample buffer is scanned for the first one bit, at which time a 7-bit element is assembled. If the parity is correct and the character code checks out to be a Start Sentinel, the code proceeds and starts pulling successive data elements from the sample buffer. If the data element is not an End Sentinel, the character is translated to ASCII and stored in the decode buffer. Should an End Sentinel be detected, the program extracts the next character, which is assumed to be the LRC byte, and finally checks the calculated LRC for a value of zero. The checks and balances included in the execution of this loop include things such as parity, a cumulative LRC, and checking to make sure I haven't run out of samples. If everything checks out, the program terminates and returns with the DPTR pointing to the decoded data buffer and the character count contained in ACC. Should a decode failure occur, a test is performed on the direction flag and if this is an attempt at a forward decode, the routine jumps to the reverse initialization entry point. The reverse entry is similar to the forward decode entry but sets up the sample pointer to the end of the sample buffer and sets the direction flag to indicate a reverse operation. The routines contained in the intermediate layer are shown in listing 3. The meaning and operation of these routines should be apparent. The key routine in this section is GET_BIT, which picks off the next bit from the sample buffer, essentially restoring the sequential nature of the initial magnetic bit stream. FIND_START is used to synchronize with the first one bit. GET_CHAR first checks to make sure it hasn't run out of samples, then assembles the next 7-bit data element while doing a parity test and LRC calculation. Any problems encountered here are sent back to the caller and are handled there. STORE_CHAR translates and deposits the data character into its respective location in the decoded-data buffer and increments the character counter. Listing 4 shows the low-level code. These routines perform the most rudiment- ary functions and operate in accordance with the direction flag. INDEX_PTR either increments or decrements the sample pointer, POSITION_BIT likewise does either a right or left shift and LOCATE_BIT returns the state of the least- or most- significant bit of the accumulator. GO AHEAD, TAKE A SWIPE Let me touch on a few additional points that may not be immediately apparent before signing off. Storing the sampled data in a continuous stream makes the sample routine work equally well with the various bit configurations used for the different recording tracks. This would not be easily attained if you tried to generate a particular element format during sample time. Furthermore, if you look at the differences between the encoded character sets and the bit formats for the different tracks, you will find that they differ in only a few areas. With a few minor changes, such as the defined Start Sentinel, number of bits per element, and character translation method, the decode routine I've shown could easily be coerced to handle the decoding of any of the standard magnetic tracks. As a matter of fact, by recoding and redefining the hard-coded constants as variables, these could be set up for the particular data track at execution time before invoking the decode function. Doing so would not only save program memory, but would also allow you to use a routine you were comfortable with. ******************************************************************************* FIGURE 1 _____________________________________________________________________ TRACK 1 |SS|FC| PAN |FS| NAME |FS| ADDITIONAL DATA |ES|LRC| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Notes: Track 1 is limited to 79 characters including SS, ES, and LRC. Mastercard PAN is variable up to 16 characters maximum. VISA is 13 or 16 characters, including mod-10 check digit. SS: Start sentinel (%) FC: Format code FS: Field separator ({) ES: End sentinel (?) LRC: Longitudinal redundency check character PAN (primary account number): 19 digits max. NAME: 26 alphanumeric characters max. ADDITIONAL DATA: Expiration date 4 Restriction or type 3 Offset or PVN 5 ______________________________________________________________________ TRACK 2 |SS|FC| PAN |FS| ADDITIONAL DATA |ES|LRC| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SS: Start sentinel (;) (hex B) FS: Field separator (=) (hex D) ES: End sentinel (?) (hex F) LRC: Longitudinal redundency check character PAN (primary account number): 19 digits max. ADDITIONAL DATA: Expiration date 4 Restriction or type 3 Offset or PVN 5 ***************************************************************************** FIGURE 2 HEAD SIGNAL __/~\__ __/~\__ __/~\__ __/~\__ __/~\__ __/~\_______ `-` `-` `-` `-` `-` ____ _______ __________ ____ CARD PRESENT |______________________________________________| ____ ____ _____________________ ____ ____ _____ READ DATA |____| |_________| |_________| ____ ______ __________ __ __ __ __ __ __ __ __ __ __ READ STROBE |__| |_| |_| |_| |_| |_| |_| |_| |_| |_| | | 0| 1| 0| 1| 1| 0| 1| 1| 0| 0| ___ HEAD 1-----X---X--------13 |MAG| 9--C2-R3 R1 C1 |TEK| | HEAD 2-----X---X--------12 | | 10-----X--X | | | | X---X------11 | | | R5 X-X R2 C6 | | 6------|--X | | X---X-------8 | | | +5VDC --------------X--R7--X--------X-|-----------------14 | | 7-----C3 | |+ | | | ____ R6 C5 | | | 16----DATA | X----------|------------------5 | | ______ ____ _______ | | X------------------2 | | 15----STROBE CARD PRESENT -------X------|-----------------------------1 | | | X----X-----3 | | | C4 R4----4 | | GND------------------------X------------------X |___| R=RESISTOR(Values weren't given) C=CAPACITOR(Values weren't given) X=CONNECTION BETWEEN WIRES MAG TEK is the Mag-Tek 21006505 ***************************************************************************** LISTING 1-- Using several externally defined routines, a sample program to read a stripe and store it in a buffer is very short. PUBLIC READ_MAG1 EXTERN MS1_BUF (XDATA) ;sample buffer EXTERN MS1_LIM (NUMBER) ;sample limit EXTERN MD1_BUF (XDATA) ;decode buffer EXTERN CP (BIT) ;card present bit EXTERN M1_CLK (BIT) ;clock bit EXTERN M1_DQ (BIT) ;data bit M1_SS EQU 5 ;start sentinel M1_ES EQU 1FH ;end sentinel ; SEG CODE ;Sample and decode magnetic track 1 ; output: ACC contains character count. ; DPTR points to data buffer READ_MAG1 PROC CALL MAG_SAMPLE JZ L?RM1 CALL MAG1_DECODE L?RM1: RET ENDPROC ;General-purpose magnetic sampling routine ; output: ACC contains sample count MAG_SAMPLE PROC MOV DPTR,#MS1_BUF MOV R1,#0 ;sample counter L?MS1: MOV R0,#8 ;bit counter L?MS2: JB CP,L?MS4 JB M1_CLK,L?MS2 MOV C,M1_DQ L?MS3: JB CP,L?MS4 JNB M1_CLK,L?MS3 CPL C RRC A DJNZ R0,L?MS2 MOVX @DPTR,A INC DPTR INC R1 ;sample counter CJNE R1,#MS1_LIM,L?MS1 L?MS4: MOV A,R1 ;final sample count RET ENDPROC ******************************************************************************* LISTING 2-- Once the serial bit stream has been acquired, the decoding algorithm takes over. ;Bidirectional magnetic track 1 decode routine ;input: sample count in ACC, output: ACC contains character count ; DPTR points to decoded data buffer ;Reg. usage for this routine (includes subroutines) as follows: ;R5: Direction flag, 0=forward ;R4: Cumulative LRC register ;R3: Decoded character counter ;R2: Nondecrementing sample count ;R1: Decrementing sample count ;R0: Bit syncronizing counter MAG1_DECODE PROC ;1st pass, setup for forward decode attempt MOV R5,#0 ;indicate forward decode MOV DPTR,#MS1_BUF ;point to start of buffer MOV R1,A ;sample counter MOV R2,A ;sample count JMP L?M1D1 L?M1D0: ;2nd pass, setup for reverse decode attempt MOV R5,#1 ;indicate reverse decode MOV DPTR,#MS1_BUF MOV A,R2 ;sample count DEC A ADD A,DPL MOV DPL,A CLR A ADDC A,DPH MOV DPH,A ;point to end of buffer MOV R1,2 ;sample counter L?M1D1: ;decode initialization MOV R3,#0 ;character counter MOV R4,#0 ;inital LRC MOV R0,#0 ;bit syncronizer CALL FIND_START ;main decode loop JNC L?M1D5 ;start bit error CALL GET_CHAR ;Start Sentinel JB ACC.7,L?M1D5 ;format error CJNE A,#M1_SS,L?M1D5 ;start setinel error L?M1D2: ;data byte or End Sentinel CALL GET_CHAR JB ACC.7,L?M1D5 ;format error CJNE A,#M1_ES,L?M1D3 ;end sentinel not found JMP L?M1D4 L?M1D3: CALL STORE_CHAR ;data character JMP L?M1D2 L?M1D4: ;LRC CALL GET_CHAR ;get LRC JB ACC.7,L?M1D5 ;format error MOV A,R4 JNZ L?M1D5 ;LRC error MOV DPTR,#MD1_BUF ;good return MOV A,R3 ;final character RET L?M1D5: ;decode error, check if 1st pass CJNE R5,#1,L?M1D0 ;check direction CLR A ;bad return RET ENDPROC ******************************************************************************* LISTING 3-- The intermediate layer of software is one level removed from the nitty-gritty details. ;Get the next bit from the sample buffer ;output: C contains data bit GET_BIT PROC CJNE R0,#0,L?GB1 ;bit synchronizer MOV R0,#8 PUSH ACC MOVX A,@DPTR CALL INDEX_PTR MOV B,A POP ACC DEC R1 ;sample counter L?GB1: XCH A,B CALL POSITION_BIT XCH A,B DEC R0 ;bit synchronizer RET ENDPROC ; ;Find the first '1' bit in the sample buffer ;output: C=1 if bit is found FIND_START PROC L?FS1: CJNE R0,#0,L?FS2 ;bit synchronizer MOV R0,#8 MOVX A,@DPTR CALL INDEX_PTR DJNZ R1,L?FS2 ;sample counter JMP L?FS4 ;out of samples L?FS2: CALL LOCATE_BIT ;test for a '1' bit JC L?FS3 CALL POSITION_BIT DEC R0 ;bit synchronizer JMP L?FS1 L?FS3: ;good return MOV B,A ;save copy in B SETB C RET L?FS4: CLR C ;bad return RET ENDPROC ; ;Get the next 7 bit element from the sample buffer ;output: ACC contains data element ; error flag is ACC.7 GET_CHAR PROC MOV A,R1 ;sample counter JZ L?GC2 ;out of samples MOV R7,#7 ;bit counter CLR A L?GC1: CALL GET_BIT ;next bit RRC A DJNZ R7,L?GC1 RR A JNB P,L?GC2 ;parity error ANL A,#3FH ;discard parity PUSH ACC XRL A,R4 ;calculate LRC MOV R4,A POP ACC ;good return RET L?GC2: SETB ACC.7 ;bad return RET ENDPROC ;Translate and store the data character ;input: ACC contains data character STORE_CHAR PROC PUSH DPL PUSH DPH PUSH ACC MOV DPTR,#MD1_BUF MOV A,R3 ;character counter ADD A,DPL MOV DPL,A CLR A ADDC A,DPH ;generate displacement MOV DPH,A POP ACC ADD A,#' ' ;translate MOVX @DPTR,A ;store POP DPH POP DPL INC R3 ;character counter RET ENDPROC ******************************************************************************* LISTING 4-- The low-level routines get right down to the ground and take care of the gory details. ;Index the sample pointer either forward or backward INDEX_PTR PROC CJNE R5,#0,L?IP1 ;check direction INC DPTR ;forward RET L?IP1: PUSH ACC ;backward DEC DPL MOV A,DPL CJNE A,#-1,L?IP2 DEC DPH L?IP2: POP ACC RET ENDPROC ;Position bit is in ACC into C in either a right or left shift POSITION_BIT PROC CJNE R5,#0,L?PB1 ;check direction RRC A ;forward RET L?PB1: RLC A RET ENDPROC ;Locate a 1 bit, either msb or lsb ;output: C=1 if bit is a one LOCATE_BIT PROC CJNE R5,#0,L?LB1 ;check direction MOV C,ACC.0 ;forward RET L?LB1: MOV C,ACC.7 ;backward RET ENDPROC ******************************************************************************* Contact: Mag-Tek, Inc. 20725 S. Annalee Ave. Carson, CA 90746 (213) 631-8602 fax: (213) 631-3956 ******************************************************************************* -- _ __ | __ | ` __ __ clafave@holonet.net | | __| ~|~ __|| ||__| Beaverton, Oregon USA |__ |_ |__| | |__| \/ |__. GO BLAZERS! From clafave@iat.holonet.net (Christopher R LaFave) Newsgroups: alt.2600 Subject: Magnetic stripe technology (2/2) Date: Sat, 21 May 1994 06:23:54 GMT >From PHRACK issue#37 ******************************************************************************* * * * Card-O-Rama: Magnetic Stripe Technology and Beyond * * * * or * * * * "A Day in the Life of a Flux Reversal" * * * * * * * * by: ..oooOO Count Zero OOooo.. .RDT. 11/22/91 * * * ******************************************************************************* ---A production of : -=Restricted -=Data -=Transmissions : : : : "Truth is cheap, but information costs." : Look in your wallet. Chances are you own at least 3 cards that have magnetic stripes on the back. ATM cards, credit cards, calling cards, frequent flyer cards, ID cards, passcards,...cards, cards, cards! And chances are you have NO idea what information is on those stripes or how they are encoded. This detailed document will enlighten you and hopefully spark your interest in this fascinating field. None of this info is 'illegal'...but MANY organizations (government, credit card companies, security firms, etc.) would rather keep you in the dark. Also, many people will IMMEDIATELY assume that you are a CRIMINAL if you merely "mention" that you are "interested in how magnetic stripe cards work." Watch yourself, ok? Just remember that there's nothing wrong with wanting to know how things work, altho in our present society, you may be labelled a "deviant" (or worse, a "hacker!"). Anyway, I will explain in detail how magstripes are encoded and give several examples of the data found on some common cards. I will also cover the technical theory behind magnetic encoding, and discuss magnetic encoding alternatives to magstripes (Wiegand, barium ferrite). Non-magnetic card technology (bar code, infrared, etc.) will be described. Finally, there will be an end discussion on security systems and the ramifications of emergent "smartcard" and biometric technologies. *DISCLAIMER* Use this info to EXPLORE, not to EXPLOIT. This text is presented for informational purposes only, and I cannot be held responsible for anything you do or any consequences thereof. I do not condone fraud, larceny, or any other criminal activities. *A WARNING* I've noticed lately a few "books" and "magazines" for sale that were FILLED with PHILES on a variety of computer topics. These philes were originally released into the Net with the intention of distributing them for FREE. HOWEVER, these philes are now being PACKAGED and sold FOR PROFIT. This really pisses me off. I am writing this to be SHARED for FREE, and I ask no payment. Feel free to reprint this in hardcopy format and sell it if you must, but NO PROFITS must be made. Not a fucking DIME! If ANYONE reprints this phile and tries to sell it FOR A PROFIT, I will hunt you down and make your life miserable. How? Use your imagination. The reality will be worse. ** MAGSTRIPE FIELDS, HEADS, ENCODING/READING ** Whew! I'll get down to business now. First, I am going to explain the basics behind fields, heads, encoding and reading. Try and absorb the THEORY behind encoding/reading. This will help you greatly if you ever decide to build your own encoder/reader from scratch (more on that later). FERROMAGNETIC materials are substances that retain magnetism after an external magnetizing field is removed. This principle is the basis of ALL magnetic recording and playback. Magnetic POLES always occur in pairs within magnetized material, and MAGNETIC FLUX lines emerge from the NORTH pole and terminate at the SOUTH. The elemental parts of MAGSTRIPES are ferromagnetic particles about 20 millionths of an inch long, each of which acts like a tiny bar magnet. These particles are rigidly held together by a resin binder. The magnetic particles are made by companies which make coloring pigments for the paint industry, and are usually called pigments. When making the magstripe media, the elemental magnetic particles are aligned with their North-South axes parallel to the magnetic stripe by means of an external magnetic fields while the binder hardens. These particles are actually permanent bar magnets with TWO STABLE POLARITIES. If a magnetic particle is placed in a strong external magnetic field of the opposite polarity, it will FLIP its own polarity (North becomes South, South becomes North). The external magnetic field strength required to produce this flip is called the COERCIVE FORCE, or COERCIVITY of the particle. Magnetic pigments are available in a variety of coercivities (more on that lateron). An unencoded magstripe is actually a series of North-South magnetic domains (see Figure 1). The adjacent N-S fluxes merge, and the entire stripe acts as a single bar magnet with North and South poles at its ends. Figure 1: N-S.N-S.N-S.N-S.N-S.N-S.N-S.N-S <-particles in stripe --------- represented as-> N-----------------------------S However, if a S-S interface is created somewhere on the stripe, the fluxes will REPEL, and we get a concentration of flux lines around the S-S interface. (same with N-N interface) ENCODING consists of creating S-S and N-N interfaces, and READING consists of (you guessed it) detecting 'em. The S-S and N-N interfaces are called FLUX REVERSALS. ||| ||| <-flux lines Figure 2: N------------N-N-S-S-----------------S --------- flux lines -> ||| ||| The external magnetic field used to flip the polarities is produced by a SOLENOID, which can REVERSE its polarity by reversing the direction of CURRENT. An ENCODING head solenoid looks like a bar magnet bent into the shape of a ring so that the North/South poles are very close and face each other across a tiny gap. The field of the solenoid is concentrated across this gap, and when elemental magnetic particles of the magstripe are exposed to this field, they polarize to the OPPOSITE (unlike poles attract). Movement of the stripe past the solenoid gap during which the polarity of the solenoid is REVERSED will produce a SINGLE flux reversal (see Figure 3). To erase a magstripe, the encoding head is held at a CONSTANT polarity and the ENTIRE stripe is moved past it. No flux reversals, no data. | | <----wires leading to solenoid | | (wrapped around ring) /-|-|-\ / \ Figure 3: | | <----solenoid (has JUST changed polarity) --------- \ / \ N S / <---gap in ring.. NS polarity across gap N----------------------SS-N-------------------------S ^^ <<<<<-direction of stripe movement S-S flux reversal created at trailing edge of solenoid! So, we now know that flux reversals are only created the INSTANT the solenoid CHANGES its POLARITY. If the solenoid in Figure 3 were to remain at its current polarity, no further flux reversals would be created as the magstripe moves from right to left. But, if we were to change the solenoid gap polarity from NS to *SN*, then (you guessed it) a *N-N* flux reversal would instantly be created. Just remember, for each and every reversal in solenoid polarity, a single flux reversal is created (commit it to memory..impress your friends..be a tech weenie!). An encoded magstripe is therefore just a series of flux reversals (NN followed by SS followed by NN ...). DATA! DATA! DATA! That's what you want! How the hell are flux reversals read and interpreted as data? Another solenoid called a READ HEAD is used to detect these flux reversals. The read head operates on the principle of ELECTROMAGNETIC RECIPROCITY: current passing thru a solenoid produces a magnetic field at the gap, therefore, the presence of a magnetic field at the gap of a solenoid coil will *produce a current in the coil*! The strongest magnetic fields on a magstrip are at the points of flux reversals. These are detected as voltage peaks by the reader, with +/- voltages corresponding to NN/SS flux reversals (remember, flux reversals come in 2 flavors). See Figure 4. magstripe---> -------NN--------SS--------NN---------SS------ Figure 4: voltage-----> .......+.........-.........+...........-..... --------- ---------- ------------- peak readout--> | | | | --------| |----------| |---- The 'peak readout' square waveform is critical. Notice that the voltage peak remains the same until a new flux reversal is encountered. Now, how can we encode DATA? The most common technique used is known as Aiken Biphase, or 'two-frequency coherent-phase encoding' (sounds impressive, eh?). First, digest the diagrams in Figure 5. Figure 5: ---------- ---------- ---------- --------- | | | | | | <- peak a) | |--------| |--------| | readouts * 0 * 0 * 0 * 0 * 0 * ----- ----- ----- ----- ----- - | | | | | | | | | | | b) | |----| |----| |----| |----| |----| * 1 * 1 * 1 * 1 * 1 * ----- ---------- ----- ----- - | | | | | | | | | c) | |----| |--------| |----| |----| * 1 * 0 * 0 * 1 * 1 * There ya have it. Data is encoded in 'bit cells,' the frequency of which is the frequency of '0' signals. '1' signals are exacty TWICE the frequency of '0' signals. Therefore, while the actual frequency of the data passing the read head will vary due to swipe speed, data density, etc, the '1' frequency will ALWAYS be TWICE the '0' frequency. Figure 5C shows exactly how '1' and '0' data exists side by side. We're getting closer to read DATA! Now, we're all familiar with binary and how numbers and letters can be represented in binary fashion very easily. There are obviously an *infinite* number of possible standards, but thankfully the American National Standards Institute (ANSI) and the International Standards Organization (ISO) have chosen 2 standards. The first is ** ANSI/ISO BCD Data format ** This is a 5-bit Binary Coded Decimal format. It uses a 16-character set, which uses 4 of the 5 available bits. The 5th bit is an ODD parity bit, which means there must be an odd number of 1's in the 5-bit character..the parity bit will 'force' the total to be odd. Also, the Least Significant Bits are read FIRST on the strip. See Figure 6. The sum of the 1's in each case is odd, thanks to the parity bit. If the read system adds up the 5 bits and gets an EVEN number, it flags the read as ERROR, and you gotta scan the card again. (yeah, I *know* a lot of you out there *already* understand parity, but I gotta cover all the bases...not everyone sleeps with their modem and can recite the entire AT command set at will, you know ;). See Figure 6 for details of ANSI/ISO BCD. Figure 6: ANSI/ISO BCD Data Format --------- * Remember that b1 (bit #1) is the LSB (least significant bit)! * The LSB is read FIRST! * Hexadecimal conversions of the Data Bits are given in parenthesis (xH). --Data Bits-- Parity b1 b2 b3 b4 b5 Character Function 0 0 0 0 1 0 (0H) Data 1 0 0 0 0 1 (1H) " 0 1 0 0 0 2 (2H) " 1 1 0 0 1 3 (3H) " 0 0 1 0 0 4 (4H) " 1 0 1 0 1 5 (5H) " 0 1 1 0 1 6 (6H) " 1 1 1 0 0 7 (7H) " 0 0 0 1 0 8 (8H) " 1 0 0 1 1 9 (9H) " 0 1 0 1 1 : (AH) Control 1 1 0 1 0 ; (BH) Start Sentinel 0 0 1 1 1 < (CH) Control 1 0 1 1 0 = (DH) Field Separator 0 1 1 1 0 > (EH) Control 1 1 1 1 1 ? (FH) End Sentinel ***** 16 Character 5-bit Set ***** 10 Numeric Data Characters 3 Framing/Field Characters 3 Control Characters The magstripe begins with a string of Zero bit-cells to permit the self-clocking feature of biphase to "sync" and begin decoding. A "Start Sentinel" character then tells the reformatting process where to start grouping the decoded bitstream into groups of 5 bits each. At the end of the data, an "End Sentinel" is encountered, which is followed by an "Longitudinal Redundancy Check (LRC) character. The LRC is a parity check for the sums of all b1, b2, b3, and b4 data bits of all preceding characters. The LRC character will catch the remote error that could occur if an individual character had two compensating errors in its bit pattern (which would fool the 5th-bit parity check). The START SENTINEL, END SENTINEL, and LRC are collectively called "Framing Characters", and are discarded at the end of the reformatting process. ** ANSI/ISO ALPHA Data Format ** Alphanumeric data can also be encoded on magstripes. The second ANSI/ISO data format is ALPHA (alphanumeric) and involves a 7-bit character set with 64 characters. As before, an odd parity bit is added to the required 6 data bits for each of the 64 characters. See Figure 7. Figure 7: --------- ANSI/ISO ALPHA Data Format * Remember that b1 (bit #1) is the LSB (least significant bit)! * The LSB is read FIRST! * Hexadecimal conversions of the Data Bits are given in parenthesis (xH). ------Data Bits------- Parity b1 b2 b3 b4 b5 b6 b7 Character Function 0 0 0 0 0 0 1 space (0H) Special 1 0 0 0 0 0 0 ! (1H) " 0 1 0 0 0 0 0 " (2H) " 1 1 0 0 0 0 1 # (3H) " 0 0 1 0 0 0 0 $ (4H) " 1 0 1 0 0 0 1 % (5H) Start Sentinel 0 1 1 0 0 0 1 & (6H) Special 1 1 1 0 0 0 0 ' (7H) " 0 0 0 1 0 0 0 ( (8H) " 1 0 0 1 0 0 1 ) (9H) " 0 1 0 1 0 0 1 * (AH) " 1 1 0 1 0 0 0 + (BH) " 0 0 1 1 0 0 1 , (CH) " 1 0 1 1 0 0 0 - (DH) " 0 1 1 1 0 0 0 . (EH) " 1 1 1 1 0 0 1 / (FH) " 0 0 0 0 1 0 0 0 (10H) Data (numeric) 1 0 0 0 1 0 1 1 (11H) " 0 1 0 0 1 0 1 2 (12H) " 1 1 0 0 1 0 0 3 (13H) " 0 0 1 0 1 0 1 4 (14H) " 1 0 1 0 1 0 0 5 (15H) " 0 1 1 0 1 0 0 6 (16H) " 1 1 1 0 1 0 1 7 (17H) " 0 0 0 1 1 0 1 8 (18H) " 1 0 0 1 1 0 0 9 (19H) " 0 1 0 1 1 0 0 : (1AH) Special 1 1 0 1 1 0 1 ; (1BH) " 0 0 1 1 1 0 0 < (1CH) " 1 0 1 1 1 0 1 = (1DH) " 0 1 1 1 1 0 1 > (1EH) " 1 1 1 1 1 0 0 ? (1FH) End Sentinel 0 0 0 0 0 1 0 @ (20H) Special 1 0 0 0 0 1 1 A (21H) Data (alpha) 0 1 0 0 0 1 1 B (22H) " 1 1 0 0 0 1 0 C (23H) " 0 0 1 0 0 1 1 D (24H) " 1 0 1 0 0 1 0 E (25H) " 0 1 1 0 0 1 0 F (26H) " 1 1 1 0 0 1 1 G (27H) " 0 0 0 1 0 1 1 H (28H) " 1 0 0 1 0 1 0 I (29H) " 0 1 0 1 0 1 0 J (2AH) " 1 1 0 1 0 1 1 K (2BH) " 0 0 1 1 0 1 0 L (2CH) " 1 0 1 1 0 1 1 M (2DH) " 0 1 1 1 0 1 1 N (2EH) " 1 1 1 1 0 1 0 O (2FH) " 0 0 0 0 1 1 1 P (30H) " 1 0 0 0 1 1 0 Q (31H) " 0 1 0 0 1 1 0 R (32H) " 1 1 0 0 1 1 1 S (33H) " 0 0 1 0 1 1 0 T (34H) " 1 0 1 0 1 1 1 U (35H) " 0 1 1 0 1 1 1 V (36H) " 1 1 1 0 1 1 0 W (37H) " 0 0 0 1 1 1 0 X (38H) " 1 0 0 1 1 1 1 Y (39H) " 0 1 0 1 1 1 1 Z (3AH) " 1 1 0 1 1 1 0 [ (3BH) Special 0 0 1 1 1 1 1 \ (3DH) Special 1 0 1 1 1 1 0 ] (3EH) Special 0 1 1 1 1 1 0 ^ (3FH) Field Separator 1 1 1 1 1 1 1 _ (40H) Special ***** 64 Character 7-bit Set ***** * 43 Alphanumeric Data Characters * 3 Framing/Field Characters * 18 Control/Special Characters The two ANSI/ISO formats, ALPHA and BCD, allow a great variety of data to be stored on magstripes. Most cards with magstripes use these formats, but occasionally some do not. More about those lateron. ** Tracks and Encoding Protocols ** Now we know how the data is stored. But WHERE is the data stored on the magstripe? ANSI/ISO standards define *3* Tracks, each of which is used for different purposes. These Tracks are defined only by their location on the magstripe, since the magstripe as a whole is magnetically homogeneous. See Figure 8. Figure 8: --------- _________________________________________________________________ | ^ ^ ^ |------------------| 0.223"--|---------|------------------------- | | | 0.353" | ^ |..................|.........|.........| 0.493" | | Track #1 0.110" | | | |............................|.........|... | | | | |............................|.........|... | | Track #2 0.110" | | |......................................|... | | | | |......................................|... | | Track #3 0.110" | |.......................................... | | | |------------------------------------------------------------------ | | | You can see the exact distances of each track from the edge of the card, as well as the uniform width and spacing. Place a magstripe card in front of you with the magstripe visible at the bottom of the card. Data is encoded from left to right (just like reading a book, eh?). See Figure 9. Figure 9: --------- ANSI/ISO Track 1,2,3 Standards Track Name Density Format Characters Function -------------------------------------------------------------------- 1 IATA 210 bpi ALPHA 79 Read Name & Account 2 ABA 75 bpi BCD 40 Read Account 3 THRIFT 210 bpi BCD 107 Read Account & *Encode* Transaction *** Track 1 Layout: *** | SS | FC | PAN | Name | FS | Additional Data | ES | LRC | SS=Start Sentinel "%" FC=Format Code PAN=Primary Acct. # (19 digits max) FS=Field Separator "^" Name=26 alphanumeric characters max. Additional Data=Expiration Date, offset, encrypted PIN, etc. ES=End Sentinel "?" LRC=Longitudinal Redundancy Check *** Track 2 Layout: *** | SS | PAN | FS | Additional Data | ES | LRC | SS=Start Sentinel ";" PAN=Primary Acct. # (19 digits max) FS=Field Separator "=" Additional Data=Expiration Date, offset, encrypted PIN, etc. ES=End Sentinel "?" LRC=Longitudinal Redundancy Check *** Track 3 Layout: ** Similar to tracks 1 and 2. Almost never used. Many different data standards used. Track 2, "American Banking Association," (ABA) is most commonly used. This is the track that is read by ATMs and credit card checkers. The ABA designed the specifications of this track and all world banks must abide by it. It contains the cardholder's account, encrypted PIN, plus other discretionary data. Track 1, named after the "International Air Transport Association," contains the cardholder's name as well as account and other discretionary data. This track is sometimes used by the airlines when securing reservations with a credit card; your name just "pops up" on their machine when they swipe your card! Since Track 1 can store MUCH more information, credit card companies are trying to urge retailers to buy card readers that read Track 1. The *problem* is that most card readers read either Track 1 or Track 2, but NOT BOTH! And the installed base of readers currently is biased towards Track 2. VISA USA is at the front of this 'exodus' to Track 1, to the point where they are offering Track 1 readers at reduced prices thru participating banks. A spokesperson for VISA commented: "We think that Track 1 represents more flexibility and the potential to deliver more information, and we intend to build new services around the increased information." What new services? We can only wait and see. Track 3 is unique. It was intended to have data read and WRITTEN on it. Cardholders would have account information UPDATED right on the magstripe. Unfortunately, Track 3 is pretty much an orphaned standard. Its *original* design was to control off-line ATM transactions, but since ATMs are now on-line ALL THE TIME, it's pretty much useless. Plus the fact that retailers and banks would have to install NEW card readers to read that track, and that costs $$. Encoding protocol specifies that each track must begin and end with a length of all Zero bits, called CLOCKING BITS. These are used to synch the self- clocking feature of biphase decoding. See Figure 10. Figure 10: end sentinel start sentinel | longitudinal redundancy check | | | 000000000000000 SS.................ES LRC 0000000000000000 leading data, data, data trailing clocking bits clocking bits (length varies) (length varies) THAT'S IT!!! There you have the ANSI/ISO STANDARDS! Completely explained. Now, the bad news. NOT EVERY CARD USES IT! Credit cards and ATM cards will follow these standards. BUT, there are many other types of cards out there. Security passes, copy machine cards, ID badges, and EACH of them may use a PROPRIETARY density/format/track-location system. ANSI/ISO is REQUIRED for financial transaction cards used in the international interbank network. All other cards can play their own game. The good news. MOST other cards follow the standards, because it's EASY to follow a standard instead of WORKING to make your OWN! Most magstripe cards other than credit cards and ATM cards will use the same Track specifications, and use either BCD or ALPHA formats. ** A Bit About Magstripe Equipment ** "Wow, now I know how to interpret all that data on magstripes! But... waitasec, what kind of equipment do I need to read the stripes? Where can I buy a reader? I don't see any in Radio Shack!!" Sorry, but magstripe equipment is hard to come by. For obvious reasons, card readers are not made commonly available to consumers. How to build one is the topic for another phile (and THIS phile is already too long!). Your best bets are to try and scope out Electronic Surplus Stores and flea markets. Don't even bother trying to buy one directly from a manufacturer, since they will immediately assume you have "criminal motives." And as for getting your hands on a magstripe ENCODER...well, good luck! Those rare beauties are worth their weight in gold. Keep your eyes open and look around, and MAYBE you'll get lucky! A bit of social engineering can go a LONG way. There are different kinds of magstripe readers/encoders. The most common ones are "swipe" machines: the type you have to physically slide the card thru. Others are "insertion" machines: like ATM machines they 'eat' your card, then regurgitate it after the transaction. Costs are in the thousands of dollars, but like I said, flea markets and surplus stores will often have GREAT deals on these things. Another problem is documentation for these machines. If you call the manufacturer and simply ask for 'em, they will probably deny you the literature. "Hey son, what are you doing with our model XYZ swipe reader? That belongs in the hands of a 'qualified' merchant or retailer, not some punk kid trying to 'find out how things work!" Again, some social engineering may be required. Tell 'em you're setting up a new business. Tell 'em you're working on a science project. Tell 'em anything that works! 2600 Magazine recently had a good article on how to build a machine that copies magstripe cards. Not much info on the actual data formats and encoding schemes, but the device described is a start. With some modifications, I bet you could route the output to a dumb terminal (or thru a null modem cable) in order to READ the data. Worth checking out the schematics. As for making your own cards, just paste a length of VCR, reel-to-reel, or audio cassette tape to a cut-out posterboard or plastic card. Works just as good as the real thing, and useful to experiment with if you have no expired or 'dead' ATM or calling cards lying around (SAVE them, don't TOSS them!). ** Examples of Data on Magstripes ** The real fun in experimenting with magstripe technology is READING cards to find out WHAT THE HELL is ON them! Haven't you wondered? The following cards are the result of my own 'research'. Data such as specific account numbers and names has been changed to protect the innocent. None the cards used to make this list were stolen or acquired illegally. Notice that I make careful note of 'common data'; data that I noticed was the same for all cards of a particular type. This is highlighted below the data with asterisks (*). Where I found varying data, I indicate it with "x"'s. In those cases, NUMBER of CHARACTERS was consistent (the number of "x"'s equals the number of characters...one to one relationship). I still don't know what some of the data fields are for, but hopefully I will be following this phile with a sequel after I collect more data. It ISN'T easy to find lots of cards to examine. Ask your friends, family, and co-workers to help! "Hey, can I, um, like BORROW your MCI calling card tonite? I'm working on an, um, EXPERIMENT. Please?" Just...be honest! Also, do some trashing. People will often BEND expired cards in half, then throw them out. Simply bend 'em back into their normal shape, and they'll usually work (I've done it!). They may be expired, but they're not ERASED! ------------------------------------------------------------------------------- -=Mastercard=- Number on front of card -> 1111 2222 3333 4444 Expiration date -> 12/99 Track 2 (BCD,75 bpi)-> ;1111222233334444=99121010000000000000? *** Track 1 (ALPHA,210 bpi)-> %B1111222233334444^PUBLIC/JOHN? * Note that the "101" was common to all MC cards checked, as well as the "B". ------------------------------------------------------------------------------- -=VISA=- Number on front of card -> 1111 2222 3333 4444 Expiration date -> 12/99 Track 2 (BCD,75 bpi)-> ;1111222233334444=9912101xxxxxxxxxxxxx? *** Track 1 (ALPHA,210 bpi)-> %B1111222233334444^PUBLIC/JOHN^9912101xxxxxxxxxxxxx? * Note that the "101" was common to all VISA cards checked, as well as the "B". Also, the "xxx" indicates numeric data that varied from card to card, with no apparent pattern. I believe this is the encrypted pin for use when cardholders get 'cash advances' from ATMs. In every case, tho, I found *13* digits of the stuff. ------------------------------------------------------------------------------- -=Discover=- Number on front of card -> 1111 2222 3333 4444 Expiration date -> 12/99 Track 2 (BCD,75 bpi)-> ;1111222233334444=991210100000? ******** Track 1 (ALPHA,210 bpi)-> %B1111222233334444^PUBLIC/JOHN___^991210100000? ******** Note, the "10100000" and "B" were common to most DISCOVER cards checked. I found a few that had "10110000" instead. Don't know the significance. Note the underscores after the name JOHN. I found consistently that the name data field had *26* charaters. Whatever was left of the field after the name was "padded" with SPACES. Soo...for all of you with names longer than 25 (exclude the "/") charaters, PREPARE to be TRUNCATED! ;) ------------------------------------------------------------------------------- -=US Sprint FON=- Number on front of card -> 111 222 3333 4444 Track 2 (BCD,75 bpi)-> ;xxxxxx11122233339==xxx4444xxxxxxxxxx=? * Track 1 (ALPHA,210 bpi)-> %B^ /^^xxxxxxxxxxxxxxxxx? * Strange. None of the cards I check had names in the Track 1 fields. Track 1 looks unused, yet it was always formatted with field separators. The "xxx" stuff varied from card to card, and I didn't see a pattern. I know it isn't a PIN, so it must be account data. ------------------------------------------------------------------------------- -=Fleet Bank=- Number on front of card -> 111111 222 3333333 Expiration date -> 12/99 Track 2 (BCD,75 bpi)-> ;1111112223333333=9912120100000000xxxx? **** Track 1 (ALPHA,210 bpi) -> %B1111112223333333^PUBLIC/JOHN___^9912120100000000000000xxxx000000? * **** Note that the "xxx" data varied. This is the encrypted PIN offset. Always 4 digits (hrmmm...). The "1201" was always the same. In fact, I tried many ATM cards from DIFFERENT BANKS...and they all had "1201". ------------------------------------------------------------------------------- (Can't leave *this* one out ;) -=Radio Shack=- Number on front of card -> 1111 222 333333 NO EXPIRATION data on card Track 2 (BCD,75 dpi)-> ;1111222333333=9912101? ******* Note that the "9912101" was the SAME for EVERY Radio Shack card I saw. Looks like when they don't have 'real' data to put in the expiration date field, they have to stick SOMETHING in there. ------------------------------------------------------------------------------- Well, that's all I'm going to put out right now. As you can see, the major types of cards (ATMs, CC) all follow the same rules more or less. I checked out a number of security passcards and timeclock entry cards..and they ALL had random stuff written to Track 2. Track 2 is by FAR the MOST utilized track on the card. And the format is pretty much always ANSI/ISO BCD. I *did* run into some hotel room access cards that, when scanned, were GARBLED. They most likely used a character set other than ASCII (if they were audio tones, my reader would have put out NOTHING...as opposed to GARBLED data). As you can see, one could write a BOOK listing different types of card data. I intended only to give you some examples. My research has been limited, but I tried to make logical conclusions based on the data I received. ** Cards of All Flavors ** People wanted to store A LOT of data on plastic cards. And they wanted that data to be 'invisible' to cardholders. Here are the different card technologies that were invented and are available today. HOLLERITH - With this system, holes are punched in a plastic or paper card and read optically. One of the earliest technologies, it is now seen as an encoded room key in hotels. The technology is not secure, but cards are cheap to make. BAR CODE - The use of bar codes is limited. They are cheap, but there is virtually no security and the bar code strip can be easily damaged. INFRARED - Not in widespread use, cards are factory encoded by creating a "shadow pattern" within the card. The card is passed thru a swipe or insertion reader that uses an infrared scanner. Infrared card pricing is moderate to expensive, and encoding is pretty secure. Infrared scanners are optical and therefore vulnerable to contamination. PROXIMITY - Hands-free operation is the primary selling point of this card. Altho several different circuit designs are used, all proximity cards permit the transmission of a code simply by bringing the card near the reader (6-12"). These cards are quite thick, up to 0.15" (the ABA standard is 0.030"!). WIEGAND - Named after its inventor, this technology uses a series of small diameter wires that, when subjected to a changing magnetic field, induce a discrete voltage output in a sensing coil. Two rows of wires are embedded in a coded strip. When the wires move past the read head, a series of pulses is read and interpreted as binary code. This technology prodces card that are VERY hard to copy or alter, and cards are moderately expensive to make. Readers based on this tech are epoxy filled, making them immune to weather conditions, and neither card nor readers are affected by external magnetic fields (don't worry about leaving these cards on top of the television set...you can't hurt them!). Here's an example of the layout of the wires in a Wiegand strip: ||| || || | ||| | || || | || || | | || | | | | | | |||| || |||| || The wires are NOT visible from the outside of the card, but if your card is white, place it in front of a VERY bright light source and peer inside. Notice that the spacings between the wires is uniform. BARIUM FERRITE - The oldest magnetic encoding technology (been around for 40 yrs!) it uses small bits of magnetized barium ferrite that are placed inside a plastic card. The polarity and location of the "spots" determines the coding. These cards have a short life cycle, and are used EXTENSIVELY in parking lots (high turnover rate, minimal security). Barium Ferrite cards are ONLY used with INSERTION readers. There you have the most commonly used cards. Magstripes are common because they are CHEAP and relatively secure. ** Magstripe Coercivity ** Magstripes themselves come in different flavors. The COERCIVITY of the magnetic media must be specified. The coercivity is the magnetic field strength required to demagnetize an encoded stripe, and therefore determines the encode head field strength required to encode the stripe. A range of media coerciviteis are available ranging from 300 Oersteds to 4,000 Oe. That boils down to HIGH-ENERGY magstripes (4,000 Oe) and LOW-ENERGY magstripes (300 Oe). REMEMBER: since all magstripes have the same magnetic remanence regardless of their coercivity, readers CANNOT tell the difference between HIGH and LOW energy stripes. Both are read the same by the same machines. LOW-ENERGY media is most common. It is used on all financial cards, but its disadvantage is that it is subject to accidental demagnetization from contact with common magnets (refrigerator, TV magnetic fields, etc.). But these cards are kept safe in wallets and purses most of the time. HIGH-ENERGY meda is used for ID Badges and access control cards, which are commonly used in 'hostile' environments (worn on uniform, used in stockrooms). Normal magnets will not affect these cards, and low-energy encoders cannot write to them. ** Not All that Fluxes is Digital ** Not all magstripe cards operate on a digital encoding method. SOME cards encode AUDIO TONES, as opposed to digital data. These cards are usually used with old, outdated, industrial-strength equipment where security is not an issue and not a great deal of data need be encoded on the card. Some subway passes are like this. They require only expiration data on the magstripe, and a short series of varying frequencies and durations are enough. Frequencies will vary with the speed of swiping, but RELATIVE frequencies will remain the same (for instance, tone 1 is twice the freq. of tone 2, and .5 the freq of tone 3, regardless of the original frequencies!). Grab an oscilliscope to visualize the tones, and listen to them on your stereo. I haven't experimented with these types of cards at all. ** Security and Smartcards ** Many security systems utilize magstripe cards, in the form of passcards and ID cards. It's interesting, but I found in a NUMBER of cases that there was a serious FLAW in the security of the system. In these cases, there was a code number PRINTED on the card. When scanned, I found this number encoded on the magstripe. Problem was, the CODE NUMBER was ALL I found on the magstripe! Meaning, by just looking at the face of the card, I immediately knew exactly what was encoded on it. Ooops! Makes it pretty damn easy to just glance at Joe's card during lunch, then go home and pop out my OWN copy of Joe's access card! Fortunately, I found this flaw only in 'smaller' companies (sometimes even universities). Bigger companies seem to know better, and DON'T print ALL of the magstripe data right on card in big, easily legible numbers. At least the big companies *I* checked. ;) Other security blunders include passcard magstripes encoded ONLY with the owner's social security number (yeah, real difficult to find out a person's SS#...GREAT idea), and having passcards with only 3 or 4 digit codes. Smartcard technology involves the use of chips embedded in plastic cards, with pinouts that temporarily contact the card reader equipment. Obviously, a GREAT deal of data could be stored in this way, and unauthorized duplication would be very difficuly. Interestingly enough, not much effort is being put into smartcards by the major credit card companies. They feel that the tech is too expensive, and that still more data can be squeezed onto magstripe cards in the future (especially Track 1). I find this somewhat analagous to the use of metallic oxide disk media. Sure, it's not the greatest (compared to erasable-writable optical disks), but it's CHEAP..and we just keep improving it. Magstripes will be around for a long time to come. The media will be refined, and data density increased. But for conventional applications, the vast storage capabilities of smartcards are just not needed. ** Biometrics: Throw yer cards away! ** I'd like to end with a mention of biometrics: the technology based on reading the physical attributes of an individual thru retina scanning, signature verification, voice verification, and other means. This was once limited to government use and to supersensitive installations. However, biometrics will soon acquire a larger market share in access control sales because much of its development stage has passed and costs will be within reach of more buyers. Eventually, we can expect biometrics to replace pretty much ALL cards..because all those plastic cards in your wallet are there JUST to help COMPANIES *identify* YOU. And with biometrics, they'll know you without having to read cards. I'm not paranoid, nor do I subscribe to any grand 'corporate conspiracy', but I find it a bit unsettling that our physical attributes will most likely someday be sitting in the cool, vast electronic databases of the CORPORATE world. Accessable by anyone willing to pay. Imagine CBI and TRW databases with your retina image, fingerprint, and voice pattern online for instant, convenient retrieval. Today, a person can CHOOSE NOT to own a credit card or a bank card...we can cut up our plastic ID cards! Without a card, a card reader is useless and cannot identify you. Paying in cash makes you invisible! However, with biometrics, all a machine has to do is watch... .listen...and record. With government/corporate America pushing all the buttons.. "Are you paying in cash?...thank you...please look into the camera. Oh, I see your name is Mr. Smith...uh, oh...my computer tells me you haven't paid your gas bill....afraid I'm going to have to keep this money and credit your gas account with it....do you have any more cash?...or would you rather I garnish your paycheck?" heh heh ** Closing Notes (FINALLY!!!!) ** Whew...this was one MOTHER of a phile. I hope it was interesting, and I hope you distribute it to all you friends. This phile was a production of "Restricted Data Transmissions"...a group of techies based in the Boston area that feel that "Information is Power"...and we intend to release a number of highly technical yet entertaining philes in the coming year....LOOK FOR THEM!! Tomorrow I'm on my way to Xmascon '91.....we made some slick buttons commemorating the event...if you ever see one of them (green wreath..XMASCON 1991 printed on it)..hang on to it!...it's a collector's item.. (hahahah) Boy, I'm sleepy... Remember.... "Truth is cheap, but information costs!" But -=RDT is gonna change all that... ;) set the info FREE! Peace. ..oooOO Count Zero OOooo.. count0@world.std.com count0@spica.bu.edu count0@atdt.org ATDT------(???)YOU-WISH (You're not paranoid if they're REALLY out to get you... ;) 様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様様 -- _ __ | __ | ` __ __ clafave@holonet.net | | __| ~|~ __|| ||__| Beaverton, Oregon USA |__ |_ |__| | |__| \/ |__. GO BLAZERS!