Recently I posted to some mailing lists, questions and observation about a
new strange functionality in W2K called OffloadModExpo. Some of these were
about a strange coincidence, I've never found a distribution which
contemporary use the _NSAKEY and the
OffloadModExpo functionality. I’ve also privately presented all the
following considerations to Scott Culp of the Microsoft Security Response
Center, a very interesting discussion followed my signaling. If someone is
interested I can make it public.

This is my posting to public mailing lists:

>>
Microsoft has released a new security bulletin
(http://www.microsoft.com/technet/security/bulletin/ms00-024.asp)
about a vulnerability in the NT registry permission setting for a
functionality called OffloadModExpo. I thanks Microsoft and Scott Culp for
the Acnowledgments.
This is the full story:

I have checked the CSPs shipped with W2K international edition and with the
High encryption pack for W2K, I have also checked lots of CSPs shipped with
W95, W98, NT SP3-4-5 and with the IE High encryption for 98 and NT and I
have found what I am going to reveal only in the following CSPs of the W2K
OS:
Microsoft Base Cryptographic Provider v1.0  implemented in rsabase.dll  W2K
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider implemented in
dssbase.dll W2K
Microsoft Base DSS Cryptographic Provider implemented in dssbase.dll W2K
Microsoft DH SChannel Cryptographic Provider implemented in dssenh.dll W2K
Microsoft Enhanced Cryptographic Provider v1.0 implemented in rsaenh.dll W2K
Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider implemented
in dssenh.dll W2K
Microsoft Exchange Cryptographic Provider v1.0 implemented in exchcsp.dll
W2K
Microsoft RSA SChannel Cryptographic Provider implemented in rsaenh.dll W2K
Microsoft Strong Cryptographic Provider implemented in rsaenh.dll W2K
And also in the rsaenhs.dll W2K
Before we start I need to clarify that what I am reporting here are both
facts and hypotesys, where the hypothesis were derived from factual
observation. I want also to emphatyze that  I am not saying that someone not
authorized has activated the vulnerability I am going to illustrate, but I
am suggesting to check  it out.OK, now we can start.
We know that modular exponentiation is one of the basic matematical
operation in public key cryptography. We know that an RSA key pair has a
public modulus “n”, a public exponent “e” and a private exponent d (we don’t
consider here inessential private key components like p, q etc.). If we have
a message “m”, padded to the modulus byte len, then its private encryption
is
c = m^d mod n
and the public decription of  “c” is
m = c^e mod n
same thing for public encryption
c = m^e mod n
and private decryption
m = c^d mod n
Normaly Microsoft CSPs use the RSA Bsafe library to calculate modular
exponentiation for public and private encryption and decryption, but in W2K
(I repeat that I’ve found this functionality only in W2K but I have not
checked all possible distributions and updates for others OS) something has
been changed.
When a client calls the CryptAquireContext CryptoAPI function, the
implementation of this function in advapi32.dll calls the CPAquireContext
function of the desired provider.  In the case of the the W2K CSPs
implementation, this function tries to open a registry key named
“HKEY_LOCAL_MACHINE\software\microsoft\cryptography\Offload”, quering  for
the value “ExpoOffload”, which, if present, must be a dll full path name.

The W2K CSPs loads the dll and queries the dll for the address of a function
called “OffloadModExpo” saving the address in a structure associated with
the returned handle.

If any error occurs (registry key, value, dll or function are not found) the
function continues without any error notification.  But,  if  a
“OffloadModExpo” function is found, then the CSP calls it  every time it
needs to calculate a power or a  modulus,  passing the base (in our example
“m” or “c”) the exponent (in our example “e” or “d”) the modulus (in our
example “n”) as input parameters and the result (in our example “c” or “m”)
as output parameter.  ”OffloadModExpo”  must return true ( not 0) or false
(0). This functionlity is documented in
http://msdn.microsoft.com/library/psdk/cryptcsp/cspref_9lnz.htm.  What is
not documented is that if OffloadModExpo returns  false then its caller in
the CSP continues  without any error notification and calls the normal Bsafe
implementation,  If OffloadModExpo returns true the caller assumes that
the returned result is valid and does not call the normal Bsafe
implementation.

If  no “OffloadModExpo” is  available (the structure holding the address is
NULL) then the CSPs call the normal Bsafe implementation.

To clarify what this really means we can examine what happens in some well
known use of public key cryptography (security related parameters are
capitalized):

Digital signature: Used in SSL authentication (client and server) or in a
digital Certificate signature done by a Certification Autority or in
documents and e-mails autentication and integrity protection, ecc.
The operation is private encryption and parameters are an hash value padded
to the modulus length in bytes, the PRIVATE EXPONENT, the modulus, and the
result is the digital signature.

Session key encryption: Used in SSL keys exchange or in secret documents or
e-mails protection, ecc.
The operation is public encryption and the parameters are the SESSION KEY
padded to modulus length, the public exponent, the modulus, while the result
is the encrypted session key.

Session key decryption: Used in SSL keys exchange or to read protected
secret documents or e-mails, ecc.
The operation is private decryption and parameters are the encrypted session
key, the PRIVATE EXPONENT, the modulus, the result is the SESSION KEY padded
to modulus length.

It is clear that by registering in a system a dll providing an
implementation of OffloadModExp a malicious user can intercept all users’
private key, confidential documents, and session keys as soon as  they are
used in a cryptographic operation.

It may be noted that by default W2K grants write access to the registry key
“HKEY_LOCAL_MACHINE\software\microsoft\cryptography” only to administrator
users. This can partially protect from unauthorized access to the
“OffloadModExpo” functionality.  However,  we must consider that

1. normally Microsoft’s Operating Systems users use a  single account with
adminitrator privileges.
2. NT, W95, W98 by default don’t protect the registry key, so anyone with a
guest account can insert the “OffloadModExpo” functionality and then wait
for a system upgrade to automatically activate it.
3. Microsoft says that this functionality is present also in NT OS, if it is
so, there are lots of other vulnerabilities to consider.
4. In any case in my opinion it is completely unacceptable that a system
administrator can access users’s private keys without the user knowledge and
assent. Microsoft apparently knows this very well: their operating systems
protect private keys with logon independent mechanisms,  and they also ask
the users which level of protection they choose.

Due to my personal relations with the _NSAKEY (see the mailing list
http://remus.prakinf.tu-ilmenau.de/ssl-users/archive28/0151.html, where I
publicized the presence of the NSA key one year before Cryptonym
http://www.cryptonym.com/hottopics/msft-nsa/msft-nsa.html),  I choose to
investigate more the presence of this feature in relation with the use of
the _NSAKEY and I found out that there is a strange coincidence:  when the
“OffloadModExpo” functionality is present the _NSAKEY is not used and when
the “OffloadModExpo” functionality is absent the _NSAKEY is used.   This is
clearly not a proof of anything, but increases our doubts as to why it is
there.

In detail, what I found is
the W2K advapi32.dll still have the _NSAKEY but DOES NOT USE IT
the W2K CSPs use the “OffloadModExpo” functionality
the W2K beta candidate release still has the _NSAKEY but DOES NOT USE IT
the W2K beta candidate release CSPs use the “OffloadModExpo” functionality
the W2K beta 3 still has the _NSAKEY but DOES NOT USE IT
the W2K beta 3 CSPs use the “OffloadModExpo” functionality
the NT5-W2K beta 2 still has the _NSAKEY and USES IT
the NT5-W2K beta 2 CSPs DO NOT HAVE  the “OffloadModExpo” functionality
Appendix: Cryptonym was partialy wrong when wrote about three keys used in
W2K beta, yes the keys are three but only two are used, the _NSAKEY is not
used.

I’ve presented all these considerations to the Microsoft Security Response
Center, a very interesting discussion followed my signaling. If someone is
interested I can make it public.

Sergio Tabanelli

>>

P.S.
I've checked again for this functionality in NT4 sp3-4-5-6 low and high
encryption packs, and I didn't found it, I think that this is a realy
strange think, if I am not wrong, this means that the secutity patch is for
a non functionality. I've also to confirm that in W2K they don't use no
more the _NSAKEY and that
I've never found a distribution which contemporary use the _NSAKEY and the
OffloadModExpo functionality.

comments are welcome.

>>

Sergio Tabanelli
-----Original Message-----
From: John Young <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: giovedì 27 aprile 2000 17.31
Subject: MS on NSA_KEY in Windows


>Duncan Campbell has provided a recent exchange of
>informative messages with Scott Culp at Microsoft on the
>origin, function and purpose of NSA_KEY in Windows:
>
>   http://cryptome.org/nsakey-ms-dc.htm
>
>
>


Reply via email to