Items from security-related news (E93.Nov-2009)

NIST bulletin

October 5, 2009, NIST bulletin, Sara Caswell of NIST wrote:

NIST announces the completion of two NIST Special Publications (SPs):
SP 800-56B, Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography
SP 800-102, Recommendation for Digital Signature Timeliness.

Both publications are available at

SP 800-56B provides specifications of key establishment schemes that are appropriate for use by the U.S. Federal Government, based on a standard developed by the Accredited Standards Committee (ASC) X9, Inc.: ANS X9.44, Key Establishment using Integer Factorization Cryptography. A key establishment scheme can be characterized as either a key agreement scheme or a key transport scheme. This Recommendation provides asymmetric-based key agreement and key transport schemes that are based on the Rivest Shamir Adleman (RSA) algorithm.

SP 800-102 is intended to address the timeliness of the digital signatures generated using the techniques specified in Federal Information Processing Standard (FIPS) 186-3. Establishing the time when a digital signature was generated is often a critical consideration. A signed message that includes the (purported) signing time provides no assurance that the private key was used to sign the message at that time unless the accuracy of the time can be trusted. SP 800-102 provides methods of obtaining assurance of the time of digital signature generation using a trusted timestamp authority that is trusted by both the signatory and the verifier.

TLS Cryptographic Authentication Failures

November 4, 2009
TLS Allows Man-in-the-Middle Attacks
Marsh Ray and Steve Dispensa,
Reported by Hilarie Orman

The cryptographic protocol TLS (Transport Layer Security) began life as a formally verified protocol called SSL. Over the years it was the subject of standardardization by the IETF, and it evolved. Today it is widely used for authenticating and encrypting http transactions. Thus, it is a matter of some significance that there are practical attacks that allow a man-in-the-middle to inject arbitrary plaintext into the protocol stream.

The weakness resulted from protocol changes that allow a cryptographic context and an associated request to be re-used. The client sends a request, the server decides to renegotiate, the man-in-the-middle modifies the server's response, and the client mindlessly sends information from the server and man-in-the middle as if it were from the client. The result is that the server sees the man-in-the-middle information as authentic, and it ignores the request that the client intended.

The descent from "secure verified design" to "broken in practice" is an ongoing saga for many protocols. Error handling methods have rendered even the best cryptography insecure, but in this case, it was a misguided attempt to streamline cryptographic negotiations that led to the problem.