Ps and Qs (and an unexceptional understanding of KEA)


http://blog.cryptographyengineering.com/2015/01/hopefully-last-post-ill-ever-write-on.html is interesting for its discussion of Ps and Qs.

Long ago, I got a briefing (from NSA folk) on the security architecture and crypto algorithms used in the security mechanisms for the type II version of MSP – the layer 7 forerunner of S/MIME (in DoD). One might recall how DoD certs, in the fortezza era, contained signing and KEA keys. KEA has a DH-like computation, and cooperates with a particular block formation process to compute a master session key. Its really quite cute, and shows that NSA has a lot of class. At the time, I was quite in awe of NSA ability to subtly tune up algorithms , mechanisms  and services (and still am, truth be told).

Now, in the KEA process based in discrete log based problems (vs curve based problems) the so-called random numbers from the certs’ keying blocks were augmented by valuyes supplied by the protocol …. from which master keys were derived (after certain blocking processes were used, and signing processes verified, note well). The keys from the UKM list (a list of secondary “randoms” that “changed” the master key for the crypto periods desired) were the source  of the protocols-contribution of (partial) keyimg material, generating the master secret.

When used in interactive protocols (such as TLS these days), both parties would contribute the KEA key and a nominated value from their UKM. In the case of email protocols, only the sender would contribute such material, with values from the devices RNG satisfying the formal requirements.

It qas made quite clear that the KEA values in the certs were public keys, that could be treated as random numbers at one level (and public keys at another).

While the security mechanism were identical, the security services that result from these different procedures for leveraging keying material were different. And, there was nothing held back about why such differences were necessary – based on pretty obvious (but also subtle) requiremnets analysis.  This was “security engineering” – that I learned from the agency (and loved to learn, from folks evidently well skilled).  That the fortezza card could be applied to the difference security services was, furthermore, absolutely intended – since folks wanted different communication security semantics, to suite the different operational theatres the devices was intended to serve.

I kind of miss professional NSA security engineering, given the drivel I read from the academic sector.

Advertisements

About home_pw@msn.com

Computer Programmer who often does network administration with focus on security servers. Very strong in Microsoft Azure cloud!
This entry was posted in crypto. Bookmark the permalink.