[117725] in Cypherpunks
laughable CAPI recovery designs
daemon@ATHENA.MIT.EDU (Anonymous)
Thu Sep 9 13:25:16 1999
Date: Thu, 9 Sep 1999 19:00:11 +0200 (CEST)
Message-Id: <199909091700.TAA06316@mail.replay.com>
From: Anonymous <nobody@replay.com>
To: cypherpunks@cyberpass.net, cryptography@c2.net
Reply-To: Anonymous <nobody@replay.com>
At 08:17 AM 9/9/99 +0100, Adam Back wrote:
>
>This general area of discussion -- software modification
>authentication -- is a bit fuzzy: if you can modify the software you
>can patch out the check of the signature (a correctly placed NOP is
>known to do it).
a "JMP" more accurately, or a couple of NOPs
>
>However, and for example in the FIPS 140-1 crypto software validation
>program, you can do simple things to slightly frustrate the simple
>minded patching out of keys etc. FIPS 140-1 suggests actions such as
>signatures on modules, code to check the signatures being located in
>two different modules (so that modification of one module alone is not
>sufficient).
NT 4 does checksum ADVAPI32.DLL so it has to recomputed, as someone noted.
>
>(FIPS 140-1 is a US government / NIST program for validation of crypto
>modules).
>
>Interestingly, a recent press release suggests Microsoft is claiming
>it will have FIPS 140-1 on their crypto modules in the latest version
>of NT.
NT 5, at minimum, will be checking real digital signatures on system
components.
....<deleted>....
>
>However, whilst this is plausible -- this is not what Microsoft are
>doing: the NSA key is accepted as a key that can be used to sign CAPI
>modules directly. And as has been noted the NSA key can be patched in
>a completely simple minded way, allowing anyone to easily insert their
>own modules.
but it does trip the "authentication" of ADVAPI32.DLL does it not? Same as
JMP/NOP in the executable?
>
>(Though one supposes it is within the bounds of possibility that the
>NSA key has two functions: where it could also used to sign
>operational key replacement patches. However in that case you would
>have expected some attempt to prevent replacement of the NSA key, but
>we know that there is no authentication for replacing the NSA key --
>you can just patch it out.)
Accoring to your assertions you just proved that the use of this key is not
a very high security priority, giving the lie to the possibility it is used
to insert black crypto modules!
>
>So in summary I conclude that Microsoft is just blowing smoke. The
>key is NSA's, and is either intended for Info War purposes, or for
>their own use, or both.
See my previous comment: your conclusion is in no way supported by the facts!
>
>Brian LaMacchia (head of CAPI development at Microsoft) knows what he
>is talking about.
Yes, but does he tell *you*?
>I think if Microsoft were in the clear, the best PR
>approach would be to just let BAL do the press release.
Microsoft did, didn't they? They're not going to have the project manager
put out a press release! I don't know why I'm taking the time to respond
to this.
>However, from
>Lucky's comments on the cryptography list:
>
>: After watching the NSAKEY talk at the Crypto rump session [name
>: elided], by his own account at the time the person ultimately
>: responsible for CAPI at Microsoft, told a group that even he had not
>: know about the second key.
CROCK
In addition, he informed us that access
>: to the Windows source code is heavily compartmentalized, making it
>: easy to insert modifications without the knowledge of even the
>: respective product managers.
CROCK - I have heard of people who have walked into Redmond and walked out
with more than a tshirt.
>
>it appears BAL was not aware of the second key. So the evidence to me
>indicates that it is NSA's key, and Microsoft does not want to admit
>it because it makes for bad PR. Or that Microsoft is doing a poor job
>of in it's press releases!
>
Occam. Use Occam. Nobody's fucking using Occam. Anyway my back channel
indicates it is a Microsoft key.
>Adam
>
