What Is BitLocker TPM+USB+Pin Authentication?
BitLocker in Windows Vista supports the following major methods for unlocking a protected volume:
TPM-only
TPM + Startup Key (USB) combination
TPM + PIN combination
Startup Key (USB)-only
The new TPM+USB+Pin feature in Windows Vista SP1 offers an additional multifactor authentication method that combines a key protected by the TPM with a Startup Key stored on a USB storage device and a user-generated Personal Identification Number (PIN). During boot, BitLocker will use TPM to ensure system integrity, request the user to present the Startup Key, and request the user to enter a PIN before it allows the machine to boot into operating system. These three factors will allow customers to implement a simpler security policy to meet higher security standards usually required in the government space.
What’s New in BitLocker TPM+USB+Pin Authentication?
A new 3-factor authentication method has been added
The customer can use the BitLocker command-line tool manage-bde.wsf to turn on BitLocker using this new authentication. (Note: the BtLocker Control Panel does not provide access to this function.)
Who Should Use BitLocker TPM+USB+Pin Authentication feature enhancements?
This feature is targeted at the following audiences, who are interested in BitLocker and interested in 3-factor authentication:
IT planners and analysts who are evaluating the product.
Enterprise IT planners and designers.
Early adopters.
Security architects who are responsible for implementing trustworthy computing.
Benefits of new features in BitLocker TPM+USB+Pin Authentication
The user can take advantage of the secure-startup protection that the TPM offers.
The user can make sure that they use “something they have” – the SK on the USB storage device.
In addition to these two factors for unlocking, the user can add “something you know”– the PIN. This is useful for
Maximizing data protection when the USB dongle is lost along with the computer
Minimizing the value of an attacker maliciously copying a Startup Key as discussed above.
Reducing the security dependency that customers have on a single piece of hardware; specifically the TPM.
With 3 unlocking factors, the user can have a high degree of protection for the data on his/her drive.
Key Scenarios Scenario 1 – Protect the machine using 3-factor authentication: Goal
A customer installs Windows Vista and wants to use BitLocker to the most secure extent by providing not only the Startup Key but also his/her PIN.
BitLocker ready computer, which passes BitLocker logo tests.
Prerequisites or specific configuration for the scenario
None.
Step-by-step scenario description
1. Turn on BitLocker on the operating system (boot) volume using the command-line tool manage-bde.wsf and specifying TPM+USB+Pin option.
2. Start encryption and wait for the encryption to finish.
3. Reboot the machine 1) without USB key, 2) with USB key but without providing PIN, 3) with USB and PIN.
Expected results
Only 3) in Step 3 will allow the customer to boot successfully into the operating system.
Known Issues for scenarios
None.
CAPI2 Revocation What Is CAPI2 Revocation?
CryptoAPI (CAPI) is the core cryptography and X.509 certificate support in Windows. CAPI2, in particular, refers to the support for PKI and X.509 certificates such as the functionality for certificate path validation, certificate stores and signature verification. One of the steps during certificate path validation is revocation checking which involves verifying the certificate status to ensure that it has not been revoked by its issuer. Online Certificate Status Protocol (OCSP) is a method for checking revocation status of a certificate.
What’s New in CAPI2 Revocation?
Support for Independent OCSP signer chain and specifying additional OCSP download locations per issuer
In Windows Vista, the OCSP client requires that the OCSP responses be signed by the issuer of the certificate that is being validated or a signer delegated by this issuer. Windows Vista SP1 modifies the OCSP implementation such that it can work with OCSP responses that are signed by trusted OCSP signers that are separate from the issuer of the certificate being validated. Additionally, in Windows Vista SP1, it is possible to specify OCSP download locations for issuing CA certificates. These OCSP URLs are added as a property to the CA certificate.
Who Should Use CAPI2 Revocation feature enhancements?
This feature is targeted at the following audiences:
Enterprise IT planners and designers: Particularly, this would be useful for PKI planners and administrators.
Early adopters.
Benefits of new features in CAPI2 Revocation
Support for Independent OCSP signer chain and specifying additional OCSP download locations
In Windows Vista, the OCSP signer certificate must be either the Issuer certificate or a certificate delegated by the issuer. A delegated certificate is signed by the issuer certificate and contains the szOID_PKIX_KP_OCSP_SIGNING (1.3.6.1.5.5.7.3.9) EKU. When using Windows Vista, it is not possible to successfully use the OCSP client for validation in deployments where the OCSP signer is not a delegated signer and has an independent chain separate from the end entity certificate’s chain. This new feature in Windows Vista SP1 will enable use of the Windows OCSP client in scenarios and deployments which have the OCSP signer certificate chaining up to a different trust anchor or a self signed OCSP signer.
The ability to specify OCSP download locations per issuer provides a huge manageability benefit. IT administrators can now use OCSP for revocation checking without having to reissue certificates simply because they did not contain an OCSP URL in the AIA extension.
Key Scenarios
Support for Independent OCSP signer chain and specifying additional OCSP download locations
Scenario 1 – Specify OCSP download locations Goal of the scenario:
The objective is to specify a OCSP download location for an issuer certificate which has been used to issue end certificates that do not contain any OCSP location in the AIA extension.
Specific hardware requirement:
No specific hardware requirement except for the hardware needed to setup a PKI infrastructure along with an OCSP responder. See the prerequisites below for more details.
Prerequisites or specific configuration for the scenario:
The organization has a public key infrastructure set up for the domain. For more information, see "Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure" at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx
The organization has an OCSP responder deployed for revocation checking purposes.
The deployment has client machines with certificates deployed that do not have an OCSP download location specified in the AIA extension.
Step-by-step scenario description:
1. Configure the OCSP responder to sign valid responses for a specific URL. Note: This URL needs to be specified for the certificates so that OCSP can be used for revocation checking. You can specify the OCSP download location corresponding to a CA certificate so that all certificates issued by that CA certificate will use this download location for OCSP.
2. To specify OCSP download locations, perform the following steps:
a. Click Start, click Start Search, type mmc, and then press ENTER.
b. On the File menu, click Add/Remove Snap-in, and then click Add.
c. Double-click Certificates under Snap-in.
d. Click Computer account and select Local computer.
e. Click Finish, and then close the dialog boxes.
f. In the management console tree, under Intermediate Certification Authorities, click Certificates.
g. Right-click the certificate in the store, for which you want to specify the OCSP download location and click Properties.
h. You will see 3 tabs: General, Cross-Certificates and OCSP. Click the OCSP tab.
i. Enter the URL in the text box next to Add URL button and click Add URL. The URL should show up in the list below.
j. If you would like to disable the use of Certificate Revocation Lists and use only OCSP for revocation checking, check the checkbox for Disable Certificate Revocation Lists (CRL). Note that this would disable use of the CRL information already present in the CRL distribution point extension in the certificate.
k. Click OK to confirm the changes.
3.Validate a certificate that was issued by this CA certificate.
Expected results:
Windows Vista SP1 is able to correctly provide the revocation status for the certificate using the specified OCSP URL.
Exceptions Scenario 2 – Use internal OCSP responder when firewall policies prevent network retrieval for revocation checking: Goal of the scenario:
Deployment has clients using commercial CA certificates. As part of revocation checking, it is necessary to setup an outbound network connection on port 80 to download revocation information. Firewall policies prevent outbound network connections on this port. The administrator sets up an internal OCSP responder to issue OCSP responses based on the commercial CA’s CRL. The goal is enable the administrator to configure the certificates to point to the internal OCSP responder to fetch the revocation information.
Specific hardware requirement:
No specific hardware requirements
Prerequisites or specific configuration for the scenario:
Outbound network connections are blocked by firewall
Clients use commercial CA certificates but need to go to the network to download the revocation information.
Step-by-step scenario description
1. Set up an internal OCSP responder based on the CRL issued by the commercial CA. The administrator would be responsible for updating the revocation information at the responder on a regular basis. Configure the responder to sign valid OCSP responses at an intranet URL. Now this URL needs to be specified for the certificates so that revocation checking can be successfully performed. You can specify the OCSP download location corresponding to the commercial CA certificate so that all certificates issued by that CA certificate will use this download location for OCSP.
2. To specify OCSP download locations, perform the following steps:
a. Click Start, click Start Search, type mmc, and then press ENTER.
b. On the File menu, click Add/Remove Snap-in, and then click Add.
c. Double-click Certificates under Snap-in.
d. Click Computer account and select Local computer.
e. Click Finish, and then close the dialog boxes.
f. In the management console tree, under Intermediate Certification Authorities, click Certificates.
g. Right-click the certificate in the store, for which you want to specify the OCSP download location and click Properties.
h. Click the OCSP tab.
i. Enter the URL in the text box next to Add URL button and then click Add URL. The URL should show up in the list below.
j. If you would like to disable the use of Certificate Revocation Lists and use only OCSP for revocation checking, check the checkbox for Disable Certificate Revocation Lists (CRL). Note that this would disable use of the CRL information already present in the CRL distribution point extension in the certificate.
k. Click OK to confirm the changes.
3. Validate a certificate that was issued by the commercial CA certificate.
Expected results:
Windows Vista SP1 is able to correctly provide the revocation status for the certificate using the specified OCSP URL.
Exceptions
None.
Scenario 3 - Check revocation using OCSP when OCSP signer certificate chains up to a different root than the root for the end entity certificate Goal of the scenario:
The objective of this scenario is to successfully perform revocation checking using OCSP on Windows Vista SP1 when the OCSP signer certificate chains up to a different root than the root for the end entity certificate.
Specific hardware requirement:
No specific hardware requirement except for the hardware needed to setup a PKI infrastructure along with an OCSP responder. See the prerequisites below for more details.
Prerequisites or specific configuration for the scenario:
The organization has a public key infrastructure set up for the domain. For more information, see “Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure” at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx
The organization has an OCSP responder deployed for revocation checking.
There is a separate root to issue the OCSP signer certificates.
The chain for the OCSP signer certificate is different from the certificate chain from the end entity certificate to the root.
Step-by-step scenario description:
1. Configure the OCSP responder to sign valid responses for a specific URL. To exercise this scenario, the OCSP signer certificate should be signed by a different trusted root certificate than the root certificate that is used for issuing the end-entity certificates.
2. Issue an end-entity certificate that contains the OCSP URL specific to the OCSP responder in its AIA extension. If the end-entity certificates are already issued and only the OCSP locations need to be specified, add the OCSP download location for the issuing CA certificate as described in the first scenario.
3. Validate this end-entity certificate that was issued in step 2.
Expected results
Windows Vista SP1 is able to correctly provide the revocation status for the end-entity certificate.
Exceptions
None.
Known Issues for scenarios
None.
| 