thoughts/data/travel.md

Travelling with  electronic devices  is a  challenge, and  this is
certainly the  case if you do  not have a travel  program for your
employees, where  you must tinker  with a new  setup on a  case by
case basis. The  complexity of the matter is though,  even when it
comes to resources, as it requires full time attention.

Some  organisations choose  to  ignore the  problem all  together,
others again  does not fully  respect their own threat  model. The
latter may be just  as dangerous, as it may lead  to a false sense
of security for the travellers.

This article is  about establishing a technical  laptop setup that
can be  re-used with ease.  Thus, other operational  and strategic
aspects are left out. The  information presented evolves around
organisations, but  might as  well apply for  a private  travel of
exposed individuals.

## Main Drivers

With that  out of the way:  multiple overall factors are  left for
consideration.  The following  factors  are the  main drivers  and
equally important when  developing a technical model  of an abroad
operation.

*  Threat resiliency.  Equipment  on travel  can  really never  be
  secured well enough, but it can be hardened to the degree that a
  threat actor needs to risk exposure to compromise it
* Usability  for the traveller. Equipment  that feels inconvenient
  will be avoided by the traveller at some point
* Usability for the supporting  organisation (both security and IT
  operations). Such setups may require  much time and attention to
  develop and if  there are an increasing number  of travellers to
  high risk areas the setup needs to scale
*  Cost.  A  travel  program is  a  balance  between  environment,
  security  and  cost.  If   the  cost  and  environmental  impact
  surpasses the value that needs to be secured, the travel program
  misses some of its  value. Critical infrastructure organisations
  is a different ball game than other industries on this point.

When it comes to threats, the  most prominent one is the evil maid
infiltration vector - which  is basically someone gaining physical
access to  a computer.  Motherboard recently  published an article
on how a  malicious party could add a backdoor  to a Dell (example
used) laptop in less than 5 minutes [1].

Other examples of relevant techniques used against travellers are:
electronic eavesdropping using  cell networks, physical monitoring
of  hotel rooms  (e.g.  camera  surveillance), malicious  charging
stations  and   so  on.  More  details   on  general  infiltration
techniques can  be found  in the  Mitre ATT&CK's  "Initial Access"
category (each described on their Wiki [1,2].

## Conceptual Overview

Now that we have reviewed the main drivers, the question is if you
can protect against the given threat model in an easily achievable
way. To assess that we will first  have to a look at an conceptual
model for  travel. Taking  a top-down  approach, the  travel setup
will in most cases consist of two components:

1. The devices used for travel
2. The server side infrastructure

There  are arguments  for a  standalone operation,  but the  legal
ramification and  practical impact of  sending an employee  into a
hostile environment with anything but local encryption is risky at
best. To note: that is, if the user will actually produce or carry
anything of value. If not, a standalone setup may in some cases be
argued for.

Tactical no-brainers when travelling are the following:

1.  The system  should disclose  as little  as possible  about the
   traveller's pattern of activity and content
2. As little information as possible  should be at rest on devices
   at risk
3. It should come at a  high cost to compromise the end-point both
   for physical and technical exploitation
4. The  equipment should never  be connected to  an organisation's
   service infrastructure directly before, during or after travel
5.  The system  should not  be obviously  provocative to  locals -
   e.g. during airport inspections.

As far  as I have  found, there  are currently one  desktop system
that sufficiently  meet these  criterions -  and that  is ChromeOS
which  comes with  sane  default settings,  has  a really  minimal
configuration  and  is  usable  to an  average  person.   However,
ChromeOS is not  a mobile operating system - and  for that purpose
iOS and Android is  a better fit even though they  do not tick off
all the above boxes.

With that  in mind  the following  model, that  I have  named "The
Tactical  Travel Protection  Model",  provides  a hardened,  basic
infrastructure setup  that uses cloud  providers to hide  in plain
sight.

![The Tactical Travel Protection Model shows the concept of a full stack travel
setup](/static/img/data/tactical_travel_protection_model.png)

The model further detailed in the following section.

## Scalability and Technical Implementation

With the conceptual model shown in the last section, it is time to
dive into implementation in a  practical situation.  The beauty of
the model  is its  modularity, so  a component -  such as  a cloud
server, can  easily be  put in a  local and  physically controlled
location.  Thus, please consider  the technologies mentioned as an
example -  the power  of the  model comes to  play when  you start
switching things up.

### Server Side Components

Consider theavailability of external services  in all parts of the
process.  Ideally  a travel  device should store  information only
outside  the regional  location of  a traveller.   Balance storage
with requirements of availability.  An  example of such is that an
enforced VPN connection  may not always be  available, which would
practically leave an SFTP link exposed or down.

For  the example  technologies  used  in the  model  shown in  the
previous section, following sections shows the use.

#### Cloud Policy, Provisioning, Device and User Management

The reason  we really need to  use a device management  service is
the  scalability of  deployment. Using  a standalone  approach may
work and provide some additional  security due to the independence
of each device, but it is inevitable in the long run if you handle
even a low amount of travels.

In this  case, especially due  to using  ChromeOS, G Suite  is the
most straightforward choice. It is important to focus the solution
on  managing  devices  when   speaking  of  travels,  not  pushing
sensitive  configuration  files  and  so on.   If  encountering  a
compromise of the G Suite  administrative account - it is possible
to push threat actor-controlled applications and configurations to
devices.  Due to this it is  essential to clean out the management
domain or create a new, untraceable one once in a while.

G Suite is  a granular solution. Examples  of recommended policies
are: enforced  use of security  tokens and the disabling  of other
two factor authentication options, screen  lock upon lid close and
so on.

When testing G Suite and ChromeOS  I figured that it is easiest to
provision  VPN  configuration  files (``.onc``)  and  certificates
manually. For iOS the same goes with ``.mobileconfig``. Doing this
adds another protective layer.

#### VPN

For VPN, my  experience is that the most reliable  option is using
native  supported VPN  clients in  the operating  system used  for
travel. In  this case  it is  ChromeOS with  OpenVPN and  iOS with
IPSec. This adds  a bit to the complexity as  iOS does not support
OpenVPN which  runs most reliably  in some countries  that censors
the  Internet. However,  ChromeOS does.  The solution  to this  is
using two VPS nodes for tunneling traffic:

1. OpenVPN service through ansible-openvpn-hardened [4]
2.   IPSec  service   through  [5].    Lenny  Zeltser   created  a
   deployment-guide on algo recently [6]

Again:  to  reduce exposure  through  centrality,  you should  not
provision   device-specific    keys   from    central   management
consoles. Also, make sure to  use certificates by any service that
needs to connect to the Internet.

**OpenVPN**:

Configure     according      to     the     README      on     the
``ansible-openvpn-hardened``  Github page.   When  you deploy  the
OpenVPN server, you will be left  with a file named something like
``<user-id>@<random-word>.preregistration-pki-embedded.ovpn``   in
the ``fetched_credentials/<domain>``  directory.  Just  like Apple
has  its ``mobileconfig``  format, the  Chromium Project  uses the
Open Network  Configuration (ONC)  [7]. In  order to  convert this
format to a  working configuration file, use  ovpn2onc.py [9] like
the following.

    python3 reference/convert.py --infile *-pki-embedded.ovpn \
                --outfile vpn_configuration.onc --name my_vpn

This     results     in     a     configuration     file     named
``vpn_configuration.onc``. ChromeOS will not give you any feedback
here, so make sure to read  through everything to get it right the
first  time. If  you  end  up troubleshooting,  I  found that  the
Chromium  project  do  have  some  working  examples  [9].  Import
``vpn_configuration.onc`` in Chrome as shown in the next section.

Due to  the hardened  setup, be  particularly strict  to configure
with  an OS  version according  to the  repo README.  For instance
Debian 8.10 won't work.

**Algo**: Has great docs as-is.

#### SFTP

An  SFTP service  is  simple to  manually  deploy.  However,  when
scalability  hardening   matters  it  is  best   to  automate  the
deployment.  Through testing available  Ansible scripts I ended up
with Johan  Meiring's ansible-sftp [10]. Again,  the configuration
is  self-explanatory.  You should  however note  that public
keys   should   be   put   in   a   ``files/``   directory   under
``ansible-sftp``    root.    These    can   be    generated   with
``ssh-keygen``, the private keys needs to be stored somewhere else
for manual transfer to the laptop accessing it.

Since  this is  a  traveller setup  you should  seek  to create  a
disconnect between cloud  drives and rather use  local storage and
SFTP. Disable OneDrive in Office  365 Business and Google Drive in
G Suite.

#### Deploying an Out-of-Band (OOB) Channel

Communications  is king  and  perhaps one  of  the most  important
things you configure.

I described using Matrix and Riot for OOB recently [11].

#### Security Keys

Nowadays, strong  authentication is  so easy that  everyone should
use  it. In  a  hostile  environment it  is  hygiene. Google  uses
Yubikeys and  Feitian tokens in their  authentication services and
so  should a  traveller [12,13,14].  This eliminates  some of  the
uncertainty  when authenticating  against  remote  servers and  is
something the  traveller can keep  on-body at all times.  For this
setup  not  every  service   can  maintain  usability  when  using
tokens. Those services  - such as a mounted SFTP  share should use
certificates.


### Client Side Components

So why a Chromebook?

*  Has a  minimal  configuration.   Everything you  do  is in  the
  browser
* You get granular control through G Suite
*  Based on  the Linux-kernel,  which means  it is  different from
  Windows and may require some extra effort from a threat actor
* A lot of work has gone  in to the user interface in ChromeOS, so
  it will feel familiar and intuitive to users
* ChromeOS has a lot of security features built-in [15], such as:
  Secure Boot, Security Key login and so on.

G Suite  will help you a  little bit on  the way when it  comes to
configuration  control.   However,  it requires  some  client-side
configuration.

The client side consists of components.  I chose to model these as
five layers:

The  Traveller. The  most important  asset on  the travel  is most
likely  your human  traveller. This  asset will  have some  values
assigned to  it, such  as security keys,  credentials and  his own
knowledge.   Anonymise information  stored here.  In other  words,
make sure to use an identifier and not the travellers real name.

Device  and  information.  When   selecting  devices  and  putting
information  on it  you have  entered the  device and  information
exposure  layer.  This  will  typically consist  of  all  hardware
peripherals, such as cameras, and  content such as calls made from
a handset. Other things to consider here for ChromeOS is deploying
PGP  and its  keys with  Mailvelope  and Office  from Google  Play
Store.

Content. It was actually kind of interesting to model this from an
iOS and ChromeOS  perspective, because ChromeOS keeps  most of its
applications in the browser while iOS has native apps on line with
Chrome. This again means that  the exposure surface of ChromeOS is
more uniform than on iOS.

Native applications. This is  the actual applications installed in
the operating  system directly. For  iOS this has  larger exposure
with  native  applications  for   e.g.  communications,  while  on
ChromeOS you  will basically  only install an  SFTP plugin  to the
file system and use Chrome for a travel.

Transport.  When  travelling to a hostile  environment, tunnel all
communications to and from the system as far as possible. Both iOS
and ChromeOS has sufficient mechanisms  here as we reviewed in the
previous section. For encryption keys:
    
1. Transfer  encryption keys stored  in the ``.p12`` file  and the
   configuration to the Chromebook
2.          Install           encryption          keys          in
   ``chrome://settings/certificates``. Use  the "Import  and Bind"
   option to install the certificate to TPM
2.     Import      the     VPN     configuration      (ONC)     in
   ``chrome://net-internals/#chromeos``

That is basically it.

## Conclusion

The art of  balancing threat resiliency, usability and  cost is an
intriguing problem.

The technology out there, presented in  this article, is in no way
designed to  survive in hostile environments  when considering the
capabilities of  nation state threat actors.  Fundamental security
mechanisms are  lacking in  this regard,  and only  companies like
Microsoft,  Google  and Apple  can  provide  the basis  to  change
those. We can however slow these actors down considerably.

An important  aspect to consider,  in order to compensate  for the
above  weaknesses, is  that  organisations needs  to handle  these
problems on an operational and strategic level as well.

Using cloud environments  are a solid choice  for travel. However,
when considering threat actors that are able to gain access to the
hosts  of those  environments they  are not  sufficient. To  solve
this, the  most valuable services  may be  moved in-house or  to a
hardened cloud environment. End-to-end encryption is also required
when using cloud  services, such as when using  the included inbox
of G Suite.

Please keep in mind that The Tactical Traveler Protection Model is
a  core model.  This  article  does not  cover  every aspect.   An
example  of   such  is  encryption  and   protection  of  external
peripherals  and  memory  devices and  operational  and  strategic
considerations.

Organisations  have yet  to  prove a  working  model resilient  to
capable adversaries.  Hopefully this  article will be a foundation
to discuss variations and weaknesses in the community.



[1] https://motherboard.vice.com/en_us/article/a3q374/hacker-bios-firmware-backdoor-evil-maid-attack-laptop-5-minutes

[2] https://mitre.github.io/attack-navigator/enterprise/

[3] https://attack.mitre.org/wiki/Initial_Access

[4] https://github.com/bau-sec/ansible-openvpn-hardened

[5] https://github.com/trailofbits/algo

[6] https://zeltser.com/deploy-algo-vpn-digital-ocean/

[7] https://www.chromium.org/chromium-os/chromiumos-design-docs/open-network-configuration

[8] https://gist.github.com/tommyskg/6d0eeecc5bab65a49d72f5b16e086976

[9] https://chromium.googlesource.com/chromium/src/+/32352ad08ee673a4d43e8593ce988b224f6482d3/chromeos/test/data/network

[10] https://github.com/johanmeiring/ansible-sftp

[11] https://secdiary.com/2018-07-11-matrix.html

[12] https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/

[13] https://www.yubico.com/product/yubikey-4-series/#yubikey-4c

[14] https://ftsafe.com/onlinestore/product?id=3

[15] http://dhanus.mit.edu/docs/ChromeOSSecurity.pdf