- Maximizing Certificate Services Implementations
- Securing Certificate Services
- Getting the Most Out of Smartcards
- Tips and Tricks for Securing Access to the Network
- Creating a Single Sign-on Environment
- Securing Access to Web Servers and Services
- Protecting Certificate-based Services from Disaster
- Integrating Smartcards with Personal Devices
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Getting the Most Out of Smartcards
Any security measure that makes it harder for end-users to do their job is never accepted whole-heartedly. Administrators have to perform extensive planning and usability studies within their organizations.
Contact-less Smartcard Support
Windows Server 2003 and Windows XP do not support the type of devices known as contact-less smartcards.
Choosing an Appropriate Smartcard
There are a variety of smartcards and USB tokens from which to choose. Smartcards that are used in a Windows Server 2003 environment run on the Microsoft Smartcard operating system. Smartcards and their readers must adhere to the ISO 7816 standard. To ensure compatibility you should always test the smartcard with the reader and confirm that USB ports will be available for token type devices.
Administrators have to plan for the usage requirements for the smartcards or USB tokens. The following list includes some considerations for the physical card or token:
Hardware type (card or USB token)
Memory requirements
Company's intended lifetime of device
Company's intended roles for device
Reader hardware
Physical location and availability of USB ports
Device management software
Memory Requirements
Smartcards and tokens use their memory to store the certificate of the user, the smartcard operating system, and additional applications. To use the smartcard in a Windows logon environment, you must be able to program the card to store the user's key pair, retrieve and store an associated public certificate, and perform public and private key operations on behalf of the user (enrollment agent).
Smartcards come in two common memory configurations—8KB and 32KB. To use the Microsoft Smartcard operating system, you need to specify the 32KB device.
Maximum Length of User's Logon Certificate
The maximum length of the user's logon certificate is 1,024 bits due to fact that it is the largest certificate that will fit in the 2.5KB space provided on the smartcard.
The components that make up the memory storage requirements on a typical 32KB smartcard device are listed in Table 3.1
Table 3.1 Typical Smartcard Memory Use (32KB Device)
|
Content |
Memory Used |
|
Windows for Smartcards operating system |
15KB |
|
Smartcard Vendor Applications |
8KB |
|
Smartcard logon certificate |
2.5KB |
|
Company Custom Applications (if any) |
1.5KB |
|
Free Space |
5KB |
The memory configuration of the smartcard is ultimately up to the company and the administrator. Smartcards can be divided into public and private memory spaces. You can define separate protected memory for the operating system, certificates, e-wallets, and other applications. This section of the card's memory can be allocated as Read Only.
The memory capacity on smartcards is increasing as vendor technology improves. This allows for more applications and certificates to be stored on the card or token. Multiple uses can be specified for the cards and the memory requirements that affect these applications should be taken into consideration when deciding to purchase such devices.
Multiple Applications Must Use a Single Smartcard Logon Certificate
Multiple applications, such as physical access and secure logons, must use a single smartcard logon certificate. Windows Server 2003 and Windows XP do not support the use of multiple certificates on a single smartcard device.
Smartcard Roles
Administrators have three roles of smartcards at their disposal. When planning the company's smartcard deployment you need to determine the number and type of each card.
Enrollment cards are issued to personnel who will be enrolling smartcards on behalf of other users. These cards have a special enrollment agent certificate that enables the card's user to act on behalf of the administrator.
User cards can be permanently issued and point to a permanent certificate server
User cards can also be temporary use cards that point to temporary certificates.
In better defining the user cards, the two types are as follows:
Permanent cards are issued to the employees to be carried with them at all times. These cards contain the cardholder's credentials, certificates, data, and custom applications. Customization of the cards might include company logos and a photograph of the cardholder.
Temporary cards are issued for limited-use and are issued to users such as guests, temporary employees, and employees who have forgotten their permanent cards.
Smartcard Life Expectancy
Administrators must take into account a few factors when deciding on the type and durability of the smartcards or tokens. These considerations should be based on the normal wear and tear expected on the device and the length of end-user's usage.
When purchasing the smartcard device you should ask the vendor(s) for expected lifetime documentation for the device.
Smartcard Reader
The physical device that the computer uses to interface with the smartcard is known as the "smartcard reader." The readers come in a few form factors, including USB, RS-232 serial port, and Personal Computer Memory Card International Association (PCMCIA) Type II slot.
The USB style token device is the simplest of the smartcard/reader combinations because it doesn't require a separate smartcard reader. One item to consider when choosing this type of device is the physical availability and access to open USB ports on the end-user's computer.
Smartcard Management Tools
You need to evaluate the bundled software that comes with the smartcard or token device. The management software can enable you and the company's developers to customize the memory allocation and custom applications.
Some smartcard and token device manufacturers supply additional security management software as well. This is important when the deployment of smartcards is transitioning from pilot to production as well as maintaining the user's smartcard credentials on the devices.
Custom application development requires a robust application programming interface (API) from the smartcard vendor. This is especially important when combining multiple uses of the smartcard such as building access and secure logon and application access.
Making Users Use Smartcards
By using group policies you can enforce user's behavior. The policies that affect smartcards are shown in Figure 3.1 and Figure 3.2
)
Figure
3.1 Group policy smartcard enforcement.
Many company expenditures are underused, if used at all, because of increasing end-users perceived complexity. The smartcard is one device that can make the users' experience actually become easier
)
Figure
3.2 Group policy smartcard removal behavior.
Users will find that they don't have to memorize those hard-to-remember strong passwords. Administrators won't find yellow Post-it notes with the user's strong password stuck to the lower-corner of the user's monitor or under her keyboard.
Providing Security Reports
More laws are passed every year that place companies and consultants at risk of not protecting users and client's data.
By verifying who a user is and when and where he signed on to the system, it makes it easier to prove that person's identity and possibly his intentions.
Security and financial auditors need to be able to read reliable reports of not only hacking attempts but also normal day-to-day network usage and system access.
Administrators of Windows Server 2003–based -CA servers can provide reporting on the following functions.
To Take Advantage of Windows Server 2003 Auditing...
To take advantage of Windows Server 2003 auditing you need to enable Audit object access by using the Group Policy Object Editor and drilling down to Computer Configuration/Windows Settings/Security Settings/Local Policies/Audit Policy and double-clicking on Audit Object access.
The CA audit log generates two types of events:
Access check
System events
CA-related system events are generated in seven key categories:
Back up and restore the CA database
Change CA configuration
Change CA security settings
Issue and manage certificate requests
Revoke certificates and publish CRLs
Store and retrieve archived keys
Start and stop Certificate Services
Administrators can enable and configure CA event auditing by performing the following steps:
Log on to the server with an account with one of the following permissions: Domain Administrator, Certificate Authority Administrator, or Certificate Authority Auditor.
Click on Start, Programs, Administrative Tools, Certification Authority.
In the console tree, right-click on the name of the CA on which you want to enable event monitoring and select Properties.
-
On the Auditing tab, click on the events to audit as shown in Figure 3.3.
Auditing CA Events
Auditing CA events is only available on Windows Server 2003, Enterprise and Datacenter Editions.
)
Figure
3.3 Enabling auditing on the Certification Authority.