UPnP Security specs available for review

[John Gilmore]

Carl,

What's the design lifetime of this security system?

1024 bit RSA is too short.  If you're going to all the trouble to
build a supposedly secure system, use a length that won't be broken.
My suggestion these days is significantly north of 2048 bits.  Don't
use a power of two, and, ideally, use key lengths that vary among
devices, so that there's no "sweet spot" for someone to build a
key-cracking machine for.

E.g. One device that implements your spec might have a key length of
2432 bits; the next one a length of 2200 bits; a third 2648 bits.

It's clear that the crypto implemented in these devices in the near
future is going to be in iterative software, rather than wide
hardware, so there's no reason to limit the keys to 1024 bits except for
performance and the tiny cost of memory space.  And we all know that:

   the number of public-key operations required is low
   the latency of public-key operations is usually negligible at system level
   the performance of hardware always increases rapidly
   available memory always increases rapidly

So don't fall into the NSA trap that's plagued cellphones and every
other consumer device.  Don't build a security system for every
household device that is "secure ENOUGH" but has a weak link designed
in.

And don't forget that Intel wants to sell that increased-performance
hardware too.  So the crypto system should be right at the "sluggishly
slow" point when first released.  Because two or three years out, new
devices will be "plenty fast" and then a few years later any crypto
overhead will be "invisible" in new devices.

Also, once you have established session keys between two devices, why
would you EVER send plaintext between them (page 6, paragraph 9)?  The
spec should say that plaintext messages will not be accepted, and the
implementations should definitely ignore any that arrive.  This is the
failure mode of US cellphones: the TDMA and CDMA standards define a
(poor) encryption scheme, but even though it's in every phone, the
cellphone service vendors have all been pressured to disable it on
every call.  (In fact it isn't even built into the base stations.)  IF
IT'S POSSIBLE TO DISABLE THE CRYPTO, THE GOVERNMENT WILL CAUSE IT TO
HAPPEN IN PRACTICE.  So spec it so each device *must* have the secure
crypto, on every message, or it won't interoperate.

Also, what's this business about manufacturers generating the
long-term keys and putting them in the devices and not letting users
change them (pg 6, first sentence)?  Have you gone over to the Dark
Side?

How many seconds would it take for a rogue Security Console to try all
possible 6-uppercase-letters passwords after you plug in a device
(e.g. to charge) and before you try to control it from your own
Security Console?  2 milliseconds per try (500 tries a second) seems
like a high estimate, for an operation that only has to check a hash,
especially ten years from now.  I didn't work out the message lengths,
but on a 10 mbit ethernet, at wire speed, wouldn't the attacker be
able to try passwords faster than this today?  And what about on the
10 gbit ethernet that'll be default in ten years, with the hash done
in the invisibly small 40 GHz embedded processor that'll be default in
ten years?

	John

PS: It's nice that on page 7 you tell manufacturers in paragraph 14
how to build back doors into devices.  As is obvious in current
telecomm systems (including "anonymity" software), if these are
buildable, then the government will pass a law mandating their use to
subvert the user's control over their own life and privacy.  E.g. this
is where you'd put the "Execute DRM" interface, where Senator Hatch
will send a message that destroys the device if hollywood thinks you
aren't a subservient godfearin' amurrican.  And the CALEA interface.

PPS: I stopped at page 7; these comments were getting long and I was
losing interest.  Carl, You know better than to design in each of
these flaws, so presumably if you'd had the power to fix them, I
wouldn't have to send in these comments.  Thus, none of them are going
to get fixed.  Right?  Why did you bother publishing this spec?  Might
as well have all the mfrs just agree on it in secret and ram it down
our throats.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com