How to use FDE without needing to share the encryption password

Question

We have an AI model which needs to be deployed on premise. The hardware will be provided by us, so we can do what ever we want on the device. The device is a mini PC running Ubuntu 18.04.

The UI is launched in kiosk mode so only our program will be running. The user should be able to start the machine, provide the username+password to login and the software will start automatically.

This device should be locked down. I.e. we need to:

1. Encrypt the hard-disk so that nobody can take the hard disk and copy the files by plugging into a different computer.
2. Enable the user to login and use the application.
3. Store the AI model, use it in a way that user will not be able to copy it or use it with any other software than ours.

To enable this, there are some issues that I found out. For user to use the system, we need to share the encryption password. Hence he will always be able to plug the hard disk to any other system and use it (or copy the model).

How can I overcome this issue?

Answer 1

According to my previous answer, suggestion by @logneck and a bit of google-fu, I came to the conclusion that it is possible to implement the scheme requested in the question with available tools and a lot of patience/expertise. This approach should satisfy the OP's request but is only a design guidance, as it has a number of drawbacks/pitfalls. It will help the OP defend from the naive attacker trying to copy data from the encrypted disk.

My previous idea to use a TPM chip remains valid. This guide, which I never tried, displays how to encrypt the disk without having to type a password and by preventing anyone to decrypt the data on another machine.

The TPM is normally embedded in the motherboard, so cannot be moved to other hardware. TPM performs hardware attestation, so that you can verify the hardware environment is compliant, and no third party card has been plugged into your mobo.

If hardware attestation passes, the TPM unlocks itself. Then LUKS module can request the TPM for the encryption key of the disk, which is stored inside the unlocked TPM.

If disk is moved to another machine, you won't have the key with you.

As described in the guide, the procss involves:

• Installing the distro of your choice
• Take ownership of the TPM chip using trousers and tpm-tools
• Install trustedgrub2 and use it as bootloader
• Add the LUKS decryption key to the TPM
• Seal the TPM

Sealing the TPM means doing hardware attestation. The guoide I linked speaks about BIOS boot instead of UEFI (UEFI uers are familiar with the concept of secure boot). Basically trustedgrub2 will measure the software. This can be simplified by checksumming the kernel to make sure it is not altered. TPM will also measure hardware to check that no other PCI card or similar was installed since TPM was sealed.

During the boot process, if hardware has not been touched/tampered with, and the booting kernel is the same who sealed the TPM, then TPM issues the secret LUKS key to the system, so that the system can decrypt itself.

Result: 1) the disk is encrypted, 2) no password is required at boot time, so the user can reboot the machine any time, and 3) the key cannot be recovered by a user because it lives in the hardware storage.

Note that this solution, similar to what Microsoft BitLocker, is not perfect and shares the same security pitfalls as Microsoft's solution. In fact, BitLocker powered only by TPM and not PIN was repeatedly criticized for its weaker security, which I will not be discussing here.

Answer 2

It comes to this: You want to implement a DRM scheme. Many before you have tried, all of them failed. It is not possible to give something (hardware, data) to users and prevent them from using it in an unintended way or copy it. You can make it harder, but you cannot prevent it. Others with more resources than you have tried (e.g. Sony, Microsoft, Nintendo to prevent pirating of console games) and in the end it all was broken.

Answer 3

The TPM solution above is not 100% safe (see @Josef comment). If you give the good to the customer, you should expect your data is communicated.

For a safe solution, you'll need your gizmo to phone home to a server that's under your own scrutiny.

Typically, each time your software has to compute something, it'll ask for a computation token with some way to authenticate the client. This token is generated by your server (so not under your customer hands) and it checked as valid before performing the computation.

You can use any signature scheme here, you'll need to sign the message plus a timestamp. The token is accepted if the signature match with the public key of your server and if the timestamp is not too far in the past.

If you absolutely don't want your AI model disclosed, also embed a key to decrypt the AI model file in this token (the key used for encryption must be per-device to avoid global leakage in case one is disclosed).

Ideally, upgrade your AI model from time to time and include the maximum allowed timestamp for using it. If someone succeed in capturing the "private" key to decrypt it, it'll be useless few days/week later so the damage will be limited.

Finally, you can also encrypt the classes your AI result will gives (if your AI is about classifying data), so that even with the model, it's useless/hard to make use of the model, unless you're connected to a server giving your the decryption keys.

Once you've done all of this, and spent weeks/months on this, you'll realize your competitors spent their time actually improving their products and it's now better than yours.

Answer 4

The use of TPM is a good option, but assuming that doesn't work for you, you could also consider some kind if network-based unlock.

Assuming you will have some kind of remote SSH access to the machine, you can add a small SSH daemon like dropbear to the initrd image, and configure the networking in your initrd. With that in place you can SSH and provide the password/key as needed.

You could also purchase hardware with some kind of remote management controller built in. Basically giving you an IP-KVM to remotely access the machine. With that in place you can remote in and provide credentials as needed. Securing and maintaining patches for the remote management controller becomes pretty important if you take this route.

Answer 5

Edit: this answer is based on wrong assumption but contains interesting elements of discussion

If Linux is a requirement, you'll have a hard time.

I dont' think that with available tools (Ubuntu etc) you can implement that on the fly. LUKS helps you perform FDE.

If you could use MS Windows for your application, you have BitLocker and Secure Boot to help. Ultimately, you could hack up a host node running MS Windows and emulating/virtualizing/dockerizing your application. We are focusing on FDE.

If you have resources to implement kernel code and customize the boot process of Ubuntu, feel free to consider re-implementing your own BitLocker using a hardware token, such as TPM, along with secure boot.

I will give you an answer based on MS BitLocker. As described in the Wikipedia article, TPM serves two main purposes: hardware attestation and key management (for FDE).

The idea is to build your own (uhmmmm.....) Linux module. I don't have record of an available solution. The TPM is normally embedded in the motherboard, so cannot be moved to other hardware. TPM performs hardware attestation, so that you can verify the hardware environment is compliant, and no third party card has been plugged into your mobo.

If hardware attestation passes, the TPM unlocks itself. Then LUKS module can request the TPM for the encryption key of the disk, which is stored inside the unlocked TPM.

If disk is moved to another machine, you won't have the key with you.

Note that this solution, similar (again) to what Microsoft does with BitLocker, is not perfect and could have security pitfalls. In fact, BitLocker powered only by TPM and not PIN was repeatedly criticized for its weaker security.