Hard disk encryption without OS access?
-
One thing I've seen done as a reasonable no-human system... is that the OS fires up, cannot access the data, calls out to another system that is physically extremely isolated from itself, but is reachable by network. That system does a series of checks to ensure it believes that the system is what it says that it is (such as verifying IP address and such) and then using an encrypted channel reaches out and decrypts the drive.
It's potentially actually safer than having a human verify. It's SO hard to work around or foresee or hack. Humans can be threatened, computers cannot. Stealing two entire systems from two different locations at the exact same time is extremely hard. Easier to put a gun to someone's head, for sure. And it guarantees the checks are done every time, and quickly.
-
@scottalanmiller said in Hard disk encryption without OS access?:
Why not do what I said? Seems like a REALLY simple solution that actually solves every aspect of the problem, including intent.
Because I hadn't read it yet
Hehehe...... -
@JasGot said in Hard disk encryption without OS access?:
@scottalanmiller said in Hard disk encryption without OS access?:
How are you taking backups today?
The software vendor does. But VM will give us the ability for our own backup as a safeguard, right?
Exactly. That's what I was thinking. If you don't have OS access today, and you don't control the app, how do you know that backups are good? I am not a big fan of VM level backups generally, but this is a case where that brute force makes a LOT of sense (to me.)
-
@scottalanmiller said in Hard disk encryption without OS access?:
That would be the intent of any "encrypted at rest" request.
Correct!
-
@Obsolesce said in Hard disk encryption without OS access?:
@scottalanmiller said in Hard disk encryption without OS access?:
If they steal the drives containing the operating system too, no more encryption.
Not with full disk encryption, unless you steal the entire server. Full disk encryption is tied to the TPM for example, so you'd need the entire thing to decrypt a hard drive or virtual disk.
Yes, there's a middle ground where someone has stolen LOTS of drives, but not the server containing them. It would protect against that case which I've never heard happen. It's a contrived case. Anyone going to that level of effort will actually find it easier to grab the server and run rather than to take the time to remove ALL the drives, but not the case that they are already in.
-
@Obsolesce said in Hard disk encryption without OS access?:
Full disk encryption is tied to the TPM for example
Actually it often is not. It CAN be, and that's a nice feature in some cases. BUT, how do you move those drives to another server when you do that (maybe it's easy, but what does the TPM do then?) Assuming drive mobility is a factor, and typically it is, you can't use that kind of full disk encryption, but you are stuck with the normal kind which doesn't use any special hardware. Then you get the assumed portability of the hardware, but just stealing the drives is enough.
-
@scottalanmiller said in Hard disk encryption without OS access?:
@JasGot said in Hard disk encryption without OS access?:
@JaredBusch said in Hard disk encryption without OS access?:
without a user present.
This is ok.
If a user isn't present, it can't qualify as encrypted. Or something equivalent to a user. This is the same as intentionally not complying. If that's okay, why not just ignore the request altogether?
I meant: it's ok if a user has to go and start up the server after an outage.
-
@scottalanmiller said in Hard disk encryption without OS access?:
@Obsolesce said in Hard disk encryption without OS access?:
Full disk encryption is tied to the TPM for example
Actually it often is not. It CAN be, and that's a nice feature in some cases. BUT, how do you move those drives to another server when you do that (maybe it's easy, but what does the TPM do then?) Assuming drive mobility is a factor, and typically it is, you can't use that kind of full disk encryption, but you are stuck with the normal kind which doesn't use any special hardware. Then you get the assumed portability of the hardware, but just stealing the drives is enough.
It should always be. And if not, like in cases where your hardware doesn't support it (no TPM), then you would be forced to use a password to unlock it. Full disk encryption with the key in the keyhole is pointless. I've not heard of any other way of doing it, that wouldn't make sense.
You can easily move drives to another system, in that case you'd need to enter the recovery key to unlock it.
-
Found some more info: https://ubuntu.com/core/docs/uc20/full-disk-encryption
-
@scottalanmiller said in Hard disk encryption without OS access?:
@pmoncho said in Hard disk encryption without OS access?:
If the client controls the server hardware, then SED SSD is a an option.
If they control the hardware, they can virtualize. Just image the system and done.
I'd like to explore this further. What is the best VM host these days?
-
@JasGot said in Hard disk encryption without OS access?:
@scottalanmiller said in Hard disk encryption without OS access?:
@pmoncho said in Hard disk encryption without OS access?:
If the client controls the server hardware, then SED SSD is a an option.
If they control the hardware, they can virtualize. Just image the system and done.
I'd like to explore this further. What is the best VM host these days?
We use ProxMox. KVM is definitely the leader on the hypervisor side. Which package you use for it is up to you. We've had great luck with ProxMox now, though. We are running a LOT of them.
-
@Obsolesce said in Hard disk encryption without OS access?:
It should always be. And if not, like in cases where your hardware doesn't support it (no TPM), then you would be forced to use a password to unlock it.
In essentially all cases, you'd want that anyway. Otherwise the fear of someone just stealing your computer remains. They just take the whole thing, turn it on, and attack it anyway that they want since it is decrypted, violating the intent of the rule.
-
@JasGot said in Hard disk encryption without OS access?:
@scottalanmiller said in Hard disk encryption without OS access?:
@JasGot said in Hard disk encryption without OS access?:
@JaredBusch said in Hard disk encryption without OS access?:
without a user present.
This is ok.
If a user isn't present, it can't qualify as encrypted. Or something equivalent to a user. This is the same as intentionally not complying. If that's okay, why not just ignore the request altogether?
I meant: it's ok if a user has to go and start up the server after an outage.
Oh, then it's an easy thing. Lots of options. But I'd still do the VM route first. Solves so many things.
-
@scottalanmiller said in Hard disk encryption without OS access?:
@Obsolesce said in Hard disk encryption without OS access?:
It should always be. And if not, like in cases where your hardware doesn't support it (no TPM), then you would be forced to use a password to unlock it.
In essentially all cases, you'd want that anyway. Otherwise the fear of someone just stealing your computer remains. They just take the whole thing, turn it on, and attack it anyway that they want since it is decrypted, violating the intent of the rule.
"Just" stealing someone's computer and turning it on to attack away will not work when protected properly, for example, BitLocker full disk encryption + BitLocker startup PIN + proper DMA attack protection (likely the case by default with modern hardware). The TPM simply won't release the key any other way. So you can't really argue against that. Anyone who cares about the security of data on end-user devices will always enforce proper protection.
With server data, similar rules apply. You also want full disk encryption as well as the other protections, so that "just" taking the whole server and attacking away won't work either.
You're likely referring to the fact that many do not do it properly, but that isn't a valid argument that full disk encryption doesn't work. It does work, when used properly and how it was designed to work. When someone says you should use full disk encryption, it's implied that it's done properly. Any security measure can be done improperly and therefore made useless. That a given, so it must be implied done correctly.
-
@Obsolesce said in Hard disk encryption without OS access?:
"Just" stealing someone's computer and turning it on to attack away will not work when protected properly, for example, BitLocker full disk encryption + BitLocker startup PIN + proper DMA attack protection (likely the case by default with modern hardware).
Sure, but then you are back to having the human interaction again and how much is TPM really doing? It sounds nice, but honestly I don't trust the companies involved with it or how it is rolled out. But the PIN/user pass is what matters here, not the TPM. The TPM plays little value.
-
@Obsolesce said in Hard disk encryption without OS access?:
You're likely referring to the fact that many do not do it properly, but that isn't a valid argument that full disk encryption doesn't work.
Most systems can't allow downtime if a human cannot be present. The problem with full disk encryption is that...
- It protects against very little. It's a newly valueless threat in the server space, it's fear mongering that makes people concerned about it, even in highly critical government systems there is rarely a real threat to be protecting against.
- To be effective at all it requires such an onerous system. You have to have human(s) that hold the keys and are always available to the system to unlock it which means you need multiple people, sharing access, that are always there (or somewhere with access) which is generally costly, often defeats the value of the system, and creates huge risks of its own.
- In a case where most attackers would overcome issues in #1, kidnapping or threatening someone with the password is generally trivial by comparison.
-
@scottalanmiller said in Hard disk encryption without OS access?:
@Obsolesce said in Hard disk encryption without OS access?:
You're likely referring to the fact that many do not do it properly, but that isn't a valid argument that full disk encryption doesn't work.
Most systems can't allow downtime if a human cannot be present. The problem with full disk encryption is that...
- It protects against very little. It's a newly valueless threat in the server space, it's fear mongering that makes people concerned about it, even in highly critical government systems there is rarely a real threat to be protecting against.
- To be effective at all it requires such an onerous system. You have to have human(s) that hold the keys and are always available to the system to unlock it which means you need multiple people, sharing access, that are always there (or somewhere with access) which is generally costly, often defeats the value of the system, and creates huge risks of its own.
- In a case where most attackers would overcome issues in #1, kidnapping or threatening someone with the password is generally trivial by comparison.
Yes, in the server space I'm with you 100%. It will require extra work and I also agree with the other points. While not impossible to automate using non-human methods, it's likely not going to happen, so yeah.
My main point and concern was in regard to end-user devices where the most relevant cases are lost or stolen devices (laptops/phones/etc.). You leave it in the taxi or it gets stolen somewhere... a proper setup will prevent data access.
But yes, there is the kidnapping and threatening as you say... so why implement any data security at all then? Why have a password for example on any device if someone could simply kidnap or threaten you and get it anyways? I mean while it could happen, but it's generally not the main threat and MOST CERTAINLY is not a reason to never encrypt your disks or use passwords, or lock your house when you leave...
-
@Obsolesce said in Hard disk encryption without OS access?:
My main point and concern was in regard to end-user devices where the most relevant cases are lost or stolen devices (laptops/phones/etc.).
Sure, but that was really the point of the OP
@JasGot said in Hard disk encryption without OS access?:
The software product they use for running their business is the only app on the server and the software vendor will not allow access to the server OS.
This is primarily a server encryption discussion.
-
@Dashrender said in Hard disk encryption without OS access?:
@Obsolesce said in Hard disk encryption without OS access?:
My main point and concern was in regard to end-user devices where the most relevant cases are lost or stolen devices (laptops/phones/etc.).
Sure, but that was really the point of the OP
@JasGot said in Hard disk encryption without OS access?:
The software product they use for running their business is the only app on the server and the software vendor will not allow access to the server OS.
This is primarily a server encryption discussion.
Yes I get that. But I was really just responding in regard to the "just stealing your computer" bit. That moreso implies personal computer, at least to me. Maybe he meant breaking into a datacenter and just stealing a server, but that didn't seem like that's what he meant.
-
@Obsolesce said in Hard disk encryption without OS access?:
@scottalanmiller said in Hard disk encryption without OS access?:
@Obsolesce said in Hard disk encryption without OS access?:
You're likely referring to the fact that many do not do it properly, but that isn't a valid argument that full disk encryption doesn't work.
Most systems can't allow downtime if a human cannot be present. The problem with full disk encryption is that...
- It protects against very little. It's a newly valueless threat in the server space, it's fear mongering that makes people concerned about it, even in highly critical government systems there is rarely a real threat to be protecting against.
- To be effective at all it requires such an onerous system. You have to have human(s) that hold the keys and are always available to the system to unlock it which means you need multiple people, sharing access, that are always there (or somewhere with access) which is generally costly, often defeats the value of the system, and creates huge risks of its own.
- In a case where most attackers would overcome issues in #1, kidnapping or threatening someone with the password is generally trivial by comparison.
Yes, in the server space I'm with you 100%. It will require extra work and I also agree with the other points. While not impossible to automate using non-human methods, it's likely not going to happen, so yeah.
My main point and concern was in regard to end-user devices where the most relevant cases are lost or stolen devices (laptops/phones/etc.). You leave it in the taxi or it gets stolen somewhere... a proper setup will prevent data access.
But yes, there is the kidnapping and threatening as you say... so why implement any data security at all then? Why have a password for example on any device if someone could simply kidnap or threaten you and get it anyways? I mean while it could happen, but it's generally not the main threat and MOST CERTAINLY is not a reason to never encrypt your disks or use passwords, or lock your house when you leave...
Yes, end user devices which normally have no function without a human present can often use full disk encryption with minimal penalty. That a human must already be present changes a lot.
