On 10/8/13 at 7:38 AM, leich...@lrw.com (Jerry Leichter) wrote:
On Oct 8, 2013, at 1:11 AM, Bill Frantz <fra...@pwpconsult.com> wrote:
We seriously need to consider what the design lifespan of our
crypto suites is in real life. That data should be
communicated to hardware and software designers so they know
what kind of update schedule needs to be supported. Users of
the resulting systems need to know that the crypto standards
have a limited life so they can include update in their
installation planning.
This would make a great April Fool's RFC, to go along with the classic "evil
bit". :-(
I think the situation is much more serious than this comment
makes it appear. As professionals, we have an obligation to
share our knowledge of the limits of our technology with the
people who are depending on it. We know that all crypto
standards which are 15 years old or older are obsolete, not
recommended for current use, or outright dangerous. We don't
know of any way to avoid this problem in the future.
I think the burden of proof is on the people who suggest that we
only have to do it right the next time and things will be
perfect. These proofs should address:
New applications of old attacks.
The fact that new attacks continue to be discovered.
The existence of powerful actors subverting standards.
The lack of a "did right" example to point to.
There are embedded systems that are impractical to update and
have expected lifetimes measured in decades...
Many perfectly good PC's will stay on XP forever because even
if there was the will and staff to upgrade, recent versions of
Windows won't run on their hardware.
...
I'm afraid the reality is that we have to design for a world in
which some devices will be running very old versions of code,
speaking only very old versions of protocols, pretty much
forever. In such a world, newer devices either need to shield
their older brethren from the sad realities or relegate them to
low-risk activities by refusing to engage in high-risk
transactions with them. It's by no means clear how one would
do this, but there really aren't any other realistic alternatives.
Users of this old equipment will need to make a security/cost
tradeoff based on their requirements. The ham radio operator who
is still running Windows 98 doesn't really concern me. (While
his internet connected system might be a bot, the bot
controllers will protect his computer from others, so his radio
logs and radio firmware update files are probably safe.) I've
already commented on the risks of sending Mailman passwords in
the clear. Low value/low risk targets don' need titanium security.
The power plant which can be destroyed by a cyber attack, c.f.
STUXNET, does concern me. Gas distribution systems do concern
me. Banking transactions do concern me, particularly business
accounts. (The recommendations for online business accounts
include using a dedicated computer -- good advice.)
Perhaps the shortest limit on the lifetime of an embedded system
is the security protocol, and not the hardware. If so, how do we
as society deal with this limit.
Cheers -- Bill
-----------------------------------------------------------------------
Bill Frantz | gets() remains as a monument | Periwinkle
(408)356-8506 | to C's continuing support of | 16345
Englewood Ave
www.pwpconsult.com | buffer overruns. | Los Gatos,
CA 95032
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
