Travelling with electronic devices can be a challenge. 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 landscape. 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 is evolved around organisations, but might as well apply for a private travel of exposed individuals.
With that out of the way: there are several overall factors to consider. 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.
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).
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:
- The devices used for travel
- The server side infrastructure
There are arguments for a completely 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:
- The system should disclose as little as possible about the traveller’s pattern of activity and content
- As little information as possible should be at rest on devices at risk
- It should come at a high cost to compromise the end-point both for physical and technical exploitation
- The equipment should never be connected to an organisation’s service infrastructure directly before, during or after travel
- 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 secure 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 exactly 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 model is detailed further in the following section.
Scalability and Technical Implementation
Now that the conceptual model has been presented in the last section, it is time to dive into how it can be implemented 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
The availability of external services needs to be considered in all parts of the process. Ideally a travel device should store information only outside the region a traveller is located. This must be balanced 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, the following is used.
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 note that this solution should be focused on managing devices when speaking of travels, not pushing sensitive configuration files and so on. However, if the G Suite administrative account is compromised - threat actor-controlled applications and configurations can be pushed 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 policies that should be implemented is the 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.
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:
- OpenVPN service through ansible-openvpn-hardened
- IPSec service through algo. Lenny Zeltser created a deployment-guide on algo recently
Again: to reduce exposure through centrality, you should not provision device-specific keys from central management consoles. Also, make sure certificates are used by any service that needs to connect to the Internet.
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). In order to convert this format to a working configuration file, use ovpn2onc.py 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 here.
vpn_configuration.onc should be imported 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 some really great docs that can be used as-is.
An SFTP service is really quite simple to manually deploy. However, when scalability hardening matters it is best to automate the deployment. Through testing various Ansible scripts I ended up with Johan Meiring’s ansible-sftp. Again, the configuration is quite 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. For Office 365 Business OneDrive can be disabled and Google Drive can be disabled 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.
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. 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?
- It has a minimal configuration. Everything you do is in the browser
- You get granular control through G Suite
- It is 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, 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, some configuration must be done on the client side.
The client side consists of several 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. Take a note that information stored here should be anonymised. 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 several native applications e.g. for 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, all communications to and from the system should be tunneled as far as it goes. Both iOS and ChromeOS has sufficient mechanisms here as we reviewed in the previous section. For encryption keys:
- Transfer encryption keys stored in the
.p12file and the configuration to the Chromebook
- Install encryption keys in
chrome://settings/certificates. Use the “Import and Bind” option to install the certificate to TPM
- Import the VPN configuration (ONC) in
That is basically it.
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 means that not every aspect is covered in this article. 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.