- Profit4Cloud > Media > Blog > Securing your work with encrypted workspaces
To encrypt, or not to encrypt, that is no longer a question. The answer is always yes, and sometimes yes with a hardware token.
There is no reason in this day and age to leave data unencrypted. Full-disk encryption is easier than ever while the performance impact is pretty much zero. It will provide adequate protection if your laptop gets stolen or otherwise lost. In this blog we will take encryption a step further and look at how you can setup encrypted workspaces for your projects that you can mount on a per-project or per-customer basis. This will provide an additional layer of protection with extra benefits.
To go with the times, we will use authentication with a YubiKey and use an encryption back-end that hides the volume contents. Whilst seemingly overkill, setting this up requires little effort and provides a level of security that will be acceptable for working with sensitive data. The tutorial at the end will be given for Ubuntu, but the software and approach used will work on both MacOS and Windows too.
There are good reasons to apply seemingly redundant encryption. Once your OS is booted all data on your disk will appear unencrypted to you and to your applications. This can become a problem in multiple scenario’s, but the one we will highlight here is when you back-up your data to the cloud.
Many of us store a (realtime) copy of our data with a cloud provider because of the convenience it provides. Yet doing so without encryption exposes us to additional risk, as we have to assume both the encryption as well as the privacy policy of our cloud provider are in good order. When working with sensitive customer data we do not have the freedom to make either assumption.
Using encrypted volumes as an extra level of protection gives us both security and convenience, allowing us to use any cloud provider without having to trust them.
If you forget to add the SiriKali sources you will get an older version of the application without YubiKey support!
# Install packages
sudo apt install cryfs sirikali yubikey-personalization
ykpersonalize -2 -ochal-resp -ochal-hmac -ohmac-lt64 -ochal-btn-trig– Use the 2nd slot in our YubiKey (slot 1 is used for one-time-passwords)
– Set the slot to challenge-response mode
– Use HMAC-SHA1 (the cryptographic hash function)
– Less than 64 bytes of input will be used for the input
– Require touching the YubiKey
Tech deepdive: Challenge-Response & SiriKali
It is interesting to look at the Challenge-Response implementation used here in-depth, as it deviates from what you might expect. We have automatically set-up our YubiKey with a secret on slot 2 as part of activating the Challenge-Response mode. Applications can now challenge the slot with a string (the challenge) and receive a hash back that is unique for the challenge (the response). Given the same challenge, the response will be the same.
Usually an application generates a unique challenge for each authentication attempt. The response that the YubiKey calculates is then verified in the application using the same secret that is stored on the YubiKey. This way the secret is never sent across and the response is of one-time use (meaning that a malicious actor cannot re-use it).But this requires sharing the key beforehand, something we have not done here! This means that most likely the response itself is used to encrypt and decrypt the data. Using the response directly is by no means insecure, in the same sense that a static password isn’t insecure.
Since the source code of SiriKali is available we can confirm our assumptions. The challenge that is sent to our YubiKey is taken from the “Key” field in the GUI, and should you leave it empty the challenge will simply be a newline character (“\n”). The response is then used directly to encrypt and decrypt the volume we create with CryFS.
Long story short, the implementation that is used for the Challenge-Response mode here is not much different from a static password. We are therefore not using our YubiKey as a second factor, but as an extra step to transform our password.
