Security Challenges for CALEA in Voice over Packet Networks

[david koontz]

"The transmission of voice over packet networks presents new challenges
in security for electronic surveillance, which is also known as
Communications Assistance for Law Enforcement Act (CALEA). The major
challenges are how to intercept the packets from/to the targeting
devices and how to interpret and encrypt/decrypt them. It often seems
that the goal of CALEA conflicts with the goals of security, yet there
is an obvious need for law enforcement to intercept VoIP packets.

This white paper, authored by surveys the stated security challenges
and presents the technical background to help participants understand
the ramifications of these issues. The author presents some solutions to
security issues in VoIP networks and discusses how the industry might
approach and resolve these concerns in the future."

http://focus.ti.com/pdfs/bcg/voip_calea_wp.pdf  Sophia Scoggins, PhD 
Voice over Packet Business Unit, TI
(pdf - 886 Kbytes)

There's a presumption stated in the paper that intercepting Voice over
Packet networks (VoP)  is required to 'fight terrorism', and includes a
call of 'TIA must publish a new set of specifications for CALEA over
Internet'.

Other than the obvious use of the war against terrorism as the root
password to bypass the scientific method in drawing conclusions, its
informative.   Either it is impractical, or we are leading to an era of
licenses for internet connections, with DRM managed IP stacks and
protocols.  I don't see why someone can't specify protocols for VoIP
phones that interact with a switch/PBX function en clair, while
establishing secure communications between endpoints, or even separate
secure sessions with the switch/PBX and other endpoints.  It isn't
apparent if anyone will be 'suitably incentivised' to use protocols
where the keys can be recovered from a 'Security Gateway'.

In addition to VoIP, there are several legacy voice security software
packages available for PCs, and UNIX like workstations.  The difference
is between having access to a VoIP phone and a laptop.  Voynage and the
like provide the ability to determine availability of another end point
on the internet.  It has always been possible to establish
communications by depending on out of band information, the equivalent
of coming to periscope depth at 5 til midnight, or listening to BBC
broadcasts for message indicators. Likewise it isn't clear traffic flow
analysis isn't more important that actual intercepts.  The whole thing
sounds reminiscent of the tortured logic used to explain air port
security measures or how Escrowed Encryption would be used to catch dumb
criminals.

>From a manufacturers point of view, its 'We want to manufacture VoIP
phones that can be tapped,  but you'll need to twist the internet into
this shape.'



   








NOTICE: This message contains privileged and confidential
information intended only for the use of the addressee
named above. If you are not the intended recipient of
this message you are hereby notified that you must not
disseminate, copy or take any action in reliance on it.
If you have received this message in error please
notify Allied Telesyn Research Ltd immediately.
Any views expressed in this message are those of the
individual sender, except where the sender has the
authority to issue and specifically states them to
be the views of Allied Telesyn Research.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Certicom Extends Security Platform, Enabling Developers to Address Government Market

[R.A. Hettinga]

Certicom Extends Security Platform, Enabling Developers to Address
Government Market
 
Certicom Security Architecture for Government provides integrated suite
of security toolkits that ensure critical FIPS 140-2 and ECC compliance

MISSISSAUGA, ON, Dec. 6 /PRNewswire-FirstCall/ - Certicom Corp.
(TSX: CIC), the authority for strong, efficient cryptography, has extended
its Certicom Security Architecture(TM), enabling developers to embed a
FIPS 140-2-validated cryptographic module into their products and be
eligible for sale into the federal government market. The Certicom Security
Architecture also provides developers with an efficient way to enhance new
and existing applications with elliptic curve cryptography (ECC) and meet
the field-of-use guidelines set out by the National Security Agency (NSA)
to protect mission-critical national security information.
The adoption of ECC within the U.S. federal government is proceeding
rapidly, and Certicom is taking a leadership role in enabling agencies and
government contractors to integrate the strongest security technology into
their products. The comprehensive Certicom Security Architecture provides a
bridge between legacy crypto systems and ECC, and gives developers the
flexibility to standardize code among different security environments and
platforms - maximizing code re-use and portability. This flexibility also
means developers will not need to redesign their solutions to meet future
government crypto requirements.
"Hardware and software developers are increasingly realizing that
compliance with regulatory requirements for security is a pressing concern,"
said Dr. Jerry Krasner, vice president and chief analyst at Embedded Market
Forecasters (http://www.embeddedforecast.com ), the premier market
intelligence and
advisory firm in the embedded technology industry. "A cost-effective approach
is to use a tool that ensures compliance with FIPS 140-2 requirements and
eliminates the potentially costly step of third-party FIPS validation of a
device or application."
Strong security is a key requirement across all networked applications
and devices. The Certicom Security Architecture allows developers who may have
little security expertise to add FIPS 140-2 validated security to their
solutions while avoiding the time and expense of the FIPS 140-2 validation
process. A common application programming interface (API) unifies Certicom's
proven developer toolkits to create a plug-and-play security architecture that
includes higher level protocol functionality that can operate in FIPS mode,
such as SSL and PKI.
"Certicom Security Architecture for Government makes it easy for OEMs,
ISVs and integrators to sell products into the government sector that meet
strict government security requirements, including FIPS 140-2 and ECC," said
Roy Pereira, vice-president, marketing and product management at Certicom.
"The National Security Agency is committed to making elliptic curve
cryptography the most widely used public-key cryptosystem for securing U.S.
government information. Certicom is committed to providing the technology and
tools to make that possible."

The Security Builder developer toolkits integrated into the Certicom
Security Architecture for Government include:
-  Security Builder(R) GSE(TM), a FIPS 140-2-validated cryptographic
   toolkit;
-  Security Builder(R) NSE(TM), a cryptographic toolkit for national
   security information;
-  Security Builder(R) Crypto(TM), a cross-platform cryptographic
   toolkit;
-  Security Builder(R) PKI(TM), a digital certificate management toolkit;
-  Security Builder(R) SSL(TM), a complete Secure Sockets Layer toolkit;
   and
-  Security Builder(R) IPSec(TM), a client-side virtual private network
   toolkit.

Certicom Security Architecture for Government is available immediately,
except for Security Builder NSE which is available in Q1 2005. For more
information, visit http://www.certicom.com/gov .

About Certicom
Certicom Corp. (TSX:CIC) is the authority for strong, efficient
cryptography required by software vendors and device manufacturers to embed
security into their products. Adopted by the U.S. government's National
Security Agency (NSA), Certicom technologies for Elliptic Curve Cryptography
(ECC) provide the most security per bit of any known public-key scheme, making
it ideal for resource-constrained environments. Certicom products and services
are currently licensed to more than 300 customers including Motorola, Oracle,
Research In Motion, Terayon, Texas Instruments and Unisys. Founded in 1985,
Certicom is headquartered in Mississauga, ON, Canada, with offices in Ottawa,
ON; Reston, VA; San Mateo, CA; and London, England. Visit
http://www.certicom.com .

Certicom, Certicom Security Architecture, Certicom CodeS

MD5 To Be Considered Harmful Someday

[Dan Kaminsky]

I've been doing some analysis on MD5 collision announced by Wang et al.  
Short version:  Yes, Virginia, there is no such thing as a safe hash 
collision -- at least in a function that's specified to be 
cryptographically secure.  The full details may be acquired at the 
following link:

http://www.doxpara.com/md5_someday.pdf
A tool, Stripwire, has been assembled to demonstrate some of the attacks 
described in the paper.  It may be acquired at the following address:

http://www.doxpara.com/stripwire-1.1.tar.gz 

Incidentally, the expectations management is by no means accidental -- 
the paper's titled "MD5 To Be Considered Harmful Someday" for a reason.  
Some people have said there's no applied implications to Joux and Wang's 
research.  They're wrong; arbitrary payloads can be successfully 
integrated into a hash collision.  But the attacks are not wildly 
practical, and in most cases exposure remains thankfully limited, for 
now.  But the risks are real enough that responsible engineers should 
take note:  This is not merely an academic threat, systems designed with 
MD5 now need to take far more care than they would if they were 
employing an unbroken hashing algorithm, and the problems are only going 
to get worse.

Some highlights from the paper:
* The attack itself is pretty limited -- essentially, we can create 
"doppelganger" blocks (my term) anywhere inside a file that may be 
swapped out, one for another, without altering the final MD5 hash.  This 
lets us create any number of binary-inequal files with the same md5sum.

* MD5 uses an appendable cascade construction -- in other words, if you 
happen to find yourself with two files that MD5 to the same hash, an 
arbitrary payload can be applied to both files and they'll still have 
the same hash.  This leads to...

* Attacks are possible using only the proof of concept test vectors 
released by Wang -- the actual attack is not necessary.

* Stripwire emits two binary packages.  They both contain an arbitrary 
payload, but the payload is encrypted with AES.  Only one of the 
packages ("Fire") is decryptable and thus dangerous; the other ("Ice") 
shields its data behind AES.  Both files share the same MD5 hash.

* Digital Signature systems are vulnerable, as they almost always sign a 
hashed representation of data rather than the data itself.

* This is an excellent vector for malicious developers to get unsafe 
code past a group of auditors, perhaps to acquire a required third party 
signature.  Alternatively, build tools themselves could be compromised 
to embed safe versions of dangerous payloads in each build.  At some 
later point, the embedded payload could be safely "activated", without 
the MD5 changing.  This has implications for Tripwire, DRM, and several 
package management architectures.

* HMAC's invulnerability has been slightly overstated.  It's definitely 
possible, given the key, to create two datasets with the same HMAC.  
Attacker possession of the key violates MAC presumptions, so the impact 
of this is particularly questionable.

* Very interesting possibilities open up once the full attack is made 
available -- among other things, we can create self-decrypting 
executables (fire.exe and ice.exe) that exhibit differential behavior 
based on their internal colliding payloads.  They'll still have the same 
MD5 hash.

* Several doppelgangers may (relatively quickly, as per Joux) be 
computed within a single multicollision-friendly block.  As such, the 
particular selection of doppelganger sets within a file can itself be 
made to represent data.  It's relatively straightforward to embed a 128 
bit signature inside an arbitrary file, in such a way that no matter the 
value of the signature, a constant MD5 hash is maintained.  This is 
curiously steganographic.

* Many popular P2P networks (and innumerable distributed content 
databases) use MD5 hashes as both a reliable search handle and a 
mechanism to ensure file integrity.  This makes them blind to any 
signature embedded within MD5 collisions.  We can use this blindness to 
track MP3 audio data as it propagates from a custom P2P node.  
"Strikeback" capacity against executable trafficking is even more 
pronounced -- it's possible to create application installers that 
self-modify with host identifying characteristics but still successfully 
retransmit on P2P networks under the global search hash.

I hope this paper proves useful to the security community at large, and 
I welcome feedback.

--Dan Kaminsky
www.doxpara.com
[EMAIL PROTECTED]
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]