Recent Changes - Search:


What Is Passive Key

What is PassiveKey

Tags: features

Problem Definition

You have an installation of PortalGuard and your are interested in learning what the benefits of using the included PassiveKey™ tool are.


The PassiveKey component of the PortalGuard Desktop serves to validate both the user -AND- the device they're using. PassiveKey is implemented as a browser toolbar installed on workstations that automatically generates a Time-based One-time Password (TOTP) on a regular interval and sets the value as a session-based cookie. This cookie is created for only specific websites and is encrypted using public-key cryptography to ensure only the PortalGuard server can decrypt it.

Once installed, the user is automatically enrolled when they login to their workstation. Enrollment data on the workstation consists of the following:

• A private/public key pair – These are generated and stored on the workstation. They are used to identify this specific user and workstation and create a PKI certificate request which is sent to the PortalGuard server. The password for this container is randomly generated and encrypted using Microsoft’s Data Protection API. This ties the user’s data to their Windows user profile.

• Certificate Authority public certificate – The public key of the PortalGuard server certificate authority is used to encrypt the cookies created by PassiveKey. Only the PortalGuard server has the private key that can decrypt the cookie.

• TOTP seed value – This is used by PassiveKey to generate a temporary time-based OTP. This seed is created by the PortalGuard server during the enrollment process and exists on both the workstation and the PortalGuard server. It is encrypted on the workstation using the user’s public key.

Enrollment data on the PortalGuard server consists of the following:

• A private/public key pair – These are generated and stored on the server in a one-time setup step. They are used to identify the PortalGuard server. They are protected with a randomly generated passphrase that is encrypted and stored in the PortalGuard bootstrap configuration.

• Self-certified Certificate Authority– The foundation of the PKI created automatically by the PortalGuard server.

• TOTP seed value – This is used by the server to validate TOTPs sent by users. This seed is created by the PortalGuard server during the enrollment process. It is encrypted on the server using the server’s public key and is stored as part of the user’s PortalGuard profile.

The enrollment workflow occurs entirely over HTTP/HTTPS and is as follows:

1. TTTEnrollment.exe on workstation automatically runs when user logs into Windows. It checks the state of the local enrollment data. It exits immediately if all parts are present and valid. If the signed public certificate is missing, then the process continues

2. The PortalGuard enrollment website is contacted in the background via HTTP/HTTPS.

3. If Active Directory is being used as the PortalGuard user repository, then the PortalGuard enrollment website would be configured for Integrated Windows authentication so the user is automatically logged in using Kerberos or NTLM. If Active Directory is not the repository, then the user will receive a prompt to manually authenticate to PortalGuard.

4. On the workstation, a public/private keypair is generated and an associated Certificate Signing Request (CSR) is created and sent to the PortalGuard enrollment website.

5. If the user’s policy allows PassiveKey enrollment, then a signed public certificate is created and stored in the user’s PortalGuard profile on the server.

6. The signed public certificate and the Certificate Authority’s public certificate are sent back to the workstation and saved.

7. The workstation then submits a TOTP enrollment request to the server.

8. If the user’s policy allows PassiveKey enrollment, then a random TOTP seed is generated, encrypted with the user’s public key and sent back. The TOTP seed is encrypted using the server’s public key and saved in the user’s PortalGuard profile on the server.

9. The workstation decrypts the TOTP seed with the user’ private key to ensure validity. It then saves all data in a container, AES-256 encrypts it with a randomly generated 64-character passphrase, then protects that passphrase with Microsoft DPAPI.

During normal browser usage, the toolbar automatically recreates the TOTP and cookie containing it on a set interval. The PortalGuard server will automatically validate the TOTP when it requires a second factor of authentication, saving the user from having to receive and manually prove possession of a device (mobile phone or hardware token).

PassiveKey for VPN/RADIUS

Starting with version 1.8 of the PortalGuard Desktop, PassiveKey TOTPs can now also be used for VPN/RADIUS access. A new “TOTP Helper” executable is installed that computes the TOTP for the current user, enters it into the currently high-lighted field and simulates a press of the ‘Enter’ key. The user triggers the TOTP Helper via Windows hotkey. The default hotkey for the TOTP Helper is Ctrl-Shift-O, with the “O” standing for “OTP”.

Here is a typical sequence demonstrating how this feature is used:

1) User launches their VPN client (e.g. IPSEC-based) or browser to the SSL VPN web page

2) User enters their standard username and password and submits it

3) The PortalGuard server validates these credentials and sends back a RADIUS response to the VPN appliance that causes the user to be prompted for an OTP

4) The user ensures the OTP/challenge input field has focus (e.g. contains a blinking cursor), the presses Ctrl-Shift-O

5) The TOTP Helper runs in the background, generating the TOTP, entering it into the VPN input field and automatically pressing the Enter key for the user.

6) The TOTP is validated by the PortalGuard server and the user’s VPN is successfully established.

This approach allows the PassiveKey TOTP to be used for VPN access without requiring any changes or custom work to occur on the VPN appliance.

Page last modified on February 01, 2016, at 10:26 AM