[iwar] [fc:Daily.Briefing.--.Uncle.Sam.Should.Learn.to.Hack]

From: Fred Cohen (fc@all.net)
Date: 2001-10-02 19:55:54


Return-Path: <sentto-279987-2625-1002077756-fc=all.net@returns.onelist.com>
Delivered-To: fc@all.net
Received: from 204.181.12.215 by localhost with POP3 (fetchmail-5.1.0) for fc@localhost (single-drop); Tue, 02 Oct 2001 19:57:15 -0700 (PDT)
Received: (qmail 28134 invoked by uid 510); 3 Oct 2001 02:56:03 -0000
Received: from n27.groups.yahoo.com (216.115.96.77) by 204.181.12.215 with SMTP; 3 Oct 2001 02:56:03 -0000
X-eGroups-Return: sentto-279987-2625-1002077756-fc=all.net@returns.onelist.com
Received: from [10.1.4.52] by n27.groups.yahoo.com with NNFMP; 03 Oct 2001 02:55:56 -0000
X-Sender: fc@big.all.net
X-Apparently-To: iwar@onelist.com
Received: (EGP: mail-7_4_1); 3 Oct 2001 02:55:56 -0000
Received: (qmail 84846 invoked from network); 3 Oct 2001 02:55:55 -0000
Received: from unknown (10.1.10.26) by m8.onelist.org with QMQP; 3 Oct 2001 02:55:55 -0000
Received: from unknown (HELO big.all.net) (65.0.156.78) by mta1 with SMTP; 3 Oct 2001 02:55:54 -0000
Received: (from fc@localhost) by big.all.net (8.9.3/8.7.3) id TAA10299 for iwar@onelist.com; Tue, 2 Oct 2001 19:55:54 -0700
Message-Id: <200110030255.TAA10299@big.all.net>
To: iwar@onelist.com (Information Warfare Mailing List)
Organization: I'm not allowed to say
X-Mailer: don't even ask
X-Mailer: ELM [version 2.5 PL1]
From: Fred Cohen <fc@all.net>
Mailing-List: list iwar@yahoogroups.com; contact iwar-owner@yahoogroups.com
Delivered-To: mailing list iwar@yahoogroups.com
Precedence: bulk
List-Unsubscribe: <mailto:iwar-unsubscribe@yahoogroups.com>
Date: Tue, 2 Oct 2001 19:55:54 -0700 (PDT)
Reply-To: iwar@yahoogroups.com
Subject: [iwar] [fc:Daily.Briefing.--.Uncle.Sam.Should.Learn.to.Hack]
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

BusinessWeek Online
Daily Briefing -- Uncle Sam Should Learn to Hack

Daily Briefing: SECURITY NET

By Alex Salkever 

With the specter of the World Trade Center and Pentagon disasters
looming large in the minds of lawmakers, the cry to ban U.S.  exports of
sophisticated encryption software has risen anew.  Encryption, or
cryptography [crypto for short], is the science of devising codes that
cloak messages in secret language.  It involves using complex algorithms
to mix characters of a message with other characters or values in a
seemingly nonsensical way.  The result is gibberish that even the
biggest supercomputers struggle to decode. 

ADVERTISEMENT

In 1998, the U.S.  government removed a ban on the production and export
for sale of advanced cryptographic software and equipment.  That raised
the ire of law-enforcement officials and national-security hawks.  But
the hubbub quickly died down thanks to the glowing aura of the boom
economy.  Now, it appears that encryption exports may be in jeopardy
again as the U.S.  scours the globe for Osama bin Laden and his Al Qaeda
cohorts. 

UNWIELDY CONTROLS.  In Britain, members of Parliament are calling for
legislation that would control cryptographic products and create a
government-controlled ``key'' registry.  That registry would store
digital keys to all cryptographic products sold commercially in the
country, allowing law-enforcement officials to use the keys and render
cloaked messages readable.  Meanwhile, in the U.S., Senator Judd Gregg
[R-N.H.] on Sept.  13 called for further review of what crypto exports
should be banned and what key registries are needed for domestic law
enforcement. 

These calls, while understandable, are misdirected.  In the past,
restrictions on crypto have had the perverse effect of hurting U.S. 
businesses and moving the research centers for this subject overseas to
Europe.  Reinstating those restrictions could hurt a wide variety of
U.S.  companies from encryption specialists RSA Technologies
(NasdaqNM:RSAS) and NTRU Cryptosystems to digital-certificate companies
such as VeriSign (NasdaqNM:VRSN) and Entrust (NasdaqNM:ENTU). 

Furthermore, a ban on crypto products -- or more control over digital
keys -- likely won't have the desired affect of restricting terrorists'
access to the technology.  Dozens of open-source crypto programs
circulate freely on the Internet, alongside their commercial brethren. 
Putting this cat back in the digital bag might prove very difficult. 

THE BACK DOOR.  A better way to deal with surveillance of terrorists
using crypto products is for law-enforcement officials to become more
skillful at hacking.  Any type of crypto product must be built as a
piece of software.  While the encoding algorithms that power crypto
products might seem invincible, any piece of software has flaws inherent
in its construction by human beings.  ``They will probably not find
fault in the algorithm itself.  They will find a fault in how its being
used,'' explains Westin Nichols, chief information security officer at
managed-security outfit Telenisus and a former technical director of
network security at the NSA. 

For example, basic security flaws in the Windows operating system could
easily be leveraged to eavesdrop -- even on crypto-protected
communications.  Why? Because crypto programs ride on top of the most
basic software kernels of a system.  So any hacks that can compromise
the underlying kernel can be leveraged upwards to snoop with relative
impunity. 

The recent CodeRed and Nimda computer attacks illustrated how root
access to computers is often remotely accessible with a minimum amount
of effort.  While terrorists may have more time to patch their systems,
many of their partners and linking organizations may not.  Without a
doubt, there's an easy way into these networks, even if they use
encryption.  ``No matter how strong the crypto is, there's always
another way in,'' says William Whyte, a noted cryptographer and director
of crypto research at NTRU. 

HUMAN WEAKNESS.  Then there's what hackers call the ``social'' hack. 
That means tricking your way into access to secure systems.  It can
range from sending spoofed e-mails asking for passwords to phone calls
from a mystery IT consultant requesting information about a company's
systems.  Guessing passwords is another favorite pastime of hackers. 

All these efforts target a simple fact -- human beings are almost always
the weakest link in any attempt to protect data or communications.  Most
people use passwords that are easy to remember rather than secure. 
Furthermore, people use the same password or variations of it for most
of their accounts. 

Everyone, even terrorists, lets their guard down in some situation that
might provide critical human intelligence to guide a cyber attack. 
Something as simple as discovering the configuration of IT systems at
banks suspected of harboring terrorist accounts might give the
government a clue as how to break into that system. 

TRICKY STRATEGIES, PROPER OVERSIGHT.  I don't mean to be flippant about
all this.  I realize that professional hacking by a government begs some
very tricky legal issues, such as when the government should be allowed
to break into people's computer systems.  But there's no reason why,
with a court order that's the legal equivalent of a digital search
warrant, such procedures couldn't be authorized in the U.S., even
internationally, if the process is properly overseen.  While that might
blur some legal lines, the U.S.  has been using intelligence operatives
to snoop in other countries for years.  So there's clearly a precedent
for it in the cyber realm, too. 

These are not always the most savory tactics and choices.  Hacking
through systems to circumvent encryption clearly risks allowing the
government, be it U.S.  or any other, too much power and depletes
citizens' already scant privacy.  That said, it's a far easier and more
manageable course of action than attempting to ban the export of
encryption software or build a key-registry system that virtually no one
wants, save the most stalwart security hawks.  The U.S.  and Britain
would be better served trying a new approach than returning to an old
tactic that hasn't worked. 

------------------
http://all.net/ 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



This archive was generated by hypermail 2.1.2 : 2001-12-31 20:59:53 PST