If you require unattended booting, you'll need to store the system key on
the hard drive. But don't worry, the system key is reportedly stored using a
complex obfuscation algorithm, and is accessible to only core OS security
components. Microsoft says it will provide the means to obtain the system key
from a tamper-proof hardware device attached to the system, thus creating the
fourth, and most powerful way of handling system keys. I don't know when
Microsoft will implement this fourth method.
A warning to would-be system key users: If you forget your system
key or lose the floppy disk, you might not be able to start your NT system.
Therefore, protect system key information diligently by creating backup copies
of the floppy or giving the password to more than one person. If you lose the
system key, you have only one way to recover the system: Use an ERD to restore
the Registry to a state before you enabled strong encryption, and start over
from scratch to implement the feature. If you want to use the password version
of the system key feature, consider creating a long password, dividing it into
parts, and giving an equal part to several different users. This way, no
individual can boot the system, and all holders of a part of the password must
enter their parts in the correct order before the system will boot. This
approach can seem paranoid, but some people need this level of control.
You can configure strong encryption independently on the Primary Domain
Controller (PDC) and each Backup Domain Controller (BDC). Each domain controller
will have a unique password encryption key and a unique system key. You cannot
use keys across multiple systems; each system must use a unique key set,
regardless of domain participation roles. Before enabling the feature on your
domain controllers, ensure that BDCs are completely in sync with the PDCs. Also,
create a fresh ERD before you start. (Be sure to read Microsoft's Knowledge Base
article Q143475 on this topic.)
CryptoAPI 2.0
As with many of Microsoft's names, CryptoAPI is an acronym. It stands for
Cryptography application programming interface. CryptoAPI 2.0 gives developers
core cryptographic and certificate functions and is an upgrade to CryptoAPI 1.0.
CryptoAPI provides the underlying technology to add security features to
applications. Examples are the ability to digitally sign a document and send it
over the Internet, and the ability to verify an individual's identity in an
exchange of personal information. Signing documents is like attaching a secret
code, or certificate, that you can positively identify as belonging to a
certain owner. If owners protect their personal certificates from being copied,
no one will be able to use a digital signing technique to impersonate them. This
approach is like having a driver's license that identifies only you.
Certificate authorities are agents entrusted to issue the keys and attest
to the validity of a given cryptography key. To get a key, you contact a
certificate authority, such as Verisign, which will give you all the information
about how to obtain a security certificate. (Find Verisign on the Web at
http://www.verisign.com.)
You can see the CryptoAPI in action if you're using Microsoft's Outlook
Express client (formerly, Microsoft Internet Mail). In the configuration
settings under Tools, Mail Options, Security, you can configure your key certificate for signing email messages--once you have a key.
CryptoAPI 2.0 uses a service-provider model: Cryptographic Service
Providers, such as the Microsoft RSA Base Provider included with SP3, provide
the cryptography. This model lets developers easily adapt their applications to
evolving cryptographic technologies and government export policies. Exporting
cryptographic tools that use key lengths longer than 56 bits is a Federal
offense (see Mark Smith's editorial, "The Key to the Kingdom," June
1997, for more information about this situation).
CryptoAPI 2.0 supports existing standards, such as X.509 v.3 certificate
formats, ASN.1 encoding, and both PKCS #7 and #10 for encapsulation. Thus,
applications using CryptoAPI can operate with other certificate-based systems
that adhere to the same standards.
Microsoft says the release version of CryptoAPI 2.0 contains several
updates to the developer's release of September 1996, including both parameter
changes and naming changes. These changes are reflected in the crypt32.dll and
wincrypt.h files. For complete details on the new CryptoAPI 2.0, be sure to
consult the documentation at http://www.microsoft.com/security/tech/misf6_2-f.htm or http://www.microsoft.com/workshop/prog/security/capi/cryptapi.htm (if your browser doesn't support frames).
NT Security Info
You've been briefed on the new security enhancements in SP3. So, how do you
keep up with all the new holes that are popping up these days? Monitor the
security resources on the Internet. You'll find numerous mailing lists, Web
sites, whitepapers, Frequently Asked Question (FAQ) lists, and other information
sources. Try locating a good digest of security information. Digests usually
contain only the important items you need, such as new security risks, new
tricks, and new tools. One example that caters exclusively to NT security
concerns is my free NT Security Digest (NTSD), published each month. Point your
Web browser to http://www.ntsecurity.net, or http://www.ntshop.net (both
lead to the same site).