We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Novell (NOVL) dirt cheap, good buy? -- Ignore unavailable to you. Want to Upgrade?

To: PJ Strifas who wrote (27994)9/4/1999 11:00:00 PM
From: Frederick Smart  Respond to of 42771
Microsoft, the NSA, and You

>>Here is the press release; for the full details, look here.

A sample program which replaces the NSA's key is here, at the bottom of the page.>>


Does this mean Microsoft cooperated with NSA to allow for the inclusion of an NSA public key??

Feedback appreciated. Help!



Microsoft Installs US Spy Agency with Windows

Research Triangle Park, NC - 31 August 1999 - Between Hotmail hacks andbrowser bugs, Microsoft has a dismal track record in computer security. Most of us accept these minor security flaws and go on with life. Buthow is an IT manager to feel when they learn that in every copy of Windows sold, Microsoft may have installed a 'back door' for the National Security Agency (NSA - the USA's spy agency) making it orders of magnitude easier for the US government to access their computers?

While investigating the security subsystems of WindowsNT4, Cryptonym's Chief Scientist Andrew Fernandes discovered exactly that - a back door for the NSA in every copy of Win95/98/NT4 and Windows2000. Building on the work of Nicko van Someren (NCipher), and Adi Shamir (the 'S' in
'RSA'), Andrew was investigating Microsoft's "CryptoAPI" architecture for security flaws. Since the CryptoAPI is the fundamental building block of cryptographic security in Windows, any flaw in it would open Windows to electronic attack.

Normally, Windows components are stripped of identifying information. If the computer is calculating "number_of_hours = 24 * number_of_days", the only thing a human can understand is that the computer is multiplying "a = 24 * b". Without the symbols "number_of_hours" and "number_of_days", we may have no idea what 'a' and 'b' stand for, or even that they calculate units of time.

In the CryptoAPI system, it was well known that Windows used special numbers called "cryptographic public keys" to verify the integrity of a CryptoAPI component before using that component's services. In other words, programmers
already knew that windows performed the calculation "component_validity =
crypto_verify(23479237498234...,crypto_component)", but no-one knew exactly
what the cryptographic key "23479237498234..." meant semantically.

Then came WindowsNT4's Service Pack 5. In this service release of software
from Microsoft, the company crucially forgot to remove the symbolic
information identifying the security components. It turns out that there are
really two keys used by Windows; the first belongs to Microsoft, and it allows
them to securely load CryptoAPI services; the second belongs to the NSA. That
means that the NSA can also securely load CryptoAPI services... on your
machine, and without your authorization.

The result is that it is tremendously easier for the NSA to load unauthorized
security services on all copies of Microsoft Windows, and once these security
services are loaded, they can effectively compromise your entire operating
system. For non-American IT managers relying on WinNT to operate highly secure
data centers, this find is worrying. The US government is currently making it
as difficult as possible for "strong" crypto to be used outside of the US;
that they have also installed a cryptographic back-door in the world's most
abundant operating system should send a strong message to foreign IT managers.

There is good news among the bad, however. It turns out that there is a flaw
in the way the "crypto_verify" function is implemented. Because of the way the
crypto verification occurs, users can easily eliminate or replace the NSA key
from the operating system without modifying any of Microsoft's original
components. Since the NSA key is easily replaced, it means that non-US
companies are free to install "strong" crypto services into Windows, without
Microsoft's or the NSA's approval. Thus the NSA has effectively removed export
control of "strong" crypto from Windows. A demonstration program that replaces
the NSA key can be found on Cryptonym's website.

Cryptonym: Bringing you the Next Generation of Internet Security,
using cryptography, risk management, and public key infrastructure.

Interview Contact:
Andrew Fernandes
Telephone: +1 919 469 4714
Fax: +1 919 469 8708

Cryptonym Corporation
1695 Lincolnshire Boulevard
Mississauga, Ontario
Canada L5E 2T2

# # #

To: PJ Strifas who wrote (27994)9/4/1999 11:19:00 PM
From: PJ Strifas  Read Replies (1) | Respond to of 42771
It's interesting that someone finally makes sense in an article and actually tells some truth about an upcoming MSFT product.

Check my next post for more on why I think this is important.

Peter J Strifas
A flaw in Active Directory?

By Dave Kearns
Network World, 08/16/99

In Network World Fusion's "Windows NT" newsletter I've been taking a close look at Active Directory as it is implemented in Windows 2000. In the August 2 newsletter, I outlined the Active Directory replication and synchronization strategy. But the more I think about it, the more afraid I become.

Active Directory uses multimaster replication. No more Primary Domain Controllers (PDC) and Backup Domain Controllers (BDC) - all Domain Controllers are equal peers. Objects can be manipulated on any Domain Controller, and the changes are then propagated to the remaining domain controllers. While this is easier on the administrator than the PDC-BDC mode of NT 4 (where all changes had to be made on the PDC), it means that there needs to be a way to reconcile changes which might be made to the same object on different Domain Controllers.

There is no time synchronization among the Domain Controllers, so changes based on time stamps won't work. Instead, a concept called the Update Sequence Number (USN) is used. Each Domain Controller holds a table containing entries for its own USN and the USNs of its replication partners. During replication, the Domain Controller compares the last known USN of its replication partner (saved in the table) with the current USN that the replication partner provides. If there have been recent changes (that is, if the replication partner provides a higher USN), the data store requests all changes from the replication partner. After receiving the data, the directory store sets the USN to the same value as that of the replication partner. This only guarantees that all changes made on a single Domain Controller will be propagated in the correct order.

If properties on the same object are changed from different domain controllers, a series of comparisons must be made by Active Directory to decide which is the correct order of changes.

The first decider is the version number. All properties carry a version number that is incremented with each change, and the higher version always takes precedent. But if I make two changes to an object on one Domain Controller (+2 to the version number), then make a change to the same object on another Domain Controller (+1 to the version number) before the first changes are propagated, my second change - not the third one, which would be correct - is the one accepted as final.

If the version numbers on the changed object are the same, then the timestamps on the changes are used. But because there is no time synchronization between Domain Controllers, this could lead to wrong information being propagated.

If both version number and timestamp are the same, Active Directory performs a binary memory copy operation and compares the buffer size. The higher buffer size wins. If the two buffers are equal, the data is the same, and one can be discarded. If they're not the same, though, there's nothing to guarantee that the correct information is chosen - just the one with a bigger buffer size!

Because none of these methods guarantees that correct information is propagated, all possible changes are logged. You can peruse the logs, then make further changes to correct the errors - and hope that they get propagated correctly.