Re: Cars hacked through wireless tire sensors

2010-08-11 Thread dan

 | 
 | Unlike the work earlier this year, these attacks are more of a  
 | nuisance than any real danger; the tire sensors only send a message  
 | every 60-90 seconds, giving attackers little opportunity to compromise  
 | systems or cause any real damage. Nonetheless, both pieces of research  
 | demonstrate that these in-car computers have been designed with  
 | ineffective security measures.
 | 

Of course, in a place where surveillance infrastructure
is already capitalized (think London), adding the ability
to track bluetooth tire sensors would be so easy... and
self-initializing at the toll stations where the license
plates are read and correlation between plate number and
current radio fingerprint trivially recorded.

--dan

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Fwd: Re: new tech report on easy-to-use IPsec

2010-08-11 Thread Adam Aviv
I think the list may get a kick out of this.

The tech-report was actually posted on the list previously, which is
where I found it. Link included for completeness.

http://mice.cs.columbia.edu/getTechreport.php?techreportID=1433



 Original Message 
Subject: Re: new tech report on easy-to-use IPsec
Date: Wed, 28 Jul 2010 21:36:47 -0400
From: Steven Bellovin s...@cs.columbia.edu
To: Adam Aviv a...@cis.upenn.edu


On Jul 28, 2010, at 9:29 51PM, Adam Aviv wrote:
 I couldn't help but notice this nugget of wisdom in your report:

 [quote]

 Public key infrastructures (PKIs) are surrounded by a great
 mystique. Organizations are regularly told that they are complex,
 require ultra-high security, and perhaps are best outsourced to
 competent parties. Setting up a certifcate authority (CA) requires a
 ceremony, a term with a technical meaning [13] but nevertheless
 redolent of high priests in robes, acolytes with censers, and
 more. This may or may not be true in general; for most IPsec uses,
 however, little of this is accurate. (High priests and censers are
 defnitely not needed; we are uncertain about the need for acolytes
 ...)

Peter Gutmann told me privately that he thinks the alternate model
involves human sacrifices and perhaps a goat...


--Steve Bellovin, http://www.cs.columbia.edu/~smb





-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI, Part II

2010-08-11 Thread Thor Lancelot Simon
On Wed, Aug 04, 2010 at 10:46:44PM -0700, Jon Callas wrote:
 
 I think you'll have to agree that unlike history, which starts out as
 tragedy and replays itself as farce, PKI has always been farce over the
 centuries. It might actually end up as tragedy, but so far so good. I'm
 sure that if we look further, the Athenians had the same issues with it
 that we do today, and that Sophocles had his own farcical commentary.

If you want to see a PKI tragedy in the making, have a look at the CRLs
used by the US DoD.

Thor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: A mighty fortress is our PKI, Part II

2010-08-11 Thread Peter Gutmann
Thor Lancelot Simon t...@rek.tjls.com writes:

If you want to see a PKI tragedy in the making, have a look at the CRLs used
by the US DoD.

Only in the making?

Actually it's all relative, in Japan the Docomo folks turned off CRLs because
they found that even a relatively modest CRL (not just the DoD monsters)
presented a nice DoS when sent over cellular data links.  What happened was
that as the CRLs grew, performance got worse and worse as the phone downloaded
the CRL.  It took them quite some time to diagnose that they were being DoS'd
by their own PKI.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Is this the first ever practically-deployed use of a threshold scheme?

2010-08-11 Thread mhey...@gmail.com
On Sun, Aug 1, 2010 at 7:10 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote:
 ...does anyone know of any significant use [of split keys] by
 J.Random luser?  I'm interested in this from a usability point
 of view.

Maybe not J.Random but J.Corporate...

A few jobs ago back in the late '90s, I worked for Network Associates
which had bought PGP (the company). We instituted the use of PGP (the
technology) corporate-wide for email and  encrypted disk volumes. PGP
allows for enforceable key recovery - corporate clients demanded it.
Our corporate key recovery key was split into, I think, 5 parts with 3
parts required for key recovery. The parts were held by various
corporate executive/officer types.

The PGP product mostly hid from the end user the fact that every
PGP-encrypted thing had an encrypted private key along with it (you
could poke around and see the key recovery blob if you really wanted
to).

I don't know what the key recovery UI looked like.

 As a corollary, has anyone gone through the process of recovering a key from
 shares held by different parties...?

It just so happens, I lost my PGP private key a year or two into this
(failed to copy it when transferring to a new desktop). We had well
documented procedures for key recovery. I never got my key or data
back. I was never informed why. Perhaps the seldom used key recovery
software had bugs and wouldn't work for my key, or we couldn't get the
required big wigs into one room, or, probably most likely, at least
three big wigs lost their shares.

Michael Heyman

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com