Check Point Full Disk Encryption gives you the highest level of Data Security. It combines boot protection, Preboot authentication, and strong encryption to ensure that only authorized users can access data stored in desktop and laptop computers.
Overview of Computer Data Security
With computer security becoming increasingly important, almost all focus has been on securing large, multi-user machines. This makes sense because mainframes and large servers are not only major repositories of data, they are also crucial to daily operations. However, there is an equally serious and growing risk of compromise to the many smaller, mostly single-user, machines, such as desktop, laptop, tablet PCs, as well as Mobile Hand-held devices, such as Smart Phones, Smart Pads (iOS/Android etc) etc. These computers frequently store an enterprise's most current and valuable information. Increasingly, portable computers also store passwords, logon scripts, and certificates used to access the enterprise network. The small size and portability of these computers mean that they are also much more vulnerable than large machines are to theft or illicit access.
An additional and often unrecognized problem is that a PC is the most available and vulnerable starting point for access to a network. Studies of computer crime reveal that insiders pose the largest threat. Clearly, providing secure PCs is an essential component of establishing network security.
Data Security Types
There are two general types of protection for data at rest: file encryption and full disk encryption. This illustrates the difference between unprotected data, standard file encryption, and Full Disk Encryption protection.
File encryption enables users to protect vital data on a file-by-file basis, which is a good solution when, for example, transferring files between users or computers. However, organizations often find file encryption insufficient since they then have to rely on the users' ability to secure the correct information and their willingness to consistently follow security procedures.
Full Disk Encryption
Unlike file encryption, which is not mandatory and therefore dependent on user discretion, Full Disk Encryption provides boot protection and sector-by-sector disk encryption.
Boot protection means authenticating users before a computer is booted.
Full Disk Encryption uses the user's credentials to derive a user key, which is used to encrypt the disk volume keys. The disk volume keys encrypt the PC disk volumes.
This prevents unauthorized persons from accessing the operating system using authentication bypass tools at the operating system level, or alternative boot media to bypass boot protection.
Disk encryption includes the system files, temp files, and even deleted files. Encryption is user-transparent and automatic, so there is no need for user intervention or user training. There is no user downtime because encryption occurs in the background without noticeable performance loss. This provides enforceable security that users cannot bypass. Because the data on the disk is encrypted, it is inaccessible to any unauthorized persons.
Full Disk Encryption Features and Benefits
Full Disk Encryption secures desktop and laptop computers from unauthorized physical access by using both boot protection and full disk encryption. Full Disk Encryption provides the following security functions:
Strong Multi-User Authentication
Support for Multi-type Authentication Methods using Smart Card, Password etc.
Secure Remote Help for users who have forgotten their passwords
Central management, deployment, configuration, monitoring and reporting.
Single Sign-On, Password Synchronization within the OneCheck concept.
Advanced Security features for Preboot Bypass using Network Authorization, TPM and Enhanced Network Location Awareness.
Audit logging of events such as successful and failed logon attempts
With Full Disk Encryption, all logical partitions/volumes are boot protected and encrypted, even if the disk is removed and loaded into a controlled machine.
The integration of boot protection and automatic encryption provides a high degree of security with minimal impact on users. This allows an organization to determine the security level instead of leaving it up to the user to encrypt information.
Boot protection prevents subversion of the operating system or the introduction of rogue programs, while sector-by-sector encryption makes it impossible to copy individual files for brute force attacks.
Full Disk Encryption guarantees that unauthorized users cannot access or manipulate information on a protected computer, from available, erased, or temporary files. Full Disk Encryption safeguards the operating system and the important system files (which often contain clues to passwords), shared devices, and the network.
The Full Disk Encryption installation on the user's PC contains all the necessary user account information, keys, and other data to protect the PC. This means there is no central user database or key repository to manage.
Benefits for Administrators
As a Full Disk Encryption administrator, you have centralized control of a decentralized system where you can very easily perform:
Installation, modification and removal of Full Disk Encryption on users from computers in the network.
Configuration and deployment of a wide range of security and policy settings on users PCs.
Modification of security policy settings to suit the needs of the entire user population, selected groups of users, or individual users.
The daily administration of the system.
Deploying Full Disk Encryption to One or Many Computers
Using just one installation policy, you can deploy Full Disk Encryption to anywhere from one to hundreds of thousands of users from a central management. This can be done either in Online Mode or Offline Mode.
Operative System Support
Check Point Endpoint Data Security Full Disk Encryption is available both on Microsoft and Apple Operating Systems, using the same Preboot Environment, Recovery Console and the majority of other features. This significantly lower the cost for keeping administrators and help desk personnel trained on a separate product per OS. It simplifies the user experience both for the administrator and user.
All cryptographic functionality in FDE is implemented using the Check Point Crypto Core. Check Point Crypto Core is a 140-2 Level 1 cryptographic module for Microsoft Windows OS, Check Point Preboot Environment OS and Apple Mac OS X. The module provides cryptographic services accessible in preboot mode, kernel mode and user mode on the respective platforms through implementation of platform specific binaries.
Full Disk Encryption can be installed using the following algorithms and key lengths:
XTS-AES-128 (available from E80.64 and higher on UEFI machines.)
XTS builds on top of XEX and extends this by a tweak value and ciphertext stealing. The mode defined by IEEE uses an AES cipher. The implementation of AES supports 128 bit key lengths.
XTS-AES-256 (available from E80.64 and higher on UEFI machines.)
XTS builds on top of XEX and extends this by a tweak value and ciphertext stealing. The mode defined by IEEE uses an AES cipher. The implementation of AES supports 256 bit key lengths.
The implementation of AES supports 256 bit key lengths. It is implemented in CBC mode with a block size of 128 bits. On CPUs supporting the Intel AES-NI instructions, the AES-NI instructions are used automatically in order to speed up the execution. Note that the FIPS validation covers both modes: software or AES-NI (hybrid).
The implementation of Blowfish supports 256 bit key lengths. It uses full 16 rounds. It is implemented in CBC mode with a block size of 64 bits.
The implementation of 3DES uses 168 bits of key length. It is implemented in CBC mode with a block size of 64 bits.
The implementation of CAST supports 128 bit keys. It is implemented in CBC mode with a block size of 64 bits.
Implementation of Software-Based Encryption
The software disk encryption uses one disk sector as the smallest block (512 bytes).
When using Blowfish, the relative sector number within the logical volume is first encrypted, and the result is used as the initialization Vector (IV) for the sector encryption.
For all other algorithms, the relative sector number is used as the IV. Each sector is encrypted in 64-bit CBC or, for AES, 128-bit CBC mode, equal to the block size of the algorithm.
Mac OS X Note
The Mac version of FDE only supports AES, implemented as described above.
Implementation of Support for Self-Encrypting Drives (SED/OPAL)
Self-Encrypting Drives (SED/Opal) disks are only supported and implemented in the Windows version of Full Disk Encryption.
When Check Point Full Disk Encryption is used together with Self Encrypting Drives (SED), all of the key management, remote-help, authentication modes, and other features described in the following sections still apply. The only difference is that the disk will handle the disk sector encryption. The key size and mode used are specific to the disk vendor, however the OPAL standard that FDE implements mandates at least 128-bit AES to be used. Unfortunately the standard omits the encryption mode, and consequently, some vendors have chosen to use AES in ECB mode. For details on the mode used, see the specific disk vendor documentation. In order to lock or unlock the SED, the device key, described in the user authentication section, is used. The device key is encrypted, as described in the following sections, using encryption based on the authentication model deployed.
Two modes exist for the SED (Opal) disks, depending on if Windows has taken ownership of the disk or not.
Setting up disks from manufactured-inactive state (8). This model enables locking on the global range and sets new, unlocked, ranges for the EFI system partition, the FDE system area partition, and the GPT tables. Unlocking at preboot, for example, unlocks the global range.
Setting up disks that have been activated by Windows 8 and later. These disks are in manufactured state and probed with ioctls from the Windows ehstor "band management" API to find out the status of the disk. Enabling locking is done via these ioctls. The AUTH_KEY for the bands is set to the FDE device master key for all ranges, including the unlocked ranges. Locking is then enabled on all ranges except the EFI system partition and the FDE system area partition.
Each encrypted partition has a single partition encryption key. The algorithm chosen for the partition encryption mandates the key type and length for the partition encryption functionality. Each partition key is encrypted with a device encryption key. The device encryption key is unique per device (PC). The device encryption key is always a 256 bit AES key, implying that the internal key encryption is 256-bit AES.
The encrypted partition keys are stored on device level. The device encryption key will be encrypted using the authentication method chosen for the individual user. For example, if password authentication is used, the device encryption key will be encrypted and stored in the user database, per user, using a password derived key. For Smart Cards, the partition key encryption key will be encrypted using RSA public key cryptography.
Password strength depends on the length, and the type of character set involved. Full Disk Encryption will calculate based on a password with a random use of all characters; i.e. Upper Case, Lower Case, Numeric, and Special Characters (94 characters total).
Remote Help Security Architecture
When performing remote help, the user gives a challenge to the helper. The helper then gives the user a response that unlocks the device. The login is performed using the helpers login info.
Schematically the remote help algorithm is: Challenge + Shared Secret = Response, the response is used as a password to encrypt the device key and the shared secret in the same way as password based encryption described above. The encrypted key blobs are stored in the local device database. The challenge is a random number generated by the DRBG. The "+" is a hash algorithm and Shared Secret is a device unique 256-bit AES key created with the DRBG. Hashing is done using the key-encryption algorithm run in "one-way mode" by using the input data as key.
The shared secret is encrypted with a 2048-bit RSA key received from the Management Server and transmitted to the server in the recovery data. RSA encryption is done. RSA encryption uses PKCS#1 v1.5 padding in E80.61 and earlier and OAEP padding starting with E80.62. The transmission to the server is done using TLS.
Deployment Mode is required before encryption can start because an installed Full Disk Encryption client first needs to:
Retrieve device policy information provided from the Endpoint Management Server
Gather and deliver requested information back to the Endpoint Management
Verify that the policy configuration is valid/complete for encryption to be initiated
If enabled, the user acquisition will continue to acquire new users until the configured condition has been fulfilled:
Number of accounts
This setting specifies the number of accounts to acquired, if this number of acquired users is reached, then the user acquisition is considered complete.
Limitation of acquisition period
When enabled, this setting specifies that the acquisition should be considered complete after a certain number of days even though the number of acquired users hasn't been reached. Note: At least one user still has to be acquired
Deployment Mode Step-by-Step Overview:
First stage - Deployment
Generation of device/master key. Status shown and reported: Init
Wait for policy to be delivered. Status shown and reported: Wait for policy
Wait for User Acquisition to finish. Status shown and reported: User Acquisition
Verify that a user has the permission to log on. Status shown and reported: Verify Setup
Activate the functionality for Preboot Bypass or Temporary Preboot Bypass, if enabled. Status shown and reported: Verify Setup
Activate the functionality for Remote Help. Status shown and reported: Verify Setup
Creating Preboot OS System Area. Status shown and reported: Setup Protection
Wait for the recovery data to be delivered. Status shown and reported: Delivering Recovery Information
Activate Preboot (update boot record on boot volume). Status shown and reported: Setup Protection
Second stage Post-deployment
Remove old restore points. Status shown and reported: Setup Protection
Update boot records on all volumes. Status shown and reported: Setup Protection
Remove intermediate files. Status shown and reported : Setup Protection
Notify that reboot is required. Status shown and reported: Awaiting Reboot
Third and final stage Enforcement
Activate background encryption. Status shown and reported: Encrypting/Encrypted/Decrypted
Preboot description, major difference depending on firmware type (BIOS/UEFI) etc.
Password - Username and password. This is the default method. The password can be the same as the Windows password or created by the user or administrator.
Smart Card - A physical card that you associate with a certificate. This is supported in E80.30 clients and higher. Users must have a physical card, an associated certificate, and Smart Card drivers installed.
Dynamic Token - A physical device that generates a new password each time users start their computers. This is supported in E80.60 clients and higher on E80.60 and higher management. This can be configured for specified users and not as the global Pre-boot authentication method.
Network Authorized Preboot Bypass
Network Authorized Preboot Bypass (formerly called UOL / Unlock On LAN) uses preboot network capabilities to access RSA private keys stored on the Endpoint Management Server in order to achieve a secure boot sequence into the OS with no user interaction.
The Management Server generates a 2048-bit RSA key pair and the internal Check Point CA on the Management Server certifies the public key. An X.509 certificate is generated.
Security Overview Step-by-Step:
As part of the client device policy, the X.509 certificate is provisioned to the clients when Unlock on LAN is enabled. This is sent under the TLS session that all FDE messages use for server communication (See Server Connection section).
The public key, embedded in the certificate, is used to encrypt the disk keys. This is done with a 256-bit random AES-CBC key encryption key (KEK) that encrypts the disk unlock key (also called the device master key). The KEK is, in turn, encrypted with the public RSA key. E80 61 and earlier uses PKCS#1 1.5 padding. From E80.62, OAEP padding is used. The encryption creates an encrypted key blob which is stored in the FDE system area on the client machine.
When in pre-boot, the pre-boot detects the Unlock on LAN policy and tries to connect to the Endpoint Server, or one of its Policy Servers (connection points). This is done in the same way as the DA, using TLS (SSL), with AES-256, to encrypt the traffic and a server certificate issued by the internal CA to strongly authenticate the server.
The encrypted key-blob created in step 3 is sent, on the TLS/SSL encrypted connection, to the server. The server decrypts the device key using the corresponding RSA private key, only stored on the Management Server.
The decrypted disk unlock key is sent back to the client, still within the same TLS/SSL connection.
The client uses the disk unlock key to decrypt the local disk volume keys.
Legacy Preboot Bypass
The legacy preboot bypass (formerly known as WIL / Windows Integrated Logon) is only recommended, due to the feature's lowering of the overall security below what is considered encryption strength, to be used for computers that are in a physically secure environment, protected by concrete walls, alarms, lock systems and other security measures to ensure that the computer will not leave the compound. To additionally protect the computer from theft, there are several security features specifically designed to disable the legacy preboot bypass in the event that the physical security is in some way compromised either by theft, abuse or similar.
Security Triggers Available to Disable Preboot Bypass
If a physically secured computer with preboot bypass enabled (for example an ATM), still should fall into the wrong hands, the following features are available to detect being vulnerable and self-trigger the disabling of the preboot bypass and enabling the preboot environment access control and authentication requirement:
Legacy Network Location Awareness
To make sure that the client is connected to the correct network, the computer pings a defined number of IP addresses during the boot process. If none of the IP addresses replies in a timely manner, the computer might have been removed from the trusted network and Preboot Bypass is disabled. The computer reboots automatically and the user must authenticate in Preboot. If one IP address replies, Preboot Bypass remains enabled. Note: While this option is enabled, Windows cannot be started in Safe Mode.
If selected, the client generates a hardware hash from identification data found in the BIOS and on the CPU. If the hard drive is stolen and put in a different computer, the hash will be incorrect and Preboot Bypass will be disabled. The computer reboots automatically, and the user must authenticate in Preboot. Warning: Disable Preboot Bypass before upgrading BIOS firmware or replacing hardware. After the upgrade, the hardware hash is automatically updated to match the new
Max failed logon attempts
If the number of failed logon attempts exceeds the number of tries specified, Preboot Bypass is disabled. The computer automatically reboots and the user must authenticate in Preboot. If the Maximum Failed Logon value is set to "1" and the end-user logs on incorrectly, Preboot Bypass is not disabled because the number of logon failures has not exceeded the number entered in this property. However, if the subsequent attempt to log onto Windows fails, Preboot Bypass is disabled.
Introduction to Remote Help functionality
Remote Help is a feature for administrators and help desk personnel to remotely help users to access computers protected with Full Disk Encryption, if the users password has been forgotten.
The basic functionality is intended to:
Help users that have forgotten their password to change their password
Allow users to access a machine where Windows Integrated Logon has been turned off due to some event
Help a user whose account has been locked to access and unlock the account
Temporarily grant access to a computer (until reboot) to enable service operations on the computer
User Interface User Experience
There are several settings and procedures that need to be properly handled when doing Remote Help in the Preboot Environment. Previously described modes of Remote Help will in this section be shown from the User/Administrator perspective.
Preboot User Experience:
Click the lower right Remote Help button for below dialog to display.
Once the user has called, or in another way contacted the administrator or help desk, the selected mode of Remote Help is selected, either Password Change or One-Time Logon.
Remote Help configuration in Endpoint Management:
Overview of Remote Help Infrastructure
The Remote Help infrastructure is divided into "Legacy" and "E80", with the major difference in E80 being the PKI security enhancement of each device having a unique key, while in the legacy versions having a much simpler design with remote helper accounts created at deployment, but being the same on all systems installed with the same installation profile.
There is still in E80 the possibility to use the legacy way of doing remote help, this setting is then called "User-bound Remote Help" and can be configured on the "Internal Account" user type.
Setting up the secure E80.xx Remote Help PKI:
When the UEPM server is installed, an asymmetric key pair is created and stored in the server database table named ASYM_KEY.
When each FDE device policy is generated in XML, the public key is inserted into the device policy.
The FDE device policy XML is stored in the server database.
The FDE device policy XML is transferred to the client.
A remote helper account is created on the endpoint with uniqe information for that device. The unique information is only generated once, at the first time the client receives the public key.
New recovery information is generated on the client containing the device's unique information
The recovery information is transferred to the server in a message named SET_FDE_RECOVERY_DATA.
When received on the server, the recovery data is retrieved from the message.
The recovery data is then stored in the server database in a table named RECOVERY_DATA.
Change Password in Preboot
If allowed, the user can at any time decide to change the preboot password from the preboot environment.
The user enters the user name and password and instead of pressing enter or clicking on "OK", the user instead clicks on "Change Password" and the below dialog will be shown:
Preboot Options Menu
In the lower right corner of the Preboot Environment, the Options menu panel can be shown if selected
The following features are available from the options menu:
Enable HII Keyboard Layout
The help dialog can either be used with the standard text shown below, or be changed to a specific text message chosen by the Endpoint administrator.
When using a tablet computer or a regular laptop with touch screen, the user can select to use the touch screen to logon using the Virtual Keyboard instead of the build-in or external keyboard. When using a tablet computer there is often no availability of either build-in or external keyboard so using the Virtual Keyboard becomes the standard procedure.
When selected the virtual keyboard and doing a preboot logon, the virtual keyboard will stay active and be automatically shown the next time the user starts the computer.
At installation the language of the preboot environment is set based on the language used within Windows, if that language is supported. Still there is a need to be able to change the language if a non-native user of the language selected at installation would need to logon.
The languages shown in the above displayed preboot dialog are currently available to be selected.
To find complex characters on a regular keyboard can sometimes be hard.
The following standard characters maps are available:
Enable HII Keyboard Layout
By default, the keyboard layout used in preboot is the defined layout provided by Full Disk Encryption for the selected language. Even if found extremely rare, there is a potential chance of a hardware model that is not compatible with the built-in provided layouts. If this event should happen, the option is available to select Enable HII Keyboard Layout and instead use the keyboard layout provided in the UEFI firmware to hopefully resolve any experienced issue.
Recovery Methods for Disaster Recovery Decryption / Data Access
The most important process/information for an encrypted system is the security and accessibility of the recovery information/data.
Disaster Recovery Console / Bootable Recovery Media
The standard method of creating recovery data is by
The recovery progress will be monitored in % finished, decryption speed in Megabyte per second, as well as showing the estimated remaining duration until the recovery decryption will finish.
Drive Slaving Utility / Dynamic Mount Utility
The fastest method to access data on the encrypted disk if the system cannot boot normally, is to use the Drive Slaving Utility.
The Drive Slaving Utility can be used in two different modes:
Secure Enterprise Setup using Preboot Authentication
The preboot environment authentication has a fundamental importance in Full Disk Encryption to provide solid and secure access control. This in providing an external (not physically attached as for example the TPM-chip) secret (Password, Smart Card PKI etc) that ensures the cryptologic strength, as well as making sure that the data on the disk does not at any time, before access control via successful authentication is made, become readable and thereby provide exposure to potential memory attacks (Cold Boot exploits) or other OS-level attacks.
The authentication method to use for preboot users needs to be set, based on security level needs. If the data at rest on a specific computer needs to be protected with maximum security, the authentication method with the highest level of provided security should be selected (in the defined example, a Smart Card with 4096-bit encryption.) For users that rarely handle any data that would require maximum-security precautions, a regular password with a good mix of upper and lower characters, numbers, and if needed special characters should be used.
The next step is to define how many accounts need to be available for logon on each computer. Many times you may set the same number for all systems, however the more accounts present on a system the larger the risk is that a specific account would be assigned to the system with a low security password (if the defined password policy has allowed such to be set) and an attacker will in most cases attack the weakest link.
In general, the default settings and value available for configuration in the Endpoint Management should be regarded as the best-practice recommendation.
Secure Enterprise Setup using Network Authorized Preboot Bypass
Before reading this section, it is important that you understand the previous section on why and when it is important to use preboot authentication, especially for mobile computers and devices that are not safeguarded by physical office security, such as walls, doors, locks and alarms.
A good example of an environment when Network Authorized Preboot Bypass (previously known as Unlock On LAN) could be the optimal choice is a helpdesk or call center type environment with desktop systems that are not allowed and never regularly leave the safeguarded office. By having the Network Authorized Preboot Bypass enabled, no personal user information is needed for each machine, and any employee could select any workspace/computer within the office to use during the day.
At system startup, the networking functionality within the preboot environment will contact the management server via secure communication and unlock encryption keys needed to be able to authenticate the system and start to boot into the regular OS. If any system would be stolen, it would become powerless and disconnected from the network LAN and at next boot on the "outside", the LAN would no longer be present, so the preboot authentication would be shown as a Network Authorization attempt that would fail due to no network available.
Lowered Security Enterprise Setup using Preboot Bypass
Before reading this section, it is important that you understand the first section on why and when it is important to use preboot authentication.
In general this feature is not recommended. It can be used for systems that do not have the possibility to use Network Authorized Preboot Bypass. However, in that case it is important to utilize built-in security features such as TPM, Hardware hash, Network Location Awareness etc to somewhat make the security situation a bit better.
Still, with no proper authentication (manual or via the network) before the regular OS (Windows/macOS) starts loading, the system will be vulnerable for either attacking the system memory or breaking past the login within the OS (something that is quite easily achieved and new exploits are yearly announced on events such as BlackHat etc, here is an example: https://www.youtube.com/watch?v=eRuca6eAdFM.
As described in earlier, there are two options for preboot bypass, naturally the most secure option should always be preferred. However, sometimes hardware and technology limitations may create obstacles and then require a mixed or restricted alternative.
Since ATMs especially have a zero downtime requirement, in combination with remote location challenges, an auto-boot configuration is sometimes setup in the OS to ensure that the system does not get halted at any stage during startup. This makes it especially important to strengthen the bypass-mode with as many available security features as possible, from Network Authorized Preboot Bypass and TPM/Hardware-Hash to Network Location Awareness.
The most basic step of troubleshooting the installation of Full Disk Encryption is to view the status shown in the Endpoint Security Client App.
In the above example, the deployment has reached the final step "Encrypted".
If a system would be stuck at any step, the thing to ensure is that the client has fully functioning network access, confirm that the client is connected, and that you can make a successful ping to the shown IP address.
Once it has been established that the client is connected and the system confirmed running, the next step to understand the state will be to analyze the logs. See Debug Procedures for the deployment.
When planning to upgrade, it is important to make sure that all prerequisites are met, both from supported client versions, supported management backend version, OS version etc.
sk107255 will provide you with a matrix of supported client/server versions.
The major challenge faced when upgrading the OS from one major version to another, since the hard drive is fully encrypted, is to get to a point in the upgrade process (often when loading into an alternative upgrade environment) when the FDE filter driver is not loaded, and thereby the data on the disk cannot be read/written. So our goal is to make the upgrade or upgrade image aware that the FDE filter need to be active/loaded at all times.
All the way back to XP there have been scripted procedures available to perform an OS in-place upgrade, upgrading from one OS major version to another with the encryption and product fully working and enabled thru the transition.
The most popular upgrade path right now is to Windows 10, see sk112246 for the process and steps to take for a successful OS in-place upgrade.
Since E80.61, OS in-place upgrade has also been available for systems encrypted with FDE running on macOS platform.
This was a major innovation for the product since in prior versions and the legacy series, a full uninstallation and decryption of the system had to take place before the system could be upgraded with a major OS version and then the system again had to be re-installed and encrypted again. See sk114213 for the latest process.
The Full Disk Encryption Preboot Environment is a resilient micro OS that resides in-between the firmware (BIOS/UEFI) and Windows/macOS. In normal circumstances there will be no need to troubleshoot the preboot itself. However, if there are issues with an external keyboard or mouse functioning properly, try to remove any connected USB-switch/hub to see if it will resolve the experienced issue.
In the event of the preboot not loading properly (black screen etc), open the firmware settings and try to change the mode of operation for the hard disk controller to see it will resolve the issue.
See Preboot Options Menu if you need to change language.
For troubleshooting touchscreen devices on UEFI-hardware, see sk93032.
If the preboot environment is not loading, see Debug Procedures on gathering proper logs for R&D CFG analysis.
The challenge/response remote help functionality is one of the oldest and most matured features in the product. Normally there is not much troubleshooting needed.
However if issues are reported, make sure to go check that the features has been properly configured on the management side and that the correct mode (One-time logon or Remote Password Change) is selected both on the client side and helper side. Also, ensure that the correct device has been selected since every device is protected by a unique key. The correct device must be selected for the challenge/response procedure to be successful.
Full recovery decryption is performed by creating a recovery media, based on the unique recovery information for a specific device. It is thereby crucial that the correct device is selected when creating the media, as well as selecting (or creating) the user that will authenticate in the recovery console for the decryption process to start.
If there is an issue with booting on the recovery media, ensure that the firmware has been correctly configured to boot towards external media, as well as the media being physically in good shape (an old USB-media for example can have damaged sectors etc that could lead to the recovery image not being able to be written to the media correctly).
For hard drives that have experienced a crash due to a physical failure, it is important to not stress the drive and make the issue worse by starting a recovery decryption.
Instead start such a procedure first by taking a sector-by-sector image of the failing drive and place the image on a fully functional and healthy hard drive. Then start the decryption process on the healthy drive and decrypt the data for rescue.
If the drive is in such a bad state that even the sector-by-sector imaging will not finish, consider sending the disk drive for repair to a company that is an expert on such procedures.
On all systems installed with Endpoint Security there is a debug log collector accessible via the Endpoint Security Client App, the tool is called CPinfo, see sk90445.
CPinfo can be executed in the below three modes, from FDE there is not much difference between the modes, as shown, However in other blades the difference is more significant and this will lead to an "Extended" being significantly larger than a "Basic" log collection.
Basic: Same information as General is gathered for FDE.
General: Same information as Basic is gathered for FDE.
Extended: In addition to Basic/General, the MSinfo is gathered in this mode. This is needed during some investigations.
The following information will be displayed during the collection of logs on the FDE blade:
As shown in the example above, there is also information extracted from the Windows registry in regards to FDE. For more information, refer to sk105818.
The CPinfoPreboot is simply a tool for collecting logs directly from preboot level in case something has happened to the system that will disable it from logon to Windows.
The Bootable CPinfoPreboot tool is an application that installs the special bootable cpinfo preboot image onto a USB media.The tool automatically finds the USB devices inserted and will present found media in a drop-down menu to the right in the UI. Just select the correct device and select "write".
This USB stick can be booted both on a computers with the legacy BIOS firmware or with the new UEFI firmware.
Once the CPinfoPreboot is booted from the created media, you will see a brief copyright notice and then a few lines of instructions telling the user not to remove the USB media during the coming process. After that there will be some '*' that indicates progress (note that on some computers, especially older systems the process can be slow).
At the end of the information gathering process, the application will display that the scan is done and that a file called preboot.zip is generated and placed on the USB media. The user is then prompted to remove the media and turn off the computer.
The USB media will now contain the zip file with gathered preboot debug logs. The USB media can be inserted into a working computer. The file can be copied via Windows and placed into a mail or uploaded to an ftp, for further analysis.
The preboot.zip file has the same layout as the .cab files generated from the regular cpinfopreboot tool.
Regular CPinfopreboot (Needs to be placed on WinPE bootable media)
Use an external USB device to collect the Pre-boot data. The device must have at least 128 MB of free space, and sufficient storage for the output cab file.
CPinfoPreboot cannot run on boot media prepared with the Full Disk Encryption filter driver
How to run the tool:
Copy CPinfoPreboot.exe to an external USB device.
Boot the client from the USB device.
Note - Microsoft Windows does not automatically detect USB devices after boot up.
Open the command prompt and type: <path to CPinfoPreboot><CPinfoPreboot.exe<output cap filename><output folder name>.
For example: C:\path\>CPinfoPreboot.exe SR1234 temp.
CPinfoPreboot stores the output file to the designated folder.
If no output name is specified, the output file has the same name as the output folder.
If no output folder is specified, CPinfoPreboot saves the output file to the working directory on the external media. An output folder is required if the working director is on read-only media.
Log cycle and versions.
Common examples from dlog1.txt:
MSI log location(s)
Using Software Deployment, the MSI log(s) will be written to the following location: C:\ProgramData\CheckPoint\Endpoint Security\
The FDE debug logs (dlog) will be located in the following location on Windows systems: C:\ProgramData\CheckPoint\Endpoint Security\Full Disk Encryption\
Potential issues that can be encountered
Deployment already started
Resolution: Deployment of the system has already started, no need to try to deploy another package to the system.
Resolution: Wait until the current ongoing uninstallation and decryption process has finished.
Leftovers from prior installation due to reimage (not uninstall)
Resolution: Remove and create a new partition before starting the reimage process.
Waiting for User Acquisition
User Acquisition with no password set on the user
Resolution: Set a password for the user
Verify Setup Protection
No users assigned for preboot authentication
Resolution: Assign user(s) to the device from the Endpoint Management.
Missing Smart Card drivers for assigned Smart Card user