In our previous blog posting, we explained WinMagic’s two-stage model for enterprise key file deployment. Enterprise key file deployment is a highly complex endeavor, with many use cases for device provisioning to consider and address; additional challenges include speed, security, and scalability. To overcome these challenges, the WinMagic model leverages pre-boot networking. In this blog posting, we explain the basics of pre-boot networking, examine how it can be utilized to improve key file deployment, and study the benefits provided by using it throughout the enterprise.

Pre-Boot Networking (PBN) and PBN Authentication

Provisioning devices with key files in conjunction with deploying full disk encryption (FDE) technologies creates a chicken-or-the-egg problem. You want to make sure that the devices provided to users are already secured, but how do you encrypt storage so that a user who hasn’t even been identified yet will be able to decrypt it on demand? The solution is to use pre-boot networking.

Pre-boot networking (PBN) is the process of performing network-based actions before boot, and the specific act of using PBN to perform user authentication is called pre-boot network authentication (PBN authentication). In many cases, organizations pair the PBN authentication with post-boot operating system authentication.

There are two types of PBN authentication: PBN device authentication and PBN user authentication.

PBN Device Authentication

PBN device authentication is also known as PBN autoboot. Autoboot occurs when unattended, automatic authentication occurs before boot for the user’s initial login to the device.

PBN device authentication can be used both for initial key file deployment and also for performing authentication of devices that should be able to boot without a person present, such as a server. Another scenario that may necessitate reliance on PBN device authentication is a desktop computer in a hospital that is accessible by many employees; after PBN device authentication occurs to verify the legitimacy of the device and the operating system decrypts and boots, user-level authentication can be enforced separately.

For more information about PBN Device Authentication, see the recent WinMagic blog posting from Derek Tsang.

PBN User Authentication

PBN user authentication is critically important for facilitating FDE deployments and usage because it provides a reliable and up-to-date source of authentication credentials for users that can be accessed before the device’s operating system is loaded.

This is a fundamentally superior approach to enterprise FDE provisioning and deployment because it allows a user to utilize any endpoint device that he or she is authorized to use without an administrator having to act to configure and deploy credentials to that device for that particular user in advance. Removing this major barrier to device provisioning is as important to the practicality and effectiveness of FDE technologies as the advent of local area networks was to the computing landscape in the 80s.

Let’s look more closely at three types of PBN user authentication:

• PBN User Authentication with Active Directory
• PBN User Authentication with Smart Cards
• PBN User Authentication by Key Manager

PBN User Authentication with Active Directory

Using PBN user authentication with Active Directory during device provisioning and use is straightforward. The figure shows the three steps involved in authenticating the user, ensuring that the user is authorized to access the device, and deploying the necessary key file to the device for future use. Let’s walk through these steps.

Step 1

The user powers up an enterprise device that has its storage protected by FDE technology. The storage cannot be decrypted until after the user is successfully authenticated, and this authentication is required and provided by the PBN user authentication implementation. When the user is prompted to authenticate, he or she enters the necessary credentials.

Step 2

Assuming that the device can access the enterprise network, the PBN user authentication implementation will verify with enterprise key management services if the user is authorized to access the device. If this is true, then it will send the provided credentials to the enterprise Active Directory server for validation. If the credentials are valid, the server will send a confirmation to the enterprise key management services.

Step 3

If the user is authorized to access the device and the user’s credentials are valid, the enterprise key management services will send the key to the device in the form of a key file that is in turn protected by the user’s credentials. The device then uses this key to decrypt the hard drive and initiates the boot of the operating system.

Note that if the device cannot access the enterprise network, such as when a user is on travel, access to the device is still possible, assuming that the user has previously been authenticated by PBN user authentication for that device and their credentials have not changed since the last PBN user authentication occurred. This is because the PBN user authentication process can store the key file on the local device, so that file can be used to authenticate the user in lieu of the entire PBN user authentication process.

Storing the key file locally on the endpoint is optional. The administrators of PBN user authentication services can configure local storage for each user/device combination. For example, an organization might permit local key file storage for single-user devices but not multi-user devices.

Other Forms of PBN User Authentication at Pre-Boot

In addition to the scenario just described for user-based Active Directory authentication, the same PBN authentication implementation can be used as the basis for performing other forms of user authentication at pre-boot. Examples include the following:

• PBN user authentication with smart cards. A smart card can be used with the local device for enterprise authentication before boot. Once the smart card is read by the device during pre-boot, the device passes the smart card’s certificate ID to the enterprise key management server. This causes the server to return to the device a key file that is encrypted using the public key on the smart card. The user can only decrypt this key file by having authenticated successfully to the smart card; key file decryption then grants access to the key needed to decrypt local storage and boot the operating system.
• PBN user authentication by key manager. In this example, authentication and authorization can be performed by the enterprise key management server itself. This is highly useful if the enterprise does not want to use existing enterprise authentication services for PBN user authentication. The user enters credentials during pre-boot and these are forwarded to the enterprise key management server. The server authenticates the user, and if authentication succeeds, the server then provides a key file to the user’s device. The device then uses a key from that file to decrypt the local storage so that the operating system can boot.

Caching Key Files

The next question after authentication is what to do and where to store the user key file. In a user provisioning scenario, the organization may want to store or cache the key file locally so the user can login in an offline mode. This behavior is analogous to the first time a Windows user logs in to a domain workstation. However, in another use case scenario, a support/helpdesk user may authenticate to a workstation only for troubleshooting requirements. The organization may not want this support or helpdesk user’s key file to be cached. Furthermore, security or compliancy requirements may impose that the key to unlock the disk must not be stored on the data drive. For this scenario, the key file can be stored directly on a token/smartcard (if feasible) or on external media, e.g., USB drive. At the end of the day, the risk tolerance and security policy of each organization will impact how it can best implement the PBConnex feature and the caching of key files.

Benefits of the PBN Authentication Approach for Endpoint Security

Using the PBN authentication approach for endpoint security provides substantial benefits, including the following:

• Increased security. Because authentication occurs before the operating system boots, operating system-level threats and vulnerabilities are irrelevant to the security of that authentication, and the endpoint encryption key is not accessible by the operating system. This prevents malware, keystroke loggers, and other malicious tools from stealing credentials and allowing attackers to reuse those credentials to gain unauthorized access to devices. This level of endpoint security is often required for compliance with security laws, regulations, frameworks, and other sets of requirements.
• Easier to use. An authorized user who needs to use a new laptop or other endpoint device can simply authenticate to that device as they would to any other device and get access to it. The authentication process will cause the necessary key management operations to occur so that storage is decrypted and the operating system can boot. Users do not have to wait for extended periods for credentials to be issued specific to that device, nor do users have to remember yet another password if existing enterprise authentication services, such as Active Directory, are leveraged.
• Lower costs. Provisioning devices for users in most environments is costly, especially in environments where users share devices because such devices often need re-provisioned. Using the PBN authentication approach for endpoint security significantly reduces costs because it minimizes the labor involved in endpoint provisioning and re-provisioning. Also, if enterprise authentication services are leveraged, handling user password rotation, resets, and other administrative duties is made considerably simpler and faster.

Conclusion

Using PBN authentication significantly improves key file deployment practices for endpoint encryption (e.g., FDE). By handling user authentication before the endpoint device boots, the user credentials are protected from operating system-level threats, and a wide variety of authentication options are made available, ranging from passwords and smart cards to integration with existing enterprise Active Directory services. Benefits of using the PBN authentication approach include increased security, improved ease of use, and lowered costs.

All the benefits of PBN authentication for endpoint encryption can be achieved through one solution: WinMagic’s SecureDoc Enterprise Server (SES). SecureDoc’s PBConnex component provides PBN authentication capabilities for deploying and provisioning software-based FDE and self-encrypting drive (SED) features, as well as enabling the use and management of other endpoint storage encryption solutions, including Microsoft BitLocker and WinMagic’s own storage encryption solutions. PBConnex is able to manage storage encryption keys for all of these products because it implements key management at the lowest layer possible, as explained in our third blog posting in this series. In addition, PBConnex can perform cryptographic wipes of previously provisioned devices and can enable Active Directory password resets to facilitate local device authentication. These features make SecureDoc and PBConnex even more helpful to an organization for achieving its security, usability, and cost goals.

Karen Scarfone is the co-author of this blog. She is a former senior computer scientist for the National Institute of Standards and Technology (NIST), and has over 15 years of experience across a wide variety of security domains.