Sergio Tabanelli wrote:
> Maybe this is not so important, but I have to repeat that in W2K OS the
> NSAKEY is still present but not used. All CSPs are verified only with the
> primary key and if the verification process fails the CSP module is
> discarded without any further verification.
This is exactly what one would expect with a backup signing key. While the
primary secret key is not lost, there is no imperative to also sign with the
secondary. In fact one would specifically not want to use the second key until
one has no choice. Are you sure that a CSP actually signed *only* with the
second key is rejected (an invalid first key should be rejected even if signed
with both, so there is no point in trying the second key)
Can you overwrite the NSAKEY in W2K with a key of your own and test a
suitably signed CSP? Of course they would likely have built in obfuscated key
integrity tests to make sure that installing CSPs not signed by M$ is not so
simple...
In any case the evidence for any real issues with NSAKEY is rather scant at
this time. Since neither key is used by non M$ CSPs, they cannot directly
compromise the security of the users. Even if the NSA can unilaterally sign
CSPs they first have to install a new CSP on your machine to get the bad guys
(and any of us who are not bad guys :-)) to use weakened crypto. What is the
suspected vulnerability introduced by the presence of the key in question?
With some notable exceptions most of the postings on this thread are of the
*me too* variety. We already know that security software is vulnerable to
deliberate and accidental flaws. Lets not restate the obvious.
In the spirit of freedom of unrestrained speculation I will conjecture the
following: Perhaps NSAKEY is there to social engineer the adversary not to rely
on encryption products, thereby reducing the impact of looser export controls
:-)
--
Viktor.
S/MIME Cryptographic Signature
