[2718] in cryptography@c2.net mail archive
RE: I believe Microsoft has knowingly violated the export rules
daemon@ATHENA.MIT.EDU (James O'Toole)
Wed May 20 00:23:50 1998
From: "James O'Toole" <otoole@lcs.mit.edu>
To: "'Robert Hettinga'" <rah@shipwright.com>,
"'rsalz@shore.net'"
<rsalz@shore.net>
Cc: "'cryptography@c2.net'" <cryptography@c2.net>,
"'dcsb@ai.mit.edu'"
<dcsb@ai.mit.edu>
Date: Tue, 19 May 1998 20:28:33 -0400
Rich,
I read your note, forwarded by Bob Hettinga, with interest.
It was not clear to me from your note how familiar you are with =
Microsoft's efforts to obtain commerce export certification for their =
cryptographic APIs. You didn't mention any so I thought I would =
summarize some things I was told by various Microsoft representatives =
(including legal staff) in late 1996 at their "Security Design Review" =
held in Bellevue, WA. I'm not sure whether the APIs I was learning =
about at that meeting are exactly the same ones you wrote about, but I'm =
guessing they may be.
At the meeting, Microsoft provided betas of a variety of newish Internet =
products including code for certificate manipulation and their new =
cryptographic APIs. They also discussed in detail the APIs, including =
one that existed to allow cryptographic service providers to plug into =
their API in order to provide imlpementations of specific cryptographic =
techniques. For example, an RSA implementation supporting 128-bit keys =
could be provided to any application by plugging into that interface. =
(I believe this is the method you refer to by which the MSRPC code gets =
to any provider exporting the SSPI.) They demonstrated SSPI provided by =
a secure smart pcmcia card and one other third-party implementation as I =
recall.
When asked about the export implications and the security-with-a-hole =
issue, Microsoft explained that they did not want to have export =
problems for their platform, and therefore had implemented in their =
platform a mechanism by which an SSPI implementation would be verified =
(at load/bind time by the operating system)
to be certified by Microsoft (via the usual Authenticode code-signing). =
Microsoft would institute certain procedures for vendors wishing to =
build SSPI implementations loadable by the platform (described below) in =
which domestic-only SSPI implementations would be labelled/signed =
differently from exportable implementations. Microsoft would export =
versions of the platform that, as configured, would not load/bind with =
SSPI implementations labelled for domestic use only. Their plan to ship =
the platform with this design had been approved in spite of the fact =
that, of course, the platform could be maliciously altered to circumvent =
the load/bind-time verification procedure for SSPI components.
The procedures described by Microsoft for getting SSPI implementations =
certified were as follows: the vendor would apply to Microsoft for =
either Domestic-Only or Exportable ratings. Microsoft would sign the =
module with the Domestic-Only flavor provided that the vendor agreed =
that their product could not be legally exported etc. etc. Microsoft =
would provide the Exportable signature if the vendor certified to =
Microsoft that their software would comply with all application commerce =
export requirements and only be exported in compliance with the law etc. =
etc. No actual testing or behavior guarantee with respect to the =
vendor's SSPI implementation would be implied by Microsoft's action, =
merely that to get that signature from Microsoft, the vendor had =
acknowledged the appropriate obligation to comply with legal =
requirements.
I want to emphasize to you that I do not work for Microsoft, am not =
their agent, and have no first hand knowledge of their export control =
compliance or their implementation of CAPI. However, I did pay =
attention to what they said. Hopefully most of what I've summarized =
above can be verified or corrected by examining Microsoft's online =
developer support resources for CAPI and/or SSPI. (I tried to do this =
by visiting www.microsoft.com and searching for any document containing =
both "export" and "cryptographic", and the first three responses were:
1. Getting CSPs Signed =A0(premium=A0content)=20
http://premium.microsoft.com/msdn/library/sdkdoc/signcsp_05us.htm=20
2. CryptoAPI and the Microsoft Base Cryptographic Provider =
=A0(premium=A0content)=20
http://premium.microsoft.com/msdn/library/sdkdoc/signcsp_7stu.htm=20
3. Export Compliance Certificate (ECC) =A0(premium=A0content)=20
http://premium.microsoft.com/msdn/library/sdkdoc/signcsp_9wkf.htm=20
All look relevant to me, but I was unable to access any of them due to a =
registration wizard problem (I think).)
If the software you reviewed is relying on essentially the same design =
(and export approval plan) described to me in late 1996, then I think =
you'll probably find that Microsoft is trying hard to comply with the =
export rules and has probably obtained valid export licenses in spite of =
the fact that, of course, the enforcement mechanisms built into their =
platform can be easily defeated...just as easily as the domestic =
versions of their products can be exported/downloaded in violation of =
the law. That's life in cyberspace, at least until every executable you =
run is encrypted with your Pentium-III processor's public key, with the =
private key stored inside the chip and known only to Intel or no one.
--Jim O'Toole
----------
From: Robert Hettinga[SMTP:rah@shipwright.com]
Sent: Tuesday, May 19, 1998 5:27 PM
To: dcsb@ai.mit.edu
Subject: FYI: I believe Microsoft has knowingly violated the export =
rules
--- begin forwarded text
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to
owner-cryptography@c2.org using -f
Date: Tue, 19 May 1998 09:12:22 -0400 (EDT)
From: Rich Salz <rsalz@shore.net>
To: cryptography@c2.net
Subject: FYI: I believe Microsoft has knowingly violated the export =
rules
Sender: owner-cryptography@c2.net
I am sending this to people and mailing lists that I think may be
interested. I hope you find it useful and interesting.
-----BEGIN PGP SIGNED MESSAGE-----
The following information is not covered by any confidentiality =
agreements.
This documented is copyrighted; see details below.
Summary
=3D=3D=3D=3D=3D=3D=3D
This note explains and asks a number of pointed questions, including
"MSRPC, part of NT and Windows95, is crypto-with-a-hole and therefore
not exportable. So how come those operating systems can be exported?"
Answers should probably be provided by the US Government.
Content
=3D=3D=3D=3D=3D=3D=3D
The export of cryptography is controlled by a set of regulations
defined by the Executive Branch of the US Government. Regulations
often have the force of law, but do not undergo the same public
scrutiny that laws created by Congress do. The regulations involved
here are known as the Export Administration Regulations (EAR). The EAR
is currently facing some court challenges to its constitutionality.
The regulations say that hardware or software that does cryptography is
a munition, to be treated in the same manner (although not the same
degree) as rocket launchers, fighter jet spare parts, and nuclear
weapons. Unlike these other items, cryptography is math, and any
individual in the world can do math, and many can create new
mathematical techniques. In addition, many cryptographic processes, or
algorithms, are published in the open literature for peer review. (The
public-key cryptographic method known as RSA, one of the strongest
encryption techniques in the world, was described in "Scientific
American.")
The EAR says that the Department of Defense (DoD) determines whether or
not a product is exportable. DoD has delegated this authority to one
of its subsidiary organizations, the National Security Agency (NSA).
There is a special group within the NSA assigned to this task. They
decide on a case-by-case basis, and their determinations are not part
of the public record. The criteria by which they decide do not seem to
be known to anyone outside of the Agency. Part of the NSA's mission is
to intercept and interpret messages that could affect our national
security. It is a widespread assumption within the technical community
that they will deny general export to anything that they cannot easily
decode.
Microsoft likes to write their system software as "components" --
pluggable pieces that can be replaced with better versions later on.
Their method, and standard, for doing this is called COM, the Component
Object Model.
One such component is their Remote Procedure Call (RPC) system. RPC is
a technique that allows two different programs to communicate. When
two, or more, programs communicate over the network, RPC is the part of
the program on each host that packages up the request, sends it over
the network to the server, and then on the server side packs up the
reply and ships it over the network back to the client. A browser
fetching a web page can be considered a simple form of RPC
RPC is a backbone technology in the "client-server" programming model
dominant in today's multi-billion-dollar Information Technology field.
MSRPC is integral to the "distributed" part of COM. It is probably
most known to end-users under the terms ActiveX, ActiveXControls, and
to the technically savvy as DCOM.
MSRPC itself uses a Microsoft component known as the Security Support
Provider Interface, or SSPI. Third-party vendors are encouraged to
write their own SSPI -- there is a section on "Writing a Security
Provider" in Microsoft's on-line documentation. Digital Equipment
Corporation is one company that has done so. MSRPC will use whatever
SSPI's are available to protect data as it is passed between machines.
Microsoft's SSPI is provided in the "secsspi.dll" and "ntlmssps.dll"
files.
MSRPC provides a number of levels to protect data:
- None -- useful for demos or single-user applications, for example
- Authenticated -- the client and/or server can know the identity
of the party at the "other end of the line"
- Tamper-proof -- nobody can intercept the data and edit it, such
as to add an extra $1000 to an electronic invoice
- Full privacy -- only the intended recipient can decrypt and
read the data.
This last one -- full privacy -- is the item of interest. The EAR
allows cryptography to be exported when used for authentication (the
second, and perhaps the third, case above), but not when it can be used
to protect whatever data a user wishes to keep private.
When a user wants full privacy, the MSRPC component requests the SSPI
to encrypt the data. In export versions, the SSPI returns an error
code, and MSRPC returns the status back to the user's program
indicating that this level of protection is not supported. In the
domestic US versions, the SSPI actually does encrypt the data.
The problem is that the NSA ordinarily calls the technique used by
Microsoft "crypto with a hole," and they routinely deny export approval
for such products. Their reasoning is that it would be fairly
straightforward to "add in" the cryptography. Their reasoning is
accurate: It is much easier to write a "plug in" -- a small bit of
crypto code based on a published paper -- than it would be to write an
entire RPC component.
For this particular situation, the NSA's concerns are demonstrably
well-placed. All of the above has been independently discovered by one
person who turned an export version of Windows into a full-strength
cryptographic device in one night of "poking around" with a
programmer's toolbox. If only to avaoid the nuisance of putting this
note itself under export control, I won't provide more information.
All of the above brings to mind the following questions. At least.
- Why is Microsoft allowed to do this when other companies
are not?
- Did Microsoft ask for approval before or after the fact?
- If before, how come the NSA gave them permission --
particularly when the user base is probably orders of
magnitude greater than any other system?
- If after, how come the world's largest software company didn't
know about this basic fact of life for security software?
- If after, when did they know, and what steps did they take to
make changes, or why not?
- Do NT5 and Windows98 work the same way?
- If so, should Microsoft be allowed to export them?
There is another part of the story. Microsoft has licensed much of its
ActiveX technology (including MSRPC and SSPI) to SoftwareAG, a German
software company that has modified it to run it to a number of
non-Microsoft systems. SoftwareAG calls their version EntireX.
According to "Essential Com" [ISBN 0201634465], this work was done in
Germany by German citizens. According to their Web pages (at
www.sagus.com), EntireX -- including the security facility -- is
available on OS/390, an IBM mainframe operating system. More
questions:
- Did Microsoft give actual cryptographic source, not just the
harder-to-modify executables, to foreign nationals?
- Does this mean that Microsoft gave technology to a foreign
company that lets them sell full-privacy security software
overseas, where IBM itself cannot? Software that competes
with products offered by IBM and others?
- Has Microsoft licensed this technology to anyone else?
Author
=3D=3D=3D=3D=3D=3D
Rich Salz
Georgetown, Massachusetts
http://www.shore.net/~rsalz
History
=3D=3D=3D=3D=3D=3D=3D
This is Draft 2, dated May 18, 1998.
Draft 1 (May 14, 1998) received limited circulation (including to the
United States Bureau of Export Administration, the agency responsible
for enforcing the EAR).
Copyright
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Copyright 1998, Rich Salz.
All Rights Reserved.
Permission is given to redistribute any tamper-evident version of this
document that has been signed with the following PGP key:
bits/keyID Date User ID
1024/462D47D1 1998/05/15 Rich Salz <rsalz@shore.net>
Fingerprint =3D 7D 7C C1 57 EE 49 49 D1 6F F4 FA 27 E1 4F 86 E5
All trademarks are property of their respective owners and are hereby
respectfully acknowledged.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNWGCcJANqsNGLUfRAQE+GQP/bHy0JB9Te8H5vlJKjIGHEWEvnkEZVFuB
ba/L6LTZ+/zQ/luCRSHP9vX6GQj8EDThiX+YO17URUTDBp/BoV0vmwVGjXJWSIgE
bIjS7znFutbufm7BEVDbg/jysRhn32eisuOXOcvGOFtowA4eY6Tz7BYXZ1gbSpyC
U/Efxez7qTk=3D
=3DT+M2
-----END PGP SIGNATURE-----
--- end forwarded text
-----------------
Robert Hettinga (rah@shipwright.com), Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
The e$ Home Page: http://www.shipwright.com/
For help on using this list (especially unsubscribing), send a message =
to
"dcsb-request@ai.mit.edu" with one line of text: "help".
