safend

Securing Your Endpoints

Safend Encryptor User Authentication

Overview:
Safend Encryptor utilizes Total Data Encryption technology that encrypts all data files, while avoiding unnecessary encryption of the operating system and program files. This innovative concept minimizes the risk of operating system failure, and poses negligible performance impact on user productivity. Leveraging this unique encryption technology, Safend Encryptor provides a genuinely transparent Hard Disk Encryption solution, by using the existing Windows login interface for user authentication.

Encrypt your Data, but dont change the way you work
Utilizing Safends proprietary and unique encryption technology, Safend Encryptor provides True SSO. Unlike most Encryption products that mandate the use of a proprietary user authentication infrastructure, Safend Encryptor uses the existing Windows Login interface for user authentication. With this unique technology, Safend Encryptor provides a secure and transparent Hard Disk Encryption solution. Transparent to the End User: Safend Encryptor transparently uses Windows Login to access the encrypted data, and users continue to use the same interface to login to the machine. Deploying Safend Encryptor does not require any end-user training. In fact, end-users do not have to know their machines are encrypted at all. Transparent to Help Desk/Support: The most common help desk task is resetting forgotten passwords. Most encryption products mandate the use of a custom procedure, which requires a long, and error prone, challenge/response procedure. With Safend Encryptor, the password reset process used is the generic AD domain password reset. Your help desk can continue to use your existing procedures for resetting passwords (i.e.: using your Directory Service Provider or any other Identity Management System). Transparent to user authentication method: The Encryptor transparently supports any multifactor authentication device supported by Windows (Smart Card, USB token, biometric, etc.), including multi-factor devices that change the Windows GINA or use a custom one. Transparent to Patch Management and Software Distribution systems: Most encryption products require major changes to the patch management process, which considerably weakens data security. Safend Encryptor allows you to maintain your current patch management infrastructure and perform remote software installations and upgrades without any prior preparation, and without affecting data security.

Safend Encryptor user authentication flow

The following section explains in detail the Encryptor user authentication flow. The authentication flow described below refers to user authentication using user and password. Two factor user authentication will be explained in section 2. In general there are two different scenarios of user authentication flow: a) Initial user authentication flow: This flow is performed the first time a new user logs into an encrypted endpoint and must occur when the endpoint is connected to the corporate network (Safend server and directory services are accessible). In this flow the new encryption secrets are generated by the server and transferred to the endpoint. The users credentials are used to generate the users secrets store. This flow will occur once for each new user logging into an encrypted endpoint. b) Cached user authentication flow: After the initial authentication flow, any subsequent authentication requests will be performed locally (following user login), using the users secret store.

User authentication process Safend Encryptor user authentication is performed as a part of Windows Interactive logon (as opposed to network logon). Windows Interactive logon occurs through the interaction of several different processes and components: 1. 2. 3. 4. The logon process (Winlogon) LSASS process. One or more Authentication Packages. SAM or Active Directory.

Winlogon is the component of Microsoft Windows operating systems that is responsible for handling the secure attention sequence, loading the user profile on logon, and optionally locking the computer when a screensaver is running. Local Security Authority Subsystem Service (LSASS) is a process in Windows operating systems that is responsible for enforcing the security: It verifies the users logging onto a Windows computer or server, handles password changes, and creates access tokens. Authentication Packages are DLLs that perform authentication checks. The Security Accounts Manager (SAM) is a database stored as a registry file and contains the users' passwords in a hashed format.

Single factor authentication user authentication diagrams: Diagram 1 High level user authentication flow:
End user logs in to windows

End user logged in

Non authenticated end user logged in

Authenticated user access

Check-in successful?

Non authenticated user access

** Explained in diagram 2

User can access encrypted data

User goes through challenge/response process

One-time access screen

User cannot access encrypted data

process completed successfully ? Yes No

Diagram 2 detailed user check-in process:

End user logs in to windows

LSASS
Kreberos Authentication Package MSV1.0 Authentication Package

Windows XP

Windows Vista / 7

Gina

Credential Provider Active Directory Winlogon

Security account manager Domain Password Cache

Windows Login Sequence Safend check-in Sequence

Decrypt machine key
Security Token Genrator

Authenticated user access

Key Decrypted successfully?

Unauthenticated user access

1. Single factor user authentication: Logon begins when an end-user presses the SAS (Secure Attention Sequence) keyboard sequence (CTRL+ALT+DELETE). After the SAS is pressed, the process Winlogon calls the GINA component to obtain a username and password (in the case of Windows Vista/7 Gina is replaced by the credential provider.). After the username and password have been entered, Winlogon passes logon information to the authentication package. Windows uses two standard authentication packages for interactive logons: Kerberos and MSV1_0. LSASS uses MSV1_0 on domain-member computers to authenticate to preWindows 2000 domains and for local account authentication or in cases where the computer cannot locate a domain controller for authentication. The Kerberos authentication package is used on domain member computers. The appropriate authentication package is used to authenticate the end user, based on the network connection state of the endpoint. The MSV1_0 authentication package takes the username and a hashed version of the password and sends a request to the local SAM to retrieve the account information, which includes the password, the groups to which the user belongs, and any account restrictions. MSV1_0 first checks the account restrictions, such as hours or type of accesses allowed. If the user cannot log on because of the restrictions in the SAM database, the logon call fails and MSV1_0 returns a failure status to the LSA. MSV1_0 then compares the hashed password and username to that stored by the SAM. In the case of a cached domain logon, MSV1_0 accesses the cached information by using

LSASS functions that store and retrieve "secrets" from the LSA database. If the information matches, MSV1_0 creates the logon session by calling LSASS. The basic control flow for Kerberos authentication is the same as the flow for MSV1_0. However, the authentication package must communicate across the network as part of the authentication process. The package does so by communicating, via the Kerberos TCP/IP port, with the Kerberos service on a domain controller: the Kerberos Key Distribution Center service. After validating hashed username and password information with Active Directory's user account objects, the result of the authentication and the user's domain logon credentials are transferred across the network to the system where the logon is taking place. Once a package authenticates a user, Winlogon continues the logon process for that user. If none of the authentication packages indicate a successful logon, the logon process is aborted. Once a successful user login is completed successfully, the authentication package which completed the user authentication broadcasts a message to all authentication packages, indicating successful login with the user login credentials. This information is captured by Safend and the login credentials are used to compute the users security token. Next a decision is made based on the type of authentication flow: a) In case this is the Initial user authentication flow (it is the first time this specific user logged into this encrypted endpoint): the endpoint requests encryption keys from the server. Once the keys are received, the encryption keys are encrypted by the users security token and stored locally. b) Cached user authentication flow (the user already completed the initial user authentication flow): The computed security token is used to decrypt the endpoints machine key. After this process is completed successfully the end user is now checked-in to his encrypted endpoint and the users desktop is displaye d. In case the security token was not able to decrypt the endpoints machine key, the users desktop will be loaded with an authentication error message user failed to check -in to an encrypted endpoint.

2. Two factor user authentication: Safend supports two factor authentication out of the box in a completely transparent manner, one that requires no changes to the existing authentication infrastructure. The product relies on a working Windows two factor authentication environment which can either be a PKI (Public Key Infrastructure) or non-PKI enabled. Safends unique True SSO technology, allows the product to transparently support a custom GINA user login interface (ones provided by the two factor authentication vendors).

Safend Encryptor two factor user authentication flow In a non-PKI two factor authentication, the user authentication is identical to the one explained above, except that the user credentials (user and password) are protected with an additional authentication device (USB token, biometric device, smart card, etc.). PKI two factor user authentication, is conducted in a similar manner to the single factor user authentication, with one major difference: instead of intercepting the user credentials, the users certificate is used to generate the hard disk encryption security token. In addition the users certificate is verified by the root authoritys public key, CRL and certificate expiration date, to make sure it is a valid user certificate before the end user is allowed to checkin to an encrypted endpoint.

The difference between user login and user check-in User login refers to the sequence of events in which the end user is authenticated with a Windows password protected computer. After the user successfully enters his credential his desktop is loaded and he has access to all his programs and files. User check-in refers to the sequence of events in which the end user credentials (used in the login process) are used to generate a token which grants one access to the encrypted data. This process occurs transparently as a part of the login process when the endpoint is encrypted by the Safend Encryptor. In most cases the user check-in process is completed after a successful user login. There are some rare cases in which the user is logged in successfully to an encrypted endpoint but the check-in process fails: 1. Corrupt local user secrets store. 2. New user logs in for the first time to a blocked encrypted endpoint. 3. A tampered SAM database or Windows password cache is identified. In any case, a valid user is unable to check-in: a dialog box is displayed to the end user which allows him to access the encrypted data using a simple challenge response process.

Machine blocking mechanism When designing the key management infrastructure, Safend took special measures to ensure that the product security is maintained during the key exchange procedure. To achieve this, the server generates the hard disk encryption secrets for a machine and transfers the key securely to the endpoint only once. Any subsequent attempt to request the machine secrets triggers a process on the Management Server that will block the machine. A blocked machine will have a sign in the Management Console and would ignore any requests for user/machine secrets transfer. The machine blocking mechanism was developed to prevent an attack from inside the organizational network in which an encrypted endpoints encryption secrets are compromised. A machine can also become blocked in a valid usage scenario, when an endpoint is formatted or destroyed and a new endpoint is installed with the same name and encrypted. The machine can be easily unblocked by an authorized Safend administrator, using the reset client status command in the Management Consoles Clients world.

Password change procedure Password changes are intercepted through the same mechanism which intercepts the user s credentials. After a password is changed (either by the Administrator or by the user himself) a new security token is generated. This new token will be used from now on to authenticate the user and allow access to encrypted data.