20

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?

  • 3
    Is it a requirement that the end user be able to restart the system, or are you able to provide it with sufficient battery backup and reliability to prevent the need for an end-user re-start for most likely circumstances? – Slartibartfast Nov 6 at 8:37
  • 12
    I think you should reconsider your design. As you say, you do not control the disk, the end user does. Does the machine require internet access? Can you send a key at runtime to decrypt the code (instead of the disk)? – schroeder Nov 6 at 9:23
  • 11
    In short, FDE is not the control that meets your needs. You need another control. – schroeder Nov 6 at 9:44
  • 12
    If you are afraid that customers will take your AI model and use it in some other software, other than yours, then the capitalist solution would be to have the better software. The more realistic approach is to consider your AI model as copyrightable good, as long as it is not merely a collection of publicly available data. In any case, you are probably better of from a Law angle than a security angle. – MechMK1 Nov 6 at 16:01
  • 2
    This is a legal question, not a security question. – erickson Nov 6 at 18:40
19

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.

  • 2
    I might be reading this incorrectly, but doesn't this solution mean that you are effectively locked into a specific Ubuntu version with that exact kernel, and as such can never again install security updates that affect the kernel? – Nzall Nov 6 at 21:45
  • 1
    @Nzall I think so, but there might be a way to have a backup key (not shared with the client) that can re-seal the kernel after an update. – Michael Nov 6 at 21:58
  • 1
    You will need to reseal the TPM after each update that affects it. From the TPM POV, a kernel update that patches a vulnerability is no different than a new kernel that added a backdoor. If you trust the live machine, you could add a hook that automatically re-sealed the TPM on every kernel update. Doing unattended updates, with machines that verify the running kernel is not without peril, though. – Ángel Nov 7 at 0:30
  • 4
    Note that this approach is going to be vulnerable to the same threats as TPM-only BitLocker. In particular, an attacker with physical access to the RAM (by tapping the pins directly, or by freezing the RAM and moving it to another machine before the state decays) will be able to extract the disk encryption key! You might be able to make the RAM tamper-resistant (and of course disable all DMA interfaces), but typical SODIMMs or similar are easy. – CBHacking Nov 7 at 1:19
  • 5
    Also note that TPM are not actually that secure – Josef Nov 7 at 9:42
23

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.

  • 5
    Not really sure this is about DRM. Most of the DRM problems come because it has to be deployed on hardware a customer owns. The OP owns the hardware/software, it just has to be deployed in a network/location that isn't 100% trusted. Sure, it won't be possible to protect it 100%, but having the proper hardware combined with good software, configuration, and monitoring may be enough to minimize the risk. – Zoredache Nov 6 at 21:37
  • 4
    @Zoredache what difference does ownership make if the hardware is installed at a customer location? If you assume the customer doesn't open the hardware, its trivial to secure it. But why not just assume the customers don't steal the AI model then? – Josef Nov 6 at 23:15
  • Perhaps not that different from the stand point of securing it, but IMO a pretty big difference from legal/ethical standpoint. Messing around with your own personally owned hardware is a lot different from attacking hardware you don't own, or have any permission to touch. Most DRM systems have to work on hardware someone personally owns. If you assume the customer doesn't open the hardware that the assumption that I believe was clear in the question, which is why I think this is not like most DRM issues. – Zoredache Nov 7 at 0:28
  • 1
    @Zoredache : If there is an option to secure it even against opening the hardware, that great. However the "does not open hardware" is a acceptable if there is no other way – Hari Nov 7 at 5:36
  • 4
    But if you assume the customer doesn't open the hardware you don't have to encrypt the disk. Because the customer wont open the hardware and connect the disk to another device! If you feel the need to encrypt the disk it proves that the constraint "customer doesn't open the hardware" doesn't actually exist! – Josef Nov 7 at 8:48
0

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.

  • If the AI model is decrypted on the device at the customers location, it's still possible to extract the unencrypted version. The only way to absolutely prevent this is to never put the model on hardware you don't control. (e.g. only compute results on your own server, located in your own facility) – Josef Nov 8 at 19:55
  • You're right that there is no limit to a unlimited power hacker. Yet, the scheme above makes the leak much less interesting because it would be: 1. time limited (model evolves and is timestamp constrained), 2. not replicable (the effort to get one model needs to be spent again for another model), 3. not discloseable (the extracted model is linked to the hacked target, that can be blacklisted) – xryl669 Nov 12 at 10:43
  • 1
    My point is that there is no way to solve the actual question. It's just not possible. What one has to do now is not to do some arbitrary stuff and say it's "good enough" but instead do a threat modeling. That means actually analyze in a structured way which threats exist, which can be mitigated and which residual risks are accepted. – Josef Nov 12 at 10:49
  • Please notice that if you split your AI model in 2 (the last part being smaller, and only stored and run on your secure server), then capturing the model will be useless. – xryl669 Nov 12 at 10:54
  • @Josef You are right, as stated in my first sentence. Yet, if the model is on the device, there is a compromise to made between having the model in clear (so it's a 2mn job to capture it) and having it encrypted with many authentication steps to get (more complex to capture but not impossible). This trade-off has to be estimated compared to the value of this model to see if it's worth it; that's my last sentence in my post. – xryl669 Nov 12 at 10:57
-1

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.

  • 4
    The problem with this idea is that, if the SSH server is running pre-decryption (and it must be, since the decryption key is sent via SSH), that means the server key cannot be stored under encryption. If the server key is stored in plain text, the attacker can extract the key and set up their own box in place of yours and signal that they've just rebooted, and when you SSH in and send over the encryption key they can steal it and use it to decrypt the whole disk. In general, there's no way to remotely authenticate hardware if the attacker physically controls that hardware. – CBHacking Nov 7 at 1:28
-1

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.

  • Thanks for the answer. However linux is a "requirement". – Hari Nov 6 at 9:35
  • 14
    Using the TPM to escrow the LUKS key in a secure boot environment on Linux has been possible for years. Why are you talking about writing a custom "Linux module"? – longneck Nov 6 at 17:00
  • 1
    @longneck please, could you provide reference? I am not up to date with Linux – usr-local-ΕΨΗΕΛΩΝ Nov 6 at 21:11
  • 3
    Note that TPM-only BitLocker+Secure Boot is not fully secure in this scenario either. TPM-only BitLocker is vulnerable to various hardware attacks; I know of no reason the same wouldn't apply to LUKS. It raises the bar for an attacker, but not beyond the capabilities of a motivated and skilled individual, and if you use removable RAM modules then I don't know any way to meaningfully mitigate such attacks. – CBHacking Nov 7 at 1:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.