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

Reply via email to