Remote Authentication White Paper

February | 2014
ViaSat Eclypt Remote Authentication
F
ViaSat Eclypt Remote
Authentication
TAB LE O F CO N TE NTS
01. Overview
3 02. ViaSat Eclypt Remote Authentication
6 03. Eclypt RA Security Features
8 04. Eclypt RA Configuration
9 05. Summary
10 06. Reference
10 V i aS a t K G- 2 0 0 a nd K G- 2 0 1 f o r S e cur e DA R
01.
Overview
ViaSat Eclypt encrypted hard drives and Inline Media Encryptors are accredited and
certified around the world to protect systems against data loss or theft for use by
organisations including government agencies, military forces, education,
healthcare and financial institutions to ensure premium data.
We offer a variety of internal, external, portable, SSD and ruggedised hard drive
configurations and custom or bespoke systems for air, land, and sea platforms.
An organisation may want
their employees to use
secure laptops within the
work place but prevent those
laptops from being used
elsewhere.
ViaSat’s Eclypt Remote Authentication (RA) is a feature of the Eclypt Pre-Authentication
Environment (PAE) that allows a host machine fitted with Eclypt drives to do the following
without operator interaction (other than applying power):
» Securely request authentication parameters from a network
» Authenticate a number of Eclypt drives with the received parameters.
» Reboot the host machines into their operating systems.
Increasingly there are scenarios where it is not convenient, possible or desirable for a user
to provide authentication parameters to the host machine via traditional authentication
mechanisms, i.e. entering a username and password and applying a user token. A user
may not be physically present at the encrypted device, or the sheer number of devices
may mean that authenticating an encrypted estate is time-consuming with a significant
management overhead.
However, data availability, integrity and confidentiality requirements still require that host
machines secure their data and the following scenarios are becoming more prevalent:
» The organisation does not want to provide users with authentication parameters.
For instance, an organisation may want their employees to use secure laptops
within the work place but prevent those laptops from being used elsewhere.
Figure 1a Restricting use of secure computing resources - work
3 / 10
V i aS a t K G- 2 0 0 a nd K G- 2 0 1 f o r S e cur e DA R
Figure 1b Restricting use of secure computing resources - home
» The organisation has secure computing assets deployed in diverse locations where it
is not possible for users to be present. For instance, a banking organisation may want to
secure the data on its ATM machines. Other scenarios could include Critical
Infrastructure Protection or unmanned facilities.
An organisation has secure
computing assets deployed
in diverse locations.
Figure 2 Authentication of unmanned computing resources
4 / 10
V i aS a t K G- 2 0 0 a nd K G- 2 0 1 f o r S e cur e DA R
» The organisation has large numbers of computing assets it wishes to secure where
individual authentication of each asset would be time consuming, impractical and
expensive. For instance an ISP or cloud storage provider may operate a server farm
where it wishes to secure the data on each server.
An organisation has a large
number of computing assets
it wishes to secure
Figure 3 Authentication of server farm
5 / 10
V i aS a t K G- 2 0 0 a nd K G- 2 0 1 f o r S e cur e DA R
02.
ViaSat Eclypt Remote Authentication
Figure 4 shows the main architectural building blocks for ViaSat Eclypt
Remote Authentication.
Key architectural building
blocks for RA.
Figure 4 Eclypt RA Architecture
The key components are as follows:
Host Machine: this is the computing resource (laptop, server, embedded system) to be
secured. It is fitted with an Eclypt drive to provide Data-At-Rest (DAR) security. The Eclypt
drive is configured with a RA Account (RAA) that must be authenticated before the Eclypt
can be unlocked for use. Sensitive data required to perform remote authentication is
protected by the Trusted Platform Module (TPM) prior to the Eclypt drive being unlocked.
See [Ref. 1] for a detailed description of the TPM.
Key Server: this is a COTS KMIP Key Server that stores an RAA Token for each RA
Account. One key server can serve many host machines. It is recommended that the key
server protects its keys using technology such as a Hardware Security Module (HSM) and
that it is housed in a secure environment.
IP Network: this provides the connectivity between the host machine and the key server.
The network need only consist of standard IP networking products such as switches, hubs
and routers. Thus, RA can be built on top of an organisation’s existing IP infrastructure.
6 / 10
V i aS a t K G- 2 0 0 a nd K G- 2 0 1 f o r S e cur e DA R
The basic operation is as follows:
» The PAE establishes a secure connection to the key server.
» The PAE requests the RAA Token for the RAA from the key server. The protocol for
requesting and receiving items from the key server is KMIP which is an open standard
details of which can be found in [Ref. 3].
» The PAE authenticates the RAA using the RAA Token and RAA Password.
» Providing the RAA is successfully authenticated, the PAE unlocks the Eclypt and
reboots the host machine into its operating system.
RAA Tokens can be marked as compromised such that, if, for example, a host machine is
reported as stolen, the next time the host machine attempts to retrieve the RAA Token the
value returned by the key server causes either: The PAE authenticates the RAA using the
RAA Token and RAA Password.
» The RA Account to become suspended thus preventing authentication.
» The Eclypt drive to be purged, destroying the crypto keys and preventing
authentication.
Which action occurs can be configured by the organisation.
7 / 10
V i aS a t K G- 2 0 0 a nd K G- 2 0 1 f o r S e cur e DA R
03.
Eclypt RA Security Features
In addition to the DAR protection provided by the Eclypt drive, the Eclypt RA
architecture supports the confidentiality, integrity and availability (CIA) of data
transferred between the host machine and key server.
Host machine and key server
must identify themselves to
each other before any data is
transferred
3.1 RA Confidentiality
Data confidentiality refers to preventing the disclosure of information to unauthorised
individuals or systems. Within RA, confidentiality requires that the following conditions are
met:
» Data can only be transferred between the host machine and the key server when they
have verified each other’s identity
» Data transferred between the host machine and the key server cannot be recovered
by a third party.
To achieve the necessary confidentiality KMIP demands that the connection between the
host machine and key server is established over TLS using mutual authentication. A
detailed description of TLS can be found in [Ref. 2].
The TLS connection is established using a strong cipher suite which provides the following
benefits:
» Host machine and key server must identify themselves to each other before any data
is transferred using standard X509 certificates with RSA 2048 bit keys meaning that RA
provides industry standard protection against:
»An attacker spoofing the host machine in order to steal its authentication
parameter.
»An attacker spoofing the key server in order to supply a stolen authentication
parameter.
The authentication parameter, passed between the key server and the host machine, is
encrypted using a FIPS approved AES algorithm for which the session key is agreed
using perfect forward secrecy. Each time a connection is established a new session key is
agreed. Thus, RA provides industry standard protection against:
» An attacker trying to steal the session key
» An attacker trying to steal the encrypted authentication parameter without the session
key.
» An attacker eventually calculating the session key for an old session as they will not
be able to use it for a future session.
» Loss of the private key as this will not allow past session traffic to be deciphered.
The host machine proves its own identity by signing a challenge with its RAA Private Key.
The key server then verifies this challenge by using the RAA Certificate (which contains
the host machines public key). The host machine uses the TPM to generate the RAA
Public/Private key pair which provides the following benefits:
8 / 10
V i aS a t K G- 2 0 0 a nd K G- 2 0 1 f o r S e cur e DA R
» The RAA Private Key is always held in the TPM and never exposed to system
memory which provides industry standard protection against an attacker’s ability to steal
it.
The RAA Private Key is bound to the TPM and therefore the host machine. If an entity
can prove it owns the RAA Certificate by using the RAA Private Key it can be asserted
that it must be the authentic host machine.
3.2 RA Integrity
Data integrity refers to maintaining and assuring the accuracy and consistency of data
over its entire life-cycle.
Within RA, message integrity is required to detect if and when data has been
tampered with whist it is in transit. TLS provides the necessary integrity checks.
3.3 RA Availability
Data availability is paramount to enable access to information when it is needed.
04.
Eclypt RA Configuration
The Eclypt PAE allows a Crypto Officer (CO) to perform the following:
» Configure the TPM for use by the PAE
» Configure the addresses of the primary and secondary key server.
» Generate the RAA Private Key and RAA Certificate Signing Request from which the
RAA Certificate can be obtained.
» Create the RA Account and set its authentication parameters to the RAA Token and
RAA Password.
» Write the RAA Token to the key server using KMIP.
Note that the RAA Certificate and Key Server Certificate are standard X509 certificates
that must be signed by a common Certificate Authority (CA). The CA may be a trusted
third party such as Verisign or the organisation’s own.
Once Eclypt RA is configured it will operate as described in section 2 above.
9 / 10
V i aS a t K G- 2 0 0 a nd K G- 2 0 1 f o r S e cur e DA R
05.
Summary
In summary, Eclypt RA provides the following features and benefits:
» A secure and convenient method to authenticate Eclypt drives in situations where it is
not convenient, possible or desirable for users to provide the authentication parameters,
for example, unmanned facilities, large data centres or Critical Infrastructure
architectures.
» Built upon accredited Eclypt technology to provide the highest level of DAR
protection.
» Authentication parameter securely retrieved from the network using the open
standard KMIP allowing for flexible choice of key servers.
» Network communications established using the TLS backed up by the hardware
protection of a TPM.
» Configuration and operation is done by the Eclypt PAE and is therefore OS agnostic.
06.
Reference
[Ref. 1] TPM Main Specification Level 2 Version 1.2 Rev. 116
[Ref. 2] RFC 5246 – Transport Layer Security Protocol
[Ref. 3] Key Management Interoperability Protocol Specification Version 1.0
For more information contact
+44 0 1929 55 44 00 (UK) | +1 888 842 7281 (USA)
[email protected]
Copyright © 2014 ViaSat, Inc. All rights reserved. ViaSat, the ViaSat logo are registered trademarks of ViaSat, Inc.
All other trademarks mentioned are the sole property of their respective companies. Specifications and product
availability are subject to change without notice.
10 /
10