Re: Sequoia told

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Fri Feb 23 2007 - 11:18:53 CST

-----Original Message-----
>From: Ed Kennedy <ekennedyx@yahoo.com>

>
> Also, security through obscurity is the traditional way of
>preserving secrets and most people have not made the conceptual jump to the
>actuality of a world without secrets. I've sat through several discussions
>on this groups where people have had to beg for examples of why security
>through obscurity was a dead end. I brought up the example of the DVD CSS
>(Content Scrambling System) that was broken soon after its release by the
>program DeCSS. Unfortunately this is now a fairly old story so I invite
>people to provide new examples.
>
>

While I personally believe security through obscurity is a useful layer in the secuirty onion, I also understand how open source does offer both greater robustnes and confidence building public assessment of security.

 iTunes is an excecellent example of a billion dollar industry that has the finest mathematicians and computer geeks at it's disposal that can't achieve lasting security through obscurity. On the other hand they can and do manage temporary episodes of security through obscurity. And they clearly that the ONLY reason they can survive when the shields are down is that they have a quick reaction time--something the voting industry lacks.

Perhaps the most recent easily understood public discussion of how it is possible to reverse engineer deliberately obscured systems is Steve Job's open letter to the world:

"To prevent illegal copies, DRM systems must allow only authorized devices to play the protected music. If a copy of a DRM protected song is posted on the Internet, it should not be able to play on a downloader’s computer or portable music device. To achieve this, a DRM system employs secrets. There is no theory of protecting content other than keeping secrets. In other words, even if one uses the most sophisticated cryptographic locks to protect the actual music, one must still “hide” the keys which unlock the music on the user’s computer or portable music player. No one has ever implemented a DRM system that does not depend on such secrets for its operation.

The problem, of course, is that there are many smart people in the world, some with a lot of time on their hands, who love to discover such secrets and publish a way for everyone to get free (and stolen) music. They are often successful in doing just that, so any company trying to protect content using a DRM must frequently update it with new and harder to discover secrets. It is a cat-and-mouse game."

It should be noted that as of this writing the Cat is ahead since all available iTunes crackers are currently broken and undergoing repairs. On the otherhand this lack of activivity may also be due to the fact that iTunes is deliberatley porous (you can burn DRM music to a CD then rip it back) so that there desire to crack it is not incentivized by a desire to actually pilfer the music but more out of a mountain-climbing "because-it's-there" mentality.

Jobs makes another relevant observation too:
"Apple was able to negotiate landmark usage rights at the time, which include allowing users to play their DRM protected music on up to 5 computers and on an unlimited number of iPods. Obtaining such rights from the music companies was unprecedented at the time, and even today is unmatched by most other digital music services. However, a key provision of our agreements with the music companies is that if our DRM system is compromised and their music becomes playable on unauthorized devices, we have only a small number of weeks to fix the problem or they can withdraw their entire music catalog from our iTunes store."

The last sentence is apropos to the dilemma faced by all vendors that lack robustness in their voting system such that security is required for foolproof election. Whenever a bug is found in a DRE the system cannot be repaired quickly enough. Getting new ITA certs and then deployment takes on the scale of a year. No way can these get fixed before the harm might befall the next election. And canceling the election is rarely an option. Conversely, OVC for example has many transparent checks and balances so while corrupted software would be bad, it's may still be possible to conduct the election in a way that can detect and workaround glithces. Moreover, whether it is or is not safe to procede is readily evaluated by the public at large before the fact and is not a closely held determination by the manufacturer.

Two examples of the latter are the Benallilo election on Sequoia software where the manufacturere knew beforehand that the database would stop counting the early votes after first 32K but assumed this would not happen and did not tell the state. (it did happen and 12,000 votes were dropped). And then there's the bug documented by Doug Jones and Supervisor Suarez for the low power condition that overwrites the vote file headers in ES&S ivotronics. When tested they cound the 1/3 of the machines Suarez sampled showed signs of corrupted records.

When we notified the state of this, they said there was no time to fix it and besides the manufacturer had not advised them if there was a bug in the version they were using.

So iTunes is an excecellent example of a billion dollar industry that has the finest mathematicians and computer geeks at it's disposal that can't achieve lasting security through obscurity. On the other hand they can and do manage temporary episodes of security through obscurity. And they admit that the ONLY reason they can survive when the shields are down is that they have a quick reaction time.

_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Wed Feb 28 23:17:23 2007

This archive was generated by hypermail 2.1.8 : Wed Feb 28 2007 - 23:17:27 CST