client side decryption with yubikey (FIDO/U2F)

[dada216]

hello there.
we are in the process of exploring solutions (enterprise level) for encrypting fileservers, after the nth data breach and exfiltration and when it finally happened to them this customer is not taking it seriously, and they are more than welcoming open source and the likes based solutions.
I've been reading a bit into the documentation and it's not clear to me if TrueNAS (enterprise) could offer this kind of solution, or at least be part of such an infra.

what we want is client side decryption, user based keys, ability to share files (hence decrypting with multiple user keys), on the client side the keys should reside on a yubikey and ideally this should be as transparent as possible for the user, they are obv windows clients. storage would be SAN based (fiber channel), the server would reside on a VM, there's also windows and linux servers in the mix that need access to the shares.

 

[Samuel Tai]

TrueNAS Core (the enthusiast edition, not the Enterprise edition) doesn't have official support for Fibre Channel, although some enterprising folks have made it work, so it probably doesn't fit your use case.

As for the encryption, I don't understand your use case. Are you asking for multi-user shares with multiple decrypt keys (1 per user + escrows)? Or home shares with individual decrypt keys + escrow? Please expand your encryption strawman design, please.

 

[Heracles]

what we want is client side decryption

Very problematic in an enterprise environment...

user based keys

To have that client-side decryption, user based keys is a requirement. So this is the same as your first.

ability to share files (hence decrypting with multiple user keys)

This is why client-side decryption is so problematic in enterprise. More on that later...

on the client side the keys should reside on a yubikey

Not sure if that specific support is an option... I never used them. myself but I think that yubikey is doing only authentication. As such, the encryption key would not reside in it. In all cases, this is NOT something you wish to have any way.


So about file-level encryption in enterprise...

You MUST put in place a key escrow service when doing user-level encryption in an enterprise environment. Whenever an employee is unavailable (sick, vacation, fired, lost or broken key...), the enterprise MUST be able to recover its data. For that, it must be able to decrypt everything. That either requires a copy of this user's key or the use of a master key. If everything is controlled by the client as you said you would like, you can not ensure that it will enforce the Master key. For that reason, you must save a copy of each and every users' keys.

To manage so many keys, keep all of them safe and up-to-date is an impossible task without a specialized infrastructure for that. Such an infrastructure is called a PKI. To put one in place is a very major project that requires real expertise.

Better options would be something like Nextcloud's server-side encryption.

Everything is encrypted by Nextcloud with keys linked with the user's password. If someone breach the server, he will not have access to the data while as a server, Nextcloud can still share and distribute the content when needed. Whenever a share is created, Nextcloud adjust the key manangement. The administrator can also force himself an access in any user's account, so can always access everything.

For an intruder to gain access, he must make it up to Admin level in Nextcloud. Other way, even as system admin, he will only be able to see the data that will be handled by the users at that very moment and not grab everything.

What you are looking for will hit you back and will most likely turn to a self-inflicted ransomware more than an actual security solution.

 

[dada216]

TrueNAS Core (the enthusiast edition, not the Enterprise edition) doesn't have official support for Fibre Channel, although some enterprising folks have made it work, so it probably doesn't fit your use case.

As for the encryption, I don't understand your use case. Are you asking for multi-user shares with multiple decrypt keys (1 per user + escrows)? Or home shares with individual decrypt keys + escrow? Please expand your encryption strawman design, please.

We are looking into the enterprise edition.

currently there's standard file shares, windows based. we are exploring options to achieve two things:
1) keep user/group based access and shared files options
2) encrypt the data
3) decrypt the data client side, preferably making use of yubikey

 

[dada216]

Very problematic in an enterprise environment...

correct, it's not an easy thing to design and deploy.
if you think about it all the pieces are there, putting them together is another story tho.

To have that client-side decryption, user based keys is a requirement. So this is the same as your first.

correct.

This is why client-side decryption is so problematic in enterprise. More on that later...

Agreed, I even thought about a simmetric key, and one key only.

Not sure if that specific support is an option... I never used them. myself but I think that yubikey is doing only authentication. As such, the encryption key would not reside in it. In all cases, this is NOT something you wish to have any way.

the yubikey can hold keys (it does hold a key), and you can generate a key and save it to the hardware itself, or you can do some sort of challenge response, that is what is being used for auth only.

So about file-level encryption in enterprise...

You MUST put in place a key escrow service when doing user-level encryption in an enterprise environment. Whenever an employee is unavailable (sick, vacation, fired, lost or broken key...), the enterprise MUST be able to recover its data. For that, it must be able to decrypt everything. That either requires a copy of this user's key or the use of a master key. If everything is controlled by the client as you said you would like, you can not ensure that it will enforce the Master key. For that reason, you must save a copy of each and every users' keys.

a master key would be acceptable, so would be having a copy of each user key, even having a copy of their hardware token.

To manage so many keys, keep all of them safe and up-to-date is an impossible task without a specialized infrastructure for that. Such an infrastructure is called a PKI. To put one in place is a very major project that requires real expertise.

I understand that, there are products around that do that, and we do have the expertise to handle such products, we are looking into KMIP, hashicorp vault and similar products

Better options would be something like Nextcloud's server-side encryption.

server side has it's drawbacks, once that server is being compromised the key is probably compromised as well, nextcloud is an option tho.

Everything is encrypted by Nextcloud with keys linked with the user's password. If someone breach the server, he will not have access to the data while as a server, Nextcloud can still share and distribute the content when needed. Whenever a share is created, Nextcloud adjust the key manangement. The administrator can also force himself an access in any user's account, so can always access everything.

For an intruder to gain access, he must make it up to Admin level in Nextcloud. Other way, even as system admin, he will only be able to see the data that will be handled by the users at that very moment and not grab everything.

even a root access to the machine does the same, because you can just use the cli to reset the admin password and get access to the keys that way.

What you are looking for will hit you back and will most likely turn to a self-inflicted ransomware more than an actual security solution.

no, that's not gonna be the case, we are very much aware of the risk of key losses, but a master key and/or having copies of the users key is an option here, even when considering hardware tokens that handle the keys, you just have to keep a secondo copy of it in a secure place.

the problem is marrying all the pieces together in a way that can be mantained and allows shared file access.

 

[Heracles]

If you use the Docker version of Nextcloud, to see anyone break into it up to root from the front door would be almost impossible. Such an intrusion would have to come from the network and OS level of the server, meaning that the intruder will probably have access to your key escrow store as well.

If you really wish to hurt yourself up to that point, you can use Nextcloud's End-To-End encryption. In that way, it is the Nextcloud client that does it all and the server has no access to data. The consequence is that data are now exposed to the same security level as your endpoints, just like you wish.

Just think about it... What is safer : your endpoints that are so numerous, outside of physical security and control, handled by regular users, used to surf the Internet and more, or is it your server that is physically secured, managed by expert, hardened properly, that does not act as a client to Internet services and more ?

To put your data's security down to the level of your endpoints is non-sense. Your server is capable of a security a million time stronger. As such, you should hardened and monitor your server instead of dropping your data's security to a lower level by delegating their security to endpoints.

Also, what would be the worst security incident ? An incident where an intruder get access to your data but after which you still have them, or an incident where no one made it to your data, but you can not access them yourself either ? You should not put confidentiality ahead of availability. Without your data, your entreprise does not exist. It is plain nothing. Once your data are lost, it will hurt for sure, but you will still be there.

So do a proper network design for your enterprise : Servers in a secured segment behind a firewall, not used as clients for external services, covered by a proper patch management solution, with user rights managed properly, using strong authentication and similar. Consider your endpoints are the compromised entity in your network, not your server. You will be a million time better protecting your server against your compromised endpoints and compromised network segments vs trying to secure your data by dropping their security level to the level of your endpoints.

 

[dada216]

If you use the Docker version of Nextcloud, to see anyone break into it up to root from the front door would be almost impossible. Such an intrusion would have to come from the network and OS level of the server, meaning that the intruder will probably have access to your key escrow store as well.

that is exactly what keys on the client side are for, and on the client side I want hardware tokens.

I'm very well aware of all the drawbacks of all those solutions, compromises have to be made.

If you really wish to hurt yourself up to that point, you can use Nextcloud's End-To-End encryption. In that way, it is the Nextcloud client that does it all and the server has no access to data.

that is not correct, but anyways.

The consequence is that data are now exposed to the same security level as your endpoints, just like you wish.

h-a-r-d-w-a-r-e t-o-k-e-n-s
moreover, with multiple keys you can have one server holding files from many different groups and even if an attacker gets an endpoint at the most he's gonna get access to that group's file.
as I said, compromises, all solutions have their drawbacks.

Just think about it... What is safer : your endpoints that are so numerous, outside of physical security and control, handled by regular users, used to surf the Internet and more, or is it your server that is physically secured, managed by expert, hardened properly, that does not act as a client to Internet services and more ?

you don't know the details of the customer we are looking this into for.

To put your data's security down to the level of your endpoints is non-sense. Your server is capable of a security a million time stronger. As such, you should hardened and monitor your server instead of dropping your data's security to a lower level by delegating their security to endpoints.

it seems you think one thing is excluding the other.

Also, what would be the worst security incident ? An incident where an intruder get access to your data but after which you still have them, or an incident where no one made it to your data, but you can not access them yourself either ? You should not put confidentiality ahead of availability. Without your data, your entreprise does not exist. It is plain nothing. Once your data are lost, it will hurt for sure, but you will still be there.

that is another issue entirely.

So do a proper network design for your enterprise : Servers in a secured segment behind a firewall, not used as clients for external services, covered by a proper patch management solution, with user rights managed properly, using strong authentication and similar. Consider your endpoints are the compromised entity in your network, not your server. You will be a million time better protecting your server against your compromised endpoints and compromised network segments vs trying to secure your data by dropping their security level to the level of your endpoints.

you seem to think you are talking to an amateur, I'm not.
if you have information about how exactly TrueNAS could be part of the chain we're building you are welcome to provide it, if you intend to lecture on the basics that is not what I'm looking for from a stranger on the internet, thank you.

 

[Samuel Tai]

I only found one enterprise product that does what you're looking for. HiCrypt, which integrates with YubiKeys. (Note, this appears to be a German product, so it may not be available to your customer.) However, this only works with Microsoft Server OSs, and doesn't support Samba, which is the SMB layer in TrueNAS. For TrueNAS, you'd have to share out individual iSCSI disks to users, which could then be encrypted with BitLocker, which appears to be the only YubiKey-compatible encryption that would work with TrueNAS. For your use case, it doesn't appear TrueNAS is a good fit.

 

[danb35]

I think that yubikey is doing only authentication

Certain models of YubiKey are able to store and even use encryption keys; I'm using one as a poor man's HSM in my local CA (see https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi-yubikey/ for details on what I did). I'm sure it doesn't meet whatever are the relevant NIST/FIPS/whatever standards, but it's still kind of nice that the signing key is inaccessible, and has in fact never existed on the filesystem of the system I'm using. But its relevance to OP's scenario is uncertain.

 

[ChrisRJ]

you seem to think you are talking to an amateur, I'm not.
if you have information about how exactly TrueNAS could be part of the chain we're building you are welcome to provide it, if you intend to lecture on the basics that is not what I'm looking for from a stranger on the internet, thank you.

We do not know you as a person or your level of competence in the areas of storage, encryption, PKI, etc. All we can judge you by is what you write in this thread, because you are new to the forum. It seems that you feel patronized by the fact that someone, who has spent a ton of time here, warns you about various aspects of the approach you have only very roughly sketched out.

If someone from the senior people on this form, like @Heracles, brings up the basics, this is happening for a reason. And, frankly, I think it deserves a "thank you, but I am aware of all this, although I didn't tell you, so you wasted your time". If someone who knows at least as much as I on the subject, answers my question with something completely different from what I expected, it usually means that my question needs refinement.

 

[Heracles]

h-a-r-d-w-a-r-e t-o-k-e-n-s

You really think that such tokens are magical ? Most of them are just memories. As such, whenever plugged in, the key is moved to RAM where it can be stolen cleartext just as easily as any other data.

Even if you get one with hardware processing, once the key is unlocked, it will just decrypt the data the intruder is looking for before he transfers the cleartext version of what he is looking for. Did you not yourself said that you were looking for the most transparent solution possible ? To be that transparent means that an intruder will have access to the decryption service just as easily as the main user.

The basic rule of cryptography is that it can not offer a protection greater than the protection applied to the key itself. Whenever / wherever the cryptogram and the key are present at the same place and time, crypto is defeated by definition because cryptogram + key = cleartext. In your setup, you look to have these two regrouped in the endpoint, so that will be the overall security level your data will have :
cryptogram + key + endpoint = cleartext + endpoint.

it seems you think one thing is excluding the other.

Indeed, they must be exclusive. One major thing to know is that security is as strong as its weakest link. If you have only one link (server OR endpoints), you are as strong as that one. If you have both, you are weaker than either of them because you have all the weakness from the weakest plus the few different extra weakness from the other. The consequence is that you will always be weaker than the weakest. To expose yourself to both risks is an even bigger non-sense than dropping to the security level your endpoints have. The proper thing would be server only. You insist for doing endpoint only, so do it. Just don't add the two set of weakness to reduce your security to even lower.

that is another issue entirely.

No, it is the same. It illustrates how your confidentiality solution turns into a threat to availability. To mitigate the risk to availability, you need a complete key escrow system, complete key management, etc. These features themselves bring their own risk and should they fail, they will either expose everything back and defeat your confidentiality or they will fail to gain you back access to your own data, turning your "solution" to a self-inflicted ransomware.

you seem to think you are talking to an amateur, I'm not.

I'am just a security engineer with over 20 years of experience, training police corps, lawyers, securing financial institutions and large enterprises....

There are no proper way of doing what you are trying to do because what you are looking for is non-sense. You should not drop your data's security to the level achieved on the endpoint because you consider the server as not safe enough. By definition, the endpoint are worst than the server. If the servers are not safe enough, the proper solution is to harden them / secure them better and not delegate their role to endpoints.

If you insist to go down that path and have your encryption micro-managed on the endpoint on a per-user and per-data basis, you need a complete PKI first. Once that PKI is in place, that one will provide you with the tool you need for file-level encryption in a way that should be more security than risk. As such, the tool you are looking for is not from TrueNAS, it is from such a PKI like Entrust.

 

[dada216]

I only found one enterprise product that does what you're looking for. HiCrypt, which integrates with YubiKeys. (Note, this appears to be a German product, so it may not be available to your customer.) However, this only works with Microsoft Server OSs, and doesn't support Samba, which is the SMB layer in TrueNAS. For TrueNAS, you'd have to share out individual iSCSI disks to users, which could then be encrypted with BitLocker, which appears to be the only YubiKey-compatible encryption that would work with TrueNAS. For your use case, it doesn't appear TrueNAS is a good fit.

we've looked into HiCrypt, it's an option we are taking into account.
we've also looked into BoxCryptor, another german product which operates on a file level only and would be compatible with any storage backend.
we are gonna develop a custom solution either on our own or together with one such company.

BitLocker can achieve keys on the TPM and auth via yubikey, but it requires a solution to allow sharing of those files over which ever protocols one chooses.

trueNAS does not appear to be a good fit for this particular project, I do find it interesting tho and I started testing it in our lab for other purposes, especially zfs replication, for a number of smaller customers it could be an alternative to the very expensive solutions native to SANs, it would also allow to build something interesting without an actual SAN.
it seems like a good project, If I find the time I can also provide expertise on KVM to test it with trueNAS scale.

 

[dada216]

Certain models of YubiKey are able to store and even use encryption keys; I'm using one as a poor man's HSM in my local CA (see https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi-yubikey/ for details on what I did). I'm sure it doesn't meet whatever are the relevant NIST/FIPS/whatever standards, but it's still kind of nice that the signing key is inaccessible, and has in fact never existed on the filesystem of the system I'm using. But its relevance to OP's scenario is uncertain.

yubikey does provide an actual HSM as well, and you can unlock the HSM with a yubikey, we're also looking into that route.

 

[dada216]

You really think that such tokens are magical ? Most of them are just memories. As such, whenever plugged in, the key is moved to RAM where it can be stolen cleartext just as easily as any other data.

have you ever actually used an hsm? have you ever actually implemented a keychain in software?
what you said is not entirely correct.

Even if you get one with hardware processing, once the key is unlocked, it will just decrypt the data the intruder is looking for before he transfers the cleartext version of what he is looking for. Did you not yourself said that you were looking for the most transparent solution possible ? To be that transparent means that an intruder will have access to the decryption service just as easily as the main user.

correct, once the data is decrypted it resides in memory, an hypothetical attacker can get to the cleartext data in memory, getting to the key itself is another story tho, bot in the case of a simple challenge response (think pkcs12) done with a yubikey or a proper hsm with the whole keychain on it who's actually decrypting the bits.
and we're talking about a very sophisticated kind of attack anyways.
perfect security does not exists, hardware tokens (hsm or auth only yubikey) definitely elevate the level of security.

The basic rule of cryptography is that it can not offer a protection greater than the protection applied to the key itself. Whenever / wherever the cryptogram and the key are present at the same place and time

it's not that simple when you actually implement this, but anyways, the general idea is correct, the details of it in a real world implementations are very different from theory tho.

, crypto is defeated by definition because cryptogram + key = cleartext. In your setup, you look to have these two regrouped in the endpoint, so that will be the overall security level your data will have :
cryptogram + key + endpoint = cleartext + endpoint.

not really, but anyways.

Indeed, they must be exclusive.

no, they are not, endpoint security and server security are not mutually exclusive, they are different layers, and depending on the specific of the situation you might want to shift certain risks to one or the other.

One major thing to know is that security is as strong as its weakest link. If you have only one link (server OR endpoints), you are as strong as that one. If you have both, you are weaker than either of them because you have all the weakness from the weakest plus the few different extra weakness from the other.

this is very generic and general.

The consequence is that you will always be weaker than the weakest. To expose yourself to both risks is an even bigger non-sense than dropping to the security level your endpoints have.

you do not understand the scenario I am operating in.

The proper thing would be server only. You insist for doing endpoint only, so do it. Just don't add the two set of weakness to reduce your security to even lower.

you don't understand what I'm doing.

No, it is the same. It illustrates how your confidentiality solution turns into a threat to availability. To mitigate the risk to availability, you need a complete key escrow system, complete key management, etc. These features themselves bring their own risk and should they fail, they will either expose everything back and defeat your confidentiality or they will fail to gain you back access to your own data, turning your "solution" to a self-inflicted ransomware.

and if server security fails, as it does, the situation is the same.
you are not really describing the weakness of any particular implementations, you are simply describing generic and general weakness in any IT system.

I'am just a security engineer with over 20 years of experience, training police corps, lawyers, securing financial institutions and large enterprises....

and you do not seem to have enough experience to understand there's plenty of different scenarios in plenty of different industries.
what you described is very general and generic.

There are no proper way of doing what you are trying to do because what you are looking for is non-sense. You should not drop your data's security to the level achieved on the endpoint because you consider the server as not safe enough. By definition, the endpoint are worst than the server. If the servers are not safe enough, the proper solution is to harden them / secure them better and not delegate their role to endpoints.

you don't understand every single possible scenario, in this scenario these endpoints are extremely secure, almost airgapped, and heavily monitored.
the servers they are using to exchange files are secured as well, for a number of reasons it makes sense to hold the keys on the endpoint.

If you insist to go down that path and have your encryption micro-managed on the endpoint on a per-user and per-data basis,

yes

you need a complete PKI first.

yes

Once that PKI is in place, that one will provide you with the tool you need for file-level encryption in a way that should be more security than risk. As such, the tool you are looking for is not from TrueNAS, it is from such a PKI like Entrust.

and I was asking what level of integration can TrueNAS offer in such a system, and it's no different than any generic linux/windows server in this regard, since I'm not familiar with TrueNAS that's what I was asking, what I got from you is a generic lecture on security that absolutely does not apply to the scenario I'm currently operating in.

btw, you mentioned nextcloud end to end encryption, did you try it yourself before suggesting it?
I did, and I wasted half a day, it hasn't been fully implemented (i.e. sharing hasn't been implemented as of today) and is extremely buggy

 

[Samuel Tai]

@dada216, @Heracles, this is getting out of hand. I'll lock this thread for further comments. Please refrain from further displays of e-masculinity.