RE: cellphones as room bugs

[Ian Farquhar (ifarquha)]

The other problem for this technique is battery life.

Let's assume we can shove a firmware update/hack/whatever into the phone to 
enable snooping, it's still transmitting when acting
as a bug.  Even if this feature is only enabled when the phone is geolocated 
somewhere "interesting", the reduction in battery
life is going to be significant.  If your phone has a standby time of days, and 
you're used to shoving it on the charger rarely,
then suddenly you're doing it several times a day, you're going to notice.  
Even if you are the dumb, stupid criminal the
government likes to tell us that surveillance always catches.

I suppose that it could be argued that you could use silence detection etc. to 
reduce power used, but most phones are pretty
aggressive at power saving already.  I doubt there are huge savings to be made 
which haven't been implemented already.

Ian.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Taral
Sent: Monday, 4 December 2006 2:26 PM
To: [EMAIL PROTECTED]
Cc: John Ioannidis; cryptography@metzdowd.com
Subject: Re: cellphones as room bugs

On 12/3/06, Thor Lancelot Simon <[EMAIL PROTECTED]> wrote:
> It's been a while since I built ISDN equipment but I do not think this 
> is correct: can you show me how, exactly, one uses Q.931 to instruct 
> the other endpoint to go off-hook?

That's the same question I have. I don't remember seeing anything in the GSM 
standard that would allow this either.

--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem

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

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

RE: padlocks with backdoors - TSA approved

[Ian Farquhar \(ifarquha\)]

Some of the locks have special indicators which flag that a TSA key has opened 
it, which marginally improves the idea, but not
by much.  Whether those flags could represent a defence in the case of a 
corrupt official in possession of TSA keys I do not
know.

Without such flags, it's an INCREDIBLY unwise idea, as if you keep the bag 
unlocked, at least you have a defence that handlers
could have added items to the luggage in transit.

Some readers will have heard the case of Schapelle Corby, who is serving a 20 
year sentence in Indonesia for trafficing
marijuana.  In the ensuing investigation, a significant amount of evidence was 
uncovered suggesting that corrupt baggage
handlers were trafficing drugs between Australian airports, using unlocked 
baggage.  Corby's laywers claimed that she was the
victim of this, and that the destination baggage handler failed to intercept 
the drugs which were planted in her luggage.

I won't make a comment on the conduct of the agencies, the media and 
governments involved in the Corby case.  However, I will
say that any government (or other) program which assumes the honesty of 
employees and contractors is fundamentally flawed, and
any associated risk analysis is either incompetent, or in failing to identify 
risk to travellers, seriously incomplete.

Ian. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hadmut Danisch
Sent: Tuesday, 27 February 2007 7:20 AM
To: cryptography@metzdowd.com
Subject: padlocks with backdoors - TSA approved

Hi,

has this been mentioned here before?


I just had my crypto mightmare experience. 


I was in a (german!) outdoor shop to complete my equipment for my next trip, 
when I came to the rack with luggage padlocks (used
to lock the zippers). 

While the german brand locks were as usual, all the US brand locks had a 
sticker 

   "Can be opened and re-locked by US luggage inspectors". 

Each of these (three digit code) locks had a small keyhole for the master key 
to open. Obviously there are different key types
(different size, shape, brand) as the locks had numbers like "TSA005" 
tell the officer which key to use to open that lock.


Never seen anything in real world which is such a precise analogon of a crypto 
backdoor for governmental access.

Ironically, they advertise it as a big advantage and important feature, since 
it allows to arrive with the lock intact and in
place instead of cut off. 


This is the point where I decided to have nightmares from now on.


regards
Hadmut

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

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

RE: Was a mistake made in the design of AACS?

[Ian Farquhar \(ifarquha\)]

On Thu, May 03, 2007 at 10:25:34AM -0700, Steve Schear wrote:
> Well, there's an idea: use different physical media formats for entertainment 
> and non-
> entertainment content (meaning, content created by MPAA members vs. not) and 
> don't sell
> writable media nor devices capable of writing it for the former, not to the 
> public, keeping
> very tight controls on the specs and supplies.  [...]

Sony's UMD format is an example of this approach.  I doubt even the most 
reality-disconnected marketeers in Sony could call it
anything but an abject failure.  I also doubt any company other than Sony - 
which has a long history of believing it can control
the delivery format - would have even bothered.

Ian.

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

RE: Free Rootkit with Every New Intel Machine

[Ian Farquhar \(ifarquha\)]

I agree with Peter here.  I also tried to procure a motherboard with a TPM chip 
- to play with Bitlocker mostly - and came to
the same conclusion.

I did find a few MBs, mostly from Intel, and a couple of other vendors.  All of 
these were corporate-style MB's, as opposed to
the gamer/enthusiast style I needed.

For example: the Gigabyte GA-965QM-DS2 (rev 2.0) which "features security 
enhancement by TPM".  More common (ASUS, Foxconn) was
the "TPM Connector", which seemed to be a hedged bet, by replacing the cost of 
the TPM chip with the cost of a socket.

I also went looking for a TPM on some other delivery mechanism (USB stick?  PCI 
card?  Anything...) but didn't turn anything up
I was actually able to purchase at the time (but maybe not now - see the 
BCM5751 below).

There's a slightly out of date matrix of products here:

http://www.tonymcfadden.net/tpmvendors_arc.html

I too have heard rumors of TPM functionality being included in either North or 
South Brigdes, but I haven't seen that happen yet
(aside from Intel, few vendors release detailed chipset datasheets anyway).  
Winbond do have a "Trusted IO" series of chips
which are basically LPC controllers plus the TPM chip (all now "not recommended 
for new designs"), and Transmeta did embed the
TPM in the TM5800.  Apparently Broadcomm also did embed a TPM on their BCM5751 
and BCM5751M ethernet controllers.

Interestingly, you will find the BCM5751 on several high end motherboards, but 
the presence of TPM functionality isn't often
mentioned.  Riii :)

Apple is one vendor who I gather does include a TPM chip on their systems, I 
gather, but that wasn't useful for me.

Ian.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Gutmann
Sent: Saturday, 23 June 2007 10:49 PM
To: [EMAIL PROTECTED]
Cc: cryptography@metzdowd.com
Subject: Re: Free Rootkit with Every New Intel Machine

[EMAIL PROTECTED] writes:

>my understanding from a person active in the NEA working group (IETF) 
>is that TPMs these days "come along for free" because they're included 
>on-die in at least one of said chips.

Check again.  A few months ago I was chatting with someone who works for a 
large US computer hardware distributor and he located
one single motherboard (an Intel one, based on an old, possibly discontinued 
chipset) in their entire inventory that contained a
TPM (they also had all the ex-IBM/Lenovo laptops, and a handful of HP laptops, 
that were reported as having TPMs).  He also said
that there were a handful of others (e.g. a few Dell laptops, which they don't
carry) with TPMs.

I've seen all sorts of *claims* of TPM support, but try going out and buying a 
PC with one (aside from IBM/Lenovo and the
handful of others) - you have to look really, *really* hard to find anything, 
and if you do decide you specifically want a
TPM-enabled MB or laptop you're severely restricting your options (unless it's 
a Lenovo).

Unless something truly miraculous happens, TPMs are destined to end their lives 
as optional theft-discouragement gadgets for
laptops (assuming they're running Windows XP, or possibly Vista if you can find 
the drivers).  They've certainly failed to make
any impression on the desktop market.

Peter.

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

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

RE: Free Rootkit with Every New Intel Machine

[Ian Farquhar \(ifarquha\)]

> It seems odd for the TPM of all devices to be put on a pluggable module as 
> shown here.  The whole point of the chip is to be bound tightly to the 
> motherboard and to observe the boot and initial program load sequence.

Maybe I am showing my eternal optimist side here, but to me, this is how TPM's 
should be used, as opposed to the way their
backers originally wanted them used.  A removable module whose connection to a 
device I establish (and can de-establish,
assuming the presence of a tamper-respondent barrier such as a sensor-enabled 
computer case to legitimize that activity) is a
very useful thing to me, as it facilitates all sorts of useful applications.  
The utility of the original intent has already
been widely criticised, so I won't repeat that here.  :)

It also shows those interesting economics at work.  The added utility of the 
TPM module (from the PoV of the user) was marginal
at best despite all claims, yet it facilitated functionality which was contrary 
to most user's interests.  The content industry
tried to claim that the TPM module would facilitate the availability of 
compelling content - which they tried to sell as it's
user utility - but like most of their claims it was a smoke and mirrors trick.

Consequently, the razor-edged economics of the motherboard and desktop industry 
has comprehensively rejected TPM except in
certain specialized marketplaces where higher profit margins are available (eg. 
Servers, corporate desktops).  The chipset
manufacturers have also failed to add this functionality to their offerings to 
date.

Now Vista has added Bitlocker, which arguably adds a user valuable feature for 
which a TPM module is needed (yes, you can run it
without TPM, but it's painful).  I wonder if we'll start to see more "TPM 
connectors" appearing, or even full TPM modules on
motherboards and cores on south bridge dies?

Personally, I'd like to see a TPM implemented as a tamper-respondent (ie. 
Self-powered) module mounted on the motherboard in a
socket which allows removal detection.  That way you get the flexibility of 
moving the module, with the safety of a programmed
response to an unauthorized removal.

Ian.

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

RE: Free Rootkit with Every New Intel Machine

[Ian Farquhar \(ifarquha\)]

Dave Korn wrote:
> Ian Farquhar wrote:
>> Maybe I am showing my eternal optimist side here, but to me, this is 
>> how TPM's should be used, as opposed to the way their backers 
>> originally wanted them used.  A removable module whose connection to a 
>> device I establish (and can de-establish, assuming the presence of a 
>> tamper-respondent barrier such as a sensor-enabled computer case to 
>> legitimize that activity) is a very useful thing to me, as it 
>> facilitates all sorts of useful applications.  [...]

> If you can remove it, what's to stop you plugging it into another machine and 
> copying all
> your DRM-encumbered material to that machine?
>
> It's supposed to identify the machine, not the user.  Sounds to me like what 
> you want is a 
> personally identifying cert that you could carry around on a usb key...

Nothing, but you missed my point.  I'm not interested in the DRM functionality, 
or user-removability.  My point was to look
beyond that original remit.

Specifically, a module which supports authenticated physical removal (with a 
programmed tamper response) *is* useful, especially
for server applications. (*)  Smartcards and "secure" USB devices might be 
useful for other applications, but not the one I was
describing, because they lack a tamper response.

Note I'm also saying "programmable tamper response".  Although I like the idea 
of wiping keys on tamper response, it's not
necessarily the ideal response.  A better possibility (in certain 
circumstances) is the device entering a "lockdown" mode with
selected and modelled reduced functionality.  Examples of such circumstances 
are where the tamper might be triggerable
maliciously, thus facilitating a DoS attack against the service. 

Ian.

(*) And isn't it interesting how so many "desktop" systems are now starting to 
run application mixes which really look like
servers?

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

RE: How the Greek cellphone network was tapped.

[Ian Farquhar \(ifarquha\)]

> 2. E2E crypto on mobiles would require cross-vendor support, which would mean 
> that it
> would have to go into the standard.  Unfortunately, standards in the mobile 
> world are
> heavily influenced by governmnets, and the four horsemen of the apocalypse 
> (drug
> dealers, paedophiles, spies, and terrorists) are still being used by 
> government types
> to nix any attempts at crypto they can't break or intercept.

Handset suppliers are traditionally uncomfortable with licensing fees for 
non-core function.  This is why, for example, memory
card support has been needed for so long, but is a relatively recent 
phenomenon.  The suppliers didn't want to pay licensing
fees to the card standards bodies, despite the massively increased data storage 
needs which were coincident with the addition of
camera functionality to phones.

Crypto has been an IP minefield for some years.  With the expiry of certain 
patents, and the availability of other unencumbered
crypto primitives (eg. AES), we may see this change.  But John's other points 
are well made, and still valid.  Downloadable MP3
ring tones are a selling point.  E2E security isn't (although I've got to 
wonder about certain teenage demographics... :)

And don't forget, some of the biggest markets are still crypto-phobic.  Every 
time I enter China I have to tick a box on the
entry form indicating that I am not carrying any "communications security 
equipment".  When my GSM mobile roams onto China
Telecom, the "unlocked paddlock" logo appears denoting that even A5/2 isn't 
allowed.  Yet China has mandated full cellphone
coverage, even in rural areas, and for companies like Motorola and Nokia, it's 
a must-own marketplace.  Features which may worry
the often inconsistent and capricious State Encryption Management Committee 
(SEMC), who can block the entry of your product into
China, is going to be pruned from the product list pretty damn quickly.

Ian.

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

RE: Elcomsoft trying to patent faster GPU-based password cracker

[Ian Farquhar (ifarquha)]

ROTFL.

When SGI's "stealth" DES Challenge project was underway in 1997, it's main 
client ran on the host's (MIPS) CPU(s), implemented
with a variant of Eli Biham's bit-slice DES implementation.  The 64-bit 195MHz 
R1 could do 2.5M keys/sec.  I was
peripherally involved in the project.

One of the things I was looking into was offloading the client into the VICE 
ASIC on the O2.  The VICE ASIC was a compression
offload engine, and combined with the MACE ASIC (which had the 3D rendering 
pipeline), provided graphics support on the O2.  At
the time, SGI put a workstation on everyone's desk in the company, so there 
were thousands of O2's around the company.

The VICE itself had two CPU's in it, the "MSP" which was a R4000-derived core 
with a 128bit vector unit, and the "BSP" which was
a custom little RISC core designed for efficiently slicing non-word-aligned 
multimedia bit streams.  Biham's algorithm would
have run beautifully on the VICE.

I'd just gotten the devkit when the project came to an end with DESCHALL's 
successful keyfind.

So I'm feeling a little bit of déjà vu about Elcomsoft's patent here.  
Offloading keyfinding algorithms to a programmable
graphics accelerator.  Wow, sounds *very* familiar.  But alas, probably not 
sufficient for a prior art claim.  Gotta also wonder
if the mailing list traffic would still exist in SGI too.

Mind you, if the patent system wasn't totally broken, this application would 
fail the obviousness test anyway.  The GPU's
mentioned below are basically just optimized little co-processors anyway.  How 
much innovation is there in offloading crypto to
a coprocessor? 

Ian.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Thursday, 25 October 2007 3:25 AM
To: Cryptography
Subject: Elcomsoft trying to patent faster GPU-based password cracker

From:

   

  Moscow, Russia - October 22, 2007 - ElcomSoft Co. Ltd. has
  discovered and filed for a US patent...Using the "brute force"
  technique of recovering passwords, it was possible, though
  time-consuming, to recover passwords from popular
  applications. For example...Windows Vista uses NTLM hashing
  by default, so using a modern dual-core PC you could test up to
  10,000,000 passwords per second, and perform a complete
  analysis in about two months. With ElcomSoft's new technology,
  the process would take only three to five days..Today's [GPU]
  chips can process fixed-point calculations. And with as much as
  1.5 Gb of onboard video memory and up to 128 processing
  units, these powerful GPU chips are much more effective than
  CPUs in performing many of these calculations...Preliminary
  tests using Elcomsoft Distributed Password Recovery product
  to recover Windows NTLM logon passwords show that the
  recovery speed has increased by a factor of twenty, simply by
  hooking up with a $150 video card's onboard GPU.

-Michael Heyman

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

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

RE: Intercepting Microsoft wireless keyboard communications

[Ian Farquhar (ifarquha)]

When I looked at this circa 2001-2002, for another company, other 27MHz
keyboards didn't even bother to encrypt.  Most of the data was sent in
the clear, with neither encryption nor robust authentication.

Exactly what makes this problem so difficult eludes me, although one
suspects that the savage profit margins on consumables like keyboards
and mice might have something to do with it.

Ian. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Leichter, Jerry
Sent: Friday, 7 December 2007 10:13 AM
To: cryptography@metzdowd.com
Subject: Intercepting Microsoft wireless keyboard communications

http://www.dreamlab.net/download/articles/Press%20Release%20Dreamlab%20T
echnologies%20Wireless%20Keyboard.pdf

Computerworld coverage at

http://www.computerworld.com/action/article.do?command=viewArticleBasic&;
articleId=9051480

The main protection against interception is the proprietary protocol,
which these guys were able to reverse engineer.  The exchange is
"encrypted" using a Caeser cipher (XOR with a single byte that is the
common key, which is the only secret in the system); they say they can
determine the right key within 30 characters or so.  Their current
hardware can read the data from 33 feet away; with a better antenna,
well over a hundred feet should be possible.  These things operate at
27 MHz, which will penetrate walls easily.

Reading multiple keyboards at once is possible and they already do it.
They are looking at injecting data into the stream - presumably not very
hard.

Many other brands of wireless keyboard may well be equally vulnerable.

-- Jerry

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

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

RE: crypto class design

[Ian Farquhar (ifarquha)]

In my experience of doing security evaluations for large financial
institutions in AsiaPac, I suspect the biggest problem you'll face in
doing this is hubris from the app developers.  I don't know why, but
these guys so often have a problem taking advice, at least in my
experience (which now covers ~15 different financial institutions in 4
countries.)

The level of ignorance runs deep, and almost without exception, most
don't see any complexity in crypto protocols or implementation, and have
a strong "security by obscurity" mentality.  Oh, and "roll your own"
algorithms are surprisingly common. I've even offered to do 1st order
algorithm reviews in a couple of cases, but been told that revealing the
algorithm compromised it's security.  "And you don't think that's a
problem in itself?"  "No."

So, good luck.  I personally have a boilerplate risk disclosure section
which basically says "your in-house app developers know squat about
crypto, and you're at risk if you're trusting their designs and
implementation as a consequence."  It's a bit nicer phrased, but that's
the gist of the ~4 page section.

Ian.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, 18 December 2007 3:39 AM
To: Cryptography
Subject: crypto class design

So... supposing I was going to design a crypto library for use within a
financial organization, which mostly deals with credit card numbers and
bank accounts, and wanted to create an API for use by developers, does
anyone have any advice on it?

It doesn't have to be terribly complete, but it does have to be
relatively easy to use correctly (i.e. securely).

I was thinking of something like this:

class crypto_api
{
...
// developers call these based on what they're trying to do
// these routines simply call crypto_logic layer
Buffer encrypt_credit_card(Buffer credit_card_number, key_t key);
Buffer encrypt_bank_account(Buffer bank_account, key_t key);
Buffer encrypt_other(Buffer buffer, key_t key);
...
};

class crypto_logic
{
...
algo_default = ALGO_AES256CBC;
// encrypt with a given algorithm
Buffer encrypt(Buffer buffer, key_t key, algo_t aid = algo_default);
// calls different routines in crypto_implementation layer depending
on algorithm used
Buffer decrypt(Buffer buffer, key_t key);
...
};

class crypto_glue
{
...
// calls routines in libraries such as OpenSSL
// mostly wrappers that translate between our data types and theirs
Buffer aes256cbc-encrypt(...);
Buffer aes256cbc-decrypt(...);
...
};

The general idea is that crypto_api provides domain-specific APIs that
are easy for anyone to understand, that the logic layer allows for the
selection of different algorithms, and the glue layer is basically a
translation layer to underlying libraries.

It is very important that the API remain stable, because the code base
is large and owned by various groups.

One thing that I'm wondering is how to indicate (e.g.) the overhead in
terms of padding, or whatever, for various algorithms... or if it
matters.  The old code had some really disturbing practices like
assuming that the output buffer was 16 octets bigger, and stuff like
that... scary.

Intend to skim the OpenSSL design and Gutmann's "Design of a
Cryptographic Security Architecture" for ideas.

Comments?
--
In God We Trust, All Others Must Provide Source Code
https://www.subspacefield.org/~travis/> Eff the ineffable!
For a good time on my email blacklist, email [EMAIL PROTECTED]

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

RE: Foibles of user "security" questions

[Ian Farquhar (ifarquha)]

I've been having this problem for years (my mother's maiden name is,
indeed, four characters long).  It's often rejected as too short, yet
I'm forced to enter it.  I do the workaround of entering it twice, but
then have to remember which sites I applied this hack for.

It's a typical dumb programmer mistake.  Data (password) vs. information
(mother's maiden name).  Character length contributes entropy to one,
but not to the other.  But on an even more fundamental level, it also
indicates a lack of attention to the input data, which could highlight
vulnerabilities in other areas too.



I'm probably preaching to the choir here, and maybe it's a sign of
"grumpy old guy syndrome", but the average programmer seems to me to be
getting dumber every year.  I personally blame University courses who've
so divorced software development from any understanding of the
underlying OS, hardware or information theory, that we've got a bunch of
people who think everyone programs in Java or C#, Microsoft is the only
OS vendor there is, and if your program runs slowly, you just needs more
memory.



Ian.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Leichter, Jerry
Sent: Tuesday, 8 January 2008 4:14 AM
To: cryptography@metzdowd.com
Subject: Foibles of user "security" questions

Reported on Computerworld recently:  To "improve security", a system was
modified to ask one of a set of fixed-form questions after the password
was entered.  Users had to provide the answers up front to enroll.  One
question:  Mother's maiden name.  User provides the 4-character answer.
System refuses to accept it:  Answer must have at least 6 characters.

I can just see the day when someone's fingerprint is rejected as
"insufficiently complex".
-- Jerry

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

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